如何画出规范的 UML 用例图

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

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

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

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

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

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

一、如何识别正确的用例

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

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

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

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

1.1 业务用例

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

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

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

1.2 系统用例

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

1.系统

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

2.系统执行者

系统执行者的定