(计算机软件与理论专业论文)面向方面模型驱动开发的研究.pdf_第1页
(计算机软件与理论专业论文)面向方面模型驱动开发的研究.pdf_第2页
(计算机软件与理论专业论文)面向方面模型驱动开发的研究.pdf_第3页
(计算机软件与理论专业论文)面向方面模型驱动开发的研究.pdf_第4页
(计算机软件与理论专业论文)面向方面模型驱动开发的研究.pdf_第5页
已阅读5页,还剩63页未读 继续免费阅读

(计算机软件与理论专业论文)面向方面模型驱动开发的研究.pdf.pdf 免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

硕士学位论文面向方面模型驱动开发的研究 面向方面模型驱动开发的研究 专业:计算机软件与理论 姓名:陈强超 指导老师:李文军教授 摘要 平台技术有效屏蔽了底层操作系统及编程语言的复杂性,大大减轻了技术上的负 担。然而,开发人员仍然需要了解具体平台的编程模型和编程接口,在编码实现 时,这些平台相关的细节常常和业务逻辑混杂在一起,大大降低了软件的可读性、 可复用性、可扩展性和可移植性。随着平台日趋多样化和复杂化,软件开发的学 习代价越来越大,开发的效率难于提高,从而阻碍了新技术的推广使用 为解决这些问题,本文把用于简化网格服务开发的模型驱动方面框架( m d a f ) 扩 展成一个通用框架,以开发基于平台的应用软件。在这个方法中,表达业务需求 的u m l 模型经c a s ei 具导出为x m i 格式的文件作为m d a f 的输入,以生成 组具体平台相关的代码以及文件。开发人员无须掌握平台相关的专门知识,需 要完成工作仅仅是建模以及不涉及平台细节的业务逻辑代码开发 m d a f 综合使用模型驱动架构( m d a ) 和面向方面编程( a o p ) 技术的方法,帮助应 用软件从平台无关模型自动转换到代码,实现了模型层次和代码层次上业务逻辑 和平台细节相分离的目标,使得基于平台的软件变得易于开发、测试以及维护 本文以m d a f 框架应用到j 2 e e e j b 平台的软件开发为例来展示m d a f 的有效 性及其优点。 关键词;模型驱动架构;面向方面编程;平台;软件开发 硕士学位论文 面向方面模型驱动开发的研究 t h er e s e a r c ho f a s p e c t - o r i e n t e d m o d e l d r i v e n d e v e l o p m e n t m a j o r :c o m p u t e rs o f t w a r ea n dt h e o r y n a m e :q i a n g c h a oc h e n s u p e r v i s o r :w e n j u nl ip r o f e s s o r a b s t r a c t p l a t f o r mt e c h n o l o g i e sh a v ee f f e c t i v e l yr e d u c e dt h eb u r d e no fd e v e l o p e r sb y c o n c e a l i n gt h eu n d e r l y i n go sa n dp r o g r a m m i n gl a n g u a g e s h o w e v e x , d e v e l o p e r ss t i l l h a v et ob ef a m i l i a rw i t ht h el o w - l e v e la p sa n dt h ep r o g r a m m i n gm o d e l so ft h e s p e c i f i cp l a t f o r m s t a n g l i n gw i t hb u s i n e s sl o # c , t h e s ep l a t f o r m - r e l a t e dd e t a i l s d e c r e a s et h er e a d a b i l i t y , r e u s a b l i t y , e x t e n d i b i l i t ya n dp o r t a b i l i t yo f t h ea p p l i c a t i o n a s t h ep l a f f o r m sb o c a ) m m o r ea n dm o r ec o m p l e xa n dv a r i e d , t h ed e v e l o p i n ge f f i c i e n c y i sb r o u g h td o w na n dt h el e a r n i n gc | l l l v ef o rn e wc o m e r si sq u i t es t e e p ,h e n c et h e s p r e a do f n e wt e c h si ss l o w e dd o w n 1 oa d d r e s st h e s ei s s u e s , am o d e l d r i v e na s p e c tf r a m e w o r k ( m d a f ) t of a c i l i t a mt h e d e v e l o p m e n to f g r i da p p l i c a t i o ni se x t e n d e di nt h i sp a p e rt os u p p o r tt h ed e v e l o p m e n t o fc o m m o np l a t f o r mb a s e da p p l i c a t i o na c c o r d i n gt ot h i sa p p r o a c h , t h eu m lo u t p u t i nx m if o r m a td e r i v e df r o mac a s et o o li su s e d 鹤t h ei n p u to ft h ef i , a m c w o r kt o g e n e r a t eas u i t eo fs o t l r c 宅c o d ea n dr e l a t e ds e t t i n gf i l e s d e v e l o p e r sn c _ g d i l te x p e r t k n o w l e d g eo ft h ep l a t f o r m ;a l lt h e ,h a v et od oi st h ep i mm o d e l i n ga n dt h e i m p l e m e n t a t i o no f b u s i n a s si o l g i c ,w h i c hi sr i c eo f p l a t f o r md e t a i l s b e n e f i t i n gf r o mt h ec o m b i n a t i o n o fm o d e l d r i v e na r c h i t e c t u r e ( m d a ) a n d a s p e c t - o r i e n t e dp r o g r a m m i n g ( a o p ) ,m d a fh e l p st oa u t o m a t et h et r a n s f o r m a t i o n f r o mt h ep i mt os o u r c o d e t h ef r a m e , y o r ke n a b l e sab c c t e rs e p a r a t i o no f b u s i n e s s l o g i ca n dp l a t f o r ms p e c i f i cd e t a i l sa tb o t hm o d e la n dc o d el e v e l s , w h i c hm a k e si te a s y t od e v e l o p , t e s ta n dm a i n t a i np l a t f o r mb a s e da p p l i c a t i o n s ac a s es t u d ya p p l y i n g i i i 坝j + 学位论史 t h er e s e a r c ho f a s p e c t - o r i e m e dm o d e l d r i v e nd e v e l o p m e n t m d a ft ot h ed e v e l o p m e n to fj 2 e e e j ba p p l i c a t i o ni sp r e s e n t e dh e r et od e m o n s t r a t e t h ee f f e c t i v e n e s sa n d a d v a n t a g e so f m d a f k e yw o r d s :m d a ;a o p ;p l a t f o r m ;s o i t w a r ed e v e l o p m e n t i v 硕土学位论文面向方血模型驱动开发的研究 第一章综述 1 1 引言 平台是指与系统基础功能无关的技术细节,它通过接口和特定的使用模型向搭建在平台之 上的各种应用提供功能和服务,这些应用不需要共l 坪台所提供的功能和服务的实现方式。 底层的细节与用户的业务没有直接关系,但又是必须解决的,需耗费大量的时间和精力。 平台的作用就在于将应用软件所要面临的共性问题进行抽象,屏蔽底层的技术细节,为上 层的应用程序提供一组比较通用的接口,形成个相对抽象与稳定的编程环境。比如中间 件的出现就是为了隔离操作系统、数据库以及网络环境下异构系统等差别而形成的个可 供应用软件复用的部分。利用这些平台技术有助于减少程序设计的复杂性,减轻应用软件 开发者的负担,保证应用软件的相对稳定,提高应用软件的可扩展性及可移植性,从而达 到保护企业的投资的目的。 平台无关是指匣用软件可以不作修改鲍运行在不同平台上,是实现软件可移植性、提升软 件价值的关键因素之一平台无关的概念是相对的:对于硬件和操作系统来说,高级语言 是平台无关的;而对于高级语言来说,中间件是平台无关的。由于中间件也种类繁多,本 文中的平台指的是中间件以及其之下的高级语言、操作系统、数据库以及硬件等等。 1 2 存在的问题 当今信息系统的开发越来越复杂,而且所涉及到的领域也越来越广,特别是随着分布式和 中间件的发展,各种平台技术不断涌现并演化完善,这为构建复杂的、异构的软件系统提 供可能,但当前基于平台技术的软件开发仍然存在不少问题。 1 2 1 技术规范过于庞大、复杂 平台技术在设计时往往需要考虑大量的函荔以支持各种复杂的砬用。比如,个分布式 顾i :学位论文 t h er e s e a r c ho f a s p e c t o r i e n t e dm o d e l - d r i v e nd e v e l o p m e n t 平台技术规范需要定义通信、资源定位及管理、资源访问、故障恢复、对象持久性以及事 务等模块。这些技术规范经常会包含大量的与平台相关的编程接口与模型,从设计、实现 直到部署运行经常要使用到各种编程语言、接口定义语言、数据库定义语言、配置描述语 言等等。开发人员要对许多架构和协议深刻理解并掌握这些底层接口和各种语言才能进行 相应的丌发,高昂的学习代价常常令人望而却步。尤其当缺少相应的集成丌发环境时,开 发效率难于提高,这阻碍了新技术的推广使用。 1 2 2 业务逻辑代码与平台相关代码相混杂 当前主流的软件开发模式采用的是面向对象技术。这种方法仅仅是对业务逻辑进行关注分 离的一维分解方法,平台相关的横切关注点会分散在业务逻辑的各个代码模块中。另外, 业务逻辑为得到平台容器的运行支持,也需要包装在平台组件之中。这样,就造成业务逻 辑与平台相关代码混杂在起,难于分开。于是,开发人员必须同时掌握业务逻辑和平台 相关等横切关注的编程,经常疲于应付平台相关的细节而无法专注于业务逻辑的实现与优 化,从而降低了软件的质量与开发效率。业务逻辑和平台细节的耦合问题是当前基于平台 的软件开发存在的各种问题的根源,软件开发效率的提高最终取决于这个问题的妥善解决。 1 2 3 平台种类繁多,更新迅速而经常不兼容 软件平台技术种类繁多,由于规范和厂商的不同,不同平台上的应用软件往往难于通信和 兼容。即使是同种平台技术,也由于软件平台规范不断演变以及版本的更新,造成体系 结构的重大改进,从而导致编程接口及模型的改变。旧的应用无法直接运行在新的平台上, 前期的投资迅速贬值。业务逻辑与平台的紧密耦合也使得软件移植的代价巨大而变得不太 可行。 1 3 主要研究思路与解决方案 1 3 1 抽象提升与关注分离 软件的发展史是个抽象提升与关注分离的过程。抽象有利于分离关注点、重用知识与设 2 硕j :学位论文面向方面模型驱动开发的研究 计。从早期的面向硬件开发,到基于操作系统衡蝠库的开发,到基于中间件的开发,直到 基于平台无关模型的开发是个抽象提升的过程;而从基于机器忙编的开发,到结构化的 开发,到面向对象开发、设计模式乃至面向方面开发则是关注分离的过程。每一次方法论 的进步都意味着软件生产力的极大提升。 因此,当前基于平台的软件开发中存在的问题也应沿着抽象提升与关注分离的思路去寻求 解决的方法。关键在于如何在开发过程中分开业务逻辑代码以及平台相关的代码,使开发 人员各尽所长:领域专家可以集中精力完成业务逻辑的开发,而平台专家则只需专注于平 台的实现细节。这样,软件的质量和开发效率容易得到大幅度提高,而平台细节的模块化 也使软件易于演化,易于移植。 1 3 2m d a 与a o p 的结合 模型驱动架构慨q 洳d dd r i v e n a r c h i mi d a ) 将软件系统的模型分离为平台无关模型 ( p l a t f o r m i n d c p c r d e n t m o d e l , p i m ) 、平台相关模型0 l a t f o r m s p e c i f i c m o d e l , p s m ) 和代码,以 缩短问题空间与求解空间横跨的鸿沟,同时又能通过变换规则将它们统起来,以这样的 方式试图去摆脱需求变更所带来的困境。m d a 重视模型在软件生命周期中的关键作用, 强调在模型层次表达软件的需求与分析,然后根据一定的变换规则,将模型自动映射成具 体的实现代码,从而提高软件的生产效率。 面向方面编程郾l ( a 印e c to r i e n t e dp f o g 咖姗i n 舀a o p 崩沭基于面向对象技术,并添加了分 离横切关注点的机制,有助于解决代码混乱和代码分散的问题。a o p 把问题分解成为功能 模块和a s p c a 模块,系统的业务功能封装在功能模块中,横切关注封装在a s p c a 模块中, 然后在编甬鼯行的时候将功能模块和a s t x x i 模块编织成个完整的软件系统。借助a o p 机制,我们能够开发更加模块化、易理解和修改的代码,并在代码层次上实现业务逻辑与 平台细节的分离,使代码更加模块化,且易于演化和移植。 m d a 与a o p 具有各自的优势,却也有各自的缺点。m d a 提供了个良好的软件开发思 路和框架,在模型层次上具有巨大的优势,但生成的代码却是业务逻辑与平台细节相混杂, 不利于理解和调试。此外,用p i m 完整并精确地表达软件需求还有很大困难,需要在生成 代码的层次e 迸行精化,但代码混杂使得改动的空间几乎没有,代码精化变得非常困难。 a o p 提供了代码层t k y _ 的关注分离机制,是对o o p 非常有益的补充。通过将平台相关的 横切关注点模块化,代码的可读性和可修改性大大提高。但a o p 仅仅提供代码层的关注 3 坝i 学位论立 t h er e s e a r c ho f a s p e c t - o r i e n t e dm o d e l d r i v e nd e v e l o p m e n t 分离,在模型层次上却无能为力。因此,m d a 与a o p 具有良好的互补作用,结合这两种 编程范型可以发挥各自的优势并最大限度弥补各自缺点带来的负面作用。 1 3 3 解决方案 中山大学李文军、黄楚伟等人1 1 1 为解决网格应用难开发难测试的问题,提出了一个代码生 成框架一一模型驱动方面框缎 m o d e l - d r i v e na s p e c tf n m a e w o f l ( , m d a f ) 爿匠简化网格应用开 发,并提高网格应用程序的可移植性。 本文将应用于网格平台的m d a f 扩展为一个通用的框架,以解决基于平台软件开发中存在 的问题。这种通用的m d a f 在体系结构设计上的基本特点主要有: 采用u m lp r o f i l e 扩展机制进行p i m 建模。对每特定平台定义一套p r o f i l e 来描述该 平台上的基于概念以及一些常见的横切属性,如事务、日志、验证、性能等。在对p i m 建模完成后,应用这套p r o f i l e 对p i m 中的元素进行标注以指定元素在目标平台上对应 的角色以及具有的横切属性,以便指导p i m 到p s m 到代码的转换。 模型转换采用v e l o c i t y 模板机制来实现。p s m 隐式地包含在转换规则与模板中,而不 是显式地作为一种中间工件。转换规则将指明标注的p i m 元素与目标平台上的( 组) 元素的对应关系。目标平台上不变的部分固定在编成模板中,可变的部分在模板上用 变量标记好,由生成器最终确定这些可变部分并填入模板以生成目标平台上的源代码。 在代码层次上采用a o p 机制。a s p e c 【代码把需要访问平台细节的代码以及横切关注的 代码模块化,从而使业务逻辑与平台细节及横切属性隔离开。在编织的时候再将a s p e c t 代码链接到业务逻辑代码中。 使用j a v a 元数据( j a v a a n n o t a f i o n ) 。代码层的a n n o t a l i o i l 对应p i m 层上的标注,用于指 明p s m 上的元素的平台属性和横切属性,以指导程序的运行时行为。 在设计模型变换前对应用进行重构,可以使用设计模i 妒1 等经受考验的“最佳实践” 以分离变与不变的部分、变得快与变得慢的部分,也可以结合a o p 和模式以弱化模块 问的耦合度,实现了业务代码对平台组件、以及平台组件之间的透明访问。 1 4 相关工作和比较 每一种新的平台技术出现时,都会相继出现相应的开发工具。这些开发工具经常包括基于 命令行界面的、基于集成开发环境c c 雩脚。dd e v e l o p m e n te n v i r o n m e n t , d e ) 的、乃至基于 4 硬上学位论文 面向方面援型驱动开发的研究 m d a 的,其易用性各有不同,生成的代码的质量也不尽相同。 1 4 i 传统的i d e 基于命令行界面的开发工具通常只包括一组支持该平台规范的库文件和一些编译运行工 具,源程序的编辑基本靠记事本等文本编辑器来进行,例如用来开发c o r b a 应用程序的 v i m l r o k 盯早期版本。这种开发工具提供的帮助非常少,因此难于支持应用程序的快速开 发和调试。 玎) e 工具的出现大大缓解采用命令行工具进行开发带来的困难。i d e 工具集成平台的库文 件和支持工具,提供从代码语法检查到代码打包运行等的帮助,还可以生成部分组件或代 码,给程序员节省了不少精力。但这些生成的代码或组件都是孤立的,i d e 无法生成它们 之间的联系,程序员仍然需要熟悉平台的接口并通过编程手工建立生成代码之间的联系, 同时需要完成业务逻辑的实现。 a n d r o m d a 阎是个遵循m d a 的开源代码生成框架,它读入由c a s e 工具导出为x m i 格 式的u m l 模型,并i 蝴件商d g e 来以实现多种平台上的代码生成,是种纯粹的m d a 方法。个c a m i d g e 通常由v d o c i t y 模板文件、部署描述文件、命名空间文件以及生成器 等j a v a 类文件组成。a n & o m d a 支持各种编程或描述语言,并具有良好的扩展能力,通过 开发c a t t r i d 萨插件可以实现相应平台上的代码生成。比如,s a c h i om i z u m 等人p 开发了一 个称为锄血胁d a l 筘的c 砌d g e 插件来支持0 g s i 规范下的g t 3 网格服务的应用程序开发。 a n d r o m d a 通过使用p r o f d e 耥相关信息,使得业务逻辑与平台细节实现了模型层 上的分离,但在代码层上又混杂起来。 1 4 3 使用元数据的m d a us m i t h 等l j 设计了个遵循m d a 的代码生成框架,用于简化w s r f 规范下g t 4 的网 格服务开发。这种方法利用u m lp f o 衄e 方式设计一套p 丘l e 来表示网格属性,在模型层 对p i m 进行标注。此外,为了得到更好的关注分离,并简化p i m 到代码的映射,p s m 被 5 r 畹l :学位论立 t h er e s e a r c ho f a s p e c t - o r i e n t e dm o d e l d r i v e nd e v e l o p m e n t 分为两个子层,即业务逻辑子层和网格子层。两个子层是分离开的,这种在模型层次上的 分离通过j a v aa n n o t a t i o n 可以映射到代码层上,实现代码层的上的业务逻辑与平台细节的 分离。因此,领域专家只需要少量的平台知识就可以在模型和代码层次t 进行网格- 丌发。 1 4 4 面向方面建模 面向方面建模【9 1 ( a s p e c t o r i e n t e d m o d e l i n g , a o m ) 是一种软件建模方法,是r 趋成熟的a o p 技术向建模阶段延伸的必然要求,其目标在于使面向方面的系统从分析、设计平滑地过渡 到代码实现。目前a o m 尚处于研究讨论之中,尽管出现了不少实现方案,但还没有统一 的标准。鉴于u m l 的广泛使用,目前主流的a o m 方案都是通过扩展u m l 来实现,其途 径大致分为两种:修改m o f 元模型和构建u m l p r o f i l e 。lf u e n t e s 等人【o 喇用u m l p r o f i l e 的扩展机制,设计了套a o m 的方案,拟定如何用p r o f i l e 的语义来表达a s p e c t 的基本特 征,以便在模型层上表达横切关注点,将之模块化。 1 4 5m d a f 的不同之处 m d a f 框架结合m d a 和a o p 的优点,它与以上的几种相关工作采用的方法都有所不同。 传统i d e 生成的代码馏件是相互独立的,程序员需要手工建立它们之问以及它们与业务逻 辑之间访问逻辑,这些工作涉及的很多平台细节。和a n d r o m d a 以及ms m f i h 等人的方 法不同之处主要在于m d a f 充分利用a o p 的优点来实现代码层次上业务逻辑与平台细节 的更好分离。和lf u e n t e s 等人的方法不同之处在于m d a f 在模型层上的p r o f i l e 标记是用 于添加平台相关的信息和注明横切关注点,而不是描述横切关注点的结构和行为。 a n d r o m d a 是种比较纯粹的m d a 方法,它利用p r o f i l e 标注技术可以在模型层分开业务 逻辑和平台细节并自动生成代码,从而可以大大节省代码的编写,其缺点在于生成的代码 又将业务逻辑和平台细节混杂在起。因此,开发人员不可避免地需要了解平台相关的技 术细节,使得业务逻辑代码难于类见独立编写和测试。而m d a f 框架中,借助a o p 强大 的关注分离机制以及a n n o t a t i o n 的帮助,生成的a s p e c t 代码可以将平台细节封装在a s p e c t 之中,从而实现模型和代码层上业务逻辑与平台细节的分离。 m s n :l i m 等人设计的框架中,依附于模型元素的p 句【e 标记用于转化成a i 瑚l t 缸i o n ,然后 根据a n n o t a t i o n 生成网格相关的适配器和包装真正业务的网格组件,将转换本地调用和远 6 硕士学位论文面向方面模型驱动开发的研究 程调用。业务逻辑代码只需与适配器打交道而不用了解平台的复杂细节。但这种基于接口 基类的面向对象方法有其固有的弱点:由于适配器模式固有的侵入性,业务逻辑代码将不 可避免地依赖于这些接口或基类。比如,业务逻辑必须知道适配器的名称才能创建实例, 而业务逻辑中混杂着访问适配器的代码将使业务逻辑无法脱离平台独立进行编码和测试。 而m d a f 使用a o p 技术可以实现平台相关特性的即插即用,业务逻辑代码无需了解平台 相关代码的改变,其它的平台相关代码也不用改变以适应新添加的平台相关的a s p e c t 模块。 a o m 的方法和本文的方法区别比较大。a o m 关心的是建模阶段横切关注点的表达方法, 其强调的是如何来制定套建模语言方案以全面、准确而又简洁地表达出面向方面方法的 基本概念。因此,同是在建模阶段中使用的u m lp r o f i l e 机制,本文却是用来标注模型元 素的角色,以表达平台相关的信息。使用u m lp r o f i l e 的好处是可以重用设计者熟悉的建 模概念,但其缺点也是明显的,p r o f i l e 扩展u m l 元模型,其语义必然会受到u m l 元模型 的限制,而设计者也容易混淆原有元素的语义与扩展元素的语义因此,用p r o f i l e 机制来 进行面向方面建模其能力是有限的,但在m d a f 中用来标注平台细节却是绰绰有余了。 1 5 论文的选题意义 1 5 1 提高了基于平台软件开发的效率与质量 i 蕴过在模型和代码两个层次上的业务逻辑与平台细节关注的分离,最大限度地减少了手工 工作量。这样就大大降低了学习的成本,用户可以不用了解平台的细节而集中精神进行领 域的业务开发,从而提高了开发的效率另外,用户的工作独立于平台关注的,当平台改 变时,仅需改变平台相关的代码即可,用户的这些工作是可以复用的因此,软件的可复 用性也得到大大的提高。 1 5 2 提出了开发模式的一种新的思路 软件工具从命令行界面工具到i d e 工具到m d a 工具的每一次演进,无疑都是开发模式的 巨大进步,为开发者带来了很多方便。本文提出了一种使用结合m d a 和a o p 优点的开发 工具来进行软件开发的模式这种筷式符合软件发展史中抽象提升与关注分离的趋势,有 效解决了之前开发模式中的根本问题:业务逻辑与平台细节的紧密耩合 7 倾i :学位论文 t h er e s e a r c ho f a s p e c t - o r i e n t e dm o d e l - d r i v e nd e v e l o p m e n t 1 5 3 划分软件参与者的责任和角色 m d a f 把软件开发参与人员分为三种角色,即框架构建人员、软件开发人员以及软件配置 人员。框架构建者负责特定平台的m d a f 框架的搭建,开发人员负责具体应用的建模和不 含平台细节的业务逻辑的实现,软件配置人员则负责具体应用的运行配置,包括数据库的 配置和服务器的配置等。这样就可以充分发挥乎台专家、业务领域专家和配置人员的专长, 使他们可以专注自己的工作而不必熟悉软件涉及的各个方面的细节。 1 6 论文的结构 论文的结构g r i t 4 来安排的:第一章简单阐述了论文的研究背景、研究思路及解决方案, 并对国内外相关工作进行了介绍和比较;第二章介绍论文中需要用到的技术基础;接下来 的第三章给出了m d a f 的设计目标、体系结构、设计原则以及基本的使用流程;第四章给 出了m d a f 应用到e i b 的一个案例,以个分布式议程管理系统的开发为例展示m d a f 的优点;第五章是对m d a f 有效性的一个评估;论文最后一章对全文的作了总结并对接下 来的工作进行了展望。 8 硕上学位论文面向方面模型驱动开发的研究 第二章论文的技术基础 本章对论文所涉及的领域以及相关的基础技术进行了简单的介绍。 2 1 模型驱动架构 2 1 1m d a 的棚念 模型驱动架狮o d e l - d r i v e na r c h i t c c u a 七, m d a ) p v 对象管理组织( o 坷。吐m a n a g e m e n tg 吼聃 o m g ) 于2 0 0 1 年提出的种应用系统设计和实现的方法,它利用自动化工具,组织和管理 企业体系架构、定义各种模型,并推动不同模型之间的转换。m d a 提供了个全面的系 统框架,通过使用软件工程方法和工具去理解、设计、操作、演化企业系统的所有方面, 并把系统抽象为不同层次,对不同层次建立相应的模型,从而致力于处理这些不同抽象层 次模型之间的关系,强调系统的最佳实践以及概念设计的复用。 模型可执行是m d a 的终极目的,即实现模型到代码的自动转换。其实这也是软件开发的 终极梦想,意味着抽象层次的再次提升。开发人员只需要考虑与业务模型相关的模型设计, 模型到具体应用平台的映射是和业务无关的,可重复的、低层次的工作,应该当交由工具 来实现。为了实现这个目的,o m g 制定了模型的精确形式化表示、模型转换、模型存储 以及交换的各种标准,如u m l 、m o f 、o c l 、q v t 、x m i 等等。 2 1 2m d a 的体系结构 m d a 由许多重要的o m g 技术标准共同构成,图z l 是m d a 的体系结构图i “,不仅包含 了o m g 已经建立的一系列重要的集成标准( 如u m l 、c o r b a 等) ,还涵盖了o m g 所定 义的普遍服务( 包括目录服务、事件处理、持久性、事务和安全性窃。此外,m d a 还支持 对特定行业( 如电信、运输行业书的标准化领域陵型的建立。 9 坝i 学位论文t h er c a r c ho f a s p e c t - o r i e n t e dm o d e l d r i v e nd e v e l o p m e n t m d a 的核心标准主要包括统一建模语言、公共仓库元模型( c o m m o nw a r e h o u s em 锄o d e l , c w m ) 、元对象设施( m e t a 例e c tf a c i l i t y , m o f ) 、x m l 元数据交换( x m lm e t a d a t a i n t e r c h a n g e , x m i ) 等,这些标准通过使用和管理跨应用程序、平台、工具和数据库的元数据, 实现m d a 模型的转换、互操作和集成。 u m l 是m d a 的基础建模语言。虽然m d a 的模型不局限于使用u m l ,但和其它建模语 言相比,u m l 作为工业标准更加成熟和完善。它通过各种视图从不同侧面描述软件系统, 使涉及软件开发各个阶段的人员能够有效沟通。在m d a 中,u m l 负责对系统体系结构的 建模,在模型层次上确定对象与对象之间的关系、数据、构件结构等内容。 c w m 用m o f 来建模,是一组元模型,可以用来对各种数据进行建模,从而可以实现不 同格式的数据的共享。c w m 是o m g 的数据仓库标准,覆盖了数据仓库应用的整个生命 周期,包括数据源表达、分析、仓库管理以及典型的数据仓库环境基础组件。 m o f 是一个标准的基础设旌,它提供组建模元素以及使用这些元素的规则,为元模型规 范定义了一种公共的抽象语言,以统一的方式描述各种建模结构,使它们不再是孤立的, 而是可以相互映射,相互交换数据,并相互理解。在抽象层次上,m o f 比u m l 更高。 m o f 对各种建模结构的描述方式的内在统性为定义模型问的自动映射提供了极大方便。 事实上,o m g 的转换定义标准查询,视图废换( q i 】n a e 恤1 s f b r m 砸0 n ,q v t ) 就是m o f 标准的一个子集。 1 0 硕士学位论文面向方面模型驱动开发的研究 x m i 是一种标准的数据交换机制,用于不同工具、知识库和中闻件之俩的元数据交换。在 m d a 中,) 。咀主要用于对u m l 元模型进行管理,定义了种基于x m l 的数据交换格式 以及一个从u m l 到x m l 的映射,方便在异构环境下的各种建模工具交换元数据。 2 1 3m d a 的意义及其不足 理想的m d a 开发方法可以有效解决传统软件开发过程中的生产效率问题、系统移植问题、 软件质量问题、互操作问题以及文档和系统后期维护的闯题。基于m d a 的应用开发增强 了软件的可复用性,提高了软件开发效率,即使需求产生了改变,也只需对业务模型p i m 进行一定的修改,通过m d a 工具保持p i m 到p s m 、代码的致性。模型的自动转换减少 了开发人员的手工编码,极大降低了软件的开发成本。m d a 也是软件方法演进过程中抽 象层次的又一次提升,使开发人员的注意力集中于与平台技术无关的p i m 上。 m d a 方法对于软件开发是具有革命性的意义,但是目前还处于发展初期阶段,基于m d a 的软件开发技术还未能真正实用化,存在着这样那样的问题,主要表现在以下几个方面: 没有统一的成熟的模型变换的标准。尽管o m g 一直在致力于制定模型的转换标准 q v t ( q u e t y v i e w t r a m f o m m f i o n ) ,但由于涉及的规范庞大以及需求的模糊等原因未能 最终完成。厂商也因q v t 的不成熟完善或其它商业原因而很少采用。目前m d a 厂商 通常使用模板的方法和自定义变换规则来实现模型和代码的转换。 对p i m 精确建模的能力不足m d a 中使用较多的是静态模型,它对动态模型的支持 不足,不能够对业务需求进行精确的建模m d a 未能很好地支持活动模型、状态模 型和交互模型等动态模型。可执行u m l 试图使用动作语言改变这种状况,但由于动 作语言的抽象层次较低,可执行u m l 一般只适用于些专门领域( 如嵌入式开发等l , 不太适用于高抽象层次的p i m 。 m d a 生成的代码是业务逻辑与平台细节相混杂的。混杂的代码难于理解,改动的空 间几乎没有。由于p i m 建模能力的不足,m d a 工具通常只能生成部分代码,剩下的 部分需要开发人员手工补充,而自动生成难于理解的代码使得修改和补充工作的效率 低下,因此就大走| 氐消了m d a 的优点。 硕l :学位论上t h er e s e a r c ho f a s p e c t o r i e m e dm o d e l - d r i v e nd e v e l o p m e n t 2 2 u m l 建模及其扩展方式 2 2 1it 概述 统一建模语言( 【j n i f i e dm o d e l i n gl a n g u a g e , u m l ) t 1 1 是一种面向对象的建模语言,它由曾经 的面向对象软件建模三种主流语言b o o t h 、o m t 和o o s e 共同发展而得,后被o m g 采纳 成为个通用的、可视化建模语言标准。 在m d a 的体系结构中,u m l 是位于m 2 层的标准建模语言。虽然在m d a 中共没有强行 规定必须使用u m l 来建模,但作为事实上的工业标准,u m l 与其它建模语言相比表现出 了极大优势。因而m d a 最为重要的p i m 和p s m 这两层模型一般都是通过u m l 来定义 的,可以说,u m l 是m d a 的基础。 u m l 是抽象语法与具体语法分离的。u m l 既可以用图形语法的方式来表示模型,又可以 用文本语法的方式来描述模型。图形化的表达能力有利于人的理解,文本方式的表达有利 于自动处理,u m l 在这两方面都有优势,并且图形和文本方式之间的相互转换也不会带 来语义损失。这就意味着用u m 巴模型不用绑定在某具体语法上,从而,不同建模工具之 间就可以方便地实现信息交换与共享。 l m 擅长于系统结构方面的建模,但它对系统动态内容的描述能力较差,因此,建立起 来的模型一致性和精确度不够高。可执行i ) 编译器检查:元数据可以在代码级别上显示规定代码必须满足的要求,从而增强了编 译器的查错能力,减少了软件排错的困难。 代码分析:元数据提供了让注释在运行时可用的方法,以编程方式访问注释的实例。 框架消费:元数据可以帮助程序元素与框架或者e b ,e m f 等工具之间的通信,从而 取代原来的基于x m l 的复杂配置文件。 语言扩展:元数据与语义属性相关联使得编译的类可以具有与原有类不同的结构和行 为,从而为核心添加了新功能,成为- 种开放式的语言。比如在j b o s s a o p 中使用元 数据就把类、方法、属性的语义分别转换为a s p e c t 、通知和切入点。 2 6 2j a v a 元数据 协a 元数据( j g 住加瑚t 撕伽) 是j 2 s e5 o f n g c r ) 新引入的重要功能,它允许程序员在j a v a 代 码中添加注释,并提供工具以编程方式进行访问并处理。j a v a 元数据的特点主要有: 元数据以标签的形式存在于j 啪代码中; 2 1 硕l ,学位论立 t h er e s e a r c ho f a s p e c t - o c i e n t e dm o d e l d r i v e nd e v e l o p m e n t 元数据描述的信息是类型安全的,即元数据内部的字段都是有明确类型的; 元数据需要编译器之外的工具额外的处理用来生成其它的程序部件: 元数据可以只存在于j a v a 源代码级别,也可以存在于编译之后的d a s s 文件内部。 j a v a 元数据的处理主要是通过a p t ( a n n o t a t i o np r o c e s s i n g t 0 0 1 ) 来实现的。a p t 是一个命令 行工具,它对源代码进行检测找出其中的元数据,并使用元数据处理器k m u m t a t i o n p r o c e s s o r s ) 来处理元数据类型。元数据处理器使用了一套m i r r o r a p i 并具备对j s r l 7 5 规范0 a v a5 元数 据规商的支持。元数据可以是编译时在源代码中读取并处理的,也可以是在d a s s 级别中 读取并处理。这两种处理方式中,元数据都不直接影响程序的语义,但a p t 工具却可以通 过生成新的代码或文件等等行为来改变程序的语义。 2 6 3 元数据与a o p 元数据与a o f 具有互补作用i 笠1 ,元数据可以扩展a o p 的连接点模型来降低a o p 的复杂 度,提高a s p e c t 的可重用性; a o p 则可以将声明性的元数据转化为运行时的行为。 a o p 中的连接点模型是包括如何来定义连接点以及切入点如何捕获连接点和它的上下文。 切入点语言的复杂程度是a o p 系统成熟程度的一个重要判别标准。编写好的a s p e c t 的关 键在于编写强壮的切入点,以及良好设计的a s p e c t 继承关系。当系统演化时,捕获比预计 多的连接点或者错过预计连接点的切入点都会使系统容易崩溃。基于代码元素名称的切入 点定义方式往往容易错捕或漏捕预计的切入点,使切入点变得复杂而难于维护,此外,复 杂的切入点定义也不利于a s p e c t 的重用。 基于元数据的连接点模型可以解决这个问题,它把原来集中在a s p e c t 中的切入点信息分散 到代码中的元数据去。这样做的好处是a s p e c t 中只用定义横切关注点的实现逻辑,提高了 a s p e c t 代码的可重用性;元数据与所需要注释的程序元素是以松耦合的方式连在起的, 因此比较直观,易于理解。j 比外,程序元素的名称的改变不会影响连接点的捕获,切入点 的复杂性不会因系统的复杂度提高而变得难于控制。 a o p 对于元数据的补充作用也是明显的。元数据只是声明性的,只有把它转化为运行时的 行为才能体现元数据的使用目的。a o p 机制能够在编织或运行时捕获元数据所注释的元 素,并通过访问该元数据的信息并在a s p 。d 代码中做出相应的处理,从而实现了程序的运 行时行为。 硕:学位论文面向方面模型驱动开发的研究 2 7v e l o c i t y 模板引擎 v e l o c i t 3 j z z i 2 s l 是个基于j a v a 的模型引擎,由开源组织a p a d 硷小组负责开发。v d o c i t y 引擎 可以作为个独立工具来产生源代码和报告,也可以作为其它系统的集成组件来使用。虽 然v e l o c i t y 最初应用于w e b 开发,但作为一个通用的模板引擎,它也同样有其它很多方面 的用途,比如s q l 语句、x m l 的生成,以及程序代码生成等等。 v e l o c i t y 模板引擎的工作原理是结合模板和上下文( c o n t e x t ) 来生成代码、x m l 等文件。上 下文是从输入的x m i 文档中产生的,类似于抽象语法树,包含了输入模型的信息。上下文 是组f f t x c ( m m e - v a l u e p a i r s ) ,允许模板很方便地读取模型信息。名值对中的值可以是简 单字符串或是j a v a 对象引用,被引用的j a v a 对象允许模型通过对象的公有接口进行访问。 v e l o c i t y 最和啦用于生成动态网页是因为它可以隔离页面的业务逻辑和外观设计,允许程 序员和网页设计者专注于各自熟悉的工作内容。在用于代码生成时,v d o d t y 同样可以帮 助分离软件的设计和实现。如图2 _ 7 所示,对于同一个输入模型,我们可以为不同的语言 定义不同的模板,通过合并上下文和模板,就可以得到相应的源代码文件

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论