软件方法笔记-4业务序列

1，描述业务用例的实现，即业务流程，然后改进它，推导出待开发系统的用例
2，描述业务用例的实现，即业务流程，有几种可选的做法：


选择一】文本


例如针对财务部“员工→报销”用例的实现，书写业务用例规约如下：


1. 员工把报销单交给财务主管


2. 财务主管确认报销单已经过员工领导审批


3. 财务主管审批报销单


4. 财务主管将审批好的报销单返还给员工


5. 员工把报销单交给会计


6. 会计复核报销单


7. 会计记录报销单


8. 会计把报销单交给出纳


9. 出纳付款


扩展：


2a. 报销单未经员工领导审批：


……


文本的缺点是不够生动，而业务建模注重生动，所以不推荐在描述业务流程时使用文本的方式，而是使用图形。不过，描述系统用例（需求）的时候，推荐使用文本，因为此时更注重精确。


用图形描述业务流程，有两种UML元素可以选择：活动图和序列图。


【选择二】活动图


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


流程图最开始用于在编码之前表达代码逻辑，也就是所谓“详细设计”。在软件规模较小、编程语言表达能力较弱的年代，这样做是情有可原的。随着软件越来越复杂，编程语言表达能力也越来越强，


针对某一小段代码画流程图变得没有必要，而且如果类某个操作的代码复杂到要画一张流程图来说明，恐怕这个操作已经有问题了。


遗憾的是，现在流程图依然成为开发团队仅有的几种“设计”手段之一（这里的“设计”加了引号，您还记得是为什么吧？不记得的话，请复习前面的内容）。也许和高校的软件开发类教材以及教师的


知识严重落后于时代步伐有点关系？这个问题本书不深入探讨。


如果流程图用来表示组织内部各系统（岗位）之间的协作，即业务流程，那就变成了业务流程图，接近于活动图。活动图可以看作是流程图的扩展，添加了分区（Partition，即UML1.x中的泳道）、分叉


（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。




序列图用面向对象的思想描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。这个做法应该起源于1995年Ivar Jacobson的“The Object Advantage”一书，， 1997


年Ivar Jacobson又出的UML版的“Software Reuse”，其中也有描述。


3，（1）活动图只关注人，序列图把人当作系统。使用活动图描述业务流程时，开发人员往往只注意人或部门的活动，忽略了非人系统的责任
   （2）活动图表示动作，序列图强迫思考动作背后的目的。不但表达了非人系统的责任，同时也清晰地揭示出来营业员这个岗位对外暴露的责任是：受理申请，这也是市民对于营业员的期望。期望和


承诺，是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。
   （3）活动图更“灵活”，序列图更不“灵活”。不少人认为活动图胜过序列图的地方是它灵活，我开始也是这么认为，但现在我的观点是：这种灵活是一把双刃剑。活动图很灵活，它的控制流箭头


可以指向任何地方，就像编码原始时代的Goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。
4，在序列图中，焦点是对象之间的责任和协作，数据流是作为消息的输入输出参数存在的。建模人员在画序列图时，不仅要看到数据的流动，还要找出背后的责任。。指向营业员的消息映射了营业员类


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


他说系统，他跟你谈类；你跟他谈类，他跟你讲业务流程……
6，订单有订单管理来辅助，商品、会员难道就没有吗？订单有状态，商品、会员难道就没有吗？把订单改成阿猫，待结账改成阿狗，实现状态机和对象管理的套路会变化吗？图4-19涉及到了几方面的知


识：（1）购物领域各个类之间的关系；（2）订单有哪些状态；（3）实现时如何管理实体对象；（4）如何实现状态机。
7,现在的世界到处充满了（非人）智能系统，如图4-20，一个老太婆上街买个菜，都有可能和许多智能系统打交道，这就带来一个问题，是不是所有的智能系统都要成为我们业务流程中的业务实体？工


作人员制作文档，还是工作人员用Word制作文档？一个智能系统要不要成为序列图上出现的业务实体，判断的标准是：它是否核心域内的系统。如果要改进的是采购的流程，不需要出现Word；如果要改


进的就是制作文档的流程，可以出现Word。
8,业务序列图中，我们可以把时间看作特殊的业务实体。时间就像上帝造好的，挂在天上的一个大钟，向全世界各种系统发送时间消息。这样，就和后面需求工作流中映射系统用例的时间执行者一致了


，同时也帮助理清什么情况下使用时间执行者的问题。
9,时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类。世界上只有一个时间系统，但有无数的定时器
10,许多建模人员画的业务流程中，只有人，没有非人系统。前文已经阐述过，人只是系统的一种，现在这个时代的业务流程中，非人系统承担的责任越来越大，以后我们要开发的新系统，很可能只有一


些接口是和人肉系统打交道，另外一些接口是和非人系统打交道。这种错误，在使用活动图描述业务流程时比较普遍，序列图把人当作系统，有助于克服这一点。有一种误解是：认为人做的事情就是本


质，电脑做的不是。其实应该把人看作系统。
11,建模人员在建模业务流程时，照搬组织制定的规范，没有去观察实际工作中人们是如何做的，或者即使观察到了人们实际没有按照规范做，却依然按照规范建模。这样做，得到的业务流程是不真实的


。上有政策，下有对策，人们在工作时往往会想出一些巧妙的方法，来规避不合理或对自己有损的规范，这些方法中的合理部分就值得计算机系统学习。如果视而不见，也就丧失了许多有价值的改进机


会。
12,建模人员没有去调研并按照业务流程的进展来画图，而是想象了自己认为系统应该有的一些功能，把这些功能拼凑起来就变成“业务流程”了。业务建模时，心中的摄像机应该一路跟随实现业务用例


的流程去拍摄，把拍到的故事如实画出来，各个系统只是流程中的一个零件。建模人员常犯的错误就是把自己要开发的系统看得比天还大，把摄像机固定在自己要开发的系统的旁边。


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


不就完了吗，还装模作样做业务建模干什么呢？