Domain-Specific Modeling and Model Driven Architecture DSM （領域定義建模）和 MDA （模型驅動架構） 模型在軟體開發中的角色 當今資訊系統的開發越來越複雜，而且所涉及到的領域也越來越廣，開發者必須掌握許多不同的技術，包括流行的面向物件技術， XML ，指令碼語言，介面定義語言，過程定義語言，資料庫定義和查詢等等。要把來自於問題領域的需求轉換成解決方案需要對許多架構和協議的深刻理解。再者，終端使用者常常期望結果是高執行效率的，易用的，易擴充套件的，而且對於不可知且不可靠的網路連線是安全的，這可是件苦差事。 在軟體開發之外的一些領域，例如電子產品（電視機， HiFi 音響，照相機）等等，我們可以看到低成本和高可靠性的情況。在過去的幾十年裡，製造行業一直採用這樣的流程：通過一連串複雜的步驟來製造一臺電視機或汽車，其中有很多步驟是完全自動化的。 我們會喜歡使用相同的原理來構築軟體，不同的是我們沒有開發出能夠允許有效分離軟體中關注點的軟體說明語言。儘管我們使用不同的程式開發語言來書寫應用邏輯，來完成不同的開發任務。例如：使用 XML 在應用元件中傳遞資料，使用 SQL 存取資料，使用 WSDL 來說明面向 Web 應用的元件的介面等等，但是它們中沒有一個直接針對終端使用者所面對的業務問題。 本文將要介紹的軟體構築技術是 domain-specific languages （領域定義語言，簡稱 DSL ）的開發。 DSL 被設計為直接面向它所要解決的問題領域。在某種程度上，它能夠代替編碼，資料交換，配置等工作，我們常把這類語言稱為建模語言。我們使用這些語言來針對問題領域進行建模。 模型裡的每個元素都對映到現實領域中的一個概念，很多年以來，模型對於定義 IT 系統如何來儲存資料一直是很重要的，現在，模型的應用更廣泛，例如對業務過程建模，服務的部署，資料中心等等。模型受歡迎是因為它能夠很好地表述問題從而避免陷入技術細節中。當技術變得越來越複雜的時候，模型是提高生產力的必須手段。模型的另一個好處是可以讓程式設計師和問題領域的專家使用同樣的表述方法，這有助於團隊成員間的溝通。我們也可以把使用模型看作彌合技術和業務之間縫隙的方法。 在過去的幾年裡，新的建模方法開始合併，特別是在 MDA 的旗幟和能夠提高軟體開發生產力及軟體可移植性的承諾下， OMG 對 UML 和一些相關技術進行了大力的推廣。但是我們必須看到 80 年代的 CASE 工具的結果，顯然， CASE 已經無法兌現當初的諾言，對於 MDA 我們仍然十分懷疑，除非能夠證明它對於我們所面對的問題找到了新的道路，不再重蹈 CASE 工具的覆轍。在我看來只有模型，模式，框架等技術結合在一起才能夠避免象 CASE 工具那樣的失敗。 Domain-Specific Languages 如果我們想通過運用模型來使領域專家能更容易地解決問題，那麼模型就必須能夠清晰地描述問題領域。對於建模語言，就是指用來針對問題領域建模的標記和關係的定義。典型的，但不是必須的，建模語言可以是一組圖釋，一組由線條連線起來的節點，也可以是流程圖或者實體－關係圖。 模型通常被標記和文字元素所修飾，開發者需要細心地審視，理解掩蓋在這些修飾下的模型真正要表達的資訊。所以要能夠進行建模就必須明白每個元素相關細節。這意味著一旦成為具有專門的建模技能的人才就會帶來豐厚的回報。 有些人可能會認為正確的觀點是應該定義一個通用的建模語言，使用它來對所有的問題領域建模，同時要教會那些領域專家們學會使用這個通用建模語言。從 UML 得到的經驗來看，這樣作並不成功，後面我們將會討論 UML 。 現在，我們把那些被設計成用來對特定問題領域建模的建模語言稱作 domain-specific languages （領域 建模語言）。領域建模語言可以針對很多問題領域建立，例如：通訊，銀行業務，空間勘測等等。 無論如何，設計和使用領域建模語言只是模型被用作輔助軟體開發的很小一部分。模型可以被分析和驗證，轉換，通過很多步驟，被部署並執行軟體。這個過程包括開發，分析，驗證模型，在很多不同領域中，通過工具將模型進行轉換，直到部署系統完成。 在軟體系統的構築中，模型的一個對應物是框架，框架是適用於整個領域的程式碼實現框架，並且給多個系統間在相同領域的不同元素提供了擴充套件點。有很多框架的例子：從 GUI 到 ERP 的基礎結構和演算法。在所有的情況下，模型的角色是使用框架，給特定的應用定義擴充套件點。在這個層面上，我們可以認為建模語言是定義擴充套件點，使其契合到框架上，來適應使用者對問題的理解的一種方法。 另一個重要的對應物是模式，一個模式本質上是一個有很多小孔的模型，和如何將這些小孔用其他模型來填充的規則。有一種高效使用模式的方法：使用一個由許多小的模型組成的大的模型，或一個由其他型別的模型組裝起來的模型。 在軟體開發過程中運用模型，模式，框架，程式碼的至關重要的一點就是最終的結果必須是“敏捷“的。在程式碼和模型間必須不存在任何不可逆性和不連續性，在整個開發過程中必須能夠對可見的各種因素作出快速的反映，變化後重新產生最終結果。 CASE 的錯誤在於沒有針對問題領域使用框架，而是使用了龐大的，不可逆的程式碼生成過程，這樣使得開發者無法修改生成的程式碼，從而使整個方法完全失效。只有將模型，模式，框架結合在一起，並使它們無縫的整合進一個敏捷的開發過程中，才可以避免出現 CASE 方法那樣的缺陷。 運用模型，模式，框架的過程從整體上看起來製造業的很相似，我們可以把軟體開發看成一個價值鏈的概念：從供應商那裡取得輸入，利用自己的專業經驗為這些輸入增加價值，到鏈條的最後產生輸出。迄今為止，軟體的構造過程很少被看作這樣的一個鏈條，根本原因在於表述軟體的方式的限制，當代碼成為表述軟體的惟一的手段時，惟一和產品密切相關的人就是程式設計師。領域定義模型、模式和框架的開發應被納入軟體價值鏈，也就是產品線中。 在微軟，我們堅信建模將對軟體開發越來越重要，我們將在即將釋出的 Visual Studio 中整合建模功能，我們相信認真地根據目標客戶的技能來設計領域定義語言的本質是：我們要給客戶直觀的，敏捷，高效，無縫的建模體驗。我們的第一個建模產品的目標是能夠立即為我們的客戶提供高收益。在最近的微軟開發者大會上，我們展示了幫助開發者進行 SOA 的開發和部署的建模工具，關於這次展示的細節，可以在 http://msdn.microsoft.com/vstudio/enterprise 找到。 隨著時間的推移，我們將繼續擴充我們的建模工具來面向更多的領域，例如：程式碼視覺化、業務建模，還會把支援更多領域的工具整合進 Visual Studio 。更長遠的計劃是通過多個產品線，包括模型，框架，模式，工具，來整合完整的軟體開發過程。 Model Driven Architecture 在 IT 界，術語 MDA 一般是指在軟體開發過程中使用模型。 但事實上，OMG 把這個術語註冊為商標，並將其引申為特殊的使用OMG 的建模技術進行模型驅動開發的概念。使用的建模技術的核心是UML 和MOF （ Meta-Object Facility 元物件設施），本文的這部分將簡要討論MDA ，然後將關注MDA 中所包含的建模技術，特別是UML 和MOF ，還將討論MDA 中和我們相關的方法學。 MDA 的本質就是區別 Platform Independent Models (PIMs) 和 Platform Specific Models (PSMs) 。當使用 MDA 開發應用程式時，必須首先建立 PIM （平臺無關模型），然後使用標準對映，轉換到 PSM （平臺定義模型），最後，對映生成最終程式程式碼，依照 OMG 的 MDA 的 FAQ ： http://www.omg.org/mda “ UML 是 MDA 所使用的關鍵技術，任何使用 MDA 建立的應用程式都基於標準化的，平臺無關的 UML 模型。”這樣，就意味著應用程式的被定義為平臺無關的，這樣應用程式就是可移植的。這很容易讓人回想其 Java 所宣稱的“ write once run anywhere ”，試圖去構建一個平臺無關的框架，諸如 Swing UI 庫，必須在效能和平臺整合上作出折衷，在過去，這種折衷是很多產品失敗的根源，因為這些失敗，業界仍然非常懷疑 MDA 的宣言，在 OOPSLA 2003 上 MDA 的 session 就是佐證。 不過， MDA 的探索在某些應用程式方面是有幫助的，一些廠商已經向我們展示了基於 J2EE 的 Web 應用，建立包含了資料實體，元件的 UML 模型，再對映到各種 J2EE 應用。但是無論如何，就象前面所提到的，這對開發者意味著全面轉向敏捷開發，而且不能引起不必要的轉變和障礙，例如不可逆的程式碼生成過程和除錯上的問題。 擴充套件 MDA 到其他領域很困難， OMG 所定義的“平臺”的概念很模糊，真正的例子也就是 J2EE 。在軟體開發過程中使用模型的道路上，使用模型來建立 J2EE 應用是有效且使用的。事實上，幾乎沒有關於平臺無關模型和平臺依賴模型間的對映標準，現存的惟一一個也是針對 Java 平臺的，儘管還有很多非標準的，開發社群的實現聲稱支援其他平臺。 總而言之， MDA 起錯了名字，它不是體系結構，它是基於對相似平臺的抽象的模型驅動開發標準。 OMG 在向業界推動 MDA 的時候，並沒有採納關於整和模型，框架，模式和工具來支援軟體產品線的建議，而且，我們將看到， MDA 所基於的 UML 和 MOF 規約將會限制它的用途。 The Unified Modeling Language UML 是一種通用建模語言，它開發於 90 年代早期，由 Grady Booch, James Rumbaugh 和 Ivar Jacobson 合併成一個統一的圖形表示法。第一次標準化在 1997 年，經過了多次修訂，最近正在開發第二個版本，這個版本已經接近完成。 UML 是龐大且難於理解的，版本 2 更是如此，要向深入的理解 UML 必須先理解它怎樣被使用。我們借用 Martin Flower 在《 UML Distilled 》一書中分類， Marting 把 UML 的使用分為 : 用作草圖，用作 Blueprint ，用作程式語言。 把 UML 當作草圖使用非常流行，很多專案都在白板上使用 UML 畫草圖。把 UML 作為草圖使用的另一個含義是把試圖從面向物件設計中生成結構化的文件被看作是不妥當的。在這種情況下， UML 是非常成功的，它完全達到了消除了面向物件設計和圖解表示的不一致問題的目的。 把 UML 作為 Blueprint 使用提升了門檻，這時的目標是在開發過程中把多種 UML 模型結合起來。對於任何改動和自動化，都向系統地將 UML 模型轉換到原始碼，這也就意味這 UML 模型必須包含足夠的資訊，才能保證轉換是有效且完整的。 當我們嘗試這樣作的時候，會很快發現 UML 的問題，因為它不能很直接的轉換到我們所使用的技術，例如：一個 UML 類不能直接用來描述一個 C# 類，因為 UML 類並不能描述 C# 中的屬性的概念。類似的，一個 UML 介面不能直接用來描述一個 Java 介面，因為 UML 不包括 Java 中的靜態欄位的概念。從這一點來看，把 UML 作為草圖使用時，沒有任何問題，但是，當 UML 被用作開發一個類的製品時，要麼違反標準，要麼引入一些不和諧因素來修補這些不匹配的問題。 將 UML 作為程式語言由一些社群支援，但是他們不喜歡走到商業化的路上，在這裡我們不作討論。 讓我們再來觀察這些 UML 的主要使用方法：作為草圖和 Blueprint 。把標準表述為一組靈活的，可擴充套件的圖釋，並無縫地對映到開發所使用的技術，而且不存在任何不匹配的描述說明，這是非常有用的。只有從模型所表述的概念進行無縫且可逆的對映才會被大多數開發者所接收。“ UML 輪廓”採用允許有限度的對語言擴充套件來使藍圖具有可擴充套件性。但是實踐證明這種可擴充套件性是非常有限的，並且還不能提供無縫的從 UML 到時下流行技術的對映。 在微軟，我們的途徑是通過我們的建模工具，使用一些易識別的擴充套件的表示法來表示概念。同時，我們發現 UML 表示法還不夠清晰，我們對其進行了增補，例如：我們使 .NET 的類視覺化，可以包含更多資訊，更容易使用，而且使得圖釋的元素更精確。這保證了 .NET 中的術語和概念能夠在圖釋中清晰地表達。我們從客戶那裡得到的反饋是壓倒性的支援這種作法。儘管我們的圖釋法不是標準的 UML ，但是它所表達的含義對任何人而言都是非常容易理解的。 在 UML 所不針對的領域，我們必須建立新的約定，例如：設計器支援開發邏輯資料中心模型，這些模型被用來部署分散式系統，在這裡我們可以使用 UML 中所不支援或支援很少的概念，而且我們可以對這些領域建立一個規約。領域定義語言被用來開發 UML 所不支援的新領域，我們可以期望將這些規約合併到這些領域中。 我們可能會發現在對 UML2.0 作過大量的擴充套件後可能會導致一門建模語言的產生， SDL （ Specification and Description Language ，定義和解釋語言），廣泛用於通訊技術領域。我們期待看到在那些 UML 還沒有涉及到的領域的關於 UML 的圖釋約定和擴充套件的遠景。 Defining Languages and Interchanging Models 在 OMG 的 MDA 旗幟下還有另一個重要的技術： MOF 。 MOF 是一個比 UML 更加抽象和難以理解的技術。理解了這個還有更難理解的術語，象 metamodel （元模型）和 meta-metamodel （元－元模型），感謝還沒有出現 meta-meta-meta-model ，我們也會盡力阻止出現。 MOF 主要作兩個工作。第一，它是一個被設計成定義建模語言的領域定義建模語言：一個 MOF 模型是一個 MDA 建模語言的定義。第二，它是一種計算一個 MDA 模型如何被序列化到一個 XML 文件或 Java API 的機制。 一個領域的建模語言包含很多方面，它必須定義領域中的概念，必須把概念表示為圖形或文字，必須定義使用者如何與語言互動，必須定義一個模型是否合法，必須定義模型間如何互動。但是 MOF 僅僅定義了語言的基本概念，以及概念的模型如何儲存和互動。一種語言的 MOF 說明並沒有提供多少使用者真正關心的東西：語言所包含的模型是什麼，它看起來象什麼，使用者如何和模型互動。 在微軟，我們希望我們的語言能夠整合到 Visual Studio 包括 IntelliSense® ，工具欄，選單，屬性欄，和對 Debug 的支援，我們發現定義如何對概念建模在整個工作中只是一個次要的方面，而且我們的語言定義工具要整合到 Visual Studio 中要比 MOF 好。 事實上，儘管這是語言定義技術的通常的地位， MOF 仍然是一個儲存概念模型，並且使用 XMI （ XML Metadata Interchange ）在模型和 CORBA 和 Java API 之間轉換的主要技術。如果使用 MOF 來定義一種語言的概念，接下來就可以使用 XMI 的方法來進行對語言的基於 XML 的自動生成。 從這個方面看，這似乎是挺吸引人的，但是，還是有一些問題。首先， XML 的生成基於語言的定義，這也就意味著使用 UML1.4 標準進行的 XMI 序列化將無法被基於 UML2.0 的實現所理解，除非使用者在這些概念的觀點能夠保持前後一致。再者， XMI 本身就在變化，也就是說可能會出現對與同一個模型的不同 XMI 序列化版本。第三， MOF 的定義也在變化，它會為了對付不同的組合而不斷加入新的元素，這將導致 MOF 的版本具有不同的取向，而且無法完全一致。所以，雖然 XMI 宣稱為建模工具提供互操作性，但是實際情況是，除非每個工具都能夠支援 MOF ， XMI ， UML 標準下的所有可能的組合，工具之間的互動才是沒問題的。 XMI 的更深層次問題是，特別是對於舊版本，由機器生成的 XML 架構常常冗長且難以閱讀，這就迫使開發者們去尋求視覺化程度更高的，可轉換的技術來維護 XML 文件。 我們不認為 XMI 對於模型的序列化來說是正確的方法。 XML 正在變的成熟，市場上有大量的模式和工具。我們認為正確的方法是，對特定的建模語言有他自己特定的 XML 架構，並且提供工具來管理語言和序列化格式間如何自動解釋和對映。如果對一個特定領域進行標準化， XML 架構就可以是標準的，這是業界廣泛存在的觀點。之後，如果語言的定義發展了，可以在舊的 XML 架構上擴充，進行移植。 XMI 有效地阻止了這個清晰的思路發展，並導致了大量不相容的 XML 架構標準，和它的互操作的目的完全背離了。 簡而言之，微軟不支援 MOF 是因為下面的原因： 1. 它還不是個穩定的標準 2. 使用它來作為設計我們的工具的語言會產生我們不願看到的結果。 3. 支援 MOF 所沒有提供的元素需要商業級的實現，我們會繼續引入 MOF 定義的改動。 4. MOF 沒有實現自己的目標。 結論 本文討論了模型在軟體開發中的角色，特別是 domain-specific languages 的定義和使用，以及在產品線中的使用，同時對 OMG 的 MDA 作了總體的評價。我們確信在敏捷軟體開發過程中模型會得到更多的使用，我們正在構築工具和技術來支援這些開發。我們看到 UML 作為重要的一步，它的未來是基於圖釋的開發者間的約定，而且可以作為面向特定問題領域的領域定義語言的靈感。也看到 XML 是模型的表現和互動的關鍵技術，我們期望對領域內容的標準化能儘早開始。