架构师备战(三)-软件工程(七) UML之用例图详解

大家好，欢迎来到IT知识分享网。

1、UML-4+1视图

UML-4+1视图将会与后面的架构4+1视图会一一对应上

视图往往出现在什么场景：我们看待一个事物，我们觉得它很复杂，难以搞清楚，为了化繁为简，我们会从一个侧面去看，这就是视图。而4+1视图就是分不同角度去看事物。

• 逻辑视图（logical view）
• 一般使用类与对象来表示，主要表示系统的功能 针对的人群是系统分析、设计人员
• 实现视图（implementation view）
• 一般是呈现了物理代码文件和组件，针对人群的是程序员
• 进程视图（process view）
• 一般强调的是并发，跟线程、进程相关，针对的人群一般是系统集成人员
• 部署视图（deploy view）
• 强调的是软件到硬件的映射关系，针对的人群是系统和网络工程师
• 用例视图（use-case view, 4+1的1，它跟其他4个人都有相关性）
• 强调的是需求分析的模型， 针对的人群是最终的用户

UML作为一种工具，虽然是从需求分析阶段去用它，但事实上，它在整个开发各个阶段都会要用到，分析阶段用了设计阶段用，设计阶段用了实现阶段也会用到前期设计好的这些图。

2、OOA阶段两个重要模型

需求分析中有两个重要模型必须要建立，一个是用例模型，一个是分析模型。

也就是说，我们要去做UML分析阶段的建模工作，主要就是建这两种模型，其他的模型不是必须的，但可以辅助性的使用。用例模型对应的是用例图，是必须的。分析模型对应的是类图，也是必须的。

用例模型的构建分四个步骤，每个步骤都会各司其职，首先识别参与者，再合并需求并获得用例，然后细化用例模型，最后调整用例模型。

分析模型的构建也分四个步骤，主要完成先定义类，再定义类之间的关系，然后为类添加职责，从而为类建立交互图。

• 用例模型（分为四个步骤）
• 1、识别参与者
• 2、合并需求获得用例
• 3、细化用例描述
• 用例名称
• 简要说明
• 事件流
• 非功能需求
• 前置条件
• 后置条件
• 扩展点
• 优先级
• 4、调整用例模型
• 包含关系
• 扩展关系
• 泛化关系
• 分析模型（分为四个步骤）
• 1、定义概念类
• 2、识别类之间的关系
• 依赖关系
• 关联关系
• 聚合关系
• 组合关系
• 泛化关系
• 实现关系
• 3、为类添加职责
• 4、建立交互图

3、用例图（重要）

3.1、用例图的定义

用例图是描述一组用例、参与者及它们之间的关系

3.2、用例图的基本思想

• 1、从用户角度描述系统的功能
• 比如我们要去进行系统的开发，要去获取对应的需求，是不是你也会去找到，z合格系统到底有那些人会去用它。然会去与用它的人沟通，看一下他们希望用到一些什么系统的功能。

• 2、参与者是外部触发因素
• 常见参与者：系统用户，老师，学生都属于参与者
• 特殊的参与者：组织、外部系统，时间
• 外部B系统通过某种机制调用A系统, B对于A来说就是一个参与者
• 时间，温度，传感器等都可以别鉴定为参与者，比如时间，我每个月，会有每个月的一号统计上一个月的报表，这个是时间就是参与者
• 3、用例是功能单元

3.3、用例图的设计思想

用例图本质上来说，是一种比较简单的图，它并不复杂，设计这种图的目的就是让大家从枯燥文字信息里面获取信息的格局发生变化才提出的，所以它本质上就很直观，其实也很实用。

3.4、用例建模的流程

• 识别参与者（必须）
• 合并需求获得用例（必须）
• 细化用例描述（必须）
• 调整用例模型（可选）

一个图书管理员相关的用例图如下

用例图是怎么绘制出来的呢，一般是这样的情况，比如我们前期已经调研出来了一些情况，可能你都已经采访的图书管理员，比如你问他平时都会用到哪些功能呢，他巴拉巴拉给你说了一大堆，你就从这一段文字当中，提取有效的信息。

3.4.1、识别参与者（必须）

图书管理员提取出来，成为参与者。这就是识别参与者

3.4.2、合并需求获得用例（必须）

然后图书馆管理员的描述了解到他要用到新增书籍，查询数据，等级外借信息，查询外借信息等，这就是所谓的合并需求获取用例。本质上就是把文字转化为图形的一个过程。

3.4.3、细化用例描述（必须）

这个用例描述非常重要，不可或缺，包含如下内容：

• 用例名称
• 简要说明
• 事件流
• 主事件流
• 备选事件流
• 非功能需求
• 前置条件
• 后置条件
• 扩展点
• 优先级

我们就看这张图，能够看出来登记外界信息到底要登记什么吗，显然是不知道的，这时候就需要细化用例描述了。

有了这个细化用例描述，就很清楚这个用例是干什么用的了。

3.4.4、调整用例模型（可选）

也叫做优化用例模型，主要是根据三大关系，包含关系（早期也叫使用关系）、扩展关系、泛化关系。

3.4.5、包含、扩展、泛化

包含关系：其中这个提取出来的公共用例称为抽象关系，而把原始用例称为基本用例或基础用例关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。

扩展关系：如果一个用例明显的混合了两种或两种以上的不同场景，根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展关系，这样描述可能更加清晰。

泛化关系：当多个用例共同有一种类似的结构和行为时，可以将他们的共性抽象成父用例，其他的用例作为泛化关系的子用例。在用例的泛化关系中，子用例时父用例的一种特殊形式，子用例集成了父用例所有结构、行为和关系。

前面这张图不好表示泛化，下面这张图将展示这三种给关系。

4、小结

这个章节主要的内容时用例图，描述了用例图的概念，基本思想，设计思路，构建流程和用例图内部组件已经对象的关系进行了描述和讲解，下一章节将不会详细描述类图的相关内容。加油！