Domain-Specific Modeling and Model Driven Architecture
DSM（领域定义建模）和MDA（模型驱动架构）
模型在软件开发中的角色
当今信息系统的开发越来越复杂，而且所涉及到的领域也越来越广，开发者必须掌握许多不同的技术，包括流行的面向对象技术，XML，脚本语言，接口定义语言，过程定义语言，数据库定义和查询等等。要把来自于问题领域的需求转换成解决方案需要对许多架构和协议的深刻理解。再者，最终用户常常期望结果是高运行效率的，易用的，易扩展的，而且对于不可知且不可靠的网络连接是安全的，这可是件苦差事。
在软件开发之外的一些领域，例如电子产品（电视机，HiFi音响，照相机）等等，我们可以看到低成本和高可靠性的情况。在过去的几十年里，制造行业一直采用这样的流程：通过一连串复杂的步骤来制造一台电视机或汽车，其中有很多步骤是完全自动化的。
我们会喜欢使用相同的原理来构筑软件，不同的是我们没有开发出能够允许有效分离软件中关注点的软件说明语言。尽管我们使用不同的程序开发语言来书写应用逻辑，来完成不同的开发任务。例如：使用XML在应用组件中传递数据，使用SQL存取数据，使用WSDL来说明面向Web应用的组件的接口等等，但是它们中没有一个直接针对最终用户所面对的业务问题。
本文将要介绍的软件构筑技术是domain-specific languages（领域定义语言，简称DSL）的开发。
DSL被设计为直接面向它所要解决的问题领域。在某种程度上，它能够代替编码，数据交换，配置等工作，我们常把这类语言称为建模语言。我们使用这些语言来针对问题领域进行建模。
模型里的每个元素都映射到现实领域中的一个概念，很多年以来，模型对于定义IT系统如何来保存数据一直是很重要的，现在，模型的应用更广泛，例如对业务过程建模，服务的部署，数据中心等等。模型受欢迎是因为它能够很好地表述问题从而避免陷入技术细节中。当技术变得越来越复杂的时候，模型是提高生产力的必须手段。模型的另一个好处是可以让程序员和问题领域的专家使用同样的表述方法，这有助于团队成员间的沟通。我们也可以把使用模型看作弥合技术和业务之间缝隙的方法。
在过去的几年里，新的建模方法开始合并，特别是在MDA的旗帜和能够提高软件开发生产力及软件可移植性的承诺下，OMG对UML和一些相关技术进行了大力的推广。但是我们必须看到80年代的CASE工具的结果，显然，CASE已经无法兑现当初的诺言，对于MDA我们仍然十分怀疑，除非能够证明它对于我们所面对的问题找到了新的道路，不再重蹈CASE工具的覆辙。在我看来只有模型，模式，框架等技术结合在一起才能够避免象CASE工具那样的失败。
Domain-Specific Languages
如果我们想通过运用模型来使领域专家能更容易地解决问题，那么模型就必须能够清晰地描述问题领域。对于建模语言，就是指用来针对问题领域建模的标记和关系的定义。典型的，但不是必须的，建模语言可以是一组图释，一组由线条连接起来的节点，也可以是流程图或者实体－关系图。
模型通常被标记和文本元素所修饰，开发者需要细心地审视，理解掩盖在这些修饰下的模型真正要表达的信息。所以要能够进行建模就必须明白每个元素相关细节。这意味着一旦成为具有专门的建模技能的人才就会带来丰厚的回报。
有些人可能会认为正确的观点是应该定义一个通用的建模语言，使用它来对所有的问题领域建模，同时要教会那些领域专家们学会使用这个通用建模语言。从UML得到的经验来看，这样作并不成功，后面我们将会讨论UML。
现在，我们把那些被设计成用来对特定问题领域建模的建模语言称作domain-specific languages（领域建模语言）。领域建模语言可以针对很多问题领域创建，例如：通讯，银行业务，空间勘测等等。
无论如何，设计和使用领域建模语言只是模型被用作辅助软件开发的很小一部分。模型可以被分析和验证，转换，通过很多步骤，被部署并执行软件。这个过程包括开发，分析，验证模型，在很多不同领域中，通过工具将模型进行转换，直到部署系统完成。
在软件系统的构筑中，模型的一个对应物是框架，框架是适用于整个领域的代码实现框架，并且给多个系统间在相同领域的不同元素提供了扩展点。有很多框架的例子：从GUI到ERP的基础结构和算法。在所有的情况下，模型的角色是使用框架，给特定的应用定义扩展点。在这个层面上，我们可以认为建模语言是定义扩展点，使其契合到框架上，来适应用户对问题的理解的一种方法。
另一个重要的对应物是模式，一个模式本质上是一个有很多小孔的模型，和如何将这些小孔用其他模型来填充的规则。有一种高效使用模式的方法：使用一个由许多小的模型组成的大的模型，或一个由其他类型的模型组装起来的模型。
在软件开发过程中运用模型，模式，框架，代码的至关重要的一点就是最终的结果必须是“敏捷“的。在代码和模型间必须不存在任何不可逆性和不连续性，在整个开发过程中必须能够对可见的各种因素作出快速的反映，变化后重新产生最终结果。CASE的错误在于没有针对问题领域使用框架，而是使用了庞大的，不可逆的代码生成过程，这样使得开发者无法修改生成的代码，从而使整个方法完全失效。只有将模型，模式，框架结合在一起，并使它们无缝的整合进一个敏捷的开发过程中，才可以避免出现CASE方法那样的缺陷。
运用模型，模式，框架的过程从整体上看起来制造业的很相似，我们可以把软件开发看成一个价值链的概念：从供应商那里取得输入，利用自己的专业经验为这些输入增加价值，到链条的最后产生输出。迄今为止，软件的构造过程很少被看作这样的一个链条，根本原因在于表述软件的方式的限制，当代码成为表述软件的惟一的手段时，惟一和产品密切相关的人就是程序员。领域定义模型、模式和框架的开发应被纳入软件价值链，也就是产品线中。
在微软，我们坚信建模将对软件开发越来越重要，我们将在即将发布的Visual Studio中整合建模功能，我们相信认真地根据目标客户的技能来设计领域定义语言的本质是：我们要给客户直观的，敏捷，高效，无缝的建模体验。我们的第一个建模产品的目标是能够立即为我们的客户提供高收益。在最近的微软开发者大会上，我们展示了帮助开发者进行SOA的开发和部署的建模工具，关于这次展示的细节，可以在http://msdn.microsoft.com/vstudio/enterprise 找到。
随着时间的推移，我们将继续扩充我们的建模工具来面向更多的领域，例如：代码可视化、业务建模，还会把支持更多领域的工具整合进Visual Studio。更长远的计划是通过多个产品线，包括模型，框架，模式，工具，来整合完整的软件开发过程。
Model Driven Architecture
在IT界，术语MDA一般是指在软件开发过程中使用模型。但事实上，OMG把这个术语注册为商标，并将其引申为特殊的使用OMG的建模技术进行模型驱动开发的概念。使用的建模技术的核心是UML和MOF（Meta-Object Facility 元对象设施），本文的这部分将简要讨论MDA，然后将关注MDA中所包含的建模技术，特别是UML和MOF，还将讨论MDA中和我们相关的方法学。
MDA的本质就是区别Platform Independent Models (PIMs) 和 Platform Specific Models (PSMs)。当使用MDA开发应用程序时，必须首先创建PIM（平台无关模型），然后使用标准映射，转换到PSM（平台定义模型），最后，映射生成最终程序代码，依照OMG的MDA的FAQ：http://www.omg.org/mda“UML是MDA所使用的关键技术，任何使用MDA创建的应用程序都基于标准化的，平台无关的UML模型。”这样，就意味着应用程序的被定义为平台无关的，这样应用程序就是可移植的。这很容易让人回想其Java所宣称的“write once run anywhere”，试图去构建一个平台无关的框架，诸如Swing UI库，必须在性能和平台集成上作出折衷，在过去，这种折衷是很多产品失败的根源，因为这些失败，业界仍然非常怀疑MDA的宣言，在OOPSLA 2003上MDA的session就是佐证。
不过，MDA的探索在某些应用程序方面是有帮助的，一些厂商已经向我们展示了基于J2EE的Web应用，创建包含了数据实体，组件的UML模型，再映射到各种J2EE应用。但是无论如何，就象前面所提到的，这对开发者意味着全面转向敏捷开发，而且不能引起不必要的转变和障碍，例如不可逆的代码生成过程和调试上的问题。
扩展MDA到其他领域很困难，OMG所定义的“平台”的概念很模糊，真正的例子也就是J2EE。在软件开发过程中使用模型的道路上，使用模型来创建J2EE应用是有效且使用的。事实上，几乎没有关于平台无关模型和平台依赖模型间的映射标准，现存的惟一一个也是针对Java平台的，尽管还有很多非标准的，开发社区的实现声称支持其他平台。
总而言之，MDA起错了名字，它不是体系结构，它是基于对相似平台的抽象的模型驱动开发标准。OMG在向业界推动MDA的时候，并没有采纳关于整和模型，框架，模式和工具来支持软件产品线的建议，而且，我们将看到，MDA所基于的UML和MOF规约将会限制它的用途。
The Unified Modeling Language
UML是一种通用建模语言，它开发于90年代早期，由Grady Booch, James Rumbaugh和Ivar Jacobson合并成一个统一的图形表示法。第一次标准化在1997年，经过了多次修订，最近正在开发第二个版本，这个版本已经接近完成。
UML是庞大且难于理解的，版本2更是如此，要向深入的理解UML必须先理解它怎样被使用。我们借用Martin Flower在《UML Distilled》一书中分类，Marting把UML的使用分为:用作草图，用作Blueprint，用作程序语言。
把UML当作草图使用非常流行，很多项目都在白板上使用UML画草图。把UML作为草图使用的另一个含义是把试图从面向对象设计中生成结构化的文档被看作是不妥当的。在这种情况下，UML是非常成功的，它完全达到了消除了面向对象设计和图解表示的不一致问题的目的。
把UML作为Blueprint使用提升了门槛，这时的目标是在开发过程中把多种UML模型结合起来。对于任何改动和自动化，都向系统地将UML模型转换到源代码，这也就意味这UML模型必须包含足够的信息，才能保证转换是有效且完整的。
当我们尝试这样作的时候，会很快发现UML的问题，因为它不能很直接的转换到我们所使用的技术，例如：一个UML类不能直接用来描述一个C#类，因为UML类并不能描述C#中的属性的概念。类似的，一个UML接口不能直接用来描述一个Java接口，因为UML不包括Java中的静态字段的概念。从这一点来看，把UML作为草图使用时，没有任何问题，但是，当UML被用作开发一个类的制品时，要么违反标准，要么引入一些不和谐因素来修补这些不匹配的问题。
将UML作为程序语言由一些社区支持，但是他们不喜欢走到商业化的路上，在这里我们不作讨论。
让我们再来观察这些UML的主要使用方法：作为草图和Blueprint。把标准表述为一组灵活的，可扩展的图释，并无缝地映射到开发所使用的技术，而且不存在任何不匹配的描述说明，这是非常有用的。只有从模型所表述的概念进行无缝且可逆的映射才会被大多数开发者所接收。“UML轮廓”采用允许有限度的对语言扩展来使蓝图具有可扩展性。但是实践证明这种可扩展性是非常有限的，并且还不能提供无