模型驱动的体系架构MDA

模型驱动的体系架构MDA很多组织已经开始对模型驱动的体系架构（MDA）进行关注，MDA 是一种应用系统设计和实现的方法。

对于几个原因来说这都是非常积极的发展。

MDA 鼓励在软件的开发过程中有效的使用系统的模型，并且它支持创建类似系统的最佳实践的重用。

所谓由对象管理组织（OMG）定义的标准，MDA 是一种组织和管理被自动化工具支持的企业体系架构和用于定义模型和推动不同模型类型之间的转换的服务的方法。

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

有效的企业软件开发今天开发企业级的应用要求一种软件架构的方法，这种方法应该能够以一种灵活的方式帮助架构师来发展他们的架构。

这种方法应该允许在及时的实现业务功能的新的能力的情况下重用已有的劳动成果，甚至是当目标基础架构本身在一直的演进。

两个重要的思想现在被认为是应对这种挑战的中心：• 面向服务的体系架构(SOA)。

企业解决方案能够被视作通过良好的说明定义了他们的服务接口契约连接的服务联合。

结果的系统设计通常被称作面向服务的体系架构（SOAs）。

通过将一个系统组织成为被封装好的服务集合，这些服务可以通过他们定义的服务接口被操作，系统的灵活性被大大的增强了。

现在很多组织用一系列的服务和服务之间的相互连接表示他们的解决方案。

• 软件的产品线。

通常，在一个组织开发和维护的系统中，存在着大量的可公用的部分。

从捕获核心业务过程和领域概念的标准领域模型，到开发人员在代码中使用的实现设计的实现细节方案，我们在企业的软件项目的每一个级别上看到了重用的方法。

当模式能够被经验丰富的从业者开发出来并在跨越组织的范围内传播时，软件开发组织将获得大量的效率。

这表现了一种朝着促进计划的资产重用，增加自动化的级别来实现被开发系统大部分的方案的软件产品线开发视图的迁移。

更加普遍的情况下，我们能够将在开发的产品线视图中定义良好模式的应用理解成为一种从一个抽象级别到一个更底层抽象级别的方案转化描述的方法。

这两种思想对对象管理组织（OMG）的思想有着重大意义的影响，一个开发和支持规范以改进企业软件开发和部署实践的软件组织联盟（在下一个部分 OMG 将扮演更重要的角色）。

OMG 已经创建了一个概念性的框架，这个概念性的框架将平台选择与独立的面向业务的决定分离开来以使在架构和演进这些系统时允许更大的灵活性。

这个概念性框架和帮助实现它的标准就是 OMG 称为的"模型驱动的体系架构（MDA）."。

应用的架构师使用 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 显示了今天软件从业者使用的建模方法的光谱。

每一个类型代表了一种独特的帮助软件从业者创建能够运行在特定运行时平台上的应用（代码）和模型与代码之间的关系的模型的使用。

8图 1: 建模的光谱今天，多数的软件开发人员仍然在使用单独－代码的方法（在建模光谱的左端，图1）并且根本没有分离的定义模型。

他们几乎完全的依靠他们编写的代码，并且他们直接在一种集成的开发环境（IDE）中（比如，IBM WebSphere Studio ， Eclipse 或者 Microsoft VisualStudio 9）通过第三代的编程语言如 Java 、C++ 或者 C# 直接的表示他们正在建立的系统的模型。

他们所做的任何"建模"都是以嵌入在代码中的编程的抽象形式进行的（比如，包、模块和接口等等），这些方式是通过程序库和对象层次的机制进行管理的。

任何分离的体系架构的设计模型都是不正规的和依靠直觉的，并且存在于白板上、PowerPoint 幻灯片上或者开发人员的脑袋中。

然而这种方法对于个体开发者和小的开发团队也许是足够的，但是这种方法使在业务逻辑实现的细节中理解系统的关键特性十分的困难。

此外，随着系统的范围和复杂度的增加，系统的演进或者在原来的设计团队成员不能直接的与维护系统的团队沟通时，这种方法对于管理这些方案的演进将是更加困难的。

一个改进是在一些适当的建模符号中提供了代码可视化。

当开发人员创建或者分析一个应用时，他们通常希望通过一些辅助理解代码的结构或者行为的图形化符号来可视化代码。

作为一种编辑基于文本代码的可选方式利用图形化的符号也是可能的，所以可视化的描写变成了一种代码的直接表示。

这种描写有时称作代码模型，或者实现模型。

在允许这种画图的工具中（比如，IBM WebSphere Studio 和 Borland Together/J），代码的视图和模型的视图可以被同时显示；当开发人员对其中的一个进行操作时，另一个视图也将立即进行同步。

在这种方法中，图与代码表示紧紧的联系在一起，并提供了在代码级别上观看和编辑的可选方法。

建模的更深层次的利益是通过双向工程（RTE）得到的，双向工程提供了一种在描述系统的架构或者设计和代码的模型之间进行双向交换的机制。

典型的情况下，开发人员将系统设计细化到一定的详细级别，然后通过应用模型－代码的转换创建第一轮的实现，这通常是手工完成的。

例如，一个工作在高级别设计的团队也许会向工作在实现级别上的团队提供设计模型（也许是通过简单的打印出模型图或者为实现团队提供包含模型的文件）。

实现团队转换这个抽象、高级别的设计成为详细的设计模型的集合和编程语言的实现。

其中表示上的重复将作为错误出现，这些错误既可以在设计模型中更正也可以在实现模型中更正。

因此，如果没有良好的纪律，抽象模型和实现模型常常—并很快—的因为步调不一致而结束。

工具能够自动化的进行最初的转换，也可以在设计模型和实现模型进行演进时帮助他们保持步调一致。

典型的，工具可以从用户必须进一步细化的设计模型生成代码的框架。

对代码的更改必须要在一些点上与原有的模型相一致（也就是术语"双向工程"或者 RTE）。

为了实现这一点，你需要一种方法来识别出被产生的用户定义的代码；在代码中放置标记就是一种方法。

实现这个方法的工具，比如 IBM Rational Rose 能够支持在模型与不同实现语言之间双向提供多种转换服务。

在一种以模型为中心的方法中，系统模型具有足够的细节能够从这些模型中生成整个系统的实现。

为了实现这一点，模型也许应该包括，比如持久数据和非持久数据、业务逻辑和表示层元素的表示法。

如果存在任何与遗留数据和服务的集成，对那些元素的接口也需要被建模。

然后代码生成过程应用一系列的模式将模型转换成代码，通常允许开发人员对被应用的模式进行一些选择（比如，选择各种不同的部署拓扑）。

这种方法常常使用标准的或者私有的应用框架和运行时服务，这些应用框架和运行时服务能够通过限制被生成应用的类型使代码生成任务更加容易。

因此，使用这种方法的工具典型的专攻于特定应用类型的生成（例如，用于实时嵌入式系统的 IBM Rational Rose Technical Developer 和用于企业 IT 系统的IBM Rational Rapid developer）。

然而，在所有的情况下，模型都是被开发人员创建和操作的主要产物。

一个单独模型的方法在图 1 中的编码/建模光谱的最右端。

在这种方法中开发人员把模型纯粹的作为理解业务或者方案领域，或者分析被提议的方案架构的辅助手段。

模型通常被作为讨论、交流和在一个单独的组织或者是跨多个组织的项目中进行分析的基础来使用。

这些模型常常出现在新工作的建议中，或者装饰在办公室的墙上和在软件实验室中作为一种促进对一些复杂领域理解的方法并建立一个共享的在完全不同的团队中的词汇表和概念集。