DSM（领域定义建模）和MDA（模型驱动架构）

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 轮廓”采用允许有限度的对语言扩展来使蓝图具有可扩展性。但是实践证明这种可扩展性是非常有限的，并且还不能提供无缝的从 UML 到时下流行技术的映射。 在微软，我们的途径是通过我们的建模工具，使用一些易识别的扩展的表示法来表示概念。同时，我们发现 UML 表示法还不够清晰，我们对其进行了增补，例如：我们使 .NET 的类可视化，可以包含更多信息，更容易使用，而且使得图释的元素更精确。这保证了 .NET 中的术语和概念能够在图释中清晰地表达。我们从客户那里得到的反馈是压倒性的支持这种作法。尽管我们的图释法不是标准的 UML ，但是它所表达的含义对任何人而言都是非常容易理解的。 在 UML 所不针对的领域，我们必须创建新的约定，例如：设计器支持开发逻辑数据中心模型，这些模型被用来部署分布式系统，在这里我们可以使用 UML 中所不支持或支持很少的概念，而且我们可以对这些领域创建一个规约。领域定义语言被用来开发 UML 所不支持的新领域，我们可以期望将这些规约合并到这些领域中。 我们可能会发现在对 UML2.0 作过大量的扩展后可能会导致一门建模语言的产生， SDL （ Specification and Description Language ，定义和解释语言），广泛用于通讯技术领域。我们期待看到在那些 UML 还没有涉及到的领域的关于 UML 的图释约定和扩展的远景。 Defining Languages and Interchanging Models 在 OMG 的 MDA 旗帜下还有另一个重要的技术： MOF 。 MOF 是一个比 UML 更加抽象和难以理解的技术。理解了这个还有更难理解的术语，象 metamodel （元模型）和 meta-metamodel （元－元模型），感谢还没有出现 meta-meta-meta-model ，我们也会尽力阻止出现。 MOF 主要作两个工作。第一，它是一个被设计成定义建模语言的领域定义建模语言：一个 MOF 模型是一个 MDA 建模语言的定义。第二，它是一种计算一个 MDA 模型如何被序列化到一个 XML 文档或 Java API 的机制。 一个领域的建模语言包含很多方面，它必须定义领域中的概念，必须把概念表示为图形或文本，必须定义用户如何与语言交互，必须定义一个模型是否合法，必须定义模型间如何交互。但是 MOF 仅仅定义了语言的基本概念，以及概念的模型如何存储和交互。一种语言的 MOF 说明并没有提供多少用户真正关心的东西：语言所包含的模型是什么，它看起来象什么，用户如何和模型交互。 在微软，我们希望我们的语言能够整合到 Visual Studio 包括 IntelliSense® ，工具栏，菜单，属性栏，和对 Debug 的支持，我们发现定义如何对概念建模在整个工作中只是一个次要的方面，而且我们的语言定义工具要整合到 Visual Studio 中要比 MOF 好。 事实上，尽管这是语言定义技术的通常的地位， MOF 仍然是一个存储概念模型，并且使用 XMI （ XML Metadata Interchange ）在模型和 CORBA 和 Java API 之间转换的主要技术。如果使用 MOF 来定义一种语言的概念，接下来就可以使用 XMI 的方法来进行对语言的基于 XML 的自动生成。 从这个方面看，这似乎是挺吸引人的，但是，还是有一些问题。首先， XML 的生成基于语言的定义，这也就意味着使用 UML1.4 标准进行的 XMI 序列化将无法被基于 UML2.0 的实现所理解，除非用户在这些概念的观点能够保持前后一致。再者， XMI 本身就在变化，也就是说可能会出现对与同一个模型的不同 XMI 序列化版本。第三， MOF 的定义也在变化，它会为了对付不同的组合而不断加入新的元素，这将导致 MOF 的版本具有不同的取向，而且无法完全一致。所以，虽然 XMI 宣称为建模工具提供互操作性，但是实际情况是，除非每个工具都能够支持 MOF ， XMI ， UML 标准下的所有可能的组合，工具之间的交互才是没问题的。 XMI 的更深层次问题是，特别是对于旧版本，由机器生成的 XML 架构常常冗长且难以阅读，这就迫使开发者们去寻求可视化程度更高的，可转换的技术来维护 XML 文档。 我们不认为 XMI 对于模型的序列化来说是正确的方法。 XML 正在变的成熟，市场上有大量的模式和工具。我们认为正确的方法是，对特定的建模语言有他自己特定的 XML 架构，并且提供工具来管理语言和序列化格式间如何自动解释和映射。如果对一个特定领域进行标准化， XML 架构就可以是标准的，这是业界广泛存在的观点。之后，如果语言的定义发展了，可以在旧的 XML 架构上扩充，进行移植。 XMI 有效地阻止了这个清晰的思路发展，并导致了大量不兼容的 XML 架构标准，和它的互操作的目的完全背离了。 简而言之，微软不支持 MOF 是因为下面的原因： 1. 它还不是个稳定的标准 2. 使用它来作为设计我们的工具的语言会产生我们不愿看到的结果。 3. 支持 MOF 所没有提供的元素需要商业级的实现，我们会继续引入 MOF 定义的改动。 4. MOF 没有实现自己的目标。 结论 本文讨论了模型在软件开发中的角色，特别是 domain-specific languages 的定义和使用，以及在产品线中的使用，同时对 OMG 的 MDA 作了总体的评价。我们确信在敏捷软件开发过程中模型会得到更多的使用，我们正在构筑工具和技术来支持这些开发。我们看到 UML 作为重要的一步，它的未来是基于图释的开发者间的约定，而且可以作为面向特定问题领域的领域定义语言的灵感。也看到 XML 是模型的表现和交互的关键技术，我们期望对领域内容的标准化能尽早开始。