目录
前言
软件工程生命周期分为八个阶段：
问题定义--->可行性研究--->需求分析
--->概要设计--->详细设计--->编码与单元测试
--->综合测试--->软件维护
这节我们讲的是软件开发流程中的一个阶段，需求分析。
需求分析
任务：系统必须做什么？
- 获取用户需求，从用户角度考虑，用户需要系统完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求
- 提交的主要文档：
软件需求规格说明书：以书面形式准确地描述软件需求。
需求获取
- 自悟
- 访谈
- 小组会
- 快速建立软件原型
UML概述
UML (Unified Modeling Language-----统一建模语言）为面向对象软件设计提供统一的、标准的、可视化的建模语言。
UML是一种可视化的建模语言。
- 建模:
建立模型，通过对客观事物建立一种抽象的方法，用来表征事物并获得对事物本身的理解，是对事物的一种无歧义的书面描述。- 建模是一种常用的、深入理解并解决问题的方法
- 建模原则：
现实世界能够映射到模型
模型能够描述现实世界；
模型行为能够正确反映现实世界方法
用例图
用例图是指由参与者（Actor）、用例（Use Case）以
及它们之间的关系(Relationship)构成的用于描述系统功能的静态视
图
- 用例图是外部参与者所能观察到的系统功能的模型图。
- 用例是参与者要实现的最终目标
- 用例图还是软件测试人员进行测试的指导
用例图示例：
用例图的组成
- 参与者(Actor)
- 用例(Use Case)
- 关系(Relationship)
用例图中的符号和含义
- 参与者与用例之间如果有明显的使用关系，可以加箭头
- 由于一个用例代表一个系统功能，扩展是指在用例上扩展一个功能，这个功能不一定被执行，扩展用例在一定条件下才执行。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性。
- 包含用例是属于从基用例分解出来的用例，包含用例一定会被执行，如果缺少包含用例，基用例就不完整。
包含的两种使用场景
- 使用包含用例来封装一组跨越多个用例的相似动作，以便被多个基用例复用。包含关系最典型的应用就是复用。
- 当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成一个被包含的用例
用例图补充："系统"
- 系统被看作是一个提供用例的黑盒子
- 描述该系统功能的用例置于方框内，代表外部实体的行为置于方框外
用例模型建模
任务：获取需求，建立需求模型
- 确定系统参与者
- 确定场景
- 确定系统用例
- 确定用例之间关系
- 用例文档的编写。
确定系统参与者
参与者是指直接和系统交互的一类事物，参与者
主要有如下三类：
- 直接使用系统的人，如 图书管理员，普通读者等（角色）
- 与该系统相关的其他系统，如支付系统、邮件系统
- 自动发生的事件，如时间，温度等自动驱动用例功能的事件。
确定系统用例
用例是对一组场景共同行为的抽象。
重点在于参与者与系统之间的交互而不是系统内部的活动。
- 可观测：
用例是参与者与系统的交互，不是系统内部的活动，且一定是参与者主动发起的，最后结果一定要反馈给参与者。习惯说用例止于边界。 - 结果值：
每个用例都会对外界参与者产生一个有价值的结果。 - 系统执行：结果值由系统所生成
- 由参与者执行：用例的识别和定义都是从参与者角度出发，要以参与者的视角获取和定义
用例文档
- 用例文档是用于描述用例的文档，每一个用例对应于一个用例文档。
- 在用例文档中需要用文字的方式描述用例的执行过程，即执行者与系统的交互过程。
- 用例建模包括用例图的绘制和用例文档的编写。
用例文档组成部分
- 用例名称
- 用例描述
- 参与者
- 前置条件
- 后置条件
- 基本事件流
- 异常事件流
- 其他事件流
- 扩展点
活动图
活动图是动态行为图：用于描述系统的工作流程或用例的内部行为。
组成元素
- 初始节点和终点
- 活动节点
- 转换
- 决策与分支，合并
- 分岔与汇合
初始节点和终点
- 初始节点表示活动的起点，用一个实心圆表示
- 终点表示活动的终结点，用一个圆圈内加一个实心圆来表示活动终点．
- 在活动图中，可能包含多个活动终点
活动节点
表示一个活动，一个活动表示一个或多个动作的集合。
转换
- 当一个活动结束时，活动控制流就会传递给下一个活动节点，在活动图中称之为"转换".
- 用一条带箭头的直线（或折线）来表示转换。
决策与分支、合并
- 决策与分支：
用菱形表示的一个或多个离开转换。- 每个离开转换上都会有一个监护条件，
- 用来表示满足什么条件的时候执行该转换。
- 合并：
指两条或多条控制路径汇合的情况- 用菱形符号表示。
- 用菱形符号表示。
分岔与汇合
分岔：
表示一个控制流被两个或多个控制流代替，经过分岔后，这些控制流是并发 进行的。
汇合与分岔相反，表示两个或多个控制流被一个控制流代替。
类图
- 类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。
类的表示
类的命名
类的属性
类的方法的命名规范
类的职责
职责指的是类所担任的任务：即类要完成什么样的功能，要承担什么样的义务。
类图中的关系
- 关联
- 聚集：包括聚合和组合
- 依赖
- 泛化
- 实现
关联
关联表示两个类的对象之间存在某种语义上的联系。
长期的，稳定的。
表现在代码实现中，一个对象会作为另一个对象的属性关联关系。
某个类的对象可以和其他类的多个对象联系。
举例：
购物功能：管理员查询用户的订单情况。用户和订单之间的关系就是关联。
聚集
- 聚集是关联的一种特殊情况。
- 聚集表示类与类之间的关系是整体与部分的关系。
聚集分为聚合和组合： - 聚合
重点：
课题组没了，不会导致人的消失。
即"整体不存在了，部分还存在"。
设计中：- 人的数组作为课题组的一个属性。
- 课题组集合作为人的一个属性。
数据库操作中，课题组的删除，不涉及到人员删除。
- 组合
如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失，则该聚集称为组合。
聚合和组合的区别
依赖
依赖关系描述两个类之间的使用关系：
- 两个类之间是没有关系的
- 但是一个类的实现需要另一个类的协助，这就产生了依赖。
依赖关系的代码表现：
方法 的局部变量、方法 参数、对静态方法的调用
注意：依赖关系不会增加属性
泛化
UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。
在UML中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。
抽象类或者抽象操作的名字用斜体表示
实现
对应于类和接口之间的关系。
- 接口：
接口通常是指一组方法的抽象集合，它们定义了类或结构体应该实现的行为。 - 接口中只包含方法的名字而不包含方法的具体实现。（多态）
顺序图
- 顺序图是动态交互图，用于显示对象间的交互活动，它关注对象之间消息传送的时间顺序。
- 目的：通过顺序图来对执行者和系统的交互过程进行建模，方便用户更好地理解系统的工作流程
顺序图组成元素
- 对象-----Object
- 生命线-----Lifeline
- 控制焦点（激活期）-----Activation
- 消息-----Message
对象
一般命名方式：
对象名：类名
生命线
- 表示对象存在的时间
- 如果对象生命期结束，则用注销符号表示
控制焦点（激活期）
- 对象执行某个动作的时期
消息
- 对象间交互信息的方式，表示为从一条生命线到另一条生命线的箭头
- 箭头指向详细的接收者，表示对其操作的调用。
- 每种消息的箭头不一样
同步消息：
发送者把消息发送后，等待，直到接收者返回控制，即必须得到回应才能进行下一项操作。
异步消息：
消息可以是一个信号或一次操作调用，收到消息即为事件。 - 可以有两种异步消息:
- 一种是发送者向接收者发送信号
- 另一种是由调用者调用接收者的操作
返回消息（虚线表示）：
表示消息的返回。一般同步的返回不需画出，直接隐含，也可使用返回消息强调返回结果值。
顺序图补充-----1.消息编号
- 顺序编号------在每个消息的前面加上一个用冒号隔开的顺序号来表示其顺序。
- 嵌套编号------把属于同一个对象发送和接收的消息放
在同一层进行编号。
分析类
对象系统中所有功能都是由类来实现，这些类是从用例文档中找出，并将其所描述的系统行为分配到这些类中，在面向对象分析阶段所定义的这些类通称为分析类。
- 分析类对应MVC架构的三个层次：Boundary，Control，Entity。
边界类(Boundaryclass)
位于系统与外界的交界处，处于系统最上层，处理系统环境和系统内部间的通信。
边界类分为两类：
- 用户界面类：系统与外部进行交互的类，在分析阶段关注于为用户提供哪些操作，如用户输入数据，展示数据给用户。
- 系统/设备接口类：系统与外部系统或设备之间交互的接口类，在分析阶段关注交互的协议。
UML中边界类的表示：
控制类Control
- 处于中间层，封装上层的边界类和下层的实体类之间的交互行为，是整个用例行为的协调器
- 控制类可以有效的将边界对象和实体对象分开
- 将用例所特有的行为与实体对象分开，使实体对象有更高的复用性。
- 更适应系统边界对象的变更；
特点：
- 独立于外部环境，不依赖于环境的变更
- 定义控制逻辑和事务逻辑
- 实体类内部结构或行为发生变更时控制类不会有大的变更。
UML中控制类的表示：
实体类(Entityclass)
代表系统的核心概念，来自对业务中的实体对象的抽象，用于记录系统所需要维护的数据和对这些数据的处理行为。
UML中实体类的表示：
OOA动态模型-状态图（未完）
- 一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
- 状态图作用：
- 描述一个特定对象的所有可能状态及其引起状态转移的事件。
- 描述业务领域的业务流程：在什么状态下，有什么事件发生，导致了什么后果。
