MDA白皮书-模型驱动开发和UML+2.0
基于模型驱动的软件开发方法
模型驱动的软件体系结构
统一建模语言 （Uniform Modeling Language, UML）
•以面向对象图的方式来描述任何类型的系统,具有很宽的 应用领域。 •其中最常用的是建立软件系统的模型,但它同样可以用于 描述非软件领域的系统,如机械系统、企业机构或业务过 程,以及处理复杂数据的信息系统、具有实时要求的工业 系统或工业过程等。 •总之,UML是一个通用的标准建模语言，可以对任何具有 静态结构和动态行为的系统进行建模。
模型驱动的软件体系结构
UML的静态建模机制
•用例图(Use case diagram) •类图(Class diagram) •对象图(Object diagram ) •包(Package) •构件图(Com)
模型驱动的软件体系结构
模型驱动的软件体系结构
模型驱动的软件开发模式
与传统开发模式的不同： •元模型和模型映射技术共享: 元 模 型 和 模 型 映 射 技 术 实际上陷含了特定领域所固有的知识。在同一个领域 的应用中，都可以共享这些元模型和模型映射技术。 •模型重用:软件重用从组件的重用扩展到模型的重用。 这是软件重用的大发展。首先，组件重用有平台的限 制，而模型的重用则脱离了这个限制；其次，模型由 于它的多层次性，使得软件的重用可以在任意一个层 次上，这样就可以最大限度地重用现有成果。
模型驱动的特点:模型的层级性
诺贝尔奖获得者赫伯特 A. 西蒙(Harbert A．Simen)曾论述到 ：“ 要构造一门关于复杂系统的比较正规的理论，有一条 路就是求助于层级理论 …… 我们可以期望，在一个复杂性 必然是从简单性进化而来的世界中，复杂系统是层级结构 的”
系统A 系统B 系统C
…
系统Z
基于构件的软件产品集成开发平台国内外研究现状
国内外研发觉状及进展趋势基于构件的软件开发是幸免重复劳动，提高软件生产效率的软件开发方式，属于“软件复用”的一种实现方式，其起点是应用系统的开发再也不采纳一切“从零开始”的模式，而是以已有的工作为基础，充分利用过去应用系统开发中积存的知识和体会，如需求分析结果、设计方案、源代码、测试打算及测试案例等，从而将开发的重点集中于应用的特有组成成份。
通过软件复用，在应用系统开发中能够充分地利用己有的开发功效，排除包括分析、设计、编码、测试等在内的许多重复劳动，从而提高了软件开发的效率；同时，通过复用高质量的已有开发功效，幸免了从头开发可能引入的错误，从而提高了软件的质量，因此基于构件开发的软件系统强调构件化和体系结构的作用，具有很强的自适应性、互操作性、扩展性和重用性。
最近几年来，构件技术和基于构件的软件开发技术慢慢成为阻碍整个软件产业的关键技术，构件化已经成为软件企业的需求，软件构件市场已现眉目，软件工业化生成模式正在推动软件产业的规模化进展。
支持构件开发和治理和基于构件进行软件开发的标准、基础工具和产品正慢慢完善。
3.1主流软件构件标准的分析比较当前，要紧有以下三种比较有阻碍的软件构件技术标准:OMG 的CORBA、微软公司的COM/DCOM和SUN的EJB（Enterprise Java Bean）。
1) CORBA是公共对象请求代理体系结构(common objectsrequest brokerarchitecture)的缩写，是对象治理组织(OMG-Object Management Group)开发的一套散布式对象技术标准，涉及接口、注册、数据库、通信和犯错处置等方面的问题。
和对象治理体系结构(OMA)概念的其他对象效劳相结合，CORBA成为支持散布式系统中对象技术的中间件设施。
CORBA的对象请求代理(ORB)作为转发消息的中间件，实现了对象间的无缝集成和互操作。
因此，CORBA可作为面向对象的软件构件在运行级上组装的技术基础，从而实现构件的黑盒复用。
模型驱动的体系架构MDA
模型驱动的体系架构MDA模型驱动的体系架构（Model-Driven Architecture，MDA）是一种软件开发方法论，旨在实现使用模型来驱动软件系统设计和开发的过程。
它提供了一种将系统的关注点从实现细节转移到概念模型层面的方法，从而提高了系统的可维护性、可扩展性和可重用性。
MDA的体系架构包括三个核心层次：计算独立（CIM）、平台独立（PIM）和平台相关（PSM）。
2. 平台独立模型（Platform Independent Model，PIM）是MDA的中间层模型，用于描述系统的业务逻辑和功能。
PIM是通过将CIM转化为与具体平台无关的模型，以便能够在不同平台上进行重用和扩展。
PIM通常使用统一建模语言（UML）或其他领域特定语言（DSL）进行描述，包括类图、时序图等。
PIM的设计重点是在保持系统功能的不变的同时，将业务逻辑和实现细节分离。
3. 平台相关模型（Platform Specific Model，PSM）是MDA的底层模型，用于描述系统在具体平台上的实现细节。
PSM是通过将PIM转化为特定平台的模型，以便具体实现系统。
PSM可以是特定编程语言、框架或平台的规范，如Java、NET、Eclipse等。
PSM的设计重点是在满足系统需求的同时，考虑特定平台的约束和限制。
MDA的核心思想是通过模型的转换和转化过程，实现从业务需求到具体实现的自动化生成。
MDA使用模型转换技术将CIM转化为PIM，然后将PIM转化为PSM，最终生成可执行的代码。
MDA的优势在于提高了系统的可维护性和可重用性。
通过将业务逻辑和实现细节分离，在需求变更或平台切换时可以更快地进行适应和修改。
同时，MDA的模型驱动方法使得可以在不同项目间共享和重用已验证的模型和模型库。
然而，MDA也存在一些挑战。
首先，准确和完整地捕捉业务需求和领域知识是一项复杂的任务，需要专业的分析和建模技能。
其次，模型转换过程可能会引入一些不一致和错误，导致最终系统的质量问题。
MDA概述
MDA，可以理解为中国移动手机桌面助理软件，适用于很多手机玩家；也可以理解为模型驱动架构。
它是由OMG定义的一个软件开发框架。
. MDA（MAIL DELIVERY AGENT）从MTA取得邮件并传送至邮件接受者的邮箱。
常见的MDA通常和MUA合二为一.MDA（Mobile Desktop Assitant）是中国移动手机桌面助理的英文缩写，它是中国移动为提高用户服务而推出的一款集短信、彩信、联系人管理、话费查询等功能在内的软件工具。
中国移动手机桌面助理（简称MDA）是中国移动最新推出的一款集短信、彩信、联系人管理、话费查询等强大功能于一体的通讯软件。
提供安全稳定的短信、彩信服务；短信定时发送功能；强大的彩信编辑功能；创意无穷的彩信文字；简约快捷的通讯录管理；方便的用户话费查询等。
手机桌面助理通过个人电脑的优势将您从手机终端解脱出来，您不用费力在手机上一个一个的打字，不用担心手机里的图片无法编辑剪裁，不用再登录网站查话费，一切都由手机桌面助理帮您完成。
中国移动全球通、动感地带和神州行（不包括北京，北京神州行暂不能开通）用户均可注册使用MDA。
MDA客户端软件免费使用，无任何包月费用；·发送短信：按0.10 元/条收费；·接收短信：接收短信免费，该短信的回复方按照移动品牌的短信资费标准收费；·发送普通彩信：按0.50元/条收费（北京、山西、江苏、安徽地区按0.30元/条收费）；·发送福娃彩信：按0.30/条收费。
运行环境：中文Windows2000/Windows2003/WindowsXP2.Model Driven Architecture模型驱动架构自从2001年被OMG（Object Management Group 国际对象管理集团）提出以后，"随风潜入夜，润物细无声"，未见轰轰烈烈宣传，各大厂商却惊人一致地争相跟进，关于MDA 的话题转眼之间在网络上也如火如荼地繁荣起来了。
UML2.0简介
基于MDA与UML扩展的安全软件开发方法
ｐｏ ｅ ｅｖ ｌ ｉ ｆ ｅｍｅｈ ｄ． ｒｖ ｓｔ ａｉ ｔ ｏ ｔｏ ｈ ｄｙ ｈ ｔ
［ ｙ ｗｏ ｄ Ｍｏ ｅ ｉ ｅ ｃ ｉ ｃｕｅＭＤＡ） Ｋｅ ｒ ｓ ｄ ｌＤｒ ｎ Ａｒｈｔ ｔｒ（ ｌ ｖ ｅ ；Ｕｎｔｄ Ｍｏ ｅｉｇ Ｌ ｎ ｕ ｇ （ ｉ ｄ ｌ ａｇ ａ ｅＵＭＬ ；Ｒ ｌ ｂ ｓｄ Ａ ｃｓ ｏ ｔ ｌ ＢＡ ；ｓｃ ｒ ｏｔ ｒｅ ｅ ｎ ） ｏｅ ａｅ ｃｅｓ ｃ ｎｒ （ — ｏ Ｒ Ｃ） ｅｕｅ ｓｆ ｗａ
全软件开发方法——ｓ Ｂ Ａ ｕ ｓ ＭＤ ， ＭＬ。
２ 基于 ＭＤ Ａ与 Ｕ ＭＬ扩展 的安全软件开发方法
２ ＭＤ ． １ Ａ技术与软件安全性分析 ＭＤ Ａ对提高软件 开发的生产率 ， 保障软件 的可移植性和
可扩展性 ，减小重复建模和编码工作有着重要 的意义 。它的 核心是在设计阶段就 已经描述 了系统 ，这样在创建系统 的时 候就大大减少 了错误解释的可能性 。 Ａ 由模型直接生成代 ＭＤ 码 ，减少 了代码 的编写 ，有效地提高 了软件开发的 生产率 ；
ｓ ｃ ｒｔ ｒ ｐ ｒｙ ｍｏ ｅ ｉ ｇ ｗｉ ｅ ｍｅ ｈ ｄ ｏ ＤＡ， ｎ ｅ ｕ ｅ ｓ ｎ ｏｓ ｏ ｔ ｒｄ ｖ ｌ ｐ ｎ ｅ ｏ ． ａ ｐ ｅ ｏ ｂ ａ ｙ ｍａ ａ ｅ ｎ ｙ ｔ ｍ ｅ ｕ ｙｐ ｏ ｅｔ ｄ ｌ ｔ ｔ ｔ ｏ ｆ ｉ ｎ ｈ ｈ Ｍ ａ ｄ ｒ ｄ ｃ ｓｒ ｋ ａ ｄ ｃ ｔ ｆｌ ｅ ｅ ｅ ｏ ｍｅ ｔ ｒ ｄ Ｅｘ ｍ ｌ ｆ ｉ ｒ ｒ ｎ ｇ ｍｅ ｔ ｓｅ ｉ ａ ｐｉ ｌ ｓ
制建立 系统 安全相 关的平台无关模型 ，将软件 的安全性分析提 前到设 计的早期 ；利用 ＭＤ Ａ方法进行 软件安全属性的建模 ，降低后期开发
软件架构师(20)-MDA与可执行UML
**********************************第1章引论*************************************◆模型驱动架构（Model Driven Architecture, MDA）通过下面二种方式改变了软件的重点：模型比代码更有价值—有关业务本质的知识资产被表示为模型，这些模型使得企业能够在适当的时候使用适当的技术平台来实现它。
模型将更精确，而不是高高在上的—所有业务相关的重要的知识都被获以并表达为模型。
模型不会随意分隔分析和设计。
◆当前的软件技术发展水平来看，它有那些多年的使用和考验的关键原则：根据主题（域）的划分，可以产生大的高内聚低耦合的“实质性的”组件。
将平台无关的行为与平台相关的行为分开，通过将“本质”模型和“实现”模型分开可以在一定程度上做到这一点。
基于模式的映射定义使得人们可以从平台无关模型（Platform Inependent Model, PIM）系统化地创建任意平台的平台相关模型。
这些映射既可以手工实现，也可以自动实现。
使用了抽象但语义严格的表示方法以后，xUML能够使模型可以被完整地精确地表达，从而实现可执行化。
这种可执行化的特点充许建模者客观地评价他们所建立的系统的正确性。
◆什么是可执行UML（xUML）?尽管UML规范在MDA过程中是必要的，但它不足以进行可执行建模。
认识到这一点后，UML中又是加入了动作语义进行增强，解决了UML很多歧义的问题，同时也为适当的UML模型元素增强了可执行为定义。
核心UML加上动作语义就称为xUML，和它就足够建立可执行的平台无关模型（Platform Inependent Model, PIM）了。
xUML=UML-语义较弱的元素+精确定义的动作语义。
◆UML与xUML的差别：UML规定了一个图形语言，使得系统可以通过一组不同类型的图式系统化地定义。
但是UML在这此图形的使用方法上很不正规。
MDA论文：基于MDA和UML技术的图书馆管理系统的实现
MDA论文：基于MDA和UML技术的图书馆管理系统的实现【中文摘要】传统的软件开发模式存在许多问题,比如生产效率难以提高、软件移植和互操作困难、维护代价居高不下。
其中OMG提出的模型驱动架构(Model—Driven Arehitecture)就是这种背景下提出的一种新型的软件开发方法。
它为解决各种互不兼容平台和中间件技术在系统集成和互操作方面存在的不足提供了新思路。
MDA的核心工件是模型,投入到MDA横型的设计努力会被多次复用来生成各种组件。
本文的研究是利用MDA和UML技术建立图书馆管理系统的可持久重用的平台模型,并通过这个模型产生图书馆管理系统。
国外图书馆的管理系统起始于1954年的美国海军兵器中心进行的单元词匹配检索,发展到今天各种机读目录格式成为各国编制书目数据普遍遵循的规范。
《中国机读目录格式》也已经通过文化部组织的专家鉴定,为全国的图书馆管理系统的整合奠定了行业基础。
随着行业的发展和软件技术的不断进步,图书馆管理软件不断的重新建设,浪费了大量人力物力,而且各开发公司的各种异构平台的图书馆系统也需要整合,建立图书馆管理系统的可持久重用的平台模型可以解决以上问题。
本文的研究方法是利用MDA的思想,借助UML工具,从全面分析图书管理系统的需求入手,产生一个平台无关的可重用模型,为图书馆系统的整合提供一种思路本文的主要工作在于深入分析MDA开发方法,结合以下几个方面对图书馆管理系统软件开发进行综合改进：·利用MDA 开发方法,把开发人员的注意力从具体的实现细节转移到PIM上来,使得开发出来的模型与具体的平台无关。
这样开发的模型工作只要做一次,就可以应用到不同的技术平台上,实现了系统设计的复用。
一旦由高水平专业技术人员开发出可以用于各个具体应用软件的MDA工具,就可以使开发出的各项PIM直接转换成大量相应代码,一般程序开发人员编写代码的工作量会变的非常小,出错率自然就大大下降,从而可以大幅度提高生产效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
白皮书模型驱动开发和UML 2.0传统编程方式的终结？本文档包含Telelogic AB专有信息。
未经Telelogic AB书面许可，不得使用本文档内的任何信息，不得复印、影印本文档的任何部分。
前言“模型驱动开发”——体会一下这几个词。
它们说出了这个不断变化的工业中一个新的改变。
这里不是说一种革命，而是一种缓慢的变化，但是肯定会渗透到我们开发系统的方式中。
这种推动将降低代码的重要性，并且专注于一些开发中的真正事情：最终的应用程序被期望怎样工作，并确保你能够根据客户的需求可靠地建立起它来。
模型驱动开发是更伟大视景MDA中的一部分。
MDA是模型驱动体系架构（Model-Dri ven Architecture）的简称，由对象管理组织OMG（Object Management Group）所驱动。
M DA表示了一种模型驱动开发方法的概念框架。
然而，尽管完整的MDA还没有成为现实，模型驱动开发现在已成为可能。
实际上，它已以较低级的形式存在了较长一段时间，所以我们并不是在做某种新的东西（当然，除非你在听某些市场人员的宣传）。
没有魔法如果模型驱动开发这么好的话，为什么不是每个人立刻加入到这个潮流中来呢？首先，模型驱动开发不是一个银子弹，能神奇地解决你所有的问题。
总有某人需要去实现系统的功能，并且还找不到任何工具来完成这一点。
所有你能发现的工具只是使这项工作更容易和直接一些。
第二，采用模型驱动开发，并不只是在开发项目的过程中更换一种工具。
它还必须和已根深蒂固的开发过程结合起来（如果没有的话，你就可以开始使用模型驱动开发了；否则你就只能改善当前的情况），但实际上更重要的是，你还会担心它对现有应用程序的影响。
决定改用基于模型的方法前确实需要有一些仔细的考虑，并且，一般说来，为了不影响当前的工作，你只会在新项目中改变开发方法。
第三，你还需要获得那些使用工具的人们的支持（你需要一些工具来应用模型驱动开发）。
开发人员常会认为“模型驱动开发不是编程”而回避它，并且当心他们的工作难于被接受。
他们还可能担心模型驱动开发将会使他们以前辛苦学来的一些技巧过时。
他们的担心也不是完全没有理由。
采用模型驱动开发后，市场确实很有可能会减少对那些精通好几种编程语言的开发人员的需求。
但是另一方面，所有好的开发人员，首先和最主要的是，他们是问题的解决者。
他们感兴趣的是尽可能地为手边的主要问题找到新的更好的解决方案。
模型第 2 页/共 2 页驱动开发激动人心的一点就是它允许开发人员集中精力于解决主要的设计问题，增加新的、酷的功能；而不是花费他们的主要时间于改正语法错误，防止内存泄露，或无休止的低级b ug上。
还有第四点，它也是第三点的一个结果，工具必须足够的好。
不幸的是，有时用户对工具期待太多，或工具提供厂商承诺过多，实际上却不能交付。
这两种情况都很容易使用户放弃模型驱动开发的想法。
你确实需要保证工具能够满足你的需求。
可视化软件工程模型驱动开发的基础是模型和表达模型的语言。
模型提供了这样一种能力，能够一致性地显示这个系统的不同视图。
一个常见的错误是认为模型驱动开发是模型和代码之间的一种关系，通过代码实现了模型。
确实很多情况下，这二者是等同的，但它大大限制了我们的视野。
模型的一个主要用途消除开发过程中各参与方之间的隔阂，需求工程师，系统分析员，软件开发人员和测试者都可以使用同一种语言。
你可以注意到，他们可能专注于语言的不同部分，以满足他们的需要，但他们都会共用一些基本的结构，并对他们正工作的系统有一个统一的认识。
而且使用统一的语言有助于消除角色间的界限，使得在项目的不同阶段人员转换到被需要的角色更加容易。
还有另外一些人需要知道项目的进展情况，包括项目领导、经理和评估委员会。
更重要的是，用户也需要知道什么将会被交付，需要加入到整个开发过程中，与创建系统的不同人员进行交流。
一种图形建模语言，比如UML，使得各参与方之间的交流成为可能，帮助架起参与方与某些系统复杂功能之间的桥梁。
模型驱动开发正逐渐获得公司高级管理者注意，其中的一个主要原因就是这种能够逐渐增加用户、管理层和大的组织机构参与的能力。
那么编程将会怎样呢？它不再需要了吗？我们在这之前提及了一下，现在再详细讨论它。
给模型提供足够的信息，工具就能生成大部分和全部系统所需要的代码。
请注意，如果你用工具去生成全部的代码，这就相当于编译你的模型。
在很多方面，这都类似于当从汇编编程转到C编程时发生的模式转换，开始的时候，存在一定的怀疑，特别是那些汇编语言编程者。
对于模型驱动开发，我们说的也是一种相似的模式转换，建模语言代替了编程语言，用建模语言来实现系统。
这主要是因为建模语言正变得更有表现力，允许用户能够指定详细第 3 页/共 3 页的系统行为。
而且，主机上的确认和验证技术能用于检查系统的正确性。
在模型中，一般说来你会忽略掉那些令人不快的细节，比如分布式，代理和内存管理，并且让工具去生成它们的代码。
这些都表明你还需要对系统的行为进行建模（或者如果你愿意，也可以编程），但你可以在更抽象的层次上进行，关注于系统的重要功能。
你的明星程序员，你记不清他已多少次拯救你的公司了，可能会说，“如果我用编程的方式实现系统可能要快很多。
”你知道他说的可能是对的。
但是，这是个大系统，或者请慢，他打算对什么编程呢？是谁为他创建了系统规范？难道他不是团队的一部分吗？或者这个系统确实很小，一个人就能够确定规范，开发和测试？即使这样，你愿意所有的信息都只存在这一个人的头脑中？如果他不小心发生车祸，或者你的竞争对手为他提供了一份他无法抗拒的待遇，这时会怎样呢？系统交付以后又会怎样呢？最终用户能够修改实现吗？或即使是理解系统？将来升级，系统维护起来方便吗？这将我们带入到模型驱动开发的另一个主要用途，把系统和软件开发更多地纳入到系统和软件工程规则中。
模型驱动开发是关于开发和维护系统的，系统并不只是由应用程序组成，还包括其他的部分，使得人们可以理解这个应用程序。
一个模型可以包含明显可执行的部分，但它几乎总是还有其他部分，并不能被运行，比如需求，系统的粗略框架，商业模型和分析模型。
在项目开发时，所有这些都应该被创建出来并保持最新，它们对于将来的维护非常重要。
模型驱动开发的现代工具提供了运行一个（或部分）模型的能力，这使得可以更早得到确认，系统能按预定方式工作。
换句话说，这意味着项目风险被极大地降低。
在模型驱动开发中，测试也变得更加重要，因为能够被更早和更频繁地进行。
这种方式，会使你对在项目后期，应用程序的各部分能够统一合作具有更多地信心。
直观地，你可能以为所有这些额外的工作会延长开发周期，但是经验显示，产品上市时间实际上是缩短了。
你花费更少的时间用于实现和测试阶段，更多的时间用于分析和设计阶段，当你迭代重复这些过程时，你会发现，这种方式的好处是实实在在的。
UML2.0的作用无疑，统一建模语言（UML，Unifid Modeling Language）就是设计用来进行模型驱动开发的语言。
它第一次标准化是在1997年，作为当时各种面向对象分析方法之争的结果。
第 4 页/共 4 页然后它迅速成为最流行的建模语言，用于“可视化、构造和存档在基于软件的系统创建过程中的产品”。
我们沿着这条道路已经走了五年，用户和工具提供商对于UML语言都有了更多的经验。
我们知道什么很有用处，也知道什么需要被改进。
而且，软件工业在这些年也发生了变化，需要去支持一些新的技术，比如基于构件的开发和可执行的模型。
这些需求还不能用现在的UML合适地处理。
为了解决这些问题，对UML大的修订工作两年前由OMG开始启动，预计于2002年底前完成。
在语言中新增加的性能，用于对系统架构建模，都是些很重要的部分，使得更容易创建任何复杂度的实际系统。
对这种规模可伸缩性的关注也扩展到了其他领域，包括对行为进行建模的图形，比如顺序图和状态机。
既然UML试图适合很多参与方的需要，它需要变成一种相当大的语言，但是并不是每一个人都需要知道语言的所有部分。
它被有意识地分割成几种视图或图形，允许你关注于只与你相关的专门领域。
其他人可能希望工作在其他的视图上，模型将保持这些视图间的一致性。
工具的考虑工具实现模型驱动开发的方式各不相同，给予用户或多或少的灵活性。
双向工程是一个可怜人的选择，他不能在模型中捕获到系统行为，并且他还把自己与某种特定的编程语言绑定在一起，这还是一种以代码为中心的方法，所有这些都将使你感到难受。
在一些紧急的场合，你甚至会忘记模型，比如一个项目就要到达最后期限（看起来在某处总有一个最后期限）了。
在项目的最后，你得到了一个可工作的应用程序，还有一个没有实际用处的模型。
这时，你甚至怀疑建模的重要性了。
对双向工程问题的一个让步就是在模型中直接插入编程代码，因此强迫你更新模型以确保最终得到一个可执行的应用程序。
这同样使你感到难受，又被绑定到某种特定编程语言，你还不得不在模型的很多地方插入代码片断。
这很像在C程序中插入汇编代码，尽管有时这是必要的，但是将来维护会是问题并可能伤害你。
考虑直接在模型中提供指定系统行为的能力，上述两种方法都变得过时。
在模型驱动开发中，你只需按一个键，在你选择的平台上，就能获得自动生成的任何语言的代码，这样在模型这一级上就能实现应用程序的可移植性。
你不需要修改代码，改变你的系统就能直接反第 5 页/共 5 页应到模型的实现上。
当然，目前还有一些路需要走，大部分的工具厂商目前都有他们自己的语言映射，但要实现MDA的目标，就需要有对不同语言和平台的标准映射和脚本。
好消息就是这种前景正在展现。
模型驱动开发确实正在起作用，并必将改变我们开发系统的方式。
第 6 页/共 6 页。