如果说活动图是文章是要说什么，那么用例图就是设计如何在文章中表达我们想要的说的：是几个故事，故事的主人翁是这么在故事里度过的。
对与软件，活动图让我们知道要做什么事，用例图就是让我们知道要做的事得分成几部分？怎么做？

如下图又是一个百度图：

图中就包括了我们所有的用例图构成部分: 参与者、用例、用例关系（扩展，包含，泛化）。

用例图的思路和画法

步骤：

1. 确定系统范围，即给系统命名。我们做的就是画一个大大的方块。
2. 找参与者
   a. 参与者就是和系统交互的对象。（可以是人，系统，时间，等）
   b. 如果有一个操作是系统定时发生的，就可以引出一个参与者：时间
3. 找用例
   a. 用例就是参与者和系统之间要做的交互
   b. 活动图可以帮助找用例的，相互验证可以改善两者
4. 编写用例叙述
   a.用例叙述不需要一次编辑完善，因为用例图是反复确认的过程。

约束：

5. 用例发生的顺序可以用在用例图中上下来暗示。
6. 包含关系的用例建议在原用例的右边
7. 扩展关系，泛化关系建议在原用例的下边
8. 参与者系统不用实现，但是我们要为参与者提供接口。这个在用例图中就要有所准备。
9. 尽量减少使用 扩展，泛化，包含关系。这些关系之间的关系不同的人理解起来比较模糊。
10. 包含和扩展关系应该避免达到两层。

用例控件

以下我们介绍用例图的各个属性，参考书籍【系统分析师UML用例实战】：

定义	图解	说明
参与者(actor)		指位于系统外部，在用例执行期间与系统产生交互的对象
用例(User Case)		系统对外提供的服务或功能
聚合关系(association)		参与者与用例之间的实线，表示两种之间交互
包含关系(include)		如果发现多个用例叙述中有一部分流程相同，就可以独立处理，重用。
扩展关系(extend)		在特定条件下才被额外使用的，部分独立处理就是扩展。扩展一般用于对旧功能的扩充定制化
泛化关系(generalization)		泛化可以用于参与者和用例，标识在原来的范围内有一个特殊的部分，不但有原来群体的功能，还有特色的功能。

用例描述

一份用例，单有用例图是不够的，用例图只能描述用例关系，而不能准确描述做什么，怎么运行。
这时我们需要用例叙述(use case narrative)，它可以用文件描述参与者与系统之间应该如何交互的细节。

主要流程和替代流程

主要流程：系统一切正常、没有例外的执行过程。
替代流程：对主流程的特殊情况的补充说明

替代流程既可以作为事件流程的一部分，描述在事件流程中，也可以单拆出来作为一个用例叙述描述。

用例叙述的格式，差别很大。
常见的有：

表格类：

文本类：

············································
用例名称
前置条件：········
后置条件：·········
事件流程：
1、----------------
2、----------------
···········································