專家解析 UML業務流程建模不足之處
本文和大家重點討論一下UML業務流程建模中的不足，統一建模語言UML有很多值得學習的地方，那么他有什么不足呢，這里和大家分享一下。
UML業務流程建模中的不足
統一建建模模語言（UML）是一種由對象管理組織（OMG）創立的幫助開發人員對軟件系統進行特定化、可視化和文檔化的模型。UML定義了十二種類型的圖例，分成三類：四種圖形代表靜態的應用結構；五種代表動態的行為；三種代表組織和管理應用的模式。行為類型包括用例圖、順序圖、活動圖、協作圖以及狀態圖。這些行為圖經常被用來給業務流程建模。業務流程建模符號（BPMN）定義了一種圖形化的符號用于給業務流程建模，從這一點上與UML的行為圖是相關和類似的。盡管如此，BPMN和UML在業務流程建模方法上有著明顯的不同。
首先，UML是將業界多種圖形的最好實踐集合在一起而發展起來的，這是它的優點，但也是它的缺點。由于它是一種雜集，它從來沒有考慮設計成一種可以一起工作的方式，因而沒有規定它定義的這十二種類型的圖形之間的聯合性問題。
因此，開發人員只能用UML來給他們的應用系統的某一部分建模，而其它部分則超出了UML規范的范圍之外，屬于用實現級層來描述，而不是建模層。相反地BPMN定義了單一類型，但提供了同屬于基于可執行過程元模型的多種視圖。因而，BPMN只定義了一層——過程建模層，卻可以輸出可執行BPML語言,這種語言部署在業務流程管理系統上可以立即執行。
第二，UML業務流程是以一種面向對象的方式來給應用系統建模，而BPMN是以面向流程的方式給應用系統建模。雖然UML定義的十二種圖形是等同的，但在UML最佳的實踐中往往傾向于優先使用第一類圖形即所謂的結構圖，它包括類圖，對象圖，組件圖和部署圖。由此而產生的結果便是：由UML定義的業務流程不可避免地傾向于必須事先定義好商業對象然后才能進行事務過程這一狹隘的做法。這也許可以解釋UML為什么在真實的業務流程中沒有被商業人員廣泛采納的原因。
BPMN采用了一種幾乎完全相反的方式來給流程建模，它提倡這樣一種方式：首先對控制流和消息流建模，對象只是在流程建模中隱含地定義。這樣做并沒有防止顯性地定義附加的商業對象，或者集成已經存在的通過商業服務而暴露的商業對象，但由于大部分商業對象模型在核心流程模型中只是部分地被隱含地定義，總體開發過程相當簡單，并以戲劇性地簡單方式來更改以應用到現有的過程當中。
第三，UML業務流程的主要目標是系統架構師和軟件工程師，而BPMN的目標是商業分析師，系統架構師和軟件工程師。一方面，UML已經發展為一種使軟件開發過程流水作業的方法，從架構設計到應用實現——這些任務都是由技術人員承擔。在另一方面，BPMN發展了一種貫穿整個商業過程的開發過程流水作業方法，從流程設計到流程部署，前一個任務是由商業人員承擔，而第二個任務是由技術人員承擔。
最后，UML并沒有定義任何可執行的元數據模型來幫助業務流程建模，而且，這樣一種可執行元數據模型必須使用模型驅動框架（MDA）來定義。與此相反，BPMN是建立在流程執行元數據模型語言BPML之上的，遵守著設計驅動框架（DDA）因而建立一種完全可執行過程并不需要任何附加的步驟。
綜上所述，BPMN在業務流程建模方面比UML更勝一籌，有望成為業務流程建模的新標準。
【編輯推薦】
