（计算机软件与理论专业论文）模型驱动构架中关联转换的研究.pdf

摘要 模型驱动构架是对象管理组织提出的一种新的软件开发方法，其 核心思想是模型通过变换自动产生代码。其中，模型变换的依据是模 型转换规则。在定义转换规则过程中，由于不同模型的关联关系在表 达形式上不一致，比较难以定义关联的转换规则。而现有的模型转换 规则在关联转换方面大多只是泛泛而谈。为了解决该问题，本文主要 研究了如何定义一套高质量的映射规则用于关联变换，并且设计与实 现了一个执行此规则的关联转换工具。 本文首先介绍了模型驱动构架开发方法的基本思想、概念、开发 过程以及相关标准。然后详细讨论了作为平台独立模型的u m l 类图中 的关联关系，并把它分为两类：普通关联和扩展关联。接着以一种模 型转换规则的语法和语义，采用q v t 标准中增量变换思想，定义了各 种关联从u m l 模型到j a v a 模型的转换规则。这套规则用伪代码的形 式描述，考虑到了每一种关联的每个细节，在规则的深度上和广度上 较之以往有很大的提高。最后，为了实现规则的转换功能，开发了一 个基于增量变换的关联模型转换工具。该工具完全按照规则中的内容 进行转换，用增量变换机制把各种关联从u m l 模型成功地变换为j a v a 模型，并且产生结果与期望的j a v a 模型相一致。 关键词模型驱动构架，关联，转换规则，转换工具，增量变换 a b s t r a c t m o d e ld r i v e na r c h i t e c t u r e ( m d a ) ，w h i c hw a sb r o u g h tf o r w a r db y o b j e c tm a n a g e m e n tg r o u p ，i san e wp a r a d i g mf o rs o f t w a r ed e v e l o p m e n t i t sc o r ec o n c e p ti st ot r a n s f o r mc o n c e p t u a lm o d e li n t oc o d ea u t o m a t i c a l l y t h em o d e l sa r et r a n s f o r m e db a s e do nt r a n s f o r l t lr u l e s d u r i n gt h ec o u r s e o fd e f i n i n gt r a n s f o r mr u l e s ，b e c a u s eo ft h ei n c o n s i s t e n te x p r e s s i n gf o r m s o fd i f f e r e n tm o d e l sa s s o c i a t i o n s i ti sh a r dt od e f i n ea s s o c i a t i o nt r a n s f o r m r u l e s s o m ee x i s t i n gm o d e lt r a n s f o r mr u l e so n l ym a k eg e n e r a ld e s c r i p t i o n o na s s o c i a t i o nt r a n s f 0 1 t n a t i o n i no r d e rt os o l v et h ep r o b l e m ，t h i st h e s i s s t u d i e sh o wt od e f i n eas u i to fe f f e c t i v em a p p i n gr u l e s f o ra s s o c i a t i o n t r a n s f o r m a t i o n ，t h e nd e s i g n sa n dr e a l i z e sat o o l ，w h i c hi m p l e m e n t st h e r u l e s ，f o ra s s o c i a t i o nt r a n s f o r m a t i o n f i r s t ，m d a sb a s i ct h o u g h t ，c o n c e p t s ，d e v e l o p i n gp r o c e s sa n d c o r r e l a t i v ec r i t e r i o n sa r ei n t r o d u c e di nt h i st h e s i s t h e na s s o c i a t i o ni n u m l sc l a s sd i a g r a m ，w h i c hi su s e da sp l a t f o r mi n d e p e n d e n tm o d e l ，i s d i s c u s s e di nd e t a i l a n di ti ss o r t e di n t ot w oc l a s s e s ：n o r m a la s s o c i a t i o n a n de x t e n d e da s s o c i a t i o n t h et h e s i sa d o p t si n c r e m e n t a lt r a n s f o r m a t i o n s t h o u g h ti nq v t , a n dd e f i n e sa s e to fr u l e s ，w h i c hi su s e di na s s o c i a t i o n t r a n s f o r m a t i o nf r o mit ，m o d e lt oj a v am o d e l b yu s i n gam o d e l t r a n s f o f i nr u l e sg r a m m a ra n ds e m a n t i c s t h i ss e to fr u l e si sd e s c r i b e di n p s e u d o c o d ef o r m ，a n dr e f e r st oe v e r ya s s o c i a t i o n sd e t a i l i t sd e p t ha n d e x t e n ta r em u c hm o r ei m p r o v e dt h a nb e f o r e a tl a s t t oi m p l e m e n tt h e a s s o c i a t i o nt r a n s f o r mr u l e s ，a na s s o c i a t i o nm o d e lt r a n s f o r m i n gt o o l ， w h i c hb a s e so ni n c r e m e n t a lt r a n s f o r m a t i o n i sd e v e l o p e d t h et o o lf u l l y a c t so nt h ec o n t e n to fr u l e st ot r a n s f o r l t l ，a n dc a l lt r a n s f o r me v e r y a s s o c i a t i o nf r o mu m lm o d e lt oj a v am o d e ls u c c e s s f u l l y , b yu s i n gt h e m e c h a n i s mo fi n c r e m e n t a lt r a n s f o r m a t i o n t h et r a n s f o r m i n gr e s u l ti s c o n s i s t e n tw i t he x p e c t a t i v ej a v am o d e l k e yw o r d sm o d e ld r i v e na r c h i t e c t u r e ，a s s o c i a t i o n ，t r a n s f o r mr u l e ， t r a n s f o r m i n gt o o l ，i n c r e m e n t a lt r a n s f o r m a t i o n l i 原创性声明 本人声明，所呈交的学位论文是本人在导师指导下进行的研究 工作及取得的研究成果。尽我所知，除了论文中特别加以标注和致谢 的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不 包含为获得中南大学或其他单位的学位或证书而使用过的材料。与我 共同工作的同志对本研究所作的贡献均已在在论文中作了明确的说 明。 作者签名：垦萱日期：! ! 丛年月卫日 关于学位论文使用授权说明 本人了解中南大学有关保留、使用学位论文的规定，即：学校 有权保留学位论文，允许学位论文被查阅和借阅；学校可以公布学位 论文的全部或部分内容，可以采用复印、缩印或其它手段保存学位论 文；学校可根据国家或湖南省有关部门规定送交学位论文。 作者签名：基鲎导师签名望垒至鳖日期：三! 年上月旦日 硕士学位论文第一章绪论 1 1 研究背景 第一章绪论 在计算机系统发展的早期时代( 6 0 年代中期以前) ，硬件的发展是其主流， 软件只是为每个具体的应用而专门编写的。这时的软件开发过程有诸多不健全之 处，比如：软件规模小；开发人员少且角色单一；只有源代码的生成，却无软件 相关的文档资料等等。 从6 0 年代中期到7 0 年代中期，软件产业表现出了“作坊”式开发特点。 这种开发过程虽然比以前的开发规模大，生产效率高，分工明确，但其基本上沿 用早期形成的个体化软件开发方法。随着计算机应用的日益普及，软件数量快速 增长，这种个体化开发方法开发出的软件，在许多方面暴露出严重的问题，特别 是在维护方面，严重耗费着资源，有些甚至成为不可维护的软件。由于软件开发 远远满足不了社会的需求，从而爆发一场“软件危机” 1 l 。 为了解决该危机，1 9 6 8 年北大西洋公约组织的计算机科学家在联邦德国召 开的国际会议上，首次提出了“软件工程”一词，希望用工程化的原则和方法来 克服软件危机【2 j 。所谓软件工程，是采用工程的概念、原理、技术和方法来开发 与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技 术方法结合起来【l 】。在此以后，人们开展了软件开发模型、开发方法、工具与环 境的研究，提出了瀑布模型、演化模型、螺旋模型、喷泉模型等开发模型，出现 了面向数据流方法、面向数据结构方法、面向对象方法等开发方法，以及一批 c a s e ( c o m p u t e ra i d e ds o f t w a r ee n g i n e e r i n g ) 工具和环境【3 1 。人们的这些努 力，解决了个体化软件开发方法带来的效率低下、质量得不到保证、难以维护等 许多问题，取得了很大的成功，使得软件产业有了一次质的飞跃。 然而，软件产业的发展并非一帆风顺，依然有问题等待着人们去解决。经过 分析，目前的软件开发中主要有以下几个最重要的问题亟待解决【4 】： 1 ) 生产效率问题：当今的软件开发过程常常是由低层的设计和编码驱动 的，它包含6 个阶段：( 1 ) 概念化和需求收集。( 2 ) 分析和功能描述。 ( 3 ) 设计。( 4 ) 编码。( 5 ) 测试。( 6 ) 部署。目前的一些软件开发方 法( 比如：增量开发、迭代开发、瀑布式开发等) 中，文档和图表都 是在前三阶段产生，一旦编码开始，这些文档和图表会很快失去价值， 它们与代码之间的距离会随着系统的进行越来越远。写文档和建模的 过程对于编写代码的贡献并不大，人们往往视其为负担，从而造成了 硕士学位论文第一章绪论 生产效率的低下。因此，如何把建模和代码的生成紧密地结合起来成 为了软件开发中一个研究的重点。 2 )可移植性问题：软件产业的发展非常快，每年都会有很多新技术被发 明并变得流行，许多公司为了追求新技术，使得自己的产品不停的更 新换代。然而，产品的更新会面l 临着两个严峻的问题：( 1 ) 如果产品 提供和新技术开发的系统相连的接口，随着新技术不断发展，产品不 一定能永远兼容该技术。且产品如果与某种技术紧密绑定，今后随技 术发展的道路将十分狭窄。( 2 ) 如果对于每种新技术，都用其重新开 发产品，代价也太大了。那么，如何使我们的产品跟上新技术的发展， 并且轻松自如，给人们留下了一个难题。 3 ) 互操作性问题：当今的技术呈现多元化发展，单一的系统可能有多项 技术实现，它们之间存在着互操作性问题；一个系统中多个组件之间 需要相互通信，它们之间也有互操作性问题；系统与系统之间需要交 流，同样有类似的问题。然而，不同的工具对元数据的管理均有自己 策略，这就给元数据共享形成了障碍，给解决互操作性带来了难题。 如何应对这些需求，能否有统一的解决方案呢? 4 )维护和文档问题：文档一直是软件开发的薄弱环节。大部分开发者觉 得他们的主要任务是编写代码，写文档既会浪费时间，降低开发速度， 又不会对当前的任务提供支持，只会为以后的任务提供帮助。没了主 观能动性，文档也就写不好，这是文档的质量总是不高的主要原因。 为了解决文档问题，目前，有一种从代码直接生成文档的工具。但此 工具只解决了低层次的文档问题，高层次的文档依然要手工维护。如 何实现所有文档都与代码同步且又不增加工作量呢? 为了解决软件开发过程中存在的以上种种问题，对象管理组织o m g 提出了一 种新的软件开发方法学一模型驱动构架( m o d e ld r i v e na r c h i t e c t u r e ，m d a ) ， 它有利于实现系统集成和互操作、解决遗留系统问题、适应业务逻辑的迅速变更 并缩短开发时间【5 1 。在m d a 中软件开发过程是由对软件系统的建模行为驱动的。 它之所以称为模型驱动是因为它是一种使用模型来指导系统的理解、设计、构造、 开发、操作、维护和修改的方法【6 j 。 m d a 框架中主要元素有模型、语言、变换、变换定义以及变换工具，其中， 模型是系统的描述，扮演着十分重要的角色，它可分为平台无关模型( p l a t f o r m i 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 ) 。 p i m 描述了系统的功能和结构，独立于任何实现技术；而p s m 在特定的目标平台 上对系统进行描述，它与系统实现技术相关( 比如：n e t ，j 2 e e ，c + + 等) ，包含 硕士学位论文 第一章绪论 了最终实现平台的全部知识【，j 。 m d a 开发过程为：首先，使用平台无关的建模语言( 例如u m l ) 搭建p i m ， 然后通过p i m 到p i m 的反复映射，对其进行精化，这种映射可以是全人工的，也 可以在规则的指导下进行，还可以通过一些变换工具自动完成。得到的精化的 p i m 再根据基于特定平台的变换规则，将p i m 变换为p s m ，最终根据p s m 到代码 的映射规则生成应用程序代码和测试框架，如图卜i 所示。 图i - 1m d a 开发过程 m d a 方法的特点是模型转换由变换工具自动完成。现有许多工具可以把p s m 变换成代码，比如市面上的一些代码生成工具，用户只需定义平台相关模型( j a v a 模型、关系数据库模型等) ，工具就能自动产生代码；而m d a 还能实现p i m 自动 变换到p s m ，这样软件开发人员只需用u m l 定义系统的p i m ，即可通过变换工具， 产生相应平台上的代码。 用建模语言作为编程语言的m d a 方法，大幅度地提高了建模在软件开发过程 中的地位。开发人员只需用建模语言对系统建模，就可利用m d a 工具开发商提供 的变换工具自动产生代码，省去了大量的编码时间，提高了生产率，改善了质量。 同时，开发人员会把大量的注意力集中到需求分析和设计上，而不必过多关注具 体的实现细节，这样会使得系统更加符合客户需求。m d a 方法还把软件开发提升 到更高一级的抽象级别一模型级别，从而达到分离问题域业务逻辑和具体实现 平台的目的，保护我们建立好的“业务逻辑”，避免了“平台易变性”的风险。 在模型变换过程中，变换工具不仅生成模型，还生成不同平台模型之间的桥接器， 用以包含平台之间联系的全部信息，这样就可以把一种平台的模型变换到另一种 平台，很好地解决了跨平台的互操作性【8 】o 总之，m d a 开发方法是软件产业中的 一场革命，对其各方面都带来了深远的影响。 1 2 研究方向的提出 m d a 方法的核心功能是模型的自动转换，要实现这一点，必须有一个功能强 大的变换工具来保证。而变换工具只是执行变换规则的载体，规则定义的质量高 低直接决定着变换工具的好坏，也决定m d a 思想能否成功地实现。因此，为自动 转换定义一套具有标准语法和执行语义且完备的变换规则是至关重要的。 硕士学位论文第一章绪论 在模型转换的过程中，p i m 的完备性、一致性、无二义性要求非常高，达不 到这些要求就无法从p i m 生成p s m 。而u m l 是当今最流行的建模语言。它融合了 众多建模方法的长处，扩展了建模方法的应用范围。在软件开发过程中，从分析、 设计、实现到部署都可以用u m l 来进行可视化建模。u m l 作为o m g 的可视化建 模语言，已经成为信息模型的标准。所以，u m l 成为搭建p i m 的首选【9 】。 u m l 描述的p i m 中的类、属性、操作等概念与目标代码中的相应概念直接对 应，比较容易定义变换规则；而关联、聚合、依赖等概念却与代码中的表达形式 出入较大，很难定义变换规则，且它们自身含有很多子信息，如何把这些信息转 换成代码层上的信息也是一个难题u o 。因此，为其定义一套准确又高效的变换规 则成为了模型到代码转换规则定义的难点。 本文重点研究了u m l 类图中关联关系的各种分类及其两种实现模式，采用一 种基于o m g 组织发布的q v t 标准的变换语言，定义了所有的关联关系从u m l 模型 到j a v a 模型转换规则，最后，设计并实现了一个针对关联的变换工具，证明了 规则的可行性。 1 3 国内外研究现状 在模型驱动构架这种开发思想刚提出来后的一段时间里，许多公司和研究单 位为了实现它，纷纷提出了自己的变换规则，这些变换规则在一定程度上促进了 m d a 的发展，为开发m d a 工具提供了很多参考依据。然而，这些规则各有各自的 变换规则定义语言，各有其长处与短处，一时间让m d a 工具开发商无从取舍。 为了实现模型变换规则的标准化，国际标准组织o m g 在2 0 0 2 年4 月2 4 日发 布了一项基于元对象设施m o f ( m e t ao b j e c tf a c i l i t y ) 2 0 版本的q v t 提案请 求r f p ( r e q u e s tf o rp r o p o s a l ) 。 所谓q v t ，是英文q u e r y ，v i e w sa n dt r a n s f o r m a t i o n s 的缩写，中文的意 思是查询、视图和转换i l ”。它们是o m g 从m o f 中抽象出来的三个相互关联的层次 模型。 查询是模型上的查询，决定了变换( 规则) 何时、如何应用到一个模型( 或一 组模型) ，以及如何建立转换结果。它相当于模型转换的约束条件，当用u m l 建 立p i m 时，一般采用与其配套的对象约束语言o c l 作为模型转换的查询语言。 对于视图，o m g 有两种解释，其一是查询产生的一个结果，也就是，视图是 查询结果的可视化。其二是变换结果的可视化。无论是哪一种，对于视图的操作， 也即是对模型的操作，视图相当于模型经过转换或者查询后的一个投影。这一点 和数据库中表的视图很相似。 转换是q v t 标准中最重要的一部分，含义是符合了查询条件的模型经规则变 4 硕士学位论文第一章绪论 换到另一个模型。其中，转换规则是十分重要的，它有以下几个衡量规则定义质 量高低的属性： 完备性。转换规则是否涵盖了模型所有元素的所有情况，是否有足够的说明 文档和示例。 可度量性。规则是否可以通过标准或者工具来度量其优劣。 简单性。作为标准的转换语言是否易于理解和使用的，否则程序员就不能自 由的进行开发。 双向映射。是否不仅源模型可以通过规则转换到目标模型，同时，目标模型 还可以转回源模型。 加工处理。用规则对模型进行转换的时候可能会遇到模型协调、失败处理、 一致性检查和模型综合等等问题，规则是否允许通过修改，解决上述问题。 o m g 组织提出的q v t 的r f p ，目的就是让各大厂商按照q v t 标准制定模型的 转换规则。到现在为止，一共收到有8 个q v t 提案，其中3 个已经完成，其余5 个还在进一步的修改中。这些提案分别是：a d a p t i v el t d ( a d a p t i v e ) ；d s t c i b m ( d s t c ) ： c o m p u w a r ec o r p o r a t i o n s u nm i c r o s y s t e m s ( s u n ) ： a l c a t e l s o f t e a m t n i v a l i o s y s t h a l e s ( t h a l e s ) ：k e n n e d yc a r t e r ( k c ) ；t c s ， w h i c hc o m p r i s e sa r t i s a n s o f t w a r e ，k i n e t u m ，k i n g sc o l l e g e ，a n d t h e u n i v e r s i t yo fy o r k ( t c s ) ：c o d a g e nt e c h n o l o g i e sc o r p o r a t i o n ( c o d a ) ； i n t e r a c t i v eo b j e c t ss o f t w a r eg m b h p r o j e c tt e c h n o l o g y ( i o ) 1 2 1 8 】。 这些提案中的变换规则基本符合q v t 标准，虽然在规则的语法和语义上，各 有各的特点，但总设计思路是一致的。这些规则可做为m d a 工具的模型转换依据。 q v t 标准按照变换对象的性质，将变换分为简单变换和复杂变换。简单变换 是把源模型中的单一元素转换为目标模型中的单一元素。常见的是，源和目标模 型本质上有相同的结构，比如：从u m l 类图中类、属性和操作到j a v a 类、字段 和方法的变换就为简单变换。这些变换是直接的，比较容易制定转换规则。 而复杂变换则是指源模型的元素和目标模型的对应元素结构上不同，要复杂 的运算方法才能实现的模型变换。u m l 类图中类与类之间关系的变换就为复杂变 换。复杂变换的变换规则较难定义。 上述8 个q v t 提案中的变换规则在简单变换方面完成得比较好，对类、属性、 操作等元素的转换规则均有定义。但在类与类之间关系这个复杂变换方面做得远 远不够，尤其是关系之一关联的转换。 它们几乎全部只定义了u m l 类图中一般关联模型的变换规则，仅是将关联关 系做一个笼统的变换，对于其他的关联模型并未涉及，也没有做深入的研究。既 没有考虑到关联的方向性，比如：单向导航关联、双向导航关联；也不考虑关联 硕士学位论文第一章绪论 的多重性，比如：一对一关联、一对多关联和多对多关联：更加没有考虑特殊关 联的情况，比如：三阶关联、有序关联、聚合等等。这样的变换规则对于工具开 发商是不利的，只会产生两种结果：开发商要不需要自己按照规则的语法定义所 有的关联关系变换规则，再按规则开发模型转换工具；要不直接按照原规则开发 工具，但这样的工具只适用于普通关联模型，一旦系统建模过程中，出现复杂的 关联模型时，工具将无法对其进行变换。 1 4 本文主要研究内容及意义 为了解决目前基于q v t 标准的模型变换规则在关联转换方面存在的问题，本 文主要做了以下3 个部分的研究工作： 1 ) 深入地研究了u m l 类图中的关联关系。 本文介绍了u m l 类图中类与类之间关系的基本概念和分类，重点讨论了关联 关系。按关联不同的性质，对其进行不同的划分，并且详细地介绍了每种特殊关 联模型，还提出了关联的两种实现模式一隐式实现模式和显式实现模式。 2 ) 用一种基于q v t 标准的变换规则定义语言，使用q v t 标准中增量变换思 想，定义了所有关联模型从p i m 到p s m 的转换规则。 采用八个q v t 提案之一的变换规则t c s 的语法和语义，按照增量变换的思想， 首先定义普通关联中隐式关联从u m l 模型到j a v a 模型的转换规则，然后定义显 式关联和每一种特殊关联与隐式关联不同之处的转换规则。这两部分规则合在一 起形成所有关联模型的转换规则。至于除关联外其它类与类之间关系的转换规 则，虽然这些关系也属于复杂变换，但它们包含的内容较少，变换模式单一，远 不如关联关系变换复杂，其转换规则也不难定义。因此，本文不定义这些关系的 转换规则。 3 ) 按照定义的关联转换规则，设计并实现了一个基于增量变换的关联模型 转换工具，验证了规则的可实现性。 该转换工具以关联转换规则为基础，根据用户定义的u m l 关联模型，用增量 变换的机制生成相应的j a v a 模型。它很好地演示了关联变换的过程，验证了规 则的可行性，并且展现了m d a 开发模式的优越性。 本研究主要有三方面的意义： 1 ) 解决了模型转换规则定义过程中，关联转换规则定义这个难题。 2 ) 对基于q v t 标准的模型转换规则在关联关系转换方面做了完全的补充， 并用增量变换思想改进了转换规则，使得m d a 中的关联转换在深度上和广度上有 了很大的提高。 3 ) 开发的关联转换工具支持增量变换，填补了现有的转换工具在该方面的 硕士学位论文 第一章绪论 空白，提高了模型转换的效率。 1 5 论文的组织 论文全文共分为七章： 第一章绪论。主要介绍m d a 的相关知识，提出了研究课题，并讨论了该课 题国内外的研究现状，阐述了论文的研究内容及其意义。 第二章主要介绍了m d a 的一些基本概念和开发流程，以及u m l 、c w m 、m o f 等m d a 中的核心技术。 第三章全面讨论了u m l 类图中的关联关系的概念及其分类，提出两种关联 实现模式，为第四章定义其转换规则打下基础。 第四章用一种基于q v t 标准的规则语言，并使用增量变换思想，按照第三 章介绍的关联模型，定义其从u m l 模型到j a v a 模型的转换规则。 第五章以第四章定义的规则为基础，对一个基于增量变换的关联转换工具 进行设计与分析。该部分包括：系统的设计思想、系统整体架构、主要模块的功 能以及x m x 引擎模块的设计过程。 第六章讨论了该关联转换工具的实现方法，包括：开发系统所用的工具和 技术、数据库设计和转换模块的实现。并用工具做了具体的关联转换，验证了工 具的模型转换功能。 第七章结束语。对所做的研究工作进行了总结，并阐述了未来需要进一步 研究的方向。 硕士学位论文 第二章模型驱动构架开发方法 第二章模型驱动构架开发方法 模型驱动构架是对象管理组织提出的一种新的软件开发方法。它是目前软件 工程中主要研究的热点之一。本章着重讨论了模型驱动构架中的主要概念以及开 发过程，并且介绍了u m l 、m o f 、c w m 、x m i4 个m d a 中的核心规范。 2 1m d a 概述 在上一章中提到的对象管理组织( o m g ) 成立于1 9 8 9 年，是以上百家大小公 司构成的非盈利的开放性组织。它的工作重点是为企业分布式应用系统提供开 放的、与开发者无关的互操作性规范，帮助计算机用户解决跨平台问题。在2 0 0 2 年初，为了解决企业间跨平台计算的要求，o m g 宣告模型驱动构架( m d a ) 是它 新的战略方向，将m d a 带入了人们的视野。 模型驱动体系结构是一种i t 系统规范的方法，它分离了系统功能的规范和 系统的具体实现，其核心思想是通过模型问的变换，达到开发软件的目的。m d a 方法抽象出与实现技术无关、完整描述业务功能的核心模型，针对不同实现技 术制定多个映射规则，然后通过这些映射规则将核心模型转换成与具体实现技 术相关的应用模型，最后，再将应用模型自动转换成代码。同时，通过不同技 术实现的应用模型间的桥接器，将应用模型联系在一起，这样就促进了集成和 互操作性，并且支持随着平台技术变迁的系统演化。 m d a 开发过程是一个从抽象到具体的过程，核心模型的抽象层次最高，独 立于任何实现技术，应用模型次之，代码模型是具体的系统实现。m d a 认为系 统开发最好的方式是隔离系统设计与系统实现，独立建模业务行为和领域元素， 关注系统应用本身而不是将中间件平台作为系统开发的中心，这一点与目前很 多基于中间件技术开发的思想有很大不同。 m d a 框架中主要元素有：模型、p i m 、p s m 、变换、变换定义、变换定义语 言以及变换工具，下面本文依次介绍这些重要的概念。 2 2m d a 中主要概念 2 2 1 模型 在m d a 中，模型是其关注的焦点和核心。那什么是模型呢? 模型是以精确定 义的语言对系统( 或系统的一部分) 做出的描述。它包含两方面内容：首先， 模型是一种系统规约1 9 1 ，是对系统各个方面的抽象，既包含对系统结构的描述， 硕士学位论文第二章模型驱动构架开发方法 又包含对系统功能或行为的描述；其次，描述使用精确定义的语言。这种语言 必须是形式化的，具有精确的语法和无歧义的语义。这样的语言适合计算机自 动解释。 在当前的软件开发过程中，一般采用u m l 语言为系统建立模型，因此，大 多数人对模型的印象是用u m l 描绘的一系列图表。当然，由于其自身的很多长 处，u m l 已成为可视化建模的标准语言，然而，模型并不仅限于此，只要是使 用精确定义的语言对系统的描述皆可称为该系统的模型。描绘系统的可视化的 图表是模型，而用c ，c + + ，j a v a 等编程语言编写出系统的源代码也是软件的模 型，称为代码模型【2 0 1 。这两种模型虽然是对同一系统的描述，但两者问的抽象 层次却不同。图表模型抽象层次高，代码模型的层次低，与平台高度相关；前 者是抽象描述，后者是具体实现。为了解这两种模型与m d a 方法有何联系，在 m d a 中扮演什么样的角色，首先要弄清楚“平台”的概念，在下一节我们将具 体介绍什么是平台。 2 2 2 平台 “平台”是多种技术的集合，提供各种功能接口，它是通用的、和具体技 术相关的( 例如：j a v a ，c # ，x m l 等) ，特定于软件提供商的( 例如：微软的n e t 平台、s u n 的j 2 e e 平台等) 。 在某些场合，平台是操作系统和相关的工具；在某些场合，平台是按良好 的规范定义的技术架构，如：n e t 或者j 2 e e ；它还有可能是某些硬件拓扑实例。 m d a 中对于平台有新的解释，它包含了以下技术： 1 ) 信息格式化技术，比如：x m ld t d 和x m ls c h e m a 。 2 ) 3 g l 和4 g l ，也就是，第三代编程语言和第四代编程语言，比如：j a v a 、 c + + 等。 3 ) 消息处理中间件，比如：w e b s p h e r em qi n t e g r a t o r 和j 2 e e 中消息驱 动b e a n 。 4 ) 分布式组件中间件，比如：d o tn e t 、c o r b a 和j 2 e e 。 只要与其中一样技术有联系，称之为平台相关；与以上所有技术均无联系 的，称为平台无关。根据模型与平台的耦合关系，m d a 中模型可分为：计算独 立模型( c i m ) 、平台无关模型( p i m ) 、平台相关模型( p s m ) 和代码模型。下面 几节依次介绍这几种概念。 2 2 3 计算独立模型 计算独立模型( 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 ，c i m ) 是独立与软件 9 硕士学位论文 第二章模型驱动构架开发方法 的模型，是从用户视角来描述特定领域面临的问题、系统需求的模型。c i m 可 能包含系统的数据信息等，它代表软件生命周期中的需求模型。 2 2 4 平台无关模型 平台无关模型( 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 i m 的目标平台必须是一个技术无关的虚拟机。虚拟 机提供了许多平台无关的通用服务，例如文件服务、安全服务等，它们可以在 多个特定的平台上被实现。p i m 代表软件生命周期中的分析模型。 2 2 5 平台相关模型 平台相关模型( p l a t f o r ms p e c i f i cm o d e l ，p s m ) 是用某种特定技术描述 系统的模型，由系统的数据、处理进程等平台相关信息组成。它代表了软件生 命周期中详细的设计模型。 2 2 6 变换 在模型驱动开发方法中，“变换”指的是模型之间的变换。以上介绍的一 些模型在m d a 中扮演着不同的角色，为了实现由模型自动生成代码，我们需要 将这些模型按一定顺序从一个模型自动转换到另一个模型，这样的过程称为模 型变换。其中，被变换的模型称为源模型，变换产生的模型称为目标模型。 当然，模型变换并非随意变换，它是按照严格的变换定义执行的。所谓变 换定义，是一组变换规则，这些规则共同描述了源模型是如何变换为目标模型 的。由于m d a 中p i m 使用特定的u m l 来描述的，所以m d a 中的模型变换规则主 要是针对u m l 模型的。 变换定义相当于一个函数，源模型是函数的参数，目标模型是函数的结果。 为了使函数自动运行，必须有一个执行函数的载体，通常把这个载体称为变换 工具。该工具按照变换定义为源模型执行变换，产生目标模型。变换工具是m d a 工具中最核心的部分，是实现其开发思想的关键所在。 2 2 7 变换规则定义语言 规则定义语言是一种书写变换规则的语言，它包含一定的语法和语义。由于 规则要求可以被变换工具解释和执行，因此，描写规则的语言必须要有高度形 式化的语法和简明无歧义的语义，这一点与可以被编译器理解的程序设计语言 o 硕士学位论文第二章模型驱动构架开发方法 类似。 2 3m d a 开发生命周期 m d a 开发方法的生命周期主要可分为两个阶段：一、建模阶段，即采用可 视化建模语言按需求为系统建立模型。二、模型转换阶段，将建立好的模型按 照变换规则，逐步转换，逐步求精，最终生成目标代码【2 1 2 2 1 。图2 1 描述了m d a 生命周期。在以下两个小节中，将分别介绍这两个阶段。 2 3 1 建模阶段 图2 - 1m d a 开发生命周期 此阶段主要是人工行为，包括两个步骤：1 p i m 的建立。2 p i m 到p i m 的 变换。p i m 分析员首先从计算独立模型( c i m ) 抽取出相关业务信息，根据各种 概要规范，使用可视化建模语言，例如：u m l ，编辑产生平台无关模型( p i m ) 。 此模型按照需求分析，详细地描绘了需要开发的系统，但与系统具体的实现技 术无关。如果用u m l 为系统建立p i m ，其中，u m l 类图和对象图表示结构，顺序 图和活动图说明行为，类和对象的名称及其语义符号表达了业务元素，模型的 其他方面指明了组件结构和行为中的平台无关方面。 然而，初次建立起来的p i m 仅仅是基础模型。一个m d a 模型包含多个层次 的p i m ，每个p i m 包含了平台无关的技术行为的内容，而基础模型只表示业务 功能和行为，因此，需要p i m 分析员对基础p i m 进行求精和特殊化，得到每一 层次的p i m 。在m d a 开发过程中，此步骤称为p i m 到p i m 的转换。同时，初步 建立的基础p i m 在很多方面需要改进，这也需要分析员对基础模型求精，过滤， 进行基础p i m 到目标p i m 的变换。 经过以上两个步骤，一个描述系统功能并且可以被变换工具执行变换的分 析模型就建立起来了。 硕士学位论文 第二章模型驱动构架开发方法 2 3 2 模型转换阶段 这个阶段是m d a 开发过程中的主要阶段，基本上是利用变换工具对位于不 同抽象层次的模型进行转换的过程，此阶段包含4 个步骤，分别是：1 p i m 到 p s m 的变换。2 p s m 到p i m 的变换。3 p s m 到p s m 的变换。4 p s m 到代码的变 换。下面将依次介绍这四个步骤。 1 ) 首先是平台无关模型到平台相关模型的转换。在这个过程中，将建模阶 段中产生的p i m 通过变换工具执行变换，生成一个或多个p s m 。p s m 是为某种特 定实现技术量身定做的，在p s m 中使用这种技术中可用的实现构造来描述系统。 这里有一个p i m 到p s m 变换具体的实例：如果开发一个三层模式的w e b 应 用，我们需要建立关系数据库来存储业务数据，建立w e b 表示层来处理表示逻 辑，建立e j b 对象业务层处理业务逻辑。同时，构造p i m 向这三种p s m 的映射 机制，并把p i m 模型分别向这三个数据结构进行映射。在生成的不同的p s m 之 间，还有桥接器，为p s m 之间建立联系，交流数据，使得整个系统成为一个有 机的整体。 从p i m 变换成一个或者多个p s m ，是m d a 中最复杂，也是最重要的一步。 2 ) p s m 到p i m 的转换。有时候从p i m 自动生成的p s m 并不能使程序员满意， 他们会根据平台的特性对p s m 加以修改，对p s m 的改变也会反映到p i m 中去， 因此就需要p s m 到p i m 的转换。从p s m 到p i m 是一个逆向工程，目前还没有比 较好的变换工具完成此过程，仍然停留在手工操作的水平上。在理想情况下， 从p s m 到p i m 的变换结果与p i m 到p s m 的变换结果相对应。 3 ) p s m 到p s m 的变换。在得到了p s m 以后，为了使生成器生成质量更高的 代码，需要对p s m 进行不断的精化，这就用到了p s m 到p s m 的转换。比如：通 过选择不同的服务配置对组件进行封装，在封装完成以后，就要对组件初始化， 选择目标机器，产生容器以及对容器配置等等。目前，这个变换过程也基本上 是由人来完成，未能实现自动化。 4 ) 最后，p s m 到代码的变换，由模型生成最后的代码。现在市面上已有一 些工具，如：r a t i o n a l 公司的r a t i o n a lr o s e ，i b m 公司的o p t i m a l j ，以及b o r l a n d 公司的t o g e t h e r ，它们可以把p s m 模型自动生成代码，并编译成可执行模块。 同时，通过在系统模型中指定的配置信息，m d a 工具将自动组合编译文件和配 置文件，通知应用服务器如何配置环境和部署程序。 2 4m d a 的核心规范 m d a 中有四个核心规范，分别是：u m l ，m o f ，c w m 和x m i ，它们使得m d a 技 硕士学位论文第二章模型驱动构架开发方法 术成为了可能。为了高效使用m d a ，了解其核，t l , 规范是必要的。下面，我们详 细地介绍这些规范的内容，在m d a 中的地位及其所起的作用。 u m l 是由r a t i o n a l 软件公司的r u m b a u g h 、j a c o b s o n 和b o o c h 合作发明的 面向对象的建模语言矧。o m g 组织不断的为它进行标准化，先后提出了若干的 版本，目前u m l 2 0 是最新版。 u m l 是实现m d a 技术的一把钥匙：使用m d a 技术创建的所有应用程序都基 于标准化的、平台独立的u m l 模型。通过将这一通用的、被普遍接受的建模标 准作为杠杆，m d a 使得开发人员可以创建能被方便地访问、具有良好的互操作 性的应用程序。 在m d a 中使用u m l 的方式有两种： 1 ) 开发人员使用u m l 来对系统进行建模，产生p i m 。使用u m l 建立的模型 必须具有一致性和精确性，能够被m d a 工具理解并能够被转换成模型和代码。 2 ) 软件架构师需要定义用于指导模型转换的规则。他们不开发某个特定系 统的模型，而是创建将一种模型转换到另一种模型的规则，这种规则是可以作 用于任何模型和不同的系统的。软件架构师必须对u m l 语言的原理和使用有深 刻的了解，同时还必须熟悉u m l 元模型，因为元模型是用来定义转换规则的重 要元素。 2 4 2m o f 元对象设施( m o f ) 是u m l 的姐妹标准，由同一个标准组织o m g 维护。它是 一种面向对象的元一元模型，为规约面向对象元模型定义了一种公共的抽象语 言。m o f 是用来定义面向对象元模型的基本元素、语法和结构，换句话说，由 m o f 定义的元模型可以用来建模其他语言，比如：u m l 的元模型就是用m o f 建立 的。因此，m o f 也是一种面向对象的建模语言，只不过，它的抽象级别高于其 他的建模语言。 以m o f 定义的面向对象元模型，可以通过交换元数据来实现互操作。m o f 为各种元模型提供了一种通用的语言基础，使它们不再是孤立的，而是可以相 互映射，相互交换元数据，并相互理解。 m o