业务建模

第3章 业务建模
1.期望和承诺的平衡

2,业务用例表达组织的本质价值

3.最后需要说明的是，题目的第一句是“以医院为研究对象”。
在讨论“有哪些用例”的时候，必须说清楚研究对象，
否则讨论是没有意义的（同理，不说清楚执行者是谁，讨论用例也是没有意义的）。

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

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

6.识别业务用例有两条路线：一条是从业务执行者开始，思考业务执行者和组织
打交道的目的；另一条是通过观察组织的内部活动，一直问为什么，
向外推到组织外部的某个业务执行者。

7.第一条路线是主要的，思考的焦点是“执行者对组织的期望和组织对执行者的承诺”的平衡点，
注意不要出现“患者到医院挂号”的用例。第二条路线用于补漏，找到之前可能会遗漏的执行者和用
例。

8.业务用例是组织的、而不是组织内某个系统的用例。组织的用例不会因为某个人肉系统或电脑系
统的存在或消失而改变。所以，“这个系统的业务用例是什么”这样的说法是错误的。您可以注意到：
前面画的业务用例图，研究对象都是组织。
既然如此，我们在开发软件系统时，为什么要研究组织的用例呢？因为我们想要把系统的价值和
组织的价值挂上钩，给组织一个购买系统的理由。也就是说，业务用例不是思考系统提供什么“功能”，
而是思考组织购买了这个系统，对组织本来就有的哪些“功能”会带来一点点帮助？
一个组织，甚至组织的一条流程都涉及到许许多多的系统。在开发不同的系统时，研究业务用例
和业务流程，发现得到的结果和开发另一个系统时的研究结果差不多，这是很正常的。开发人员不必
因此感到惊慌，更不要因为“业务用例太少”、“业务用例太简单了”不自觉地改变研究对象，把待开
发系统的用例搬上来。
如果一时之间难以确定要改进的业务组织，难以思考组织的用例，可以先不画业务用例图，先画
要重点改进的流程的业务序列图，再从中归纳出合适的待研究组织和业务用例。

第四章 业务建模 之 业务序列图

1.业务流程
文本，活动图，序列图

（1）活动图只关注人，序列图把人当作系统。

息化发展到今天，待改进的当前现实中不只有人肉系统（即业务工人），还有大量的非人肉系统（即业
务实体），这些非人肉系统封装了许多最开始位于人肉系统中的逻辑。将来和新系统交互的系统（也就
是新系统的执行者），有可能只有一部分是人，另外一部分是非人肉系统。

（2）活动图表示动作，序列图强迫思考动作背后的目的。

期望和承诺，是用例和对象技术的关键思想。使用序列图
来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。

另外我认为，软件开发中的业务建模更应该像讲故事，通过故事来思考待开发系统的位置，证明
待开发系统确实能为组织带来好处。挑选需要改进的具体场景一个一个画序列图，比在一张图上把各
种可能性和分支都罗列出来还是要好一些

4.2业务序列图要点
4.2.1消息代表责任分配而不是数据流动
4.2.2聚集于系统之间的协作

业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人肉系统

这里引出建模的一个基本原则：抽象级别的一致

4.2.3 只画核心域相关的系统

4.2.4 把时间看作特殊的业务实体