复旦大学961-软件工程-第二章-软件需求

961全部内容链接

软件需求的概念

需求工程定义为“直到（但不包括）把软件分解为实际架构构建之前的所有活动”。

软件需求包括：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性需求。

需求工程的基本过程

需求工程分为六个阶段：

• 需求获取：①系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、描述不同运行条件下系统或产品使用状况的应用场景等；②需求获取的工作产品为进行需求分析提供了基础
• 需求分析与协商：需求获取结束后，分析活动对需求进行分类组织，分析每个需求和其它需求的关系来检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。
• 系统建模：①建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。②常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。
• 需求规约：①软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。②需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。
• 需求验证：作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。
• 需求管理：①需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。②换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。

分层数据流模型

结构化分析方法

主要思想：抽象与自顶向下的逐层分解。

• 抽象：忽略一个问题中与当前目标无关的那些方面，以便更充分地关注与当前目标有关的方面
• 分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为止

数据流图

Data Flow Diagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工)过程，用于对系统的功能建模，基本元素包括：

数据流图示例：

数据流图的扩充符号

描述一个加工的多个数据流之间的关系

• 星号(＊)：表示数据流之间存在“与”关系
  • 所有输入数据流同时存在时，才能进行加工处理
  • 或者加工处理的结果是同时产生所有输出数据流
• 加号(＋)：表示数据流之间存在“或”关系
  • 至少存在一个输入数据流时，才能进行加工处理
  • 或者加工处理的结果至少产生一个输出数据流
• 异或(⊕)：表示数据流之间存在“异或”(互斥)关系
  • 必须存在且仅存在一个输入数据流时，才能进行加工处理
  • 或者加工处理的结果产生且仅产生一个输出数据流

数据流图的各个层次

• 顶层图：只有代表整个软件系统的1个加工，描述了软件系统与外界(源或宿)之间的数据流
• 0层图：顶层图中的加工经分解后的图称为0层图(只有1张)
• 中间层图：中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图
• 底层图：处于最底层的图称为底层图，其中所有的加工不再分解成新的子图

分层数据流图的画法

用例和场景建模及其UML表达

接下来的部分个人认为是出题的重点，但是基本不会考概念，只会给出场景，让你们去绘制相应的图。所以我用个人的理解，用最通俗的语言去解释每个概念，如有不严谨或错误的地方，欢迎在评论区指正。

用例图（用况图）

用况图的基本概念

用况图也叫用例图，用况图的主要功能是描述一个系统都有哪些功能，以及哪些角色会如何使用这些功能，不包含具体实现细节。 它包含了几个部分：

• 执行者（Actor，也叫参与者）：就是一个系统的使用者，这个使用者可以是普通用户，管理员，甚至可以是外部系统。
• 用况（Use Case，也叫用例）：可以理解为一个系统的某一个功能。比如上图中的设置订单，产生订单，安排支付等等
• 系统边界：就是图中的那个矩形，写了电话订购4个字。就是说把这个系统里的用况全部用矩形圈起来，矩形里面的就是系统提供的功能
• 关系：包括用况和用况的关系，就是图中的连线。用况和角色之间的连线

用况之间的关系

• 关联关系：一般是指执行者与用况之间的关系，可以简单理解为执行者要用这个用况。用横线（——）表示。

• 扩展关系：这个是指用况和用况之间有扩展关系。如图，导出Excel这个用况可以服务其他的用况。而“充值金额查询”这个用况需要用到“导出Excel”，但是即使金额查询没有导出excel的功能依然不影响该用况的单独存在，那么他们俩之间的关系就是扩展关系。符号为：

• 包含关系：就是一个用况包含了其他用况。比如图中，“设置订单”包含了“提供客户数据”，“产生订单”等。如果设置订单脱离了这些功能，则设置订单就无法单独存在，即不能正常提供功能。符号为：

• 泛化关系：与Java中的继承关系类似。如支付功能泛化后，可以衍生出现金支付和信用卡支付。符号为：

用况图举例

绘图时注意《include》和《extend》的箭头方向

活动图

活动图就是具体到某个功能的业务细节了。比如上图是订单管理的活动图。它主要描述订单管理的业务流程是什么。它主要包含如下部分：

• 起点：就是该活动的起点。没什么特殊意义。用实心圆表示。
• 结束：就是标志一下这个活动结束了。也没啥特殊意义。用空心圆+实心圆表示（上面的图有点问题）。
• 活动：就是一个动作，比如登录，显示订单列表等。用矩形表示
• 条件判断：前一个动作执行后，进行一个判断，来决定之后的走向。对应代码里面就是if。用菱形表示。
• 动作流：就是该动作结束后，下一步执行哪个。用箭头（→）表示

活动图举例：

若图中存在并行执行的，如图中的“制作并发放提货单”和“更新库存”，并行执行的上下话两个横扛，表示并行执行。

泳道图

泳道图其他不能算一种图。它是活动图的派生。也叫跨职能活动图，比如跨多个用户，或跨多个部分们等。可以把不同的用户，或者不同的部门分到不同的泳道中。活动也相应的进行分类。这样可以让活动图看的更清晰。

比如这样一张泳道图（原图链接），包含4个泳道，每个泳道代表一种职能。

顺序图

顺序图也叫时序图。与活动图一样，也是用来描述某一个功能的业务流程。但是它更注重对象与对象之间的交互，以及每个动作和消息发生的先后顺序。

绘制细节参考

状态机图

状态机图也叫状态图。它是各个流程的进一步细化。它是指某一个对象的状态变化。注意，精确到了某一个对象。比如，人的状态有生老病死。进程的五种状态等。状态机图就是用来描述这些状态是如何发生变化的。比如：

这是一个电梯的状态图，其中包含以下几个模块：

• 状态：表示当前对象的状态。图中就是指当前电梯的状态，符号为：
  其中状态名不能没有，其他两个可以没有。如果没有状态变量，则第二个就是活动。比如上图中的“向上移动和移动楼层”，这个移动楼层是活动而不是变量。
• 迁移：或者说转移。是指一个状态到另一个状态的转变。符号为箭头。箭头上写的是使该状态发生转变的事件。如，当开始上升时，电梯的状态变为向上移动。当到达时，电梯的状态变为空闲等。
• 起始状态：一个点。指向这个对象最初的状态
• 结束状态：若对象有最终状态，则最终状态指向该符号。比如人的最终状态是死，那么就是死指向该符号。上述图中，电梯没有最终状态，所以也就没有出现结束状态这个符号。

数据模型建模及其UML表达（类图）

类图就是描述面向对象关系用的。用图形的方式表示各个类之间的面向对象关系。这里只写一部分，应付考试，除了这些外，类图还有更详细的内容，考试不需要太过精确。

类的表示

类包含以下三个内容：

• 类名：对应Java中的类名，如Student
• 属性名：对应Java中的类的成员变量，格式为属性名:方法，如 age:int, name:String
• 操作：对应Java中的类方法，如 eat(), 如果有参数，则为 eat(food:String)。

注意：在画类图时，除了类名不可省略外，其他部分如果不重要可以省略。考试时如果有地方，尽量还是写上。

对象的表示

对象就是把类实例化之后产生的那个对象。表示方法与class类似，包含以下三个内容：

• 对象名:类名：指定对象名和类名。如 xiaoming:Student。注意需要增添下划线，与类区分开。
• 属性名=值：需要给出成员变量的具体值。如 age=18，name=“xiaoming”
• 操作：这个与类保持一致即可。

类之间的关系

关联

描述对象之间和其他实例之间的关系。常见的是包含关系，用直线表示。比如

两边是类，中间用线连接起来。线上写清楚他们之间关联的关系。

二元关联

是指两个类之间有关系。比如上面的 国家-城市。 关联通常是双向的，例如：
关联的两端还可以加上数量（星号“*”代表多个），例如：
这是指一个公司可以雇佣多个员工，一个员工也可以服务于多个公司。属于多对多关系

例2：

这个是指一个公司可以雇佣多个员工，但一个员工只能服务于一个公司。即一对多关系

关联的两端还可以加上角色名，例如：

该例子中，人是抽象的，驾驶员是人的泛化（驾驶员继承人）。轿车和公车也是如此。相当于在两端具体说明了该类的角色。

关联也可以自关联，即自身和自身关联，如：
员工和员工自关联。员工泛化出了工人和老板。其中关系为老板管理工人。而老板的数量是“0…1”，也就是0个或1个。而员工的数量是“1…*”，也就是1个或更多个。

多元关联

如果三个及以上的类之间有联系的话，也是可以相互关联的，他们中间加一个菱形，代表他们三个相互关联。这个用的应该不多。例如：

受限关联

一对多或多对多的时候，对“多”端进行说明。限制它一下，例如：
目录中包含多个文件，但限制这些文件必须是有序（ordered）的。

再例如：

目录和文件是一对多关系。但是通过对文件名的限制，唯一确定了某一个文件。也就是说我只想要该目录中的“文件名”文件

受限关联考的应该不多。即使在UML中没有体现出来，我觉得也还OK。

聚合

聚合的含义突出在这个聚字上。一堆人聚集在一起就聚成了一个组。一堆省份聚集在一起就聚成了一个国家。所以聚合的特点是组成成分必须一致，都是由一类东西组成的。例如：
该图表示多个人作为组的成员可以聚集成多个组。连接符号就是一个空心菱形加一条线。空心菱形是在最终的聚集结果上。

组合

组合的含义突出在组上面，“显示器+主机”组成了“计算机”，“胳膊、腿、头等”组成了“人”。组合强调的是不同的东西组成起来成为了一个新的东西。注意区分组合和聚合的区别。 组合的连接与聚合类似，只不过使用的是实心菱形。例如：
该图中，“多个正文+多个对话框+多个按钮+多个菜单”组合成了一个窗口

泛化

泛化就对应Java中的继承。 例如，Student 继承 Human。反过来说，Student是Human的泛化，或者说 Human可以泛化出Student。泛化的符号为
例如：

实现

实现就是Java中的实现（implement），一个类实现一个接口。符号为

依赖

依赖就是一个类用到了另一个类。它和关联不一样，关联是指一个类拥有另一个类的对象。比如：

class Company {
	Employee[] employees;
} // 这叫关联

这种叫关联（公司和员工是关联关系）。

但是依赖是使用关系，比如：

import java.lang.String; // Company使用了String

class Company {
	Employee[] employees;
	
	public Company(List<String> name) {
		Object obj = new Employee();
		// ...
	}
}

在该代码中Company和String的关系就是依赖，Company依赖String，除此之外，Company还依赖List，Object。 依赖的符号为：

书中对依赖有着更多的分类，比如访问、绑定、调用等。个人觉得没必要记这么多，只要知道这两个是依赖关系即可。