模型驱动的体系架构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 幻灯片上或者开发人员的脑袋中。然而这种方法对于个体开发者和小的开发团队也许是足够的，但是这种方法使在业务逻辑实现的细节中理解系统的关键特性十分的困难。此外，随着系统的范围和复杂度的增加，系统的演进或者在原来的设计团队成员不能直接的与维护系统的团队沟通时，这种方法对于管理这些方案的演进将是更加困难的。

一个改进是在一些适当的建模符号中提供了代码可视化。当开发人员创建或者分析一个应用时，他们通常希望通过一些辅助理解代码的结构或者行为的图形化符号来可视化代码。作为一种编辑基于文本代码的可选方式利用图形化的符号也是可能的，所以可视化的