還是原來我在blog中提到過的，微軟的思路：dsl，包括現在說的dsm，其實都是或者說來自mda的思路。
只不過是：
1) 不是用的uml的標準。
2) 現在通過領域限定來降低目前實現mda支援的難度。而且和微軟的大多數產品一樣，微軟做的東西易用性上會好一些，這一點足夠重要。
dsm規避了mda發展中的難題，不苛求在pim這個層面完全表達模型的細節。如果不限定領域的話，現有的模型描述語言以及約束描述如ocl，模型轉換語言qvt等都不能滿足一方面表達能力足夠，描述精確，一方面又足夠抽象，同時還能夠簡單易用的要求。這種情況下，dsm不失為乙個好辦法。
但我希望的是，千萬別因為這個中間產品做得好，就走到這裡就算了：），當然，這個操心有些提前了，現在中間產品還遠沒有做得好呢。
摘譯自
面向領域建模
dsm的**生成怎麼就比
uml好呢？
by juha-pekka tolvanen
軟體開發複雜性不斷提公升，這導致很多公司開始在他們的開發過程加入乙個新的階段：建模。目前進行設計的最知名的方法就是叫做uml的符號體系了。uml致力於提供**的視覺化表示。在開發實現之前進行設計的意義很大，因此開發團隊也希望能夠從模型中收穫更多，而不僅僅是作為文件和規約的替代品，最後並不反應最終的**情況。根據uml設計進行自動的**生成是乙個辦法，但現在這也是uml為人詬病的乙個短處，在實踐中，能夠生成的最終可用的**往往很少。
domain-specific modeling (dsm，面向領域建模) 是一種新的建模方式。和uml不同，dsm提供的建模結構更靠近現實世界的物件（譯註：即最終的**實現）一些。更重要地，dsm可以提供完全的**生成能力。這樣，開發人員可以更高效地開發應用程式。
看乙個例子
下面通過乙個例子來簡單比較一下dsm和uml吧：
構建乙個通過**進行會議註冊的應用程式，可以選擇付款方式，並可以瀏覽（view（譯註：view？通過**怎麼view？不過意思大家都知道就是了j））會議安排。
使用uml，我們會首先在乙個use case圖中表達該程式的外部需求，然後應用uml的類圖和順序圖、狀態圖等進行內部設計。
顯然，當我們深入到細節設計部分時，會有多種可能的設計方案，不同的開發者可能選擇不同的方案，這些方案未見得哪個就比哪個好多少。uml支援這些不同的設計，在得到正確的設計這一點上不能提供什麼幫助。畢竟uml不知道關於這個應用的任何知識。要得到正確的設計，開發者需要了解問題域（**），構建該應用程式的平台（例如symbian）以及如何正確地畫uml。
最後，在用13個uml圖中挑出一些做了設計之後，我們就進入了寫**的階段。自然地，我們希望可以從設計中生成盡可能多的**，但uml卻不能做到這一點。為什麼？uml是乙個通用的建模語言，這意味著不管你設計什麼樣的軟體，都可以用uml。也正是因為這一點，uml的發明者們需要做出很多妥協，來讓uml「quite good for everything but great for nothing」。結果就是：開發人員可以從uml中生成的有效**很少。在所有的建模完成之後，我們對系統有了乙個好的理解，但是，但是，沒有可執行的程式。不可避免地，在編碼實現和測試階段，我們會對設計有一些修改，但通常大家都懶得去更新涉及到的所有模型，這樣模型就過時了（譯註：模型的一致性維護一直是乙個問題）。
**生成器
dsm認為，開發者可以更有效地進行軟體設計，如果他們用的符號系統是面向目前開發的問題領域的。dsm支援開發者描述需要的各個方面，而且也不多描述一些無用的資訊。這些符號體系的提供以及到**的對映由公司的專家負責，其餘的開發人員就可以從他們的設計中自動生成完全的高質量的**。當然，這需要dsm工具的支援，這些工具將支援dsm語言的定義、使用和維護。這些工作將耗費數月以上。這些工具實際上已經有了，microsoft、metacase和xactium以及諸如eclipse gmf的框架等，都有這方面的支援。
使用為了我們的**這個問題域所特別定製的領域特定語言，我們可以建立乙個更有表現力的設計，中間使用的都是領域特定的概念，例如簡訊、佔線阿什麼的，每個都會有一些規則。
使用dsm，我們可以關注於尋找用領域概念表示的解決方案，而不是**。最終的描述捕獲了這個程式的所有需要的靜態和行為方面，可以完全從模型生成最後的程式。這和前面我們看到的uml模型是完全不同的。
領域特定建模支援機遇產品模型（models of the product）而不是基於**模型（models of the code）的快速開發。我們的**程式就是乙個例子。
考慮從設計到編碼的整個週期，dsm的實現不需要額外的投資，相反還會節省開發的資源。過去，所有的開發人員都使用問題域的概念來工作，然後手工地將這些工作對映到實現對應的概念上去。而在這些開發人員中，有些人做得好些，有些人則對映得差一些。因此，現在讓有經驗的開發人員來定義這些概念和對應的對映，這個工作只需進行一次，其他人用就好了。如果某個專家寫好了**生成器，用它生成的**比普通開發者手工寫出帶來**質量甚至還好一些。
鄧麗君的領域建模
建模競賽題第2賽季第22輪 請根據以下資訊畫出系統的分析類圖。6分 所有回答者都可以得分。總分數根據時間和答案質量綜合評定，回答時間靠後的分數打折扣，折扣係數0.05。舉例 第乙個答，答案質量得分4分，總分4分 第5個答，答案質量得分5分，總分5 1 5 1 0.05 4分。如果有人喜歡一首歌曲，他...
業務領域建模Domain Modeling
每個業務都有乙個對應的業務模型，這個業務模型設計的時候，完全不需要考慮任何軟體設計的思想，比如物件的抽象 繼承 儲存 效能，等。我們是從業務本身出發，分析業務邊界範圍內的各種業務概念，以及業務概念之間的關係，通常我們可以使用乙個業務模型的圖來表達這些業務概念以及業務概念之間的關係。那麼如何得到乙個業...
業務領域建模Domain Modeling
以您的工程實踐專案為例，在深入理解需求的基礎上進行業務領域建模domain modeling 最終畫出業務類圖，並說明業務類圖中每乙個類 屬性 方法的 對於有關聯類association class的情況要進一步給出關聯式資料庫的模型。記住 我們是對業務建模，不是對系統建模！我的工程實踐題目改成了 ...