更多文章，见我在博客园的blog：www.cnblogs.com/dahuzizyd
使用领域定义建模语言来提高生产力
根据对软件生产力的调查，Java的平均生产率只比Basic提高了20%，C++还不如Java，事实上，除了smalltalk，还没有哪个主流的程序语言的平均生产率比Basic有实质的提高。
在经过了开发语言的战争以及对象，组件，框架等诸多概念后，20年来我们几乎没有什么大的进步，但是，回顾这些年来的主要的变化：从汇编语言到BASIC，生产率有400%的提升，为什么会有如此大的飞跃，在今天我们怎样才能再次实现这样的飞跃？
400%的增长率在于抽象程度的提高。C++，BASCI，Java中的每条语句都相当于几条汇编指令，更重要的是，这些语言可以自动翻译成汇编指令。从生产率上看，这意味着你用一行代码得到了五行代码。
UML能够提高生产力吗
象UML这样的传统建模语言并没有提高生产力，因为他们的核心模型和程序设计语言所提供的抽象级别是相同的：在使用UML设计的时候，我们依然在和对象打交道，它们的属性，返回值等等，使用支持UML的建模工具进行一天的建模工作仍然相当于一天的编码。
然而，在使用了这类工具的代码生成功能后，你仍然需要手工改动或添加一些主要的代码，因此，你将在两个地方维护相同的信息－代码和模型，而这则是对困难开出的处方。有谁见过手写汇编代码然后尝试使他们的C++代码和其保持同步？
当然，UML也有他的好处：可视化的表述方式更方便阅读，易于获取整体的描述。但是看看UML现在在实际中应用的情况，许多开发者觉得在模型中无法表现出他所想要表现的东西，他们还需要一些东西来作这些事。还有许多人认为UML太复杂了，而且希望它简化到只留下核心的元素。
UML试图为所有人作所有事，因此无法提升抽象级别。
用领域定义建模提升抽象级别
我们怎样才能提供比3GL更高级别的抽象呢？那就是放弃对所有类型的应用程序都使用一组通用程序语言概念的尝试，取而代之的是每个公司都可以使用产品中的概念，创建自己的可视化表示法。
领域定义建模语言的标记，以及使用它们的规则和它们之间是怎样联系的，直接来源于问题领域，来源于系统的目标环境。这提供了比UML更高的抽象级别，这样作的结果是一个富有表现力，但却是有界的设计语言，专门定义问题领域运行的系统。
例如，一个用来开发移动电话系统的DSM语言可以使用象“Soft Button”，“menu”，“Send SMS”，“notification”等概念，这些概念可以用于移动开发领域，但是却很难用于web系统，ERP，或者商业智能软件。定义一个专用的DSM语言要比定义一个象UML和Java这样的通用语言要容易的多。这样只需要一点建模工作就可以完整地定义一个系统。
因为是完整的，所以DSM语言应当能够很好的成为自动生成完整代码的依据，从开发工作的核心部分得到图形化的模型，然后为它自动生成所有的代码和文档。模型既是设计也是文档，是产品的说明和高抽象级别的系统，也是代码实现。文档化和可实现性贯穿于系统整个生命周期，而且是真正的模型驱动。
从DSM语言进行完整的代码生成需要代码生成器。从模型到代码的映射都定义在生成器里，DSM语言需要一个能够满足问题领域需求的代码生成器，换句话说，要确定能够按照你想要的方式从DSM语言生成完整的代码，你要能够完全自由的来定义你的语言如何映射到代码。
修改代码生成器对DSM语言是完全无用的。问题和解决方案领域的知识一直都在发展，因此，你需要尽可能的演进你的领域定义建模语言和代码生成器，而且不要冀希望于工具提供商来作这些事情。
什么时候，怎样实现领域定义建模语言
领域定义建模需要一种DSM语言和于之相配的代码生成器。尽管这比实现一个通用建模语言要简单的多，但也不是每个开发者都可以作的事情。这需要精通问题领域和将要生成的代码的相关知识，先由领域专家发现要开发的产品的特征，再来开发系统，或者在某个系统上进行配置以满足客户自定义的需求，如CRM，工作流，付费系统等等。
进行此类开发的富有经验的开发者们必须知道问题领域中的概念，约束规则，怎样编码或者进行配置。这样的专家能够教授团队成员相关领域的知识，并且有资格去定义那些能够提高开发者效率的自动化机制。
DSM适用于那些我们经常进行重复劳动的情况。例如从各个有差异的产品中逐渐演变出一个通用的平台，这样的平台基于一些共同的基础的东西来控制复杂度，同时使产品具有更好的多样性。
这种途径的关键在于共享，复用组件，模块和开发那些来源于标准组件，并且能够进行装配的不同组件而产生的制品。这些标准组件是解决方案中提升抽象程度的关键部分。
然而，在很多时候开发团队使用通用编程语言在“产品平台”上开发软件，为什么要使用通用的程序设计语言在“产品平台”所定义的边界集合中开发软件呢？“产品平台”本身就是为了使事情变得简单，所以为什么不在现有的产品平台上使用DSM语言呢？代码生成器会根据模型生成代码来接入到产品平台上。
但是当产品平台本身可能会有很多变动，或者有多种平台，在这种情况下需要在代码生成器和平台之间创建一个框架，这样，平台本身的变动对于专家们来说就只是修改框架了，而代码生成器和DSM语言和其他所有开发者们所使用的东西都可以保持不变，当然，开发者们所创建的模型也可以不作改动。
和上面的情况形成鲜明对比的是直接在平台上编写代码的那些项目，当平台改变的时候通常意味着代码的大规模改动。在代码生成器和平台之间创建一个框架是比单单针对一个平台的更好的方法。这样作可以由框架来处理不同的情况，而不是由代码生成器来处理。
小结：DSM实现需要领域专家来对DSM语言和代码生成器来进行定义，它可以用来改变这样的情况：使用开发环境进行重复的工作，而这些工作都是可以进行优化的。DSM需要开发资源上的投入和时间来构筑DSM环境。尽管常常会和那些紧急的项目冲突，但是从长远看还是值得的。
关于DSM的经验表明，和当前的开发环境相比，DSM对生产力有5－10倍的提升。而且，可以由专家进行主要的开发，然后由其他的开发者进行代码生成，而不需要由每个开发者都按照“最佳实践”来自行开发。
DSM的工具
一个软件开发方法如果没有工具的支持，它的价值就很小了。在白板上设计DSM语言并不会给你生成代码，这样，当DSM被用来帮助定义一个系统或应用程序时，就无法提高生产力。许多组织都在开发自己的DSM环境来支持他们的DSM语言和代码生成器。所以在我们寻找提高生产力的方法的同时带来了巨大的商机。
今天，竞争的升级迫使开发商缩减开支，减短开发时间来适应市场需求。提高开发团队的生产力是达到这一目的的重要手段。在意识到UML无法提供生产力后，许多公司，比如：MetaCase (MetaEdit+), Microsoft (Software Factories), Eclipse (EMF & GEF),和Xactium (XMF-Mosaic)，在开发可以让用户创建领域定义的，基于模型的代码生成环境。
也有一些人在尝试使UML具有“领域定义”的能力，其他一些人则致力于能够完全自由地设计DSM语言和代码生成器。我们的理想当然是有这样的工具，它能够真正地提供高于程序设计语言的抽象能力，而且能够达到领域定义所需要的抽象级别。此外，代码生成器是完全可定制的，而且生成的代码看上去就和手写的一样。
这样的工具可以让专家用尽可能少的工作就可以得到他所渴望得到的结果。特别是初期的定义过程必须是尽可能高效的，而且专家们可以尝试多种方案。接下来，DSM语言开始应用，而且真正的模型已经存在了，工具能够控制建模语言的演化而且自动更新模型。
DSM和MDA的不同
现在，Object Management Group（OMG）极力推动MDA－一种模型驱动方法，由高抽象级别的UML模型转换到低抽象级别的UML模型。
通常有两种级别：平台独立模型（PIMs），平台定义模型（PSMs），但是PIM和PSM并没有提高抽象级别。有一个概念很重要，就是象.NET，J2EE，CORBA这样的“软件平台”和“产品平台”之间的区别，正象前面所提到的，后者具有更高的抽象度。
在MDA里，在每个阶段你都要反复编辑模型的每个细节，直到最后根据最终的模型来生成代码。OMG推行MDA的目的是为了在不同的软件平台上定义一个标准的模型格式，使得模型可以在各个厂商的工具间通用。这个目标非常有野心，但是还需要很多年才能实现。
DSM需要问题领域的专业知识，这些知识只能依靠一个公司连续不断地针对同一问题领域进行开发来获取。平台独立性不是最要紧的，尽管这对DSM来说很容易，DSM只要使用代码生成器针对不同平台生成不同的代码就可以了。DSM真正的关注点在于提高生产力。
对于MDA，OMG没有使用DSM语言，而是使用通用的UML，他们自己的标准建模语言，没有关注可能存在于组织内部的对于某个领域的专业知识，而是假定这些专业知识是不存在或不相关的。
MDA需要精深的方法学的知识，这些知识有可能存在于开发组织之外或者需要更多的经验，因而DSM所需要专业知识在组织内部已经存在并实际应用。在这种情况下选择MDA还是DSM是很清楚的。
结论
回顾软件开发的过程，开发者们一直在追求更好的抽象，自动化，可视化来提高生产力。DSM结合了这些方法并且拷贝了编译器成功的基础：在生成代码的时候，处理也随之完成。
在使用DSM的时候有一些障碍：DSM的实现需要结合定义领域定义建模语言和代码生成器。已经有许多工具能够让这些变的简单，使专家们能够运用他们的专业特长使工作更简单，更快速，而且更有趣。
引用
[SPR, 2005] Software Productivity Research. SPR Programming Languages Table™
(PLT2005),