软件方法笔记-3业务用例

1,业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”这个名字其实起得不好，应该更名为“组织建模”。出于对过去叫法的尊重，本书依然称为“业务建模”
2,很多时候我们把自己在开发的系统（现在流行叫××平台了）看得太重了，感觉没有我们开发的系统，组织就玩不转了.组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复


杂的系统——人肉系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。要改进组织的价值，不一定要开发软件，有时换人（也就是说，不是更换软件系统，而


是更换人肉系统）更管用。和一套软件系统的价格相比，也许雇用一名高级员工花费更多。
3,为什么需求经常“容易变化”？根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上马磨合后


发现问题，自然要改。“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能，大多数假的需求


变化会消于无形。遗憾的是，不少开发团队在改进的时候给自己开错了药方，以为应该通过提升设计的弹性来应变。设计是应对真正需求变化的手段，假的需求变化应该通过改进业务建模来应对
4,如果东西拿到客户面前，客户说“好呀，正是我想要的！”，过了半年，客户又说“形势变了，这个东西要改一下。”这是需求变了。如果东西拿到客户面前，客户说“这不是我想要的！”，这时硬


要说“需求变了”，脸皮有点厚了。
5，业务建模既然是研究组织，那么研究哪个组织呢？最佳的研究范围就是愿景波及的、需要改进的组织。如果发现组织的绝大多数流程和改进不相干，说明选的范围可能太大了；如果发现很多要改进的


地方未涉及，说明选的范围可能太小了
6，组织范围选择思路,画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统…）包在里面。注意上面的用词，“大多数责任可能被替换的系统”，而不是“大多数系统用户”


。因为此时待开发系统的边界尚未确定，不能先入为主地把某些人肉系统称为用户（而且前面我们说了，不是“用户”，而是“执行者”）。系统要做的改进和训练专员的工作有关，不代表训练专员一


定是该系统的执行者，也许人力资源总监会觉得取消所有的训练专员可能是更好的方案。
7,如果苍井老师购买了一套软件安装在她的电脑里，她会觉得这套软件是她的，但是，如果苍井老师觉得新浪微博很好用，她的认识就有些微妙的变化，会觉得新浪微博是新浪公司的。开发人员在为探


索互联网网站的需求而做业务建模时，也常会发生类似错误——要开发下一代互联网网站挑战新浪微博，所以把新浪公司作为研究对象？更正确的做法是把明星人群作为研究对象，思考如何做出更牛的


网站来向大众辐射苍井老师们的魅力。
8,面向大众的互联网网站只不过是软件的另一种表现形式——不再是购买光盘或下载安装包到本地安装，而是免费或收费“租用”系统（前面也说了，“免费”并非真的免费，我们付出了最宝贵的时间


）。苍井老师碰到 “新浪微博”，她只关心这个系统的功能和性能就够了，她会关心这个系统是新浪公司还是搜狐公司开发的？路上捡到的？还是外星人开发的？业务建模时应该研究的组织是该网站的


目标人群，并非负责开发和维护这个网站的开发组织。如果要改进的是运营网站的组织的内部运营工作，把网站组织作为研究对象就是合理的。总之，病在谁身上，就给谁做检查。
9,业务执行者的定义是：在组织之外和组织交互的人群或组织.
10,在寻找业务执行者时，有时会和组织内的人混淆，例如银行里面的营业员。营业员在组织里面，不是业务执行者，我们称其为业务工人（Business Worker）——组织内的人肉系统。业务执行者和业


务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的，一个是组织可以替换的零件。业务工人可能会被新的业务工人替换，但更多的可能是被新的业务实体（Business Entity）


替换。业务实体就是组织中的非人系统，例如银行的取款机、点钞机、营业系统。
11,在没有点钞机的时代，储户拿着一叠钞票到银行存钱，营业员需要凭着手感（界面层）一张张数，数的时候大脑（核心领域层）还要很快判断钞票的真伪。点钞、数数的逻辑封装在营业员的大脑里，


营业员非常累。有了点钞机，营业员只需要把整叠钞票放进点钞机过一下，点钞机会负责辨认假钞和计数。“验钞”、“数数”的责任和逻辑从人脑转移到了点钞机的大脑。营业员轻松了，当然，银行


也就不需要那么多营业员了。
12,责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，“我在开发一个新系统”，其实说的就是“我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任”。这样，探索需


求的思路就出来了。我们画好现状的业务序列图，然后把待开发的系统作为一个新的业务实体空降到序列图中，寻找改进点，得到该业务实体的责任，就可以直接映射到待开发系统的用例。
13,业务工人和业务实体不在业务用例图中出现，因为它们不是组织的价值，而是成本。业务工人和业务实体放在名为“业务对象”的包里，作为类（Class）的一个构造型。在识别业务执行者时，不需


要画业务工人和业务实体，在接下来画业务用例的实现——业务序列图的时候加上就可以。
14,业务执行者是一个组织（或人群），而不是系统。因为研究对象是组织，和它对应的概念也应该是组织.应该把银行系统看作业务实体，在业务建模的类图、序列图里出现，正确的业务用例图如下：


顾客-商场-银行 而非(顾客-商场-银行系统)
15，识别业务执行者时，可以这样思考：拿着摄像机对准组织的边界，谁上门找它办事？谁打电话给它？谁发邮件给它？它出门找谁办事？打电话给谁？发邮件给谁…可能就会找到它的供应商、客户…


…如果研究的组织是一个部门，那么其他部门就有可能成为它的执行者。
16，业务用例指业务执行者希望通过和组织交互达到的，而且组织能提供的价值。以上面提到的商业银行为例，我们可以这样思考，储户到银行的目的是什么？可能是存款、取款、转账。如果穿越回到


三百年前，图3-8所示用例图依然适用。业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。三百年前，银行要实现“储户→存款”的用例，需要许多人肉系统（业务工人）一起协作，


现在则变成了少数人肉系统（业务工人）和许多电脑系统（业务实体）之间的协作
17，患者确实是医院的执行者，但挂号不算医院针对患者的用例，因为挂号不是患者对医院的期望和医院对患者的承诺的平衡点。患者到医院来，挂到了号，医院的服务到此为止，患者到医院来时心中


的期望并没有得到满足（如果说满足？那么执行者就不叫患者，叫号贩子）。或者说，医院这个研究对象能承诺向患者提供的价值不只是挂号，而是看病。医生和收费人员是医院内的业务工人。业务用


例是为业务执行者服务，不是为业务工人服务。或者说，业务用例表达组织的本质价值。可能有人又会想：难道医院不要收费吗？收费不是医院的一个本质吗？这里反映了开发人员常见的一个问题：分


不清问题和问题的解决方案。医院确实要收费，但是选项E说的不是“收费”，而是“收费人员收费”，也就是说人肉系统坐在那里收钱，这是很容易替换的解决方案，背后的问题是医院的老板要通过医


院来赚钱，至于钱怎么收上来的，是收费人员这个业务工人坐在那里收钞票，还是银行系统内部转账，无所谓。同理，“医生诊治”也只是解决方案。病人要的是把病治好，治疗的过程短，不痛苦，没


有后遗症，收费还便宜，并不在意他的病是医生动手术治好的，还是有个很牛的仪器给照好的。医院老板巴不得不用请那么多医生，照样为病人看病赚钱，只不过做不到而已。。在讨论“有哪些用例”


的时候，必须说清楚研究对象，否则讨论是没有意义的（同理，不说清楚执行者是谁，讨论用例也是没有意义的）
18，先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值。识别业务用例有两条路线：一条是从业务执行者开始，思考业务执行者和组织打交道的目的；另一条是通过


观察组织的内部活动，一直问为什么，向外推到组织外部的某个业务执行者。第一条路线是主要的，思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点，注意不要出现“患者到医院


挂号”的用例。第二条路线用于补漏，找到之前可能会遗漏的执行者和用例。采用第二条路线思考时，会出现的一个错误是直接将内部活动作为业务用例。只要了解基本道理，稍加注意就可以避免这个


错误。这条路线还引出一个值得商讨的话题：管理型业务用例。
19，有箭头从执行者指向用例，也有箭头从用例指向执行者。前一种执行者称为用例的主执行者，后一种执行者称为用例的辅助执行者。所有公司都逃不掉一个用例：政府要向它征税。不过，从愿景判


断，我们的改进和UMLChina如何纳税的流程无关，所以不需要把不打算改进其实现的用例画出来。注意：虽然不画出来，但它们是存在的。
20，业务用例是组织的、而不是组织内某个系统的用例。组织的用例不会因为某个人肉系统或电脑系统的存在或消失而改变。所以，“这个系统的业务用例是什么”这样的说法是错误的。您可以注意到：前面画的业务用例图，研究对象都是组织。


既然如此，我们在开发软件系统时，为什么要研究组织的用例呢？因为我们想要把系统的价值和组织的价值挂上钩，给组织一个购买系统的理由。也就是说，业务用例不是思考系统提供什么“功能”，而是思考组织购买了这个系统，对组织本来就有的哪些“功能”会带来一点点帮助。


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

如果一时之间难以确定要改进的业务组织，难以思考组织的用例，可以先不画业务用例图，先画要重点改进的流程的业务序列图，再从中归纳出合适的待研究组织和业务用例。

参考:http://blog.csdn.net/joeyon1985