工作流模型

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

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

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

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

过程视图是本文研究的主要内容，本文通过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操作）。