第 1 部分: 使用模式的模型驱动开发范例的概述

模型驱动开发（Model-driven development，MDD）是软件开发的一种样式，其中主要的软件工件都是由代码和其他工件所生成的模型。其目标是提高企业应用程序开发的生产力和质量。模式在 MDD 的模型转换和代码生成中扮演重要角色。本系列文章详细地讨论了利用 IBM ? Rational? Software Architect（支持 MDD 的集成开发环境）进行模型驱动及基于模式的开发范例。

引言

模型驱动开发（Model-driven development，MDD）是由模型驱动体系架构（Model-driven Architecture，MDA）技术支持并驱动的新软件开发范例，是对象管理组织（Object Management Group，OMG) 发布的软件设计方法。MDA 提供一组指南，用于构建表示为模型的规范，从独立于平台的模型（platform-independent model，PIM）开始，通过适当的具体到领域的语言，然后转换为用于实际的实现平台的一个或多个具体到平台的模型（platform-specific models，PSMs）。它可以是很多种平台，例如 Java? 2 Platform、Enterprise Edition (J2EE?)、CORBA 或 .Net，以通常的程序设计语言实现，例如 Java?、C# 和 Python。MDA 通常用自动化的工具来执行，如 IBM? Rational? Software Architect。MDD 由 MDA 驱动，并更着重于模型转换和代码生成。

然而，MDD 所使用的基于代码生成的方法有它不利的方面，这是由于例如所生成代码中的约束、技术不强的开发人员和与模型的紧耦合等因素造成的。当企业 100％ 地投入到代码生成中时，就没有余地进行调整了，尤其是在开发人员仔细检查其模型的时候。

基于模式的开发方法能够帮助解决该问题。模式是在已知环境中重现问题的解决方案。模式将设计人员的时间、技能和知识进行萃取，从而解决软件问题。此外，当模式在许多不同的项目中重复地使用时，它就成为了最佳实践。通过设计特殊的设计模式，开发人员可以更灵活地控制所生成的代码，这就不简单地拘泥于抽象模型了。

而且，MDD 可以通过转换自动化地实现模式，这将排除重复的低层次开发工作，并且可以将技术性的专家经验加入到代码中，以提高一致性和可维护性。为了生成能够将变更反映到实现架构的解决方案工件，就要迅速地重新应用被修改的转换。

本文关注于如何用基于资产的开发来优化作为集成开发方法的 MDD。使用该方法，开发人员首先用统一建模语言（Unified Modeling Language，UML）构建对象模型，然后通过利用了模式存储库的代码生成工具来生成代码。

使用 Rational Software Architect 来应用 MDD

阅读了此信息，您可能发现，应用该开发方法需要可以支持以下内容的集成开发环境（Integrated Development Environment，IDE）：

使用 UML 建模

模式基础架构

模型转换和代码生成

具体到平台的设计和开发工具及单元测试环境

Rational Software Architect 是提供以上所有功能的工具。Rational Software Architect 是能够利用 UML 进行模型驱动开发的集成设计和开发工具，用以创建良好架构的应用程序和服务。有了 Rational Software Architect，您可以：

利用开放且可扩展的建模平台

加速软件建模和设计

将开发过程自动化并且将资产复用最大化

更有成果地开发应用程序和 Web 服务

UML 模型

MDD 的主要特点之一是将模型作为重要工件。模型是以特定的观点对系统的描述，忽略了不相关的细节，同时更清晰地看到关注的特性。在 MDD 中，模型必须是计算机能够处理的，这样您可以用自动化的方式访问模型的内容。为了让您能够生成工件，模型必须是计算机可以处理的。白板上的图可能会满足作为模型的其他标准，但直到您以计算机能够处理的方式获取它时，您才能在 MDD 工具链中使用它。

软件模型一般用 UML 表示。UML 模型隐藏了技术实现细节，这样可以利用来自应用领域的概念来设计系统。一般应用程序设计用 UML 建模工具，例如 Rational Software Architect，以及与应用领域相关的概念来实现。

甚至在 MDD 之前，使用 UML 模型来设计软件就是很好的实践。在大部分情况下，以两种方式来使用模型：

作为非正式地传达系统某个方面的框架结构

作为描绘您人工实现的详细设计的蓝图。

在 MDD 中，模型不仅用作框架结构或蓝图，而且作为主要工件，通过应用转换，由这些工件生成有效的实现。在 MDD 中，在开发新软件组件时，准确的描述面向领域的应用程序模型是主要关注点。代码和其他目标领域工件利用根据建模专家和目标领域专家而设计的转换来生成。

转换

UML 建模是有价值的技术，但人工地将模型和代码同步是容易出错且消耗时间的。转换是区别 MDD 与其他使用建模的方法的主要特征。MDD 是将开发过程自动化，从而生成任何工件，这可以源于模型中的信息。除了代码，由转换而生成的工件包括，但不限于以下内容：

文档：在遵照正式的开发方法的组织中，生成文档占据重要的开发工作。保持文档与实现的一致是众所周知的难题。当使用 MDD 时，由模型来生成文档。这既确保了一致性，又使得开发人员每天处理的模型中的信息可用，而不是在很难导航的文档中搜寻。文档可以通过工具，例如 Rational Software Architect 的 Report Generator 来生成，或者通过转换来生成。

测试工件：由软件模型中包含的信息很可能生成基础的测试工件（例如，利用 JUnit）。

构建并部署脚本：利用专长，构建和部署架构师可以创建生成构建及部署脚本的转换。

其他模型一个系统包含不同的抽象层次（分析、设计、实现）上的相互依赖的模型，表示系统不同的部分（UI、数据库、业务逻辑、系统管理），不同的关注点（安全、性能和弹性），或不同的任务（测试、部署建模）。在许多情况下，由一个模型部分地生成另一个模型是可能的事情（例如，从分析模型转换为设计模型，或者从应用模型转换为测试模型）。

模式

MDD 的另一个主要特征是获取专家经验。模式获取最佳实践解决方案来重现问题。在 MDD 中，模式可以出现在建模的所有抽象层次上。例如：

架构模式

设计模式

实现模式

模式是可以进行组合的，用以为解决更大的问题而生成模式菜单，并且涵盖领域的最佳实践。

模式指定模型元素的特征，以及那些元素之间的关系。当您将模式应用到模型中时，您可以将模式自动化，在转换中新的元素被创建，已有的元素被修改，以符合模式的定义。

模式提高解决方案的一致性和质量。这可以通过在 MDD 中使用转换来自动化模式的实现来完成这一点，这样可以排除重复的低层次开发工作。与其在构建解决方案工件时重复且人工地应用技术专家经验，倒不如将专家经验直接编入转换之中。这样做就拥有了一致性和可维护性的双重优势。迅速地再次应用修改了的转换，从而生成将变更反应到实现架构上的解决方案工件。

从业务问题到软件解决方案

图 1 展示了如何利用 MDD 将业务问题转换为软件解决方案。评审业务问题，并且应用一些通用的业务模式。这样做部分地填充了设计模型，并且在构建的具体业务功能中加入细节。然后，应用平台独立的设计模式，以将设计模型转换为运行时独立的组件。在那之后，选择运行时平台，并且使用具体到运行时的实现模式来生成工件。

图 1. 利用 MDD 将业务问题转化为软件解决方案

使用带有模式的 MDD 的好处

软件开发行业已经发现了采用带有模式的 MDD 的很多好处。一些重要的包括：

提高生产率： MDD 通过从模型生成代码和工件来减少软件开发的成本，这样做提高了开发人员的生产率。

增加复用： MDD 在应用于大型项目或组织层时优势尤其明显。这是因为在每次复用它们时，开发转换的投资回报率都有所提高。使用可靠且经过测试的转换还可以提高开发新功能的可预计性，并且减少项目风险（因为架构和技术问题已经解决了）。

提高可维护性：技术的演进导致解决方案组件逐渐成为先前平台技术的遗产。MDD 帮助解决这一问题，它引出可维护的架构，在该架构中可以快速且一致地进行变更，使您更有效地将组件迁移到新技术上。

灵活性更强：高层次的模型与实现细节无关。保持模型与实现细节无关可以使得处理底层平台技术及其技术架构中的变更成为更容易的事情。通过更新转换来完成对实现的技术架构的变更。再次对原来的模型应用转换，从而生成依照新方法的实现工件。

一致性： 人工地应用编码实践和架构上的决策是容易出错的活动。MDD 确保一致地生成那些工件。

提高沟通性： 模型省略了与了解系统逻辑行为不相关的实现细节。因此，模型更接近问题领域，减少了涉众所了解的概念和解决方案所用的表示语言之间的语义鸿沟。模型还简化了设计层系统的理解及退出。这形成了对系统的沟通性的增加。

保留专家经验： 项目或组织经常依赖于重复做出最佳实践决策的重要专家。有了模式和转换中获取的专家经验，他们不需要出现在项目的其他成员面前来应用（得益于）这些经验。

降低风险： 当使用 MDD 方法时，早期的应用程序开发着重于建模活动。这意味着，直到晚些时候才选择具体的技术平台或产品版本是可能的（当进一步的信息可用时，从而减少风险）。

经验教训

MDD 是可靠的开发方法。然而，行业反馈指出，不是所有使用 MDD 的项目都是成功的。这一般源于一些因素：

糟糕的项目选择

计划不充分

缺少必要的经验和技能

要帮助您从 MDD 中获得最大利益，以下是一些从过去项目中获得的经验。

选择恰当的候选项目： MDD 在应用于大型项目或组织层之上时特别强大，因为来自转换的开发或购买中的投资回报（return on investment，ROI）在每次复用时都增加了。好的候选项目也应该有良好的架构和可重复的行为的模式，以便可以对那些模式进行抽象，从而获取专家经验，并且在转换中使用。

考虑附加的成本： 您可能需要考虑开发或购买转换的成本，但是谨慎的成本计划可以确保长期内的成本降低。

取得小的成功： 在许多组织中，一些怀疑论对新的方法进行质疑，直到新方法得到证实。如果这是您使用 MDD 方法的第一个项目，那么明智的做法是将 MDD 工具的开发分割为许多迭代。后继的迭代建立于您所获得的经验之上，允许您支持越来越广的业务应用程序的情景集。

发展适当的技能： MDD 要求架构师和开发人员要熟悉 UML 和 MDD 的 IDE。在团队中培养成这些技能最初要花些时间，这导致了项目延迟。然而，对于同样的项目团队，后继的项目将更容易。如果这是您第一个使用 MDD 的项目，那么引入专家来发动团队是很好的选择。

时刻考虑复用：在应用程序开发人员为业务应用程序生成工件时，它们会多次使用为项目而构建的 MDD 工具。该工具在后继的项目中得到复用也是可能的。时刻考虑在更大的环境中复用将在长期内为您的组织带来重大的好处。

选择适当的开发工具。 拥有适当的工具将确保您从 MDD 中获得最大价值。项目团队（包括项目经理、业务分析人员、解决方案架构师、开发人员，和测试人员）应该评估并验证正在使用的开发工具。

总结

本系列第 1 部分描绘出模型驱动和基于模式的开发范例的全景。概括地说，MDD 开启了模式的潜能，以创建设计优良的解决方案，而模式为 MDD 提供内容。

第 2 部分: IBM Rational Software Architect 中的模型驱动开发工具支持

Rational Software Architect 为使用模式的模型驱动开发（model-driven development，MDD）提供完整的工具支持。Rational Software Architect 基于资产的开发框架通过支持模型、模式和转换的复用来补充 MDD。本文中一个简单的情景向您概述了如何在 MDD 中使用 Rational Software Architect。

如本系列第 1 部分中所提到的，要使用模型驱动及基于模式的开发方法，您需要支持以下内容的集成开发环境（integrated development environment，IDE）：

利用统一建模语言（Unified Modeling Langugage，UML）建模

模式基础架构

模型转换及代码生成

具体到平台的设计和开发工具

单元测试环境

IBM? Rational? Software Architect 不但提供支持端到端的模型驱动开发（model-driven development，MDD）的这些功能，而且还提供支持基于资产开发的增值功能，通过支持模型、模式和转换的复用为 MDD 进行补充（参见图 1）。

图 1. 集成开发环境图

本文，也就是系列的第 2 部分，强调了与模型驱动开发、模式和基于资产的开发相关的 IBM Rational Software Architect 的重要工具支持。一个简单的场景将指导您了解那些特性，并且为第 3 部分中的案例研究做准备。

利用 UML 建模

模型已经成为软件设计的主要工件，因此从相应的程序代码上转移走了相当多的注意力。因而，模型不仅令您获取并传达应用程序架构的所有方面，而且还作为各种自动和半自动过程导出程序和相关模型的源头。所以，您可以将模型用作以下目的：

可视化地表示您想要构建的系统

促进对系统的一般了解

开发、验证，并传达系统的架构

生成代码

Rational Software Architect 集成了强大的 UML 软件建模框架，并且完全支持 UML 2.0（UML 标准的第一个重要的修订版）建模。这意味着它能够更好地支持 MDD 工具及方法，可以帮助您获取并传达设计的意图。

在 UML 建模中，模型包含许多元素，例如角色、用例、类和包，以及一个或多个表示系统具体角度的图，例如活动图或类图。

Rational Software Architect Modeling 透视图

Rational Software Architect 提供了一个组合以下相关视图的建模透视图。

Model Explorer

Model Explorer（图 2）展示了可能包含许多模型的建模项目。模型（本身就是模型元素）包含相应的模型元素，例如包、类、参数、方法和约束。在 Model Explorer 中，您可以添加、删除、分类，并组织元素，您还可以在图编辑器中打开 UML 图。

图 2. 展示 Model Explorer 视图的抓图

Diagram Navigator

Diagram Navigator 是工作区中不同的项目视图。它在目录（树型）视图中显示建模项目、UML 模型，及其 UML 图，如 图 3所示。

图 3. Diagram Navigator 视图的抓屏

UML 图帮助您可视化并控制模型中的元素。不同的图表示您正在开发的系统、应用程序，或数据库的不同视图。因为图可以说明模型的多个方面，所以同样的模型元素可以出现在一个或多个图中。

UML 利用许多涉众公认的标准标记，提供让用户获取并传达应用程序架构所有方面的各种图。这些是 13 个正式的 UML 2.0 图，每一个都表示系统的不同方面：

活动图：活动图提供对系统行为的视图，它描述了过程中的活动序列。除了展示活动中动作之间的流，类似流程图，活动图还可以展示并行或并发的流，及交替的流。

类图：您可以使用类图来对组成系统的对象建模，展示对象之间的关系，以及描述那些对象要做什么，及它们要提供什么服务。类图对对象建模过程是很重要的，并且在分析和设计阶段是有用的。

通信图：原来在 UML 1 中称为协作图，通信图展示了对象之间的消息流，并且展示了若干对象如何一起合作实现共同目标。类似于序列图，通信图也对用例的动态行为建模。然而，通信图更看重对象的协作，而不是时间序列。

组件图：组件图展示了系统组件之间的结构关系。在 UML 2 中，组件是系统或子系统中自治，封装的单元，它提供一个或多个接口。因此，组件图能够让架构师来验证，组件在实现系统的所需功能。

复合结构图：复合结构图探索了在通信链路上协作的连通实例的运行时实例。

部署图：部署图描述了处理节点的运行时配置，以及运行于那些节点（系统的硬件、安装在硬件之上的软件，以及连接不同机器的中间件）之上的组件的静态视图。

交互总览图：交互总览图是活动图的变体，它当中的节点表示交互图。交互图包含序列、通信、交互总览，及时序图。

对象图：使用对象图来探究对象的真实世界的实例，以及它们之间的关系。对象图类似于类图，因为关系的标记是一样的。要解释对象之间复杂的关系，对象图是很好的选择。

包图：包图可以让您将模型元素组织为用文件夹表示的组，这使 UML 图更容易理解。

序列图：序列图说明了交互中对象之间消息的时间序列。它包含参与者小组，例如角色、系统或子系统、类，和用生命线表示的组件，以及交互过程中交换的消息。

状态机图：状态机图描述了对象所处的各种状态，以及那些状态之间的变迁。

时间图：时间图探究了具体的时期中一个或多个对象的行为。

用例图：使用用例图来可视化（或例举）用例和角色之间的关系，以及用例和其他用例之间的关系。

Diagram Editor

您可以由 Diagram Navigator 或 Model Explorer 视图在 Diagram Editor 中打开 UML 图（图 4）。您可以同时选择打开多个图，然后使用选项卡在打开的图之间切换。

UML 图包含许多图元素。图元素，也称为图形，是表示 UML 元素（例如类、接口，和关系），或者没有 UML 语义的几何形状（例如椭圆形、菱形和矩形）的图形或文本元素。在 Diagram Editor 中，您可以从 Model Explorer 中将现有的模型元素拖拽到图中，或者您可以使用选项板来创建新的图元素。（如果图元素表示 UML 元素，那么其相应的 UML 元素将被添加到模型中。）

图 4. Diagram Editor 视图

属性（Properties）

如果您选择 UML 图中的图元素，您可以在 Properties 视图中看到并设置该图元素的属性（图 5）。属性是控制 UML 图中图形和连接件的特征的值。例如，每个图形和连接件都有一个线条颜色属性，您可以通过它指定图形的边或者连接件的线的颜色。您还可以指定属性值，从而改变连接件的线条样式，以及显示或隐藏间隔或间隔标题。

如果您在 Model Explorer 中选择模型元素，那么您可以看到并设置模型元素的属性，例如名称和可视性、模型的概要文件，和类的属性及方法。

图 5. Properties 视图

模型模板

Rational Software Architect 包含用例、分析和设计模型的模板。每一个都针对不同的开发阶段：需求、分析和设计。

Rational Software Architect 不为表示实现的物理组成的实现模型提供模板，包括实现子系统和实现元素（源代码、数据和可执行文件）。不包含实现模板的原因是 Rational Software Architect 的操作理论是：通过设计使用平台无关的模型，然后通过各种不同的转换，让 Rational Software Architect 把这些设计转换为代码或实现级工件。

用例模型

用例模型提供有关您正在开发的系统或应用程序的行为的详细信息。它根据为实现目标或解决用户所确定的问题而必须存在的功能，确定出系统的需求（用例），并且指定周围环境（角色）和用例与角色之间的关系（用例图）。用例模型还包括描述用户与系统如何交互的用例图和活动图。

分析模型

分析模型描述了您正在建模的系统或应用程序的结构。它包括了描述用例模型中所确定的功能需求的逻辑实现的类和序列图。

分析模型确定出系统中的主要类，并且包含一组描述系统如何构建的用例实现。类图通过利用原型对系统的功能部分建模对系统的静态结构进行描述。序列图通过描述用例中事件执行时的流对用例进行实现。这些用例实现对系统的一些部分如何在具体用例环境中交互进行建模。

分析模型描述了系统的逻辑结构，因而它是设计模型的基础。

设计模型

设计模型是基于分析模型的，它向系统的实际实现中添加了详细信息。设计模型通过使用各种图（包括序列图、状态机图、组件图和部署图），详细地描述了应用程序是如何构成，以及如何实现的。它还描述了程序设计构想及技术，例如那些用于持久性、分布、安全，及记录的内容。

设计模式通常对设计模型进行提炼，从而获取经常使用的，或复杂的结构和过程。

模式框架

如前面设计模型部分中所提到的，您可以利用设计模式对设计模型进行提炼（修改或添加 UML 元素），从而将解决方案应用到已知问题上。您可以利用 Rational Software Architect 的模式框架来完成许多重要的任务：

撰写模式

以插件的形式将模式作为可复用资产进行打包

在模式库中找到并导航到模式

将模式应用于 UML 元素

撰写模式

您可以通过扩展两个插件来撰写设计模式：抽象出模式服务用途的模式服务和模式框架。模式服务和模式框架提供构建、设计、编码、搜索、组织，及应用模式的基本功能。

“Content authoring demystified”这篇文章（参见参考资源）详细地介绍了如何撰写新的模式。

打包并发布模式用于重用

您可以导出一个符合可复用资产规范（Reusable Asset Specification，RAS）的作为可部署，可复用资产的模式插件，以便将来可以再次使用。可复用资产可以作为文件进行交换，或者发布到资产存储库中，让其他人来搜索，然后方便地将模式导入到他们的 Rational Software Architect 工作台中。

“Content authoring demystified”这篇文章（参见参考资源）也介绍了如何将模式打包为 RAS 资产文件，并且导出到文件系统中。或者，您可能想要将资产直接导出到存储库中，如图 6所示。

图 6. 将模式导出到资产存储库中

发现模式

在 Rational Software Architect 可以通过很多方法找到模式，例如使用 Pattern Explorer 和 Asset Explorer。

Pattern Explorer：在建模透视图中，单击通常位于屏幕最右边的图标。模式导航器出现，它显示出 Rational Software Architect 所安装的模式，其中装载着四人帮（Gang of Four，GoF）设计模式。如果您已经导入了其他模式，那么这些模式也会列出来。在 Pattern Explorer（图 7）中，您可以搜索、组织，或将模式拖拽到 UML 图中。

图 7. Pattern Explorer 视图

Asset Explorer：所有的模式都默认地存储在模式类型的本地 RAS 存储库中，您可以将其组织成逻辑分组，或者子目录。在 RAS 透视图的 Asset Explorer 视图中，您可以在 Patterns Repository 目录下找到 Rational Software Architect 所安装的模式。

如果您已经创建了到任意资产存储库的连接，那么不论是本地或是远程，如果有其他人发布了资产存储库，您都可以从所连接的资产存储库中找到模式，如 图 8所示。您可以从资产存储库中将模式导入到 Rational Software Architect 工作区中，以便您可以在 Pattern Explorer 中使用它们。

图 8. Asset Explorer 视图

应用模式

应用模式是非常直截了当的。您可以从 Pattern Explorer 中将模式实例拖拽到 UML 图中，然后将 UML 元素作为参数绑定到模式实例上（选择现有的或创建新的）。当您将参数绑定到模式实例上之后，模式实例将通过修改现有模型元素或新增模型元素来精练模型。

在本文后面的部分中，您将找到有关应用模式的更多信息，以及一个实例。

转换

如早先提到的，您可以将设计模型转换为 Rational Software Architect 中的实现级工件，例如可执行的代码、XSD、WSDL、文档，和配置脚本。

Rational Software Architect 装载了五个转换，如图 9所示。您可以将这些转换应用于 UML 元素的不同级别，例如模型、包、类，和接口。例如：

UML to C++

UML to Java

UML to EJB

UML to CORBA

UML to XSD

这些转换提供了由 UML 模型生成相应的 Eclipse 项目和相关工件的基本功能。例如，UML 到 Enterprise Java? beans（EJB）的转换将创建 EJB 项目，而 UML 到 Java 的转换将创建 Java 项目。您可以扩展这些转换，添加行为，或者您可以通过扩展 Rational Software Architect 转换框架，撰写您自己的转换。“Content authoring demystified”这篇文章（参见参考资源）介绍了如何扩展 UML 到 Java 的转换的实例，以及如何创建自己的 Rational Software Architect 转换的实例。

图 9. Rational 软件中包含的转换

基于资产的开发框架

模型、模式，和转换是可复用的资产。开发它们之后，其他人可以进行组织、存储并使用，从而加速 MDD，并确保更好的投资回报率。因此，基于资产的开发对 MDD 是重要的补充。

Rational Software Architect 利用可复用的资产规范（Reusable Asset Specification，RAS）来提供标准的方法打包并消耗（使用）向已知环境提供问题解决方案的资产。RAS 资产是相关工件和描述资产的清单的集合，如图 10所示。Artifacts（工件） 是软件开发生命周期中的任意工作产品，例如需求文档、模型、源代码文件、部署描述符、测试用例，及脚本。一般来说，术语 工件 与文件相关联。

图 10. 什么构成了资产

打包资产用于重用

利用 Rational Software Architect 建模工具的 RAS 导出功能来打包资产，可以确保自动地获取所有参考过的文件，以及您想要分享的相关模型和项目、文档、源代码，和其他开发工件。（要了解更多信息，阅读参考资源中的“Content authoring demystified”文章。）在将资产打包之后，您可以选择在本地文件系统中保存，或者导出到资产存储库中。

导入现有资产

Rational Software Architect 中的 RAS 导入功能解包并还原 RAS 资产中的文件到本地文件或文件夹，或者到 Eclipse 工作区中。导入带有可部署插件的资产，例如模式和转换，将导致在 Rational Software Architect 中安装插件。您可以从本地文件系统或资产存储库中导入资产。

资产存储库

RAS 资产可以存储在基于 RAS 的资产存储库中。利用 Rational Software Architect，当您在打包资产时，可以选择将其导出到所连接的资产存储库中。您还可以在 RAS 透视图的 Asset Explorer 视图中将资产以 .ras 的文件格式从文件系统中发表到所连接的存储库中。

此外，您可以在 Asset Explorer 中观看、搜索，并从资产存储库中导入资产，如图 8所示。Rational Software Architect 支持以下四类基于 RAS 的资产存储库。您可以在 Asset Explorer 视图中创建到达这些存储库的连接。

本地存储库：本地文件系统存储库为个人使用。除非您使用网络文件系统来存储本地存储库，不然您不能在团队之间共享该存储库。

工作组存储库：基于 Web 服务的存储库为团队所使用。这是您可以安装到 J2EE 应用程序服务器上的 Java? 2 Platform，Enterprise Edition（J2EE?）应用程序。它可以用于在安装了 Rational Software Architect 的团队之间进行资产的分享。您可以从? alphaWorks?（参见参考资源）上下载工作组存储库。

XDE 存储库：该选项提供对遗留 Rational XDE 存储库的反向支持。

developerWorks 存储库：存储在 IBM? developerWorks?中。您可以搜索并导入 IBM 提供的新设计模式。模式的数量在稳固的增长着，因此不要忘记常去看看。

将所有内容放在一起：简单的场景

现在是时候了解如何将所有的 MDD 工具支持放在一起的时候了。该场景将带着您经过以下这些步骤：

在资产存储库中存储设计模式资产

导航到存储库并导入设计模式

创建 UML 模型

向 UML 模型中应用 Interface Inheritance 设计模式

将模型转换为 Java 代码

步骤 1. 在资产存储库中存储设计模式资产

从本文的下载部分下载 Interface Inheritance 设计模式。当该模式应用到一个类时，设计模式将把该类的公共方法抽取出来，放入一个接口中，并且创建类和接口之间的集成关系。

创建到存储库的连接。

在 Rational Software Architect 中，启动 RAS（可复用资产）透视图。

在 Asset Explorer 视图中，创建到存储库的连接，单击 存储库图标图标。

如果您已经安装了 Workgroup Repository，那么选择 Workgroup Repository 并输入存储库实例的 URL，或者，选择 Local Repository，并输入您要存储资产的位置。

将模式资产导入存储库。

在 Asset Explorer 视图中，单击右键打开环境菜单，并选择 Publish Asset...。

定位到您所下载的资产文件，并在发布的列表中选择repository（参见图 11。）

在资产发布之后，Interface Inheritance 模式将出现在连接的存储库之下的资产列表中。

图 11. 将模式资产导入存储库

步骤 2. 导航到存储库并导入设计模式

导航到资产并搜索。在 Asset Explorer 中，您可以从不同的存储库中导航这些资产，并且使用存储库图标图标打开搜索对话框来搜索资产。

导入设计模式。

右键单击 Interface Inheritance 资产，并在环境菜单中选择 Import...。Import RAS Asset 向导将启动。消息窗口告诉您，该资产包含可部署的插件，以及导入它将安装插件。单击 OK 确认该信息。

完成导入向导的过程。

模式插件应该被 Rational Software Architect 动态地加载。切换到 Modeling 透视图，单击存储库图标 图标，打开 Pattern Explorer。您会看到 Miscellaneous Patterns 类别下的 Interface Inheritance 模式。注意：如果您没有看到，那么插件没有被动态地加载上，因此，您需要使用 -clean 参数重新启动 Rational Software Architect，这样将使它加载新的插件。

步骤 3. 创建 UML 模型

创建名为Lab2 的新 UML Project。

创建名为 Lab2Model 的新 Modeling Project，如图 12中所示。将自动打开一个模型的默认图。

图 12. 创建新的 UML 模型

在图中，创建名为 com.ibm.xtools.patterns.samples.impl 的包。

创建名为 Lab2Class 的新类，包含以下共有方法：

op1(arg1:String):String

op2(arg1:Integer):Integer

如果您想看到完整的标记，在类上单击右键，并在环境菜单中选择图 13中展示的选项。

图 13. Show Signature 选项

步骤 4. 向 UML 模型中应用 Interface Inheritance 设计模式

如果您在 Model Explorer 中创建，将 Lab2Class 拖拽到 com.ibm.xtools.patterns.sample.impl 中。注意：如果您在图中创建了类，忽略此步骤。

在 Pattern Explorer 中，从 Miscellaneous Patterns 类别中找到 Interface Inheritance模式，将其拖拽到图中，如图 14中所示。

图 14. 找到 Interface Inheritance 模式

将鼠标指针放在 Pattern Instance 的 Abstract Interface参数上（图 15）。您会发现该参数上的菜单栏中有两个图标：

第一个将创建一个与参数名相同的假名的 Interface。

选择 第二个图标，并输入接口名称：Model2Interface

图 15. 应用模式

创建名为 com.ibm.xtools.patterns.interfaces 的包。

在 Model Explorer 中将 Model2Interface拖拽到com.ibm.xtools.patterns.interfaces 中

将 Lab2Class 拖拽到模式实例的Implementation Class 参数中。这将把 Lab2Class 绑定到 Implementation Class 参数上。

从 Model Explorer 中将 Model2Interface 拖拽到图中，以研究关系。您会找到：

Model2Interface 与 Lab2Class 有同样的公共方法

Lab2Class 已经实现了 Model2Interface。注意：如果您没有看到关系，那么单击图的空白部分，选择 Filters > show/hide relationships...，并单击 OK。这将刷新图中的关系，如图 16 所示。

图 16. 应用模式的完整过程

步骤 5. 将模型转换为 Java 代码

在 Model Explorer 中右键单击 Lab2Model 。注意：务必选择带有存储库图标图标的模型，不是.emx文件。

在环境菜单中选择Transform > Run Transformation > UML to Java。

创建名为 Lab2Code 的新目标项目。

选择 Run，执行转换。

观察 Lab2Code 项目中生成的代码，这是 Interface Inheritance 模式的。

将您投资的价值最大化

您可以看到 Rational Software Architect 的完整工具支持为您的模型驱动开发和模式带来的优势。当您将它和补充 MDD 的 Rational Software Architect 的基于资产的开发框架组合起来时，您就可以通过复用模型、模式，及转换，将时间和金钱的投资回报率最大化，统一开发过程，加速开发循环，并且标准化共享的资产。