如何画出规范的 UML 用例图

如果你在做设计过程中有一些困惑，如：不会找用例、两个用例图分不清楚、不知道自己画的对不对。那么希望本文能帮助厘清上面几个问题，真正掌握用例图，在后面的设计中能运用的得心应手。

在做设计的时候你是否有以下困惑？

1.不会找用例：业务用例、系统用例又都是啥啊？我该如何把用例写对啊？

2.两个用例图分不清楚：业务用例图和系统用例图感觉好像啊，似乎没啥区别啊？

3.不知道自己画的对不对：照猫画虎画了个用例图，但是我也不知道画的对不对，万一评审的人也不会呢，就这样交差吧

如果你在做设计过程中有以上困惑，那么希望本文能帮助厘清上面几个问题，真正掌握用例图，在后面的设计中能运用的得心应手。

一、如何识别正确的用例

首先看用例的概念，百科上定义“用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术”。什么意思呢，这里我引用《大象：Thinking in UML》里面的一段话来解释下这个定义

这个世界的功能性体现在，首先有某人的一个愿望，这个愿望驱使人去做事并获得一个确定的结果。如果没有愿望，功能性就无从谈起。一个系统就是由各种各样的愿望组成的，换句话说，各种各样的人为着各自的目的做着各种各样的事情共同组成了一个系统。如果我们要描述一个系统的功能性需求，就要找到对这个系统有愿望的人，让他们来说明他们会在这个系统里做什么事，想要什么结果。如果所有对系统有愿望的人要做的所有事情都找全了，那这个系统的功能性就被确定下来了。

用例的一个最主要的特征是它是相对独立的。这意味着它不需要与其他用例交互而独自完成参与者的目的，也就是说用例从“功能”上说是完备的。用例本质体现了系统参与者的愿望，不能完整达到参与者愿望的不能称为用例。例如取钱是一个有效的用例，填写取款单却不是，因为完整的目的是取到钱，没有人会为了填写取款单而专门跑一趟银行的。

用例有两种，业务用例和系统用例，那么我们如何准确的识别用例呢？接下来我们就对业务用例、系统用例逐一分析。

1.1 业务用例

业务用例的定义是业务执行者希望通过和所研究组织交互获得的价值。

我们可以看到一个关键词--价值，这个价值不是指你（组织）能提供什么而是指我（执行者）想要什么，这个时候就需要把视角放在组织外部，切换到执行者上，看看他希望从组织获得什么，而不是把视角放在组织内部，看组织能提供什么。比如说以餐馆这个组织为例，其业务执行者主要是顾客，虽然餐馆可以提供零钱兑换、球赛播放、充电宝租借等服务，但是顾客来餐馆就是为了吃饭的，顾客->就餐就是餐馆的业务用例，提供就餐服务就是餐馆这个组织最大的价值。

试想一个餐馆如果不围绕“提供物美价廉的就餐服务”这一理念去经营，而是饭菜质量做的很差，提供了很多充电宝服务，那么这个餐馆的结果可想而知。

1.2 系统用例

说完业务用例我们再来看看系统用例，系统用例的定义是系统能够为执行者提供的、涉众可以接受的价值。其中的几个概念：

1.系统

封装了自身的数据和行为，能独立对外提供服务的东西才能称为系统。需要注意的系统是一个整体，系统可能会有很多子系统。比如银行转账交易时候需要做风控，如果有商家向银行售卖交易系统，那么风控这个子系统肯定是包含在整个交易系统内的，一起打包卖给银行的。

2.系统执行者

系统执行者的定义是在所研究系统外，与该系统发生功能性交互的其他系统。这里需要注意几点：

• 系统执行者一定是在系统外的，可以是人或者其他系统；
• 系统执行者必须是要和系统有交互的；
• 系统执行者不一定是业务执行者；

3.涉众

涉众是与要建设的业务系统相关的一切人和事，系统执行者也是涉众的一部分。

这里还是以餐馆为例，假如顾客是通过口头告诉服务员（不是自己扫码下单）我要点啥菜，服务员通过下单系统为顾客下单，那么研究这个下单系统可以得出：

1.系统执行者：服务员，虽然顾客作为餐馆这个组织的业务执行者，但是与下单系统直接交互的是服务员，所以服务员才是点餐系统的系统执行者；

2.涉众，这个就很多了，顾客、服务员、餐馆老板、厨师等等都是涉众，因为都是下单系统的利益关系者；

a.顾客担心自己下单没成功，等了很久不上菜；b.服务员担心没出单导致顾客投诉，自己奖金被扣；c.老板担心系统故障引起很多顾客投诉，生意受到影响；

d.厨师担心下单系统分配不合理，所有的菜都分配给自己做；

一般这个下单系统可以登录、下单，查看下单记录，这些都是下单系统的一些功能。我们再来回顾下系统用例的概念：系统用例指的是系统能够为执行者提供的、涉众可以接受的价值。那我们接下来就从每个涉众的视角分析一下对这些功能的需要情况。

	登录	下单	查看下单记录
服务员	我需要，要不然别人下错单了怪我头上咋办	I need it！	我需要，方便查看顾客菜品上齐了没
顾客	I don't care！	能不能下单直接影响我能不能吃上饭	我也需要，得打印出来我的菜单，结账时候好核对
老板	我也需要，可以看看服务员的工作情况	下单系统不能下单我买它来干啥	我需要，方便订单管理，也方便看看哪个菜客人点的最多
厨师	I don't care！	不能下单谁告诉我该做什么菜	我需要，要不然说我少做了一道菜没法解释

所以，从上可以得出下单、查看下单记录满足系统用例的概念，系统用例图如下

可以看到，和业务用例不同的是在研究系统用例时我们需要把视角切换到系统，从系统出发看看能为执行者提供什么样的、涉众都可以接受价值。

Tips:
1.用例的名字一般是动宾结构，也就是“动词+名词”，但是不严格要求的。比如“成果分析”这个行业术语没必要硬倒过来改成“分析成果”

2.老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样得到的系统用例才是是最真实的。

3.用例是可以有主执行者和辅执行者的：主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来。一般说来，辅执行者是人肉系统的情况比较少，更多时候是另一个非人智能系统。

4.主执行者和辅执行者是相对于用例来说的，“ xx 是xx用例的主/辅执行者” 是正确的，“ xx 是xx系统的主/辅执行者” 说法是错误的。

二、如何区分业务用例图和系统用例图

相信经过上面的分析，你已经发现了两个用例图的异同点，如果没有，我再贴一下两个图（便于对比下单系统就简化成下单这个一个用例），便于更直观的对比：

没错，两个图的最大的不同就是有无“/”，业务用例图在业务执行者和业务用例上是有“/”的，系统用例图在系统执行者和系统用例图上没有“/”，就是这么简单。所以现在再看到下面这个几个图，你是不是可以一眼看出其中的问题了。

三、如何用 PlantUML 画出规范的用例图

PlantUML 是一个快速创建 UML 图形的组件或者可以说是语言，通过简单和直观的语言来定义图形。其在学习成本、效率、团队协同以及维护成本上都有比较大的优势，所以推荐使用 PlantUML 来画图。

用例图画起来其实很简单，主要就是四个要素，这里以系统用例为例，四个要素分别是系统、执行者、用例、关系。

3.1 系统

系统用一个矩形块表示，在 UML语法中是rectangle。如下：

 @startuml rectangle "xx 系统" { } @enduml

3.2 执行者

执行者是用火材人表示，在 UML 语法中是actor，主要有两种写法，如下：

 @startuml '系统执行者的两种写法' actor Actor1 :Actor2: '业务执行者的两种写法' actor/ Actor3 :Actor4:/ @enduml

3.3 用例

用例是用一个椭圆表示。在UML 语法中是usecase ，业务用例和系统用例的两种写法如下：

 @startuml usecase/ " 业务用例 1" as UC1 '业务用例的第二种写法：() + 用例名称 + /' (业务用例 2)/ as UC3 usecase "系统用例 1" as UC2 '系统用例的第二种写法：() + 用例名称 ' (系统用例 2) @enduml

3.4 关系

系统用例图中关系主要有四种，分别是关联、包含、扩展、泛化。

3.4.1 关联

关联是执行者和用例之间的一种关系，一般用实线 + 实心箭头表示：

 @startuml actor Actor rectangle "xx系统" { usecase "系统用例 1" as UC1 } Actor -> UC1 @enduml

这里有一点需要注意的是，虽然表示关联关系可以直接用实线如A-B这样表示，但是在用例图中我们尽量用实线+箭头表示，否则如下：

你无法区分 Actor1 和 Actor2 谁是主执行者谁是辅执行者，又或者两个都是主执行者？加上箭头后就非常容易区分，如下

3.4.2 包含

包含是用例之间的一种关系，其中一个用例（称为基本用例）的行为包含了另一个用例（称为包含用例）的行为，用虚线箭头 + <<include>>表示，箭头指向包含用例。

包含关系意味着包含用例是基本用例中不可缺少的一个执行步骤，如果缺少了该包含用例，基本用例就会变得不完整，可类比类图中对象之间的组合关系。使用包含关系的两个场景：

• 当基本用例较复杂时，可以分解出一些包含用例；
• 当两个或以上的基本用例存在一些重复行为时，可以提炼出一个包含用例；

 @startuml '加入下面代码指定方向，使 UML 从左往右更直观' left to right direction actor Actor rectangle "xx系统" { usecase "基本用例" as UC1 usecase "包含用例 1" as UC2 usecase "包含用例 2" as UC3 } Actor --> UC1 UC1 ..> UC2 : <<include>> UC1 ..> UC3 : <<include>> @enduml

上面我用了Actor --> UC1、UC1 ..> UC2，有兴趣的可以换成->、.>看看效果

3.4.3 扩展关系

扩展是用例之间的一种关系，其中一个用例（称为扩展用例）的行为增强了另一个用例（称为基本用例）的行为，用虚线箭头 + <<extend>>表示，箭头指向基本用例。

扩展用例是对基本用例的一种补充或强化，即使没有该扩展用例，对基本用例也不会产生直接影响，基本用例自身仍然是完整的。也就是说扩展用例是基本用例的一种可能的补充，如购买运费险就是对下单这一用例的扩展，买不买运费险都不影响下单。

 @startuml left to right direction actor Actor rectangle "xx系统" { usecase "基本用例" as UC1 usecase "扩展用例" as UC2 } Actor --> UC1 UC1 <.. UC2 : <<extend>> @enduml

3.4.4 泛化

泛化关系也可以称作继承关系（类比类图中的泛化），用一个实线 + 空心箭头来表示，可以表示执行者间的关系也可以表示用例之间的关系。

 @startuml left to right direction actor Actor rectangle "xx系统" { usecase "支付" as UC1 usecase "微信支付" as UC2 usecase "支付宝支付" as UC3 } Actor --> UC1 UC1 <|-- UC2 UC1 <|-- UC3 @enduml

四、一个案例

这里我们以某银行的 App 为例，作为银行的一个系统我们对其进行分析：

1.系统：那自然是这个 App

2.系统执行者

a.主执行者：一般来银行办业务的客户都是主执行者，包括个人用户和企业用户；

b.辅执行者：银行，用户在 App 办理的所有业务都需要银行来配合执行；

3.系统用例：作为银行的线上业务，包含转账、查询余额、理财、贷款。

4.关系：这里需要注意的是转账过多有可能会超过限额，这个时候会提示超限；在办贷款业务之前，银行肯定会对用户的资产进行评估，这样才能决定其贷款额度。

 @startuml left to right direction actor 客户 as Actor actor 银行 as Actor2 rectangle "某银行App" { usecase "转账" as UC1 usecase "查询余额" as UC2 usecase "理财" as UC3 usecase "贷款" as UC4 usecase "评估资产" as UC5 usecase "提示限额" as UC6 } Actor <|-up- 个人用户 Actor <|-up- 企业用户 Actor --> UC1 Actor --> UC2 Actor --> UC3 Actor --> UC4 UC1 ----> Actor2 UC2 ----> Actor2 UC3 ----> Actor2 UC4 ----> Actor2 UC4 .left.> UC5 :<<include>> UC1 <.down. UC6 :<<extend>> @enduml

整体用例图如下：

作者 | 夜合

原文链接

本文为阿里云原创内容，未经允许不得转载。