英文原文：Model Driven Development Misperceptions and Challenges

　　多年以來，采用模型驅(qū)動(dòng)開發(fā)（MDD）的水平似乎仍沒預(yù)期的那么好。阻礙、限制MDD使用的因素有很多，例如對(duì)實(shí)際的MDD成功案例缺乏認(rèn)知、不確定如何在平常使用MDD、缺少預(yù)先投資的撥款模式、或是沒有戰(zhàn)略舉措的重點(diǎn)。

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

　　建模早已證明了它在改善溝通、促進(jìn)業(yè)務(wù)編排、提升質(zhì)量、提高生產(chǎn)率上的價(jià)值。它的使用范圍很廣，分析、設(shè)計(jì)和開發(fā)都會(huì)有所涉及。考慮到這一點(diǎn)，我們就來看看有關(guān)MDD的諸多誤解和挑戰(zhàn)，我們又該怎樣利用現(xiàn)代方法和相關(guān)工具集解決這些問題。

　　1 - 挑戰(zhàn)：方法不當(dāng)且不可用

　　過去，MDD的一個(gè)關(guān)鍵抑制因素是人們實(shí)施活動(dòng)的時(shí)候沒有現(xiàn)成的MDD最佳實(shí)踐。比如說，人們?cè)陂喿x有關(guān)如何執(zhí)行特定任務(wù)（諸如設(shè)計(jì)高可用的解決方案）的過程文檔時(shí)，文檔里并沒有任何MDD的內(nèi)容。為了得到MDD實(shí)踐，人們不得不到論文或書本里去找，然后再應(yīng)用到現(xiàn)有的非MDD文檔上。

　　如今，MDD從業(yè)者在進(jìn)行日常工作時(shí)，可用的MDD指南已經(jīng)越來越多，而且那些信息嵌在他們每天使用的工具中。我們先看看開發(fā)過程，它包括利用MDD原則的“工具向?qū)?rdquo;最佳實(shí)踐，這些“工具向?qū)?rdquo;隸屬于整個(gè)方法和過程。

　　特定任務(wù)的指南（例如需求評(píng)審、設(shè)計(jì)用戶接口或設(shè)計(jì)高可用的解決方案）現(xiàn)在都包含指向MDD內(nèi)容的鏈接。比如推薦設(shè)計(jì)模式、提供設(shè)計(jì)中應(yīng)用模式的指南、利用現(xiàn)成工具中的模式實(shí)現(xiàn)。

　　以前還有另一個(gè)阻礙因素，就是MDD與特定開發(fā)方法過度摻雜，人們無法提取MDD最佳實(shí)踐，并將其應(yīng)用到不同的場(chǎng)景中。一個(gè)典型的例子就是面向?qū)ο蠓治龊驮O(shè)計(jì)（OOAD）中存在大量工具，你要么采用全部的OOAD內(nèi)容，將其作為從MDD受益的一部分內(nèi)容，要么就完全拋棄OOAD。MDD的最佳實(shí)踐曾是OOAD框架的一部分，但人們并不知道如何在框架之外利用這些最佳實(shí)踐。抽取出MDD的內(nèi)容并將其應(yīng)用到不同的場(chǎng)景中是不可能的。

　　這些因素再加上其他一些原因?qū)е缕髽I(yè)很難在它們的環(huán)境里采用最佳實(shí)踐（包括MDD最佳實(shí)踐）。公司已經(jīng)有了合適的過程和方法，而給這些方法添加MDD方面的內(nèi)容卻很困難。

　　為了在組織和特定類型的項(xiàng)目中采用MDD，業(yè)界在裁剪特定開發(fā)過程方面已經(jīng)做得越來越好。比如有的研討會(huì)旨在指導(dǎo)團(tuán)隊(duì)完成定制的開發(fā)過程，這通常被稱作“方法采用研討會(huì)”。研討會(huì)的目的是針對(duì)特定項(xiàng)目裁剪現(xiàn)有的方法內(nèi)容，它通常會(huì)涉及以下人員：過程工程師（管理組織開發(fā)過程的人）、首席架構(gòu)師、開發(fā)人員組長(zhǎng)和項(xiàng)目經(jīng)理。

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

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

　　下一節(jié)我們會(huì)討論關(guān)于模式實(shí)現(xiàn)的機(jī)制。不管選用什么方法，要點(diǎn)都是獲取越來越多的指南，并將其落實(shí)到工具中，從而更好地指導(dǎo)用戶充分利用模型。

　　正如軟件解決方案可能會(huì)過度工程化一樣，創(chuàng)建指南也會(huì)發(fā)生同樣的問題。克服這個(gè)挑戰(zhàn)的最后一點(diǎn)是要?jiǎng)?wù)實(shí)、主動(dòng)。計(jì)算出構(gòu)建方案所需步驟的全部細(xì)節(jié)，無論從價(jià)值來說還是從時(shí)間來說都沒有什么意義。那關(guān)鍵的步驟是什么呢？他們?nèi)绾闻c團(tuán)隊(duì)的技術(shù)相結(jié)合？在文檔化步驟上投入時(shí)間的意義何在？相對(duì)于自動(dòng)化，在創(chuàng)建靜態(tài)文檔上又該投入多少呢？

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

　　2 - 挑戰(zhàn)：基礎(chǔ)設(shè)施和工具不能從MDD獲益

　　近幾年，我們看到建模工具已不局限于對(duì)特定圖形符號(hào)（比如UML）的支持了，經(jīng)過發(fā)展，它已然能幫助從業(yè)者完成工作。這些工具不僅支持圖形建模符號(hào)，也內(nèi)置了MDD特性，這些特性有利于：

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

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

　　領(lǐng)域獨(dú)立的工具不太可能內(nèi)置領(lǐng)域所需的所有MDD工件。工具除了提供開箱即用的MDD工件外（比如一組設(shè)計(jì)模式實(shí)現(xiàn)），也允許你擴(kuò)展現(xiàn)有的工件、創(chuàng)建自己的工件。現(xiàn)在的工具包含“擴(kuò)展框架”，以及最佳實(shí)踐、模板和API。Rational Software Architect之類的工具還允許你構(gòu)建適用于領(lǐng)域的MDD工件（例如模式實(shí)現(xiàn)、規(guī)則、約束等）。

　　既然你能構(gòu)建這些MDD工件，那么基于資產(chǎn)的開發(fā)（ABD）就能讓你與他人共享工件、提升復(fù)用的實(shí)踐和基礎(chǔ)設(shè)施。換句話說，ABD最佳實(shí)踐和基礎(chǔ)設(shè)施的改進(jìn)支撐了MDD的采用進(jìn)程。諸如Rational Asset Manager的可復(fù)用資產(chǎn)庫(kù)能讓你管理可復(fù)用的軟件工件，讓開發(fā)社區(qū)共享和復(fù)用工件。試想一個(gè)為領(lǐng)域創(chuàng)建的模式實(shí)現(xiàn)，你現(xiàn)在可以把它提交到資產(chǎn)庫(kù)中，該模式經(jīng)過評(píng)審和認(rèn)可，社區(qū)中的其他從業(yè)者就可以復(fù)用它了。作為這個(gè)生態(tài)系統(tǒng)的一部分，你可以監(jiān)控資產(chǎn)被復(fù)用的時(shí)機(jī)和方式，收集反饋信息并確保整個(gè)團(tuán)隊(duì)在使用合適資產(chǎn)的正確版本。

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

　　3 - 誤解：MDD==UML？

　　有一個(gè)誤解是MDD意味著你必須使用統(tǒng)一建模語言（UML）——現(xiàn)狀如此，完全是因?yàn)閬碜詫?duì)象管理組織（OMG）的UML規(guī)范進(jìn)行了這樣的描述。消除這一誤解的方法有很多。

　　打消這種念頭的第一種方法是用MDD的方法工作，這只需要你在執(zhí)行任務(wù)時(shí)把模型作為關(guān)鍵的工件使用，并使用利用這些模型的自動(dòng)化機(jī)制。在這種情況下，模型是用語言簡(jiǎn)化了的現(xiàn)實(shí)，而這些語言具有定義良好的語法和語義。因此，可以在MDD中使用的語言有很多，而不僅僅是UML。 

　　在大多數(shù)情況下，我們確實(shí)要為手頭上的任務(wù)選擇合適的工具。如果我們的MDD需要標(biāo)準(zhǔn)化、為人熟知、被廣泛支持的語言，那UML就是一個(gè)不錯(cuò)的選擇。UML也是可擴(kuò)展的。嚴(yán)格來說，它能通過配置（提供定制的元素、屬性和約束）進(jìn)行定制。這能讓UML對(duì)所作的工作來說變得具體，也能讓語言更加易學(xué)易用。增強(qiáng)建模語言可用性或針對(duì)性的另一種方式是創(chuàng)建你自己的領(lǐng)域特定語言（DSL）。

　　要記住的是，我們受益于使用的語言和創(chuàng)建的模型。為了指導(dǎo)投資，我們要權(quán)衡以下問題：

• 是否能有效地設(shè)計(jì)和理解解空間？
• 能否輕松地和其他人溝通？
• 是否能基于已經(jīng)創(chuàng)建好的模型生成方案的其他部分？
• 能否有效利用開發(fā)生命期之外的結(jié)果？
• 是否能從實(shí)現(xiàn)追溯到設(shè)計(jì)？甚至需求？

　　4 - 誤解：MDD放之四海而皆準(zhǔn)

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

　　其中一個(gè)例子是，我們可以和傳統(tǒng)的面向?qū)ο蠓治龊驮O(shè)計(jì)（OOAD）一起使用MDD。在審視OOAD和MDD的時(shí)候，往往會(huì)發(fā)現(xiàn)使用了很多模型，比如用例、分析、設(shè)計(jì)和實(shí)現(xiàn)。有很多現(xiàn)成的例子和文檔演示了如何使用這些模型來完成方案。但這并不意味著你必須用上所有的模型。關(guān)鍵是我們要有效地利用抽象。抽象的層次取決于所處的場(chǎng)景、使用的語言、相關(guān)的約束、規(guī)則和假設(shè)，以及可能實(shí)施的自動(dòng)化。

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

　　5-誤解：圖表就是模型

　　MDD中關(guān)鍵的一點(diǎn)是要認(rèn)識(shí)到我們?cè)趧?chuàng)建模型——正如前面所討論的，模型是用語言簡(jiǎn)化現(xiàn)實(shí)，該語言要具有良好定義的語法和語義。我們?cè)谀Ｐ椭锌梢园l(fā)現(xiàn)大量模型元素和一組圖表。每種圖表都提供了模型元素之上的一個(gè)視圖。每個(gè)模型元素屬于零或多個(gè)圖表。我們要關(guān)注模型元素——它們是什么？有哪些關(guān)系？有什么屬性？我們通常使用圖表來幫助我們理清這些問題。此外，我們還將圖表作為和其他人溝通的方式。但模型的關(guān)鍵信息存在于模型元素中——因?yàn)檫@能讓我們生成所需的視圖、創(chuàng)建所需的圖表，從模型生成其他元素。如果MDD只是圖表，那工具能畫出漂亮的圖片就能滿足我們的需求了。這并不是說圖表（和支持圖表的工具）不重要。創(chuàng)建模型和圖表的工具需要進(jìn)行調(diào)整，以適合目標(biāo)受眾。

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

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

　　以前對(duì)MDD的誤解之一就是它只能應(yīng)用于代碼。MDD基本上被局限在一個(gè)較低的抽象層次，因此它的影響也很有限。很多人只用MDD工具“可視化”代碼（也就是將代碼圖形化的逆向轉(zhuǎn)換）。這樣是有好處的，比如說，更好地理解大段代碼，以及組件或類之間的關(guān)系。但撇開這些來說，代碼可視化并不能獲得先前討論的那些MDD優(yōu)勢(shì)（比如業(yè)務(wù)編排、改善質(zhì)量、提高生產(chǎn)率或影響分析），因?yàn)樗鞯囊磺幸簿褪亲屇阋詧D形化的方式查看代碼而已。這是基本、初級(jí)的圖形使用方法，和預(yù)期的一樣，它的投資低，收益也低。

　　再?gòu)?fù)雜一點(diǎn)兒，在代碼可視化之后，讓可視化結(jié)果和預(yù)期的設(shè)計(jì)保持一致。例如設(shè)計(jì)師或架構(gòu)師想評(píng)審開發(fā)團(tuán)隊(duì)開發(fā)的代碼，代碼的可視化視圖就能讓他們對(duì)代碼和設(shè)計(jì)進(jìn)行比較，因?yàn)榭梢暬Y(jié)果和設(shè)計(jì)使用了相同的可視化技術(shù)（比如UML類）。不過，盡管可視化結(jié)果和設(shè)計(jì)用相同的語言表示，但兩者之間仍然有很大差距，因?yàn)樗鼈兯幍某橄髮哟尾煌DD工具憑借可視化、可追蹤性、分析和發(fā)現(xiàn)功能、重構(gòu)支持能幫助設(shè)計(jì)師完成工作。一旦標(biāo)注出設(shè)計(jì)和代碼之間有分歧的地方，人工干預(yù)就必不可少了，設(shè)計(jì)師就要和開發(fā)團(tuán)隊(duì)進(jìn)行溝通。這能提升價(jià)值，但仍然無法完全擁有MDD的優(yōu)勢(shì)。為了支持分析和溝通，需要增加時(shí)間和精力，而且每個(gè)項(xiàng)目都需要投入多次。

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

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

• 業(yè)務(wù)：該層次對(duì)業(yè)務(wù)策劃師、業(yè)務(wù)分析師或產(chǎn)品所有者來說是有意義的。在這個(gè)層次上，模型元素是業(yè)務(wù)目標(biāo)、關(guān)鍵性能指標(biāo)、業(yè)務(wù)方針和功能域之類的內(nèi)容。
• 分析：分析和設(shè)計(jì)通常要一起看，分析模型的元素有時(shí)會(huì)演進(jìn)為設(shè)計(jì)元素。在SOA里，考慮分析是很重要的，因?yàn)榉治鍪侵С謽I(yè)務(wù)元素的技術(shù)模型元素的起點(diǎn)。
• 設(shè)計(jì)[3]：SOA方案中，大多數(shù)在架構(gòu)上重要的元素都是在這個(gè)層次建模的。設(shè)計(jì)時(shí)要用文檔記錄架構(gòu)的關(guān)鍵元素，以及它們的實(shí)現(xiàn)方法。
• 實(shí)現(xiàn)：實(shí)現(xiàn)是“代碼”層次的抽象。在該層中，你可以用MDD基于設(shè)計(jì)生成代碼存根，并在需要的時(shí)候讓代碼和設(shè)計(jì)保持一致。

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

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

　　沒有什么銀彈。所需的代碼并非都能自動(dòng)生成（除非你的領(lǐng)域非常小）。最后，你必須處理模型和代碼，MDD則會(huì)指導(dǎo)你利用模型、保持代碼與模型之間的同步。

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

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

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

　　7-挑戰(zhàn)：平臺(tái)無關(guān)性面臨挑戰(zhàn)

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

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

　　8 - 挑戰(zhàn)：保持編碼人員的創(chuàng)造力

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

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

　　9 - 挑戰(zhàn)：沒有可利用的內(nèi)容

　　和其它相對(duì)比較新的方法一樣，在最佳實(shí)踐被充分理解和基礎(chǔ)設(shè)施就位之前，產(chǎn)出的內(nèi)容都很有限。現(xiàn)在MDD在軟件行業(yè)越來越成熟，有了越來越多的推進(jìn)力，可以看到，高質(zhì)量的MDD內(nèi)容和資產(chǎn)也越來越多。讓這些內(nèi)容從一開始就可用，對(duì)采用MDD來說是至關(guān)重要的。

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

　　這里討論的MDD內(nèi)容不僅僅是設(shè)計(jì)模式或UML項(xiàng)目模板。我們所說的內(nèi)容是指行業(yè)或方案的參考架構(gòu)（比如呼叫中心參考架構(gòu)或銀行參考架構(gòu)）、作為可執(zhí)行模型的行業(yè)標(biāo)準(zhǔn)集（比如保險(xiǎn)業(yè)的ACORD或電信行業(yè)的SID）或?qū)崿F(xiàn)存根的模板大全。這類資產(chǎn)的一個(gè)成功案例就是WebSphere Business Services Fabric（WBSF）的行業(yè)內(nèi)容包（ICPs）。WBSF框架由運(yùn)行時(shí)和相關(guān)工具組成。ICPs為特定行業(yè)（領(lǐng)域）提供了可定制的內(nèi)容，從而成為框架的有益補(bǔ)充。這些內(nèi)容包括不同抽象層次（比如業(yè)務(wù)、設(shè)計(jì)和實(shí)現(xiàn)）上的模型和模板，它們遵循行業(yè)標(biāo)準(zhǔn)，由組織加以裁剪和采用。

　　這些資產(chǎn)的核心價(jià)值在于提供了更多的業(yè)務(wù)價(jià)值，而且更接近組織的戰(zhàn)略。換句話說，業(yè)務(wù)能看到它們會(huì)影響損益底線。如果我們比較可復(fù)用設(shè)計(jì)模式的價(jià)值和行業(yè)框架的價(jià)值，毫無疑問，行業(yè)框架能創(chuàng)造更高的價(jià)值。但行業(yè)架構(gòu)的適用性是很有限的。譬如說，如果是保險(xiǎn)業(yè)的行業(yè)架構(gòu)，那就無法在電信行業(yè)中使用。與此相反，設(shè)計(jì)模式的應(yīng)用與行業(yè)無關(guān)，但設(shè)計(jì)模式提供的價(jià)值卻有限，而且離損益底線更遠(yuǎn)。跟基于資產(chǎn)的開發(fā)（ABD）社區(qū)所認(rèn)可的一樣，讓內(nèi)容可定制（技術(shù)術(shù)語是“可變點(diǎn)”）有助于擴(kuò)大其適用性。

　　要注意的是，此類內(nèi)容并不局限在高層次的抽象上（比如業(yè)務(wù)模型）。由于運(yùn)營(yíng)資產(chǎn)都是可執(zhí)行的，所以它們會(huì)影響損益底線。例如安全領(lǐng)域的資產(chǎn)，能復(fù)用、改變的細(xì)粒度訪問控制策略。可以確定的是，這些會(huì)對(duì)損益底線有所影響，人們也能從這里建立到高層次業(yè)務(wù)安全策略的聯(lián)系。

　　10 - 誤解：MDD僅用于開發(fā)

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

　　我們之前曾將業(yè)務(wù)驅(qū)動(dòng)開發(fā)（BDD）作為MDD的特例進(jìn)行了討論。那種情況下的焦點(diǎn)是業(yè)務(wù)建模——業(yè)務(wù)里的過程是什么？它們?nèi)绾喂ぷ鳎咳绾螌?duì)它們進(jìn)行優(yōu)化？如果在這部分沒有做好，那就會(huì)遭遇“無用的信息輸入和輸出（Garbage In，Garbage Out）”。

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

　　如果要增強(qiáng)已有解決方案的功能，又怎么樣呢？如果需求‘A’變化了，這對(duì)系統(tǒng)又會(huì)有什么影響呢？你如何確定IT布局中的哪些部分應(yīng)該進(jìn)行驗(yàn)證和修改呢？如果不能跟蹤從需求到實(shí)現(xiàn)的過程，這個(gè)問題就很難回答，回答的代價(jià)也很高。

　　在企業(yè)里利用MDD的例子還包括對(duì)企業(yè)架構(gòu)和運(yùn)作建模的支持，但也不局限于此。雖然目標(biāo)千差萬別，但我們?nèi)云谕軌驕贤ā⒗贸橄蟆⒈ＷC治理、支持一致性、提高生產(chǎn)率。

　　總結(jié)

　　MDD帶來了很多好處，它能促進(jìn)溝通、改進(jìn)業(yè)務(wù)編排、提升質(zhì)量、提高生產(chǎn)率。如果你以前關(guān)注過MDD，那現(xiàn)在應(yīng)該換個(gè)眼光來看待MDD。如果你從沒關(guān)注過MDD，那現(xiàn)在可是關(guān)注的好時(shí)機(jī)，因?yàn)楣ぞ咧С忠呀?jīng)很成熟了。

　　MDD在工具集里有點(diǎn)兒與眾不同——就像你不會(huì)只使用一種語言，或是某種語言的單個(gè)庫(kù)，為了達(dá)到目的，你需要選擇合適的MDD方法和角度。如果想在項(xiàng)目中利用MDD，為了找到適合你的方式，你需要認(rèn)真考慮下面的問題：

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

　　致謝

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

　　資源

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

　　英文原文：Model Driven Development Misperceptions and Challenges

　　[1] 我們并不關(guān)注資金模型或戰(zhàn)略創(chuàng)新等組織方面的內(nèi)容。相反，我們要解決的是在嘗試采用MDD時(shí)可能面臨的挑戰(zhàn)，并提供能克服這些挑戰(zhàn)的MDD最新進(jìn)展。

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

　　[3] 高級(jí)設(shè)計(jì)和詳細(xì)設(shè)計(jì)這兩個(gè)層次的抽象都很常見。這里只是一個(gè)例子，你的選擇還是應(yīng)該視約束和目標(biāo)而定。

　　[4] Scott Schneider和Randy Lexvold在EclipseCon 2008大會(huì)上所作的演講：模式領(lǐng)悟！基于模式的自動(dòng)化技術(shù)實(shí)踐。

　　譯者簡(jiǎn)介： 張兵，有Web應(yīng)用開發(fā)、XML技術(shù)、消息中間件和企業(yè)服務(wù)總線等方面的開發(fā)經(jīng)驗(yàn)，對(duì)SOA領(lǐng)域比較熟悉，關(guān)注軟件架構(gòu)技術(shù)和有效的項(xiàng)目管理。

it知識(shí)庫(kù)：模型驅(qū)動(dòng)開發(fā)的誤解和挑戰(zhàn)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。