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 IndependentModels (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規約將會限制它的用途。