MDSF：特定領域建模 DSM（Domain Specific）介紹

文章目錄

• 兩件事情
• 四個執行個體化層級
• DSM樣本
• 商業價值
• 構建DSM的成本
• 什麼時候需要建立一個DSM方案
• DSM開發角色
• DSM的是與不是...
• DSM與其他建模方法的不同
• DSM定義和DSM使用
• DSM應用流程
• 特定領域語言定義
• 領域架構
• DSM工具比較
• DSM與軟體工廠、產品線工程的關係

     在讀書筆記：Visual Studio DSL工具特定領域開發指南中介紹了特定領域開發的一些相關技術有：模型驅動開發 MDA、面向語言編程 LOP
、語言工作平台 Language Workbenches
、特定領域建模 DSM
、產生式編程 Generative Rrogramming
、意圖軟體 Intentional Software 、軟體工廠 SOftware Factories。本篇通過書籍Domain-Specific Modeling來給大家介紹一下特定領域建模DSM，這也是OpenExpressApp採用的特定領域開發方法。如果你想提高軟體開發的產量和品質，那麼這本書你應該看看。

　　Domain-Specific Modeling (DSM)是軟體開發中新的方法，它有希望能夠大幅度的提高開發速度並簡化軟體開發。在過去十年中，早期採用DSM的人已經提高了五到十倍的速度，這本書是第一本介紹DSM的書籍，涉及領域建模、語言定義、代碼產生和DSL工具等內容，它還向大家介紹了不同領域的樣本 ，展示了在團隊中如何使用DSM來改善軟體開發。

　　這本書介紹了DSM是什麼，為什麼它有用，以及如何成功的產生和使用DSM方案來提高產量和品質。全書分為四部分：

1. DSM介紹以及帶來的商業價值
2. DSM基礎：定義以及DSM架構
3. DSM樣本：手機、保險等實際案例
4. 產生DSM方案：語言定義、組建定義、領域架構、定義流程、DSM工具和DSM的使用

以下我與大家分享一下DSM的主要內容。

兩件事情

1. 提高抽象層級，從【專用的方案域的技術相關內容】轉到【直接使用問題域的業務概念和規則】
   
2. 允許使用者選擇某種語言或其他形式來產生最終產品。基於這點，MDA和DSM的區別之一：MDA不能由使用者控制產生的程式碼，而DSM運行使用者完全控制產生步驟。DSM不期望產生所有的代碼，但是可以基於模型產生大部分通用代碼。DSM產生的程式碼等工件時可讀、有效、滿足功能要求的基於應用特定的資產。

      

 三個核心元素　

有經驗的開發人員都會有下面簡單的實踐，也可以說是三個基本的開發實踐價值觀：

• 不重複自己
• 如果重複三次，則考慮自動化
• 定製方案比通用方案要更好

 　DSM完成符合上面的實踐，通過定製化的建模方式去應對問題領域，通過抽象和產生解決了產量和品質的問題。它需要有經驗的業務和開發人員開發三種東西：可以在建模工具中基於特定領域的模型語言來對應用進行建模，然後DSM引擎會使用特定領域的代碼產生器來產生架構代碼或可執行檔模型在領域架構上運行。

1. 特定領域的模型語言
2. 特定領域的代碼產生器
3. 領域架構

 

四個執行個體化層級

DSM是一種模型驅動開發方法，所以它的核心就是模型，從模型定義到建模到模型運行，這幾步中模型一個分為四個層級：

1. 元元模型：基於元模型定義之上的高層次抽象模型，用於構建元模型。MetaEdit+使用的是GPPPRR，這也是OpenExpressApp的MetaModelEngine採用的元元模型
2. 元模型：基於業務領域的抽象模型，例如實體等
3. 模型：如果元模型是定義，那麼模型就是元模型的執行個體，例如Author是一個實體
4. 應用：模型定義是一個具體的業務類別，應用則是模型的一個執行個體，例如Steven Kelly是一個作者

DSM樣本

書中介紹了不同行業的一些樣本，讀者可以有針對性看與自己類似行業的樣本。更多樣本見：http://www.metacase.com/cases/dsm_examples.html

商業價值

• 縮短上市時間，開發生產力能夠提高5-10倍
• 由於使用的是經過驗證的工具，產品品質顯著提高
• 積累領域知識
• ......

構建DSM的成本

DSM先期投入的成本比通用模型要多，實際上有時成本會更低，因為前期投入的人力會比通用目的建模的人少。但是，到了後期可以看出明顯使用特定領域建模比通用目的建模所需要的成本要低很多。

  

什麼時候需要建立一個DSM方案

基於產品架構演變出來的產品變數越多，則構建一個DSM方案所帶來價值越大：很多管理軟體都是基於變數來做的個人化需求，這其實是項目型產品，做的項目越多，投資報酬率越大

DSM開發角色

　　在以前的基於組件開發技術中，有人開發組件，有人使用組件。在產品線開發中，一部分人開發所有項目通用的平台，一部分人使用這些資產進行開發。DSM開發組織機構與這些方法類似，也區分兩種不同的角色：開發DSM解決方案的角色和使用DSM進行開發的角色。　　

　　在DSM中我們可以定義出以下幾種角色：

1. 領域專家：具備問題域的豐富業務知識，他們熟悉領域內的術語、概念、流程和規則。當開發業務系統時，專家懂得業務知識。如果是技術領域，則架構師和開發經理就是領域專家。
2. 特定模型語言開發人員：設計元模型，並提供使用指導和模型樣本。語言開發人員與領域專家和關鍵DSM使用者關係密切。
3. 產生器開發人員：從模型轉換成代碼。通常產生器開發人員也是定義領域架構的人員。
4. 領域架構開發人員：通常是有應用架構的具有豐富經驗的架構師和開發人員。他們提供在目標環境下的參考實現，並且已經開發過組件架構、類庫等。
5. 建模工具開發人員：實現模型語言和代碼產生器的建模工具。 
6. DSM使用者：模型在進階別層次上進行抽象，很大程度上支援測試、產品管理、QA、實施、銷售和客戶等多種人員進行溝通。DSM使用者人數做多，他們使用建模工具進行開發。
   • 業務工程師使用模型建立業務領域概念
   • IT工程師使用模型擴充技術模型
   • 測試人員使用模型建立測試案例
   • 部署人員可以生產安裝程式
   • 管理員可以擷取度量資訊

DSM的是與不是...

• 不是代碼的模型表現，而是特定領域業務
• 不是模型草圖或者文檔，而是模型作為核心資產來驅動後續產品開發
• 不是重型建模開發，而是基於需要部分建模產生產品，迭代進行
• 不是產生需要更改的代碼，而是產生領域架構需要的執行模型或者代碼，不修改產生的工件
• 不是產生不足夠的代碼，而是自己完成控制產生環節
• 不使用模型和代碼的雙向同步，而只是由模型產生代碼

DSM與其他建模方法的不同

• UML
  UML是一種大家熟知的設計語言，它其原來類、方法、屬性等代碼世界的概念。它對開發的自動化和提高產能上基本上沒有提供協助，它沒有提高抽象層級來支援代碼產生
• 可執行UML
  可執行UML的目標是把UML作為一種程式設計語言 ，它的抽象層級很低，不支援特定的問題域
• MDA
  MDA不能由使用者控制產生的程式碼，而DSM運行使用者完全控制產生步驟。
• 定製化UML
  OCL、MOF都是特定的語言，這些語言也沒有明確的特定語言概念

DSM定義和DSM使用

DSM定義都是元模型的定義，包括語言、產生器以及領域架構的編寫。DSM定義完成後，通過建模產生模型，產生代碼，運行在領域架構上。由於不可能所有代碼都完成組建，所有還需要開發人員編寫一些代碼，這部分代碼有可能會獨立存在，也有可能會併入領域架構。

DSM應用流程

1. 驗證DSM概念：瞭解DSM，可以就小範圍已知的領域嘗試特定領域概念進行開發，例如對UI部分使用UI模型
2. 開展一個實驗項目：找到一個項目作為DSM方案的實驗基地，開發DSM項目的第一版
3. 使用DSM方案：大範圍的推廣DSM方案
4. DSM維護：不斷完善、維護DSM項目

　　以上幾步其實也是技術推廣的較為通用的步驟，都是小範圍驗證、項目實驗、大範圍推廣再就是持續應用完善。OpenExpressApp目前處在第2步，系統的DSM方案支援才剛開始。

特定領域語言定義

領域架構

DSM工具比較

DSM與軟體工廠、產品線工程的關係

　　在以前我也介紹過軟體工廠包括以下幾部分：產品線工程、架構架構、模型驅動開發和指導。而DSM是一種模型驅動開發方法，它屬於軟體工程的一個模型驅動方法，這也是OpenExpressApp採用的主要方法

　　在軟體產品線工程方法 － 四個主要方法原則中介紹過產品線工程的成本（規模化產品開發方法－產品線工程 .pdf），DSM作為模型驅動開發的一種方法支援產品線工程，所以產品線工程的經濟圖與上面介紹的DSM成本圖也有所相似，都是必須有前期的投入成本，一般等做到三個項目後才可以見到回報：

  

DSM：使用MetaEdit+編寫Family Tree Modeling Language

MetaModelEngine：元模型引擎開發思路

Domain-specific modelling language and code generator for developing repository-based Eclipse plug-ins

 

歡迎轉載，轉載請註明：轉載自周金根 [ http://zhoujg.cnblogs.com/ ]