什么是DSM

DSM：Domain-Specific Modeling

板桥里人 http://www.jdon.com 2006/5/1（转载请保留）

当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模板之间映射。

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

1、来源：官方VS非官方。官方与非官方的区别。黑群晖是非官方的产品，所搭载的操作系统是经第三方人员修改后用非官方的方式安装，并未经群晖官方支持。黑群晖虽然在形式上实现了和群晖类似的功能，但是由于硬件是自己搭建，系统由未知来源的第三方提供，隐藏着巨大隐患。

2、安全性：安全可靠稳定 VS 数据损坏担忧。一款群晖产品在设计之初做了严格测试，确保每一个部件都正常运行。不管是能耗控制，还是存放的空间占用率，都力求达到最优化的用户体验。而且群晖还为提供最及时的安全更新支持，即使是非最新版本也提供补丁更新，让系统时刻保持最新，达到最稳定的状态，旨在提供安全无虞的数据存储体验。然而，黑群晖安装复杂，升级困难，功耗大、安全性低数据易丢失，反观白群晖则是安装、系统升级简单容易、稳定安全可靠。而且，数据存储安全是选择存储方案的根本。黑群晖虽然在形式上实现了和群晖类似的功能，但是由于硬件是自己搭建，系统由未知来源的第三方提供，数据安全上隐藏巨大忧患。

3、便捷程度：一键安装 VS 重重困难的折腾。群晖NAS安装简单，就算是不谙IT技术的家庭用户也可以完成系统安装与设置——接通电源、网络，再使用电脑根据界面指示一步一步操作即可完成，整个安装过程简单方便快捷。而且当你在遇到问题时，可以直接在系统里面、或是群晖官网提交问题给群晖技术工程师，获得即时的服务与协助。对比黑群晖而言，在DIY黑群晖时需要做很多准备，购买硬件进行组装，下载引导程序，制作启动介质等等。接下来就是准备系统安装，安装过程中选择项还特别讲究，选错了就会照成安装失败，必须重新来过。安装完成后还需要做补丁，防止修改的系统不稳定造成死机。而且，困难重重折腾的安装只是一个开始，安装完成后还有漫无止境的问题。当非官方DSM系统功能出现缺失，因不是官方提供的产品，也无法获得群晖官方技术支持。对于数据最核心的存储设备而言，这些“困难”造成数据最核心、根本的问题——安全、稳定无法被解决。

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com