下面談一點關於MDA的感受。
1. PIM-PSM-CODE
這是MDA眼中最MDA的軟件開發方法，也有工具如OptimalJ實現了這種範式，當初在成立mdachina.net的時候，這個工具被俺之輩如視MDA之珍寶，俺則是把它的文檔全看了，例子也做了一些。以爲自此可以draw & run with a true MDA tool，可是事實並非如此。
OptimalJ對於PIM和PSM同步做的不好，幾個PIM->PSM，PSM->PIM來回下來，建模者估計會對OptimalJ的模型同步邏輯（通過某種標記表示模型的是否可更新…）暈倒。
OptimalJ對於CODE模型缺乏更邏輯的分離機制。在CODE保護塊中編程而不是利用語言分離機制（如類繼承，import之類），將導致很難管理機制與手工代碼的邏輯邊界，增加了代碼的混亂。也許除了用不同顏色區分手工代碼與機制代碼之外，還要加上另一層UI（模型）表示這種區別？，明明PIM，PSM清楚地表示了業務模型和技術模型，到了CODE模型，基本上是另外一回事了（因爲PIM和PSM具有廣譜效應：一個模型映射爲多個代碼段），可是要在CODE模型中增加手工代碼，除了保護段外沒有更好的、更邏輯的方法，則是很令人失望的。
當然不只是OptimalJ纔有這種問題，其它號稱true MDA工具的，也有類似的問題。這裏不一一表來。
2. 仍是重複工作
當前MDA的主流還在與3GL做相同的工作，類描述，代碼生成，粒度太小，做個小應用還累的半死：安全，集羣、cache等等還要手工編碼（設計就沒圖了）。因爲幾乎所有的MDA工具都有一個底層假設的邊界：OptimalJ/ArchStyler只做了常用J2EE的建模和自動生成，androMDA要好一點，除了常用J2EE還有一些輕量級框架，而那種像VE，xtUML則只能在更小的範圍內可以自動化。事實上，一旦需要超出MDA工具的底層假設邊界，則一切得自已實現：code，modeling, metamodeling, code generator design（CMMC）。然後再是模型集成，這不是一件容易的事，似乎MDA、MDD之類的方法學，強烈地依賴於開發團隊有自治建模/元建模的能力，在現在這種快速delive系統的時代，誰有時間做metamodeling，除了俺這種沒事找事的人。
3.關於複用
的確，在MDA上下文中，模型（設計）複用變的更加真實，就是除了設計圖紙的交流以外，還要在建模工具、代碼生成器層面上做到複用的保證。IP之父也說過類似的話：複用DSL和產生器比複用結果組件好的多。可是若結果組件與模型沒有太大差別（就像當前PIM這種低級抽象），或者結果組件具有高度的可配置性（如EJB、Spring Bean的XML配置），那麼DSL和產生器複用與高度可配置的組件複用並沒有本質差別，前者更增加了開發費用。
奇怪的是，至今在MDA環境下，大家還在研究UML類圖、狀態圖、對象圖之類的語言級別的模型語義。對於含有領域級別的豐富語義的模型，很少見到公開發表。幸好有一個MDA學者做了這方面的初期工作，在那裏我們可以看到應用商業構架型技術構造的領域模型，如：CRM應用的模型（money，order，person等一套可複用的類）。可是，這方面的工作還少的可憐，試想我們做系統時，有多少次在使用money, order，person概念，有多少次在重複地爲money, order，person建模？，從這個角度講，領域模型庫確實有用。但是領域模型庫要到真正的結果組件，按MDA的走法，同樣存在PIM-PSM-CODE的問題，還有不同的建模工具所導出的模型版本問題、UMLCASE工具依賴的問題。這個痛苦的現實使得領域模型庫更多是做爲信息交流而不是drive MDA機器。
4.關於豐富的應用
從當前MDA實踐來看，除了一些trivial的系統可以快速開發以外，大的、另類的系統基本上是沒有公開發表過。我們不能憑一兩個（或是多個）成功的trivial應用（petstore，cafeshop）就有足夠的勇氣說：任何系統都可以用MDA方式解決。前面已說了，一旦需求超出MDA工具所能提供的邊界，你將走上：(CMMC)的不歸路，雖然有：GME(Generic Metmodling Environment)，EMF，之類的元建模工具，這些工具的邏輯其實不容易把握，除了在“元”字鬧鬼以外，基本上與應用域無關，或者只是trivial地表示一個應用域的概念和工具內實例化（而不是代碼生成，這些工具都假設你可以很好地做代碼生成工作），其它事情，you must CMMC。
於是，俺最初幻想有這麼一個工具具備強大的元級能力（像smalltalk這種具有真反射能力的語言、工具和環境，像objecteeringUML內置的模型操縱語言和強大的uml profile與插件綁定），可以實現CMMC的複雜工作，現實情況是它們仍然只是一種元建模的枷鎖，元建模真的要這樣做嗎。
5.關於元建模
元建模一直被認爲是MDA的高階應用，動不動就要MOF重型擴展來解決領域建模的問題，其實在俺看來：重型擴展基本沒有必要，而且導致模型重複，試想重型擴展是不是還要再建一遍類似的MOF::Class,MOF::Attribute,MOF::Association概念？，UML profile比MOF重型擴展更好，因爲UML profile不需要重複設計MOF/UML結構。
6.關於LOP，GP，MDD
MDA的路一旦走的不順，什麼變種的方法都來了，LOP（Language-Oriented Programming），GP（Generative Programming），MDD（Model-Driven Development），MDSD（Model-Driven Software Development），它們或多或少地採用了翻譯範式：由高層抽象到底層實現，以更靈活的領域概念表示手段。現在看來，沒有具體領域的涉及和積累，這些工具或方法只能是說教。原文：http://www.cnblogs.com/xiterator/archive/2006/03/07/344786.html
