本文来自于 Rational Edge: 在这个由三部分文章组成的系列的第一篇中，Brown 解释了模型和建模的重要性，并介绍了四个关键的 MDA 的原则，同时让你了解一下 IBM 在定义 MDA 方法和支持标准上扮演的领导者的角色。

　在最近的几个月很多组织已经开始对模型驱动的体系架构（MDA） 1 进行关注，MDA 是一种应用系统设计和实现的方法。对于几个原因来说这都是非常积极的发展。 MDA 鼓励在软件的开发过程中有效的使用系统的模型，并且它支持创建类似系统的最佳实践的重用。所谓由对象管理组织 （OMG）定义的标准，MDA 是一种组织和管理被自动化工具支持的企业体系架构和用于定义模型和推动不同模型类型之间的转换的服务的方法。

当被 OMG 定义的 MDA 标准和用于创建和进化企业级软件系统的术语在业界被广泛的引用时，仅仅到目前为止， OMG 和它的成员，包括 IBM Rational ，已经能够在 MDA 意味着什么、MDA 将向哪里发展、MDA 的哪些方面对于今天的技术是可能的和如何在实践中利用 MDA 上提供清晰的指导。

本文是这个由三篇文章组成的系列的第一部分，这个系列将覆盖：在现今的工业中建模将如何被使用和 MDA 与当今软件系统的关系（第一部分）；MDA 工具支持的分类（第二部分）；和在 IBM 的模型驱动的开发技术环境中 MDA 的使用样例（第三部分）。

在这个第一部分的文章中，我们解释了模型和建模的重要性，并介绍了四个关键的 MDA 的原则，同时让你了解一下 IBM 在定义 MDA 方法和支持标准上扮演的领导者的角色 2 。

有效的企业软件开发

今天开发企业级的应用要求一种软件架构的方法，这种方法应该能够以一种灵活的方式帮助架构师来发展他们的架构。这种方法应该允许在及时的实现业务功能的新的能力的情况下重用已有的劳动成果，甚至是当目标基础架构本身在一直的演进。两个重要的思想现在被认为是应对这种挑战的中心：

• 面向服务的体系架构(SOA)。企业解决方案能够被视作通过良好的说明定义了他们的服务接口契约连接的服务联合。结果的系统设计通常被称作面向服务的体系架构（SOAs）。 3 通过将一个系统组织成为被封装好的服务集合，这些服务可以通过他们定义的服务接口被操作，系统的灵活性被大大的增强了。现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。
• 软件的产品线。通常，在一个组织开发和维护的系统中，存在着大量的可公用的部分。从捕获核心业务过程和领域概念的标准领域模型，到开发人员在代码中使用的实现设计的实现细节方案，我们在企业的软件项目的每一个级别上看到了重用的方法。当模式能够被经验丰富的从业者开发出来并在跨越组织的范围内传播时，软件开发组织将获得大量的效率。这表现了一种朝着促进计划的资产重用，增加自动化的级别来实现被开发系统大部分的方案的软件产品线开发视图的迁移。 4 更加普遍的情况下，我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。

这两种思想对对象管理组织（OMG）的思想有着重大意义的影响，一个开发和支持规范以改进企业软件开发和部署实践的软件组织联盟（在下一个部分 OMG 将扮演更重要的角色）。OMG 已经创建了一个概念性的框架 5 ，这个概念性的框架将平台选择与独立的面向业务的决定分离开来以使在架构和演进这些系统时允许更大的灵活性。这个概念性框架和帮助实现它的标准就是 OMG 称为的"模型驱动的体系架构（MDA）."。 6 应用的架构师使用 MDA 框架作为表示他们企业架构的蓝图，并且使用在 MDA 中的开发标准作为他们独立于供应商和技术的"未来的证明 "。

OMG 的 MDA 的概念通过 OMG 的构建模型的标准对系统的交互性提供了一种开放的、供应商中立的方法：统一建模语言（UML），Meta-Object Facility (MOF)， XML Metadata Interchange (XMI) 和 Common Warehouse Meta-model (CWM) 。企业应用的描述能够使用这些建模标准被建立并被转化到一种主流的开发的或者是私有的平台上，包括 CORBA ，J2EE ，.NET 和基于 Web 的平台。

在我们开始深入的了解 MDA 之前，让我们考虑一下在软件开发中进行建模的基本概念和好处。

建模的基本原理

模型提供了一个物理系统的抽象，模型可以让工程师们通过忽略无关的细节而把注意力放到系统的重要部分来思考系统。工程中的所有工作形式都依赖模型来理解复杂的、真实世界的系统。模型被用在很多的方面：预期系统的质量，当系统的某些方面变化时推理特定的属性，和为各种涉众沟通关键的系统特征。模型也可以作为实现物理系统的先驱被开发，或者模型可以根据一个已存在的系统或者开发中的系统被产生作为理解系统行为的帮助手段。

系统和模型转换

因为一个系统的很多方面也许都是让人感兴趣的，你可以及时的根据系统相关的部分在任何点上使用各种不同的建模概念和符号来突出一个或者多个特定透视图或者视图。此外，在一些情况下，你可以使用提示或者规则来添加一些模型，这可以帮助你将模型从一种表示法转换成为另一种表示法。通常在相同的抽象级别上转换到系统的不同视图是必要的（例如，从架构视图到行为视图的转换），并且模型的转换将使它更加容易。在其他的情况下，模型之间的转换是在一个特定的方面上进行的，这种转换是从一个抽象级别到另一个抽象级别，这往往是通过按照转换的规则添加更多的细节从更加高的抽象视图到低的抽象视图进行的。

模型、建模和 MDA

模型和模型驱动的软件开发是 MDA 方法的核心。因此，为了更好的理解 MDA ，我们应该首先来了解一下企业应用开发人员是如何利用建模的。

追溯到程序设计的最早的日子，在软件工程的世界里，建模有着悠久的传统。多数近期的革新都是关注于符号和工具的，这些工具允许用户非常容易的映射到在特定的操作系统上能够被编译的编程语言代码的方式来表示对软件的架构师和开发人员有价值的系统透视图。这些实践的当前情况是使用统一建模语言（UML）作为首选的建模符号。UML 允许开发团队在相应的模型中获取一个系统的各方面的重要特征。这些模型之间的转换主要是手工进行的。UML 建模工具典型的支持需求的跟踪和模型元素之间的依赖关系，通过支持文档和补充的咨询信息提供如何作为大范围开发工作的一部分来维护同步模型的最佳实践的指导。

一个有用的刻画当前实践特色的方法是看一下用于同步模型和源代码的不同的方法。这在图 1 中被列举 7 图 1 显示了今天软件从业者使用的建模方法的光谱。每一个类型代表了一种独特的帮助软件从业者创建能够运行在特定运行时平台上的应用（代码）和模型与代码之间的关系的模型的使用。

　图 1: 建模的光谱

今天，多数的软件开发人员仍然在使用 单独－代码的方法（在建模光谱的左端，图 1）并且根本没有分离的定义模型。他们几乎完全的依靠他们编写的代码，并且他们直接在一种集成的开发环境（IDE）中（比如，IBM WebSphere Studio ， Eclipse 或者 Microsoft VisualStudio 9 ）通过第三代的编程语言如 Java 、C++ 或者 C# 直接的表示他们正在建立的系统的模型。他们所做的任何"建模"都是以嵌入在代码中的编程的抽象形式进行的（比如，包、模块和接口等等），这些方式是通过程序库和对象层次的机制进行管理的。任何分离的体系架构的设计模型都是不正规的和依靠直觉的，并且存在于白板上、PowerPoint 幻灯片上或者开发人员的脑袋中。然而这种方法对于个体开发者和小的开发团队也许是足够的，但是这种方法使在业务逻辑实现的细节中理解系统的关键特性十分的困难。此外，随着系统的范围和复杂度的增加，系统的演进或者在原来的设计团队成员不能直接的与维护系统的团队沟通时，这种方法对于管理这些方案的演进将是更加困难的。

一个改进是在一些适当的建模符号中提供了 代码可视化。当开发人员创建或者分析一个应用时，他们通常希望通过一些辅助理解代码的结构或者行为的图形化符号来可视化代码。作为一种编辑基于文本代码的可选方式利用图形化的符号也是可能的， 所以可视化的描写变成了一种代码的直接表示。这种描写有时称作代码模型，或者实现模型。在允许这种画图的工具中（比如，IBM WebSphere Studio 和 Borland Together/J），代码的视图和模型的视图可以被同时显示；当开发人员对其中的一个进行操作时，另一个视图也将立即进行同步。在这种方法中，图与代码表示紧紧的联系在一起，并提供了在代码级别上观看和编辑的可选方法。

建模的更深层次的利益是通过 双向工程（RTE）得到的，双向工程提供了一种在描述系统的架构或者设计和代码的模型之间进行双向交换的机制。典型的情况下，开发人员将系统设计细化到一定的详细级别，然后通过应用模型－代码的转换创建第一轮的实现，这通常是手工完成的。例如，一个工作在高级别设计的团队也许会向工作在实现级别上的团队提供设计模型（也许是通过简单的打印出模型图或者为实现团队提供包含模型的文件）。实现团队转换这个抽象、高级别的设计成为详细的设计模型的集合和编程语言的实现。其中表示上的重复将作为错误出现，这些错误既可以在设计模型中更正也可以在实现模型中更正。因此，如果没有良好的纪律，抽象模型和实现模型常常 — 并很快 — 的因为步调不一致而结束。

工具能够自动化的进行最初的转换，也可以在设计模型和实现模型进行演进时帮助他们保持步调一致。典型的，工具可以从用户必须进一步细化的设计模型生成代码的框架。 10 对代码的更改必须要在一些点上与原有的模型相一致（也就是术语"双向工程"或者 RTE）。为了实现这一点，你需要一种方法来识别出被产生的用户定义的代码；在代码中放置标记就是一种方法。实现这个方法的工具，比如 IBM Rational Rose 能够支持在模型与不同实现语言之间双向提供多种转换服务。

在一种 以模型为中心的方法中，系统模型具有足够的细节能够从这些模型中生成整个系统的实现。为了实现这一点，模型也许应该包括，比如持久数据和非持久数据、业务逻辑和表示层元素的表示法。如果存在任何与遗留数据和服务的集成，对那些元素的接口也需要被建模。然后代码生成过程应用一系列的模式将模型转换成代码，通常允许开发人员对被应用的模式进行一些选择（比如，选择各种不同的部署拓扑）。这种方法常常使用标准的或者私有的应用框架和运行时服务，这些应用框架和运行时服务能够通过限制被生成应用的类型使代码生成任务更加容易。因此，使用这种方法的工具典型的专攻于特定应用类型的生成（例如，用于实时嵌入式系统的 IBM Rational Rose Technical Developer 和用于企业 IT 系统的 IBM Rational Rapid developer）。然而，在所有的情况下，模型都是被开发人员创建和操作的主要产物。

一个 单独模型的方法在图 1 中的编码/建模光谱的最右端。在这种方法中开发人员把模型纯粹的作为理解业务或者方案领域，或者分析被提议的方案架构的辅助手段。模型通常被作为讨论、交流和在一个单独的组织或者是跨多个组织的项目中进行分析的基础来使用。这些模型常常出现在新工作的建议中，或者装饰在办公室的墙上和在软件实验室中作为一种促进对一些复杂领域理解的方法并建立一个共享的在完全不同的团队中的词汇表和概念集。实际上，一个系统的实现，不论是从打草稿开始还是作为一个已有方案的更新，都可以从模型中分离出来。一个有趣的例子是越来越多的组织将他们的系统的实现和维护进行外包，而他们自己维护整个的企业架构的控制。

MDA：成长中的公认舆论

建模已经在软件工程中起到了较大的影响，并且它对于每一个企业级方案的成功都是至关重要的。然而，在模型的表示和如何使用上有着很大的多样性。一个有意思的问题是：这些方法中的哪一种我们能够描述为"模型驱动呢"？如果我创建一个系统的某些部分的可视化表示，这能意味着我正在实践 MDA 吗？不幸的是，没有一个确定的答案。然而，存在着一种正在成长的舆论认为 MDA 是最贴近于从更加抽象的模型自动的产生代码，并且使用标准的说明语言来描述那些模型的方法。我们在接下来的部分探究这个概念。

MDA 的理论

对于 MDA 是什么和不是什么有着很多中观点和意见，最权威的观点是被对象管理组织（OMG）提供的，一个拥有超过 800 家公司、组织和个人的软件行业联盟。为什么 OMG 关于 MDA 的观点是如此的重要呢？作为一个新兴的体系架构的标准，MDA 属于 OMG 支持的悠久传统和过去二十年中的众多计算机标准。 OMG 一直负责一些对于系统的说明和互操作性方面的工业上知名的和最具影响力的规范的开发，包括公共对象请求代理体系架构（CORBA），OMG 接口定义语言（IDL），Internet Inter-ORB Protocol (IIOP)，统一建模语言（UML），Meta Object Facility (MOF)， XML Metadata Interchange (XMI)， Common Warehouse Model (CWM) 和 Object Management Architecture (OMA)。此外，OMG 也增强了这些规范来支持特定行业，比如卫生保健业、制造业、电信业和其他的行业。

OMG 已经重新关注它的策略、标准和定位来支持 MDA 方法。OMG 正在将 MDA 作为一种开发更加准确的满足客户需要并且在系统的演进中具有更好灵活性的系统方法来促进它的发展。MDA 方法构建在较早期的系统规范标准的工作上，并且为定义相互连接的系统提供一种全面的具有互操作能力的框架。

MDA 原则

OMG 组织对于 MDA 的观点下有四个原则：

• 以一中定义良好的符号表示的模型是理解企业级方案系统的基础。
• 系统的构建能够围绕着一系列模型通过使用在模型之间的一系列转换被组织的，并且能被组织到一个分层的和转换的体系架构框架中。
• 以一系列元模型来描述模型的一种正式的支持能够使在模型中有意义的集成和转换变得容易，并且是通过工具实现自动化的基础。
• 接受和广泛采纳基于模型的方法需要工业的标准提供开放性给客户，并鼓励供应商之间的竞争。

为了支持这些原则，OMG 已经定义了一系列的层次和转换，他们为 MDA 提供了概念性的框架和词汇表。特别的，OMG 确定了四种模型类型：计算无关的模型（CIM），平台无关的模型（PIM），被一个平台模型（PM）描述的平台相关的模型（PSM）和一个实现相关的模型（ISM）。

对于 MDA 来说，“平台”仅仅是相对特定的视图观点有意义的 --换句话说，一个人的 PIM 可以是另一人的 PSM 。例如，如果一个模型没有 规定一种特定的中间件技术的选择，那这个模型对于通讯中间件来说就是一个 PIM 。然而，当一个使用特定的中间件（比如CORBA）被决定使用时，这个模型就被转化成了一个 CORBA 相关的 PSM 。新的模型在 ORB 的选择上也许仍然是一个 PIM -- 在目标操作系统和硬件的方面这个模型也是一个 PIM 。如图 2 所示。

　图 2: PIM 到 PSM 转化的例子

作为结果，一个 MDA 工具也许通过几个步骤支持转化一个模型，从最初的分析模型到可执行的代码。例如，IBM Rational XDE 的模式工具就支持这种多种转换的开发。相比之下，一个工具（比如，IBM Rational Rose Technical Developer）能够仅用一个步骤就将模型从 UML 转化成可执行的代码。

MDA 的从业者认可转换能够被应用到一个系统的各个方面的抽象描述以添加细节，使描述更加准确，或者在表示法之间进行转换。不同类型模型之间的区别允许我们将软件和系统开发想象成为一系列在不同模型表示法之间的细化。对于包括了在表示系统不同方面的模型之间的细化，对一个模型的细节的添加，或者在不同的模型类型之间的转换的情况下，这些模型和他们的细化是开发方法的重要组成部分。

这里是关于模型的抽象本质和模型所表达的详细实现的三种重要思想：

• 模型分类。我们能够通过如何表示目标平台的各个方面的术语对软件和系统模型进行分类。在所有的软件和系统开发中都存在着通过语言、硬件、网络拓扑、通讯协议和底层架构等选择所带来的重要约束。这些约束的每一个能够被作为一个方案"平台."的元素被考虑。MDA 的方法帮助我们关注在被设计方法的业务方面的本质上，而不是在 "平台."相关的细节上。
• 平台无关。"平台"的概念是相当复杂和高度依赖环境的。例如，在一些情况下，平台也许是操作系统和相关的工具；在一些情况下，它也许是被良好定义的编程模型所代表的技术架构，比如 J2EE 或者 .Net ；在其他的情况下，它也许是一个特定的硬件拓扑的实例。在任何情况下，考虑根据不同抽象级别的模型被用于不同的目的，而不是将注意力分散到定义"平台."上是更加重要的。
• 模型的转换和细化。通过将软件和系统开发想象成为一系列的模型细化，模型之间的转换变成了开发过程中的第一类元素。这是重要的，因为大量的工作任务发生在定义这些转换上，这通常需要特殊的业务领域的知识和用来实现的技术等等。我们能够通过明确的获取这些转换和跨方案的重用它们来改进系统的效率和质量。如果不同的抽象模型被良好的定义，我们能够使用标准的转换。例如，在以 UML 表示的设计模型和以 J2EE 表示的实现模型之间，我们能够使用良好理解的能够被应用、验证和自动化的 UML 到 J2EE 的转换模式。

在这些模型表示法和支持的转换之下是一系列的元模型。分析、自动化和转换模型的能力需要一个清晰、明确的方法来描述模型的语义。因此，对于一个建模方法模型的本质本身也必须能够以模型来表示，我们称这种模型为元模型。例如，UML 的标准语义和符号就是用元模型描述的，工具的提供商以一种标准的方法使用元模型来实现 UML 。UML 元模型精确的描述了类、属性和这两个概念之间的关系的细节。

OMG 认可对于建模来说元模型和正规语义的重要性，，并且还定义了一系列元建模级别和用于表示元模型的标准语言：Meta Object Facility （MOF）。元模型使用 MOF 正式的定义一系列建模构想的抽象语法。

模型和模型之间的转换将使用开放的标准被说明。作为工业的联盟，OMG 一直拥护多种用于说明系统和系统间的互连性的重要工业标准。通过这些标准，例如 CORBA、 IIOP、 UML 和 CWM ，软件行业能够实现以前不可能的系统互操作能力的级别，此外，工具交换标准，例如 MOF 和 XMI ，也促进了工具的互操作。

一个简单的例子

图 3 显示了一个平台无关模型（PIM）和它的三种转换到平台相关模型（PSM）的简单的例子。

　图 3:PIM 到 PSM 转换的简单例子

在图 3 中的简单的 PIM 表示了一个客户和帐号。在这个抽象级别上，模型通过类和类的属性描述了领域的重要特征，但是并没有描述任何关于什么样的技术将被使用的平台相关的选择。图 3 指出了三个特定的被定义的映射，或者转换，和一些用来表示这些映射的标准来创建 PSM 。例如，一个方法是使用被 XML Schema Definitions (XSD) 或者 Document Type Definitions (DTD)表示的标准定义将以 UML 表示的 PSM 输出成为 XMI 格式。然后这能被用作代码生成工具的输入，这个代码生成工具为每一个以 UML 定义的类生成 Java 语言的接口定义。

通常，一系列的规则被建立在代码生成工具中以执行转换。然而，代码生成工具往往允许那些规则通过脚本语言的形式被明确的定义。

简单的介绍 MDA 的理论

随着使用模型来表示问题和方案领域关键思想的悠久历史，MDA 为使用模型和应用模型之间的转换作为被控制的、高效的软件开发过程的一部分提供了概念性的框架。这里是今天控制 MDA 用法的基本设想和因素：

• 模型帮助人们理解和交流复杂的思想。
• 根据环境上下文，许多不同种类的元素能够被模型化。这些模型提供了符合世界的不同视图。
• 我们在这些模型的所有级别上看到了公用性 -- 不论是在被分析的问题上还是在被建议的方案上。
• 应用不同类型模型的思想和模型表示法之间转换提供了一种定义良好的开发和识别和重用公用方法的方式。
• 在"模型驱动的体系架构"方面，OMG 提供了一个概念性的框架和一系列表示模型、模型关系和模型到模型转换的标准。
• 工具和技术能够帮助实现这个方法，并使这个方法更具实践性和高效的被应用。

IBM 和 MDA

IBM 在对建模、模型驱动开发的支持上有着悠久的传统，并且 MDA 显然跨越了 IBM 的很多技术和服务领域（例如，业务建模、数据建模和部署建模等等）。这里我们将关注于 IBM Rational 的解决方案，在 IBM Rational 的解决方案中建模主要被用于驱动企业级应用、软件密集系统的设计和实现。

在过去的十多年中， IBM Rational 工具一直强调建模作为一种提升系统抽象级别的方法的重要性，软件的从业者在这个抽象的级别上理解和构建软件解决方案。在过去的几年中，软件开发行业不断的意识到更高级别抽象的价值 — 从在机器语言级别上的代码描述到 MDA 的出现 — 见图 4 。

　图 4: 对于软件从业者渐增的抽象级别

我们已经看到了一系列的软件从业者理解的软件密集的解决方案的基本转变。这些转变改变了绝大多数软件工程师们的思想。从前，他们只是关心他们自己的低级别的操作数据位和在 CPU 的寄存器之间移动字节的细节；现在，他们将主要的时间花费在根据被支持的用例来理解用户的问题领域和设计提供行为的服务之间的协作的方案来实现那些用例上。只有存在着支持高效的允许新概念被清晰的表达和共享的工具，这个在思想上意义深远的转变才有可能。

这个转变的基础当然是 UML 。它提供了一个公共概念的单一集合，这些公共概念被广泛的应用到软件工业中，很快的结束了当设计软件系统时应该使用哪一种概念集合的长期争论。IBM Rational 在定义 UML 中的领导角色被广泛的认可，IBM Rational Rose 产品在实现 UML 来支持大型软件系统的架构方面也是同样出众的。相同的原则已经被应用到了 IBM Rational Rose XDE 产品家族当中，它合并了丰富的建模环境和面向代码的工具集以为在各种架构类型和特定的目标运行时平台中创建方案提供全面的从业者桌面。

通过 IBM 的支持 OMG 定义的 MDA 可视化建模和开发工具，和随着时间的推移对 MDA 的支持， IBM 将继续这种在建模支持上的传统。

IBM 对 MDA 的观点

IBM 坚定的相信通过创建问题领域和方案领域的模型和在整个软件项目的生命周期中调整这些模型，软件组织将会很好的被服务。因为 IBM 一直是模型驱动的软件开发方法的强烈建议者，并且模型驱动的开发形成了来自于 IBM 的最佳实践和工具的关键组件，今天遍及世界的 IBM 的客户使用了这些技术来实现良好的结果。

IBM 将 MDA 视为一种新兴的关注于一种软件开发的特殊方式的标准和技术的集合 -- 它指明了某种模型类型被使用，这些模型如何被准备和不同模型类型之间的关系。 MDA 和 实现 MDA 的工具提供下面的方法：

• 说明与支持平台无关的系统、
• 说明平台。
• 选择系统开发的特定平台。
• 将系统说明转换成特定平台相关的模型。

总而言之，IBM 相信两种软件开发工具将为 MDA 提供强有力的支持：

• 在模型定义和转换上提供了高度自动化的工具，典型的是针对特定的应用领域的，适合这个领域的复杂的转换规则能够被预先定义。
• 被设计用于更加通用的目的，但是能够通过最终用户和第三方工具供应商的扩展和定制被配置以支持 MDA 的工具，典型的是针对更大范围的应用领域的。

IBM Rational 提供了这两类产品。 13 在第一类产品中，IBM Rational Rose Technical Developer 提供了高度自动化的模型转换和强大的代码生成能力 — 这种能力对于嵌入式系统和其他技术软件产品的开发人员尤其重要。类似的，IBM Rational Rapid Developer 提供了高度自动化的面向 J2EE 应用的 MDA 的实现，它能够集成和扩展已有的遗留系统。在第二个种类中，IBM Rational Rose XDE Developer 提供了模式能力、代码模板和应用接口的合并，这允许开发人员和供应商为更加普遍的领域适用性自己开发他们的 MDA 实现。

IBM 在 MDA 上的领导地位

IBM 对 MDA 支持的其他重要方面能够在很多关键的 MDA 标准中 IBM 扮演的领导地位看到。IBM 一贯的为 OMG 在以下方面提供强有力的支持：

详细的标准大量的来自于 IBM 的技术。一个重要的例子，当然是 UML ，它是基于 IBM Rational — 以前的 Rational 软件 ，2003 年被 IBM 收购—的基础上。另外，IBM Rational 在其他的标准上也有着重要的影响，比如，Meta Object Facility (MOF)，QVT 标准和新兴的可重用资产规范（RAS）的工作上。

　来自于 IBM Rational 的对驱动 MDA 标准的个人承诺。IBM Rational 的职员在 OMG 的机构委员会中、标准任务和开发方案的团队中占据着关键的位置。IBM Rational 热衷于继续在 MDA 标准上的深层次的参与，并确保那些标准在 IBM Rational 的工具中是可实践的和高效的。

总结

MDA 还在一个发展的过程中；完整的 MDA 定义还在不断的演进。狭义上讲，它是关于一个系统的不同的抽象模型，和在模型之间的定义良好的模型转换。广义上讲，它是关于抽象的各种级别上的模型，这些抽象作为基础为软件架构服务，这些架构最终将通过各种实现技术被实现。此时，MDA 被解释的非常广泛，并且很多组织（他们的一些工具已经在本文中被提及）主张在不同的方案中"支持" 或者 "符合" MDA 的标准。

我们已经利用这个机会表明了 IBM Rational 对于 MDA 的观点和我们的工具是如何支持被 OMG 定义的 MDA 的。基本上，当前我们的可视化和开发工具以两种方式支持 MDA：1）通过在特定的方案领域提供高度自动化，和 2）通过允许组织容易的为自己的特定领域构建定制的模型驱动的方法来提供综合目的的能力。随着时间的迁移，我们也将坚定的支持 MDA 。

IBM 将 MDA 视为一系列新兴的关注于软件开发的特殊方式的标准和技术 -- 这种开发方式强调在各种抽象的级别上利用建模，最重要的是通过这些模型的信息整合和信息流。这种方法允许开发人员通过使用与他们的信息和决定最匹配的模型类型对项目作出贡献。它也允许高级的项目成员通过他们对模型到模型转换的定义和实现使他们的工作效率最大化。系统的分析人员、测试人员和质量保证人员能够在系统被完成之前利用模型分析系统和系统的性能。

今天，IBM 正积极的与被选择的客户一起工作来改进 MDA 的实践。这些经验将随着时间的推移驱动我们支持 MDA 的方法。

鸣谢

在本文中被讨论的思想反映了一个来自于 IBM 的广泛团队的思想，包括 Jim Amsden, Grady Booch, Gary Cernosek, Magnus Christerson, Jim Conallen, Luan Doan-Minh, Pete Eeles, John Hogg, Sridhar Iyengar, Simon Johnston, Grant Larsen, Martin Nally, Jim Rumbaugh, Bran Selic, 和 Dave Tropeano 。

进一步的读物

如果你对学习更多的在实践中应用 MDA 的知识，这里是三个主要的来源：

OMG 的材料。OMG 是学习、了解 MDA 思想的主要来源（浏览 http://www.omg.org/mda）。当前，OMG 的材料趋于既有瞄准在实现规范的技术上的也有 MDA 方法的高级别的白皮书和展示，并且还提供概念和标准的全面介绍。不幸的是，在这两个方面的材料之间的能够让人更多的了解 MDA 在实际的开发方法和开发环境是如何被应用的资源是不够丰富的。你可以参看下面的“参考资料”部分。

　书和论文。为了弥补 OMG 材料的缺乏，一些专家已经出版和发表了一些关于 MDA 的书和论文。主要的两本是：Kleppe 所著的 MDA Explained: The Model Driven Architecture Practice and Promise（Addison Wesley ， 2003） 和 D. Frankel 所著的 Model Driven Architecture: Applying MDA to Enterprise Computing（Wiley 出版社 ， 2003）。第三本书正在编写之中：S. Mellor 所著的 MDA Distilled（将在 2004 年 由 Addison Wesley 出版）。其他的一些书籍在重要的 MDA 技术方面提供了有用的观点，比如在可执行的 UML 和对象约束语言（OCL）方面。他们包括 S. Mellor 所著的 Executable UML: A Foundation for MDA（Addison Wesley ， 2003） 和 J. Warmer 与 A. Kleppe 所著的 The Object Constraint Language: Getting Your Models Ready for MDA， 第二版 （Addison Wesley ， 2003）。这两类书提供了在 重要的 OMG 的标准以及这些标准之间的关系和支持 MDA 的实践中的有限的观点上提供了看法。你可以参看下面的“参考资料”部分。

　主要的工业和理论材料。就像 MDA 方法受到了支持一样，众多关于 MDA 的实践应用、能力和限制的材料是可得到的。当前，这种材料在关注点、深度和质量上是不一样的。OMG 维护了一个小的 MDA 论文的库（ www.omg.org/mda/presentations.htm），它提供了一个好的开始点。使用 Web 搜索引擎将找到更多的资料。

注释

2 对于那些有兴趣更多的了解一些在实践中应用 MDA 的人有一些帮助的资源。本文末尾的"进一步的读物"部分提供了一个有用的开始点。

3 D.K. Barry, Web Services and Service Oriented Architectures。 Morgan Kaufman ， 2003 。

4 P. Clements and L. Northrop ， Software Product Lines: Practices and Patterns。Addison Wesley ， 2001 。

5 在本文中，一个概念性的框架是指导计划、理解和企业方案实现的重要的概念和机构集合。

6 Richard Soley and OMG Staff Strategy Group ， "Model Driven Architecture," November 2000 。

7 图 1 是基于最初被 John Daniels 使用的图的。

8 许多其他的重要生命周期产物也会从模型驱动方法中受益（比如，需求列表、测试用例和构建脚本）。为了简单起见，我们将经理放在主要的开发周期产物上 -- 代码。

9 对于这个讨论我们将忽略代码本身就是一种编程模型实现的事实，这个编程模型将开发人员从在内存、寄存器中操作单个的位的机器代码中抽象了出来。

10 在一些情况下，更多的代码框架根据模型被真实的产生出来。

11 本文中涉及到的更加详细的样例将在本系列文章的后续部分中被讨论。然而，你就＝可能希望了解一下 MDA 在商业工具中的例子，比如 IBM Rational Rose Technical Developer 和 Rapid Developer 产品（ http://www.ibm.com/rational）或者应用这种方法的开放源码的 MDA 工具（比如，AndroMDA ( http://www.andromda.org和 Jamda ( http://jamda.sourceforge.net））。

12 看一下，比如 http://www.rational.com/success和使用 "model driven." 关键字进行搜索。

13 使用 IBM Rational 工具创建 MDA 方案的详细例子将会在本系列文章的后续部分被提供。这里提供的是 IBM Rational 工具对 MDA 支持的简单介绍。

参考资料

T. Sloan, "Business Model Collaborations: Pushing Software Revolution." Software Magazine, September 2003: www.softwaremag.com

A. Kleppe, J. Warmer, and W. Bast, MDA Explained: The Model Driven Architecture Practice and Promise. Addison Wesley, 2003.

D. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing. Wiley Press, 2003.

Richard Soley and OMG Staff Strategy Group, "Model Driven Architecture." November 2000.

P. Harman, "MDA: An Idea Whose Time Has Come." Cutter Consortium, 2003.

B. Selic, "The Pragmatics of Model-Driven Development," IEEE Software, Vol. 20, #5, September 2003.

T. Gardner, C. Griffin, J. Koehler, and R. Hauser, "A review of OMG MOF 2.0 Query/View/Transformation Submissions and Recommendations Towards the Final Standard." IBM Whitepaper submitted to the OMG, September 17, 2003.

D.K. Barry, Web Services and Service Oriented Architectures. Morgan Kaufman, 2003.

P. Clements and L. Northrop, Software Product Lines: Practices and Patterns. Addison Wesley, 2001.

A. Thomas Manes, Web Services: A Manager's Guide. Addison Wesley, 2003.

S. Mellor et al., MDA Distilled.Forthcoming from Addison Wesley, 2004.

S. Mellor et al., Executable UML: A Foundation for MDA. Addison Wesley, 2003.

J. Warmer and A. Kleppe, The Object Constraint Language: Getting Your Models Ready for MDA, second edition. Addison Wesley, 2003.

J. Daniels, "Modeling with a Sense of Purpose." IEEE Software, pp8-10, Jan/Feb 2002.

　关于作者

　Alan Brown has authored this article

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号