DSM：面向建模專家或系統分析師的解決方案

當DSL（Domain-Specific Languages）誕生時，不少人比較激動，歡呼一個新的語言時代到臨。其實，這不是計算機領域的新語言，而是一種新的建模語言。
　　DSL是一種專門供領域建模專家（也就是系統分析師）使用的語言，這些領域專家不同于程序高手，他們有一套自己認知世界和表達世界的思維和方式（如UML），因此，他們不感興趣于軟件設計細節，希望軟件能夠按照他們分析設計的結果去運行和執行就可以了。

　　其實，現如今在Java和.NET分治天下軟件語言之時，不可能再有對和Java等同樣層次的新語言的新需求， 因為大家都已經經歷過優美動人的語言故事，新語言陷阱是每個人理性的認識。因此，聰明的專家發現，DSL特征不是發明新輪子，而是提供一種面向領域建模方便的工具語言，類似UML，但UML不能再勝任這樣的工作（見UML和Java的阻抗），MDA有待進一步完善提高，建模專家需要的是DSM（Domain-Specific Modeling）。

提高開發生產效率

　　按照軟件生產效率研究（Software Productivity Research）, Java的平均生產率僅比BASIC高20%, C++不會好過Java，當今Java和.NET語言紛爭帶給程序員很多選擇的痛苦，我們把更多注意力關注在對象、組件和框架（objects, components, and frameworks）等概念上，但是開發效率并沒有比20年前有顯著增長，從匯編語言到BASIC是400%的增長，在當前21世紀，我們應該怎樣完成這樣的跳躍式發展？

UML能否勝任？

　　象UML這樣傳統的建模語言并不能提高軟件生產率，你需要在兩處維護信息系統：語言代碼和UML模型，為保持一致來回奔命，我們知道，java/C++/BASIC都將被編譯器編譯成匯編語言，可是有人看到過這樣情形：開發者手工更改編譯器并且試圖使C++代碼和匯編代碼保持一致？可是這種現象會發生在UML模型和語言代碼之間。

　　當然，UML有其優點：作為能夠迅速被讀懂的虛擬符號，UML世界現在吵吵嚷嚷，一半人發現UML并不能表達他們在建模時需要的一些概念，因此要求將入一些新的東西進入UML核心標準；可是還有另外一些人則認為UML太復雜，應該從UML核心元素中減去一些元素。當UML試圖適合所有的人時，它就不能大力提高其抽象層次了。

　　這是目前基于UML的大多數MDA工具發生尷尬現象。MDA工具制造商發現它們僅僅能夠比手工編碼提高生產效率(study)35%，遠沒有我們希望的400%革命性跳躍。

什么是DSM？

　　只有提高抽象層次，將軟件直接面向建模專家或系統分析師，然后運用自動化代碼生成技術，這樣才能高質量大幅度快速開發出軟件系統，在OOPSLA（領先的軟件工程會議），大家認為DSM可能是一種解決方案。Bill Gates 和 Grady Booch也發表過同樣觀點。

　　DSM意味Domain-Specific Modeling領域定義建模，通過使用領域概念直接指定解決方案，DSM提高了超越程序代碼之上的抽象層次，最終軟件產品將從高層次的設計中直接自動產生，這樣一個自動過程是可以實現的，因為 語言和代碼產生器可以滿足某一個公司或領域的需求，建模專家使用定義這個自動機器，而程序員只管使用即可。

　　實踐經驗已經證明：DSM比現有方式（包括基于UML的MDA）效率提高5-10倍，正如Booch說的那樣： ”當建模概念可以直接映射到領域Domain，而不是計算機具體技術概念時，MDA的價值已經完成“，這句話的意思是： MDA已經證明我們可以直接從領域專家Domain觀點直接建模，而不必拘束于具體的計算機技術概念，或者說：直接由有經驗的系統分析師/建模專家分析設計進而生產出軟件系統已經被MDA證明是可行的了，MDA的價值也就在于此，
Booch等人寄希望于使用DSM替代MDA。

　　由建模專家定義有關領域和組件的代碼產生器，這樣做的結果要好于大多數開發者手工開發。從MDA教訓來看，大家認識到：不可能有“一種尺寸適合所有身材”的代碼產生方案，不必象MDA那樣疲于往來返工，DSM所做的正如將代碼編譯成匯編語言的編譯器所做的。

DSM工作原理

　　首先，每個行業都有一些經驗豐富行業專家，俗成系統分析師，他們對業務系統非常熟悉，但是不太了解軟件技術，由這些專家定義一個包含域概念和規則的域定義語言（domain-specific language），并且定義這些域概念和規則映射到代碼產生器的映射；實際上這些建模專家所要表達的就是：我們的需求應該看上去是怎樣？我是怎么寫代碼的。

　　然后，其他開發者就使用建模語言根據前面定義的規則制作模型，最后，代碼將自動產生，因為建模專家參與了定義代碼生產器，這樣最后產生的代碼質量要高于正常程序員手工完成的代碼質量。更重要的是，制作模型將比手工寫代碼更快。

與MDA區別

　　DSM與MDA主要區別是：MDA工具商自己定義代碼產生器，這些代碼產生器第一次看非常好，但是以后就變樣走味了，難以適應需求的變化。.

　　DSM中，由你控制DSL和代碼產生器，這些工具可以被調整以適應你自己的系統，作為開發者，你只需要定義DSL和實現自己的代碼產生器，所有這一切都是由你來定義控制，正所謂定制性強。

DSL案例

　　TSS上最近的文章“Improving Developer Productivity with Lightweight Domain Specific Modeling”演示了如何使用DSM實現輕量建模的過程，共分五步：

ArgoUML 能夠用作定義DSL模型，開發人員能夠設計DSL模型適合問題域。

將 ArgoUML模型轉為Eclipse模型格式的Ecore.

使用Eclipse的插件JET模板定義代碼如何產生。

Ecore模型輸入到模板定義中，然后再定義Ecore模型中的模型元素和帶有Merlin的JET模板之間映射。

最后結果是產生最終代碼。

參考文章：

Improving Developer Productivity with Lightweight Domain Specific Modeling

Why DSM?

Ruby On Rails 與Jdon Framework架構比較

原文轉自：http://www.anti-gravitydesign.com