（计算机应用技术专业论文）基于j2ee平台的mda模型转换研究.pdf

基于j 2 e e 平台的蛐 模型转换研究 摘要 解决平台间的异构性、提升计算平台的抽象性，推动着软件技术和软件 工程的发展。中间件技术屏蔽了底层分布式计算的复杂性和异构性，简化了 分布式应用程序的开发，是对计算平台的一种抽象。但目前主流的中间件平 台的互操作和集成困难，o m g 对中间件平台再抽象，提出了m i ) a ( m o d e ld r i v e n a r c h i t e c t u r e ) 。m d a 作为一种新的软件开发模式，致力于提高软件开发行为的 抽象级别，将业务逻辑定义为精确的高层抽象模型，减弱了各种语言和中间 件平台的差异对软件开发造成的影响。模型驱动式软件开发( m o d ed r i v e n d e v e l o p m e n t ，m d d ) 就是对实际问题建模，并精化、转换模型，直至生成可 执行代码的过程，软件的生命周期就是以模型为载体并由模型转换来驱动的 过程。 实现m d a 需要解决两个主要问题是如何有效地建立软件模型和如何有效 进行模型间的转换，目前以u m l 及扩展机制作为建模标准语言已基本可以实 现有效建模，但至今没有一个统一的方案进行有效地模型转换。模型转换是 m d a 的核心，也是目前m d a 研究的热点。本文在对姗a 核心概念定义和对模 型划分的基础上，提出了一种基于j 2 e e 中问件平台的m d a 实现方案，并采 用e j b 、j 】i i s 、j n o i 、跚i 、j a x p 等分布式技术，和x m i 规范、产生式规刚、 转换引擎、组件模板、构件建模器等理念，对方案的实现思想进行了阐述。 该实现方案在一定程度上消除了模型转换技术的异构性，具有分布性强、可 扩展性好、资源利用率低、跨平台和规范等优点。 关键词：软件开发模式中间件模型驱动架构产生式规则 模板构件建模器模型转换引擎 基于j 2 e e 平台的如 模型转换研究 a b s t r a c t t os o l v et h eh e t e r o g e n e i t ya n dp r o m o t et h ea b s t r a c t i o no fc o m p u t i n gp l a t f o r m p r o m o t et h ed e v e l o p m e n to ft h es o f t w a r ee n g i n e e r i n g m i d d l e w a r ew h i c hi st h e a b s t r a c t i o no fc o m p u t i n g p l a t f o r m ；i t h a ss h i e l d e dt h ec o m p l e x i t ya n d h e t e r o g e n e i t yo fd i s t r i b u t e dc o m p u t i n g ，a n ds i m p l i f i e dt h ed e v e l o p m e n to ft h e d i s t r i b u t e d a p p l i c a t i o n h o w e v e r , t h e m u t u a l o p e r a t i o na n di n t e g r a t i o n o f m a i n s t r e a mm i d d l e w a r ea r ev e r yd i f f i c u l t o m gp u t t e df o r w a r dm o d e ld r i v e n a r c h i t e c t u r e ( m d a ) ，w h i c hr a i s e dt h ea b s t r a c t i o nl e v e lo fm i d d l e w a r e b e i n ga l l e wk i n do fs o f t w a r ed e v e l o p m e n tm e t h o d ，m d ad e d i c a t e st or a i s et h e a b s t r a c t i o nl e v e lo fs o f t w a r ed e v e l o p m e n t , d e f i n e st h eb u s i n e s sl o g i ca th i g h a b s t r a c t i o n l e v e l ，a n dw e a k e n st h ea f f e c tw h i c hp r o g r a m m i n gl a n g u a g e o r m i d d i e w a r eh a so ns o f t w a r ed e v e l o p m e n t m o d e ld r i v e nd e v e l o p m e n ti st h e p r o c e s so fs e t t i n gl 】pt h em o d e lf o ra c t u a lp r o b l e m , r e f u t i n ga n dw a n s f o r m i n g m o d e l ，u pt oc r e a t i n ge x e c u t a b l ec o d e ，a n dt h el i f ec y c l eo f s o f t w a r ei st h ep r o c e 8 5 o f t a k i n gm o d e l a sc a r r i e ra n db e i n gm o d e lt r a n s f o r m a t i o nd r i v e n m k e yp r o b l e m so fi m p l e m e n t i n gm d a a h o wt ob u i l du pt h es o f t w a r e m o d e la n dh o wt ot r a n s f o r mt h em o d e le f f e c t i v e l y a tp r e s e n t , u m la n di t s e x p a n d i n gm e c h a n i s mc a ni m p l e m e n tb u i l d i n gl 巾m o d e l0 1 1t h ew h o l e ，b u tt h e r e i sn o tau n i f o r mp r o j e c tf o rm o d e lt r a n s f o r m a t i o nv e r ye f f e c t i v e l y m o d e l t r a n s f o r m a t i o n sa l et h ec o r ea n dr e s e a r c hf o c u so fm d a 砒p r e s e n t o nt h e f o u n d a t i o no fd e f i n i n gt h ec o r ec o n c e p ta n dd i v i d i n gt h em o d e l ，t h i sp a p e rp u t s f o r w a r dak i n do fm d ab l u ep r i n ta c c o r d i n gt ot h em i d d l e w a r eo fj 2 e e ，a n d e l a b o r a t e st h em f l i z a t i o nt h o u g h t , w h i c hu s e st h ed i s t r i b u t e dt e c h n i q u eo ff j b ， j m s ，j n d i ，r m i ，j a x p , a n dx m ic r i t e r i o n , p r o d u c t i o nr u l e ，t r a n s f o r m a t i o n e n g i n e ，c o m p o n e n tt e m p l a t e ，c o m p o n e n tm o d e l i n g t h i sp r o j e c tr e m o v e st h e h e t e r o g e n e i t yo fm o d e lt r a n s f o r m a t i o nt os o m ee x t e n t , a n dh a st h ea d v a n t a g e so f d i s t r i b u t i o n , e x p a n s i b i l i t y , c r o s s - p l a f f o r m , r e s o u r o eu t i l i z a t i o n , a n dn o r m k e yw o r d s ：s o f t w a r ed e v e l o p m e n t a lm o d e l ；m i d d l e w a r e ；m d a ；p r o d u c t i o nr u l e ； t e m p l a t e ；c o m p o n e n tm o d e l i n g ；m o d e lt r a n s f o r m a t i o ne n g i n e 2 基于j 2 e e 平台的m d a 模型转换研究 第一章绪论 软件开发模式是描述软体开发过程的一系列步骤及其执行程序。开发的 过程依循系统化、逻辑化的步骤进行时，将有利于标准、规范与政策的推行 和建立，而且开发过程将更提高效率，更能确保质量，也更容易管理。开发 模式是一个比较模糊的概念，很难给出一个精确的定义。本文给出开发模式 的几个本质特征以便于进一步讨论： ( 1 ) 开发过程的阶段划分，开发分为哪几个阶段进行，每个阶段主要完 成什么任务。 ( 2 ) 各阶段开发的出发点，在各个开发阶段的开始，有什么可以利用的 成果和开发工具，开发活动所针对的对象是什么。 ( 3 ) 各阶段开发成果的表现形式，在各个开发阶段结束的时候，开发成 果以哪种形式表现出来。 1 。1 传统的软件开发模式 1 1 1 面向过程的开发模式 随着计算机要解决的问题越来越复杂，计算机科学家试图将复杂的问题 分解成简单的问题，然后再逐个解决，这种设计方法就是面向过程的结构化 程序设计方法。结构化程序设计方法的基本恿想是从全局出发，对功能自顶 向下逐步求精。基于这种思想，可将软件开发过程划分为以下六个阶段： 1 ) 系统可行性研究，分析现状，明确系统功能，进行代价、成本估算； 2 ) 系统需求分析，根据系统功能分析系统逻辑上的实现。在这个阶段 可用数据流图、数据结构图等概括出分析结果。分析过程要与用户密切合作， 其结果要得到用户的认可； 3 ) 系统结构设计，结合数据流图等分析文档，对功能自顶向下逐层分解， 细化成一个个简明的程序模块，并确定模块之间的接口关系； 基于j 2 e e 平台的m i ) a 模型转换研究 4 ) 编码，对系统结构图中各模块进行编程； 5 ) 调试与验收，根据规范，设计典型输入数据，上机运行，将输出结果 与预定的正确结果相比较； 6 ) 运行维护，包括对系统的“修改”和“增强”。 典型的面向过程的结构化开发过程有瀑布法和原型法。这些方法的阶段 性成果包括e r 图、数据流图、数据字典、流程图等文档。面向过程的开发 模式的隐含要求是：在预先知道系统组成并理解系统结构关系的前提下，分 析系统各组成部分之问如何按一定的处理方式处理数据，并进行动态的相互 作用。 1 1 2 面向对象的开发模式 面向对象思想来自于抽象数据类型，指解决问题时以对象为单位，将表 示事物属性的数据和事物特性的动作封装起来组成系统单元。自1 9 8 1 年面 向对象的程序设计语言s m a l l t a l k - 8 0 问世以来，面向对象技术迅速发展。 面向对象思想日趋成熟，在面向对象分析( o b j e c t - o r i e n t e d a n a l y s i s ，o o a ) 、 面向对象设计( o b j e c t - o r i e n t e dd e s i g n ，0 0 d ) 和面向对象编程 ( o b j e c t - o r i e n t e dp r o g r a a 瑚i n g ，o o p ) 的过程中运用得十分成功，己成为软 件工程学的主流。面向对象思想的三个基本特征是：封装、继承和多态。 封装是将对象特征的实现方式，封装概念的关键点在于被封装对象的消 息接口。所有与该对象进行的沟通都要通过响应消息的操作来完成。因为其 数据和过程的内部实现细节对外界隐蔽，所以封装在很多时候被称为“信息 隐藏”。封装起到了两个方面的保护作用：一方面，对象内部的状态被保护 起来，不会被其他对象直接篡改；另一方面，对象内部特征的变化不会改变 其他对象与该对象的沟通方式。封装使得系统具有更明显的高内聚、低耦合 特征。整个系统的体系结构将变得更有延展性。 继承是传统系统和0 0 系统间的关键区别之一。子类y 继承其超类x 的 所有属性和操作。这意味着，所有原本针对x 设计和实现的数据结构和算 法不需要进行迸一步的工作即可被y 使用。复用被直接实现。继承是描述 6 基丁二j 2 e e 平台的m d a 模型转换研究 层次分类的一种机制，其本质目的是表述并使用事物之间的相似性。同时事 物之间的区别得以更加明显。这带来两个方面的益处；一方面，对同层次事 物之间所具有的相同特征，没有必要在这个层次内作分别的、重复的描述， 可以将这部分内容放到更高的一个层次中去描述；另一方面，主体理解客体 的概括程度是可以选择的，主体可以根据实际需要决定采用较高层次的描述 或者是较低层次的描述来认识客体。 多态性是指同个操作作用于不同的对象上可以有不同的解释，并产生 不同的执行结果。例如“画”操作，作用在“矩形”对象上，则在画板上画 一个矩形，作用在“三角型”对象上，则在画板上画一个三角型。也就是说， 相同操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的 这个操作去执行，从而产生不同的结果。 1 2 传统软件开发模式的不足 1 2 1 生产效率 目前的软件开发过程是以概要设计( 1 0 w - l e v e l ) 和编码驱动的，如图1 所示，无论是采用增量开发还是迭代开发，或者是传统的瀑布式开发途径， 文档和相关 轼挣开麓壤圣上童蹙一十逸挖匏拉嚣 井麓 嗣鲁救盘0 波筏 图1 软件开发过程 的设计图表都是在前三个阶段中产生。需求分析往往使用文本和图的方式来 描述，其中的图经常采用u m l 实现，如用例图、类图、交互图、活动图等。 这一叠厚厚的纸面文件往往给人以深刻的印象，丙其中的设计工件往往仅是 纸件丽已。 7 基于j 2 e e 平台的蚰a 模型转换研究 当编码开始的时候，前三个阶段产生的文档和相关图片就迅速失去了它 们的价值。随着编码阶段的继续进行，图片和代码之间的关联逐渐减弱甚至 消失，它们不再是对代码的精确描述，或多或少地成为了无关的图片。随着 时间的推移，系统不断地被修改，文档、设计图表和代码之间的距离就越来 越疏远。在很多情况下，仅仅是代码进行了修改，因为修改文档和设计图表 所要花费的代价十分大，为了在控制成本的情况下按时交付系统只好放弃。 但是，这样又会给系统的后期维护带来巨大的代价。所以，开发人员要么花 时间去维护详细设计文档和设计图表与代码的同步；要么花时问在维护阶段 来分析系统是如何工作的，这些方式都是不能直接产出代码的，也是代价高 昂，导致生产效率低下。 1 2 2 可移植性 软件产业有一个和其他产业不同的特点，就是每过一段时间都会有新技 术被发明并变得流行，如：j 2 e e ，n e t ，w e bs e r v i c e 等。许多公司都有充 分的理由追随这些新技术，公司在享受新技术带来了的实际好处同时还必须 承担技术落后的代价。新技术取代老技术，老系统失去价值。对于同一种技 术，技术本身也在改变，他们以不同的版本出现，新版本并没有确保向后兼 容。这样导致有些新旧系统无法兼容，形成了信息孤岛。 1 2 3 互操作性 软件系统很少能够孤立地存在，大多数都需要和其它系统进行通信。一 个典型的例子就是，很多公司在他们的现存系统上构建了基于w e b 的新系统， 如基于p h p 、a s p 、j s p 等技术的w e b 应用程序需要从现存的后端系统中获取 信息等等。系统往往要使用多种技术来实现，他们之间也存在互操作的问题。 而系统中不同的组件也可能使用各自最佳的技术来实现，他们之间也需要互 操作。不同的工具对于元数据的管理均有自己的策略，这就给元数据的共享 形成了障碍，也降低了不同软件的互操作性。没有一个统一方案来解决互操 作的需求。 3 基于j 2 e e 平台的m d a 模型转换研究 1 2 4 文档问题 许多的开发人员总是认为编码才是他们的主要任务，文档可用性的支持 可以缓一缓。写文档成了强制的任务，而不是出于激励的目的，不是出于自 愿的工作当然不能做好。这也是文档为什么质量总是不够高的原因之一。 能够检查文档质量的也只能是开发团队的人员，而他们自己却讨厌写文 档的工作。因此这也是文档总是不能得到更新的原因。每次代码改变之后必 须手工去在一堆文档中找出设计中需要更改的地方，这是多么烦琐的工作。 其实开发人员的这种想法是错误的。我们的工作是开发一个容易修改和便于 将来维护的系统。 在代码层次上解决这一问题的方案就是能够便利地从代码中产生文档， 使得文档是代码中不可分割的一部分。这种方案被一些语言所支持，比如 e i f f e l 和j a v a 语言。但是这种方案只能解决概要( 1 0 w - l e v e l ) 设计文档的问 题，详细( h i g h - l e v e l ) 的设计文档仍然需要手工维护。对于一个复杂的系统， 在抽象层次上描述系统的详细设计文档尤为重要。否则无法保持文档和代码 的同步，而又额外增加很多工作量。 。 i 3 新的软件开发模式m d a 嘲 对于复杂的、大规模的软件开发，我们通常采用的原则是对其进行抽象、 问题分解和视点分离，以便在不同的抽象层次、不同的角度考虑问题和分析 问题。实践证明，对软件进行建模己经成为实现这些原则的主要方法。软件 模型是以精确定义的语言对系统做出的描述。它能够使我们获取对系统本质 的抽象，并指导我们的整个软件开发过程。2 0 0 2 年o m g ( o b j e c tm a n a g e m e n t g r o u p ，对象管理组织) 提出了模型驱动架构( m o d e ld r i v e na r c h i t e c t u r e ， m d a ) ，它是一种全新的软件开发模式。在模型驱动架构中模型在开发过程中 扮演了非常重要的角色。在m d a 中软件开发过程是由软件系统的建模行为驱 动的。 o m g 的构想是将目前的开发行为提升到更高的抽象层级一分析模型级， 9 基于j 2 e e 平台的如a 模型转换研究 把针对特定计算平台的编码工作交由模型转换自动完成，这样的情况下，业 务逻辑与实现技术被成功地解耦，二者相对独立变化，因此模型的价值在包 容已有技术的条件下被最大化。这种目的根源于软件开发的现状，在传统的 软件开发方法中，随着项目的进展，设计阶段产生的u m l 模型和代码之间的 同步变得越来越困难一代码为了应付新增加的需求和新产生的技术而不断 变化，模型却一直停留在原地不动，这使得模型在一段时间之后就失去了它 的价值。在雠d a 中，模型不再是一种辅助工具，而是开发过程的产品，系统 的实现和更改都应由业务模型驱动。 k l d h 将对应用集成中间件技术和产品形成有力的影响。一方面，基于m i ) a 平台独立的思想，各类中间件技术将重新融合在一起，不同的中间件技术将 根据本身的定位，在集成的企业信息架构中找到自己的位置：同时，由于业 务构件的抽象性，使得企业业务模型可以独立于中间件技术而存在，大大丰 富了构件的层次性，从而为企业信息资产的积累提供了巨大的机会；此外， 按照m d 全面关注应用开发的完整生命周期的理念，基于中间件的应用开发 平台和运行平台将完美地结合在一起，从而在构件协同框架下，为提高软件 质量和软件生产效率以及增强软件的可移植性、协同工作能力和可维护性找 到一条新的途径。 1 4 小结 本章从软件开发模式的角度进行阐述，介绍了传统软件开发模式和其优 缺点，对新的软件开发模式j d i ) a 出现的必要性进行了说明，并简单介绍了 t u i d a 。有关k i d h 的详细论述和标准安排到论文的第二章，包括基于m d a 的软 件开发过程、m d h 的相关标准、岫a 阵营的分类、旧a 模型转换的几种方案。 论文第三章主要论述j 2 e e 中间平台，i l i d a 的实现必须是依赖某一中间件平 台，在这一章讲述了在众多中间件平台中选择j 2 e e 平台的原因、j 2 e e 架构 和j e e e 的主要技术标准。论文的第四章将全面阐述一种基于j 2 e e 中间件平 台的姗a 模型转换方案，包括如何构建j 2 e e 开发平台、m d a 模型转换中涉及 核心概念的界定、 , i d a 模型转换的两阶段实现、肋a 模型转换规则、构件模 1 0 基于j 2 e e 平台的m d a 模穆转换研究 板、构件建模器和j l o a 模型转换引擎的实现。论文的第五章是对本文所做工 作的总结和下一步工作的展望。 基于j 2 e e 平台的蛐a 模型转换研究 第二章模型驱动架构m d a m d a 的核心思想是以模型作为整个软件开发过程的中心，根据不同的开 发阶段，使用不同抽象层次的模型对系统进行分析、提炼和获取相关的信息， 并尽可能详尽的把这些信息反映到模型中去，从而使得这种模型比以往软件 开发中所采用的模型具有更重要的地位和作用。这些模型从某种意义上说已 经成为一种开发工件，而不仅仅停留在作为指导开发过程或者软件文档的水 平上。基于m d a 开发过程中使用的模型也具有比以往更精确的信息和更严格 的约束，而不单单是一种图形化的模型表示方法或者设计人员之间交流的途 径。 2 1 基于m d a 的软件开发过程 m d a 的开发过程如图2 所示，是由对软件系统的建模过程驱动的，它和 传统的软件开发过程的主要区别是：形式化的模型在软件开发过程中将努力 取代或者部分取代完全基于3 g l ( t h et h i r dg e n e r a t i o nl a n g u a g e ) 代码的 开发。$ t d a 的基本开发模式是：1 ) 首先使用平台无关模型( 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 i m 是对系统的一种高层次的抽象，与具体的实现技术无关。在此过程 中，可以根据客户需求和其它因素不断地对h m 进行精化，以使它能更加精 确地描述系统。2 ) 然后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 s m 。p s m 是针对所选择的实现技术、平台，对系统量身定做的模型。 由于现今的很多系统都跨越多种技术平台，所以对于一个p i m 可以拥有多个 p s m 。这是岫a 中最复杂，也是最重要的一步。3 ) 根据系统的需求对p s m 不断加以精化，当从p i m 自动生成的p s m 不能满足特定的需求时，可以根据 平台的特性对p s m 加以修改。4 ) 最后模型转换引擎将每个p s m 都转换到实 现代码。 基于j 2 e e 平台的m d a 模型转换研究 n d a ! li 垃霞t 矗，0t 丘l 爱2 p i 麓# 旃 图2 基于h d a 的软件开发过程 2 2m d a 相关标准 渤a 的核心是建模和模型映射技术，其相关标准如下。 2 2 1c w m ( c o m m o nw a r e h o u s em e t a m o d e l ，公共仓库元 模型) 旧 c w m 定义了一个元模型，用来表述数据仓库和业务分析领域中的业务和 技术元数据，它是在异构的，不同厂商软件系统中交换元数据实例的基础。 遵循c 咖元模型标准的系统可以通过一致的元模型格式交换元数据。 c 州包含有一系列的元模型，它们能表述数据资源( d a t ar e s o u r c e s ) 、 分析器( a n a l y s i s ) 、数据仓库管理( w a r e h o u s em a n a g e m e n t ) 以及典型数据仓 库业务智能环境。数据资源元模型能对遗留和非遗留数据资源建模，包括 关系数据库、面向记录的数据库以及基于】( m l 和对象的数据资源。c 肌的分 析器中定义了一个元模型，用于数据交换、o l a p 、信息可视化报告、业务专 门用语和数据挖掘。数据仓库管理部分包括表述标准数据仓库过程的元模 型、活动跟踪和安排。基本的元模型支持不同通用元素和服务的规格说明， 如数据类型、类型系统映射、抽象主键和索引、表达式、业务信息和基于构 件的软件实施。 c 删表述了在软件系统之间交换元数据的基于模型的方法。产品问相互 基于j 2 e e 平台的m d a 模型转换研究 共享的元数据用与一个或多个c 硼元模型一致的数据模型表示。一个产品输 出元数据时，根据c 硼的标准，用自己内部的元数据结构表示模型。类似地， 当产品输入元数据时，根据与c 硼标准一致的模型，将其映射到自己内部的 元数据中。c 删所提供的元模型足以对整个数据仓库建模。通过使用遵循c 删 标准的工具。可以从数据仓库模型中直接生成一个数据仓库实例。这个工具 的不同部分可以给不同需要的工具使用。 c 州模型要有较高的类属性和对共享元数据的外部表述。对于不符合c 删 格式的元数据，可以通过c 硼提供的标准扩展机制，向核心c 嘲元模型扩展。 2 2 2u m l ( u n i f i e dm o d e il a n g u a g e ，统一建模语言) 硼 u 忆是一种为离散系统建模的图形化语言。虽然我们没必要将u m l 与特 定的应用领域和建模过程绑在一起，但它却最广泛的应用在面向对象软件设 计领域中。现在，u 甩己经m o f 删i 构成了0 m g 元数据体系结构的基础之一 ( c 嗍是领域相关的扩展) 。 u m l 中不同的建模元素能对静态和动态方面建模。u m l 静态模型包括类、 属性、操作和接口。类之间标准的关系有继承泛化、关联、依赖和包含，这 些都能用l r m l 类图建模。对于系统中动态语义的建模，可以用顺序图和协作 图。状态机可以用于对象内部活动的描述。u 札中的用例图描述面向对象分 析和外部系统行为的建模。u m l 还提供了包、构件等概念，并且可以将其配 置到分布计算体系结构的结点中。 u m l 由元模型形式化定义，这个元模型是用u m l 循环定义的。这种元模 型循环定义使得u i l l 基于一个小的元素集合。 m d a 中的模型基本上是用u m l 表示的，c 硼同样也是用u m l 描述的。u m l 虽然是定义c w m 的符号基础，但c 删同时也扩展了核心u m l 元模型的子集， 添加了数据仓库和业务分析领域的概念。构建基于c 删的数据仓库模型时， 与其它的建模语言( 如文本的) 相比，使用可视化的建模语言更容易操作和理 解复杂的元数据结构。另外，由于u m l 元模型较精确地定义了u m l 语言( i 珊i l 的语义虽然不够精确，但与其它可视化建模语言相比，它在语义精确度和符 1 4 基于j 2 e e 平台的i l d a 模型转换研究 合的可读性上有较好的折衷) ，因此可视化的u 眦模型向其它的形式化规约 转换的自动化程度相对较高。这就方便了在不同平台和不同工具间的c w m 模 型的交换。 2 2 3m o f ( m e t a o b j e c tf a c iii t y ，元对象设施) 咖 m o f 是o m g 的一个标准，用来给元模型规格说明定义通用、抽象的语言。 m o f 是元一元模型的一个例子，或者是元模型的模型。m o f 从根本上是支持面 向对象的概念的，它为离散系统的面向对象定义了基本的元素、语法和元模 型结构。m o f 可以看作是c w m 和u m l 元模型的通用模型。m o f 的规格说明提 供了：1 ) 一般的m o f 对象及其关联的抽象模型；2 ) 任一基于m o f 的元模型到 与语言无关的接口( c o r b ai d l 中定义) 的映射规则。通过一个给定的元模型 的这些接口，可以对任意基于这些元模型的模型进行访问和修改；3 ) 基于m o f 元模型元素的生存周期语义、构成语义和闭包语义的定义规则；4 ) 一种反射 接口( r e f l e c t i v ei n t e r f a c e ) 结构。定义了对基于啪f 元模型的显示和操 作，而它们的映射接口是未知的。 m o f 用另一种方法实现不同领域的不同元模型之间的互操作。基于m o f 的应用不用关心某个模型实例接口所涉及的领域知识，而可以使用反射接口 的一般操作对模型进行读取和更新。 m o f 被o m g 作为表述元模型的标准，c w m 元模型也是遵循这一标准进行 设计的，这就使得c w n 能使用其它基于m o f 的o m g 的规格说明特别的，它 允许使用x m i 交换设计仓库元数据，这些元数据是用c w m 元模型表述的：它 还允许使用) 【m l 和其它编程语言对基于c w m 元模型的数据仓库元数据进行编 程访问。 2 2 4x 川( x m lm e t a d a t ai n t e r c h a n g e ，x m l 元数据交 换) 嗍 瑚i 的目标是以串行化的方式进行模型间的交换。由于m o f 是o m g 己采 1 5 基于j 2 e e 平台的- 魄模型转换研究 用的表述元数据的标准，那么，自然的，x m i 的目标是m o f 元数据的交换， 即符合m o f 元模型的元数据。实际上，x m i 有两种映射：一个是m o f 元模型 和x m l 的d t d ；另一个是m o f 元数据和x 1 4 l 文档。x m i 可以看作是个与中 间件技术无关的通用元数据交换格式。任何能对) 【m i 流进行编码和解码的元 数据库或工具之白j 可以进行元数据交换。 c w m 用x m i 作为它的交换机制，这意味着) ( 1 l i 强大的功能和灵活性可以 用于数据仓库元数据及c 删元模型的交换上，c 删不需要对) ( m i 进行任何扩 展。c w m 元模型标准的d t d 是用x m i 的d t d 产生规则生成的。这样，可以用 硼i 的文档生成规则将数据仓库元数据编码成x m l 文档。c w m 元模型标准的 x m l 文档也是用基于m o fd t d 的x m i 文档生成规则产生的。 2 3m d a 阵营的划分 m d a 是由上述一系列的标准族加上模型驱动开发的思想共同组成的，而 后续的研究者根据对m d a 研究的侧重点不同，导致了m d a 阵营的分裂。 s t e v ec o o k 将m d a 研究者划分为三个阵营，m a r t i nf l o w e r 也同意他的 观点，并针对这三个阵营对待语言平台的态度进行了详细的讨论。另外， m a r t i n 还提出了一个肋d 阵营。总结他们两个人的意见，本文将m d a 阵营划 分为四个部分，其中有的阵营是完全对立的，而有的则是兼容并蓄的。 2 3 1u m lp i m 阵营 u m lp i m 阵营可以说是目前最强大的，因为它是如此符合m d a 最初的构 想，从大家了解最多的u l i l 开始建立p i m ，然后转换为p s m ( 例如c o r b a ， j 2 e e ，n e t ) ，然后生成代码，一切看来都如此流畅，和以前出现的技术可 以兼容，并且也不缺少工具和厂商的支持。 但是，它也是受到诟病最多的一个阵营，一个最大的问题就是关于u m l 是否是平台无关的问题，如果u m l 不是平台无关的，则显然它不适合用来构 建p i m 。m o f 阵营的人对于u m l 的抛弃就是基于这个原因，他们认为m o f 才 是m d a 的本源，过多的使用u 札会导致不能真正的构建p i m ，因为u m l 本身 1 6 基于j 2 e e 平台的 模型转换研究 就是个平台。u 缸p i m 阵营的另一个问题是，u 盹过于繁琐，u t l l 2 0 标准 充斥着各种各样作用不大的填充物，不仅没有能够让u m l 更加实用，反而导 致了u m l 的复杂度增加，可用性下降。还有一个不能回避的问题是，u 札p i m 阵营更加注重系统的结构，而不注重( 不能解决) 系统的语义( 动作流程) ， 因此很多人倾向于去掉u 札动作语义，或者根本不使用u 札动作语义。 尽管u m lp i m 有这么多的缺点，但是其优点也是显而易见的：1 ) 符合 标准：2 ) 对于普通的软件从业者来说，学习u m l 比学习m o f 要更容易一些； 3 ) 可以使用的工具更丰富一些。 2 3 2m o f 阵营 使用m o f 来直接构建建模语言和模型转换语言在一些书中称为“重量级” 方法，而使用u m lp r o f i l e 来扩充u m l 生成新的建模语言称为“轻量级”方 法。由此可见，学习和使用矾o f 是一件比较耗时的事情，但是这并没有阻挡 啪f 阵营的脚步，他们认为m o f 才是m d a 的核心，才是纯粹的m d a 。 鐾 鼋i l 乳 霎 一。 图3m o f 的四层结构 m o f 定义的四层模型如图3 所示，其中赫o 层表示的是我们系统中的实体， m 1 层是系统的模型，m 2 层是元模型，也就是u 眦语言定义之类的内容，m 3 1 7 基于j 2 e e 平台的盼 模型转换研究 层是元一元模型，是用来定义如u 札语言、i d l 语言用的模型，m 3 层是自描 述的。元层次本质上不限于四层，重要的是每层之间的实例化关系，以及m 3 层的自描述能力。 m o f 脱离了u 札，这样增加了岫a 的生命力，与其让m d a 技术与新的技 术竞争，不如将m d a 分化为几个阵营之争。m o f 的缺点是学习困难，工具较 少，而优点则是灵活自如。 2 3 3 可执行的u m l 阵营 这个阵营认为：第四代语言就属于可执行的u m l ，其他的无论影响力还 是问题域的覆盖性，统统不如。当u m l 真正可以执行了，对于高级语言程序 员的需求量就会像现在的汇编程序员一样稀少了。可执行的u m l 也是m d a 研 究的热点，尤其是在觚d a 技术提出之初，所有的m d a 支持者都满心欢喜的想 象i $ 1 l 编译器的出现，可以将手头的模型直接转换为可执行程序。 完全不产生高级语言代码的u l l 编译器，也许在某个局部领域内可以实 现，但是能够做到像高级语言编译器那样完整，在目前是根本不可能的。原 因很简单，目前的o m l 表达能力有限，它不能完全承载程序所需要的信息。 即使是u 札扩充了动作语义之后。 2 3 4m d d 阵营捌 m d d 阵营严格说来不一定属于m d a 阵营，因为他们无视m d a 的诸多规范， 而是自成一体。他们是典型的“拿来主义”者，有用的就拿来，没用的就扔 掉。很多人号称m d a 的支持者，但是从来没有遵循过任何m d a 的规范。他们 只是拿来了模型驱动的思想来武装自己的开发方法。不过他们也许更加清晰 的认识到鼢a 的精髓，毕竟他们还没有在冗长的m d a 规范中泡得发自。 从另一个方面来说，他们是更加纯粹的岫a 支持者，因为m d ag u i d e 的 开头就说：m d a 是一种模型驱动的软件开发模式，它增加了模型的重要性， 提供了用模型来完成分析、设计、构造、部署、操作、维护和修改的系统开 发过程。岫a 是一种方法，而不是仅仅是规范。 基于j 2 e e 平台的如a 模型转换研究 2 4i d a 模型转换方案分类 o u g 提出了i a d a 开发方法后，模型变换引起了人们的关注，模型变换是 旧a 能否实现的关键技术，从利用模型来描述软件系统开始，人们就在关注 模型变换方面的问题。通过国内外关于模型变换技术方面的研究，总的来说 有四种不同的策略来支持用户定义的模型变换。直接操作方法、中间表达方 法、关系逻辑方法和变换语言支持方法。其中，一部分对这些方法的实现已 作为q v t 的提案提交给o m g 。下面，我们将对这些方法所在领域内的实现和 相关工具的优缺点进行分析。 2 4 1 直接模型操作 直接操作方法通过给用户预留了一组通用编程语言的a p i 接口( 例如： j a v a ，v b 等语言) 来获取和操作模型的内部表达形式。使用这种方法的工具 通常在内部构建了一个实施模型变换的框架，框架提供了组织模型变换的基 础设施。使用这种方法的典型框架包括：r a t i o n a lr o s e 提供的组v b 接口 以及利用j a v a 元数据接口( j a v am e t a d a t ai n t e r f a c e 。j m i ) 提供的一组j a v a 接口。 j m i 是由s u n 的j a v a 社区项目( j a v ac o m m u n i t yp r o c e s s ，j c p ) 提出的 m o f - j a v a 的映射。j m i 定义了如何将m o f 元数据表示成j a v a 对象的规则。 这些规则定义了将元数据的抽象语法转换成j a v aa p i 的标准形式，这些a p i 为遵从元模型的模型域提供了用j a v a 对象表示模型的方法。通过定义这样 的一个标准，各种不同的实现可以共享这组接口，并保证含有相同的语义。 通过上述的编程接口，用户可以自行编写实现模型变换的算法，以操作 m o f 模型仓库或者其它形式的模型元素，从而实现模型变换。直接操作方法 的优点是：开发者可以选择比较熟悉的编程语言，编写模型变换的规则，另 外开发者还可以在这种过程式的语言中自行编写复杂的算法。 这种方法的缺点是：所提供的a p i 接口通常限定了可以执行的变换种类。 并且由于定义变换所使用的是通用编程语言，它们缺乏在较高的抽象层次上 1 9 基于j 2 e e 平台的m i ) a 模型转换研究 定义变换的能力。再者，通过编写代码实现变换是一种比较繁琐而且易于出 错的工作，通过这种方法编写的变换算法一般也难以维护和复用。 2 4 。2 中间表达形式 中间表达方法首先以一种标准的形式如x m l 来表示模型。工具提供一组 接口将模型导出到这种表示形式，然后采用基于这种表示形式的变换技术间 接的实现对模型的变换。经过变换后的文件可以再次导入到建模工具中去。 这种方法典型的是使用x m i 技术，x m i ( x m l 元数据交换) “1 是由o m g 制 定的基于m o f 和x m l 的一个标准。标准主要定义了m o f - x m l 元模型之间的映 射关系。当把x m i 作用于u m l 元模型时，可以产生用于交换u m l 模型的d t d 或者s c h e m a ，对于其它的元模型也是如此。x m i 还定义了产生满足所生成的 d t d 或s c h e m a 的x m l 文档的规则集合。许多工具提供了通过x m i 导入和导出 模型的基础设施，模型通过使用这些设施可以被表示成x m l 格式的文件。然 后，可以通过使用x s l t ( x s l t 是一种用于变换x m l 文档格式的标准化技术) 进行模型变换。 中间表达方法的优点是：通过使用x m i 标准和x m l 文件来表示模型不但 可以解决工具之间模型交换的问题，并且把模型之间变换问题转化为对x m l 文档操作的问题。 这种方法最主要的缺点是：操作复杂，由于一个模型会导出庞大的的x m l 文档，以及x s l t 程序本身的复杂性和难以阅读性，因此通过手工编写x s l t 来实现模型变换很容易出错并且难以维护；另一个缺点是由于这种中间表达 方法通常是以一种批处理的方式进行的，因而这种形式的变换难以通过一种 和用户交互的方式进行。 2 4 3 基于逻辑语言的方法 这种方案主要是建立在数学逻辑关系上的一种表达式方法。其基本的概 念是把源和目标模型元素表示为一种关系，并且使用约束来进行形式化表 示。这种形式化表示本身是不可执行的，但是对这些表达式约束可以赋予执 基于j 2 e e 平台的1 4 d a 模型转换研究 行语义，例如：逻辑程序。 这种方法的典型应用是一个已被验证的变换框架，m a u d e ，它是一种基 于逻辑的语言。l l a u d e 代码包含了一组不变式和重写规则。其执行引擎应用 这些规则来进行模型变换。m a u d e 接受u m l 抽象语法作为一组原理，变换规 则可以被定义成重写规则，它工作的情况类似于图变换理论的方法。 基于逻辑语言的方法确实是一种比较好的方法，因为逻辑语言的一致性 匹配、搜索、以及追溯等机制很适合求解模型变换的问题。虽然这种方法很 有价值，但是使用逻辑语言撰写一个变换规则却并不简单。 2 5 小结 本章详细论述了基于帅a 的软件开发过程、m i ) a 的核心技术标准、i i i d a 支持的不同阵营和m 嚏模型转换的几种方案。论文的第四章将会以中间表达 式的方案阐述m d a 模型转换的实现。 2 l 基于j 2 e e 平台的m d a 模型转换研究 第三章j 2 e e 中间件平