模型驱动架构（MDA，Model Driven Architecture）浅述

来源：互联网发布：中国乐队那么少知乎编辑：程序博客网时间：2024/05/19 22:46

前言

西西弗斯是古希腊神话中的科林斯国王，他被罚将一块巨石推到山上，但无论西西弗斯如何努力，每次石头到达山顶之前都不可避免地滚下来，周而复始，永无休止。

在《应用MDA》一书中，作者Frankel将IT人比作现代版的西西弗斯，面对日新月异层出不穷的技术平台，不可避免地不断重复一些工作。理想的MDAer，试图阻止这一悲剧的继续发生。今天，我们通过分析MDA的概念，了解其内涵，看看MDA是否有希望完成这个艰巨的任务。

定义

MDA是由OMG（Object Management Group，国际对象管理集团）[1]于2001年提出来的。其核心思想是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型（PIM，Platform Independent Model），然后针对不同实现技术制定多个转换规则，通过这些转换规则及辅助工具将 PIM 转换成与具体实现技术相关的平台相关模型（PSM，Platform Specific Model），最后将经过充实的 PSM 转换成代码。通过PIM和PSM，MDA的目的是分离业务建模与底层平台技术，以保护建模的成果不受技术变迁的影响。

图1 MDA结构示意图 [1]

图1为MDA的结构示意图。最内环是MDA的核心技术：MOF（Meta Object Facility，元对象设施）、CWM（Common Warehouse Metamodel，公共数据仓库元模型）和UML。MDA的主要工作就是要把基于这些技术建立的PIM转换到不同的中间件平台上，得到对应的PSM。中间环上给出的是目前主要针对的实现平台：CORBA、XML、JAVA、Web Services和.NET。显然，随着技术的发展，这个列表将不断扩充。最外环是MDA提供的公共服务如事务（Transactions）等，向外发散的箭头是指MDA在不同垂直领域的应用，如电子商务、电信和制造业等。

在OMG的MDA首页，图1的右边是OMG给出的一段解释，这段解释从2001年放上去N年不变，堪称化石:D，这次为了这篇文章，我上去看了看，呵呵，措辞有点小变化，具体就不多说了，翻译如下：

MDA提供了一个中立于各开发商的开放的方法，以应对业务和技术变化带来的挑战。基于OMG制定的各项标准，MDA将业务和应用逻辑与底层平台技术分离开来。通过使用UML以及其他的OMG建模标准，来表达应用程序或者集成系统的业务功能和行为，得到的平台无关模型可以通过MDA实现到各种平台上的，如Web Services、.NET、CORBA、J2EE等。这些平台无关模型将应用的业务功能与行为同实现它们的技术特定的代码分离开来。随技术一起的，是为支持跨越不同平台的交互性而带来的无情的繁杂循环，MDA将应用的核心从他们的魔爪中保护出来。（在MDA的工作方式下，）不管应用了哪种具体的技术平台，系统的业务部分和技术部分都可以各自演进（而互不影响）-业务逻辑随业务需求的变化而改变，如果业务有需要的话，技术部分也可以随时享受到新的技术发展带来的好处。[1]

可以注意到，OMG强调MDA必须基于OMG的各项标准。而软件业发展这么多年，太多的故事表明，成功的标准多半是顺其自然产生的，如UML，刻意而为的理想主义者的标准，在商业利益和其他各种因素的作用下，往往是困难重重。

近年来，MDA在工业界的发展非常迅速，诞生了很多优秀的开源和商业工具。软件巨头微软和IBM也都加入了这个战场，但是，这其中大多数的工具都并没有严格遵循OMG的标准，最典型的就是微软的VSTS了，难道说它们都不是MDA的工具和应用了？

在我的blog：“概念之争：什么是MDA？”[3]中，我简单地分为广义的MDA和狭义的MDA。对某种工具或者方法，不论是否严格遵循了OMG的各项标准，只要实现了系统业务逻辑和实现技术的分离，我们都认为它是支持MDA的，比如VSTS和Rational Rose[2]。而相反，狭义MDA则不仅看效果，还要看手段，必须遵循OMG的MDA的模型组织和元建模、建模、管理和执行的一系列标准的，才可以说是支持MDA的。显然，在这种定义下，VSTS并不是一个MDA工具。

这篇文章中，我们还就这个话题进行深入一些的阐述。当然了，概念之争没有什么太大的意义，我们只是借此机会将MDA的相关概念弄弄清楚。

狭义MDA

狭义的MDA者是严格的标准主义者，他们希望用一套基于一致语义基础的统一的元模型/模型管理框架将模型管理起来，并应用基于这个一致语义基础的各种标准来实现对模型的建模、元建模、转换等各种操作。

这个说法挺拗口的，“基于一致语义基础”，我举个例子，比如在UML之前，有几十种不同的面向对象建模语言，不同的语言对相同的概念有不同的叫法，例如现在UML中的类的操作，曾经被叫做“责任”、“函数”、“服务”和“方法”。这样，假设有两种建模语言aML和bML，基于aML建模得到的系统模型和基于bML建模得到的模型，相互之间用的不是一种语言，不能相互理解，很难交互。需要一个翻译，这样往往带来额外的开销和效率的损失。而有了UML这个统一的建模语言之后，这些问题就迎刃而解了。

在MDA的架构中，UML只是“unified modeling language”，是应用于面向对象设计和开发领域的建模语言，而不是“universal modeling language”，不是万能的建模语言。比如数据仓库、软件过程管理等不同的领域，都各自有自己特定的术语，比如系统设计人员，满口说的是“类”、“接口”、 “方法”、“关联”，软件过程建模人员满口说的是“角色”、“活动”和“工作产品”、“文档”，为了表达的清晰方便，OMG为不同的领域定义各自的领域特定语言，例如，UML应用于OO设计与开发，给系统设计人员用；而为软件过程建模人员，OMG定义了SPEM（Software Process Engineering Metamodel），其中定义了软件过程建模需要用到的各种抽象概念和关系结构。

但是，这些不同的领域建模语言之间也有交互的需求，例如UML模型中的一个构件，可能对应于SPEM模型中的一个工作产品。为了保证不同领域的模型之间的交互，这些不同的领域建模语言也需要一个“一致的语义基础”。这也正是MDA的核心，OMG为此给出的答案是MOF。

图2. MDA的模型和标准

如图2所示，MDA中将模型和元模型分为四层，其中：

l M0层是实例层，这一层是M1层模型的实例化。例如，对应UML模型的具体的一个程序。

l M1层是模型层，是建模人员通常所面对的模型，例如图中的UML模型，是分析和设计，包括开发人员最为熟悉不过的了。

l M2层称为元模型层，其中对应的是M1层模型的元模型，如UML和SPEM等。M2层元模型中提取了不同领域的抽象概念和关系结构，为M1层的建模提供了建模符号。也即，M2层提供对应不同领域的领域建模语言。

l M3层是元元模型层，MOF就位于这一层。MOF提供了定义M2层元模型所需要的更抽象一级的建模支持。MOF是M2层所有元模型的元模型，同时，它也是自描述的，MOF可以描述MOF元模型自身。注意，在MDA框架中，M3层只有MOF这一个模型，它是MDA中最基础和核心的标准，它为MDA框架中的所有模型/元模型提供了统一的语义基础，使得基于MOF的统一的模型操作成为可能。

如上所说，MOF解决了M2层不同元模型之间的交互性。

其中重要的一点是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