一種支持簡便重構的過程元模型*

李 新,許元坤

(汕頭大學工學院,廣東 汕頭 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.