| UML软件工程组织 | |||
| |
|||
|
|||
探索模型驱动开发 (MDD) 和相关方法，第 4 部分: 将领域特定建模应用于模型驱动的体系结构
2008-07-31 作者：Peter Kovari 出处:IBM
在本文中，使用 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，您需要以下工具：
领域特定语言和建模日常生活中存在许多适用或使用 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 和 DSM 中的领域通常以元模型的形式捕获，如 图 1 所示。设置恰当的领域范围和正确地定义边界是关键成功因素（将在稍后讨论）。 可以使用不同的表示法、技术和工具以许多不同的方式定义 DLS 的领域。大多数情况下，为 DSL 指定的领域被描述为元模型。这是一种流行的方法，因为：
使用实体关系模型是一种定义 DSL 的形式。还存在其他方法和形式，但是本文将集中于实体关系建模技术，因为此项技术与稍后将描述的技术更密切相关。Eclipse 的 EMF 项目也正在遵循实体关系建模技术来捕获 DSL。实体关系模型相对易于捕获、易于维护、易于使用工具来支持，并且概念通常得到了很好的理解。 成功的领域规范的秘诀是拥有描述该领域的良好元模型。（稍后将讨论良好元模型的要素。）捕获元模型并不是无足轻重的任务，而是需要大量的技能和经验。技能可以通过实践来获得。捕获元模型是某种类型的抽象，通常是架构师应该具备的技能。此活动所需要的实际技能是能够平面化层次（树形）结构。 存在各种捕获元模型的不同方法和技术。以下示例也许可以帮助您着手开始此任务。
在尝试捕获良好的元模型时考虑以下事项。
在诸如 IT 等工程科学中，专家使用模型、关系图和草图来描述问题或解决方案的特定细节。对可视化表示形式的需要起因于围绕该行业的高度复杂性。抽象和自动化论证了可视化建模需要的合理性。 IT 中的工程师处理各种输入、输出、工作产品和可交付件。一个输出可能成为另一个工作产品的输入。模型和关系图通常就是实际工作产品或其中的一部分。信息流、先前成果的重用以及工作流自动化论证了使用模型而不是使用简单关系图的合理性。 构建和使用工具方法应该实现：
将 DSM 投入实践根据“一幅图胜过千言万语”的精神，使用为特定领域定义的元素的可视化模型表示形式可以完整地描述整个解决方案。尽管可以使用许多技术和技巧来为 DSM 提供工具支持，但是本文仅讨论一个选项：使用 EMF 和 GMF 的 DSM。 在深入到使用 EMF 和 GMF 的细节之前，让我们看一下 DSL/DSM 与统一建模语言（Unified Modeling Language，UML）路线之间的简要比较。务必理解的是，存在不同的路线不是为了彼此竞争。 在某些方面，使用 DSL 和 UML 的建模处于该范围的两个对立端。UML 是一种统一（或通用）建模语言；它可以支持几乎任何模型。DSM 是一种领域特定 建模语言。它只能支持特定类型的模型。 使用 LEGO 玩具作为类比，将 UML 看作是一堆具有几种不同颜色和几种不同大小的基本标准积木块。DSL 就像是中世纪骑士城堡工具箱中的一组大尺寸的砌块、具有不同颜色和纹理的石块——与中世纪城堡的整段石墙类似的大型元素。可以想象人们如何通过该工具箱建造非常吸引人的实用城堡。但是，在基本石块基础上建造起来的城堡缺乏适当的颜色、纹理和中世纪特征。 存在两个单独的技能方面：定义 DSL 所需要的技能，以及使用该语言所需要的技能。
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 的详细信息超出了本文的范围。有关高级功能的概述和信息，请参见 参考资料。 作为 Eclipse 中的一个相对较新的项目，GMF 提供了一个为 Eclipse 工作台开发图形工具和关系图编辑器的框架。该框架包括两个部分：
GMF 本身的工具是一组专用于图形建模工具开发的 DSL。从本质上讲，GMF 合并各种图形建模工具中的功能、能力和模式（超集），从该工具超集中提取可变性，并最终为开发模式提供一个建模前端。 GMF 是用于为 DSL/DSM 开发工具的理想选择，因为它：
图 2 显示了用于构建建模工具、建模本身和在模型基础上产生构件的最基本方法。 图 2. 基本建模方法
从本质上讲，如图所示，存在两个起点：
从元模型开始，开发人员必须建立该特定领域的元模型或语言。约束可以充实元模型，以确保模型实例的语义正确性和有效性。大多数图形编辑器都可以在元模型的基础上生成，但是其他部分则必须手动进行定义。可以为图形编辑器指定一组新的约束，因为图形表示形式可能使用与原始元模型不同的构造来进行建模。可以使用图形编辑器来创建和编辑模型实例。这些模型是模型驱动的开发的结果。模型成为转换的输入，以生成最终构件（例如代码）。 前面提到的两个入口点与两种基本的建模方法相关：自顶向下和自底向上。 自顶向下的建模方法首先捕获元模型，然后开发转换和代码生成器以产生构件。表 1 显示了自顶向下的建模方法的优点和缺点： 表 1. 自顶向下的建模方法的优点和缺点
自底向上的建模方法从构件开始，基于实例构建模型，最后在模型的基础上定义元模型。表 2 显示了自底向上的建模方法的优点和缺点。 表 2. 使用自底向上建模方法的优点和缺点
上述两种方法的组合是“中间相遇”(meet in the middle) 方法，此方法利用了前述两种方法的优点。开发从两个方向开始，在概念元模型基础上创建工具，同时基于构件创建元模型。通过一组转换建立所获得的两个元模型之间的联系。表 3 显示了这种组合方法的优点和缺点。 表 3. 使用“中间相遇”方法的优点和缺点
实际上，自顶向下的方法很少产生元模型以支持开发构件的生成。这种方法对于捕获概念及其关系是非常出色的。类似地，自底向上的方法很少产生可有效地传达或描述特定领域的元模型。尽管可以遵循纯粹的自顶向下或自底向上的方法，但这样充满了挑战。 约束和验证经常作为与元模型和 DSL 相关的主题一并进行讨论。约束 确保模型实例在语义上是正确的。验证 是检查模型实例上的约束的过程。验证还可以为建模人员提供反馈，从而帮助纠正模型。 用 DSL 术语来说，约束确保使用该语言的词汇来构造的句子是有意义的。可以通过不同的形式定义元模型的约束，包括使用：
转换用于将表示源实例的数据和结构映射到表示目标实例的新结构和数据。转换中的源和目标可以是模型或任何其他构件。用 DSL 术语来说，转换是不同领域之间或某个领域和其他构件之间的映射操作。之所以需要转换，通常是因为实例（模型或构件）在不同的领域中、具有不同的格式或具有不同的版本。实际上，转换可用于各种目的，例如：
在使用转换时，具有相同元模型的模型实例之间的几个转换示例包括：
为 DSL/DSM 开发工具是一个高度迭代的过程，如下所述。
此时，基于某个元模型的图形建模工具已经可用了。如果该建模工具产生输出，此输出可能只是一个持久化的模型实例，则无需做其他工作。如果预期该模型将用作所生成的构件的基础，则很可能必须开发一组转换。 下面的图来自于 GMF Eclipse 项目中附带的 Mindmap 示例。这些图显示了一组用于开发 GMF 工具的典型模型和项目构件。图 3 显示了 Mindmap 工具。 图 3. 用于 Mindmap 工具的 .ecore 模型
图 4 显示了工具面板定义。 图 4. 工具面板定义
图 5 显示了图形元素和形状定义。 图 5. 图形元素和形状定义
图 6 显示了 .ecore 模型、工具面板以及图形节点和形状之间的映射定义。 图 6. .ecore 模型、工具面板以及图形节点和形状之间的映射定义
图 7 显示了项目细节和构件。 图 7. 项目细节和构件
图 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 工作台。 主要开发用于建模的插件的两种使用形式如下：
总结领域特定语言和领域特定建模是许多不同 IT 角色（甚至 IT 以外的角色）的工具箱中的强大工具。通过使用 DSL 和 DSM，IT 架构师可以清楚理解他们所处理的领域，并且能够更有效地传达该领域的细节。然而，务必记住 DSL 和 DSM 不是解决所有问题的万能答案——它们的适用性取决于所构建的语言和工具的优劣情况。 参考资料学习
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
