（计算机软件与理论专业论文）基于mda的持久层代码生成系统.pdf

摘要 本文将m d a 过程应用于生成持久层代码。在对多个建模工具的比较研究后，确 定使用v pf o ru m l 作为p i m 的建模工具，对该工具所导出的类模型的x m l 文件结构 做了深入分析，提出了解析该文件结构的算法，实现了对它的高效解析；确定了使用 e u m l 2 作为p s m 的建模工具，分析了它所支持的e c o r e 模型以及e c o r e 文件结构，并 提出了针对e c o r e 文件的生成算法，应用该算法比应用e m f 生成e c o r e 文件更加简便。 本文将观察者模式、v e l o c i t y 技术应用于最终代码的生成过程，提高了生成效率并简化 了生成操作。本文重点解决了对实体间泛化关系的支持，这是那些通过建数据库表生 成持久层代码的系统所不具备的功能。和它们相比，本文所研究的持久层代码生成系 统将使应用丌发更加高效，因为它不但没有在原有的应用开发过程中增加额外的工作， 而且取消了建数据库表这一步骤。 关键字：m d a 持久层p i mp s m 代码生成系统 a b s t r a c t t h ep r o c e s so fm d ai sa p p l i e dt og e n e r a t i n gp e r s i s t e n tl a y e rc o d ei nt h i sp a p e r a f t e r d o i n gc o m p a r a t i v es t u d ya m o n g s tan u m b e ro fm o d e l i n gt o o l s ，i ti sd e t e r m i n e dt ou s e v pf o r u m la st h em o d e l i n gt o o lo fp i m ，t h ex m ld o c u m e n ts t r u c t u r ei sa n a l y z e dw h i c h i s e x p o r t e df r o mc l a s sm o d e l sb yt h i st o o la n dt h ea l g o r i t h mi sp r o p o s e dw h i c hi s u s e dt o a n a l y z et h i sd o c u m e n ts t r u c t u r e ，f o rw h i c ht h eh i g h e re f f i c i e n c yo fa n a l y s i si sr e a l i z e d ；i ti s d e t e r m i n e dt ou s ee u m l 2a st h em o d e l i n gt o o lo fp s m ，t h ee c o r em o d e lw h i c ht h i st o o l s u p p o r t sa sw e l la se c o r ef i l es t r u c t u r ea l ea l la n a l y z e da n dt h eg e n e r a t i o na l g o r i t h mf o r e c o r ed o c u m e n t si sp u tf o r w a r d a p p l y i n gt h i sa l g o r i t h mt og e n e r a t i n ge c o r ed o c u m e n t s l s m o r ee a s i l yt h a na p p l y i n ge m ei nt h i sp a p e r , o b s e r v e rp a t t e r na n dv e l o c i t yt e c h n o l o g ya r e a p p l i e dt ot h ep r o c e s so fg e n e r a t i n gf i n a lc o d e ，t h u st h eg e n e r a t i n ge f f i c i e n c yi si m p r o v e d a n dt h eg e n e r a t i n go p e r a t i o ni ss i m p l i f i e d t h ep r o b l e mo ft h es u p p o r to fg e n e r a l i z a t i o n r e l a t i o n s h i pa m o n ge n t i t i e si ss o l v e d ，w h i c hi sn o tb es u p p o r t e db yt h o s es y s t e m sw h i c h a u t o m a t i c a l l yg e n e r a t ec o d ef o rp e r s i s t e n tl a y e rb yb u i l d i n gd a t a b a s et a b l e s c o m p a r e dt o t h o s es y s t e m s ，t h en e wc o d eg e n e r a t i o ns y s t e mf o rp e r s i s t e n tl a y e rw i l le n a b l ea p p l i c a t i o n d e v e l o p m e n tt ob em o r ee f f i c i e n t ，a si t n o to n l yd o e s n ta d de x t r aw o r ki nt h eo r i g i n a l d e v e l o p m e n tp r o c e s s ，b u ta l s oc a n c e l st h es t e po fb u i l d i n gd a t a b a s et a b l e s k e yw o r d s ：m d ap e r s i s t e n tl a y e r p i mp s mc o d eg e n e r a t i o ns y s t e m 长春理工大学硕士( 或博士) 学位论文原创性声明 本人郑重声明：所呈交的硕士( 或博士) 学位论文，基于m d a 的持久层代码生成 系统是本人在指导教师的指导下，独立进行研究工作所取得的成果。除文中已经注 明引用的内容外，本论文不包含任何其他个人或集体己经发表或撰写过的作品成果。 对本文的研究做出重要贡献的个人和集体，均己在文中以明确方式标明。本人完全意 识到本声明的法律结果由本人承担。 作者签名：盈q 年l 月丝日 长春理工大学学位论文版权使用授权书 本学位论文作者及指导教师完全了解“长春理工大学硕士、博士学位论文版权使 用规定，同意长春理工大学保留并向中国科学信息研究所、中国优秀博硕士学位论文 全文数据库和c n k i 系列数据库及其它国家有关部门或机构送交学位论文的复印件和电 子版，允许论文被查阅和借阅。本人授权长春理工大学可以将本学位论文的全部或部 分内容编入有关数据库进行检索，也可采用影印、缩印或扫描等复制手段保存和汇编 学位论文。 作者签名： 指导导师签名： 年上月旦日 年土月羔日 1 1 本文研究的目的和意义 第一章绪论 通过对多个基于j 2 e e 技术的项目的比较研究，发现这些项目之间有不少类似的地 方。例如持久层所采用的通常都是h i b e r n a t e 技术，运用的设计模式都是d a o ( d a t a a c c e s so b j e c t ) 模式l l j 。业务层的每一个业务方法通过调用持久层的一组d a o 来完成 一项业务。以上这种设计已经被多个项目应用，并被确认为相对优秀的持久层和业务 层解决方案。在持久层d a o 中最常出现的方法有四个，即针对某个数据表的i n s e r t 、 u p d a t e 、d e l e t e 、s e l e c t 操作。d a o 一般是与业务无关的，仅仅是对数据表的操作【2 1 。 因此，持久层代码十分适合使用工具自动生成。实际上，目前也出现了不少持久 层代码的生成工具，而且生成的代码是绑定于h i b e r n a t e 框架的，例如h i b e r n a t e s y n c h r o n i z e r 、h i b e r c l i p s e 等。但在项目中使用这些代码生成工具后发现，它们都需要 建数据库表，该步骤类似于使用d b m s 的客户端管理工具建数据表。因此，这些工具 生成代码的过程还是很繁琐。此外，由于关系数据建模并不能体现泛化关系，所以， 这些代码生成工具也无法支持实体间泛化关系。 综上，需要开发一个新的持久层代码生成系统( 以下简称新系统) 。新系统生成持 久层代码的方式和那些通过建数据库表来生成持久层代码的系统不同，新系统应用了 m d a 过程。应用新系统不仅不在原有的应用开发过程中增加额外工作，而且不需要建 数据库表。此外，应用m d a 使得新系统能够支持实体间泛化关系( m d a 可以使用 u m l 来进行实体问关系建模，而u m l 支持泛化关系) 。应用新系统还能获得如下两个 方面的益处： 首先是简化开发，尤其要做到持久层的零代码。通过分析以往所做过的项目，发 现持久层的代码往往不带有业务逻辑。持久层的操作很简单，就是对数据库的添加、 删除、修改以及检索。这些代码是可以由软件自动生成的。以往在开发项目时，都要 为持久层编写代码。这些代码虽然简单，但代码量却很庞大，除了j a v a 源代码文件还 需要编写很多的配置文件。在编写完持久层代码之后还要进行测试。占用了很多的开 发时间。如果持久层代码能够自动生成。不但节省了开发时间，减轻了程序员的负担， 而且生成的代码会有更少的b u g ，持久层几乎不用专门测试。 其次是代码更加规范，更利于管理和维护。新系统所生成的持久层代码是符合d a 0 设计模式的。业务层需要通过d a o 工厂来获取d a o 。然后通过调用d a o 的相关方法 来持久化业务数据。在界面层则需要使用业务代理工厂来获取业务代理类以完成业务， 业务代理类提供了数据库事务的代理服务。因此，当新系统生成持久层代码的同时也 就规范了业务层以及界面层的一些操作。整个应用系统的结构更加清晰，代码更易读。 自然也就更利于维护并且能有效减少b u g 。 新系统还必须具备优良的用户界面。既然要提高应用开发的效率，就必须提供便 捷的操作。新系统能够为开发人员提供与u m l 建模方式相同的操作体验，即开发人员 只要像画u m l 类图一样画出应用系统的每一个实体以及实体间的关联关系、泛化关 系。然后经过简单的操作，就可以获得持久层所需要的所有代码。在提供便捷操作的 同时，新系统也必须提供一定的灵活性，即开发人员可以根据项目的具体需求进行代 码的定制。此外，从建模阶段的模型元素到最终生成的代码都必须符合目前业界的相 关规范。 1 2 国内外研究现状 1 2 1m d a m d a 是o m g 在2 0 0 2 年初确定的战略方向。m d a 以新的方式整合一系列趋势， 从而有助于软件业应付企业计算的压力。m d a 对基于组件丌发、设计模式、中间件、 说明性规约、多层系统、企业应用集成、契约式设计等技术进行扩展并推动这些技术 更好地协作。 m d a 使用基于标准的建模语言作为形式化开发语言【3 】。形式化模型驱动产生3 g l 代码、h t m l 、x m l 、w s d l 、i d l 以及其他工件的生成器。形式化模型是m d a 的核 心，它是生产过程的直接部分。在这样的环境下，建模人员和编码人员的角色区分就 不再那么明显了。建模行为即编码行为。这并不意味着不再需要非正式的建模。非正 式的建模有助于人们之间关于构架和设计的交流。非正式的建模是对u m l 的良好运 用，但是不能驱动代码生成器。 通常使用u m l 作为形式化模型的建模语言，它也是m d a 推荐的建模语言。o m g 在较新版本的u m l 中定义了u m l 自身的形式化模型。该模型定义了u m l 建模者使 用的概念，并将它们赋予抽象语法( 而非图形表示法的语法) 。u m l 的这一形式化模 型被称为u m l 的元模型。元模型是模型的模型。除了u m l 模型被形式化定义之外， o m g 还定义了一种基于x m i 的x m l 语法来表示u m l 模型，以及如何用j a v a 对象和 c o r b a 对象来表示u m l 模型1 4 j 。 u m l 具有内置的扩展机制，允许在u m l 已经定义的基本建模结构之上定义新的 建模结构。一个扩展集构成了u m l 的一种方言，被称为p r o f i l e l 5 1 。u m l 的p r o f i l i n g 机制是对m d a 的一大贡献。使用p r o f i l e ，可以为系统的某一方面定义特定语言。 o m g 在1 9 9 7 年批准了m o f ( 元对象设施) ，它是u m l 的姐妹标准。m o f 和u m l p r o f i l i n g 一样，是m d a 的语言定义机制。对m d a 而言，m o f 更重要，因为甚至u m l 都是使用m o f 定义的。m o f 是用来定义u m l 元模型的语言，即u m l 元模型的模型。 m o f 的诞生基于一个基本假定，那就是会有不止一种模型，所以建模语言也会有不止 2 一种，因为不同的功能需要不同的建模结构集【6 j 。 m o f 从u m l 借鉴了面向对象类建模结构，并将其作为描述建模结构的抽象语法。 因此m o f 模型看上去就像u m l 类模型。o m g 为m o f 定义了4 个元层次，分别被命 名为m 3 、m 2 、m 1 和m 0 ，m o f 模型处在m 3 层【7 j 。在元层次结构中，某一层次的元素 通常由上一层次的元素来描述，m 3 层除外。m 3 层的m o f 元素是m 3 层m o f 元素的 实例。换句话说，m o f 是自描述的。制定元层次在某些情况下具有实践价值，它有利 于解释某些概念，有利于人们更好地理解模型。 目前，国外有关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 的体系中作一个最初的探索和尝试。例如o r m 就 是在一定层次上实现m d a 在数据库应用方面的探索，但也只是解决了一个实体模型 映射的问题。 1 2 2d a o 设计模式 d a o ( 数据访问对象) 模式是j 2 e e 模式目录中的一个常用模式，因为大多数j 2 e e 应用系统都需要访问数据库。目前国内对于d a o 模式的应用十分广泛，这主要得益于 j a v a 及j 2 e e 技术在国内的流行。 d a o 模式的产生也是为了适应企业计算的复杂性。众所周知，大多数企业级应用 会使用关系型数据库管理系统( i b m s ) 作为持久化存储介质。但是，企业数据也可 能存储于别的地方，例如大型主机或者遗留系统、轻量级目录访问协议( l d a p ) 仓库、 面向对象数据库( o o d b ) 、普通文件等。另外，可以把外部系统的服务所提供的数据 也视为持久化数据，例如b 2 b 集成系统，信用卡机构的服务等等。 对于这些形形色色的持久化存储介质，它们的访问机制、支持的a p i 和功能特性 也是各不相同的。即便是遵从同一套a p i ，底层的实现也可能在标准的特性之外再提 供一些专有的扩展。 如果将持久化逻辑与应用逻辑混淆，就会导致应用程序直接依赖于持久化存储机 制的实现。一旦在组件中出现这样的代码级依赖，再想把应用程序从一种数据源移植 到另一种数据源就会困难重重。当数据源发生变化时，组件也必须加以修改才能使用 新的数据源。 d a o 模式的参与者一般包括：c l i e n t ( 客户端) 、d a t a a c c e s s o b j e c t ( 数据访问对象) 、 d a t a s o u r c e ( 数据源) 、r e s u l t s e t ( 结果集) 以及d a t a ( 数据) 。有的文献中将d a t a 称 为传输对象( t r a n s f e r o b j e c t ) ，也有的将其称为值对象( v a l u e o b j e c t ) ，这两个名称所 指都是同一个事物。国内也有文献将c l i e n t 称为b u s i n e s s o b j e c t ( 代表业务层的数据访 3 问请求端) 。 d a o 设计模式通常和工厂方法模式1 8 】以及抽象工厂模式【8 】联合使用，后两种模式 主要用于获取d a t a a c c e s s o b j e c t 。d a o 工厂方法策略是最常用的策略。抽象工厂模式 用于进一步提高工厂实现的灵活性。如果需要经常切换持久化存储介质，或者同时使 用多种存储介质，就会需要这种灵活性。国内有文献提出使用反射机制来实现抽象工 厂模式，从而实现服务端与工厂类的彻底解耦。 1 3 本文的主要工作和组织结构 首先，对h i b e r n a t e 框架做了非常深入的研究，对它的特性充分了解。因为新系统 所生成的代码是基于h i b e r n a t e 框架的。因此，为了保证正确性以及广泛的适用性，必 须对h i b e m a t e 有全面、深入的了解。 其次，对建模工具( 包括p i m 以及p s m 建模工具) 做了比较研究。因为新系统不 可能对所有的建模工具都提供支持，因此必须从众多的建模工具中选择合适的工具。 对于p i m ，本文最终选择了v i s u a lp a r a d i g mf o ru m l 6 3c o m m u n i t ye d i t i o n ( 以下简称 v p f o r u m l ) ，并分析了它所导出的类模型的x m l 文件结构，在此基础上提出了针对 该文件结构的解析算法；对于p s m ，本文选择了e c l i p s e 的u m l 插件e u m l 2 作为建 模工具，并分析了它所支持e c o r e 模型结构以及e c o r e 文件结构，在此基础上提出了生 成e c o r e 文件的算法。 最后，应用观察者模式以及v e l o c i t y 技术来生成最终的代码。在这一过程中，重 点解决了复合主属性以及实体间关联关系、泛化关系的支持问题。 本文还提出了将j a v a 反射机制与h i b e r n a t e 的q b c 查询机制相结合实现较复杂的 查询功能，以及将j a v a 动态代理机制应用于代理模式实现数据库事务代理功能。 本论文共分七章，各章组织如下： 第一章：说明了本课题研究的目的、意义、研究现状，以及论文的组织结构。 第二章：通过实例研究了m d a 过程中的关键步骤，从而确定了新系统的关注点 以及需要解决的问题。 第四章：阐述如何从p i m 转化为p s m 。确定了使用v pf o ru m l 作为p i m 的建模 工具以及e u m l 2 作为p s m 的建模工具。详细论述了p i m 所对应的x m l 文件的格式、 e c o r e 文件的格式以及如何将前者转化为后者。 第五章：详述了如何将p s m 转化为最终代码。首先介绍了h i b e r n a t e ，确定了新系 统的目标，接着论述如何解析p s m ，最后详细讨论了对关联关系、泛化关系以及复合 主属性等的支持是如何实现的。 第六章：对新系统进行了扩展，使其能够支持基本查询以及数据库事务。 第七章：对全文工作进行总结，提出了目前存在的问题和下一步的工作目标。 4 第二章m d a 过程研究 本章通过一个实例研究了m d a 过程所需的各类模型以及这些模型间的基本关系 和映射。这并不是一个完整的m d a 过程，只是阐述了m d a 过程中在不同抽象层次上 的不同类型的模型，以及这些模型之间、模型与代码之间的关系。尽管这不是一个完 整的m d a 过程，但却包含了m d a 过程中最重要、最关键的部分。 本章的实例是一个职称评审系统的参评人申报子系统。该子系统负责完成参评人 申报流程，为参评人提供编辑基本信息、编辑附属信息、上传附件等功能。本节所使 用的模型均为u m l 模型，u m l 是m d a 推荐的建模语言。 2 1 业务模型 业务模型描述了业务领域，如职称评审领域。业务模型通常在捕获需求的过程中 产生。常用的业务模型有用例模型、活动模型、交互模型、协作模型等。图2 1 是一个 业务的用例模型，描述了参评人申报子系统的用户角色以及相关的活动。 黪谬久 、心 图2 1 参评人申报子系统的片j 例图 图2 2 是一个活动模型，描述了参评人申报的业务流程。该业务模型不考虑业务过 程的哪些部分要被自动化。 _ 洲挺储司 f 、 - 飞。兰 科”协 ，1 回 2 2 需求模型 需求模型通常在分析的过程中产生。其实，捕获需求与分析之间并没有十分严格 的界限。业务模型主要面向最终用户，而需求模型主要面向系统的开发人员。常用的 需求模型有状态模型、类模型、交互模型、协作模型和用例模型等。 图2 3 是一个类模型，描述了参评人申报业务所涉及的相关实体类。这是一个信息 理想化模型，因为它独立于技术设计决策，即独立于计算。例如，b a s i c l n f o 表示参评 人基本信息，它没有属性，所以在技术设计时会为它添加属性并定义属性的数据类型。 对q u a l i f i c a t i o n ( 学历学位) 、a c a d e m i c g r o u p ( 学术团体) 、w o r k e x p e r i e n c e ( 工作经历) 、 a p p l i c a n t a c c e s s o r y ( 附件) 等实体类也要做出同样的技术决策。 图2 3 参评人申报子系统实体类图 2 3 平台无关模型( p i m ) 在理想的世界中，需求分析员只需要把需求模型递交给生成器，生成器就能自动 生成需要的系统。但在实践中，需求模型通常是比较简略的。以图2 3 所示类模型为例， 该类模型显示了参评人申报业务所涉及的相关实体类的名称以及若干实体类的若干属 性，但并未包括所有实体类的所有属性，也未包括类的用途。因此只是一个简略的模 型，该模型需要被进一步细化。细化后的模型是能够被生成器处理的计算模型，即平 台无关模型p i m 。 图2 4 是一个p i m 。通过使用 构造型标识了类是实体类，将被实现 为持久层的v o 类。此外，还定义了所有v o 类的所有属性以及属性的数据类型。但 p i m 并未标明实体类将用何种3 g l 来实现，因此它满足了“独立于3 g l ”这一平台独立 性标准。 6 图2 4 参评人申报予系统的p i m 2 4 平台相关模型( p s m ) 平台相关模型( p s m ) 可以由p i m 自动生成。平台相关模型是一个同特定的信息 格式化技术、编程语言、分布式组件中间件、消息中间件相关的计算模型。本小节讨 论的p s m 同j a v a 编程语言相关。如图2 5 所示，每个实体类的数据类型都绑定到了某 个j a v a 的数据类型。如e l o n g o b j e c t 表示j a v a 1 a n g l o n g 、e s t r i n g 表示j a v a 1 a n g s t r i n g 、 e b y t e a r r a y 表示b y t e ，即b y t e 数组。 图2 5 参评人申报子系统的p s m 7 第三章p i m 到p s m 的转化 运用d a o 设计模式后所产生的效果大多数是正面的，但由于引入了一个新的层 次，增加了应用系统开发的工作量，包括设计、编码和测试。新系统主要目的就是为 了消除运用d a o 模式后所产生的负面效果。 研究发现，d a o 设计模式中一个值对象通常对应一个数据访问对象；值对象中的 方法基本上都是对其属性的g e t 、s e t 操作；数据访问对象都会拥有i n s e r t ( 插入) 、u p d a t e ( 更新) 、l o a d ( 读取) 、d e l e t e ( 删除) 以及f i n d ( 查询) 五个方法：这五个方法对于 任何一个值对象来说所做的操作都是一样的，方法的参数个数也是相同的，所不同的 是参数的类型。因此，完全可以通过一种方式来自动地生成符合d a o 模式的持久层代 码。目前，也已经出现了这样的工具，例如h i b e r n a t es y n c h r o n i z e r ，这是一个e c l i p s e 的插件，通过构建数据库表的方式来生成持久层代码。这么做的优点是在生成代码的 同时连数据库表也建好了。但这种生成方式也有弊端。首先，必须为用户提供一个类 似数据库客户端一样的建表工具。用户建表的过程和以往在数据库客户端中建表的过 程是一样的。这种方式实际上并没有消除建表这一开发活动。其次，该插件并不支持 实体间的泛化关系。究其原因，它是通过建数据库表的方式生成持久层代码，而关系 数据建模并不能体现泛化关系。 新系统引入了m d a 开发方法。通过第二章的介绍，m d a 过程主要是建模，代码 最终由模型生成。m d a 过程主要的模型有业务模型、需求模型、p i m 、p s m 。m d a 过程与面向对象软件开发过程是类似的，都要经历捕获需求，分析，设计( 细化) 、实 现这四个阶段。m d a 主要是将实现阶段自动化了，即从p i m 到p s m 、p s m 到最终代 码这两个转化过程是自动完成的。m d a 可以使用u m l 来构建模型m d a 也可以 使用别的建模语言来构建模型，但u m l 是m d a 推荐的建模语言。 新系统生成代码的方式是由类模型产生最终代码。与h i b e r n a t es y n c h r o n i z e r 相比， 消除了建数据表这一开发活动，而且能够提供对泛化关系的支持。本章主要介绍如何 从p i m 自动生成p s m 。 3 1p i m 与p s m 的建模工具研究 3 1 1u m l 新系统使用u m l 作为p i m 的建模语言。推荐使用支持u m l2 0 的u m l 工具， 因为在1 2 1 小节介绍了u m l2 0 包含了u m l 自身的形式化模型，并且o m g 还定义 了一种基于x m i 的x m l 语法来表示u m l 模型。因此支持u m l2 0 的u m l 工具通常 8 都具有将u m l 模型图导出为x m l 文件的功能【9 】。从而使生成器能够通过对x m l 文 件的解析来精确地理解u m l 模型。 新系统推荐使用的u m l 工具为v pf o ru m l ，这是一个用j a v a 开发的u m l 工具， 支持u m l2 1 规范，具备将u m l 模型导出x m l 文件的功能。例3 1 所示的是使用 v pf o ru m l 的“导出x m l ”功能所导出的x m l 文件的片段。该x m l 文件由图3 1 所 示的u m l 类模型图导出。图3 1 所示的u m l 类图包含1 个包、4 个类、3 个关系、2 个属性、1 个构造型，尽管元素不多，但具有代表性。 图3 1u m l 类模型图 例3 1 由u m l 类图导出的x m l 文件的片段 ! 定义关联关系 m o d e l r e fi d = ”c l a s sl ”胁 9 ! 一定义泛化关系- ! 定义包一 ! 一定义类 ! 一定义属性 m o d e l r e f i d = ”s t r i n g ”厶 1 0 ! 一显示相关部分 v pf o ru m l 所导出的x m l 文件十分庞大，例3 1 中所示的x m l 文件片段剔除了 很多对于新系统无关紧要的信息。x m l 文件主要包括两大部分，模型部分与显示部分， 标签定义的为模型部分， 标签定义的为显示部分，新系统主要关 注模型部分，即 标签中的内容。 标签中定义的u m l 模型图中的所有模型元素，每个模型元素用一个 标签定义。 标签都包含i d 属性与m o d e l t y p e 属性。i d 属性用来唯一标 识一个模型元素，不同模型元素在当前的x m l 文件中不会拥有相同的i d 属性值，通 过i d 属性还可以方便地引用模型元素。在例3 1 的x m l 文件中随处可见 标签，该标签就是用于引用某个模型元素，其i d 属性的值为所引用的模型元素的i d 属 性值。m o d e l t y p e 属性用于区分模型元素的类型，即分类。在u m l 类图中常见的模型 元素有：表示包的模型元素( m o d e l t y p e 属性值为p a c k a g e ) 、表示类的模型元素 ( m o d e l t y p e 属性值为c l a s s ) 、表示关联关系的模型元素( m o d e l t y p e 属性值为 a s s o c i a t i o n ) 、表示泛化关系的模型元素( m o d e l t y p e 属性值为g e n e r a l i z a t i o n ) 、表示构 造型的模型元素( m o d e l t y p e 属性值为s t e r e o t y p e ) 、表示数据类型的模型元素 ( m o d e l t y p e 属性值为d a t a t y p e ) 等等。 标签中的模型元素可以有父子关系，也可称为包含关系。在面向对象的 概念里，“包”可以包含“类”，“类”可以包含属性。例3 1 所示的x m l 文件通过使用 标签来体现模型元素之间的包含关系。如图3 1 中4 个类的模型元素就 被定义在c a 包的模型元素的 标签内；c l a s s l 类的a t t r 属性的模型元素也 被定义在c l a s s l 类模型元素的 标签内。 “关系类型”的模型元素通常都有一个“f r o m ”端，一个t o ”端。以关联关系为例，在 “f r o m ”端与t 0 ”端总有一个n a m e 属性值为m u l t i p l i c i t y 的 标签，该标签 定义了被关联的模型元素的个数。如图3 1 所示，c l a s s l 与c l a s s 2 之间是一对多的关 系，则c l a s s l 端的m u l t i p l i c i t y 值为1 ，c l a s s 2 端的m u l t i p l i c i t y 值为0 木。图3 1 中c l a s s 4 比较特殊，它是一个自关联的类，因此“f r o m ”端与”端都指向c l a s s 4 ，但两端的 m u l t i p l i c i t y 值不同，其中一个值为1 ，一个值为o 。 。 “类”模型元素通常包括两个部分。第一部分定义了与“类”模型关联的“构造型”模 型，如c l a s s l 所关联的 ，用 标签引用；第二部分定义了类 的属性，属性也是通过 标签引用到相关的“数据类型”模型。 3 1 2e m f 本小节，将讨论新系统的p s m 。p s m 可以使用u m l 建模。如果使用u m l 建模， 则需要构建更多的构造型，使模型能够更充分地表达平台相关信息。由于p i m 是使用 u m l 构建的，则在p i m 中添加更多的构造型，p i m 就转化成了p s m 。但新系统并未 使用这种方式来构建p s m 。首先，本课题所使用的v pf o ru m l 虽然可以自定义构造 型，但将对象的属性与某个构造型关联之后，不能够在图形中反应出来，而必须查看 属性的详细信息才能了解它所关联的构造型，十分不直观。其次，p s m 的构建还是需 要人工完成，当模型很复杂的时候，工作量是相当大的，而且人工构建p s m 也不符合 m d a 的精神。最终，新系统选择使用e m f 来构建p s m 。 e m f ( e c l i p s em o d e l i n gf r a m e w o r k ) 是e c l i p s e 的一个建模框架，它是一个j a v a 开源框架与代码生成工具，用于为基于结构化的模型构建工具和其它应用程序【l0 1 。给 定一个模型后，e m f 就能够生成j a v a 源代码它允许创建、查询、更新、串行化以 及反串行化模型的实例。e m f 提供一个反射a p i 以存取模型实例并且允许动态地创建 模型。 新系统并未使用e m f 来生成代码。尽管e m f 生成代码的能力很强，但e m f 并不 专门针对持久层，尤其是本课题所研究的持久层基于h i b e r n a t e 框架的d a o 模式 的实现。新系统使用了e m f 的e c o r e 作为p s m 的元模型。之所以选择e c o r e ，因为它 是e m f 中的类m o f 的核心元模型，它处在m o f 元层次所定义的m 2 层，e m f 使用 e c o r e 来建模。此外，e m f 还提供了操作e c o r e 的相关方法，可以将模型导出e c o r e 文 件( 一个x m l 文件) ，也可以从e c o r e 文件中读取模型信息。 图3 2 所示为e c o r e 元数据的完整的类层次结构图。e m f 中的一个关键接口是 e o b j e c t ，它在概念上等价于j a v a 1 a n g o b j e c t 。所有的建模对象，都要实现这个接口， 该接1 ：3 提供以下几个重要特征：类似j a v a 的o b j e c t g e t c l a s s 0 ，通过使用e c l a s s 0 方法， 能检索实例的元数据，也就是它的e c l a s s ；在任何e m f 建模的对象上，都能使用反射 a p i ( e g e t 0 、e s e t 0 ) 来存取它的数据。这在概念上等同于j a v a 的 j a v a 1 a n g r e f l e c t m e t h o d i n v o k e ( ) 方法，尽管效率更高些；从任何实例对象，都可以通过 使用e c o n t a i n e r 0 方法得到它的容器( p a r e n t ) ；e o b j e c t 也扩展了n o t i f i e r , 这允许你监视对 象的数据的所有变化。 1 2 e o b j e c t l e 鲥o d e l e l e m e n t 千 7 “i a 昧n n 甘。觚t a i o ni e f a c t o r ye n a c n e d e l e m e n t ii 八 i n t e r f a c e i n t e r f a c e ic l a s s e d 破藕1 m ，t e p 甜a n l e t 毫i e o i ) e r 剐t i o n s t r u c t u r a l f e 越u ie i 弋7千 i n t e r f a c e e e n u m e a t t t i b u t er e f e l e n c e i 图3 2e e o r e 兀数据的u m l 类图 3 1 3e u m l 2 尽管e c o r e 的构建j a v a 类模型很强，但毕竟是一个形式化的模型，e m f 也只是定 义了x m l 语法来表示e c o r e 模型，e c l i p s e 本身所带的e c o r e 建模工具功能很弱，使用 该工具来进行e c o r e 建模无异于使用x m l 来建模，十分不直观。因此，必须寻找或者 开发一个能够以图形方式进行e c o r e 建模的工具，好在已经存在了这样的工具 e u m l 2 。 e u m l 2 是一个u m l 建模工具，而且能够以e c l i p s e 插件的形式使用。使用e u m l 2 进行e c o r e 建模和使用u m l 工具进行u m l 建模的方式类似。如图3 3 所示为使用 e u m l 2 构建的e c o r e 模型。该模型图与u m l 的类图极其相似，只要了解u m l 类图的 开发人员很容易就能读懂e c o r e 模型图。所不同的是，类的属性的数据类型使用的是 e c o r e 数据类型，e c o r e 数据类型与j a v a 中的数据类型对应，如e s t r i n g 对应于 j a v a 1 a n g s t r i n g 、e l o n g o b j e c t 对应于j a v a 1 a n g l o n g 等等。因此，e c o r e 模型图实际上 是一个p s m 。 1 3 密c ：nl 图3 3 使用e u m l 2 构建的e e o r e 模型图 e c o r e 模型图对应于e c o r e 文件，即x m l 文件。图3 3 所示的e c o r e 模型所对应的 e c o r e 文件的内容如例3 2 所示。为了使文件内容更加简明、清晰，例3 2 所示的e c o r e 文件删除了原e c o r e 文件中的x m l 命名空间标记。 例3 2e c o r e 文件的片段 e s t r u c t u r a l f e a t u r e st y p e = e a t t r i b u t e ”n a m e = ”a t t r ”e t y p e = ”e s t r i n g ”胗 e s t r u c t u r a l f e a t u r e st y p e = ”e r e f e r e n c e ”n a m e = ”a s s o1 ”i o w e r b o u n d = ”1 ” e t y p e = ”# o n c l a s s1 ”e o p p o s i t e = ”# c n c l a s s1 a s s 0 2 ”侈 不难看出， 标签表示的是模型中的“包”，也即j a v a 中的p a c k a g e ， 包是可以嵌套包的，因此 标签也可以嵌套 标签。在e c o r e 模型中，类通常是在包里( j a v a 中c l a s s 也通常属于某个p a c k a g e ) ，因此 标签( 表示“类”) 被定义在 标签里。类可以有父类，在 标 1 4 签中可以有e s u p e r t y p e s 属性，该属性值定义了类的父类。类中的属性由 标签定义。属性通常有两种( 在3 1 2 小节的图3 2 中， e s t r u c t u r a l f e a t u r e 接口有两个子接口) ，普通属性( 类型为e a t t r i b u t e ) 和引用属性 ( e r e f e r e n c e ) 。普通属性的类型基本都是j a v a 的常用数据类型。引用属性用于表示类 之间的关联关系。如图3 3 中c l a s s l 与c l a s s 2 之间是一对多的关系，反映到e c o r e 文件 中，就分别在c l a s s l 和c l a s s 2 的 标签中定义t y p e 属性值为e r e f e r e n c e 的 标签。 标签的u p p e r b o u n d 属性用于定义所引 用的类的个数的上限，其值可以是1 ，1 表示类的个数可以无限大。如果不定义 u p p e r b o u n d 属性，则可解释为类的个数最多为1 。如例3 2 中c l a s s 2 的 标签就未定义u p p e r b o u n d 值，因为c l a s s 2 所引用的c l a s s l 的个数 最多为1 。 3 2p i m 转化为p s m 在3 1 节已经确定了v pf o ru m l 作为p i m 的构建工具，e u m l 2 作为p s m 的构建 工具，如何将p i m 自动转化为p s m 也就成了新系统所要解决的重要问题之一。通过 3 1 节的分析，已经了解到p i m 可以导出成x m l 文件，p s m 也可以导出成x m l 文件， 而且v pf o ru m l 和e u m l 2 都可读取相应的x m l 文件并将模型图展现给开发人员。 因此，新系统只需要能够将p i m 的x m l 文件转化成p s m 的x m l 文件，问题就解决 了。转化过程分为两步，解析p i m 的x m l 文件与生成p s m 的x m l 文件。 3 2 1 解析p i m 的x m l 文件 通过3 1 1 小节对v pf o ru m l 所导出的x