事件驱动架构模型_模型驱动架构简介

事件驱动架构模型_模型驱动架构简介 最近几个月，许多组织开始将注意力集中在模型驱动的体系结构（MDA） ^1上，作为应用程序设计和实现的一种方法。 由于几个原因，这是一个非常积极的发展。 MDA鼓励在软件开发过程中有效使用系统模型，并在创建系统系列时支持重用最佳实践。 正如对象管理组（OMG）定义的那样，MDA是一种组织和管理由自动化工具和服务支持的企业体系结构的方法，用于定义模型和促进不同模型类型之间的转换。

尽管OMG定义的用于创建和发展企业级软件系统的MDA标准和术语在业界得到广泛引用，但直到最近，OMG及其成员（包括IBM Rational）才能够提供有关MDA含义的明确指导，我们的发展方向，当今技术可能在MDA的哪些方面以及如何在实践中利用MDA。

本文是由三部分组成的系列文章的第一部分，该系列文章涵盖：当今工业中如何使用建模以及MDA与当今系统的相关性（第一部分）；以及 MDA工具支持的分类（第二部分）； 以及在IBM模型驱动的开发技术中使用MDA的示例（第III部分）。

在第一部分中，我们研究了模型和建模的重要性，并介绍了MDA的四个关键原则。 然后，我们看一下IBM对MDA的支持以及IBM在定义MDA方法及其支持标准方面所起的领导作用。 ²

有效的企业软件开发

当前，开发企业级应用程序需要一种软件架构方法，以帮助架构师以灵活的方式发展其解决方案。这种方法应允许在新功能的上下文中重用现有工作，这些新功能可以及时实现业务功能，即使目标基础结构本身也在不断发展。现在，两个重要的想法被认为是应对这一挑战的核心：

面向服务的体系结构（SOA） 。企业解决方案可以看作是服务的联盟，这些联盟通过定义良好的服务接口的指定合同进行连接。由此产生的系统设计通常称为面向服务的体系结构（SOA）。 ³通过将系统组织为封装的服务的集合，从而对通过其服务接口定义的操作进行调用，可以增强系统体系结构的灵活性。现在，许多组织都在服务和互连方面表达了他们的解决方案。
软件产品线 。通常，组织开发和维护的系统之间存在很多共性。从具有捕获核心业务流程和域概念的标准域模型，到开发人员实施特定解决方案以代码实现设计的方式，我们看到了在企业软件项目的每个级别上都反复出现的方法。当模式可以由熟练的从业者定义并在IT组织中传播时，组织将获得极大的效率。这代表着朝着软件产品线的发展方向发展，这种观点促进了资产的计划重用，并提高了自动化水平，从而为正在开发的系统的大部分实现了解决方案。 ⁴更一般而言，我们可以在开发的产品线视图中理解定义明确的模式的应用，以将解决方案的描述从一个抽象级别转换为一个较低抽象级别。

这两个想法对对象管理组（OMG）的思想产生了重大影响，对象管理组是一个软件组织的联盟，该组织开发并支持规范以改进企业软件开发和部署的实践。（OMG在下一节中将扮演重要角色。）OMG创建了一个概念框架⁵ ，该框架将面向业务的决策与平台决策分开，以在架构和发展这些系统时提供更大的灵活性。这个概念框架和帮助实现它的标准就是OMG所说的“模型驱动体系结构（MDA）”。 ⁶应用程序架构师将MDA框架用作表达其企业体系结构的蓝图，并采用MDA固有的开放标准作为他们对供应商锁定和技术流失的“未来证明”。

OMG的MDA概念通过OMG既定的建模标准为系统互操作性提供了一种开放的，与供应商无关的方法：统一建模语言（UML），元对象工具（MOF），XML元数据交换（XMI）和通用仓库元模型（ CWM）。可以使用这些建模标准来构建企业解决方案的描述，并将其转换为主要的开放或专有平台，包括CORBA，J2EE，.NET和基于Web的平台。

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

建模原理

模型提供了物理系统的抽象，使工程师可以通过忽略无关的细节而专注于相关细节来推理该系统。所有形式的工程都依靠模型来理解复杂的实际系统。模型以多种方式使用：预测系统质量，在系统方面发生更改时针对特定属性的原因，以及将关键系统特征传达给各个涉众。可以将模型开发为实现物理系统的前提，或者可以从现有系统或正在开发的系统中派生模型，以帮助理解其行为。

视图和模型转换

由于可能需要关注系统的许多方面，因此可以根据任何时间点的相关性，使用各种建模概念和表示法突出显示该系统的一个或多个特定视角或视图。此外，在某些情况下，您可以使用提示或规则扩充模型，以帮助将它们从一种表示形式转换为另一种表示形式。通常有必要在等效的抽象级别（例如，从结构视图到行为视图）转换为系统的不同视图，并且模型转换可以简化此过程。在其他情况下，通过添加转换规则提供的更多详细信息，转换会将提供特定视角的模型从一个抽象级别转换为另一个抽象级别，通常从更抽象的视图转换为不太抽象的视图。

模型，建模和MDA

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

在软件工程世界中，建模具有悠久的传统，可以追溯到编程的早期。最新的创新集中在符号和工具上，这些符号和工具允许用户以易于映射到可为特定操作系统平台编译的编程语言代码的方式，向软件设计师和开发人员表达系统的价值观点。该实践的当前状态采用统一建模语言（UML）作为主要建模符号。 UML使开发团队可以在相应的模型中捕获系统的各种重要特征。这些模型之间的转换主要是手动的。 UML建模工具通常支持需求可追溯性和建模元素之间的依赖关系，并带有支持文档和补充性咨询产品，它们提供了有关如何维护同步模型的最佳实践指南，这是大规模开发工作的一部分。

表征当前实践的一种有用方法是查看模型与它们帮助描述的源代码同步的不同方法。图^1、7对此进行了说明，该图显示了当今软件从业人员正在使用的各种建模方法。每个类别都标识了模型的特定用途，以帮助软件从业人员为特定的运行时平台创建正在运行的应用程序（代码），以及模型与代码之间的关系。 ⁸

图1：建模范围

查看全尺寸图片

如今，大多数软件开发人员仍采用仅代码的方法（建模范围的左端，图1），根本不使用单独定义的模型。他们几乎完全依赖于编写的代码，并且在集成开发环境（IDE）（例如IBM WebSphere Studio）中以第三代编程语言（例如Java，C ++或C＃）直接表达他们正在构建的系统的模型。，Eclipse或Microsoft VisualStudio。 ⁹他们所做的任何“建模”都是嵌入在代码中的编程抽象形式（例如，包，模块，接口等），这些抽象通过诸如程序库和对象层次结构之类的机制进行管理。建筑设计的任何单独建模都是非正式且直观的，并且存在于白板，PowerPoint幻灯片或开发人员的头脑中。尽管这种方法可能适合个人和非常小的团队，但是这使得在业务逻辑的实现细节中难以理解系统的关键特性。此外，随着这些解决方案的规模和复杂性的增加，随着系统的发展，或者当维护团队无法直接访问设计团队的原始成员时，管理这些解决方案的演进变得更加困难。

一种改进是以某些适当的建模符号提供代码可视化 。当开发人员创建或分析应用程序时，他们通常希望通过某种图形表示法来可视化代码，以帮助他们理解代码的结构或行为。作为编辑基于文本的代码的替代方法，也可以操纵图形符号，以使视觉呈现成为代码的直接表示。这种渲染有时称为代码模型或实现模型（尽管许多人认为将这些工件称为“图”并保留“模型”的使用以用于更高的抽象级别是适当的）。在允许这种图表的工具中（例如，IBM WebSphere Studio和Borland Together / J），可以同时显示代码视图和模型视图。当开发人员操纵其中一个视图时，另一个视图将立即与其同步。在这种方法中，图表是紧密耦合的代码表示形式，并提供了一种替代方法来查看和可能在代码级别进行编辑。

往返工程 （RTE）可提供更多的建模优势，该工程在描述系统架构或设计的抽象模型与代码之间提供了双向交换。开发人员通常会在某种程度上详细说明系统设计，然后通常通过手动应用模型到代码的转换来创建首过实施。例如，一个从事高级设计的团队可能会向从事实现的团队提供设计模型（可能只是通过打印出模型图或为实现团队提供包含模型的文件）。实现团队将这种抽象的高层设计转换为一组详细的设计模型和编程语言实现。这些表示的迭代将作为可能在设计或代码中纠正的错误发生。因此，由于没有足够的纪律性，抽象模型和实现模型通常（而且很快）最终会步履蹒跚。

工具可以使初始转换自动化，并且还可以随着设计和实施模型的发展保持步调一致。通常，这些工具会根据用户需要进一步完善的设计模型生成代码存根。 ¹⁰对代码的更改必须在某些时候与原始模型保持一致（因此，术语“往返工程”或RTE）。为此，您需要一种识别生成的代码与用户定义的代码的方法。在代码中放置标记是一种方法。实现这种方法的工具（例如IBM Rational Rose）可以提供支持模型和不同实现语言之间的RTE的多种转换服务。

在以模型为中心的方法中，系统模型具有足够的细节，可以从模型本身生成完整的系统实现。为了实现这一点，模型可以包括例如持久性和非持久性数据的表示，业务逻辑和表示元素。如果与遗留数据和服务进行了任何集成，则可能还需要对这些元素的接口进行建模。然后，代码生成过程可以应用一系列模式将模型转换为代码，从而经常允许开发人员在所应用的模式中进行一些选择（例如，在各种部署拓扑中）。这种方法经常使用标准或专有的应用程序框架和运行时服务，这些服务框架通过限制可以生成的应用程序的样式来简化代码生成任务。因此，使用这种方法的工具通常专门用于特定样式的应用程序的生成（例如，用于实时嵌入式系统的IBM Rational Rose技术开发人员和用于企业IT系统的IBM Rational Rapid开发人员）。但是，在所有情况下，模型都是开发人员创建和操纵的主要工件。

仅模型方法位于图1所示的编码/建模频谱的最右端。在这种方法中，开发人员纯粹使用模型来帮助理解业务或解决方案领域，或用于分析所提出解决方案的体系结构。模型经常用作单个组织内或跨多个组织项目的团队之间进行讨论，交流和分析的基础。这些模型经常出现在新工作的提案中，或者在软件实验室的办公室和立方体的墙壁上装饰，以促进对某些复杂的关注领域的理解，并在不同团队之间建立共享的词汇表和概念集。实际上，无论是从头开始还是作为对现有解决方案的更新，系统的实现都可以与模型断开连接。一个有趣的例子是，越来越多的组织在保持对整个企业体系结构的控制的同时，将其系统的实现和维护外包。

MDA：日益增长的共识

建模对软件工程产生了重大影响，对于每个企业级解决方案的成功至关重要。但是，模型代表什么以及如何使用它们，种类繁多。一个有趣的问题是：我们可以将其中哪些方法描述为“模型驱动”？如果我创建系统某个部分的可视化图像，是否表示我正在练习MDA？不幸的是，没有确切的答案。相反，越来越多的共识认为，MDA与从更抽象的模型自动（半）生成代码并采用标准规范语言描述这些模型的方法紧密相关。我们将在下一部分中探讨这个概念。

理论上的MDA

关于什么是MDA，什么不是MDA有许多意见。但是，最权威的观点是由对象管理小组（OMG）提供的，对象管理小组是由800多家公司，组织和个人组成的行业联盟。为什么OMG的MDA观如此重要？作为新兴的体系结构标准，在过去的二十年中，MDA成为了OMG支持和众多计算标准的编纂的悠久传统。 OMG负责开发一些针对系统规范和互操作的业界最著名和最有影响力的标准，包括通用对象请求代理体系结构（CORBA），OMG接口定义语言（IDL），Internet Inter-ORB协议（IIOP），统一建模语言（UML），元对象工具（MOF），XML元数据交换（XMI），通用仓库模型（CWM）和对象管理体系结构（OMA）。此外，OMG还增强了这些规范，以支持特定行业，例如医疗保健，制造，电信和其他行业。

OMG重新调整了其战略，标准和定位，以支持MDA方法。它正在推广MDA，以开发更准确地满足客户需求并在系统演进中提供更大灵活性的系统。 MDA方法建立在较早的系统规范标准工作的基础上，并且提供了用于定义互连系统的综合互操作性框架。

MDA原理

OMG对MDA的看法基于以下四个原则：

以明确定义的符号表示的模型是理解企业级解决方案系统的基石。
通过在模型之间施加一系列转换，可以围绕一组模型来组织系统的构建，将其组织为层和转换的体系结构框架。
在一组元模型中描述模型的正式基础有助于模型之间有意义的集成和转换，并且是通过工具实现自动化的基础。
要接受和广泛采用这种基于模型的方法，就需要行业标准以向消费者开放并促进供应商之间的竞争。

为了支持这些原则，OMG定义了一组特定的层和转换，它们为MDA提供了概念框架和词汇。值得注意的是，OMG识别四种类型的模型：计算独立模型（CIM），平台独立模型（PIM），由平台模型（PM）描述的特定于平台的模型（PSM）和特定于实现的模型（ISM）。

对于MDA，“平台”仅相对于特定的观点才有意义-换句话说，一个人的PIM是另一个人的PSM。例如，如果该模型没有规定中间件技术的特定选择，则该模型可以是关于通信中间件的选择的PIM。但是，当决定使用特定的中间件（例如CORBA）时，该模型将转换为CORBA特定的PSM。就选择ORB而言，新模型可能仍是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意识到元模型和形式语义对于建模的重要性，并且它定义了一组元模型级别以及用于表达元模型的标准语言：元对象工具（MOF）。元模型使用MOF来正式定义一组建模构造的抽象语法。

模型和它们之间的转换将使用开放标准来指定。作为行业协会，OMG倡导了许多用于指定系统及其互连的重要行业标准。通过CORBA，IIOP，UML和CWM等标准，软件行业可以达到以前无法实现的系统互操作性水平。此外，MOF和XMI等工具互换标准也促进了工具互操作性。

一个简单的例子

图3显示了平台无关模型（PIM）及其转换为三种不同的平台特定模型（PSM）的简化示例。

图3：从PIM到PSM转换的简化示例

查看全尺寸图片

图3中的简单PIM代表一个客户和帐户。在此抽象级别上，该模型根据类及其属性描述了域的重要特征，但是没有描述有关使用哪种技术来表示它们的任何特定于平台的选择。图3说明了定义为创建PSM的三个特定映射或转换，以及用于表达这些映射的标准。例如，一种方法是使用表示为XML架构定义（XSD）或文档类型定义（DTD）的标准定义，将以UML表示的PSM导出为XMI格式。然后，可以将其用作代码生成工具的输入，该工具为UML中定义的每个类在Java中生成接口定义。

通常，在代码生成工具中内置了一组规则以执行转换。但是，代码生成工具通常允许将这些规则专门定义为脚本语言中的模板。 ¹¹

概述MDA理论

在使用模型表示问题和解决方案领域中的关键思想的悠久历史之后，MDA提供了一个概念框架，用于使用模型并在模型之间进行转换，以此作为受控，有效的软件开发过程的一部分。以下是当今控制MDA使用的基本假设和参数：

模型可以帮助人们理解和交流复杂的想法。
根据上下文，可以对许多不同种类的元素进行建模。这些提供了对世界的不同看法，必须最终调和。
我们在这些模型的各个层次上都看到了共性– 在正在分析的问题和建议的解决方案中。
应用不同类型的模型的思想并在表示之间进行转换可提供一种定义明确的开发样式，从而可以识别和重用常见方法。
在所谓的“模型驱动的体系结构”中，OMG提供了一个概念框架和一组标准来表达模型，模型关系以及模型到模型的转换。
工具和技术可以帮助实现此方法，并使其实用，高效地应用。

IBM和MDA

IBM在建模，模型驱动的开发和MDA方面拥有悠久的支持历史，这在IBM技术和服务的许多领域都很明显（例如，在业务建模，数据建模，部署建模等方面）。在这里，我们将集中讨论IBM Rational解决方案，在该解决方案中，建模主要用于驱动企业级软件密集型系统的设计和实现。

十多年来，IBM Rational工具一直强调模型的重要性，认为模型是提高软件从业人员理解和构建软件解决方案的抽象水平的一种方式。在过去的几年中，软件开发行业越来越意识到更高级别的抽象的价值-从机器语言级别的代码描述到MDA本身的出现-如图4所示。

图4：软件从业者日益提高的抽象水平

查看全尺寸图片

我们已经看到软件从业人员对软件密集型解决方案的看法发生了一些根本性的变化。这些举措改变了绝大多数软件工程师的思维方式。以前，他们关心的是处理数据位和在CPU中的寄存器之间移动字节的底层细节。现在，他们越来越多地将大部分时间用在要支持的用例方面，了解用户的问题领域，并设计解决方案，将其概念化为提供行为的服务协作以实现这些用例。这种思想上的深刻转变之所以能够实现，是因为它得到了有效工具的支持，这些工具可以使新概念得以清晰表达和共享。

当然，UML是实现此更改的关键。它提供了一套通用概念，并在整个软件行业中得到了广泛使用，这很快结束了关于在设计软件系统时使用哪种概念的冗长辩论。众所周知，IBM Rational在定义UML中的领导作用，以及IBM Rational Rose产品在实施UML以支持大型软件系统的架构方面的杰出地位，都得到了广泛认可。 IBM Rational Rose XDE中应用了相同的原理，该原理将丰富的建模环境与面向代码的工具集结合在一起，以创建一个全面的实践者桌面，以针对各种运行时基础架构创建各种架构样式的解决方案。

IBM继续保持丰富的建模支持传统，IBM通过其可视化建模和开发工具来支持当今OMG定义的MDA，并致力于随着时间的发展来支持MDA。

IBM对MDA的看法

IBM坚信，通过创建问题域和解决方案域的模型以及在软件项目的整个生命周期内协调这些模型，可以为组织提供良好的服务。因为IBM强烈支持这种模型驱动的方法进行软件开发，并且模型驱动的开发构成了IBM可用的最佳实践和工具的关键组成部分，所以今天，许多IBM客户都采用这些技术来产生巨大的效果。 ¹²

IBM认识到MDA是一种针对特定软件开发风格的新兴标准和技术，其中规定了要使用的某些类型的模型，如何准备这些模型以及不同模型之间的关系。。 MDA提供了一种方法，并为以下方面提供了工具：

独立于支持平台的平台来指定系统。
指定平台。
为正在开发的系统选择特定的平台。
将系统规范转换为针对特定平台的规范。

总体而言，IBM相信两类软件开发工具为MDA提供了强大的支持：

在模型定义和转换中提供高度自动化的工具，通常针对特定的应用程序域，可以针对这些特定应用程序域预定义适合该域的复杂转换规则。
设计用于更一般用途的工具，但可以将其配置为通过最终用户和第三方工具供应商扩展和自定义来支持MDA，这些扩展和自定义通常针对更广泛的应用程序域。

IBM Rational提供这两个类别的产品。 ¹³

在第一类中，IBM Rational Rose Technical Developer提供了高度自动化的模型转换和强大的代码生成功能-这些功能对于嵌入式系统和其他技术软件产品的开发人员而言尤其重要。同样，IBM Rational Rapid Developer提供了针对J2EE应用程序的MDA的高度自动化实现，该J2EE应用程序集成和扩展了现有的遗留系统。 In the second category, IBM Rational Rose XDE Developer offers a combination of patterns capabilities, code templates, and application8 Many other important lifecycle artifacts also benefit from a model driven approach (eg, requirements lists, test cases, and build scripts). For simplicity we concentrate on the primary development artifact â???? the code.program interfaces that allow developers and third-party tool vendors to custom-develop their implementation of MDA for more general domain applicability.

IBM leadership for MDA

Another important aspect of IBM's support for MDA can be seen in the leadership position that IBM plays in many of the key MDA standards. IBM has consistently provided strong support for the OMG in terms of:

Specific standards largely derived from IBM technologies. The key example, of course, is UML, as it was based on the work of IBM Rational--formerly Rational Software--which was acquired by IBM in 2003. However, IBM Rational has also had a major influence on other standards such as the Meta Object Facility (MOF), the Query, View, and Transformation (QVT) standards, and the emerging Reusable Asset Specification (RAS) work.
Personal commitments from IBM Rational to drive MDA standards. IBM Rational personnel occupy key positions on the OMG Architecture Board, on standards task forces, and in the teams developing solutions. IBM Rational is committed to continuing this deep involvement in MDA standards, and to ensuring that those standards are practical and effectively implemented in IBM Rational tools.

Summary

MDA is a work in progress; the very definition of MDA is evolving. In the narrowest sense, it is about different abstract models of a system, and well-defined model transformations among them. In a more general sense, it is about models at varying levels of abstraction that serve as the basis for software architectures that are ultimately realized through various implementation technologies. At this time, MDA is interpreted very broadly, and many organizations (some of whose tools have been mentioned in this article) claim "support for," or "conformance to," MDA in their diverse solutions.

We have taken this opportunity to characterize the IBM Rational view of MDA and how our tools support MDA as it is defined today by the OMG. Fundamentally, our visual modeling and development tools support MDA today in two key ways: 1) by offering a high degree of automation in specific solution domains, and 2) by providing general-purpose capabilities that allow organizations readily to construct customized, model driven approaches for their own specific domain. We are also firmly committed to supporting MDA as it evolves over time.

IBM recognizes MDA as an emerging set of standards and technologies focused on a particular style of software development â???? one that emphasizes the advantages of modeling at various levels of abstraction and, most important, the integration and flow of information through these models. This approach allows software developers to contribute to a project through the types of models that best match the kinds of information and decisions they make. It also allows senior project members to maximize their effectiveness through their definition and implementations of model-to-model transformations. System analysts, testers, and quality assurance staff can leverage models to analyze the system and its performance before the system is complete.

IBM is actively working with select clients today to improve MDA practice. Those experiences will drive the way we support MDA as it evolves over time.

致谢

The ideas discussed in this article reflect the thinking of a broad team at IBM, including 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, and Dave Tropeano.

进一步阅读

For those interested in learning more about applying MDA in practice, there are three primary sources:

OMG materials . The OMG is the primary source for learning about many MDA ideas (see http://www.omg.org/mda ). Currently, its offerings tend to be either detailed specifications aimed at technologists implementing those specifications or high-level whitepapers and presentations that position the MDA approach for non-practitioners and provide overviews of concepts and standards. Unfortunately, there is little material to fill the space between these two extremes for those who want to understand more about MDA in the context of current development approaches, and how MDA can be applied in practice. Also see "References" below.
Books and papers . Recognizing the gaps in OMG materials, a number of experts have written books and papers on MDA that are now appearing in print. The two primary texts are: Kleppe et al., MDA Explained: The Model Driven Architecture Practice and Promise (Addison Wesley, 2003) and D. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing (Wiley Press, 2003). At this writing, a third book is on the way: S. Mellor et al., MDA Distilled (to be published by Addison Wesley, 2004). Another group of books offers useful perspectives on key MDA technologies, such as executable UML and the Object Constraint Language (OCL). These works include S. Mellor et al., Executable UML: A Foundation for MDA (Addison Wesley, 2003) and J. Warmer and A. Kleppe, The Object Constraint Language: Getting Your Models Ready for MDA , second edition (Addison Wesley, 2003). Both classes of books offer perspectives on the key OMG standards and their relationships, supported with limited insights into MDA in practice. Also see "References" below.
Broader industry and academic materials . As the MDA approach gains support, a number of materials are becoming available that address its practical application, strengths, and limitations. Currently, this material is very variable in focus, depth, and quality. The OMG maintains a small library of MDA papers ( www.omg.org/mda/presentations.htm ) that offers a good starting point. A wider search with a Web search engine will provide many more pointers.

You can also learn more about Model driven Architecture (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.

DK 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.

笔记

1 Model Driven Architecture (MDA) is a Registered Trade Mark of the Object Management Group.

2 There are a number of sources of help for those interested in learning more about applying MDA in practice. The "Further reading" section at the end of this article offers a useful starting point.

3 DK 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 In this context a conceptual framework is a set of key concepts and structures that guides the planning, understanding, and realization of an enterprise solution.

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

7 Figure 1 is based on a diagram originally used by John Daniels.

8 Many other important lifecycle artifacts also benefit from a model driven approach (eg, requirements lists, test cases, and build scripts). For simplicity we concentrate on the primary development artifact â???? the code.

9 For this discussion we shall ignore the fact that the code is itself a realization of a programming model that abstracts the developer from the underlying machine code for manipulating individual bits in memory, registers, etc.

10 In some cases much more than code stubs can be generated, depending on the fidelity of the models.

11 More detailed examples of this will be described in subsequent parts of this series. However, you may wish to take a look at examples of MDA in action in commercial tools such as IBM Rational Rose Technical Developer and Rapid Developer products ( https://www.ibm.com/software/rational ), or open source MDA tools applying this approach (eg, AndroMDA ( http://www.andromda.org ) and Jamda ( http://jamda.sourceforge.net )).

12 See, for example, https://www.ibm.com/software/rational and do a search using the keywords "model driven."

13 Detailed examples of the use of IBM Rational tools to create MDA solutions will be provided in subsequent parts of this series. Here we offer a broad overview of IBM Rational tool support for MDA.

翻译自: https://www.ibm.com/developerworks/rational/library/3100.html