一种支持简便重构的过程元模型*

李 新,许元坤

(汕头大学工学院,广东 汕头 515063)

1 引言

业务过程系统的出现对企业的经营和管理产生了深刻的影响，使企业能够在计算机的支持下进行异步、松散耦合的协同信息处理，将企业的经营管理技术提升到了过程管理自动化的阶段。在业务过程系统的发展中，工作流(Workflow)概念的提出具有重要意义[1]。

工作流对业务过程进行了抽象化处理，将业务过程中各步骤之间的逻辑关系抽取出来，称为过程逻辑。与之相对应，业务自身的个体特性称为业务逻辑。工作流的核心理念在于“过程逻辑与业务逻辑分离”，工作流管理系统WFMS(WorkFlow Management System)是实现这一理念的软件平台，即工作流管理系统为过程逻辑的自动化处理提供支持。

建筑于工作流基础之上的业务过程系统一方面可以显著提高系统的开发效率，另一方面，当业务过程系统需要重构的时候，得益于两种逻辑的分离，可以使重构的任务大为简化。然而，随着工作流应用的日益扩大和不断深入，人们发现“过程逻辑与业务逻辑分离”这一理想中的目标与现实中的实际情况具有相当大的差距。实际的情况常常是过程逻辑与业务逻辑以各种形式耦合在一起难于分离。以常见的公文审批为例，一份公文需要签署多人的意见，在某一时刻，当前不同的审批结果将导向不同的执行路径。公文的审批意见属于业务特性的范畴，而审批过程的执行则属于过程特性的范畴，显而易见，两种性质是密切相关的。过程-业务间的耦合是大量的业务过程的固有属性，其形态多种多样，对工作流中“过程逻辑与业务逻辑分离”的实现构成了巨大的挑战。

过程逻辑与业务逻辑难于分离的现状对工作流系统的应用和推广造成了很多困难，已经成为工作流技术发展的瓶颈[2]。两种逻辑的混叠使得工作流建模复杂，需要在过程模型中额外增加许多业务特性的描述，而由于工作流管理系统对于过程-业务间耦合问题的考虑不足，很多时候甚至无法对其进行规范化的描述。同时，过程的建模方法又直接影响着过程重构的实施，当业务过程面临重构的需求时，复杂和不规范的过程模型将导致重构工作不易进行，并且使得重构任务变得十分繁重。本文针对上述问题，对过程模型中业务元素的规范化表示进行了研究，提出了新的过程模型方法，在此基础上，进一步支持过程的简便重构。

2 相关工作与问题分析

对于因过程-业务间的耦合而引起的过程不确定性问题，长期以来，研究者从不同角度对其进行了多方面的研究，并且在工作流的基础上进一步提出了“柔性工作流”的概念[3]，所谓“柔性”是指工作流系统能够在动态变化甚至信息不完整的情况下处理和应对业务过程的变更和异常的能力。柔性工作流的研究主要包括两方面的内容：柔性策略和柔性模型。前者往往在特定的过程模型下，针对若干柔性问题的需求，研究过程路径的柔性选择、过程结构的动态修改以及过程的异常处理等方案策略[4～6]；后者则试图建立支持柔性工作流的新的过程模型与软件体系结构[7,8]。两方面的研究内容是相互支撑的，柔性策略可以为柔性模型提供具体的技术方案，而柔性模型则可以为柔性策略的实现提供理论方法等基础层面的支持。

工作流技术的软件平台—工作流管理系统正越来越多地增加了对柔性工作流的支持，如IBM的WebSphere MQ工作流产品使用数据映射的方式以更好地构建业务过程模型，METEOR(Managing End-To-End OpeRations)系统部分支持执行路径的柔性选择并具有一定的异常处理能力，Agentwork系统使用了基于规则的柔性建模方法[9]，InWoLvE工作流挖掘系统采用数据挖掘和机器学习技术进行工作流建模，以提高过程对业务环境的适应性[10]，清华大学的CIMFlow工作流管理系统提供了分布式的自适应任务调度方法[11]等。

从研究现状来看，柔性工作流的发展正处于“百花齐放”的局面，针对不同的问题，不断有新的策略和模型提出。然而，就目前的研究结果而言，该领域尚远未达到成熟的阶段，许多问题还没有在业界形成一致的看法。本文认为，对于柔性工作流，至少有以下几个方面的问题值得进一步探讨：

(1)许多柔性工作流系统采用了“刚性+柔性”的组合策略，即对于刚性过程使用WFMC等传统模型，而对于不确定性过程，用另一套柔性技术方案作为补充。系统中实际存在着相互分离的两种甚至多种过程模型和建模方法，这使得过程建模的复杂程度大大提高，同时，随着系统的扩展，工作流系统本身的复杂度也会显著上升。相对而言，如果能够采用统一的模型方法，支持各种形式的过程建模，将是一种更好的选择。

(2)工作流管理系统的过程逻辑的表达能力仍然有所欠缺，工作流中过程逻辑的表示主要依据的是工作流模式，而工作流模式种类繁多，某一种工作流管理系统通常只支持其中一部分的工作流模式。实际上，即便有一种工作流管理系统可以支持所有的工作流模式，依然无法满足应用中许多过程逻辑表示的需求。因此，能否考虑改变将工作流模式看做一个整体的传统观点，而代之以一种“逻辑组合”的方式来构造工作流模式，既可以提高过程逻辑的表达能力，又可以增强表示方法的灵活性。

(3)现有系统对过程-业务间的耦合问题的考虑明显不足，业务元素对过程逻辑的影响是多方面的，目前尚缺乏对这一问题的系统化的分析和总结。另外，许多系统没有建立起对业务元素抽象描述的有效手段，导致系统中过程逻辑和业务逻辑的界线变得模糊不清，相互之间交织重叠。同时，受业务元素的影响，对过程逻辑的处理没有严格按照“定义-解释”的执行机制，而是大量采用了程序代码的方式，使得过程重构时需要重新编译系统，重构任务繁重。

这几点问题均与过程重构密切相关，下文将围绕这些问题对过程模型和过程重构的内容做进一步的阐述。

3 过程逻辑

首先给出与业务过程相关的若干定义。

定义1(业务过程) 业务过程是一组按照特定逻辑关系组织在一起的一组业务活动的总体。业务过程可以表示为一个三元组，BP=〈B,P,A〉，其中BP为业务过程，B为业务活动的集合，P为活动间过程逻辑的集合，A为业务元素对过程逻辑的作用，即过程-业务的动态关联的集合。

定义2(过程-业务的动态关联) 业务元素的取值或结构与过程逻辑相关，并且，只有在过程的运行期才能获取其数值及结构，将这种过程与业务间的相关性称为过程-业务的动态关联。设业务元素的集合为BS，BS的幂集为BSPS，过程逻辑的集合为P，则过程-业务的动态关联集合A可表示为BSPS和P上的关系，即A：BSPS↔P。

定义3(纯过程逻辑) 某个过程逻辑，如果其中不含有任何与业务元素相关的内容，则称该过程逻辑为纯过程逻辑。对于只含有纯过程逻辑的业务过程BP来说，相当于上述表示业务元素对过程逻辑的作用的集合A为空集，即A=∅。

对于纯过程逻辑而言，业务过程中的活动在工作流中只具有抽象状态，而不具有个性化的业务状态。例如，可以为活动设置以下的基本状态：启动、运行、挂起、完成(正常提交)和中止(异常停止)等，活动间过程逻辑的表示仅使用这些抽象的状态。图1显示了两种常见的工作流模式：顺序模式和并行分支模式，这两种模式均属于纯过程逻辑，当前一个活动状态为完成时，后一个或者后一组活动可以开始启动。

Figure 1 Schematic diagram of pure process logic图1 纯过程逻辑示意图

按照定义1～定义3的叙述，可以将一个业务过程的内容划分为三个组成部分：纯过程逻辑、过程-业务动态关联的过程逻辑和业务逻辑。与以往的划分方法相比，本文对过程逻辑进行了进一步的细分，突出了过程-业务动态的关联这一要素，之所以这样做是因为该要素与过程的建模及过程重构等问题具有直接的、密切的联系。

图2是一个简单的业务过程片断，其描述如下：首先用户填写维修申请；然后，由业务员对申请审核提交；系统根据申请表中的数据进行判断，如果申请维修的日期在货物出售一个月以内，则予以免费更换；如果属于电脑主机部件，且时间在一个月到三年之间，则予以免费维修；如果属于外设部件，且时间在一个月到一年之间，则予以免费维修；此外，进行收费维修。

Figure 2 Schematic diagram of the process of computer maintenance图2 电脑维修业务过程片段示意图

该业务过程片断包含了两组过程逻辑：从“维修申请”活动到“申请审核”活动之间是顺序逻辑，属于纯过程逻辑；而从“申请审核”到三个具体的“维修”活动之间是选择逻辑，选择的因素为货物类型、售出时间等业务元素，因此，这一过程逻辑属于过程-业务动态关联的过程逻辑。

当业务环境和用户需求等发生变化时，需要对业务过程系统进行变更或重新设计来适应这种变化，这称为业务过程系统的重构。按照本文对业务过程内容的划分，可以将业务过程系统的重构分解为与之对应的三个方面：纯过程逻辑的重构、过程-业务动态关联的过程逻辑的重构和业务逻辑的重构，其中，前两者属于过程逻辑的范畴，而后一个则与过程结构无关。由此，本文提出以下定义。

定义4(过程重构) 业务过程系统中任何与过程逻辑相关的重构称为过程重构。

业务过程系统的重构内容如图3所示。

Figure 3 Schematic diagram of the content of process reconfiguration图3 业务过程系统的重构内容示意图

本文讨论的主题是过程重构，业务逻辑的重构完全属于应用程序内部的问题，不在本文讨论范围之内。

4 WFMC模型与柔性工作流

WFMC的过程元模型是工作流领域具有权威地位的一种模型，该模型如图4所示。

Figure 4 Schematic diagram of WFMC process meta-model图4 WFMC过程元模型示意图

在这个元模型中，WFMC定义了过程的基本元素及其相互间的关系，其中有两个元素值得关注：工作流相关数据和转移条件。工作流相关数据是跨越在过程逻辑和业务逻辑之间的一种元素，它属于业务性的数据，但同时又在过程逻辑的表示中被使用；转移条件是活动的组成部分，可以表示活动之间的转移关系，在转移活动中对工作流相关数据进行了引用。从第3节的叙述可以看出，工作流相关数据和转移条件的作用正是用于表达本文所提出的过程-业务动态关联方面的内容。然而，在WFMC的模型中，对于转移条件和工作流相关数据的细节却并未制定具体的规范，具体表现在：

(1)没有对工作流相关数据的形式做出规范；

(2)没有对工作流相关数据的使用和引用方法做出规范；

(3)没有对转移条件的形式做出规范；

(4)没有对活动中如何放置转移条件做出规范。

由此可知，WFMC模型对于工作流相关数据和转移条件的约定是极为宽松的。这种宽松的形式为工作流管理系统在业务过程的设计和实现上留下了自由发展的空间，但另一方面，也连带地导致了业务过程设计和实现上的随意性乃至混乱的局面。随着企业业务过程复杂度的提高和过程重构频繁度的上升，这种随意性的负面作用变得越来越明显，过程-业务的动态关联往往以过程逻辑和业务逻辑紧密耦合的形式来表示(而且绝大多数时候采用的是程序代码的形式)，同时，由于设计开发人员的“随意发挥”，即便是在同一种工作流管理系统之下，不同人员对于业务过程的实现方法也会呈现出较大的差别。下面以图2中“申请审核”活动到“免费更换”、“免费维修”和“收费维修”三个活动之间的过程逻辑的实现方法来阐述这一问题，基于WFMC元模型的工作流系统的示意性实现方法如下：

duration=presentdate()-application.getsaledate();

if (duration≤1 month ) thenflowobj.start(ActFreechg)；

…∥其它业务处理代码

componenttype=application.gettype();

if ((componenttypeismaincomponente) and (duration>1 month) and (duration≤3 years))

thenflowobj.start(ActFreerep)；

…∥其它业务处理代码

if ((componenttypeisexternalcomponente) and (duration>1 month) and (duration≤1 year))

thenflowobj.start(ActFreerep)；

…∥其它业务处理代码

flowobj.start(ActChargerep)；

其中，duration和componenttype是工作流相关数据，表示货物出售时间和货物类型；if语句为转移条件，ActXXX为活动，工作流管理系统提供了start方法用于启动活动。

在上述代码中，业务处理和转移条件是交织在一起的，过程逻辑和业务逻辑紧密耦合，因为工作流管理系统并没有提供将两种逻辑分离的指导原则和技术手段。

柔性工作流注意到了传统的工作流系统中所存在的问题，对过程-业务动态关联内容的表达进行了部分的规范，例如ECA(Event，Condition，Action)规则等方法，提出将规则(相当于WFMC模型中的转移条件)单独进行放置，并由事件进行驱动。柔性工作流系统对图2中的过程逻辑的示意性实现方法如下，

业务处理模块：

duration=presentdate()-application.getsaledate();

componenttype=application.getcomponent();

…∥其它业务处理代码

过程逻辑模块(业务规则)：

if (duration≤1 month) thenflowobj.start(ActFreechg)

…∥其它规则

与传统的工作流系统相比，柔性工作流系统对过程-业务动态关联的过程逻辑在形式上进行了适当的分离，业务逻辑与过程逻辑的代码分别处于不同的模块中。同时，在一种系统内部，业务规则的表达也具有较为规范的形式。然而，应该注意到柔性工作流对过程逻辑和业务逻辑的分离仍然是有限的，业务数据直接嵌入在业务规则的语句中，也就是说，工作流相关数据所引起的过程逻辑和业务逻辑紧密耦合的现象并未得到根本改变，并且，柔性工作流依然使用程序代码的方式实现业务规则，并继续将业务规则作为活动的一部分包含在活动中，这些都对可能发生的过程重构造成负面的影响。

5 过程重构

假定图2中的业务过程发生了以下改变：

(1)需要两个业务员同时对“维修申请”进行审核，两份审核均通过才能进入维修环节。

(2)维修条例将免费更换的时间延长为三个月，免费维修的时间也据此做相应改变，其它不变。即申请维修的日期在货物出售三个月以内，则予以免费更换；如果属于电脑主机部件，且时间在三个月到三年之间，予以免费维修；如果属于外设部件，且时间在三个月到一年之间，则予以免费维修。

以上两个变化涉及到图2中两个过程逻辑的变化，因此该问题属于过程重构。对于基于WFMC元模型的工作流系统，重构内容如下：

(1)需要将“维修申请”活动到“申请审核”活动之间的顺序模式改为并行分支模式。

(2)由于有两个并行的“审核”活动，因此，需要添加一个汇聚活动使两个并行活动会合，采用的工作流模式为同步模式。

(3)需要修改涉及到货物出售时间的有关程序代码，将“一个月”改为“三个月”。

(4)把第4节中用于选择“免费更换”、“免费维修”和“收费维修”三个活动的if语句从“申请审核”活动中移走，放置到“汇聚”活动中。这是因为在重构后的业务过程中，“申请审核”活动的功能变为单一的人工审核，而选择“免费更换”、“免费维修”和“收费维修”的任务从“申请审核”活动转移到了“汇聚”活动。

上述(1)和(2)可以通过修改过程定义来完成，(3)和(4)则需要通过修改程序代码来完成。重构后的业务过程如图5所示。

Figure 5 Schematic diagram of process structure after process reconfiguration图5 过程重构后的过程结构示意图

由以上实例可知，基于WFMC元模型的工作流系统在过程重构时，不仅需要改变过程定义，而且往往不得不对程序代码进行修改。

柔性工作流比起传统的工作流系统在过程重构上所取得的进步极为有限。以本文所示的实例而言，柔性工作流系统所要执行的重构任务和传统的工作流系统大致相同，区别只在于柔性工作流的业务规则被放置在单独的程序模块中，在做代码修改的时候，可以更加快速、准确地对修改部分定位以及避免代码间的交叉影响。

从广义上讲，业务过程系统的重构属于软件重构的范畴，可以应用一般的软件重构技术方法。但是，业务过程系统的重构又存在着其特殊性的一面，首先，业务过程系统通常具有较大的规模，整个系统的设计、开发和部署会耗费大量的人力物力，所以，业务过程系统的重构应尽量避免“牵一发而动全局”的情况，希望将系统的变动局限在尽可能小的范围内，即偏向于“局部重构”的策略；其次，业务过程系统通常涉及到多种业务处理的组合，来自任何一个环节的变化都有可能引发过程的重构，也就是说，比起一般的应用系统，业务过程系统有可能会较多地遭遇重构的需求，导致重构的频率显著上升。

修改程序代码是一般的软件系统重构常用的方法，进行代码重构时，必然要经历以下阶段：代码重写、编译、连接和部署，整个过程需要耗费较大的人力物力。并且修改程序代码还需要一个基本的前提，就是能够获取到程序源代码，对于业务过程系统而言，通常用户都不具备这一条件，因此，必须有软件供应商的参与、协助才能开展代码重构工作。

由以上分析可知，过程重构的频繁性和采用修改程序代码的过程重构方式之间形成了一种难以调和的矛盾。事实上情况正是如此，例如，ERP就是一种基于工作流的业务过程系统。以当前最具有代表性的ERP产品—SAP而言，用户若要进行系统重构是一件相当困难的任务，必须在SAP技术人员的全程指导和支援下才能开展此类工作，并且代价高昂，又极为耗时、耗力。

工作流的概念提出的时候，对过程重构的问题有过认真的考虑，“过程逻辑与业务逻辑分离”的理念和将过程的定义与过程执行阶段分开的技术方法都遵循的是降低过程重构复杂度的原则。可是，受限于过程逻辑表达能力和系统运行机制的限制，以往的方法难以处理过程-业务动态关联的情况，使得过程逻辑很多时候无法用过程定义而是要用程序代码的方式实现，造成了业务过程模型复杂和过程重构不易实施的局面。

本文针对这一问题，提出了简便重构的概念。

定义5(简便重构) 通过过程定义的方式或以过程定义为主的方式所进行的与业务逻辑有效隔离的过程重构，称为过程的简便重构。

上述定义强调了两个方面：

(1)过程重构应以过程定义为主，尽量不涉及到程序代码的修改。

(2)在过程逻辑和业务逻辑之间应当建立起有效的隔离机制，降低两者的耦合度。

从目前的情况来看，无论是基于WFMC模型的传统工作流系统，还是其后加入“柔性”策略的柔性工作流系统，均不具备简便重构的条件；其根本原因在于，它们的过程元模型和系统框架都没有对过程-业务动态关联的因素予以充分考虑。

6 一种新的过程元模型

本文认为，“刚性+柔性”的组合模式仅仅是工作流发展过程中的一种过渡形式，最终应该在过程的元模型中吸收进各种“柔性”的要素，使得“柔性”成为过程模型方法的内在特性。过程的简便重构不是一个孤立的问题，它是系统本身具备强有力的过程逻辑表达能力和处理能力的一种体现。

在上文中，对WFMC元模型和柔性工作流所存在的问题进行了初步的分析，下面进一步讨论与过程逻辑相关的若干问题。

(1)工作流模式的问题。

工作流模式是过程逻辑的抽象表达形式，现有的工作流技术将工作流模式作为一个整体的单元进行处理，这种方法造成的一个结果就是工作流模式种类繁多，随着过程逻辑复杂程度的提高，模式类型的数量呈爆炸式增长。事实上，过程逻辑作为活动间的关系，可以被分解为更基础的单元，如图6所示。

Figure 6 Schematic diagram of the decomposition of process logic图6 过程逻辑分解示意图

图6中存在两组活动的集合：活动集1和活动集2。活动集1经过某种逻辑进行汇合，然后又经过另一种逻辑分支转移到活动集2。而汇合逻辑与分支逻辑的组合即为过去被看做一个整体单元的工作流模式。从逻辑学的角度而言，汇合逻辑和分支逻辑并没有什么区别，两者可以采用完全一致的逻辑表达形式，只是其中的内容有所分别，汇合逻辑中的内容是活动的状态，而分支逻辑中的内容是活动的动作。假定逻辑形态的数量为N，则汇合逻辑与分支逻辑的组合数为N2，即过程逻辑(工作流模式)的类型数理论上为N2。因此，将工作流模式分解为汇合逻辑和分支逻辑可以有效解决单一的工作流模式“组合爆炸”的问题。过程逻辑分解的另一个好处在于，可以对过程逻辑的性质进行更加细致的分析，对其逻辑特征进行更好的抽象。

(2)过程逻辑表达形式统一的问题。

现有的工作流模式在表达过程逻辑时有一个限制，只能在纯过程逻辑的范围内，而过程-业务动态关联的过程逻辑则是用程序代码另外描述的；仅有前者采用的是过程定义的方式。事实上，纯过程逻辑和过程-业务动态关联的过程逻辑的区别不在于逻辑特性本身，而在于逻辑中所包含的具体成分：在纯过程逻辑中，是过程、活动的抽象内容，而在过程-业务动态关联的过程逻辑中，是与业务处理相关的内容。因此，在对业务元素进行抽象映射的处理后，两者在表达形式上可以统一，都能够采用过程定义的方式加以实现。

(3)转移条件的问题。

WFMC元模型把转移条件放置在活动内部，这在某种程度上来说是不合理的。转移条件表达的是活动间的转移关系，在层次上应处于和活动平行的地位，而不是从属于活动。现有的方式造成的一个直接的结果就是，转移条件无法表达多个活动的汇合，当汇合时，必须额外引进一个汇聚活动，图5即为一例。

(4)工作流相关数据的问题。

工作流相关数据本质上反映的是活动的业务状态，既与业务处理相关，又与过程逻辑相关，对它的形式和使用方式应该做出严格限定。在系统中，原有的工作流相关数据需要被分解为两个实体，一个是业务处理中的程序数据，另一个是过程逻辑中的过程定义数据，两个实体间可以通过映射的方式建立联系。

基于以上对WFMC元模型与现有工作流技术的分析，并吸取了在工作流系统中运用事件机制的思路(文献[4，12～14])，本文提出了一种新的过程元模型—ESR元模型，图7显示了该元模型的基本组成和结构。

Figure 7 Schematic diagram of ESR meta-model图7 ESR元模型示意图

对比图4和图7可以看到，在新的过程元模型中，去除了原先缺乏细节规范的工作流相关数据和转移条件两项元素，增加了事件、状态和规则三项新的元素。

定义6(事件) 事件是业务过程系统中对所发生的行为的抽象，事件可用一个三元组表示：Event=〈eID,eName,RuleGroup〉，eID为事件的标示，eName为事件的名称，RuleGroup为事件所关联的规则群。

过程和活动均可拥有事件，按照事件是否与具体业务相关，又可将事件分为系统事件和业务事件，比如：过程暂停和活动完成可表示为系统事件，某项业务中的数据表格填写完毕可表示为业务事件。系统事件属于“纯过程逻辑”的范畴，对任何类型的业务过程均适用，因此在工作流管理系统中采用预定义的方式设定。而业务事件则随业务处理的需求而定，可在业务过程模型中由开发人员自行定义。尽管概念上存在着差别，但系统事件和业务事件的表达形式是完全一致的，并且，工作流管理系统对两种事件也采用了完全相同的处理方式。

定义7(状态) 状态是业务过程系统中对形态、状况的抽象。状态可用一个四元组表示：State=〈sID,sName,sDomain,sMap,Value〉，sID为状态标示，sName为状态名，sDomain为状态取值范围，sMap为状态与业务数据的映射关系，Value为状态的取值。

过程、活动和角色均可拥有状态，与事件类似，状态也可分为系统状态和业务状态两类，比如，活动的就绪、执行、挂起和完成等属于系统状态，而上文例子中货物出售时间则可表示为业务状态。

事实上，在以往的工作流系统中已经存在状态的概念，但是与本文中的状态相比，有以下几点不同：

(1)WFMC元模型并未把状态作为一种标准的模型元素来看待。

(2)以往工作流系统中的状态基本属于“纯过程逻辑”的范畴，仅相当于本文中的系统状态。

(3)以往工作流系统中的状态为系统预定义状态，无法由用户自行定义扩展。

(4)状态变化的处理方法对用户透明，用户无法根据业务需求干涉和改变处理过程。

从概念上说，ESR元模型中的状态覆盖了以往工作流中状态和工作流相关数据两个方面的内容，同时在表达形式和使用方法上进行了规范、统一。

定义8(规则) 规则是ESR(Event-State-Rule)元模型中过程逻辑的表达形式，规则可用一个二元组表示:Rule=〈P,Q〉，P是规则的前提，Q是规则的结果，习惯上，将以上的二元组表达为P→Q的形式。

P是基于状态的逻辑表达式，用于表示图6中的汇合逻辑，其形式化描述如下:

P∷=AθA

A∷=Activity.State|Constant|F|Count(P(,P)*) |others

P∷=～P|PΦP|(P)

θ∷=‘>’|‘<’|‘=’|‘≥’|‘≤’|‘≠’

Φ∷=‘∧’|‘∨’|‘⊕’

F∷=Founc()|Founc(A(,A)*)

其中，θ为比较运算符；Ψ和Φ为逻辑运算符，∧、∨、⊕、～分别表示与、或、异或和否定运算；Activity表示活动，A为数据，数据的形式有状态(State)、常数(Constant)和函数返回值(F、Count);Founc为一般函数;Count是计数函数，其参数为若干逻辑表达式，返回值为逻辑值为“真”的逻辑表达式个数。假定P1、P2、P3为逻辑表达式，P1=True，P2=True，P3=False，则Count(P1,P2,P3)的返回值为2，Count函数的作用是提供一种“多选逻辑”，这是业务过程中广泛存在的一种逻辑，比如，项目评审中的投票表决等；others为保留字，表示一个规则群中其它规则都不满足时的情况。

Q是基于动作的逻辑表达式，用于表示图6中的分支逻辑，其形式化描述如下：

Value∷=Activity.State|Constant|F|Count(Q(,Q)*)

Q∷=Activity.F|SetState(Activity.State,Value)|ValueθValue

F∷=Founc()|Founc(Value(,Value)*)

Q∷=QΦQ|(Q)

θ∷=‘>’|‘<’|‘=’|‘≥’|‘≤’|‘≠’

Φ∷=‘∧’|‘∨’|‘⊕’

其中，Φ为逻辑运算符，含义和上面相同；Activity表示活动，F为活动中的动作(函数)；SetState是状态设置函数，将值Value赋予状态State；Value为数据，可以是另一个状态当前的取值(作用相当于变量)，常数(Constant)或者函数的返回值；Founc为函数，函数有返回值，并且可以带有参数。

Q具有和P类似的文法结构，只是其逻辑关系和P相比简单一些，因此在系统实现时，只需要做出一种模型解释器，即可同时解释规则的前提和结果。

一组相关的规则组织在一起形成一个规则群，而规则群与事件相关联，由特定的事件触发规则的匹配。这种机制实质上体现的是“数据驱动”的思路，即由系统状态的变化驱动过程的控制，实现活动间的转移。

7 基于ESR元模型的工作流模型框架和业务过程建模方法

7.1 工作流模型框架

过程-业务的动态关联是业务过程的内在属性，对这一问题的处理方法很大程度上决定了工作流系统对过程逻辑与业务逻辑的分离程度。在以往的工作流系统中，对于过程逻辑与业务逻辑的界限时常处于并不明确的状态，导致两种逻辑很多时候以高耦合度的方式呈现，第4节中的例子对此已有说明。

ESR元模型确立了一种新的工作流模型框架，其主要内容包括：

(1)状态映射将与过程逻辑相关的业务数据映射为业务状态。

(2)逻辑规则形式的过程逻辑表示方法，并且采用数据化的方式对逻辑规则进行存储。

(3)事件机制：由事件触发逻辑规则的匹配，实施过程控制。

这一模型框架清晰划分了过程逻辑与业务逻辑之间的界限，明确了过程定义和程序代码的使用范围，其概况如图8所示，图中横线的下方属于业务逻辑的范畴，采用程序代码的方式实现；横线的上方属于过程逻辑的范畴(包含过程-业务的动态关联)，采用过程定义的方式实现。过程定义中除了传统的图形化过程结构定义之外，还包括事件定义、状态定义、状态映射定义和逻辑规则定义等，过程定义形成的业务过程模型以数据化的形式存储在计算机中，由模型解释器在过程的运行期解释执行。

Figure 8 Schematic diagram of workflow framework on ESR meta-model图8 基于ESR元模型的工作流模型框架示意图

7.2 过程建模方法

基于ESR元模型的过程建模大致分为以下几个步骤：

(1)过程结构图定义，描述过程的基本结构。和传统的过程结构图相比，这里的过程结构图增加了一项新的图形元素—规则群。

(2)事件、状态与状态映射定义。对于过程-业务动态关联的情况，可以由用户定义与业务相关的事件和状态；对于纯过程逻辑，则仅使用系统预定义的事件和状态。

(3)规则与规则群定义：描述过程逻辑的细节以及规则与事件的对应关系。

下面针对典型的过程逻辑形态，分别叙述基于ESR元模型的过程建模方法。

7.3 顺序逻辑建模

顺序逻辑是最简单的过程逻辑形态，其过程结构图如图9所示。

Figure 9 Structure diagram of the process for sequence logic图9 顺序逻辑过程结构图

与以往的过程结构图仅有活动不同，图9的过程结构图中还包含了位于活动间的规则群，设图9中的规则群记为RG，RG中的规则由活动1预定义的提交事件触发，设eActcommit为活动提交事件的名称，则事件与规则群挂接的定义形式为：

Act1.eActcommit→RG

顺序逻辑为纯过程逻辑，活动1结束后活动2开始执行，因此无须定义业务状态。设finished为系统状态，表示活动完成；start()为系统方法，表示活动的启动，则规则定义为：

Rule:Act1.finished→Act2.start()

规则Rule放置在规则群RG中，挂接在规则群上的事件触发规则群中规则的匹配，如果系统的状态使某个规则的前提为真，则由该规则的结果确定后续需要执行的活动和动作；经过模型解释器对规则的解释，工作流管理系统即可实施相应的过程控制。

7.4 分支/并行逻辑建模

分支/并行逻辑是工作流中较为复杂的一类逻辑形态，它的具体形式多种多样，按照分支的个数可以划分为单路分支(异或)和多路分支(并行)两大类，而多路分支还可以具有不同的逻辑关系。分支/并行逻辑的过程结构图如图10所示。

Figure 10 Structure diagram of the process for parallel/split logic图10 分支/并行逻辑过程结构图

下面按照不同的逻辑关系分别对各种不同的分支/并行逻辑形态进行描述。

D.1 单路分支(异或)

事件与规则群的挂接与前边相同，不再复述(以下仅叙述规则定义)，规则定义为：

Rule:Act1.finished→Act21.start()⊕ …⊕Act2n.start()

D.2 与分支(n路并行)

规则定义为：

Rule:Act1.finished→Act21.start()∧…∧Act2n.start()

D.3 或分支(1—n路并行)

规则定义为：

Rule:Act1.finished→Act21.start()∨…∨Act2n.start()

D.4m路选择分支(m路并行)

从m个分支中选择n路执行，规则定义为:

Rule:Act1.finished→

count(Act21.start()∨…∨Act2n.start())=m

D.5 混合分支

分支中不止一种逻辑，而是多种逻辑的组合，例如，将活动21～活动2n分成两组，活动21～活动24为一组，活动25～活动2n为另一组，两组之间为异或关系，组内为与并行方式,规则定义为:

Rule:Act1.finished→(Act21.start()∧…∧Act24.start())⊕(Act25.start()∧…∧Act2m.start())

可以看出，使用逻辑规则的方式能够灵活一致地灵活表示各种形态的分支/并行逻辑。与此相反，在以往的工作流模式方法中，通常无法直接表达混合分支的情形，往往需要借助于程序代码才能进行此类描述，这无疑增加了过程建模和过程重构的复杂度。

7.5 汇合逻辑建模

汇合是与分支相对应的一类过程逻辑形态，分支逻辑与汇合逻辑一起构成了完整的分支/并行路径。汇合逻辑的过程结构图如图11所示。

Figure 11 Structure diagram of the process for merge logic图11 汇合逻辑过程结构图

从逻辑运算的角度来看，汇合逻辑与分支逻辑具有类似的形式，下面按照不同的逻辑关系分别对各种不同的汇合逻辑形态进行描述。

E.1 单路汇合(异或)

此时，规则群RG可由活动11～活动1n中任何一个的提交事件触发，事件与规则群挂接的定义形式为:

Act11.eActcommit→RG

…

Act1n.eActcommit→RG

规则定义为:

Rule:Act11.finished⊕…⊕Act1n.finished→Act2.start()

E.2 与汇合(n路汇合)

事件与规则群的挂接与E.1相同，不再复述(以下仅叙述规则定义)，规则定义为:

Rule:Act11.finished∧…∧Act1n.finished→Act2.start()

E.3 或汇合(1-n路汇合)

规则定义为:

Rule:Act11.finished∨…∨Act1n.finished→Act2.start()

E.4m路选择汇合(m路汇合)

规则定义为:

Rule:count(Act11.finished, …,Act1n.finished)=m

→Act2.start()

E.5 混合汇合

汇合中不止一种逻辑，而是多种逻辑的组合，例如，将活动11～活动1n分成两组，活动11～活动14为一组，活动15～活动1n为另一组，两组之间为异或关系，组内为与汇合方式,规则定义为:

Rule:(Act11.finished∧…∧Act14.finished)⊕(Act15.finished∧…∧Act1n.finished)→Act2.start()

与分支类似，以往工作流模式的方法通常无法直接表达混合汇合的情形，往往需要借助于程序代码才能进行此类描述，而本文的逻辑方法却可以对此灵活地加以定义。

值得指出的是，以上的汇合逻辑规定活动2仅执行一次，当活动2执行之后，规则群RG将不被触发，即新的活动1x的完成不会再引起RG中规则的匹配。假使活动2需要多次执行，则需要对本文现有的规则文法进行修改，增加新的语法元素用于描述活动2多次执行的有关内容。

7.6 汇合-分支组合逻辑建模

ESR元模型将规则置于与活动平行的地位，除了概念上更加合理之外，另一个积极的效果就是无须引入汇聚活动(见图5)，即可直接表示汇合-分支组合逻辑。汇合-分支组合逻辑的过程结构图如图12所示。

Figure 12 Structure diagram of the process for the composition of merge and split logic图12 汇合-分支组合逻辑过程结构图

假定以上过程逻辑中汇聚为与的方式，而分支为异或方式，则事件与规则群挂接的定义形式为:

Act11.eActcommit→RG

…

Act1n.eActcommit→RG

规则定义为:

Rule:Act11.finished∧…∧Act1n.finished→

Act21.start()⊕ …⊕Act2m.start()

并且与D.5和E.5中所述类似，汇合-分支组合逻辑中的汇合与分支也可以是混合逻辑的形式。显然，在目前的工作流管理系统中，完全无法象本文这样直接表示此类过程逻辑形态。

7.7 循环逻辑建模

一般来说，工作流中的循环比起结构化程序设计中的循环会复杂得多，这源于以下两个原因：

(1)工作流中不建议强制采用“单入单出”的循环结构，以避免给用户带来太多的约束。

(2)工作流的活动不能简单抽象为程序中的语句，因为活动有时并非能够看做整体的执行单元。

考虑到工作流中循环的随意性，本文对工作流的循环采用了类似于“Goto语句”的方式进行表示，将循环看做分支逻辑与汇合逻辑相结合的一种特例。

图13是一个带有循环的过程结构图，活动3执行完后会根据不同的情况转移到不同的活动，其中，转移到活动1和活动2将构成循环。为简练起见，以下仅叙述和循环有关的内容。

图13中，RG31、RG32和RG33为规则群，它们均由活动3的提交事件触发，事件与规则群挂接的定义形式为：

Act3.eActcommit→RG31

Act3.eActcommit→RG32

Act3.eActcommit→RG33

Figure 13 Structure diagram of the process with the cycle图13 带有循环的过程结构图

与前面的分支不同，这里的分支通常与业务状态相关，即活动3完成后走哪一路分支取决于活动3的当前业务状态值，因此需要定义一个用于表示循环的业务状态，记为Act3.itr，并且需要定义该状态与业务元素之间的映射关系ff：

ff(Act3.业务元素*)→Act3.itr

RG31中的规则为:

Rule:Act3.finished∧Act3.itr=1→Act1.start()

RG32中的规则为:

Rule:Act3.finished∧Act3.itr=2→Act2.func()

RG33中的规则为:

Rule:Act3.finished∧Act3.itr=3→Act4.start()

由以上定义可知，虽然Act3.eActcommit事件会同时触发三个规则群，但是业务状态Act3.itr使得仅有一个分支得以执行。RG32中的规则表示，循环时活动2并非简单地被启动，而是执行该活动中一个特定的方法func()，这体现了ESR模型具有将业务方法融合进规则表示的能力。

循环逻辑的挑战更多地来自于活动的实例化，一个活动在循环中会反复被实例化，而活动的并行使得实例化在先的活动未必先完成，这就有必要采取一定的手段对并行的活动加以区分。在本文的表示方法中，活动的执行源于规则的匹配，因此，规则群可以作为活动“分组”的依据。例如，一个活动2的实例，可以由它是源于RG31还是源于RG32的规则执行来加以分别；而同一规则群引发的多活动实例的执行则可以由时标加以区分，由此实现对循环实例化的“分组”鉴别。

7.8 电脑维修业务的过程建模

现以第3节中的电脑维修业务为例，进一步介绍过程-业务动态关联情况下的过程建模方法，其过程结构图如图14所示。在ESR元模型中，过程和活动均可拥有事件和状态，所以事件和状态的定义分别在过程和活动两个层次上进行。图14中显示了在活动内部可定义活动级的事件和状态。

Figure 14 Structure diagram of the process of computer maintainance图14 电脑维修业务的过程结构图

(1)事件定义、状态定义与状态映射定义。

对于电脑维修业务，可以直接使用系统预定义的活动提交事件，而仅需要将这一事件挂接到相应的规则群即可。

“维修申请”活动的设定为：

Actapply.eActcommit→RGapply-check(RGapply-check为规则群)

“申请审核”活动的设定为：

Actcheck.eActcommit→RGcheck-service(RGcheck-service为规则群)

电脑维修业务需要定义的状态有商品出售时间Actapply.sDuration和商品类型Actapply.sType。

Actapply.sDuration的映射定义为:

presentdate()-saledate→Actcheck.sDuration

其中，presentdate()为系统函数，获取当前日期，saledate为“维修申请”活动中的业务数据—商品出售日期，Actcheck.sDuration表示的是商品出售时间。

Actapply.sType的映射定义为:

componenttype→Actcheck.sType

其中，componenttype为维修申请活动中的业务数据—商品类型。

(2)规则与规则群定义。

图14中有两个规则群：RGapply-check(申请活动和审核活动间的规则群)和RGcheck-service(审核活动和维修活动间的规则群)。

RGapply-check中包含一条规则：

Rule:Actapply.finished→Actcheck.start()

RGcheck-service中包含四条规则：

Rule1:Actcheck.finished∧Actapply.sDuration≤1 month→ActFreechg.start()

Rule2:Actcheck.finished∧Actapply.sType=maincomponente∧Actapply.sDuration>1 month∧Actapply.sDuration≤3 years→ActFreerep.start()

Rule3:Actcheck.finished∧Actapply.sType=externalcomponente∧Actapply.sDuration>1 month∧Actapply.sDuration≤1 year→ActFreerep.start()

Rule4:Actcheck.finished∧others→ActChargerep.start()

其中，Actapply、ActFreechg、ActFreerep和ActChargerep分别表示“维修申请”活动、“免费更换”活动、“免费维修”活动和“收费维修”活动。others表示当Rule1～Rule3的前提都不满足时的缺省处理情况。例如，在本例中，Actapply.sDuration>3 years即在others的范围内(值得注意的是，others仅针对业务状态，而不涉及系统状态，例如，Actcheck.finished即不属于others判定的内容)。

以上的介绍显然无法涉及基于ESR元模型的过程建模的所有方面。限于篇幅，本文不再对ERS模型框架下的建模方法进行更多的叙述。由上述介绍可知，ESR模型框架对过程的抽象元素和业务元素采用了一致性的表示方法，实现了“刚性过程”和“柔性过程”的统一建模。过程-业务的动态关联成为业务过程模型的内在因素，过程定义成为表达过程逻辑的唯一方式。统一建模的方法，不仅可以简化工作流系统的系统结构，而且能够最大限度地避免过程重构时对程序代码的修改，为过程的简便重构提供了强有力的支持手段。

8 简便重构实例

8.1 重构实例1

首先来看第5节中的重构问题，在电脑维修业务过程中增加了新的活动(改为两个审核活动)，并且与过程相关的业务数据的数值发生了变化(免费更换的时间延长为三个月)。

重构方法：修改过程结构图，修改规则。

新的过程结构图如图15所示。

Figure 15 Structure diagram of the process of computer maintainance with new activities图15 添加新活动的电脑维修业务过程结构图

然后，修改事件与规则群挂接的定义以及相关的规则定义。新的事件挂接定义为:

Actcheck1.eActcommit→RGcheck-service

Actcheck2.eActcommit→RGcheck-service

RGapply-check规则群中的规则改为:

Rule:Actapply.finished→

Actcheck1.start()∧Actcheck2.start()

RGcheck-service规则群中的规则改为:

Rule1:Actcheck1.finished∧Actcheck2.finished∧Actapply.sDuration≤3 months→ActFreechg.start()

Rule2:Actcheck1.finished∧Actcheck2.finished∧Actapply.sType=maincomponente∧

Actapply.sDuration>3 months∧Actapply.sDuration≤3 years→ActFreerep.start()

Rule3:Actcheck1.finished∧Actcheck2.finished∧Actapply.sType=externalcomponente∧

Actapply.sDuration>3 months∧Actapply.sDuration≤1 year→ActFreerep.start()

Rule4:Actcheck1.finished∧Actcheck2.finished∧others→ActChargerep.start()

与第5节中基于WFMC元模型的传统工作流系统及柔性工作流系统相比，基于ESR元模型的重构工作得到了大幅度的简化:

(1)仅仅需要修改过程定义，而无须修改任何程序代码即可完成过程重构。

(2)无须添加“汇聚”活动处理并行分支的汇合，汇合逻辑直接包含在了规则中。

(3)纯过程逻辑和过程-业务动态关联的过程逻辑采用统一的形式集中放置在一起，便于用户对重构内容的定位。

(4)无须业务过程系统的开发人员协助，用户自己可以独立承担重构任务。

8.2 重构实例2

假定在电脑维修业务过程中，商品信息原先含有商品金额(amount)一项，现在维修条例中增加与商品金额相关的内容，规定若外设金额超过3 000元，与主机维修条件相同，不足3 000元的按原条例执行。这种情况可以概括为“业务处理中的数据没有变化，但业务规则中涉及到的业务数据类型发生变化”。

重构方法：设置新的状态和状态映射，修改规则。

新状态：在“维修申请”活动中建立一个新状态Actapply.sAmount。

新的状态映射：amount→Actapply.sAmount

RGcheck-service规则群中的规则改为:

(Rule1、Rule2和Rule4保持不变)

Rule3:Actcheck.finished∧Actapply.sType=externalcomponente∧Actapply.sDuration>1 month∧((Actapply.sAmount≥3000∧Actapply.sDuration≤3 years)∨(Actapply.sAmount<3000∧Actapply.sDuration≤1 year))→ActFreerep.start()

基于WFMC元模型的传统工作流系统及柔性工作流系统实施这项重构任务时，需要修改“审核”活动中的程序代码，并重新编译系统。

8.3 重构实例3

假定在电脑维修业务过程中，原先不含有“客户类别”信息，现在新增这一数据，并在维修条例中设定VIP客户享有一年免费更换，五年免费维修的服务，而非VIP客户按照原条例执行。这种情况可以概括为“增加了新的业务元素，且该业务元素与过程逻辑相关”。

由于增加了新的业务元素，所以不可避免地要对业务处理程序加以修改。

重构方法：在业务处理程序中增加新的数据项customer，并在过程定义中建立对应的状态和状态映射，然后修改规则。

新状态：在“维修申请”活动中建立一个新状态Actapply.sCustomer。

新的状态映射：customer→Actapply.sCustomer

RGcheck-service规则群中的规则改为：

Rule1:Actcheck.finished∧((Actapply.sCustomer=VIP∧Actapply.sDuration≤1 year)∨(Actapply.sCustomer≠VIP∧Actapply.sDuration≤1 month))→ActFreechg.start()

Rule2:Actcheck.finished∧Actapply.sCustomer=VIP∧Actapply.sDuration>1 year∧Actapply.sDuration≤5 years→ActFreerep.start()

Rule3:Actcheck.finished∧Actapply.sCustomer≠VIP∧Actapply.sType=maincomponente∧Actapply.sDuration>1 month∧Actapply.sDuration≤3 years→ActFreerep.start()

Rule4:Actcheck.finished∧Actapply.sCustomer≠VIP∧Actapply.sType=externalcomponente∧Actapply.sDuration>1 month∧Actapply.sDuration≤1 year→ActFreerep.start()

Rule5:Actcheck.finished∧others→ActChargerep.start()

基于WFMC元模型的传统工作流系统及柔性工作流系统实施这项重构任务时的工作如下:

(1)修改“维修申请”活动的业务处理程序代码，增加“客户类别”数据项customer。

(2)修改“审核”活动有关过程逻辑的程序代码。

(3)重新编译“维修申请”活动和“审核”活动。

其中，第(1)项工作与基于ESR元模型的系统相同；虽然在本例中，基于ESR元模型的系统也需要修改程序代码，但是其重构工作主要以过程定义的方式进行，代码修改量远远少于基于WFMC原模型的系统，并且仅需要重新编译“维修申请”一个活动。

表1对上述过程重构实例进行了总结，对比了不同的工作流系统在若干典型情况下实施过程重构的方式。从表1中可以看出，基于ESR元模型的系统仅仅当业务处理程序中的数据类型发生变化，且该变化与过程逻辑相关时才需要修改程序代码；其它情况下，均可通过修改过程定义的方式实施过程重构；反之，基于WFMC的传统工作流系统和柔性工作流系统却在绝大部分情况下需要修改程序代码，并重新编译系统。

9 结束语

Table 1 Comparison of different methods of process reconfiguration

ESR元模型定义了新的模型元素和模型结构，同时建立了一种基于事件-规则机制的工作流模型框架。这种模型框架可以对纯过程逻辑和过程-业务动态关联的过程逻辑用统一的过程定义方法进行表示，然后由模型解释器对过程定义解释执行，改变了以往普遍存在的“刚性过程”和“柔性过程”分离建模的状况，简化了业务过程系统的建模和运行机制。ESR模型框架更好地实现了过程逻辑与业务逻辑的分离，当过程逻辑发生变化时，建立在该模型框架下的业务过程系统能够通过对过程定义的修改来适应系统变更的需求；并且根据重构任务的不同，过程的重构可以有针对性地在不同的模型层次上实施，从而达到过程简便重构的目的。

过程逻辑表示方法是业务过程建模的核心问题，本文概要地叙述了用于表示过程逻辑的规则的文法形式。但是，过程逻辑的形态种类繁多，如何用规则的方法对各类形态的过程逻辑进行抽象描述有待进一步深入研究。

[1] Luo Hai-bin, Fan Yu-shun, Wu Cheng. Overview of workflow technology[J]. Journal of Software, 2000,11(7):899-907.(in Chinese)

[2] Tan Wei,Fan Yu-shun.Research on architecture and key technology for business process management[J]. Computer Integrated Manufacturing System, 2004,10(7):2-6.(in Chinese)

[3] Li Jing-jie, Wang Wei-ping, Yang Feng. Review on approaches of flexible workflow[J]. Computer Integrated Manufacturing System, 2010,16(8):1569-1577.(in Chinese)

[4] Joao F, Wu Qin-yi, Simon M. Towards flexible event-handling in workflows through data states[C]∥Proc of the 6th World Congress on Services, 2010:344-351.

[5] Pesic M, Schonenberg M, Van der Aalst. Declare:Full support for loosely-structured processes[C]∥Proc of the 11th IEEE Enterprise Distributed Object Computing Conference, 2007:287-298.

[6] Zhang Jing-le, Yang Yang, Zeng Ming. Method for flexible workflow modeling supporting task change and performance analysis[C]∥Proc of 2009 WRI World Congress on Software Engineering, 2009:51-55.

[7] Sun Rui-zhi, Shi Mei-lin. A meta-model supporting dynamic changing workflow[J]. Chinese Journal of Electronics, 2002,30(12):2052-2056.(in Chinese)

[8] Dadam P,Reichert M,Rinderle-Ma S.From ADEPT to AristaFlow BPM suite:A research vision has become reality[C]∥Proc of the 1st International Workshop on Empirical Research in Business Process Management, 2009:529-531.

[9] Muller R,Greiner U,Rahm E.Agentwork:A workflow system supporting rule-based workflow adaptation[J]. Data and Knowledge Engineering, 2004,51(2):223-256.

[10] Herbst J, Karagiannis D. Workflow mning with InWoLvE[J]. Computers in Industry, 2004,53(3):245-264.

[11] Tan Yi-yong,Wang Rui,Fan Yu-shun,et al.Adaptive scheduling method for real-time tasks in distributed workflow[J]. Computer Integrated Manufacturing System, 2010,16(9):1887-1895.(in Chinese)

[12] Hu Jin-min, Zhang Shen-sheng, Yu Xin-ying. A workflow model based on ECA rules and activity decomposition[J]. Journal of Software, 2002,13(4):761-767.(in Chinese)

[13] Jang Ju-lian, Alan F. An event-driven workflow engine for service-based business systems[C]∥Proc of the 10th IEEE International Enterprise Distributed Object Computing Conference, 2006:233-242.

[14] Wang Yi, Li Ming-lu. ECA rule-based workflow modeling and implementation for service composition[J]. IEICE Transactions on Information and Systems, 2006,89(2):624-630.

附中文参考文献：

[1] 罗海滨, 范玉顺, 吴澄. 工作流技术综述[J]. 软件学报, 2000,11(7):899-907.

[2] 谭伟,范玉顺. 业务过程管理框架与关键技术研究[J]. 计算机集成制造系统, 2004,10(7):2-6.

[3] 李竞杰, 王维平, 杨峰. 柔性工作流理论方法综述[J]. 计算机集成制造系统, 2010,16(8):1569-1577.

[7] 孙瑞志, 史美林. 一个支持动态变化的工作流元模型[J]. 电子学报, 2002,30(12):2052-2056.

[11] 谭宜勇, 王锐, 范玉顺,等. 分布式工作流中的自适应实时任务调度方法[J]. 计算机集成制造系统, 2010,16(9):1887-1895.

[12] 胡锦敏, 张申生, 余新颖. 基于ECA 规则和活动分解的工作流模型[J]. 软件学报, 2002,13(4):761-767.