MDA(Model Driven Architecture)是模型驱动架构，它是由OMG定义的一个软件开发框架。它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。和UML相比，MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。MDA把建模语言用作一种编程语言而不仅仅是设计语言。MDA的关键之处是模型在软件开发中扮演了非常重要的角色。

MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，MDA提供了一种途径（通过相关的工具）来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。MDA的三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性。

模型驱动架构（MDA）是OMG组织近年来一直热炒的一个新的技术体系，同时也是众多搞软件模型研究人员的一个新热点。MDA（模型驱动）核心的思路是希望通过对商业模型（比如企业信息化或建筑领域的解决方案）的领域研究。进而提炼出一个相对核心的领域模型，同时抽象出一个PIM（平台无关模型）。之后根据不同的开发平台（例如.net或J2EE），应用平台（windows或unix）形成相应的 PSM（平台相关模型）。依照相应的工具，例如 ArcStyler可以完整地生成相应的代码和软件系统。当然这里只是罗列出一个大致的思路和方法。

1 MDA理论还处在一个探索期，很多理论和方法并不成熟，当然无从谈起有成熟的工具，从目前的趋势而言，从理论到实际的工具都离OMG组织所提出的预想有较大距离，至少还需要数年的努力才能成型 。

2目前无论是国外的开源组织还是国内的一些组织对MDA都只是处在一个草创阶段，很多人所谓的应用MDA 其实都只是在MDA的体系中作一个最初的探索和尝试。例如 ORM就是在一定层次上实现MDA 在数据库应用方面的探索，但也只是解决了一个实体模型映射的问题。前几天一个面试人员用 ArcStyler4.X 做了一个银行POS系统的应用模型，生成了一点还需要修改的框架代码。就告诉我说他已经掌握了 MDA，斯等水准真是让我汗颜！佩服！

3 MDA的第一个热点可能是桥接器，而在MDA领域中，映射是个很重要的点，而转换和交互都只是在这个点上的延伸 。

4 目前而言，最有可能在MDA体系中得以实现的语言是 JAVA，尽管我很讨厌JAVA的一些愚蠢方法。

5 MDA的核心是PIM，因为他是最抽象和协同性最高的。同时就当前形势而言，PIM也是一个瓶颈！同时就目前的 UML2.0（从OMG那里得到最新的）而言，还不足以作为建立整个MDA体系的语言。同时对于MOF中的一些定义似乎还有提升的必要。因为对于整个体系而言，MOF应该更多的作为一个标准，只有在标准成熟的前提下，才有可能产生正确的映射规则。

6 等到MDA风光无限的那天，会使一部分程序员失业，但不会是全部，起码MDA工具要有人做，因为一个MDA工具不足以应付所有的领域。这就好比没有一个财务系统能适应所有的企业一样。因为各个领域的标准化不同。

一、MDA（模型驱动架构）背景

MDA目前在以下领域得到了应用：

• 银行业
• 保险业
• 公共企业(特别在金融管理领域)
• 嵌入式系统
• 后勤保障系统

您将会看到，MDA确在其中起到了作用。

MDA的流程

MDA的实现主要集中在以下3个步骤：

1 首先，您用UML对您的应用领域进行高度抽象的建模，这个模型和实现它的技术（或者底层技术）完全没有关系。这个模型我们称之为平台无关模型(PIM)。

2 然后，PIM将被转换为一个或多个平台相关模型(PSM)。这个翻译的过程一般是自动实现的。PSM将用一个特定的实现技术来描述您的系统。它将用到这种技术所提供的种种架构，比如EJB, 数据库模型，COM组件等等。

3 最后，PSM将被翻译成源代码。因为每个PSM已经完全依靠某种特定的技术，这个步骤一般是比较简单的。

MDA流程中最难的一步，是从PIM生成一个PSM。它要求您对您要应用的基础技术具有丰富且巩固的知识，另一方面，源模型(PIM)必须具备自动生成PSM所要求的足够信息量。

通过模板生成：MDA-light?!

在MDA的实际应用当中，一个较容易的实现是通过模板(我们称之为MDA-light)。这样，平台相关模型这一步可以说是被跳过了，您可以直接从高度抽象的PIM生成源代码。您将继续在MDA-light的基础上进行真正意义的编程：您必须在源代码，而不是UML，编写细致的应用逻辑。

使用MDA的前提

• 业界(甚至是整个世界)一个被广泛接受的事实是：只有变化是永恒的。技术永远在革新。这在中间件领域尤其明显，当然还有数据库技术，操作系统，甚至是编程语言都经常变化。这些技术明显比应用领域的基本概念要变化的快。
• 如果您在某一特定的应用领域工作，在这个领域中的项目都具有一定的相似性。整个应用程序族或者不同的项目都属于同一个应用领域，那么，MDA或者生成流程将特别适合于您
  。

MDA的优点

• 您对建模的投资将更加持久的有效--远长于您目前实现它所应用的技术。这将更有利于保护您的投资。
• 您具有了技术上的灵活性。
• 您将不再受技术或应用所具有的不同变化周期的影响--在MDA的帮助下，您可以中立的保持两方面的多样性。

MDA的缺点

• MDA意味着更多的"组装"而不是"开发"--在为一个应用建立PIM的时候，您基本上没有技术上的周旋空间。这对于今天的很多开发人员来说，还是难以想象的。
• 软件开发的创造性在一定程度上减弱了。开发人员常常觉得，就一种新技术展开争论，在技术的前沿工作，是十分吸引人的。可是在MDA流程下，大量的工作是建立模型，这和具体的技术相距甚远，但符合OMG的建议。
• 潜在的不成熟性。UML2.0还在幼年时代。MDA工具出现的时间也相对很短。这里还隐藏了很多风险。

MDA流程和生成开发中有待解决的问题

• 数据和应用程序的移植：目前在商业领域经常需要面对的问题是，大量的数据和应用程序如何向新的，MDA为基础的系统中移植。纯粹的MDA流程将把数据模型和数据库表结构看成是技术细节。它们不应该对平台无关模型(PIM)层产生任何影响--那么，您的MDA工具或生成器也负责生成数据库脚本吗？
• 软件维护：编制不同的发行版本，补丁或者升级，是对目前正在运行的程序进行维护的重要组成部分。MDA怎么处理这些问题呢？每次进行一次全新的安装？
• 投资报酬率(Return-on-Investment)：从什么样的环境和系统开始计算？从应用MDA的第二个项目？还是从第五个开始？
• 购买软件架构还是自主开发？
• 生成器和相关工具造成了对其生产商的依赖--这种对生产商的依赖是我们以往一直极力避免的。
• 企业应用整合(EAI)：高度的抽象，听起来不错--但是对于已经在运转的应用系统，怎么得到这种抽象呢？

您可以看到--潜在很多实际问题（其回答都具有重要的意义）。这些问题正是我们创立openMDA的原因：在很多项目当中，某些以上的问题已经得到了实验性的回答，您（和我们）都将从中获益！

二、MDA的软件开发周期

在MDA中软件开发过程是由软件系统的建模行为驱动的。下面是MDA的软件开发周期：

MDA生命周期和传统生命周期没有大的不同，主要的区别在于开发过程创建的工件，包括PIM（Platform Independent Model，平台无关模型）、PSM（Platform specific Model，平台相关模型）和代码。PIM是具有高抽象层次、独立任何实现技术的模型。PIM被转换为一个或多个PSM。PSM是为某种特定实现技术量身定做。例如，EJB PSM是用EJB结构表达的系统模型。开发的最后一步是把每个PSM变化为代码， PSM同应用技术密切相关。传统的开发过程从模型到模型的变换，或者从模型到代码的变换是手工完成的。但是MDA的变换都是由工具自动完成的。从PIM到PSM，再从PSM到代码都可以由工具实现。PIM, PSM,和Code 模型被作为软件开发生命周期中的设计工件，在传统的开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不同的视角来看待我们的系统，将高层次的PIM 转换到PSM 的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构，而不会被具体的实现技术所“污染”，同时对于复杂系统，也减少了开发人员的工作量。

MDA的出现，为提高软件开发效率，增强软件的可移植性、协同工作能力和可维护性，以及文档编制的便利性指明了解决之道。MDA被面向对象技术界预言为未来两年里最重要的方法学。当今建模的主要问题在于，对于很多企业来说它只是纸面上的练习。这就造成了模型和代码不同步的问题，代码会被不断修改，而模型不会被更新，这样模型就失去了意义。弥补建模和开发之间的鸿沟的关键就在于将建模变为开发的一个必不可少的部分。MDA 是模型驱动开发的框架，MDA 的愿景是定义一种描述和创建系统的新的途径。MDA 使得UML 的用途走得更远，而不仅仅是美丽的图画。很多专家预言MDA 有可能会带领我们进入软件开发的另一个黄金时代。

三、MDA框架

MDA 将软件系统的模型分离为平台无关模型PIM 和特定平台模型PSM，同时又能通过转换规则将它们统一起来，以这样的方式试图去摆脱需求变更所带来的困境。平台无关模型PIM 是对系统高层次的抽象，其中不包括任何与实现技术相关的信息；特定平台模型PSM是特定平台相关的模型。在MDA 框架中，首先使用平台无关的建模语言来搭建平台无关的模型PIM，然后根据特定平台和实现语言的映射规则，将PIM 转换以生成平台相关的模型PSM，最终生成应用程序代码和测试框架。

MDA框架的“建筑材料”包括：高层次模型；一种或多种标准、精确定义的语言，用来编写高层次模型；如何把PIM变换到PSM的定义；编写这些定义的语言，这种语言能够被变换工具执行；能够执行变换定义的工具；能够执行PSM到代码的变换工具。

上图是MDA的框架，它的主要元素有模型、PIM、PSM、语言、变换、变换定义、以及变换工具。MDA 是一个开放的，中立于软件供应商的架构，它广阔地支持不同的应用领域和技术平台，能够成为应用领域和具体技术平台之间的杠杆。在MDA 开发途径中，PIM 代表对需求的建模，PSM 代表应用具体技术后的模型，这使得MDA 成为需求和技术之间的杠杆；它们各自的改变都可以是相互独立的，不会造成商业逻辑和实现技术的紧密藕合，同时MDA 又可以通过转换来弥补它们之间的鸿沟，从而保护我们的投资。MDA 开发途径使得我们的系统能够灵活地被实现、集成、维护和测试，系统的轻便性、互操作性和可重用性都是可以长期保持的，能够应对未来的变化。

四、MDA的现状

MDA 还处在一个发展的过程中，MDA还在不断的演进。虽然MDA正朝气蓬勃地走来，但是人们也能看出它所存在的问题。MDA最大的好处就是业务模型的持久价值，但是付出的代价是增加了抽象层，而目前看来，层之间的转换并不是我们所期待的那样顺畅，至少，从PIM到PSM，从PSM到代码，这个实现的过程要远比从3GL生成机器代码来得困难。在建模技术方面，UML正在暴露其固有的缺陷，它需要扩展更多的机制来支持精确建模和分析模型，虽然目前OCL为精确建模提供了一定的支持，但是这种支持距离可执行模型的理想还很遥远。回顾MDA的历史，我们可以看出UML的巨大成功为MDA的产生奠定了坚实的基础，同时也感觉到：在由软件工艺到软件工程的漫漫长路中，MDA只不过是向前迈进了一小步，但却给整个软件业掀起了一场波澜，它在模型定义、开发过程等诸多方面都将对未来IT技术产生深远的影响。

目前在MDA开发工具市场上的情形是：由于从PIM 到PSM转换方法的标准化尚未完成，IBM、Borland等大型厂商大都持谨慎态度，虽然也纷纷在他们的开发工具中提供部分的MDA功能，但并没有完全遵循OMG定义的MDA规范。虽然如此，IBM除了在Rational中增加MDA功能之外，在开源项目Eclipse中，也提出了EMF（Eclipse Modeling Framework）这一创新的MDA代码生成系统项目，由此可见IBM对MDA这一发展中的技术的重视程度。Borland公司宣称他们也在关注MDA技术，并且准备在Together中配置基于MDA的模型自动生成功能。相对于业界大厂的冷静和矜持，一些中小厂商反而特别活跃，像Interactive Objects公司著名的ArcStyler、Compuware公司著名的OptimalJ，还有开放源码的AndroMDA等遵循OMG标准规范的MDA工具已在一些项目中得到了广泛的运用，并取得了显著的成效。

五、MDA的相关标准

为了实现MDA这一宏大构想，OMG制定了一系列的标准：

UML：UML被MDA用来描述各种模型。它并不是为MDA而生，但是作为目前最为风行的建模语言，UML已经占据了全球建模语言领域90％的市场份额，成为了建模语言事实上的标准，因此OMG将它作为MDA技术的基础是自然而然的明智选择。它是MDA的基础，也是MDA最有力的武器。

MOF：MOF（Meta Object Facility 元对象机制）是比UML更高层次的抽象，它的目的是为了描述UML的扩展或者其它未来可能出现的类UML的建模语言。虽然MOF也不是为MDA而生的，但是我们可以体味到OMG的工程师们良苦的用心和长远的目光。

XMI：XMI（XML-based metadata Interchange）是基于XML的元数据交换。它通过标准化的XML文档格式和DTDs（Document Type Definitions）为各种模型定义了一种基于XML的数据交换格式。这使得作为最终产品的模型可以在各种不同的工具中传递，这一点是非常重要的，它保证了MDA不会在打破了一种束缚之后再被加上一层新的束缚。

CWM：CWM（Common Warehouse Metamodel 公共仓库元模型）提供了一种数据格式变换的手段，在任意级别的模型上都可以使用CWM来描述两种数据模型之间的映射规则，比如将数据实体从关系数据库变换为XML格式。在MOF的框架下，CWM使得通用的数据模型变换引擎成为可能。

在OMG的蓝图中，UML、MOF、XMI、CWM等一系列标准分别解决了MDA的模型建立、模型扩展、模型交换、模型变换这几个方面的问题。OMG试图通过标准化的定义，扩大MDA的应用范围。同时通过这样一个可扩展的建模语言环境，IT厂商可以自由实现自己的建模语言，以及语言到可执行代码的映射，然而不管怎么样，都必须处于OMG的标准化框架之下。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号