问题域、问题空间
语法、语义
案例、方法、工具
DSL脚本(DSL Script):每一个DSL的核心都是一个域模型,它定义了这一语言所代表的各种概念,这些概念的属性,以及它们之间的关系
在问题域中用于构建、配置或者其他用途的一种语言
可以是文本,也可以是图形,或者两者混合使用
图形语言不只是图表,否则使用Visio之类的画图软件就行了,它实际上是要创建模型,这个模型要能够从概念上描绘你正在创建的系统,并对其内容进行图表化的表示。一个模型可以同时由多个图表来表示,每个图表表示模型的某个方面
文本语言用户输入,可以快速的打字。
文本语言的优势在于可以进行比较和合并,而图形表达式可以更容易的看出内容之间的关联。
相对来说,文本语言比图形复杂
语义模型(Semantic Model)
DSL脚本的一种内存完整表示
有时候这个就是抽象语法树(AST)
分离Parse和Generate
生成代码(Generated Code):DSL的一个最重要的应用是用来生产简单的文本形式的工件,例如源代码、数据库脚本
DSL脚本的一种可执行表示
解释语义模型
高级别的重用:如果仅适用通用编程语言,则每次只能解决一个问题,但如果应用特定领域开发方法设计并实现一些特殊语言,每个特殊语言可以高效地解决一类相似的问题
使用DSL的软件架构可以跨接软件工程过程各阶段之间的鸿沟,特别是通过代码生成可以很好的进行设计和实现阶段的衔接
让领域专家参与开发过程,不仅仅是需求阶段,架构阶段也需要参与
通过在问题空间工作,可以让不熟悉如何实现技术的人,包括商业人士,也能够更了解模型
使用DSL表达的模型,可以在问题空间这个较高的抽象层次进行验证,这意味着可以在开发周期的更早期发现因为理解和表述而造成的错误。
一个模型中具备了重要的业务知识,将解决方案从一种技术迁移到另一种技术,或在同一技术的不同版本之间迁移,就变的相对容易。一般通过适当修改生成器或解释器就可以做到。
外部DSL可以摆脱内部DSL寄宿语言的限制,可以重新设计一种新的语言,但是增加了学习新的语言的学习成本,并且需要工具的支持。
为了降低风险,我们并不是马上就从头开始开发框架及其DSL,而是应该从现有的可以在某些应用中使用的代码开始,逐步的对其进行参数化,逐步的发现那些在不同应用中变化的部分,然后使这些部分依赖于DSL。
自上而下的方法倾向于快速建立一个完整且自包含的模型,具有更长远的考虑,有助于保证结构的一致性。但是从另一方面看,这种方法容易导致在概念层设计出很复杂的模型,并且该模型难于实现。因此在实际应用中,将自上而下和自下而上两种方法交替使用会更有效。采用渐进的方式可以避免早期投入过大风险,但是需要定期进行一致性检查。
识别可变性与发现DSL:DSL是用你的框架具体的实现你的体系架构模式中可变的部分
开发领域模型捕获可变性
定义标记:在适当的地方使用常见标记法或与标记法相关的约定
开发验证的约束:识别树形之间的依赖性,认出快照中的强制或禁止的循环
开发并演进框架:理解你的DSL针对的代码体系结构,并在框架中编写它
测试DSL:包括验证的约束与规则、生成器与命令、以及生成的代码
演化和移植DSL:确保旧的模型在新版本的DSL中能够使用
识别好的DSL:范围、最小性、常见标记法,适度的冗余,合理的使用句法空间,使用用户术语
<a href="http://book.douban.com/subject/4775030/"></a>
<a target="_blank" href="http://www.jot.fm/issues/issue_2009_09/column6/index.html">Best Practices for DSLs and Model-Driven Development </a>
<a href="http://www.cnblogs.com/zhoujg/archive/2010/07/26/1785002.html">读书笔记:Visual Studio DSL工具特定领域开发指南</a>
<a href="http://www.cnblogs.com/zhoujg/archive/2010/05/19/1739145.html">DSL的演进</a>
本文转自 jingen_zhou 51CTO博客,原文链接:http://blog.51cto.com/zhoujg/403112,如需转载请自行联系原作者