前言

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

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

antswallow

模型驱动架构（MDA，Model Driven Architecture）浅述相关推荐

转：解救西西弗斯- 模型驱动架构（MDA，Model Driven Architecture）浅述
原文: 解救西西弗斯- 模型驱动架构(MDA,Model Driven Architecture)浅述前言西西弗斯是古希腊神话中的科林斯国王,他被罚将一块巨石推到山上,但无论西西弗斯如何努力,每次 ...
解救西西弗斯- 模型驱动架构（MDA，Model Driven Architecture）浅述
这是应邀发表在<软件世界>2007年7月刊上的一个MDA介绍文章,入门者可以看看 :) ================================================== ...
MDA(模型驱动架构)
https://www.cnblogs.com/hobe/archive/2005/10/21/259583.html 1. 什么是MDA MDA(Model Driven Archi ...
全模型驱动架构（f-MDA）的基本思想
传统MDA实现方案的共同缺陷模型驱动架构(ModelDriven Architecture, MDA)的核心思想是抽象出与实现技术无关.完整描述业务功能的核心平台无关模型( PIM , Platfo ...
解救西西弗斯- 模型驱动架构
前言西西弗斯是古希腊神话中的科林斯国王,他被罚将一块巨石推到山上,但无论西西弗斯如何努力,每次石头到达山顶之前都不可避免地滚下来,周而复始,永无休止. 在<应用MDA>一书中,作者Fra ...
MDA：模型驱动架构简介
MDA:模型驱动架构 2011-04-18 23:30 模型驱动架构(MDA)是一种独立于特定平台和软件供应商的软件体系结构设计和开发方法,它适用于设计.部署.集成等软件开发的整个生命周期. MDA ...
微服务浅述---架构演进
微服务浅述---架构演进提到架构演进,我们很容易想到'单体应用---分布式/SOA---微服务'的演进过程,那么为什么会有这个必然演进?演进的过程中遇到了哪些坑?是怎么解决这些坑的? 为什么会有这个 ...
The Model Driven Software Network
国外的一个模型驱动软件开发的讨论社区,The Model Driven Software Network这个社区讨论的都是模型驱动开发相关的话题,虽然建立不久,但加入的人越来越多,建立群组的是Mark ...
CV学习笔记-浅述CV方向
浅述CV方向一.浅述人工智能的一些术语 1. 人工智能初探人工智能是通过机器来模拟人类认知能力的技术人工智能最核心的能力就是根据给定的输入做出判断或预测关键时间节点:1956年,达特茅斯会议, ...

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

前言

定义

狭义 MDA

广义 MDA

结束语

参考文献

antswallow

模型驱动架构（MDA，Model Driven Architecture）浅述相关推荐

最新文章

热门文章