基于擴展BPMN的“家園互動”式兒童健康管理系統架構

王新康，倪 楓，劉 姜，楊 帆，郭 悅

（1 上海理工大學 管理學院，上海 200093；2 上海市金山區陽光城幼兒園，上海 200540；3 河南理工大學 財經學院，河南 焦作 454000）

0 引言

近年來，信息化發展逐漸成為國內企業的一個發展方向。相應地，業務流程管理（Business Process Management，BPM）和面向服務的架構（Service-Oriented Architecture，SOA）等信息系統也隨著計算機技術的迅猛發展不斷由概念、理論的研究而陸續經由項目研發、并最終轉化為實用系統。眾所周知，目前的市場環境變化迅速，企業之間的競爭日益激烈，企業為了確保自身生存就必然要提升工作效率，所以在不久的將來，數字系統也將成為各家企業生存發展中不可或缺的重要組成部分。

模型驅動架構（Model Driven Architecture，MDA）在2001年7月由OMG發布，其核心思想在于先構建計算無關模型（Computation Independent Model，CIM），隨后形成了平臺無關模型（Platform Independent Model，PIM），再設計平臺相關模型（Platform Specific Model，PSM）。其中，元對象設施（Meta Object Facility，MOF）是MDA的核心技術之一。MOF是OMG為幫助銷售商、開發者和用戶更好地使用元模型和元數據技術而制定推出的技術規范，并已于2005年成為ISO標準。

目前，國內外的眾多學者都在致力研究如何拓展BPMN使其更有利于企業的后期使用。代飛等人使用Petri網定義BPMN2.0編排的語義，并以此分析BPMN2.0的編排結構和控制流錯誤。陳蕾等人融合if-else語句以及IDEF建模方法與BPMN模型建立元模型映射，實現各描述模型之間語義、粒度的對齊。Valderas等人通過定義一種允許在BPMN模型中創造微服務組合的方法，最終實現組合的整體圖和拆分圖共存。Zafar等人提出了一種支持通過BPMN對交換和轉換過程進行建模的框架，將BPMN模型轉換為SoaML模型后生成可執行Java Web服務，實現從BPMN模型自動生成可執行Web服務。

隨著SOA技術的日臻成熟，有效運用SOA也逐漸成為了一個重要的研究方向。陳娜等人針對傳統SOA效率低下的不足，將Petri網應用于SOA服務識別中。王暢針對傳統的工作流管理系統設計了一種基于SOA的工作流管理系統的5層框架。Kumar等人提出一種基于Petri網的表示依賴關系規范的SOA的依賴分析，并在概念層次上對依賴關系進行建模。

同樣地，MDA的模型間也有多種轉換，當下的研究主要集中在PIM至PSM的轉換與PIM至PIM的轉換方面，而CIM至PIM轉換的相關研究較少。曹曉夏等人通過將CIM特征分層得到層次特征需求模型，并將模式分為不同層級形成分層體系結構，通過識別特征是在哪個層級發生變化，從而實現PIM的相應變化。Li等人通過擴展Petri網模型元素作為橋梁連接CIM模型和PIM模型。Betari等人提出一種使用UML的核心建模概念將CIM轉化為PIM的方式。還有一些學者借助于MDA架構在不同模型間形成映射。Wang等人采用MDA方式實現模型轉化，將UML模型映射到基于Web Service模型中。

近年來，已有為數可觀的國內外學者相繼開始探尋BPM和SOA相融合的方式。鄧子云等人運用SOA和BPM結合架構了第三方物流信息系統集成平臺。尹裴等人提出以提升信息系統柔性為方向，采用BPM和SOA相結合的方式來實現。倪楓提出基于TOGAF的外層和內層迭代建模方法，并在內層進一步探討了BPM＋SOA建模方法。李潤曄等人借助于模型間映射將BPM和SOA相結合來進行建模架構。Hachicha等人提出一種面向服務架構中協同業務流程的分析和評估方法，以保持企業在競爭市場中的競爭力。

基于前人對于BPMN和SOA的技術成果，本文擬使用MDA建模架構和MOF元模型規范對BPMN與SoaML之間互相映射的方式和規范展開研究。

1 業務流程主流建模方法

1.1 業務流程建模與標注

業務流程建模與標注（Business Process Model and Notation，BPMN）提供了一套易于被所有業務用戶理解的符號，在業務流程設計和流程實施間構建了標準化橋梁。BPMN基于業務流程圖，通過規定和定義一些標準化圖形元素，并將其進行組合可以得到一個標準的BPMN流程。BPMN2.0包含5類元素，分別是：流程對象（Flow Objects）、連接對象（Connecting Objects）、泳道（Swim Lanes）、工件（Artifacts）、數據（Data）。

1.2 SOA架構

1.2.1 面向服務架構

研究可知，隨著XML和Web Service等技術的快速發展，SOA已然從概念逐漸轉向于現實應用，并日漸成為軟件工程的實踐方法之一。服務注冊庫、服務請求者和服務提供者是SOA包含的主要3個角色，三者之間的關系如圖1所示。SOA為企業的軟件系統提供了一種通過對服務流程化來構建分布式系統的標準和方法，能夠大幅度減少信息業務的冗余。SOA具有松耦合性、粗粒度性、標準化接口等優勢。

圖1 SOA基本組成Fig.1 Basic composition of SOA

1.2.2 面向服務架構建模語言

面向服務架構建模語言（Service-Oriented Architecture Modeling Language，SoaML）是對UML2的拓展，集成了建模功能，以支持在不同級別和不同方法上使用SOA。SoaML主要在6個主要領域拓展UML，分別是：參與者、服務接口、服務合約、服務架構、服務數據、能力。

2 BPMN模型與SoaML模型映射

2.1 BPM和SOA關系

BPM是一種業務流程協調的管理模式，偏向于管理方面，而SOA則是面向服務的一種架構，更偏向于是一種建模體系和思想，兩者看似毫不相關，但各自卻在經過數年發展和演變后，迄今為止已經具備了良好的整合契機。BPM和SOA的關系如圖2所示。

圖2 BPM與SOA關系Fig.2 Relationship between BPM and SOA

從圖2中可以看出在業務流程中，每項任務和流程都對應著具體的業務系統，SOA作為中間的橋梁可使BPM能夠更為高效、便捷地使用各業務系統，而BPM則讓SOA可以更清晰地對各業務系統進行有機整合。BPMN和SoaML分別作為BPM和SOA的一種建模語言同樣具有這些特點，BPMN使用各種圖形化符號體現業務流程，能夠較為宏觀地展現不同參與者之間的信息傳遞和工作與任務等相關業務的交互，SoaML通過把業務活動中任務和信息流傳遞打包封裝成具有描述功能的作用的服務，從而展現不同服務之間關系和數據流，因此本文的研究關鍵就在于探索BPMN與SoaML之間相互映射和聯系。

2.2 元模型建立及集合定義

MDA四層元模型層次架構為元模型的擴展提供體系結構基礎。MDA四層次架構的聯系和關聯如圖3所示。圖3中，層為元元模型層，是元模型體系結構的基礎結構，用于定義元模型，包含關聯、類、屬性等元素。層為元模型層，是層的實例，用于描述元模型。層為模型層，是層的實例，用于描述數據和對象，包含各類模型。層為實例層，一般是對象和數據，主要體現了現實世界中的事物對象。

圖3 MDA層次架構Fig.3 MDA levels architecture

本文的系統架構以具體對象或數據為基礎建立的元模型，這些元模型自身一般具有不同的語義，因此首先要在語義層將BPMN和SoaML元模型映射至同一個元模型中。系統架構中所使用的2種建模語言均遵循一定的語法，故稍后在語法層定義映射規則并以該映射規則根據語義層的映射結果在語法層實現模型間映射。在映射前，先根據一定的標準對元模型進行定義，本文構建的元模型包含有元素、屬性以及關系，其中屬性一般是元素在建模過程中所賦予的功能和在建模中的表現方式，而關系包含元素與元素和元素與屬性之間的關系。

2.2.1 本體元模型建立及集合定義

為了將系統架構所使用的2種建模語言建立起宏觀聯系，首先在語義層對整個系統構建本體元模型。考慮到本文主要研究BPMN和SoaML之間的映射關系，所以根據整個系統需求和運行流程以及2種模型的特點選擇合適的本體元素。其次，根據各元素在建模過程中所需要的功能和表現方式賦予相應屬性，有助于定義映射規則使2種建模語言向標記元模型進行映射。最后，基于定制的語義明確2種不同建模語言之間的關系，得到本體元模型如圖4所示。

圖4 系統架構的本體元模型Fig.4 Ontology meta-model of system architecture

從圖4中可以看出，本文的本體元模型是基于BPMN的業務視圖和基于SoaML的服務視圖所建立的。圖4中，圓角矩形框內的本體元素和矩形框內分隔上半部分為本體元素；屬性包含矩形框內分隔下半部分的功能屬性；“屬于”、“組成”以及矩形框內的分隔體現了本體元素和本體元素間以及本體元素與屬性之間關系。

2.2.2 標記元模型建立及集合定義

構建模型使用的建模語言的語法可以視為許多標記的語義所組成的集合，因此可以參照本體元模型的建模步驟對標記元模型進行建模。根據BPMN2.0包含的至關重要的5類元素，在明確其在建模過程中的具體功能屬性后，即可推得BPMN元模型，如圖5所示。

本文的標記元模型基于BPMN模型建立，圖5中圓角矩形框內的標記元素和矩形框內分隔上半部分是標記元素；屬性包含了矩形框內分隔下半部分的功能屬性；“屬于”、“組成”以及矩形框內的分隔則表明了標記元素之間和標記元素與屬性之間的關系。

圖5 BPMN元模型Fig.5 BPMN meta-model

2.2.3 服務元模型建立及集合定義

類似于標記元模型，服務元模型的建模步驟也可以類比本體元模型的建模步驟。研究可知SoaML主要在6個領域拓展了UML2，所以根據這6個主要領域提取適合的服務元素，當明確各服務元素在建模過程中的具體功能屬性后，即可得到SoaML元模型如圖6所示。

本文的服務模型基于SoaML模型建立。圖6中，圓角矩形框內的服務元素和矩形框內分隔上半部分為服務元素；屬性包含矩形框內分隔下半部分的功能屬性；“屬于”、“組成”以及矩形框內的分隔則表明了服務元素之間和服務元素與屬性之間的關系。

圖6 SoaML元模型Fig.6 SoaML meta-model

2.3 模型間映射

BPMN的標記元模型和SoaML的服務元模型之間的映射思路如圖7所示。本文將模型間映射分為2部分。首先在語義層根據元模型的語義定義映射規則，將標記元模型和服務元模型中具有相同或類似的屬性的標記元素和服務元素映射到本體元模型中具有同樣屬性的本體元素。接下來，基于前一步的映射標記元素、服務元素、本體元素都有相同功能屬性，以本體元素及其功能屬性作為映射依據，在語法層定義映射規則，使標記元素和服務元素之間在語法層中形成映射。

圖7 元模型映射Fig.7 Mapping of meta-model

2.3.1 語義層定義及映射規則

語義為建模語言表達的概念和建模語言的符號之間架起了連接的橋梁，具體表示了表達式的含義。語義主要包含2種：靜態語義和動態語義。其中，靜態語義是在模型構建、系統運行之前就已經確定的語義，即模型的符號本身就可以表達識別相應的語義；動態語義是在系統運行期間才能夠識別認定的語義，包括一致性和合法性等。在大部分建模語言中，類型相關的信息屬于靜態語義，并通常與一些語義規則的約束條件相對應，用于規定一段語句或一個模型是否符合定義，而動態語義一般來說約束上相對較弱，在編譯代碼或構建模型時不受動態語義規則限制，因此在建模時無法判斷是否合法，只有在模型運行時才會知道是否出現錯誤。本文研究建立的系統架構中的元模型都采用靜態語義，且使用的建模語言都具有明確的定義和功能，因此在建立模型時就能夠知曉模型是否符合建模規范和語義規則，而在正確建立模型后也可確保系統正常運行。

參照前文所提及的模型映射步驟，首先對整個系統架構在語義層進行映射。元模型之間的映射中都需要遵守一定語義規則，以確保模型映射后仍然符合一定語義且具有合法性，本文針對提出的模型和系統架構定義如下語義映射規則：

（1）服務元模型和標記元模型的映射對象必須是元素。

（2）映射的服務元素或標記元素和被映射的本體元素必須具有屬性。

（3）映射的服務元素或標記元素的屬性和被映射的本體元素的屬性必須相同或相似。

基于上文定義的語義映射規則，首先按照不同功能屬性將本體元模型中業務視圖和服務視圖中具有相同屬性的本體元素分類，再根據語義規則將標記元模型和服務元模型中的元素映射到本體元模型中，映射后模型如圖8所示。

圖8 語義層映射Fig.8 Mapping in semantic layer

本體元模型的本體元素中，“節點”、“活動”、“信息”、“規則”的屬性在標記元模型和服務元模型中都有相應的元素具有該功能屬性。

2.3.2 語法層定義及映射規則

語法是指建模語言具有精確定義的形式，語法同樣可以分為2類：抽象語法和具體語法。其中，抽象語法是對建模語言本質性的描述，目的在于描述模型元素、元素之間的關系和聯系以及模型合法性約束，通常關注的是建模語言概念和元素的抽象表達，并不關注具體將如何呈現給用戶。以前述提出的標記元模型為例，模型中的標記元素僅僅是抽象表達，未能賦予相應的圖形符號表達，而研究中可以通過功能屬性對建模語言定義規則用于判斷模型在抽象語法方面是否合法，以此控制非法模型出現。

通過抽象語法，僅僅可以知道模型的一些抽象概念和約束條件，無法進行實際建模，此時需要借助具體語法進行建模。具體語法包含2種形式。一種是基于文字和數學符號的文本語法，另一種是基于圖形化符號的圖形化語法。前者使用通俗易懂的符號，較容易理解；后者使用圖形展示，模型元素之間的關系、事件或任務之間的聯系和事件順序可以較為直觀地做出展示。兩者各有利弊，由于本文選取BPMN和SoaML兩種已經普遍使用的建模語言，因此本文主要討論這2種語言中主要使用的圖形化語法。表達語法的圖形多種多樣，大多使用的是方框、圓、實線箭頭、虛線箭頭等標準圖形以及如信封等可以直接代表某一種元素的特殊圖形，而且還可以根據不同的具體功能對圖形進行一定修改，部分模型元素和圖形化語法見表1。

表1 模型元素及其圖形化語法Tab.1 Model elements and graphical syntax

研究至此，還需要基于語法層定義一個映射規則，可以將模型之間的映射具體化，明確模型具體的映射方法和映射規范。這里給出了一個定義為六元組的模型映射規則，重點展示了將BPMN元模型映射到SoaML模型的規則，記為：

其中，表示BPMN模型的標記元素；表示SoaML模型的服務元素；表示映射條件；表示標記元素的屬性；表示服務元素的屬性；為函數，表示模型間的映射關系。

在本文的模型中，函數表示如下的映射關系：：→，表明BPMN模型中的標記元素在滿足一定條件時，轉換成SoaML模型中的服務元素。例如f：→。其中，映射條件是該標記元素的功能屬性和服務元素的功能屬性相同或類似且可以在本體元模型中找到具有相同或類似功能屬性的本體元素，主要表示BPMN模型中的標記元素和的功能屬性在滿足條件時，可以映射成SoaML模型中的服務元素和的功能屬性。

根據上文定義的映射規則，BPMN中部分標記元素可以與SoaML中部分服務元素相互映射，相互映射關系見表2。

表2 BPMN與SoaML映射關系Tab.2 Mapping relationship between BPMN and SoaML

從以上的建模過程和映射規則中不難看出，可以相互映射的2種不同建模語言中參與映射的元素一定存在相同或類似的功能屬性，而且在本體元模型中也能夠找到具有相同功能屬性的元素。因為本文基于BPMN和SoaML兩種建模語言結合建立本體元模型，保證了語義一致性。而BPMN和SoaML兩種建模語言已經具有較完善的語法，提出的映射規則是基于這些語法的，所以語法的一致性也得到保證。

2.4 建模過程

由于整個系統建模架構在DoDAF的框架基礎上，因此參考DoDAF的多個視圖并根據前文元模型的映射方法來構建整個系統模型。本文研究建立的系統架構主要使用了用例圖、BPMN、SoaML，對應DoDAF八大視圖中SV、OV、SvcV，再根據具體需求使用其它視圖。

圖9是基于上文的建模過程。由圖9可知，第一步，根據系統的用戶和需求建立系統用例圖、即系統視圖；第二步，建立以BPMN為主要建模語言的業務視圖；第三步，將BPMN的標記元素按照一定的映射依據和映射規則分別在語義層和語法層進行映射，建立以SoaML為主要建模語言的服務視圖；第四步，根據系統和用戶的其它需求構建相應的其它視圖；第五步，后續系統功能或其中的用戶發生改變，以系統用例圖為基礎重復上述步驟進行迭代，完善其余視圖和整個系統架構，直至達到使用者要求。

圖9 建模過程Fig.9 Modeling process

3 兒童健康管理系統建模案例

根據研究提出的系統架構建模和模型間映射關系，對家園互動方式的兒童健康管理系統進行建模。系統主要采用BPMN和SoaML兩種建模語言對系統進行建模架構。對此可做分析闡述如下。

3.1 用例圖建模

兒童健康管理系統主要包含查看兒童實時健康數據和突發情況應對兩個功能。其中，查看兒童實時健康數據功能滿足了家長或幼兒園教師在兒童不在身邊時能隨時了解兒童的實時健康狀況。突發情況應對功能確保兒童在身體狀況出現變化的時候能夠獲得及時的關注并第一時間告知幼兒園教師和家長。參與用戶主要包括2種角色：家長或幼兒園教師和幼兒園負責人員。將兒童健康管理系統建模分析后用例圖詳見如下。

（1）用例名稱：兒童健康管理系統。

（2）系統角色：家長或幼兒園教師、幼兒園負責人員。

（3）簡要說明：家長或幼兒園教師是系統主要用戶，具有查看兒童實時健康數據和接收突發消息的權限。幼兒園負責人具有維護兒童信息和處理應急情況的權限。

（4）前置條件：

①家長、幼兒園教師和幼兒園負責人員都進行了注冊和審核，有權訪問兒童健康管理系統。

②手環獲取的身體數據直接導入兒童健康管理系統中。

（5）后置條件：可以判斷身體數據是否異常，及時做出反應。

兒童健康管理系統用例圖的簡單描述見圖10。由圖10中可以看出，幼兒園負責人員主要起著維護兒童信息和處理應急情況的作用，而家長或幼兒園教師可以通過登錄進入兒童健康管理系統查看兒童當前健康情況，并當幼兒遇到應急情況時就會接收到相關信息。

圖10 兒童健康管理系統用例圖Fig.10 Use case diagram of child health management system

3.2 BPMN模型建模

整個系統基于具有實時監控健康數據的智能手環進行建模，主要涉及用戶端、手環端和幼兒園端等，BPMN模型如圖11所示，展現整個系統運行流程。用戶主要是幼兒園教師和兒童家長，在需要時可通過登錄系統并輸入兒童的相關信息查看兒童實時健康情況，如果兒童遇到突發情況時，也會通過短信或微信消息及時通知家長和幼兒園教師。同時，一旦手環端監測到兒童健康數據有異常就會迅速響應，通知幼兒園相關人員第一時間做出反應，幼兒園方將根據當日入園情況判斷兒童是否在園。如果兒童在園，園方相關人員就會立刻通知幼兒園相關醫務人員前去照看并迅速通知幼兒園當班教師，在了解具體情況后告知家長相關異常情況；如果兒童并不在園，幼兒園相關人員就會通知家長并與其取得聯系，在得知具體情況后通知幼兒園教師。

圖11 兒童健康管理系統BPMN模型Fig.11 BPMN model of child health management system

3.3 SoaML模型建模

根據第2節提出的BPMN和SoaML映射方法和規則，首先定義各個服務合約中的接口和角色，如圖12所示。每個服務接口代表一個操作，一般至少有一個提供者和一個使用者，而提供者和使用者由簡單接口定義，信息和數據則通過接口在提供者和使用者之間傳遞。

圖12 兒童健康管理系統服務接口Fig.12 Service interface of child health management system

緊接著，創建服務合約，如圖13所示。服務合約中除了由BPMN模型中泳道映射得來的3個角色，還增加定義了服務提供者和服務使用者，使得服務合約能鮮明展現服務提供者和服務使用者之間如何提供和使用服務以及信息流傳遞的方向。服務合約則由BPMN模型中任務映射而來。

圖13 兒童健康管理系統服務合約Fig.13 Service contract of child health management system

以“查看兒童實時健康數據”服務為例，服務提供者“手環”鏈接至服務接口圖中相應的簡單接口“手環”；服務使用者“家長／幼兒園教師”鏈接至服務接口圖中相應的簡單接口“家長／幼兒園教師”。

最后，根據上文繪制出的服務接口圖和服務合約圖，使用服務結構圖展現兒童健康管理系統，如圖14所示，用于描述兒童健康管理系統的多個服務以及服務之間的關系和聯系。

圖14 兒童健康管理系統服務架構Fig.14 Service architecture of child health management system

在此過程中，3個參與者分別對應BPMN模型中泳道“用戶端”、“手環端”、“幼兒園端”。以服務合約“查看兒童實時健康數據”為例，即通過BPMN模型中的任務“輸入兒童信息”、“匹配兒童信息”、“獲取兒童實時健康數據”、“查看兒童實時健康數據”打包映射得到。

4 結束語

本文運用MDA四層次架構和MOF元模型規范，搭建出一個具有4個層次的架構，定義并形成以整個系統為基礎的本體元模型、以BPMN為基礎的標記元模型、以SoaML為基礎的服務元模型。此后，定義映射規則明確映射規范，將BPMN的元素和SoaML的元素之間進行映射，形成完善的BPM＋SOA系統架構，達到建模的目的。

本文對于BPMN和SoaML兩種建模語言以及相互之間映射做了初步研究，但本文所給出的系統架構和映射方法仍存在一定缺陷：輸入輸出操作和傳遞的信息流的數據類型需要進一步明確、本文并沒有形成可操作的界面供用戶使用、元模型的定義以及語義和語法的定義可以更加完善準確、映射規則的定義也需要進一步完善。未來還需要進一步深入研究，從而研發出可供企業使用的技術系統。