（计算机应用技术专业论文）mda在领域工程上的研究与应用.pdf

摘要 为了进一步提高软件复用程度，为软件的工业化大生产创造必要的技术条件和生产 模式，对象管理组织( 0 m g ) 于2 0 0 1 年7 月推出了模型驱动体系结构( 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 d a 认为系统开发的最好方式是隔离系统设计与系统实现、 独立建模业务行为和领域元素，关注系统应用的本身。m d a 使用可以被机器处理的形 式化模型，首先针对业务行为建立平台无关模型( p i m ) ，然后采用模型映射技术和代 码自动生成技术转换为平台相关模型( p s m ) 直至代码。这种开发方式实现了模型在不 同平台中的复用。在m d a 中模型是生产的直接驱动力，它是可执行的并能产生输出的。 然而从理论到实践还有很大的一段路要走，本文正是基于如何更好的将m d a 应用 于中小型软件的开发过程这一目的，在实践的基础上提出了一个m d a 扩展开发模式。 论文首先系统地阐述了m d a 的定义、核心技术、开发步骤、研究和发展现状，并结合 领域工程中的模型构建方法阐述了适用于中小型软件开发企业的m d a 扩展开发模式。 文中针对m d a 的p i m 模型的构建方法提出了改进思想：将m d a 中平台无关模型( p i m ) 的构建过程分成了建立领域框架模型和在此基础上加入不同的企业相关元模型这两个步 骤。这种将p i m 模型进一步分解的方法提高了模型的抽象层次和复用性，是将m d a 应 用于项目开发实践的有效方法。然后本文又结合一个应用实例通用水泥领域生产设 备管理原形系统的构建过程对m d a 扩展开发模式进行了进一步的阐述，从实践上证明 了该模式的可行性。最后，本文还介绍了白行开发的基于该原型系统的代码生成器 p r o j e c t m a n a g e r 的设计思想和具体实现。 关键词：模型驱动体系结构( m d a ) ：领域工程：模型：代码自动生成 a b s t r a c t i no r d e rt oe n l a r g et h ee x t e n to fs o f t w a r er e u s ea n dp r e p a r ef o rt h ei n d u s t r i a l i z a t i o no f s o f t w a r e ，t h eo b j e c tm a n a g e m e n tg r o u p ( o m g ) a d v a n c e d an e wf r a m e w o r kn a m e dm 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 ) i t a l l o w sd e v e l o p e r st ob u i l ds y s t e m s a c c o r d i n g t ot h e i rc o r e b u s i n e s sl o g i ca n dd a t a - - i n d e p e n d e n t l yo f a n y p a r t i c u l a rh a r d w a r e ，o p e r a t i n gs y s t e m ，o r m i d d l e w a r e m d a p r o m o t e s t h ec r e a t i o no f m a c h i n e r e a d a b l e ，h i g h l ya b s t r a c tm o d e l st h a ta r e d e v e l o p e di n d e p e n d e n t l yo f t h ei m p l e m e n t a t i o nt e c h n o l o g ya n d s t o r e di ns t a n d a r d i z e d r e p o s i t o r i e s t h e r e ，t h e yc a n b ea c c e s s e dr e p e a t e d l ya n d a u t o m a t i c a l l yt r a n s f o r m e db y t o o l s i n t os c h e m a s ，c o d es k e l e t o n s ，t e s th a r n e s s e s ，i n t e g r a t i o nc o d e ，a n dd e p l o y m e n t s c r i p t sf o r v a r i o u sp l a t f o r m s h o w e v e r ，i t sal o n gw a y t og oi no r d e rt oa p p l yt h et h e o r yt op r a c t i c e a i m m i n ga ta p p l y m d at o t h ed e v e l o p i n gp r o c e s so fm e d i u m s i z e ds o f t w a r e ，t h i sp a p e rp r e s e n t sa l le x t e n d e d d e v e l o p i n gm o d e o f m d ab a s e do n p r a c t i c e f i r s t ，i ts e t sf o r t ht h ed e f i n i t i o n ，c o r et e c h n o l o g y ， d e v e l o p i n gs t e p ，s t u d ya n dt h ed e v e l o p m e n ts t a t u s o fm d a s e c o n d ，c o n t h i n i n gw i t ht h e c o n s t r u c t i o nm e t h o do fm o d e li nd o m a i ne n g i n e e r i n g ，i ti n t e r p r e t sa ne x t e n d e dd e v e l o p i n g m o d eo fm d a w h a ti si m p r o v e di nt h i sp a p e ri st h a tt h ee x t e n s i o nd i v i d st h ec o n s t r u c t i o no f p i mi n t ot w op a r t s ：t h ec o n s t r u c t i o no fd o m a i nf r a m w o r km o d e la n dt h ec o n s t r u c t i o no f e n t e r p r i s es p e c i f i cm o d e l t h i si sa ne f f e c t i v em e t h o di nt h ep r a c t i c eo fm d a t h a ti m p r o v e s t h er e h s a b l ea n da b s t r a c t i v ep r o p e r t i e so fp i m a l s o ，i tg i v e sa ne x a m p l e ：c o m m a nc e m e n t d o m a i np r o d u c te q u i p m e n tm a n a g e m e n t p r o t o t y p es y s t e m a n dm a k e saf a r t h e ri n t e r p r e t a t i o n a t l a s t ，i t i n t r o d u c e st h e d e s i g n a n d i m p l e m e n t a t i o n o fac o d e a u t o g e n e r a t o r n a m e d p r o j e c t m a n a g e r k e yw o r d s ：m d a ：d o m a i ne n g i b e e ri n g ：m o d e i ：c o d ea u t o g e n e r a t i o n 种a 在领域工程上的研究与应用 0 前言 软件对现代企业的正常运作起着越来越关键的作用，从机器语言、汇编语言发展到 现在的高级语言，软件开发的抽象层次越来越高。这也就意味着，开发人员越来越多地 关注问题本身而不是一些技术上的实现细节。许多业界的智者已经从x p 等敏捷方法转 向了“先设计后编码”甚至“先架构后设计”的方法。针对这一系列的发展趋势，o m g 组织在2 0 0 1 年提出了模型驱动架构( 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 是 一种基于u m l 以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。 以独立于实现的技术开发，以标准化的方式储存机器可读和高度抽象的模型，并进行数 据交换等操作【1 1 。简单地说，m d a 是在软件开发过程中使用模型的种方法埘，其目的 是为了“把建模语言当编程语言来用，而不只是设计语言”l l j 。模型可执行( e x e c u t a b l e m o d e l ) 是m d a 的终极目的。m d a 的推出标志着软件业界对模型价值的重新定位，它 将不再只是扮演软件开发的配角，而是作为核心贯穿整个开发的始末。 但是目前m d a 还只是处于标准化和规范的制订阶段，虽然一些嗅觉灵敏的公司已 经声称开始在自己的产品中加入对m d a 的支持，甚至一些支持m d a 的设计工具已经 问世，但是m d a 真正应用于软件开发实践中的例子还很少，国内的相关研究和应用也 处于刚刚起步阶段。本文正是以研究m d a 实际应用方法为目的，在平台无关模型的构 建方法上进行了有益的探索和实成工作。 本文将m d a 中的核心思想运用到领域工程的实践中，以m d a 在中小软件企业中 的应用为入手点，通过分析中小软件企业的特点提出了一个适用于中小型软件开发企业 的m d a 扩展开发模式。文中对m d a 开发过程中平台无关模型的构建方法进行了改进， 把领域框架模型引入到p i m 模型的构建过程中。通过将平台无关模型细分为通用领域框 架平台无关模型和企业相关平台无关模型这两个实现部分进一步提高了模型的复用程 度，缩短了软件开发周期。我们通过构建一个通用水泥领域生产设备管理原形系统将这 一扩展的m d a 开发模式应用予实践。在实践过程中发现现有的m d a 工具中对功能代 码自动生成的支持程度并不是很高，针对这种情况，我们又在代码自动生成部分进行了 功能上的扩展。基于现有的通用领域框架模型设计了代码自动生成器p r o j e c t m a n a g e r 。 将对模型的整体层次结构的支持和通用功能的实现部分自动嵌入到生成的代码，这样就 可以有效的弥补m d a 工具中对功能逻辑代码支持程度的缺陷。通过实践证明，m d a 扩 展开发模式可以提高模型的抽象层次；增强模型的复用性，缩短软件开发的周期，为中 小型软件开发企业在应用m d a 开发面向特定领域的软件提出了一套可行的方案。 全文共分六章，第一章绪论从当前软件开发面临的问题入手，分析了m d a 产生的 背景和趋势；第二章简要介绍了m d a 的相关理论知识：第三章将m d a 思想与领域工 程模型构建方法相结合阐述了一个适用于中小软件开发企业的m d a 扩展开发模式；第 四章结合一个应用实例对m d a 扩展开发模式做了迸一步的阐述；第五章介绍了在一个 实例模型结构的基础上扩展的代码自动生成工具p r o j e c t m a n a g e r 的设计思想和具体实 现：第六章总结全文并提出下一步的工作。 m d a 在领域工程上的研究与应用 1 绪论 早在1 9 8 9 年，为了解决跨平台的软件互操作问题，由软件技术供应商、开发者和最 终用户共同发起成立了对象管理集团o m g 。这个组织所提出的c o r b a 互操作标准已 经成为事实上的工业标准。然而，仅仅依靠孤立的接口标准所能达到的跨平台互操作能 力并不能满足需求，跨平台的软件互操作需要一个根本的解决方案。 自从c o r b a 标准制定以来，o m g 一直把它作为制订其他互操作标准的基础，因 此这些标准很自然地可以统一在对象管理体系结构o m a 之中。但1 9 9 7 年以来，随着一 系列不基于c o r b a 的重要标准的发布，o m g 对于解决软件互操作问题有了新的认识。 建模技术的逐步完善使得软件互操作问题的解决方法不再仅仅局限于统一的接口标准， 而是扩展到整个的软件生命周期，包括商务建模、系统设计、组件的构造、组合、集成、 发布和管理以及更新【3 1 a 为了更好地挖掘众多建模标准的潜力，促进和规范建模技术的 进一步发展，制定一个清晰的体系结构势在必行。 作为在软件互操作领域摄有影响力的组织，o m g 于2 0 0 1 年7 月发布了模型驱动体 系结构( m d a ) 。m d a 的推出标志着软件业界对模型价值的重新定位，它将不再只是 扮演软件开发的配角，而是作为核心贯穿整个开发的始末。这种以模型为核心的开发将 使软件的面貌以及生产软件的模式都大为改观。可以说m d a 的初衷是为了解决软件互 操作问题，但所带来的影响却将远远超越互操作领域。 1 1 传统的软件开发模式面临的问题 现 让我们重新审视一下我们的系统，并回顾一下开发此系统的艰辛的过程，我们会发 - 我们疲于应付需求的不断变更 我们的文档迅速地失效、维护困难 项目二期开发生产力无法提升 一 每当一种新的技术产生的时候，我们必须做许多重复的工作 系统永远不可能只用一种技术实现，且不跟其它系统交互。不断变更的需求同样也 给我们的系统带来困难。下面我们将分析我们使用传统的软件开发模式会遇到的问题： 1 1 1 生产力和维护性问题 当今我们的软件开发过程是以概要设计( 1 0 w - l e v e l ) 和编码驱动的。无论我们是采 用增量开发还是迭代开发，或者是传统的瀑布式开发途径，文档和相关的设计图表都是 在前三个阶段中产生。我们的需求分析往往使用文本和图的方式来描述，其中的图经常 采用u m l 图，如用例图、类图、交互图、活动图等。当编码开始的时候，前三个阶段 m d 在领域工程上的研究与应用 产生的文档和相关图片就迅速失去了它们的价值。随着编码阶段的继续进行，图片和代 码之间的关联逐渐减弱甚至消失，它们不再是对代码的精确描述，或多或少地成为了无 关的图片。编码驱动的软件开发过程如图1 - 1 所示。 瓣* 茳蘼地a 叶# 自艘 稚 日触艇 图卜1 编码驱动软件开发过程( 设计工件是文档、图) f i g u r e1 1 c o d ed r i v e ns o f t w a r ed e v e l o p m e n t 随着时间的推移，系统不断地被修改，文档、设计图表和代码之间的距离就越来越 疏远。我们仅仅是修改了代码，因为修改文档和设计图表所要花费的代价是我们无法容 忍的。同时，即使我们修改了图和文档，这样的工作是否有效也值得怀疑，因为我们还 会不断地修改代码。难道我们要花更多的时间去不断修改文档吗? 那些接踵而至的客户 需求怎么办? 哪个重要? 还是放弃文档比较现实吧。那我们前期还花那么长时间写详细 设计干什么呢? 极限编程x p ( e x t r e m ep r o g r a m m i n g ) 现在迅速地流行起来，一个主要的原因就是 它承认了代码是真正驱动软件开发的力量这个事实。在开发过程中，真正产出效益的阶 段是编码阶段和测试阶段。但是极限编程只能够解决软件开发中的部分问题：当一个团 队初始开发一个系统的时候，保存在它们大脑中的设计思想足以使它们理解这个系统。 问题是当第一个版本发布之后，团队可能会解散，其它来维护这个系统的人可能是一个 新人，那么它就只有代码和测试结果，这就使得系统维护极其困难。 所以，要么我们花时间在前三个阶段，写详细设计文档和设计图表；或者我们花时 间在维护阶段，来发现我们的系统是如何工作的。这些方式都是不能直接产出代码的， 也是花费比较高昂的。许多开发人员认为直接书写代码才是有产出的，设计模型和文档 则不能。但是，在一个程序的项目团队中，这些任务都是必须被完成的。抛弃文档写作 就能提高生产力吗? 文档写到什么粒度，既能很好地指导编码和测试，又能不降低生产 率呢? 这些一直是困扰开发人员的难题。 1 1 2 适应性问题 软件工业与传统工业相比，有其特殊性，它的发展速度令人吃惊。每年( 甚至更快) ， 新技术就被发明并迅速流行起来，例如( j a v a ，l i n u x ，x m 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 bs e r v i c e s 等等) 。许多公司必须跟从这种改变， 原因是用户提出使用新技术的需求或者新技术能够真正解决一些问题( 例如，x m l 解决 异构系统间的数据交换) ，当然还有一种情况就是软件供应商停止对旧的技术提供支持。 m o a 在领域工程上的研究与应用 新技术能够使得一些公司获得一些切实的好处，但是人们必须面临的困境就是，他 们必须快速跳跃前迸，而且必须忍受前期投资失去价值的现实，这无疑是非常痛苦的。 情况更加复杂的是，新技术本身也在发生变化。它们也会不断推出不同的版本，而且并 不能保证能完全做到向后兼容。软件供应商通常也只是对最近的2 到3 个版本提供支持。 现存的一些系统要么提供接口与新技术开发的系统连接，要么转向新技术。那些仍 然使用旧技术的遗产系统必然需要和使用新技术开发的系统进行互连。我们的系统如果 和某种技术紧密绑定，那么注定这个系统在跟随技术发展的道路上是步履沉重的，那么 如何设计我们的系统才能够使得我们的系统足够地轻便，能够适应技术的不断前进昵? 1 i 3 互操作性问题 软件系统很少能够孤立地存在，大多数都需要和其它系统进行通信。一个典型的例 子就是，很多公司在他们的现存系统上构建了基于w e b 的新系统；基于h t m l 、a s p 、 j s p 等的w e b 应用程序需要从现存的后端系统中获取信息等等。系统往往要使用多种技 术来实现，他们之间也存在互操作的问题。现在我们往往在系统中使用组件，不同的组 件使用各自最佳的技术来实现，他们之间也需要互操作。 不同的工具对于元数据的管理均有自己的策略，这就给元数据的共享形成了障碍， 也降低了不同软件的互操作性。如何应对这些互操作的需求呢? 能否有一个统一的解决 方案呢? 1 1 4 文档问题 许多的开发人员总是认为编码才是他们的主要任务，文档可用性的支持可以缓一缓。 最终写文档成了强制的任务，而不是出于激励的目的，不是出于自愿的工作当然不能做 好。这个是文档为什么质量总是不够高的原因之一。 能够检查文档质量的也只能是开发团队的人员，而他们自己却讨厌写文档的工作。 因此这也是文档总是不能得到更新的原因。每次代码改变之后必须手工去在一堆文档中 找出设计中需要更改的地方，这是多么烦琐的工作。而我们的工作应该是开发一个容易 修改和便于将来维护的系统。 在代码层次上解决这一问题的方案就是能够便利地从代码中产生文档，使得文档是 代码中不可分割的一部分。这种方案被一些语言所支持，比如j a v a 语言。但是这种方案 只能解决概要( 1 0 w 1 e v e l ) 设计文档的问题，详细( h i g h - l e v e l ) 的设计文档仍然需要手 工维护。对于一个复杂的系统，在抽象层次上描述系统的详细设计文档尤为重要。如何 能够保持文档和代码的同步，而又不额外增加很多工作量呢? 1 2 新软件开发模式m d a 的提出 人们一直在不断的探索新的开发模式以彻底解决现存的问题。对象管理组织o m g m d a 在领域工程上的研究与应用 在这方面作出了重大的贡献。它于2 0 0 1 年7 月推出了基于模型的m d 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 d a 的新发明，但是m d a 可以扩展并推动这些技术更好地协作。 m d a 非常强调建立良好的设计，这些设计不再停留在纸上，而是存储在标准仓库 中，它们可以被m d a 工具读取，并通过各大厂商提供的各种标准映射自动变成c + + 代 码、j a v a 代码、c # 代码、测试框架、整合代码、j a v a 对象、n e t 对象、部署脚本乃至软 件文档，而且可以映射到j 2 e e 、n e t 等各种平台。而且，软件开发各阶段工件( 代码、 文档等) 以及各版本的同步问题不再存在，因为从本质上说，m d a 方法极大的去除了 重复劳动，你不需要在文档、模型、代码中把同一问题的答案用几种语言分别描述一遍， 也不需要维护同一套应用系统的w i n d o w s 、l i n u x 或者j 2 e e 、n e t 等多个版本；相反， 你只需辛苦一次，剩下的事情就交给各种m d a 映射去自动解决。投入到m d a 模型的 设计努力会被多次复用来生成各种组件。这些模型可以在应用的整个生命周期中不断更 新，以精确反映经过多次维护的软件现在是怎样工作的，而不是停留在设计阶段结束的 一幅静止画面上。简而言之，m d a 是一个在今天多平台i t 环境中创建良好设计的构架。 m d a 软件开发过程的模式如图卜2 所耐。 图卜2 肋a 的软件开发模式 f i g u r e1 2 t h ed e v e l o p p i n gm o d eo f f 1 ) a 开发人员首先创建系统的平台无关模型( 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 的反复映射来进行精化，这种映射的含义比较宽泛，可以是全人工的，也可 以在一系列规则的指导下进行，还可以通过一些自动化的工具来完成，但实际上，要想 达到完全的自动化是很困难的。在获得了足够精化的p i m 以后，就要通过具有一定规则 的映射来生成与特定平台相关的模型p s 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 映射逐步精化，最终得到代码。m d a 推出的本意是要在更高的层次上解决互 操作问题。然而事实上，将模型作为驱动开发的主干，这种策略却在软件开发模式上有 着重大意义。为了让大家进一步的了解m d a ，下面我们将在下一章详细介绍m d a 的一 些基本概念。 m d a 在领域工程上的研究与应用 2m d a 基础理论 2 1m d a 的基本概念 2 1 1m d a 的产生背景 软件系统的开发本质上是一个从模型到最终实现的过程。由于具体的实现技术及其 相关标准总在不断地发展变化，如果系统的模型和实现技术是一种紧密耦合关系，那么 系统的升级以及系统与其他系统之间的集成就相当困难。基于此，o m g 提出了把系统 的业务功能分析设计和系统的具体实现基本分离的思路，以求把实现技术的变化对业务 系统的影响降低到最小化的程度。从宏观看，这种m d a 的思想使得应用模型与领域模 型在整个软件生命周期中得到了复用，保证了已有投资并驱动整个系统的技术升级。 2 1 2m d a 的概念 m d 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 中，平台指的是和系统的基础功能无关的技术细节口】。例如一个资金转账的组 件，它的基础功能就是从一个指定的账户扣除一定数额的资金，并在另一个指定的账户 里增加相同数额的资金。无论这个组件是以c o r b a 对象的方式来实现还是以f a b 来实 现，这个功能是不变的。一个不带有任何特定技术细节的系统模型，就是平台无关模型 ( p i m ) 。这种模型描述了系统独立于任何实现平台的结构和功能特征。而包括了特定 技术细节的模型，就是平台相关模型( p s m ) 。这种模型描述建立在特定技术基础上的 系统结构和功能特征。 基于m d a 的开发首先关注于分布式系统或者应用程序的功能和行为，丽不是它将 采用哪种具体的技术来实现。m d a 使得业务逻辑和实现细节相分离。因此，每当一种 新的技术( 例如x m l s o a p ) 到来的时候，我们不必再重复对系统或者应用进行建模的 过程，而其他架构往往都和某种特定的技术或者平台捆绑在一起，无法达到这一目的。 使用m d a ，我们对系统的功能和行为的建模只需一次，而且是仅需一次。将p i m 映射 到某个特定平台的p s m 的工作是由工具自动完成的，当我们需要支持新的技术的时候， 这就简化了我们的工作。 2 2m d a 的组成结构 2 2 1 组成结构概述 m d a 的结构可以分为三个依次包容的圈层，如图2 - 1 所示，从里向外分别是核心 技术层、中间件技术层、公共服务层1 3 1 。 m d a 在领域工程上的研究与应用 核心技术层包括统一建模语言( u n i f o r mm o d e l i n gl a n g u a g e ，u m l ，建模工具) 、 元对象设施( m e t a - o b j e c tf a c i l i t y ，m o f ，标准的建模与交换结构) 、公共仓库元模型 ( 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 ，数据仓库的标准) 、基于x m l 的元数据交 换( x m lm e t a d a t ai n t e r c h a n g e ，x m i ，信息交换的标准格式) 等，这些核心技术直接面 对系统结构的架构。 中间件技术层包括c o r b a ，w e b s e r v i c e ，j a v a ，n e t ，x m i x m l 等。通过合适的 映射工具，可以从用m d a 核心技术表示出来的系统体系结构模型直接生成中间层代码。 公共服务层包括o m g 从众多业务运行系统中提取出来的公共服务，如目录服务、 安全服务、事务服务、事件服务等。这些服务可以方便地集成到最终的应用系统中，如 空间信息服务，电信、商务、制造等。 图2 1m d a 组成结构图 f i g u r e2 - 1c o n s t r u c t i o no f 肋a 2 2 2m d a 的模型架构介绍 在m d a 中，模型不再仅仅是描绘系统，扶助沟通的工具，而是软件开发的核心和 主干【2 】。为了从技术细节及其复杂实现中分类出相应特定的业务信息，m d a 依赖于2 个 独特的模型：平台无关模型( p i m ：p l a t f o r mi n d e p e n d e n tm o d e l ) 和平台相关模型( p s m ： p l a t f o i i ns p e c i f i cm o d e l ) 。m d a 就是一种基于p i m 规范和开发应用程序的方法。通过 使用不同的映射规则，一个p i m 可被映射成多个p s m 。他们之间有着抽象和求精的关 系，m d a 的目标是通过模型精化消除不相关的抽象细节层次。模型之间通过模型映射 机制相互映射，从而保证了模型的可追溯性【5 】。 软件的开发和更新过程就是模型自顶而下，逐步求精的过程。首先由模型映射专家 仰a 在领域工程上的研究与应用 将商务模型映射到平台无关的模型，然后由平台技术专家将平台无关模型映射到平台相 关模型嘿 m d a 的基本思想就是：切都是模型。软件的生命周期就是以模型为载体并由模 型映射所驱动的过程 6 1 。首先赭象出与实现技术无关、完整描述业务功能的核，心模型 ( p i m ) ，针对不同实现技术制订多个映射规则，通过这些规则及辅助工具将p i m 转换 成与具体实现技术相关的应用模型( p s m ) ，最后将p s m 转换成特定运行平台上的代 码。 2 3m d a 的核心技术 建模和模型映射技术是m d a 的核心，它们是元对象设施( m e t ao b j e c tf a c i l i t y m o f ) ，统一建模语言( u n i f i e dm o d e l i n gl a n g u a g e ，u m l ) 。 2 3 1 统一建模语言u m l u m l 融合了b o o c h ，o m t 和d o s e 方法中的基本概念，而且这些基本概念与其他 面向对象技术中的基本概念大多相同f ”，因而，u m l 成为这些方法以及其他方法的使用 者乐于采用的一种简单一致的建模语言。u m l 扩展了现有方法的应用范围，从分析、设 计、实现、部署都可以用u m l 来进行可视化建模。目前，u m l 作为对象管理组织( o m g ) 的标准可视化建模语言，已成为信息模型的标准语言。 u m l 是使能m d a 技术的一把钥匙：使用m d a 技术创建的所有应用程序都基于标 准化的、平台独立的u m l 模型。通过将这一通用的、被普遍接受的建模标准作为杠杆， m d a 使得开发人员可以创建能被轻便地访问、天生具有良好的互操作性的应用程序。 在m d a 中使用u m l 的方式可以有两种 i 、开发人员使用u m l 来对系统进行建模，产生p i m 。使用u m l 建立的模型必须 具有一致性和精确性，能够被m d a 工具理解并能够被转换成模型和代码。 2 、软件架构师需要定义用于指导模型转换的规则。他们不开发某个特定系统的模型， 而是创建将种模型转换到另一种模型的规则，这种规则是可以作用于任何模型和不同 的系统的。软件架构师必须对u m l 语言的原理和使用有深刻的了解，同时还必须熟悉 u m l 元模型，因为元模型是用来定义转换规贝f j 的重要元素。 2 3 2 元对象设施m o f 不同的功能需要不同的建模结构集：关系数据建模所需的建模结构包括表、列、键 等等。工作流建模所需的建模结构集包括活动、执行者、变化、分割、连接等等。i y m l 类建模所需的建模结构集包括类、属性、操作、关联等等。所以，为了描述某一特定类 型的模型，我们必须描述组成该类模型的建模结构集。能有一种一致的方法来描述语言 m d a 在领域工程上的研究与应用 结构是非常有用的。业界正在使用全然不同的方法来描述不同类型建模结构的本质。 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 天生就是面向 对象的，它定义了基本的元素、语法、元模型的结构，为构建面向对象元模型定义了一 种公共的抽象语言【9 】。这种元模型可以是通用的，如u m l ，也可以是针对特殊应用领域 的，如c w m 。 m o f 映射提供了将m o f 的m e t a - m o d e l 中的语义具体加以应用的手段。m o f 映射 包括三种类型：抽象映射、i d l 映射、x m l 映射。抽象映射是一组规则，它确定了 m e t a - m o d e l 里的各种语义是如何对依据该m e t a - m o d e l 定义的m o d e l 进行限制和规范的； i d l 映射是一组标准模板，可以将一个用m o f 定义的m e t a m o d e l 映射成一组c o r b a i d l 接口，这组接口的用途是访问一组c o r b a o b j e c t ，而这组c o r b a o b j e c t 则是表现 用这个m e t a - m o d e l 定义的m e t a - d a t a 的。这些i d l 接口的典型用途是用在存放元数据的 存储上；x m l 映射产生该m e t a - m o d e l 对应的x m ld t d 3 ，以及提供一组规则将 m e t a - m o d e l 定义的m o d e l 映射成遵守该d t d 的x m l 文件。这些标准的x m l 文件非常 适合异构的环境下传递。 2 4m d a 的开发生命周期 如图2 2 所示，m d a 开发模式的生命周期与传统的方式看起来区别并不大。他们 都具有相同的开发阶段，主要的区别就是各个阶段的设计工件是不相同的，m d a 的设 计工件是正式的精确模型，它们能够被机器所理解。 2 4 1m d a 开发步骤 图2 2 模型驱动软件生命周期 f i g u r e2 - 2 l i f ec y c l eo fm d a ( 1 ) 首先我们使用平台无关模型p i m 从如何以最好的方式支持商业逻辑的角度来 对系统进行建模。p i m 是对系统的一种高层次的抽象，与具体的实现技术无关。在此过 程中，我们会不断根据客户需求和其它因素对p i m 进行精化，以使得它能够更加精确地 描述我们的系统。 ( 2 ) 然后p i m 可以被转换到一个或者多个特定平台模型p s m s ，对于每种特定的技 9 m d a 在领域工程上的研究与应用 术平台都会生成独立的p s m 。p s m 是针对你选择的实现技术、平台，对你的系统度身 定做的模型。例如，e j bp s m 是对使用邵b 结构的系统的建模，它包含一些e 3 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 nb e a n ”等。而关系数据库p s m 包含 名称如”t a b l e ”、”c o l u m n ”、”f o r e i g nk e y ”等。由于现今的很多系统都跨越多种技术，所以 对于一个p i m 拥有多个p s m 是很正常的。这是m d a 中最复杂，也是最重要的一步。 ( 3 ) 有时候从p l m 自动生成的p s m 并不能使挑剔的程序员满意，他们会根据平台 的特性对p s m 加以修改，对p s m 的改变也能够反映到p i m 中去，这是m d a 的高级特 性【1 0 1 。 ( 4 ) 对p s m 迸行不断的精化，以指导生成器生成质量更高的代码。 ( 5 ) 最后一步就是将每个p s m 都转换到代码，由于p s m 跟具体的系统实现技术 已经很接近，因此这种转换来得比较直接。 2 4 2m d a 提升了抽象层次 p i m ，p s m ，和c o d e 模型被作为软件开发生命周期中的设计工件。重要的是，它们 代表了对系统不同层次的抽象，从不同的视角来看待我们的系统，将高层次的p i m 转换 到p s m 的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构， 而不会被具体的实现技术所“污染”，同时对于复杂系统，也减少了开发人员的工作量。 2 5 m d a 的特点 2 5 1m d a 与其它架构的不同点 m d a 开发途径看起来和传统的开发方法很类似，但是这里有一个至关霞要的不同， 就是模型在m d a 中是可执行的，是能够产生输出的。 传统意义上，从模型到模型，从模型到代码的转换主要是手工完成的。虽然有些工 具可以从模型中产生部分代码，但是它们一般都是通过指定的模板来生成，有很大的局 限性，大多数的工作仍然需要手工来完成。 与之形成鲜明对照的是m d a 中的转换通常都是通过工具来完成的。许多工具能够 将p s m 转换成代码。事实上，p s m 已经和代码非常接近，这种转换其实没什么稀奇的。 对于m d a 来说，其重要的改变就是它将从p i m 到p s m 的转换也自动化了，它是m d a 给我们带来的最大的惊喜。想想以前，从详细设计中创建数据库模型要花费我们多少工 作? 从相同的设计中创建c o m 组件或者f a b 组件要花我们多少时间? 现在使用i v i d a 我们可以自动化这一过程。 由于m d a 是- - j e e 新的框架，现在的工具无法百分之百完成从p i m 到p s m 以及从 p s m 到代码的转换。开发人员需要手工来完善转换后的p s m 或者c o d e 模型，不过现在 1 0 m d a 在领域工程上的研究与应用 的工具已经可以从p i m 最终产生具备基本功能的可运行的应用程序。这样开发人员可以 迅速地验证系统的基本功能，从而进一步优化p i m 。 从这里我们可以看出，事实上建模语言在m d a 中已经成为了一种编程语言而不仅 仅是设计语言，模型所发挥的作用更大了，能够从模型中生成代码，也使得我们对建模 的投资获得了更大回报。 2 5 2 使用m d a 进行系统开发的好处 2 5 2 1 提高了生产率 m d a 将开发人员的注意力转移到开发p i m 上，虽然很多时候仍然需要做很多复杂 的工作定义额外的信息来指导模型的转换。但是这种工作只需要做一次，并能应用到不 同的技术平台上。虽然定义转换规则的工作量是比较大的，但是它仅仅由高水平的软件 架构师来完成，一旦创建完成，就可以分发到项目组中使用，主要的开发人员只需要将 注意力放在开发p i m 上面。由于它们创建p i m 的过程与具体的平台无关，它们可以免 于陷入具体的实现细节当中。这些实现细节可以在从p i m 到p s m 模型转换的过程中被 自动加入。这就从两方面提高了生产率：一方面，最好的实践表明模型技术将系统分离 成不同的模块，这种分离是m d a 的基础，简化了每个系统模块，使得他们易于创建、 开发、重用和维护。p i n 开发人员由于不需要设计和撰写平台相关的细节，减少了工作 量。在p s m 和c o d e 层面，开发人员仅需要编写少量的代码，因为大部分的框架代码都 已经从p 1 m 中自动生成了。另一方面，从模型中自动生产高质量的、完全的实现代码， 将使得开发者解放出来，他们可以花更多的时间去解决商业逻辑的问题，这样可以使得 系统更加符合客户需求，在更短的时间内完成更多的功能性需求的分析和设计。 能够带来这种效率提升的前提是我们拥有一个能够完全实现从p i m 到p s m 自动化 转换的工具。这就暗示着我们的系统大部分信息都必须融入到p i m 当中，并能够被工具 所理解。由于详细设计不再仅仅是纸张，而是能够直接产生代码的驱动力，所以就要求 p t m 必须完整、准确，对系统建模的要求比传统的开发方式要高很多。 2 5 2 2 增加了可适应性 m d a 关注的是平台无关的模型，而它天生就具有较强的适应性。对于多种流行的 平台，很多工具将会支持从p i m 到此平台的p s m 的转换。对于那些不是很流行的平台， 开发人员可以选择支持插入功能的工具，将为这种平台定义的转换规则嵌入到工具中使 用。对于将来可能产生的新的技术和平台，软件工业将会分发相应的转换规则。这能够 使得我们迅速地将p i m 使用新的技术实现，并发布到新的平台中。 2 5 2 3 增加了互操作性 从p i n 中生成的多个p s m 之间可能存在一定的关系，在m d a 中，它们被称为桥 接器( b r i d g e s ) 。由于p s m 针对一个特定的目标平台，所以它们相互之间不能够直接通 信。无论如何，我们需要将一个平台的概念转换到另一个平台的相关概念，这就是我们 m d a 在领域工程上的研究与应用 常说的互操作性。m d a 解决这一问题的方法是，不光从p i m 生成p s m ，还生成连接p s m 的桥接器。 假设我们从p i m 中生成两种目标平台的p s m ，我们所需要的弥补两个p s m 之间鸿 沟的桥接器接信息都是可得的。对于一个p s m 中的每个元素都是从p i m 中的元素转换 得到的；对于p i m 中的每一个元素都会转换到2 个p s m 中的对应元素。因此我们可以 推断一个p s m 中的元素和另一p s m 中的元素是有关系的。同时我们也知道两个平台的 技术细节，因此我们就掌握了为p s m 之间生成桥接器的所有有用信息。 举例来说明这个过程：个p s m 是j a v a 平台模型，另一个p s m 是关系数据库模型。 对于p i m 中的一个元素c u s t o m e r ，转换到j a v a 平台模型中是j a v ac l a s s ：转换到关系数 据库模型中是一张表。创建j a v a 对象和数据库表之间的桥接器接是非常容易的。为了从 数据库中获得数据，我们查询c u s t o m e r 表，实例化j a v a 对象并保存数据到对象中：为 了保存对象，我们从j a v a 对象中获得数据并保存到c u s t o m e r 数据库表中。 我们可以通过使用工具产生p s m 以及它们之间的桥接器来实现跨平台的互操作性。 你可以通过投资p i m 的方式来将你从繁杂的技术细节变更中“拯救”出来。 2 5 2 4 提高了可维护性，解决了文档问题 在m d a 中，模型是对代码的最佳谂释，p i m 完全可以当做设计文档来对待。与传 统的文档相比，一个很大的不同就是当完成p i m 的创建之后，p i m 不会象传统的文档那 样被“抛弃”。对系统的改变首先是要更改p i m ，再从p i m 重新生成p s m 和代码。根 据