《一样的月光》；词：吴念真、罗大佑，曲：李寿全，唱：苏芮；1982
有了愿景，我们知道老大对他所代表的组织现状的某些指标不满意。接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模（businessmodeling）的主要内容。
“业务建模”这个名字其实起得不好，应该更名为“组织建模”。出于对过去叫法的尊重，本书依然称为“业务建模”。
含糊的“业务”
“业务”这个词在软件开发团队中使用很频繁,例如“我是一名业务架构师”、“我们要了解业务”等等，但是往往说话的人未必真的理解话中的“业务”具体指什么。
有时候“业务”指“核心域知识”。开发人员假装谦虚“我是做技术的，业务不太懂唉”，就是这个意思。甚至有的开发人员在潜意识里是这样划分的：我懂且我感兴趣→技术；我懂且不感兴趣→业务；我不懂且感兴趣→高科技；我不懂且不感兴趣→忽悠。
有时候“业务”指“组织级别的知识”。例如“业务建模”、“业务用例”、“业务流程”说的就是组织级别的知识。
对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。软件系统只是组织的一个零件。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。为了让组织更好地对外提供价值，不一定要开发软件，有时换人更管用。也就是说，不是引进新的软件系统，而是引进新的人脑系统。
开发人员有时会有意无意把自己的系统想得太重要，还喜欢起××云平台等很牛的名字，以为没有他们开发的系统，组织就玩不转了。有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。我问道：难道银行以前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其实想想就知道，银行已经成立多少年，该公司才成立几年？所以，为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”，意思是这个零件和组织厕所里的马桶没有本质区别。
开发团队经常发现需求“容易变化”。根源之一是需求的来路不正，没有把系统当作一个零件放在组织中来看，靠拍脑袋得出需求，导致得到的系统需求是错的。系统投入使用后，发现和组织的其他零件格格不入，自然要改。“需求变化剧烈”是一个假象，真正的需求没有变，只不过一开始得到的需求是假的。如果能正确运用业务建模技能，“需求变化”会消于无形。
可以从内外两个方面来研究组织。从外部看，组织是一些价值的集合，我们可以用业务用例图表示；从内部看，组织是一些系统的集合，我们可以用业务序列图来表示。
图3-1组织的外观和内观
3.2.1业务执行者（BusinessActor）
以某组织为研究对象，在该组织之外和该组织交互的组织（人群或机构）就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行者。
以一家商业银行为研究对象，观察在它边界之外和它打交道的人群或机构，可以看到储户来存钱，企业来贷款，人民银行要对它作监管…。这些就是该商业银行的执行者。如图3-2所示。
图3-2业务执行者
业务执行者的图标是一个小人，头上有一道斜杠，这个带斜杠的小人实际上是一个执行者的构造型<
3.2.2业务工人和业务实体
组织内的人称为业务工人（BusinessWorker），例如某商业银行里面的营业员。业务执行者和业务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的服务对象，一个是组织可以替换的零件。
*经常有人会提到在家上班、在客户处上班、某些岗位人员的工资和保险由外包公司负责等等“特殊情况”。其实，组织内外的边界是以责任划分，而不是物理位置。这些情况没有什么特别。关于责任的边界，第五章会再详细讨论。
业务工人是可以被替换的人脑零件，它可能会被其他业务工人替换，但更有可能被业务实体（BusinessEntity）替换。业务实体是组织中的非人智能系统，例如银行的取款机、点钞机、营业系统。
在没有点钞机的时代，储户拿着一叠钞票到银行存钱，营业员需要凭着手感（界面层）一张张数，触摸信号传到大脑（核心域层），大脑要很快判断钞票的真伪和计数。验钞、计数的逻辑封装在营业员的大脑里，营业员非常累，而且营业员要有经验，小白是干不了的。这样，人力成本高了很多。
有了点钞机，营业员只需要把整叠钞票放进点钞机过一下，点钞机会负责验钞和计数。也就是说，验钞和计数的逻辑从人脑转移到了点钞机的大脑，如图3-3所示。营业员轻松了，或者说，银行也就不需要那么多有经验的营业员了。许多信息化程度很高的领域，绝大多数领域逻辑目前已经运行在业务实体中，业务工人主要负责输入信息。银行所属的金融领域就是如此。
图3-3逻辑从营业员的大脑转到点钞机的大脑
责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需求的思路就出来了——我们画好现状的业务序列图，然后寻找改进点改进业务序列图。在改进的业务序列图上，从外部指向所研究软件系统（业务实体）的消息，可以直接映射到该系统的用例。如图3-4所示。
图3-4改进业务序列图，映射系统用例
业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。在识别业务执行者时，不需要画业务工人和业务实体。
在接下来画业务用例的实现——业务序列图的时候，将业务工人和业务实体作为类（Class）的一个构造型，放在名为“业务对象”的包里。和业务执行者一样，如果您使用的工具没有<
3.3.3识别业务执行者
这里要注意的是，作为观察者的建模人员本身是一个人脑系统，所以在观察组织边界时，直觉上观察到的不是组织之间的交互，而是组织派出的系统之间的交互，但是一定要把它理解成组织之间的交互，因为谈论业务执行者时，研究对象是一个组织，和所研究组织对应的外部对应物——业务执行者也应该是一个组织。
二维生命观察三维宇宙，三维生命观察四维宇宙，同样难度很大。
例如，以某国税局为研究对象，可以观察到企业财务人员到国税局报税，但是业务执行者不是企业财务人员，而是企业。也许某个时期，企业财务人员和国税局窗口人员交互；后来，企业财务人员和国税系统交互；再后来，企业系统和国税系统交互。不管观察到哪两个系统交互，从组织的抽象级别，都应该理解为企业和国税局这两个机构之间的交互，如图3-5。
图3-5系统交互背后的机构交互
同一个机构内部也是如此。如果以一个部门为研究对象，即使观察到的是两个员工之间的交互，也应该找到现象背后的部门之间的交互，如图3-6所示。
图3-6部门对部门，一致的抽象级别
有的时候，个人的背后不是机构而是人群。如图3-7所示，参与“组织晚会”用例时，员工并不代表他所在的部门，只是作为员工人群的一份子。
图3-7个人的背后也可能是人群
在图3-6和3-7中，有箭头从执行者指向用例，也有箭头从用例指向执行者。前一种执行者称为用例的主执行者，后一种执行者称为用例的辅助执行者。例如，图3-6右侧可以这样解读：营销部找产品部帮忙规划产品，产品部仅靠自己的力量不足以完成，需要找研发部帮忙。或者这样解读：营销部向产品部“购买”服务，产品部向研发部“购买”服务。
1.卖饮料有不同吆喝方法，对应了软件开发的工作流，请为以下a)b)c)找出合适的对应选项。
a)男程序员快来买啊！我可以喝，而且味道不错，保质期又长，便于携带…
b)男程序员快来买啊！喝了我，老板月月给你加薪，美女疯狂倒追你！
c)男程序员快来买啊！我这里面有糖、磷酸、咖啡因……
2.从什么年代开始，银行、政府、商店等机构内部有大量的智能系统？
3.以下不能作为业务建模研究对象的是
4.一个组织，从外面看是______的集合，从里面看是_______的集合。
5.以下说法正确的是
6.以医院为研究对象，针对以下概念正确的说法是（多选）：
护士、患者、CT扫描仪、医生、保安、医院信息系统、卫生局
7.以一家超市为研究对象做业务建模。建模人员观察到：顾客到超市买东西，找收银员结账；收银员会使用超市管理系统来结账，结账时超市管理系统会请求银行系统完成交易。上面提到的名词中，属于超市的执行者的是（可多选）：
7.针对以下研究对象，财务人员最有可能是业务执行者的是____________。
业务用例指业务执行者希望通过和所研究组织交互获得的价值。以上面提到的某商业银行为例，储户和银行打交道的目的可能有存款、取款、转账，所以银行针对储户的用例如下：
图3-9某商业银行针对储户的用例
和业务执行者一样，业务用例上有个斜杠，表示这是组织的用例。如果工具不提供这个图标，处理方法参照业务执行者。
如果穿越回三百年前，图3-9依然适用。业务用例代表组织的本质价值，很难变化，变化的是业务用例的实现——业务流程。三百年前，银行要实现“储户→存款”的用例，需要许多人脑系统（业务工人）一起协作，现在则变成了少数人脑系统（业务工人）和许多电脑系统（业务实体）之间的协作。
图3-10用例没变，实现用例的零件变了
业务用例刷新了业务流程的概念。我们把业务流程看作是业务用例的实现，将其组织在业务用例的下面。组织内部之所以有业务流程，是因为要实现业务用例。组织里发生的一切都是为了给业务执行者提供价值。
这样的思路对改进业务流程有非常大的帮助：先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值，如图3-11。
图3-11从价值出发重新构造业务流程
业务用例是组织的价值，不会因为某个人脑系统或电脑系统的存在或消失而改变。所以，“这个系统的业务用例是什么”这样的说法是错误的。
3.3.1正确理解价值
用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点，买卖的平衡点。
例如，以医院为研究对象，“患者→挂号”不是用例，因为挂号不是患者对医院的期望和医院对患者的承诺的平衡点。如果挂到了号后医院的服务到此为止，患者到医院来时心中的期望没有得到满足。或者说，医院这个研究对象能承诺向患者提供的价值不是挂号，而是看病。
或者可以这样思考：医院能这样叫卖自己吗？“来呀来呀，我这家医院能挂号呀！”，患者一听，“哇，真棒耶，这医院能挂号耶，我赶紧去！”其实患者巴不得不挂号也能看病，只不过人太多了，需要拿号排队。
如果把研究对象改为医院挂号室，“患者→挂号”就是合适的用例。患者对挂号室的期望是能挂到号，不会因为挂号室没帮他看病就破口大骂。挂号室对他的承诺也就是能给他号。
以上提到的正确和错误的用例图如图3-12所示：
图3-12期望和承诺的平衡
如果患者在窗口挂到的是明天的号，他离开医院回家了，明天再来医院就诊，那么挂号算不算医院的一个用例呢？仍然是不算的，因为患者心中仍然在期待，这件事情没有完。
图3-14工商系统的用例
可能有这样的组织，例如“**情报所”，它对外提供的价值就是提供一些信息。即使如此，业务用例名字最好也不要用“查询**”这样软件味道十足的名字，可以写成“了解**”。
边界框问题
从图3-12也可以看出，讨论“是不是用例”、“有哪些用例”的时候，必须先说清楚研究对象，否则讨论没有意义。画用例图时，能加上边界框尽量加上。有的建模工具没有提供这个边界框，可以用一个Note注明研究对象，如图3-15。
图3-15没有边界框，用例图也要用Note注明研究对象
也有人觉得没有边界框比起有边界框更能利用更多空间，对比效果如图3-16。不过，我建议初学者还是画边界框，以便时刻提醒自己当前的研究对象是什么，熟练的建模人员自便。
图3-16有无边界框的用例图布局对比
3.3.2识别业务用例的思路和常犯错误
识别业务用例有两条思路：一条是从业务执行者开始，思考业务执行者和组织交互的目的；另一条是通过观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。第一条路线是主要的，第二条路线用于补漏。如图3-17。
图3-17识别业务用例的两条路线
识别业务用例本来应该是很简单的事情，但是，许多程序员出身的需求人员受到了以往工作经历的影响，往往把简单的事情变得复杂。试列举一些常见的错误如下：
错误一：把业务工人的行为当作业务用例。
例如，以医院为研究对象，有人会画出图3-18：
图3-18业务工人的行为当作业务用例
这种情况的出现往往和没有注明研究对象有关。如果用边界框注明了研究对象，如图3-19，建模人员就会警觉，收费人员和医生在医院里面，是业务工人，不是业务执行者。
图3-19边界框有助于识别内外
不过，可能又会有人害怕“收费人员收费”“医生诊治”的信息此时不表达出来就忘记了。就像谈恋爱时迫不及待要表白一样，他千方百计要赶紧把这个信息表达出来，否则以后就没机会了，所以又会有图3-20，而且他还有理由：难道医院不要收费和诊治吗？收费和诊治不是医院的本质吗？
图3-20业务工人的业务用例
这里反映了建模人员常见的一个问题：分不清问题和问题的解决方案。
医院确实要收费，但图3-20说的不是收费，而是收费的一个解决方案——收费人员人脑系统坐在那里收费，背后的真实问题是医院的老板要通过医院来赚钱，至于钱怎么收上来的，是收费人员这个业务工人坐在那里收钞票，还是各种业务实体互相协作来达到收费的目的，老板是无所谓的。
同理，“医生诊治”也只是解决方案。患者要的是把病治好，治疗的过程短，不痛苦，没有后遗症，收费还便宜，并不在意他的病是医生动手术治好的，还是有个很牛的仪器给照好的。医院老板巴不得不用雇佣那么多收费人员和医生，照样为患者看病赚钱，只不过目前做不到而已。
或者这样思考，医院的成立不是为了容纳收费人员和医生，以解决本地户口的下岗人员和医科毕业生的就业问题，是患者要看病、老板想赚钱，于是才有了医院。
业务用例是为业务执行者服务，不是为业务工人服务。这不是什么规范问题，背后有它的道理。要从业务执行者的角度去看，才能看得清楚组织的本质价值。
像收费人员这样的人脑零件，以现在的IT技术替换掉没有问题，不过像医生这样读了很多年书，经过许多年专业训练的人脑零件，替换起来更难一些。
即使现在医生的地位还比较稳固，他的责任也已经被替换了一部分。过去去看病，说：“医生我咳嗽。”，医生会让我们伸出舌头看一看，听诊器放胸口听一听，躺在床上按一按。现在呢，医生抬头看一眼，啪啪就开单，“去照个××吧”，把检查的责任转移给仪器了。
几年前人们还认为人工智能攻克围棋还需要很久，现在AlphaGo已经使这个目标变为现实，也许不久的将来，各行各业打酱油的从业者将会被人工智能代替。
错误二：业务用例随待引入系统伸缩。
有的建模人员把臆想的待引入系统的用例直接当成业务用例画出来，如图3-21。
图3-21将臆想的系统用例当成业务用例
根据前面讲的知识要点，一看图3-21右侧，护士在组织边界外面，就知道不对了。但是，要求建模人员按照业务用例的定义做时，有人就会说：我的系统就是这个功能，我已经知道了，我还要考虑其他东西干什么？
这是一种“致命的自负”。正是因为很多情况下拍脑袋得到的是错误的需求，所以才要做业务建模，从组织的价值来推导系统应该具备什么价值才会对组织有帮助，这样系统才能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？
好了，现在建模人员知道护士在所研究组织边界里面，不能作为业务执行者了，但是又有可能还是受待引入系统的影响，导致组织的价值随着所引入系统的价值大小伸缩，如图3-22。
图3-22组织的价值受所引入系统影响
因为建模人员臆想待引入系统的主要功能是审核医嘱，所以画出的图中，医院或护士站就变成了一个“审核医嘱”的机构。
碰到这种情况，我通常都会用开玩笑的口气说，幸亏你们团队不是卖马桶的，否则就有可能得到图3-23：
图3-23医院变成了上厕所的机构
即使真的是卖马桶的，想要打败其他对手把马桶成功卖给医院，也依然需要研究医院的流程，找到马桶适合改进的改进点，才能打造出为医院量身定制的贴心马桶，如图3-24。
图3-24马桶也要从医院的流程找需求
一个组织，甚至组织的一条流程都涉及许许多多的系统。在开发不同的系统时，研究业务用例和业务流程，发现得到的结果和开发另一个系统时的研究结果差不多，这是很正常的。建模发人员不必因此感到惊慌，更不要因为“业务用例太少”、“业务用例太简单了”不自觉地改变研究对象，把待开发系统的用例搬上来。
错误三：把害怕漏掉的扩展路径片段提升为业务用例
还是用上文的例子，医院的用例是“患者→看病”，但是下一步待改进的可能是药剂科的药师盘点药品的流程片段，而这个看起来好像不能从患者看病的流程里找出来，所以建模人员会担心，然后画出图3-25左侧。也许画完后建模人员会意识到不妥，特地把研究范围缩小一些，得到图3-25右侧。左右两个图药师都在药剂科外面，都是错的。
用例下面除了有一条基本路径，还有若干条扩展路径。扩展路径的目的是预防或应对基本路径上发生的意外。
业务用例代表从组织视角看问题的高度。一个组织内部的所有零件，都应该从组织价值的角度来认识。不仅指员工或软件系统这样的重要零件，就连应该用什么颜色的桌子、什么品牌的电脑、盖什么形状的大楼，都不是随意的。
电影《国产凌凌漆》[周1994]中，陈司令对凌凌漆说，就算是一张卫生纸、一条内裤，国家都有它的用途。话虽夸张却有道理，一草一木都要服从组织的大局。
图3-26用例下面的流程片段
错误四：管理型业务用例
还有一种错误是从“药师盘点药品”推导出背后的好处，然后画成“管理型业务用例”，如图3-27。
图3-27管理型业务用例
这样的“业务用例”不可取。它没有特定组织的味道，哪家营利机构不是为了赚钱？另外，也很容易和愿景、涉众利益混在一起，发展下去，就会有“顾客→希望东西更便宜”之类的“用例”。
1.关于业务用例和系统用例的区别，以下正确的是：
2.以一家软件公司为研究对象，以下正确的是
3.如果有人问：“这个佣金系统的业务用例是什么？”您应该怎么回答？
4.如果您使用的建模工具中没有业务执行者、业务用例、业务工人、业务实体等图标，可以怎么做？（本题可多选）
5.公交公司里有调度员，调度员的工作除了调度之外，还要制订线路行车作业计划，还要不定期上路调查客流等等。假设根据愿景判断，下一步改进点应该在调度员上路调查客流的环节，那么，这个环节应该归属哪个业务用例呢？
①以公交公司为研究对象的“市民→乘车”用例
②以公交公司为研究对象的“调度员→调查客流”用例
③以系统为研究对象的“调度员→调查客流”用例
④以调度室为研究对象的“公司管理层→调度”用例
⑤以公交公司为研究对象的“公司董事会→提高运营效率”用例
图3-28UMLChina组织的用例
【步骤1】展开业务建模包下的业务用例包，双击业务用例用例图。
图3-29空白的用例图
【步骤2】点击工具箱中的，再点击图的顶部中间，在文本框中输入UMLChina，拖动边界框的边调整到合适的大小。
图3-30放置边界框，确定研究对象
【步骤3】单击工具箱中的，单击边界框的左侧，在文本框输入开发人员。双击开发人员执行者，单击属性框Stereotype栏右侧的按钮，在Stereotype对话框选择businessactor（也可以在属性框Stereotype栏直接输入businessactor），单击OK，再单击OK。
图3-31添加业务执行者
【步骤4】单击工具箱中的，单击边界框内，在文本框输入参加公开课。双击参加公开课用例，单击属性框Stereotype栏右侧的按钮，在Stereotype对话框选择businessusecase（也可以在属性框Stereotype栏直接输入businessusecase），单击OK，再单击OK。
图3-32添加业务用例
【步骤5】单击开发人员执行者，按住开发人员执行者右侧的小箭头（QuickLink），拖到参加公开课用例上，松开鼠标按键，从快捷菜单中选择Association。双击执行者和用例之间的关联线，在弹出属性框的Direction选择框中选择Source→Destination。
图3-33建立业务执行者和业务用例之间的关联
【步骤6】同上方法，在边界框外部右侧添加业务执行者餐饮提供商和会议室提供商，并建立用例参加公开课指向执行者餐饮提供商、会议室提供商的关联。