一种基于产生式的流程管理模型分析方法

一种基于产生式的流程管理模型分析方法摘要：在深入分析业务流程模型和合理的抽象业务活动基础上，提出了一种基于产生式的流程模型形式化分析方法，并提供了一种从一般流程描述到该模型的转换方法；在此基础上，推导了一系列行之有效的流程属性验证规则，并通过应用实际例子证明了所提出方法的有效性。关键词：业务流程模型；分析和验证业务过程的建模、分析和优化是支持企业业务过程重组的重要基础。行之有效的模型分析方法是成功进行模型分析的关键技术问题。业务流程重组的实质是企业根据市场需要以企业经营过程为核心重构企业的关键业务流程，并建立与其匹配的运行机制和组织结构，实现对经营过程的有效管理和控制。它一般分为五个阶段，即项目规划、企业经营过程建模、模型分析与优化、基于模型的业务经营过程重组实施和项目评价与监控。在这个过程中模型分析与优化是企业实施业务流程重组中非常重要的一个环节，对业务流程重组成功与否起着至关重要的作用。近几年来，作为支持业务流程重组的重要技术的工作流技术得到了广泛重视。但是由于工作流技术产生于实际应用，缺乏良好的理论基础，应用工作流方法建立的企业经营过程模型缺乏必要且行之有效的模型验证和模型分析方法。研究如何从理论上验证所建立的过程模型结构的合理性，研究如何评价所建立的模型的性能和优化模型的方法就显得尤为重要。OncePI是中国科学院软件所软件工程中心自主研发的集工作流开发、监控和管理于一身的业务流程管理系统。该系统为企业应用提供了一个构建灵活、高效、自适应流程的平台。OncePI引入面向服务的核心理念，通过将业务流程逻辑与实现各业务的应用相分离、管理流程参与者的相互关系、集成内部和外部资源以及监控和分析流程性能，实现了对业务流程整个生存周期的控制。这样，管理者可以将精力集中于业务自身的优化、组合，从而适应不断变化的商业环境。然而，如果一个业务流程管理系统没有提供一套强有力的流程模型分析工具，流程模型的正确性、有效性和高效性就不能得到有效保证，为系统在现实的企业业务流程运行环境中的应用留下了障碍，特别是对于具有大规模业务流程的企业应用环境中，依靠人工对业务流程模型的维护，难以保证企业业务流程的正确性以及有效、高效的运行。本文通过分析现有业务流程验证概念和方法，结合OncePI系统在实际应用中面临的流程分析和验证需求，提出了一种基于产生式的流程分析模型以及相应的模型生成方法和验证规则。在此基础上，将这套方法应用于OncePI的流程模型分析和验证之中，开发了一套有力的流程模型分析工具，为OncePI的集成流程设计和开发提供了可靠的保证。1业务流程验证概念和方法工作流技术已经被越来越多的业界采用为商业应用和开发的关键技术。其主要特征是自动执行包括人员和自动型应用在内的业务流程。工作流模型是对工作流的抽象表示，也就是对经营过程的抽象表示。由于工作流需要在计算机环境下运行，建立相应的工作流模型是必不可少的。工作流模型应该完整地提出支持工作流定义的概念，为建模用户提供工作流定义所需要的组件或元素。理想的工作流模型能够清楚地定义任意情况下的工作流，能够适应用户在建模过程中所提出的各种要求。定义和描述工作流模型的方法多种多样，有业务流程语言如XPDL、BPML、BPEL等，还有形式化模型如EPCM模型、Petri网和工作流网等。概括起来可以分为语言描述方法、基于图结构的方法、基于逻辑的方法、代数方法和ECA规则方法几类sup[1]/sup。由于工作流模型的复杂性，目前还没有有效的算法可以对工作流模型的正确性进行分析。目前已有的大部分工作流产品提供了流程模型的仿真和测试工具，也有一些研究者为流程模型的分析和验证提出了各不相同的概念和方法。现有的流程模型分析和验证方法大概可以分为三类：（1）基于图形化简的流程验证方法一般而言，基于图形化简的验证方法适用于基于图结构的流程模型描述方法sup[2，3]/sup，通过定义图形结构的化简规则，能够在一定程度上验证流程模型。在文献[4]中，SadiqW等人对有向无环图(DirectedAcyclicGraph，DAG)表示的业务流程证明其结构的正确性。在证明工作图结构正确性的同时使用了如下五种归约规则：终结符规约、顺序规约、邻接规约、闭合归约和重叠归约。如果一个工作流图是正确的，则反复使用这些归约规则可以将工作流图归约为空。但是由于图形结构表达方式的局限性，这种流程模型验证方法只能对部分流程结构中存在的问题进行分析和验证，不能广泛应用在一般的流程模型验证问题中。文献[5]中列举了一个反例——交叉全连接的工作流图，证明了虽然此工作流图是正确的。但是使用重叠归约规则不能消去图中的交叉全连接结构，此流图也无法规约为空。（2）基于模型的流程分析验证方法文献[6]中提出了用Petri网进行工作流建模的工作流网，将工作流模型的正确性归纳为工作流网的完整性，并在文献[5]中提出了一种基于Petri网的图形化简方法辅助模型验证。但是其提出的化简步骤由于不具备完备性而不能完全验证工作流模型的正确性。文献[1]提到的基于模型检查的流程分析方法具有很好的理论基础。这种方法分为两个阶段：首先通过模型映射，将定义的流程模型映射到一种易于分析和验证的有限状态机模型上；在这个模型上使用相应的模型检查器，探索整个状态空间，检查是否每一个系统状态都满足指定的流程属性。由于这种方法只能应用在有限状态机模型上，在流程模型的验证中同样只能部分地验证流程属性。（3）基于仿真的流程分析方法文献[7]中提出了一种基于仿真的模型验证方法，但它缺乏理论上的严格证明，而且当发现系统中确实存在冲突或死锁时，并不能给出错误发生的确切位置（只是给出了一些辅助的检测数据）。基于仿真的流程验证方法，能够结合具体工作流系统，仿真流程模型的执行过程，因而具有很好的实用性。但是其本身没有严格的理论依据，并且依赖于具体的工作流系统，不具有普遍性。OncePI的业务流程分析和验证采用了一种类似于文献[1]中提到的流程验证框架，即将业务流程的验证划分为两个阶段：首先通过模型映射，将定义的流程模型映射到一种基于产生式的流程分析模型上；然后在这个模型上使用相应的模型化简和变换规则，实现流程属性的分析和验证。这种基于产生式的模型以形式语言理论为基础，能够很好地表达业务流程并体现流程的过程特性。2基于产生式的流程分析模型一般而言，工作流是一类能够完全或部分自动执行的业务过程。根据一系列过程规则，文档、信息或任务能在不同的执行者之间传递、执行sup[8]/sup。而流程的业务过程模型通过流程模型中的各种实体及其约束关系(包括控制流和数据流)，将业务活动串联起来，从而表达流程的业务过程。几乎所有的流程模型都是基于活动（Activity）的，活动是具体执行业务任务的抽象。对于一个面向服务的业务流程管理系统而言，将活动的具体实现绑定到对某个服务的调用。这里的服务是一个抽象概念，可以是WebService或者应用程序甚至是人工活动。这样，可以把业务流程看做是服务的组合过程。下面本文使用“服务”这个概念指代流程模型中具体执行业务任务的实体。2.1服务的抽象如上文所述，在本文中服务指代流程模型中具体执行业务任务的实体。那么流程执行过程中，服务是如何完成业务任务的呢？粗略地说，服务请求方通过调用服务，与服务提供方之间发生交互，改变服务提供方和服务请求方的当前状态，从而完成业务任务。因此，本文将服务定义为服务执行上下文状态的一个映射。基于这样的理解，本文可以把服务形式化描述为Service:(context,environment)-(context,environme其中，Service是流程中的业务活动抽象，即服务；context是流程上下文的一个抽象，它代表服务调用方（流程实例）的上下文状态；environment代表服务提供方（服务实现，如预定义的应用）执行服务的当前状态。这样，服务定义了执行过程中流程实例上下文状态的跃迁及其对服务实现所处环境的作用。在以服务为着眼点时，可以合并服务提供方和调用方的状态，通称为服务执行的context；在以流程为着眼点时，可以忽略服务实现所处的环境状态，而把context直接看做是流程本身的上下文状态，这样服务的形式化表述简化为Service:context-从服务的角度重新考查流程的特征，可以定义服务的组合概念。本文把服务复合的逻辑称为服务复合算子。2.2服务算子及其性质本文使用服务复合算子来描述流程中服务的复合逻辑。什么是服务的组合呢？一种基本的认识是，多个服务的组合仍然可以被视为服务，即多个服务共同对服务运行环境的作用，可以等效地认为是一个新的服务对其的作用。这个新的服务即是组合的服务，服务组合的结果仍然是服务。基于这样一个认识，本文定义了服务算子来描述服务的组合。定义1服务算子定义在服务域，并且其值域也是服务域，用来描述服务的组合Operator:-其中*指定了算子的元数。正如21节对流程中服务的组合过程所描述的那样，分析了先前存在的大部分业务流程语言（XPDL、BPEL、BPML）和被研究的各种流程模式sup[9～12]/sup。顺序组合和并发组合是两种基本服务组合方式，其他的流程语言结构和流程模式都可以通过这两种服务组合方式配合特定的路由逻辑复合而成。（1）顺序算子：它表达了服务的顺序组合逻辑和流程中服务之间显式的因果联系。使用“•”符号表示顺序算子。服务的顺序组合可以表示为这个表达式代表的语义是S(context)=S2(S1(context))，称之为两个服务的“积”。多个服务的顺序组合使用类似的表达式S=S1•S2•S3。在不会引起误会的场合也可以直接省略“•”符号而直接将顺序组合的服务并置在一起，如S=ab，S=abc。（2）并发算子：它表达了服务的并发组合逻辑，在流程模型中被广泛用来刻画没有因果联系的活动的并发执行。服务的并发组合可以表示为这个表达式代表的语义是，称之为服务的“和”。如上文所述，context的合并时机和规则取决于流程引擎的具体实现。多个服务的并发组合使用类似的表达式S=S1+S2+S3。（3）选择算子：它用来表达流程中服务的路由选择逻辑。许多类型的流程模型中存在这样的路由逻辑；服务的选择依赖于运行时具体的流程上下文内容。选择算子被用来刻画这种动态路由逻辑。首先，定义服务的动态选择函数表示为Eval:context-其中，context是流程中服务启动时的上下文状态；service是流程实例运行时选择执行的服务分支；Eval函数定义了上下文状态到服务分支的映射。在这个基础上，服务选择逻辑可表示为这个表达式代表的语义是S(context)等于S1(context)还是S2(context)取决于Eval函数对context映射的结果。多个服务的选择逻辑可以用类似的表达式表达S=Eval?S1|S2|S3。在静态表达流程结构时，可以忽略选择函数而把选择表达式简写为从这个定义出发，可以得出选择算子表达的是所谓的XOR选择逻辑sup[15]/sup。从这个算子可以扩展出一些新的算子，用来表达很常见的一些流程模式，如While循环和循环模式。本文使用闭包算子和正闭包算子来表达。下面进一步分析这三种基本服务复合算子的性质。考虑流程模型中服务的语义，结合上文中对顺序、并发和选择算子的详细讨论，针对算子的运算法则，有如下结论：（1）顺序算子不具备交换律，即一般情况下，；（2）顺序算子具有结合律，即(S1•S2)•S3=S1•(S2•S3)；（3）并发算子具有交换律，即S1+S2=S2+S1；（4）并发算子具有结合律，即(S1+S2)+S3=S1+(S2+S3)；（5）选择算子具有交换律，即S1|S2=S2|S1；（6）选择算子具有结合律，即(S1|S2)|S3=S1|(S2|S3)；（7）顺序算子与并发算子之间不存在分配律，即S1+S2•S3≠S1•S2+S1•S3