当你脑子里有一个商业案例时，你该怎么向老板介绍呢？一大段文字，或是动手写个 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
还有一些关系表示“包含”和“扩展”，比如客户在输入用户名密码后，系统需要验证登陆有效性，这个操作是每一次登陆后必然发生的用例，我们会用
<<include>>来连接这两个先后发生的事件；但是登陆“有可能”会失败，这时候系统会显示一个错误信息，我们把这种后续可能发生的用例，用<<extend>>来表示它与之前用例的关系。UML 中，“包含”和“扩展”在表现上就是虚线+箭头的形式，然后在虚线上方注释具体的关系形式。
include & extend
-
Generalization
另外一种常见的关系叫做“泛化”，也可以称作“继承”。继承在 UML 中的表现方式是实线+空心箭头。还是以我们银行 App 为例，现在的银行通常提供多种账户支付手段，你既可以从储蓄账户里支取现金，也可以从一些 T+0 的货币型基金账户扣钱；而这两种细分的支付手段，如下所示，在用例图中可以表示为通用支付用例的泛化用例：
Generalization
当然，“泛化”（或是“继承”）并不局限于用例之间，也可以是参与者继承参与者的形式，如 VIP 客户和普通客户都可以是通用客户的泛化参与者。
Extension points & Note
最后，所有 UML 视图事实上都可以加注释，专业术语叫延伸（Extension points）和批注（Note）；这两种注释性质形同，都是起说明作用：
- 延伸：通常是用例椭圆下半区加注的说明，相对来说内容较少
- 批注：是一个类似文本的图案，用虚线连接特定元素，可以附带较多文字信息
extension Points & note
小结
好了，UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景，在产品设计阶段，我们可以使用用例图为用户、系统和功能服务建立起抽象关系，以便描述产品所呈现的外部动态特征。在一些大厂中，通常由产品经理或是设计师来首先绘制 UML 用例图，再交于开发团队实现。
我们举了一个银行 App 的例子，事实上有点大了；现实开发中，一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时，也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case，然后逐步地为这些较大的功能模块画出细分 Case 的用例图。
网友评论