第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 逻辑从营业员的大脑转到点钞机的大脑
责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了。我们画好现状的业务序列图，然后寻找改进点改进业务序列图。在改进的业务序列图上，从外部指向所研究软件系统（业务实体）的消息，可以直接映射到该系统的用例。
