模型驱动架构MDA浅述

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

袁峰

2007年7月10日

前言

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

在《应用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层不同元模型之间的交互性。