李 新,許元坤

(汕頭大學工學院,廣東 汕頭 515063)

1 引言

業(yè)務過程系統(tǒng)的出現(xiàn)對企業(yè)的經營和管理產生了深刻的影響，使企業(yè)能夠在計算機的支持下進行異步、松散耦合的協(xié)同信息處理，將企業(yè)的經營管理技術提升到了過程管理自動化的階段。在業(yè)務過程系統(tǒng)的發(fā)展中，工作流(Workflow)概念的提出具有重要意義[1]。

工作流對業(yè)務過程進行了抽象化處理，將業(yè)務過程中各步驟之間的邏輯關系抽取出來，稱為過程邏輯。與之相對應，業(yè)務自身的個體特性稱為業(yè)務邏輯。工作流的核心理念在于“過程邏輯與業(yè)務邏輯分離”，工作流管理系統(tǒng)WFMS(WorkFlow Management System)是實現(xiàn)這一理念的軟件平臺，即工作流管理系統(tǒng)為過程邏輯的自動化處理提供支持。

建筑于工作流基礎之上的業(yè)務過程系統(tǒng)一方面可以顯著提高系統(tǒng)的開發(fā)效率，另一方面，當業(yè)務過程系統(tǒng)需要重構的時候，得益于兩種邏輯的分離，可以使重構的任務大為簡化。然而，隨著工作流應用的日益擴大和不斷深入，人們發(fā)現(xiàn)“過程邏輯與業(yè)務邏輯分離”這一理想中的目標與現(xiàn)實中的實際情況具有相當大的差距。實際的情況常常是過程邏輯與業(yè)務邏輯以各種形式耦合在一起難于分離。以常見的公文審批為例，一份公文需要簽署多人的意見，在某一時刻，當前不同的審批結果將導向不同的執(zhí)行路徑。公文的審批意見屬于業(yè)務特性的范疇，而審批過程的執(zhí)行則屬于過程特性的范疇，顯而易見，兩種性質是密切相關的。過程-業(yè)務間的耦合是大量的業(yè)務過程的固有屬性，其形態(tài)多種多樣，對工作流中“過程邏輯與業(yè)務邏輯分離”的實現(xiàn)構成了巨大的挑戰(zhàn)。

過程邏輯與業(yè)務邏輯難于分離的現(xiàn)狀對工作流系統(tǒng)的應用和推廣造成了很多困難，已經成為工作流技術發(fā)展的瓶頸[2]。兩種邏輯的混疊使得工作流建模復雜，需要在過程模型中額外增加許多業(yè)務特性的描述，而由于工作流管理系統(tǒng)對于過程-業(yè)務間耦合問題的考慮不足，很多時候甚至無法對其進行規(guī)范化的描述。同時，過程的建模方法又直接影響著過程重構的實施，當業(yè)務過程面臨重構的需求時，復雜和不規(guī)范的過程模型將導致重構工作不易進行，并且使得重構任務變得十分繁重。本文針對上述問題，對過程模型中業(yè)務元素的規(guī)范化表示進行了研究，提出了新的過程模型方法，在此基礎上，進一步支持過程的簡便重構。

2 相關工作與問題分析

對于因過程-業(yè)務間的耦合而引起的過程不確定性問題，長期以來，研究者從不同角度對其進行了多方面的研究，并且在工作流的基礎上進一步提出了“柔性工作流”的概念[3]，所謂“柔性”是指工作流系統(tǒng)能夠在動態(tài)變化甚至信息不完整的情況下處理和應對業(yè)務過程的變更和異常的能力。柔性工作流的研究主要包括兩方面的內容：柔性策略和柔性模型。前者往往在特定的過程模型下，針對若干柔性問題的需求，研究過程路徑的柔性選擇、過程結構的動態(tài)修改以及過程的異常處理等方案策略[4～6]；后者則試圖建立支持柔性工作流的新的過程模型與軟件體系結構[7,8]。兩方面的研究內容是相互支撐的，柔性策略可以為柔性模型提供具體的技術方案，而柔性模型則可以為柔性策略的實現(xiàn)提供理論方法等基礎層面的支持。

工作流技術的軟件平臺—工作流管理系統(tǒng)正越來越多地增加了對柔性工作流的支持，如IBM的WebSphere MQ工作流產品使用數(shù)據(jù)映射的方式以更好地構建業(yè)務過程模型，METEOR(Managing End-To-End OpeRations)系統(tǒng)部分支持執(zhí)行路徑的柔性選擇并具有一定的異常處理能力，Agentwork系統(tǒng)使用了基于規(guī)則的柔性建模方法[9]，InWoLvE工作流挖掘系統(tǒng)采用數(shù)據(jù)挖掘和機器學習技術進行工作流建模，以提高過程對業(yè)務環(huán)境的適應性[10]，清華大學的CIMFlow工作流管理系統(tǒng)提供了分布式的自適應任務調度方法[11]等。

從研究現(xiàn)狀來看，柔性工作流的發(fā)展正處于“百花齊放”的局面，針對不同的問題，不斷有新的策略和模型提出。然而，就目前的研究結果而言，該領域尚遠未達到成熟的階段，許多問題還沒有在業(yè)界形成一致的看法。本文認為，對于柔性工作流，至少有以下幾個方面的問題值得進一步探討：

(1)許多柔性工作流系統(tǒng)采用了“剛性+柔性”的組合策略，即對于剛性過程使用WFMC等傳統(tǒng)模型，而對于不確定性過程，用另一套柔性技術方案作為補充。系統(tǒng)中實際存在著相互分離的兩種甚至多種過程模型和建模方法，這使得過程建模的復雜程度大大提高，同時，隨著系統(tǒng)的擴展，工作流系統(tǒng)本身的復雜度也會顯著上升。相對而言，如果能夠采用統(tǒng)一的模型方法，支持各種形式的過程建模，將是一種更好的選擇。

(2)工作流管理系統(tǒng)的過程邏輯的表達能力仍然有所欠缺，工作流中過程邏輯的表示主要依據(jù)的是工作流模式，而工作流模式種類繁多，某一種工作流管理系統(tǒng)通常只支持其中一部分的工作流模式。實際上，即便有一種工作流管理系統(tǒng)可以支持所有的工作流模式，依然無法滿足應用中許多過程邏輯表示的需求。因此，能否考慮改變將工作流模式看做一個整體的傳統(tǒng)觀點，而代之以一種“邏輯組合”的方式來構造工作流模式，既可以提高過程邏輯的表達能力，又可以增強表示方法的靈活性。

(3)現(xiàn)有系統(tǒng)對過程-業(yè)務間的耦合問題的考慮明顯不足，業(yè)務元素對過程邏輯的影響是多方面的，目前尚缺乏對這一問題的系統(tǒng)化的分析和總結。另外，許多系統(tǒng)沒有建立起對業(yè)務元素抽象描述的有效手段，導致系統(tǒng)中過程邏輯和業(yè)務邏輯的界線變得模糊不清，相互之間交織重疊。同時，受業(yè)務元素的影響，對過程邏輯的處理沒有嚴格按照“定義-解釋”的執(zhí)行機制，而是大量采用了程序代碼的方式，使得過程重構時需要重新編譯系統(tǒng)，重構任務繁重。

這幾點問題均與過程重構密切相關，下文將圍繞這些問題對過程模型和過程重構的內容做進一步的闡述。

3 過程邏輯

首先給出與業(yè)務過程相關的若干定義。

定義1(業(yè)務過程) 業(yè)務過程是一組按照特定邏輯關系組織在一起的一組業(yè)務活動的總體。業(yè)務過程可以表示為一個三元組，BP=〈B,P,A〉，其中BP為業(yè)務過程，B為業(yè)務活動的集合，P為活動間過程邏輯的集合，A為業(yè)務元素對過程邏輯的作用，即過程-業(yè)務的動態(tài)關聯(lián)的集合。

定義2(過程-業(yè)務的動態(tài)關聯(lián)) 業(yè)務元素的取值或結構與過程邏輯相關，并且，只有在過程的運行期才能獲取其數(shù)值及結構，將這種過程與業(yè)務間的相關性稱為過程-業(yè)務的動態(tài)關聯(lián)。設業(yè)務元素的集合為BS，BS的冪集為BSPS，過程邏輯的集合為P，則過程-業(yè)務的動態(tài)關聯(lián)集合A可表示為BSPS和P上的關系，即A：BSPS?P。

定義3(純過程邏輯) 某個過程邏輯，如果其中不含有任何與業(yè)務元素相關的內容，則稱該過程邏輯為純過程邏輯。對于只含有純過程邏輯的業(yè)務過程BP來說，相當于上述表示業(yè)務元素對過程邏輯的作用的集合A為空集，即A=?。

對于純過程邏輯而言，業(yè)務過程中的活動在工作流中只具有抽象狀態(tài)，而不具有個性化的業(yè)務狀態(tài)。例如，可以為活動設置以下的基本狀態(tài)：啟動、運行、掛起、完成(正常提交)和中止(異常停止)等，活動間過程邏輯的表示僅使用這些抽象的狀態(tài)。圖1顯示了兩種常見的工作流模式：順序模式和并行分支模式，這兩種模式均屬于純過程邏輯，當前一個活動狀態(tài)為完成時，后一個或者后一組活動可以開始啟動。

Figure 1 Schematic diagram of pure process logic圖1 純過程邏輯示意圖

按照定義1～定義3的敘述，可以將一個業(yè)務過程的內容劃分為三個組成部分：純過程邏輯、過程-業(yè)務動態(tài)關聯(lián)的過程邏輯和業(yè)務邏輯。與以往的劃分方法相比，本文對過程邏輯進行了進一步的細分，突出了過程-業(yè)務動態(tài)的關聯(lián)這一要素，之所以這樣做是因為該要素與過程的建模及過程重構等問題具有直接的、密切的聯(lián)系。

圖2是一個簡單的業(yè)務過程片斷，其描述如下：首先用戶填寫維修申請；然后，由業(yè)務員對申請審核提交；系統(tǒng)根據(jù)申請表中的數(shù)據(jù)進行判斷，如果申請維修的日期在貨物出售一個月以內，則予以免費更換；如果屬于電腦主機部件，且時間在一個月到三年之間，則予以免費維修；如果屬于外設部件，且時間在一個月到一年之間，則予以免費維修；此外，進行收費維修。

Figure 2 Schematic diagram of the process of computer maintenance圖2 電腦維修業(yè)務過程片段示意圖

該業(yè)務過程片斷包含了兩組過程邏輯：從“維修申請”活動到“申請審核”活動之間是順序邏輯，屬于純過程邏輯；而從“申請審核”到三個具體的“維修”活動之間是選擇邏輯，選擇的因素為貨物類型、售出時間等業(yè)務元素，因此，這一過程邏輯屬于過程-業(yè)務動態(tài)關聯(lián)的過程邏輯。

當業(yè)務環(huán)境和用戶需求等發(fā)生變化時，需要對業(yè)務過程系統(tǒng)進行變更或重新設計來適應這種變化，這稱為業(yè)務過程系統(tǒng)的重構。按照本文對業(yè)務過程內容的劃分，可以將業(yè)務過程系統(tǒng)的重構分解為與之對應的三個方面：純過程邏輯的重構、過程-業(yè)務動態(tài)關聯(lián)的過程邏輯的重構和業(yè)務邏輯的重構，其中，前兩者屬于過程邏輯的范疇，而后一個則與過程結構無關。由此，本文提出以下定義。

定義4(過程重構) 業(yè)務過程系統(tǒng)中任何與過程邏輯相關的重構稱為過程重構。

業(yè)務過程系統(tǒng)的重構內容如圖3所示。

Figure 3 Schematic diagram of the content of process reconfiguration圖3 業(yè)務過程系統(tǒng)的重構內容示意圖

本文討論的主題是過程重構，業(yè)務邏輯的重構完全屬于應用程序內部的問題，不在本文討論范圍之內。

4 WFMC模型與柔性工作流

WFMC的過程元模型是工作流領域具有權威地位的一種模型，該模型如圖4所示。

Figure 4 Schematic diagram of WFMC process meta-model圖4 WFMC過程元模型示意圖

在這個元模型中，WFMC定義了過程的基本元素及其相互間的關系，其中有兩個元素值得關注：工作流相關數(shù)據(jù)和轉移條件。工作流相關數(shù)據(jù)是跨越在過程邏輯和業(yè)務邏輯之間的一種元素，它屬于業(yè)務性的數(shù)據(jù)，但同時又在過程邏輯的表示中被使用；轉移條件是活動的組成部分，可以表示活動之間的轉移關系，在轉移活動中對工作流相關數(shù)據(jù)進行了引用。從第3節(jié)的敘述可以看出，工作流相關數(shù)據(jù)和轉移條件的作用正是用于表達本文所提出的過程-業(yè)務動態(tài)關聯(lián)方面的內容。然而，在WFMC的模型中，對于轉移條件和工作流相關數(shù)據(jù)的細節(jié)卻并未制定具體的規(guī)范，具體表現(xiàn)在：

(1)沒有對工作流相關數(shù)據(jù)的形式做出規(guī)范；

(2)沒有對工作流相關數(shù)據(jù)的使用和引用方法做出規(guī)范；

(3)沒有對轉移條件的形式做出規(guī)范；

(4)沒有對活動中如何放置轉移條件做出規(guī)范。

由此可知，WFMC模型對于工作流相關數(shù)據(jù)和轉移條件的約定是極為寬松的。這種寬松的形式為工作流管理系統(tǒng)在業(yè)務過程的設計和實現(xiàn)上留下了自由發(fā)展的空間，但另一方面，也連帶地導致了業(yè)務過程設計和實現(xiàn)上的隨意性乃至混亂的局面。隨著企業(yè)業(yè)務過程復雜度的提高和過程重構頻繁度的上升，這種隨意性的負面作用變得越來越明顯，過程-業(yè)務的動態(tài)關聯(lián)往往以過程邏輯和業(yè)務邏輯緊密耦合的形式來表示(而且絕大多數(shù)時候采用的是程序代碼的形式)，同時，由于設計開發(fā)人員的“隨意發(fā)揮”，即便是在同一種工作流管理系統(tǒng)之下，不同人員對于業(yè)務過程的實現(xiàn)方法也會呈現(xiàn)出較大的差別。下面以圖2中“申請審核”活動到“免費更換”、“免費維修”和“收費維修”三個活動之間的過程邏輯的實現(xiàn)方法來闡述這一問題，基于WFMC元模型的工作流系統(tǒng)的示意性實現(xiàn)方法如下：

duration=presentdate()-application.getsaledate();

if (duration≤1 month ) thenflowobj.start(ActFreechg)；

…∥其它業(yè)務處理代碼

componenttype=application.gettype();

if ((componenttypeismaincomponente) and (duration>1 month) and (duration≤3 years))

thenflowobj.start(ActFreerep)；

…∥其它業(yè)務處理代碼

if ((componenttypeisexternalcomponente) and (duration>1 month) and (duration≤1 year))

thenflowobj.start(ActFreerep)；

…∥其它業(yè)務處理代碼

flowobj.start(ActChargerep)；

其中，duration和componenttype是工作流相關數(shù)據(jù)，表示貨物出售時間和貨物類型；if語句為轉移條件，ActXXX為活動，工作流管理系統(tǒng)提供了start方法用于啟動活動。

在上述代碼中，業(yè)務處理和轉移條件是交織在一起的，過程邏輯和業(yè)務邏輯緊密耦合，因為工作流管理系統(tǒng)并沒有提供將兩種邏輯分離的指導原則和技術手段。

柔性工作流注意到了傳統(tǒng)的工作流系統(tǒng)中所存在的問題，對過程-業(yè)務動態(tài)關聯(lián)內容的表達進行了部分的規(guī)范，例如ECA(Event，Condition，Action)規(guī)則等方法，提出將規(guī)則(相當于WFMC模型中的轉移條件)單獨進行放置，并由事件進行驅動。柔性工作流系統(tǒng)對圖2中的過程邏輯的示意性實現(xiàn)方法如下，

業(yè)務處理模塊：

duration=presentdate()-application.getsaledate();

componenttype=application.getcomponent();

…∥其它業(yè)務處理代碼

過程邏輯模塊(業(yè)務規(guī)則)：

if (duration≤1 month) thenflowobj.start(ActFreechg)

…∥其它規(guī)則

與傳統(tǒng)的工作流系統(tǒng)相比，柔性工作流系統(tǒng)對過程-業(yè)務動態(tài)關聯(lián)的過程邏輯在形式上進行了適當?shù)姆蛛x，業(yè)務邏輯與過程邏輯的代碼分別處于不同的模塊中。同時，在一種系統(tǒng)內部，業(yè)務規(guī)則的表達也具有較為規(guī)范的形式。然而，應該注意到柔性工作流對過程邏輯和業(yè)務邏輯的分離仍然是有限的，業(yè)務數(shù)據(jù)直接嵌入在業(yè)務規(guī)則的語句中，也就是說，工作流相關數(shù)據(jù)所引起的過程邏輯和業(yè)務邏輯緊密耦合的現(xiàn)象并未得到根本改變，并且，柔性工作流依然使用程序代碼的方式實現(xiàn)業(yè)務規(guī)則，并繼續(xù)將業(yè)務規(guī)則作為活動的一部分包含在活動中，這些都對可能發(fā)生的過程重構造成負面的影響。

5 過程重構

假定圖2中的業(yè)務過程發(fā)生了以下改變：

(1)需要兩個業(yè)務員同時對“維修申請”進行審核，兩份審核均通過才能進入維修環(huán)節(jié)。

(2)維修條例將免費更換的時間延長為三個月，免費維修的時間也據(jù)此做相應改變，其它不變。即申請維修的日期在貨物出售三個月以內，則予以免費更換；如果屬于電腦主機部件，且時間在三個月到三年之間，予以免費維修；如果屬于外設部件，且時間在三個月到一年之間，則予以免費維修。

以上兩個變化涉及到圖2中兩個過程邏輯的變化，因此該問題屬于過程重構。對于基于WFMC元模型的工作流系統(tǒng)，重構內容如下：

(1)需要將“維修申請”活動到“申請審核”活動之間的順序模式改為并行分支模式。

(2)由于有兩個并行的“審核”活動，因此，需要添加一個匯聚活動使兩個并行活動會合，采用的工作流模式為同步模式。

(3)需要修改涉及到貨物出售時間的有關程序代碼，將“一個月”改為“三個月”。

(4)把第4節(jié)中用于選擇“免費更換”、“免費維修”和“收費維修”三個活動的if語句從“申請審核”活動中移走，放置到“匯聚”活動中。這是因為在重構后的業(yè)務過程中，“申請審核”活動的功能變?yōu)閱我坏娜斯徍?，而選擇“免費更換”、“免費維修”和“收費維修”的任務從“申請審核”活動轉移到了“匯聚”活動。

上述(1)和(2)可以通過修改過程定義來完成，(3)和(4)則需要通過修改程序代碼來完成。重構后的業(yè)務過程如圖5所示。

Figure 5 Schematic diagram of process structure after process reconfiguration圖5 過程重構后的過程結構示意圖

由以上實例可知，基于WFMC元模型的工作流系統(tǒng)在過程重構時，不僅需要改變過程定義，而且往往不得不對程序代碼進行修改。

柔性工作流比起傳統(tǒng)的工作流系統(tǒng)在過程重構上所取得的進步極為有限。以本文所示的實例而言，柔性工作流系統(tǒng)所要執(zhí)行的重構任務和傳統(tǒng)的工作流系統(tǒng)大致相同，區(qū)別只在于柔性工作流的業(yè)務規(guī)則被放置在單獨的程序模塊中，在做代碼修改的時候，可以更加快速、準確地對修改部分定位以及避免代碼間的交叉影響。

從廣義上講，業(yè)務過程系統(tǒng)的重構屬于軟件重構的范疇，可以應用一般的軟件重構技術方法。但是，業(yè)務過程系統(tǒng)的重構又存在著其特殊性的一面，首先，業(yè)務過程系統(tǒng)通常具有較大的規(guī)模，整個系統(tǒng)的設計、開發(fā)和部署會耗費大量的人力物力，所以，業(yè)務過程系統(tǒng)的重構應盡量避免“牽一發(fā)而動全局”的情況，希望將系統(tǒng)的變動局限在盡可能小的范圍內，即偏向于“局部重構”的策略；其次，業(yè)務過程系統(tǒng)通常涉及到多種業(yè)務處理的組合，來自任何一個環(huán)節(jié)的變化都有可能引發(fā)過程的重構，也就是說，比起一般的應用系統(tǒng)，業(yè)務過程系統(tǒng)有可能會較多地遭遇重構的需求，導致重構的頻率顯著上升。

修改程序代碼是一般的軟件系統(tǒng)重構常用的方法，進行代碼重構時，必然要經歷以下階段：代碼重寫、編譯、連接和部署，整個過程需要耗費較大的人力物力。并且修改程序代碼還需要一個基本的前提，就是能夠獲取到程序源代碼，對于業(yè)務過程系統(tǒng)而言，通常用戶都不具備這一條件，因此，必須有軟件供應商的參與、協(xié)助才能開展代碼重構工作。

由以上分析可知，過程重構的頻繁性和采用修改程序代碼的過程重構方式之間形成了一種難以調和的矛盾。事實上情況正是如此，例如，ERP就是一種基于工作流的業(yè)務過程系統(tǒng)。以當前最具有代表性的ERP產品—SAP而言，用戶若要進行系統(tǒng)重構是一件相當困難的任務，必須在SAP技術人員的全程指導和支援下才能開展此類工作，并且代價高昂，又極為耗時、耗力。

工作流的概念提出的時候，對過程重構的問題有過認真的考慮，“過程邏輯與業(yè)務邏輯分離”的理念和將過程的定義與過程執(zhí)行階段分開的技術方法都遵循的是降低過程重構復雜度的原則。可是，受限于過程邏輯表達能力和系統(tǒng)運行機制的限制，以往的方法難以處理過程-業(yè)務動態(tài)關聯(lián)的情況，使得過程邏輯很多時候無法用過程定義而是要用程序代碼的方式實現(xiàn)，造成了業(yè)務過程模型復雜和過程重構不易實施的局面。

本文針對這一問題，提出了簡便重構的概念。

定義5(簡便重構) 通過過程定義的方式或以過程定義為主的方式所進行的與業(yè)務邏輯有效隔離的過程重構，稱為過程的簡便重構。

上述定義強調了兩個方面：

(1)過程重構應以過程定義為主，盡量不涉及到程序代碼的修改。

(2)在過程邏輯和業(yè)務邏輯之間應當建立起有效的隔離機制，降低兩者的耦合度。

從目前的情況來看，無論是基于WFMC模型的傳統(tǒng)工作流系統(tǒng)，還是其后加入“柔性”策略的柔性工作流系統(tǒng)，均不具備簡便重構的條件；其根本原因在于，它們的過程元模型和系統(tǒng)框架都沒有對過程-業(yè)務動態(tài)關聯(lián)的因素予以充分考慮。

6 一種新的過程元模型

本文認為，“剛性+柔性”的組合模式僅僅是工作流發(fā)展過程中的一種過渡形式，最終應該在過程的元模型中吸收進各種“柔性”的要素，使得“柔性”成為過程模型方法的內在特性。過程的簡便重構不是一個孤立的問題，它是系統(tǒng)本身具備強有力的過程邏輯表達能力和處理能力的一種體現(xiàn)。

在上文中，對WFMC元模型和柔性工作流所存在的問題進行了初步的分析，下面進一步討論與過程邏輯相關的若干問題。

(1)工作流模式的問題。

工作流模式是過程邏輯的抽象表達形式，現(xiàn)有的工作流技術將工作流模式作為一個整體的單元進行處理，這種方法造成的一個結果就是工作流模式種類繁多，隨著過程邏輯復雜程度的提高，模式類型的數(shù)量呈爆炸式增長。事實上，過程邏輯作為活動間的關系，可以被分解為更基礎的單元，如圖6所示。

Figure 6 Schematic diagram of the decomposition of process logic圖6 過程邏輯分解示意圖

圖6中存在兩組活動的集合：活動集1和活動集2?；顒蛹?經過某種邏輯進行匯合，然后又經過另一種邏輯分支轉移到活動集2。而匯合邏輯與分支邏輯的組合即為過去被看做一個整體單元的工作流模式。從邏輯學的角度而言，匯合邏輯和分支邏輯并沒有什么區(qū)別，兩者可以采用完全一致的邏輯表達形式，只是其中的內容有所分別，匯合邏輯中的內容是活動的狀態(tài)，而分支邏輯中的內容是活動的動作。假定邏輯形態(tài)的數(shù)量為N，則匯合邏輯與分支邏輯的組合數(shù)為N2，即過程邏輯(工作流模式)的類型數(shù)理論上為N2。因此，將工作流模式分解為匯合邏輯和分支邏輯可以有效解決單一的工作流模式“組合爆炸”的問題。過程邏輯分解的另一個好處在于，可以對過程邏輯的性質進行更加細致的分析，對其邏輯特征進行更好的抽象。

(2)過程邏輯表達形式統(tǒng)一的問題。

現(xiàn)有的工作流模式在表達過程邏輯時有一個限制，只能在純過程邏輯的范圍內，而過程-業(yè)務動態(tài)關聯(lián)的過程邏輯則是用程序代碼另外描述的；僅有前者采用的是過程定義的方式。事實上，純過程邏輯和過程-業(yè)務動態(tài)關聯(lián)的過程邏輯的區(qū)別不在于邏輯特性本身，而在于邏輯中所包含的具體成分：在純過程邏輯中，是過程、活動的抽象內容，而在過程-業(yè)務動態(tài)關聯(lián)的過程邏輯中，是與業(yè)務處理相關的內容。因此，在對業(yè)務元素進行抽象映射的處理后，兩者在表達形式上可以統(tǒng)一，都能夠采用過程定義的方式加以實現(xiàn)。

(3)轉移條件的問題。

WFMC元模型把轉移條件放置在活動內部，這在某種程度上來說是不合理的。轉移條件表達的是活動間的轉移關系，在層次上應處于和活動平行的地位，而不是從屬于活動?，F(xiàn)有的方式造成的一個直接的結果就是，轉移條件無法表達多個活動的匯合，當匯合時，必須額外引進一個匯聚活動，圖5即為一例。

(4)工作流相關數(shù)據(jù)的問題。

工作流相關數(shù)據(jù)本質上反映的是活動的業(yè)務狀態(tài)，既與業(yè)務處理相關，又與過程邏輯相關，對它的形式和使用方式應該做出嚴格限定。在系統(tǒng)中，原有的工作流相關數(shù)據(jù)需要被分解為兩個實體，一個是業(yè)務處理中的程序數(shù)據(jù)，另一個是過程邏輯中的過程定義數(shù)據(jù)，兩個實體間可以通過映射的方式建立聯(lián)系。

基于以上對WFMC元模型與現(xiàn)有工作流技術的分析，并吸取了在工作流系統(tǒng)中運用事件機制的思路(文獻[4，12～14])，本文提出了一種新的過程元模型—ESR元模型，圖7顯示了該元模型的基本組成和結構。

Figure 7 Schematic diagram of ESR meta-model圖7 ESR元模型示意圖

對比圖4和圖7可以看到，在新的過程元模型中，去除了原先缺乏細節(jié)規(guī)范的工作流相關數(shù)據(jù)和轉移條件兩項元素，增加了事件、狀態(tài)和規(guī)則三項新的元素。

定義6(事件) 事件是業(yè)務過程系統(tǒng)中對所發(fā)生的行為的抽象，事件可用一個三元組表示：Event=〈eID,eName,RuleGroup〉，eID為事件的標示，eName為事件的名稱，RuleGroup為事件所關聯(lián)的規(guī)則群。

過程和活動均可擁有事件，按照事件是否與具體業(yè)務相關，又可將事件分為系統(tǒng)事件和業(yè)務事件，比如：過程暫停和活動完成可表示為系統(tǒng)事件，某項業(yè)務中的數(shù)據(jù)表格填寫完畢可表示為業(yè)務事件。系統(tǒng)事件屬于“純過程邏輯”的范疇，對任何類型的業(yè)務過程均適用，因此在工作流管理系統(tǒng)中采用預定義的方式設定。而業(yè)務事件則隨業(yè)務處理的需求而定，可在業(yè)務過程模型中由開發(fā)人員自行定義。盡管概念上存在著差別，但系統(tǒng)事件和業(yè)務事件的表達形式是完全一致的，并且，工作流管理系統(tǒng)對兩種事件也采用了完全相同的處理方式。

定義7(狀態(tài)) 狀態(tài)是業(yè)務過程系統(tǒng)中對形態(tài)、狀況的抽象。狀態(tài)可用一個四元組表示：State=〈sID,sName,sDomain,sMap,Value〉，sID為狀態(tài)標示，sName為狀態(tài)名，sDomain為狀態(tài)取值范圍，sMap為狀態(tài)與業(yè)務數(shù)據(jù)的映射關系，Value為狀態(tài)的取值。

過程、活動和角色均可擁有狀態(tài)，與事件類似，狀態(tài)也可分為系統(tǒng)狀態(tài)和業(yè)務狀態(tài)兩類，比如，活動的就緒、執(zhí)行、掛起和完成等屬于系統(tǒng)狀態(tài)，而上文例子中貨物出售時間則可表示為業(yè)務狀態(tài)。

事實上，在以往的工作流系統(tǒng)中已經存在狀態(tài)的概念，但是與本文中的狀態(tài)相比，有以下幾點不同：

(1)WFMC元模型并未把狀態(tài)作為一種標準的模型元素來看待。

(2)以往工作流系統(tǒng)中的狀態(tài)基本屬于“純過程邏輯”的范疇，僅相當于本文中的系統(tǒng)狀態(tài)。

(3)以往工作流系統(tǒng)中的狀態(tài)為系統(tǒng)預定義狀態(tài)，無法由用戶自行定義擴展。

(4)狀態(tài)變化的處理方法對用戶透明，用戶無法根據(jù)業(yè)務需求干涉和改變處理過程。

從概念上說，ESR元模型中的狀態(tài)覆蓋了以往工作流中狀態(tài)和工作流相關數(shù)據(jù)兩個方面的內容，同時在表達形式和使用方法上進行了規(guī)范、統(tǒng)一。

定義8(規(guī)則) 規(guī)則是ESR(Event-State-Rule)元模型中過程邏輯的表達形式，規(guī)則可用一個二元組表示:Rule=〈P,Q〉，P是規(guī)則的前提，Q是規(guī)則的結果，習慣上，將以上的二元組表達為P→Q的形式。

P是基于狀態(tài)的邏輯表達式，用于表示圖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為數(shù)據(jù)，數(shù)據(jù)的形式有狀態(tài)(State)、常數(shù)(Constant)和函數(shù)返回值(F、Count);Founc為一般函數(shù);Count是計數(shù)函數(shù)，其參數(shù)為若干邏輯表達式，返回值為邏輯值為“真”的邏輯表達式個數(shù)。假定P1、P2、P3為邏輯表達式，P1=True，P2=True，P3=False，則Count(P1,P2,P3)的返回值為2，Count函數(shù)的作用是提供一種“多選邏輯”，這是業(yè)務過程中廣泛存在的一種邏輯，比如，項目評審中的投票表決等；others為保留字，表示一個規(guī)則群中其它規(guī)則都不滿足時的情況。

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(xiàn)為活動中的動作(函數(shù))；SetState是狀態(tài)設置函數(shù)，將值Value賦予狀態(tài)State；Value為數(shù)據(jù)，可以是另一個狀態(tài)當前的取值(作用相當于變量)，常數(shù)(Constant)或者函數(shù)的返回值；Founc為函數(shù)，函數(shù)有返回值，并且可以帶有參數(shù)。

Q具有和P類似的文法結構，只是其邏輯關系和P相比簡單一些，因此在系統(tǒng)實現(xiàn)時，只需要做出一種模型解釋器，即可同時解釋規(guī)則的前提和結果。

一組相關的規(guī)則組織在一起形成一個規(guī)則群，而規(guī)則群與事件相關聯(lián)，由特定的事件觸發(fā)規(guī)則的匹配。這種機制實質上體現(xiàn)的是“數(shù)據(jù)驅動”的思路，即由系統(tǒng)狀態(tài)的變化驅動過程的控制，實現(xiàn)活動間的轉移。

7 基于ESR元模型的工作流模型框架和業(yè)務過程建模方法

7.1 工作流模型框架

過程-業(yè)務的動態(tài)關聯(lián)是業(yè)務過程的內在屬性，對這一問題的處理方法很大程度上決定了工作流系統(tǒng)對過程邏輯與業(yè)務邏輯的分離程度。在以往的工作流系統(tǒng)中，對于過程邏輯與業(yè)務邏輯的界限時常處于并不明確的狀態(tài)，導致兩種邏輯很多時候以高耦合度的方式呈現(xiàn)，第4節(jié)中的例子對此已有說明。

ESR元模型確立了一種新的工作流模型框架，其主要內容包括：

(1)狀態(tài)映射將與過程邏輯相關的業(yè)務數(shù)據(jù)映射為業(yè)務狀態(tài)。

(2)邏輯規(guī)則形式的過程邏輯表示方法，并且采用數(shù)據(jù)化的方式對邏輯規(guī)則進行存儲。

(3)事件機制：由事件觸發(fā)邏輯規(guī)則的匹配，實施過程控制。

這一模型框架清晰劃分了過程邏輯與業(yè)務邏輯之間的界限，明確了過程定義和程序代碼的使用范圍，其概況如圖8所示，圖中橫線的下方屬于業(yè)務邏輯的范疇，采用程序代碼的方式實現(xiàn)；橫線的上方屬于過程邏輯的范疇(包含過程-業(yè)務的動態(tài)關聯(lián))，采用過程定義的方式實現(xiàn)。過程定義中除了傳統(tǒng)的圖形化過程結構定義之外，還包括事件定義、狀態(tài)定義、狀態(tài)映射定義和邏輯規(guī)則定義等，過程定義形成的業(yè)務過程模型以數(shù)據(jù)化的形式存儲在計算機中，由模型解釋器在過程的運行期解釋執(zhí)行。

Figure 8 Schematic diagram of workflow framework on ESR meta-model圖8 基于ESR元模型的工作流模型框架示意圖

7.2 過程建模方法

基于ESR元模型的過程建模大致分為以下幾個步驟：

(1)過程結構圖定義，描述過程的基本結構。和傳統(tǒng)的過程結構圖相比，這里的過程結構圖增加了一項新的圖形元素—規(guī)則群。

(2)事件、狀態(tài)與狀態(tài)映射定義。對于過程-業(yè)務動態(tài)關聯(lián)的情況，可以由用戶定義與業(yè)務相關的事件和狀態(tài)；對于純過程邏輯，則僅使用系統(tǒng)預定義的事件和狀態(tài)。

(3)規(guī)則與規(guī)則群定義：描述過程邏輯的細節(jié)以及規(guī)則與事件的對應關系。

下面針對典型的過程邏輯形態(tài)，分別敘述基于ESR元模型的過程建模方法。

7.3 順序邏輯建模

順序邏輯是最簡單的過程邏輯形態(tài)，其過程結構圖如圖9所示。

Figure 9 Structure diagram of the process for sequence logic圖9 順序邏輯過程結構圖

與以往的過程結構圖僅有活動不同，圖9的過程結構圖中還包含了位于活動間的規(guī)則群，設圖9中的規(guī)則群記為RG，RG中的規(guī)則由活動1預定義的提交事件觸發(fā)，設eActcommit為活動提交事件的名稱，則事件與規(guī)則群掛接的定義形式為：

Act1.eActcommit→RG

順序邏輯為純過程邏輯，活動1結束后活動2開始執(zhí)行，因此無須定義業(yè)務狀態(tài)。設finished為系統(tǒng)狀態(tài)，表示活動完成；start()為系統(tǒng)方法，表示活動的啟動，則規(guī)則定義為：

Rule:Act1.finished→Act2.start()

規(guī)則Rule放置在規(guī)則群RG中，掛接在規(guī)則群上的事件觸發(fā)規(guī)則群中規(guī)則的匹配，如果系統(tǒng)的狀態(tài)使某個規(guī)則的前提為真，則由該規(guī)則的結果確定后續(xù)需要執(zhí)行的活動和動作；經過模型解釋器對規(guī)則的解釋，工作流管理系統(tǒng)即可實施相應的過程控制。

7.4 分支/并行邏輯建模

分支/并行邏輯是工作流中較為復雜的一類邏輯形態(tài)，它的具體形式多種多樣，按照分支的個數(shù)可以劃分為單路分支(異或)和多路分支(并行)兩大類，而多路分支還可以具有不同的邏輯關系。分支/并行邏輯的過程結構圖如圖10所示。

Figure 10 Structure diagram of the process for parallel/split logic圖10 分支/并行邏輯過程結構圖

下面按照不同的邏輯關系分別對各種不同的分支/并行邏輯形態(tài)進行描述。

D.1 單路分支(異或)

事件與規(guī)則群的掛接與前邊相同，不再復述(以下僅敘述規(guī)則定義)，規(guī)則定義為：

Rule:Act1.finished→Act21.start()⊕ …⊕Act2n.start()

D.2 與分支(n路并行)

規(guī)則定義為：

Rule:Act1.finished→Act21.start()∧…∧Act2n.start()

D.3 或分支(1—n路并行)

規(guī)則定義為：

Rule:Act1.finished→Act21.start()∨…∨Act2n.start()

D.4m路選擇分支(m路并行)

從m個分支中選擇n路執(zhí)行，規(guī)則定義為:

Rule:Act1.finished→

count(Act21.start()∨…∨Act2n.start())=m

D.5 混合分支

分支中不止一種邏輯，而是多種邏輯的組合，例如，將活動21～活動2n分成兩組，活動21～活動24為一組，活動25～活動2n為另一組，兩組之間為異或關系，組內為與并行方式,規(guī)則定義為:

Rule:Act1.finished→(Act21.start()∧…∧Act24.start())⊕(Act25.start()∧…∧Act2m.start())

可以看出，使用邏輯規(guī)則的方式能夠靈活一致地靈活表示各種形態(tài)的分支/并行邏輯。與此相反，在以往的工作流模式方法中，通常無法直接表達混合分支的情形，往往需要借助于程序代碼才能進行此類描述，這無疑增加了過程建模和過程重構的復雜度。

7.5 匯合邏輯建模

匯合是與分支相對應的一類過程邏輯形態(tài)，分支邏輯與匯合邏輯一起構成了完整的分支/并行路徑。匯合邏輯的過程結構圖如圖11所示。

Figure 11 Structure diagram of the process for merge logic圖11 匯合邏輯過程結構圖

從邏輯運算的角度來看，匯合邏輯與分支邏輯具有類似的形式，下面按照不同的邏輯關系分別對各種不同的匯合邏輯形態(tài)進行描述。

E.1 單路匯合(異或)

此時，規(guī)則群RG可由活動11～活動1n中任何一個的提交事件觸發(fā)，事件與規(guī)則群掛接的定義形式為:

Act11.eActcommit→RG

…

Act1n.eActcommit→RG

規(guī)則定義為:

Rule:Act11.finished⊕…⊕Act1n.finished→Act2.start()

E.2 與匯合(n路匯合)

事件與規(guī)則群的掛接與E.1相同，不再復述(以下僅敘述規(guī)則定義)，規(guī)則定義為:

Rule:Act11.finished∧…∧Act1n.finished→Act2.start()

E.3 或匯合(1-n路匯合)

規(guī)則定義為:

Rule:Act11.finished∨…∨Act1n.finished→Act2.start()

E.4m路選擇匯合(m路匯合)

規(guī)則定義為:

Rule:count(Act11.finished, …,Act1n.finished)=m

→Act2.start()

E.5 混合匯合

匯合中不止一種邏輯，而是多種邏輯的組合，例如，將活動11～活動1n分成兩組，活動11～活動14為一組，活動15～活動1n為另一組，兩組之間為異或關系，組內為與匯合方式,規(guī)則定義為:

Rule:(Act11.finished∧…∧Act14.finished)⊕(Act15.finished∧…∧Act1n.finished)→Act2.start()

與分支類似，以往工作流模式的方法通常無法直接表達混合匯合的情形，往往需要借助于程序代碼才能進行此類描述，而本文的邏輯方法卻可以對此靈活地加以定義。

值得指出的是，以上的匯合邏輯規(guī)定活動2僅執(zhí)行一次，當活動2執(zhí)行之后，規(guī)則群RG將不被觸發(fā)，即新的活動1x的完成不會再引起RG中規(guī)則的匹配。假使活動2需要多次執(zhí)行，則需要對本文現(xiàn)有的規(guī)則文法進行修改，增加新的語法元素用于描述活動2多次執(zhí)行的有關內容。

7.6 匯合-分支組合邏輯建模

ESR元模型將規(guī)則置于與活動平行的地位，除了概念上更加合理之外，另一個積極的效果就是無須引入匯聚活動(見圖5)，即可直接表示匯合-分支組合邏輯。匯合-分支組合邏輯的過程結構圖如圖12所示。

Figure 12 Structure diagram of the process for the composition of merge and split logic圖12 匯合-分支組合邏輯過程結構圖

假定以上過程邏輯中匯聚為與的方式，而分支為異或方式，則事件與規(guī)則群掛接的定義形式為:

Act11.eActcommit→RG

…

Act1n.eActcommit→RG

規(guī)則定義為:

Rule:Act11.finished∧…∧Act1n.finished→

Act21.start()⊕ …⊕Act2m.start()

并且與D.5和E.5中所述類似，匯合-分支組合邏輯中的匯合與分支也可以是混合邏輯的形式。顯然，在目前的工作流管理系統(tǒng)中，完全無法象本文這樣直接表示此類過程邏輯形態(tài)。

7.7 循環(huán)邏輯建模

一般來說，工作流中的循環(huán)比起結構化程序設計中的循環(huán)會復雜得多，這源于以下兩個原因：

(1)工作流中不建議強制采用“單入單出”的循環(huán)結構，以避免給用戶帶來太多的約束。

(2)工作流的活動不能簡單抽象為程序中的語句，因為活動有時并非能夠看做整體的執(zhí)行單元。

考慮到工作流中循環(huán)的隨意性，本文對工作流的循環(huán)采用了類似于“Goto語句”的方式進行表示，將循環(huán)看做分支邏輯與匯合邏輯相結合的一種特例。

圖13是一個帶有循環(huán)的過程結構圖，活動3執(zhí)行完后會根據(jù)不同的情況轉移到不同的活動，其中，轉移到活動1和活動2將構成循環(huán)。為簡練起見，以下僅敘述和循環(huán)有關的內容。

圖13中，RG31、RG32和RG33為規(guī)則群，它們均由活動3的提交事件觸發(fā)，事件與規(guī)則群掛接的定義形式為：

Act3.eActcommit→RG31

Act3.eActcommit→RG32

Act3.eActcommit→RG33

Figure 13 Structure diagram of the process with the cycle圖13 帶有循環(huán)的過程結構圖

與前面的分支不同，這里的分支通常與業(yè)務狀態(tài)相關，即活動3完成后走哪一路分支取決于活動3的當前業(yè)務狀態(tài)值，因此需要定義一個用于表示循環(huán)的業(yè)務狀態(tài)，記為Act3.itr，并且需要定義該狀態(tài)與業(yè)務元素之間的映射關系ff：

ff(Act3.業(yè)務元素*)→Act3.itr

RG31中的規(guī)則為:

Rule:Act3.finished∧Act3.itr=1→Act1.start()

RG32中的規(guī)則為:

Rule:Act3.finished∧Act3.itr=2→Act2.func()

RG33中的規(guī)則為:

Rule:Act3.finished∧Act3.itr=3→Act4.start()

由以上定義可知，雖然Act3.eActcommit事件會同時觸發(fā)三個規(guī)則群，但是業(yè)務狀態(tài)Act3.itr使得僅有一個分支得以執(zhí)行。RG32中的規(guī)則表示，循環(huán)時活動2并非簡單地被啟動，而是執(zhí)行該活動中一個特定的方法func()，這體現(xiàn)了ESR模型具有將業(yè)務方法融合進規(guī)則表示的能力。

循環(huán)邏輯的挑戰(zhàn)更多地來自于活動的實例化，一個活動在循環(huán)中會反復被實例化，而活動的并行使得實例化在先的活動未必先完成，這就有必要采取一定的手段對并行的活動加以區(qū)分。在本文的表示方法中，活動的執(zhí)行源于規(guī)則的匹配，因此，規(guī)則群可以作為活動“分組”的依據(jù)。例如，一個活動2的實例，可以由它是源于RG31還是源于RG32的規(guī)則執(zhí)行來加以分別；而同一規(guī)則群引發(fā)的多活動實例的執(zhí)行則可以由時標加以區(qū)分，由此實現(xiàn)對循環(huán)實例化的“分組”鑒別。

7.8 電腦維修業(yè)務的過程建模

現(xiàn)以第3節(jié)中的電腦維修業(yè)務為例，進一步介紹過程-業(yè)務動態(tài)關聯(lián)情況下的過程建模方法，其過程結構圖如圖14所示。在ESR元模型中，過程和活動均可擁有事件和狀態(tài)，所以事件和狀態(tài)的定義分別在過程和活動兩個層次上進行。圖14中顯示了在活動內部可定義活動級的事件和狀態(tài)。

Figure 14 Structure diagram of the process of computer maintainance圖14 電腦維修業(yè)務的過程結構圖

(1)事件定義、狀態(tài)定義與狀態(tài)映射定義。

對于電腦維修業(yè)務，可以直接使用系統(tǒng)預定義的活動提交事件，而僅需要將這一事件掛接到相應的規(guī)則群即可。

“維修申請”活動的設定為：

Actapply.eActcommit→RGapply-check(RGapply-check為規(guī)則群)

“申請審核”活動的設定為：

Actcheck.eActcommit→RGcheck-service(RGcheck-service為規(guī)則群)

電腦維修業(yè)務需要定義的狀態(tài)有商品出售時間Actapply.sDuration和商品類型Actapply.sType。

Actapply.sDuration的映射定義為:

presentdate()-saledate→Actcheck.sDuration

其中，presentdate()為系統(tǒng)函數(shù)，獲取當前日期，saledate為“維修申請”活動中的業(yè)務數(shù)據(jù)—商品出售日期，Actcheck.sDuration表示的是商品出售時間。

Actapply.sType的映射定義為:

componenttype→Actcheck.sType

其中，componenttype為維修申請活動中的業(yè)務數(shù)據(jù)—商品類型。

(2)規(guī)則與規(guī)則群定義。

圖14中有兩個規(guī)則群：RGapply-check(申請活動和審核活動間的規(guī)則群)和RGcheck-service(審核活動和維修活動間的規(guī)則群)。

RGapply-check中包含一條規(guī)則：

Rule:Actapply.finished→Actcheck.start()

RGcheck-service中包含四條規(guī)則：

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僅針對業(yè)務狀態(tài)，而不涉及系統(tǒng)狀態(tài)，例如，Actcheck.finished即不屬于others判定的內容)。

以上的介紹顯然無法涉及基于ESR元模型的過程建模的所有方面。限于篇幅，本文不再對ERS模型框架下的建模方法進行更多的敘述。由上述介紹可知，ESR模型框架對過程的抽象元素和業(yè)務元素采用了一致性的表示方法，實現(xiàn)了“剛性過程”和“柔性過程”的統(tǒng)一建模。過程-業(yè)務的動態(tài)關聯(lián)成為業(yè)務過程模型的內在因素，過程定義成為表達過程邏輯的唯一方式。統(tǒng)一建模的方法，不僅可以簡化工作流系統(tǒng)的系統(tǒng)結構，而且能夠最大限度地避免過程重構時對程序代碼的修改，為過程的簡便重構提供了強有力的支持手段。

8 簡便重構實例

8.1 重構實例1

首先來看第5節(jié)中的重構問題，在電腦維修業(yè)務過程中增加了新的活動(改為兩個審核活動)，并且與過程相關的業(yè)務數(shù)據(jù)的數(shù)值發(fā)生了變化(免費更換的時間延長為三個月)。

重構方法：修改過程結構圖，修改規(guī)則。

新的過程結構圖如圖15所示。

Figure 15 Structure diagram of the process of computer maintainance with new activities圖15 添加新活動的電腦維修業(yè)務過程結構圖

然后，修改事件與規(guī)則群掛接的定義以及相關的規(guī)則定義。新的事件掛接定義為:

Actcheck1.eActcommit→RGcheck-service

Actcheck2.eActcommit→RGcheck-service

RGapply-check規(guī)則群中的規(guī)則改為:

Rule:Actapply.finished→

Actcheck1.start()∧Actcheck2.start()

RGcheck-service規(guī)則群中的規(guī)則改為:

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節(jié)中基于WFMC元模型的傳統(tǒng)工作流系統(tǒng)及柔性工作流系統(tǒng)相比，基于ESR元模型的重構工作得到了大幅度的簡化:

(1)僅僅需要修改過程定義，而無須修改任何程序代碼即可完成過程重構。

(2)無須添加“匯聚”活動處理并行分支的匯合，匯合邏輯直接包含在了規(guī)則中。

(3)純過程邏輯和過程-業(yè)務動態(tài)關聯(lián)的過程邏輯采用統(tǒng)一的形式集中放置在一起，便于用戶對重構內容的定位。

(4)無須業(yè)務過程系統(tǒng)的開發(fā)人員協(xié)助，用戶自己可以獨立承擔重構任務。

8.2 重構實例2

假定在電腦維修業(yè)務過程中，商品信息原先含有商品金額(amount)一項，現(xiàn)在維修條例中增加與商品金額相關的內容，規(guī)定若外設金額超過3 000元，與主機維修條件相同，不足3 000元的按原條例執(zhí)行。這種情況可以概括為“業(yè)務處理中的數(shù)據(jù)沒有變化，但業(yè)務規(guī)則中涉及到的業(yè)務數(shù)據(jù)類型發(fā)生變化”。

重構方法：設置新的狀態(tài)和狀態(tài)映射，修改規(guī)則。

新狀態(tài)：在“維修申請”活動中建立一個新狀態(tài)Actapply.sAmount。

新的狀態(tài)映射：amount→Actapply.sAmount

RGcheck-service規(guī)則群中的規(guī)則改為:

(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元模型的傳統(tǒng)工作流系統(tǒng)及柔性工作流系統(tǒng)實施這項重構任務時，需要修改“審核”活動中的程序代碼，并重新編譯系統(tǒng)。

8.3 重構實例3

假定在電腦維修業(yè)務過程中，原先不含有“客戶類別”信息，現(xiàn)在新增這一數(shù)據(jù)，并在維修條例中設定VIP客戶享有一年免費更換，五年免費維修的服務，而非VIP客戶按照原條例執(zhí)行。這種情況可以概括為“增加了新的業(yè)務元素，且該業(yè)務元素與過程邏輯相關”。

由于增加了新的業(yè)務元素，所以不可避免地要對業(yè)務處理程序加以修改。

重構方法：在業(yè)務處理程序中增加新的數(shù)據(jù)項customer，并在過程定義中建立對應的狀態(tài)和狀態(tài)映射，然后修改規(guī)則。

新狀態(tài)：在“維修申請”活動中建立一個新狀態(tài)Actapply.sCustomer。

新的狀態(tài)映射：customer→Actapply.sCustomer

RGcheck-service規(guī)則群中的規(guī)則改為：

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元模型的傳統(tǒng)工作流系統(tǒng)及柔性工作流系統(tǒng)實施這項重構任務時的工作如下:

(1)修改“維修申請”活動的業(yè)務處理程序代碼，增加“客戶類別”數(shù)據(jù)項customer。

(2)修改“審核”活動有關過程邏輯的程序代碼。

(3)重新編譯“維修申請”活動和“審核”活動。

其中，第(1)項工作與基于ESR元模型的系統(tǒng)相同；雖然在本例中，基于ESR元模型的系統(tǒng)也需要修改程序代碼，但是其重構工作主要以過程定義的方式進行，代碼修改量遠遠少于基于WFMC原模型的系統(tǒng)，并且僅需要重新編譯“維修申請”一個活動。

表1對上述過程重構實例進行了總結，對比了不同的工作流系統(tǒng)在若干典型情況下實施過程重構的方式。從表1中可以看出，基于ESR元模型的系統(tǒng)僅僅當業(yè)務處理程序中的數(shù)據(jù)類型發(fā)生變化，且該變化與過程邏輯相關時才需要修改程序代碼；其它情況下，均可通過修改過程定義的方式實施過程重構；反之，基于WFMC的傳統(tǒng)工作流系統(tǒng)和柔性工作流系統(tǒng)卻在絕大部分情況下需要修改程序代碼，并重新編譯系統(tǒng)。

9 結束語

Table 1 Comparison of different methods of process reconfiguration

ESR元模型定義了新的模型元素和模型結構，同時建立了一種基于事件-規(guī)則機制的工作流模型框架。這種模型框架可以對純過程邏輯和過程-業(yè)務動態(tài)關聯(lián)的過程邏輯用統(tǒng)一的過程定義方法進行表示，然后由模型解釋器對過程定義解釋執(zhí)行，改變了以往普遍存在的“剛性過程”和“柔性過程”分離建模的狀況，簡化了業(yè)務過程系統(tǒng)的建模和運行機制。ESR模型框架更好地實現(xiàn)了過程邏輯與業(yè)務邏輯的分離，當過程邏輯發(fā)生變化時，建立在該模型框架下的業(yè)務過程系統(tǒng)能夠通過對過程定義的修改來適應系統(tǒng)變更的需求；并且根據(jù)重構任務的不同，過程的重構可以有針對性地在不同的模型層次上實施，從而達到過程簡便重構的目的。

過程邏輯表示方法是業(yè)務過程建模的核心問題，本文概要地敘述了用于表示過程邏輯的規(guī)則的文法形式。但是，過程邏輯的形態(tài)種類繁多，如何用規(guī)則的方法對各類形態(tài)的過程邏輯進行抽象描述有待進一步深入研究。

[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] 譚偉,范玉順. 業(yè)務過程管理框架與關鍵技術研究[J]. 計算機集成制造系統(tǒng), 2004,10(7):2-6.

[3] 李競杰, 王維平, 楊峰. 柔性工作流理論方法綜述[J]. 計算機集成制造系統(tǒng), 2010,16(8):1569-1577.

[7] 孫瑞志, 史美林. 一個支持動態(tài)變化的工作流元模型[J]. 電子學報, 2002,30(12):2052-2056.

[11] 譚宜勇, 王銳, 范玉順,等. 分布式工作流中的自適應實時任務調度方法[J]. 計算機集成制造系統(tǒng), 2010,16(9):1887-1895.

[12] 胡錦敏, 張申生, 余新穎. 基于ECA 規(guī)則和活動分解的工作流模型[J]. 軟件學報, 2002,13(4):761-767.