基于面向服務業(yè)務流程管理的系統(tǒng)架構建模

李潤曄， 倪 楓， 劉 姜， 鐘賢欣， 全啟宸， 周彥琪

（上海理工大學 管理學院，上海 200093）

1 BPM+SOA 架構方法

信息時代，企業(yè)業(yè)務環(huán)境瞬息萬變，對信息系統(tǒng)的復雜性、敏捷性等要求越來越高。雖然業(yè)務流程管理（business process management, BPM）能促進業(yè)務流程的優(yōu)化，但無法對齊不斷變化的業(yè)務流程和IT 系統(tǒng)。而能銜接BPM 與企業(yè)后端并封裝應用系統(tǒng)功能的面向服務架構（service-oriented architecture, SOA）可以通過其松耦合、粗粒度的特點，彌補BPM 固化于各系統(tǒng)的缺陷，還能將業(yè)務流程轉(zhuǎn)化為可復用組件，利用接口和協(xié)議相互聯(lián)系，促進系統(tǒng)間信息以及業(yè)務邏輯的共享。兩者結(jié)合，融合信息技術與管理技術，確保業(yè)務流程的高效性以及IT 架構的敏捷性，充分利用現(xiàn)有資源，促進業(yè)務間協(xié)作。

對象管理組（object management group, OMG）所提出的模型驅(qū)動架構（model driven architecture,MDA）為BPM+SOA 系統(tǒng)架構所涉及的多層次建模提供參考，其開發(fā)軟件主要從計算無關模型（computing independent model, CIM）到平臺無關模型（platform independent model, PIM），再到平臺相關模型（platform specific model, PSM），最后轉(zhuǎn)換成代碼。由此，開發(fā)各階段的工作成果得到保護，過程由一系列模型驅(qū)動，并經(jīng)過迭代使其不斷完善[1]。如今基于MDA 的復雜系統(tǒng)建模主要有通用方法[2]、并行方法[3]、對象?過程法[4]和狀態(tài)分析法[5]這4 種。

近年來，國內(nèi)外對BPM+SOA 的研究眾多，如Beimborn 等證明了兩者的互補性[6]；王玉娟促進了中石化科技管理系統(tǒng)復雜業(yè)務邏輯的可維護性與可擴展性的實現(xiàn)[7]；Zhao 等以BPM 為出發(fā)點，結(jié)合SOA 與企業(yè)服務總線實現(xiàn)系統(tǒng)的集成[8]；Alam 等對面向服務架構方法的發(fā)展與影響進行系統(tǒng)評估[9]；Laumer 等通過調(diào)查，得出信息系統(tǒng)與不同業(yè)務流程管理組件結(jié)合，將產(chǎn)生不同流程績效的結(jié)論[10]；Hachicha 等為面向服務架構中的協(xié)作業(yè)務流程提供了分析與評估的方法[11]。然而，這些研究與建模語言的聯(lián)系不夠緊密，限制了通過BPM+SOA 方法進行系統(tǒng)架構設計與建模的工程應用。

另外，BPM+SOA 的系統(tǒng)架構需要將計算獨立的業(yè)務模型轉(zhuǎn)換成平臺獨立的服務模型。模型轉(zhuǎn)換是模型驅(qū)動架構的關鍵技術之一，可被用于將質(zhì)量較低的模型重構成質(zhì)量較高的模型[12]，或?qū)⒏叱橄髮拥哪Ｐ娃D(zhuǎn)換為低抽象層的模型。轉(zhuǎn)換技術主要有直接法、目標結(jié)構驅(qū)動法、關系法、圖轉(zhuǎn)換法等[13]。近年來，曾一等通過元模型實現(xiàn)PIM到PSM 的自動轉(zhuǎn)換[14]；蘇紅軍等驗證了通過編程實現(xiàn)模型驅(qū)動轉(zhuǎn)換的靈活性和功能實現(xiàn)的多樣性[15]。然而，目前國內(nèi)學者的相關研究主要圍繞PIM 與PSM 間的轉(zhuǎn)換，甚少涉及CIM，難以滿足BPM+SOA 的系統(tǒng)架構建模的需要。

元對象機制（meta object facility, MOF）中，元模型是模型的上層抽象，能滿足模型自身的集成、存儲以及管理等需要[16]。在元模型應用中，本體元模型較為常見。如Henderson-Sellers 結(jié)合元模型和本體論的概念，提出“領域本體論”（domain ontology）[17]；如Béhé等所提出的本體元模型描述了多代理模擬概念[18]；又如閆雪峰等所構建的本體設計元模型能夠有效地轉(zhuǎn)換并實例化成為虛擬樣機仿真模型[19]。部分學者還注意到系統(tǒng)架構中，建模語言和元模型之間的關系，提出元建模方法，如何嘯等所提出的表示法定義元模型[20]，又如Pardillo 等對擴展UML 配置元模型（UML profile meta-model）的研究[21]。但元建模對語義的描述不夠完善且在需要多側(cè)面描述的復雜系統(tǒng)建模過程中的作用相對有限[22]。

本文將在前人研究的基礎上，利用protégé軟件進行語義層和語法層兩次推理，探究雙方各自的建模語言之間的映射規(guī)范，并通過案例證明方法的可行性。

2 建模語言

2.1 BPMN

由業(yè)務流程管理倡議組織創(chuàng)建并由OMG 發(fā)布的業(yè)務流程建模與標注（business process model and Notation, BPMN）在建模領域的優(yōu)勢主要在于：提供了一套易被業(yè)務用戶理解的標記語言，所構建的模型注重分析與描述業(yè)務流程，有助于對流程的可視化管理，為其設計與實現(xiàn)提供標準化橋梁。BPMN2.0 語言則進一步為存儲、交換與執(zhí)行等問題提供解決方案。它將圖形化標記分為5 種基本類型，即流對象（flow objects）、連接對象（connecting objects）、泳道（swim lanes）、人工制造物（artifacts）、數(shù)據(jù)（data）。

2.2 SoaML

面向服務架構建模語言（service-oriented architecture modeling language, SoaML）是對標準建模語言（UML）的拓展，關注并描述參與者的需要與功能，并將他們在服務價值鏈中聯(lián)系起來。其主要建模元素有參與者（participant）、接口（interface）、服務合約（service contract）、服務體系結(jié)構（service architecture）、服務數(shù)據(jù)（service data）以及能力（capability）。SoaML 的主要優(yōu)勢在于：關注整個系統(tǒng)架構的實現(xiàn)，為業(yè)務模型到IT 模型搭設橋梁，提供變化的可追溯性，只要服務定義維持不變，業(yè)務流程或信息技術方面就能進行相對獨立的變更，由此提升系統(tǒng)的敏捷性。

2.3 融合機制

在系統(tǒng)架構過程中，融合BPMN 與SoaML 的建模能力。由于BPMN 能夠較宏觀地展現(xiàn)多個參與者間的業(yè)務交互，描述業(yè)務活動的實現(xiàn)過程，確保系統(tǒng)能夠緊密匹配持續(xù)優(yōu)化的業(yè)務流程，故以BPMN 為主要建模語言的業(yè)務模型對應系統(tǒng)需求描述而獨立于技術實現(xiàn)的CIM；由于SoaML 將具體的業(yè)務活動封裝成描述功能的服務，并展現(xiàn)服務間關系和數(shù)據(jù)流，故以SoaML 為主要建模語言的服務模型對應重視整個系統(tǒng)架構的實現(xiàn)而忽略平臺相關部分的PIM。以此為原則建立融合機制，不但銜接業(yè)務層與技術層，更符合模型驅(qū)動架構的要求。在DoDAF 2.X（The Department of Defense Architecture Framework 2.0）框架下，BPMN 滿足業(yè)務活動模型OV-5b 的要求，而SoaML 滿足展現(xiàn)參與者和服務以及兩兩相互關系的SvcV-1 模型與描述服務功能以及功能中服務數(shù)據(jù)流的SvcV-4 模型等的要求。

本文通過No Magic 公司的Cameo EA 產(chǎn)品構建BPMN 和SoaML 模型。Cameo EA 為系統(tǒng)架構提供強大而健全的標準，促進同一系統(tǒng)不同視圖模型數(shù)據(jù)元素的一致性，有助于BPMN 與SoaML的結(jié)合。

3 基于元模型映射的模型關聯(lián)

3.1 元模型的分類與作用

結(jié)合上文所述，將元模型分為本體元模型和標記元模型。本體元模型是基于概念所處語境以及自身語義的，屬于語義層的元模型。而為圖形化建模語言服務的標記元模型則由于抽象圖形在模型中本身帶有一定的規(guī)則和語法，屬于語法層的元模型。圖1 體現(xiàn)了兩者在MOF 中的運用以及區(qū)別。

圖 1 本體元模型和標記元模型在元對象機制中的運用及兩者區(qū)別Fig.1 Application of the ontology meta-model and notation meta-model in MOF and the differences between them

基于Gerber 等的觀點：“若一個本體模型能降低抽象級而建立實例化的模型，則這個本體模型就是該模型實例的元模型[23]”?？梢匀绱死斫獗倔w元模型：基于語義構建的，能夠?qū)⑵渌母拍顚嵗删唧w的、彼此間存在關系的詞匯并構成模型的本體模型。本體元模型用集合語言表示為

式中：MMO表示本體元模型；EO表示本體元素；AO表示相關屬性；RO表示類與類或類與屬性間的關系。

基于何嘯等的表示法定義元模型[20]、Pardillo等的UML 配置元模型擴展版[21]、可視化建模語言使用指南中的元素分類圖等，可以如此理解標記元模型：基于語法構建的，能將其所包含的標記實例化成具體的、彼此關聯(lián)的符號并構成圖形化模型的模型。標記元模型用集合語言表示為

式中：MMN表示標記元模型；EN表示標記元素；AN表示相關屬性；RN表示標記與標記或標記與屬性間的關系。

圖1 中，M2 層的“人吃食物”是M3 層的“飲食起居”這個高度抽象的概念性詞語的一個實例。在這個本體元模型中，“人”和“食物”都是實體EO，它們都具備自身的屬性，即AO，而“吃”成為了這2 個實體之間的關系RO。至于M2 層的標記元模型，是對M3 層的“BPMN 元素”這一抽象概述的一種實例化。不同于偏重語義的本體元模型，該標記元模型中“泳道”、“任務”、“事件”3 個實體EN是BPMN模型中的3 種圖形符號，它們自身所具備的屬性AN，是由建模語言BPMN 的語法要求所賦予的。比如，按照BPMN 語法規(guī)定，“泳道”和“任務”的符號形狀與用途都不相同，“泳道”有“一大一小兩矩形框”與“體現(xiàn)行為主體”的屬性，而“任務”有“圓角矩形框”與“表示流程中某個活動”的屬性。實體間的關系RN，也需要結(jié)合BPMN 的語法要求。比如，“泳道”和“任務”的關系RN是“任務”實體必須嵌在“泳道”實體中才能體現(xiàn)該“泳道”所代表的主體進行該“任務”。因此，本體元模型是可以基于自然語言語義直接構建，而標記元模型的構建必須考慮其上層，即某種可視化建模語言的語法規(guī)定。

由于系統(tǒng)架構涉及多個視圖表述，其建模語言各不相同，并需要保持語義的一致性和語法的正確性，因此，代表語義層的本體元模型將維持不變，代表語法層的各建模語言標記元模型間能夠通過本體元模型實現(xiàn)映射，而且標記元模型所對應的概念，是本體元模型中不同視圖的交集O，所以，兩者關系可如圖2 所示。

圖 2 本體元模型和標記元模型的關系Fig. 2 Relationship between the ontology meta-model and notation meta-model

3.2 本體元模型的構建

為了描述系統(tǒng)架構建模過程中所涉及到的概念，聯(lián)系不同建模語言，需要構建一個本體元模型。首先，由于本文主要研究BPM+SOA 的系統(tǒng)架構建模，因此，該本體元模型以運用BPM 思想的業(yè)務視圖和代表SOA 理念的服務視圖為主。其次，參考美國國防部提出的核心體系結(jié)構數(shù)據(jù)模型以及DoDAF 元模型中所涉及的概念，提出適合各視圖并具有代表性的本體元素。再次，為這些元素賦予功能屬性，實現(xiàn)不同建模語言的標記元模型間的映射。最后，基于語義明確它們的關系，進而得到圖3 的本體元模型。

由圖3 可知，式（1）中的MMO為圖3 所示的BPM+SOA 系統(tǒng)架構的本體元模型；本體元素EO有“節(jié)點”、“活動”、“信息”、“規(guī)則”、“資源”、“能力”等；相關屬性AO則是矩形框內(nèi)的功能屬性；“組成”和“是屬性”則代表本體元素間以及本體元素和屬性間的關系RO。其中，業(yè)務視圖和服務視圖中的“信息”主要指模型中被傳遞的信息實例， 該實例是活動輸入、輸出的來源，與活動是多對多的關系；而服務視圖中的“資源”則描述系統(tǒng)在活動的執(zhí)行過程中所涉及到的相關數(shù)據(jù)實體。另外，結(jié)合圖2 和圖3，可得當標記元模型A 表示BPMN 的標記元模型，而標記元模型B 表示SoaML 的標記元模型時，A 屬于業(yè)務視圖，B 屬于服務視圖，交集為

圖 3 業(yè)務流程管理結(jié)合面向服務架構的系統(tǒng)架構的本體元模型Fig.3 Ontology meta-model of system architecture based on BPM+SOA

式中：n 表示節(jié)點；a 表示活動；i 表示信息；r 表示規(guī)則。

3.3 標記元模型的構建

建模語言的語法可視作諸多標記的語義的集合，所以，標記元模型的構建方法與本體建模相似。而式（2）中的MMN為圖4 所示BPMN 的部分標記元模型以及圖5 所示的SoaML 標記元模型；圖4和圖5 中的橢圓框代表標記元素EN；矩形框代表相關屬性AN；“屬于”、“組成”和“是屬性”則代表標記元素間以及標記元素和屬性間的關系RN。

圖 4 業(yè)務流程建模與標注的部分標記元模型（以流程編制模型為主）Fig.4 Partial notation meta-model of BPMN （mainly based on process orchestration）

3.3.1 BPMN 的元模型

圍繞業(yè)務視圖中最常見的流程編制元素，在確定了重要的專業(yè)術語及其屬性，并且結(jié)合語義關系明確了與BPMN 標記元素的映射關聯(lián)之后，可得如圖4 所示的以流程編制模型為主的部分BPMN 標記元模型。

3.3.2 SoaML 的元模型

SoaML 對UML 的延伸主要有6 個方面，根據(jù)語義確定SoaML 標記元素間關系并為它們賦予功能屬性，可得如圖5 所示的SoaML 標記元模型。

3.4 模型間映射

圖6 展示了本文使用protégé進行映射的思路，其中，元素的功能屬性是為了實現(xiàn)推理，之所以使用本體元模型，是因為系統(tǒng)架構是基于DoDAF 框架的，需要應用該框架內(nèi)的相關概念確保不同建模語言的標記元模型間映射的準確性，進而為不同層級模型間的轉(zhuǎn)換始終滿足DoDAF 框架的要求提供保障。基于此思路，本文將推理映射分為兩部分。

第一步是將標記元素映射到本體元素的語義層映射，當標記元素集M 的屬性值為功能屬性集F 時，便能利用推理建立M 和屬性值同為F 相等類的本體元素集E 之間的映射關系。第二步是為不同建模語言的標記元素構建映射關系的語法層映射?；谏弦徊降耐评?，使屬性值為F 的標記元素集M 和屬性值為F 的標記元素集N 都成為了E 的子集，進而以E 為橋梁，生成M 和N 的映射規(guī)范。

語義層映射是為了確保語義間的一致性，即保障不同抽象級的模型始終處于同一個系統(tǒng)架構的框架下；而語法層映射是為了確保語法的準確性，即通過建立2 個標記元模型間的映射規(guī)范，保障標記的使用規(guī)則滿足當前的建模語言要求。語義層映射是語法層映射的基礎，語法層映射是語義層映射在系統(tǒng)架構建模中的進一步應用，所獲得的映射規(guī)范則是兩步推理的結(jié)論。

3.4.1 語義層映射

在protégé中完成本體元模型和標記元模型的構建后，使用其自帶的推理機進行推理，本體元模型的各個本體元素因推理而具備子類，圖7 為借助OWL Viz 插件展示的以本體元素“節(jié)點”為例的推理結(jié)果節(jié)選?？梢姡ㄟ^推理，標記元素根據(jù)其所具備的功能屬性，映射到了本體元素，即語義層的映射得到實現(xiàn)。

圖 7 以“節(jié)點”為例的推理后模型Fig.7 Inferred model in OWL Viz taking “node” as an example

3.4.2 語法層映射

在原有的基礎上，新增一個類mapping_rule，利用推理機進行推理，并將推理所得的映射規(guī)范整理成表1。表1 縱向是BPMN 的標記元素，橫向是SoaML 的標記元素。表中●表示存在映射關系，空則表示不存在映射關系。

表 1 業(yè)務流程建模與標注和面向服務架構建模語言的映射規(guī)范Tab.1 Mapping rules between BPMN and SoaML

綜上所述，來自不同建模語言的標記元素通過系統(tǒng)架構本體元模型的不同抽象級的交集O 生成標記間的映射規(guī)范，即語法層的映射得到實現(xiàn)。

在通過這兩步映射所得的映射規(guī)范中，存在映射關系的2 個標記元素必定是同一個本體元素因protege 推理而具備的子類。又因為該本體元素所隸屬的BPM+SOA 系統(tǒng)架構本體元模型是基于DoDAF 框架而構建的，同為該本體元素子類的標記元素皆在一定程度上符合DoDAF 框架的要求，都能在各自的可視化模型中體現(xiàn)該本體元素的語義，所以，語義的一致性得到了保障。而本體元素和標記元素間以及標記元素之間的映射關系主要通過它們的功能屬性來確立，標記元素的功能屬性是由該標記元素所屬的建模語言的語法規(guī)定所賦予的，因此，標記元素間的映射關系滿足各自建模語言的語法要求，確保了語法準確性。

3.5 建模過程

對于BPM+SOA 的系統(tǒng)架構下的模型構建，主要根據(jù)上述元模型映射的方法，并參考DoDAF的諸多視圖。DoDAF 2.X 以數(shù)據(jù)為中心，支持SOA，并具備展現(xiàn)模型頂層特性的全景視圖（all viewpoint, AV）、描述可部署能力和能力需求等的能力視圖（capability viewpoint, CV）、闡述所設想的業(yè)務和行動等的業(yè)務視圖（operational viewpoint,OV）、體現(xiàn)執(zhí)行者和服務以及交互關系的服務視圖（service viewpoint, SvcV）、展現(xiàn)獨立系統(tǒng)或遺留系統(tǒng)情況的系統(tǒng)視圖（systems viewpoint, SV）、分析能力和業(yè)務與所實施項目的關系的項目視圖（project viewpoint, PV）、描述數(shù)據(jù)關系并保證數(shù)據(jù)結(jié)構一致性的數(shù)據(jù)視圖（data and information viewpoint, DIV）、展現(xiàn)可應用的標準或約束等的標準視圖（standards viewpoint, StdV）。

建模過程如圖8 所示。第一步，根據(jù)外界需求構建能力視圖；第二步，構建以BPMN 為主要建模語言的業(yè)務視圖；第三步，按照映射規(guī)范，構建以SoaML 為主要建模語言的服務視圖；第四步，構建相應的數(shù)據(jù)視圖和其他視圖；第五步，根據(jù)變化的需求，以原能力視圖模型為初始狀態(tài)，對其進行迭代，即重復上述步驟，完善其余視圖模型，持續(xù)優(yōu)化系統(tǒng)，保障系統(tǒng)敏捷性，逐漸接近目標。圖8 中，各視圖下標n（n≥1）表示迭代的次數(shù)，每迭代一次，都會使得n=n+1，由此循環(huán)迭代該系統(tǒng)架構建模過程。

圖 8 基于業(yè)務流程管理結(jié)合面向服務架構的系統(tǒng)架構建模過程Fig.8 Process of system architecture modeling based on BPM+SOA

4 游樂園智能手環(huán)建模案例

按照上述建模過程，本案例的建模步驟主要有：第一步，構建能力視圖，展現(xiàn)功能結(jié)構；第二步，構建業(yè)務視圖，描述節(jié)點、信息流、業(yè)務流程以及規(guī)則；第三步，構建服務視圖，體現(xiàn)系統(tǒng)功能的參與者、行動、服務以及交互關系；第四步，構建數(shù)據(jù)視圖，描述業(yè)務數(shù)據(jù)間關系。其中，業(yè)務視圖與服務視圖將重點體現(xiàn)前文提及的元模型映射的方法。

4.1 能力視圖

游樂園智能手環(huán)適用于覆蓋范圍廣、人口流動性大、所含子項目眾多的區(qū)域，如迪士尼樂園，其目標用戶主要是園區(qū)內(nèi)的游客。其設計初衷在于引導游客參與故事情景，提升游園體驗，并設置電子圍欄避免在游玩時以兒童為代表的游客在人群中與同伴走散，還能主動就突發(fā)狀況發(fā)起緊急呼救，為園區(qū)安全提供強有力的保障。因此，智能手環(huán)有如圖9 所示的幾個主要功能。

圖 9 游樂園智能手環(huán)功能結(jié)構圖Fig.9 Functional structure of the smart bracelet for amusement park

4.2 業(yè)務視圖

智能手環(huán)系統(tǒng)主要涉及游客、智能手環(huán)、游玩設備、第三方（如安全中心和急救中心）等節(jié)點，故以“走失尋回”場景為例的信息流如圖10所示。而圖11 所示的BPMN 模型，展現(xiàn)該場景中的工作流程。

業(yè)務視圖還包含描述該業(yè)務中所有預期事件執(zhí)行條件的規(guī)則模型，表2 例舉了“走失尋回”場景下的一條規(guī)則。

圖 10 “走失尋回”場景下智能手環(huán)業(yè)務節(jié)點與信息流Fig.10 Operational node and resource flow of the smart bracelet in “l(fā)ost search” scenario

圖 11 “走失尋回”場景下的BPMN 模型Fig.11 BPMN model in “l(fā)ost search” scenario

表 2 “走失尋回”場景下的業(yè)務規(guī)則模型節(jié)選Tab.2 Partial operational rules model in “l(fā)ost search ”scenario

4.3 服務視圖

首先，將業(yè)務視圖中場景“走失尋回”用服務體系結(jié)構來展現(xiàn)，用于描述各服務以及它們之間的關系，如圖12 所示。其中，3 個參與者（Participant）分別對應業(yè)務視圖中的3 個泳道，游客、智能手環(huán)和安全中心。業(yè)務視圖中的任務“設置初始值”、“游覽園區(qū)”和子流程“地理定位”被打包映射成游客和智能手環(huán)間的一個服務合約（Service Contract）“地理定位”。子流程“狀態(tài)應對”和任務“追尋目標”被打包映射成游客和智能手環(huán)間的服務合約“狀態(tài)應對”。任務“確認尋回”被映射成服務合約“確認尋回”。另外，由于業(yè)務視圖中，智能手環(huán)和安全中心也發(fā)生了交互，所以，將子流程“狀態(tài)應對”中與安全中心相關的任務和任務“確認尋回”打包，映射成第四個服務合約“第三方幫助”。

其次，結(jié)合映射規(guī)范，定義各服務合約中的接口和角色，如圖13 所示，消息流都將通過接口的不同操作（operations）實現(xiàn)傳遞。由泳道映射而來的角色，相比參與者，增加了消息提供方（provider）和消息使用方（consumer）的設定，由此體現(xiàn)了消息的流向。接口則由業(yè)務視圖中的消息流映射而來，并在消息流的基礎上，定義了信息傳遞的操作，為進一步實現(xiàn)該系統(tǒng)奠定基礎。

業(yè)務視圖中BPMN 模型的語義延續(xù)到服務視圖中，并根據(jù)服務視圖中SoaML 的語法規(guī)定調(diào)整標記元素，以此保障了語法的準確性。

圖 12 “走失尋回”場景下的服務體系結(jié)構Fig.12 Service architecture in “l(fā)ost search” scenario

圖 13 “走失尋回”場景下的服務合約Fig.13 Service contract in “l(fā)ost search” scenario

4.4 數(shù)據(jù)視圖

圖 14 “走失尋回”場景下的邏輯數(shù)據(jù)模型Fig.14 Logic data model in “l(fā)ost search” scenario

本案例主要展現(xiàn)業(yè)務流程中的數(shù)據(jù)要素，即構建邏輯數(shù)據(jù)模型。經(jīng)過定義實體、定義關系和定義屬性3 個步驟，分解BPMN 模型中的消息流和數(shù)據(jù)關聯(lián)，得到圖14 的邏輯數(shù)據(jù)模型。

5 結(jié)束語

本文所提出的基于元模型映射的BPM+SOA系統(tǒng)架構建模方法，為面向服務業(yè)務流程建模理論與建模語言的融合提供了一種思路，促進了系統(tǒng)架構設計過程中CIM 到PIM 的轉(zhuǎn)換。另外，將語義層的本體元模型和語法層的標記元模型相結(jié)合，有助于維持系統(tǒng)架構不同視圖中的語義一致性和語法準確性。本文的方法還存在的局限：對于本體元模型和標記元模型的定義有待完善；構建系統(tǒng)架構本體元模型的原則和標準尚待探索；模型間的映射規(guī)則尚待完善，并實現(xiàn)自動映射和模型轉(zhuǎn)換。以此作為進一步研究方向，最終期望實現(xiàn)BPM+SOA 系統(tǒng)架構建模的自動化。