UML软件工程组织

 

 

高级工作流模式深入业务场景分析(1)——多路合并
 
2008-06-30 来源:网络
 

(1) 描述

两条或更多的分支合并到单一的一条后续路径中,每一条使能进入分支都激活后续路径的一次执行线程。虽然多条分支在图形上是合并的,但是这个多路合并并不对这些分支激活的后续线程进行任何的同步。

(2) 抽象模型描述

多路合并的Flash动画

上图中,B和C是多路选择后的分支,这样的分支可以超过两个,假设还有E、F……,这样的分支在多路选择处不进行同步,每一个分支都会激活一次D的执行,即D(B)、D(C)、D(E)……,并且这些D的线程互不干扰。

(3) 业务场景举例

报销流程,假设分为三部分:住宿费、交通费、飞机票特殊报销。可能出现的情况有:住宿费+交通费;住宿费+交通费+飞机票特殊报销;交通费;交通费+飞机票特殊报销……

流程开始,首先填写报销申请(勾选报销的内容,三种费用中选择),之后流程根据勾选的内容激活后续的填写不同报销单的分支,最后每一张报销单都需要经过审批。

如果流程引擎没有实现多路合并我们可以变相的实现上面的功能。如下图:

但上述的实现有以下的不足:

a、 重复工作量,审批分明是同一个活动,非要分多个来画;

b、 无法进行统计,若要对审批这一活动的时间、数量等信息进行统计分析,那么分成了多个活动后就难于进行统计。

c、 资源的分配,假设审批是由一个岗位来负责,且任务压力应该在这个岗位上负载均衡,那么分成了多个活动后这个资源的分配也无从着手。

(4) 含义引申

多路合并的后续路径,是一些相同行为的执行线程,这就类似于另外一种模式——多实例模式。这些线程终有一个需要同步的时候,在业务场景中,这个同步就非常的复杂,如后续步骤为制证,这种业务可以分为以下情况,我们一一举例说明:

a、 强制一对一:一个审批后的单据生成一个财务凭证,那么这些多实例的线程暂时不同步,留到后续步骤。这种管理方式是比较常见的。

b、 强制多对一:同一个报销申请产生的报销单据,需要生成在一个财务凭证上。因此在制证前就需要同步。这种管理方式是比较常见的。

c、 任意多对多:在本场景中,这个不太可能发生,但在一般的物流业务中却非常常见。假设飞机票的审批比较严格,拖得时间比较长,另外两个报销单早批了,那么先将这两个生成同一个财务凭证。这种任意性的规则,一般都是通过人来判断的。


 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号