DSM:面向建模专家或系统分析师的解决方案

发表于:2007-04-28来源:作者:点击数: 标签:系统DSM分析师专家面向
当DSL(Domain-Specific Languages)诞生时,不少人比较激动,欢呼一个新的语言时代到临。其实,这不是计算机领域的新语言,而是一种新的建模语言。 DSL是一种专门供领域建模专家(也就是系统分析师)使用的语言,这些领域专家不同于程序高手,他们有一套自

当DSL(Domain-Specific Languages)诞生时,不少人比较激动,欢呼一个新的语言时代到临。其实,这不是计算机领域的新语言,而是一种新的建模语言。
  DSL是一种专门供领域建模专家(也就是系统分析师)使用的语言,这些领域专家不同于程序高手,他们有一套自己认知世界和表达世界的思维和方式(如UML),因此,他们不感兴趣于软件设计细节,希望软件能够按照他们分析设计的结果去运行和执行就可以了。

  其实,现如今在Java.NET分治天下软件语言之时,不可能再有对和Java等同样层次的新语言的新需求, 因为大家都已经经历过优美动人的语言故事,新语言陷阱是每个人理性的认识。因此,聪明的专家发现,DSL特征不是发明新轮子,而是提供一种面向领域建模方便的工具语言,类似UML,但UML不能再胜任这样的工作(见UML和Java的阻抗),MDA有待进一步完善提高,建模专家需要的是DSM(Domain-Specific Modeling)。

提高开发生产效率

  按照软件生产效率研究(Software Productivity Research), Java的平均生产率仅比BASIC高20%, C++不会好过Java,当今Java和.NET语言纷争带给程序员很多选择的痛苦,我们把更多注意力关注在对象、组件和框架(objects, components, and frameworks)等概念上,但是开发效率并没有比20年前有显著增长,从汇编语言到BASIC是400%的增长,在当前21世纪,我们应该怎样完成这样的跳跃式发展?

UML能否胜任?

  象UML这样传统的建模语言并不能提高软件生产率,你需要在两处维护信息系统:语言代码和UML模型,为保持一致来回奔命,我们知道,java/C++/BASIC都将被编译器编译成汇编语言,可是有人看到过这样情形:开发者手工更改编译器并且试图使C++代码和汇编代码保持一致?可是这种现象会发生在UML模型和语言代码之间。

  当然,UML有其优点:作为能够迅速被读懂的虚拟符号,UML世界现在吵吵嚷嚷,一半人发现UML并不能表达他们在建模时需要的一些概念,因此要求将入一些新的东西进入UML核心标准;可是还有另外一些人则认为UML太复杂,应该从UML核心元素中减去一些元素。当UML试图适合所有的人时,它就不能大力提高其抽象层次了。

  这是目前基于UML的大多数MDA工具发生尴尬现象。MDA工具制造商发现它们仅仅能够比手工编码提高生产效率(study)35%,远没有我们希望的400%革命性跳跃。

什么是DSM?

  只有提高抽象层次,将软件直接面向建模专家或系统分析师,然后运用自动化代码生成技术,这样才能高质量大幅度快速开发出软件系统,在OOPSLA(领先的软件工程会议),大家认为DSM可能是一种解决方案。Bill Gates 和 Grady Booch也发表过同样观点。

  DSM意味Domain-Specific Modeling领域定义建模,通过使用领域概念直接指定解决方案,DSM提高了超越程序代码之上的抽象层次,最终软件产品将从高层次的设计中直接自动产生,这样一个自动过程是可以实现的,因为 语言和代码产生器可以满足某一个公司或领域的需求,建模专家使用定义这个自动机器,而程序员只管使用即可。

  实践经验已经证明:DSM比现有方式(包括基于UML的MDA)效率提高5-10倍,正如Booch说的那样: ”当建模概念可以直接映射到领域Domain,而不是计算机具体技术概念时,MDA的价值已经完成“,这句话的意思是: MDA已经证明我们可以直接从领域专家Domain观点直接建模,而不必拘束于具体的计算机技术概念,或者说:直接由有经验的系统分析师/建模专家分析设计进而生产出软件系统已经被MDA证明是可行的了,MDA的价值也就在于此,
Booch等人寄希望于使用DSM替代MDA。

  由建模专家定义有关领域和组件的代码产生器,这样做的结果要好于大多数开发者手工开发。从MDA教训来看,大家认识到:不可能有“一种尺寸适合所有身材”的代码产生方案,不必象MDA那样疲于往来返工,DSM所做的正如将代码编译成汇编语言的编译器所做的。

DSM工作原理

  首先,每个行业都有一些经验丰富行业专家,俗成系统分析师,他们对业务系统非常熟悉,但是不太了解软件技术,由这些专家定义一个包含域概念和规则的域定义语言(domain-specific language),并且定义这些域概念和规则映射到代码产生器的映射;实际上这些建模专家所要表达的就是:我们的需求应该看上去是怎样?我是怎么写代码的。

  然后,其他开发者就使用建模语言根据前面定义的规则制作模型,最后,代码将自动产生,因为建模专家参与了定义代码生产器,这样最后产生的代码质量要高于正常程序员手工完成的代码质量。更重要的是,制作模型将比手工写代码更快。

与MDA区别

  DSM与MDA主要区别是:MDA工具商自己定义代码产生器,这些代码产生器第一次看非常好,但是以后就变样走味了,难以适应需求的变化。.

  DSM中,由你控制DSL和代码产生器,这些工具可以被调整以适应你自己的系统,作为开发者,你只需要定义DSL和实现自己的代码产生器,所有这一切都是由你来定义控制,正所谓定制性强。

DSL案例

  TSS上最近的文章“Improving Developer Productivity with Lightweight Domain Specific Modeling”演示了如何使用DSM实现轻量建模的过程,共分五步:

ArgoUML 能够用作定义DSL模型,开发人员能够设计DSL模型适合问题域。

将 ArgoUML模型转为Eclipse模型格式的Ecore.

使用Eclipse的插件JET模板定义代码如何产生。

Ecore模型输入到模板定义中,然后再定义Ecore模型中的模型元素和带有Merlin的JET模板之间映射。

最后结果是产生最终代码。

 

参考文章:

Improving Developer Productivity with Lightweight Domain Specific Modeling

Why DSM?

Ruby On Rails 与Jdon Framework架构比较

原文转自:http://www.ltesting.net