业务建模 活动图和序列图

http://blog.csdn.net/huaishu/article/details/39249383

活动图，更准确地说是活动图的“山寨版”——流程图，应该是在开发人员中使用频率最高的图形了。

如果流程图用来表示组织内部各系统（岗位）之间的协作，即业务流程，那就变成了业务流程图，接近于活动图。活动图可以看作是流程图的扩展，添加了分区（Partition，即UML1.x中的泳道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。

序列图用面向对象的思想描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。

我刚开始为开发团队提供服务的前几年，讲授描述业务流程的技能时选择的是活动图，2005年10月以后，改成了序列图，所以本书主要采用序列图来描述业务流程。做出这个选择基于以下几点理由：

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

软件开发的目的就是要改进当前的现实，可能是引进一个新系统，也可能是升级现有的系统。信息化发展到今天，待改进的当前现实中不只有人肉系统（即业务工人），还有大量的非人系统（即业务实体），这些非人系统封装了许多最开始位于人肉系统中的逻辑。将来和新系统交互的系统（也就是新系统的执行者），有可能只有一部分是人，另外一部分是非人系统。互联网的发展，更是使得许多商业或政府组织用来和大众打交道的接口系统不再是人肉系统，而是电脑系统。

使用活动图描述业务流程时，开发人员往往只注意人或部门的活动，忽略了非人系统的责任。待改进的现实中，会计记录报销单和出纳记录付款信息都需要用到现有的电脑系统SCS，活动图图4-1未能表达出来，序列图图4-2表达出来了。虽然活动图可以稍作变通，将非人系统也单列为分区，但我见过的绝大多数活动图，分区的抬头只是描述人或部门。

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

图4-5不但表达了非人系统的责任，同时也清晰地揭示出来营业员这个岗位对外暴露的责任是：受理申请，这也是市民对于营业员的期望。期望和承诺，是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。

（3）活动图更“灵活”，序列图更不“灵活”。

不少人认为活动图胜过序列图的地方是它灵活，我开始也是这么认为，但现在我的观点是：这种灵活是一把双刃剑。活动图很灵活，它的控制流箭头可以指向任何地方，就像编码原始时代的Goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。

序列图通过alt、loop等结构化控制片断来描述业务流程，强迫开发人员用这种方式去思考。对于现状确实乱七八糟的流程，描述起来相对要困难，需要按照场景分开画很多张序列图来表达，但这也揭示了业务流程的糟糕现状。

这里引出建模的一个基本原则：抽象级别一致。开发人员在建模和讨论问题时，经常是想到哪画到哪，打哪指哪，抽象级别和研究对象一会跳到这里，一会跳到那里。你跟他讲业务流程，他跟你说系统；你跟他说系统，他跟你谈类；你跟他谈类，他跟你讲业务流程……

了解绘制业务序列图的一些要点后，我们开始来绘制改进前的、也就是现状的业务序列图。

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

许多建模人员画的业务流程中，只有人，没有非人系统。前文已经阐述过，人只是系统的一种，现在这个时代的业务流程中，非人系统承担的责任越来越大，以后我们要开发的新系统，很可能只有一些接口是和人肉系统打交道，另外一些接口是和非人系统打交道。

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

建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的。上有政策，下有对策，人们在工作时往往会想出一些巧妙的方法，来规避不合理或对自己有损的规范，这些方法中的合理部分就值得计算机系统学习。如果视而不见，也就丧失了许多有价值的改进机会。

4.3.3 错误：以待开发系统为中心拼凑流程

业务建模就是要从业务流程中找到待开发系统的位置，证明您的系统如果有这些功能，对实现业务用例是有帮助的。这样，这个系统就能卖得出去。如果已经认定了系统有这些功能，直接画系统用例图不就完了吗，还装模作样做业务建模干什么呢？