通过阅读本文章，你将知道：
- 什么是用例图？
- 用例图的目的是什么？
- 如何设计用例图？
概述
- 什么是用例图
用例图是参与者（用户或外部系统）与所考虑的系统之间交互的可视化表示。它从用户的角度描述系统的功能或行为。用例图捕获系统的功能需求，并帮助识别不同的参与者如何与系统交互以实现特定的目标或任务。
用例图提供了系统功能的高级概述，显示了它提供的不同特性或功能以及用户或外部系统如何与其交互。它们充当利益相关者之间的沟通工具，帮助澄清和验证需求、识别系统边界并支持开发和测试流程。
- 用例图的目的
- 展示用户与系统交互的方式
- 可视化系统架构
- 验证与确认系统需求
用例图的组成
用例如由如下元素组成：
- 参与者(Actor)
- 用例(Use Case)
- 系统(System)
- 包(Package)
接下来分别介绍上面元素。
参与者(Actor)
用例图中的参与者是在给定系统中执行角色的任何实体。这可以是一个人、组织或外部系统。通常用如下符号表示：
用例(Use Case)
用例代表系统内的功能或操作。它被绘制为椭圆形并以函数命名。它通常使用如下符号表示：
系统(System)
系统用于定义用例的范围并绘制为矩形。这是一个可选元素，但在可视化大型系统时很有用。例如，您可以创建所有用例，然后使用系统对象来定义项目涵盖的范围。或者您甚至可以使用它来显示不同版本中涵盖的不同领域。
包(Package)
包也是一个可选元素，和面向对象编程中的“包”概念类似，它用于将一些用例分组在一起。它通常使用如下符号表示：
用例图中的关系
用例图中可以有 5 种关系类型：
- 参与者和用例之间的关联关系
- 参与者之间的泛化关系
- 用例之间的扩展关系(<< extend >>)
- 用例之间的包含关系(<< include >>)
- 用例之间的泛化关系
参与者和用例之间的关联
参与者和用例之间的关联关系我们用实线表示，它其实强调的是一个参与者必须至少和一个用例关联，否则这个参与者不应该出现，不符合用例图的规范。
参与者之间的泛化
参与者(Actor)的泛化意味着一个参与者可以继承另一参与者的角色。当参与者A泛化于参与者B时，就表示参与者A继承了参与者B的所有用例。比如说普通员工和管理员之间的关系就是泛化关系，管理员可以拥有员工的所有操作行为(用例)。
例如下面：
用例之间的扩展关系
用例A扩展用例B，指的是在用例A的基础上添加用例B的基础上额外添加一些扩展行为。通常是可选的 它通过如下符号表示：
例如下面，我们对【存入资金】这个用例扩展了【计算资金】这个用例，并且只有存款超过 10,000 或年龄超过 55岁时才会触发该扩展用例。
在对一个用例进行扩展时我们通常会考虑如下事项：
- 扩展用例取决于扩展（基本）用例。在下图中，如果没有“存款资金”用例，“计算奖金”用例就没有多大意义。
- 扩展用例通常是可选的，并且可以有条件地触发。在图中，可以看到只有存款超过 10,000 或年龄超过 55岁时才会触发扩展用例。
- 扩展（基本）用例本身必须有意义。这意味着它应该是独立的，并且不能依赖于扩展用例的行为。
以上三点是我们在设计扩展用例时通常需要考虑的。
用例之间的包含关系
用例A包含于用例B，指的是用例B的行为是用例A的一部分。它通常用如下符号表示
这样设计主要原因是在多个用例中用例B是通用操作，所以为了简化复杂的行为。把通用行为用例B抽取出来。
注意用例之间的包含关系和用例之间的扩展关系的区别：
包含用例B它是强制的，而不是可选的，没有包含用例B，基本用例A就不完整。而在上一节中，扩展用例B是可选的，而且通常是在某一条件触发时才存在。
用例之间的泛化关系
用例之间的泛化关关系和参与者之间的泛化关系一样，当用例A泛化于用例B时，用例A就继承了用例B的所有行为。使用如下符号表示：
例如下面的支付账单用例泛化于微信支付用例和支付宝用例：
如何创建用例
在对一个系统设计用例时，我们一般遵循如下流程步骤：
- 找到系统中所有的参与者(Actor)
- 找到系统中所有的用例(Usee Case)
- 寻找系统中可重用的用例(用例之间的<< include >> )
- 开始完成不同参与者和用例之间的关联
- 开始对某个用例添加可选功能(用例之间的<< extend >>)
- 验证细化
