“模型驅動開發”——體會一下這幾個詞。它們說出了這個不斷變化的工業中一個新的改變。這里不是說一種革命，而是一種緩慢的變化，但是肯定會滲透到我們開發系統的方式中。這種推動將降低代碼的重要性，并且專注于一些開發中的真正事情：最終的應用程序被期望怎樣工作，并確保你能夠根據客戶的需求可靠地建立起它來。
模型驅動開發是更偉大視景MDA 中的一部分。MDA 是模型驅動體系架構（Model-Driven Architecture）的簡稱，由對象管理組織OMG（Object Management Group）所驅動。MDA 表示了一種模型驅動開發方法的概念框架。然而，盡管完整的MDA 還沒有成為現實，模型驅動開發現在已成為可能。實際上，它已以較低級的形式存在了較長一段時間，所以我們并不是在做某種新的東西（當然，除非你在聽某些市場人員的宣傳）。
沒有魔法
如果模型驅動開發這么好的話，為什么不是每個人立刻加入到這個潮流中來呢？
首先，模型驅動開發不是一個銀子彈，能神奇地解決你所有的問題�？傆心橙诵枰崿F系統的功能，并且還找不到任何工具來完成這一點。所有你能發現的工具只是使這項工作更容易和直接一些。
第二，采用模型驅動開發，并不只是在開發項目的過程中更換一種工具。它還必須和已根深蒂固的開發過程結合起來（如果沒有的話，你就可以開始使用模型驅動開發了；否則你就只能改善當前的情況），但實際上更重要的是，你還會擔心它對現有應用程序的影響。決定改用基于模型的方法前確實需要有一些仔細的考慮，并且，一般說來，為了不影響當前的工作，你只會在新項目中改變開發方法。
第三，你還需要獲得那些使用工具的人們的支持（你需要一些工具來應用模型驅動開發）。開發人員常會認為“模型驅動開發不是編程”而回避它，并且當心他們的工作難于被接受。他們還可能擔心模型驅動開發將會使他們以前辛苦學來的一些技巧過時。他們的擔心也不是完全沒有理由。采用模型驅動開發后，市場確實很有可能會減少對那些精通好幾種編程語言的開發人員的需求。但是另一方面，所有好的開發人員，首先和最主要的是，他們是問題的解決者。他們感興趣的是盡可能地為手邊的主要問題找到新的更好的解決方案。模型驅動開發激動人心的一點就是它允許開發人員集中精力于解決主要的設計問題，增加新的、酷的功能；而不是花費他們的主要時間于改正語法錯誤，防止內存泄露，或無休止的低級bug 上。
還有第四點，它也是第三點的一個結果，工具必須足夠的好。不幸的是，有時用戶對工具期待太多，或工具提供廠商承諾過多，實際上卻不能交付。這兩種情況都很容易使用戶放棄模型驅動開發的想法。你確實需要保證工具能夠滿足你的需求。
可視化軟件工程
模型驅動開發的基礎是模型和表達模型的語言。模型提供了這樣一種能力，能夠一致性地顯示這個系統的不同視圖。一個常見的錯誤是認為模型驅動開發是模型和代碼之間的一種關系，通過代碼實現了模型。確實很多情況下，這二者是等同的，但它大大限制了我們的視野。
模型的一個主要用途消除開發過程中各參與方之間的隔閡，需求工程師，系統分析員，軟件開發人員和測試者都可以使用同一種語言。你可以注意到，他們可能專注于語言的不同部分，以滿足他們的需要，但他們都會共用一些基本的結構，并對他們正工作的系統有一個統一的認識。而且使用統一的語言有助于消除角色間的界限，使得在項目的不同階段人員轉換到被需要的角色更加容易。還有另外一些人需要知道項目的進展情況，包括項目領導、經理和評估委員會。更重要的是，用戶也需要知道什么將會被交付，需要加入到整個開發過程中，與創建系統的不同人員進行交流。一種圖形建模語言，比如UML，使得各參與方之間的交流成為可能，幫助架起參與方與某些系統復雜功能之間的橋梁。模型驅動開發正逐漸獲得公司高級管理者注意，其中的一個主要原因就是這種能夠逐漸增加用戶、管理層和大的組織機構參與的能力。
那么編程將會怎樣呢？它不再需要了嗎？我們在這之前提及了一下，現在再詳細討論它。給模型提供足夠的信息，工具就能生成大部分和全部系統所需要的代碼。請注意，如果你用工具去生成全部的代碼，這就相當于編譯你的模型。在很多方面，這都類似于當從匯編編程轉到C 編程時發生的模式轉換，開始的時候，存在一定的懷疑，特別是那些匯編語言編程者。對于模型驅動開發，我們說的也是一種相似的模式轉換，建模語言代替了編程語言，用建模語言來實現系統。這主要是因為建模語言正變得更有表現力，允許用戶能夠指定詳細的系統行為。而且，主機上的確認和驗證技術能用于檢查系統的正確性。在模型中，一般說來你會忽略掉那些令人不快的細節，比如分布式，代理和內存管理，并且讓工具去生成它們的代碼。這些都表明你還需要對系統的行為進行建模（或者如果你愿意，也可以編程），但你可以在更抽象的層次上進行，關注于系統的重要功能。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/