0 需求分析基础

需求分析的任务

1. 建立分析模型，达成开发者和用户对需求信息的共同理解
2. 依据共同的理解，发挥创造性，创建软件系统解决方案

需求分析模型与建模

• “模型是对事物的抽象，帮助⼈们在创建⼀个事物之前可以有更好的理解”[Blaha2005]
• 建⽴模型的过程被称为建模。“它是对系统进⾏思考和推理的⼀种⽅式。建模的⽬标是建⽴系统的⼀个表示，这个表示以精确⼀致的⽅式描述系统，使得系统的使⽤更加容易“[Fishwick1994]。

建模常用手段是抽象（Abstraction）和分解（Decomposition/Partitioning）

常见分析模型

方法	模型	描述
结构化方法	数据流图，Data Flow Diagram	从数据传递和加工的角度，描述了系统从输入到输出的功能处理过程。运用功能分解的方法，用层次结构简化处理复杂的问题
	实体关系图，Entity Relationship Diagram	描述系统中的数据对象及其关系，定义了系统中使用、处理和产生的所有数据
面向对象方法	用例图，Use-Case Diagram	描述用户与系统的交互。从交互的角度说明了系统的边界和功能范围
	类图，Class Diagram	描述应用领域当中重要的概念以及概念之间的关系。它捕获了系统的静态结构
	交互图（顺序图），Interaction(Sequence) Diagram	描述系统中一次交互的行为过程，说明了在交互当中的对象协作关系
	状态图，State Diagram	描述系统、用例或者对象在其整个生命期内的状态变化和行为过程

1 用例图

用例：在系统（或者子系统或者类）和外部对象的交互当中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务。[Rumbaugh2004]

用例描述了在不同条件下系统对某一用户的请求的响应。根据用户的请求和请求时系统的条件，系统将执行不同的行为序列，每一个行为序列被称为一个场景，一个用例是多个场景的集合。

用例图的基本元素

1. 用例：椭圆表示
2. 参与者：小人，是系统或者其它系统对要开发的系统扮演的角色
3. 关系：简单的就是一条直线，参与者之间可能会有继承之类的关系，用例之间也会有关系
4. 系统边界：一个框，限定系统的边界

1.1 用例图的建立

1. 目标分析与解决方向的确定
2. 寻找参与者
3. 寻找用例
4. 细化用例

细化用例：如果用例的力度不合适就需要进行细化和调整，判断标准是如果用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务

用例图建立过程中的常见错误：

1. 不要讲用例细化为单个操作：例如，不要将用户管理细化为增加、修改和删除三个更小的用例，因为他们要联合起来才能体现出业务价值
2. 不要将同一个业务目标细化为不同用例：例如特价策略制定和赠送策略制定
3. 不要将没有业务价值的内容作为用例：常见的错误有“登陆”（应该描述为安全性或者质量需求）、“数据验证”（应该描述为数据需求）、“连接数据库”（属于软件内部实现而不是需求）等

1.2 用例模板

2 分析类图

又称为概念类图或领域模型

分析类图是面向对象分析方法的核心，描述类（对象）和这些类（对象）之间的关系。它与设计类图有所不同，主要关注系统与外界的交互，而不是软件系统的内部构造机制。类型、方法、可见性等复杂的软件构造细节不会在概念类图中

需要注意的是这里所说的分析类图和设计类图是不太一样的

2.1 分析类图的基本元素

1. 对象：主要包括标识符、状态和行为
2. 类：对象集合的抽象
3. 链接（Link/Dependency）：对象之间的互相协作的关系，描述了对象之间的物理或者业务联系
4. 关联：对象之间链接的抽象，包括聚合与组合（更强的关联关系）
5. 继承：是一种泛化的关系

几种关系的图例：

1. 依赖：虚线鱼骨箭头
2. 关联：实线鱼骨箭头（双向关联没有箭头）
3. 聚合：实线空心菱形箭头
4. 组合：实线实心菱形箭头
5. 泛化-继承：实线空心三角形箭头
6. 泛化-实现接口：虚线空心三角形箭头

2.2 建立概念类图

对每个用例文本描述，尤其是场景描述，建立局部的概念类图：

1. 根据用例的文本描述，识别候选类
2. 筛选候选类，确定概念类
3. 识别关联
4. 识别重要属性

将所有用例产生的局部概念类图进行合并，建立软件系统的整体概念类图

2.2.1 候选类识别

1. 发现软件系统与外界交互可能涉及的对象与类，它们就是候选类
2. 行为分析、名词分析、CRC等很多方法都可以用来分析用例文本描述

2.2.2 确定概念类

确定概念类的准则

1. 依据系统的需求
2. 该类的对象实例的状态与行为是否完全必要

候选类向概念类的转化

1. 如果候选类的对象实例：
   1. 既需要维持一定的状态，有需要依据状态表现一定的行为（即有相关的状态和行为），那么它就是一个概念类
   2. 如果只需要维护状态，但是不需要表现行为，那么它应该是其他概念类的属性
   3. 如果不需要维护状态，但是需要表现行为，那么首先要审视需求是否有遗漏，因为没有状态支持的对象无法表现行为。如果确定没有需求的遗漏，就需要剔除该候选类，并将行为转交给具备状态支持能力的其他概念类
   4. 如果既不需要维护状态，又不需要表现行为，那么该候选类应该完全被剔除。

2.2.3 识别关联

1. 分析用例文本描述，发现概念类之间的协作，需要协作的类之间需要建立关系
2. 分析和补充问题域内的关系，例如概念类之间的整体部分关系和明显的语义联系。（但要注意对问题域关系的补充要适可而止，不要把关系搞得过度复杂化）
3. 去除冗余关联和导出关联

2.2.4 识别重要属性

1. 这些属性往往是实现类写作时必要的信息，是写作的条件、输入、结果或者过程记录
2. 通过分析用例的描述，并与用户交流，补充问题域信息，可以发现重要的属性信息
3. 在分析每个单独的用例（场景）描述时，为各个概念类发现的重要属性可能不多，甚至有些概念类没有任何重要属性。但是，系统通常有多个用例和很多场景，会建立多个局部的概念类图，只有在合并所有局部概念类图之后，各个概念类的重要属性才能得到全面的体现

3 系统顺序图

分析阶段主要是利用系统顺序图，表达系统和外部参与者之间的交互行为。

消息种类

1. 同步消息：实线实心三角箭头
2. 异步消息：实线鱼骨箭头
3. 返回消息：虚线鱼骨箭头

图例

1. Opt是可选项
2. loop是循环
3. alt是多选一

4 状态图

如何建立状态图

1. 确定上下文环境：状态图是立足于状态快照进行行为描述的，因此建立状态图时首先要搞清楚状态的主体，确定状态的上下文环境。常见的状态主体有：类、用例、多个用例和整个系统。
2. 识别状态：状态主体会表现出一些稳定的状态，它们需要被识别出来，并且标记出其中的初始状态和结束状态集。在有些情况下，可能会不存在确定的初始状态和结束状态
3. 建立状态转换：根据需求所描述的系统行为，建立各个稳定状态之间可能存在的转换
4. 补充详细信息，完善状态图：添加转换的触发事件、转换行为和监护条件等详细信息

Reference

1. 南京大学软件学院2022春季学期《软件工程与计算二》