英文原文：Model Driven Development Misperceptions and Challenges

　　多年以來，采用模型驅動開發（MDD）的水平似乎仍沒預期的那么好。阻礙、限制MDD使用的因素有很多，例如對實際的MDD成功案例缺乏認知、不確定如何在平常使用MDD、缺少預先投資的撥款模式、或是沒有戰略舉措的重點。

　　如果你過去嘗試過MDD，那你很可能遇到了一些挫折，導致你現在不再用它。也或許你正在嘗試采用MDD，而又面臨著一些挑戰和阻礙。無論你遇到上述哪種情況，本文都對你有所幫助。我們會在本文中看一看與采用MDD相關的挑戰和誤解[1]。

　　建模早已證明了它在改善溝通、促進業務編排、提升質量、提高生產率上的價值。它的使用范圍很廣，分析、設計和開發都會有所涉及?？紤]到這一點，我們就來看看有關MDD的諸多誤解和挑戰，我們又該怎樣利用現代方法和相關工具集解決這些問題。

　　1 - 挑戰：方法不當且不可用

　　過去，MDD的一個關鍵抑制因素是人們實施活動的時候沒有現成的MDD最佳實踐。比如說，人們在閱讀有關如何執行特定任務（諸如設計高可用的解決方案）的過程文檔時，文檔里并沒有任何MDD的內容。為了得到MDD實踐，人們不得不到論文或書本里去找，然后再應用到現有的非MDD文檔上。

　　如今，MDD從業者在進行日常工作時，可用的MDD指南已經越來越多，而且那些信息嵌在他們每天使用的工具中。我們先看看開發過程，它包括利用MDD原則的“工具向導”最佳實踐，這些“工具向導”隸屬于整個方法和過程。

　　特定任務的指南（例如需求評審、設計用戶接口或設計高可用的解決方案）現在都包含指向MDD內容的鏈接。比如推薦設計模式、提供設計中應用模式的指南、利用現成工具中的模式實現。

　　以前還有另一個阻礙因素，就是MDD與特定開發方法過度摻雜，人們無法提取MDD最佳實踐，并將其應用到不同的場景中。一個典型的例子就是面向對象分析和設計（OOAD）中存在大量工具，你要么采用全部的OOAD內容，將其作為從MDD受益的一部分內容，要么就完全拋棄OOAD。MDD的最佳實踐曾是OOAD框架的一部分，但人們并不知道如何在框架之外利用這些最佳實踐。抽取出MDD的內容并將其應用到不同的場景中是不可能的。

　　這些因素再加上其他一些原因導致企業很難在它們的環境里采用最佳實踐（包括MDD最佳實踐）。公司已經有了合適的過程和方法，而給這些方法添加MDD方面的內容卻很困難。

　　為了在組織和特定類型的項目中采用MDD，業界在裁剪特定開發過程方面已經做得越來越好。比如有的研討會旨在指導團隊完成定制的開發過程，這通常被稱作“方法采用研討會”。研討會的目的是針對特定項目裁剪現有的方法內容，它通常會涉及以下人員：過程工程師（管理組織開發過程的人）、首席架構師、開發人員組長和項目經理。

　　支持定制后，方法工具浮出水面，比如Rational Method Composer和Eclipse Process Framework Composer，它們包含定制的最佳實踐庫。這些工具的思想是整理、打包最佳實踐，用工具為組織裁剪并采用這些最佳實踐。在工具中，你選擇想要采用的某些方法元素，對它們進行修改、編輯，并將其組織成希望關注的過程。然后將該過程以可讀格式（例如HTML）在組織內發布，供從業者在日常工作中遵循。

　　盡管使用上述工具和方法的可用指南有很多，但仍然要求用戶找到、理解并遵照指南?？缭竭@一障礙的措施是，除了在工具里提供指南之外，還要將方案的全面自動化。舉例來說，你能在使用基于Eclipse的產品時利用備忘單（Cheat Sheets）。備忘單提供完成任務的步驟指南，并能自動化工作流里的步驟。

　　下一節我們會討論關于模式實現的機制。不管選用什么方法，要點都是獲取越來越多的指南，并將其落實到工具中，從而更好地指導用戶充分利用模型。

　　正如軟件解決方案可能會過度工程化一樣，創建指南也會發生同樣的問題。克服這個挑戰的最后一點是要務實、主動。計算出構建方案所需步驟的全部細節，無論從價值來說還是從時間來說都沒有什么意義。那關鍵的步驟是什么呢？他們如何與團隊的技術相結合？在文檔化步驟上投入時間的意義何在？相對于自動化，在創建靜態文檔上又該投入多少呢？

　　過程，尤其是MDD，都不是放之四海而皆準的，這將在“4-誤解”中討論。

　　2 - 挑戰：基礎設施和工具不能從MDD獲益

　　近幾年，我們看到建模工具已不局限于對特定圖形符號（比如UML）的支持了，經過發展，它已然能幫助從業者完成工作。這些工具不僅支持圖形建模符號，也內置了MDD特性，這些特性有利于：

• 業務編排：業務編排是SOA等成功方法的關鍵方面。通過使用MDD模型、自動化、以及與之關聯的“追蹤”，你能記錄決策的原因，跟蹤滿足業務需求的所有方式。另外，我們可以研究利用MDD的特定版本，比如業務驅動開發（BDD）。顧名思義，BDD關注的是業務建模。你可以在這種情況下進行建模，也可以在某些情況下模擬組成業務的流程。
• 高質量：由于實踐內建在工具中，并進行了自動化處理，因此出錯的幾率非常小，甚至不會出錯。
• 增強的一致性和治理：由于工具支持指南和最佳實踐的自動化，所以提高了解決方案中元素的一致性。另外，工具也能確保構建的元素是固定的，并與需求和最佳實踐保持一致。
• 提高的生產率：重復、耗時的工作現在都自動化了。從業者可以“復用”，把時間花在最緊要的事情上（比如業務邏輯）。依賴自動構建，用戶群的復雜度和自動化要么可以在當前項目中實現，要么可以分散在多個項目中實現。
• 改善的溝通：使用模型、工具和自動化，從業者（例如架構師）能針對不同的受眾創建不同的視圖。
• 影響分析：MDD的可追蹤性能讓你分析出需求變更對解決方案造成的影響，反之亦然。

　　讓我們以設計模式為例，來說明工具如何給MDD帶來了活力。假設某本書中描述了設計模式，我們將其稱為模式規范。該規范非常有用。它描述了模式的使用時機、模式的特征，以及使用模式的好處和意義。模式規范能幫助人們理解模式并做出恰當的選擇。但模式規范并不能確保設計的高質量和生產率的提高。為了從中受益，你必須將這些模式“自動化”。我們將其稱為模式實現，也就是模式規范在工具中的可復用編輯。使用模式實現，設計者可以將模式快速應用到他們的設計中，也能確保這些應用準確無誤。

　　領域獨立的工具不太可能內置領域所需的所有MDD工件。工具除了提供開箱即用的MDD工件外（比如一組設計模式實現），也允許你擴展現有的工件、創建自己的工件?，F在的工具包含“擴展框架”，以及最佳實踐、模板和API。Rational Software Architect之類的工具還允許你構建適用于領域的MDD工件（例如模式實現、規則、約束等）。

　　既然你能構建這些MDD工件，那么基于資產的開發（ABD）就能讓你與他人共享工件、提升復用的實踐和基礎設施。換句話說，ABD最佳實踐和基礎設施的改進支撐了MDD的采用進程。諸如Rational Asset Manager的可復用資產庫能讓你管理可復用的軟件工件，讓開發社區共享和復用工件。試想一個為領域創建的模式實現，你現在可以把它提交到資產庫中，該模式經過評審和認可，社區中的其他從業者就可以復用它了。作為這個生態系統的一部分，你可以監控資產被復用的時機和方式，收集反饋信息并確保整個團隊在使用合適資產的正確版本。

　　我們重新回到務實和實用上來。在對用戶和用戶所在組織有意義的情況下，ABD及復用倡議才需要被采用。你需要識別出你的成熟度級別，并采用支持該級別的工具和過程。通過事先思考和計劃，你可以隨需確定、推廣ABD計劃，避免不必要的開銷和成本。

　　3 - 誤解：MDD==UML？

　　有一個誤解是MDD意味著你必須使用統一建模語言（UML）——現狀如此，完全是因為來自對象管理組織（OMG）的UML規范進行了這樣的描述。消除這一誤解的方法有很多。

　　打消這種念頭的第一種方法是用MDD的方法工作，這只需要你在執行任務時把模型作為關鍵的工件使用，并使用利用這些模型的自動化機制。在這種情況下，模型是用語言簡化了的現實，而這些語言具有定義良好的語法和語義。因此，可以在MDD中使用的語言有很多，而不僅僅是UML。 

　　在大多數情況下，我們確實要為手頭上的任務選擇合適的工具。如果我們的MDD需要標準化、為人熟知、被廣泛支持的語言，那UML就是一個不錯的選擇。UML也是可擴展的。嚴格來說，它能通過配置（提供定制的元素、屬性和約束）進行定制。這能讓UML對所作的工作來說變得具體，也能讓語言更加易學易用。增強建模語言可用性或針對性的另一種方式是創建你自己的領域特定語言（DSL）。

　　要記住的是，我們受益于使用的語言和創建的模型。為了指導投資，我們要權衡以下問題：

• 是否能有效地設計和理解解空間？
• 能否輕松地和其他人溝通？
• 是否能基于已經創建好的模型生成方案的其他部分？
• 能否有效利用開發生命期之外的結果？
• 是否能從實現追溯到設計？甚至需求？

　　4 - 誤解：MDD放之四海而皆準

　　根據前面的誤解可以看出，MDD顯然不是放之四海而皆準的解決方法，任何非預設的生產線工具集都可以用來構建產品。MDD就是用模型為特定情況增加價值，它適用于特定領域，跟你所開發的軟件類型也是配套的。因此，我們能在自己的場景中看到很多使用MDD、有意義的方式。

　　其中一個例子是，我們可以和傳統的面向對象分析和設計（OOAD）一起使用MDD。在審視OOAD和MDD的時候，往往會發現使用了很多模型，比如用例、分析、設計和實現。有很多現成的例子和文檔演示了如何使用這些模型來完成方案。但這并不意味著你必須用上所有的模型。關鍵是我們要有效地利用抽象。抽象的層次取決于所處的場景、使用的語言、相關的約束、規則和假設，以及可能實施的自動化。

　　除了在模型數量（和相關的抽象層次）上務實之外，也要切合實際地選擇模型中用于交流的圖表。比如說，如果使用UML作為建模語言，就沒必要使用所有可用的圖表類型（類圖、交互圖……）。語言中有一系列圖表可供選擇，一般用途的建模語言能為各種需求提供服務就可以了。在特定情形下，對于你試圖完成的工作來說，只選擇那些能為其增加價值、有助于溝通的圖表才是有意義的。至于完整性，我們可以進行進一步的討論，要注意的是，即使在一個圖表中，你也不必使用所有可用的模型元素。

　　5-誤解：圖表就是模型

　　MDD中關鍵的一點是要認識到我們在創建模型——正如前面所討論的，模型是用語言簡化現實，該語言要具有良好定義的語法和語義。我們在模型中可以發現大量模型元素和一組圖表。每種圖表都提供了模型元素之上的一個視圖。每個模型元素屬于零或多個圖表。我們要關注模型元素——它們是什么？有哪些關系？有什么屬性？我們通常使用圖表來幫助我們理清這些問題。此外，我們還將圖表作為和其他人溝通的方式。但模型的關鍵信息存在于模型元素中——因為這能讓我們生成所需的視圖、創建所需的圖表，從模型生成其他元素。如果MDD只是圖表，那工具能畫出漂亮的圖片就能滿足我們的需求了。這并不是說圖表（和支持圖表的工具）不重要。創建模型和圖表的工具需要進行調整，以適合目標受眾。

　　結合有選擇性地使用圖表，我們還能利用視角讓模型更加可用、更加利于溝通。視角是組織模型的一種方式，以便模型的某些方面可以提供額外的圖表，使模型面向各種各樣的受眾。透視圖通常只包含圖表，而沒有額外的語義元素。嚴格來說，在你更新語義元素時，透視圖會自動保持同步。使用透視圖可以讓你與其他角色和小組有效溝通，從而為MDD增加價值。每個小組都想理解方案中的一部分內容，也就是與他們的需求相關的那部分。在不打亂模型、不構建獨立模型、或是不在維護同一元素的多個版本上浪費時間的情況下，透視圖可以支持這些需求。請記住，我的意思并不是讓你支持所有不同的小組，并創建龐大的一組透視圖。再次強調一下，關鍵是要務實，要創建有意義、能帶來價值的圖表與視角。

　　6 - 誤解：代碼就是模型，模型就是代碼

　　以前對MDD的誤解之一就是它只能應用于代碼。MDD基本上被局限在一個較低的抽象層次，因此它的影響也很有限。很多人只用MDD工具“可視化”代碼（也就是將代碼圖形化的逆向轉換）。這樣是有好處的，比如說，更好地理解大段代碼，以及組件或類之間的關系。但撇開這些來說，代碼可視化并不能獲得先前討論的那些MDD優勢（比如業務編排、改善質量、提高生產率或影響分析），因為它所作的一切也就是讓你以圖形化的方式查看代碼而已。這是基本、初級的圖形使用方法，和預期的一樣，它的投資低，收益也低。

　　再復雜一點兒，在代碼可視化之后，讓可視化結果和預期的設計保持一致。例如設計師或架構師想評審開發團隊開發的代碼，代碼的可視化視圖就能讓他們對代碼和設計進行比較，因為可視化結果和設計使用了相同的可視化技術（比如UML類）。不過，盡管可視化結果和設計用相同的語言表示，但兩者之間仍然有很大差距，因為它們所處的抽象層次不同。MDD工具憑借可視化、可追蹤性、分析和發現功能、重構支持能幫助設計師完成工作。一旦標注出設計和代碼之間有分歧的地方，人工干預就必不可少了，設計師就要和開發團隊進行溝通。這能提升價值，但仍然無法完全擁有MDD的優勢。為了支持分析和溝通，需要增加時間和精力，而且每個項目都需要投入多次。

　　MDD應該適用于任何層次的抽象，并有助于不同層次之間的連通。你應該在較高層次的抽象上進行建模。以分析模型為例（像系統的用例模型），它是設計模型的輸入。分析模型中的有些元素可以在設計中予以利用。比如說，功能域信息分類（包）和用例可以用來創建設計模型中交互圖的基礎模板，用例會在設計模型中實現。利用工具及其擴展性，你可以修改“分析到設計”的轉換過程，接著讓組織內的成員在質量和生產率上獲益。

　　MDD適用于所有層次的抽象，而抽象的層次是無窮盡的。要為領域和組織選擇有意義的抽象層次。例如，在SOA中，可以在開發方案時采用以下的抽象層次[2]：

• 業務：該層次對業務策劃師、業務分析師或產品所有者來說是有意義的。在這個層次上，模型元素是業務目標、關鍵性能指標、業務方針和功能域之類的內容。
• 分析：分析和設計通常要一起看，分析模型的元素有時會演進為設計元素。在SOA里，考慮分析是很重要的，因為分析是支持業務元素的技術模型元素的起點。
• 設計[3]：SOA方案中，大多數在架構上重要的元素都是在這個層次建模的。設計時要用文檔記錄架構的關鍵元素，以及它們的實現方法。
• 實現：實現是“代碼”層次的抽象。在該層中，你可以用MDD基于設計生成代碼存根，并在需要的時候讓代碼和設計保持一致。

　　另一方面會出現這樣的情況：人們熱衷于模型和MDD，甚至僅僅為了建模而建模，卻忘了把模型轉換成可操作或可執行的內容。架構師可以和利益相關者、設計者和開發人員溝通，但你仍然不能完全受益于MDD。在你策劃MDD的策略和方法時，要思考一下如何利用模型。譬如，部署方案最終用什么平臺？如何提高代碼質量和開發人員的生產率？是否能將模型轉換成代碼存根？

　　另外，模型所包含的有用設計信息要多于生成代碼所需的信息，所以我們還要看看其它方式，來利用這些已捕獲的重要而有價值的信息。這包括文檔的生成、測試用例、部署腳本等，這樣就能顯著提高項目的整體生產率。眾所周知，實際的代碼編寫只是整個項目的一部分工作而已。

　　沒有什么銀彈。所需的代碼并非都能自動生成（除非你的領域非常?。?。最后，你必須處理模型和代碼，MDD則會指導你利用模型、保持代碼與模型之間的同步。

　　不過雙向工程怎么樣呢？如何利用自動化保持不同抽象層次之間的模型同步呢？這也是一般方案中較為棘手的問題。例如，從較高層次的模型向較低層次的模型轉換時，許多元素會展開——一個元素會在較低層次上演化出多個元素。一旦創建了較高層次的模型，用戶就可以更新、移除、添加較低層次上的模型元素。那又該如何映射回較高層次的模型去呢？若干組詳細的元素又怎樣轉換/映射到少量的高層次元素呢？面臨這樣的挑戰，就很有必要想清楚，追求的這種方法到底是不是開發方法的一部分。

　　由于修改極可能在代碼級別發生，所以若沒有保持模型和代碼一致的方法，模型很快就只剩文檔了。最近，Rational Software Architect之類的工具在“保持一致”方面有了很大的改進，提供了可視化代碼、比較和合并的功能。請注意，用于協調這些變化的方法比工具化的能力更為重要，這和治理也是相關的。舉例來說，架構師看到了代碼和模型之間的差異，怎么辦呢？去和開發人員討論？讓開發人員修改代碼？還是架構師修改模型？正如你所看到的，這些都不是完全自動化的方法。

　　已經取得巨大成功的另一個方式是預先在工具化上投資（要么購買要么定制），通過約束、規則和假設減小問題空間。對問題空間所能做的限制越多，生成高比例解決方案、減少抽象層次、消除雙向工程需求的可能性就越大。在這種情況下，今后的關注點只需放在工程上。

　　7-挑戰：平臺無關性面臨挑戰

　　雖然不確定平臺無關性發生的時間或原因，但是在高層次上進行建模、然后生成解決方案的想法已經引起了廣泛關注?；蛟S平臺無關性來自于MDA的平臺無關模型，也或許來自其它地方。不管來源如何，都要認識到很難從很高層次的內容進行延展，也很難將一種表示定位到許多不同類型的實現上去。已經有一些解決方案能讓用戶利用模型生成全部的結果代碼了。但在那些情況下，也正如前面小節中所討論的，工具化對領域來說很有針對性，而且利用了一組約束、規則和假設才使轉變成為可能。解決方案空間比較狹小，這樣才為生成高層次的內容提供了可能性。隨著解決方案空間的擴展，生成會變得越來越困難。

　　就連遷移到DSL上也會提出這樣的問題：使用相同的模型作為輸入，生成不同的底層實現有多容易。在利用DSL的時候，關鍵應該是具體的領域和當前的項目。正如從許多敏捷過程中（以及自己的經驗）學到的，過度工程化、計算每種可能性都要付出代價。這同樣適用于建模和使用的語言。針對具體領域并不一定就是什么壞事，事實上它反而是最佳利益。不過，創建一個領域特定的解決方案，再大范圍地加以應用是不切實際的。

　　8 - 挑戰：保持編碼人員的創造力

　　在我們轉向MDD，期望簡化設計表達、改善溝通、生成部分解決方案的時候，我們還需要認識到這會對團隊產生影響。有些團隊成員可能喜歡在較低的抽象層次工作；他們也許會在場景建模時覺得拘束，反而在努力實現解決方案的時候感到自如。這些擔心并非都是合理的，但還是要聽出“弦外之音”。我們需要保證每個團隊成員都能發揮最大的作用。

　　即使在處理模型的時候，我們也需要底層實現的相關專業知識。應該使用什么框架？這些框架如何整合？下面以模式為例進行說明。構建模式實現的關鍵輸入是參考解決方案，也就是樣例，它用來決定模式實現應該做什么以及怎么做。如果我們要構建自己的模式實現，那誰來構建樣例？誰來判定該樣例是不是解決問題的最佳方式？既然期望能簡化建模體驗，那又由誰來給出規則、假設和約束呢？又該怎樣把它們編輯到人人都要用的工具中呢？這些問題都強調，有很多地方都需要專業知識、創造性、以及解決問題的技巧。MDD策劃、啟動時有一點非常重要，那就是與團隊成員溝通這些挑戰，并確保每個成員都能以有建設性、有效率的方式為項目效力。反思一下過去的項目，真正創新的工作花費了多少時間？而機械、乏味、重復的任務又占用了多少時間？

　　9 - 挑戰：沒有可利用的內容

　　和其它相對比較新的方法一樣，在最佳實踐被充分理解和基礎設施就位之前，產出的內容都很有限?，F在MDD在軟件行業越來越成熟，有了越來越多的推進力，可以看到，高質量的MDD內容和資產也越來越多。讓這些內容從一開始就可用，對采用MDD來說是至關重要的。

　　面對有挑戰性的業務問題，僅有工具和基礎設施還不足以交付解決這些問題的軟件。最終解決問題的往往都不是工具，而是使用工具的人[4]。如果希望大家使用工具，那么最初就有工具的話，情況就會有很大不同。你是否曾經面對過一塊白板、一張紙或IDE工作空間？如果你一開始就有參考或模板，或者有內容指導、組織你的方法，豈不是更容易一些？

　　這里討論的MDD內容不僅僅是設計模式或UML項目模板。我們所說的內容是指行業或方案的參考架構（比如呼叫中心參考架構或銀行參考架構）、作為可執行模型的行業標準集（比如保險業的ACORD或電信行業的SID）或實現存根的模板大全。這類資產的一個成功案例就是WebSphere Business Services Fabric（WBSF）的行業內容包（ICPs）。WBSF框架由運行時和相關工具組成。ICPs為特定行業（領域）提供了可定制的內容，從而成為框架的有益補充。這些內容包括不同抽象層次（比如業務、設計和實現）上的模型和模板，它們遵循行業標準，由組織加以裁剪和采用。

　　這些資產的核心價值在于提供了更多的業務價值，而且更接近組織的戰略。換句話說，業務能看到它們會影響損益底線。如果我們比較可復用設計模式的價值和行業框架的價值，毫無疑問，行業框架能創造更高的價值。但行業架構的適用性是很有限的。譬如說，如果是保險業的行業架構，那就無法在電信行業中使用。與此相反，設計模式的應用與行業無關，但設計模式提供的價值卻有限，而且離損益底線更遠。跟基于資產的開發（ABD）社區所認可的一樣，讓內容可定制（技術術語是“可變點”）有助于擴大其適用性。

　　要注意的是，此類內容并不局限在高層次的抽象上（比如業務模型）。由于運營資產都是可執行的，所以它們會影響損益底線。例如安全領域的資產，能復用、改變的細粒度訪問控制策略。可以確定的是，這些會對損益底線有所影響，人們也能從這里建立到高層次業務安全策略的聯系。

　　10 - 誤解：MDD僅用于開發

　　構建軟件解決方案的時候，使用模型來指定架構、關聯的服務和組件具有很大的價值，從解決方案的其它方面來說也是如此。但這僅僅是MDD給組織帶來的一部分價值。要想利用模型并從中獲益，就沒必要把使用范圍限定得這么窄。

　　我們之前曾將業務驅動開發（BDD）作為MDD的特例進行了討論。那種情況下的焦點是業務建模——業務里的過程是什么？它們如何工作？如何對它們進行優化？如果在這部分沒有做好，那就會遭遇“無用的信息輸入和輸出（Garbage In，Garbage Out）”。

　　此外，我們還能利用模型來支持規范一致性。模型能提供易于理解的表示，詳細說明結果方案如何支持規范要求。比如說，要表明組織是如何對細分客戶群、業務范圍（LOB）或渠道持續應用某規則的，就能用模型來實現這一規范需求。只提供代碼到文檔的一致性并不足以成為一個最佳的方案。

　　如果要增強已有解決方案的功能，又怎么樣呢？如果需求‘A’變化了，這對系統又會有什么影響呢？你如何確定IT布局中的哪些部分應該進行驗證和修改呢？如果不能跟蹤從需求到實現的過程，這個問題就很難回答，回答的代價也很高。

　　在企業里利用MDD的例子還包括對企業架構和運作建模的支持，但也不局限于此。雖然目標千差萬別，但我們仍期望能夠溝通、利用抽象、保證治理、支持一致性、提高生產率。

　　總結

　　MDD帶來了很多好處，它能促進溝通、改進業務編排、提升質量、提高生產率。如果你以前關注過MDD，那現在應該換個眼光來看待MDD。如果你從沒關注過MDD，那現在可是關注的好時機，因為工具支持已經很成熟了。

　　MDD在工具集里有點兒與眾不同——就像你不會只使用一種語言，或是某種語言的單個庫，為了達到目的，你需要選擇合適的MDD方法和角度。如果想在項目中利用MDD，為了找到適合你的方式，你需要認真考慮下面的問題：

• 處于怎樣的情境？
• 對建模工具有什么需求？
• 對建模語言有哪些需求？
• 需要哪幾個抽象的層次？
• 如何簡化并自動化構建好的方案？
• 需要哪些類型的圖？需要多少個圖？
• 和誰進行溝通？他們要了解些什么？
• 如何確定MDD方法和工具能被整個團隊采用？
• 如何發揮整個團隊的優勢，并讓每個人都參與進來？
• 問題空間里是否有現成的可用內容？
• 如何利用MDD來支持業務？如何利用MDD支持IT？如何利用MDD提供業務和IT編排？
• 有哪些可用內容？這些內容如何針對你的情況進行定制？

　　致謝

　　感謝Brian Byrne、Greg Hodgkinson和Alessandro Di Bari分享他們的洞見，提出了提高本文質量的寶貴建議。

　　資源

• InfoQ采訪——結合MDD和SOA： http://www.infoq.com/articles/bertrand-portier-on-mdd-soma
• 使用模型驅動開發和基于模式的工程在devWorks上設計SOA（系列文章）
• 用基于資產的開發實現戰略復用：http://www.redbooks.ibm.com/abstracts/sg247529.html
• 使用Rational SDP構建SOA解決方案：http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
• 揭秘SOA中架構和服務的基本原則——第一部分：利用架構和抽象層次創建更好的SOA：http://www.ibm.com/developerworks/library/ar-archserv1/
• EclipseCon 2008大會：模式領悟！基于模式的自動化技術實踐：http://www.eclipsecon.org/2008/?page=sub/&id=432
• 模型驅動的開發和相關方法的探討：在模型驅動的體系結構中應用領域特定建模：http://www.ibm.com/developerworks/library/ar-mdd4/
• Eclipse建模框架：http://www.eclipse.org/modeling/emf/
• Eclipse流程框架：http://www.eclipse.org/epf/
• 利用SOA、BPM和EA進行戰略業務和IT編排：http://www.ibm.com/developerworks/websphere/bpmjournal/0812_jensen/0812_jensen.html
• 模式：使用IBM Rational Software Architect進行模型驅動開發：http://www.redbooks.ibm.com/abstracts/sg247105.html?Open

　　英文原文：Model Driven Development Misperceptions and Challenges

　　[1] 我們并不關注資金模型或戰略創新等組織方面的內容。相反，我們要解決的是在嘗試采用MDD時可能面臨的挑戰，并提供能克服這些挑戰的MDD最新進展。

　　[2] 在抽象的SOA層面上，這個列表絕不是官方的、全面的。它在這里只是說明抽象的例子，而非代碼（實現）。

　　[3] 高級設計和詳細設計這兩個層次的抽象都很常見。這里只是一個例子，你的選擇還是應該視約束和目標而定。

　　[4] Scott Schneider和Randy Lexvold在EclipseCon 2008大會上所作的演講：模式領悟！基于模式的自動化技術實踐。

　　譯者簡介： 張兵，有Web應用開發、XML技術、消息中間件和企業服務總線等方面的開發經驗，對SOA領域比較熟悉，關注軟件架構技術和有效的項目管理。

it知識庫：模型驅動開發的誤解和挑戰，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。