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

前言

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

在《应用
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

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

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]

OMG

是非营利的国际技术联盟，过去著名的工作成果是
UML

和
CORBA

。

[2]

Rational Rose

是一个
UML

建模工具。但是，举例来说，在使用
UML profile for web application

进行建模的时候，
Rose

内置的转换工具根据用户创建的业务模型生成相应的代码框架，这时候，从某种意义上说，它扮演了
MDA

工具的角色。

[3]

对应
MOF1.3

版本。