DSL編程:有人將DSL編程稱之為聲明式(Declarative)編程。
DSL是在模型之上建立的一種更加靈活的對 模型化的理解和使用方式。
語義模型是DSL的核心。
內部DSL:用通用語言的語法表示DSL,需要安裝某種風格使用這種語言。
外部DSL:在主程序設計語言之外,用一種單獨的語言表示領域專有語言。可以是定制語法,或者遵循另外一種語法,如XML。
DSL定義:針對某一領域,具有受限表達性的一種計算機程序設計語言。
外部DSL:不同於應用系統主要使用語言(c,java,c++,c#)的語言。
內部DSL:通用語言的特定用法。內部DSL通常是一段合法的程序,但是具有特定的風格。而且只用到了語言一部分特性。Ruby形成了顯著的DSL文化。后面好好看看。
http://blog.csdn.net/chgaowei/article/details/21296483
MDSF:DSL(Domain Specific Language)介紹
前面介紹過模型驅動開發(MDD)、軟件工廠(Software factory)、特定領域建模 DSM(Domain Specific)等都是高抽象的開發方法,這些方法使用的語言都是特定領域語言(DSL)。相比於通用目的語言(C#/C++/JAVA/Delphi等)而言,DSL是一種為了特定任務而設計的開發語言,例如SQL是一種專門處理數據庫的語言,本篇將介紹一下DSL。
一種語言
我們熟知的編程語言(如C#、Ruby等)是一種通用語言,MDA基於UML語言,而模型驅動開發(MDD)基於DSL。DSL是一種基於特定領域的語言,它使工作更貼近於客戶的理解,而不是實現本身,這樣有利於開發過程中,所有參與人員使用同一種語言進行交流。
DSML
DSML是 特定領域模型語言(domain-specific modelling language),之前介紹的MetaEdit+使用的DSM方法中使用的就是DSML,它是一種可以用來構建圖形模型的一種DSL,DSM的GOPPRR就是一個用來構建DSML語言的元模型。
DSL涉及內容
- 問題域、問題空間
- 語法、語義
- 案例、方法、工具
DSL架構
- DSL腳本(DSL Script):每一個DSL的核心都是一個域模型,它定義了這一語言所代表的各種概念,這些概念的屬性,以及它們之間的關系
- 在問題域中用於構建、配置或者其他用途的一種語言
- 可以是文本,也可以是圖形,或者兩者混合使用
- 圖形語言不只是圖表,否則使用Visio之類的畫圖軟件就行了,它實際上是要創建模型,這個模型要能夠從概念上描繪你正在創建的系統,並對其內容進行圖表化的表示。一個模型可以同時由多個圖表來表示,每個圖表表示模型的某個方面
- 文本語言用戶輸入,可以快速的打字。
- 文本語言的優勢在於可以進行比較和合並,而圖形表達式可以更容易的看出內容之間的關聯。
- 相對來說,文本語言比圖形復雜
- 語義模型(Semantic Model)
- DSL腳本的一種內存完整表示
- 有時候這個就是抽象語法樹(AST)
- 分離Parse和Generate
- 生成代碼(Generated Code):DSL的一個最重要的應用是用來生產簡單的文本形式的工件,例如源代碼、數據庫腳本
- DSL腳本的一種可執行表示
- 解釋語義模型
DSL應用的優點
- 高級別的重用:如果僅適用通用編程語言,則每次只能解決一個問題,但如果應用特定領域開發方法設計並實現一些特殊語言,每個特殊語言可以高效地解決一類相似的問題
- 使用DSL的軟件架構可以跨接軟件工程過程各階段之間的鴻溝,特別是通過代碼生成可以很好的進行設計和實現階段的銜接
- 讓領域專家參與開發過程,不僅僅是需求階段,架構階段也需要參與
- 通過在問題空間工作,可以讓不熟悉如何實現技術的人,包括商業人士,也能夠更了解模型
- 使用DSL表達的模型,可以在問題空間這個較高的抽象層次進行驗證,這意味着可以在開發周期的更早期發現因為理解和表述而造成的錯誤。
- 一個模型中具備了重要的業務知識,將解決方案從一種技術遷移到另一種技術,或在同一技術的不同版本之間遷移,就變的相對容易。一般通過適當修改生成器或解釋器就可以做到。
樣式(Styles)
之前在信息系統開發平台OpenExpressApp: 之 如何實現自動化測試框架介紹了在OEA上使用Ruby語法實現的一個自動化測試語言,這個就屬於內部DSL。而在OpenExpressApp對建模支持的初步計划中介紹的MetaModelEngie屬於外部DSL。
外部DSL可以擺脫內部DSL寄宿語言的限制,可以重新設計一種新的語言,但是增加了學習新的語言的學習成本,並且需要工具的支持。
設計DSL
為了降低風險,我們並不是馬上就從頭開始開發框架及其DSL,而是應該從現有的可以在某些應用中使用的代碼開始,逐步的對其進行參數化,逐步的發現那些在不同應用中變化的部分,然后使這些部分依賴於DSL。
自上而下的方法傾向於快速建立一個完整且自包含的模型,具有更長遠的考慮,有助於保證結構的一致性。但是從另一方面看,這種方法容易導致在概念層設計出很復雜的模型,並且該模型難於實現。因此在實際應用中,將自上而下和自下而上兩種方法交替使用會更有效。采用漸進的方式可以避免早期投入過大風險,但是需要定期進行一致性檢查。
在《Visual Studio DSL工具特定領域開發指南》書中對設計DSL做了如下步驟:
- 識別可變性與發現DSL:DSL是用你的框架具體的實現你的體系架構模式中可變的部分
- 開發領域模型捕獲可變性
- 定義標記:在適當的地方使用常見標記法或與標記法相關的約定
- 開發驗證的約束:識別樹形之間的依賴性,認出快照中的強制或禁止的循環
- 開發並演進框架:理解你的DSL針對的代碼體系結構,並在框架中編寫它
- 測試DSL:包括驗證的約束與規則、生成器與命令、以及生成的代碼
- 演化和移植DSL:確保舊的模型在新版本的DSL中能夠使用
- 識別好的DSL:范圍、最小性、常見標記法,適度的冗余,合理的使用句法空間,使用用戶術語
應用場景
......
書籍
Martin Fowler花了幾年時間寫了一本DSL的書籍《Domain Specific Languages》,我還沒有看,感興趣的可以先看看它在網站上寫的系列文章 Domain Specific Languages
Best Practices for DSLs and Model-Driven Development
讀書筆記:Visual Studio DSL工具特定領域開發指南
DSL的演進
http://www.educity.cn/wenda/130355.html