点击链接阅读原文，获取更多技术内容：如何画出规范的 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。如下：

@startumlrectangle "xx 系统" {}@enduml

内容剩余60%，完整内容可点击下方链接查看：如何画出规范的 UML 用例图-阿里云开发者社区

阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：阿里云开发者社区-云计算社区-阿里云