序言
对于用例图，主要分为业务用例图和系统用例图，两者不同之处是研究对象，业务用例图的研究对象是组织，系统用例图的研究对象是系统。
我们最常用的是系统用例图，它从用户视角描述系统功能，是用户所能观察到的系统功能的模型图，帮助开发团队以一种可视化的方式理解系统的功能需求。
系统用例图的四要素：
- System（系统）：封装了自身的数据和行为，能对外提供服务的整体，用一个矩形块表示；
- Actor（参与者或执行者）：在所研究的系统外，与该系统发生功能性交互的人或其他系统，用一个小人表示；
- Use Case（用例）：系统外部可见的系统功能，对系统提供的服务进行描述，用一个椭圆表示；
- Relationship（关系）：包括执行者与用例之间的关联关系，执行者之间或用例之间的泛化关系，还有用例之间的包含关系和扩展关系，其中关联关系用一个实线箭头表示，泛化关系用一个实线空心三角箭头表示，包含关系用一个虚线箭头+<
>表示，扩展关系用一个虚线箭头+< >表示。
根据四要素，我们可以通过四步法来画系统用例图：
- 第一步：定系统；
- 第二步：找执行者；
- 第三步：添用例；
- 第四步：画关系。
定系统
第一步是定系统，通常是拖出一个巨大的矩形块，并将其命名为我们的目标系统——代码打靶服务。一个系统用例图一般只会有一个 系统，之后我们会把该系统相关的功能（用例）放置在系统内部，系统的相关方（执行者）放置在系统的左右两侧。
代码打靶服务是为打靶人员提供的一个可通过Web进行代码打靶的自动化工具。打靶人员在线浏览一段称作靶子的代码片段，然后根据规范添加标准化的评审意见，待打靶完成后提交答卷，服务会根据靶标（答案）来完成阅卷，并展示打靶结果。打靶人员根据弱项进行改进，可以有效提升Code Review能力和编码能力。
找执行者
第二步是找执行者，即在所研究的系统外，与该系统发生功能性交互的人或其他系统。
对于代码打靶服务，执行者除过打靶人员，还有管理员和用户认证服务：
- 管理员维护靶场，以便于打靶人员访问；
- 不管是打靶人员，还是管理员，都需要登陆，而登陆不是代码打靶服务的核心功能，我们可以委托用户认证服务来完成。
打靶人员是主要的执行者，我们放在左边，而将用户认证服务和管理员放在右边：
添用例
第三步是添用例，就是在系统内添加该系统所提供的功能，一般使用动宾短语来表达用例。
代码打靶服务对打靶人员提供的功能包括：
- 登录；
- 打靶；
- 提交答卷；
- 查看打靶结果。
代码打靶服务对管理员提供的功能包括：
- 登录；
- 管理靶场。
我们将识别出来的用例放在系统中：
第四步：画关系
第四步是画关系，我们按各种关系分别来阐述。
关联关系
执行者和用例之间是关联关系。在UML标准中，执行者和用例之间没有要求使用箭头，但笔者认为通过箭头可以明确表示出用例的执行方向，所以建议加上。
有的箭头是从执行者指向用例，这样的执行者称为用例的主执行者，有的箭头是从用例指向执行者，这样的执行者称之为用例的辅执行者。主执行者主动发起用例的交互，辅执行者在用例的交互中被动参与进来。
一般来说，辅执行者绝大多数都是外系统，人作为辅执行者的情况比较少，所以碰到辅执行者是人的时候要多留心，常见的错误是把信息的接收者或将来可能使用信息的人当成辅执行者。
我们举一个辅执行者是人的例子：营业员使用营业系统为顾客办卡，在用例交互过程中，需要顾客配合输入账户密码，否则办卡用例不能成功，这时顾客是合适的辅执行者。
还需要注意的是，主执行者和辅执行者是针对某个用例来说的，一个外系统可以是这个用例的辅执行者，也是可以是另外一个用例的主执行者。对于代码打靶服务来说，打靶人员和管理员都是登陆用例的主执行者，而用户认证服务是登陆用例的辅执行者。
我们给代码打靶服务画上关联关系：
泛化关系
泛化关系也可以称作继承关系，用一个实线空心箭头来表示。
执行者之间存在泛化关系。对于打靶人员来说，可以泛化为开发人员和架构师两个执行者。
用例之间也存在泛化关系。对于登录用例来说，可以泛化为扫码登录和手工输入登录两个用例。
我们给代码打靶服务画上泛化关系：
包含关系
包含是用例之间的一种关系，其中一个用例（称为基本用例）的行为包含了另一个用例（称为包含用例）的行为，用虚线箭头+<
包含关系意味着包含用例是基本用例中不可缺少的一个执行步骤，如果缺少了该包含用例，基本用例就会变得不完整。倘若熟悉面向对象设计与分析方法，可以将包含关系类比为对象之间的组合关系，如汽车与轮胎，是一种 must have 关系。
使用包含关系的两个场景：
- 当基本用例较复杂时，可以分解出一些包含用例
- 当两个或以上的基本用例存在一些重复行为时，可以提炼出一个包含用例
对于打靶人员，在打靶前先要获取靶场，所以获取靶场可以作为打靶这个基本用例的包含用例。同样，在提交答卷后，代码打靶服务只有在阅卷成功后才给予正常响应，所以阅卷可以作为提交答卷这个基本用例的包含用例。
对于管理员来说，管理靶场这个功能比较复杂：
- 一个靶场可以组合多个靶子，一个靶子可以同时被多个靶场选择，可见靶子也需要独立的生命周期管理，将管理靶子作为管理靶场这个基本用例的包含用例；
- 打靶人员打靶时，需要根据规范来添加标准化的评审意见，而每个靶子绑定的规范可能不同，即使对于相同的规范，其版本也可能会升级演进，可见规范也需要独立的生命周期管理，将管理规范作为管理靶场这个基本用例的包含用例。
我们给代码打靶服务画上包含关系：
扩展关系
扩展是用例之间的一种关系，其中一个用例（称为扩展用例）的行为增强了另一个用例（称为基本用例）的行为，用虚线箭头+<
扩展用例是对基本用例的一种补充或强化，即使没有该扩展用例，对基本用例也不会产生直接影响，基本用例自身仍然是完整的。倘若熟悉面向对象设计与分析方法，可以将扩展关系类比为对象之间的聚合关系，如汽车与车载音响，是一种 nice to have 关系。
如果一个基本用例还有其他动作，但该动作在一定条件下才执行，可以将它放在扩展用例中。
当打靶人员查看打靶结果时，如果靶标已过脱敏期，则靶标信息会附加到打靶结果中，所以展示靶标可以作为查看打靶结果这个基本用例的扩展用例。
我们给代码打靶服务画上扩展关系：
小结
用例图属于UML图的行为图类别，是一种描述业务功能的动态视图：
根据研究对象的不同，用例图分为业务用例图和系统用例图，我们平常用的比较多的是系统用例图。系统用例图包括系统、执行者、用例和关系四要素，说明谁要使用系统，以及使用这个系统干什么。系统用例图展示了一个外部用户能够观察到的系统功能模型图，帮助开发团队以一种可视化的方式理解系统的功能需求。
我们推荐使用四步法来画系统用例图：
- 第一步：定系统；
- 第二步：找执行者；
- 第三步：添用例；
- 第四步：画关系。
希望读者掌握四步法，帮助开发团队以一种可视化的方式理解系统的功能需求。