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 中被列举 ⁷ 图 1 显示了今天软件从业者使用的建模方法的光谱。每一个类型代表了一种独特的帮助软件从业者创建能够运行在特定运行时平台上的应用（代码）和模型与代码之间的关系的模型的使用。 ⁸

图 1: 建模的光谱

今天，多数的软件开发人员仍然在使用 单独－代码的方法（在建模光谱的左端，图 1）并且根本没有分离的定义模型。他们几乎完全的依靠他们编写的代码，并且他们直接在一种集成的开发环境（IDE）中（比如，IBM WebSphere Studio ， Eclipse 或者 Microsoft VisualStudio ⁹ ）通过第三代的编程语言如 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 中的编码/建模光谱的最右端。在这种方法中开发人员把模型纯粹的作为理解业务或者方案领域，或者分析被提议的方案架构的辅助手段。模型通常被作为讨论、交流和在一个单独的组织或者是跨多个组织的项目中进行分析的基础来使用。这些模型常常出现在新工作的建议中，或者装饰在办公室的墙上和在软件实验室中作为一种促进对一些复杂领域理解的方法并建立一个共享的在完全不同的团队中的词汇表和概念集。实际上，一个系统的实现，不论是从打草稿开始还是作为一个已有方案的更新，都可以从模型中分离出来。一个有趣的例子是越来越多的组织将他们的系统的实现和维护进行外包，而他们自己维护整个的企业架构的控制。

MDA：成长中的公认舆论

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

MDA 的理论

对于 MDA 是什么和不是什么有着很多中观点和意见，最权威的观点是被对象管理组织（OMG）提供的，一个拥有超过 800 家公司、组织和个人的软件行业联盟。为什么 OMG 关于 MDA 的观点是如此的重要呢？作为一个新兴的体系架构的标准，MDA 属于 OMG 支持的悠久传统和过去二十年中的众多计算机标准。 OMG 一直负责一些对于系统的说明和互操作性方面的工业上知名的和最具影响力的规范的开发，包括公共对象请求代理体系架构（CORBA），OMG 接口定义语言（IDL），Inte.net 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 正式的定义一系列建模构想的抽象语法。

原文转自：http://www.ltesting.net