微风吹过的街道 实验八 团队作业4：团队项目需求建模与系统设计

项目 内容
课程班级博客链接 班级链接
这个作业要求链接 要求链接
团队名称 微风吹过的街道
团队成员分工描述 王颖奇：例图及uml等
李婷华：规格说明书
汪慧和：系统设计说明书
杨野：wbs及文档
团队的课程学习目标 ProcessOn建模工具学习、项目需求分析建模、软件系统设计
这个作业在哪些方面帮助团队实现学习目标 学习uml模型，MVC设计模式，面向对象设计方法等
团队博客链接 博客链接
团队项目Github仓库地址链接 仓库链接

任务1：以团队协作学习方式掌握在线作图工具ProcessOn的软件操作方法。

ProcessOn简介:

  ProcessOn的使用简单，用户只需通过注册便可获得的服务，通过关注感兴趣的流程标签、专家和公司动态获取社交流信息。ProcessOn被设计的足够简洁和高效，没有打扰用户的广告信息，那些贡献高质量流程知识的顾问专家或商业公司会被推荐给访问者，那些能够提供卓越BPM系统解决方案的工具厂商也被连接到ProcessOn提供延伸服务，这些专业知识和工具服务正是每个流程化组织所需的。

  • 专业的流程模板和海量共享的流程图：
    • 价值链图（EVC）
    • 常规流程图(Flowchart)
    • 事件过程链图(EPC)
    • BPMN2.0图
    • Venn维恩图
    • Org组织结构图
    • iOS线框图
    • UI页面原型设计图
    • UML统一建模语言
  • 符合标准的格式交换，并开放私有POS格式给开发者：
    • 将Visio图转换成ProcessOn文件
    • 将BPMN2.0文件转换成ProcessOn文件
    • 将ProcessOn的BPMN图导出成BPMN格式文件
    • 将ProcessOn的图导出成开放格式的pos元数据文件
  • 强大且易于使用：
    • 提供绘制高层流程图和低层流程图的标准形状集
    • 支持Autoprompt，快速添加和连接对象
    • 从任何对象拖拽出新线条
    • 拖放来添加您自己的图片
    • 流程文件和形状的数据属性自定义
    • 提供设计分层流程体系所需的热点链接
  • 协作：
    • 包含更改即时合并与同步的实时协作
    • 不限数量的同时协作者
    • 强大的版本管控功能，包含完整的修订历史记录

任务2：整理实验七作业成果，应用面向对象分析方法（OOA），参考国标GB8567—88中《软件需求规格说明书》格式，编制团队项目需求规格说明书，并将该文档上传到团队项目Github仓库，文档内容要求如下：

  • （1）采用用例图（或者DFD图）建模表示项目功能需求，模型使用规范一致的图形符号和文字描述内容；
  • （2）参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限；
  • （3）选择适当的UML模型，建立问题域对象模型；
  • （4）编制项目的WBS
  • （5）估计各项任务所需时间

上传截图：

任务3：查阅资料，回答以下问题：

（1）何谓软件设计模式？
  软件设计模式，又称设计模式，是一套被反复使用、多数人知晓的、经过分类别目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。软件设计模式(software design pattern)根据维基百科,软件设计模式是在平常的软件设计工作中所遭遇的问题的一种通用的、可重复使用的解决方案。不出意外的话，每个从事编程项目的人都可能会有同样的思考。协作过程表明必须有一些标准和规则来使代码更加优雅并适应变化。这就是为什么我们有了 面向对象编程（OOP）和 软件框架工具。设计模式有点类似于 OOP，但它通过将变化视为自然开发过程的一部分而进一步发展。基本上，设计模式利用了一些 OOP 的思想，比如抽象和接口，但是专注于改变的过程。
  当开始开发项目时，经常会听到这样一个术语重构，它意味着通过改变代码使它变得更优雅和可复用；这就是设计模式耀眼的地方。当你处理现有代码时（无论是由其他人构建还是你自己过去构建的），了解设计模式可以帮助你以不同的方式看待事物，你将发现问题以及改进代码的方法。有很多种设计模式，其中单例模式、工厂模式和观察者模式三种最受欢迎。
（2）什么是C/S？
  C/S结构是一种（客户机/服务器）的模式，就是我们熟知的一些软件系统，比如我们经常说的某某信息管理系统，或者我们比较常用的QQ等这些桌面级的应用程序。这种模式下通络通信量比较低，降低了系统的通讯开销，响应速度快，交互性比较强。比较利于大量的数据。
服务端的特征：

  • 被动的角色（从）。
  • 等待来自客户端的请求。
  • 处理请求并传回结果。

客户端的特征：

  • 主动的角色（主）。
  • 发送请求。
  • 等待直到收到响应。

  服务器可以是有状态或者无状态的。无状态的服务器不会保留任何两个请求之间的信息，有状态服务器会记住请求之间的信息。这些信息的作用域可以是全局的或者某个事务 （session）的。静态 HTML 页面服务器是一个无状态服务器的例子，Apache Tomcat 是一个有状态服务器。服务端与客户端的交互经常使用循序图描述，循序图是 UML 中的一个标准。
（3）什么是B/S结构?
  B/S结构，是浏览器模式，客户端只需要安装一个浏览器，就可以访问服务端了。比如常用的淘宝，百度等这些网站。相对于C/S结构来说，这个结构的特点就是分布性强，维护起来方便，开发简单，总体拥有成本低，而且对于客户端来说，客户端访问的永远都是最新版本，不像C/S结构的，需要定期更新软件。B/S可以利用不断成熟的WWW的浏览器技术进行开发，例如网页语言（JavaScript，AJAX，jQuery....）等。

B/S架构的优点：

  • 1、客户端无需安装，有Web浏览器即可。
  • 2、BS架构可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。
  • 3、BS架构无需升级多个客户端，升级服务器即可。可以随时更新版本，而无需用户重新下载啊什么的。

B/S架构的缺点：

  • 1、在跨浏览器上，BS架构不尽如人意。
  • 2、表现要达到CS程序的程度需要花费不少精力。
  • 3、在速度和安全性上需要花费巨大的设计成本，这是BS架构的最大问题。
  • 4、客户端服务器端的交互是请求-响应模式，通常需要刷新页面，这并不是客户乐意看到的。（在Ajax风行后此问题得到了一定程度的缓解）

（4）什么是MVC设计模式？
  MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
  MVC模式最早由Trygve Reenskaug在1978年提出，是施乐帕罗奥多研究中心（Xerox PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件架构。MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式透过对复杂度的简化，使程序结构更加直观。软件系统透过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员可以依据自身的专长分组：

  • 控制器（Controller）- 负责转发请求，对请求进行处理。
  • 视图（View） - 界面设计人员进行图形界面设计。
  • 模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

  在最初的JSP网页中，像数据库查询语句(SQL query)这样的数据层代码和像HTML这样的表示层代码是混在一起。虽然有着经验比较丰富的开发者会将数据从表示层分离开来，但这样的良好设计通常并不是很容易做到的，实现它需要精心地计划和不断的尝试。MVC可以从根本上强制性地将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它带给我们的好处是毋庸置疑的。

  首先，多个 View 能共享一个 Model 。如今，同一个Web应用程序会提供多种用户界面，例如用户希望既能够通过浏览器来收发电子邮件，还希望通过手机来访问电子邮箱，这就要求Web网站同时能提供Internet界面和WAP界面。在MVC设计模式中， Model 响应用户请求并返回响应数据，View 负责格式化数据并把它们呈现给用户，业务逻辑和表示层分离，同一个 Model 可以被不同的 View 重用，所以大大提高了代码的可重用性。

  其次，Controller 是自包含（self-contained,指高独立内聚）的对象，与 Model 和 View 保持相对独立，所以可以方便的改变应用程序的数据层和业务规则。例如，把数据库从MySQL移植到Oracle，或者把RDBMS数据源改变成LDAP数据源，只需改变 Model 即可。一旦正确地实现了控制器，不管数据来自数据库还是LDAP服务器，View 都会正确地显示它们。由于MVC模式的三个模块相互独立，改变其中一个不会影响其他两个，所以依据这种设计思想能构造良好的少互扰性的构件。

  此外，Controller 提高了应用程序的灵活性和可配置性。Controller 可以用来连接不同的 Model 和 View 去完成用户的需求，也可以构造应用程序提供强有力的手段。给定一些可重用的 Model 、 View 和Controller 可以根据用户的需求选择适当的 Model 进行处理，然后选择适当的的 View 将处理结果显示给用户。

任务4：以任务1的成果为基础，应用面向对象设计（OOD）方法，撰写团队项目软件系统设计说明书，以回答：软件是如何实现用户需求的？文档内容要求如下：

（1）采用适合的软件设计模式设计软件系统总体结构；
（2）设计软件系统数据库逻辑结构；
（3）说明软件重用方案；
（4）设计关键类的重点服务。

上传截图：

任务5：完成《实验七 团队作业3：团队项目需求分析与原型设计》团队博文作业

  • 1.记录完成各项任务实际花费的时间和分工
任务 时间
任务1 1h
任务2 5h
任务3 3h
任务4 5h
任务5 14h
  • 2.从团队分工和协作学习角度，陈述团队实施ProcessOn建模工具学习、项目需求分析建模、软件系统设计等学习活动的心得
      总体来说Processon还是比较好用，首先它支持一些默认的组件库比较丰富，包括很多icon，会使得设计显得高大上一些，其次会有一些对齐的辅助，帮助我们快速的对齐一些基本元素，导出也相对方便。制作起来都还是挺方便的。劣势在于不支持自己的图上传，只能使用他提供的图，更好的思路可能是你从别的地方找到一个图，可以直接复制粘贴成为自己内部的元素。免费的作图张数也有限制。
      进行需求分析建模时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。分析员通过需求分析，逐步细化对软件的要求,最为困难的概念性工作便是要编写出详细的技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。如果做错，这将是会最终给系统带来极大损害的一部分，并且以后再对它进行修改也极为困难。
      软件需求是软件开发的目标,也是其项目开发成功与失败的重要因素。有时候错误的需求分析很可能导致软件开发的全盘否定,需求错误的代价会随着项目的展开儿发生变化。如果需求错误能够及时的修复，那么其代价就会被限定在一定的范围之内。如果没有及时的发现，则很可能让整个软件的开发出现大问题。明白了正确的需求的重要性，还要注意一点就是把握软件在开发过程中应该有的功能性需求和非功能性需求。软件开发的前期要首先分析和撰写需求规格说明书，这也在一定程度上给我们一个机会去深究软件本身应该具备的功能性意义。
    组员感想1：
      在设计软件系统的过程中会有好几种方案，而我们要通过对比最终获得成本、效率较高的方案，比如我们的软件是采用java语言开发的，而不是采用C语言开发，这就是一种语言选择方案。而要把在书本上学到的理论知识运用到文档说明以及软件设计，发现有很多东西其实还是有一定的出入的，这时候对我们的思想是有冲击的，对一个知识有了多方面的见解和更深刻的认识。在本次实验过程中，跟团队成员讨论如何使用ProcessOn建模工具，这是继墨刀之后又接触的一个新的东西，在进行项目需求分析建模的过程中我们对我们的整个软件进行了剖析，对一些不足也进行了整改。总之，是在不断改进中成长，最后需要感谢我的小伙伴们，我们的合作也越来越默契了。
    组员感想2：
      通过本次实验，我了解到了ProcessOn建模工具，学习了它的使用方法，并与团队相互协作，共同创建了用例图和UML，运用到了团队项目当中，完成了需求分析的项目建模。除此之外，还学习了许多与软件系统设计相关的知识，如什么是c/s，b/s和mvc设计模式等，使我受益匪浅。通过本次的实验学习，既完善了软件工程的相关知识，又加深了与小组成员的友谊与合作程度。
    组员感想3：
      本次的实验中，我们又接触到了一个新的建模工具ProcessOn，通过组内的讨论，我们先学习了如何使用这个工具，接着进行团队分工，讨论了一下与我们设计的系统所需要的文档相关的内容，将软件工程这门课学到的理论知识结合到实践中。在这个过程中也遇到了一些问题，比如各种UML建模图的实现，最终通过团队协作完成了本次的作业。在这个过程中，我们的合作也越来越顺利。
posted @ 2020-06-05 20:36  微风吹过的街道  阅读(284)  评论(1)  编辑  收藏  举报