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

最近几个月，许多组织已开始将注意力集中在模型驱动的体系结构（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应用程序集成和扩展了现有的遗留系统。 在第二类中，IBM Rational Rose XDE Developer提供了模式功能，代码模板和应用程序8的组合。许多其他重要的生命周期工件也受益于模型驱动的方法（例如，需求列表，测试用例和构建脚本）。 为简单起见，我们专注于主要的开发工件– code.program接口，使开发人员和第三方工具供应商可以自定义开发其MDA的实现，以实现更通用的域适用性。

IBM在MDA方面的领导地位

从IBM在许多关键MDA标准中扮演的领导角色可以看出IBM支持MDA的另一个重要方面。 IBM一直在以下方面为OMG提供强大的支持：

• 特定标准主要源自IBM技术。 当然，关键示例是UML，因为它基于IBM Rational（以前称为Rational Software）的工作，该产品于2003年被IBM收购。但是，IBM Rational还对其他标准产生了重大影响，例如元对象工具（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的不断发展，我们也坚定地致力于支持MDA。

IBM将MDA视为针对特定软件开发风格的新兴标准和技术集– 一种强调在各种抽象级别进行建模的优势，最重要的是强调通过这些模型进行信息的集成和流动。 这种方法允许软件开发人员通过最能匹配他们所做出的信息和决策类型的模型类型来为项目做出贡献。 它还允许高级项目成员通过定义和实施模型到模型的转换来最大化其有效性。 系统分析师，测试人员和质量保证人员可以在系统完成之前利用模型来分析系统及其性能。

IBM现在正在积极与精选客户合作，以​​改善MDA惯例。 随着MDA的发展，这些经验将推动我们支持MDA的方式。

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