| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | 课程班级博客链接 |
| 这个作业要求链接 | 作业要求链接 |
| 团队名 | 佩琪小分队 |
| 团队成员分工描述 | * 云云：完成任务1、任务2 * 婷婷：完成任务1、任务2 * 作朝：完成任务3任务4和任务5 * 诚：完成任务3任务4和任务5 |
| 团队的课程学习目标 | （1） 共同学习使用UML建模工具Visio； （2） 学习掌握应用面向对象设计方法（OOD），完善团队项目的《软件需求规格说明书》 （3）理解和掌握面向对象软件系统设计原理、设计过程和技术，完成项目软件系统设计说明书 |
| 这个作业在哪些方面帮助团队实现学习目标 | （1）促进了团队之间的合作加深，成员之间得互相借鉴学习，互助提升； （2）学会熟练使用ProcessOn,Visio等常用图形绘制工具； （3）了解了软件设计模式； （4）完成了需求规格说明书与系统设计说明书。 |
| 团队博客链接 | 博客地址链接 |
| 团队项目Github仓库地址链接 | 仓库链接 |
任务1：按教师公布团队项目互评名单，对互评方《实验七 团队作业4：团队项目需求建模与系统设计》的项目成果进行评价；
| 评价小组 | |
|---|---|
| 结对方团队名称 | 卡其脱离太 |
| 对方团队博客链接 | 卡其脱离太 实验七 团队作业4：团队项目需求建模与系统设计 |
| 对方Github项目仓库链接 | Github项目仓库 |
| 评价内容链接 | 卡其脱离太 实验七 团队作业4：团队项目需求建模与系统设计 |
GitHub仓库截图
互评内容
结合实验七评分标准，给出互评团队作业评分成绩
- 博文结构：对整篇博文总体来说，结构清晰；排版整洁、简单；博文尽可能多的使用图表进行相关的说明，给人以直观的感觉，具有阅读体验。
- 博文内容：从博文的整体结构和内容来看，该小组非常认真，在相应任务的撰写过程中，尽可能使用简练的语言，进行博文的书写，总结精简、到位。
- 任务分工与时间分配：成员分工明确合理，明确的分工有利于项目进行；同时各项工作耗时合理。
- 评分：17+5+55+46+16=139.
- 成绩为139分。
任务2：使用Visio，应用面向对象分析方法（OOA），完善团队项目的《软件需求规格说明书》，并将该文档上传到团队项目Github仓库
2.1 采用用例图（或者DFD图）建模表示项目功能需求，模型使用规范一致的图形符号和文字描述内容
- 用例图（User Case）是被称为参与者的来外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，源以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
- 将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
- 用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
2.2 参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限
- 第一象限（杀手功能，必要需求）：实现精准、快速地对银行卡卡号的自动定位、分割和识别。
- 第二象限（外围功能，必要需求）：用户使用体验，界面的简介美观。
- 第三象限（外围功能，辅助需求）：设定图片存储与识别记录的存储及登录信息的存储。
- 第四象限（杀手功能，辅助需求）：用户查看公告以及管理员发布公告。
2.3 选取适当的UML模型，建立问题域对象模型
- 类图一般在详细设计过程中出现，主要用来描述系统中各个模块中类之间的关系，包括类或者类与接口的继承关系，类之间的依赖、聚合等关系。
- 它还描述每一个类的详细信息，包括变量，和方法。
- 通过类图，就能实际的把系统中的各个类，即对象描述清楚，下一步就是按照这个详细的设计编码了。
- 本系统主要设计了四个大的关键类:admin，user，news，records,即管理员类，用户类，公告类，记录类。基于这四个父类的基础上，继承更行，查询，修改等子类。设计的类图如图所示：
2.4 编制项目的WBS
WBS即工作分解结构，是以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。WBS是项目管理重要的专业术语之一，无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构（WBS）都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础；同时也是控制项目变更的重要基础。创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。
2.5 估计各项任务所需时间
本团队采用Wideband Delphi估计法进行估算：
Wideband Delphi估计法，这是一种结构化的方法，严格按照流程执行。Wideband Delphi估计法的目的不是比较估计的准确性，而是在较短的时间内让团队充分沟通，交换意见。这种估计法的主观性比较强，估计值缺少客观的统计，可能会有很大的偏差，因此，我觉得这种方法可以用于软件项目准备阶段的粗略估计，不适合做项目的精确估计。
- 人员：
- 估计专家，至少3人
- 项目经理，可兼任估计专家
- 评估协调人，可由项目经理兼任。如果项目经理同时兼任估计专家和协调人，须注意匿名估计的有效性
- 流程：
- 协调人发送估计所需的材料，估计表
- 协调人召集会议，讨论与待估量相关的估计假定和理由
- 专家匿名提交估计表
- 协调人整理，并将结果返回给专家，计算各待估量的最大值、最小值、平均值、偏差率。若偏差率未超过可接受范围，则不需要再估计，可将平均值作为最终结果。建议的偏差率可接受范围为30%。偏差率=MAX[（最大值-平均值），（平均值-最小值）] / 平均值
- 协调人召集会议，讨论偏差率超出可接受范围的待估量。不用对估计结果进行讨论，看是否可以将一些任务再进行分解或者合并
- 专家匿名提交新的估计表
- 重复4~6，直至估计分布范围已小到可接受的范围
(1) 建立估算小组：
| 角色 | 职责 |
|---|---|
| PM | 制定Delphi估算活动计划 建立估算小组 估算准备：包括需求文档，估算样例表等 主持会议 记录并通报会议结果 |
| 估算小组 | 熟悉所获得估算基础资料 用Wideband Delphi估算法实施估算,提供并修订估算意见 形成估算结果文档 |
(2) 估算表样例（估算小组匿名投票）：
| 项目名称 | 基于深度学习的银行卡识别系统 |
|---|---|
| 标识 | task1 |
| 负责人 | *诚 *作朝 |
| 估计日期 | 2020年6月2日 |
| 假定及理由 | 假设由两个人完成全部任务 |
| 待估量 | 登录模块开发进度 |
| 估计值 | 4天 |
| 估计值计算方法 | 取平均值（前提为偏差率小于30%） |
(3) 汇总估算表样例（主持人汇总每个模块估算结果）：
| 待估量/估算小组成员 | 成员1 | 成员2 | 成员3 | 成员4 |
|---|---|---|---|---|
| 登录模块进度（天） | 3 | 5 | 5 | 3 |
| 最大值 | 5 | |||
| 最小值 | 3 | |||
| 平均值 | 4 | |||
| 偏差率 | MAX[（最大值-平均值），（平均值-最小值）] / 平均值 = 25%（合格） |
(4) 汇总估算表样例：
| WBS Activity | 初值 | change1 | change2 | ··· | 终值 |
|---|---|---|---|---|---|
| task1(登录模块) | 4 | 4 | 4 | ··· | 4 |
| task2(注册模块) | 2 | 3 | 2 | ··· | 2 |
| task3 (登陆记录模块) | 4 | 4 | 4 | ··· | 4 |
| task4（银行卡分割模块) | 14 | 15 | 14 | ··· | 14 |
| task5（银行卡识别模块) | 10 | 12 | 10 | ··· | 11 |
| task6（公告模块) | 7 | 9 | 6 | ··· | 7 |
| task7（识别记录模块) | 7 | 8 | 7 | ··· | 8 |
| task8（管理员模块) | 8 | 7 | 7 | ··· | 7 |
| task9（个人信息模块) | 6 | 8 | 7 | ··· | 7 |
| 和值 | 62 | 62 | 61 | ··· | 64 |
如上表估算结果所示，项目完成进度估算值为64天。
2.6 将《项目需求规格说明书》上传到团队项目Github仓库
三.查阅资料，回答以下问题：
3.1 软件设计模式
- 概念：
软件设计模式，又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
- 基本要素:
软件设计模式使人们可以更加简单方便地复用成功的设计和体系结构，它通常包含以下几个基本要素：模式名称、别名、动机、问题、解决方案、效果、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式等，其中最关键的元素包括以下 4 个主要部分。
3.2 什么是C/S
- 概述：
C/S（Client/Server）结构，即客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构。
- 结构模型：
3.3 什么是B/S结构
- 概述：
B/S（Brower/Server,浏览器/服务器）模式又称B/S结构，是Web兴起后的一种网络结构模式。Web浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用；客户机上只需要安装一个浏览器，服务器上安装SQL Server, Oracle, MySql等数据库；浏览器通过Web Server同数据库进行数据交互。
- 结构模型：
3.4 MVC设计模式
- 概念：
MVC模式（Model-View-Controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。
- 运行机制：
- 三个部件：
- 控制器Controller：接受用户的输入并调用模型和视图去完成用户的需求。对请求进行处理，负责请求转发。
- 视图View：界面设计人员进行图形界面设计，多个视图能共享一个模型。
- 模型Model：程序编写程序应用的功能（实现算法等等）、数据库管理，在MVC的三个部件中，模型拥有最多的处理任务。模型与数据格式无关，这样一个模型能为多个视图提供数据。
四.以任务1的成果为基础，撰写团队项目软件系统设计说明书，回答：软件是如何实现用户需求的？
4.1. 采用适合的软件设计模式设计软件系统总体结构
整个系统架构运行流程如下图所示：
整个系统模块功能如图所示：
数据流程图（Data Flow Diagram，DFD/Data Flow Chart），是一种能全面地描述系统数据流程的主要工具，它用一组符号来描述整个系统中信息的全貌，综合地反映出信息在系统中的流动、处理和存储情况。它有两个特征：抽象性和概括性。综合这两个特征对该系统的数据流向进行分析，系统的整体数据流程如图所示：
4.2. 设计软件系统数据库逻辑结构
数据库的逻辑结构设计就是把概念结构设计阶段设计好的基本实体-关系图转换为与选用的数据库管理系统产品所支持的数据模型相符合的逻辑结构。所以需要先设计实体-关系图
- 本系统数据库名称为db_secondhandmarket，数据库中包括：
（1）用户表
（2）识别记录表
（3）系统管理人员表
（4）公告表
4.3. 软件重用方案
我们的重用设计是建立在springMVC框架之上。我们分析可能重用部分的实例有两种方式，一种是继承类库中的构件要用到的基本功能的类。主要是一些界面元素，如菜单活框、列表框，这些构件在很多模块中都要用到，且处理逻辑大致相同，并进行扩充其处理逻辑，如增加输入合法性检测等，这样我们在使用这些经过扩充的构件时不必每个都去重复那些处理逻辑，大大提高了效率，而且，这些构件都是经过测试或其他人使用过的，质量也有保证。
另一种方式是我们的构件在类库找不到相似的类，我们将从头创建自己的类，但为了将自己创建的类，如用户权限处理等，也纳入springMVC的框架，我们自己创建的类都继承框架的一个抽象类，这样做的好处是把自己创建的类纳入Controller类的层次化管理，且这也是为实现虚拟函数和动态联编方便。我们也为每个件的功能和接口建立了文档，供应用开发中使用。这样我们就在springMVC的框架下，建立了我们自己的一个重用构件库。最后是在应用中重用构件库中的构件。当用户需求变化时，我们能用构件库快速重构我们的应用。
我们的重用主要是在源代码级，通过类的继承来实现。其实可重用的范围是很大的，如设计的重用，测试用列的重用，可运行的代码的重用等。将来会扩大重用的粒度，在框架基础上，进一步根据我们项目本身的软硬件环境定制出一个适用于我们系统的框架，如加进注册功能，数据库连接的功能等。这样，我们可直接重用这个框架，这可以极大地提高软件的开发和维护的效率。
使用重用不仅提高了开发效率，还保证了应用的风格和质量。特别是对我们这种新手较多的团队开发，采用重用的方法，让有经验的成员负责整个应用的框架，让新手使用重用来创建应用，这非常有利于提高效率，在保证质量的同时也为新手提供一个循序渐进的学习机会，有利于新手的成长。
4.4. 设计关键类的重点服务
- 本系统主要设计了四个大的关键类:admin，user，news，records,即管理员类，用户类，公告类，记录类。基于这四个父类的基础上，继承更行，查询，修改等子类。设计的类图如图所示：
4.5.将《项目软件设计说明书》上传到团队项目Github仓库
五.完成《实验八 团队作业4：团队项目需求建模与系统设计》团队博文作业
5.1.各项任务实际花费的时间和分工
- 任务花费时间如下：
| 任务 | 预计花费时间(h) | 实际花费时间(h) |
|---|---|---|
| 任务一 | 1 | 2 |
| 任务二 | 14 | 17 |
| 任务三 | 0.5 | 0.5 |
| 任务四 | 15 | 16 |
| 任务五 | 1.5 | 2 |
5.2.从团队分工和协作学习角度，陈述团队实施ProcessOn建模工具学习、项目需求分析建模、软件系统设计等学习活动的心得
*诚：本次团队项目学习，总体感觉很不错，相对应的工具功能还是比较齐全的。但是之前没有绘制过类图等一些图，所以也学习了相关的绘制标准和知识。在这里花费了一些时间。最后和队友一起完成所有的用例图等图表的绘制。对于项目需求分析建模这项任务我们是在之前的原型设计基础上进一步将需求建模规范化，专业化。根据国标GB8567—88中《软件需求规格说明书》格式制定出了我们项目自己的需求分析文档，并建立相关模型。也学到了很多撰写文档的技巧和知识。对于软件系统设计任务的学习，我们团队成员一起设计出整体的软件总体框架，再将其细粒分模块设计。最终设计出我们的整体系统框架。但这里主要难点在于类图的制作，因为之前没有相关的实操，所以在绘制类图的部分下了很大功夫才按照标准绘制出来。
*作朝：在本次作业中，我们熟悉了UML模型的绘制。我主要负责的是需求分析建模部分，一开始做的并不顺利，虽然理论课已经学习过，但是实践起来才发现各种问题，于是不得不重新学习，仔细研读，才顺利做出了各个模块和系统总体的用例图。而对象模型图我们原先组内商量做类图，可是类图过于复杂，各种类的关联关系交错。最后在组长的帮助下完成了这部分。本次作业团队成员积极协作，分工明确。大家在有困难时互相帮助，有疑惑时共同商讨，不足之处在慢慢改进。后面团队会更加团结的。
*云云：在本次团队作业中我再次熟悉了UML建模工具Visio，并与小组成员讨论系统的用例图和类图，但是还是有些不理解，所以，在完成的时候花费了较长的时间。通过阅读书籍和网络查阅资料，我基本理解和掌握一定的面向对象需求分析建模技术。
通过阅读了《构建之法—现代软件工程》8.5节功能的定位和优先级，我知道了功能分析的四个象限，并且通过讨论完成了系统的功能分析四象限。此外，通过查阅资料了解了C/S结构和B/S结构以及MVC设计模式。
在完成任务四的过程中，这部分是对上次实验中软件设计的一个迭代和完善，在经过需求分析建模后，但是使用Visio和OOD来对软件设计进行迭代和完善。所以，先学习什么是OOD，然后根据所学的知识对软件设计进行迭代和完善。
在本次团队作业中，需要学习的知识很多，但是我们通过小组学习、讨论和分工合作，最终在规定时间里按要求完成了本团队作业的所有任务！
*婷婷:在本次实验中我学会了使用UML建模工具Visio，并绘制了系统的用例图和类图，由于初次学习到这部分知识，对其不够理解，在完成的时候要先熟练掌握这部分知识，才能进行后面的工作，耗费的时间比较长，但在此过程中我学习到了很多，而且对OOA 有一定的掌握。我还阅读了《构建之法》功能的定位和先级，思考讨论系统四个象限的内容，并很好地完了这个任务。通过查阅资料了解了C/S结构和B/S结构以及MVC设计模式。在完成任务四的过程中，首先学习了什么是OOD，然后根据所学的知识进行软件系统总体结构和数据库逻辑结构的设计，最后完善了《软件设计说明书》并按要求上传。这次的实验难度比较大，需要学习的新知识特别多，但是我们通过小组学习和讨论，最终按要求完成了本实验的所有任务！
