第 3 部分: 进一步研究模型驱动开发和其他行业方法

在本文中，在业界的其他相关活动的上下文中了解模型驱动开发（model-driven development，MDD）。比较软件工厂、领域特定语言和 MDD 方法。探索如何将开发构件可视化为模型，以及使用可执行的统一建模语言（Unified Modeling Language，UML）方法来直接执行模型。

引言

在本系列前面的两篇文章中，您了解到模型驱动开发（model-driven development，MDD）方法可以改进软件解决方案的业务价值和体系结构完整性。

实现模型驱动开发，增加您的 IT 系统的业务价值 讨论了 MDD 如何能够交付价值。

结合模式与建模以实现架构驱动开发 解释了 MDD 如何支持体系结构驱动的开发方法。

本文将在业界发生的其他相关活动的上下文中讨论 MDD。您将了解 Object Management Group (OMG) 行业标准机构在 MDD 中发挥的作用，并了解软件工厂方法与 MDD 的比较情况。此外，本文还研究各种将开发构件可视化为模型并使用可执行的 UML 方法来直接执行模型的技术。

重温模型驱动开发

在 MDD 中，模型不仅用作纲要或蓝图，而且还用作主要的构件，通过应用转换可以在这些构件基础上生成高效的实现。在 MDD 中，面向应用领域的模型是开发新软件组件时的主要重点。代码和其他目标领域构件通过转换来生成，这些转换是使用来自建模专家和目标领域专家的输入来设计的。

OMG 和模型驱动架构

OMG 是负责制定企业应用程序领域的互操作性标准的开放协会。OMG 负责开发作为 MDD 核心的统一建模语言（Unified Modeling Language，UML），同时还推动模型驱动架构（model-driven architecture，MDA）活动。MDA 是 MDD 方法的一种形式化，例如 Rational 软件已推广了多年的方法。根据 OMG 的定义，MDA 是一种在自动化的工具和服务支持下组织和管理企业体系结构的方法，并同时用于定义模型和促进不同模型类型之间的转换。

术语 MDA 和 MDD 经常交换使用。在本文中，MDD 指的是由软件开发人员执行的活动。MDA 保留用于其正式的 OMG 定义，此定义更多地集中于创建一个可在其中实行 MDD 的正式框架。OMG 的 MDA 指南将 MDA 描述为具有三个主要目标：

1.可移植性

2.互操作性

3.可重用性

其目的是通过将系统的操作规范与在特定平台上实现系统的方法细节分离，从而实现这些目标。MDA 使得工具能够通过执行以下任务来帮助满足这些目标：

1.指定与平台无关的系统

2.指定平台

3.为系统选择平台

4.将系统规范转换为针对特定平台的规范

平台 的概念是 OMG MDA 的中心。平台是通过应用程序能够使用的一组子系统和技术来对接口和使用模式的实现，而不考虑有关如何实现平台的详细信息。

MDA 模型

MDA 定义了三种模型：

计算独立模型（Computation-Independent Model，CIM）

描述系统的需求和将在其中使用系统的业务上下文。此模型通常描述系统将用于做什么，而不描述如何实现系统。CIM 通常用业务语言或领域特定语言来表示，仅当 IT 系统的使用是业务上下文的一部分时，才会非常有限地涉及到 IT 系统的使用。

平台独立模型（Platform-Independent Model，PIM）

描述如何构造系统，而不涉及到用于实现模型的技术。此模型不描述用于为特定平台构建解决方案的机制。PIM 在由特定平台实现时可能是适当的，或者可能适合于多种平台上的实现。

平台特定模型（Platform-Specific Model，PSM）

从特定平台的角度描述解决方案。其中包括如何实现 CIM 和如何在特定平台上完成该实现的细节。

从 PIM 到 PSM 的转换是 MDA 的核心。将一种模型转换为同一个系统中的另一种模型的过程称为模型转换。图 1 显示了可能具有附加信息的 PIM 到 PSM 的转换。

图 1. PIM 到 PSM 的转换

MDA 并不将这些模型视为固定的层，而是阐明 PIM 和 PSM 可以分层，相对于更抽象的模型，每个模型为 PSM，相对于更具体的模型，每个模型为 PIM。例如，您可以有一个高级设计模型、一个详细设计模型和一个带有两个 MDA 模式实例的实现模型。在每个级别，您都可以引入有关实现平台的进一步假设。相对于高级设计模型，详细设计模型为 PSM，相对于实现模型，详细设计模型为 PIM。

有关是否应该首先将 PIM 转换为非代码 PSM 然后再转换为代码，或者是否允许从 PIM直接生成代码（意味着您的 PSM 是代码），MDA 社区存在许多讨论。在使用 Java? 2 Platform, Enterprise Edition (J2EE) 和 Java 平台时，Rational Software Architect (RSA) 将代码构件可视化为 UML 关系图。此功能为您提供了优点，使您能够可视化平台构件，同时避免对额外的转换级别的需要。在本文中，您将应用程序建模为 PIM，然后将那些模型转换为 PSM，后者被直接捕获为实现构件。

这里介绍的许多原理也适合于其他建模层之间的转换。例如，当遵循 Rational Unified Process (RUP) 时，您可以从分析模型开始，然后将分析模型转换为设计模型的纲要。还可以将 WebSphere Business Modeler 模型转换为充当软件开发规范的 PIM。Rational Software Architect 包括此类转换，并且可以导入 WebSphere Business Modeler 模型。

IBM 和 MDA

白皮书“An MDA Manifesto”（请参阅 参考资料）清楚地说明了 IBM 的 MDA 远景。该白皮书介绍了 MDA 的三个基本原则，如图 2 和图 3 所示。

图 2. MDA 的三个基本原则

直接表示、自动化和开放标准的概念是模型驱动的方法的核心。

图 3. MDA 宣言的基本原则（来自 IBM）

软件工厂和领域特定语言

领域特定语言（domain-specific language，DSL）是一种为特定问题领域而开发的软件开发语言。DSL 的示例包括电子表格宏和数据库查询语言。DSL 在软件业已有很长的历史，但它们目前正在作为 Microsoft? 的软件工厂（请参阅 参考资料）活动的一部分而受到关注。

软件工厂定义为：

...一条软件生产线，其中根据用于构建特定种类的应用程序的方法，为诸如 Visual Studio Team System 等可扩展的开发工具配置了打包内容，例如 DSL、模式、框架和指导。例如，可以使用 .NET? 框架、C#、Microsoft Business Framework、Microsoft SQL Server 和 Microsoft Host Integration Server 来建立一个用于瘦客户端客户关系管理（customer relationship management，CRM）应用程序的软件工厂。配备此工厂以后，您可以快速实现无穷种类的 CRM 应用程序，每个应用程序包含基于特定客户的独特需求的独特功能。更好的是，通过使此工厂对第三方可用，然后第三方可以扩展此工厂以快速构建整合了其增值扩展的 CRM 应用程序，这样您就可以使用此工厂来创建一个生态系统。

MDD 和软件工厂方法之间存在大量的相似性。两种方法都提倡使用应用程序域概念和向软件生命周期中引入自动化。两种方法都强调可视化建模和通过模式来捕获专业技术的重要性。两种方法之间的主要区别是对开放标准（尤其是 UML）的重视。

创建 DSL 的 MDD 方法是引入 UML 概要，后者扩展并约束 UML 以实现特定的用途。例如，存在用于软件服务 (SOA)、测试和业务建模的 UML 概要。

UML 和 DSL

通常以过度简单化的术语来解释 UML 的作用：MDD 提倡将 UML 用于所有的领域特定的建模，而软件工厂方法则提倡从不使用 UML。这是对两种方法的定位的不恰当陈述。

虽然 MDD 方法将 UML（带自定义）视为用于大多数应用程序建模的首选建模语言，但它也承认自定义语言在某种专门情况下的价值。这就是 OMG Meta-Object Facility (MOF) 标准的目的，此标准在 MDD 中起着重要作用。UML 本身是使用 MOF 来定义的，并且存在许多其他语言的 MOF 定义。作为一种明智应用的技术，MDD 方法承认非 UML DSL 的价值。

软件工厂方法并不完全拒绝 UML。它假设您使用 UML 来开发纲要和文档，而非 UML DSL 则应该用于开发将在其基础上生成代码的模型。（参考资料中的“Visual Studio 2005 Team System Modeling Strategy and FAQ”条目提供了更多信息。）

从表 1 中可以看到，使用 UML 作为 DSL 的基础存在优点和缺点。

表 1. 使用 UML 概要作为 DSL 的优点和缺点

虽然 UML 是许多 DSL 的适当基础，但是在有些情况下，MDD 过程的部分则需要替代的方法。可以取代 UML 或额外尝试以下技术：

基于 MOF 的语言

在适合使用自定义语言的情况下，使用 MOF 来定义新语言。Rational Software Architect 包括的开放源代码组件 Eclipse Modeling Framework 生成一个用于处理 MOF 定义的语言的 Java 实现，以及用于以该语言创建模型实例的基本 Eclipse 工具。

将来，很可能生成完整的图形编辑器。此技术是用于实现 Rational Software Architect 支持的许多语言的技术，包括 UML 和 XSD。应小心使用此方法，以确保将该语言与 UML 和同一解决方案上下文中使用的其他非 UML DSL 集成。

自定义用户界面

对于某些用户，可视化的建模方法也许不适合于捕获他们的专门知识。具有逐步指南和自定义图形元素的自定义工具也许更适合用于填充模型。显然，这种方法具有与之关联的附加成本，但它是一项在恰当情况下适用的有用技术。

从现有格式进行转换

驱动 MDD 工具链所需要的信息可能已经捕获到现有的工具中。该工具可能是另一个软件建模工具、某个业务建模工具或诸如 Microsoft Excel 等桌面工具。可以访问的任何信息都可以转换为 UML 模型。特别是对于预先存在的资产，可以使用此方法来生成模型，而不是手动对相同的信息建模。

虚拟化

虚拟化 是将实现构件看作 UML 模型的技术。此类模型是平台特定的，但它们隐藏了一些细节，这些细节会转移对应用程序总体体系结构的注意力。

Rational Software Architect 支持 Java 和 J2EE 构件的虚拟化。这种工作模式可以获得建模的一些优点，同时还可以使用以代码为中心的方法。在使用虚拟化时，代码是主要构件，模型是在代码基础上生成的。模型不是持久化的（尽管其布局信息是持久化的）；它们只是代码的虚拟化。图 4 显示了一个简单的 J2EE 项目及其对应的 UML 虚拟化。

图 4. 实体 Bean 的虚拟化

模型是在代码基础上生成的。当被虚拟化的构件的模型（通常是在内存中）可用，因此不需要分析构件的文本表示形式时，虚拟化将变得更容易。这是在 MDD 工具链中使用非 UML 模型的示例。

虚拟化提供了模型驱动的方法的一些优点：

可以隐藏某些实现细节以获得系统的设计级视图。

UML 模型和代码保持同步，从而避免文档和实现之间的不匹配。

尽管虚拟化非常有价值，但它只能非常有限地提高抽象级别。在使用虚拟化时，我们仅限于隐藏受平台支持的概念的细节。存在两种在模型驱动开发中使用虚拟化的主要方法。虚拟化是：

实现 MDD 的一个步骤。除了拥有其自身的直接优点外，虚拟化还可以提高开发人员对 UML 建模的熟悉性。这种熟悉性可以简化到 MDD 方法的转换。

一种使用平台特定的 UML 模型的有用技术。与在应用程序模型和实现构件之间维护一个中间实现模型不同，您可以直接生成代码，同时仍然拥有将实现模型虚拟化的好处。

可执行的 UML

可执行的 UML 不是指具有执行语义的 UML。（UML 具有执行语义，虽然无疑可以在某些方面对它们进行加强和形式化，并且 UML 2.0 显著改进了这些语义。)可执行的 UML 通常与将 UML 视为完整的编程语言相关联，不只是对于高级语义的表示，而且是对于完整的可执行模型的表示。这样的模型在 UML 虚拟机上执行，或者通过编译为低级编程语言来执行。

可执行 UML 的替代方法以及当前 MDD 中的普遍做法是切换到某种低级编程语言以填充细节。可执行的 UML 方法具有开发人员不需要学习多种语言（UML 和目标语言）的优点。所有开发和调试都在建模级别实施。

UML 不支持通过操作和活动来表示详细的语义。但是，为这些构造提供的唯一符号是可视符号。人们一般认同文本语言对于捕获详细语义来说更为高效，例如数学算法和文本处理。

现在已经定义了许多可执行的 UML 语言，包括操作的文本表示法，并且 OMG 目前正在进行可执行 UML 标准的开发。

有关此方法的进一步变化是在 UML 模型中嵌入低级编程语言代码片段。这是 Rational Technical Developer 工具（以前的 Rational Rose Real-Time）所采用的方法，它将 Java 或 C++ 代码片段嵌入可执行的 UML 模型。

总结

在本文中，您了解到 OMG 的 MDA 活动如何正在致力于形式化 MDD 思想并提供标准以支持该方法。您探索了术语 MDD，此术语指的是一种与 OMG 正在开发的正式 MDA 大体一致的开发方法。

MDD 还具有许多与其他活动的相同之处，例如 Microsoft 的软件工厂和领域特定语言。尽管这些方法之间存在重要区别，例如标准对 MDD 的重要性，但它们也具有许多相似性。

将现有的构件可视化为 UML 模型是采用 UML 方法的第一步。此步骤可以实现模型驱动开发的一些优点，不过程度非常有限。

可执行 UML 方法将开发完全提升到建模级别。此方法在某些领域一直非常成功，但是还没有得到广泛采用。

第 4 部分: 将领域特定建模应用于模型驱动的体系结构

在本文中，使用 Eclipse Modeling Framework (EMF) 和 Graphical Modeling Framework (GMF) 技术来为领域特定语言产生领域特定建模辅助工具。了解定义领域特定语言的价值，探索基本概念和不同的建模方法，以及获取有关创建良好元模型的提示。

引言

在体系结构设计和软件工程中，您需要清楚理解体系结构的领域，并且能够有效地将该信息传达给其他人员。可以使用各种技术和工具来应对此挑战，例如使用领域特定语言（domain-specific language，DSL）和领域特定建模（domain-specific modeling，DSM）。DSM 充当 DSL 的前端，并允许用户通过可视化的表示形式来表示构造。

本文集中于使用 Eclipse Modeling Framework (EMF) 和 Graphical Modeling Framework (GMF) 技术来说明如何为 DSL 产生 DSM 辅助工具。

要使用 EMF 和 GMF 来开发 DSL 和 DSM，您需要以下工具：

1.建模和元模型建模概念和技术

使用 EMF 的建模

使用 GMF 模型来进行工具开发

2.模型转换概念和技术的建模

3.构件转换概念和技术的建模

4.软件工程和编程：

Java 编程

了解 EMF API

领域特定语言和建模

日常生活中存在许多适用或使用 DSL 的领域。一些实际 DSL 包括：交通和道路标志、平装家具组装图、象棋游戏（和大多数其他台式游戏）以及电路设计。与 IT 相关的 DSL 示例包括 HTML、SQL、WS-* 标准、业务流程执行语言（Business Process Execution Language，BPEL）和 POV 场景描述语言。

与这些 IT 示例相关的 DSM 示例包括所见即所得 (WYSIWYG) HTML 编辑器、BPEL 编辑器和 POV Modeler。

使用 DSL 来定义范围

定义 DSL 是非常有价值的，因为 DSL 通过设置非常特定的范围来帮助集中于特定的领域。一方面，小心设置的范围可以确保领域专家以结构化和详细的方式捕获知识和专门技术。另一方面，专门知识和技能可由该领域的用户提取并重用。

DSL 的另一个重要方面在于，它使您可以指定粒度，这意味着在详细描述和模糊描述之间寻求妥协，定义 DSL 部分将对此进行介绍。

为什么应该使用 DSL 而不是使用通用语言（general purposed language，GPL）呢？与 DSL 相比，GPL 使用足够简单和基本的词汇来描述任何领域，而不描述明确细节。可以使用 GPL 来实现相同级别的领域表示和理解，但是与 DSL 方法相比，GPL 对关于该领域和通用语言的预期知识级别要求是相当高的。DSL 的一个主要优点在于，它需要很少的时间即可理解和传达某个领域的详细信息。它需要很少的时间来学习使用相关工具。

例如，业务应用程序通常是使用复杂的软件解决方案来实现的，但是大多数解决方案都使用相同的构件（模式）来交付业务功能。DSL 使您可以对软件解决方案进行抽象，并隐藏实现细节。DSL 还可以使用来自业务领域的词汇，并为 IT 领域提供转换。

遗憾的是，存在使用得非常糟糕的 DSL 的实例（或反模式）。在这样的情况下，DSL 被用在错误的上下文中，并且通常是用于错误的目的。几个反模式的示例如下：

具有错误上下文的 DSL，并混合了抽象级别（例如，混合了用例和用户界面细节）

具有错误上下文的 DSL，并且未能分离关注事项（例如，混合了持久性细节和用户界面细节）

具有太多约束的 DSL，这是由僵化的结构所导致的（例如，复杂应用程序的配置细节）

具有太多元素（通常是由于未确定模式而导致的）或模型元素实例最终出现在元模型中的 DSL

具有冗余内容（例如，混合了用于不同类型的用户界面的用户交互流，包括 Web 浏览器，以及网页交互流）

回页首

定义领域

领域 是一个良好定义的主题方面，并使用一组有限的概念进行描述。DSL 和 DSM 中的领域通常以元模型的形式捕获，如 图 1 所示。设置恰当的领域范围和正确地定义边界是关键成功因素（将在稍后讨论）。

可以使用不同的表示法、技术和工具以许多不同的方式定义 DLS 的领域。大多数情况下，为 DSL 指定的领域被描述为元模型。这是一种流行的方法，因为：

元模型是自描述性的，并使用 DSL 来捕获 DSL 的元模型（领域）。

元模型相对容易理解；它们与实体关系模型非常相似。

元模型易于使用和重用于进一步的处理（模型驱动的开发）。

元模型非常适应模型驱动的体系结构方法。

图 1. 元-实例象限中的概念

元-实例象限中的概念

使用实体关系模型是一种定义 DSL 的形式。还存在其他方法和形式，但是本文将集中于实体关系建模技术，因为此项技术与稍后将描述的技术更密切相关。Eclipse 的 EMF 项目也正在遵循实体关系建模技术来捕获 DSL。实体关系模型相对易于捕获、易于维护、易于使用工具来支持，并且概念通常得到了很好的理解。

定义 DSL

成功的领域规范的秘诀是拥有描述该领域的良好元模型。（稍后将讨论良好元模型的要素。）捕获元模型并不是无足轻重的任务，而是需要大量的技能和经验。技能可以通过实践来获得。捕获元模型是某种类型的抽象，通常是架构师应该具备的技能。此活动所需要的实际技能是能够平面化层次（树形）结构。

存在各种捕获元模型的不同方法和技术。以下示例也许可以帮助您着手开始此任务。

使用纸和铅笔，开始绘制您希望获得的结果的模型实例。务必记住以下几个简单概念：

您是在绘制图而不是树（尽管树也是图）。

使用方框来表示元素。

在方框之间使用直接连接。

使用方框中的方框来表示包含。

此时不要过于担心外观，虽然大致了解以后将如何表示元素也是不错的。其他元素也是如此，例如连接。

开始考虑各个方框的属性。

不要考虑元素的可视化放置；例如，左侧的方框、位于 (10,10) 的方框 (x,y)。

考虑捕获和绘制多个实例。

考虑捕获同一个模型的不同表示形式（结构）。此方法可以帮助您更好了解领域，优化元模型，并使您可以开发工具友好的元模型。

一旦拥有了一组很好的模型实例，并且这组模型实例似乎表示了您希望捕获和传达的概念，即可开始使用建模工具（此处为 EMF）来捕获元模型并平面化元素层次结构。建模环境和工具的约束将指导您开发有效的元模型。

不存在用于测试元模型的简单方法，因此最好的选项是反复试验，直到该模型（基于已构建的元模型）与预想的结果密切匹配。幸运的是，创建工具是方便快捷的，因此试验过程也相对快速。

不要直接从该元模型的第一个实例构建关系图编辑器；应该首先使用更简单的模型编辑器，例如 EMF 树编辑器。

在树编辑器按预期工作以后，就可以开始构建第一个关系图编辑器了。这很可能也是一个迭代过程，同样应该使用反复试验的方法。

该元模型可能不是“工具友好”的，意味着该元模型的约束不允许您按最初计划的方式构建可视化编辑器。在此情况下，唯一的选项是返回到最初的元模型，并尝试使用不同的结构和构造来捕获相同的概念。设计工具友好的元模型是一项从经验中获得的技能。

在尝试捕获良好的元模型时考虑以下事项。

定义范围

确保模型中捕获的信息级别一致并且相关。仅捕获相关信息；不要构建或使用复杂的通用模型。在模型中捕获适当级别的详细信息，而不是混合不同的抽象级别。在捕获元模型时应用关注事项分离原则（将模型组件化）。确保模型中捕获的信息不会在开发过程中在其他模型中重复 DSM。在理想的情况下，所有的信息具有单个权威视图或模型，其他模型只是反映内容。

例如，基础设施建模将从集中于位置和可能功能的概念性节点的捕获开始，而不是考虑针对性能、可用性或类似特性的关注事项。下一步，您可以构建一个更特定的模型，其中包括前面放弃的关注事项（性能、可用性等等）。在非常详细的级别，该模型可以包括基础设施的物理细节，包括网络地址、计算机类型、规格等等。

粒度

不存在用于计算或决定正确粒度级别的神奇公式。可以提出以下问题以帮助您做出决定：

模型中应该捕获多少信息？

需要多少信息才足以充分理解该领域并且易于传达？

信息在什么情况下太多？

考虑粒度的一种方法是在模型中捕获细节和在转换中捕获细节之间寻找平衡：

捕获太多的细节就像是在使用某个模型或领域特定语言来开发代码。在此情况下，留给转换的细节所剩无几。

未在模型中捕获足够的信息会妨碍适当级别的理解和传达。在此情况下，大多数细节不得不包括在转换中。

确定领域

使用 DSL，提出应该确定多少个领域的问题是恰当的。答案取决于领域的上下文。与许多 IT 术语一样，领域 是一个被反复使用的术语。通常，在考虑要指定的领域数量时，您需要在两件事情之间进行区分。

首先，始终存在可正确地称为领域的更大领域。这始终适用于其中某些元素仅远程相关的更大上下文。Java? 2 Platform, Enterprise Edition (J2EE) 应用程序就是一个示例。这个大型领域包括 Enterprise JavaBeans (EJB)、Servlet 和 JavaServer Pages (JSP) 组件以及其他相关构件。

其次，DSL 中的领域上下文要比前一情况更小和更集中。在无法用特定的领域术语来表述的情况下，应该将这些领域称为子领域或微领域。J2EE 应用程序中的 EJB 模块就是一个示例。这个特定领域仅考虑各种类型的 EJB 和与之相关的构件。

处理语义

所有可能的元素安排（词汇）在领域中都具有特定的解释。不存在有关如何安排语言元素或如何解释这些元素的歧义性。需要在所定义的领域范围中表示的所有事物都可以使用该语言 (DSL) 来表示。

元模型中定义的约束是语义的关键驱动因素。约束可以确保无效的安排不会出现在模型中。

工具友好性

对于元模型，工具友好性是指为特定元模型 (DSL) 设计和开发工具的容易程度。“工具友好”不是科学度量；它是一种从工具开发的角度表示模型质量的方法。决定工具友好性是一项简单的测试：如果很容易为模型开发工具（在此例中为关系图编辑器），则模型是工具友好的。采用工具友好性是用于实现以下目的的很好做法：

更容易和更快的工具开发

快速的原型开发

加强的工具易用性

更好的领域理解

更好的模型构造和更高的模型重用机会

遗憾的是，在捕获元模型时，减轻工具开发人员的工作不属于优先考虑的事项。自底向上的方法通常产生工具不友好的元模型。然而，遵循自顶向下的方法（或任何其他方法）来捕获元模型并不能保证工具友好性。

领域特定建模

在诸如 IT 等工程科学中，专家使用模型、关系图和草图来描述问题或解决方案的特定细节。对可视化表示形式的需要起因于围绕该行业的高度复杂性。抽象和自动化论证了可视化建模需要的合理性。

IT 中的工程师处理各种输入、输出、工作产品和可交付件。一个输出可能成为另一个工作产品的输入。模型和关系图通常就是实际工作产品或其中的一部分。信息流、先前成果的重用以及工作流自动化论证了使用模型而不是使用简单关系图的合理性。

构建和使用工具方法应该实现：

架构师或程序员对领域的更好理解

工具友好的元模型

非常高的重用可能性

有关易用性和可用性的信息

更接近元模型的设计

所捕获的模型中可潜在地在其他场合共享和重用的语义

回页首

将 DSM 投入实践

根据“一幅图胜过千言万语”的精神，使用为特定领域定义的元素的可视化模型表示形式可以完整地描述整个解决方案。尽管可以使用许多技术和技巧来为 DSM 提供工具支持，但是本文仅讨论一个选项：使用 EMF 和 GMF 的 DSM。

在深入到使用 EMF 和 GMF 的细节之前，让我们看一下 DSL/DSM 与统一建模语言（Unified Modeling Language，UML）路线之间的简要比较。务必理解的是，存在不同的路线不是为了彼此竞争。

选择 DSL/DSM 还是 UML？

在某些方面，使用 DSL 和 UML 的建模处于该范围的两个对立端。UML 是一种统一（或通用）建模语言；它可以支持几乎任何模型。DSM 是一种领域特定 建模语言。它只能支持特定类型的模型。

使用 LEGO 玩具作为类比，将 UML 看作是一堆具有几种不同颜色和几种不同大小的基本标准积木块。DSL 就像是中世纪骑士城堡工具箱中的一组大尺寸的砌块、具有不同颜色和纹理的石块——与中世纪城堡的整段石墙类似的大型元素。可以想象人们如何通过该工具箱建造非常吸引人的实用城堡。但是，在基本石块基础上建造起来的城堡缺乏适当的颜色、纹理和中世纪特征。

存在两个单独的技能方面：定义 DSL 所需要的技能，以及使用该语言所需要的技能。

开发该语言 (DSL) 或建模工具 (DSM)

使用 EMF 和 GMF 需要 EMF 的知识，EMF 不过就是一个实体关系建模工具。GMF 本身就是一种 DSL，您必须理解它才能开发图形关系图编辑器。

使用 UML2 的开发需要充分了解 UML2 元素、元素之间的关系，以及如何定义构造型来对元素进行自定义。以图形关系图编辑器为例。如果该编辑器的功能不足够，则存在某种程度的自定义空间，此自定义需要特定的开发技能。

使用该语言 (DSL) 或建模工具 (DSM) 本身进行开发

对于 EMF 和 GMF，一旦了解了特定的领域，开发是非常简单的。

在 UML2 的情况下，开发人员必须熟悉特定的领域和 UML2 本身。

UML2 的用户群比 EMF 和 GMF 更大，但是 EMF/GMF 阵营正在不断发展（通过邮件列表上的活动和有关该主题的日益增加的文章数量可以判断出这一点）。相反，谈到开发 DSL/DSM，EMF 和 GMF 通常是首选的技术。选择 EMF 和 GMF 的主要原因是 UML 关系图中缺乏对某些更复杂的构造的支持。

在将 IBM? Rational? Software Architect 中的 UML2 与 RSA 中的 EMF 和 GMF 做比较时，团队开发是一个重要的方面。除了基于 Eclipse 工作台的标准团队开发支持以外，Rational Software Architect 中的 UML2 工具还具有高级的建模功能以支持团队开发。这些功能包括模型比较、差异突出显示和模型合并。EMF 目前不具备相同级别的团队开发支持。

回页首

探索 EMF 和 GMF 路线

EMF 是来自 Eclipse 工作台的成熟技术。有关使用 EMF 的详细信息超出了本文的范围。有关高级功能的概述和信息，请参见 参考资料。

使用 GMF 进行图形建模

作为 Eclipse 中的一个相对较新的项目，GMF 提供了一个为 Eclipse 工作台开发图形工具和关系图编辑器的框架。该框架包括两个部分：

GMF 运行时（Eclipse 的一部分，并提供用于图形工具的基本的公共元素和服务）

GMF 工具（帮助进行使用 GMF 运行时的 Eclipse 插件的开发，以交付最终的建模工具）

GMF 本身的工具是一组专用于图形建模工具开发的 DSL。从本质上讲，GMF 合并各种图形建模工具中的功能、能力和模式（超集），从该工具超集中提取可变性，并最终为开发模式提供一个建模前端。

GMF 是用于为 DSL/DSM 开发工具的理想选择，因为它：

方便快捷

遵循模型驱动的方法，无需编写任何一行代码即可产生结果

提供了可满足图形建模工具环境的大多数复杂和苛刻要求的完善级别

产生高质量的工具

建模方法

图 2 显示了用于构建建模工具、建模本身和在模型基础上产生构件的最基本方法。

图 2. 基本建模方法

图 2. 基本建模方法

从本质上讲，如图所示，存在两个起点：

首先创建元模型，而不考虑最终构件的关注事项

使用最终构件来驱动元模型的开发或在最终构件基础上生成元模型

从元模型开始，开发人员必须建立该特定领域的元模型或语言。约束可以充实元模型，以确保模型实例的语义正确性和有效性。大多数图形编辑器都可以在元模型的基础上生成，但是其他部分则必须手动进行定义。可以为图形编辑器指定一组新的约束，因为图形表示形式可能使用与原始元模型不同的构造来进行建模。可以使用图形编辑器来创建和编辑模型实例。这些模型是模型驱动的开发的结果。模型成为转换的输入，以生成最终构件（例如代码）。

前面提到的两个入口点与两种基本的建模方法相关：自顶向下和自底向上。

自顶向下的建模方法首先捕获元模型，然后开发转换和代码生成器以产生构件。表 1 显示了自顶向下的建模方法的优点和缺点：

表 1. 自顶向下的建模方法的优点和缺点

优点 缺点

存在构建工具友好的元模型的更好机会。

可能不会产生预期的构件或提供用于生成构件的理想输入。

由于前述原因，正反向工程可能中断。

自底向上的建模方法从构件开始，基于实例构建模型，最后在模型的基础上定义元模型。表 2 显示了自底向上的建模方法的优点和缺点。

表 2. 使用自底向上建模方法的优点和缺点

优点 缺点

代码（构件）生成器要么很容易开发，要么是其中一个副产品。

开发元模型来表示构件的概念和上下文是非常繁琐的。

创建工具友好的元模型非常繁琐，需要技能和专业知识。

上述两种方法的组合是“中间相遇”(meet in the middle) 方法，此方法利用了前述两种方法的优点。开发从两个方向开始，在概念元模型基础上创建工具，同时基于构件创建元模型。通过一组转换建立所获得的两个元模型之间的联系。表 3 显示了这种组合方法的优点和缺点。

表 3. 使用“中间相遇”方法的优点和缺点

优点 缺点

从现有的模型和构件开始；不需要开发新的模型和构件。

可能获得预期用于图形建模和用于生成构件的结果。

需要深入理解现有的元模型（自顶向下和自底向上），因为它们很可能来自于不同的来源。

很可能需要附加的开发或使用映射工具来进行转换。

实际上，自顶向下的方法很少产生元模型以支持开发构件的生成。这种方法对于捕获概念及其关系是非常出色的。类似地，自底向上的方法很少产生可有效地传达或描述特定领域的元模型。尽管可以遵循纯粹的自顶向下或自底向上的方法，但这样充满了挑战。

约束

约束和验证经常作为与元模型和 DSL 相关的主题一并进行讨论。约束 确保模型实例在语义上是正确的。验证 是检查模型实例上的约束的过程。验证还可以为建模人员提供反馈，从而帮助纠正模型。

用 DSL 术语来说，约束确保使用该语言的词汇来构造的句子是有意义的。可以通过不同的形式定义元模型的约束，包括使用：

某种约束语言，例如 OCL

特定扩展点的某种编程语言，例如 Java

正则表达式，例如 regexp

约束不仅限制模型中的某些构造，其中某些约束还可以计算和填充元素的值。还可以在元模型中捕获一些较简单的约束，而不需要用于支持复杂约束的扩展。这些约束可以是必需属性、基数或预定义（缺省）值。

转换

转换用于将表示源实例的数据和结构映射到表示目标实例的新结构和数据。转换中的源和目标可以是模型或任何其他构件。用 DSL 术语来说，转换是不同领域之间或某个领域和其他构件之间的映射操作。之所以需要转换，通常是因为实例（模型或构件）在不同的领域中、具有不同的格式或具有不同的版本。实际上，转换可用于各种目的，例如：

在模型基础上生成代码

将一个或多个模型映射到另一个模型（一对一或多对一）

在代码构件基础上生成模型

在使用转换时，具有相同元模型的模型实例之间的几个转换示例包括：

充实或扩展源模型

初始化源模型

更改源模型中的数据（包括版本更新）

GMF 应用程序的开发过程中有一组用作示例的很好转换。GMF 仪表板（Eclipse 视图）甚至提供了转换步骤、构件及其关系的可视化表示形式。

开发过程

为 DSL/DSM 开发工具是一个高度迭代的过程，如下所述。

开发元模型。可以通过各种格式捕获元模型，例如 XML 模式 (XSD)、带注释的 Java 代码、ECore 模型或 Rational Rose? UML 模型。

生成基本工具将产生一个简单的树形编辑器。此编辑器已经是一个可用的工具，没有新奇的功能，仅用于满足基本的编辑需要。

使用该基本工具来测试模型。重复从步骤 1 开始的步骤，直到达到预期的结果。

通过以下方式创建并指定工具模型：

创建工具面板 (.gmftool)。

创建图形元素及其可视化表示形式 (.gmfgraph)。

创建领域模型、图形和可视化元素以及工具面板之间的映射 (.gmfmap)。

在前面步骤中指定的模型的基础上生成工具。

测试该图形建模工具。

从步骤 4 开始重复，直到达到预期的结果。

此时，基于某个元模型的图形建模工具已经可用了。如果该建模工具产生输出，此输出可能只是一个持久化的模型实例，则无需做其他工作。如果预期该模型将用作所生成的构件的基础，则很可能必须开发一组转换。

下面的图来自于 GMF Eclipse 项目中附带的 Mindmap 示例。这些图显示了一组用于开发 GMF 工具的典型模型和项目构件。图 3 显示了 Mindmap 工具。

图 3. 用于 Mindmap 工具的 .ecore 模型

图 3. 用于 Mindmap 工具的 .ecore 模型

图 4 显示了工具面板定义。

图 4. 工具面板定义

图 4. 工具面板定义

图 5 显示了图形元素和形状定义。

图 5. 图形元素和形状定义

图 5. 图形元素和形状定义

图 6 显示了 .ecore 模型、工具面板以及图形节点和形状之间的映射定义。

图 6. .ecore 模型、工具面板以及图形节点和形状之间的映射定义

图 6. .ecore 模型、工具面板以及图形节点和形状之间的映射定义

图 7 显示了项目细节和构件。

图 7. 项目细节和构件

图 7. 项目细节和构件

图 8. 带有所有模型的 GMF Dashboard

图 8. 带有所有模型的 GMF Dashboard

回页首

开发和运行时环境

Eclipse 是使用 EMF 和 GMF 来进行 DSL 和 DSM 开发的开发环境。IBM 的 Rational Software Architect 包括了为 DSL 和 DSM 开发工具所必需的所有 Eclipse 项目。相关项目包括 EMF、GEF、GMF、UML2 和 EMFT。Eclipse Modeling Project 具有这些项目的详细信息。前面描述的工具开发的结果是 Eclipse 插件。本质上，工具的运行时环境是 Eclipse 工作台。

主要开发用于建模的插件的两种使用形式如下：

安装在现有的 Eclipse 工作台之上，使其成为开发环境不可或缺的一部分。

安装为独立插件，仍然使用 Eclipse 工作台，但是独立于 Rich Client Platform 之上的其余开发工具而运行。

回页首

总结

领域特定语言和领域特定建模是许多不同 IT 角色（甚至 IT 以外的角色）的工具箱中的强大工具。通过使用 DSL 和 DSM，IT 架构师可以清楚理解他们所处理的领域，并且能够更有效地传达该领域的细节。然而，务必记住 DSL 和 DSM 不是解决所有问题的万能答案——它们的适用性取决于所构建的语言和工具的优劣情况。