第3章 业务建模 之 业务用例图
一样的月光，一样的照着新店溪
《一样的月光》；词：吴念真、罗大佑，曲：李寿全，唱：苏芮；1982
3.1 软件是组织的零件
有了愿景，我们知道老大对他所代表的组织现状的某些指标不满意。接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模（business modeling）的主要内容。
“业务建模”这个名字其实起得不好，应该更名为“组织建模”。出于对过去叫法的尊重，本书依然称为“业务建模”。
| 含糊的“业务” “业务”这个词在软件开发团队中使用很频繁,例如“我是一名业务架构师”、“我们要了解业务”等等，但是话中的“业务”具体指什么，往往说话的人未必理解。 有时候“业务”指“核心域知识”。开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：我懂且我感兴趣→技术；我懂且不感兴趣→业务；我不懂且感兴趣→高科技；我不懂且不感兴趣→忽悠。 有时候“业务”指“组织级别的知识”。例如“业务建模”、“业务用例”、“业务流程”说的就是组织级别的知识。 |
对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。软件系统只是组织的一个零件。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。为了让组织更好地对外提供价值，不一定要开发软件，有时换人更管用。也就是说，不是引进新的软件系统，而是引进新的人脑系统。和一套软件系统的价格相比，也许雇用一名高级员工花费更多。
开发人员有时会有意无意把自己的系统想得太重要，还喜欢起××云平台等很牛的名字，以为没有他们开发的系统，组织就玩不转了。有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。我问道：难道银行以前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其实想想就知道，银行已经成立多少年，该公司才成立几年？所以，为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”，意思是这个零件和组织厕所里的马桶没有本质区别。
开发团队经常发现需求 “容易变化”。根源之一是需求的来路不正，没有把系统当作一个零件放在组织中来看，靠拍脑袋得出需求，导致得到的系统需求是错的。系统投入使用后，发现和组织的其他零件格格不入，自然要改。“需求变化剧烈”是一个假象，真正的需求没有变，只不过一开始得到的需求是假的。如果能正确运用业务建模技能，“需求变化”会消于无形。
可以从内外两个方面来研究组织。从外部看，组织是一些价值的集合，我们可以用业务用例图表示；从内部看，组织是一些系统的集合，我们可以用业务序列图来表示。
图3-1 组织的外观和内观
3.2 识别业务执行者
3.2.1 业务执行者（Business Actor）
以某组织为研究对象，在该组织之外和该组织交互的组织（人群或机构）就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行者。
以一家商业银行为研究对象，观察在它边界之外和它打交道的人群或机构，可以看到储户来存钱，企业来贷款，人民银行要对它作监管…。这些就是该商业银行的执行者。如图3-2所示。
图3-2 业务执行者
业务执行者的图标是一个小人，头上有一道斜杠，这个带斜杠的小人实际上是一个执行者的构造型<<Business Actor>>的图形表示，Rational工具和EA里都有。如果您使用的UML工具没有这个图形，可以用执行者的小人图标加上文本构造型<<Business Actor>>取代，或者不加构造型也无所谓，因为边界框已经表明了研究对象是一个组织，它的执行者自然是业务执行者。
3.2.2 业务工人和业务实体
组织内的人称为业务工人（Business Worker），例如某商业银行里面的营业员。业务执行者和业务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的服务对象，一个是组织可以替换的零件。
*经常有人会提到在家上班、在客户处上班、某些岗位人员的工资和保险由外包公司负责等等“特殊情况”。 其实，组织内外的边界是以责任划分，而不是物理位置。这些情况没有什么特别。关于责任的边界，第五章会再详细讨论。
业务工人是可以被替换的人脑零件，它可能会被其他业务工人替换，但更有可能被业务实体（Business Entity）替换。业务实体是组织中的非人智能系统，例如银行的取款机、点钞机、营业系统。
在没有点钞机的时代，储户拿着一叠钞票到银行存钱，营业员需要凭着手感（界面层）一张张数，触摸信号传到大脑（核心域层），大脑要很快判断钞票的真伪和计数。验钞、计数的逻辑封装在营业员的大脑里，营业员非常累，而且营业员要有经验，小白是干不了的。这样，人力成本高了很多。
有了点钞机，营业员只需要把整叠钞票放进点钞机过一下，点钞机会负责验钞和计数。也就是说，验钞和计数的逻辑从人脑转移到了点钞机的大脑，如图3-3所示。营业员轻松了，或者说，银行也就不需要那么多有经验的营业员了。许多信息化程度很高的领域，绝大多数领域逻辑目前已经运行在业务实体中，业务工人主要负责输入信息。银行所属的金融领域就是如此。
图3-3 逻辑从营业员的大脑转到点钞机的大脑
责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了——我们画好现状的业务序列图，然后寻找改进点改进业务序列图。在改进的业务序列图上，从外部指向所研究软件系统（业务实体）的消息，可以直接映射到该系统的用例。如图3-4所示。
图3-4 改进业务序列图，映射系统用例
业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。在识别业务执行者时，不需要画业务工人和业务实体。
在接下来画业务用例的实现——业务序列图的时候，将业务工人和业务实体作为类（Class）的一个构造型，放在名为“业务对象”的包里。和业务执行者一样，如果您使用的工具没有<<Business Worker>>和<<Business Entity>>构造型，可以自己造，或者干脆不要构造型直接用类表示。背后的思想是一样的：类之间通过协作实现用例。组织的业务工人和业务实体协作完成业务用例，系统的类协作完成系统用例。
3.3.3 识别业务执行者
把观察的焦点对准组织的边界，看看边界外有哪些人群或机构会和它交互，交互的姿态可以是主动的，也可以是被动的；交互的形式可以是面对面，也可以是发邮件、发微信……。这些外部人群或机构就是所研究组织的执行者。
这里要注意的是，作为观察者的建模人员本身是一个人脑系统，所以在观察组织边界时，直觉上观察到的不是组织之间的交互，而是组织派出的系统之间的交互，但是一定要把它理解成组织之间的交互，因为谈论业务执行者时，研究对象是一个组织，和所研究组织对应的外部对应物——业务执行者也应该是一个组织。
| 二维生命观察三维宇宙，三维生命观察四维宇宙，同样难度很大。 |
例如，以某国税局为研究对象，可以观察到企业财务人员到国税局报税，但是业务执行者不是企业财务人员，而是企业。也许某个时期，企业财务人员和国税局窗口人员交互；后来，企业财务人员和国税系统交互；再后来，企业系统和国税系统交互。不管观察到哪两个系统交互，从组织的抽象级别，都应该理解为企业和国税局这两个机构之间的交互，如图3-5。
图3-5 系统交互背后的机构交互
同一个机构内部也是如此。如果以一个部门为研究对象，即使观察到的是两个员工之间的交互，也应该找到现象背后的部门之间的交互，如图3-6所示。
图3-6 部门对部门，一致的抽象级别
有的时候，个人的背后不是机构而是人群。如图3-7所示，参与“组织晚会”用例时，员工并不代表他所在的部门，只是作为员工人群的一份子。
图3-7 个人的背后也可能是人群
如果您之前阅读过一些用例相关的书籍或文章，可能知道“系统定时发生”的事件会被提炼成“时间”这个外系统作为主执行者的系统用例。不过，如果研究对象是一个组织，“时间”作为组织的执行者是不合适的，应该把时间看作某个外部组织派来的一个接口系统，参见图3-8的水文站定期上报监测数据的例子。
图3-8 时间也是系统，不能和组织并列
扫码或访问http://www.umlchina.com/book/quiz3_1.htm完成在线测试，做到全对以获得答案。
| 1. 卖饮料有不同吆喝方法，对应了软件开发的工作流，请为以下a) b) c)找出合适的对应选项。 a)男程序员快来买啊！我可以喝，而且味道不错，保质期又长，便于携带… b)男程序员快来买啊！喝了我，老板月月给你加薪，美女疯狂倒追你！ c)男程序员快来买啊！我这里面有糖、磷酸、咖啡因…… A) 业务建模是a，需求是b，分析设计是c。 B) 业务建模是a，需求是c，分析设计是b。 C) 业务建模是b，需求是a，分析设计是c。 D) 业务建模是b，需求是c，分析设计是a。 E) 业务建模是c，需求是a，分析设计是b。 F) 业务建模是c，需求是b，分析设计是a。 |
| 2. 从什么年代开始，银行、政府、商店等机构内部有大量的智能系统？ A) 1980年代 B) 1970年代 C) 1960年代 D) 早于1900年 |
| 3. 以下不能作为业务建模研究对象的是 A) 屌丝 B) 微信 C) 八天连锁酒店有限公司 D) JZ县城管大队 |
| 4. 一个组织，从外面看是______的集合，从里面看是_______的集合。 A) 价值；系统 B) 业务执行者，业务用例 C) 业务执行者；业务工人 D) 功能；性能 |
| 5. 以下说法正确的是 A) 业务执行者在系统外面，业务工人在系统里面。 B) 业务执行者在系统里面，业务工人在系统外面。 C) 业务工人不能取代业务实体的责任。 D) 业务工人可以取代业务工人的责任。 |
| 6. 以医院为研究对象，针对以下概念正确的说法是（多选）： 护士、患者、CT扫描仪、医生、保安、医院信息系统、卫生局 A) 卫生局是业务执行者。 B) 因为保安的社保关系不在医院，保安不是业务工人。 C) CT扫描仪是业务实体。 D) 医生是业务执行者。 |
| 7. 以一家超市为研究对象做业务建模。建模人员观察到：顾客到超市买东西，找收银员结账；收银员会使用超市管理系统来结账，结账时超市管理系统会请求银行系统完成交易。上面提到的名词中，属于超市的执行者的是（可多选）： A) 收银员 B) 顾客 C) 超市管理系统 D) 银行系统 E) 银行 |
3.3.4 识别业务用例
业务用例指业务执行者希望通过和所研究组织交互获得的价值。以上面提到的某商业银行为例，储户和银行打交道的目的可能有存款、取款、转账，所以银行针对储户的用例如下：
图3-9 某商业银行针对储户的用例
如果穿越回三百年前，图3-9依然适用。业务用例代表组织的本质价值，很难变化，变化的是业务用例的实现——业务流程。三百年前，银行要实现“储户→存款”的用例，需要许多人脑系统（业务工人）一起协作，现在则变成了少数人脑系统（业务工人）和许多电脑系统（业务实体）之间的协作。
图3-10 用例没变，实现用例的零件变了
3.3.4.1 正确理解价值
用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点，买卖的平衡点。
例如，以医院为研究对象，“患者→挂号”不是用例，因为挂号不是患者对医院的期望和医院对患者的承诺的平衡点。如果挂到了号后医院的服务到此为止，患者到医院来时心中的期望没有得到满足。或者说，医院这个研究对象能承诺向患者提供的价值不是挂号，而是看病。
或者可以这样思考：医院能这样叫卖自己吗？“来呀来呀，我这家医院能挂号呀！”，患者一听，“哇，真棒耶，这医院能挂号耶，我赶紧去！”其实患者巴不得不挂号也能看病，只不过人太多了，需要拿号排队。
如果把研究对象改为医院挂号室，“患者→挂号”就是合适的用例。患者对挂号室的期望是能挂到号，不会因为挂号室没帮他看病就破口大骂。挂号室对他的承诺也就是能给他号。
以上提到的正确和错误的用例图如图3-11所示：
图3-11 期望和承诺的平衡
如果患者在窗口挂到的是明天的号，他离开医院回家了，明天再来医院就诊，那么挂号算不算医院的一个用例呢？仍然是不算的，因为患者心中仍然在期待，这件事情没有完。
（如果患者在家里使用医院的微信公众号挂到了第二天的号，明天再去医院就诊，那么医院的用例图会有变化吗？请读者使用本章前面已经提到的知识点自行解答。）
业务用例是组织对组织的服务，相对于系统为系统提供的服务（系统用例）来说，所需要的时间是比较长的，不能把用例实现过程中的某个交互片段当成用例。如图3-12所示，企业和工商局打交道变更地址的过程中，可能要发生多次交互，但是用例只有一个。
图3-12 业务用例持续的时间比较长
系统用例的持续时间比较短，如图3-13所示。一个典型的执行者离开系统去干别的事情时，如果他心里认为得到目前的结果不算白做，那就可以把它作为一个系统用例。有一些词汇带有浓浓的“系统”味道，例如新增、查看，录入，查询、修改、配置……，带有这些词汇的用例，很可能不是组织提供的价值，而是某系统提供的价值。
图3-13 工商系统的用例
3.3.4.2 识别业务用例的思路和常犯错误
识别业务用例有两条思路：一条是从业务执行者开始，思考业务执行者和组织交互的目的；另一条是通过观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。第一条路线是主要的，第二条路线用于补漏。
图3-14 识别业务用例的两条路线
识别业务用例本来应该是很简单的事情，但是，许多程序员出身的需求人员受到了以往工作经历的影响，往往把简单的事情变得复杂。试列举一些常见的错误如下：
错误一：把业务工人的行为当作业务用例。
例如，以医院为研究对象，有人会画出图3-15：
图3-15 业务工人的行为当作业务用例
这种情况的出现往往和没有注明研究对象有关。如果用边界框注明了研究对象，如图3-16，建模人员就会警觉，收费人员和医生在医院里面，是业务工人，不是业务执行者。
图3-16 边界框有助于识别内外
不过，可能又会有人害怕“收费人员收费”“医生诊治”的信息此时不表达出来就忘记了。就像谈恋爱时迫不及待要表白一样，他千方百计都要赶紧把这个信息表达出来，否则以后就没机会了，所以又会有图3-17，而且他还有理由：难道医院不要收费和诊治吗？收费和诊治不是医院的本质吗？
图3-17 业务工人的业务用例
这里反映了建模人员常见的一个问题：分不清问题和问题的解决方案。
医院确实要收费，但图3-17说的不是收费，而是收费的一个解决方案——收费人员人脑系统坐在那里收费，背后的真实问题是医院的老板要通过医院来赚钱，至于钱怎么收上来的，是收费人员这个业务工人坐在那里收钞票，还是各种业务实体互相协作来达到收费的目的，老板是无所谓的。
同理，“医生诊治”也只是解决方案。患者要的是把病治好，治疗的过程短，不痛苦，没有后遗症，收费还便宜，并不在意他的病是医生动手术治好的，还是有个很牛的仪器给照好的。医院老板巴不得不用雇佣那么多收费人员和医生，照样为患者看病赚钱，只不过目前做不到而已。
或者这样思考，医院的成立不是为了容纳收费人员和医生，以解决本地户口的下岗人员和医科毕业生的就业问题，是患者要看病、老板想赚钱，于是才有了医院。
业务用例是为业务执行者服务，不是为业务工人服务。这不是什么规范问题，背后有它的道理。要从业务执行者的角度去看，才能看得清楚组织的本质价值。
像收费人员这样的人脑零件，以现在的IT技术替换掉没有问题，不过像医生这样读了很多年书，经过许多年专业训练的人脑零件，替换起来更难一些。
即使现在医生的地位还比较稳固，他的责任也已经被替换了一部分。过去去看病，说：“医生我咳嗽。”，医生会让我们伸出舌头看一看，听诊器放胸口听一听，躺在床上按一按。现在呢，医生抬头看一眼，啪啪就开单，“去照个××吧”，把检查的责任转移给仪器了。
几年前人们还认为人工智能攻克围棋还需要很久，现在AlphaGo已经使这个目标变为现实，也许不久的将来，各行各业打酱油的从业者将会被人工智能代替。
错误二：业务用例随待引入系统伸缩。
有的建模人员把臆想的待引入系统的用例直接当成业务用例画出来，如图3-18。
图3-18 将臆想的系统用例当成业务用例
根据前面讲的知识要点，一看图3-18右侧，护士在组织边界外面，就知道不对了。但是，要求建模人员按照业务用例的定义做时，有人就会说：我的系统就是这个功能，我已经知道了，我还要考虑其他东西干什么？
这是一种“致命的自负”。正是因为很多情况下拍脑袋得到的是错误的需求，所以才要做业务建模，从组织的价值来推导系统应该具备什么价值才会对组织有帮助，这样系统才能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？
就像考试做题一样，如果已经知道答案是A，那就不用再花时间计算了。问题在于，我们很多时候是不知道的，不过瞎蒙也有25%的概率蒙对，然后就拿出来当作成功经验宣传，碰上掌握了方法的竞争对手，分分钟被虐成渣。
好了，现在建模人员知道护士在所研究组织边界里面，不能作为业务执行者了，但是又有可能还是受待引入系统的影响，导致组织的价值随着所引入系统的价值大小伸缩，如图3-19。
图3-19 组织的价值受所引入系统影响
因为建模人员臆想待引入系统的主要功能是审核医嘱，所以画出的图中，医院或护士站就变成了一个“审核医嘱”的机构。
碰到这种情况，我通常都会用开玩笑的口气说，幸亏你们团队不是卖马桶的，否则就有可能得到图3-20：
图3-20 医院变成了上厕所的机构
即使真的是卖马桶的，想要打败其他对手把马桶成功卖给医院，也依然需要研究医院的流程，找到马桶适合改进的改进点，才能打造出为医院量身定制的贴心马桶，如图3-21。
图3-21 马桶也要从医院的流程找需求
错误三：把害怕漏掉的扩展路径片段提升为业务用例
如果待改进的流程片段位于业务用例的主流程中，建模人员会比较安心，因为他预计往下建模时，他想要看到的部分肯定会出现；如果待改进的流程片段位于业务用例的支撑流程中，建模人员可能就慌了，害怕自己关心的部分漏掉了，于是为了让自己安心，把自己关注的片段提升为组织的用例。
还是用上文的例子，医院的用例是“患者→看病”，但是下一步待改进的可能是药剂科的药师盘点药品的流程片段，而这个看起来好像不能从患者看病的流程里找出来，所以建模人员会担心，然后画出图3-22左侧。也许画完后建模人员会意识到不妥，特地把研究范围缩小一些，得到图3-22右侧。左右两个图药师都在药剂科外面，都是错的。
图3-22 把关注的流程片段当成组织的用例
用例下面除了有一条基本路径，还有若干条扩展路径。扩展路径的目的是预防或应对基本路径上发生的意外。
以上面的“药师盘点药品”为例，如果药师不盘点，会导致真实库存和账面库存有差距，“患者→看病”的基本路径进行到取药片段时，才发现其实某种药品已经没有库存或者现有库存药品是坏的，往“患者→看病”的成功目标行进的道路上遇到了阻碍。同理，医院里为什么有保洁员打扫卫生？为什么内部要花时间搞团队建设？都应该从“患者→看病”的高度来看。
业务用例代表从组织视角看问题的高度。一个组织内部的所有零件，都应该从组织价值的角度来认识。不用说员工或软件系统这样的重要零件，就连应该用什么颜色的桌子、什么品牌的电脑、盖什么形状的大楼，都不是随意的。
电影《国产凌凌漆》[周 1994]中，陈司令对凌凌漆说，就算是一张卫生纸、一条内裤，国家都有它的用途。话虽夸张，却有道理，一草一木都要服从组织的大局。
当前关注的改进点有时是在基本路径中，有时是在扩展路径中，都不应该影响业务用例图。如果能比较确定和愿景相关的片段的位置，那就不必先画基本路径，再画扩展路径，画了一大堆才轮到待改进的片段，就直接在用例下面画该片段即可，如图3-23。
图3-23 用例下面的流程片段
就像看病一样，患者说“医生我这两天咳得厉害”（愿景：降低咳嗽的频繁程度到正常人水平），医生从常理判断可能原因有：咽喉发炎、支气管发炎、肺部发炎等，决定先给最可能的部位拍片（建模愿景相关的片段）。当然，如果拍片发现前面这些推断都是错的，也许就需要来个全身扫描了。