软件方法-第4章 业务建模 之 业务序列图
第4章 业务建模 之 业务序列图
我像是一颗棋子，来去全不由自己
《棋子》；词：潘丽玉，曲：杨明煌，唱：王靖雯；1994
上一章我们得到了待改进组织的业务用例图，本章我们将讨论业务建模中最繁重的工作——描述业务用例的实现，即业务流程，然后改进它，推导出待开发系统的用例。
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.1 描述业务流程的手段
描述业务用例的实现，即业务流程，有几种可选的做法：
【选择一】文本
例如针对财务部“员工→报销”用例的实现，书写业务用例规约如下：
1. 员工把报销单交给财务主管
2. 财务主管确认报销单已经过员工领导审批
3. 财务主管审批报销单
4. 财务主管将审批好的报销单返还给员工
5. 员工把报销单交给会计
6. 会计复核报销单
7. 会计记录报销单
8. 会计把报销单交给出纳
9. 出纳付款
2a. 报销单未经员工领导审批：
文本的缺点是不够生动，而业务建模注重生动，所以不推荐在描述业务流程时使用文本的方式，而是使用图形。不过，描述系统用例（需求）的时候，推荐使用文本，因为此时更注重精确。
用图形描述业务流程，有两种UML元素可以选择：活动图和序列图。
【选择二】活动图
活动图，更准确地说是活动图的“山寨版”——流程图，应该是在开发人员中使用频率最高的图形了。
流程图最开始用于在编码之前表达代码逻辑，也就是所谓“详细设计”。在软件规模较小、编程语言表达能力较弱的年代，这样做是情有可原的。随着软件越来越复杂，编程语言表达能力也越来越强，针对某一小段代码画流程图变得没有必要，而且如果类某个操作的代码复杂到要画一张流程图来说明，恐怕这个操作已经有问题了。
遗憾的是，现在流程图依然成为开发团队仅有的几种“设计”手段之一（这里的“设计”加了引号，您还记得是为什么吧？不记得的话，请复习前面的内容）。也许和高校的软件开发类教材以及教师的知识严重落后于时代步伐有点关系？这个问题本书不深入探讨。
如果流程图用来表示组织内部各系统（岗位）之间的协作，即业务流程，那就变成了业务流程图，接近于活动图。活动图可以看作是流程图的扩展，添加了分区（Partition，即UML1.x中的泳道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。
上面的报销业务流程用活动图可以表示如下：
图4-1 用活动图描述业务流程
【选择三】序列图
序列图用面向对象的思想描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。这个做法应该起源于1995年Ivar Jacobson的“The
Object Advantage”一书，， 1997年Ivar
Jacobson又出的UML版的“Software Reuse”，其中也有描述。
上面的报销业务流程用序列图可以表示如下：
图4-2 用序列图描述业务流程
我刚开始为开发团队提供服务的前几年，讲授描述业务流程的技能时选择的是活动图，2005年10月以后，改成了序列图，所以本书主要采用序列图来描述业务流程。做出这个选择基于以下几点理由：
（1）活动图只关注人，序列图把人当作系统。
软件开发的目的就是要改进当前的现实，可能是引进一个新系统，也可能是升级现有的系统。信息化发展到今天，待改进的当前现实中不只有人肉系统（即业务工人），还有大量的非人系统（即业务实体），这些非人系统封装了许多最开始位于人肉系统中的逻辑。将来和新系统交互的系统（也就是新系统的执行者），有可能只有一部分是人，另外一部分是非人系统。互联网的发展，更是使得许多商业或政府组织用来和大众打交道的接口系统不再是人肉系统，而是电脑系统。
图4-3 组织用来和大众打交道的“第一刀”越来越多由非人系统承担
使用活动图描述业务流程时，开发人员往往只注意人或部门的活动，忽略了非人系统的责任。待改进的现实中，会计记录报销单和出纳记录付款信息都需要用到现有的电脑系统SCS，活动图图4-1未能表达出来，序列图图4-2表达出来了。虽然活动图可以稍作变通，将非人系统也单列为分区，但我见过的绝大多数活动图，分区的抬头只是描述人或部门。
（2）活动图表示动作，序列图强迫思考动作背后的目的。
对比图4-4和图4-5：
图4-4 活动图表示动作
图4-5 序列图强迫思考背后的目的
图4-5不但表达了非人系统的责任，同时也清晰地揭示出来营业员这个岗位对外暴露的责任是：受理申请，这也是市民对于营业员的期望。期望和承诺，是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。
（3）活动图更“灵活”，序列图更不“灵活”。
不少人认为活动图胜过序列图的地方是它灵活，我开始也是这么认为，但现在我的观点是：这种灵活是一把双刃剑。活动图很灵活，它的控制流箭头可以指向任何地方，就像编码原始时代的Goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。
图4-6 活动图的灵活是把双刃剑
序列图通过alt、loop等结构化控制片断来描述业务流程，强迫开发人员用这种方式去思考。对于现状确实乱七八糟的流程，描述起来相对要困难，需要按照场景分开画很多张序列图来表达，但这也揭示了业务流程的糟糕现状。
另外我认为，软件开发中的业务建模更应该像讲故事，通过故事来思考待开发系统的位置，证明待开发系统确实能为组织带来好处。挑选需要改进的具体场景一个一个画序列图，比在一张图上把各种可能性和分支都罗列出来还是要好一些。
必须要承认，用活动图或类似活动图的手段（如BPMN）来建模业务流程是主流，而且已有的参考资料和模型积累也非序列图可比。本书选择了序列图来做业务建模，最主要原因还是“把人和电脑系统一样看待”。如果您使用其他方法来做业务建模已经做得很好，而且能解决这个问题，就没有必要切换到序列图。
这里展开说一个问题：多，不代表有价值。经常有开发人员问我，“潘老师，UML用得好的团队多不多？”我只能回答“不多”。于是提问者就释然了，哦，用得好的不多，看起来这个东西用处不大，我不学也没关系的。
围棋下得好的、足球踢得好的、脑外科手术做得好的、长得漂亮的女性…都不多，但是一旦突破门槛进入这个圈子，就会有很大的竞争优势。就拿编码来说，可能读者觉得会编码的人挺多的，周围的人大多都会，其实会编码的人占全国人口比例也很少很少，编码编得好的就更少了，但不能推导出“编码没用”的结论。相反，正是因为编码有门槛，所以大多数程序员尽管买不起房，衣食无忧是做得到的。
活动图或山寨活动图也不是最流行的，前文说过了，更流行的是随意而画的“草图”。“草图”也不是最流行的，最流行的应该是什么都懒得画，把脓包一遮了之。
UML提供了交互概述图（Interaction
Overview diagram），采用活动图的形式将各个场景的序列图串起来，相当于结合了活动图和序列图的特点。本书的模型也展示了交互概述图的用法。
在介绍绘制业务序列图的要点之前，我们先来看一些有趣的序列图，体验一下这种建模技术所带来的“严肃的创造力”。
图4-7 改进前的餐馆
图4-8 改进后的餐馆
图4-9 改进前的下载
图4-10 改进后的下载
图4-11 改进前的QQ泡妞
图4-12 改进后的QQ泡妞
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.2 业务序列图要点
消息代表责任分配而不是数据流动
图4-13 消息的含义是责任流不是数据流
这是最常犯也是最根本的序列图错误了。A指向B的消息，代表“A请求B做某事”，或者“A调用B做某事的服务”，做某事是B的一个责任。图4-13中，指向营业员的消息映射了营业员类的一个责任。（UML的定义中，消息有许多花样，在讲到分析设计的时候再介绍，这里说的是最常见的代表调用的消息）
在序列图中，焦点是对象之间的责任和协作，数据流是作为消息的输入输出参数存在的。建模人员在画序列图时，不仅要看到数据的流动，还要找出背后的责任。数据流很多时候是双向的，但责任封装在A这里，就不需要封装在B那里。
图4-14 消息的命名
图4-14中，业务人员指向科长和仓库管理员的消息代表了他们对业务人员提供的服务。如果业务人员传递借用单给仓库管理员没有特定的目的，可以用“处理借用单”来命名。另外，消息名称中不用带“请求”二字，消息箭头就已经有请求的意思。
在建模工具中，需要人工映射消息成为类的操作，然后就可以在各张序列图中反复使用了。图4-15是EA的界面，点击“Operations”按钮映射操作：
图4-15 EA中把消息映射为操作
聚焦于系统之间的协作
图4-16 系统内部的组件露出来了
业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人系统。图4-16是错误的，CRM系统内部的一个组件“客户表”露了出来。既然“客户表”可以露出来，销售支持的大脑、心脏、手指要不要露出来呢？毕竟是大脑指挥，心脏提供能量，用手指录入的。又如下图：&
图4-17& 表达了过细的交互步骤
销售支持在使用CRM系统记录客户资料的时候，有可能有多次交互，但在业务序列图中没有必要画出来，只需要在销售支持和CRM系统之间画一个“记录客户资料”就够了。
这里引出建模的一个基本原则：抽象级别一致。开发人员在建模和讨论问题时，经常是想到哪画到哪，打哪指哪，抽象级别和研究对象一会跳到这里，一会跳到那里。你跟他讲业务流程，他跟你说系统；你跟他说系统，他跟你谈类；你跟他谈类，他跟你讲业务流程……
图4-18是一张分析类图，这张图是合理的。
图4-18 购物系统的分析类图
建模人员突然来了兴趣，给订单周围加了一些东西，如图4-19。
图4-19 各种抽象级别混合起来了
订单有订单管理来辅助，商品、会员难道就没有吗？订单有状态，商品、会员难道就没有吗？把订单改成阿猫，待结账改成阿狗，实现状态机和对象管理的套路会变化吗？图4-19涉及到了几方面的知识：（1）购物领域各个类之间的关系；（2）订单有哪些状态；（3）实现时如何管理实体对象；（4）如何实现状态机。
人脑的容量是有限的，过早把各种领域的知识混杂，人脑需要处理的逻辑就会从M+N+O+P增加到M*N*O*P。正确的做法是将不同的知识分开表达，（2）放在订单类的状态机图中，（3）和（4）不需要画图，只需要用典型的代码案例表达所选择的实现套路，而实现套路经过选定以后就是有规律的，程序员经过分析模型加典型用例代码案例的训练，就可以举一反三，按图施工。
只画核心域相关的系统
图4-20 老太婆上街买个菜也不简单
现在的世界到处充满了（非人）智能系统，如图4-20，一个老太婆上街买个菜，都有可能和许多智能系统打交道，这就带来一个问题，是不是所有的智能系统都要成为我们业务流程中的业务实体？
图4-21 Word要不要画出来？
如图4-21，工作人员制作文档，还是工作人员用Word制作文档？一个智能系统要不要成为序列图上出现的业务实体，判断的标准是：它是否核心域内的系统。如果要改进的是采购的流程，不需要出现Word；如果要改进的就是制作文档的流程，可以出现Word。
核心域/非核心域的概念，在后面的工作流中还会不断提到，此处先不详细讨论。有时很难判断也没关系，您想过这个问题，就已经比没想过要好了！可以先画出来，然后如果发现它跟改进的流程无关（就像工作人员用Word、用WPS、用纸笔来制作文档，不影响采购流程的改进结果），再把它删掉。
把时间看作特殊的业务实体
业务序列图中，我们可以把时间看作特殊的业务实体。时间就像上帝造好的，挂在天上的一个大钟，向全世界各种系统发送时间消息。这样，就和后面需求工作流中映射系统用例的时间执行者一致了，同时也帮助理清什么情况下使用时间执行者的问题。
图 4-22 把时间当作一个系统
注意：时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类。世界上只有一个时间系统，但有无数的定时器。
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.3 【业务建模步骤1-3】：现状业务序列图
了解绘制业务序列图的一些要点后，我们开始来绘制改进前的、也就是现状的业务序列图。
现状就是：假如今天要引进您的系统的组织的业务流程发生，拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。在场景中，出场的也许全部都是人肉系统；也许除了人肉还有许多非人系统，唯独没有您要开发的系统；也许已经有了您的系统的1.0版本，正在等待2.0版本的改进……总之，现状就是现状。
说起来这么简单的事情，其实做到也很不容易。下面列出一些常见的错误：
4.3.1 错误：把“现状”误解为“纯手工”
许多建模人员画的业务流程中，只有人，没有非人系统。前文已经阐述过，人只是系统的一种，现在这个时代的业务流程中，非人系统承担的责任越来越大，以后我们要开发的新系统，很可能只有一些接口是和人肉系统打交道，另外一些接口是和非人系统打交道。
业务流程中全是人，那是二十多年前的“现状”，那是先锋、安易、用友等应用软件先驱刚刚起步的年代。基于二十多年前的现状来改进，得到的系统岂不是要和二十年前的软件一样？这样的软件怎么能卖得出去？新系统的需求通过研究业务现状，再结合愿景推导得到。如果描述的业务现状是虚假的现状，在上面得到需求就如同在流沙之上构建大厦，让人担心了。
举一个生活中的例子，三十年前人们走亲访友，带一包米、一只鸡、一筒饼干上门是非常得体而且受欢迎的，现在大家都过上了小康生活，您再带这些礼物去，在对方看来未必是什么好东西。您开发的系统就像送给客户的礼物。
这种错误，在使用活动图描述业务流程时比较普遍，序列图把人当作系统，有助于克服这一点。有一种误解是：认为人做的事情就是本质，电脑做的不是。其实应该把人看作系统。
4.3.2 错误：把“现状”误解为“规范”
建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的。上有政策，下有对策，人们在工作时往往会想出一些巧妙的方法，来规避不合理或对自己有损的规范，这些方法中的合理部分就值得计算机系统学习。如果视而不见，也就丧失了许多有价值的改进机会。
4.3.3 错误：以待开发系统为中心拼凑流程
图4-23 以待开发系统为中心拼凑流程
如图4-23，建模人员没有去调研并按照业务流程的进展来画图，而是想象了自己认为系统应该有的一些功能，把这些功能拼凑起来就变成“业务流程”了。
业务建模时，心中的摄像机应该一路跟随实现业务用例的流程去拍摄，把拍到的故事如实画出来，各个系统只是流程中的一个零件。建模人员常犯的错误就是把自己要开发的系统看得比天还大，把摄像机固定在自己要开发的系统的旁边。
业务建模就是要从业务流程中找到待开发系统的位置，证明您的系统如果有这些功能，对实现业务用例是有帮助的。这样，这个系统就能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？
1. 以下说法不正确的是
&#61601; A) 抽象级别一致是建模的重要原则
&#61601; B) 因为软件总是要修改的，所以要善于分离软件涉及的各种知识，降低修改的成本
&#61601; C) 因为软件总是要修改的，所以不用设计，赶紧编码是硬道理
&#61601; D) 序列图上的箭头代表责任分配
2. 描述业务用例的实现——业务流程适合用的UML图有（本题可多选）
&#61601; A) 活动图
&#61601; B) 用例图
&#61601; C) 序列图
&#61601; D) 状态机图
&#61601; E) 流程图
&#61601; F) 依赖图
3. 关于在业务建模中使用活动图和序列图，以下说法正确的是（本题可多选）
&#61601; A) 当前开发人员做业务建模时，序列图使用最多，所以《软件方法》书中以序列图为主。
&#61601; B) 序列图表示动作，活动图强迫思考动作背后的目的
&#61601; C) 活动图背后是面向过程的思想，序列图背后是面向对象的思想
&#61601; D) 活动图的“灵活”是优点也是缺点
4. 以下序列图存在错误的地方有
5. 以下书店系统的类图中有不少错误，最要不得的错误是：
&#61601; A) Catalog和cBinaryTree之间的关系&&&&&&&&&&&
&#61601; B) Catalog和Book之间的关系
&#61601; C) Book和Item之间的关系&&&&&&&&&&&&&&&&&&&&&&&
D) Item和Order之间的关系
此页面上的内容需要较新版本的 Adobe Flash Player。
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.4 案例
前面说过，现状就是现状，就是马上拿起摄像机跟随业务流程拍摄得到的现状。但是为了展示更多的“改进点”，我们把时间拨回到2005年的“蛮荒时代”。
在2002－2004年间，UMLChina的业务主要以上门为客户提供内训为主。虽然也有自己举办的公开课，但收费比较贵，人数不是很多。2005年4月，UMLChina开始举办不以盈利为目的的“非盈利公开课”，每人2天仅收400元（现在这个公开课依然举办，不过费用变为800元）。学员蜂拥而至，最多的一期达到100多人。人数的增加带来了工作量的增加，挤压了其他工作的时间，迫切需要在业务中引进专门的信息系统来减少工作量。所以，我们先要对“参加公开课”中认为值得改进的流程建模，想办法从中间寻找能用计算机系统来改进的改进点。
“参加公开课”用例的部分业务序列图如下：
图4-24 序列图：参加公开课－发布消息
图4-25 序列图：参加公开课－准备上课设施
图4-26 序列图：参加公开课－报名
图4-27 序列图：参加公开课－准备上课材料
图4-28 序列图：参加公开课－上课
图4-29 交互概述图：参加公开课
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.5 工具操作
【步骤1】在UMLChina的业务用例图上右击参加公开课用例，从快捷菜单选择Add|Add Diagram。
图4-30 添加图
【步骤2】在New
Diagram对话框中，将Name改为1-发布消息，在左侧的Select From列表选择UML Behavioral，在右侧的Diagram Types选择Sequence，点击OK按钮。
图4-31 空白序列图
【步骤3】双击业务建模|业务对象包下的业务对象类图。点击工具箱中的，点击类图空白处，在弹出的Class属性框，设置Name为公司助理，Stereotype选择Business Worker，点击确定。
图4-32 添加业务工人
【步骤4】在Project
Browser里双击新增加的1-发布消息序列图，选择业务对象包下的公司助理，拖到序列图的最左侧。在弹出的Paste Element对话框选择as Instance of
Element (object) 单选钮。点击OK。
图4-33 放置实例
【步骤5】按照【步骤3】的操作，在业务对象类图上添加一个新的业务工人技术专家。
图4-34 添加技术专家业务工人
【步骤6】按照【步骤4】的操作，在1-发布消息序列图上添加技术专家的实例。
图4-35 在序列图上添加技术专家实例
【步骤7】点击序列图上的：公司助理实例，按住右边出现的箭头，拖放到：技术专家实例，松开。
图4-36 创建消息
【步骤8】双击：公司助理和：技术专家之间的消息，在Message Properties属性框上点击Operations按钮，在技术专家Operations属性框，设置Name为决定下次公开课事宜，点击Save，点击确定，点击OK。
图4-37 设置消息
【步骤9】在业务对象类图上添加一个类，名称为Outlook，Stereotype选择Business Entity。
图4-38 添加业务实体
【步骤10】在1-发布消息序列图上添加一个Outlook的实例。双击该实例，在Object instance
Properties属性框设置Name为专家Outlook。
图4-39 在序列图添加Outlook实例
【步骤11】在：技术专家和专家Outlook：Outlook之间创建消息，名为查看日程，并映射操作。
图4-40 创建：技术专家和专家Outlook：Outlook之间的消息
【步骤12】选中：技术专家生命线，将右侧小箭头拖出去再放回：技术专家，创建自身消息并映射操作，名称为决定合适的时间和课程。
图4-41 创建自身消息
【步骤13】继续创建消息记录日程、通知助理。
图4-42 继续添加消息
【步骤14】选中：技术专家生命线，创建从：技术专家到：公司助理的消息，选中新创建的消息，点击向右的箭头，使该消息附加到通知助理消息上。双击新创建的消息，在Message Properties属性框中选中Is Return复选框。点击OK。
图4-43 添加返回消息
【步骤15】继续添加其他实例和消息。
图4-44 添加其他实例和消息
【步骤16】点击工具箱里的，再点击查看联系人消息的左上方，在弹出的Combined Fragment属性框中，选择Type为loop，设置Condition为所有联系人。点击OK。调整loop框的大小，把最后4条消息包住。
图4-45 添加交互片断框
【步骤17】创建其他序列图：2-准备上课设施（内容见图4-25）、3-报名（内容见图4-26）、4-准备上课材料（内容见图4-27）、5-上课（内容见图4-28）、4a-换购发票（内容留空）、4b-购买耗材（内容留空）。
【步骤18】在UMLChina的业务用例图上右击参加公开课用例，从快捷菜单选择Add|Add Diagram。在New Diagram对话框中，在左侧的Select From列表选择UML Behavioral，在右侧的Diagram Types选择Interaction Overview。点击OK。
图4-46 创建交互概述图
【步骤19】点击工具箱中的，再点击交互概述图的左上角。在弹出的ActivityInitial：ActivityInitial属性框中，将Name清空。点击确定。
图4-47 添加初始活动
【步骤20】在Project
Browser中选择1-发布消息序列图，拖到交互概述图上。在弹出的Select Type对话框选择Interaction
Occurrence，点击OK。在弹出的InteractionOccurrence: 1-发布消息属性框上直接点击确定。
图4-48 添加交互发生
【步骤21】选中起点，按住右侧的箭头，拖到1-发布消息交互发生上。在快捷菜单选择Control Flow。
图4-49 添加控制流
【步骤22】继续添加2-准备上课设施、3-报名、4-准备上课材料、5-上课，绘制它们之间的控制流。
图4-50 继续添加交互发生
【步骤23】点击工具箱中的，再点击交互概述图的最下方，在弹出的ActivityFinal：ActivityFinal属性框中，将Name清空。点击确定。
图4-51 添加终点
【步骤24】建立5-上课和终点之间的控制流。
图4-52 添加到终点的控制流
【步骤25】在交互概述图上添加4a-换购发票，绘制从4-准备上课材料到4a-换购发票的控制流。双击新添加的控制流，在ControlFlow
Properties的Constraints页签，设置Guard为发票用完。
图4-53 添加带警戒的控制流
【步骤26】继续绘制，完成如图4-29的交互概述图。
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.6 【业务建模步骤1-4】：改进业务序列图
绘制现状的业务序列图后，我们开始来思考：如果通过进一步信息化来改进现状，应该会给现状带来什么样的改进？信息化给人类的工作和生活带来的改进，常见的有以下几种：
注意：“进一步信息化”不一定需要引进一个全新的系统，也可以通过修改现有系统的责任达到。经常有人问“我是在遗留系统的基础上改进，建模技能还适用吗？”其实，所有系统都是在遗留系统基础上改进得到，最早的遗留系统是人肉系统。
4.6.1 改进一：物流变成信息流
我1997年刚参加工作的时候，每个月最期待的就是发工资的日子。财务到各个办公室吆喝“发工资了！”，大家就拥到财务室排队签字领信封，信封里有现金和工资条，每个人都会偷偷数一数，对一对。把发工资的故事画成如下序列图，可以看到钞票扎这个“物”在不同人之间传来传去。
图4-54 发工资——1997的故事
现在，发工资就变成了下面的序列图。原来的物流变成了信息流，在需要物的时候，才将信息变成物。
图4-55 发工资——2012的故事
物的流转成本会随着距离的增加而明显增加，信息流则不会。尽可能把物流变成信息流，在需要物的时候，才将信息变成物。这样，流转成本会大大降低。物流变成信息流的改进对人类社会生活的影响已经很明显。我们不再到邮局寄信，而是写电子邮件或发短信；我们口中的文件默认的不再是纸面文件，而是电子文件；我们看的书也逐渐变成了电子书。
物流变成信息流的改进模式如下：
图4-56 物流变成信息流
您能从您现在的项目中想出符合这个改进模式的例子吗？
4.6.2 改进二：改善信息流转
信息系统越来越多以后，一个人为了达到目的可能需要和多个信息系统打交道，各个信息系统中的信息靠人来协调，例如以下场景：
图4-57 改善信息流转——改进前
业务工人“调度科”在多个业务实体之间疲于奔命（虽然只是鼠标在奔），可以引进新的信息系统改进如下：
图4-58 改善信息流转——改进后
改善信息流转的改进模式如下：
图4-59 改善信息流转
您能从您现在的项目中想出符合这个改进模式的例子吗？
4.6.3 改进三：封装领域逻辑
以上是信息系统对人类工作和生活的初步改进。更高难度的改进是信息系统封装领域里的逻辑。这些领域逻辑原来可能封装在人脑中，通过提炼后封装到信息系统中，从而使人脑得到解放。
图4-60 封装领域逻辑——改进前
图4-60所示的情况，组织要雇用许多有一定经验的销售员，成本相当高。如果能够把销售员大脑中的经验提炼出来，封装到信息系统中，组织的成本就降下来了。
图4-61 封装领域逻辑——改进后
封装领域逻辑的改进模式如下：
图4-62 封装领域逻辑
您能从您现在的项目中想出符合这个改进模式的例子吗？
由上可见，绘制业务流程时一定要注意画出人脑中的思考逻辑，这是十分重要的改进点。我看过许多人画的业务流程，大多数象白开水一样，科长审批，处长审批，局长审批，没有内心活动，好像局长只是个审批机器。
目前面向大众的互联网（及移动互联网）系统如QQ、Facebook、Twitter，完成的大多是改进一和改进二，系统内部封装的逻辑不复杂。这样的场面很常见：稍有新意的互联网系统刚面世，很快就出现几十、几百个功能几乎一模一样的模仿者，这些模仿者中有的甚至是几个大学生凑一凑就开发出来的。谁成谁败，决胜点根本不是系统本身的功能，而是谁能早点多点拿到投资来购买内容和大做宣传，风险投资人也声称“投资是投人不是投产品本身”。许多互联网系统一开始就是比着烧钱，看最终谁能活下来等到赚钱这一天，然后赢家通吃。
专注于一个领域的行业软件，凝结了该行业的丰富领域知识，达到了改进三。这样的系统就能够靠软件本身的功能挣钱。不过，开发这种系统的公司往往是“隐形冠军”，在它所处的领域大名鼎鼎，在大众媒体却无声无息，例如做地震勘探行业软件的ION公司。
一些软件开发类媒体的总编更喜欢让自己的杂志和网站谈论互联网、开源……总归就是鼓动广大程序员向做不赚钱软件的开发人员学习，开发人员做不赚钱的软件时最开心，因为没有“赚钱”这个丑陋的压力嘛！要不就是用Facebook上市的故事激励程序员——“要么不赚，要赚就赚笔特大的！”。希望媒体多介绍一些在各行各业遍地开花、乐意思考“怎样的设计能让KTV灵活调整价格策略”的软件企业，多教教程序员“怎样通过做软件每年赚一百万”，比起教大家如何拉风投、如何上市圈多少个亿更实际。
这些年我参加一些软件开发的大会时，常会看到这样的场面：来自某网站的年轻工程师在台上大谈敏捷、架构，在一个行业钻研了十几二十年的研发总监在台下听。台上介绍的“经验”就是二三十年前的作坊式开发，台下做电力、税务行业软件的开发人员却误以为值得借鉴，因为他也梦想自己的软件有一天也有这么多的人使用。
这个场景有点讽刺，好像买彩票中了两个亿的彩民向每年赚几百万的小企业家介绍致富经验。台上的人介绍“我平时就是吃喝玩乐，结果中了亿元大奖”，台下的小老板很惭愧，纷纷表示以后也吃喝玩乐，以为这样就能中奖。
可能有人要解释“某某网站要应付这么多用户，背后技术门槛也不低”，这和中两亿大奖要纳四千万所得税类似。纳税是中奖带来的“快乐的痛苦”，不是中奖的原因，不是你愿意纳税就能中奖。有几个网站因为解决不了太多并发用户倒闭了？倒是不少网站准备好了应付上亿用户的架构，偏偏大家就是不用你。一些“纳税式”开发人员误以为自己带来了网站的成功，其实是网站的成功带来了他。
其实应该反过来才对。网站要能够赚钱，终归要向改进三迈进，而这方面就要多向行业软件学习了，不说太偏的，做好一个“餐饮管理系统”的领域模型，就需要学习很多东西了。
4.6.4 阿布思考法
张三断了一只手，一开始很痛苦，只剩下一只手以后的日子怎么过啊！过了些天，痛苦就慢慢淡了。他心里会比较，比起因地震大腿截肢的，因下雨溺毙车中的，自己已经很幸运了。
大学生李四失恋了，想人生还有什么意义，从教学楼楼顶跳下去吧。过了一星期，已经忘了当初为什么喜欢她。
老外刚进中国，觉得这个看不惯那个看不惯，怎么买东西不排队，怎么过马路闯红灯。过了一个月，混得比我们还要油。
人很容易适应现实，这是好事。如果没有这种自我调节的能力，就会一直沉溺在痛苦之中。不过，这种能力确实是捕获和探索需求的一个大障碍。例如，张三刚使用某个软件时痛苦不堪，谁做的软件，简直就是狗屎！用了一个月，他不但适应了这摊狗屎，还安慰自己，现在这个不景气的时节，有份工作做就不错了，人家想要来受这份累还没机会呢！这个时候如果去找他调研改进，他已经把痛苦忘得一干二净，麻木了，习惯了。
如果面对痛苦的是一位有钱或有权的人，结果会不一样。让我们把这位有钱有权的人叫做“阿布”。阿布借用了中国人对俄罗斯大富豪罗曼·阿布拉莫维奇（Roman Abramovich）的称呼。2003年，罗曼·阿布拉莫维奇收购英格兰球会切尔西，从此阿布广为人知。他大手笔买入球员，招来穆里尼奥，改变了英超的格局，使英超重新成为世界第一联赛。
阿布如果断了一只手，他不会像普通人一样善罢甘休。阿布会想：能不能移植一只手？如果肢体移植技术成熟，阿布拍出100万美元，会有“志愿者”乐意把自己的手奉上。如果肢体移植的技术还不成熟，阿布会投资成立一家肢体移植研究中心，招揽优秀医学专家来研究肢体再生和移植技术。再不济，阿布还可以找精密仪器专家帮他定制一只电子手。
阿布心仪的美女把阿布甩了，阿布会等待或“创造”出机会让美女爱上他。韩剧可能会这样演绎：美女的父亲得了尿毒症没钱换肾，阿布匿名帮美女支付了，一个偶然的机会，美女得知了这个秘密……。
阿布思考法寻找改进的思路是：
（1）假设有充足的资源去解决问题，得到一个完美的方案；
（2）用手上现有的资源去山寨这个完美方案。
如果有一个方案，花费完美方案1%的资源，能达到完美方案40％效果。这个方案已经是目前最好的方案了，因为它是在突破思维限制以后一步步往后退得来的。
许多伟大的创新，其实就是用廉价的替代方案来山寨过去富豪和高官的生活。小时候有一个让我印象很深的辩论：慈禧太后幸福还是现代的工人幸福？认为工人幸福的那一方的辩解理由之一是“工人回到家有电视看，慈禧太后有电视看吗？”事实上，慈禧太后虽然没有我们今天的“电视”看，但她有权有势，想看什么戏，只要通过太监传召，各种戏班名角马上入宫开演，而且是3D的、超大屏幕的现场直播。可惜的是，这种生活全国只有她老人家一个人享受，普通人怎么办呢，看山寨版——小电视呗！
我们来看看阿布思考法应用在软件开发上，能给需求捕获带来什么好处。
如何做一家优秀的网上商店？互相盯着其他网店竞争对手都添加了什么新功能，彼此搞模仿秀就可以了吗？不妨思考一下，阿布们最喜欢去哪里购物？洛杉矶？迪拜？然后去调研这些富豪爱逛的商店，它们的服务有哪些特色，想办法在软件系统中山寨。
打算做一个创新的会议管理软件？不要光盯着现有的会议管理软件，不妨思考一下，服务最周到、组织最得力的会议是什么会？在中国，应该是五年一次的党的全国代表大会？之所以服务周到组织得力，未必是靠电脑系统，而是靠经验丰富的人。如果能在会议管理软件中山寨一二，会不会成为亮点？
调研未必要亲临现场（去一趟迪拜或人民大会堂有一定代价），通过各种途径查资料也是调研。注意，不要把闭门造车的所谓“头脑风暴”当作调研，创新的需求从观察和思考的汗水中来，不是拍脑袋就能得到的。不去观察和调研，有时很难想象另一个层次的人是如何生活的，就像过去老农民的“头脑风暴”——“毛主席这么大的官，屋里肯定挂满了烧鸡和油条！”。
山寨未必要模仿得多象，99%是山寨，1%也是山寨。最简单的山寨就是意淫了，过去皇上后宫佳丽三千，今天单身程序员硬盘里也有东瀛佳丽三千。
我们再看一个例子：买火车票。自从12306系统运行以来，网上订火车票的越来越多。现在订票的故事是这样的：
图 4-63 屌丝刘先生买票
上图中，旅客要判断有无合适的票，可以通过“封装领域逻辑”移到12306系统中，这确实是一个改进点，但这就够了吗？没有票了，屌丝旅客就悻悻地下线了。如果换作阿布想要体验坐火车旅游的感觉，阿布的助理接受买票任务后，必然像电影《普拉达女王》（The Devil Wears Prada）里的助理小姐，使命必达。
图4-64 阿布买票
能否把“弄高价票”移到信息系统中？也就是说，留出一些票给愿意出更高价格的人。
图4-65 阿布买票的山寨版
当然，图4-64的高价竞票在中国不现实。在中国，买火车票不是经济问题，是政治问题。
阿布思考法来自Barry Nalebuff和Ian Ayres所著书籍“Why Not?: How to Use Everyday Ingenuity to Solve Problems Big and
Small”中的第一个技巧：“What Would Croesus Do?”我把它改成了国人更容易理解的阿布。
2000年初，我从《财富》的网站上知道了Thirdvoice，马上觉得“哇，这个东西真酷！”。Thirdvoice是一个浏览器插件，可以在任意网页上贴便条（评论），同样装了Thirdvoice的网友浏览到该网页时，会看到之前贴的便条，其实这些便条都集中放在服务器上，相当于一个基于URL的BBS。当时互联网创业的泡沫正盛，我花了几个月的业余时间，模仿Thirdvoice开发了一个中文山寨版“即时贴”，还特地租了服务器，把客户端放到各大下载网站让人下载，希望能吸引到风险投资，理由是能做到“人以群分”。过了一个多月，国内又出现了“傲客”等类似软件，不过仅过了半年多，随着互联网进入寒冬，大家都不了了之，鼻祖ThirdVoice也于2001年4月停止了服务。这次失败的创业尝试，我除了学到开发浏览器（仅限IE）插件的一些技巧，还初步体会“有趣”和“有用”的区别，以及“聪明人太多，做事必须竭尽全力”。
现在想起来，当年震撼我的ThirdVoice也可以看作阿布思考法一个应用。在别人家墙上贴标语或宣传画，甚至写字，历史上多的是。
4-66 UMLChina标语
1. 以下改进属于什么类型的改进？
&#61601; A) 合并条件表达式
&#61601; B) 封装领域逻辑
&#61601; C) 物流变成信息流
&#61601; D) 改善信息流转
&#61601; E) 提炼接口
2. 现在有些数码相机提供“笑脸捕捉”功能，这属于哪一种改进？
&#61601; A) 提炼类
&#61601; B) 封装领域逻辑
&#61601; C) 物流变成信息流
&#61601; D) 改善信息流转
&#61601; E) 提炼接口
3. 阿布思考法有两个步骤：
&#61601; A) 首先做业务建模，然后做需求
&#61601; B) 首先做愿景，然后做业务建模
&#61601; C) 首先不考虑业务建模，然后做需求
&#61601; D) 首先考虑资源限制，然后找山寨版
&#61601; E) 首先不考虑资源限制，然后找山寨版
&#61601; F) 首先找山寨版，然后再扩展
4. 过去几年的著名事件中，以下哪个和阿布思考法的内涵近似？
&#61601; A) 陈*希
&#61601; B) 干*露
&#61601; C) 周*锋
&#61601; D) 郭*美
此页面上的内容需要较新版本的 Adobe Flash Player。
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.7 案例
回到UMLChina的案例。观察业务序列图，挑出最重要的改进点。序列图4-24到4-28的这么多步骤中，值得改进的地方很多，但根据愿景，我们认为以下这个片断最值得改进：
图4-67 最值得改进的片断
挑中这个发通知的片断，原因是涉及的人数最多，而且会一直增加。处理一名学员的报名确实要花更多时间，但毕竟每次公开课报名人数有限（如果人真的多到忙不过来，那是快乐的烦恼了！）。
可以注意到，图4-67中有一个封装在人脑中的逻辑“挑选待通知联系人”，这是一个非常复杂的逻辑。总的原则是：能不通知就不通知。
如果不知道对方姓甚名谁，乱发邮件给他就不好了。我们从最开始的一些参加过活动的联系人开始，慢慢扩大联系人的范围。如果对方有一定头衔，应该用对方头衔称呼他，例如“陈总”，而不是直呼其名。
我们主要在北京、上海和广州开课。如果一个人在广州工作，给他发北京的通知是不合适的，但给石家庄和太原的人发就合适了。其他类型的活动，如网络上的国外专家语音讲座，则不受地域限制，可以全部发通知。如果某个研发总监或培训经理已经询问过本次公开课的事宜，就不必再通知该组织里的开发人员……
我们往业务序列图里空降一个新的业务实体“UMLChina系统”，将这个片断改进如下：
图4-68 第一个改进
从这个图就可以映射出UMLChina系统最值得做的第一批用例（见第5章）。
可以看到，UML建模并不是像一些不了解情况的开发人员想象的那样，“做完了所有的业务建模再做需求，做完了所有需求再做分析设计”，而是迅速定位最值得改进的改进点，得到系统最有价值的用例，先开发。和光会喊口号的“敏捷”不同的是，这里的“快”是有道理、有方法可讲的。
<span lang=EN-US style='font-size:16.0
line-height:150%;font-family:"微软雅黑","sans-serif";color:#.8 工具操作
【步骤1】在业务建模|业务对象包下的业务对象类图上，放置一个新的业务实体UMLChina系统。
图4-69 添加待开发系统为新的业务实体
【步骤2】打开业务建模|业务用例包下参加公开课用例下的序列图1-发布消息，把业务实体UMLChina系统从项目浏览器拖到序列图中，放置在：技术专家和专家Outlook：Outlook之间，在弹出的Paste Element对话框选择as Instance of
Element (object) 单选钮。点击OK。
如果想保留改进前的业务序列图，可以右击序列图“1-发布消息”，从快捷菜单选择copy diagram，再右击用例“参加公开课”，从快捷菜单选择paste
diagram，把得到的新序列图命名为“1-发布消息改进”，再在这张图上添加新业务实体。
图4-70 将新业务实体添加到需要改进的序列图中
【步骤3】把业务实体时间从项目浏览器拖到序列图1-发布消息中，放置在：UMLChina系统和专家Outlook：Outlook之间，在弹出的Paste Element对话框选择as Instance of
Element (object) 单选钮。点击OK。
图4-71 把业务实体时间添加到需要改进的序列图中
【步骤4】在：公司助理和：UMLChina系统之间创建消息，名为为公开课创建通知任务，并映射操作。选择：公司助理和助理Outlook：Outlook之间的消息查看联系人，按Ctrl+Delete键，在弹出对话框点击是。选择：公司助理和助理Outlook：Outlook之间的消息发邮件，按Ctrl+Delete键，在弹出对话框点击是。选择助理Outlook：Outlook生命线，按Ctrl+Delete键，在弹出对话框点击是。
图4-72 删除本场景不需要的消息和生命线
【步骤5】在：时间和：UMLChina系统之间创建消息，名为执行通知任务，并映射操作，消息的位置放在为公开课创建通知任务之下。
图4-73 添加时间和UMLChina系统之间的消息
【步骤6】右击：公司助理，在快捷菜单中选择Find|Locate Classifier in Project Browser，定位到项目浏览器中的公司助理。点开＋号，选中挑选待通知联系人和通知联系人操作，拖到UMLChina系统下面。
图4-74 将责任从公司助理转移到UMLChina系统
【步骤7】在序列图1-发布消息中，右击消息挑选待通知联系人，从快捷菜单选择Advanced|Set Source and Target...，在弹出对话框中，将From Element和To Element都改为UMLChina系统，点击OK。针对消息通知联系人做同样的操作。如果发现消息挑选待通知联系人、通知联系人没有和执行通知任务连在一起，可以分别右击这几条消息，将快捷菜单中Activations|Start New Message Group前面的勾去掉。
图4-75 转移消息的起点终点
【步骤8】把loop框缩小到只圈住挑选待通知联系人和通知联系人，双击loop框，在弹出属性框中把Condition框中的所有联系人改为所有符合通知条件的联系人，点击Save，点击OK。
图4-76 修改loop框
图4-77 改进后的业务序列图}