模型驅(qū)動(dòng)開發(fā)的誤解和挑戰(zhàn)

1、模型驅(qū)動(dòng)開發(fā)的誤解和挑戰(zhàn) 2009年11月30日 來源： 作者：Bertrand Portier, Lee Ackerman 編輯：李倩 評論：0條 本文Tag： 軟件開發(fā) 開發(fā)模型 【IT168 技術(shù)文章】 多年以來，采用模型驅(qū)動(dòng)開發(fā)（MDD）的水平似乎仍沒預(yù)期的那么好。阻礙、限制MDD使用的因素有很多，例如對實(shí)際的MDD成功案例缺乏認(rèn)知、不確定如何在平常使用MDD、缺少預(yù)先投資的撥款模式、或是沒有戰(zhàn)略舉措的重點(diǎn)。 如果你過去嘗試過MDD，那你很可能遇到了一些挫折，導(dǎo)致你現(xiàn)在不再用它。也或許你正在嘗試采用MDD，而又面臨著一些挑戰(zhàn)和阻礙。無論你遇到上述哪種情況，本文都對你有所幫助。我們會(huì)在本

2、文中看一看與采用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í)踐。比如說，人們在閱讀有關(guān)如何執(zhí)行特定任務(wù)（諸如設(shè)計(jì)高可用的解決方案）的過程文檔時(shí)，文檔里并沒有任何MDD的內(nèi)容。為了得到MDD實(shí)踐，人們不得不到論文或書本里去找，然后再應(yīng)用到現(xiàn)有的非MDD文檔上。 如今，MDD從業(yè)者在進(jìn)行日常工

3、作時(shí)，可用的MDD指南已經(jīng)越來越多，而且那些信息嵌在他們每天使用的工具中。我們先看看開發(fā)過程，它包括利用MDD原則的“工具向?qū)А弊罴褜?shí)踐，這些“工具向?qū)А彪`屬于整個(gè)方法和過程。 特定任務(wù)的指南（例如需求評審、設(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)用到不同的場景中。一個(gè)典型的例子就是面向?qū)ο蠓治龊驮O(shè)計(jì)（OOAD）中存在大量工具，你要么采用全部的OOAD內(nèi)容，將其作為從MDD受益的一部分內(nèi)容，要么就完全拋

4、棄OOAD。MDD的最佳實(shí)踐曾是OOAD框架的一部分，但人們并不知道如何在框架之外利用這些最佳實(shí)踐。抽取出MDD的內(nèi)容并將其應(yī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ì)的目的是針對特定項(xiàng)目裁剪現(xiàn)有的方法內(nèi)容，它通常會(huì)涉及以下人員：過程工程師（管理組織開發(fā)過程的人）、首席架構(gòu)師、開發(fā)

5、人員組長和項(xiàng)目經(jīng)理。 支持定制后，方法工具浮出水面，比如Rational Method Composer和Eclipse Process Framework Composer，它們包含定制的最佳實(shí)踐庫。這些工具的思想是整理、打包最佳實(shí)踐，用工具為組織裁剪并采用這些最佳實(shí)踐。在工具中，你選擇想要采用的某些方法元素，對它們進(jìn)行修改、編輯，并將其組織成希望關(guān)注的過程。然后將該過程以可讀格式（例如HTML）在組織內(nèi)發(fā)布，供從業(yè)者在日常工作中遵循。 盡管使用上述工具和方法的可用指南有很多，但仍然要求用戶找到、理解并遵照指南?？缭竭@一障礙的措施是，除了在工具里提供指南之外，還要將方案的全面自動(dòng)化。舉例來說

6、，你能在使用基于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í)間的意義何在？相對于自動(dòng)化，在創(chuàng)建靜態(tài)文檔上又該投入多少呢？ 過程，尤其是M

7、DD，都不是放之四海而皆準(zhǔn)的，這將在“4-誤解”中討論。 2-挑戰(zhàn)：基礎(chǔ)設(shè)施和工具不能從MDD獲益 近幾年，我們看到建模工具已不局限于對特定圖形符號（比如UML）的支持了，經(jīng)過發(fā)展，它已然能幫助從業(yè)者完成工作。這些工具不僅支持圖形建模符號，也內(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ì)

8、量：由于實(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)師）能針對不同的受眾創(chuàng)建不同的視圖。 影響分析：MDD的可追蹤性能讓你分析出需求變更對解決方案造成的影響

9、，反之亦然。 讓我們以設(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)有

10、的工件、創(chuàng)建自己的工件?，F(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)庫能讓你管理可復(fù)用的軟件工件，讓開發(fā)社區(qū)共享和復(fù)用工件。試想一個(gè)為領(lǐng)域創(chuàng)建的模式實(shí)現(xiàn)，你現(xiàn)在可以把它提交到資產(chǎn)庫中，該模式經(jīng)過評審和認(rèn)可，社區(qū)中的其他從業(yè)者就

11、可以復(fù)用它了。作為這個(gè)生態(tài)系統(tǒng)的一部分，你可以監(jiān)控資產(chǎn)被復(fù)用的時(shí)機(jī)和方式，收集反饋信息并確保整個(gè)團(tuán)隊(duì)在使用合適資產(chǎn)的正確版本。 我們重新回到務(wù)實(shí)和實(shí)用上來。在對用戶和用戶所在組織有意義的情況下，ABD及復(fù)用倡議才需要被采用。你需要識別出你的成熟度級別，并采用支持該級別的工具和過程。通過事先思考和計(jì)劃，你可以隨需確定、推廣ABD計(jì)劃，避免不必要的開銷和成本。 3-誤解：MDD=UML？ 有一個(gè)誤解是MDD意味著你必須使用統(tǒng)一建模語言（UML）現(xiàn)狀如此，完全是因?yàn)閬碜詫ο蠊芾斫M織（OMG）的UML規(guī)范進(jìn)行了這樣的描述。消除這一誤解的方法有很多。 打消這種念頭的第一種方法是用MDD的方法工作，這只需

12、要你在執(zhí)行任務(wù)時(shí)把模型作為關(guān)鍵的工件使用，并使用利用這些模型的自動(dòng)化機(jī)制。在這種情況下，模型是用語言簡化了的現(xiàn)實(shí)，而這些語言具有定義良好的語法和語義。因此，可以在MDD中使用的語言有很多，而不僅僅是UML。 在大多數(shù)情況下，我們確實(shí)要為手頭上的任務(wù)選擇合適的工具。如果我們的MDD需要標(biāo)準(zhǔn)化、為人熟知、被廣泛支持的語言，那UML就是一個(gè)不錯(cuò)的選擇。UML也是可擴(kuò)展的。嚴(yán)格來說，它能通過配置（提供定制的元素、屬性和約束）進(jìn)行定制。這能讓UML對所作的工作來說變得具體，也能讓語言更加易學(xué)易用。增強(qiáng)建模語言可用性或針對性的另一種方式是創(chuàng)建你自己的領(lǐng)域特定語言（DSL）。 要記住的是，我們受益于使用的語

13、言和創(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ā)的軟件類型也是配套的。因此，我們能在自己的場景中看到很多使用MDD、有意義的方式。 其中一個(gè)例子是，我們可以和傳統(tǒng)的面向?qū)ο蠓治龊驮O(shè)計(jì)（OOAD）一起使用MDD。在審

14、視OOAD和MDD的時(shí)候，往往會(huì)發(fā)現(xiàn)使用了很多模型，比如用例、分析、設(shè)計(jì)和實(shí)現(xiàn)。有很多現(xiàn)成的例子和文檔演示了如何使用這些模型來完成方案。但這并不意味著你必須用上所有的模型。關(guān)鍵是我們要有效地利用抽象。抽象的層次取決于所處的場景、使用的語言、相關(guān)的約束、規(guī)則和假設(shè)，以及可能實(shí)施的自動(dòng)化。 除了在模型數(shù)量（和相關(guān)的抽象層次）上務(wù)實(shí)之外，也要切合實(shí)際地選擇模型中用于交流的圖表。比如說，如果使用UML作為建模語言，就沒必要使用所有可用的圖表類型（類圖、交互圖）。語言中有一系列圖表可供選擇，一般用途的建模語言能為各種需求提供服務(wù)就可以了。在特定情形下，對于你試圖完成的工作來說，只選擇那些能為其增加價(jià)值、

15、有助于溝通的圖表才是有意義的。至于完整性，我們可以進(jìn)行進(jìn)一步的討論，要注意的是，即使在一個(gè)圖表中，你也不必使用所有可用的模型元素。 5-誤解：圖表就是模型 MDD中關(guān)鍵的一點(diǎn)是要認(rèn)識到我們在創(chuàng)建模型正如前面所討論的，模型是用語言簡化現(xiàn)實(shí)，該語言要具有良好定義的語法和語義。我們在模型中可以發(fā)現(xiàn)大量模型元素和一組圖表。每種圖表都提供了模型元素之上的一個(gè)視圖。每個(gè)模型元素屬于零或多個(gè)圖表。我們要關(guān)注模型元素它們是什么？有哪些關(guān)系？有什么屬性？我們通常使用圖表來幫助我們理清這些問題。此外，我們還將圖表作為和其他人溝通的方式。但模型的關(guān)鍵信息存在于模型元素中因?yàn)檫@能讓我們生成所需的視圖、創(chuàng)建所需的圖表，

16、從模型生成其他元素。如果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ú)立模型、或

17、是不在維護(hù)同一元素的多個(gè)版本上浪費(fèi)時(shí)間的情況下，透視圖可以支持這些需求。請記住，我的意思并不是讓你支持所有不同的小組，并創(chuàng)建龐大的一組透視圖。再次強(qiáng)調(diào)一下，關(guān)鍵是要?jiǎng)?wù)實(shí)，要?jiǎng)?chuàng)建有意義、能帶來價(jià)值的圖表與視角。 6-誤解：代碼就是模型，模型就是代碼 以前對MDD的誤解之一就是它只能應(yīng)用于代碼。MDD基本上被局限在一個(gè)較低的抽象層次，因此它的影響也很有限。很多人只用MDD工具“可視化”代碼（也就是將代碼圖形化的逆向轉(zhuǎn)換）。這樣是有好處的，比如說，更好地理解大段代碼，以及組件或類之間的關(guān)系。但撇開這些來說，代碼可視化并不能獲得先前討論的那些MDD優(yōu)勢（比如業(yè)務(wù)編排、改善質(zhì)量、提高生產(chǎn)率或影響分析），

18、因?yàn)樗鞯囊磺幸簿褪亲屇阋詧D形化的方式查看代碼而已。這是基本、初級的圖形使用方法，和預(yù)期的一樣，它的投資低，收益也低。 再復(fù)雜一點(diǎn)兒，在代碼可視化之后，讓可視化結(jié)果和預(yù)期的設(shè)計(jì)保持一致。例如設(shè)計(jì)師或架構(gòu)師想評審開發(fā)團(tuán)隊(duì)開發(fā)的代碼，代碼的可視化視圖就能讓他們對代碼和設(shè)計(jì)進(jìn)行比較，因?yàn)榭梢暬Y(jié)果和設(shè)計(jì)使用了相同的可視化技術(shù)（比如UML類）。不過，盡管可視化結(jié)果和設(shè)計(jì)用相同的語言表示，但兩者之間仍然有很大差距，因?yàn)樗鼈兯幍某橄髮哟尾煌?。MDD工具憑借可視化、可追蹤性、分析和發(fā)現(xiàn)功能、重構(gòu)支持能幫助設(shè)計(jì)師完成工作。一旦標(biāo)注出設(shè)計(jì)和代碼之間有分歧的地方，人工干預(yù)就必不可少了，設(shè)計(jì)師就要和開發(fā)團(tuán)隊(duì)進(jìn)行

19、溝通。這能提升價(jià)值，但仍然無法完全擁有MDD的優(yōu)勢。為了支持分析和溝通，需要增加時(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)域和組織選擇有意義的抽象層次。例

20、如，在SOA中，可以在開發(fā)方案時(shí)采用以下的抽象層次2： 業(yè)務(wù)：該層次對業(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)這樣

21、的情況：人們熱衷于模型和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à)值的信息。這包括文檔的生成、測試用例、部署腳本等，這樣就能顯著提高項(xiàng)目的整體生產(chǎn)率。眾所周知，實(shí)際的代碼編寫只是整個(gè)項(xiàng)目的一部分工作而已。 沒有什么銀彈。所需的代碼并非

22、都能自動(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ā)方法的一部分。 由于修改極可能在代碼級別發(fā)生，所以若沒有

23、保持模型和代碼一致的方法，模型很快就只剩文檔了。最近，Rational Software Architect之類的工具在“保持一致”方面有了很大的改進(jìn)，提供了可視化代碼、比較和合并的功能。請注意，用于協(xié)調(diào)這些變化的方法比工具化的能力更為重要，這和治理也是相關(guān)的。舉例來說，架構(gòu)師看到了代碼和模型之間的差異，怎么辦呢？去和開發(fā)人員討論？讓開發(fā)人員修改代碼？還是架構(gòu)師修改模型？正如你所看到的，這些都不是完全自動(dòng)化的方法。 已經(jīng)取得巨大成功的另一個(gè)方式是預(yù)先在工具化上投資（要么購買要么定制），通過約束、規(guī)則和假設(shè)減小問題空間。對問題空間所能做的限制越多，生成高比例解決方案、減少抽象層次、消除雙向工程需

24、求的可能性就越大。在這種情況下，今后的關(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)識到很難從很高層次的內(nèi)容進(jìn)行延展，也很難將一種表示定位到許多不同類型的實(shí)現(xiàn)上去。已經(jīng)有一些解決方案能讓用戶利用模型生成全部的結(jié)果代碼了。但在那些情況下，也正如前面小節(jié)中所討論的，工具化對領(lǐng)域來說很有針對性，而且利用了一組約束、規(guī)則和假設(shè)才使轉(zhuǎn)變成為可能。解決方案空間比較狹小，這樣才為生成高層次的內(nèi)容提供了可能性。隨著解決方

25、案空間的擴(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à)。這同樣適用于建模和使用的語言。針對具體領(lǐng)域并不一定就是什么壞事，事實(shí)上它反而是最佳利益。不過，創(chuàng)建一個(gè)領(lǐng)域特定的解決方案，再大范圍地加以應(yīng)用是不切實(shí)際的。 8-挑戰(zhàn)：保持編碼人員的創(chuàng)造力 在我們轉(zhuǎn)向MDD，期望簡化設(shè)計(jì)表達(dá)、改善溝通、生成部分解決方案的時(shí)候，我們還需要認(rèn)識到這會(huì)對團(tuán)隊(duì)產(chǎn)生影響。有些團(tuán)隊(duì)成員可能喜歡在較低的抽象層次工

26、作；他們也許會(huì)在場景建模時(shí)覺得拘束，反而在努力實(shí)現(xiàn)解決方案的時(shí)候感到自如。這些擔(dān)心并非都是合理的，但還是要聽出“弦外之音”。我們需要保證每個(gè)團(tuán)隊(duì)成員都能發(fā)揮最大的作用。 即使在處理模型的時(shí)候，我們也需要底層實(shí)現(xiàn)的相關(guān)專業(yè)知識。應(yīng)該使用什么框架？這些框架如何整合？下面以模式為例進(jìn)行說明。構(gòu)建模式實(shí)現(xiàn)的關(guān)鍵輸入是參考解決方案，也就是樣例，它用來決定模式實(shí)現(xiàn)應(yīng)該做什么以及怎么做。如果我們要構(gòu)建自己的模式實(shí)現(xiàn)，那誰來構(gòu)建樣例？誰來判定該樣例是不是解決問題的最佳方式？既然期望能簡化建模體驗(yàn)，那又由誰來給出規(guī)則、假設(shè)和約束呢？又該怎樣把它們編輯到人人都要用的工具中呢？這些問題都強(qiáng)調(diào)，有很多地方都需要專業(yè)知

27、識、創(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)容 和其它相對比較新的方法一樣，在最佳實(shí)踐被充分理解和基礎(chǔ)設(shè)施就位之前，產(chǎn)出的內(nèi)容都很有限?，F(xiàn)在MDD在軟件行業(yè)越來越成熟，有了越來越多的推進(jìn)力，可以看到，高質(zhì)量的MDD內(nèi)容和資產(chǎn)也越來越多。讓這些內(nèi)容從一開始就可用，對采用MDD來說是至關(guān)重要的。 面對有挑戰(zhàn)性的業(yè)務(wù)問題，僅有工具和基礎(chǔ)設(shè)施還不足以交付解決這些問題的軟件。最終解決

28、問題的往往都不是工具，而是使用工具的人4。如果希望大家使用工具，那么最初就有工具的話，情況就會(huì)有很大不同。你是否曾經(jīng)面對過一塊白板、一張紙或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框

29、架由運(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)營資產(chǎn)都是可執(zhí)行的，所以它們會(huì)影響損益底線。例如安全領(lǐng)域的資產(chǎn)，能復(fù)用、改變的細(xì)粒度訪問控制策略?？梢源_定的是，這些會(huì)對損益底線有所影響，人們也能從這里建立到高層次業(yè)務(wù)安全策略的聯(lián)系。 10-誤解：MDD僅用于開發(fā) 構(gòu)建軟件解決方案的時(shí)候，使用模型來指定架構(gòu)、關(guān)聯(lián)的服務(wù)和組件具有很大的價(jià)值，從解決方案的其它方面來說也是如此。但這僅僅是M