实验八 团队作业4：团队项目需求建模与系统设计
| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/ |
| 这个作业要求链接 | https://www.cnblogs.com/nwnu-daizh/p/12976163.html |
| 团队名称 | 三带一队 |
| 团队成员分工描述 | 葛佳诚（PM）：撰写软件系统设计说明书，数据库逻辑结构设计 李佩杉：撰写软件需求规格说明书、WBS设计 张芹：撰写软件需求规格说明书、UML设计 赵栋：软件设计模式学习，用例图绘制 |
| 团队的课程学习目标 | 1.学习使用UML建模工具； 2.掌握面向对象需求分析建模技术； 3.理解和掌握面向对象软件系统设计原理、设计过程和技术 |
| 这个作业在哪些方面帮助团队实现学习目标 | 1.学会熟练使用ProcessOn,Visio等常用UML图形绘制工具 2.绘制UML图等 3.了解软件设计模式 4.完成需求建模与系统设计说明书 |
| 团队博客链接 | https://www.cnblogs.com/sandaiyi/ |
| 团队项目Github仓库地址链接 | https://github.com/sandaiyi08/SearchSystem |
任务一：以团队协作学习方式掌握在线作图工具ProcessOn的软件操作方法。
ProcessOn软件简介
ProcessOn是一个在线作图工具的聚合平台，建立在并行计算和分布式存储架构之上，这使得它能够为全球的专家顾问、商业组织提供一个共享的流程知识仓库，将结构化的流程最佳实践分享给亿万互联网企业用户。它可以在线画流程图、思维导图、UI原型图、UML、网络拓扑图、组织结构图。无需下载安装，便于跨端使用；ProcessOn的文件可以进行协作，实现多人共同浏览和编辑；支持vsdx、xmind、txt、excel等格式文件的导入，支持导出高清png、jpg、pdf等格式文件，满足多场景的下载需求；用户可以将自己有价值的知识绘制成图后发布到ProcessOn平台，与相关人物交流。ProcessOn专注于为作图人员提供价值，利用互联网和社交技术颠覆了人们梳理流程的方法习惯，继而使商业用户获得比传统模式更高的效率和回报，改善人们对流程图的创作过程。
团队学习截图如下图1.1所示：
图1.1 团队学习
任务2：整理实验七作业成果，应用面向对象分析方法（OOA），参考国标GB8567—88中《软件需求规格说明书》格式，编制团队项目需求规格说明书，并将该文档上传到团队项目Github仓库
1.采用用例图（或者DFD图）建模表示项目功能需求，模型使用规范一致的图形符号和文字描述内容；
图2.1.1 会议截图
本系统拟实现个人用户登录注册本系统，进行老人的信息相关录入可以实现对于自己录入信息的增、删、改功能；警务则通过登录进入本系统，采集走失老人的面部信息进行识别，获取老人的相关信息通过联系家属或者带他们回家的方式解决问题，管理员则对警察的身份进行核查，进行警察以及用户的管理。
2.参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限；
图2.2.1 四象限图
3.编制项目的WBS
（1）团队项目的WBS
图2.3.1 WBS图
（2）使用WBS工具创建看板图
图2.3.2 看板图
（3）使用WBS工具创建燃尽图
图2.3.3 燃尽图
4.选择适当的UML模型，建立问题域对象模型；
图2.4.1 类图
图2.4.2 用户状态图
5.估计各项任务所需时间
| 任务 | 具体内容 | 所需时间（h） |
|---|---|---|
| 任务1 | 用例图设计 | 2 |
| 任务2 | 四象限图绘制 | 1 |
| 任务3 | UML模型设计 | 3 |
| 任务4 | 编制项目WBS | 3 |
| 任务5 | 估计各项任务所需 | 0.1 |
任务3：查阅资料，回答以下问题：
1.何谓软件设计模式？
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
- 设计模式分为三种类型：
- 创建型模式：单例模式、建造者模式、工厂模式、原型模式等。
- 结构型模式：适配器模式、装饰模式、组合模式、外观模式等。
- 行为型模式：命令模式、迭代器模式、观察者模式、备忘录模式、状态模式、访问者模式等。
- 设计模式的六大原则
- 开闭原则：对扩展开放，对修改关闭。即为了使程序的扩展性好，易于维护和升级。
- 里氏代换原则：任何基类可以出现的地方，子类一定可以出现。 对“开-闭”原则的补充，是对实现抽象化的具体步骤的规范。
- 依赖倒转原则：这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
- 接口隔离原则：使用多个隔离的接口，比使用单个接口要好。降低依赖，降低耦合。
- 迪米特法则（最少知道原则）：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
- 合成复用原则：原则是尽量使用合成/聚合的方式，而不是使用继承。
2.什么是C/S？
C/S结构：Client/Server，是一种软件系统体系结构，即客户机和服务器结构。通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。
C/S结构可以看做是胖客户端架构。客户端实现绝大多数的业务逻辑处理和界面展示，作为客户端的部分需要承受很大的压力，从分利用客户端的资源，对客户机的要求较高。
目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件。传统的C／S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于没能提供用户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且代价高， 效率低。
- C/S结构的优点:
- C/S结构的界面和操作简单丰富。
- C/S结构的管理信息系统具有较强的事务处理能力。
- C/S结构的安全性能可以很容易保证，实现多层认证也不难。
- C/S结构的响应速度快。由于客户端实现与服务器的直接相连，没有中间环节，只有一层交互，因此响应速度较快。
- C/S结构的缺点:
- 适用面窄，通常用于局域网中。
- 客户端需要安装专用的客户端软件。
- 维护升级成本高，进行一次维护升级，需要所有客户端的程序进行重新安装。
- 对客户端的操作系统一般也会有限制。
3.什么是B/S结构?
B/S结构:即浏览器和服务器结构,Browser/Server。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。
B/S结构可以看作是瘦客户端，只是把显示的较少的逻辑交给了Web浏览器，事务逻辑数据处理在放在了Server端，这样就避免了庞大的胖客户端，减少了客户端的压力。B/S结构的系统无须特别安装，只有Web浏览器即可。当然AJAX\Flex等等的普遍使用也有富客户端的发展方向。
以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。
- B/S结构的优点:
- 无需安装，客户端不需要安装有浏览器即可。
- 分布性特点，可以随时随地进行查询、浏览等业务处理。
- 业务扩展便捷，通过增加页面即可增加服务器功能。
- 升级维护便捷，无需升级多个客户端，升级服务器即可，就可以实现所有用户的同步更新。
- 共享性强特点，可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。
- B/S结构的缺点:
- 在跨浏览器上，BS结构不尽如人意。
- 在速度和安全性上需要花费很多设计成本，响应速度不及C/S，随着AJAX技术的发展，相比传统B/S结构软件速度有很大提升。
- 用户体验不是很理想，B/S需要单独界面设计，各个浏览器厂商的对浏览器的解析的标准不同。客户端服务器端的交互是请求-响应模式，通常需要刷新页面，这并不是客户乐意看到的。
4.什么是MVC设计模式？
MVC：Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，MVC是一个框架模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。
- Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
- View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
- Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
任务4：以任务1的成果为基础，应用面向对象设计（OOD）方法，撰写团队项目软件系统设计说明书，以回答：软件是如何实现用户需求的？
团队项目软件概要说明书上传至Github截图如下图4.1所示，软件的设计模式与软件系统总体结构、数据库的逻辑结构、软件的重用方案与关键类的设计均在其中有所说明，详细内容截图如下图4.2、4.3所示。
图4.1 Github项目文档
图4.2 项目文档1
图4.3 项目文档2
任务5：完成《实验八 团队作业4：团队项目需求建模与系统设计》团队博文作业：
1.记录完成《实验八 团队作业4：团队项目需求建模与系统设计》各项任务实际花费的时间和分工
| 任务 | 所需时间（h） |
|---|---|
| 任务1 | 2 |
| 任务2 | 10 |
| 任务3 | 2 |
| 任务4 | 10 |
| 任务5 | 2 |
2.从团队分工和协作学习角度，陈述团队实施ProcessOn建模工具学习、项目需求分析建模、软件系统设计等学习活动的心得
ProcessOn建模工具学习:
本次实验中针对ProcessOn建模工具的学习,本小组采用在企业微信上开线上会议的方式进行，由葛佳诚（PM）主持。由于在之前的学习中，对于建模以及流程图等方面的知识已经有了一定的了解，因此本次学习开展较为顺利且高效。大家各自针对自己的掌握程度发表意见，相互学习，共同解决问题，并制作了简单的样例图，完成了相关的设计工作。在此次团队学习中，我们团队对PressOn这一建模工具有了较为充分的理解，也将该工具与我们常用的设计工具Visio进行了对比，总的来说，这款设计工具胜在轻量，十分适合小型的软件开发设计，对我们学生也较为友好。
项目需求分析建模:
由于之前情况，每个人对于分析建模的擅长领域不同，因此对于任务进行合理地划分，由赵栋负责用例图、葛佳诚负责四象限图的绘制，张芹负责UML设计，李佩杉负责WBS设计，最后张芹、李佩杉共同撰写软件需求规格说明书。通过本次需求分析建模过程，我们针对负责部分的不理解之处共同商讨并及时解决问题，对用户需求有了进一步的认识，也对系统功能有了进一步的明确，虽然可能在过程中存在一些不足，但是我们团队相信通过这次讨论学习，我们在未来的学习中能够做得更好。
软件系统设计:
软件系统设计层面，由葛佳诚负责软件系统总体结构和系统数据库逻辑结构设计，张芹负责软件重用方案，李佩杉负责设计类的关键类的重点服务，最后由赵栋进行汇总。由于之前学习情况的不同，在此部分实现各成员进度不一致在该部分花费时间较多。不过还是相互合作，及时沟通，存在问题也能高效率解决，这使团队成员之间更加团结，且为之后的相关分工设计等工作积累了经验。