基本控制流模式之1 :序列模式

　　摘要

　　顾名思义, 在同一个流程中,只有当前驱活动(节点)完成后后继活动才能接着进行。

　　同义词

　　时序路由, 系列路由.

　　示例

　　比如，核实账户活动之前已经先获取了信用卡详细资料,这二个活动很显然构成了序列控制模型。

　　又如，收到客户收据活动之前传票转帐活动显然是已经完成过的。

　　动机

　　序列模式作为基本构造的工作模型， 它常常被用来构造一系列连续的活动,前驱活动执行完后后继活动才接着执行。 每项活动作为整个序列的部件存在, 从一个控制流的优势上看,从一个活动到另一个活动之前没有边界条件或附带条件,因此它是比较有效率的基本工作流形式。

　　背景

　　图1 是使用Coloured Petri-Net (CPN) 形式图说明序列模型。

　　实现

　　序列模式现在已得到众多的工作流系统和商业流程语言广泛地最直接地支持。

　　问题

　　虽然几乎所有的工作流系统和商业流程建模语言都会支持序列模式, 然而, 只是在实现的表现上存在各种微妙区别, 这些分歧集中体现在如何处理在给定一个或两个不同并发流程实例环境下的个体的流转, 在本质上的这些变化的特点在于在工作流过程实施中是否提供一个安全的处理模型或者不是。 在Coloured Petri-Net (CPN)条款中 ,这相当于在过程模型中的每个位置,如图1 中所示 (即在一个流程案例中要么最多只能包含的一个令牌要么不包含一个) 。 解决方案

　　这个问题有着各种不同的处理方式。 bpmn , xpdl和UML 2.0活动图按照假设使用"令牌为本"的方法来管理流程实例并通过此方法来鉴别它们，尽管它们没有详细说明实际发生是如何实现的。

　　此外, 虽然个别令牌都被假设为是保存的,在执行的过程来说, 它可能是一项活动, 分支或聚合,并且按照适度的预期的执行着流程。

　　Staffware不理会这个问题,当一个节点或步骤收到两个(或以上)节点或步骤的接入时 , 在执行的同时, 它们简直被合并成一个单一的节点(从而导致条件) 。 COSA则采取保守型策略, 活动双方通过实施安全的过程模型,并通过禁用前驱活动之前的一个,使目前的活动,能直到后继的活动就已经完成。

　　评价标准

　　序列模型看来得到任何工作流产品的全方位地支持,它们大都提供一种方法并使之能按顺序地执行两个(或以上)的活动, 它通常是基于有向弧之间的活动或规则,并按照整体设置去执行相关顺序活动或规则。

　　产品评价

　　达到某+评级,在工作流引擎必须证明它符合每一个具体的标准。

　　实现+ / -评级,它至少必须符合所列标准之一。

　　以上二者评级如果能不能达到，则被评定为级别- 。

　　描述

　　分支成一个分支成两个或两个以上并行的分支，每个分支是并行进行的。

　　同义词

　　AND分支,并行路由, 平行分支/分叉

　　示例

　　比如,某高校完成招生活动后,同时开办学生档案和确认报名活动。又如,当一个入侵警报收到并触发派遣巡逻活动,并通知警方立即活动。再如,当客户一旦为货物付款,那么商家就将发出帐单,并同时为客户包寄货物。 　动机

　　平行分支模式允许单个节点被分叉成两个或两个以上的同步执行,而且 ,这些分支在将来的一段时间内将可能或者不会再同步。

　　背景

　　图 2 描述了平行分支的执行，活动A完成后，两个不同线程的执行被初始化成活动B和C，它们能够并发执行。

　　实现

　　在所有评审过的产品中，平行分支模式存在着隐式和显式两种流程模型。如果它是显式的, 那么平行分支是通过一个前驱和两个或两个以上的节点来构造的。 如果它是隐式的, 则是通过如下两种方式之一来实现:

　　1 )控制流可以分成两个(或两个以上)不同分支。

　　2 )平行分支所触发的活动,并没有任何附带条件。

　　在下列已经评审或的产品中, Staffware、 WebSphere MQ、 FLOWer、 COSA and iPlanet代表着隐式构造模式 ,SAP Workflow、 EPCs and BPEL则通过显示的分支构造器来实现, UML 2.0 ADs、 BPMN and XPDL则允许以上两种实现方式。

　　问题

　　尚未定义

　　解决方案

　　N/A.

　　评价标准

　　任何产品都全力支持这一模式,均提供了一种构建方式(不论明示或暗示),允许在某个流程节点的线程控制模型,它可以被分成两个或两个以上分支，并且是并行地分支。

　　产品评价

　　达到某+评级,在工作流引擎必须证明它符合每一个具体的标准。

　　实现+ / -评级,它至少必须符合所列标准之一。

　　以上二者评级如果能不能达到，则被评定为级别- 。

　　描述

　　连接的两个或更多的分支合并成为一个单一的活动或节点。

　　同义词

　　AND-Join, 相交, 同步

　　示例

　　比如，某公司在审核发票和生成发票两个活动完成后，发货活动将会紧接着执行。又如, 商店的现金盘点活动只能在商店打痒和信用卡打单汇总后完成后才能进行。

　　动机

　　同步提供了一条途径reconverging的执行线程两个或更多并行分支. 一般来说,这些分行开设一个平行分裂(分裂)的建设进程早期模型. 线程的控制是通过这一活动开展后立即同步一旦所有新任科 完成.

　　背景

　　如图3的CPN模型图很好地说明了聚合模式。

　　在此模型中包含两个重要的背景条件:

　　( 1 )每一个引入的分支通过给定的案例精确地执行着。

　　( 2 )一旦引入的分支已完成, 同步者能够复位和重新运作。 这些条件很重要,因为如果所有引入的分支没有完整, 那么同步将产生死锁,如果每个分支收到多于一个的触发, 那么构造行为将是未定义的。 如果没有了这些限制,这些问题反而会成为大问题。

　　实现

　　如同平行分支模式一样，聚合同步模式也有两种处理模型：隐式的和显式的。

　　Staffware 和SAP Workflowm EPCs, BPMN, and XPDL均是显式的AND-Join构造器实现。 其他提供商如WebSphere MQ, FLOWer, COSA, iPlanet 和BPEL是种隐式构造模式 ,它通过多种的无条件的引入分支连接控制到活动上,仅当这些弧线的每个活动收到分支控制引入时此活动才被激活, UML 2.0 ADs则同时支持以上两种实现方式。

　　问题

　　使用同步模式,有可能会导致一种死锁的情况出现,分支构造因为种种原因未能如愿建立起来， 这可能会产生的后果之一是处于并行之一的活动,未能成功地完成或者是因为线程的控制没有在分支范围之内。

　　解决方案

　　你或许知道，目前尚未有工作流系统或业务流程执行语言提供解决这方面问题的明确支持,这方面的问题是因为一个引入的分支所造成的活动失败,但其结构性的性质一般能够保证可能造成的死锁并不存在。

　　评价标准

　　目前所有提供商对此种模式提供了全力支持，它们一般会提供一个构造器把几种执行的分支合并为独一的分支。这种合并行为反生在当它收到了任一引入分支的消息后。

　　产品评价

　　达到某+评级,在工作流引擎必须证明它符合每一个具体的标准。

　　实现+ / -评级,它至少必须符合所列标准之一。

　　以上二者评级如果能不能达到，则被评定为级别。