[翻译] DSL和模型驱动开发的最佳实践(1/4)

1 引言 
 
这篇文章我将介绍多年来我使用DSL进行软件开发的最佳实践,在开始之前,我先概述一下内容。我专门针对自定义描述软件系统的领域特定语言,这些语言可以是文本的也可以是图形的,创建的模型再由代码生成,验证,模拟和解释使用,DSL是为开发人员和架构人员使用的(主要包括软件系统的架构/技术方面),同时也可以被那些通常不被称为开发者的商业用户使用。 
   我明确排除内置/嵌入式的DSL, 比如由Ruby,Coverge或者Lisp构建的DSL, 当然也不考虑MPS(译注:Jetbrains开发的,我在
这里有介绍)这种通过扩展一个图灵完备的语言构建的DSL。 
   这篇文章是最佳实践的一些高度概括。对于他们其中的每一个,我都可以写很多页(实际上确实也是,已经有了很多关于这些或者其它实践的内容,见[1,2,3])。 尽管内容简单,这篇文章还是会提醒你当考虑MD*你的项目时应该考虑的所有的事情。
   关于术语的注意事项:
   使用MD*作为MDD,MDSD,MDE,MDA,MIC和其它原理相同的方法名词的缩写。
   模型可以通过很多种方式处理,可以被验证,转换,生成代码或者解释。采用“模型处理(model processing)”(名词是模型处理器model processor)这个术语来代表所有的这些。
   使用术语”元数据(metaware)”来指所有的元数据级别的物件。元数据包括DSL,元模型,编辑器,模型处理。
   通常一个描述系统的全面的模型分成许多“模型单元(model units)”,我称之为分区partitions(例如XML文件)。  
   采用术语”业务应用business”,来指示所有应用领域,可以是科学,机械,自动化,金融或者保险,而不是具体的财务/会计/法律这些业务,这个词主要用来与程序员/设计师/分析师处理的程序/软件区分。
 
   每一个最佳实践都评定了星级,数据来源于我在同事当中做的一个小调查。到现在为止,只有10个人回复了,所以这个调查不一定有代表性,但是它肯定是最佳实践的一个指示:
  
leer_klein 我并不认为是这样,我经常使用一种技术与之相矛盾
  
lone_klein 我没有使用过,但是它听起来有道理,我想如果当我必须要面对这样的问题的时候我会这样来做
  
two_klein 我成功的使用过,但是我不肯定这是通用的最佳实践
  
voll_klein 我成功的使用过很多次,我确信这是最佳做法,不用才怪呢 
 
  文章有三个主要部分:
    第1部分: DSL的设计,设计你的语言时一定要铭记的最佳实践。
    第2部分: 模型处理,模型检查,解释和代码生成。
    第3部分: 考虑你必须记住的有关过程和组织方面的事情。
    第4部分: 着眼于MD*世界里面临的问题和挑战.

2  设计DSL
  领域特定语言的语言来源
twoandhalf
  如何能够挖掘出你的DSL表示什么?如何来进行抽象,以及对应的符号是什么?这不是一个普通问题,事实是这是MD*里最主要的问题,这需要大量的经验和思考以及不断的迭代。不过也有一些典型的方法:
   如果你在构建一个技术型的DSL,语言的来源通常是一个已经存在的框架Framework,类库library,架构architecture或者是架构模式architecture pattern,这方面的知识通常是你已经具备了的,构建DSL主要是形式化这些知识:定义表示方式,用格式化的语言表达出来,并且构建生成器生成部分实现代码,在这过程中,经常会将框架的一些功能特征当成合理的潜规则(默认规则),这能够提高框架的抽象层次,使框架更容易使用
   如果你在构建一个业务领域DSL, 你需要收集领域专家现有的知识,在保险,科学,后勤这些领域,专家们绝对有能力很好地表达相关知识.他们一直做这方面,经常使用Excel或者Word.他们有自己的”语言”来表达领域概念,虽然可能并不是规范的语言,并且没有工具支持。在这种情况下,你的工作就是提供这种规范格式和工具,除了领域知识,其它的东西也是可以利用的:比如硬件结构或者设备特征在个别领域也是不错的选择。
   在以上两个领域,我们对DSL的期望很明确,只需要注意一些细节,表示形式,规范化,视点(ViewPoints),喜好(这些也是很重要的)。不过在其它的情况下我们就没有这么幸运了,如果没有现成的领域知识,我们必须去做一个领域分析,利用已有的应用,从需求出发,参与其中。 
   对于你的第一个DSL,尝试找到一两个案例,理想的情况是从第一个案例开始,因为构建DSL和支持工具的人往往就是领域专家或者软件架构师和开发者.


    极根表现力 twoandhalf 
    当构建DSL的时候,确认你没有被诱惑到构建又一个图灵完备的通用语言,其实在许多情况下,仅仅一个声明式的语言就足以表述一个系统了。
    注意配置和定制之间的差异,一个可定制的DSL提供了足够的词汇量,让你能够创造性的组合成任意复杂的句子,可配置的DSL由明确的参数组成,用户可以直接指定参数的值(例如特征模型)。当然配置型DSL是比较有限的,因为实例以及事物之间的关系并不能够很容易的表达,然而它们并不是很复杂,你越是向配置方面倾斜,一般构建模型处理就越容易,对于用户来讲,也就更容易使用,因为它的表面的复杂性是有限的。
    请注意精确性和算法完整之间的不同,许多领域专家能够正规的精确的定义他们的领域里的东西(即这个领域是什么),但是他们不能够定义算法来实现系统,但是作为开发者来说,你的工作就是提供一种形式语言来给领域专家用于表述事实,然后实现生成器和解析器来把这些事实映射为可执行的算法(要和它们表述的知识保持正确),DSL表述了“什么”,而模型处理器添加了“如何”。
    如果需要关注你的系统由哪个3GL语言来抽象(例如,你需要一个图灵完备的强大的表达能力,而不用比较大的语义扩展),尝试定义一个DSL来实现这个并不是一个好的注意。定义或者生成一个API,来让开发者直接用3GL写代码, 你可以在生成的代码里直接生成挂钩,让开发者可以直接用3GL代码实现一些特殊的功能,保持挂钩的目的性一定要明确,其数量一定要有限

    符号,符号,符号twoandhalf
   构建DSL的时候,表现符号是相当重要的。作为语言设计者,你关心的可能多半是基本的元数据模型,可能并不真正的关心”漂亮的语法”, 但是从领域用户的角度来看,情况可能正好相反。
   特别是在业务领域(但不限于),要想成功,你必须调整你的表现方式来适应这个领域(甚至是这个领域已经存在的表现方式)。试图劝服他们来使用一个“更好的表现方式”往往会让你失望,只要实现他们有的就行了。
   注意这可能需要文本或者图形符号,类似于Excel电子表格,表单系统或者他们的混合,现在的DSL工具在这方面有限制。不过我相信在今后几年DSL工具的演变中将主要解决这个问题。
到现在为止,你只需要考虑到表现符号的易变性,尽最大努力开发可用的工具。
   表现符号应该使通用的东西表达起来简明,能够提供一些合理的缺省规则,即使少数需要额外的修饰来实现也是允许的。
   当勾画DSL定义原型的时候,从表现方式开始,与使用者直接交叉检查是很有用的。
 

    图形  vs  文本符号twoandhalf
  是不是图形描述的比文本描述的更容易理解呢? 其实不然。就易理解性来说最重要的就是把需要用语言抽象转达的概念排列,一个设计好的文本符号更加持久耐用,当然,对于一些特定类型的信息,图形符号是更好的选择:实体之间的关系,一些事件或者信号/数据流的时序/顺序。相反,用图形展现公式是一条走不通的死路(附注:图形公式编辑器在某种程度上是与显示分数,矩阵,积分等方式的混合体)。
   在谈到决定一个合适的符号时,你可能需要考虑以下两个因素:大多数(但不是全部)工具环境,相对于比用户友好可扩展的图形编辑器来说,文本符号的编辑器(包括代码完成,语法高亮等)更容易构建和演变,文本符号还更容易与源代码管理和build机制集成。 
  此外,代替使用全面的图形编辑,你可能会考虑文本编辑+可视化图形(见下文)。
  在使用图形编辑器的环境中需要做很多工作,我建议首先使用简单的文本编辑器(文本,树,通常的框/线)来稳定语言的概念和抽象,然后再投入开发一个完美的图形化编辑器
  在许多系统中,一些观点是支持图形编辑器,其它的是文本。有时候你甚至想混合这两种方式: 状态机(图形符号)其中的断言表达式(文本符号),但是这对于现在的工作来说比较棘手。

    语义DSL(未评级)
   只为DSL定义抽象和表现符号还是不够的,你还必须定义抽象的意义--语言的语义。
   在某种意义上,一个语言的语义比使用这个语言表达需要更多的这个领域的知识:语言允许用户使用模型仅仅表达针对于某一特定 系统/应用/案例。然后语义需要这个领域每一个  系统/应用/案例 之间所有相同的东西。  
   从技术上讲,这是生成器,解析器的工作,平台使他们联系起来,然而从语言使用者的角度来说(他们并不知道什么是模型处理器),语义是隐性知识“语言是如何工作的”,而它必须解释为“语言的意义”.
   有许多种正式地定义语义的方式,但是没有任何一个在主流DSL实践中是足够实用的(到2008年), 因为一种语言的含义在两个方面来定义:用短文来解释,用例子用于语言使用者,并且直接向下通过代码生成器或者解析器和可执行平台绑定在一起。(严格意义上讲,这是业务语义的定义,因为生成器映射语言概念到已经存在语义的目标语言概念)

 

原文: Best Practices for DSLs and Model-Driven Development 
        由于篇幅太长,所以分几部分翻译。翻译水平有限,如果英语不错,最好直接阅读原文.
        向模型驱动开发的同学们强烈推荐此文!

作者:孤独侠客似水流年
出处:http://lonely7345.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

posted @ 2010-03-29 23:23 孤独侠客 阅读(...) 评论(...) 编辑 收藏