BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

访谈与书评:DSL Engineering

| 作者 Ralph Winzinger 关注 0 他的粉丝 ,译者 赵震一 关注 0 他的粉丝 发布于 2013年7月10日. 估计阅读时间: 14 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

Markus Völter是"Model-Driven Software Development"一书的合著者之一,最近他出版了一本模型驱动软件开发(model-driven software development ,简称MDSD)领域的新书。 “DSL Engineering”一书专注于领域特定语言的设计与实现(DSLs)。

DSLs是指那些具有优选的词汇表,并在某一特定领域用于有效描述问题和解决方案的语言。相比之下,像Java这样的通用目的语言(general pupose languages ,简称GPL)可以用于描述相同的问题和解决方案,但是它们最大的特点是需要更加冗长的程序,并且更难以使用工具进行分析,也更难以被领域专家所理解。

因此,设计良好的DSLs非常适合非编程人员用以在形式上定义业务相关模型。通常,这些模型稍后可以转变为例如GPL源代码或文档这样的工件。

InfoQ有机会联系到了该书的主要作者Markus Völter和联合作者之一的Christrian Dietrich。

InfoQ:能分别聊聊你们在DSLs领域的相关经验吗?

Markus Völter: 我在模型和代码生成相关的领域已经工作了差不多10年。我是从使用基于UML的语言和生成器开始的,但是很快转移到了DSL阵营。特别是在使用现代的语言工作台时,DSL的方式比UML更加强大也更具生产力。总之,我自己花了十年的时间来构建语言、分析器和代码生成器,同时也帮助我的客户做着相同的事情。这些项目包括对AUTOSAR标准的概念验证、用于架构定义的各种DSLs、用于配置助听器和冰箱的DSLs以及在保险业务和需求工程中的DSLs等。在工具方面,我主要使用老当益壮的openArchitectureWare框架、Eclipse EMF/GMF/Xtext以及最近的JetBrains MPS。在最近的两年里,我花了很多的时间用于开发mbeddr系统,这是一个用于基于JetBrains MPS之上的嵌入式软件开发环境,该环境也是基于DSLs的。

Christian Dietrich: 我在建模项目方面已经工作了六年以上。我首次接触MDSD是在一个使用UML和专有代码生成器的项目中。从那以后我使用openArchitectureWare以及基于UML和基于EMF的模型做了很多事。在2008年,我发现了oAW Xtext,当时我简直太激动了:相比于曾经使用lex和yacc或者是 antlr, 使用合理的工具来创建文本语言变得如此简单。我开始深入这个框架,自该项目迁移到Eclipse起,我在工作中使用它做了很多的事情。同时,我在业余时间成为了Eclipse Xtext论坛的支持者。我也使用MDSD和DSLs领域的其他一些技术做过一些工作,比如MPS,但主要还是专注于Xtext。

InfoQ:你们的书覆盖了设计、实现和应用领域特定语言的整个周期。使用DSLs和模型驱动软件开发(MDSD)的最有效点(sweet spot)是什么?

Markus: 我不认为存在一个所谓最有效的点,这也是为什么本书在它的四个部分中描述了六个不同领域的适应性。这些领域包括需求工程、软件架构、非常特定的应用逻辑、软件实现、将DSLs作为开发者工具以及在软件产品线的环境中使用它们。我在以上的每个领域中都见到过DSLs很棒的使用案例。这里有一些指导方针来帮助你从大致上判断在以上任意一个领域中使用某种DSL是否会成功(当然,除此之外,必须具有足够胜任的开发者):你是否真正理解你将要创建DSL的所在领域,或者至少有某些方式来逐渐形成这种理解。同样,该领域需要足够多的特定抽象或标记来保证构建和使用DSL取代某种代码库或框架的GPL。另一个使用DSL的绝佳原因是你需要对程序做进一步的分析,而该分析需要静态的(比如编译时)领域层面的语义。再一个原因是你想让非程序员在该领域开发应用(请注意我在这里没有使用“程序”一词),这需要去除掉所有的GPL,因为它会通过代码引入噪声。最后,你越频繁地使用DSL来构建系统,创建DSL的成本将越低(这就是语言工作台的来由),也更容易对DSL创建进行验证。

InfoQ:另一方面,你是否能给我们一些提示,在什么时候不要使用这些技术?

Markus: 好的,如果当我先前所描述的标准都不符合的时候,将不适合使用这些技术 :-) 更严肃的是,有一种说法认为任何有用的DSL将不可避免地最终以GPL的形态结束。我的经验告诉我这是不对的,但是,肯定的是如果你在没有真正理解DSL的情况下开始开发DSL将会是一种风险。直到你真正理解了该领域,那么你的DSL将会优美、声明式的并且简单。但是在这个时刻,你可能会尝试将GPLs中的循环、条件判断和所有其他东西添加到DSL中。这确实是个风险。模块化的语言和语言扩展可以对这个风险进行稍许的弥补:使用别的方式来取代开发一种完整的独立DSL,你可以考虑通过使用领域特定的概念对一种例如Java或C这样的基础语言进行增量扩展。用户通常都可以回到Java或C的层面,所以你将不需要为领域中的每个角落提供DSL概念。一些当前的语言工作台(特别是MPS)真的非常擅长此类的语言模块化。我在前面所提到的mbeddr项目通过对这种思想的探索,使用嵌入式软件开发的领域特定概念对C进行了增量扩展。

InfoQ:这听起来真是两全其美—非常强大。但是这样一来应用开发将会再次成为软件开发者的职责吗?

Markus: 是的,你说的没错。这些工作针对的是那些了解基础语言的程序员所使用的DSLs。这很好地突出了两种不同风格的DSLs之间的区别:应用领域DSLs原本就是为领域专家准备的;它们只包含了领域概念,理想情况下将不包含别的任何内容。它们通常是被自顶而下(top-down)开发的,也就是说你是从现实世界领域中的概念开始的。与此相对的,如果你愿意,可以使用技术DSLs。他们是为开发者准备的。它们通常通过向GPL“添加”领域特定的抽象进行构建,它们“应该”包含所有该GPL的东西,并且不限制特定的用户使用,但是仍然通过提供较高层面的概念简化了开发。它们通常是通过自底而上(bottom up)的方式开发的,就是说你是从该GPL和现存的方言或模式开始的。

InfoQ: Christian,你目前正在德国最大的MDSD项目中工作。如果要成功地设计和使用领域特定语言,应该按什么样的步骤进行?

Christian: 第一步就是理解领域及其概念。如果没有这些知识,你将无法发现正确的抽象。然后,当你为语言定义抽象和具体语法的时候,应该一直着眼于概念的易懂性和清晰的语义。这通常将反复地帮助你进行工作。如果你使用DSLs来生成代码或文档,或者使用解释器来进行一些模拟,那么请使用DSLs中的概念来将这些工件开发在一起。这将帮助你检验抽象语法的质量。如果你将DSL和生成器开发成框架:那么就吃你自己的狗粮吧(译者注:eat your own dog food,俚语,特指公司使用自己生产的产品)。这样一来你就能看到你的DSL究竟是达到了预期的目标还是毫无用处。还有一种观点是在早期就考虑模型的大小和规模从而设计出使用实际模型执行的DSL。使用五行代码的测试文件是不可能发现关于对性能的误解的。

InfoQ:回顾你这些年所参与的项目,使用DSLs最常见的陷阱是什么?

Christian: 我认为一个比较常见的陷阱是随着时间的流逝,DSLs要么对于每个特定情况的概念定义过于工程化,导致零抽象,要么变得过于通用成为"GPLish"。用户最终将堕入复杂性的地域。为了削弱这种效果,随着时间的变化我们需要对DSL进行进化。因此你不要畏惧对语言进行重构,特别是你可以通过工具支持来完成这项工作。相比于Xtext,在MPS中更早的进行了重构。另一个常见的陷阱是过于将精力集中在具体的语法上,而忽视了抽象语法和语义。根据我前面提到的,在一个与领域没有接触且没有应用的象牙塔里开发DSLs这一思想是错误的。你必须经常去证明你的DSLs是符合领域需求的。

InfoQ: Markus,看来使用DSLs和模型驱动方法不可能在一开始就有所回报。你能不能就什么样的项目规模及配置可以受益于MDSD谈谈你的观点?

Markus: 我无法同意你刚才所说的。我可以在两个小时内构建一个小型的DSL,当然它在第一天就给我带来了回报。理所当然,一个更大型的DSL需要更长的时间去开发,因此它也需要更长的时间来获取回报。这都跟比率有关,所以事实上真的没有特定的规模和配置。我曾看到过由小型团队开发的简易DSL。我同样也看到过花费了大量精力的DSL,估计得跨越产品平台几年甚至是几十年之久的生命周期才能获得回报。尤其是在一开始,较好的想法是从一个简单问题开始,随着投入更多的精力,和平常的项目一样,失败的风险终将会由于那些与大小及规模相关联的众所周知的原因而逐渐变大。再次强调,我喜欢那种对一种基础语言进行增量扩展的方式:它允许你根据需求的增长从而添加更多的领域特定抽象(“三振出局,你将自动化”)。

InfoQ:在这本书中,提到了三种DSL框架—Xtext, Jetbrains MPS Spoofax。你能详细描述下这些框架之间的区别吗?它们之间可以互相替换吗?它们是否有其独有的场景和用例?

Markus: 它们三个差别很大,这也是我们在书中选用这三个框架的主要原因。Xtext目前主要用于构建文本的、外部的DSLs。它很成熟、有着很好的支持并且也支持Eclipse EMF,它是现今大部分建模成果的支柱。Spoofax也是基于Eclipse的,但是它并不依赖于EMF。它是荷兰代尔夫特工业大学(TU Delft)开发的一个系统,在它所支持的特性方面更具创新性,比如它具有一种用于名字绑定和作用域选取(scoping)的声明性语言,在语言模块化方面很大程度上超越了Xtext。但是从另一角度来看,它还不是非常普遍。JetBrains MPS则与前两项更加不同。它并不使用普通的文本编辑和文本解析,取而代之的是一种投影方式,通过这种方式每一次的编辑操作会直接修改抽象语法树(AST),你所看到或与之交互的仅仅是投影。这将允许用户使用更加宽泛的标记,包括表格、分数条以及今年晚些时候的各种图形。这同样使得很容易对语言进行扩展,并且可以在单个程序中各自关联成熟的扩展。MPS并不像Xtext那样被广泛使用,但是使用人数正在不断增长。拥有了这三个工具,你便可以构建实用的(bread-and-butter)DSLs了,这些工具可以替换着使用。但是不管则样,它们的偏重点是不同的。举个例子,配合Xbase的Xtext与Xtext的交互操作非常适合于Java生态圈。可以非常容易地构建DSLs来复用Java的类型和表达式,并生成Java代码。Spoofax由一个研究性的小组开发,所以同时也是个研究成果的承载工具,展示了一些它最近的特性。如果你要构建整个语言的生态系统,并且它还具有语言之间的引用、扩展和内嵌等,又或者在需要“奇怪的”领域标记的时候,那么MPS很明显拥有其有效点。很难简略地回答这个问题。我想你应该读读这本书的第三部分,然后就会形成你自己的观点了:-)

这本书的纸版和PDF都已经可以获取。后者可以通过自愿捐赠的方式下载到。该书目前还没有特定的电子阅读器格式。

关于图书作者

Markus Völter 已经在模型驱动软件开发和领域特定语言领域工作了10年之久。他同时也是在该主题方面活跃于各种会议的演讲者。

 

Christian Dietrich 是德国Itemis AG公司的咨询师。Itemis不仅仅提供Eclipse项目 XtextXtend在定义DSLs和通过模型生成工件方面的咨询服务,同时也是这些项目活跃的开发组织。

 

查看英文原文:Interview and Book Review: DSL Engineering

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT