MDA續篇
MDA的基本原理：
下圖顯示MDA之所以可用的原因。
(點選放大)圖中，除CIM->PIM的轉換須依賴人工技巧之外，其他模式轉換通常可借助工具來作業 (註： M2M = Model-to-Model，M2C = Model-to-Code)。對於MDA而言，模式間的轉換有重要的意涵，就是在較高抽象層次(abstraction level)作分析，也就是建構PIM，設計的抽象層次較低，程式的產生更低，從高抽象層次轉換到低層次的作業則盡可能借助自動化工具(理由已如3+1文章內所述)，例如M2M以及M2C則自動化轉換，這種不同抽象層次的作業完全符合所謂「事務分離」(separation of concern - SoC)的架構法(architectural approach)，SoC可以讓業務分析者集中在業務邏輯的分析與設計而不必考慮系統的細節，簡言之，分析者只要管好(包括發展與保養)PIM即可，為達到這種SoC，OMG因此定義不同抽象層次的觀點(view)，即CIM、PIM、PSM、與Code (OMG的MDA樣式並不包括Code)。
MDA是軟體發展的一種骨架(framework)，因此適用於你所使用的任何軟體發展方法，例如你可以用傳統的分析與設計法，或敏捷模式化(agile modeling)，或+1文章內所談的「原型樣式」(archetype patterns)來描述CIM與製作PIM，所以不用改變你所學的東西，就如Grady Booch所說的：公司要訓練MDA專家並無困難，也就是說只要懂一點UML而且仍然可保持所學，以減低訓練費用，同時，使用MDA技術尚可加速ROI。(註：最近有人提議使用OMG最近所提供的Business Process Modeling Notation (BPMN) 來描述CIM，有機會再來談談BPMN)。
MDA的主幹(backbone) - MOF：
雖然MDA主張使用UML為標準模式語言來模式化(modeling)PIM與PSM，但除UML之外，MDA仍然接受其他已存在的模式語言，只不過大家比較熱中UML，而且廠商製造的工具也都以UML為主。然十分聰明而且可喜的事情是，OMG設計了所謂"Meta Object Facility" (MOF)來例證化(instantiate)各種不同的模式語言，因此MOF成為所謂"metamodeling"的標準，我們可以說MOF就是MDA的基本骨幹。那麼，何謂MOF？MOF本身就是一種模式語言，它所例證化出來的模式本身也是一種模式，就是所謂metamodel，我們用下列表格來表示。
其中M2是M3的例證(instance)，M1與M0分別為M2與M1的例證，UML(M2)就是由MOF例證化而來的模式語言，例如我們設計的類別模式(屬M1)，如Person，或Car就是由UML(M2)所例證化產生的模式，因所設計的類別也是一種模式，所以我們說在M2的UML為metamodel，而它的源頭MOF則為metametamodel，UML的工具就是依據M2所發展，因此它能夠模式化世界上所有的物件。MOF還定義一種基於XML的模式語言交換格式(interchange format)稱為"XML Metadata Interchange(XMI)"，讓不同的模式之間可以相互交換模式資訊，因此形成metamodel之間的「互通」(interoperability)，這是MOF重要優點與漂亮的地方，例如Java/EJB與SQL可以互通(參照上述「MDA基本原理」圖)。除MOF與UML(含OCL)之外，OMG尚有與MDA有關而由MOF例證化而來的其他標準，諸如職司模式化資料倉庫的"Common Warehouse Metamodel "(CWM)，或者用於模式轉換的語言"Query, Views, and Transformation "(QVT)等，這些OMG標準我們不擬在此地詳談，因為實際應用MDA發展軟體系統時，除UML與MOF/XMI外，其他標準不會直接涉及。
模式轉換(Transformation)：
此地，我們稍微談一談模式轉換，模式轉換並不是甚麼新鮮事，例如從GUI螢幕輸入某些資訊，這些資訊模式就會被轉換成程式模式 ，不過對於MDA而言，模式間的轉換是應用MDA的重點，例如PIM-PSM-Code模式轉換就是幾乎所有MDA工具必須具備的功能。
「轉換」是一套規則，這些規則說明，在某模式內的元素(elements)如何轉成另外模式內的元素，當要轉換時可能會輸入某些資訊 (但並非絕對必要)，稱為「記號」(mark)，這些記號不得「汙染」原模式，例如PIM根據所謂「技術樣式」(technology pattern) 轉成在EJB平台的PSM，PSM再借助「實作樣式」(implementation pattern) 轉成程式，這些樣式內就有轉換規則與記號。PIM-PSM-Code的自動化轉換範例因受限部落格篇幅還是請讀者參閱：http://jses.seat.org.tw/index.php/jses/article/view/34/22 。
MDA宣言(the MDA Manifesto)：
基本上，MDA的基礎包括三項思維。
- 直接表達(Direct representation)：將軟體發展者集中於技術範疇 (如EJB或.NET等)方式，轉向注意問題範疇，但要減低問題範疇與表達方式間的語意間隔(semantic distance)，這是MDA的要務之一，不過如何做到？光靠UML與OCL似乎不能完整描述模式，因此可使用「特殊範疇語言」(domain-specific language - DSL)或UML Profile。
- 自動化(Automation)：應用概念的直接表達固然可以抓住發展者的想法，但是如果要以人工將模式轉換成程式則不旦廢時而且易錯，因此MDA工具的使用可以解決這種問題，我在MDA 3+1篇文章內一直強調，自動化模式轉換有諸多好處，此外，自動化不但可以直接執行模式，也可以扮演範疇與實作間的橋樑，當然要模式自動化轉換必須借助工具。
- 開放式標準(Open standards)：工業標準不旦能達到重用的目的，同時也可鼓勵廠商生產不同需要的工具，標準的產生表示工業的成熟度，MDA所接受的標準主要是UML以及MOF模式語言，這些標準經多年經驗證明可用在各種情況與範疇，除此之外，尚有其他開放性的OMG標準如CWM或QVT等，以及一些私有標準如EJB或.NET。
MDA是否已成熟：
MDA是否已成熟，我認為沒有確切的答案，這要看從甚麼角度來看，如果說由可使用度來看，MDA的確已算成熟，至少接近成熟，因為有很多的專案是用MDA技術在發展，諸位可以進入OMG的網站看看使用MDA技術成功的例子(http://www/omg.org/mda/products_success)，最近Michael Guttman/John Parodi出了一本書：Real-Life MDA，其中提供6種使用MDA發展系統的實際範例，關心MDA是否可用的人士或許可參考。不過MDA不能算是完全成熟，因為尚有一些問題待解，例如如何直接表達問題範疇以減少問題範疇與表達間的語意間隔，如MDA宣言所談的Direct Representation的問題尚待解決。又如模式間的轉換問題，也就是MDA宣言的第二項：自動化，雖然OMG設計有QVT為標準，但是廠商製作的工具也尚未一致使用。
有一項值得注意但尚在發展中的轉換問題就是BPMN->UML->PIM的轉換。與MDA幾乎同時提出的另一種標準BPMN，其工具可以用來描述業務處理流程(CIM)，這些BPMN工具產生的資訊，應可以傳遞給UML工具以創造PIM，這種轉換相當複雜，我認為如果這種轉換問題可以解決，CIM->PIM->PSM->Code的模式轉換就可一路自動化，我看MDA在實用上就可算成熟。
結語(Epilogue)：
這一篇MDA續篇可能比較嚴肅而且「無趣」，不過或可提供對MDA關心的讀者參考，以前刊載的三篇漫談文章(漫談「模式驅動架構」(一)、(二)、(三) )，漫談了一些MDA的由來、MDA的模式化、MDA如何與敏捷「掛勾」、以及如何快速發展與技術無關的PIM，但這一篇續篇我們談了很重要的MDA骨幹 - MOF以及模式間的轉換，我想我已經初步談完MDA的本質，有興趣的讀者從這些本質也許對MDA應有初步的概念，讀者如對續篇以及3+1輕鬆談文章如有疑慮，勞駕使用「意見」欄，本人將盡其所能回應。
[例] 下圖表示我使用MDA工具 (OptimalJ)的示意例子，我們可以找一個或多個主要「關鍵抽象」(key abstractions)開始，如類別Customer，以「反覆與漸增」(iterative and incremental)方法完成如訂貨處理系統 (Order Processing System) (請參照2007年3月份的JSES 3-12頁的文章)。
「註」：(1)上圖顯示反覆與漸進發展流程，依個人經驗，用MDA技術以這種流程發展軟體系統，不但迅速而且可減少錯誤。(2)所謂「關鍵抽象」是一種屬於與問題範疇相關的字彙(vocabulary)的類別或物件，始於Grady Booch。
過去曾survey 過MDA這樣的技術，但我的想像只能到 M2 (metamodel)這一層，完全無法理解 M3這一層（metametamodel）。可以舉一個例子嗎？(m0->m1->m2->4) example: (張山->People->Class->X)。X 是什麼？
回覆刪除也就是說，在 m3 中的 class 與在 m2 的 classes 有什麼不同？（參考文中的表）
當我們要設計一種程式語言，我們大多使用Backus Naur Form(BNF)來定義該語言的語法(syntax)，但是BNF只能定義文字程式語言，如果是模式語言則如何來定義，因為模式語言如UML是一種圖形語法(graphical syntax)，因此在MDA中我們須要與BNF不同的機制來定義這種語言，這種機制稱為metamodeling。因為模式化語言並不只有UML，還可以有其他形式的語言，要產生各種模式語言，其源頭必須抽象化，例如許多Concrete Classes繼承自一個Abstract Class一樣，因此OMG設計一種MOF的骨架(framework)，這種骨架有四種層次，比方說，「Mr.Huang是資工系學生」，這是一種資料，是MOF framework的M0層次，但是Mr.Huang是Student之一，Student就是一種Model，但Student代表許多人，如Mr.Lee, Mr.Wang等等，因此Student就比Mr.Huang等抽象些，在MOF framework中屬於M1層次，以UML的語言來講Student是一種類別，也是這些Mrs.的template，再說世界上也不只有Student類別，尚有其他類別如Car, Account, ...等等，因此我們必須有一種超越個別類別的語言來描述這些使用者定義的類別，這就是UML的Class(當然UML還有其他語言如Attribute, Dependency,...)，其抽象層次又高一層，所以稱UML為metamodel(meta有超越之意)，但是用來modeling世界上各種物件的也不只UML，只不過它比較眾所喜愛的模式語言而已，也可以有其他語言，產生這些模式語言的源頭本身也是一種模式語言，就是M3層次稱為MOF，因OMG並無設計特別的MOF模式言，因此就借用UML的語法，所以MOF也有class, attributes, generalization, associations, operations,...但是這些比UML的class,...抽象層次更高，因四個層次的MOF framework已夠用來模式化世界上的物件，所以用不着設計第5層次，因此我們說M3為meta-meta-model，而用不着有meta-meta-meta-model，MOF本身就是"is based on"自己，而其他層次是由上一層次例證化而成(instantiate)。
回覆刪除至於說M3中的class與在M2的class有何不同？我在前面已說過，M3的classes,attributes,...只是借用UML(M2)的語法，但抽象層次更高，因此M2的class是由M3的class例證化而來，不過UML比MOF包含更廣，例如MOF中並無use cases。
謝謝。有點瞭解了。也就是說MOF提供了讓別人定義 metamodel 的機制。感覺起來野心真的不小，也感受到他細膩的部分。
回覆刪除關於黃教授所發表的MDA文章中所述:讀者反應卻十分冷淡, 其實不是反應冷淡問題, 而是一位實務工作者很難去體會MDA與自己工作的切身連結, 我自己一直是系統分析方法的研究及實務工作者, 對MDA也從實務的觀點去深入的思考過, 也試著建立一些可有效執行PIM to PSM, PSM to Code的UML Profile 及模型轉換規則, 也有了好的效果, 最近也將之寫成文章投到 SCI 期刊去, 所以我個人認為要能實現 MDA 是需要從 Model 的建構開始便需要有一套屬於領域的UML Profile及轉換對映機制才有機會, 所以要談 MDA 可能需要從 UML Profile 及轉換規則的建立談起。
回覆刪除但是要建立一個大型系統的MDA其實是不容易的, 我從實務工作中得到了一個小的經驗, 若能降低Model的複雜度將有利於MDA的實現, 而如何降低Model的複雜度, 個人認為建立個別系統領域的開發框架(framework), 將資料處理及流程控制抽出封裝到開發框架中,可以有效的減少應用程式的複雜度, 進而降低模型的複雜度, 有效的實現 MDA。
目前的UML無法完全模式化軟體系統，因此設計所謂"First-Class Extension Mechanism"在metamodel層次的UML Profile，UML Profile是由UML tailor而使用在特殊領域的語言，因此有人說UML並非語言，而是各種語言的家族，這無關重要，UML Profile依OMG提供可用在PIM與PSM，EAI，EDOC，...等等，當然自己也可以依需要自行擬定，例如在原型樣式快速發展一文中，因需要擬定了一個profile，在MDA宣
回覆刪除言第一項中，我提到用UML Profile來創造完整的PIM(當然最好是DSL)。PIM事實上是比一般OO的分析模式更嚴格而完整的分析模式，如果是設計模式就違反SoC原則而不易保養，所以我說發展者只要管好PIM的發展就好，這句話是有點大而化之，但依MDA宣言第二項：Automation是有點道理。
至於PIM-PSM-Code的模式轉換問題，雖然可自行發展轉換規則，但從實務的角度來看，並不實際(當然研究寫論文則另當別論)，所以我比較傾向使用MDA工具，當然自行發展規則一樣可以自動化模式轉換，如果進入OMG使用MDA成功的範例的網頁，就可以發現所有公司都使用工具，例如E-SoftSys說，他們使用MDA工具提昇40%生產力。
至於羅老師說開發特殊領域的框架可以降低model的複雜度，我十分認同，本來框架不但可降低複雜度而且提昇重用度，但是開發系統領域的框架，並非只為MDA，使用其他方法發展軟體，框架一樣有用，不過如使用MDA技術發展系統，其主要是要創造PIM，因此框架是用來方便創造PIM，例如，我在『利用「原型樣式」快速發展軟體』一文所提的「原型樣式」就是可用來創造PIM的框架。
正如羅老師所提，要建立一個大型系統的MDA的確不容易，但這不是MDA的「原罪」，而是在如何創造適當的PIM上面，PIM是由CIM而來，CIM-PIM的建立是OO的問題，只要PIM確定，其他模式的轉換就可自動化，羅老師的經驗，認為model很複雜，降低它有利於MDA的實現，是沒錯，為何我們不考慮建立model的方法，例如所謂Agile Modeling的技術似乎可減低建立模式的困難度與複雜度。
黃教授所言, 考慮model的建立方法來降低model的複雜度, 的確是所有model建構者應深思的, Agile Modeling 的技術是值得我們去探討的, 尤其在台灣的軟體專案中, 似乎不曾有過專案預算或時程可以容許我們去建構複雜又龐大的系統模型。
回覆刪除