【正文】 義好的工作流邏輯推進(jìn)工作流實(shí)例的執(zhí)行[5,6]。(2)系統(tǒng)運(yùn)行時(shí)間的控制功能 在其運(yùn)行環(huán)境中管理工作流過程，并連續(xù)地處理組成一個(gè)過程的各活動(dòng)。 現(xiàn)有的工作流建模方法及存在問題模型是用文字、圖形、圖表、符號(hào)關(guān)系式以及實(shí)體模樣等描述所認(rèn)識(shí)到的客觀對(duì)象的一種簡(jiǎn)化表示形式。工作流模型是對(duì)工作流的抽象表示，也就是對(duì)業(yè)務(wù)過程的抽象表示。由于需要在計(jì)算機(jī)環(huán)境下運(yùn)行，所以，工作流模型既要讓人讀懂，也要讓計(jì)算機(jī)能夠讀懂并能解釋所定義的業(yè)務(wù)過程?，F(xiàn)今的工作流建模方法主要有基于活動(dòng)網(wǎng)絡(luò)、Petri網(wǎng)、語言行為理論、活動(dòng)與狀態(tài)圖以及擴(kuò)展事務(wù)模型的建模方法。基于XML的典型業(yè)務(wù)過程定義語言是BPMI維護(hù)的BPML，其他類似的語言還包括：BPQL、WSFL、XLANG、BPEL、WSCDL、XPDL等。這種方法的優(yōu)點(diǎn)是直觀并且易于理解，因此目前很多工作流管理系統(tǒng)都采用這種方法建立工作流模型。Petri網(wǎng)是完全形式化的，可以對(duì)模型進(jìn)行準(zhǔn)確的判斷和分析，非常易于計(jì)算機(jī)理解和自動(dòng)實(shí)現(xiàn)。但基于Pertri網(wǎng)的工作流模型有著模型不直觀的缺點(diǎn)，導(dǎo)致了其不易被非專業(yè)人員理解和溝通[12~15]。這種方法的優(yōu)點(diǎn)是易學(xué)習(xí)和易理解，并且比圖形化模型容易驗(yàn)證和實(shí)現(xiàn)?；谑聞?wù)模型的建模方法來源于數(shù)據(jù)庫研究領(lǐng)域，事務(wù)處理對(duì)于維護(hù)數(shù)據(jù)庫的正確性、一致性和出錯(cuò)恢復(fù)都具有重要意義[17~19]，在工作流模型中引入事務(wù)概念可以提高工作流管理系統(tǒng)的可靠性。 工作流引擎綜述及其不足工作流引擎是一個(gè)為工作流實(shí)例的執(zhí)行提供運(yùn)行服務(wù)環(huán)境的軟件，它是工作流執(zhí)行服務(wù)的核心，是執(zhí)行企業(yè)經(jīng)營流程的“業(yè)務(wù)操作系統(tǒng)”的內(nèi)核。目前工作流引擎產(chǎn)品數(shù)量相當(dāng)多，其中有軟件制造商所提供的商業(yè)產(chǎn)品，也有一些由個(gè)人或自由組織所發(fā)起的開源項(xiàng)目。前者的商業(yè)產(chǎn)品代表有Action Technologies ActionWorks Metor、IBM Websphere MQ Workflow、SAP Business Workflow等著名軟件。后者現(xiàn)在主要包括了一些使用BPEL的產(chǎn)品。嵌入式工作流引擎不能單獨(dú)運(yùn)行，只能嵌入到系統(tǒng)內(nèi)部作為系統(tǒng)的一個(gè)組件運(yùn)行。嵌入式工作流引擎的一個(gè)代表是開源工作流引擎OSWorkflow，它可看作是一個(gè)嵌入在系統(tǒng)內(nèi)部的有限狀態(tài)機(jī)，簡(jiǎn)單靈活。按代碼是否開源分類，可將工作流引擎分為開源工作流引擎與商業(yè)工作流引擎。后者的主要代表有國內(nèi)的西安協(xié)同、中唐、有生博大、東方易維等。(1)沒有通用的工作流引擎 現(xiàn)今的工作流引擎產(chǎn)品大多數(shù)都限定在一個(gè)具體的領(lǐng)域，沒有一個(gè)適合所有領(lǐng)域的產(chǎn)品。(3)內(nèi)部執(zhí)行機(jī)制各不相同 由于工作流引擎輸入的模型不盡相同，也導(dǎo)致了各種工作流引擎的內(nèi)部執(zhí)行機(jī)制各不一樣，有的采用Petri網(wǎng)的令牌機(jī)制，有的則采用了有限狀態(tài)機(jī)的執(zhí)行方法。當(dāng)工作流引擎作為嵌入式工作時(shí)，使得工作流引擎與所嵌入的系統(tǒng)是緊耦合的。 MDA的發(fā)展OMG在2002年初宣告了模型驅(qū)動(dòng)構(gòu)架(Model Driven Architecture, MDA)為它的戰(zhàn)略方向。在基于MDA的開發(fā)過程中，開發(fā)人員把注意力轉(zhuǎn)移到開發(fā)模型上，將更多的精力用到功能性需求的分析和設(shè)計(jì)，而不是過早的陷入具體的實(shí)現(xiàn)細(xì)節(jié)當(dāng)中。MDA把建模語言當(dāng)作是編程語言來用，而不致使當(dāng)作設(shè)計(jì)語言來用。MDA以一種全新的方式將IT技術(shù)的一系列新的趨勢(shì)性技術(shù)整合在一起，這些技術(shù)包括基于組件的軟件開發(fā)(ComponentBased Software Development, CBSD)、設(shè)計(jì)模式、中間件、說明性規(guī)約、多層系統(tǒng)、企業(yè)應(yīng)用集成以及契約式設(shè)計(jì)等等[25]。國內(nèi)外對(duì)于MDA的研究主要集中在兩方面。另外一方面是開發(fā)各種MDA的通用工具，它可以通過配置第三方的插件或者擴(kuò)展來支持MDA的實(shí)現(xiàn)，針對(duì)廣闊的應(yīng)用領(lǐng)域?qū)崿F(xiàn)MDA的解決方案。有的模型是直觀的、容易被人理解的，例如活動(dòng)圖等；而有的模型是形式化的，很容易被計(jì)算機(jī)所理解，Petri網(wǎng)是一個(gè)典型的代表。針對(duì)上述缺點(diǎn)分析，可采用MDA的開發(fā)方法處理，平臺(tái)無關(guān)模型(Platform Independent Model, PIM)層的工作流模型追求模型的直觀性，采用圖形化表述，平臺(tái)相關(guān)模型(Platform Specific Model, PSM)層的工作流模型面向平臺(tái)，采用XML文件形式描述，最后在代碼(code)層實(shí)現(xiàn)一個(gè)工作流引擎解釋執(zhí)行模型。這樣大大減少了程序員在進(jìn)行業(yè)務(wù)邏輯編程時(shí)的工作量。 本碩士論文的研究?jī)?nèi)容本論文的主要工作是采用ICEMDA的方法對(duì)工作流建模，并設(shè)計(jì)實(shí)現(xiàn)一個(gè)工作流引擎對(duì)其提供執(zhí)行服務(wù)，主要的工作如下所述：(1)ICEMDA的工作流建模 在ICEMDA的環(huán)境下，建立ICEPIM層工作流模型，它采用了UML+的圖形對(duì)企業(yè)的業(yè)務(wù)流程建立模型；而后通過擴(kuò)展XPDL定義了PSM層可執(zhí)行工作流模型；最后在兩層工作流模型的基礎(chǔ)上，定義了一系列的自動(dòng)映射規(guī)則實(shí)現(xiàn)轉(zhuǎn)換。重點(diǎn)研究了工作流引擎中的路由算法和條件判斷策略。(3)設(shè)計(jì)實(shí)現(xiàn)支持ICEMDA的工作流引擎 首先總體設(shè)計(jì)了工作流引擎的體系結(jié)構(gòu)，對(duì)工作流引擎進(jìn)行了模塊劃分，方便以后的擴(kuò)展和改進(jìn)。接口定義主要包括角色/用戶數(shù)據(jù)映射、工作流相關(guān)數(shù)據(jù)以及任務(wù)列表。接著分析比較了此工作流引擎和開源工作流引擎Shark。圖11是本文的研究思路和問題鏈。它是在MDA方法的基礎(chǔ)上，提出了一系列模型、視圖和方法對(duì)企業(yè)應(yīng)用軟件進(jìn)行描述，以便達(dá)到快速、準(zhǔn)確、高效地開發(fā)應(yīng)用系統(tǒng)的方法。圖21 基于ICEMDA的工作流系統(tǒng)Figure 21 The workflow system based on ICEMDAICEMDA分為四層架構(gòu)ICECIM(Computing Independent Model)、ICEPIM(Platform Independent Model)、ICEPSM(Platform Specific Model)和ICECode層四層架構(gòu)。每一個(gè)模型描述了由企業(yè)業(yè)務(wù)到企業(yè)軟件應(yīng)用這一過程抽象中某一個(gè)階段的成果，每一個(gè)視圖描述了某一特定模型的某個(gè)側(cè)面。其中BO[27]是融數(shù)據(jù)和方法于一體的，具有一定生命周期的對(duì)象。ICEPSM是平臺(tái)相關(guān)模型。該構(gòu)件被稱為業(yè)務(wù)構(gòu)件(Business Component, BC)[28]，其模型被稱為BC 模型。ICEMDA的Code層是在平臺(tái)基礎(chǔ)上的，基于框架和工作流引擎的可配置的構(gòu)件化系統(tǒng)。訂單、報(bào)表、設(shè)備、員工等都可以稱為業(yè)務(wù)對(duì)象。業(yè)務(wù)活動(dòng)是一個(gè)角色處理表單全部或者部分?jǐn)?shù)據(jù)項(xiàng)的一系列業(yè)務(wù)操作的集合。 模型需求業(yè)務(wù)對(duì)象的概念來源于企業(yè)日常業(yè)務(wù)處理的單據(jù)和報(bào)表，對(duì)單據(jù)和報(bào)表的處理過程使業(yè)務(wù)對(duì)象的狀態(tài)不斷發(fā)生變化。(1)確定業(yè)務(wù)活動(dòng)的時(shí)序關(guān)系 業(yè)務(wù)對(duì)象所包含的業(yè)務(wù)活動(dòng)之間的時(shí)序關(guān)系不一定都是順序的，所以工作流模型需要描述業(yè)務(wù)對(duì)象內(nèi)部以及業(yè)務(wù)對(duì)象之間各業(yè)務(wù)活動(dòng)間的時(shí)序關(guān)系。因此，這些約束條件也該在圖形化的工作流模型中表達(dá)出來。除以上三個(gè)方面，ICEPIM工作流模型還應(yīng)該能夠向下轉(zhuǎn)換成ICEPSM工作流執(zhí)行模型。如圖22所示，圖中詳細(xì)描述了PIM層工作流模型包含的元素以及元素之間的關(guān)系。同樣，不同業(yè)務(wù)活動(dòng)之間的關(guān)系都可以用工作流的基本組成元素——控制流來統(tǒng)一地進(jìn)行描述。下面分別介紹PIM工作流元模型中的各個(gè)元素。業(yè)務(wù)活動(dòng)一般表示某崗位對(duì)一個(gè)表單、文檔或者報(bào)表中的部分或者全部的數(shù)據(jù)項(xiàng)進(jìn)行的一次處理。(2)事件 業(yè)務(wù)活動(dòng)執(zhí)行完畢后，由執(zhí)行人發(fā)出事件，用于觸發(fā)下一個(gè)活動(dòng)，充當(dāng)了業(yè)務(wù)活動(dòng)的觸發(fā)器。根據(jù)事件源可將事件分為兩類：時(shí)間事件和人工事件。從形式上，連接了活動(dòng)與活動(dòng)、活動(dòng)與連接器、決策節(jié)點(diǎn)和連接器、決策節(jié)點(diǎn)和業(yè)務(wù)活動(dòng)等之間的關(guān)系，最終使整個(gè)工作量模型形成一個(gè)有向圖事件和功能或業(yè)務(wù)過程之間的執(zhí)行順序關(guān)系。常見的邏輯連接符包括：異或XOR、與AND、或OR。在順序模式下，活動(dòng)只產(chǎn)生一個(gè)事件，一個(gè)事件只觸發(fā)一個(gè)活動(dòng)。OR表示多選多控制模式，在多選多模式下，可能有多個(gè)滿足條件的控制流分支被選中執(zhí)行。(5)角色 角色是對(duì)能夠區(qū)分不同責(zé)任的一類用戶的抽象描述，在軟件系統(tǒng)中，角色往往體現(xiàn)的是權(quán)限。在PIM層工作流模型中，對(duì)角色的復(fù)雜信息并不定義，因?yàn)檫@些信息會(huì)在角色模型中描述。(6)條件表達(dá)式 條件表達(dá)式根據(jù)應(yīng)用的位置可分為三類：轉(zhuǎn)移條件、前置條件和后置條件。前置條件是業(yè)務(wù)活動(dòng)執(zhí)行前需要滿足的條件。(7)業(yè)務(wù)活動(dòng)輸入輸出數(shù)據(jù) 每個(gè)業(yè)務(wù)活動(dòng)都包含一個(gè)輸入數(shù)據(jù)或者輸出數(shù)據(jù)，例如采購訂單需要根據(jù)采購需求或者采購計(jì)劃制定，輸出結(jié)果是采購訂單。為了便于PIM層各個(gè)模型間的互操作，ICEPIM層模型用UML+圖表示。圖23 ICEPIM工作流元模型元素圖形化Figure 23 The graph of the ICEPIM workflow metamodel 示例采購需求單有制定和審批兩個(gè)活動(dòng)，但根據(jù)審批金額的不同，所需要的審批人員也不同，圖24描述了采購需求單的內(nèi)部業(yè)務(wù)流程。圖24 采購需求單的制定審批流程Figure 24 Making and auditing process of the purchase requirement order ICEPIM工作流元模型的形式化定義PIM層工作流模型以業(yè)務(wù)活動(dòng)為中心，通過控制流和連接器描述業(yè)務(wù)活動(dòng)時(shí)序關(guān)系，從而表示一個(gè)業(yè)務(wù)流程。PIM層工作流模型可由一個(gè)二十三元組描述。(2)每一個(gè)業(yè)務(wù)活動(dòng)BusinessActivity是一個(gè)五元組：其中，ID是業(yè)務(wù)活動(dòng)的唯一標(biāo)識(shí)；Name是業(yè)務(wù)活動(dòng)的名稱；Description是業(yè)務(wù)活動(dòng)的描述性文字；PreExecCtrl是業(yè)務(wù)活動(dòng)的執(zhí)行前控制模式，描述了活動(dòng)的執(zhí)行是需要人工干預(yù)還是自動(dòng)啟動(dòng)；PreExecCtrl是業(yè)務(wù)活動(dòng)的執(zhí)行前控制模式；Deadline是業(yè)務(wù)活動(dòng)的期限，描述業(yè)務(wù)活動(dòng)被執(zhí)行的最大次數(shù)或者最后時(shí)間。(4)Flows是PIM層工作流模型的控制流集合。(6)Decisions是PIM層工作流模型的決策集合。其中，n表示Decision包含的條件表達(dá)式的個(gè)數(shù)；DeciCond是一個(gè)函數(shù)：(8)Conditions是PIM層工作流模型的約束條件集合。而每一個(gè)連接器只有取值：XOR、OR、AND。(11)Finish是PIM層工作流模型的結(jié)束節(jié)點(diǎn)。(13)ActBOID是一個(gè)為業(yè)務(wù)活動(dòng)指定其所對(duì)應(yīng)的業(yè)務(wù)對(duì)象ID的函數(shù)：上式中是一個(gè)部分函數(shù)，表明了業(yè)務(wù)活動(dòng)也可不與任何業(yè)務(wù)對(duì)象相關(guān)聯(lián)，此為可選項(xiàng)。(15)ActPreCond也是一個(gè)函數(shù)，為業(yè)務(wù)活動(dòng)指定前置條件，類似的，前置條件是業(yè)務(wù)活動(dòng)的可選項(xiàng)，因此也是一個(gè)部分函數(shù)：(16)ActPostCond與ActPreCond類似，是一個(gè)為業(yè)務(wù)活動(dòng)指定后置條件的函數(shù)，類似的，后置條件也是業(yè)務(wù)活動(dòng)的可選項(xiàng)，因此也是一個(gè)部分函數(shù)：(17)EventType描述event類型的函數(shù)：(18)FlowType是將每一個(gè)控制流Flow指定類型的函數(shù)，控制流有三種類型：附加事件型、附加條件型以及無任何附加型。因此，SourceFlow和TargetFlow兩個(gè)函數(shù)如下所示：(20)FlowEvent為一個(gè)函數(shù)，它為附加事件型的控制流指定附加的事件，只有在產(chǎn)生相應(yīng)的事件后，控制流才能被經(jīng)過執(zhí)行：(21)FlowResult為變遷附加決策結(jié)果的函數(shù)，從而可以根據(jù)決策中心的結(jié)果判斷出可執(zhí)行的分支：(22)FlowCond也為一個(gè)函數(shù)，它為附加條件型的控制流指定附加的條件，只有在滿足指定的條件后，控制流才能被經(jīng)過執(zhí)行：(23)DeciCond是一個(gè)函數(shù)，它為每一個(gè)決策中心指定其所包含的條件表達(dá)式。(25)FinishAct是一個(gè)將活動(dòng)或者連接器映射到結(jié)束節(jié)點(diǎn)的函數(shù)，描述了模型的結(jié)束業(yè)務(wù)活動(dòng)。(2)只有連接器可以擁有多個(gè)進(jìn)入控制流，而業(yè)務(wù)活動(dòng)和決策點(diǎn)只能有一個(gè)進(jìn)入控制流；開始節(jié)點(diǎn)和其他元素都沒有進(jìn)入控制流。 ICEPSM層可執(zhí)行工作流模型ICEPSM層可執(zhí)行工作流模型是以業(yè)務(wù)構(gòu)件（Business Component, 簡(jiǎn)稱BC）的業(yè)務(wù)活動(dòng)為中心的，描述了一個(gè)業(yè)務(wù)構(gòu)件間的業(yè)務(wù)活動(dòng)的流轉(zhuǎn)次序以及業(yè)務(wù)構(gòu)件之間的時(shí)序執(zhí)行關(guān)系。而XPDL作為一種工作流過程定義之間的公共交互格式，它的通用性和可轉(zhuǎn)換性符合現(xiàn)代軟件開發(fā)的形式，為工作流過程定義互相轉(zhuǎn)換提供了規(guī)范。通過以上分析，ICEPSM層可執(zhí)行工作流模型采用XML語言描述，并且采用的XML語言遵循XPDL規(guī)范，對(duì)于XPDL不能描述的信息，通過擴(kuò)展屬性的方式描述，這樣通過擴(kuò)展的XPDL形成了可執(zhí)行工作流模型。WfMC為工作流系統(tǒng)制定了5類功能接口，其中接口1(過程定義輸入/輸出接口)包含了一個(gè)用于描述工作流過程定義的公共元模型，以及過程定義間進(jìn)行相互轉(zhuǎn)換的XML Schema。XPDL不可能支持所有模型的附加屬性，依靠一系列有限的描述工作流過程定義的實(shí)體，XPDL可以支持一些不同的擴(kuò)展屬性處理方法。無論P(yáng)IM層的工作流模型采用什么圖形描述，只要PSM層可執(zhí)行工作流模型符合XPDL規(guī)范，那么就可以保持相同的表示形式。圖25是XPDL的元模型以及上層實(shí)體。 過程定義(WorkflowProcessDefinition)過程定義詳細(xì)說明了構(gòu)成工作流的元素，包括活動(dòng)、轉(zhuǎn)移、應(yīng)用程序和相關(guān)數(shù)據(jù)等實(shí)體的定義或者聲明。在表21中詳細(xì)描述了工作流過程定義的屬性以及包含的子元素，并對(duì)這些屬性和子元素作了語義描述。如果是PUBLIC：過程能被外部系統(tǒng)或者應(yīng)用程序調(diào)用；PRIVATE：過程只能被子流程調(diào)用子元素Activities組成過程的活動(dòng)列表ActivitySets活動(dòng)、變遷的自包含集合列表Applications工作流應(yīng)用程序聲明列表Data Fields工作流相關(guān)數(shù)據(jù)列表Extended Attributes可選的、開發(fā)者自定義的屬性，用來滿足特殊需求Formal Par