模型驱动架构MDA浅述

其中重要的一点是MOF支持自省（introspection）机制，在MOF中，定义了操作基于MOF的各级模型和元模型的统一的反射接口如RefBaseObject, RefObject,RefAssociation, RefPackage[3]。

l  Reflective::RefBaseObject   //获取所有的MOF对象

l  Reflective::RefObject       //获取所有对象（对应MOF中classifier的对象）

l  Reflective::RefAssociation   //获取所有Association对象

l  Reflective::RefPackage      //获取所有Package对象

通过这些接口，遵循MOF的程序实现可以在不了解一个对象接口的情况下使用这个对象，即，可以遍历各层的对象结构，找到需要的对象并进行相关操作。例如创建、更新、访问和调用M1层对象实例的操作。

在实际使用中，需要使用编程语言来实现这些接口。为利用标准化的好处，需要定义从MOF到这些（MDA之外的）编程语言之间的映射。例如，定义Java中实现RefObject( ) 接口的规格，这样可以保证一个Java的MOF实现可以被其它用户统一地使用。如图2右边部分所示，OMG定义了从MOF到Java、XML、IDL等的映射。其中最早定义的是从MOF到IDL的映射。到XML的映射就是XMI（XML Metadata Interchange）标准；到Java的映射就是JMI（Java Metadata Interface）；正在制定中或即将制定的还有到WSDL、.NET的映射。目前，XMI已经广泛应用于各UML建模工具中，用于存储模型并在不同工具之间导入导出；JMI也广泛应用各种基于Java的MDA工具中，例如AndroMDA中就用了Sun的JMI实现-MDR。

除了图2中出现的MOF、JMI和XMI之外，MDA中还有两个重要的标准需要提一下，那就是QVT和OCL。

l  QVT（Query/View/Transformation）：模型转换标准，为基于MOF的元模型/模型之间的转换提供标准的转换规则描述语言；

l  OCL（Object Constraint Language）：对象约束语言，用于配合UML和其它M2层元模型，精确地描述模型语义。

标准化的好处毋庸置疑，基于这些标准，工具厂商可以开发自动化的工具。理想情况下，开发人员只需关注于业务建模，开发PIM。从PIM如何得到最后面向具体技术平台的可执行的应用程序，都由自动化的MDA工具来解决了。

怎么样，是不是很理想化？听上去似乎是UML虚拟机一样的玩意，似乎是可以解决软件危机的银弹了。但事实上，现实总是残酷的，首先，将开发工具从高级语言变为抽象层次更高一些的建模语言，可以起到一定的作用，但还是不能解决软件开发的根本复杂性。其次，就是目前这样一个理想化的MDA架构和相关标准，也是千呼万唤出不来，出来也还要反复改。例如，MDA中重要的QVT标准，从2002年发布RFP（Request for Proposal）至今，还没有第一版的标准出来。

广义MDA

实现理想框架的复杂性和难度，对OMG日渐官僚的不耐、以及更重要的商业利益和其他各种因素合在一起，促使软件开发商们纷纷踏上了其他的探索之路。

不管白猫黑猫，抓到老鼠就是好猫。对软件开发者以及各种涉众而言，只要实现了业务逻辑和底层技术平台的分离，能够保证当年辛苦辛苦建模的成果不随着技术平台的变化而像西西弗斯推石头上山那样一遍一遍不可避免地重来，它就是MDA（其实不叫MDA也没啥:D）。

图3 基于MDA的开发过程

如图3所示，对应传统的需求－分析－设计－开发－测试－交付过程，基于MDA的开发过程由模型和模型之间的转换组成。最终的应用程序也可看做模型，它是对应最终实现平台（如机器码）的PSM。在MDA开发过程中，按照时间顺序，首先由需求人员建模得到PIM（有些地方将完全不包含技术设计的这个模型称为CIM（Computation Independent Metamodel，计算无关模型），我们也将它看作一种PIM），在需求分析阶段都可对PIM进行精化；然后在对应传统开发的设计阶段，进行PIM->PSM模型转换，最后是从PSM到最终程序的转换，对应为传统开发的开发编码阶段。

为支持以上过程，需要有些人做一些相关的准备工作，例如，在进行领域建模时，需要有对应的领域元模型，用以作为方便的建模语言。在进行PIM->PSM的转换时，自动化工具需要根据转换规则来进行，而转换规则需要有人来事先提供。这些-元模型和转换规则-都是可以一次写好，重复使用的。

在微软的VSTS中，提供了定义领域特定语言DSL（Domain Specific Language），也就是我们上面所说的领域元模型，的方便的环境，并支持从基于DSL的模型到程序代码的生成以及双向工程。微软是典型的背叛标准者，把MDA的思想全盘接受，换个名字，然后决然抛弃了MDA的核心标准UML和MOF J。同时，微软又是绝对的现实主义者，他从切实提高开发效率出发，提供至少在目前阶段更容易被开发者所接受的MDA开发支持。我认为，从这个意义上说，VSTS是广义的MDA工具。

其他很多工具，由于商业宣传等因素，只要和模型转换、代码生成等挂上钩的，往往也声称自己是MDA工具。这些都可以理解，也没有必要较真。按照上文我们分析的，只要实现或者部分实现了业务逻辑和技术细节的分离，都可以说是广义的MDA工具，比如基于Velocity面向特定平台如J2EE的代码生成工具XDoclet、Middlegen等。

结束语

Brooks在人月神话中提到，软件开发问题的原因在于软件的根本困难：概念结构的复杂性、一致性、可变性和不可预见性，因此没有可以彻底解决问题的“银弹”。不管是狭义的MDA还是广义的MDA，都只能帮助开发人员降低开发时所面对的复杂度，并不能解决根本的问题。回到文章开始提到的问题，MDA可能难以解救西西弗斯，但是，我们相信它是向着这个方向的努力，如果MDA可以给软件业的西西弗斯们送个千斤顶，让大家喘口气儿，也很不错啊 J

最后，给大家推荐几个链接：

1.       www. Modelbased.net        上面给出了MDA等各种工具的列表介绍，还经常更新。

2.       yuandafeng.googlepages.com   我试图开始整理的一个MDA资源页面。

其他我想要推荐的链接，在2上面也可以看到了。

参考文献

[1]       http://www.omg.org/mda/

[2]       模型驱动架构MDA介绍，袁峰，非程序员，总第32期，

[3]       http://blog.csdn.net/yuandafeng/archive/2004/12/13/215191.aspx

[4]       http://www.omg.org/technology/documents/modeling_spec_catalog.htm

[1] [2]

责任编辑 webmaster

相关链接