摘要:提出了基于BPMN規范的三維業務流程模型,并采用模型驅動的開發方法和基于Eclipse插件實現了原型系統OnceBPD;最后利用該系統展示了一個旅行登記流程模型的案例。
關鍵詞:業務流程建模; 模型驅動; 業務流程建模符號; Eclipse; 插件
中圖分類號:TP311文獻標志碼:A
文章編號:1001-3695(2008)04-1271-04
近年來,隨著企業信息化水平的不斷提高,業務流程管理(business process management,BPM)獲得了越來越多的應用。BPM是一種以規范化的業務流程為中心,以持續地提高組織業務效績為目的,以提升和改造企業信息系統為手段的系統化方法,能夠有效地輔助企業對業務流程建模、再造和管理,實現企業智能化業務管理。
業務流程建模是BPM的前期階段,為BPM提供了可視化的業務流程設計,輸出為可執行的業務流程語言。業務流程描述語言是BPM整個流程層的基礎和核心內容。目前有很多標準,包括BPEL(business process execution language)、BPML(business process modeling language)、XPDL(XML process definition language)等。其中:BPEL由于其對Web服務技術的良好支持,更是獲得多數廠商的青睞。但是由于BPEL規范中各元素的圖形表示沒有統一規范的定義,各個廠商的實現方式各不相同,再加上BPEL規范本身的復雜性,難以被業務人員理解和使用,從業務流程的設計、開發到管理監控都增加了復雜度,降低了工作效率。因此BPMI(business process modeling integration)組織提出了業務流程建模符號BPMN,統一定義了各種元素的圖形表示,便于業務人員的理解。另外,在軟件工具支持下BPMN還能夠轉換成可執行語言如BPEL,進而由流程引擎直接運行。這樣,提高了開發的抽象層次,不同的人員能夠工作在自己擅長的抽象層次緊密合作,提高了工作效率。
目前還沒有基于BPMN規范的開源業務流程建模工具,商業化的工具如Borland Together 2006、Soyatec eBPMN等都還是起步階段,功能比較有限。本文提出了基于BPMN規范的三維業務流程模型,能夠更好地支持業務流程建模。基于該模型,采用模型驅動的開發方法,設計實現了一個業務流程建模平臺OnceBPD。筆者的目標是,用戶通過這個圖形化的平臺,能夠快速開發一個業務流程以及綁定具體的業務活動、組織和數據。
1基本概念
1.1業務流程管理
BPM技術是從工作流技術發展而來的,其關鍵是將業務流程計算機模型化、標準化,使業務流程與業務應用相分離。BPM的技術實現被稱為業務流程管理系統(BPMS)。BPMS使企業能夠對核心流程進行建模、部署和管理。業務流程管理系統主要由以下幾部分組成:業務流程建模平臺、流程分析模塊和配置管理平臺。流程建模平臺將現有的實際的業務流程抽象成為圖形化和形式化的業務流程,再通過流程分析模塊中驗證(validation)和檢查(verification)來校驗業務流程是否合理和正確,隨后用性能分析工具對業務流程進行性能分析,用優化模塊對業務流程進行優化。在得出了正確合理優化后的業務流程后,使用配置管理平臺將業務流程模型集成到現有的產品中去,用信息系統的形式反映出來。可見,業務流程建模平臺在BPMS系統中是處于前端位置,直接與業務人員交互。輸出的業務流程模型,通常用業務流程描述語言表達,是BPMS后續階段的輸入。所以一個建模平臺的好壞對BPMS評價有很大的影響。
1.2BPM-N規范
在2006年2月,BPMN被OMG(object modeling group)組織接受為正式標準,加速了其在業務流程可視化建模方向的發展。BPMN定義了出現在業務流程中的各種元素的圖形表示和屬性。BPMN使用四類基本建模符號建模業務流程,即流動對象、連接對象、泳池/泳道和用戶自定義對象。其主要元素如圖1所示。
1.3模型驅動開發
模型驅動開發(model driven development, MDD)是更快地開發更好的軟件的一種方法和一組技術。在對業務邏輯進行抽象的基礎上,使用統一建模語言(UML)對業務邏輯建模,得到了一個或多個業務對象模型,同時抽象出一個平臺無關模型(platform-independent model,PIM);之后根據不同的開發平臺(如.NET或J2EE)和應用平臺(如Windows或UNIX)形成相應的平臺相關模型(platform-specific model, PSM);最后生成代碼,獲得實現的基礎。模型驅動的開發能夠保證縮短開發時間、減少軟件bug和增加軟件的可維護性。可以將一個開發項目中涉及的各種人都團結在一起,允許大家在各自擅長的抽象層次上進行工作。
對象管理組織(OMG)在 MDD 概念之上又提出了模型驅動的體系架構(MDA),并開發了一組標準來支持 MDD。MDA概念的核心是一系列重要的OMG 標準:統一建模語言(unified modeling language,UML)、元對象設施(meta object facility,MOF)、XML元數據交換(XML metadata interchange,XMI)和通用倉庫元模型(common warehouse metamodel,CWM)。這些標準定義了MDA 的下層基礎設施,并為當前的系統建模技術發展作出了巨大的貢獻。其中,MOF架構包含了模型的四個元層次。這四個層次被命名為M3、M2、M1和M0。
M3層:元元模型,即定義元模型的構造集合,如MOF類、MOF屬性、MOF關聯等。
M2層:元模型,由元元模型構造的實例組成,如UML類、UML屬性、UML狀態、UML活動等。
M1層:模型,由元模型構造的實例組成,如customer類、Account類等。
M0層:對象和數據,也即M1模型構造的實例,如客戶Jane Smith、客戶Joe Jones等對象。
本文采用的模型層次對應為:Eclipse EMF(eclipse mode-ling framework)提供了M3層模型,通過EMF建立M2層模型即業務流程元模型,用戶設計具體的流程模型即M1層。最后流程實例化并在BPMS中運行的就是M0層。
2設計與實現
2.1元模型建模
業務流程建模就是將現實世界中的業務過程抽象出來,并用一種形式化的、計算機可處理的方式來表示。這種形式化結構稱為業務流程模型。將業務流程模型分為三個子模型,即流程模型、組織模型和數據模型。
2.1.1流程元模型
本文將基于BPMN規范實現流程元模型。其類圖如圖2所示。
各元素描述如下:
a) Diagram(圖表)和process(流程)
圖表是最上層模型,包含了其他所有的元素,表示一個完整的業務流程圖。流程對象包含了一個業務流程的抽象描述,屬性包括名稱、狀態、流程元素和流程數據等。
b) Swimlanes(組織責任區)
通常是用來描述某一特定組織內所涉及到的企業流程,以及與相鄰組織的合作關系。有兩種類型的swimlanes,分別為pool和lane。
pool(泳池):可以看做一個特定的實體,如公司。它可以由一個或是多個lane來組成一個pool,而pool之間通過消息流來進行溝通。
lane(泳道):lane可看做pool的一部分,表示單一組織的流程描述,而兩個相鄰lane則是描述組織之間的合作關系。
c)Flow object(流動對象)
流動對象是流程的節點,包含event(事件)、activity(活動)及gateway(路由)。
Event(事件):在業務流程中,事件影響流程運轉,通常有產生的原因和后果,包括活動的開始、活動的結束、文檔的改變以及消息的到達等,被稱為驅動(trigger)。BPMN將事件分為三種,即開始事件、中間事件和結束事件,而每一種都有相應的事件驅動。
Activity(活動):活動是用來表示企業流程中的基本的單元元素。根據活動的復雜程度,又可以分為Task(任務)和子流程(sub-process)。
Gateway(路由):它由幾個邏輯判斷式來指示流動對象的流向。
d) Connection object(連接對象)
用來連接流動對象的對象。主要區分為三個部分,分別是sequence flow(序列流)、message flow(信息流)及association(結合關系)。
Sequence flow(序列流):用來表示流程中活動執行的順序。
Message flow(信息流):用來表示兩個pool之間的消息傳遞和接受關系。
Association(結合關系):用來描述兩個流動對象之間的連接關系。通常這兩個流動對象是不具有順序關系的,不影響流程運轉。
e) Artifacts(用戶自定義對象)
BPMN除了以上的設計元素供流程設計人員設計流程外,還提供了用戶自定義的對象,讓用戶可以作出更加豐富的設計。這部分對象主要分三類,分別是data object(數據對象)、group(群組)及annotation(注釋)。
Data object(數據對象):主要描述兩個活動之間的序列流所提供的信息,這可能包括信息的流入或流出。
Group(群組):通常被用來說明一組活動的集合,特別是用來對跨越兩個pool的活動集合的關系描述。
Annotation(注釋):用連接關系線附著在流動對象上,對其進行解釋說明。
2.1.2組織元模型
組織模型是對一個組織內人員、角色、資源等實體及其相互關系的描述。然而在BPMN規范中沒有定義一個完整的組織模型,因此筆者擴充定義了一個組織模型,如圖3所示。模型可以分為兩個部分:組織部門和組織職位是面向企業的組織模型;用戶、角色和權限是工作流系統內部所需的組織模型。
組織部門:是對組織內某個部門的抽象。包括部門名稱、描述、性質、聯系方式等屬性以及包含的子部門列表、上級部門和組織職位列表等元素。
組織職位:是在一個部門中根據分工形成的職位,一般職位變化較小,而人員變動較大。包括職位名稱、描述、性質等屬性以及包含職員(用戶)列表和角色列表等元素。
角色:是工作流管理系統中具有某種權限的標志。包括名稱、描述等屬性以及包含用戶列表和權限列表。
用戶:是隸屬于某個組織職位的員工,參與活動的執行。包括名稱、性別、地址等屬性以及包含角色列表和所屬職位等元素。
權限:是對工作流管理系統的操作能力的描述。包括權限ID和描述等等。
2.1.3數據元模型
數據模型是業務流程在執行過程對所訪問對象的描述。數據模型不像組織模型有明確的模型定義,而是有多種數據類型,如流程級的輸入/輸出數據、活動級的輸入/輸出數據等。所有的數據都要在流程模型中的相關數據中聲明,流程模型提供了一些基本的數據類型,如string、int等類型。對復雜的數據聲明本文采用XML schema文件來定義。
2.1.4子模型之間的相互關系
流程模型、數據模型和組織模型從三個方面定義了一個業務流程模型。流程模型是主體,其他兩個模型需要在流程模型中聲明。即通過組織責任區將組織模型綁定到流程模型中,通過XML名稱空間將數據模型綁定到流程模型中。
流程模型、數據模型和組織模型相分離有以下的優點:a) 提高了各模型的可重用性。同一個數據模型和組織模型可以在不同的流程模型中使用。b) 數據模型的建立,可以使系統和外部應用的數據交換接口更清晰。c) 組織模型的建立,可以使組織定義更靈活,適應不同公司的組織機構。
2.2OnceBPD系統的結構和功能
基于以上的元模型,通過模型驅動的方法開發了建模平臺的原型系統OnceBPD。系統劃分為四個模塊,模塊之間的關系如圖4所示。其中模型倉庫用來保存用戶定義的模型文件。
2.2.1工程管理模塊
工程管理模塊是整個建模工具的主要模塊,用于新建、刪除、上傳和部署一個流程。將整個界面分成四個部分,提供了三種視圖和一個編輯器,即資源樹視圖、屬性視圖、大綱視圖和流程模型編輯器。資源樹視圖將指定的工作區目錄下已持久化的流程以樹型結構顯示出來,并在這個結構上進行各種操作。屬性視圖顯示流程或活動的屬性。大綱視圖以樹型結構顯示一個流程包含的活動節點。流程模型編輯器由流程模型定義模塊負責。
2.2.2流程模型定義模塊
流程模型定義模塊是建模工具的核心模塊。該模塊提供了流程模型編輯器,包括流程設計視圖和流程元素調色板。用戶在調色板中選擇各種活動,拖拽到設計視圖,通過轉移鏈連接各個活動節點,最后設置各個活動節點的屬性和轉移鏈上的條件。
2.2.3組織模型定義模塊
提供了一個組織模型的模型編輯器。整個組織模型是以樹狀的方式顯示的,方便用戶編輯各個實體的屬性,并將所有的組織信息保存在數據庫中。最后通過流程模型的組織責任區將組織模型與流程模型關聯起來。
2.2.4數據模型定義模塊
提供了一個XML schema編輯器,幫助用戶方便地編輯數據模型。用戶不用輸入那些重復的標簽,只需輸入必要的數據類型和數據名稱等信息。XML schema能夠以不同顏色分類顯示,使得用戶有一個直觀的感受。最后通過流程模型的相關數據屬性聲明將數據模型和流程模型關聯。
2.3系統實現
系統采用Eclipse的插件開發技術實現。分別用到了Eclipse GMF(graphical modeling framework)、Eclipse EMF(eclipse modeling framework)和GEF(graphical editing framework)這三個開發框架。流程模型設計模塊整體采用MVC(model-view-control)的架構,通過繼承和實現框架類完成,利用框架定義了各種模型,通過模型驅動的開發方法實現,大大提高了系統的開發效率。組織模型設計模塊將在未來的工作中完成,通過類似上述流程建模模塊的設計方法,能夠很容易地完成這個模塊。數據模型定義模塊通過Eclipse自帶的XML schema編輯器完成。工程管理模塊通過Eclipse RCP(rich client platform)實現,得到的系統是一個獨立的桌面應用,其他模型通過插件方式運行在這個系統中。系統的結果界面如圖5所示,顯示風格類似Eclipse。在流程設計時,用戶從調色板中選擇流程元素,通過各種連接對象將各個流程元素連接起來;接著定義元素的屬性,得到一個符合BPMN規范的流程模型;然后綁定組織模型和數據模型;最后通過一個轉換工具,將BPMN轉換成BPEL語言,這樣就完成了一個完整的業務流程建模。轉換工具的實現可以參考文獻[7]。
3應用舉例
通過對旅行登記建流程模,展現開發平臺對業務流程建模的支持。其流程模型圖形如圖6所示。收到啟動消息的開始事件啟動整個流程,由信用卡查詢任務對用戶的信用度進行查詢,然后進入訂購子流程。
子流程是一個事務活動,同時執行預訂機票和預訂旅館這兩個任務。如果預訂均成功,則執行訂購成功任務通知用戶預訂成功;如果子流程發生異常,則分別執行取消機票預訂和取消旅館預訂這兩個補償任務,然后執行定購失敗任務通知用戶訂購失敗,最后執行消息驅動的結束事件,通知系統流程結束。所有的任務都是通過調用相應的Web服務實現。通過圖形化界面,筆者設計了一個業務流程。流程有豐富的表達能力和易于理解的特點,有效地提高了開發效率。
4結束語
業務流程建模平臺是業務流程管理系統的重要組成部分。本文提出了三維業務流程模型,即流程模型、組織模型和數據模型。基于BPMN規范,分別對其元模型建模;利用模型驅動的開發方法和開源Eclipse開發框架來實現。通過對旅行登記流程建模,可見本文的方法對業務流程有很好的支持,有較好的顯示效果,完整支持BPMN規范,大大方便了業務人員,提高了工作效率。今后的工作是研究如何完善業務模型、流程模型正確性檢測以及對流程仿真監控等;進一步加強建模平臺,以符合業務流程建模需求。
參考文獻:
[1]殷冬良,張成洪.協同商務環境下的業務流程管理(BPM)技術研究[J]. 物流科技,2006, 29(6):78-80.
[2]BPMI .org. OMG: business process modeling notation specification[S/OL]. Final Adopted Specification.(2006). http://www.bpmn.org/.
[3]李紅臣,史美林.工作流模型及其形式化描述[J]. 計算機學報,2003,26(11):1456-1463.
[4]Eclipse.org. GMF tutorial BPMN [EB/OL]. (2006-10-26).[2007-03-27].http://wiki.eclipse.org/index.php/GMF_Tutorial_BPMN#Running_Diagram_with_no_Domain_.28optional.29.
[5]MOORE W, et al. Eclipse development using the graphical editing framework and the eclipse modeling framework[M/OL].(2004). [2007-03-27]. http://www.redbooks.ibm.com/abstracts/sg246302.html.
[6]FRANKE D S. 應用MDA[M]. 鮑志云,譯.北京: 人民郵電出版社,2003.
[7]OUYANG C,WMP van der Aalst,DUMAS M,et al. Translating BPMNto BPEL[EB/OL]. (2006-07-19).[2007-03-27].http://eprints.qut.edu.au/archive/00003615/.
“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”