（计算机应用技术专业论文）模型驱动体系结构的应用研究.pdf

摘要 随着软件产业的不断发展及软件规模的不断扩大，软件生产过程中出现了一些新的阻碍 软件产业进一步发展的问题。如需求的不断变更、文档维护、重复开发等。为解决这些问题， 对象管理组织o m g 提出了基于模型驱动的体系结构( m o d e l d r i v e n a r c h i t e c t u r e ，m d a ) 技 术。m d a 是一种通过模型驱动来开发软件系统的方法，是o m g 在实现模型的可执行性上的 努力，其目的是为了“把建模语言当编程语言来用”。m d a 的研究基于统建模语言u m l 、 元对象设施m o f 、数据仓库元模型c w m 和基于x m l 的元数据交换x m i 等o m g 标准基础 之上。使用m d a 及其相关标准构建的平台无关的应用程序能够在多个开放的或专有的平台 上实现，包括c o r b a 、j 2 e e 、n e t 以及，e b 服务或其他任何基于w e b 的平台。 本文的第一部分从m d a 的原理开始，介绍了m d a 的相关概念和标准，讨论了m d a 方式 f 的应用程序的开发流秽。第二部分分析t m d a 方法的关键技术，其中包括对u m l 的扩展， 采用x m i 标准实现u m l 模型的转换，以及从p i m i p s m 的转换技术。研究了m d a 在j 2 e e s z 台中的实现以及m d a 方式 - j 2 e e 应用的开发，并提出了对m d a 体系结构进行扩展的思想。 第二部分介绍了实现m d a 方法的开发工具，以研究生培养信息系统项目为开发实例，应用 m d a 方法进行系统开发，讨论了项目中所遇到的问题并总结t m d a 对软件开发的影响。论 文最后是本文的总结以及对模型驱动开发方法的展望。 关键字：m d a 、模型驱动、业务层模型、平台无关模型、平台相关模型、j 2 e e l j a b s t r a c t s e v e r a lp r o b l e m ss u c ha sn e e d sc h a n g i n ga n dd o c u m e n tm a i n t e n a n c ee m e 唱ea sn e wd r a g s o ot h ef u r t h e rp r o g r e s so fs o f t w a r ei n d u s t r y i no r d e rt os e t t l et h e s ep r o b l e m s ，t h eo b j e c t m a n a g e m e n tg o v e r n m e n t ( o m g ) p r e s e n t san e wt e c h n o l o g yc a l l e dm 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 hs h o w st h ei d e at ob u i l ds y s t e m st h r o u g hm o d e l s m d ai sa na t t e m p to ft h eo m g t oi m p l e m e n tt h ee x e c u t i o na b i l i t yo fm o d e l sw i t ht h ep u r p o s et ou s em o d e l i n gl a n g u a g e sa s p r o g r a m m i n gl a n g u a g e s t h er e s e a r c ho f m d a i sc u r r e n t l yb a s e do nm o eu m l ，c w ma n dx m i t h ep l a t f o r m - i n d e p e n d e n ta p p l i c a t i o nc o n s t r u c t e do nm d aa n di t sc o r r e l a t i v es t a n d a r d sc a nr u n o nm u l t i p l eo p e no rs p e c i f i cp l a t f o r m s ，i n c l u d i n gc o r b a ，j 2 e e ，n e t , w e bs e r v i c e so ra n yo t h e r p l a t f o r mb a s e do nt h ew e b i nt h i sp a p e r , w ef i r s tr e n e wt h et h e o r y , c o n c e p ta n dc o r r e l a t i v es t a n d a r d so fm d a t h e nw e d i s c u s st h em a i nt e c h n i q u e so fm d a ，i n c l u d i n ge x t e n d i n gu m l ，t r a n s l a t i o nf r o mu m lm o d e lt o x m lu s i n gx m i ，t r a n s l a t i o nt e c h n o l o g yf r o mp i mt o p s m ，t h ei m p l e m e n t a t i o na n dd e v e l o p m e n t o fa p p l i c a t i o nb a s e do nj 2 e eo fm d a w ep r o p o s et h em e t h o dt oe x t e n d i n gt h ea r c h i t e c t u r eo f m d a n e x t , w ei n t r o d u c et h ei m p l e m e n t a t i o nt o o l so fm d aa n dd i s c u s ss o m ei s s u e se n c o u n t e r e d i nt h ed e v e l o p m e n to fa ni l l u s t r a t i o ns y s t e m a tl a s t ，w ec o n c l u d et h i sp a p e rw i t hd i s c u s s i o no n f u t u r ew o r k ； k e yw o r d s ：m d a ( m o d e ld r i v e na r c h i t e c t u r e ) ，m o d e ld r i v e n ，o p e r a t i o nm o d e l ，p l a t f o r m - i n d e p e n d e n tm o d e l ，p l a t f o r m s p e c i f i cm o d e l ，j 2 e e 东南大学学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表或撰写过的研究成果，也不包含为获得东南大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 研究生签名： 住燕 曰期：宴! 坚：! ：p 东南大学学位论文使用授权声明 东南大学、中国科学技术信息研究所、国家图书馆有权保留本人所送交学位 论文的复印件和电子文档，可以采用影印、缩印或其他复制手段保存论文。本人 电子文档的内容和纸质论文的内容相一致。除在保密期内的保密论文外，允许论 文被查阅和借阅，可以公布( 包括刊登) 论文的全部或部分内容。论文的公布( 包 括刊登) 授权东南大学研究生院办理。 研究生签名：l 兰垒导师签名：研究生签名： l 善二：l导师签名： i i 拙 日期：娜，2 歹 第一章引言 第一章引言 以计算机技术为代表的信息技术对人类社会已经产生了深刻的影响，随着网络的发展，这种影 响的蔓延呈现出愈演愈烈的趋势。社会对于信息的需求似乎永远也得不到满足。计算机硬件遵循摩 尔定律稳步发展，网络的发展则超越了摩尔定律，然而与之不相协调的是，计算机软件的生产一直 没有成熟起来，面对工业化的需求，绝大多数软件还是通过手工艺阶段的生产模式开发的：人们普 遍希望有更多适合各个领域的应用软件，并希望运行的软件使用更加方便，软件投入市场所需的时 间越短越好。而授权软件开发的客户，更关注的是开发软件的成本和所开发的软件的使用寿命，也 就是对软件的质量有更高的要求。然而软件开发的当前状况与强大、复杂软件的需求并不一致。许 多软件开发的投资却并没有带来所期望的结果，甚至是大失所望。还有一些项目由于开发过程中所 需预算大大超出了预期预算，以至于客户端最后只好中止它们。有些系统在一开始看上去很成功， 但不久它们就被认为不能满足变化的需求，不具有灵活的扩展性。上述种种情形的存在，对软件行 业提出了挑战，软件开发者必须改进传统的软件开发过程，提高软件开发的灵活性，对需求的可追 踪性，否则，将无法面对当前复杂而且多变的软件开发要求。 1 1 软件开发过程 作为新兴产业的软件开发业，经历了二：十世纪六、七十年代产生的“软件危机”( s o , w a r ec r i s i s ) 后，1 9 6 8 年秋，北约的科技委员会第一次提出了软件工程( s o f t w a r ee n g i n e e r i n g ) 的概念。软件工 程经过3 0 多年的发展，人们针对软件危机的表现和原因，经过实践和总结从而认识到：按照工程化 的原则和方法组织软件开发工作，是摆脱软件危机的一个主要出路。按照工程化的原则和方法，软 件开发被视为一个问题的解决过程，其中，“需求”可以被认为是相关领域有待解决的问题，软件 工作者捕获“需求”、理解面临的问题，提出问题的解决方案并实现它。由此，人们提出了软件生 命周期的概念，它通常包括以下几个阶段： 需求调查：需求调查阶段，根据目标来确认需要处理的问题，回答“问题是什么”，“它是 否值得解决”等。这阶段得到对需要处理问题的详细描述。 分析：分析阶段，分析和理解需求，了解软件应用领域，以及需求的功能、行为、性能和接 口，理解需要构造程序的本质。需求调查和分析都需要有文档和用户进行交流。 设计：设计阶段，将需求转换成软件表示，集中于四个完全不同的要素上：数据结构、软件 体系结构、界面表示和算法细节。设计也是文档化的。 编码实现：编码实现阶段，将设计变成机器可读的形式，用计算机编程语言对它进行描述。 测试：测试阶段，对程序的测试，保证程序的正确性。 1 壅重查堂堡主兰竺丝苎 部署和维护：部署和维护工作使得软件程序对用户可用，并且保证程序的正确性a 此外，现在还有很多其它类型的生命周期模型，例如瀑布式、迭代式开发模型，它们都需要涉 及上述一些阶段的活动。总的来说，当今软件开发过程主要是以非形式化的需求驱动软件的开发， 如图1 - 1 所示： 软件开发理论上是一个迭代的过程开发人员喜欢走的捷径 图1 - 1 传统的软件开发过程 1 2 传统软件开发过程存在的问题 通过以上工程化的软孛 开发方法虽然解决了一些困扰软件开发过程的问题，但是，建立软件系 统仍需要训练有素的程序员进行艰难琐细的工作，而这些开发人员依然是昂贵的资源，对软件开发 项目采取“人海战术”的方案代价高昂，而且质量也不能保证。另外，许多软件开发的投资带来的 、 是令人失望的结果：很多的项目以失败而告终；其它一些项目大大超出了预算，以至于管理层只好 中止它们；有些系统在开始看上去很成功。但是时间久了，它们就被证明是不稳定的，或者不具 有灵活的扩展性。产生这些令人失望的结果的原因体现在以下几方面： 1 2 1 需求的不断变更 由于经济全球化和竞争越来越激烈，企业的管理与业务必须经常变化，这种变化必然反映到对 应用软件需求的变化。虽然，应用软件开发人员与客户交互需求时总会规定应用系统实现的范围， 并把该范围落实在合同上。但事实上，开发方往往会经受不住客户的压力而扩大系统实现的范围； 同时，在需求范围内的变更则更多。客户熟悉的是企业的业务，他们并不关心需求的更改对整个系 统开发过程的影响。 需求的变更直接影响软件开发过程的初始阶段，这会导致软件最终实现的重大修改。对客户的 耍求说不，明显是不可取的方法。因此，应用软件系统开发人员会疲于处理变更产生的影响。如何 处理不断变更的需求是困扰软件开发人员的一道难题。 1 2 2 文档维护 传统软件开发过程中，文档和相关的设计图表都是在前三个阶段产生。需求分析往往使用文本 和图的方式对需求进行描述，这会产生很多纸面的说明文件，不过，当编码开始时，前三个阶段产 第一章引言 生的文档和图表就迅速失去了它们的价值。随着编码的深入，文档、设计图表与代码之间的关联逐 渐减弱，它们不再是对代码的精确描述。随时间的推移，系统被不断地修改，文档、设计图表与代 。 码之间的距离就越来越远。事实上，工程中往往只修改代码。因为，代码修改之后必须手工在文档 中找出设计图纸中需要修改的地方，这样做十分烦琐而且低效：并且，能够检查文档质量的也只能 是开发团队的人员，他们完成这项工作要花费的时间和精力也是整个软件开发团队无法容忍的。一 种解决方案是从代码层次入手，从代码中产生文档，这样文档就变成代码不可分割的一部分。但这 种方案只能解决概要设计文档的问题，详细的设计文档仍然需要手工维护。 极限编程x p ( e x t r e m ep r o g r a m m i n g ) 迅速地流行起来，它承认代码是真正驱动软件开发的力量。 但极限编程只能解决软件开发中的部分问题：当一个团队开始开发一个系统的时候，保存在团队成 员大脑中的设计思想足以使他们理解这个系统。但是，当第一个版本发布之后，团队可能会解散， 后来维护这个系统的人可能是一个新人，那么他就只有代码和测试结果，这使得系统维护极其困难。 所以，要么花时间在开发的前三个阶段，写详细设计文档和设计图表；要么花时间在维护阶段， 理解系统如何工作。这些与文档维护有关的工作，降低了软件的生产力。所以，文档维护到什么程 度，既能很好地指导编码和测试，又不降低生产率，也是困扰应用系统开发人员的一道难题。 1 2 3 软件的轻便性 、 软件工业与传统工业相比有其特殊性，它的发展速度令人吃惊。每年都有新技术被发明并迅速 流行起来，例如( j a v a ，l i n u x ，x v l l ，h t m l ，s o a p ，u m l ，j 2 e e 。n e t ，j s p ，a s p ，f l a s h ，w e b s e r v i c e s 等等) 。新技术的确能够真正解决一些问题( 例如，x m l 解决异构系统间的数据交换) 。但面 临的困境就是，应用系统开发商必须快速跳跃前进，而且必须忍受前期投资的丢失，这无疑是非常 痛苦的。更复杂的是。新技术本身也在发生变化，它们也会不断推出不同的版本，而且并不能保证 能完全做到向后兼容。 现有的系统，或者通过接口与用新技术开发的系统相连接，或者转向新技术。如果系统和某种 技术紧密绑定，那么该系统注定在随技术发展的道路上是步履沉重的。那么，系统开发人员该如何 设计系统才能够使得系统足够轻便，从而跟上技术前进的步伐? 1 2 4 重复开发 现阶段，面向企业应用系统的定制项目在定范围内依然存在，应用软件供应商往往会为同行 业的企业定制类似的应用系统。但由于各企业的业务之间存在细微差别，如果按传统软件开发方法 操作，应用软件供应商不得不依然付出相当多的精力去完成类似的系统，这造成了软件生产效率的 低下。原因就是，软件供应商对自己己产生软件的重用力度不够。9 0 年代中期热捧的面向对象程序 设计( o b j e c to r i e n t e dp r o g r a m ，o o p ) 的一个很大的目标就是实现可复用的软件。但是，事实上没 有多少人进行类层次上的重用，每个程序员在编程的时候，都习惯用自己创建的类，并在此基础上 3 东南大学硕士学位论文 进行进一步的开发，这并没有从根本上解决软件重用的问题。从软件开发的经验来看，被复用得最 好的都是一个个相对完整的、独立实现一定功能的模块。但是，企业间业务上的区别导致了这些模 块并不能如期望中那样，被方便的重用到多个应用软件系统中。 所以，在建设类似的系统时，减小重复开发才能使软件开发的效率提高。如何提高软件的复用 度，构造适合不同企业业务的模块，也是困扰系统开发者的一个难题。 以上是一些软件开发过程中的新问题，它们给软件开发者带来了很大的压力：用密集的劳动力 处理复杂的、多变的需求给软件生产成本带来了压力；软件复杂性的增加给软件的质量带来了压力， 而软件业界对编码的执著使得质量方面的压力更为沉重；多种新计算平台的出现，使得软件寿命方 面的压力不断增大。企业经理人已经不太可能把宝贵的资本投在不会带来显著效益的项目上。计算 机技术的发展过程是一个螺旋式发展过程。传统软件开发方法面临的主要挑战是：以凝固的需求为 前提；应变能力差；质量不能保证等。 1 3 改进软件开发过程的可行性 行业发展过程中面临的危机，一般是由于该行业的操作( 运作) 方式不能适应行业发展的客观 情况而产生的。当今的应用软件开发正面临着这样的压力，这是行业发展到一定阶段的结果。软件 开发的可行性主要是指软件产业经济上的可行性，通常以软件质量、寿命期与软件开发成本等三个 方面作为衡量依据。建立高质量、长寿命的业务软件代价是昂贵的，因此，软件需要在质量、寿命 期、开发成本等方面一定要找到新的解决方案。 i 3 1 降低生产成本 从软件开发的回顾可以看出，降低软件生产成本的通用方法是成本的转嫁将高昂的程序员 成本转嫁到成本相对低廉的机器资源上去。这就是要在软件开发中让机器代替人做更多的事情。从 本质上来看，为了将程序员的工作交给机器完成，就需要对客观事物进行抽象，将复杂的过程用简 单的方式进行描述，形成固定模型，再交给机器完成。这样，能以较少盼代码描述以前需要复杂描 述的过程，从而减小了人工开发的工作量，降低了生产成本。同时，这种通过抽象得到的模型也可 以理解为，将成熟的良好设计的规范代码( 如组件) 引入项目中，减少程序员在优化和改错方面的 工作，可以降低生产成本。 1 3 2 提高软件质量 为了提高软件代码的质量，人们在软件方法学方面作了很多的努力，如o o p 改交了程序员对客 观世界的认识方式，通过使用对象模型对客观世界进行抽象；通过如规约式设计等软件开发方法， 规范编程的方式使得程序的质量得到提高。此外，优秀代码的复用也是保证程序质量的好办法，基 于组件的编程在这方面起了很大的作用。 4 第一章引言 1 3 3 提高软件寿命 一般情况下，实现软件代码在平台间的可移植性是提高软件寿命的主要方法。如果对软件系统 进行进一步的抽象，将软件视为独立于平台的模型，这样软件的寿命无疑会太大延长。 1 4 建模技术 从上述的论述可以看出，对软件开发过程中的对象进行抽象，将复杂的事件抽象成描述简单、 使用良好的模型是软件发展过程中的必经之路。并且，随着模型抽象的不断提升，开发人员就可以 使用更加接近于现实世界的概念来表达业务逻辑，可以设想，软件技术发展到一定阶段，最终用户 可以自己动手开发设计需要的软件了。 软件开发通常分为开发层次和设计层次。现阶段，开发层次的模型抽象已经达到组件的级别， 而在设计层次，则是使用如u m l 等建模工具实现软件模型的构造。但大多数人都习惯于把这种软 件模型看作设计工件，而把3 g l 程序看作开发工件。很多公司把建模人员和编码人员的角色完全分 离。其结果就是，模型比如u m l 模型，经常是非形式化的，这意味着它们不能被机器处理。编码 人员把它们当作“指南”和“说明书”使用，不直接作用于编码过程。如果一些形式化的模型可被 机器处理，这样的模型就是生产过程的直接部分，这就增加了提高软件开发效率的可行性。 模型驱动架构是由o m g 定义的一个软件开发框檠。其关键之处是，模型在软件开发过程中扮 演了非常重要的角色。在m d a 中，软件开发过程是由对软件系统的建模行为驱动的。这就从根本 上改变了传统软件开发方式。 1 5 国内外研究现状 o m g 的m d a 思想推出不久，世界各大计算机软件厂商i b m 、o r a c l e 、1 0 n a 、微软等等都急 忙宣称将在自己的企业级软件解决方案中融入m d a 的思想。两大建模工具厂商r a t i o n a l 和t o g e t h e r 也声明自己的产品开始加入对m d a 的支持。 目前国外已经出现了不少优秀的工具和平台以支持m d a 方法。如法国公司s o f t e a m 的 o b j e e t e e r i n g 工具，它是第一个完全支持m d a 方法的c a s es e 具。其它公司如t o g e t h e r s o r 的t o g e t h e r c o n t r o l c e n t e r ，r a t i o n a l 的r a t i o n a lx d e ，i n t e r a c t i v eo b j e c t ss o f t w a r e 的a r c s t y l e r ，c o m p u w a r e 的 o p t i m l j 都采用了m d a 思想。 m d a 在小公司中接受得要授一些，但在大公司中被迅速采用，原因很简单：它确实改变了软件 开发的方式，使软件开发过程变得更加有效。已经开展了建模工作的公司也往往只是这样做的：以 前的建模工作由于和系统实现没有联系，因此建模完了往往就丢在了一边，系统的实现是另外考虑 的。出现这种情况的原因在于：模型和实现没有直接的关系。m d a 要作的就是把模型本身也作为一 个开发的工件。由模型经编译器自动生成基于某种标准或平台( 如j 2 e e 、，n e t 、c o r b a 、c o m 等) 5 东南大学硕士学位论文 的软件代码，甚至得到w e bs e r v i c e s ，从u m l 到s o a p ( 简单对象访问协议) 和w s d l 的映射。因 此，采取基于模型的方法，不用产生大量的中间文档，实际上，工作成果将自动生成出代码。 2 0 0 4 年，基于模型驱动架构的金蝶e a s 4 0 集团版正式问世。上海普元公司的e o s 应用软件平 台、北京凯科思特公司的k c o m 商业工程企业应用平台都声称其实现了m d a 方法。金蝶e a s 4 0 产品研发过程可以抽象为三个步骤：第一步，建立元模型。元模型是建立模型的模型，元模型将管 理软件的所有应用原子化，所谓原子化，即将所有应用进行原子化分解，细分到不能再分割的操作 单元，每个操作单元即是一个原子化任务。元模型能将软件系统中存在的所有应用集进行原子化分 解，为业务语言即描述特定领域业务的语言开发打下了基础；第二步，在元模型的基础上，运用建 模工具建立业务模型，包括组织模型、功能模型、信息模型、流程模型等，这些模型属于平台无关 模型；第三步，根据不同的平台，对业务模型进行模型编译，生成相应平台的实现模型。这样就将 传统的业务模型和平台相关的实现模型分离开了，摆脱了管理软件对技术基础平台的依赖，同时， 从业务模型到不同平台的实现模型都保留了一致性。同一套业务模型，既可以在j 2 e e 平台上实现， 也可以在n e t 的基础上实现。 目前m d a 依然处在发展中，h m 到p s m 的定义尚未标准化，分析设计人员手工将p i m 转换成 p s m ，使用m d a 工具来辅助手工转换。 6 第二章筷型驱动开发方法综述 第二章模型驱动开发方法综述 在计算机领域，如何为软件的工业化大生产创造必要的技术条件和生产模式成为软件工程研究 的首要问题。无论是8 0 年代软件工程领域出现过的计算机辅助软件工程( c a s e ) 的热潮，还是基 于面向对象技术和组件技术的“装配重用”软件思路，都有一些根本性的问题没有得到解决，因此 大规模的“装配”软件生产还处在一个理想阶段。对象管理组o m g 近两年提出了基于模型驱动的 体系结构( m o d e ld i i v e na r c h i t e c t u r em d a ) 技术，该技术是建模技术发展史上的一个里程碑。m d a 是一种在软件开发中使刚模型来建立软件系统和解决互操作性等问题的途径。简单地说，m d a 是 o m g 在实现模型的可执行性上的努力，其目的是为了“把建模语言当编程语言来用”。为了实现这 个目的，o m g 制定了模型的精确形式化表示、模型存储以及模型交换方面的各种规范如u m l 2 、 m o f ( m e t a o b j e c t f a c i l i t y ) 、o c l ( o b j e c t c o n s t r a i n t l a n g u a g e ) 、q v t ( q u e r y v i e w t r a n s f o r m a t i o n s ) 、 x m l ( x m lm e t a d a t ai n t e r c h a n g e ) 等。 2 1m d a 的思想0 4 l m d a 不是某种具体的技术，也不是一种具体的方法论，它是包含了诸多规范的一个集合，是 o m g 提出的在模型驱动软制：开发方面的一个总的架构。 o m g 组织提出m d a 在两方面作了很大的努力： m d a 提供了统的元数据管理框架。 m d a 是o m g 在实现模型的可执行上进行的努力。 2 1 1m d a 提供了统一的元数据管理框架 国际标准化纲织o m g ( o b j e c t m a n a g e m e n t g r o u p ) 是独立于各厂商的非盈利性组织，其宗旨是 统一不同商业产品与标准之间的数据交换与互操作，从而改善各厂商软件产品之间的不兼容性。公 共对象请求代理结构( c o m m o no b j e c tr e q u e s tb r o k e ra r c h i t e c t u r e ，c o r b a ) 是o m g 以往的一个 重要的工作成果，c o r b a 致力丁提供一个跨平台和跨语言的对象互操作框架，在中问件层次上统 一不兼容的平台和不同语言开发的对象。但由于在中间件级别涌现出来的e j b 和n e t 造成了新的层 次上的不兼容，o m g 的这个努力已经被证明没有达到预期的效果。从这个意义上看，m d a 是一种 往比c o r b a 更高抽象层次上提供的实现软件间互操作的方法它是o m g 一贯思想的自然延续。 如图2 - 1 所示，在考虑当一操作性问题时，遵常将不兼容情况分为纵向和横向两个维度x m 可 以解决不同数据之间的不兼容，c o r b a 可以在一定程度上解决不同对象之间的不兼容。但不同软 件产品之间的交互，不仅限于数据与数据之间、对象与对象之间、或者模型与模型之间，不同层次 之间的交互也同样非常多，比如模型和源代码的交互( 由模型生成代码) ，模型和应用的交互等。以 东南大学硕士学位论文 以往的解决思路都没有考虑到不同层次间不兼容问题的解决，m d a 则在这方面做了重要的工作。 应用 对象 模型 数据 平台 应用 必 应用 对象对象 模型模型 数据 数据 u 口0 平台平台 图2 - 1 层次之间的不兼容性 同层次之间的不兼容，实质上是元数据的不兼容。m d a 的一个重要贡献在于提供了管理不同元 数据的统一框架。m d a 允许使用不同格式( 不同元数据描述) 的数据存在，并为描述这些数据的语 言( 其元数据) 提供了统一的定义语言，即m o f 。m d a 通过基于m o f 的四层元模型( 如图2 。2 ) 架构对元数据进行统一管理，不但能解决图2 1 中不同抽象层次上的不兼容的问题，还可以在更广 泛范围元数据的管理上发挥作用。举例来说，考虑一个软件开发过程。对于相同的组件，在需求阶 段，使用需求模型来描述；在开发阶段，使用u m l 模型来描述；在测试阶段，使用测试模型来描 述，由于侧重点的不同，不同阶段对这个组件的描述使用了不同的元模型。但是，在m d a 统 一的元数据管理框架下，这些由元模型描述得到的模型，就可以进行交互和转换等工作。这样，模 型就可以与应用进行互操作，由模型生成应用程序。 霸箍 删 蝴斌 i 蜷 m 3 m o f , 阳定义元模型的m o f 类、蔫 掬i 蠛合烛、关联罅 m 2多擞毅。由m o f 构造u m l 类、届 盼舞尉缎成性、状卷婷i 洲褒捌铺， 强i。模型，由m 2 j 灌蟹构。c 协燃“ 造盼爽朔i 组成樊、“v e a u t o r ” 袭等 m o 2 对煮制数据，也即觚l 窖户j 躺机账 横型糊造躲实调 声2 3 4 4 、蕊工： 啦9 4 9 镩 图2 - 2 m o f 的四层模型 2 1 2m d a 是o m g 在实现模型的可执行上进行的努力 m d a 的一个重要目标是加强模型在开发中的作用，简单地说，就是实现模型的可执行。m d a 技术的核心概念均是o m g 的一系列标准：统一建模语言u m l 、元对象设施m o f 、x m l 元数据交 换x m ! 、公共数据仓库元模型c w m 。m d a 的核心标准组成y f i l j 建模式驱动软件开发方法的基础。 8 第二章模型驱动开发方法综述 m d a 将抽象层次提高到模型的高度，其理想情况是：开发人员只要考虑与业务逻辑相关的模型设计， 而由模型到应用的实现过程中和业务无关的、重复的、低层次的工作，它可以交由机器来实现。目 前，m d a 要做的是将业务逻辑从不同的中间件平台( j 2 e e 、n e t 、c o r b a 、w e bs e r v i c e ) 中剥离 出来，开发人员只要考虑业务逻辑的建模，得到和具体中间件技术细节无关的p i m 。在m d a 提供 的相关技术支持之下，将p i m 转换成加入了技术细节的不同平台上的p s m 。最后，由p s m 生成应 用程序，其表现形式可能是一个可运行的j a v a 程序，或者是w i n d o w 系统上部署的w e bs e r v i c e ， 这样，m d a 的模型晟终实现了可执行性。 2 2m d a 方法的核心概念3 1 m d a 技术的核心概念均是o m g 的一系列标准：统一建模语言u m l ( u n i f i e dm o d e l i n g l a n g u a g e ) 、元对象设施m o f ( m e t ao b j e c tf a c i l i t y ) 、x m l 元数据交换x m i ( x m lm e m d m a i n t e r c h a n g e ) 、公共数据仓库元模型c w m ( c o m m o nw a r e h o u s em e t a m o d e l ) 。m d a 的核心标准组成 了创建模式驱动的一致性系统纲要的基础，这个系统纲要完成授权、发布和管理模型的功能。 下面介绍一下m d a 的各个标准在统一元数据方面所起的作用： 2 2 1c w l v l c w m 是用来对数据仓库( 包括关系型、非关系型等) 中的元数据进行建模的规范，它为数据仓库、 数据挖掘领域内的元数据定义了对应的元模型，它同时也是多层系统、异构系统间元数据实例交换 f f 勺基础。c w m 提供了一种数据格式变换的手段。在任意级别的模型上都可以使用c w m 来描述两 种数据模型之间的映射规则，比如将数据实体从关系数据库变换为x m l 格式。在m o f 的框架下， c w m 使得通用的数据模型变换引擎成为可能。这一新的元数据集成标准为顺利解决数据仓库的集 成问题提供了便利，从而解决了在组织中和组织之间共享数据的关键问题。 2 2 2u m l u m l 是定义c w m 的符号基础( 不光是c w m ，这里只谈论u m l 对于统一元数据所做的努力) ， 但是c w m 同时也扩展了核心的u m l 元模型的子集来支持数据仓库等。使用c w m 来构建数据仓 库模型的时候，可视化的建模工具是首选。一方面包含复杂的元数据结构的可视化模型对于人来说， 易于管理和理解。另一方面，由于u m l 语言被精确地定义( 通过u m l 元模型) ，可视化的u m l 模 删能够被自动地转换到其它格式。这就给交换与平台、工具无关的c w m 模型，以及从c w m 模型 中构造i 具相关的元数据都带来了便利性。 2 2 3 m o f 不同的建模对象或领域需要不同的建模结构集：关系数据建模所需的建模结构包括表、列、键 等等。工作流建模所需的建模结构集包括活动、执行者、变化、分割、连接等等。u m l 类建模所需 9 东南大学硕士学位论文 的建模结构集包括类、属性、操作、关联等等。定义c o r b a 接口的建模结构集包括接口、值类型 等等。所以，为了描述某一特定类型的模型，必须描述组成该类模型的建模结构集。能有一种一致 的方法来描述语言结构是非常有用的。业界正在使用全然不同的方法来描述不同类型建模结构的本 质。m o f 放弃了把这些不同的建模结构集都合并成一个集合的想法，而采用统一方式来描述组成某 类模型的建模结构属性以及建模结构间的关系。 m o f 被用来描述关系数据模型的建模结构，也被用来描述u m l 类模型的建模结构；它还被用 来描述其他种类的建模所用到的结构。m o f 是通用的、抽象的，用于定义元模型的语言，它可以被 称为m e t a m e t a m o d e l 或者定义元模型的模型。m o f 天生就是面向对象的，它定义了基本的元素、语 法、元模型的结构。m o f 可以作为定义c w m 和u m l 元模型的更通用的模型。 m o f 标准提供了： 抽象模型：定义m o f 对象和他们之间的关联 规则的集合：将基于m o f 的元模型映射到语言无关的接口( 使用c o r b ai d l 来定义) 。对 这些接口的实现可以被用来访问和修改任何基于这个元模型的模型。 定义元模型元素的生命周期、复合、和关闭语义的规则。 层级的反射接口( r e f l e c t i v ei n t e r f a c e s ) ：定义了通用的操作，用于发现( d i s c o v e r ) 和操纵基于 m o f 元模型的模型，但是对于映射后的接口的属主是未知的。 如图2 - 2 ，列出了m o f 包含的4 个元层次以及其作用，m 3 层是元层次的尽头，层次止于此，因 为m 3 层m o f 元素是m 3 层m o f 元；素的实例。换句话说，m o f 用m o f 来描述本身，也就是说m o f 是自 描述的。m o f 为其自身结构定义了一个遵守m o f 的模型。该模型常被称为m o f 自身模型。m o f 自身 模型同其余任意m o f 元模型均有细微差别：它是m o f 的m o f 元模型。 2 2 4 x m i x m i 将m o f 映射到w 3 c 的x m l 语言上。x m 定义了x m l 标记( t a g s ) 如何表示序列化的兼容 m o f 的模型。基于m o f 的元模型被转换为d t d s 或者x m ls c h e m a ，模型根据其对应的d t d 或者 x m ls c h e m a 被转换为x m l 文档。以前基于标记的语言在表示对象和对象的关联上存在许多的困 难，而这在x m i 中得到了解决。此外，x m i 基于x m l 的特性，意味着元数据( 翔t a g s 表示) 和其实 例【元素内容) 可以共存于同一个文档中，这使得应用程序可以容易地通过其元数据来理解实例。x m i 同时具有自描述和天生的同步特性，这就是为什么基于x m l 的交换在分布式的、异构环境中是如此 重要的原因。 x m i 是o m g 组织发布的m d a ( 模型驱动构架) 规范族的一员。x m i ( x m l b a s e d m e t a d a t a i m e r c h a n g e ) 是z 基- 于x m l 的元数据交换。它通过标准化的x m l 文档格式$ i d t d s ( d o c u m e n tt y p e d e f i n i t i o n s ) 为u m l 元模型( 元模型是一类特殊的模型) 和其他模型定义了一种基于x m l 的数据 1 0 第二章模型驱动开发方法综述 交换格式。它同时也定义了一个从u m l 到x m l 的映射。 x m i 的主要目的就是让各种分布式的异构环境中的建模工具和元数据存储( m e m d a t ar e p o s i t o r i e ) 仓库之间能方便地进行数据交换。其中，建模工具基于o m g - - l f f v l l ，元数据存储仓库基于o m g m o f 。x m i 集成了三个关键的工业标准：x m l 一扩展标记语言( e x l e n s i b l em a r k u pl a n g u a g e ) ， m ，一统一建模语言( u n i f i e d m o d e l i n g l a n g u a g e ) ，m o f 一元对象设施( 诅o 巧e c t f a c i l 对) 。 这三个标准的集成是o m g 和w 3 c 元数据和建模技术的最好的“联姻”。它能使各个分布式系统 的开发人员能在互联网上方便地共享他们的对象模型和元数据。在o m g 采纳的u m l 规范中把u m l 元模型定义成一个m o f 元模型。这意味着x m i 规范将直接带领我们进入使用u m l 格式的模型进行数 据交换的时代。 x m i 规范中包括了两个主要的部分： x m ld t d 的产生规则：用于为使用x m i 进行编码的元数据文件产生相应的x m ld t d 文件。 x m id t d s 作为x m i 文档的语法描述文件，可以方便地使用通用的x m l t 具对x m i 文档进行有效 性校验。 x m l 文档的产生规则：它为元数据蓼j x m l 文档提供了编码规则。同样它还应用于把x m i 文 档反编码，重新构造生成元数据。 x m i 规范支持任何可以用m o f 表示的元数据( 包括模型和元模型) 的数据转换。规范同时支持 完整的模型或是一个模型的片断到x m l 的转换。 2 3 v l d a 方法的开发过程 m d a 开发模式关注的是对系统的建模，包括对模型的理解、设计、创建、维护和修改。图2 3 显示了模型驱动开发方法解决问题的过程： m d a 开发过程，班平台无关的模型p i m 作为驱动 图2 - 3 模型驱动的开发途径的解决问题的过程 m d a 开发模式的生命周期与传统的方式看起来区别并不大。它们具有相同的开发阶段，主要的 区别是各个阶段的设计工件不同的。m d a 的设计工件是精确的模型，它们能够被机器理解。m d a 开发过程通常包含以下几个阶段： 东南大学硕士学位论文 1 首先，与普通的应用开发一样要对需求进行了解，获取需求相关的文档。 2 其次，使用平台无关模型p i m ( p l a t f o r m i n d e p e n d e n t m o d e l ) 从支持从业务逻辑的角度来对 系统进行建模。p i m 是对系统的一种高层次的抽象，与具体的实现技术无关。在此过程中，会 不断根据客户需求和其它因素对p i m 进行精化，使得它能够更加精确的描述系统。 3 然后，p i m 可以被转换到一个或者多个特定业务层模型p s m s ( p l a t f o r m s p e c i f i e dm o d e l ) 。 p s m 是针对确定的实现技术、平台，为系统度身定做的模型。例如，j 2 e e - p s m 是对使用j 2 e e 结构的系统的建模，它包含一些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 i m 拥有多个p s m 是很正常的。 这是m d a 中最复杂，也是最重要的一步。有时，由p i m 自动生成的p s m 并不是很满意，可以 根据平台的特性对p s m 加以修改，对p s m 的修改能够反映到p i m 中去。 4 对p s m 进行不断的精化，以指导生成器生成质量更高的代码。 5 最后一步就是将每个p s m 都转换到代码，由于p s m 跟具体的系统实现技术已经很接近，因 此这种转换来得比较直接。 2 第三章m d a 方法的关键技术 第三章m d a 方法的关键技术 3 1 对u m l 的扩展 3 1 1 u m l 在m d a 中的角色 u m l 是使能m d a 技术的一把钥匙：使用m d a 技术创建的所有应用程序都基于标准化的、平 台独立的u m l 模型。通过将这一通用的、被普遍接受的建模标准作为杠杆，使得m d a 可以创建能 被容易地访问、具有良好的互操作性的应用程序。 在m d a 中使用u m l 的方式可以有两种： 使用u m l 来对系统进行建模，产生p i m 。使用u m l 建立的模型必须具有一致性和精确性， 能够被m d a 工具理解并能够被转换成模型和代码。 软件架构师需要定义用于指导模型转换的规则。他们不开发某个特定系统的模型，而是创建 将一种模型转换到另一种模型的规则，这种规则是可以作用于任何模型和不同的系统