如果说活动图是文章是要说什么，那么用例图就是设计如何在文章中表达我们想要的说的：是几个故事，故事的主人翁是这么在故事里度过的。
对与软件，活动图让我们知道要做什么事，用例图就是让我们知道要做的事得分成几部分？怎么做？
如下图又是一个百度图：
图中就包括了我们所有的用例图构成部分: 参与者、用例、用例关系（扩展，包含，泛化）。
用例图的思路和画法
步骤：
- 确定系统范围，即给系统命名。我们做的就是画一个大大的方块。
- 找参与者
a. 参与者就是和系统交互的对象。（可以是人，系统，时间，等）
b. 如果有一个操作是系统定时发生的，就可以引出一个参与者：时间 - 找用例
a. 用例就是参与者和系统之间要做的交互
b. 活动图可以帮助找用例的，相互验证可以改善两者 - 编写用例叙述
a.用例叙述不需要一次编辑完善，因为用例图是反复确认的过程。
约束：
- 用例发生的顺序可以用在用例图中上下来暗示。
- 包含关系的用例建议在原用例的右边
- 扩展关系，泛化关系建议在原用例的下边
- 参与者系统不用实现，但是我们要为参与者提供接口。这个在用例图中就要有所准备。
- 尽量减少使用 扩展，泛化，包含关系。这些关系之间的关系不同的人理解起来比较模糊。
- 包含和扩展关系应该避免达到两层。
用例控件
以下我们介绍用例图的各个属性，参考书籍【系统分析师UML用例实战】：
| 定义 |
图解 |
说明 |
|---|---|---|
| 参与者(actor) |  |
指位于系统外部，在用例执行期间与系统产生交互的对象 |
| 用例(User Case) |  |
系统对外提供的服务或功能 |
| 聚合关系(association) |  |
参与者与用例之间的实线，表示两种之间交互 |
| 包含关系(include) |  |
如果发现多个用例叙述中有一部分流程相同，就可以独立处理，重用。 |
| 扩展关系(extend) |  |
在特定条件下才被额外使用的，部分独立处理就是扩展。扩展一般用于对旧功能的扩充定制化 |
| 泛化关系(generalization) |  |
泛化可以用于参与者和用例，标识在原来的范围内有一个特殊的部分，不但有原来群体的功能，还有特色的功能。 |
用例描述
一份用例，单有用例图是不够的，用例图只能描述用例关系，而不能准确描述做什么，怎么运行。
这时我们需要用例叙述(use case narrative)，它可以用文件描述参与者与系统之间应该如何交互的细节。
| 用例叙述组成 | |
|---|---|
| 前置条件(precondition) | 执行该用例之前，必须成立的条件。即前置条件成立，用例才会执行。 |
| 后置条件(postcondition) | 执行该用例之后，必须成立的条件。即执行用例后，要检测后置条件。如果条件成立，说明用例正确执行完毕。 |
| 事件流程(flow of event) | 在前置条件和后置条件中间执行的流程，也是用例真正要做的事。 |
主要流程和替代流程
主要流程：系统一切正常、没有例外的执行过程。
替代流程：对主流程的特殊情况的补充说明
替代流程既可以作为事件流程的一部分，描述在事件流程中，也可以单拆出来作为一个用例叙述描述。
用例叙述的格式，差别很大。
常见的有：
表格类：
| 用例名称 | |
|---|---|
| 前置条件 | ------------------------------------- |
| 后置条件 | ------------------------------------- |
| 事件流程 | ------------------------------------- |
文本类：
············································
用例名称
前置条件：········
后置条件：·········
事件流程：
1、----------------
2、----------------
···········································
