MDA：一场软件开发方式的革命，还是Case Tools老瓶中装的新醋？
最近看了Martin Fowler的Weblog上一篇有关MDA的短文(ModelDrivenArchitecture――模型驱动架构)。在这篇Weblog中，Martin Fowler认为对MDA目前存在两种看法：一部分人认为MDA是软件开发自汇编语言到高级语言之后又一次革命性的“突变”；另一部分人则认为MDA不过是已有的Case Tools的“昙花一现”。究竟MDA是一场软件开发方式的革命，还是已有的Case Tools的老瓶中装的新醋呢？这个问题引起了一场争论，本文试图从回溯MDA的历史及其由来，以及目前的一些现状来进一步探究一下MDA这个目前还在发展中的技术。
MDA的历史及其由来
MDA（Model Driven Architecture，模型驱动架构）是OMG目前推出的全新的软件开发框架，这一框架的推出已给整个软件业带来了一场“地震”，或许把J2EE和.NET等底层平台技术的快速发展比作“地震”更合适一些，MDA更像是一种“防震”设施，它把我们从底层平台的“剧烈振动”中安全的隔离出来，保护了我们业已建立的“业务逻辑大厦”的安然无恙，使我们在面对一轮一轮因平台技术剧变而产生的冲击波时能够泰然处之。它必将在诸多方面对软件技术的未来产生深远的影响，然而它的“源”在哪里呢？
过去的十几年里，OMG标准化了ORB（Object Request Broker）和一系列的对象服务框架（即所谓的CORBA架构）。从1995年起，OMG开始非正式的采用与工业相关的一些技术规范，并于96、97年进行了正式化工作。与此同时，在Mary Loomis的领导下进一步扩大了工作范围使之包含对象建模，这就导致了UML建模语言的产生，并随之于2001年OMG组织进一步采纳了另外一个框架——MDA。当然MDA不像CORBA框架那样是用于实现分布式对象系统，而是一种在软件开发中使用模型的方式。回顾MDA的历史，我们可以看出UML的巨大成功为MDA的产生奠定了坚实的基础，同时也感觉到：在由软件工艺到软件工程的漫漫长路中，MDA只不过是向前迈进了一小步，但却给整个软件业掀起了一场波澜，它在模型定义、开发过程等诸多方面都将对未来IT技术产生深远的影响。
MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，MDA提供了一种途径（通过相关的工具）来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。MDA的三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性。
什么是MDA？
什么是MDA呢？简而言之，就是一个围绕支持模型驱动开发过程的一系列标准的框架，这些标准包括：统一建模语言UML（Unified Modeling Language）、元对象机制MOF（Meta Object Facility）、XML元数据交换XMI（XML Metadata Interchange）、公共数据仓库元模型CWM（Common Warehouse Metamodel）等。在David Frankel的《应用MDA》一书中是这样定义的：MDA就是把建模语言当编程语言来用，而不只是当作设计语言来用。用建模语言编程可以提高生产率，改善质量，并使软件产品生存期更长。
MDA将软件系统的模型分为：平台无关模型PIM（Platform Independent Model）和平台相关模型PSM（Platform Specific Model），并且他们之间通过相应的转换规则联系起来。PIM是一个不考虑具体实现技术的纯分析模型，在这个层次上PIM是可重用的，通过PIM进一步提高了软件系统的抽象层次，同时也屏蔽了由于底层平台技术的变化所带来的冲击；PSM顾名思义是与特定的平台系统相关的模型，它基于某一个特定的实现技术，比如J2EE。在MDA方式的开发过程中，首先使用平台无关的建模语言构建PIM，然后根据具体的实现平台和语言转换规则，将PIM转换成与特定平台相关的PSMs，最后由代码生成工具生成最终的应用程序代码和测试框架。
MDA主要包括两个方面的内容：
1、统一的管理元数据的框架
2、可执行的模型和代码自动生成
在进一步说明之前先解释一下几个相关的重要概念：
元数据（Metadata）：用来表示模型的数据。例如：一个UML模型；一个在IDL中表达的CORBA对象模型；一个用CWM表达的关系数据库模式等等。
元模型（Metamodel）：所谓元模型就是模型的模型。
因为MOF是整个MDA架构体系的基础，这里有必要解释一下什么是MOF？看看David Frankel是怎么说的吧：“MOF（元对象设施）是UML的姊妹标准，它从本质上来说就是UML类建模结构的一个约束子集，你可以使用它来建立一种建模语言的模型。MDA可以处理由风格炯异的语言所描述的模型，只要有了这种语言的MOF元模型。”如果把David Frankel的表述说的更直白一些就是：MOF就是一个定义建模语言的建模语言。MOF按照不同的目的，分别定义了不同的建模语言标准规范。例如，针对一般的OO建模目的，定义了UML；针对交换业务数据目的，定义了CWM等等。
1．统一的管理元数据的框架
为了统一分布式异构系统之间元数据的共享问题，MDA的一个主要目标是建立一个统一的管理元数据的框架。MDA是通过基于MOF的四层元模型框架结构来管理元数据的，如图一所示：
图一
其中：
M3层：元元模型层，即定义元模型的元模型，在这一层上有MOF。
M2层：元模型层，由MOF定义的用于不同领域的元模型，例如：UML、CWM、XMI等。
M1层：模型层，这一层由M2层提供的元模型进行具体建模所得到的模型实例。例如：对一个具体的业务实体的建模等等。
M0层：实现层，这一层是对应于M1层所创建的模型在特定平台上的具体实现，也即我们最终得到的可执行的应用系统。
MDA通过这一元数据管理框架来达到元数据的定义、交换、存储和共享，从而在更高的抽象层次上实现了异构系统之间元数据的共享和交换，实现了异构系统之间的互操作。
2．可执行的模型和代码自动生成
力图使模型成为可执行的，首先必须使建模语言具有精确定义的语义。这里所谓的语义指的是软件模型在运行时的“解释”，类似于例如：哪一个对象被创建？何时被创建以及创建之后做什么等等。需要注意的是：这里的“精确”并没有暗含“详细”的意思，它只是说明了模型只有唯一一个可能的“解释”。
什么是代码自动生成呢？简单说就是从模型自动生成语义上等价的程序代码，当然MDA工具也提供了手工修改所生成的代码的能力，但这里需要注意的是：1.所生成的代码中通常会包含一些与模型结构方面紧密相关的部分“不可触动”的代码；2.这种修改有可能意味着模型不能被重新创建。虽然有以上两点顾忌，但是出于对生成的代码效率等诸多方面因素的考虑，手工修改所生成代码的能力还是必需的。有关代码的自动生成还包括在模型中插入手写代码的能力和最优化的增量生成（即只有模型中发生变化的部分才重新生成代码）等等多个方面的内容。
MDA是一次软件抽象层次的提高
OMG推出MDA的宗旨是试图把软件开发行为提升到更高一级的抽象级别――模型级别，而把针对特定平台的编码工作交由机器来自动生成，从而达到分离问题域的业务逻辑和底层的具体实现平台的目的。那么，我们先来看看什么是软件抽象层次？
Grady Booch是这样定义软件抽象层次的：“那就是Java、C＃和C++所试图要达到的一些方面，每一个方面都会使我们更加远离所依赖的硬件并且实际上允许我们表达一些事情，在表述这些事情的过程中，我们通过数量繁多的步骤扩展这些事情直到底层的硬件。这样就可以使我们更近似的以人的角度而不是从机器的角度来寻求问题域的解。” Grady Booch的定义虽然有点晦涩难懂，但却告诉我们一个事实，要提高抽象层次就必须分离问题域的业务逻辑和底层的具体实现平台，平台无关模型PIM正是向这个方向迈进了一大步。
MDA和Case Tools的差异
让我们回到本文开始处提到的争论。关于MDA和Case Tools的差异，Frankel是这样描述的：MDA的本质不是代码生成，尽管代码生成被认为是主要成就。MDA也可以通过构造能直接执行模型的虚拟机来实现。
MDA和Case Tools主要存在两方面的差异。首先，在Case Tools时代，我们需要为系统实现框架和业务流程两方面建模，而目前的情况是已有许多成熟的流行实现框架，我们只需要集中精力于我们的业务流程即可，不必关心系统实现框架。其次，从PIM到PSM的转换已有许多相关的成熟模式可以加以利用，这些模式可以把一些通常的业务模型转化为特定平台上的一些成熟的实现框架。在Case Tools时代模式概念还不成熟并且也没有被广泛理解，使用Case Tools我们不仅需要建模我们的问题域，还必须创建一些实现模式，这使得整个系统的抽象过程过于复杂。而MDA则是建筑在成熟的实现模式之上的产物，它借助于成功的UML技术和成熟的模式技术简化了整个系统的抽象过程，提高了抽象层次。
MDA不是“银弹”，但极大的提高了软件开发效率
开发出著名的MDA开发工具OptimalJ的Compuware公司曾经委托The Middleware公司研究过一个案例：两个团队开发同一个应用，其中一个使用MDA，另一个不使用。这个案例也可以看作是以模型为中心的开发方式和以代码为中心的开发方式的对比。为了便于公平的比较，案例选择的是众所周知的J2EE PetStore应用程序，它是一个简单的基于Web的J2EE电子商务系统，所包含的功能基本可以代表当今的主流应用。两个团队的最终结果如下所示：
每个团队最终使用的开发小时数统计结果
团队
初始估算小时数
实际的小时数
传统团队
499
507.5
MDA团队
442
330
结果是惊人的，从上图可见，MDA团队在效率上占有绝对优势，效率提高了几乎30％多，其中还没有计算因是第一次使用MDA方法所必须的熟悉和学习工具时间，可见使用MDA方法可以极大地提高软件开发效率，这一点是毋庸置疑的。
MDA工具的现状
目前在MDA开发工具市场上的情形是：由于从PIM 到PSM转换方法的标准化尚未完成，IBM、Borland等大型厂商大都持谨慎态度，虽然也纷纷在他们的开发工具中提供部分的MDA功能，但并没有完全遵循OMG定义的MDA规范。虽然如此，IBM除了在Rational中增加MDA功能之外（在XDE、Rose等工具中都提供了MDA功能），在所鼎力倡导的开源项目Eclipse中，也提出了EMF（Eclipse Modeling Framework）这一创新的MDA代码生成系统项目，由此可见IBM对MDA这一发展中的技术的重视程度。Borland公司宣称他们也在关注MDA技术，并且准备在Together中配置基于MDA的模型自动生成功能。相对于业界大厂的冷静和矜持，一些中小厂商反而特别活跃，像Interactive Objects公司著名的ArcStyler、Compuware公司著名的OptimalJ，还有开放源码的AndroMDA等遵循OMG标准规范的MDA工具已在一些项目中得到了广泛的运用，并取得了显著的成效。
结束语
MDA并不仅仅是“UML+代码生成”，它带给我们更多的是一种思考问题的方式和观念的变化。它帮助我们更多的以“用例”的角度考虑我们所面临的问题，它构筑于UML建模语言巨大成功的基础之上。虽然Martin Fowler本人更倾向于后一种观点，但毋庸置疑的是模型驱动开发确实正在起作用，并必将改变我们开发系统的方式。我们以David Frankel的话作为本文的结束语：“我们基本的MDA的目标已经被使用了很多年了——在‘MDA’这个词出现之前——应用于嵌入式和实时系统。基于Schlaer-Mellor的系统被用于为所有种类的电子设备生成嵌入式代码，从抽象模型产生数百万行C/C++代码来完成复杂的电信交换。在某些方面，我可以说比起企业应用系统，MDA在这种系统上有更成功的表现。”
既然在嵌入式和实时系统已取得成功，在企业级开发方面也必将成功，我们将拭目以待。
本文地址：http://com.8s8s.com/it/it37266.htm