论文部分内容阅读
1 概述
业务流程变更（Business Progress Change，BPC）[1]是在业务流程定义阶段或执行阶段出现，相对于原来的流程定义的更改，其需求有的来自于客户要求、相关法律变更等外因，有的来自于科技更新、追求效率效益等内因，都是为了使系统适应环境、优化流程、提升效率、提高收益。要在流程定义的时候提前考虑到所有可能的业务流程是非常困难的，而执行过程中变更需要业务人员与专业技术人员在前期沟通协调，制定变更计划。考虑到流程局部的修改可能牵扯到整个业务流程的变量配置，故变更时还需等待流程实例全部执行完毕或将运行实例临时撤销。由此可见，传统变更方式不仅耗时耗力，还需企业承担变更过程中可能导致的数据错误、信息丢失等风险。
若业务流程系统能够在仍有实例运行时的过程定义根据变更衍生出新的流程定义，并对过程中实例的情况做出反应和处理的能力，那么称该系统能够动态实现变更自适应。传统业务流程模型进行数据修改、逻辑变更的难度较大，不利于变更自适应技术的实现，而以数据为中心的业务流程模型将底层数据提升至流程工单（Artifact）中，修改数据简单易行。本文基于以数据为中心的业务流程模型，提出动态修改方法，研究了变更自适应技术，设计并实现了变更自适应业务流程系统。
与传统变更方法相比，变更自适应技术不仅能够判断变更能否自动化完成；并且能快速响应可自适应的变更而无需等待实例执行结束；同时自动适应变更内容，在不修改系统的前提下完成业务流程的变更。
2 国内外相关研究
目前，国内外的学者从不同角度对业务流程的变更提出了应对方法。
文献[2]在Petri网模型中用关系矩阵表示节点路由，用状态标识矩阵描述实例状态，通过变更处理算法查找可越过节点和迁移节点，从而实现业务流程的及时变更。为了表达活动之间的依赖关系，文献[3]提出了控制流检测表（CFC table），用于存储业务流程实例的所有可能变化。当执行发生变化时，生成新的CFC table。随后文献[4]通过分析新的CFC table中被修改的行，来增加、修改、删除规则以及变迁之间的结构一致性。虽然这种方式使得结构一致性有了保障，但却因CFC table的频繁更新造成不必要的开销。文献[5]在此基础上提出了基于业务流程相似性和数据类型相容性的适应更变方法。定义内容类型的相容性，通过操作类型检测表（Operation Type Checking table，OTC table）记录内容之间的相容性。内容之间的相容性变化不大，更新频率更低，于是在一致性的基础上比文献[4]缩小了开销。
然而这些研究基于元模型的业务流程，对流程数据的操作需要较大开发力度。
3 支持变更自适应的业务流程模型
本文在以Artifact为中心的业务流程模型（Arti-Flow）[6]的基础上，对其进行了添加和扩展，引入了版本信息、流程方向图等概念，提出了一种以数据为中心的业务流程的变更自适应模型（DBPCA， Data-centric Business Process Change Adaptation），为实现业务流程的动态性和自适应性提供了基础。
3.1 DBPCA模型
以数据为中心的业务流程模型具有动态实例与静态模式定义分离的特性、数据与活动的隔离特性、实例之间的隔离性以及工单的特性。在这些特性的基础上，DBPCA模型强调了业务流程中“任务”及“事件”的逻辑关系，引入版本信息、流程方向图等概念，为业务流程变更自适应做了铺垫。
DBPCA模型是分层结构，由顶层的业务流程模式、底层的数据库模式以及中间的映射模块三部分组成。业务流程模式中包含了流程定义部分、规则约束部分和各类工单，流程的定义和执行受规则约束的规范，工单为业务流程提供各类信息。底层的数据库模式类似ER模型。映射模块为业务流程和数据库提供通信机制。工单是一个具体的，可识别的，能够自描述的信息块，商业人员可利用其来运行业务。工单构成了业务流程产生和存储的信息块，是业务流程中唯一包含的准确信息，其内部数据与数据库数据通过映射模块一一对应。
3.2 版本信息
版本信息是工单内关于业务流程的主要信息的一个相对简化的数据集，其形式化描述可表示为：
V = （V_ID， VD， L）
其中，V_ID是该版本的版本号（唯一）；VD是工单数据的子集，仅包含了工单ID和工单现在的状态；L是流程中任务及事件的逻辑关系，可抽象为一个有向无环图，称为流程方向图。
流程实例内的版本信息V包含L以及实例流程状态数据，取出这部分信息便于查询和操作动态改变执行顺序自适应变更修改，L是由事件集E内的事件，任务集T内的任务以及其相应关系组成的有向无环图，用于决定实例执行的前进方向。版本信息是决定一个业务流程实例前进方向的核心内容。图1通过实例列举了一个版本信息内L的数据表以及对应的流程方向图。
3.3 约束定义
文章设定了一系列流程定义时必须满足且运行和变更时必须遵守的规则，这些规则称为约束[7]。为了保证业务流程按照定义的方向执行，以及应对业务流程变更时系统的稳定性和版本决策的正确性，避免死循环和不确定性运行结果的产生，以下约束是至关重要的。
1）更新约束。业务流程变更必须满足更新约束，若本次变更包含以下冲突，则可能破坏运行方向的唯一性，使得业务流程产生不确定的结果，那么将禁止本次操作的所有更新。
任务事件冲突集：CT ? E×T 表示一个业务流程中事件响应引发某任务执行。若两个任务由一个事件引发或者说一个事件可由两个任务响应，则表示这两个任务存在冲突。
任务顺序冲突集：CET?Path（T×T）。Path（ti，tj）表示了两个任务的执行顺序关系；存在任务执行顺序关系使得任务ti执行后一定要执行任务tj（并非立即执行）。若Path（ti，tj）∈CET表示ti与tj两个任务有执行顺序上的冲突。即：任务ti执行后一定有任务tj执行，且任务tj执行后有ti执行，那么这两个任务顺序执行路径存在冲突。 流程方向冲突：业务流程由begin事件引发，并由end事件结束。若路径由begin事件开始，存在路径到达事件t（非end事件）且该路径终止于该事件，则存在流程方向冲突。
2）版本约束。每个业务实例在某一确定时刻能且只能按照其中一个版本所规定流程执行。
3）隔离约束。每个实例的执行都是相互独立的，实例对应的同类工单数据相互之间并无直接访问联系。
4 业务流程变更自适应系统
在上文提出的DBPCA模型的基础上，本节则研究扩展了传统的业务流程引擎，设计并实现了支持业务流程变更自适应的管理平台，同时详细分析了动态修改方法与自适应方法的过程与算法。与传统的以数据为中心的业务流程管理平台相比，本文研究具有以下特点：
1）任务与事件的逻辑关系为主要的流程控制手段；
2）业务流程管理与任务执行分离；
3）多业务流程版本共存；
4）支持业务流程变更自适应；
5）具有动态实例的查询功能。
4.1 系统结构及组成
系统采用Spring MVC框架模式实现，在jBPM业务流程引擎的基础结构上增加Artifact的构造模块以及Artifact与底层数据库的映射绑定模块，将数据提升到业务流程层面，然后添加规则验证模块和自适应模块，规则验证模块验证变更的自适应性，自适应模块实现业务流程的动态自适应机制。以数据为中心的业务流程变更自适应系统体系结构图如图2所示：
由图1所示，系统中各重点构成功能实现可做如下论述。
1）表示层。负责系统与用户的通信。用户通过用户管理模块、表单管理模块、流程管理模块、实例管理模块完成业务流程内容、变更业务流程定义。
2）Web服务器。采用Spring MVC模式，该轻量级框架扩展性强，代码架构清晰，有利于模块开发。
3）业务流程引擎。为业务流程服务提供运行环境，是业务流程系统的核心，负责解释过程定义、创建和执行过程实例、以及和业务流程应用及客户进行通信。本文的业务流程引擎jBPM是开源的可扩展平台，具有开发便利、易扩展、可移植等优点。
4）自适应模块。主要工作包括根据传入的流程变更信息修改业务流程的定义、协调动态实例。修改业务流程的定义主要用于协调变更前后的定义，修整流程定义，为实例自适应提供基础。动态实例的协调主要是协调受修改影响的运行时实例，保证这些实例在新模型下能够正确执行。这些处于过渡阶段的实例根据决策或按照旧版本继续执行，或按新版本执行，或按调整后的流程路径进行执行。
5）规则验证工具。根据规则约束验证业务流程定义和修改过程中是否有逻辑矛盾的流程，验证变更是否具有自适应性。自适应模块和验证工具可以使用户灵活地进行业务流程修改的定义，保证修改的正确性。
6）Artifact模块。负责Artifact的定义和结构存储，将实例数据保存至工单，减少与数据库的交互，提高了业务流程的灵活性。
7）映射模块。负责Artifact模型与数据库模型的映射，是数据持久化操作的保障。
8）实例日志。记录业务流程中所有的状态变化、事件以及和控制流相关的数据等信息。
9）版本信息。为了支持业务流程的动态灵活改进及实例自适应，在业务流程定义被长久修改后，还必须存储修改前的业务流程定义信息。
4.2 动态修改方法
实例内的版本信息包含了定义的业务流程执行方向，所以改变版本信息内的任务对应的前驱事件和产生事件，即可更改业务流程的运行轨迹，实现动态变更。业务流程定义的变更可完全通过工单数据的修改由任务与事件的逻辑重组实现。
定义1：业务流程在原定义任务内容和顺序的基础上产生的任何改变都称为业务流程的变更。
原子性的变更操作有三种：添加、删除、替换。任何变更操作都可由这三种原子性操作组合而成，所以本文只详细讨论这三种原子性操作的动态修改方法。需要注意的是，原子性操作直接影响了任务与事件的顺序逻辑关系，故受事件冲突约束和任务冲突约束的直接规范，在处理原子性操作的时候必须断开已更改的任务-事件逻辑关系，以满足任务事件冲突约束。
4.2.1 添加操作
添加原子操作分为两种情况，一种是在业务流程的两个相邻任务之间添加任务（L->L_1），一种是在业务流程的最后一个任务后添加任务（L->L_2）。
添加操作的修改过程如图3所示，首先要判断待删除的任务是否为最后一个任务：
（1）若要在任务Ti，Tj之间添加新的任务Tk，按以下三个步骤：
断开Tj任务与Ti产生事件的顺序关系；
Tk的前驱事件f_event为Ti的产生事件，Tk -> f_event = Ti -> e_event；
Tj的前驱事件为Tk的产生事件，Tj -> f_event = Tk -> e_event；
（2）若添加的新任务Tk在流程的最末，则按以下步骤：
将原最后的任务Tn的产生事件设为新的事件Event_n，断开事件end与原任务Tn的响应关系，Tn -> e_event = Event_n；
在Tn后添加新事件Tk；
Tk的前驱事件f_event为Tn的产生事件，Tk -> f_event = Tn -> e_event；
4.2.2 删除操作
企业的业务流程中的删除操作极少出现第一个任务就删除的情况，故在此主要分析中间任务删除情况（L->L_1）和最后一个任务的删除情况（L->L_2）。
删除操作的修改过程如图4所示，首先要判断待删除的任务是否为最后一个任务： （1）若要删除的任务Tk不是最后一个任务，Ti、Tj分别为Tk的前驱、后继任务，则按以下步骤：
将后者Tj的前驱事件设为前者Ti的产生事件Tj -> f_event = Ti -> e_event；
断开待删除任务Tk的前驱事件f_event与Tk的关系，保证任务事件冲突约束；
断开待删除任务Tk的产生事件与Tj的关系，保证事件冲突约束；
（2）若删除新任务Tk在流程的最末，Tn为Tk前一个任务，则按以下步骤：
将Tn的产生事件设为end事件，Tn -> e_event = end；
断开待删除任务Tk的前驱事件f_event与Tn的关系；
断开待删除任务Tk与end事件的关系，保证任务事件冲突约束；
4.2.3 替换操作
原子的替换操作只需将某个任务及其自带的产生任务替换为另一个新的任务和产生任务，若替换任务在流程末尾，则直接将任务的产生事件设为end事件。新任务取代了原任务的所有逻辑关系，故替换操作只与前驱事件和产生事件有关，而不干扰其他任务。
替换操作的修改过程如图5所示，版本信息的修改转换为流程任务的替换操作分为三个步骤：
1）添加任务Tk，将Tk的前驱事件设为被替换任务Ti的前驱事件；
2）将Tk下一任务Tj的前驱事件设为Tk的产生事件，若无下一任务，则将Tk响应事件设为end事件；
3）断开被替换任务Ti与Tk前驱事件和完成事件的关系，保证事件冲突约束和任务冲突约束。
4.3 变更自适应方法
在DBPCA模型中，业务流程的管理与任务执行分离，且持久化操作在任务彻底完成后进行，为动态运行时的变更自适应提供了可行性。本节提出了变更自适应，将上节中动态修改方法生成的变更后流程与原流程协调，生成方便实例自适应的流程定义，并给出动态自适应机制实现实例的自适应功能。
用户接口接收到用户的变更信息时，会先反馈给引擎调用“中断”处理机制保存当前数据，然后对变更后的业务流程进行逻辑分析，判断此次变更是否能够自适应。若不满足更新约束，系统将会禁止本次所有更新；若满足约束，则系统进行流程定义自适应，自适应过程完毕后会发送一个内部事件到引擎，继续动态实例自适应和新实例的执行。
4.3.1 流程定义自适应
图6展示了变更前流程及目标流程的简化方向图，变更起点是两个方向图第一个不同的任务，变更终点是两个方向图逆序第一个不同的任务。
根据变更变起点和终点，业务流程方向图可以分成三部分：
1）位于变更起点之前的部分为变更前部；
2）位于变更终点之后的部分为变更后部；
3）变更起点和终点之间内是变更区域。
前两种情况1）、2）所做修改为：
为原任务添加新的产生事件Event_Vn（n=1，2，..，表示版本号）；
将原任务的后继任务的驱动事件更改为Event_Vn；
将变更后流程内同任务的后继任务的驱动事件更改为原任务产生事件Event。
最后处理情况3），变更后部的第一个任务仅需添加新的前驱事件，并设为新版本变更区域最后一个任务的产生事件。变更自适应后业务流程方向图如图7所示。
修改产生的新流程定义与原定义合并后的业务流程方向图如图7所示，Task_B为变更前驱的第一个任务，满足情况1），于是添加了新的产生事件Event2_V1，并将原定义的下一个任务Task_C的前驱事件设为Event2_V1，而将新版本的后继任务Task_D的前驱事件设为Event2。如此，新实例会按照Event2事件为引导执行变更后的业务流程。Task_D属于情况2），是两个版本的变更区域内重复的任务，应与Task_B做同样修改，保证新实例的运行路径为由Event4引导的变更后路径。基于此再处理新版本变更区域最后一个任务Task_G，将其产生事件设为Task_E（变更后部的第一个任务）的前驱事件。
产生事件和驱动事件的变换可使新产生实例以新流程版本为默认前进方向执行。而将变更前后的业务流程的非变更区域合并，为后续业务流程实例任务的版本选择工作提供了方便。
4.3.2 动态实例自适应
由于变更后的流程在变更前部的最后任务添加了一个产生事件，并替换了原产生事件的逻辑关系，由原产生事件承载新的任务逻辑关系，故不需改变实例的产生事件便可按照新流程执行。由于当前实例已执行的最近任务可能属于方向图中三个部分的任一个，相应地，研究即将动态实例的自适应处理也分三种情况。
1）若已执行的最后一个任务在变更前部，则按照新定义的业务流程执行。
2）若已执行的最后一个任务在变更后部，由于变更后部的任务流程不受变更影响，故不做修改，扔按照原业务步骤执行。
3）若实例已经执行到了变更区域内的任务，如图8所示，该实例会根据实例日志及设定的回退路径回退到变更区域开始的地方，再按照新的流程定义重新执行。
由于业务流程中任务的回退受约束规则以及某些任务不可逆的限制，目前只能由技术人员专门在指定的任务处写入代码建立退回的转移路径，并不能够灵活实现任务的任意退回。
在实例自适应的过程中，难免出现异常。异常可能使实例执行结果错误甚至导致实例的信息丢失。异常情况分为可预见异常与不可预见异常两种类型。
1）可预见异常。在实例自适应过程中，对执行到变更区域内的实例需要根据日志数据回退。而某些任务是无法回退的，例如向用户发送邮件。对于无法回退的任务在处理回退自适应时就会产生异常，这类异常是可以预见的。对可预见异常，技术人员可利用代码获取异常实例的相关信息，存入异常实例列表供业务人员人工处理。 2）不可预见异常。对于不可预见的异常，为了防止其导致流程瘫痪，采取了设置时间阈值和重呼次数的方法。每个任务会设置一个时间阈值，若超过这个时间阈值仍未响应；则该任务的前置事件重新调用，发出请求再次执行该任务。若请求的次数超过了设置的重呼次数，则该实例发送给用户接口，交由人工操作解决。
5 结束语
本文的主要研究内容是以数据为中心的业务流程的变更自适应技术。在对以数据为中心的业务流程模型以及业务流程变更相关技术的研究基础上，发现了传统业务流程建模方法处理流程变更的不足。基于以上情况，本文提出了一种以数据为中心的业务流程的变更自适应模型，详细阐述该模型的架构及组成。提出了动态修改和变更自适应方法，并在jBPM流程引擎基础上实现了以数据为中心的业务流程变更自适应系统。该系统已在校工会平台中成功使用，使“九必访”审核、帮困申请等流程的管理、变更提高了效率。
然而，本文还存在不足之处需要进一步改进，例如：模型中各约束规则是保障业务流程正确运行的关键，需进一步地研究完善约束集及约束间的冲突；本文系统目前并不能够灵活实现任务的任意退回，将完善的回退机制引入，会有效提高易用性。
参考文献
[1] 张静乐， 杨扬， 曾明，等. 支持异常处理的柔性业务流程可信赖性分析[J]. 计算机科学， 2010， 37（4）：41-44.
[2] 刘清华， 李璐璐， 万立，等. 工作流的动态变更处理方法[J]. 计算机辅助设计与图形学学报， 2011， 23（2）：331-338.
[3] ZHANG S， WANG B. The research on decision approach of data dependence in dynamic workflow system[C]//Parallel and Distributed Computing， Applications and Technologies， 2005. PDCAT 2005. Sixth International Conference on. Dalian： IEEE， 2005： 1027-1029.
[4] MEJIA B J F， FALCARIN P， MORISIO M， et al. Dynamic context-aware business process： a rule-based approach supported by pattern identification[C]//Proceedings of the 2010 ACM Symposium on Applied Computing. Sierre： ACM， 2010： 470-474.
[5] 张红霞， 邹华， 林荣恒， 等. 基于马尔科夫决策过程的可适变业务流程建模及分析[J]. 电子与信息学报， 2013， 35（7）： 1760-1765.
[6] XU W， SU J， YAN Z， et al. An artifact-centric approach to dynamic modification of workflow execution[M]//Robert Meersman. On the Move to Meaningful Internet Systems： OTM 2011. Berlin Heidelberg：Springer ， 2011： 256-273.
[7] SUN Y， SU J. Conformance for DecSerFlow constraints[J]. Lecture Notes in Computer Science， 2014， 8831：139-153.
业务流程变更（Business Progress Change，BPC）[1]是在业务流程定义阶段或执行阶段出现，相对于原来的流程定义的更改，其需求有的来自于客户要求、相关法律变更等外因，有的来自于科技更新、追求效率效益等内因，都是为了使系统适应环境、优化流程、提升效率、提高收益。要在流程定义的时候提前考虑到所有可能的业务流程是非常困难的，而执行过程中变更需要业务人员与专业技术人员在前期沟通协调，制定变更计划。考虑到流程局部的修改可能牵扯到整个业务流程的变量配置，故变更时还需等待流程实例全部执行完毕或将运行实例临时撤销。由此可见，传统变更方式不仅耗时耗力，还需企业承担变更过程中可能导致的数据错误、信息丢失等风险。
若业务流程系统能够在仍有实例运行时的过程定义根据变更衍生出新的流程定义，并对过程中实例的情况做出反应和处理的能力，那么称该系统能够动态实现变更自适应。传统业务流程模型进行数据修改、逻辑变更的难度较大，不利于变更自适应技术的实现，而以数据为中心的业务流程模型将底层数据提升至流程工单（Artifact）中，修改数据简单易行。本文基于以数据为中心的业务流程模型，提出动态修改方法，研究了变更自适应技术，设计并实现了变更自适应业务流程系统。
与传统变更方法相比，变更自适应技术不仅能够判断变更能否自动化完成；并且能快速响应可自适应的变更而无需等待实例执行结束；同时自动适应变更内容，在不修改系统的前提下完成业务流程的变更。
2 国内外相关研究
目前，国内外的学者从不同角度对业务流程的变更提出了应对方法。
文献[2]在Petri网模型中用关系矩阵表示节点路由，用状态标识矩阵描述实例状态，通过变更处理算法查找可越过节点和迁移节点，从而实现业务流程的及时变更。为了表达活动之间的依赖关系，文献[3]提出了控制流检测表（CFC table），用于存储业务流程实例的所有可能变化。当执行发生变化时，生成新的CFC table。随后文献[4]通过分析新的CFC table中被修改的行，来增加、修改、删除规则以及变迁之间的结构一致性。虽然这种方式使得结构一致性有了保障，但却因CFC table的频繁更新造成不必要的开销。文献[5]在此基础上提出了基于业务流程相似性和数据类型相容性的适应更变方法。定义内容类型的相容性，通过操作类型检测表（Operation Type Checking table，OTC table）记录内容之间的相容性。内容之间的相容性变化不大，更新频率更低，于是在一致性的基础上比文献[4]缩小了开销。
然而这些研究基于元模型的业务流程，对流程数据的操作需要较大开发力度。
3 支持变更自适应的业务流程模型
本文在以Artifact为中心的业务流程模型（Arti-Flow）[6]的基础上，对其进行了添加和扩展，引入了版本信息、流程方向图等概念，提出了一种以数据为中心的业务流程的变更自适应模型（DBPCA， Data-centric Business Process Change Adaptation），为实现业务流程的动态性和自适应性提供了基础。
3.1 DBPCA模型
以数据为中心的业务流程模型具有动态实例与静态模式定义分离的特性、数据与活动的隔离特性、实例之间的隔离性以及工单的特性。在这些特性的基础上，DBPCA模型强调了业务流程中“任务”及“事件”的逻辑关系，引入版本信息、流程方向图等概念，为业务流程变更自适应做了铺垫。
DBPCA模型是分层结构，由顶层的业务流程模式、底层的数据库模式以及中间的映射模块三部分组成。业务流程模式中包含了流程定义部分、规则约束部分和各类工单，流程的定义和执行受规则约束的规范，工单为业务流程提供各类信息。底层的数据库模式类似ER模型。映射模块为业务流程和数据库提供通信机制。工单是一个具体的，可识别的，能够自描述的信息块，商业人员可利用其来运行业务。工单构成了业务流程产生和存储的信息块，是业务流程中唯一包含的准确信息，其内部数据与数据库数据通过映射模块一一对应。
3.2 版本信息
版本信息是工单内关于业务流程的主要信息的一个相对简化的数据集，其形式化描述可表示为：
V = （V_ID， VD， L）
其中，V_ID是该版本的版本号（唯一）；VD是工单数据的子集，仅包含了工单ID和工单现在的状态；L是流程中任务及事件的逻辑关系，可抽象为一个有向无环图，称为流程方向图。
流程实例内的版本信息V包含L以及实例流程状态数据，取出这部分信息便于查询和操作动态改变执行顺序自适应变更修改，L是由事件集E内的事件，任务集T内的任务以及其相应关系组成的有向无环图，用于决定实例执行的前进方向。版本信息是决定一个业务流程实例前进方向的核心内容。图1通过实例列举了一个版本信息内L的数据表以及对应的流程方向图。
3.3 约束定义
文章设定了一系列流程定义时必须满足且运行和变更时必须遵守的规则，这些规则称为约束[7]。为了保证业务流程按照定义的方向执行，以及应对业务流程变更时系统的稳定性和版本决策的正确性，避免死循环和不确定性运行结果的产生，以下约束是至关重要的。
1）更新约束。业务流程变更必须满足更新约束，若本次变更包含以下冲突，则可能破坏运行方向的唯一性，使得业务流程产生不确定的结果，那么将禁止本次操作的所有更新。
任务事件冲突集：CT ? E×T 表示一个业务流程中事件响应引发某任务执行。若两个任务由一个事件引发或者说一个事件可由两个任务响应，则表示这两个任务存在冲突。
任务顺序冲突集：CET?Path（T×T）。Path（ti，tj）表示了两个任务的执行顺序关系；存在任务执行顺序关系使得任务ti执行后一定要执行任务tj（并非立即执行）。若Path（ti，tj）∈CET表示ti与tj两个任务有执行顺序上的冲突。即：任务ti执行后一定有任务tj执行，且任务tj执行后有ti执行，那么这两个任务顺序执行路径存在冲突。 流程方向冲突：业务流程由begin事件引发，并由end事件结束。若路径由begin事件开始，存在路径到达事件t（非end事件）且该路径终止于该事件，则存在流程方向冲突。
2）版本约束。每个业务实例在某一确定时刻能且只能按照其中一个版本所规定流程执行。
3）隔离约束。每个实例的执行都是相互独立的，实例对应的同类工单数据相互之间并无直接访问联系。
4 业务流程变更自适应系统
在上文提出的DBPCA模型的基础上，本节则研究扩展了传统的业务流程引擎，设计并实现了支持业务流程变更自适应的管理平台，同时详细分析了动态修改方法与自适应方法的过程与算法。与传统的以数据为中心的业务流程管理平台相比，本文研究具有以下特点：
1）任务与事件的逻辑关系为主要的流程控制手段；
2）业务流程管理与任务执行分离；
3）多业务流程版本共存；
4）支持业务流程变更自适应；
5）具有动态实例的查询功能。
4.1 系统结构及组成
系统采用Spring MVC框架模式实现，在jBPM业务流程引擎的基础结构上增加Artifact的构造模块以及Artifact与底层数据库的映射绑定模块，将数据提升到业务流程层面，然后添加规则验证模块和自适应模块，规则验证模块验证变更的自适应性，自适应模块实现业务流程的动态自适应机制。以数据为中心的业务流程变更自适应系统体系结构图如图2所示：
由图1所示，系统中各重点构成功能实现可做如下论述。
1）表示层。负责系统与用户的通信。用户通过用户管理模块、表单管理模块、流程管理模块、实例管理模块完成业务流程内容、变更业务流程定义。
2）Web服务器。采用Spring MVC模式，该轻量级框架扩展性强，代码架构清晰，有利于模块开发。
3）业务流程引擎。为业务流程服务提供运行环境，是业务流程系统的核心，负责解释过程定义、创建和执行过程实例、以及和业务流程应用及客户进行通信。本文的业务流程引擎jBPM是开源的可扩展平台，具有开发便利、易扩展、可移植等优点。
4）自适应模块。主要工作包括根据传入的流程变更信息修改业务流程的定义、协调动态实例。修改业务流程的定义主要用于协调变更前后的定义，修整流程定义，为实例自适应提供基础。动态实例的协调主要是协调受修改影响的运行时实例，保证这些实例在新模型下能够正确执行。这些处于过渡阶段的实例根据决策或按照旧版本继续执行，或按新版本执行，或按调整后的流程路径进行执行。
5）规则验证工具。根据规则约束验证业务流程定义和修改过程中是否有逻辑矛盾的流程，验证变更是否具有自适应性。自适应模块和验证工具可以使用户灵活地进行业务流程修改的定义，保证修改的正确性。
6）Artifact模块。负责Artifact的定义和结构存储，将实例数据保存至工单，减少与数据库的交互，提高了业务流程的灵活性。
7）映射模块。负责Artifact模型与数据库模型的映射，是数据持久化操作的保障。
8）实例日志。记录业务流程中所有的状态变化、事件以及和控制流相关的数据等信息。
9）版本信息。为了支持业务流程的动态灵活改进及实例自适应，在业务流程定义被长久修改后，还必须存储修改前的业务流程定义信息。
4.2 动态修改方法
实例内的版本信息包含了定义的业务流程执行方向，所以改变版本信息内的任务对应的前驱事件和产生事件，即可更改业务流程的运行轨迹，实现动态变更。业务流程定义的变更可完全通过工单数据的修改由任务与事件的逻辑重组实现。
定义1：业务流程在原定义任务内容和顺序的基础上产生的任何改变都称为业务流程的变更。
原子性的变更操作有三种：添加、删除、替换。任何变更操作都可由这三种原子性操作组合而成，所以本文只详细讨论这三种原子性操作的动态修改方法。需要注意的是，原子性操作直接影响了任务与事件的顺序逻辑关系，故受事件冲突约束和任务冲突约束的直接规范，在处理原子性操作的时候必须断开已更改的任务-事件逻辑关系，以满足任务事件冲突约束。
4.2.1 添加操作
添加原子操作分为两种情况，一种是在业务流程的两个相邻任务之间添加任务（L->L_1），一种是在业务流程的最后一个任务后添加任务（L->L_2）。
添加操作的修改过程如图3所示，首先要判断待删除的任务是否为最后一个任务：
（1）若要在任务Ti，Tj之间添加新的任务Tk，按以下三个步骤：
断开Tj任务与Ti产生事件的顺序关系；
Tk的前驱事件f_event为Ti的产生事件，Tk -> f_event = Ti -> e_event；
Tj的前驱事件为Tk的产生事件，Tj -> f_event = Tk -> e_event；
（2）若添加的新任务Tk在流程的最末，则按以下步骤：
将原最后的任务Tn的产生事件设为新的事件Event_n，断开事件end与原任务Tn的响应关系，Tn -> e_event = Event_n；
在Tn后添加新事件Tk；
Tk的前驱事件f_event为Tn的产生事件，Tk -> f_event = Tn -> e_event；
4.2.2 删除操作
企业的业务流程中的删除操作极少出现第一个任务就删除的情况，故在此主要分析中间任务删除情况（L->L_1）和最后一个任务的删除情况（L->L_2）。
删除操作的修改过程如图4所示，首先要判断待删除的任务是否为最后一个任务： （1）若要删除的任务Tk不是最后一个任务，Ti、Tj分别为Tk的前驱、后继任务，则按以下步骤：
将后者Tj的前驱事件设为前者Ti的产生事件Tj -> f_event = Ti -> e_event；
断开待删除任务Tk的前驱事件f_event与Tk的关系，保证任务事件冲突约束；
断开待删除任务Tk的产生事件与Tj的关系，保证事件冲突约束；
（2）若删除新任务Tk在流程的最末，Tn为Tk前一个任务，则按以下步骤：
将Tn的产生事件设为end事件，Tn -> e_event = end；
断开待删除任务Tk的前驱事件f_event与Tn的关系；
断开待删除任务Tk与end事件的关系，保证任务事件冲突约束；
4.2.3 替换操作
原子的替换操作只需将某个任务及其自带的产生任务替换为另一个新的任务和产生任务，若替换任务在流程末尾，则直接将任务的产生事件设为end事件。新任务取代了原任务的所有逻辑关系，故替换操作只与前驱事件和产生事件有关，而不干扰其他任务。
替换操作的修改过程如图5所示，版本信息的修改转换为流程任务的替换操作分为三个步骤：
1）添加任务Tk，将Tk的前驱事件设为被替换任务Ti的前驱事件；
2）将Tk下一任务Tj的前驱事件设为Tk的产生事件，若无下一任务，则将Tk响应事件设为end事件；
3）断开被替换任务Ti与Tk前驱事件和完成事件的关系，保证事件冲突约束和任务冲突约束。
4.3 变更自适应方法
在DBPCA模型中，业务流程的管理与任务执行分离，且持久化操作在任务彻底完成后进行，为动态运行时的变更自适应提供了可行性。本节提出了变更自适应，将上节中动态修改方法生成的变更后流程与原流程协调，生成方便实例自适应的流程定义，并给出动态自适应机制实现实例的自适应功能。
用户接口接收到用户的变更信息时，会先反馈给引擎调用“中断”处理机制保存当前数据，然后对变更后的业务流程进行逻辑分析，判断此次变更是否能够自适应。若不满足更新约束，系统将会禁止本次所有更新；若满足约束，则系统进行流程定义自适应，自适应过程完毕后会发送一个内部事件到引擎，继续动态实例自适应和新实例的执行。
4.3.1 流程定义自适应
图6展示了变更前流程及目标流程的简化方向图，变更起点是两个方向图第一个不同的任务，变更终点是两个方向图逆序第一个不同的任务。
根据变更变起点和终点，业务流程方向图可以分成三部分：
1）位于变更起点之前的部分为变更前部；
2）位于变更终点之后的部分为变更后部；
3）变更起点和终点之间内是变更区域。
前两种情况1）、2）所做修改为：
为原任务添加新的产生事件Event_Vn（n=1，2，..，表示版本号）；
将原任务的后继任务的驱动事件更改为Event_Vn；
将变更后流程内同任务的后继任务的驱动事件更改为原任务产生事件Event。
最后处理情况3），变更后部的第一个任务仅需添加新的前驱事件，并设为新版本变更区域最后一个任务的产生事件。变更自适应后业务流程方向图如图7所示。
修改产生的新流程定义与原定义合并后的业务流程方向图如图7所示，Task_B为变更前驱的第一个任务，满足情况1），于是添加了新的产生事件Event2_V1，并将原定义的下一个任务Task_C的前驱事件设为Event2_V1，而将新版本的后继任务Task_D的前驱事件设为Event2。如此，新实例会按照Event2事件为引导执行变更后的业务流程。Task_D属于情况2），是两个版本的变更区域内重复的任务，应与Task_B做同样修改，保证新实例的运行路径为由Event4引导的变更后路径。基于此再处理新版本变更区域最后一个任务Task_G，将其产生事件设为Task_E（变更后部的第一个任务）的前驱事件。
产生事件和驱动事件的变换可使新产生实例以新流程版本为默认前进方向执行。而将变更前后的业务流程的非变更区域合并，为后续业务流程实例任务的版本选择工作提供了方便。
4.3.2 动态实例自适应
由于变更后的流程在变更前部的最后任务添加了一个产生事件，并替换了原产生事件的逻辑关系，由原产生事件承载新的任务逻辑关系，故不需改变实例的产生事件便可按照新流程执行。由于当前实例已执行的最近任务可能属于方向图中三个部分的任一个，相应地，研究即将动态实例的自适应处理也分三种情况。
1）若已执行的最后一个任务在变更前部，则按照新定义的业务流程执行。
2）若已执行的最后一个任务在变更后部，由于变更后部的任务流程不受变更影响，故不做修改，扔按照原业务步骤执行。
3）若实例已经执行到了变更区域内的任务，如图8所示，该实例会根据实例日志及设定的回退路径回退到变更区域开始的地方，再按照新的流程定义重新执行。
由于业务流程中任务的回退受约束规则以及某些任务不可逆的限制，目前只能由技术人员专门在指定的任务处写入代码建立退回的转移路径，并不能够灵活实现任务的任意退回。
在实例自适应的过程中，难免出现异常。异常可能使实例执行结果错误甚至导致实例的信息丢失。异常情况分为可预见异常与不可预见异常两种类型。
1）可预见异常。在实例自适应过程中，对执行到变更区域内的实例需要根据日志数据回退。而某些任务是无法回退的，例如向用户发送邮件。对于无法回退的任务在处理回退自适应时就会产生异常，这类异常是可以预见的。对可预见异常，技术人员可利用代码获取异常实例的相关信息，存入异常实例列表供业务人员人工处理。 2）不可预见异常。对于不可预见的异常，为了防止其导致流程瘫痪，采取了设置时间阈值和重呼次数的方法。每个任务会设置一个时间阈值，若超过这个时间阈值仍未响应；则该任务的前置事件重新调用，发出请求再次执行该任务。若请求的次数超过了设置的重呼次数，则该实例发送给用户接口，交由人工操作解决。
5 结束语
本文的主要研究内容是以数据为中心的业务流程的变更自适应技术。在对以数据为中心的业务流程模型以及业务流程变更相关技术的研究基础上，发现了传统业务流程建模方法处理流程变更的不足。基于以上情况，本文提出了一种以数据为中心的业务流程的变更自适应模型，详细阐述该模型的架构及组成。提出了动态修改和变更自适应方法，并在jBPM流程引擎基础上实现了以数据为中心的业务流程变更自适应系统。该系统已在校工会平台中成功使用，使“九必访”审核、帮困申请等流程的管理、变更提高了效率。
然而，本文还存在不足之处需要进一步改进，例如：模型中各约束规则是保障业务流程正确运行的关键，需进一步地研究完善约束集及约束间的冲突；本文系统目前并不能够灵活实现任务的任意退回，将完善的回退机制引入，会有效提高易用性。
参考文献
[1] 张静乐， 杨扬， 曾明，等. 支持异常处理的柔性业务流程可信赖性分析[J]. 计算机科学， 2010， 37（4）：41-44.
[2] 刘清华， 李璐璐， 万立，等. 工作流的动态变更处理方法[J]. 计算机辅助设计与图形学学报， 2011， 23（2）：331-338.
[3] ZHANG S， WANG B. The research on decision approach of data dependence in dynamic workflow system[C]//Parallel and Distributed Computing， Applications and Technologies， 2005. PDCAT 2005. Sixth International Conference on. Dalian： IEEE， 2005： 1027-1029.
[4] MEJIA B J F， FALCARIN P， MORISIO M， et al. Dynamic context-aware business process： a rule-based approach supported by pattern identification[C]//Proceedings of the 2010 ACM Symposium on Applied Computing. Sierre： ACM， 2010： 470-474.
[5] 张红霞， 邹华， 林荣恒， 等. 基于马尔科夫决策过程的可适变业务流程建模及分析[J]. 电子与信息学报， 2013， 35（7）： 1760-1765.
[6] XU W， SU J， YAN Z， et al. An artifact-centric approach to dynamic modification of workflow execution[M]//Robert Meersman. On the Move to Meaningful Internet Systems： OTM 2011. Berlin Heidelberg：Springer ， 2011： 256-273.
[7] SUN Y， SU J. Conformance for DecSerFlow constraints[J]. Lecture Notes in Computer Science， 2014， 8831：139-153.