MDA Model Driven Architecture 模式驱动开发

模式驱动开发

MDA的流程 MDA的实现主要集中在以下3个步骤：

1 首先，您用UML对您的应用领域进行高度抽象的建模，这个模型和实现它的技术（或者底层技术）完全没有关系。这个模型我们称之为平台无关模型(PIM)。

2 然后，PIM将被转换为一个或多个平台相关模型(PSM)。这个翻译的过程一般是自动实现的。PSM将用一个特定的 实现技术来描述您的系统。它将用到这种技术所提供的种种架构，比如EJB, 数据库模型， COM组件等等。

3 最后，PSM将被翻译成 源代码。因为每个PSM已经完全依靠某种特定的技术，这个步骤一般是比较简单的。

MDA流程中最难的一步，是从PIM生成一个PSM。它要求您对您要应用的基础技术具有丰富且巩固的知识，另一方面，源模型(PIM)必须具备自动生成PSM所要求的足够信息量。

通过模板生成：MDA-light?!

在MDA的实际应用当中，一个较容易的实现是通过模板(我们称之为MDA-light)。这样，平台相关模型这一步可以说是被跳过了，您可以直接从高度抽象的PIM生成 源代码。您将继续在MDA-light的基础上进行真正意义的编程：您必须在 源代码，而不是UML，编写细致的应用逻辑。

使用前提

* 业界(甚至是整个世界)一个被广泛接受的事实是：只有变化是永恒的。技术永远在革新。这在 中间件领域尤其明显，当然还有数据库技术， 操作系统，甚至是编程语言都经常变化。这些技术明显比应用领域的基本概念要变化的快。

* 如果您在某一特定的应用领域工作，在这个领域中的项目都具有一定的相似性。整个 应用程序族或者不同的项目都属于同一个应用领域，那么，MDA或者生成流程将特别适合于您 。

优点

* 您对建模的投资将更加持久的有效--远长于您实现它所应用的技术。这将更有利于保护您的投资。 * 您具有了技术上的灵活性。 * 您将不再受技术或应用所具有的不同变化周期的影响--在MDA的帮助下，您可以中立的保持两方面的多样性。

缺点

* MDA意味着更多的"组装"而不是"开发"--在为一个应用建立PIM的时候，您基本上没有技术上的 周旋空间。这对于今天的很多开发人员来说，还是难以想象的。 * 软件开发的创造性在一定程度上减弱了。开发人员常常觉得，就一种新技术展开争论，在技术的前沿工作，是十分吸引人的。可是在MDA流程下，大量的工作是建立模型，这和具体的技术相距甚远，但符合OMG的建议。 * 潜在的不成熟性。UML2.0还在幼年时代。MDA工具出现的时间也相对很短。这里还隐藏了很多风险。

存在问题

* 数据和 应用程序的移植：在商业领域经常需要面对的问题是，大量的数据和应用程序如何向新的，MDA为基础的系统中移植。纯粹的MDA流程将把数据模型和数据库表结构看成是技术细节。它们不应该对平台无关模型(PIM)层产生任何影响--那么，您的MDA工具或生成器也负责生成 数据库脚本吗？

* 软件维护：编制不同的发行版本， 补丁或者升级，是对目前正在运行的程序进行维护的重要组成部分。MDA怎么处理这些问题呢？每次进行一次全新的安装？

* 投资报酬率(Return-on-Investment)：从什么样的环境和系统开始计算？从应用MDA的第二个项目？还是从第五个开始？

* 购买 软件架构还是自主开发？

* 生成器和相关工具造成了对其生产商的依赖--这种对生产商的依赖是我们以往一直极力避免的。

* 企业应用整合(EAI)：高度的抽象，听起来不错--但是对于已经在运转的应用系统，怎么得到这种抽象呢？

您可以看到--潜在很多实际问题（其回答都具有重要的意义）。这些问题正是我们创立openMDA

多重置换扩增： 能够提供高度均 一完整的全基因组序列， 确保最低的位点扩增误差， 使产物与模板的遗传序列信息保持一致， 是一种真正意义的全基因组扩增方法。

自从2001年MDA被OMG（Object Management Group 国际对象管理集团）提出以后，"随风潜入夜，润物细无声"，未见轰轰烈烈宣传，各大厂商却惊人一致地争相跟进，关于MDA的话题转眼之间在网络上也如火如荼地繁荣起来了。

为了实现MDA这一宏大构想，OMG制定了一系列的标准：

UML：UML被MDA用来描述各种模型。它并不是为MDA而生，但是作为目前最为风行的 建模语言，UML已经占据了全球建模语言领域90%的市场份额，成为了建模语言事实上的标准，因此OMG将它作为MDA技术的基础是自然而然的明智选择。它是MDA的基础，也是MDA最有力的武器。

MOF：MOF（Meta Object Facility 元对象机制）是比UML更高层次的抽象，它的目的是为了描述UML的扩展或者其它未来可能出现的类UML的 建模语言。由此我们可以看到OMG的"野心"，虽然MOF也不是为MDA而生的，但是我们可以体味到OMG的工程师们良苦的用心和长远的目光。

XMI：XMI（XML-based metadata Interchange）是基于XML的元数据交换。它通过标准化的XML文档格式和DTDs（Document Type Definitions）为各种模型定义了一种基于XML的数据交换格式。这使得作为最终产品的模型可以在各种不同的工具中传递，这一点是非常重要的，它保证了MDA不会在打破了一种束缚之后再被加上一层新的束缚。

CWM：CWM（Common Warehouse Metamodel 公共仓库元模型）提供了一种数据格式变换的手段，在任意级别的模型上都可以使用CWM来描述两种数据模型之间的映射规则，比如将数据实体从关系数据库变换为XML格式。在MOF的 框架下，CWM使得通用的数据模型变换引擎成为可能。

在OMG的蓝图中，UML、MOF、XMI、CWM等一系列标准分别解决了MDA的模型建立、模型扩展、模型交换、模型变换这几个方面的问题。OMG试图通过标准化的定义，扩大MDA的应用范围。同时通过这样一个可扩展的 建模语言环境，IT厂商可以自由实现自己的建模语言，以及语言到可执行代码的映射，然而不管怎么样，都必须处于OMG的标准化框架之下。

MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，MDA提供了一种途径（通过相关的工具）来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。MDA的三个主要目标是：通过架构性的分离来实现轻便性、 互操作性和可重用性。

在MDA中软件开发过程是由 软件系统的建模行为驱动的。

MDA生命周期和传统生命周期没有大的不同，主要的区别在于开发过程创建的工件，包括PIM（Platform Independent Model，平台无关模型）、PSM（Platform specific Model，平台相关模型）和代码。PIM是具有高抽象层次、独立任何 实现技术的模型。PIM被转换为一个或多个PSM。PSM是为某种特定 实现技术量身定做。例如，EJB PSM是用EJB结构表达的 系统模型。开发的最后一步是把每个PSM变化为代码， PSM同应用技术密切相关。传统的开发过程从模型到模型的变换，或者从模型到代码的变换是手工完成的。但是MDA的变换都是由工具自动完成的。从PIM到PSM，再从PSM到代码都可以由工具实现。PIM, PSM,和Code 模型被作为软件开发生命周期中的设计工件，在传统的开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不同的视角来看待我们的系统，将高层次的PIM 转换到PSM 的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构，而不会被具体的 实现技术所“污染”，同时对于复杂系统，也减少了开发人员的工作量。

MDA的出现，为提高 软件开发效率，增强软件的可移植性、 协同工作能力和可维护性，以及 文档编制的便利性指明了解决之道。MDA被 面向对象技术界预言为未来两年里最重要的方法学。当今建模的主要问题在于，对于很多企业来说它只是纸面上的练习。这就造成了模型和代码不同步的问题，代码会被不断修改，而模型不会被更新，这样模型就失去了意义。弥补建模和开发之间的鸿沟的关键就在于将建模变为开发的一个必不可少的部分。MDA 是 模型驱动开发的框架，MDA 的愿景是定义一种描述和创建系统的新的途径。MDA 使得UML 的用途走得更远，而不仅仅是美丽的图画。很多专家预言MDA 有可能会带领我们进入 软件开发的另一个黄金时代。