高級(jí)軟件工程論文.docx

模型驅(qū)動(dòng)的開(kāi)發(fā)（MDD）摘要“十年內(nèi)，沒(méi)有任何單獨(dú)的軟件工程進(jìn)展可以使軟件生產(chǎn)率有數(shù)量級(jí)的提高”，F(xiàn)rederick Brooks在1986年做出的這一論斷被廣泛稱(chēng)為“銀彈定律”。Brooks給了這一定律一個(gè)10年的期限。然而事實(shí)證明他過(guò)于謹(jǐn)慎了，在他做出這個(gè)論斷之后接近20年，銀彈定律仍然像魔咒一樣緊緊束縛住軟件工業(yè)。盡管專(zhuān)業(yè)人士嘗試了大量的新技術(shù)和新方法，但是效果令人失望。面向?qū)ο蟊蛔C明有負(fù)眾望，軟件工程更是陷入泥潭，魔咒絲毫沒(méi)有松綁的意思。我們應(yīng)當(dāng)像敬畏“沒(méi)有永動(dòng)機(jī)”的理論那樣敬畏“銀彈定律”呢，還是應(yīng)當(dāng)去挑戰(zhàn)它、突破它？ 事實(shí)上，軟件理論家和實(shí)踐者一刻都沒(méi)有停止過(guò)突破“銀彈定律”的嘗試?！澳Ｐ万?qū)動(dòng)開(kāi)發(fā)”可能是最新的一次嘗試。本文通過(guò)從軟件工程的未來(lái)發(fā)展趨勢(shì)對(duì)MDD進(jìn)行了一系列的分析。KEY：銀彈定律，模型驅(qū)動(dòng)開(kāi)發(fā)，軟件工業(yè)，永動(dòng)機(jī)Abstractten years, there is no single software engineering progress can make the software of magnitude increase productivity, Frederick Brooks made in 1986, this argument is widely known as the silver bullet Law. Brooks gave the law of a 10-year period. But the fact that he was too cautious, he made this assertion in nearly 20 years later, the same silver bullet Law is still tightly bound to live as the curse of the software industry. Although a large number of professionals who try new technologies and new methods, but the effect is disappointing. Object-Oriented been shown to have fallen short of expectations, software engineering is stalled, the spell did not mean relaxation. We should like the fear of no perpetual motion machinetheory that fear of the silver bullet Law, or should be to challenge it, break it? In fact, theorists and practitioners of the software have not stopped a breakthrough moment, silver bullet Law attempt. Model-driven developmentmay be the latest attempt. This article from the future trends of software engineering, a series of analysis of MDD. KEY: silver bullet law, model-driven development, software industry, perpetual motion machine目錄摘要2引言4探索模型驅(qū)動(dòng)開(kāi)發(fā) (MDD) 和相關(guān)方法1: 實(shí)現(xiàn)模型驅(qū)動(dòng)開(kāi)發(fā)，增加您的 IT 系統(tǒng)的業(yè)務(wù)價(jià)值5探索模型驅(qū)動(dòng)開(kāi)發(fā) (MDD) 和相關(guān)方法2: 結(jié)合模式與建模以實(shí)現(xiàn)架構(gòu)驅(qū)動(dòng)開(kāi)發(fā)-明確地捕獲您的架構(gòu)決策8探索模型驅(qū)動(dòng)開(kāi)發(fā) (MDD) 和相關(guān)方法3 : 進(jìn)一步研究模型驅(qū)動(dòng)開(kāi)發(fā)和其他行業(yè)方法1115種使用模型驅(qū)動(dòng)開(kāi)發(fā)MDD的理由12模型驅(qū)動(dòng)開(kāi)發(fā)的誤解和挑戰(zhàn)15總結(jié)19參考文獻(xiàn)：20引言關(guān)于軟件工程的未來(lái)發(fā)展趨勢(shì)，我們?cè)?jīng)討論了很多次。但是軟件工程的發(fā)展不可能是孤立的，依據(jù)計(jì)算模型和軟件開(kāi)發(fā)本身的變化和趨勢(shì)，我們由此可以推測(cè)軟件工程的發(fā)展趨勢(shì)。 需求工程，漸成熱點(diǎn)：專(zhuān)業(yè)化的角色，日益復(fù)雜的業(yè)務(wù)創(chuàng)新，全球分布的團(tuán)隊(duì)以及互聯(lián)網(wǎng)級(jí)的交付速度，這些都對(duì)需求獲取的正確性和有效性提出了更高的要求。 DSSA和MDD，老樹(shù)新花（基于領(lǐng)域的構(gòu)架（DSSA）與模型驅(qū)動(dòng)的開(kāi)發(fā)（MDD）：隨著軟件應(yīng)用的日益普及，軟件已經(jīng)超出了將手動(dòng)流程自動(dòng)化的范疇，而開(kāi)始成為業(yè)務(wù)創(chuàng)新的主要推動(dòng)力。因此，引入捕獲特定領(lǐng)域內(nèi)最先進(jìn)需求及其實(shí)現(xiàn)架構(gòu)的DSSA成為行業(yè)客戶的熱點(diǎn)之一。而且，DSSA的引入將MDD門(mén)檻大大降低了，也使基于DSSA的MDD支撐工具成為可能，從而可以極大地提高開(kāi)發(fā)效率并保證軟件質(zhì)量。 迭代/敏捷，漸成標(biāo)準(zhǔn)：隨著軟件交付周期的日益加快，迭代化開(kāi)發(fā)已經(jīng)成為大多數(shù)軟件開(kāi)發(fā)團(tuán)隊(duì)的必選項(xiàng)。但是迭代對(duì)整個(gè)團(tuán)隊(duì)的需求、架構(gòu)、協(xié)同及測(cè)試能力都提出了更高的要求，現(xiàn)在許多開(kāi)發(fā)團(tuán)隊(duì)都在試圖導(dǎo)入迭代化開(kāi)發(fā)的過(guò)程中，敏捷可是被看成迭代化開(kāi)發(fā)的一種導(dǎo)入方式，這不過(guò)敏捷的范圍其實(shí)比迭代化開(kāi)發(fā)更大一些。 持續(xù)集成，蓄勢(shì)待發(fā)：持續(xù)集成是保證迭代化開(kāi)發(fā)質(zhì)量的主要方式，通過(guò)持續(xù)集成可以利用自動(dòng)化的方式來(lái)盡量自動(dòng)地、盡早保證代碼質(zhì)量。隨著迭代和敏捷的流行，持續(xù)集成相關(guān)的工具成為現(xiàn)在市場(chǎng)上的新熱點(diǎn)。 基于實(shí)踐的過(guò)程框架，方興未艾：開(kāi)發(fā)角色的專(zhuān)業(yè)化的和分布的全球化都要求軟件開(kāi)發(fā)過(guò)程更加規(guī)范，而敏捷又要求過(guò)程必須緊密貼合項(xiàng)目的實(shí)際需要，因此傳統(tǒng)的大一統(tǒng)的過(guò)程無(wú)法符合這一需求。新一代的過(guò)程將是以實(shí)踐為核心的，項(xiàng)目可以通過(guò)組裝所需的不同實(shí)踐來(lái)獲得貼近項(xiàng)目要求的過(guò)程。 配置管理，昨日黃花：隨著開(kāi)發(fā)團(tuán)隊(duì)規(guī)模的日益減小，配置管理的復(fù)雜性大大降低了，我們注意到越來(lái)越多的用戶轉(zhuǎn)向使用開(kāi)源的配置管理工具；未來(lái)的配置管理工具更多的以一種全生命周期管理平臺(tái)（Application Lifecycle Management）的方式出現(xiàn)，弱化了單項(xiàng)的配置管理能力而強(qiáng)調(diào)了全流程的整合。探索模型驅(qū)動(dòng)開(kāi)發(fā) (MDD) 和相關(guān)方法1: 實(shí)現(xiàn)模型驅(qū)動(dòng)開(kāi)發(fā)，增加您的 IT 系統(tǒng)的業(yè)務(wù)價(jià)值Tracy Gardner 博士是英國(guó) IBM Software Group Services 的解決方案架構(gòu)師。她在模型驅(qū)動(dòng)開(kāi)發(fā)方面有著五年以上的行業(yè)經(jīng)驗(yàn)。她在模型驅(qū)動(dòng)開(kāi)發(fā)方面撰寫(xiě)大量文章并做了大量演講。她擁有 Bath 大學(xué)的軟件工程博士學(xué)位。您可以通過(guò) 聯(lián)系 Tracy。了解您目前的業(yè)務(wù)環(huán)境IT 開(kāi)發(fā)不會(huì)孤立出現(xiàn)。IT 的目的是簡(jiǎn)化業(yè)務(wù)運(yùn)作，這意味著業(yè)務(wù)環(huán)境的需求推動(dòng)著我們開(kāi)發(fā) IT 的方法。表 1展示了一些當(dāng)前的業(yè)務(wù)推動(dòng)力。推動(dòng)力描述隨需應(yīng)變的業(yè)務(wù)由于商家應(yīng)該更具適應(yīng)性和靈活性，所以 IT 系統(tǒng)要做得太多了。業(yè)務(wù)關(guān)聯(lián)大家強(qiáng)烈關(guān)注 IT 部門(mén)交付業(yè)務(wù)價(jià)值。軟件必須是與業(yè)務(wù)相關(guān)的。業(yè)務(wù)及 IT 人員之間的錯(cuò)誤傳達(dá)會(huì)導(dǎo)致從 IT 交付觀點(diǎn)看成功的項(xiàng)目，被視為業(yè)務(wù)上的失敗。成本控制根據(jù)承諾的力度對(duì) IT 投資的時(shí)代早已過(guò)去?，F(xiàn)在，IT 部門(mén)在強(qiáng)大的預(yù)算約束下運(yùn)作，并且應(yīng)該證明其金錢(qián)方面的價(jià)值。不斷增加的復(fù)雜性軟件系統(tǒng)在規(guī)模和復(fù)雜度上不斷的增加，從而滿足業(yè)務(wù)需要。對(duì)小規(guī)模開(kāi)發(fā)有效的技術(shù)，不一定適用于按企業(yè)級(jí)的計(jì)劃。技能可用性當(dāng)今 IT 平臺(tái)的成熟意味著交付軟件需要專(zhuān)家的經(jīng)驗(yàn)。許多組織努力尋找著有充足技能的專(zhuān)業(yè)人員支持它們的開(kāi)發(fā)。項(xiàng)目常常依賴(lài)于一些關(guān)鍵的人物，如果這些人離開(kāi)了，損失會(huì)很?chē)?yán)重。變化的中間件環(huán)境現(xiàn)今的應(yīng)用程序都部署到極為多樣的中間件平臺(tái)上，平臺(tái)技術(shù)的變更率沒(méi)有表現(xiàn)出減慢的跡象。商家希望利用中間件中的先進(jìn)技術(shù)，但不愿意重復(fù)地編寫(xiě)它們的應(yīng)用程序。表 1. 當(dāng)前的業(yè)務(wù)推動(dòng)力了解軟件開(kāi)發(fā)的模型驅(qū)動(dòng)方法模型驅(qū)動(dòng)開(kāi)發(fā)（Model-driven development，MDD）是軟件開(kāi)發(fā)的一種樣式，其中主要的軟件工件是模型，根據(jù)最佳實(shí)踐，可以從這些模型生成代碼和其他工件。模型是從特定角度對(duì)系統(tǒng)進(jìn)行的描述，它省略了相關(guān)的細(xì)節(jié)，因此可以更清楚地看到感興趣的特性。例如，結(jié)構(gòu)工程師會(huì)創(chuàng)建適合于確定建筑物承載特性的模型。在 MDD 中，我們引入了附加的標(biāo)準(zhǔn)，即模型必須是計(jì)算機(jī)可讀的。例如，我們必須能夠以自動(dòng)化的方式估計(jì)模型的內(nèi)容。模型的計(jì)算機(jī)可讀性是它能夠生成工件的必要條件。白板上的圖也許滿足作為模型的其他標(biāo)準(zhǔn)。然而，直到我們以計(jì)算機(jī)可讀的方式獲取它時(shí)，才能夠在 MDD 工具系列中使用它。軟件模型一般用統(tǒng)一建模語(yǔ)言（Unified Modeling Language，UML）表示。UML 是用于說(shuō)明、可視化，并文檔化軟件系統(tǒng)的語(yǔ)言。它為軟件模型提供了可視化的表示和基礎(chǔ)的語(yǔ)義。UML 還擁有用來(lái)確保自動(dòng)化的標(biāo)準(zhǔn)化的計(jì)算機(jī)可讀的序列化格式。軟件模型隱藏了技術(shù)實(shí)現(xiàn)的細(xì)節(jié)，因此，我們可以利用來(lái)自應(yīng)用領(lǐng)域中的概念來(lái)設(shè)計(jì)系統(tǒng)。為 MDD 項(xiàng)目估計(jì)任務(wù)MDD 對(duì)我們構(gòu)建業(yè)務(wù)應(yīng)用軟件的方式有著深遠(yuǎn)的影響。它獲得了頂級(jí)技術(shù)人員的經(jīng)驗(yàn)及決策，通過(guò)為項(xiàng)目的需求所定制的工具使余下的團(tuán)隊(duì)可以獲得這些經(jīng)驗(yàn)和決策。由于大量的低層次編碼工作已經(jīng)自動(dòng)化了，所以開(kāi)發(fā)的成本，以及測(cè)試業(yè)務(wù)軟件的成本極大地減少了。錯(cuò)誤的數(shù)量減少了，并且在工作完成的方式上增加了一致性。然而，MDD 確實(shí)創(chuàng)建了項(xiàng)目的不同一面，需要管理一個(gè)項(xiàng)目中的另一個(gè)項(xiàng)目。內(nèi)部工程包含了 MDD 工具的開(kāi)發(fā)，這些工具可以供開(kāi)發(fā)團(tuán)隊(duì)在外部項(xiàng)目中構(gòu)建業(yè)務(wù)應(yīng)用程序時(shí)使用。一般來(lái)說(shuō)，開(kāi)始要將一個(gè)業(yè)務(wù)應(yīng)用程序確定為利用 MDD 工具構(gòu)建的，著重于需求，并且可以對(duì)該方法進(jìn)行一些調(diào)整的第一個(gè)項(xiàng)目。一旦開(kāi)始開(kāi)發(fā)了，就可以將 MDD 工具用于構(gòu)建許多業(yè)務(wù)應(yīng)用程序了。對(duì)于兩個(gè)項(xiàng)目，謹(jǐn)慎地組織和計(jì)劃是非常重要的，特別是在一開(kāi)始的時(shí)候。在與開(kāi)發(fā)項(xiàng)目相關(guān)的平常問(wèn)題之上，存在著管理額外的內(nèi)部依賴(lài)集的需求。MDD 工具需求必須在應(yīng)用程序開(kāi)發(fā)人員需要它們之前進(jìn)行確認(rèn)和開(kāi)發(fā)。兩個(gè)項(xiàng)目的任務(wù)流要互相聯(lián)結(jié)的，這樣可以確保由 MDD 工具項(xiàng)目而來(lái)的交付產(chǎn)品是及時(shí)的。圖 1 展示了 MDD 項(xiàng)目中的任務(wù)流。陰影的任務(wù)可能在傳統(tǒng)項(xiàng)目中執(zhí)行。白色的任務(wù)是為具體項(xiàng)目構(gòu)建 MDD 工件的附加任務(wù)。圖 1. 開(kāi)發(fā) MDD 工件的步驟MDD 擁有極大地提高當(dāng)前主流軟件開(kāi)發(fā)實(shí)踐的潛能。表 2 展示了 MDD 方法的優(yōu)點(diǎn)。好處說(shuō)明增加了生產(chǎn)力通過(guò)由模型生成代碼和工件的方式，減少了軟件開(kāi)發(fā)的成本，同時(shí)增加了開(kāi)發(fā)人員的生產(chǎn)力。您必須考慮轉(zhuǎn)換開(kāi)發(fā)（或購(gòu)買(mǎi)）的成本，但謹(jǐn)慎的計(jì)劃可以幫助確保成本的整體減少?？删S護(hù)性許多解決方案組件是使用遺留平臺(tái)技術(shù)實(shí)現(xiàn)的，但組織不再掌握這方面的技術(shù)了。MDD 形成了可維護(hù)的架構(gòu)，在其中可以快速一致地做出變更，可以將組件更有效地移植到新技術(shù)上。 高層次的模型與不相關(guān)的實(shí)現(xiàn)細(xì)節(jié)無(wú)關(guān)，這使得處理底層平臺(tái)技術(shù)及其技術(shù)架構(gòu)中的變更更加容易。您可以通過(guò)更新轉(zhuǎn)換來(lái)變更實(shí)現(xiàn)的技術(shù)架構(gòu)。轉(zhuǎn)換被重復(fù)地應(yīng)用于原有的模型，用于生成依據(jù)新方法的實(shí)現(xiàn)工件。您可以在做出最終決策之前嘗試不同的想法。不好的決策很容易變更。人們經(jīng)常按照錯(cuò)誤的決策繼續(xù)進(jìn)行軟件項(xiàng)目，而成本過(guò)高難于修復(fù)。遺留系統(tǒng)的復(fù)用一貫地在 UML 中為現(xiàn)有的遺留平臺(tái)建模。如果有許多組件是在同一個(gè)遺留平臺(tái)上實(shí)現(xiàn)的，那么您可以開(kāi)發(fā)從組件到 UML 的逆向轉(zhuǎn)換。您可以將組件移植到新的平臺(tái)上，或者生成包裝器（wrapper），通過(guò)集成技術(shù)，例如 Web 服務(wù)，來(lái)訪問(wèn)遺留組件。適應(yīng)性由于已經(jīng)在自動(dòng)化方面進(jìn)行了投資，因此添加或修改業(yè)務(wù)功能就是很簡(jiǎn)單的了。當(dāng)添加新的業(yè)務(wù)功能時(shí)，您只需要開(kāi)發(fā)針對(duì)該功能的行為。生成實(shí)現(xiàn)工件所需的剩余信息可以在轉(zhuǎn)換中獲取。一致性手動(dòng)地應(yīng)用編碼實(shí)踐以及架構(gòu)決策是容易出錯(cuò)的。MDD 確保一致地生成工件?？芍貜?fù)性當(dāng)在程序或組織層應(yīng)用時(shí)，MDD 尤其強(qiáng)大，來(lái)自開(kāi)發(fā)轉(zhuǎn)換的投資回報(bào)在每次復(fù)用時(shí)都有所增加。使用經(jīng)過(guò)試驗(yàn)和測(cè)試的轉(zhuǎn)換還增加了開(kāi)發(fā)新功能的可預(yù)測(cè)性，并且減少了風(fēng)險(xiǎn)，因?yàn)榧軜?gòu)和技術(shù)問(wèn)題已經(jīng)解決了。改進(jìn)了涉眾的交流模型省略了與了解系統(tǒng)邏輯行為無(wú)關(guān)的實(shí)現(xiàn)細(xì)節(jié)。它們更接近于問(wèn)題領(lǐng)域，減少了涉眾所了解的概念，與表示解決方案所用語(yǔ)言之間的語(yǔ)義差異。簡(jiǎn)化了與業(yè)務(wù)目標(biāo)更好地結(jié)合的解決方案的交付。改進(jìn)了設(shè)計(jì)的交流模型幫助您在設(shè)計(jì)層上了解系統(tǒng)，引出了對(duì)系統(tǒng)的改進(jìn)的討論和交流。因?yàn)槟Ｐ褪窍到y(tǒng)定義的一部分，比起文檔，它們從不會(huì)過(guò)時(shí)，而且是可靠的。經(jīng)驗(yàn)獲取項(xiàng)目或組織經(jīng)常依靠重復(fù)地做出最佳實(shí)踐決策的重要專(zhuān)家。他們的經(jīng)驗(yàn)可以在模式和轉(zhuǎn)換中獲得，因此，他們不需要直接面對(duì)項(xiàng)目的其他成員。而且，有了伴隨轉(zhuǎn)換的充足文檔，即使當(dāng)專(zhuān)家離開(kāi)時(shí)，組織的經(jīng)驗(yàn)仍舊保留在模式和轉(zhuǎn)換中。模型可以作為長(zhǎng)期的資產(chǎn)模型是獲取組織的 IT 系統(tǒng)的功能的重要資產(chǎn)。高層的模型對(duì)最新平臺(tái)級(jí)上的變更具有彈性。它們只在業(yè)務(wù)需求變更時(shí)才發(fā)生變更。推遲技術(shù)決策的能力早期的應(yīng)用程序開(kāi)發(fā)針對(duì)建模活動(dòng)。您可以推遲具體技術(shù)平臺(tái)或產(chǎn)品版本的選擇，直到有更多的信息可用時(shí)再選擇。在出現(xiàn)極其長(zhǎng)的開(kāi)發(fā)循環(huán)（例如，航空交通管制系統(tǒng)）的領(lǐng)域中，這是至關(guān)重要的。在開(kāi)發(fā)開(kāi)始時(shí)，目標(biāo)平臺(tái)可能還不存在。表 2. MDD 好處探索模型驅(qū)動(dòng)開(kāi)發(fā) (MDD) 和相關(guān)方法2: 結(jié)合模式與建模以實(shí)現(xiàn)架構(gòu)驅(qū)動(dòng)開(kāi)發(fā)-明確地捕獲您的架構(gòu)決策Larry Yusuf 是在英國(guó) Hursley Labs 設(shè)計(jì)軟件團(tuán)隊(duì)策略和技術(shù)的解決方案設(shè)計(jì)師。他在業(yè)務(wù)集成和建模方面有四年的經(jīng)驗(yàn)，著重于業(yè)務(wù)過(guò)程管理、事件及解決方案管理，以及集成模式。他在這些方面寫(xiě)了大量文章并進(jìn)行大量演講。您可以通過(guò) 聯(lián)系 Larry。利用模式和模型驅(qū)動(dòng)開(kāi)發(fā)（model-driven development，MDD）可以進(jìn)行架構(gòu)驅(qū)動(dòng)開(kāi)發(fā)。這種開(kāi)發(fā)類(lèi)型可以使我們明確地獲得架構(gòu)決策，并且在系統(tǒng)中對(duì)架構(gòu)決策自動(dòng)化編碼。通過(guò)使用模式及 MDD，您可以減少工作中的復(fù)雜性，并且進(jìn)行按需設(shè)計(jì)及開(kāi)發(fā)。MDD 概述在 MDD 中，模型不僅用作框架或藍(lán)圖，而且作為通過(guò)變換的應(yīng)用來(lái)生成的有效實(shí)現(xiàn)所依據(jù)的主要工件。在 MDD 中，當(dāng)開(kāi)發(fā)新的軟件組件時(shí)，面向應(yīng)用領(lǐng)域的模型是主要焦點(diǎn)。代碼和其他領(lǐng)域工件是利用將來(lái)自建模專(zhuān)家和目標(biāo)領(lǐng)域?qū)＜业囊庖?jiàn)作為輸入的轉(zhuǎn)換來(lái)生成的。定義架構(gòu)和架構(gòu)風(fēng)格IEEE 將架構(gòu)定義為：軟件系統(tǒng)的架構(gòu)（在一個(gè)特定的時(shí)間點(diǎn)）是通過(guò)接口，那些由連續(xù)的較小組件和接口組成的組件，交互的重要組件進(jìn)行組織或結(jié)構(gòu)化的。架構(gòu)反映了有關(guān)功能在系統(tǒng)中如何分布，要使用哪些技術(shù)，及要采用哪些設(shè)計(jì)模式的決定。架構(gòu)包含了一組架構(gòu)原則和決定。有時(shí)候這些架構(gòu)原則被記錄下來(lái)，但常常推論的原因卻無(wú)從得知。在一些情況下，甚至沒(méi)有對(duì)架構(gòu)原則進(jìn)行過(guò)充分的考慮，這導(dǎo)致了糟糕或不一致的架構(gòu)。當(dāng)然，編寫(xiě)架構(gòu)原則是一個(gè)好的主意，但是如果可以更進(jìn)一步，并以變更或引入架構(gòu)原則會(huì)實(shí)際地改變系統(tǒng)架構(gòu)的方式獲取它們會(huì)怎樣呢？而且，如果能將那些同樣的原則應(yīng)用于多個(gè)組件、服務(wù)和解決方案會(huì)怎樣呢？這些優(yōu)勢(shì)是 MDD 所涉及的。MDD 還將架構(gòu)風(fēng)格自動(dòng)化。在 MDD 中，不僅僅簡(jiǎn)單地將所實(shí)現(xiàn)的解決方案的架構(gòu)原則、模式，和轉(zhuǎn)換編寫(xiě)為文檔。MDD 方法還要求明確地做出架構(gòu)決策。當(dāng)獲得了新的理解時(shí)，MDD 能夠更容易地矯正不好的決策。當(dāng)原則手工地應(yīng)用于整個(gè)系統(tǒng)中時(shí)，修改是很困難的。但如果在轉(zhuǎn)換中獲取，并被自動(dòng)地應(yīng)用，修改轉(zhuǎn)換和再生成是較容易的。在做出最終決策之前，嘗試許多其他選擇也是花費(fèi)較少成本的。當(dāng)通過(guò)重復(fù)地應(yīng)用模式和轉(zhuǎn)換以確定最佳匹配來(lái)驗(yàn)證解決方案滿足非功能需求時(shí)，該方法是有價(jià)值的。 了解模式在 MDD 中，利用具體領(lǐng)域的概念來(lái)建模。例如，在企業(yè)整合領(lǐng)域中，可能會(huì)用到消息、代理和適配器。應(yīng)用領(lǐng)域的詞匯中還常常包含模式。在企業(yè)整合領(lǐng)域中，可以保證交付和發(fā)布訂閱模式。這些模式不是單個(gè)的元素，而是引入元素和對(duì)其行為的約束之間的關(guān)系。每個(gè)模式都包含它所適用的環(huán)境的信息，以及它與其他模式的關(guān)系。軟件開(kāi)發(fā)的特點(diǎn)意味著，額外地將用模式語(yǔ)言進(jìn)行設(shè)計(jì)的過(guò)程自動(dòng)化是可行的。我們可以通過(guò)從較大的模式轉(zhuǎn)移到較小的模式來(lái)設(shè)計(jì)軟件系統(tǒng)，如圖 1 所示。通常，將建筑物的物理構(gòu)建自動(dòng)化是不可能的。然而，軟件系統(tǒng)是用根據(jù)實(shí)現(xiàn)模式自動(dòng)生成的信息工件構(gòu)建的。建筑者必須手工地應(yīng)用構(gòu)建模式，而軟件架構(gòu)師可以充分詳細(xì)地描述軟件實(shí)現(xiàn)模式，使在已知具體應(yīng)用環(huán)境的時(shí)候生成這些模式。如在圖 2 中所看到的，依據(jù)所選擇的模式和技術(shù)架構(gòu)原則，詳細(xì)的系統(tǒng)模型可以轉(zhuǎn)換為一組運(yùn)行時(shí)工件（源代碼、部署描述符，等等）。在某些情況下，可能會(huì)使用直接實(shí)現(xiàn)了應(yīng)用模式的實(shí)現(xiàn)模式。在其他情況下，可能要應(yīng)用多個(gè)較低層次的實(shí)現(xiàn)模式來(lái)實(shí)現(xiàn)應(yīng)用模式。結(jié)合模式與 MDD模式 與 MDD 的互補(bǔ)性是架構(gòu)驅(qū)動(dòng)開(kāi)發(fā)的關(guān)鍵。模式與 MDD 以下面兩種重要的方式相關(guān)聯(lián)： MDD 可以將模式的應(yīng)用自動(dòng)化。 傳統(tǒng)上，模式是以文檔的形式記錄下來(lái)，UML 常常幫助說(shuō)明模式。然后手工地應(yīng)用模式。 模式為 MDD 提供內(nèi)容。 MDD 讓您從設(shè)計(jì)良好的模型轉(zhuǎn)移到設(shè)計(jì)良好的實(shí)現(xiàn)上。模式在建模和實(shí)現(xiàn)層獲取最佳實(shí)踐。在不了解應(yīng)用領(lǐng)域的模式和實(shí)現(xiàn)領(lǐng)域的模式的情況下，MDD 是不可能的。軟件模式可以在抽象層中應(yīng)用，并可以跨抽象層應(yīng)用?？梢詫⒛Ｊ浇M合起來(lái)，為解決較大的問(wèn)題生成復(fù)合模式，并為覆蓋領(lǐng)域的最佳實(shí)踐生成模式語(yǔ)言。當(dāng)使用本文中的架構(gòu)驅(qū)動(dòng)的方法來(lái)開(kāi)發(fā)時(shí)，系統(tǒng)的設(shè)計(jì)就如圖 3 所顯示的那樣進(jìn)行。模式和 MDD 是填補(bǔ)商業(yè)和 IT 之間鴻溝，并確保商業(yè)價(jià)值交付的關(guān)鍵。模式及 MDD 的采用： 減少了響應(yīng)的時(shí)間 使隨需的設(shè)計(jì)和開(kāi)發(fā)成為可能 減少?gòu)?fù)雜性模式和 MDD 已經(jīng)成熟，并且正交付著切實(shí)的結(jié)果。探索模型驅(qū)動(dòng)開(kāi)發(fā) (MDD) 和相關(guān)方法3 : 進(jìn)一步研究模型驅(qū)動(dòng)開(kāi)發(fā)和其他行業(yè)方法Larry Yusuf 是 Software Group Strategy and Technology 的一名解決方案架構(gòu)師，在英國(guó)的 Hursley Labs 工作。他擁有 4 年的業(yè)務(wù)集成和建模經(jīng)驗(yàn)，重點(diǎn)進(jìn)行業(yè)務(wù)流程管理、事件和解決方案管理以及集成模式方面的工作。他撰寫(xiě)過(guò)這些方面的大量文章，并多次進(jìn)行相關(guān)演講。重溫模型驅(qū)動(dòng)開(kāi)發(fā)在 MDD 中，模型不僅用作綱要或藍(lán)圖，而且還用作主要的構(gòu)件，通過(guò)應(yīng)用轉(zhuǎn)換可以在這些構(gòu)件基礎(chǔ)上生成高效的實(shí)現(xiàn)。在 MDD 中，面向應(yīng)用領(lǐng)域的模型是開(kāi)發(fā)新軟件組件時(shí)的主要重點(diǎn)。代碼和其他目標(biāo)領(lǐng)域構(gòu)件通過(guò)轉(zhuǎn)換來(lái)生成，這些轉(zhuǎn)換是使用來(lái)自建模專(zhuān)家和目標(biāo)領(lǐng)域?qū)＜业妮斎雭?lái)設(shè)計(jì)的。 OMG 和模型驅(qū)動(dòng)架構(gòu)OMG 是負(fù)責(zé)制定企業(yè)應(yīng)用程序領(lǐng)域的互操作性標(biāo)準(zhǔn)的開(kāi)放協(xié)會(huì)。OMG 負(fù)責(zé)開(kāi)發(fā)作為 MDD 核心的統(tǒng)一建模語(yǔ)言（Unified Modeling Language，UML），同時(shí)還推動(dòng)模型驅(qū)動(dòng)架構(gòu)（model-driven architecture，MDA）活動(dòng)。MDA 是 MDD 方法的一種形式化法。根據(jù) OMG 的定義，MDA 是一種在自動(dòng)化的工具和服務(wù)支持下組織和管理企業(yè)體系結(jié)構(gòu)的方法，并同時(shí)用于定義模型和促進(jìn)不同模型類(lèi)型之間的轉(zhuǎn)換。術(shù)語(yǔ) MDA 和 MDD 經(jīng)常交換使用。在本文中，MDD 指的是由軟件開(kāi)發(fā)人員執(zhí)行的活動(dòng)。MDA 保留用于其正式的 OMG 定義，此定義更多地集中于創(chuàng)建一個(gè)可在其中實(shí)行 MDD 的正式框架。OMG 的 MDA 指南將 MDA 描述為具有三個(gè)主要目標(biāo)： 可移植性 互操作性 可重用性其目的是通過(guò)將系統(tǒng)的操作規(guī)范與在特定平臺(tái)上實(shí)現(xiàn)系統(tǒng)的方法細(xì)節(jié)分離，從而實(shí)現(xiàn)這些目標(biāo)。MDA 使得工具能夠通過(guò)執(zhí)行以下任務(wù)來(lái)幫助滿足這些目標(biāo)： 指定與平臺(tái)無(wú)關(guān)的系統(tǒng) 指定平臺(tái) 為系統(tǒng)選擇平臺(tái) 將系統(tǒng)規(guī)范轉(zhuǎn)換為針對(duì)特定平臺(tái)的規(guī)范MDA 模型MDA 定義了三種模型： 計(jì)算獨(dú)立模型（Computation-Independent Model，CIM）描述系統(tǒng)的需求和將在其中使用系統(tǒng)的業(yè)務(wù)上下文。此模型通常描述系統(tǒng)將用于做什么，而不描述如何實(shí)現(xiàn)系統(tǒng)。CIM 通常用業(yè)務(wù)語(yǔ)言或領(lǐng)域特定語(yǔ)言來(lái)表示，僅當(dāng) IT 系統(tǒng)的使用是業(yè)務(wù)上下文的一部分時(shí)，才會(huì)非常有限地涉及到 IT 系統(tǒng)的使用。平臺(tái)獨(dú)立模型（Platform-Independent Model，PIM）描述如何構(gòu)造系統(tǒng)，而不涉及到用于實(shí)現(xiàn)模型的技術(shù)。此模型不描述用于為特定平臺(tái)構(gòu)建解決方案的機(jī)制。PIM 在由特定平臺(tái)實(shí)現(xiàn)時(shí)可能是適當(dāng)?shù)?，或者可能適合于多種平臺(tái)上的實(shí)現(xiàn)。平臺(tái)特定模型（Platform-Specific Model，PSM）從特定平臺(tái)的角度描述解決方案。其中包括如何實(shí)現(xiàn) CIM 和如何在特定平臺(tái)上完成該實(shí)現(xiàn)的細(xì)節(jié)。15種使用模型驅(qū)動(dòng)開(kāi)發(fā)MDD的理由2009-12-03 21:45轉(zhuǎn)自：1. MDD is faster MDD很快（真正快速開(kāi)發(fā)）在MDD應(yīng)用模型中能夠指定一個(gè)比傳統(tǒng)的編程語(yǔ)言更高的抽象層次。該模型能夠自動(dòng)轉(zhuǎn)化為可立即運(yùn)行工作的應(yīng)用程序（通過(guò)UML工具），生成可解釋/執(zhí)行模型代碼。模型中的每個(gè)元素代表了多行代碼，這樣使得模型在一個(gè)更高的抽象層次比相應(yīng)的代碼要精簡(jiǎn)得多，更能大道至簡(jiǎn)。2.MDD is more cost-effective MDD更具有成本優(yōu)勢(shì)因?yàn)镸DD快速開(kāi)發(fā)所以比較快地推向市場(chǎng)，MDD意味更少的人員 專(zhuān)家，更高的質(zhì)量，成本只是你學(xué)習(xí)MDD的成本以及工具采購(gòu)，使用MDD拓展和維護(hù)應(yīng)用程序的做法也更符合成本效益。通過(guò)更高級(jí)別模型閱讀，比較容易理解應(yīng)用程序。3. MDD leads to increased quality MDD引導(dǎo)質(zhì)量提高因?yàn)檐浖軜?gòu)是在一個(gè)更高模型級(jí)別定義，然后通過(guò)引擎或框架轉(zhuǎn)換成代碼，這樣我們能夠讓我們最優(yōu)秀的人員從事引擎和框架的開(kāi)發(fā)，進(jìn)而提高平臺(tái)的質(zhì)量。 我們?cè)陧?xiàng)目中學(xué)習(xí)到的最佳實(shí)踐模式可以被導(dǎo)引到引擎或框架代碼產(chǎn)生器中，這樣將被重用到所有使用MDD的項(xiàng)目中。4. MDD is less error-proneMDD很少出錯(cuò) 測(cè)試會(huì)浪費(fèi)很多時(shí)間，因?yàn)镸DD可以確保代碼的質(zhì)量，這樣讓你可以專(zhuān)注于測(cè)試應(yīng)用程序的特點(diǎn)功能即驗(yàn)收測(cè)試上，不必關(guān)注通用的一些測(cè)試項(xiàng)目，如基礎(chǔ)設(shè)施相關(guān)的技術(shù)問(wèn)題或安全漏洞。5. MDD leads to meaningful validationMDD引導(dǎo)有意義的校驗(yàn)業(yè)務(wù)驗(yàn)證都已經(jīng)在更高級(jí)別的模型中完成，編程工具只能幫助你驗(yàn)證代碼語(yǔ)言的錯(cuò)誤，不能驗(yàn)證業(yè)務(wù)上的錯(cuò)誤。6. MDD results in software being less sensitive for changes in personnelMDD可以不在乎人事變動(dòng)不需要特別的技術(shù)高手或架構(gòu)師就能夠建立軟件，節(jié)約人力成本。此外，如果有人加入一個(gè)項(xiàng)目，比較容易理解高層次的軟件應(yīng)用模型，這比試圖通過(guò)閱讀理解源代碼要輕松多(banq個(gè)人體會(huì)：本人曾經(jīng)只用兩三個(gè)月就理解了一個(gè)中型NGOSS級(jí)別的BOSS系統(tǒng)(通過(guò)together逆向工程模型化)，當(dāng)然也主要因?yàn)樵到y(tǒng)基于Hibernate的模型對(duì)象化，如果是純粹基于SQL就沒(méi)有這么幸運(yùn)了)。7.MDD empowers domain expertsMDD授權(quán)領(lǐng)域?qū)＜覙I(yè)務(wù)領(lǐng)域?qū)＜夷軌蜃⒅亟＃夹g(shù)專(zhuān)家可以專(zhuān)注于建立一個(gè)MDD需要的框架或DSL等工具。一個(gè)軟件系統(tǒng)不再只是程序編制就可以了，領(lǐng)域?qū)＜铱梢酝ㄟ^(guò)符號(hào)（如文字，圖形，表格）等直接表達(dá)他們對(duì)業(yè)務(wù)領(lǐng)域的深入理解 。8. MDD let advanced programmers focus on the hard stuff MDD能夠讓高級(jí)程序員專(zhuān)攻難關(guān)在MDD中，高級(jí)程序員的重復(fù)性工作要少得多，他們可以專(zhuān)注于他們工作的創(chuàng)造性方面。他們可以集中精力建設(shè)MDD的工具。他們還可以指導(dǎo)初級(jí)開(kāi)發(fā)或領(lǐng)域的專(zhuān)家，也可以申請(qǐng)領(lǐng)取困難攻關(guān)，領(lǐng)域?qū)＜铱梢詫?zhuān)注例如模型的圖形用戶界面，流程和業(yè)務(wù)規(guī)則。而應(yīng)用程序的集成部分（使用webservices，API調(diào)用，數(shù)據(jù)庫(kù)集成等）對(duì)于領(lǐng)域?qū)＜襾?lái)說(shuō)，存在太大困難，可以由高級(jí)程序員來(lái)完成。9. MDD bridges the gap between business and IT MDD在業(yè)務(wù)和IT之間架設(shè)了橋梁領(lǐng)域?qū)＜遥ɑ蛳到y(tǒng)分析師）可以直接參與業(yè)務(wù)發(fā)展進(jìn)程（見(jiàn)第7點(diǎn)）。技術(shù)專(zhuān)家（軟件應(yīng)用）可以在一個(gè)更高的層次定義盡可能和領(lǐng)域概念的定義聲明有關(guān)模型。通過(guò)在模型和模型實(shí)現(xiàn)之間定義一個(gè)重要的轉(zhuǎn)換機(jī)制，就可以在業(yè)務(wù)和IT技術(shù)之間建立一個(gè)橋梁，比如使用一個(gè)基于model-driven SOA的框架。10. MDD results in software being less sensitive for changes in business requirements MDD可以減少業(yè)務(wù)需求帶來(lái)改變的影響面對(duì)軟件開(kāi)發(fā)的問(wèn)題之一是業(yè)務(wù)需求經(jīng)常變化速度超過(guò)了軟件系統(tǒng)支持改變，這對(duì)于企業(yè)是一個(gè)重點(diǎn)戰(zhàn)略問(wèn)題：能夠保持足夠長(zhǎng)的時(shí)間調(diào)整其核心業(yè)務(wù)與IT流程。MDD使軟件開(kāi)發(fā)更快（見(jiàn)第1點(diǎn)），它也導(dǎo)致更容易改變應(yīng)用（因?yàn)榈?點(diǎn)和6）。如果在業(yè)務(wù)需求和軟件之間的存在一個(gè)聯(lián)系，那么應(yīng)用程序甚至有可能自動(dòng)適應(yīng)部分模型的變化（見(jiàn)第9點(diǎn)）11. MDD results in software being less sensitive for changes in technology MDD導(dǎo)致技術(shù)對(duì)變化不是太敏感技術(shù)變化很快， Java EE, SOA / SOBA, webservices,REST, SCA, OSGi等等，甚至遷移到云計(jì)算環(huán)境，當(dāng)您希望您的應(yīng)用程序遷移到其他技術(shù)時(shí)，MDD可以確保你不必改變你的應(yīng)用模型，。唯一需要改變的代碼生成器（或DSL解釋器）。改變后的代碼生成器（或添加額外的代碼生成選項(xiàng)）可以幫助所有的應(yīng)用程序模型直接轉(zhuǎn)換成基于新技術(shù)架構(gòu)的代碼。12. MDD really enforces architecture MDD增強(qiáng)架構(gòu)當(dāng)使用MDD開(kāi)發(fā)軟件應(yīng)用程序，保證符合選定架構(gòu)。你可以真正實(shí)現(xiàn)架構(gòu)標(biāo)準(zhǔn)化， 構(gòu)建架構(gòu)原則Constructional architecture principles能夠知道設(shè)計(jì)構(gòu)建，并且能夠反映在代碼生成器或解釋器中。13. MDD captures domain knowledge MDD可以截獲領(lǐng)域知識(shí)關(guān)于MDD的優(yōu)點(diǎn)是，你不是只創(chuàng)建軟件，但你也捕捉正式高層次的領(lǐng)域知識(shí)模型。在大多數(shù)情況下這方面的知識(shí)是不明確，見(jiàn)文章基于DDD的DSL14. MDD provides up-to-date documentation MDD提供最新的文檔當(dāng)使用MDD是，您不會(huì)遭遇不完整或過(guò)時(shí)的文件，因?yàn)樵撃Ｐ褪褂谜_的抽象，可以讓領(lǐng)域?qū)＜液涂蛻舳寄芸炊?5. MDD enables to focus on business problems instead of technology MDD能夠關(guān)注業(yè)務(wù)而不是技術(shù)停止討論使用WS-* 或者 REST，MDD能夠讓你專(zhuān)注于業(yè)務(wù)問(wèn)題如何解決，而不是著眼于如何解決這些問(wèn)題的技術(shù)支撐。模型驅(qū)動(dòng)開(kāi)發(fā)的誤解和挑戰(zhàn) 2009年11月30日 來(lái)源： 作者：Bertrand Portier, Lee Ackerman 1-挑戰(zhàn)：方法不當(dāng)且不可用 過(guò)去，MDD的一個(gè)關(guān)鍵抑制因素是人們實(shí)施活動(dòng)的時(shí)候沒(méi)有現(xiàn)成的MDD最佳實(shí)踐。比如說(shuō)，人們?cè)陂喿x有關(guān)如何執(zhí)行特定任務(wù)（諸如設(shè)計(jì)高可用的解決方案）的過(guò)程文檔時(shí)，文檔里并沒(méi)有任何MDD的內(nèi)容。為了得到MDD實(shí)踐，人們不得不到論文或書(shū)本里去找，然后再應(yīng)用到現(xiàn)有的非MDD文檔上。如今，MDD從業(yè)者在進(jìn)行日常工作時(shí)，可用的MDD指南已經(jīng)越來(lái)越多，而且那些信息嵌在他們每天使用的工具中。我們先看看開(kāi)發(fā)過(guò)程，它包括利用MDD原則的“工具向?qū)А弊罴褜?shí)踐，這些“工具向?qū)А彪`屬于整個(gè)方法和過(guò)程。 以前還有另一個(gè)阻礙因素，就是MDD與特定開(kāi)發(fā)方法過(guò)度摻雜，人們無(wú)法提取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)景中是不可能的。 2-挑戰(zhàn)：基礎(chǔ)設(shè)施和工具不能從MDD獲益 近幾年，我們看到建模工具已不局限于對(duì)特定圖形符號(hào)（比如UML）的支持了，經(jīng)過(guò)發(fā)展，它已然能幫助從業(yè)者完成工作。這些工具不僅支持圖形建模符號(hào)，也內(nèi)置了MDD特性，這些特性有利于：業(yè)務(wù)編排高質(zhì)量 提高的生產(chǎn)率 改善的溝通 影響分析 讓我們以設(shè)計(jì)模式為例，來(lái)說(shuō)明工具如何給MDD帶來(lái)了活力。假設(shè)某本書(shū)中描述了設(shè)計(jì)模式，我們將其稱(chēng)為模式規(guī)范。該規(guī)范非常有用。它描述了模式的使用時(shí)機(jī)、模式的特征，以及使用模式的好處和意義。模式規(guī)范能幫助人們理解模式并做出恰當(dāng)?shù)倪x擇。但模式規(guī)范并不能確保設(shè)計(jì)的高質(zhì)量和生產(chǎn)率的提高。為了從中受益，你必須將這些模式“自動(dòng)化”。我們將其稱(chēng)為模式實(shí)現(xiàn)，也就是模式規(guī)范在工具中的可復(fù)用編輯。使用模式實(shí)現(xiàn)，設(shè)計(jì)者可以將模式快速應(yīng)用到他們的設(shè)計(jì)中，也能確保這些應(yīng)用準(zhǔn)確無(wú)誤。 領(lǐng)域獨(dú)立的工具不太可能內(nèi)置領(lǐng)域所需的所有MDD工件。工具除了提供開(kāi)箱即用的MDD工件外（比如一組設(shè)計(jì)模式實(shí)現(xiàn)），也允許你擴(kuò)展現(xiàn)有的工件、創(chuàng)建自己的工件?，F(xiàn)在的工具包含“擴(kuò)展框架”，以及最佳實(shí)踐、模板和API。Rational Software Architect之類(lèi)的工具還允許你構(gòu)建適用于領(lǐng)域的MDD工件（例如模式實(shí)現(xiàn)、規(guī)則、約束等）。 既然你能構(gòu)建這些MDD工件，那么基于資產(chǎn)的開(kāi)發(fā)（ABD）就能讓你與他人共享工件、提升復(fù)用的實(shí)踐和基礎(chǔ)設(shè)施。換句話說(shuō)，ABD最佳實(shí)踐和基礎(chǔ)設(shè)施的改進(jìn)支撐了MDD的采用進(jìn)程。諸如Rational Asset Manager的可復(fù)用資產(chǎn)庫(kù)能讓你管理可復(fù)用的軟件工件，讓開(kāi)發(fā)社區(qū)共享和復(fù)用工件。試想一個(gè)為領(lǐng)域創(chuàng)建的模式實(shí)現(xiàn)，你現(xiàn)在可以把它提交到資產(chǎn)庫(kù)中，該模式經(jīng)過(guò)評(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)的正確版本。3-誤解：MDD=UML？ 有一個(gè)誤解是MDD意味著你必須使用統(tǒng)一建模語(yǔ)言（UML）現(xiàn)狀如此，完全是因?yàn)閬?lái)自對(duì)象管理組織（OMG）的UML規(guī)范進(jìn)行了這樣的描述。消除這一誤解的方法有很多。 打消這種念頭的第一種方法是用MDD的方法工作，這只需要你在執(zhí)行任務(wù)時(shí)把模型作為關(guān)鍵的工件使用，并使用利用這些模型的自動(dòng)化機(jī)制。在這種情況下，模型是用語(yǔ)言簡(jiǎn)化了的現(xiàn)實(shí)，而這些語(yǔ)言具有定義良好的語(yǔ)法和語(yǔ)義。因此，可以在MDD中使用的語(yǔ)言有很多，而不僅僅是UML。 在大多數(shù)情況下，我們確實(shí)要為手頭上的任務(wù)選擇合適的工具。如果我們的MDD需要標(biāo)準(zhǔn)化、為人熟知、被廣泛支持的語(yǔ)言，那UML就是一個(gè)不錯(cuò)的選擇。UML也是可擴(kuò)展的。嚴(yán)格來(lái)說(shuō)，它能通過(guò)配置（提供定制的元素、屬性和約束）進(jìn)行定制。這能讓UML對(duì)所作的工作來(lái)說(shuō)變得具體，也能讓語(yǔ)言更加易學(xué)易用。增強(qiáng)建模語(yǔ)言可用性或針對(duì)性的另一種方式是創(chuàng)建你自己的領(lǐng)域特定語(yǔ)言（DSL）。要記住的是，我們受益于使用的語(yǔ)言和創(chuàng)建的模型。為了指導(dǎo)投資，我們要權(quán)衡以下問(wèn)題： 是否能有效地設(shè)計(jì)和理解解空間？ 能否輕松地和其他人溝通？ 是否能基于已經(jīng)創(chuàng)建好的模型生成方案的其他部分？ 能否有效利用開(kāi)發(fā)生命期之外的結(jié)果？ 是否能從實(shí)現(xiàn)追溯到設(shè)計(jì)？甚至需求？ 4-誤解：MDD放之四海而皆準(zhǔn) 根據(jù)前面的誤解可以看出，MDD顯然不是放之四海而皆準(zhǔn)的解決方法，任何非預(yù)設(shè)的生產(chǎn)線工具集都可以用來(lái)構(gòu)建產(chǎn)品。MDD就是用模型為特定情況增加價(jià)值，它適用于特定領(lǐng)域，跟你所開(kāi)發(fā)的軟件類(lèi)型也是配套的。因此，我們能在自己的場(chǎng)景中看到很多使用MDD、有意義的方式。 5-誤解：圖表就是模型 MDD中關(guān)鍵的一點(diǎn)是要認(rèn)識(shí)到我們?cè)趧?chuàng)建模型正如前面所討論的，模型是用語(yǔ)言簡(jiǎn)化現(xiàn)實(shí)，該語(yǔ)言要具有良好定義的語(yǔ)法和語(yǔ)義。我們?cè)谀Ｐ椭锌梢园l(fā)現(xiàn)大量模型元素和一組圖表。每種圖表都提供了模型元素之上的一個(gè)視圖。每個(gè)模型元素屬于零或多個(gè)圖表。我們要關(guān)注模型元素它們是什么？有哪些關(guān)系？有什么屬性？我們通常使用圖表來(lái)幫助我們理清這些問(wèn)題。此外，我們還將圖表作為和其他人溝通的方式。但模型的關(guān)鍵信息存在于模型元素中因?yàn)檫@能讓我們生成所需的視圖、創(chuàng)建所需的圖表，從模型生成其他元素。如果MDD只是圖表，那工具能畫(huà)出漂亮的圖片就能滿足我們的需求了。這并不是說(shuō)圖表不重要。創(chuàng)建模型和圖表的工具需要進(jìn)行調(diào)整，以適合目標(biāo)受眾。 6-誤解：代碼就是模型，模型就是代碼 以前對(duì)MDD的誤解之一就是它只能應(yīng)用于代碼。MDD基本上被局限在一個(gè)較低的抽象層次，因此它的影響也很有限。很多人只用MDD工具“可視化”代碼（也就是將代碼圖形化的逆向轉(zhuǎn)換）。這樣是有好處的，比如說(shuō)，更好地理解大段代碼，以及組件或類(lèi)之間的關(guān)系。但撇開(kāi)這些來(lái)說(shuō)，代碼可視化并不能獲得先前討論的那些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)審開(kāi)發(fā)團(tuán)隊(duì)開(kāi)發(fā)的代碼，代碼的可視化視圖就能讓他們對(duì)代碼和設(shè)計(jì)進(jìn)行比較，因?yàn)榭梢暬Y(jié)果和設(shè)計(jì)使用了相同的可視化技術(shù)（比如UML類(lèi)）。不過(guò)，盡管可視化結(jié)果和設(shè)計(jì)用相同的語(yǔ)言表示，但兩者之間仍然有很大差距，因?yàn)樗鼈兯幍某橄髮哟尾煌?。MDD工具憑借可視化、可追蹤性、分析和發(fā)現(xiàn)功能、重構(gòu)支持能幫助設(shè)計(jì)師完成工作。一旦標(biāo)注出設(shè)計(jì)和代碼之間有分歧的地方，人工干預(yù)就必不可少了，設(shè)計(jì)師就要和開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行溝通。這能提升價(jià)值，但仍然無(wú)法完全擁有MDD的優(yōu)勢(shì)。為了支持分析和溝通，需要增加時(shí)間和精力，而且每個(gè)項(xiàng)目都需要投入多次。 另一方面會(huì)出現(xiàn)這樣的情況：人們熱衷于模型和MDD，甚至僅僅為了建模而建模，卻忘了把模型轉(zhuǎn)換成可操作或可執(zhí)行的內(nèi)容。架構(gòu)師可以和利益相關(guān)者、設(shè)計(jì)者和開(kāi)發(fā)人員溝通，但你仍然不能完全受益于MDD。在你策劃MDD的策略和方法時(shí)，要思考一下如何利用模型。譬如，部署方案最終用什么平臺(tái)？如何提高代碼質(zhì)量和開(kāi)發(fā)人員的生產(chǎn)率？是否能將模型轉(zhuǎn)換成代碼存根？ 另外，模型所包含的有用設(shè)計(jì)信息要多于生成代碼所需的信息，所以我們還要看看其它方式，來(lái)利用這些已捕獲的重要而有價(jià)值的信息。這包括文檔的生成、測(cè)試用例、部署腳本等，這樣就能顯著提高項(xiàng)目的整體生產(chǎn)率。眾所周知，實(shí)際的代碼編寫(xiě)只是整個(gè)項(xiàng)目的一部分工作而已。 沒(méi)有什么銀彈。所需的代碼并非都能自動(dòng)生成（除非你的領(lǐng)域非常小）。最后，你必須處理模型和代碼，MDD則會(huì)指導(dǎo)你利用模型、保持代碼與模型之間的同步。 不過(guò)雙向工程怎么樣呢？如何利用自動(dòng)化保持不同抽象層次之間的模型同步呢？這也是一般方案中較為棘手的問(wèn)題。例如，從較高層次的模型向較低層次的模型轉(zhuǎn)換時(shí)，許多元素會(huì)展開(kāi)一個(gè)元素會(huì)在較低層次上演化出多個(gè)元素。一旦創(chuàng)建了較高層次的模型，用戶就可以更新、移除、添加較低層次上的模型元素。那又該如何映射回較高層次的模型去呢？若干組詳細(xì)的元素又怎樣轉(zhuǎn)換/映射到少量的高層次元素呢？面臨這樣的挑戰(zhàn)，就很有必要想清楚，追求的這種方法到底是不是開(kāi)發(fā)方法的一部分。 由于修改極可能在代碼級(jí)別發(fā)生，所以若沒(méi)有保持模型和代碼一致的方法，模型很快就只剩文檔了。最近，Rational Software Architect之類(lèi)的工具在“保持一致”方面有了很大的改進(jìn)，提供了可視化代碼、比較和合并的功能。請(qǐng)注意，用于協(xié)調(diào)這些變化的方法比工具化的能力更為重要，這和治理也是相關(guān)的。舉例來(lái)說(shuō)，架構(gòu)師看到了代碼和模型之間的差異，怎么辦呢？去和開(kāi)發(fā)人員討論？讓開(kāi)發(fā)人員修改代碼？還是架構(gòu)師修改模型？正如你所看到的，這些都不是完全自動(dòng)化的方法。7-挑戰(zhàn)：平臺(tái)無(wú)關(guān)性面臨挑戰(zhàn) 雖然不確定平臺(tái)無(wú)關(guān)性發(fā)生的時(shí)間或原因，但是在高層次上進(jìn)行建模、然后生成解決方案的想法已經(jīng)引起了廣泛關(guān)注?；蛟S平臺(tái)無(wú)關(guān)性來(lái)自于MDA的平臺(tái)無(wú)關(guān)模型，也或許來(lái)自其它地方。不管來(lái)源如何，都要認(rèn)識(shí)到很難從很高層次的內(nèi)容進(jìn)行延展，也很難將一種表示定位到許多不同類(lèi)型的實(shí)現(xiàn)上去。已經(jīng)有一些解決方案能讓用戶利用模型生成全部的結(jié)果代碼了。但在那些情況下，也正如前面小節(jié)中所討論的，工具化對(duì)領(lǐng)域來(lái)說(shuō)很有針對(duì)性，而且利用了一組約束、規(guī)則和假設(shè)才使轉(zhuǎn)變成為可能。解決方案空間比較狹小，這樣才為生成高層次的內(nèi)容提供了可能性。隨著解決方案空間的擴(kuò)展，生成會(huì)變得越來(lái)越困難。 就連遷移到DSL上也會(huì)提出這樣的問(wèn)題：使用相同的模型作為輸入，生成不同的底層實(shí)現(xiàn)有多容易。在利用DSL的時(shí)候，關(guān)鍵應(yīng)該是具體的領(lǐng)域和當(dāng)前的項(xiàng)目。正如從許多敏捷過(guò)程中（以及自己的經(jīng)驗(yàn)）學(xué)到的，過(guò)度工程化、計(jì)算每種可能性都要付出代價(jià)。這同樣適用于建模和使用的語(yǔ)言。針對(duì)具體領(lǐng)域并不一定就是什么壞事，事實(shí)上它反而是最佳利益。不過(guò)，創(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í)覺(jué)得拘束，反而在努力實(shí)現(xiàn)解決方案的時(shí)候感到自如。這些擔(dān)心并非都是合理的，但還是要聽(tīng)出“弦外之音”。我們需要保證每個(gè)團(tuán)隊(duì)成員都能發(fā)揮最大的作用。 即使在處理模型的時(shí)候，我們也需要底層實(shí)現(xiàn)的相關(guān)專(zhuān)業(yè)知識(shí)。應(yīng)該使用什么框架？這些框架如何整合？下面以模式為例進(jìn)行說(shuō)明。構(gòu)建模式實(shí)現(xiàn)的關(guān)鍵輸入是參考解決方案，也就是樣例，它用來(lái)決定模式實(shí)現(xiàn)應(yīng)該做什么以及怎么做。如果我們要構(gòu)建自己的模式實(shí)現(xiàn)，那誰(shuí)來(lái)構(gòu)建樣例？誰(shuí)來(lái)判定該樣例是不是解決問(wèn)題的最佳方式？既然期望能簡(jiǎn)化建模體驗(yàn)，那又由誰(shuí)來(lái)給出規(guī)則、假設(shè)和約束呢？又該怎樣把它們編輯到人人都要用的工具中呢？這些問(wèn)題都強(qiáng)調(diào)，有很多地方都需要專(zhuān)業(yè)知識(shí)、創(chuàng)造性、以及解決問(wèn)題的技巧。MDD策劃、啟動(dòng)時(shí)有一點(diǎn)非常重要，那就是與團(tuán)隊(duì)成員溝通這些挑戰(zhàn)，并確保每個(gè)成員都能以有建設(shè)性、有效率的方式為項(xiàng)目效力。 9-挑戰(zhàn)：沒(méi)有可利用的內(nèi)容 和其它相對(duì)比較新的方法一樣，在最佳實(shí)踐被充分理解和基礎(chǔ)設(shè)施就位之前，產(chǎn)出的內(nèi)容都很有限?，F(xiàn)在MDD在軟件行業(yè)越來(lái)越成熟，有了越來(lái)越多的推進(jìn)力，可以看到，高質(zhì)量的MDD內(nèi)容和資產(chǎn)也越來(lái)越多。讓這些內(nèi)容從一開(kāi)始就可用，對(duì)采用MDD來(lái)說(shuō)是至關(guān)重要的。 10-誤解：MDD僅用于開(kāi)發(fā) 構(gòu)建軟件解決方案的時(shí)候，使用模型來(lái)指定架構(gòu)、關(guān)聯(lián)的服務(wù)和組件具有很大的價(jià)值，從解決方案的其它方面來(lái)說(shuō)也是如此。但這僅僅是MDD給組織帶來(lái)的一部分價(jià)值。要想利用模型并從中獲益，就沒(méi)必要把使用范圍限定得這么窄。此外，我們還能利用模型來(lái)支持規(guī)范一致性。模型能提供易于理解的表示，詳細(xì)說(shuō)明結(jié)果方案如何支持規(guī)范要求。比如說(shuō)，要表明組織是如何對(duì)細(xì)分客戶群、業(yè)務(wù)范圍（LOB）或渠道持續(xù)應(yīng)用某規(guī)則的，就能用模型來(lái)實(shí)現(xiàn)這一規(guī)范需求。只提供代碼到文檔的一致性并不足以成為一個(gè)最佳的方案?？偨Y(jié) MDD帶來(lái)了很多好處，它能促進(jìn)溝通、改進(jìn)業(yè)務(wù)編排、提升質(zhì)量、提高生產(chǎn)率。如果你以前關(guān)注過(guò)MDD，那現(xiàn)在應(yīng)該換個(gè)眼光來(lái)看待MDD。如果你從沒(méi)關(guān)注過(guò)MDD，那現(xiàn)在可是關(guān)注的好時(shí)機(jī)，因?yàn)楣ぞ咧С忠呀?jīng)很成熟了。 MDD在工具集里有點(diǎn)兒與眾不同就像你不會(huì)只使用一種語(yǔ)言，或是某種語(yǔ)言的單個(gè)庫(kù)，為了達(dá)到目的，你需要選擇合適的MDD方法和角度。如果