业务建模利器-业务序列图

下面主要探讨业务建模中的重点工作 - 描述业务用例的实现，即业务流程

1. 描述业务流程的手段

    1.1 使用文本，对流程进行顺序书写，1,2,3,4 的列下来

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

    1.2 活动图

    就是在使用最为广泛的业务流程图上增加分区，有开始，步骤和结束

   eg：报销业务流程用活动图

 

 1.3 序列图

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

      这个做法起源于1995年Ivar Jacobson的“The Object Advantage”一书，， 1997年Ivar Jacobson又出的UML版的“Software Reuse”，其中也有描述。（传颂其名）

      上面的报销业务流程图用序列图可以表现如下：

系列图的特点：

     1. 活动图只关注人，序列图把人作为一个参与的系统看待

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

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

对比图4-4和图4-5：

图4-4 活动图表示动作

图4-5 序列图强迫思考背后的目的

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

      3. 活动图更加的随意，序列图更加规范

        活动图灵活，它的控制流箭头可以指向任何地方，就像编码原始时代的Goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。

图4-6 活动图的灵活是把双刃剑

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

同样引用原作者对于画图的一段议论：

　　软件开发中的业务建模更应该像讲故事，通过故事来思考待开发系统的位置，证明待开发系统确实能为组织带来好处。挑选需要改进的具体场景一个一个画序列图，比在一张图上把各种可能性和分支都罗列出来还是要好一些。

　　必须要承认，用活动图或类似活动图的手段（如BPMN）来建模业务流程是主流，而且已有的参考资料和模型积累也非序列图可比。本书选择了序列图来做业务建模，最主要原因还是“把人和电脑系统一样看待”。如果您使用其他方法来做业务建模已经做得很好，而且能解决这个问题，就没有必要切换到序列图。

　　这里展开说一个问题：多，不代表有价值。经常有开发人员问我，“潘老师，UML用得好的团队多不多？”我只能回答“不多”。于是提问者就释然了，哦，用得好的不多，看起来这个东西用处不大，我不学也没关系的。

　　围棋下得好的、足球踢得好的、脑外科手术做得好的、长得漂亮的女性…都不多，但是一旦突破门槛进入这个圈子，就会有很大的竞争优势。就拿编码来说，可能读者觉得会编码的人挺多的，周围的人大多都会，其实会编码的人占全国人口比例也很少很少，编码编得好的就更少了，但不能推导出“编码没用”的结论。相反，正是因为编码有门槛，所以大多数程序员尽管买不起房，衣食无忧是做得到的。

　　活动图或山寨活动图也不是最流行的，前文说过了，更流行的是随意而画的“草图”。“草图”也不是最流行的，最流行的应该是什么都懒得画，把脓包一遮了之。

 

建模技术所带来的“严肃的创造力”。

图4-7 改进前的餐馆

图4-8 改进后的餐馆

图4-9 改进前的下载

图4-10 改进后的下载

2.  业务序列图绘制要点

    2.1 消息代表责任分配而非数据流

图4-13 消息的含义是责任流不是数据流

　　　　2.1.1 在序列图中，焦点是对象之间的责任和协作，数据流是作为消息的输入输出参数存在的。建模人员在画序列图时，不仅要看到数据的流动，还要找出背后的责任。数据流很多时候是双向的，但责任封装在A这里，就不需要封装在B那里。

　　　　2.1.2 消息名称中不用带“请求”二字，消息箭头就已经有请求的意思。

　　2.2 聚焦于系统之间的协作

　　　　

图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）不需要画图，只需要用典型的代码案例表达所选择的实现套路，而实现套路经过选定以后就是有规律的，程序员经过分析模型加典型用例代码案例的训练，就可以举一反三，按图施工。

　　2.3 只画核心域相关的系统

　　　　无关的东西太多，会分散人的注意力

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

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

图 4-22 把时间当作一个系统

注意：时间和定时器不是一个概念。时间是外系统，定时器是其他系统用来和时间打交道的边界类。世界上只有一个时间系统，但有无数的定时器。

3. 现状业务序列图

　　现状就是：假如今天要引进您的系统的组织的业务流程发生，拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。在场景中，出场的也许全部都是人肉系统；也许除了人肉还有许多非人系统，唯独没有您要开发的系统；也许已经有了您的系统的1.0版本，正在等待2.0版本的改进……总之，现状就是现状。

　　常见的错误：

     　　1. 把“现状”误解为“纯手工”

　　　　　　业务流程中，不应该是都是人，需要将涉及的系统进行一定的展示

　　　　2. 把“现状”误解为“规范”

　　　　　　客户业务人员的工作方式，并不是一定是最优处理方案，也可能没有按照实际的规范来工作，这些业务流程可以认为是不真实的，我们 建立的业务流程，应该是时候合理符合规范的，并不是一味的去附和客户。

　　　　3. 以待开发系统为中心拼凑流程

　　　　　　

图4-23 以待开发系统为中心拼凑流程

　　如图4-23，建模人员没有去调研并按照业务流程的进展来画图，而是想象了自己认为系统应该有的一些功能，把这些功能拼凑起来就变成“业务流程”了。

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

　　业务建模就是要从业务流程中找到待开发系统的位置，证明您的系统如果有这些功能，对实现业务用例是有帮助的。

 

摘录参考：http://blog.csdn.net/huaishu/article/details/39249383

转载于:https://www.cnblogs.com/hyiam/p/5917171.html