下载文档原格式
国内外研发觉状及进展趋势基于构件的软件开发是幸免重复劳动，提高软件生产效率的软件开发方式，属于“软件复用”的一种实现方式，其起点是应用系统的开发再也不采纳一切“从零开始”的模式，而是以已有的工作为基础，充分利用过去应用系统开发中积存的知识和体会，如需求分析结果、设计方案、源代码、测试打算及测试案例等，从而将开发的重点集中于应用的特有组成成份。
通过软件复用，在应用系统开发中能够充分地利用己有的开发功效，排除包括分析、设计、编码、测试等在内的许多重复劳动，从而提高了软件开发的效率；同时，通过复用高质量的已有开发功效，幸免了从头开发可能引入的错误，从而提高了软件的质量，因此基于构件开发的软件系统强调构件化和体系结构的作用，具有很强的自适应性、互操作性、扩展性和重用性。
最近几年来，构件技术和基于构件的软件开发技术慢慢成为阻碍整个软件产业的关键技术，构件化已经成为软件企业的需求，软件构件市场已现眉目，软件工业化生成模式正在推动软件产业的规模化进展。
支持构件开发和治理和基于构件进行软件开发的标准、基础工具和产品正慢慢完善。
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模型驱动的体系架构（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，可以理解为中国移动手机桌面助理软件，适用于很多手机玩家；也可以理解为模型驱动架构。
它是由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 的话题转眼之间在网络上也如火如荼地繁荣起来了。
**********************************第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技术的图书馆管理系统的实现【中文摘要】传统的软件开发模式存在许多问题,比如生产效率难以提高、软件移植和互操作困难、维护代价居高不下。
其中OMG提出的模型驱动架构(Model—Driven Arehitecture)就是这种背景下提出的一种新型的软件开发方法。
它为解决各种互不兼容平台和中间件技术在系统集成和互操作方面存在的不足提供了新思路。
MDA的核心工件是模型,投入到MDA横型的设计努力会被多次复用来生成各种组件。
本文的研究是利用MDA和UML技术建立图书馆管理系统的可持久重用的平台模型,并通过这个模型产生图书馆管理系统。
国外图书馆的管理系统起始于1954年的美国海军兵器中心进行的单元词匹配检索,发展到今天各种机读目录格式成为各国编制书目数据普遍遵循的规范。
《中国机读目录格式》也已经通过文化部组织的专家鉴定,为全国的图书馆管理系统的整合奠定了行业基础。
随着行业的发展和软件技术的不断进步,图书馆管理软件不断的重新建设,浪费了大量人力物力,而且各开发公司的各种异构平台的图书馆系统也需要整合,建立图书馆管理系统的可持久重用的平台模型可以解决以上问题。
本文的研究方法是利用MDA的思想,借助UML工具,从全面分析图书管理系统的需求入手,产生一个平台无关的可重用模型,为图书馆系统的整合提供一种思路本文的主要工作在于深入分析MDA开发方法,结合以下几个方面对图书馆管理系统软件开发进行综合改进：·利用MDA 开发方法,把开发人员的注意力从具体的实现细节转移到PIM上来,使得开发出来的模型与具体的平台无关。
这样开发的模型工作只要做一次,就可以应用到不同的技术平台上,实现了系统设计的复用。
一旦由高水平专业技术人员开发出可以用于各个具体应用软件的MDA工具,就可以使开发出的各项PIM直接转换成大量相应代码,一般程序开发人员编写代码的工作量会变的非常小,出错率自然就大大下降,从而可以大幅度提高生产效率。
MDA模型驱动开发方法学主讲：张文（Jevons）一、传统软件工程方法学传统的软件开发方式有许多模型，瀑布模型是其中最典型也最受诟病的一种，为了描述一个软件的生命周期，我们暂时以这种模型来阐述一下软件开发的过程。
软件开发要经历可行性分析研究，需求分析，总体设计（概要设计），详细设计，集成和测试等过程。
一个成熟的软件模型在这些环节都需要生成大量的文档，目前的很多CMMI工具能很好的管理好这些文档，比如将需求文档关联到后期的详细设计的过程或编码的过程等。
由于这个过程的生命周期太长，导致了开发过程中发现的问题不能及时反映到模型中来（虽然某些工具能跟踪到需求的变化），这个传统的工作过程虽然在目前遇到了极大的挑战，所以目前非常流行所谓的敏捷开发，本人也非常崇尚这种开发方式，但从我的经验来看，敏捷开发应该更多的体现在小项目或大项目的子模块的开发。
对于一个较大的项目而言，一定的设计和研讨还是必不可少的。
但如何解决之前所提到的开发周期过长，错误反馈不到位的诟病呢？我认为，在详细设计阶段，如果能有一个好的开发模型将能极大的解决这种问题，而MDA就是这么一个开发模型。
二、MDA的过程MDA，全称叫模型驱动开发，顾名思义，开发是由模型来推动的，即开发之前需要建立良好的模型。
也许大家现在有了一定的概念了，因为大家在大大小小的开发时都会画一些uml图，建立一定的模型，然后一个软件的雏形就应运而生了。
如果大家能做到这一步，恭喜你，说明你已经具备一定的设计能力了。
但我也要反问你，在工作过程中，请问有哪次的模型是你自己觉得非常满意的，或者说是你的得意之作吧。
面对这个简单问题，我想任何肯定回答都是牵强的，因为小的软件过程基本上不需要良好的设计，而大的软件过程，则很难做到良好的设计，如果没有一个良好的开发机制的话。
而MDA的开发方式则不一样，因为设计和编码可以融为一体，而且任何编码之前都是设计，任何设计都能生成编码，代码中也能访问到设计中的元数据定义，这就是MDA的神奇之处。
模型驱动架构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。
白皮书模型驱动开发和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 页。
