（计算机软件与理论专业论文）基于模型驱动架构的软件生成技术研究.pdf

太原理工大学硕士研究生学位论文 基于模型驱动架构的软件生成技术研究 摘要 软件的简便性开发和自动生成一直是软件开发的努力发展的理想目标。 应用软件尤其是企业级应用软件系统作为一类计算机应用系统，以应用领 域的多样性、开发技术的复杂性著称。为了解决软件开发难度大、周期长 与缺少高技术软件人才的矛盾，人们需要软件自动生成技术的支持。为了 提高软件开发效率，改进软件开发方法，提高软件自动化过程，本文对软 件开发方法和过程进行了探索性研究工作，并结合m d a 的思想，提出了基 于模型驱动架构的软件生成技术的研究课题。 本课题的目的在于，提出一个整体性的应用级软件的自动生成框架，并 且对框架中各个关键部分的结构和作用机制进行分析讨论。另外，对整个 框架中的核心部分进行设计与实现研究，提出一种实现方法。 本文主要从两个方面对该课题进行了分析论述： 一、提出了一种基于模型驱动架构的软件生成框架。整个框架主要包括 建模系统、代码生成系统以及公共类型系统和公共类型映射系统等基础设 施。在该框架中，建模系统利用当前比较通用的u m l 作为建模语言。与许 多其它建模工具相比，建模系统是整个软件开发过程的核心，不再是软件 开发的辅助工具。因为模型是软件开发的驱动力，通过模型转换，大部分 代码被自动生成。另外，本文对代码生成系统的结构和代码生成机制进行 了阐述。 二、提出了一种从u m l 模型到x m l 模型的转换方法。在基于模型驱动架 太原理工大学硕士研究生学位论文 构的软件自动生成框架中，其中一个关键的机制就是，要从u m l 模型自动 转换为x m l 模型。x m l 模型作为文本数据是代码生成系统的输入，是由u m l 模型驱动生成代码的中间数据。本文主要对该部分进行了实验分析和设计。 此外，本文前面几章还对m d a 和当前的软件自动生成技术进行了分析研 究。 最后，本文对本课题研究中的一些不足进行了一定的分析，对未来进一 步深入研究工作进行了展望。 关键字：m d a ，u m l ，x m l ，模型变换，代码生成，建模系统 n 太原理工大学硕士研究生学位论文 t h er e s e a r c ho fs o f t w a r eg e n e r a tio n t e c h n o l o g yb a s e do nt h em o d e ld riv e na r c hit e c t u r e a b s t r a c t s i m p l ed e v e l o p m e n ta n da u t o m a t i cg e n e r a t i o no fs o f t w a r ei sa l w a y st h e d r e a m b o a to fs o f t w a r e d e v e l o p m e n t a p p l i c a t i o n ss o r w a r e ，e s p e c i a l l yt h e e n t e r p r i s ea p p l i c a t i o ns o f t w a r e ，i sf a m o u sf o rd i v e r s i t yo fa p p l i c a t i o nd o m a i n a n dc o m p l e xo fd e v e l o p m e n tt e c h n o l o g ya sak i n do fc o m p u t e ra p p l i c a t i o n s y s t e m i no r d e rt os o l v et h ec o n t r a d i c t i o n ，s u c ha sh a r d ，l o n gc y c l et i m ea n d s h o r t a g eo fh i g h - t e c ht e c h n o l o g i s to fs o f t w a r ed e v e l o p m e n t ，s ow en e e dt h e a u t o m a t i cg e n e r a t i o no fs o f t w a r et e c h n o l o g y i no r d e rt oh e i g h t e nt h ee f f i c i e n c y o fs o r w a r ed e v e l o p m e n t ，i m p r o v et h ew a yo fs o f t w a r ed e v e l o p m e n ta n d e n h a n c et h ep r o c e s so fs o r w a r ea u t o m a t i z a t i o n t h i sp a p e rd os o m eg r o p i n g r e s e a r c hw o r ko nt h em e t h o da n dp r o c e s so fs o f t - w a r ed e v e l o p m e n ta n db r i n g f o r w a r dt h er e s e a r c ht a s ko nt h es o w a r eg e n e r a t i o nt e c h n o l o g yb a s e do nt h e m o d e ld r i v e na r c h i t e c t u r ec o m b i n e dw i t ht h et h i n k i n go f m d a t h er e s e a r c ha i ma t b r i n g i n gf o r w a r da ni n t e 鲥t yf r a m eo fa u t o m a t i c g e n e r a t i o nf o ra p p l i c a t i o ns o r w a r e ，a l s oa n a l y z ea n dd i s c u s sa b o u tt h es t r u c t u r e a n dt h eo p e r a t i o nm e c h a n i s mo fp i v o t a la s p e c ti nt h ef r a m e i na d d i t i o n , t h i s p a p e rd os o m ed e s i g na n di m p l e m e n tr e s e a r c hf o rt h ek e r n e lo ft h em d n l ea n d b r i n gf o r w a r da ni m p l e m e n tm e t h o d t h i sp a p e rh a sa n a l y z e da n dd i s c u s s e dm a i n l yf o rt h er e s e a r c hf r o mt w o a s p e c t s ： f i r s t l y , b r i n gf o r w a r daf r a m eo ft h es o f t w a r eg e n e r a t i o nb a s e do nt h e m o d e ld r i v e na r c h i t e c t u r e i tm a i n l yc o n t a i n st h ei n f r a s t r u c t u r ei nt h ef r a m ef o r m o d e l i n gs y s t e m , c o d eg e n e r a t i o ns y s t e m , c o m m o nt y p es y s t e ma n dc o m m o n u l 太原理工大学硕士研究生学位论文 t y p em a p p i n gs y s t e ma n d s oo n i nt h ef l a m e ，m o d e l i n gs y s t e mu s et h ec o m m o n u m la s m o d e l i n gl a n g u a g e c o m p a r ew i t h t h eo t h e rm o d e l i n gt o o l s ，t h e m o d e l i n gs y s t e mi st h ec o r eo ft h ew h o l ep r o c e s so fs o f t w a r ed e v e l o p m e n t , n o l o n g e rt h ea s s i s t a n tt o o lf o rs o f t w a r ed e v e l o p m e n t a sm o d e li st h ed r i v e rf o r s o f t w a r ed e v e l o p m e n t ，am a j o r i t yo fc o d ea r ea u t o m a t i cg e n e r a t e dt h r o u g h m o d e lt r a n s f o r m a t i o n i na d d i t i o n ，t h ep a p e ra l s oh a st a l k e da b o u tt h es t r u c t u r e a n dm e c h a n i s mo f c o d eg e n e r a t i o ns y s t e m s e c o n d l 5b r i n gf o r w a r dam e t h o do nh o w t ot r a n s f o r mf r o mu m lm o d e l t ox m lm o d e l i nt h ea u t o m a t i cg e n e r a t i o nf l a m eb a s e do nt h em o d e ld r i v e n a r c h i t e c t u r e ，o n eo ft h ep i v o t a lm e c h a n i s m s i st h a tn e e dt ot r a n s f o r m a u t o m a t i c a l l yf r o mu m l m o d e lt ox m lm o d e l a st e x td a t a ，x m lm o d e li st h e i n p u to fc o d eg e n e r a t i o ns y s t e m ，w h i c hi s m i d d l ed a t ag e n e r a t e df r o mt h e s y s t e md r i v e nf r o mu m l m o d e l t h ep a p e rh a sm a i n l yd o n ee x p e r i m e n ta n d d e s i g na b o u tt h i sp a r t b e s i d e s ，t h ef r o n tc h a p t e r so ft h ep a p e rd os o m ea n a l y s i sa b o u tm d a a n d t h es o f t w a r ea u t o m a t i cg e n e r a t i o nt e c h n o l o g y k e yw o r d s ：m d a ，u m l ，x m l ，m o d e lt r a n s f o n n a t i o n , c o d e g e n e r a t i o n , m o d e l i n gs y s t e m i v 声明 本人郑重声明：所呈交的学位论文，是本人在指导教师的指导下。 独立进行研究所取得的成果。除文中已经注明引用的内容外。本论文 不包含其他个人或集体已经发表或撰写过的科研成果。对本文的研究 做出重要贡献的个人和集体，均已在文中以明确方式标明。本声明的 法律责任由本人承担。 论文作者签名：垒童垒日期： 关于学位论文使用权的说明 本人完全了解太原理工大学有关保管、使用学位论文的规定，其 中包括：学校有权保管、并向有关部门送交学位论文的原件与复印 件；学校可以采用影印、缩印或其它复制手段复制并保存学位论文； 学校可允许学位论文被查阅或借阅；学校可以学术交流为目的。 复制赠送和交换学位论文；学校可以公布学位论文的全部或部分内 容( 保密学位论文在解密后遵守此规定l o 签 名：一兰童垄 日期：1 2 ：墅； 导师签名：日期： 太原理工大学硕士研究生学位论文 第一章绪论 软件的简便性开发和自动生成一直是软件开发的努力发展的理想目标，但现阶段自 动生成的应用领域基本上还是在代码自动生成和专属领域软件自动生成上。 应用软件尤其是企业级应用软件系统作为一类计算机应用系统，以应用领域的多样 性、开发技术的复杂性著称。为了解决软件开发难度大、周期长与缺少高技术软件人才 的矛盾，人们需要软件自动化技术的支持。 1 1 软件技术概述 软件技术自上世纪5 0 6 0 年代以来一直不断地发展。驱动软件技术不断发展的一个 主要原因是人们至今尚没有找到一个能够高效率、高质量、低成本生产软件的满意方法。 回顾软件技术发展的历程，软件技术的每一次进步，都促进了软件生产力水平的提高与 改善。软件技术的发展经历了大约以下五代历程“1 ： 第一代( 5 0 _ 6 0 年代) ，是以a l g o l 、f o r t r a n 等编程语言为标志的算法技术。那时， 程序设计是一种任人发挥创造才能的活动，写出的程序只要能在计算机上得出正确的结 果，程序的写法可以不受约束，程序往往是一件充满了技巧和窍门的艺术品”。基于这 种算法技术的软件生产率非常低，程序很难看懂，甚至程序员自己写的程序，过一段时 间后自己也看不懂，这给软件的修改、维护带来极大的困难。6 0 年代末出现了“软件危 机”。 第二代( t o 年代) ，是以p a s c a l 、c o b o l 等编程语言和关系数据库管理系统为标志的 结构化软件技术。这种技术以强调数据结构、程序模块化结构为特征，采用自顶向下逐 步求精的设计方法和单入口单出口的控制结构，从而大大改善了程序的可读性。伴随着 结构化软件技术而出现的软件工程方法( 包括c a s e 工具) ，使软件工作的范围从只考虑 程序的编写扩展到从定义、编码、测试到使用、维护等整个软件生命周期。软件不仅仅 是程序，还包括开发、使用、维护程序需求的所有文档，编程工作大约只占软件开发全 部工作量的2 0 。结构化软件技术使软件由个人作坊的艺术品”，变为团队的工程产品， 大大改善了软件的质量与可维护性，但软件开发的成本却大大增加。 第三代( 8 0 年代) 的软件技术是以s m a l l t a l k 、c + + 等为代表的面向对象技术( o o ) 。面 太原理工大学硕士研究生学位论文 向对象技术以对象作为最基本的元素，它将软件系统看成是离散的对象的集合。一个对 象既包括数据结构，也包括行为。一般情况下，一个对象与现实世界的一个事物相对应。 面向对象技术的最大优点是帮助分析者、设计者及用户清楚地表述概念，互相进行交流， 并作为描述、分析和建立软件文档的一种手段。显然，这将大大提高软件的易读性、可 维护性、可重用性，进一步地，这使得从软件分析到软件设计的转变非常自然，因此可 大大降低软件开发成本。而算法技术和结构化技术相应的转变就没有这种自然性，因为 这两者的实现基础是计算机指令系统，而不是人思维中的概念。例如，循环和分支等语 言机制就是对机器跳转指令的抽象。另外，面向对象技术中的继承、封装、多态性等机 制，直接为软件重用提供了进一步的支持。面向对象技术可以通过有效的软件重用来提 高软件生产率。 第四代( 9 0 年代) 的软件技术是以c o r b a 等为代表的分布式面向对象技术( d 0 0 ) 。随 着计算机网络技术的发展，进入9 0 年代以来，异构环境下分布式软件的开发已成为一 种主流需求，面向对象技术对软件的重用，仅限于单台计算机上、同种操作系统与编程 语言环境下的软件重用，对象往往仅存在于一个程序中，程序的外界并不可能感知和访 问这些对象。异构环境分布式系统中的软件重用，要求能够重用不同计算机上、不同操 作系统或语言环境下，由不同人员不同时间开发的软件模块。具体地，就是要解决不同 软件之间的组合性、互操作性、可移植性等技术问题。分布式面向对象技术的核心是中 间件技术，即是通过在系统软件与应用软件之间提供一个统一的软总线( s o f t w a r eb u s ) ， 以屏蔽不同操作系统、不同语言环境的差别，将异构分布式系统“转化”为一个对软件 开发人员而言虚拟的单台计算机、单一开发环境。分布式面向对象技术不仅使面向对象 技术的优点在异构分布式环境下得到保持，更重要的是大大简化了异构分布式软件开发 工作的复杂性。另外，分布式面向对象技术对于如何保留利用已有的传统遗留软件 ( l e g a c y s y s t e m ) ，并使已有遗留软件与新开发软件能够互操作方面提供了有效的解决方 案。 第五代( 9 0 年代中期至今) 软件技术是以c o m 、c o r b a 3 0 、e j b 和w e bs e r v i c e 等为 代表的软件构件技术。面向对象技术及分布式对象技术等支持的软件重用只是以程序 源代码的形式进行的，而不是软件的最终形式一可执行二进制码的重用。这要求设计者 在重用别人的软件时，必须要理解别人的设计和编程风格。对于封装风格的类库，使用 者不仅需要理解封装在类库内的底层技术，还需要理解类库本身所强加的抽象概念。因 此应用其他开发人员的代码往往比再实现这些代码要付出更多的代价。软件构件技术的 突破，在于实现对软件可执行二进制码的重用。这样，一个软件可被切分成一些构件， 2 太原理工大学硕士研究生学位论文 这些构件可以单独开发、单独编译，甚至单独调试与测试。当所有的构件开发完成后， 把它们组合在一起就得到完整的应用系统。 1 。2 存在问题 通过对以上软件开发方式和发展趋势的简要介绍，可以发现，开发者的角色逐渐分 化为组件开发组、组件集成组，面向对象的概念开始从类级别抽象到组件级别，软件生 产开始跟传统制造业一样出现工业化生产趋势。软件的开发始终都在围绕如何提高已有 系统的复用度，缩短软件开发周期，提高项目的成功率等因素上面。但是到目前为止， 相关数字表明，5 0 0 , 6 的大型软件项目都会中途夭折。大型项目平均都要推迟一年以上的 工期，成本要超出计划的一倍，而性能却比预期的要低得多。分析其原因，主要有以下 几点： 首先，业务需求的变化太快。由于市场竞争的激烈，迫使企业要更快地重新修改其 业务规则。需求的改变，很显然常常会引起系统设计的改变，并造成功能的增删与大量 代码添加、修改。 其次，在软件开发的整个过程中，缺乏统一的规范约束，如缺乏完备规范的开发文 档、设计文档等。在目前软件开发人员跳槽频繁的客观情况下，由别人来接手离去人员 未完成的软件开发工作，这是非常困难的，往往造成工期拖延、成本上升，甚至项目失 败。 综上所述，关键的因素是需要某些工具或平台对软件开发的整个过程进行严格的规 范约束与效率支持，而软件自动生成工具的研制是解决上述问题的有效方法之一，它对 于整个软件生产具有非常重要的意义。其作用类似于工业生产中的自动化流水生产线， 以汽车行业为例，通过标准化零配件的生产和配件组装完成整车的大规模、高效率生产。 1 3 论文内容和组织结构 1 3 1 论文内容 为了加强企业应用系统开发过程的集成、实现软件过程的复用，为了实现应用系统 的自动生成，希望有这样的整体性的软件开发平台，能够将构件、语言和提供运行的支 撑环境三者“无缝”地结合起来，对于软件设计者只需用业务建模的方式指出“做什么”， 就能够产生一个完整的应用系统。 太原理工大学硕士研究生学位论文 根据上述目的，本课题对这样一个整体性的应用软件的自动生成技术进行研究。 根据上述软件技术发展趋势与所存在问题的分析，本文提出了自己的解决方案一基 于模型驱动架构的软件自动生成的研究设想。该设想主要围绕基于模型驱动架构的软件 自动生成框架以及模型转换等问题进行探索性的研究。本文首先对软件技术发展的历程 进行了回顾，而后对m d a ( 模型驱动架构) 理论进行分析讨论，随后在对目前各种软件 自动生成研究状况分析的基础之上，提出了基于模型驱动架构的软件自动生成框架，并 对框架中的各个部分分别进行了比较详细的论述；另外，重点介绍了本人u m l 到x m l 转 换方法方面的研究情况。最后对到目前为止的研究工作进行了总结，并对今后的研究进 行了展望。 1 3 2 论文组织结构 第二章主要介绍了m d a 理论，分析了m d a 的核心思想。内容上主要包括介绍m d a 的 产生背景，对比于传统软件开发模式所面临的问题，讨论了m d a 的开发生命周期以及开 发模式，分析m d a 的优点。另外，还比较详细介绍了胁a 框架和相关的核心技术。 第三章主要分析了当前的软件自动生成技术研究状况。根据方式方法和作用内容与 形式的不同，从c a s e 工具与技术、领域专用应用软件自动生成、代码自动生成等三方 面进行了介绍。其中着重介绍了基于领域语言的应用软件自动生成技术和代码自动生成 原理。 第四章通过对m d a 理论的研究以及对各种软件自动生成技术的研究，提出了一种基 于m d a 思想的软件自动生成框架。主要对所提出的框架中的建模系统和代码生成系统进 行了详细论述和分析。 第五章主要提出了一种从u m l 模型到x m l 模型的转换方法。主要对该方法进行了详 述，并且给出了实验结果。 第六章是本文的总结部分。主要对所做的研究工作进行总结，对研究的不足进行了 分析，并且对今后的研究工作进行了展望。 4 太原理工大学硕士研究生学位论文 第二章m d a 理论 软件产业在i t 产业中历来占有重要的地位，迸入2 1 世纪，这种地位继续得到巩固 和凸现。纵观软件产业的发展历史，计算技术经历了“以机器为中心一以应用为中心一 以企业为中心”的变化，软件开发方法的进步有助于维持软件产品质量、全生命期、生 产成本的平衡嘲。以企业为中心的计算主要包括以下方面：基于组件开发 ( c o m p o n e n t - b a s e dd e v e l o p m e n t ) 、设计模式( d e s i g np a t t e r n s ) 中间件( m i d d l e w a r e ) 、 说明性规约( d e c l a r a t i v es p e c i f i c a t i o n ) 、企业构架( e n t e r p r i s ea r c h i t e c t u r e ) 、企 业应用集成( e n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ) 、契约式设计( d e s i g nb y c o n t r a c t ) 娜。作为将这一系列新的趋势性技术整合到一起的开发方法，模型驱动架构 ( 佃a ，m o d e ld r i v e na r c h i t e c t u r e ) 的出现，为提高软件开发效率，增强软件的可移 植性、协同工作能力和可维护性，以及文档编制的便利性指明了解决之道。也正因为如 此， i d a 被面向对象技术专家预言为未来几年里最重要的方法学。 2 1m d a 背景 软件系统的开发本质上是一个从模型到最终实现的过程。由于具体的实现技术及其 相关标准总在不断地发展变化，如果系统的模型和实现技术是一种紧密结合关系，那么 系统的升级以及系统与其他系统之间的集成就相当困难。 m d a ( m o d e ld r i v e na r c h i t e c t u r e ，模型驱动架构) 是由o m g 定义的一个软件开发框 架。m d a 是一种系统开发方法，提供一种利用模型去指导分析、设计、构建、部署、操 作、维护和更新的手段“”。它是一种基于u l l l 以及其他工业标准的框架，支持软件设计 和模型的可视化、存储和交换。和u 札相比，m d a 能够创建出机器可读和高度抽象的模 型，这些模型独立于实现技术，以标准化的方式储存。m d a 把建模语言用作一种编程语 言而不仅仅是设计语割5 1 。a 的关键之处是模型在软件开发中扮演了非常重要的角色。 肋a 源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分 离出来的思想，肋a 提供了一种途径( 通过相关的工具) 来规范化一个平台独立的系统、 规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。 通过把系统的业务功能分析设计和系统的具体实现基本分离，以求把实现技术的变化对 业务系统的影响降低到最小化的程度“。从宏观上看，m d a 使得应用模型与领域模型在 太原理工大学硕士研究生学位论文 整个软件生命周期中得到了复用，保证了已有投资并驱动整个系统的技术升级。m d a 的 三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性。 模型驱动架构( m d a ) 是o m g 组织近年来一直热炒的一个新的技术体系，同时也是众 多搞软件模型研究人员的一个新热点。m d a 理论还处在一个探索期，很多理论和方法并 不成熟，当然无从谈起有成熟的工具，从目前的趋势而言，从理论到实际的工具都离o m g 组织所提出的预想有较大距离。目前，无论是国外的开源组织还是国内的一些组织，对 m d a 都只是处在一个草创阶段，很多人所谓的应用m d a 其实都只是在m d a 的体系中作一 个最初的探索和尝试。 2 2m d a 开发过程 2 2 1 传统软件开发模式所面临的问题 ( 1 ) 生产效率问题 目前我们的软件开发过程是以系统设计和编码驱动的。如图2 - 1 为一个典型的传统 软件开发过程，它包括一系列阶段：需求收集、分析及功能描述、设计、编码、测试和 部署。无论我们是采用增量开发和迭代开发，或者是使用传统的瀑布式开发过程，文档 和相关的设计图表都是在前三个阶段中产生。我们的需求分析往往使用文本和图表的方 式来描述，其中的图经常采用0 m l 图，如用例图、类图、交互图、活动图等。一旦开始 编码，前三个阶段产生的文档和相关图表就很快会失去它们的价值。随着编码阶段的进 展，图片和代码之间的联系会逐渐减弱甚至消失，它们不再是对代码的精确描述，或多 或少地成为了无关的图片。 程序员的捷径 理论上的选代过程 图2 - 1 传统软件开发过程 f i g u r e2 - 1t r a d i t i o n a lp r o c e s so f s o f t w a r ed e v e l o p m e n t 随着时间的推移，系统不断地被修改，文档、设计图表和代码之间的距离就越来越 疏远。我们仅仅是修改了代码，因为修改文档和设计图表所要花费的代价是我们无法容 6 太原理工大学硕士研究生学位论文 忍的。同时，即使我们修改了图表和文档，这样的工作是否有效也值得怀疑，因为我们 还会不断地修改代码。 极限编程x p ( e x t r e m ep r o g r a m m i n g ) 的理念正在迅速地普及和流行，一个主要的原 因就是它承认代码是软件开发的驱动力这个事实。在开发过程中，真正具有生产力的阶 段是编码阶段和测试阶段。但是极限编程只能够解决软件开发中的部分问题：当一个团 队初始开发一个系统的时候，保存在它们大脑中的设计思想足以使它们理解这个系统。 问题是当第一个版本发布之后，团队可能会解散，其他来维护这个系统的人可能是一个 新人，那么它就只有代码和测试结果，这就使得系统维护极其困难。 所以，要么我们花时间在前三个阶段建立高层次的文档和图表，包括详细设计文档 和设计图表；或者我们花时间在维护阶段，来发现我们的系统是如何工作的。这些方式 都是不能直接产出代码的，也是花费比较高昂的。许多开发人员认为直接编写代码才具 有生产力，设计模型和文档则不具备。但是，在一个软件系统的项目团队中，这些任务 都是必须被完成的。抛弃文档写作就能提高生产力吗? 文档写到什么粒度，既能很好地 指导编码和测试，又能不降低生产率呢? 这些一直是困扰开发人员的难题。 ( 2 ) 可移植性问题 软件产业与传统产业相比，有其特殊性，它的发展速度令人吃惊。每年( 甚至更短时 间内) ，都会有新技术被发明并迅速流行起来，例如j a v a 、l i n u x 、x m l 、s o a p 、u m l 、 j 2 e e 、n e t 、w e bs e r v i c e s 、w e b 2 0 等等) 。许多公司都有充分理由追随这些新技术， 如：客户需要、解决实际问题( 例如x m l 解决异构系统间的数据交换) 、新的各种软件工 具等不支持老技术等等。 新技术能够使得一些公司获得一些切实的好处，但是人们必须面临的困境就是，他 们必须快速跳跃前进，而且必须忍受前期投资失去价值的现实，这无疑是非常痛苦的。 情况更加复杂的是，新技术本身也在发生变化。它们也会不断推出不同的版本，而且并 不能保证能完全做到向后兼容。软件供应商通常也只是对最近的2 到3 个版本提供支持。 现存的软件要么被移植到新技术，要么被移植到老技术的新版本。而使用老技术的 遗产系统必然需要和基于新技术的新系统进行交互。我们的系统如果和某种技术紧密绑 定，那么注定这个系统在跟随技术发展的道路上是步履沉重的，那么如何设计我们的系 统才能够使得我们的系统足够地轻便，能够适应技术的不断前进呢? ( 3 ) 互操作性问题 软件系统很少能够孤立地存在。大多数系统都需要和其它系统进行通信。一个典型 的例子就是，很多公司在他们的现存系统上构建了新的基于w e b 的系统：基于h t m l ， 7 太原理工大学硕士研究生学位论文 a s p n e t 。j 2 e e 等的w e b 系统需要从现存的后端系统中获取信息等等。系统往往要使用 多种技术来实现，他们之间也存在互操作的问题。现在我们往往在系统中使用组件，不 同的组件使用各自最佳的技术来实现，他们之间也需要互操作。 不同的工具对于元数据的管理均有自己的策略，这就给元数据的共享形成了障碍， 也降低了不同软件的互操作性。如何应对这些互操作的需求呢? 能否有一个统一的解决 方案呢? ( 4 ) 维护与文档问题 文档一直是软件开发过程中的薄弱环节，许多开发人员常常在事后才补写文档。大 多数开发人员总是认为编码才是他们的主要任务，在开发过程中编写文档需要花时间， 会降低开发速度。文档并没有为开发人员当前的主要任务提供支持，而是为以后的任务 提供支持。编写文档成了强制的任务，并非自愿的工作。这是文档质量不高的一个主要 原因。 能够检查文档质量的也只能是开发团队的人员，而他们自己却讨厌编写文档。因此 这也是文档总是不能得到更新的原因。每次代码改变之后必须手工去在一堆文档中找出 设计中需要更改的地方，这是很烦琐的工作。而我们应该是开发一个容易更新和便于将 来维护的系统。 在代码层次上解决这一问题的方案就是提供可以从源代码直接生成文档的机制，确 保文档总是最新。文档事实上是代码的一部分，而不是一个独立实体。但这只解决了底 层次文档问题。高层次的文档依然需要手工维护。对于一个复杂的系统，在较高抽象层 次上描述系统的详细设计文档尤为重要。如何能够保持文档和代码的同步，而又不额外 增加很多工作量呢? 2 2 2m d a 开发生命周期 如图2 2 所示描述了仰a 开发生命周期。从图中可以看出，m d a 开发模式的生命周 期与传统开发模式的生命周期看起来并没有太大的不同，都具有相同的开发阶段。一个 主要的区别就是开发阶段创建的设计工件的性质不同。岫a 的设计工件是形式化的精确 模型，可以被计算机理解。 太原理工大学硕士研究生学位论文 图2 - 2 蛐 开发生命周期 f i g u r e2 - 2 l i f ec y c l eo f m d a d e v e l o p m e n t 另外，传统上，从模型到模型的变换，或者从模型到代码的变换，主要是手工完成 的。许多工具可以从模型生成一部分代码，但是往往只生成一些模板代码，大部分工作 需要手工完成。与此相反，m d a 变换总是由工具执行的，如图2 3 所示。许多工具可 以把p s m 变换成代码，因为p s m 已经和代码很接近了。m d a 的创新之处是把p i m 到 p s m 的变换也自动化了。这是m d a 带来的显著好处。 图2 - 3 从p i m 到代码的变换 f i g u r e2 - 3t r a n s f o r m a t i o nf r o mp i mt oc o d e m d a 中，主要有三种模型：平台独立模型( p l a t f o r mi n d e p e n d e n tm o d e l ，p i m ) 、平 台相关模型( p l a t f o r ms p e c i f i cm o d e l ，p s m ) 和代码。 ( a ) 平台独立模型 平台独立模型p i m 是具有高抽象层次、独立于任何实现技术的模型“”。这种模型描 述了独立于任何实现平台的系统结构和功能特征。m d a 定义的第一类模型就是平台独立 模型p i m 。p i m 描述支撑某些业务的软件系统在p i m 中，是从“系统如何才能最好地 支撑业务”的视角对系统建模的。至于系统是用大型机上的关系数据库实现，还是用e j b 应用服务器实现，这不是p i m 关心的内容。在定义p i l l 的过程中，我们会不断根据客户 需求和其它因素对p i m 进行精化，以使得它能够更加精确地描述我们的系统。 ( b ) 平台相关模型 平台相关模型p s m 是与特定实现技术或平台相关的模型“”，是为某种特定实现技术 量身定做的。在p i m 构造完成后，p i m 被变换为一个或多个平台相关模型p s m ，为每个 特定的技术平台生成一个单独的p s m 。例如，e j bp s m 是用e j b 结构表达的系统模型， 9 太原理工大学硕士研究生学位论文 它通常会包含e j b 特有的术语，比如“h o m ei n t e r f a c e ”、“e n t i t yb e a n ”、“s e s s i o n b e a n ”等等。关系数据库p s m 则包含“表”、“列”、“外键”等术语。显然，p s m 只对了 解相应平台的开发者有意义。由于现今的很多系统都跨越多种技术，所以对于一个p i m 拥有多个p s m 是很正常的。这是m d a 中最复杂，也是最重要的一步。 有时候从p i m 自动生成的p s m 并不能使挑剔的程序员满意，他们会根据平台的特性 对p s m 加以修改，对p s m 进行不断的精化，以指导生成器生成质量更高的代码。对p s m 的改变也能够反映到p i m 中去，这是m d a 的高级特性。 ( c ) 代码 开发的最后一步是把每个p s m 变换成代码。因为p s m 同相应技术密切相关，所以这 一变换相对比较直接。 m d a 定义了p i m 、p s m 和代码，还定义了它们之间的关系。在开发过程中应当首先创 建p i m ，然后把它变换成一个或多个p s m ，最后再变换成代码。把p i m 变换成一个或多 个p s m 是m d a 开发过程中最复杂的一步。p i m 、p s m 和代码表现为开发生命周期中不同阶 段的工件。从另外一个角度看，它们表现了系统规约的不同抽象层次；从不同的视角来 看待我们的系统，将高层次的p i m 转换到p s m 的能力提升了抽象的层次，能够使得开 发人员更加清晰地了解系统的整个架构，而不会被具体的实现技术所干扰，同时对于复 杂系统，也减少了开发人员的工作量。 2 2 3n d a 模型变换 1 ) c i m ( c o m p u t a t i o n a li n d e p e n d e n tm o d e l ，计算独立模型) 到p i m 的变换。这主 要是将描述系统功能的业务模型变换到分析模型，这个过程主要由系统分析设计人员手 工来实现。 2 ) p i m 到p i l l 的变换。当模型在开发生命周期中得到了改进、过滤或者特殊化，但 是不需要任何与特定平台相关的信息，那么将使用从p i m 到p i m 的变换。最常见的变换 如从分析模型到总体设计模型的交换。p i m 到p d i 的变换通常与模型求精相关。从软件 工程的角度来说，这是正向工程。 3 ) p i m 到p s m 的变换。p i m 到p s m 的变换是m d a 的核心嘲。当p i m 被细化，对应到 执行基础架构上时，则需要执行从p i m 到p s m 的变换。从p i m 到p s m 的变换是基于特定 平台特性的。因此，在建模过程中需要使用u m l 来描述平台的特性。如将一个逻辑的组 件模型变换到己有的业务组件模型( 比如j 2e e 平台的e j b 或者c o r b a 平台的c c m ) 就是 一种p i m 到p s m 的变换。在m d a 的实际应用中，变换工具可以根据不同的变换规则将一 1 0 太原理工大学硕士研究生学位论文 个p i m 变换到多个不同的p s m ，并在这些p s m 之间生成桥接器，在这些p s m 之间建立联 系。 4 ) p s m 到p s m 的变换。当涉及到组件实现与部署时，需要用到p s m 到p s m 的变换。 比如说通过选择不同的服务配置对组件进行封装，在封装完成以后，就要对组件进行初 始化，选择目标机器，产生容器以及对容器的配置等等。所以说p s m 到p s u 的变换与特 定平台模型的细化相关，是对p s m 的求精。 5 ) p s m 到p i m 的变换。当要从现有的实现模型中抽取出抽象的平台无关模型的时候， 就需要用到p s m 到p i m 的变换，尽管可以开发某些工具完成这个过程。但是，从软件工 程的角度来看，这是一种逆向工程，类似于“模型挖掘”的过程，一般很难做到完全的 自动化。在理想情况下，从p s m 到p i m 的变换结果应该与p i m 到p s m 的变换结果相对应。 2 2 4m o a 开发模式 基于m d a 的开发首先关注于应用系统的功能和行为，而不是它将采用哪种具体的技 术来实现。m d a 使得业务逻辑和实现细节相分离。因此，每当一种新的技术( 例如) ( i i l s o a p ) 到来的时候，我们不必再重复对系统或者应用进行建模的过程，而其他架构往往都和某 种特定的技术或者平台捆绑在一起，无法达到这一目的。使用m d a ，我们对系统的功能 和行为的建模只需一次，而且是仅需一次。 在m d a 中，模型不再仅仅是描绘系统，扶助沟通的工具，而是软件开发的核心和主 干。为了从技术细节及其复杂实现中分类出相应特定的业务信息，m d a 依赖于2 个独特 的模型：平台无关模型( p i m ：p l a t f o r mi n d e p e n d e n tm o d e l ) 和平台相关模型( p s m ： p l a t f o r ms p e c i f i cm o d e l ) 。m i ) a 就是一种基于p i u 规范开发应用程序的方法。通过使 用不同的映射规则，一个p i m 可被映射成多个p s m 。他们之间有着抽象和求精的关系， m d a 的目标是通过模型精化消除不相关的抽象细节层次。模型之间通过模型映射机制相 互映射，从而保证了模型的可追溯性。 软件的开发和更新过程就是自顶向下，逐步求精的建模过程。首先由模型映射专家 将业务模型映射到平台无关的模型，然后由平台技术专家将平台无关模型映射到平台相 关模型。 m d a 的基本思想就是：一切都是模型，一切都由模型驱动。软件的生命周期就是以 模型为载体并由模型映射所驱动的过程。首先抽象出与实现技术无关、完整描述业务功 能的核心模型( p i l ) ，针对不同实现技术制订多个映射规则，通过这些规则及辅助工具 将p i m 转换成与具体实现技术相关的应用模型( p s m ) ，最后将p s m 转换成特定运行平台 太原理工大学硕士研究生学位论文 上的代码。 2 3m d a 技术框架 2 3 1m d a 的技术组成结构 m d a 的结构可以分为三个依次包容的圈层，如图2 - 4 所示，从里向外分别是核心 技术层、中间件技术层、公共服务层。 图2 - 4m d a 技术框架 f i g u r e2 4 i v i d at e c h n o l o g ya r c h i t e c t u r e 核心技术层包括统一建模语言( u n i f o r mm o d e l i n gl a n g u a g e ，u m l ，建模工具) 、元 对象设施( m e t a - o b j e c tf a c i l i t y 。m o f ，标准的建模与交换结构) 、公共仓库元模型 ( c o m m o nw a r e h o u s em e t a m o d e l ，c 删，数据仓库的标准) 、基于x m l 的元数据交换( ) ( h i l g e t a d a t ai n t e r c h a n g e ，x m i ，信息交换的标准格式) 等，这些核心技术直接面对系统结 构的架构。 中间件技术层包括c o p r a ，w e b s e r v i c e ，j a v a ，n e t ，) ( m i 蹦l 等。通过合适的映 射工具，可以从用m d a 核心技术表示出来的系统体系结构模型直接生成中间层代码。 公共服务层包