如何建模：ODM、CIM及模型驅動的層次

MILY: 宋體; mso-hansi-font-family: 'Times New Roman'; mso-ansi-language: ZH-CN">模型驅動應用的核心和癥結就在于一個長期困擾我們的問題：如何對復雜問題建模？對模型驅動的眾多懷疑正是這個問題沒能得到有效解決的明證。

一、MDA的規劃及實現

MDA的規劃其實是非常宏偉的，MDA顯然充分意識到了問題的復雜性，所有嚴格區分了MDA四類模型：

     1、計算無關模型（Computation Independent Model, CIM）

     2、平臺無關模型（Platform Independent Model, PIM）

     3、平臺特定模型（Platform Specific Model, PSM）

     4、實現相關模型（Implementation Specific Model, ISM）。

其中3、4二個模型解決軟件基礎設施問題，也即如今熱門的業務基礎平臺問題。模型驅動實現的關鍵在于，從PIM到業務基礎平臺如何對接。就MDA的規劃來看，主要是通過模型交換。但可執行UML（xUML）顯然給出了另一種快捷的方式。這樣，就有二種模型驅動的實現方式：

    xUML--就是使用動態執行引擎直接執行UML模型

    模型交換--就是把PIM模型變換為容易執行的PSM模型

MDA更多的是從白盒視角規劃了業務基礎平臺的實現架構�？蓤绦蠻ML的模型驅動程度無疑更高。且較之MDA采用PSM來解決對多平臺的支持，xUML則是類java跨平臺的方式，顯得更為敏捷。

二、計算的邏輯模型或邏輯服務模型

更重要的是，xUML實際上消解了PIM與PSM的區分，而專注于計算的邏輯模型。所以，在關于《新一代企業信息系統研究與開發綱要》的對話中，我用不嚴格的語言表術了這個問題：

    從現實的觀點出發，邏輯層（或服務層）才是模型驅動的關鍵。就一般而論，業務模型與技術體系的松散耦合，是以邏輯服務層為中介的。所以，我得出一個結論：一套良好的服務元語義，可能是模型驅動系統的關鍵。

這里，我把計算的邏輯模型稱為邏輯服務模型，是想融合進SOA的思想（而不是技術）。所謂一套良好的服務元語義就是指一種xUML的規范。顯然，這里一個隱含的前提是，UML語言本身并不能直接作為這種規范，需要在其上擴展，尤其是融合DSL，方能構建出良好的服務元語義。

當然，這里出現了拋開UML另起爐灶的觀點。從理論上，這也是可行的。比如，Microsoft就可能這樣做。但是，這個成本太高，也只有Microsoft玩得起。事實上，模型驅動的思想很早就出現了。如今通過MDA流行起來，實際上是得益于UML的成功。拋開UML談模型驅動，明顯缺乏根基。最近UMLChina上的一個消息表明，就是財大氣粗的Mcrosoft也并不想赤裸裸地拋開UML鬧革命。所以：

在我前面的一系列隨筆中，多次提到業務本體分析的意義。實際上也是在探索拓展UML的可能方式。把“本體”概念與UML關聯，無疑很有希望開拓一個全新的領域。當然，這個難度很大。我曾經在轉帖：CYC+CRM：知識商務的未來之路 中說：

     就已有成果看，如CYC給出的知識體系，同ERP類企業建模產生的抽象業務體系，在概念的分類上有較大的交叉；盡管從理論上講融合起來是可能的，但實際上將可能是長期的過程。

不過，這個進展目前看來還不錯。DSTC提交到OMG(對象管理組織)的本體定義元模型(ODM)，就把本體和模型清晰地關聯了起來：

     面向對象模型的目的是抽象，去掉和簡化了與當前任務無關的概念和關系；而本體的目的是知識表示，不能簡化。沒有完全的本體，必須支持本體的更新和進化。面向對象模型的實例要由最終實現來創建和管理，每個實例都是事實；而知識管理則從邏輯推理出發，不必創建所有實例，并且實例只是表示看法和觀點，允許不同源的知識有沖突。

     本體和模型的關系：模型可以看作是本體在當前任務條件下的抽象和簡化。本體可以轉換為模型。

而且，ODM中的元模型體系也初步成熟：

      1、描述邏輯元模型

      2、RDF Schema元模型

      3、OWL元模型

      4、簡單公共邏輯元模型

      5、關系實體元模型

      6、Topic Maps元模型

那么，ODM是否可以作為一個有效的邏輯服務建模規范呢？還沒有定論。從現有成果來看，OWL在知識發現方面做得還不錯。從一個實用的觀點出發，也可以說，把本體引進UML，無非是以UML構建了一種融合OWL的知識發現領域的DSL而已。

三、計算無關模型或業務建模

當然，如何使UML變得可執行，這是問題的一個方面。還有一個重要的問題是，計算無關模型CIM又該如何同xUML對接呢？

我通常把CIM模型簡單地稱之業務模型，從而明確地與當前的企業建模成果關聯起來�，F有的主要從CIMS演化而來的企業建模，與UML的面向對象建模，是有較大裂縫的。當然，這種融合也已開始。如ARIS就已經有了與UML之間的關聯性成果。最近，UMLChina的一則新聞DMTF和OMG結盟用UML和XMI來打造CIM顯示，傳統企業建模紛紛加快了與UML融合的步伐。網上曾經一度有關于UML究竟適不適合業務建模的爭論，看來現在都擱置一邊了。融合是大勢所趨。

但UML如何適應業務建模其實還是一個問題。實際上，與ODM在元建模層次上融合本體與UML的做法不同，我更多的是關注通過擴展UML構建本體業務體系的可能性。也就是說，我只是在CIM模型的層面上融合本體分析的思想。

正是這種努力，我發現了問題的復雜性：從業務模型直接驅動應用，就現有技術而言，還是有困難的。所以，在關于《新一代企業信息系統研究與開發綱要》的對話中，我表達了抵達目標的通途是否已經具備的觀點：

    我降低了模型驅動的目標，這是切合MDA技術發展的。也就是說，只有把業務模型轉換為邏輯模型，才能放到技術引擎里執行。直接執行現有企業工程理論的那種業務模型的技術引擎是未來的目標。

總之， 模型驅動應用的現實愿景是，從業務建模的CIM模型到邏輯服務模型，適合采用模型交換實現對接，而從邏輯服務模型到可執行應用，則完全可以采用xUML技術實現。