一文读懂 UML 用例图

当你脑子里有一个商业案例时，你该怎么向老板介绍呢？一大段文字，或是动手写个 Demo？老板很忙，老板也不见得懂你所说的“高大上”技术，有没有那种实现成本较低但又包含较多信息的表现方式呢？有，画张图呗！

今天起再开个专题，谈谈我们开发中常用到的一些图形建模手段。前言结束，我们从 UML 视图启航。

UML Use Case 图

UML——Unified Modeling Language——统一建模语言，是业务建模阶段最常用和最重要的一种视图。由于它简单易懂，常常用于跨组织的文档或演示的说明中；这里所谓的跨组织指的不仅仅是开发部门间，而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中，第一张图一般都是用例图：是的，就是那个有“小人”的图。

用例图主要有三个部分组成：用例（Use Case）、参与者（Actor），以及它们互相间的关系（Relationship）；形式上就是用椭圆、小人，以及箭头的连线组合。

Use Case

例子

我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP，它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。

Systems

画用例图的第一步通常是拖出一个巨大的矩形块，并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System，之后我们会把所有该系统相关的是功能（“用例”）放置在系统内部，系统的相关方（“参与者”）放置在系统的左右两侧。

Banking App

Actors

第二个绘制元素就是参与者，即系统相关方，可以是人、组织、外部设备，或是其他系统。在我们这个银行案例里，该 App 的相关方有两个：就是客户（Customer）和银行（Bank）。

Actors

通常来说，一个用例图中会有两三个参与者，我们会把主要参与者放在系统左侧，次要参与者（主要参与者的回应方）放在右侧；显然我们的 App 主要是面向客户的，所以把客户放在了左边。

Use Case

第三步就是在系统内添加具体的用例，也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单，只提供如下业务：

用户登录（login）
查看余额（check balance）
转账（transfer funds）
消费（make payment）

Use Case

Relationships

第四步，我们再把参与者与用例串联起来，就是我们所说的关系（Relationships）。用例图中，关系还可以继续细分：

association

“关联”是最朴素、最通用的一种关系形式——UML 图中用实线表示。如下所示，客户在操作 App 时，能使用到登陆、查看余额、转账和交易等等操作，我们就可以简单的将客户和这几个用例通过“关联”绑定起来。再看银行方面，当客户查看余额、转账、交易时，它自然要有所回应，所以也需要将它和这三个用例“关联”起来；而登陆操作是系统自动鉴权的，因此不与银行方连接。

Relationships
include & extend

还有一些关系表示“包含”和“扩展”，比如客户在输入用户名密码后，系统需要验证登陆有效性，这个操作是每一次登陆后必然发生的用例，我们会用 <> 来连接这两个先后发生的事件；但是登陆“有可能”会失败，这时候系统会显示一个错误信息，我们把这种后续可能发生的用例，用 <> 来表示它与之前用例的关系。UML 中，“包含”和“扩展”在表现上就是虚线+箭头的形式，然后在虚线上方注释具体的关系形式。

include & extend
Generalization

另外一种常见的关系叫做“泛化”，也可以称作“继承”。继承在 UML 中的表现方式是实线+空心箭头。还是以我们银行 App 为例，现在的银行通常提供多种账户支付手段，你既可以从储蓄账户里支取现金，也可以从一些 T+0 的货币型基金账户扣钱；而这两种细分的支付手段，如下所示，在用例图中可以表示为通用支付用例的泛化用例：

Generalization

当然，“泛化”（或是“继承”）并不局限于用例之间，也可以是参与者继承参与者的形式，如 VIP 客户和普通客户都可以是通用客户的泛化参与者。