何伟潮的《软件方法》读书笔记（用其他工具把书里的图画了一遍）（1-2）业务序列图

以下是何伟潮的读书笔记，难得的是，他用其他工具把书中的图自己画了一遍。

1、建模

1.1、业务建模之愿景

重点1：通俗一点讲，一个东西的愿景就是：东西最应该卖个谁，对他有什么好处？

重点2：愿景是需求排序的主要依据。

重点3：老大、愿景、需求都是基于现状寻找最值得的改进。改进过后，又是新的现状了，还是基于现状寻找最值得的改进。进一步说也可以说，需求只有真假对错，没有变化。说需求有变化，那是从一个静止时间点来看的。

1.1.1、愿景

1.2、业务建模之业务用例图

有了愿景，我们知道老大对他所代表的组织的现状的某些指标不满意。接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模（Business modeling）的主要内容。

重点1：软件系统只是组织的一个零件。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人脑系统。

重点2：开发团队发现需求“容易变化”。根源之一是需求的来路不正，没有把系统当作一个零件放在组织中来看，靠拍脑袋得出需求，导致得到的系统需求是错的。

1.2.1、业务角色

① 业务执行者

以某组织为研究对象，在组织之外和组织交互的其他组织（人群或机构）就是该组织的执行者。以一家商业银行为研究对象，观察在它边界之外和它打交道的人群或机构，可以看到储户来存钱，企业来贷款，人民银行要它作监督等等，这些就是该商业银行的执行者，如下图所示：

这里要注意的是，作为观察者的建模人员本身是一个人脑系统，所以在观察组织边界时，直觉上观察到的不是组织之间的交互，而是组织派出的系统之间的交互，但是一定要把它理解成组织间的交互，因为谈论业务执行者时，研究对象是组织，所以外部对应物——业务执行者也应该是组织。例如：以某国税局为研究对象，可以观察到企业财务人员到国税局报税，但业务执行者不是企业财务人员，而是企业。也许到后来，企业财务人员和国税系统交互，又或许再后来是企业系统与国税系统交互，从组织的抽象级别来看，都应该理解为企业和国税局这两个机构之间的交互，如下图所示：

② 业务工人

组织内的人称为业务工人，例如某商业银行里面的营业员。业务工人是可以被替换的人脑零件，它可能被其他业务工人替换，但更有可能被业务实体替换。

③ 业务实体

业务实体是组织中的非人智能系统，例如银行的ATM、点钞机、营业系统。

1.2.2、识别业务用例

重点1：业务用例指业务执行者希望通过和所研究组织交互获得的价值。业务用例是组织的价值，不会因为某个人脑系统或电脑系统的存在或消失而改变，好比如300年前的商业银行和当前的银行的业务用例是不变的，因为银行提供价值的本质没有改变。所以“这个系统的业务用例是什么”这样的说法是错误的。

重点2：用好用例，关键在于理解“价值”。价值是期望和承诺的平衡点、买卖的平衡点。例如以“医院”为研究对象，真正的用例是“患者→看病”，而不是“患者→挂号”，患者→挂号”可以是以“挂号室”为研究对象的业务用例（如下图）。所以做任何事情之前，要搞清楚“边界”，没有边界会很容易盲目“拍脑袋”做一些努力但没效果的事情。

1.2.2.1、识别业务用例思路

识别业务用例的思路有两条：

【从外到内】从业务执行者开始考虑，思考业务执行者和组织交互的目的（主要）；

【从内到外】通过观察组织的内部活动，一直问为什么，向外推导出组织外部的某个业务执行者（补漏）。

1.2.2.1.1、识别业务用例常犯错误

错误1 ：把业务工人的行为当做业务用例。

错误2：业务用例随待引入系统伸缩。

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

错误4：管理型业务用例。

总结：错误的根源主要源于：建模人员分不清问题和问题的解决方案。

1.3、业务建模之业务序列图

1.3.1、描述业务流程的手段

本章节主要讨论的是业务建模中最繁重的工作——描述业务用例的实现，即业务流程，然后改进它，推导出待引入系统的用例。目前描述业务流程的可选择手段有文本、活动图和序列图，它们的主要区别如下（以财务部“员工→报销”用例的实现为样例）：

● 文本

文本的缺点是不够生动，所以在描述业务流程时很少使用文本方式。不过，描述系统用例（即系统需求）的流程时，文本是常用的，因为此时更注重精确，而且还要表达业务规则、性能等目前尚未被UML标准覆盖的内容。

● 活动图

活动图的前身是流程图，应该是在建模人员中使用频率最高的图形，是随机械工程领域慢慢引入到计算机领域。不过，随着编程语言表达能力越来越强，针对简单的分支或循环逻辑画图在很多情况下已经变得没有必要。

● 序列图

序列图与活动图的比较如下：

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

在上一章节中已经提到，现在的业务流程中已经有很多领域逻辑是封装在业务实体而不是业务工人中，如果忽略非人智能系统，很多重要信息就丢掉了。

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

序列图可以更加清晰地表述业务工人或业务实体对外的责任，也就是用例的期望值。期望和承诺是用例和对象技术的关键思想，使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地惯窃业务建模和系统建模的始终。

3）活动图“灵活”，序列图“不灵活”；

不少人认为活动图胜过序列图的地方是它灵活，但这灵活是一把双刃剑。活动图很灵活，他的控制箭头可以指向任何地方，就像编码原始时代的“goto”语句，所以活动图很容易画。不过，“很容易画”的活动图也比较容易掩盖建模人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图可通过alt、loop等结构化控制片段来描述业务流程，强迫建模人员用这种方式思考。

1.3.2、业务序列图要点

1.3.2.1、消息代表责任分配而不是数据流动

序列图中最重要的要点是消息的含义。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，而“做某事”是B的一个责任。

1.3.2.2、抽象级别是系统之间的协作

业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小颗粒是系统，包括人和非人系统，而系统之间最主要突出的是协作。所以“系统粒度”和“协作”是业务序列图的关键要点，如果记住了这两个关键点，就可以避免了对组织对象抽象的错误以及对协作理解的错误。

以上说的两种错误是把需求和分析的工作流的工作带入了业务建模。第一样例图提到的系统内部的组件，应该在分析和设计工作流中描述；第二样例图提到了交互步骤，应该在需求工作流中描述。除了以上两种抽象级别的错误，还有一种是：业务序列图的内容和业务用例图差不多，如下所示：

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

业务序列图中，我们把时间看作特殊的业务实体。把时间看作上帝造好挂在天上的一个大钟，向全世界各种系统发送时间消息，这样，就和后面需要工作流中映射系统用例的时间执行者一致了，同时也帮助理清什么情况下使用时间执行者的问题。

值得注意的一点是，时间和定时器不是一个概念，时间是“外系统”，定时器是其他系统用来和时间打交道的“边界类”。世界上只有一个时间系统，但有无数的定时器。如果建模人员在识别系统用例时说“执行者是定时器”，那就错了，执行者是时间。

1.3.2.4、为业务对象分配合适的责任

分配给业务对象的责任必须是该对象有能力承担的，这需要我们自身必须对理解要十分清晰，毕竟我们自己说话有时候的会含糊。例如“工作人员用Word写标书”这样的说法好像可以接受，但如果按照说话的文字不假思索地随便画，会很容易导致对象责任分配不准确。

1.3.3、现状业务序列图

业务序列图描述的是业务流程，建模需要通过在现状的业务序列图基础上找出改进的要点。如果要把现状序列图画出来，就必须让自己站在客观的角度“亲临现场”，“如实”地把所看到的记录下来，尽力描绘出真实的现状。但说起来非常简单，做到却极其困难。总结到这里，忽然让我想起了彼得·德鲁克。下面列出一些描述现状时经常犯的错误。

1）错误：把想象中的改进当成现状

很多时候造成这种错误，背后的原因很可能是根本没有深入到组织流程中去做观察和访谈，对现状没有认识，只好想像一个改进后的场景来应付。

2）错误：把“现状”误解为“纯手工”

有的建模人员以为人做的事情才是本质，所以他画的业务流程中，只有人，没有非人系统，完全忽略了在技术进步下慢慢可以替代人的这些“业务实体”。

3）错误：把“现状”误解为“本开发团队未参与之前”

开发团队很容易会误以为当他们开始参与组织流程完善而开发系统的时候当作“现状”，这就是典型的“技术思维”，很多时候在开发团队在参与组织流程完善前，组织已经经过了许多次“非系统级”的流程改进，这是站在组织角度去看问题的。

4）错误：把“现状”误解为“规范”

建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的，毕竟上有政策，下有对策。

5）错误：“我是创新，没有现状”

互联网创业公司的建模人员很容易犯的这个错误，动不动就说“我做的是互联网创新，没有现状”，但他们已经忘记了历史上所有的创新都是站在前辈这些巨人的肩膀之上这个事实。

6）错误：“我做产品，没有现状”

非定制系统的开发团队进程拿这句话做接口。A公司的流程和B公司的流程有差异，中国的流程和外国的流程有差异，画谁的现状好的？问这个问题的时候，我想是开始开发团队忘记了“做需求时把产品当项目做”的道理，在第2章节中也提到过“谁比谁更像”的重点。

1.3.4、改进业务序列图

上面提到的现状业务序列图是对组织现状的客观描述，而改进业务序列图是通过信息化手段去思考对业务现状序列图的一些改进。通常，信息化给人类的工作和生活带来的改进有三种模式。

1.3.4.1、改进模式一：物流变成信息流

和信息的光电运输比起来，用其他手段运输的物的流转速度就显得太慢了，而且运输成本会随着距离的增加而明显增加。如果同类物的不同实例之间可以相互取代，那么可以提炼物中包含的部分或全部有价值的信息，在需要发生物流的地方，改为通过软件系统交互信息，需要物的时候再将信息变成物，这样就可以大大增加流转速度和降低流转成本。

1.3.4.2、改进模式二：改善信息流转

软件系统越来越多，而各个软件系统之间沟通不畅，导致一个人为了达到某个目的可能需要和多个软件系统打交道，如果把各软件系统之间的协调工作改为一个软件系统来完成，人只需要和单个软件系统打交道，信息的流转就改进了。

1.3.4.3、改进模式三：封装领域逻辑

在业务流程中，有很多步骤是由人脑来判断和计算的，领域逻辑封装在人脑中。相对于计算机，人脑（业务人才）存在成本高，状态不稳定、会徇私舞弊等问题。如果能够提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑，业务流程就得到了改进。换句话说，领域逻辑的封装是对系统“内在”价值的提升，相对于前两个改进模式有更高的要求和更大的困难。

1.3.4.4、改进思考方式：阿布思考法

在软件开发团队中，当有人提出新的想法时，经常会被马上否定“太难了，做不了”，最终得到一个平庸的、毫无竞争力的系统。学会像阿布（俄罗斯大富豪罗曼·阿布拉莫维奇）一样思考，有助于克服普通人因资源受限而不敢展开想象的思维障碍。阿布思考法分两步：

1）假设有充足的资源去解决问题，得到一个完美的方案；

2）用手上现有的资源去山寨这个完美的方案。

其实，阿布思考法的核心思想就是，不要闭门造车，要“接地气”的行动起来，主动去观察，或主动寻找有用的信息去分析和调研，不要被各种局限被迫让步。