工作流模型

过程视图是工作流模型的核心视图。

它描述企业的业务流程，定义业务过程中包含的活动以及这
些活动之间的逻辑关系。

活动和活动间以连接弧表示控制关系。

通过描述活动的基本属性，如活
动由谁执行，有哪些人员、组织或盟员企业负责执行，活动执行需要的软件(如应用程序)和硬件
(如机床设备)资源，以及活动的触发条件、执行状态等，可以建立过程视图、资源视图和组织视
图的关系。

过程视图是本文研究的主要内容，本文通过ECA规则来表达过程视图。

基于ECA规则和元操作的工作流建模原理
3.1 工作流模型的结构
图：工作流模型的结构
1.1.1过程视图
过程视图是工作流模型的核心视图。

它描述企业的业务流程，定义业务过程中包含的活动以及这些活动之间的逻辑关系。

活动和活动间以连接弧表示控制关系。

通过描述活动的基本属性，
如活动由谁执行，有哪些人员、组织或盟员企业负责执行，活动执行需要的软件(如应用程序)
和硬件(如机床设备)资源，以及活动的触发条件、执行状态等，可以建立过程视图、资源视图和
组织视图的关系。

过程视图是本文研究的主要内容，本文通过ECA规则来表达过程视图。

1.1.2组织视图
组织视图描述企业中的组织单元和组织单元间的关系。

组织单元是具有一定功能和责任的组织实体，一般会承担过程模型产生的各种任务。

组织单元之间往往存在从属或协作关系，形成
一定的对应关系。

本文对组织视图描述中，采用一种面向对象的关系模型，不同于传统的层次结
构。

是在组织模型中引入类的概念(如角色类、组织类、人员类、职位类等)，建立类之间的关系
模型，支持层次化的查找和匹配规则，便于工作流的任务分配和执行者绑定。

1.1.3资源视图
资源视图描述企业中资源的类型以及资源实体的属性。

资源是工作流模型中非常重要的一个概念，是活动可以执行的必备条件。

资源类型可以是执行活动所需的软件和硬件设施等，或者
是活动执行后产生的新的物理实体。

组织视图和资源视图之间存在着映射关系，即每一个资源实
体都有与其对应的责任组织单元，该组织单元负责对此资源实体的使用和维护。

1.1.4信息视图
信息视图从信息关系的角度描述经营过程中的数据结构特征和数据关系。

信息视图的信息来源于组织视图、资源视图和过程视图中的数据结构及数据关系。

信息一般可以根据信息的功能
分成不同的类别，比如工作流系统内部使用的信息和工作流系统外部的信息。

本文采用XML结
构描述工作流系统内部依赖的数据结构（相关数据）。

1.1.5小结
工作流系统的集中模型不是孤立存在的，它们之间存在着相互交叉和依赖的复杂关系。

工作流管理系统的软件实体的功能就是把这几种试图（模型）有机的融合在一起，使它们共同组成
一个企业的业务流程模型。

因此，工作流模型是指导工作流管理系统开发的基本理论基础，而工
作流的模型的各种试图从各个角度描述了工作流模型的结构。

这其中最为重要和核心的是过程视
图，这是本文描述的重点。

3.2 工作流建模方法现状
工作流模型是对业务过程的抽象表示，工作流建模是工作流技术理论研究和实际应用的基础。

目前相对于工作流产品的实现技术和发展速度而言，工作流建模理论的研究相对滞后，在建模方法上还没有形成比较系统化的理论体系。

下面列出目前存在的几种常见的建模方法。

3.2.1基于活动网络的工作流建模方法
这种建模方法从过程定义入手，绘制活动网络图，它的优点是比较直观，容易理解，一般情况下，图中的节点表示过程中的活动或者状态，而有向弧则表示节点间的时序依赖关系。

优点是比较直观，实现起来也不复杂。

其缺点是不能处理复杂的过程逻辑，缺乏柔韧性，在关系复杂的情况下容易出现很多连线的图。

3.2.2基于形式化表示的工作流建模方法
这种表示方法一般具有比较严格的数学理论基础，采用形式化的方法精确定义流程。

基于Petri网的建模方法是一个典型的代表，在基于Petri网的建模当中，包含库所、变迁和标记三种元素，变迁是系统当中的主动元素，变迁在前驱库所全部满足条件才可以实施，变迁完毕以后会往每一个后继库所放置标记。

Petri网络的优点是定义比较严格，模型比较容易得到验证；缺点是流程复杂时一般会产生非常复杂和费解的Petri网。

3.2.3基于对话模型的建模方法
这种方法创建的模型包括很多个闭环，每一个闭环都包括需求、协商、执行和满意四个阶段。

如图：
一个对话闭环
每一个闭环一般描述一个工作，闭环是在客户方和服务方的对话过程中完成的。

当一个闭环完成以后，服务方可能成为另一个闭环的客户方。

流程的推进就是通过多个闭环环环相扣进行的。

这种模型的优点是非常适合于描述以人的交互为特征的经营过程；缺点是支持层次化建模的能力不足，不适合于比较固定的企业经营过程，建模人员很难完整明确的列出双方所有可能的语言行为。

3.2.4基于事务的建模方法
事务的概念来自于数据库研究领域，用以解决数据的并发访问和出错恢复问题。

事务性问题在工作流管理系统当中更加重要，因为工作流管理系统比数据库管理系统的操作要更加复杂的多，其活动的持续时间有时候很长。

因此，从提高工作流管理系统的可靠性出发，来研究基于高级事务模型的工作流也比较有意义。

Amit Sheth在对高级事务模型进行研究的基础上提出了事务工作流（Transactional Workflow）的概念，他完全从工作流的角度提出了任务的结构化定义以及基于任务间依赖关系的工作流定义。

由于实际环境当中高级复杂事务的情形相当复杂，这种建模方法的广泛应用还存在一定难度。

3.2.5基于ECA规则的建模方法
基于ECA规则的工作流建模方法以事件驱动工作流实例的推进，事件驱动的机制为分布式工作流提供了一种统一的组件行为描述机制，它可以通过严格定义事件的语义来保证工作流的正确执行以及对它的监控。

另外，以事件驱动为中心还可以大大提高系统的柔性，这种柔性允许工作流实例在运行过程当中修改过程结构。

3.2.6小结
纵观上面提到的各种建模方法，它们在实现上各有优点和缺点。

有的简单直观（活动网络模型），有的利用形式化表达而便于进行流程验证（Petri网模型）；有的采用类似于人与人之间交互的方式（基于对话的模型）；有的对现有成熟的数据库技术进行扩展（基于事务的模型）。

这些模型在实际使用上经常会有交叉，比如大部分模型的实现都可以和图形化建模相结合，利用图形网络直观地表达业务流程的大致结构。

由于基于ECA规则的建模方法在功能表达上不受表达方式的限制，扩展性较好，比较容易在分布式环境下工作，所以特别适合于实际应用。

本文表述的建模方法在传统的ECA规则的研究的基础上进行扩展和细化，并使其结合元操作思想。

这种建模方法提供比较清晰地工作流层次架构，能够很大限度地提高工作流管理系统的灵活性和扩展性。

3.3 ECA规则结合元操作实现工作流模型
3.3.1原理概述
本建模方法把工作流管理系统的职责分为两部分：动态职责和静态职责。

动态职责指工作流系统过程和活动之间的相互协作和相互影响；静态职责指工作流系统对自身数据模型的维护。

动态职责的部分使用ECA规则来描述，静态职责部分被称为工作流系统的元操作。

通过ECA
规则和元操作的有机结合实现工作流管理系统动态职责和静态职责的分离，从而最大限度的提高工作流管理系统的灵活性和适应性。

3.3.2工作流管理系统的静态职责和动态职责
根据WFMC的工作流参考模型，要实现一个工作流管理系统（WFMS），需要提供从接口1到街口5等多种功能，这些功能涉及流程定义、工作列表、组织资源、应用调用等多个方面。

总的来说，我们可以从静态和动态两个方面来看WFMS的职责。

3.3.2.1静态职责
从静态方面来看，工作流系统是一个复杂的逻辑结构，它包括流程定义、流程实例、工作列表、相关数据等等很多种的数据。

外界对于工作流系统的每一次请求都是对工作流系统的一些
数据结构的修改。

比如下图：一个启动活动A的动作会在WFMS当中修改活动A的状态为“运
行”。

静态职责包括很多方面，比如：
启动流程——在工作流数据库当中创建一个流程实例。

挂起活动——在工作流数据库当中修改对应活动状态为“挂起”。

修改活动的属性——修改数据库当中对应的记录。

分配工作任务给人员A——在工作列表库中创建一个工作项（可能是一条记录），使得该工作的参与者为A。

3.3.2.2动态职责
从动态方面看，工作流管理系统又是一个根据用户的操作而发生连锁反应的“反应堆”。

用户的一个很简单的操作可能会引起工作流系统的一连串复杂的级联变化。

比如下图：一个结束
活动A的动作会导致一个启动活动B的动作和一个启动活动C的动作。

动态职责包括很多，比如：
顺序活动的流转——前驱活动的结束动作会导致后继活动的启动动作。

子流程活动的结束——一个流程实例的结束（子流程的实例）会导致另外一个流程实例的对应活动（子流成实例对应得父活动）的结束。

终点活动的结束——该活动的结束会导致整个流程的结束。

3.3.2.3动态职责和静态职责的关系
动态职责和静态职责的关系是相互影响和相互依赖的。

比如，对于功能顺序活动流转来说，系统履行动态职责为“前驱活动的结束动作会导致后继活动的启动动作”，而“后继活动的启动动作”又要“修改活动及活动的状态为运行”，这又
是一个静态职责。

再比如：对于功能启动流程来说，系统履行静态职责“在工作流数据库当中创建一个流程实例”，而创建以后又要导致流程当中的开始活动直接进入运行状态，这就产生了连动效应，导
致了动态职责。

3.3.3基于ECA规则实现动态职责
上面讨论了工作流系统的动态职责和静态职责。

本节讨论ECA规则，它可以用来实现动态职责。

3.3.3.1什么是ECA规则
反应型系统与其外部环境的交互过程利用具有动态交互特征的ECA (事件-条件-动作)规则进行描述是非常合适的。

ECA规则定义了在某一事件下（Event）,当满足定义好的条件
（Condition），被定义对象将执行的动作（Action）。

ECA规则广泛用于主动数据库技术中[5]。

在这里，我们根据WFMS的特性，也利用ECA规则来描述WFMS与其外部环境之间的交互行
为。

3.3.3.2对ECA规则的扩展
根据ECA规则的概念，可以采用如下的结构对其进行描述：
本文针对ECA规则在工作流引擎当中应用的特点，在三个方面对ECA规则进行针对实现的扩展：
1. 事件可以是多个，即Event被扩展为事件列表EventList,EventList表示Event的集合
（Event1,Event2, . . . . ,EventN），集合当中的所有事件没有先后顺序，当EventList当中
的任何一个Event发生，该ECA规则被触发。

2. 条件可以是多个，即由多个IF条件和多个DO操作。

扩展IF…DO…为IF… DO… ,IF…DO…,...(可
能无限多个)。

规则解释器执行的时候的判断规则是：如果某IF条件满足，则执行紧随其后的
DO操作，并跳过该条件后面的所有的条件判断和所有其他的DO操作（包括下面将要说明的
DEFAULT操作）
3. 增加确省操作（即DEFAULT操作）。

当所有的IF条件都不满足的情况下执行确省操作，如果有
一个IF条件满足，则不执行确省操作。

经过扩展的ECA规则的信息结构可以描述如下：
3.3.3.3根据扩展的ECA规则实现工作流的流程流转
流程的流转职责为工作流管理系统最重要的动态职责。

该职责可以通过对顺序、选择、并行、单一归并、多路归并等路由模式的支持来说明。

通过ECA规则可以表达多种流程模式，下
面列出来其中几种作简要说明和讨论。

1．顺序路由
如图，假设流程存在三个串行活动：活动A、活动B、活动C。

我们可以通过以下几个ECA规则来表达这个顺序关系：
规则1：
规则2：
条件“T RUE”表示无论何种情况下总能
够被满足的条件。

2．选择路由
如图，假设存在四个活动活动A、活动B、活动C、活动D。

依赖关系为：活动A结束以
后，根据条件判断，如果Condition1满足则启动活动B,如果Condition2满足，则启动活动C，
如果Condition1和Condition2都不满足，则启动活动D。

可以用以下几个规则来表达这个选择关系：
规则：
3．并行路由
如图，假设存在四个活动活动A、活动B、活动C、活动D。

依赖关系为：活动A结束以后，同时启动活动B、活动C、活动D。

可以用以下几个规则表达这个并行关系：
规则：
4．单一归并路由
如图，假设存在四个活动活动A、活动B、活动C、活动D。

依赖关系为：活动A、活动B、活动C任意一个结束以后，活动D就启动。

可以用以下几个规则表达这个并行关系：
规则：
值得注意的是：由于我们在扩展ECA 规则时候定义EventList 当中只要有一个Event 被触发整个规则就被触发，所以这里需要有三条规则才能处理这种路由关系。

5．多路归并路由
如图，假设存在四个活动活动A 、活动B 、活动C
、活动D 。

依赖关系为：活动A 、活动B 、活动C 全部结束以后，活动D 才启动。

可以用以下几个规则表达这个并行关系：
规则：
值得注意的是：规则第一行的 “ON A 结束，B 结束，C 结束”，表达的含义是“活动A 结束 或者 活动B 结束 或者 活动C 结束”，即活动A 、活动B 和活动C 当中只要有一个结束，事件就触发成功。

所以在Condition 部分还要判断三个活动的状态都为结束。

3.3.4 ECA规则和元操作的结合
3.3.
4.1 工作流管理系统的元操作集
工作流管理系统的静态职责相关的功能集合可以被看作元操作集。

一个元操作包含于对工作流模型数据库的有意义的操作序列，比如：创建流程实例，修改活动的状态，创建工作项，结束工作项等等。

如图，工作流管理系统的元操作集实现了对工作流管理系统数据模型的封装，把一个纯数据模型工作流管理系统封装成为一个主要体现为操作的工作流管理系统。

更高层次内的所有功能都不能越过工作流管理系统元操作集合直接访问底层的数据模型。

这一定程度上实现了工作流管理系统软件的解偶。

3.3.
4.2 ECA规则和元操作的结合
本模型把ECA规则和元操作进行结合，结合的方式是限制ECA规则当中所有的Action 都是工作流管理系统的元操作；也就是说ECA规则不能直接访问底层数据模型，而只能通过对元操作的调用达到需要的功能。

这种限制一定程度上为工作流管理系统的实现提供了方便，其实质是实现了一个ECA规则作为外观控制器的微内核的工作流。

在这种组织下，工作流管理系统可以分为四个层次，由外到内依次是：用户接口层、ECA 规则层、WFMS元操作层、WFMS数据模型层。

多个层次的设计使得基于这种结构的WFMS具有极大的灵活性和扩展性。

这是因为，最内的两层——数据模型层和元操作层一般都是很稳定的，元操作层一般只有少数一些操作组成，通
过扩展ECA规则层的规则定义就可以很大程度地根据需要丰富工作流管理系统的用户接口层功
能。

3.3.
4.3扩展ECA规则和元操作的结合的模式下WFMS的运
作过程
扩展ECA规则和元操作结合的模式可以充分体现工作流管理系统当中静态职责和动态职责的关系。

在这种方式下，一个外部事件请求被满足的过程为：ECA规则处理机处理外部事件，处理的结果会调用元操作，元操作执行过程中会给ECA规则产生新的事件，于是ECA规则处理机又
去处理新的事件；如此循环，直到不存在新的事件为止。

而一个外部对于元操作的调用过程为：
元操作执行过程中给ECA规则产生事件，ECA规则处理该事件又会调用新的元操作。

外部事件的处理通信过程：
外部调用的处理通信过程：
3.4 基于ECA规则和元操作建模方法的优点
首先，与基于活动网络或者图形表示法的工作流模型相比，基于ECA规则的模型可以用比较简洁的图形表达复杂的流程。

基于活动网络或者图形表达的工作流模型的功能通常受到网络或
者图形本身的限制（例如：每一个活动和它能够影响到的活动之间必须有边或者连线），在业务
流程特别复杂的情况下容易产生让人费解和复杂的图形。

基于ECA规则的工作流模型虽然在建
模工具的外观上一般也采用图形化的外观表示方法，但其具体的流程逻辑可以不必全部体现在流
程图形上，而通过一些潜规则（不通过图形表达出来的语义逻辑规则）来实现。

这样,在具体的流程非常复杂的情况下，依然可以通过比较简洁的图形来表达。

其次，与基于形式化表示的建模方法相比，基于ECA规则和元操作的工作流模型不会非常复杂和令人费解。

比如和采用Petri网的工作流模型相比，Petri网由于引入了库所、变迁和标记等多种对象，并对各种对象的操作规则进行了严格的限制，这就使得这种方法创建的模型比具体的业务流程模型更加复杂。

特别是在业务流程比较复杂的情况下，不得不采用更加复杂的数学模型（虽然比较严格的数学模型给流程正确性的自动化校验带来一些方便）。

基于ECA规则和元操作的模型当中的每一步规则都是和具体的业务规则相匹配的，不会加入额外的因素而使模型变得复杂。

另外，ECA规则和元操作的分离使得工作流模型的扩展变得简单。

元操作的个数和功能一般来说是会比较稳定，它们封装了整个的工作流系统数据模型。

当需要增加新的业务规则时，一般只需要在ECA规则层增加对应的规则即可。

这就像Unix内核虽然比较小，但可以基于此开发出各种各样的复杂的应用程序。

总之，基于ECA规则和元操作的工作流模型由于其语义与图形表达的无关性、流程模型的规则和业务规则的统一性以及严格灵活的分层结构，使得表达的流程简单而灵活易变，在具体应用上具有很强的实践意义。

本章首先介绍工作流参考模型；然后介绍数据模型；再然后介绍元操作和ECA 规则的具体表达方法（这是本章的重点）；最后通过具体的例子来说明本模型如何表达业务流程。

4.1 工作流参考模型
本文第二章提到了工作流联盟（简称WFMC）。

工作流联盟提出了一个工作流参考模型。

该模型从系统结构、术语使用、接口实施等方面提供规范化与标准化定义，并以此为基础实现工作流管理系统之间的互操作。

本节将首先分析一下工作流参考模型，因为工作流参考模型对本模型的功能和实现架构有很大影响。

工作流参考模型定义了工作流系统当中涉及到的主要软件实体，包括：过程定义工具、工作流引擎、工作流管理工具、工作流客户应用、工作流机直接调用的应用、其他工作流执行服务。

其中前三部分为工作流管理系统的自己的软件实体；第四部分是可以由客户定制的部分；第五部分是应用系统的应用程序；第六部分是和其他工作流引擎交互时才需要的。

工作流参考模型如图：
图：工作流参考模型
系统的核心部分是工作流引擎，引擎是驱动流程进行运作的主要部件，它负责解释工作流流程定义，创建并初始化流程实例，控制流程流动的路径，记录流程运行状态，挂起或唤醒流程，终止正在运行的流程，与其他引擎之间通讯等等工作。

WFMC没有针对引擎的实现提供具体的标准，因为对引擎做过多的约束并没有多大的现实意义[5]。

一个工作流管理系统可以包含一个或多个引擎，并通过API向外部提供五个方面的功能服务，这些功能分别为：
● 接口1－流程定义的导入导出
● 接口2－同客户端应用程序和工作列表处理程序之间的交互
● 接口3－软件工具和应用程序的调用
● 接口4－不同工作流管理系统之间的协同工作
● 接口5－管理和监视功能
通过这五个接口，工作流管理系统可以同外部的软件工具进行交互，这些工具可以由同一厂商提供，也可以由不同的厂商提供，但前提是这些工具都必须遵循WFMC的规范。

用户也可以有充分的选择空间来决定哪一厂商的产品，或者自己开发属于哪一个接口的工具。

这五个接口一般通过API的形式提供给用户或软件开发商，这些API称为WAPI（Workflow API），也有厂商将API封装成组件形式提供，以简化开发难度、降低成本并提高效率。

下面对这五个接口的功能作简要介绍。

● 接口1
许多不同厂商提供的工具可以进行工作流流程的分析、建模、描述和归档等工作。

这些工具需要识别公共的流程交换格式，以支持在这些不同的产品之间传送工作流的流程定义。

接口1便定义了这样的交换格式。

此外，接口1还定义了设计环境与运行环境之间交换的规范，以使不同的建模工具产生的流程定义可以输入到不同的工作流产品的运行环境中。

为了提供一个访问和描述工作流定义的公共方法，需要引入一个工作流元数据模型（meta－data Model），这个模型确定了流程定义中用到的一般的实体，这些实体都有不同的属性，不同厂商开发的工具可以根据公共的交换形式向工作流运行环境传送这些模型，传送可以通过API实现，也可以通过批量（Batch）传送实现。

● 接口2
工作流管理系统必须提供同用户之间交互的通道，以便用户参与到系统的运行中。

接口2主要完成这方面的功能。

WFMC在关于接口2 的规范中定义了工作流管理系统必须提供的类型、数据结构、API和错误代码，并以C语言头文件。