UML-用例图

[luhui]

概念

先看官网怎么说的：

Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.

简单来说，用例图是用于描述行为的图，他用于描述一系列角色（actors）与用例（use case）之间的关系。因此，通过用例图，我们能够知道系统中涉及到的角色、以及每个角色都能通过这个系统做什么。
一般我们描述事件，可能会使用 5W1H 的方式来表达，对应来看，用例图便是从 who&what 的维度来表达设计。

使用场景

从概念我们得知，用例图用于描述系统中的角色对应的行为，因此比较适合通过用例图来表达产品需求，确定系统边界。
用例图和用户故事（user story）表达的模式是相似的，作为 xx （actor），我希望通过 xx 方式（use case），以便我可以 xx （用户原始诉求）。
当然，在表达产品需求时，用户故事和用例并不完全是一一对应的关系，我们可能会对用例进行归类，不过这就是需求分析的维度了，不在这篇文章阐述的范围。

用例图元素

元素的具体表达方式，请参考官网，本篇文章重点在于说明每个元素具体的含义

角色（actor）

An actor is behaviored classifier which specifies a role played by an external entity that interacts with the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the subject.

角色代表的是直接或间接使用这个系统的用户或系统、设备。在面向用户的产品中，角色可能是人，比如学生，在面向技术的产品中（比如 broker，mq），则角色可能是客户端，业务系统。

在实践的过程中，我碰到一些同学会把具体的人名作为将角色，比如王大胖，这是不正确的。actor 表示的是 role（角色），即一类用户的标识，比如学生、厨师、客户端、系统等等。

用例（use case）

Use cases allow to capture requirements of systems under design or consideration, describe functionality provided by those systems, and determine the requirements the systems pose on their environment.

用例就是角色能够执行的动作，描述了角色能够怎么使用我们提供的系统。他表达的是一个系统的功能，比如用户注册、添加购物车、支付等等。

包含关系（include relationship）

Use case include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case.

包含关系，顾名思义，即表达一个用例（基础用例）包含另一个用例（新增用例）的场景。一般是某个用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。

强化表达子用例的例子：

复用用例的例子：

扩展关系 （extend relationship）

Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case.

扩展关系表明的是一个用例（基础用例）执行过程中的可选过程，基础用例本身可以完整的场景，扩展用例作为一个**可选（optional）**�过程插入到基础用例中。比如用户注册的场景，注册本身可以作为一个单独的用例，但是在注册的过程中，用户可以寻求帮助，查看注册指引，那么获取帮助就是一个可选的流程，整个用例场景我们就可以这么表达：

注意，**可选（optional）**是一个很主观的描述，比如丰巢的取件过程，取件是一个基础用例，取件时，如果快递放置的时间长，可能要扫码支付费用，那么支付费用这个用例到底是包含用例还是扩展用例，则取决于产品定义，是 optional 还是 alternative，直观的来看，就是看弹出支付窗口时，能不能跳过，如果能跳过，则是 optional，属于扩展用例，否则属于包含用例

小技巧

神秘的 7

<<金字塔原理>>里提到的说法，大脑的短期记忆无法一次容纳7个以上的记忆项目，当发现需要处理项目超过7个时，应该对其进行归纳，方便记忆。

在用例图上也适用，当一个角色能够进行超过 7 个的用例时，应该对用例进行归纳，利用归纳法、包含关系、扩展关系来优化用例图的表达

用例完整性

我们通常使用用例图来表达需求，在表达之后，应该把用例图与产品经理的用户故事，或者交互原型等等由相关方输出的结果进行比对，确认我们分析的需求是否完整，是否能够覆盖需求。

思考题

通常我们拿到的需求是产品经理的用户故事，或者交互设计的交互稿，我们要如何根据这些具象、零散的需求，整理成易于阅读的用例图呢？