第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 时间也是系统，不能和组织并列

在图3-6和3-7中，有箭头从执行者指向用例，也有箭头从用例指向执行者。前一种执行者称为用例的主执行者，后一种执行者称为用例的辅助执行者。例如，图3-6右侧可以这样解读：营销部找产品部帮忙规划产品，产品部仅靠自己的力量不足以完成，需要找研发部帮忙。或者这样解读：营销部向产品部“购买”服务，产品部向研发部“购买”服务。

本书不提供练习题答案，请扫码或访问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) 银行

7. 针对以下研究对象，财务人员最有可能是业务执行者的是____________。

 A) 某省注册会计师考试委员会

 B) 某市国税局

 C) 公司人力资源部

 D) 公司财务部

3.3 识别业务用例

业务用例指业务执行者希望通过和所研究组织交互获得的价值。以上面提到的某商业银行为例，储户和银行打交道的目的可能有存款、取款、转账，所以银行针对储户的用例如下：

图3-9 某商业银行针对储户的用例

和业务执行者一样，业务用例上有个斜杠，表示这是组织的用例。如果工具不提供这个图标，处理方法参照业务执行者。

如果穿越回三百年前，图3-9依然适用。业务用例代表组织的本质价值，很难变化，变化的是业务用例的实现——业务流程。三百年前，银行要实现“储户→存款”的用例，需要许多人脑系统（业务工人）一起协作，现在则变成了少数人脑系统（业务工人）和许多电脑系统（业务实体）之间的协作。

图3-10 用例没变，实现用例的零件变了

业务用例刷新了业务流程的概念。我们把业务流程看作是业务用例的实现，将其组织在业务用例的下面。组织内部之所以有业务流程，是因为要实现业务用例。组织里发生的一切都是为了给业务执行者提供价值。

这样的思路对改进业务流程有非常大的帮助：先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值，如图3-11。

图3-11 从价值出发重新构造业务流程

业务用例是组织的价值，不会因为某个人脑系统或电脑系统的存在或消失而改变。所以，“这个系统的业务用例是什么”这样的说法是错误的。

3.3.1 正确理解价值

用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点，买卖的平衡点。

例如，以医院为研究对象，“患者→挂号”不是用例，因为挂号不是患者对医院的期望和医院对患者的承诺的平衡点。如果挂到了号后医院的服务到此为止，患者到医院来时心中的期望没有得到满足。或者说，医院这个研究对象能承诺向患者提供的价值不是挂号，而是看病。

或者可以这样思考：医院能这样叫卖自己吗？“来呀来呀，我这家医院能挂号呀！”，患者一听，“哇，真棒耶，这医院能挂号耶，我赶紧去！”其实患者巴不得不挂号也能看病，只不过人太多了，需要拿号排队。

如果把研究对象改为医院挂号室，“患者→挂号”就是合适的用例。患者对挂号室的期望是能挂到号，不会因为挂号室没帮他看病就破口大骂。挂号室对他的承诺也就是能给他号。

以上提到的正确和错误的用例图如图3-12所示：

图3-12 期望和承诺的平衡

如果患者在窗口挂到的是明天的号，他离开医院回家了，明天再来医院就诊，那么挂号算不算医院的一个用例呢？仍然是不算的，因为患者心中仍然在期待，这件事情没有完。

（如果患者在家里使用医院的微信公众号挂到了第二天的号，明天再去医院就诊，那么医院的用例图会有变化吗？请读者使用本章前面已经提到的知识点自行解答。）

业务用例是组织对组织的服务，相对于系统为系统提供的服务（系统用例）来说，所需要的时间是比较长的，不能把用例实现过程中的某个交互片段当成用例。如图3-13所示，企业和工商局打交道变更地址的过程中，可能要发生多次交互，但是用例只有一个。

图3-13 业务用例持续的时间比较长

系统用例的持续时间比较短，如图3-14所示。一个典型的执行者离开系统去干别的事情时，如果他心里认为得到目前的结果不算白做，那就可以把它作为一个系统用例。有一些词汇带有浓浓的“系统”味道，例如新增、查看，录入，查询、修改、配置……，带有这些词汇的用例，很可能不是组织提供的价值，而是某系统提供的价值。

图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右侧，护士在组织边界外面，就知道不对了。但是，要求建模人员按照业务用例的定义做时，有人就会说：我的系统就是这个功能，我已经知道了，我还要考虑其他东西干什么？

这是一种“致命的自负”。正是因为很多情况下拍脑袋得到的是错误的需求，所以才要做业务建模，从组织的价值来推导系统应该具备什么价值才会对组织有帮助，这样系统才能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？

就像考试做题一样，如果已经知道答案是A，那就不用再花时间计算了。问题在于，我们很多时候是不知道的，不过瞎蒙也有25%的概率蒙对，然后就拿出来当作成功经验宣传，碰上掌握了方法的竞争对手，分分钟被虐成渣。

好了，现在建模人员知道护士在所研究组织边界里面，不能作为业务执行者了，但是又有可能还是受待引入系统的影响，导致组织的价值随着所引入系统的价值大小伸缩，如图3-22。

图3-22 组织的价值受所引入系统影响

因为建模人员臆想待引入系统的主要功能是审核医嘱，所以画出的图中，医院或护士站就变成了一个“审核医嘱”的机构。

碰到这种情况，我通常都会用开玩笑的口气说，幸亏你们团队不是卖马桶的，否则就有可能得到图3-23：

图3-23 医院变成了上厕所的机构

即使真的是卖马桶的，想要打败其他对手把马桶成功卖给医院，也依然需要研究医院的流程，找到马桶适合改进的改进点，才能打造出为医院量身定制的贴心马桶，如图3-24。

图3-24 马桶也要从医院的流程找需求

一个组织，甚至组织的一条流程都涉及许许多多的系统。在开发不同的系统时，研究业务用例和业务流程，发现得到的结果和开发另一个系统时的研究结果差不多，这是很正常的。建模发人员不必因此感到惊慌，更不要因为“业务用例太少”、“业务用例太简单了”不自觉地改变研究对象，把待开发系统的用例搬上来。

错误三：把害怕漏掉的扩展路径片段提升为业务用例

如果待改进的流程片段位于业务用例的主流程中，建模人员会比较安心，因为他预计往下建模时，他想要看到的部分肯定会出现；如果待改进的流程片段位于业务用例的支撑流程中，建模人员可能就慌了，害怕自己关心的部分漏掉了，于是为了让自己安心，把自己关注的片段提升为组织的用例。

还是用上文的例子，医院的用例是“患者→看病”，但是下一步待改进的可能是药剂科的药师盘点药品的流程片段，而这个看起来好像不能从患者看病的流程里找出来，所以建模人员会担心，然后画出图3-25左侧。也许画完后建模人员会意识到不妥，特地把研究范围缩小一些，得到图3-25右侧。左右两个图药师都在药剂科外面，都是错的。

图3-25 把关注的流程片段当成组织的用例

用例下面除了有一条基本路径，还有若干条扩展路径。扩展路径的目的是预防或应对基本路径上发生的意外。

以上面的“药师盘点药品”为例，如果药师不盘点，会导致真实库存和账面库存有差距，“患者→看病”的基本路径进行到取药片段时，才发现其实某种药品已经没有库存或者现有库存药品是坏的，往“患者→看病”的成功目标行进的道路上遇到了阻碍。同理，医院里为什么有保洁员打扫卫生？为什么内部要花时间搞团队建设？都应该从“患者→看病”的高度来看。

业务用例代表从组织视角看问题的高度。一个组织内部的所有零件，都应该从组织价值的角度来认识。不仅指员工或软件系统这样的重要零件，就连应该用什么颜色的桌子、什么品牌的电脑、盖什么形状的大楼，都不是随意的。

电影《国产凌凌漆》[周 1994]中，陈司令对凌凌漆说，就算是一张卫生纸、一条内裤，国家都有它的用途。话虽夸张却有道理，一草一木都要服从组织的大局。

当前关注的改进点有时是在基本路径中，有时是在扩展路径中，都不应该影响业务用例图。如果有较大把握判断和愿景相关的片段的位置，直接在用例下面画该片段即可，如图3-26。否则先画基本路径，再画扩展路径，画了一大堆才轮到待改进的片段，时间没有花在刀刃上。

图3-26 用例下面的流程片段

就像看病一样，患者说“医生我这两天咳得厉害”（愿景：降低咳嗽的频繁程度到正常人水平），医生从常理判断可能原因有：咽喉发炎、支气管发炎、肺部发炎等，决定先给最可能的部位（愿景相关的片段）拍片。当然，如果拍片发现前面这些推断都是错的，也许就需要来个全身扫描了。

错误四：管理型业务用例

还有一种错误是从“药师盘点药品”推导出背后的好处，然后画成“管理型业务用例”，如图3-27。

图3-27 管理型业务用例

这样的“业务用例”不可取。它没有特定组织的味道，哪家营利机构不是为了赚钱？另外，也很容易和愿景、涉众利益混在一起，发展下去，就会有“顾客→希望东西更便宜”之类的“用例”。

本书不提供练习题答案，请扫码或访问http://www.umlchina.com/book/quiz3_2.htm完成在线测试，做到全对，自然就知道答案了。

1. 关于业务用例和系统用例的区别，以下正确的是：

 A) 业务用例研究人工，系统用例研究自动化

 B) 业务用例研究组织，系统用例研究系统

 C) 业务用例研究业务，系统用例研究技术实现

 D) 业务用例研究系统外的工作，系统用例研究系统负责的工作

 E) 业务用例抽象，系统用例具体

 F) 业务用例不是所有系统都有，系统用例所有系统都有

2. 以一家软件公司为研究对象，以下正确的是

 A) ②和③

 B) 只有④

 C) 只有②

 D) ①和④

3. 如果有人问：“这个佣金系统的业务用例是什么？”您应该怎么回答？

 A) 经纪→领取佣金

 B) 财务部→发放经纪佣金

 C) 不清楚，再给出这个系统更详细的资料才行

 D) 不知道，问题问得不对

 E) 财务人员→计算佣金

 F) 经纪→领取佣金 以及 财务人员→计算佣金

4. 如果您使用的建模工具中没有业务执行者、业务用例、业务工人、业务实体等图标，可以怎么做？（本题可多选）

 A) 改用有图标的工具

 B) 那就不做业务建模了

 C) 只要注明了研究对象是组织就没关系，就用标准的执行者和类

 D) 自己在工具中添加文本构造型来代替

5. 公交公司里有调度员，调度员的工作除了调度之外，还要制订线路行车作业计划，还要不定期上路调查客流等等。假设根据愿景判断，下一步改进点应该在调度员上路调查客流的环节，那么，这个环节应该归属哪个业务用例呢？

①以公交公司为研究对象的“市民→乘车”用例

②以公交公司为研究对象的“调度员→调查客流”用例

③以系统为研究对象的“调度员→调查客流”用例

④以调度室为研究对象的“公司管理层→调度”用例

⑤以公交公司为研究对象的“公司董事会→提高运营效率”用例

 A) ①和④

 B) 只有③

 C) ②和⑤

 D) ③和⑤

3.5 案例和工具操作

UMLChina业务系统改进的组织是UMLChina组织，第一个迭代周期只需要关注最值得改进的业务用例。根据愿景推测，参加公开课的流程最值得改进，业务用例图只需要先画出这个业务用例就够了。UMLChina组织当然还有很多别的用例，包括所有公司都逃不掉的用例——政府要向它征税，只不过改进纳税的流程离愿景比较远，所以我们不画出来，但不代表它不存在。

图3-28 UMLChina组织的用例

【步骤1】展开业务建模包下的业务用例包，双击业务用例用例图。

图3-29 空白的用例图

【步骤2】点击工具箱中的，再点击图的顶部中间，在文本框中输入UMLChina，拖动边界框的边调整到合适的大小。

图3-30 放置边界框，确定研究对象

【步骤3】单击工具箱中的，单击边界框的左侧，在文本框输入开发人员。双击开发人员执行者，单击属性框Stereotype栏右侧的按钮，在Stereotype对话框选择business actor（也可以在属性框Stereotype栏直接输入business actor），单击OK，再单击OK。

图3-31 添加业务执行者

【步骤4】单击工具箱中的，单击边界框内，在文本框输入参加公开课。双击参加公开课用例，单击属性框Stereotype栏右侧的按钮，在Stereotype对话框选择business use case（也可以在属性框Stereotype栏直接输入business use case），单击OK，再单击OK。

图3-32 添加业务用例

【步骤5】单击开发人员执行者，按住开发人员执行者右侧的小箭头（Quick Link），拖到参加公开课用例上，松开鼠标按键，从快捷菜单中选择Association。双击执行者和用例之间的关联线，在弹出属性框的Direction选择框中选择Source→Destination。

图3-33 建立业务执行者和业务用例之间的关联

【步骤6】同上方法，在边界框外部右侧添加业务执行者餐饮提供商和会议室提供商，并建立用例参加公开课指向执行者餐饮提供商、会议室提供商的关联。

图3-34 得到完工的用例图