《软件方法》第4章 业务建模 之 业务序列图

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

我像是一颗棋子，来去全不由自己
《棋子》；词：潘丽玉，曲：杨明煌，唱：王菲；1994
]

步骤3：现状业务序列图
描述业务用例的实现，即业务流程，有几种可选的做法：
【选择一】文本。
例如针对财务部的“员工报销”业务流程，书写业务用例文档如下：
1. 员工把报销单交给财务主管
2. 财务主管确认报销单已经过员工领导审批
3. 财务主管审批报销单
4. 财务主管将审批好的报销单返还给员工
5. 员工把报销单交给会计
6. 会计复核报销单
7. 会计记录报销单
8. 会计把报销单交给出纳
9. 出纳付款
文本的缺点是不够生动，而业务建模注重生动，所以不推荐使用文本的方式，而是使用图形。不过，描述系统用例（需求）的时候，推荐使用文本，因为此时更注重精确。用图形描述业务流程，有两种UML元素可以选择：活动图和序列图。
【选择二】活动图
活动图，更准确地说是活动图的“山寨版”――流程图，应该是在开发人员中使用频率最高的图形了。
流程图最开始用于在编码之前表达代码逻辑，也就是所谓“详细设计”。在软件规模较小、编程语言表达能力较弱的年代，这样做是情有可原的。随着软件的规模越来越复杂，编程语言表达能力也越来越强，针对某一小段代码画流程图变得没有必要――如果类某个操作的代码复杂到要画一张流程图来说明，恐怕这个操作已经有问题了。
遗憾的是，现在流程图依然成为开发团队仅有的几种“设计”手段之一（这里的“设计”加了引号，您还记得是为什么吧？不记得的话，请复习前面的内容）。也许和高校的软件开发教材以及教师的知识严重落后于时代步伐有点关系？这个问题本书不深入探讨。
如果流程图用来表示组织内部各系统（岗位）之间的协作，即业务流程，那就变成了业务流程图，接近于活动图。活动图可以看作是流程图的扩展，添加了分区（Partition）、分叉（Fork）、结合（Join）…等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。
上面的报销业务流程用活动图可以表示如下：

图4-1 用活动图描述业务流程
【选择三】序列图
序列图用面向对象的思想描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。这个思想应该是起源于1995年Ivar Jacobson的“The Object Advantage”一书，很遗憾，这本书没有渠道获得，我也没有看过，幸好1997年Ivar Jacobson又出了UML版的“Software Reuse”，此书大陆有影印版和中译版。
本书采用序列图来描述业务流程，序列图比活动图优越之处如下：



带有图和测试题的PDF版本《软件方法》下载地址为：
http://www.umlchina.com/book/panjiayu.htm