实验八 upower队 团队作业5：团队项目需求建模与系统设计（2）
| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | 班级博客 |
| 这个作业要求链接 | 作业要求 |
| 团队名称 | upower队 |
| 团队成员分工描述 | 吴：PM，分配任务、学习使用Visio、写规格说明书 梁：学习使用Visio、画用例图、对互评小组进行的项目成果进行评论 石**：完善WBS结构，估计各项任务所需要的时间 马*：画功能分析的象限，写文档 |
| 团队的课程学习目标 | （1）学习使用UML建模工具Visio； （2）掌握面向对象需求分析建模技术； （3）理解和掌握面向对象软件系统设计原理、设计过程和技术。 |
| 这个作业在哪些方面帮助团队实现学习目标 | (1)自主学习建模工具Visio,为作图作准备 （2）阅读《构建之法—现代软件工程》有利于我们对功能的定位，给出功能分析的四个象限 (3)团队成员分工协作，不仅能够按时完成任务，还能促进同学之间的友谊 |
| 团队博客链接 | 团队博客 |
| 团队项目Github仓库地址链接 | GitHub仓库 |
一、实验目的与要求
（1）学习使用UML建模工具Visio；
（2）掌握面向对象需求分析建模技术；
（3）理解和掌握面向对象软件系统设计原理、设计过程和技术。
二、实验内容与步骤
任务1：按团队项目互评名单，对互评方《实验七 项目需求分析建模与系统设计（1）》的项目成果进行评价，具体要求如下：
（1）阅读互评团队项目博文作业并进行评论，评论要点包括：博文结构、博文内容、任务分工与时间耗费。将以上评论内容发布到互评团队博客评论区。
（2）下载并阅读互评方团队项目资料。
| 项目 | 内容 |
|---|---|
| 结对方团队博客链接 | 结对方团队博客链接 |
| 结对方Github项目仓库链接 | 结对方Github项目仓库链接 |
| 符合（1）要求的博客评论 | 博客评论链接  |
| 结合实验七评分标准，给出互评团队作业评分成绩 | 110 |
任务2：使用Visio，应用面向对象分析方法（OOA），完善团队项目的《软件需求规格说明书》，并将该文档上传到团队项目Github仓库，文档内容要求如下：
（1）采用用例图表示项目功能需求，模型使用规范一致的图形符号和文字描述内容；
用例图（User Case）是被称为参与者的来外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，源以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
学生用例图：
教师用例图：
管理员用例图：
系统总体用例图：
（2）参考《构建之法—现代软件工程》8.5节功能的定位和优先级，给出功能分析的四个象限；
功能分析的四个象限：
（3）选择适当的UML模型，建立问题域对象模型；
（4）完善项目的WBS，估计各项任务所需时间
项目的WBS：
各项任务所需时间：
团队采用Wideband Delphi估计法进行估算：
Wideband Delphi估计法，这是一种结构化的方法，严格按照流程执行。Wideband Delphi估计法的目的不是比较估计的准确性，而是在较短的时间内让团队充分沟通，交换意见。这种估计法的主观性比较强，估计值缺少客观的统计，可能会有很大的偏差，因此，我觉得这种方法可以用于软件项目准备阶段的粗略估计，不适合做项目的精确估计。
（1）人员：
a估计专家，至少3人。
b项目经理，可兼任估计专家。
c评估协调人，可由项目经理兼任。如果项目经理同时兼任估计专家和协调人，须注意匿名估计的有效性。
（2）流程：
a协调人发送估计所需的材料，估计表。
b协调人召集会议，讨论与待估量相关的估计假定和理由。
c专家匿名提交估计表。
d协调人整理，并将结果返回给专家，计算各待估量的最大值、最小值、平均值、偏差率。若偏差率未超过可接受范围，则不需要再估计，可将平均值作为最终结果。建议的偏差率可接受范围为30%。偏差率=MAX[（最大值-平均值），（平均值-最小值）] / 平均值。
e协调人召集会议，讨论偏差率超出可接受范围的待估量。不用对估计结果进行讨论，看是否可以将一些任务再进行分解或者合并。
f专家匿名提交新的估计表.
g重复4~6，直至估计分布范围已小到可接受的范围.
小组建立表：
| 角色 | 职责 |
| ---- | ---- | ---- |
| PM | 制定Delphi估算活动计划
建立估算小组
估算准备：包括需求文档，估算样例表等
主持会议
记录并通报会议结果|
| 估算小组 | 熟悉所获得估算基础资料
用Wideband Delphi估算法实施估算,提供并修订估算意见
形成估算结果文档|
估算表样例（个人估算）：
| 项目名称 | 计算机科学与工程学院题库管理系统项目进度估计 |
|---|---|
| 标识 | task1 |
| 负责人 | 吴丽丽 |
| 估计日期 | 2021年6月2日 |
| 假定及理由 | 假设由一个人完成全部任务 |
| 待估量 | 登录模块开发进度 |
| 估计值 | 4天 |
| 估计值计算方法 | 取平均值（前提为偏差率小于30%） |
估算表样例（估算小组匿名投票）：
| 待估量/估算小组成员 | 成员1 | 成员2 | 成员3 | 成员4 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 登录模块进度（天） | 3 | 5 | 5 | 3 |
| 最大值 | 5 |
| 最小值 | 3 |
| 平均值 | 4 |
| 偏差率 | MAX[（最大值-平均值），（平均值-最小值）] / 平均值 = 25%（合格） |
汇总估算表样例：
| WBS Activity | 初值 | change1 | change2 | ··· | 终值 |
|---|---|---|---|---|---|
| task1(登录模块) | 4 | 4 | 4 | ··· | 4 |
| task2(注册模块) | 2 | 3 | 2 | ··· | 2 |
| task3 (学生模块) | 12 | 12 | 12 | ··· | 12 |
| task4（教师模块) | 20 | 20 | 20 | ··· | 20 |
| task5（管理模块) | 18 | 19 | 17 | ··· | 18 |
| 和值 | 56 | 58 | 55 | ··· | 56 |
如上表估算结果所示，本团队项目完成进度估计所需时间为56天。
《软件需求规格说明书1.2》已上传至GitHub仓库详情可从此查看。
任务3：查阅资料，回答以下问题：
（1）什么是C/S结构？
C/S 结构，即客户机和服务器结构。
它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
结构模型如下：
（2）什么是B/S结构?
B/S结构（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。
这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要安装一个浏览器（Browser英 ['braʊzə]美 ['braʊzɚ]），如Netscape Navigator或Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。
结构模型如下：
C/S和B/S并没有本质的区别：B/S是基于特定通信协议(HTTP)的C/S架构，也就是说B/S包含在C/S中，是特殊的C/S架构。
之所以在C/S架构上提出B/S架构，是为了满足瘦客户端、一体化客户端的需要，最终目的节约客户端更新、维护等的成本，及广域资源的共享。
（1）B/S属于C/S，浏览器只是特殊的客户端；
（2）C/S可以使用任何通信协议，而B/S这个特殊的C/S架构规定必须实现HTTP协议；
（3）浏览器是一个通用客户端，本质上开发浏览器，还是实现一个C/S系统。
（3）什么是MVC设计模式？
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
如上图所示：
Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。
通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。
通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。
通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
MVC模式将它们分离以提高系统的灵活性和复用性，不使用MVC模式，用户界面设计往往将这些对象混在一起。MVC模式实现了模型和视图的分离，这带来了几个好处。
（1）一个模型提供不同的多个视图表现形式，也能够为一个模型创建新的视图而无须重写模型。一旦模型的数据发生变化，模型将通知有关的视图，每个视图相应地刷新自己。
（2）模型可复用。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。
（3）提高开发效率。在开发界面显示部分时，你仅仅需要考虑的是如何布局一个好的用户界面；开发模型时，你仅仅要考虑的是业务逻辑和数据维护，这样能使开发者专注于某一方面的开发，提高开发效率。
mvc模式把原本杂乱无章的类，分为三堆，严格监管，按规则行事。说到底一切都是为了使类之间的耦合性更松散。好的代码应该对扩展开放，对修改关闭。
任务4：以任务2的成果为基础，使用Visio，应用面向对象设计（OOD）方法，撰写团队项目软件系统设计说明书，以回答：软件是如何实现用户需求的？文档内容要求如下：
（1） 采用适合的软件设计模式设计软件系统总体结构；
系统总体结构：
（2） 设计软件系统数据库逻辑结构；
数据库逻辑结构说明部分截图：
（3） 说明软件重用方案；
说明软件重用方案说明的部分截图：
（4） 设计关键类的重点服务。
设计的类图：
《项目软件系统设计说明书1.2》已上传至GitHub仓库详情可从此查看。
任务5：完成《实验八 团队作业5：团队项目需求建模与系统设计（2）》团队博文作业：
- 情况说明：已完成
记录完成《实验八 团队作业5：团队项目需求建模与系统设计（2）》各项任务实际花费的时间和分工（4分）；
- 情况说明：本次作业的各项任务分工已在博文开头给出，以下是各项任务实际花费的时间：
| 任务 | 实际花费时间（min） |
|---|---|
| 任务1 | 30 |
| 任务2 | 200 |
| 任务3 | 40 |
| 任务4 | 170 |
| 任务5 | 30 |
结合实验七、实验八的学习体验，对比陈述结构化软件分析与设计、面向对象分析与设计两类软件开发技术的异同。（10分）
结构化方法包括结构化分析(Structured Analysis，简称SA)、结构化设计(Structured Design，简称SD)和结构化程序设计(Structured Program Design，简称SP)三部分内容。相应地，面向对象方法包括面向对象分析(Object-Oriented Analysis，简称OOA)、面向对象设计(Object—Oriented Design，简称OOD)和面向对象程序语言(Object-Oriented Program Design，简称OOP)。两种软件开发方法从起源、思想、分析、设计，到程序设计、扩展重用、应用等各个方面有着许多的联系和区别，接下来我将从以下几方面来论述：
（1）从起源上看
结构化方法与面向对象方法都起源于相应的程序设计思想和语言。它们的起源和发展具有模式一致性：
（2）从思想上看
结构化方法承袭了结构化程序设计的思想，把待解决的问题看作一个系统，用系统科学的思想方法来分析和解决问题。结构化方法遵循抽象原则、分解原则和模块化原则；以数据和功能为中心；以模块为基本单位；以算法为程序核心；强调逐步求精和信息隐藏。
面向对象方法的思想是模拟了客观世界的事物以及事物之间的联系。面向对象以类取代模块为基本单位；通过封装、继承和多态的机制，表征对象的数据和功能、联系和通信；通过对对象的管理和对象间的通讯完成信息处理与信息管理的计算和存储，实现软件功能。
对于结构化方法，模块由函数实现，完成对输入数据的加工和计算，数据和功能是分离的；而面向对象把数据和功能封装在对象中，形成一个整体。两种方法在数据和功能上的不同处理是其思想上的本质差别。
（3）从分析上看
建立模型是为了更好地理解要模拟的现实世界，是软件开发方法的核心问题。在结构化方法中，使用SA构建系统的环境模型和逻辑模型，实现模型的主要工具有数据字典(DD)、ER图和数据流图(DFD)。数据字典是一个包含所有系统数据元素定义的仓库；ER图描述了数据之间的属性及联系；数据流图是描述信息流和数据从输入到输出变换，并展示系统和外部的接口、数据的输入和输出以及数据的存储的应用图形技术。SA的前提条件是需求分析，建模过程是迭代分解需求、不断细化应用的过程，即数据流图的分解从顶层图开始，按照每个加工对应一个子图的分解原则，逐层分解为0层图、1层图等。
面向对象方法使用OOA定义类，对现实世界建模。OOA的主要任务是要在问题域上构建具有主题层、对象层、结构层、属性层和服务层的OOA模型，实现模型的主要工具有用例图(Use-Case)和类图(Class Diagram)。用例图从用户角度描述系统功能，并指出各功能的操作者，是对需求分析的整理；类图定义了类的组成（属性和服务）、类的结构和类间的关系，确定并划分系统中的类。经过OOA，系统的静态模型建立起来。
相对于结构化方法使用DD、ER图和DFD分别描述数据和功能（尽管二者存在相互参考），面向对象方法中，无论是用例图还是类图，数据和功能的描述总是并行的。
（4）从设计上看
在结构化方法中，使用SD构建系统的行为和功能模型，实现模型的主要工具有模块结构图(SC)和程序流程图。模块结构图说明了系统的模块的划分、模块的功能、模块间的数据传递及调用关系。根据数据流图，我们能够映射出相应的软件的上层模块结构；结合数据流图，我们可以逐步分解上层模块，设计出中、下层模块；对于得到的全部模块，我们需要设计模块基本的内部结构和外部接口及对模块结构进行优化。进一步，则是针对每一个模块设计程序流程图，整理优化，归纳算法。SD依然是对项目系统的进一步分解求精的过程，把模型从逻辑级，细化到模块级，再细化到程序级。
而OOD不只是对OOA的细化，更主要的，构建了系统的动态模型，实现模型的主要工具有交互图(Sequence Diagram)、状态图(State Diagram)、活动图(Activity Diagram)。和模块相比，对象最大的不同是具有“活性”，突出表现在对象具有状态和对象间能够通讯。交互图描述对象间的交互关系，显示对象之间的动态合作关系，强调对象之间消息发送的时间顺序；状态图描述对象的所有可能状态，以及事件发生时状态的转移条件；活动图描述为满足用例要求所进行的活动以及活动间的约束关系，用于识别并行活动，以提高系统效率[2]。
（5）从程序上看
结构化程序设计是一种过程式的“解题”的方式，程序关注且只关注对于输入数据，输出正确的结果，代码是算法的直接体现，代码效率高；面型对象程序设计是整体式的“建模”的方式，程序关注现实客体，而非某些数据，代码是功能的直接体现，复杂的算法往往是一两行库函数处理，代码效率低。
（6）从扩展重用上看
结构化方法是面向整体应用进行的分析、设计，程序设计也是过程式的针对固定的输入域，代码定向性明显。所以，结构化方法的可扩展性较差，功能的变化可能危及整个系统；重用性不好，若系统间存在嵌套关系，主系统可重用子系统；较难以组合拼接，系统的设计实现是紧耦合的，连接往往是有缝的。
相反，面向对象方法虽然基于应用，但面向现实客体，对象之间独立性较强，功能是对象的交互。所以，面向对象的可扩展性较强，只需扩展或修改某个类，或调整某种通讯；重用性好，面向对象的继承和多态机制大大提高了代码重用的层次和粒度；易于组合拼接，对象是数据和功能的最小单位，为对象建立新的通信的联系，就能够组合出新的软件系统。
从设计方面，我们可以比较明显地看出结构化和面向对象的区别。结构化方法的核心是程序，从分析到设计，其实是从抽象到具体，从模糊到清晰地实现程序的过程；而面向对象方法的核心是功能，分析的是对象，设计的是行为，程序设计和系统设计相对分离。
（7）从应用上看
结构化方法的实质是问题求解，结构化程序是由算法决定的，算法是程序员分析设计的，程序的执行过程主要是由程序员控制，而不是由用户控制；面向对象方法中，程序员设计的是对象属性及操作方法，但在什么时间、使用什么方式操作对象则是完全由用户交互控制。
结构化方法的建模工具难以表达交互性强的软件系统，程序设计融入系统的分析和设计中，处理大型系统时会过于复杂，甚至很难控制；面向对象方法的抽象机制提供了自然的建模方法，特别是能很好地把握对象之间复杂的相互关系。
结构化方法比较适合工程计算、实时数据的跟踪处理、各种自动控制系统等等； 面向对象分析更加适用于复杂的、由用户控制程序执行过程的应用软件，比如大型游戏软件以及各类管理信息系统软件。
从团队分工和协作学习角度，陈述团队实施Visio建模工具学习、项目需求分析建模、软件系统设计等学习活动的心得（每项3分，合计9分）
吴**：本次团队项目学习，我们首先进行的是对Visio建模工具的学习，该项建模任务基本可以说是全员参与了，因为两个文档每个人都有撰写，而且都有对应的图表。不过在此之前没有绘制过类图等一些图，所以也学习了相关的绘制标准和知识。在这里花费了一些时间。最后和组员一起完成所有的用例图等图表的绘制。在本次作业，我学会了用Visio建模工具来进行绘画图形，在上次作业中我们是通过结构化方法来进行项目需求分析建模、软件系统设计的，而这一次我们采用的是面向对象分析方法来进行进一步的分析，我从中体验到了结构化分析方法与面向对象方法的异同，明白了它们之间的差异，同时也从这两次作业中深刻的理解到了它们的设计思路及思想，让我们更进一步的理解到结构化方法和面向对象方法对于不同的软件系统各有优劣。结构化方法把解空间分数据和功能两部分，可以更加清晰地进行需求分析和功能分解，数据流图能够细致地说明数据在各个功能模块之间的流动和变化，更适于系统设计的前期阶段。设计人员清楚地了解数据和系统要求的操作后，面向对象方法能够把数据和功能以对象为单位封装成一个整体，更直观地表达对象的状态变化和对象间的交互，更加准确地分析功能的实现过程，更适于在软件后期细化系统的具体行为。在本次作业中，我们团队成员分工明确，组员们一起交流沟通，对于不懂的问题，及时提出，组员一起探讨学习，促进了组员之间的友谊，利于团队和谐，促进团队的发展。
梁**：在本次作业中，我们一起学习了Visio建模工具，本次我们采用的是面向对象分析方法来进行项目需求分析以及软件系统设计，通过本次作业的完成，我从中了解到了其与我们上次采用结构化分析方法有所不同，虽然在理论课上，老师已经向我们介绍了关于它们的理论知识，但是对其了解不深，后通过我们自己的项目，对项目采用不同的方法去分析，让我从中更能了解到它们的异同点，可以说这几次的作业给我带来了许多不一样的体验，收获满满。经过几次的团队协作，我发现我们团队合作起来越来越顺利，不像以前一样磕磕碰碰，团队中各组员关系融洽，一起学习、一起进步，利于团队的发展。
石**：在本次实验任务发布后，我们组就一起学习了用Visio建模工具，之后PM根据我们的特长来进行合理分工，因为我在软件设计方面比较熟悉，所以担任起了关于软件设计、绘制类图的重任，带领我们团队的成员一起学习，因为其他组员对类图不太熟悉，我还向他们介绍了其相应的用法以及绘制的要点步骤，组员之间一起学习、合作，共同完成团队任务。总的来说，在我们团队，分工明确，PM会根据各自的特长来分配任务，让懂得该方面的组员来承担其领队的责任，带领其他组员一起团结协作，这种做法我是很赞同的，这样不仅利于团队和谐，也利于团队之间各个成员扬长避短，利于团队工作的开展。
马*：作业前期任务主要是利用Visio工具绘图，大家共同学习了Visio工具，一起完成了用例图、类图、WBS、数据流图等，还完成了一系列分析建模。在本次作业中，主要的问题不在于绘图工具的使用，而在于我们对需要建立的模型的认识不够，例如绘制类图的时候无从下手，后在石同学的带领下，我们了解了如何去绘制类图，完成了这些，大家又协作完成了项目需求报告和系统设计报告。我其实不是一个可以独立做事情的人，所以很喜欢和其他组员一起商量、共同完成事情的氛围，非常感谢组员的帮助以及通力合作。
