前言

软件工程生命周期分为八个阶段：
问题定义—>可行性研究—>需求分析
—>概要设计—>详细设计—>编码与单元测试
—>综合测试—>软件维护

这节我们讲的是软件开发流程中的一个阶段，需求分析。

---

需求分析

任务：系统必须做什么？

• 获取用户需求，从用户角度考虑，用户需要系统完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求
• 提交的主要文档：
  软件需求规格说明书：以书面形式准确地描述软件需求。

UML概述

UML (Unified Modeling Language-----统一建模语言）为面向对象软件设计提供统一的、标准的、可视化的建模语言。
UML是一种可视化的建模语言。

• 建模:
  建立模型，通过对客观事物建立一种抽象的方法，用来表征事物并获得对事物本身的理解，是对事物的一种无歧义的书面描述。
• 建模是一种常用的、深入理解并解决问题的方法
• 建模原则：
  现实世界能够映射到模型
  模型能够描述现实世界；
  模型行为能够正确反映现实世界方法

用例图

用例图是指由参与者（Actor）、用例（Use Case）以
及它们之间的关系(Relationship)构成的用于描述系统功能的静态视
图

• 用例图是外部参与者所能观察到的系统功能的模型图。
• 用例是参与者要实现的最终目标
• 用例图还是软件测试人员进行测试的指导

用例图示例：

用例图的组成

• 参与者(Actor)
• 用例(Use Case)
• 关系(Relationship)

用例图中的符号和含义

1. 参与者与用例之间如果有明显的使用关系，可以加箭头
2. 由于一个用例代表一个系统功能，扩展是指在用例上扩展一个功能，这个功能不一定被执行，扩展用例在一定条件下才执行。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性。
3. 包含用例是属于从基用例分解出来的用例，包含用例一定会被执行，如果缺少包含用例，基用例就不完整。
   

包含的两种使用场景

4. 使用包含用例来封装一组跨越多个用例的相似动作，以便被多个基用例复用。包含关系最典型的应用就是复用。
5. 当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成一个被包含的用例

用例图补充：“系统”

6. 系统被看作是一个提供用例的黑盒子
7. 描述该系统功能的用例置于方框内，代表外部实体的行为置于方框外
   

用例模型建模

任务：获取需求，建立需求模型

1. 确定系统参与者
2. 确定场景
3. 确定系统用例
4. 确定用例之间关系
5. 用例文档的编写。

确定系统参与者

参与者是指直接和系统交互的一类事物，参与者
主要有如下三类：

• 直接使用系统的人，如 图书管理员，普通读者等（角色）
• 与该系统相关的其他系统，如支付系统、邮件系统
• 自动发生的事件，如时间，温度等自动驱动用例功能的事件。

确定系统用例

用例是对一组场景共同行为的抽象。
重点在于参与者与系统之间的交互而不是系统内部的活动。

• 可观测：
  用例是参与者与系统的交互，不是系统内部的活动，且一定是参与者主动发起的，最后结果一定要反馈给参与者。习惯说用例止于边界。
• 结果值：
  每个用例都会对外界参与者产生一个有价值的结果。
• 系统执行：结果值由系统所生成
• 由参与者执行：用例的识别和定义都是从参与者角度出发，要以参与者的视角获取和定义

用例文档

• 用例文档是用于描述用例的文档，每一个用例对应于一个用例文档。
• 在用例文档中需要用文字的方式描述用例的执行过程，即执行者与系统的交互过程。
• 用例建模包括用例图的绘制和用例文档的编写。

用例文档组成部分

• 用例名称
• 用例描述
• 参与者
• 前置条件
• 后置条件
• 基本事件流
• 异常事件流
• 其他事件流
• 扩展点
  
  

活动图

活动图是动态行为图：用于描述系统的工作流程或用例的内部行为。

组成元素

• 初始节点和终点
• 活动节点
• 转换
• 决策与分支，合并
• 分岔与汇合

初始节点和终点

• 初始节点表示活动的起点，用一个实心圆表示
• 终点表示活动的终结点，用一个圆圈内加一个实心圆来表示活动终点．
• 在活动图中，可能包含多个活动终点

活动节点

表示一个活动，一个活动表示一个或多个动作的集合。

转换

• 当一个活动结束时，活动控制流就会传递给下一个活动节点，在活动图中称之为“转换”.
• 用一条带箭头的直线（或折线）来表示转换。

决策与分支、合并

• 决策与分支：
  用菱形表示的一个或多个离开转换。
  • 每个离开转换上都会有一个监护条件，
  • 用来表示满足什么条件的时候执行该转换。
• 合并：
  指两条或多条控制路径汇合的情况
  • 用菱形符号表示。
    

分岔与汇合

分岔：
表示一个控制流被两个或多个控制流代替，经过分岔后，这些控制流是并发进行的。
汇合与分岔相反，表示两个或多个控制流被一个控制流代替。

类图

• 类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。

类的表示

类的命名

类的属性

类的方法的命名规范

类的职责

职责指的是类所担任的任务：即类要完成什么样的功能，要承担什么样的义务。

类图中的关系

• 关联
• 聚集：包括聚合和组合
• 依赖
• 泛化
• 实现

关联

关联表示两个类的对象之间存在某种语义上的联系。
长期的，稳定的。
表现在代码实现中，一个对象会作为另一个对象的属性关联关系。
某个类的对象可以和其他类的多个对象联系。

举例：
购物功能：管理员查询用户的订单情况。用户和订单之间的关系就是关联。

聚集

• 聚集是关联的一种特殊情况。
• 聚集表示类与类之间的关系是整体与部分的关系。
  
  聚集分为聚合和组合：
• 聚合
  
  重点：
  课题组没了，不会导致人的消失。
  即“整体不存在了，部分还存在”。
  设计中：
  • 人的数组作为课题组的一个属性。
  • 课题组集合作为人的一个属性。

数据库操作中，课题组的删除，不涉及到人员删除。

• 组合
  如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失，则该聚集称为组合。

聚合和组合的区别

依赖

依赖关系描述两个类之间的使用关系：

• 两个类之间是没有关系的
• 但是一个类的实现需要另一个类的协助，这就产生了依赖。

依赖关系的代码表现：
方法的局部变量、方法参数、对静态方法的调用
注意：依赖关系不会增加属性

泛化

UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。

在UML中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。

抽象类或者抽象操作的名字用斜体表示

实现

对应于类和接口之间的关系。

• 接口：
  接口通常是指一组方法的抽象集合，它们定义了类或结构体应该实现的行为。
• 接口中只包含方法的名字而不包含方法的具体实现。（多态）
  

顺序图

• 顺序图是动态交互图，用于显示对象间的交互活动，它关注对象之间消息传送的时间顺序。
• 目的：通过顺序图来对执行者和系统的交互过程进行建模，方便用户更好地理解系统的工作流程

顺序图组成元素

• 对象-----Object
• 生命线-----Lifeline
• 控制焦点（激活期）-----Activation
• 消息-----Message

对象

一般命名方式：

对象名：类名

生命线

• 表示对象存在的时间
• 如果对象生命期结束，则用注销符号表示
  

控制焦点（激活期）

• 对象执行某个动作的时期
  

消息

• 对象间交互信息的方式，表示为从一条生命线到另一条生命线的箭头
• 箭头指向详细的接收者，表示对其操作的调用。
• 每种消息的箭头不一样
  同步消息：
  发送者把消息发送后，等待，直到接收者返回控制，即必须得到回应才能进行下一项操作。
  
  异步消息：
  消息可以是一个信号或一次操作调用，收到消息即为事件。
• 可以有两种异步消息:
  • 一种是发送者向接收者发送信号
  • 另一种是由调用者调用接收者的操作

返回消息（虚线表示）：
表示消息的返回。一般同步的返回不需画出，直接隐含，也可使用返回消息强调返回结果值。

顺序图补充-----1.消息编号

• 顺序编号——在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。
  
• 嵌套编号——把属于同一个对象发送和接收的消息放
  在同一层进行编号。
  

分析类

对象系统中所有功能都是由类来实现，这些类是从用例文档中找出，并将其所描述的系统行为分配到这些类中，在面向对象分析阶段所定义的这些类通称为分析类。

• 分析类对应MVC架构的三个层次：Boundary，Control，Entity。

边界类(Boundaryclass)

位于系统与外界的交界处，处于系统最上层，处理系统环境和系统内部间的通信。
边界类分为两类：

• 用户界面类：系统与外部进行交互的类，在分析阶段关注于为用户提供哪些操作，如用户输入数据，展示数据给用户。
• 系统/设备接口类：系统与外部系统或设备之间交互的接口类，在分析阶段关注交互的协议。

UML中边界类的表示：

控制类Control

• 处于中间层，封装上层的边界类和下层的实体类之间的交互行为，是整个用例行为的协调器
• 控制类可以有效的将边界对象和实体对象分开
  • 将用例所特有的行为与实体对象分开，使实体对象有更高的复用性。
  • 更适应系统边界对象的变更；

特点：

• 独立于外部环境，不依赖于环境的变更
• 定义控制逻辑和事务逻辑
• 实体类内部结构或行为发生变更时控制类不会有大的变更。

UML中控制类的表示：

实体类(Entityclass)

代表系统的核心概念，来自对业务中的实体对象的抽象，用于记录系统所需要维护的数据和对这些数据的处理行为。
UML中实体类的表示：

OOA动态模型-状态图（未完）

• 一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
• 状态图作用：
  • 描述一个特定对象的所有可能状态及其引起状态转移的事件。
  • 描述业务领域的业务流程：在什么状态下，有什么事件发生，导致了什么后果。