大王不高兴 实验八 团队作业4：团队项目需求建模与系统设计

项目	内容
课程班级博客链接	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
作业要求链接	https://www.cnblogs.com/nwnu-daizh/p/12976163.html
团队名称	大王不高兴
团队成员分工描述	王之泰：PM，开发 韩腊梅：界面设计 陈亚茹：测试 李瑞红：文档
团队的课程学习目标	学习使用UML建模工具；掌握面向对象需求分析建模技术；理解和掌握面向对象软件系统设计原理、设计过程和技术。
本作业在哪些方面帮助团队实现学习目标	促进了团队之间的合作加深，成员之间得互相借鉴学习，互助提升
团队博客链接	https://www.cnblogs.com/xiaochenCYR/p/13019144.html
团队Github仓库地址链接	https://github.com/YHwzt/Team_project4

一.以团队协作学习方式掌握在线作图工具ProcessOn的软件操作方法。

1.1 ProcessOn软件简介

　　支持绘制思维导图、流程图、UML、网络拓扑图、组织结构图、原型图、时间轴等等。

　　ProcessOn将全球的专家顾问、咨询机构、BPM厂商、IT解决方案厂商和广泛的企业用户紧密的连接在一起，提供基于云服务的免费流程梳理、创作协作工具，与同事和客户协同设计，实时创建和编辑文件，并可以实现更改的及时合并与同步，这意味着跨部门的流程梳理、优化和确认可以即刻完成。专注于为作图人员提供价值，利用互联网和社交技术颠覆了人们梳理流程的方法习惯，继而使商业用户获得比传统模式更高的效率和回报，改善人们对流程图的创作过程。

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

1.2 ProcessOn 团队协作使用效果阐述

　　之前本团队成员大多数在绘制流程图和思维导图的时候使用的都是Visio这款软件，该工具功能本身非常强大，但是我们觉得这个工具更适合机械电器等画图，上面有很多极其形象的元器件。所以在本次任务我们使用了网页版绘制工具Process on。经过团队学习了几十分钟之后很容易就上手使用了。使用效果还是很不错的。

　　绘制界面还是很通用的，新建流程图，出现下面的界面。之后的步骤只要是绘制过类似图形的都知道该怎么操作了。

　　并且还有快捷键查询，也是非常便捷的。

　　但该款软件也就只在操作便捷以及免费使用上面占了些优势。相比绘制出来的图。还是Visio等老牌产品质量要好一些。

　　同一个图形，绘制出来的效果对比

　　visio绘图效果：

　　processon绘图效果：

　　总体来看：用visio绘图，字体大小，图形尺寸以及图片的清晰程度都要比processon方便调节一点，使用process　on这款轻量级软件，有着简洁直观、轻量级、无广告插入的特点，是非常适合非专业用户的，但是经常绘制图的还是不要怕麻烦安装一个Visio效果来的好一点。

二.整理作业成果，编制团队项目需求规格说明书

2.1 采用用例图（或者DFD图）建模表示项目功能需求，模型使用规范一致的图形符号和文字描述内容

• 用例图（User Case）是被称为参与者的来外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，源以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

• 将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。

• 用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。

• 游客用例图

• 注册用户用例图

• 系统管理员用例图

• 系统总体用例图

2.2 参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限

• 第一象限（杀手功能，必要需求）：可以购买商品。

• 第二象限（外围功能，必要需求）：可以浏览商品，查看钱包信息。

• 第三象限（外围功能，辅助需求）：管理员查看用户信息。

• 第四象限（杀手功能，辅助需求）：管理员可以做简单系统设置

2.3 选取适当的UML模型，建立问题域对象模型

• 类图一般在详细设计过程中出现，主要用来描述系统中各个模块中类之间的关系，包括类或者类与接口的继承关系，类之间的依赖、聚合等关系。

• 它还描述每一个类的详细信息，包括变量，和方法。

• 通过类图，就能实际的把系统中的各个类，即对象描述清楚，下一步就是按照这个详细的设计编码了。

• 本系统主要设计了三个大的关键类:admin,user,goods,即管理员类，用户类，商品类。基于这三个父类的基础上，继承更行，查询，修改等子类。设计的类图如图所示：

• 清晰度不够可点击此链接查看类图。

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. 采用适合的软件设计模式设计软件系统总体结构

　　本校园二手物品交易系统采用SSM（Spring MVC+Spring+Mybatis）框架开发，是标准的MVC模式，将整个系统划分为View层，Controller层，Service层，DAO层四层。其中，Spring MVC负责请求的转发和视图管理，Spring实现业务对象管理，Mybatis作为数据对象的持久化引擎。整个系统架构运行流程如下图所示：

　　系统按照功能主要分为游客、注册用户、管理员三个模块，游客具有用户注册、商品浏商品查找的功能。注册用户除了基本的商品浏览和商品查找功能外，还有用户登录、查看商品详情、商品发布、商品求购、添加收藏和个人信息设置功能。管理员具有对用户信息、商品信息的管理功能和系统基本设置功能。整个系统模块功能如图所示：

　　数据流程图（Data Flow Diagram，DFD/Data Flow Chart），是一种能全面地描述系统数据流程的主要工具，它用一组符号来描述整个系统中信息的全貌，综合地反映出信息在系统中的流动、处理和存储情况。它有两个特征：抽象性和概括性。综合这两个特征对该系统的数据流向进行分析，系统的整体数据流程如图所示：

　　系统工作流程主要从游客、已登录用户以及管理员三个不同的角色在系统中的操作流程为主，具体如图所示：

4.2. 设计软件系统数据库逻辑结构

　　数据库的逻辑结构设计就是把概念结构设计阶段设计好的基本实体-关系图转换为与选用的数据库管理系统产品所支持的数据模型相符合的逻辑结构。所以需要先设计实体-关系图，校园二手商品交易系统的全局E-R模型如图所示。

• 本系统数据库名称为db_secondhandmarket，数据库中包括：

（1）用户表（user）

（2）管理员表（admin）

（3）商品表（goods）

（4）关注表（focus）

（5）分类表（catelog）

（6）信息表（notice）

（7）订单（orders）

• 下图以商品表数据结构为例，其余表的数据结构见文档《项目软件系统设计说明书》。

字段名称	数据类型	主键	是否空	说明
name	varchar(50)	N	Y	商品名称
price	float(11,2)	N	Y	出售价格
real_price	float(11,2)	N	Y	真实价格
start_time	varchar(25)	N	Y	发布时间
polish_time	varchar(30)	N	Y	擦亮时间，按该时间进行查询，精确到时分秒
end_time	varchar(25)	N	Y	下架时间
describle	text	N	Y	详细信息
status	int(11)	N	N	状态(上架1;下架0)

4.3. 软件重用方案

　　我们的重用设计是建立在springMVC框架之上。我们分析可能重用部分的实例有两种方式，一种是继承类库中的构件要用到的基本功能的类。主要是一些界面元素，如菜单活框、列表框，这些构件在很多模块中都要用到，且处理逻辑大致相同，并进行扩充其处理逻辑，如增加输入合法性检测等，这样我们在使用这些经过扩充的构件时不必每个都去重复那些处理逻辑，大大提高了效率，而且，这些构件都是经过测试或其他人使用过的，质量也有保证。

　　另一种方式是我们的构件在类库找不到相似的类，我们将从头创建自己的类，但为了将自己创建的类，如用户权限处理等，也纳入springMVC的框架，我们自己创建的类都继承框架的一个抽象类，这样做的好处是把自己创建的类纳入Controller类的层次化管理，且这也是为实现虚拟函数和动态联编方便。我们也为每个件的功能和接口建立了文档，供应用开发中使用。这样我们就在springMVC的框架下，建立了我们自己的一个重用构件库。最后是在应用中重用构件库中的构件。当用户需求变化时，我们能用构件库快速重构我们的应用。
　　
　　我们的重用主要是在源代码级，通过类的继承来实现。其实可重用的范围是很大的，如设计的重用，测试用列的重用，可运行的代码的重用等。将来会扩大重用的粒度，在框架基础上，进一步根据我们项目本身的软硬件环境定制出一个适用于我们系统的框架，如加进注册功能，数据库连接的功能等。这样，我们可直接重用这个框架，这可以极大地提高软件的开发和维护的效率。

　　使用重用不仅提高了开发效率，还保证了应用的风格和质量。特别是对我们这种新手较多的团队开发，采用重用的方法，让有经验的成员负责整个应用的框架，让新手使用重用来创建应用，这非常有利于提高效率，在保证质量的同时也为新手提供一个循序渐进的学习机会，有利于新手的成长。

4.4. 设计关键类的重点服务

• 本系统主要设计了三个大的关键类:admin,user,goods,即管理员类，用户类，商品类。基于这三个父类的基础上，继承更行，查询，修改等子类。设计的类图如图所示：

4.5.将《项目软件设计说明书》上传到团队项目Github仓库

五.完成《实验八 团队作业4：团队项目需求建模与系统设计》团队博文作业

5.1.各项任务实际花费的时间和分工

• 任务花费时间如下：

任务	预计花费时间(h)	实际花费时间(h)
任务一	1	2
任务二	14	17
任务三	0.5	0.5
任务四	15	16
任务五	1.5	2

• 成员任务分工如下：

成员	任务分工
王之泰	PM,任务四文档编撰、修改；任务一学习；博文修改，材料上传
韩腊梅	任务四文档编撰、修改；任务一学习
陈亚茹	任务二文档编撰,修改；任务三资料查询；任务一学习
李瑞红	任务二文档编撰,修改；任务一学习；博文撰写

5.2.从团队分工和协作学习角度，陈述团队实施ProcessOn建模工具学习、项目需求分析建模、软件系统设计等学习活动的心得

王之泰：本次团队项目学习，我们首先进行的是对ProcessOn建模工具的学习，该项建模任务基本可以说是全员参与了，因为两个文档每个人都有撰写，而且都有对应的图表，因为之前我一直使用的是Visio来绘制流程图之类。所以对该工具只是简单的熟悉了以下就上手了。总体感觉很不错，相对应的工具功能还是比较齐全的。但是之前没有绘制过类图等一些图，所以也学习了相关的绘制标准和知识。在这里花费了一些时间。最后和队友一起完成所有的用例图等图表的绘制。对于项目需求分析建模这项任务我们是在之前的原型设计基础上进一步将需求建模规范化，专业化。根据国标GB8567—88中《软件需求规格说明书》格式制定出了我们项目自己的需求分析文档，并建立相关模型。也学到了很多撰写文档的技巧和知识。对于软件系统设计任务的学习，我们团队成员一起设计出整体的软件总体框架，再将其细粒分模块设计。最终设计出我们的整体系统框架。但这里主要难点在于类图的制作，因为之前没有相关的实操，所以在绘制类图的部分下了很大功夫才按照标准绘制出来。

李瑞红：在本次作业中，我们共同学习了ProcessOn建模工具，熟悉了UML模型的绘制。我主要负责的是需求分析建模部分，一开始做的并不顺利，虽然理论课已经学习过，但是实践起来才发现各种问题，于是不得不重新学习，仔细研读，才顺利做出了各个模块和系统总体的用例图。而对象模型图我们原先组内商量做类图，可是类图过于复杂，各种类的关联关系交错。最后在组长的帮助下完成了这部分。本次作业团队成员积极协作，分工明确。大家在有困难时互相帮助，有疑惑时共同商讨，不足之处在慢慢改进。后面团队会更加团结的。

韩腊梅：团队成员仔细阅读任务要求后，组长给每个成员分配了任务，这样加快的任务的完成速度，成员专心完成自己的任务；在个人任务完成之后，通过成员之间讨论，对自己负责的任务进行多次迭代修改，在原来的基础上进行完善。本次任务中用到了在线作图工具ProcessOn，通过团队成员对该工具的协作学习以及使用，发现ProcessOn工具是一个特别方便的工具，里面有多种类型图的图元，并且功能齐全、操作简单。

陈亚茹:作业前期任务主要是利用processon工具绘图。大家共同学习了processon工具，完成了用例图、类图、WBS、数据流图等。完成了一系列分析建模。其实主要的问题不在于绘图工具的使用，而在于我们对于需要建立的模型的认识不明朗，例如绘制类图的时候无从下手。完成了这些，大家又协作完成了项目需求报告和系统设计报告。我其实不是一个可以独立做事情的人，所以很喜欢这种大家可以一起商量共同完成事情的氛围，非常感谢队友的帮助以及通力合作。