（计算机应用技术专业论文）新型抽象建模的研究与实现.pdf

摘要 摘要 本课题针对“需求快速变化这一企业级管理软件开发中呈现的特点，提出 一个“以用户为中心 的软件过程模型，即软件组织和业务用户共同参与软件开 发活动，并由业务用户完成最终应用软件的构造，而软件组织的根本任务则是打 造可以让业务用户使用的开发环境。 透过深入研究o m g 的模型驱动攥架( m o d e ld r i v e na r c i 睦t e c t u r e ) 理论，本 文提出了一种新的软件开发过程，通过采用模型捕捉用户的核心需求，去除与实 现技术相关的不重要的细节，提高用户需求的抽象层次，有效的解决了复杂性的 闯题。由于采用模型建模系统，不涉及具体的实现技术，与具体实现技术相关的 工作都由模型转换工具来完成，所以可以根据具体需求的变化，随时更新系统的 模型生成新的系统，从而屏蔽了由实现技术带来的多样性的问题和随着时间变化 带来的易交性的问题。本文通过讨论模型的构造过程和模型转换过程，并结含自 主开发的企业梅建平台( n e wg e n e r a t i o np l a t f o r mf o re n t e r p r i s ea p p l i c a t i o n i n t e g r a t i o n ) 说明软件开发过程。 由于目前的模型语言( 如u m l 、m o f ) 的语义定义还不够精确，所以其相 关应用( 如模型转换) 无法得以精确的描述。因此，本文提邀了一耪新型的掬象 模型，可执行模型。通过规范的概念识别、文法定义、语法分析和语义分析的过 程，构造可执行模型，由此彻底解决语义不精确、二义性等问胚。可执行模型的 可执行性表现为能够在实现具体应用前对系统进行验 芷、测试。模型的可执行髓 力也是进一步模型转换应用及其它相关应用的基础。 由于可执行模型与具体的技术细节和实现平台无关，就需要进行从平台无关 模型( p l a t f o r mi n d e p e n d e n tm o d e l ) 至e 平台相关模型( p l a t f o r ms p e c i f i cm o d e l ) 的转 换。本文通过对平台无关模型和平台相关模型的结构和语义表达特点进行分析， 提出了基予语义一致性的模型转换方法，为模型转换提供语义层面的指导。转换 后的平台相关模型可以利用企业构建平台中的运行平台验证、解析平台相关模型， 理解其中包含的信息，最终实现整个系统应用。当需求发生变更时，开发人员只 霈要更改模型，导出新的平台相关模型并加载到运行平台中，就能够完成系统的 一次迭代。这种方法可以极好的应对企业业务的变化，实现开发中的快速迭代。 综上所述，本文的研究成果丰富了可执行模型的理论，推动了可执行模型的 摘要 应用研究，具有一定的理论意义和实用价值，为模型可执行的研究和可执行模型 集成开发环境的研制提供了有意义的方法和手段。 关键词：模型驱动框架，可执行模型，语义一致性的模型转换，企业构建平台 a b s t r a c t a b s 仃a c t r e q u i r e m e n t sc h a n g er a p i d l y i st h ec h a r a c t e r i s t i co fe n t e r p r i s em a n a g e m e n t s o f t w a r e c o n s i d e r i n gt h i sp o i n t ，w ep r o p o s ean e wm o d e lw i t hf o c u so nu s e r i nt h i s m o d e l ，s o f t - w a r eo r g a n i z ea n db u s i n e s su s e rj o i nt h es o f t w a r ed e v e l o p m e n tt o g e t h e r , a n dt h eu s e r sc o m p l e t et h ed e v e l o p m e n tf i n a l l y , o t h e r w i s et h es o f t w a r eo r g a n i z e st a s k i st od e v e l o pi n t e g r e a t i o nd e v e l o p m e n te n v i r o n m e n t t h i sr e s e a r e hi sb a s e do nt h eb a s i ct h e o r i e so fm d a ，a n dm a k e ss o m ee x t e n s i o n w er e s e a r c hm d a t h e o r yd e e p l ya n dp r o p o s ean e w s o f t w a r ed e v e l o p m e n tm e t h o d w e u s em o d e lt os e i z et h eu s e r sc o r er e q u i r e m e n t , n o tt oc o n s i d e rt h ed e t a i lm a ti s r e l e v a n tt ot e c h n i q u eb u tn o tv e r yi m p o r t ；t h i sm o d e lw i l li m p r o v et h ea b s t r a c tl e v e l w i t hu s e r sr e q u i r e m e n t ，a n ds o l v et h ec o m p l e xp r o b l e me f f e c t i v e l y b e c a u s eo f u s i n g m o d e lt ob u i l d s y s t e m ，n o tr e l e v a n t t o s p e c i f i ct e c h n i q u e ，w en e e dm o d e l t r a n s f o r m a t i o nt o o l st of i n i s ht h i st r a n s f o r m a t i o n w ec a l lu p d a t et h em o d e la ta n yt i m e a c c o r d i n gt ot h er e q u i r e m e n t ，s ot h a tt oa v o i dc o m p l e x i t y , d i v e r s i t ya n dc h a n g ed u r i n g s o f t w a r ed e v e l o p m e n t i nt h i sp a p e r , i tw i l le x p l a i nt h ep r o c e s so fm o d e l sb u i l da n d t h ep r o c e s so fm o d e lt r a n s f o r m a t i o n , a n dw i l lc o m b i n ew i me n t e r p r i s ea r c h i t e c t u r e p l a t f o r m a l lo ft h em o d e ll a n g u a g e si ne x i s t e n c ea r ep o o ri ns e m a n t i c s ，a n dt h u sa l l r e l e v a n ta p p l i c a t i o n s ，s u c ha sm o d e lt r a n s f o r m a t i o n , c a n n o tb es p e c i f i e dp r e c i s e l yw i t h t h e m i nm y p a p e r , ip r o p o s ean e wa b s t r a c tm o d e l ，e x c u t a b l em o d e l a f t e rf o u rp h r a s e t h a ti sc o n c e p t si d e n t i f y , g a m m e r sd e f i n e ，s y n t a xa n a l y s ea n ds e m a n t i c ea n a l y s e ，w e c a l lb u i l dt h i se x e u t a b l em o d e l ，s o 也a ts o l v et h es e m a n t i c sp r o b l e m t h ee x e c u t a b l e a p p l i c a t i o n m o d e lc a nb ev a l i d a t e d ，t e s t e d ，e m u l a t e db e f o r ei ti sr e a l i z e d t h e e x e c u t a b l ea b i l i t yo fm o d e li se l e m e n t a r yf o rm o d e lt r a n s f o r m a t i o na p p l i c a t i o na n d o t h e rr e l e v a n ta p p l i c a t i o n b e c a u s eo ft h i sm o d e li sp l a t f o r mi n d e p e n d e n tm o d e l ，a f t e rt h ep h r a s eo fm o d e l s i l l a b s t r a c t b u i l d t h i sp a p e rp r o p o s e dan e wt r a n s f o r m a t i o nm e t h o d ，m o d e lt r a n s f o r m a t i o nb a s e d o ns e m a n t i cc o n s i s t e n c ya c c o r d i n gt oa n a l y z i n gt h ec o n s t r u c to ft h o s et w om o d e l sa n d t h ec h a r a c t e ro fs e m a n t i c a f t e rt r a n s f o r m a t i o n , w ec a na n a l y s ea n du n d e r s t a n dt h i s p s m b yu s i n gn p e a i ，f i n a l l yf i n i s h e st h ew h o l es y s t e m t h i sm e t h o dc a nd e a lw i m t h ec h a n g eo f e n t e r p r i s ee x c e l l e n t l y i nc o n c l u s i o n ，t h ea c h i e v e m e n to ft h i sd i s s e r t a t i o ne n r i c h st h ee x e c u t a b l em o d e l t h e o r ya n dm a k e st h ea p p l i e dr e s e a r c ho nt h ee x e c u t a b l em o d e lt h e o r yp r o g r e s s i ti so f g r e a tt h e o r ys i g n i f i c a n c ea n dp r a c t i c ev a l u e i tp r o v i d e se f f e c t i v em e t h o d sa n dm e a l l 8 f o rt h er e s e a r c ho nt h ee x e c u t a b l em o d e la n di t si n t e g r a t i o nd e v e l o p m e n te n v l r o n m e n t k e yw o r d sm d a , e x e c u t a b l em o d e l ，m o d e lt r a n s f o r m a t i o nb a s e do ns e m a n t i c ； e n t e r p r i s ea r c h i t e c t u r ep l a t f o r m i v 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工 作及取得的研究藏果。据我所知，除了文中特别加以标注和致谢的地 方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含 为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。 与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明 确的说明并表示谢意簪 签名_ 。釜壶! 茎 旦期：年月圜 关于论文使用授权的说明 本学位论文作者完全了髂电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁 盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文 的全部或部分内容编入有关数据瘴进行检索，可以采用影印、缩印或 扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名：堡垒磊导师签名： 日期：年月臼 第一章绪论 1 1 课题背景 第一章绪论 在复杂多变的市场经济环境下，企业不断的优化调整自身业务规则，这导致 管理软件的业务需求总是不断变化，如何找到一种新的软件开发过程模型，使软 件开发能够快速适应需求的变化，这已经成为软件研究人员的重要研究课题之一。 1 2 课题研究的内容和意义 企业信息化管理已经成为制约企业特别是中小企业发展的核心问题。对于大 型企业而言，由于管理模式相对接近，使用一套通用的管理软件相对可行。而对 中小企业，关键问题在于实施成本。一方面根据国家统计局公布的数字，截至2 0 0 5 年底，中国有超过1 千万家的中小企业，这些企业具有强烈的信息化需求；另一 方面，他们有千差万别的应用需求，又无力承担实施信息化的高昂费用。基于以 上分析，研发一个新一代企业级应用系统构建平台，快速定制应用系统，使得构 建的应用系统功能全面、强大，就成为解决上述问题的最佳思路。中小企业可以 在这样的平台上定制完全符合本企业实际应用需求的应用系统，并根据企业的成 长随时进行调整；实施这些应用的费用相对低廉，只需要支付特定功能的费用， 并根据功能的扩展再支付更新费用。根据以上思路，企业级应用系统构建平台一 小m e a i ( n e wg e n e r a t i o np l a t f o r mf o re n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o n ) ，能完全 满足中小型企业的要求。 随着信息技术的发展，一大批信息系统，如客户关系管理系统、自动办公系 统、资金管理系统等被开发出来，对提高管理效率起到了重要的作用。但是在这 些系统的开发和后续的扩展过程中存在很多长期无法解决的难题，最突出的问题 就是设计与实现不一致。本课题就是通过对软件开发框架的研究，创建出机器可 读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存，最终实 现支持软件设计和模型的可视化、存储和交换。通过模型，填补在设计和实现之 1 电子科技大学硕士学位论文 间的鸿沟。 1 3 课题来源和作者的主要工作 课题来源于信息产业部信息产业生产发展基金“n p e 似一新一代企业应用系 统构建平台 以及电子科技大学青年博士平台基金。作者主要的工作是在该课题 中对模型驱动构架的理论研究及实现。 1 4 本文的章节安排 本论文内容安排如下： 第一章，绪论，介绍课题的背景、研究的内容和意义、可以的背景以及作者 的主要工作。 第二章，基于模型驱动框架的综述，包括模型驱动架构的基本原理的介绍， 传统设计开发方式和模型驱动架构的对比。 第三章，模型的总体研究。针对m o f 模型和u m l 元模型的无法提供精确的 语义的问题，提出了可执行模型，并研究了可执行模型的构建。 第四章，可执行模型域的研究，结合企业构建平台将可执行模型分为应用域、 服务域和数据域三个部分，并分别从这三个域对可执行模型进行研究。 第五章，可执行模型转换的研究，现存的模型转换方法存在诸多弊端，本章 提出了一种新的基于语义一致性的模型转换方法，并结合可执行模型进行研究。 第六章，课题总结，总结了本课题的创新点，实用性，并提出了未来的工作 方向。 2 第二章基于模型驱动架构的综述 第二章基于模型驱动架构的综述 2 1 企业信息系统现状 企业信息化一直以来被人们广泛关注并投入巨大人力、物力进行建设和研究。 企业信息化也为企业带来经济效益和保证了其未来的竞争力。所以，选择适合企 业的通用管理软件是加快信息化进程的关键。目前市场上虽然有名目繁多的管理 软件，如e r p ( e n t e r p r i s er e s o u r c ep l a n n i n g ) 、c r m ( c m s t o m e rr e l a t i o n s h i p m a n a g e m e n t ) 、s c m ( s u p p l y c h a i nm a n a g e m e n t ) 等。但是，专门针对中小企业产 品始终较为匮乏。 传统企业信息系统( 国内外相关产品，如3 r d w a v e 、b u s i n e s s 3 0 、思维加速平 台等) 具有功能较强，行业专用性较强等的优点，但他们同时也存在着很多不足 的地方，如： 1 ) 目前市场上相对成熟的管理类软件大都是为大中型企业设计的，其系统模 块的复杂度较高，对于业务流程相对简单、应用需求相对单一、专业技术人才缺 乏的中小企业来说，不可能选择使用那些系统复杂度高、使用难度大的产品。 2 ) 开发和部署成本较高，动辄数百万甚至上千万的价格也实在令中小企业望 而生畏。 3 ) 构建非常麻烦，在操作系统、数据库系统方面兼容性不高，对中小企业适 应性差。 2 2 当前应用系统中主要面临的问题 2 2 1企业现实与系统抽象之间的差距 这个问题是企业应用系统开发中一切麻烦的根源。企业作为社会商业活动最 重要的组成单位，其本身非常复杂。哪怕是一个小型企业，其内部也会存在着大 3 电子科技大学硕士学位论文 量的实体、流程、关系、规则、事件等等部分，这些部分相互交织，又互为影响。 而大型企业的复杂就更加难以令人想象。特别是庞大到了实行集团制，乃至于跨 国经营的企业。其内部组织结构、业务流程和数据信息格式多种多样。以零售业 巨头w a l m a r t 为例，该公司一天产生的数据量就多达数十g b 。这还只是进入系 统的数据，此外必然还有大量没有进入系统或者无法用系统描述的事情发生。而 这，正是复杂的企业现实。 企业应用系统的目的便是要描述如此复杂的企业，并或多或少，将企业现实 带入到计算世界中来。但企业应用系统必然是有所为有所不为，它不可能将企业 各个方面事无巨细统统处理，只能根据企业需要处理部分业务；同时它也不会将 企业现实完整再现，而只是在现实基础上加以抽象，在一定的高度下进行工作。 举一个最为常见的例子，一个企业有很多的客户( c u s t o m e r ) ，姓名可能是 j o c r g ，j e n s 等等，企业会对每一个顾客使用相应的流程。而在企业系统中，会把 所有的客户都抽象为一个c u s t o m e r 类，然后对这个c u s t o m e r 类应用统一的流程 进行处理。在此过程中，企业同不同客户大量复杂的关系，就被抽象为c u s t o m e r 类与企业流程的关系了。 这样的抽象面临着一个重大挑战，那就是它能否准确的代表企业现实。在抽 象的过程中，无论是对企业实体信息，企业流程还是企业规则以及外部事件，只 要对任何一个部分的抽象不够准确，都会导致最后企业应用系统的不准确，从而 无法适应企业的需要。 近十年来，这种抽象的难度又有大大的提高，原因是如今的企业变化过于迅 速。国际形势在变，商业环境在变，技术革命日新月异，企业无不试图通过及时 而灵活的调整自己以适应外部环境。于是大量企业几乎每年都会进行局部甚至全 体的组织结构调整，企业流程再造，企业规则更改。可以想象到企业应用系统随 之而调整的难度会有多么大，因为在传统意义上，一套系统一旦交付使用，那就 如同盖好的楼房已经很难再更改了，因此在近十年来，企业应用系统的淘汰率也 大大提高。很多企业系统甚至长期没有交付的时候，因为需求似乎永远在变动。 特别突出的例子是一些不够灵活得e r p 系统。很多e r p 产品在产品中内置了一 套业务规则，这套规则是从大量普遍性需求中抽象出来的，可以满足很多客户的 4 第二章基于模型驱动架构的综述 需要，但过于死板，一般还要求客户改变自己的原有业务流程来适应新系统。每 个企业都有自己的独特情况，强行套用系统的业务规则实在是削足适履。大部分 e r p 系统提供商在面对用户的特定需求时，往往采取对原有产品进行修改，或进 行二次开发以适应客户的要求，这个过程会耗费大量的资源。而且在二次开发过 程中，由于面对的是一个不确定而且非标准化的客户需求，开发过程更加难以控 制。这无形中又增加了企业的信息化成本。 2 2 2 系统建模不够准确且前后脱节 当前企业应用系统开发中，对企业现实进行抽象最常用( 甚至可以说是唯一) 的方法是对企业建立模型。 对象管理组织( o b j e c tm a n a g e m e n tg r o u p ，o m g ) 对系统模型的定义如下【l 】： 系统模型是为了达到某种目的，对系统及系统所处的环境所进行的描述或者规范 化的表述。模型经常被表示为图形和文字的组合，其中文字可能是建模语言或者 自然语言。 从模型本身的定义来看，大部分建模语言和建模工具都能提供一整套的图形 和文字组建用来描述企业现实的抽象结果和描述系统本身，这对企业系统开发帮 助甚大，至少使得在前期，复杂的企业能够迅速被抽象出来，而在整个开发过程 中，也有一套基本的标准可以遵循。然而很多问题也正是出在模型上。 首先模型能否准确地描述企业和系统本身。对企业现实进行建模，最理想的 情况是使用专门的企业业务建模工具，并根据建模结果生成和配置系统。然而现 在大多数建模工具没有这个能力，对企业建模仍然依靠一些传统的工具和手段， 只不过对传统工具加以扩展使其适应企业建模而已。这样做往往无法精确和完整 地描企业，最后建模结果的可读性也比较差。而对企业的分析模型不准确势必导 致最终的软件产品无法符合企业需要，并在实施过程中花费更多的人力物力去修 正前面的错误，一些根本性的错误很可能导致最后系统的失败。 5 电子科技大学硕士学位论文 2 3 模型驱动架构介绍 2 3 1 模型驱动思想的由来 软件开发经济可行性取决于在何种程度上开发出质量和全寿命期同软件的开 发成本相对应的系统。在这里，将质量、全寿命期、开发成本称为软件开发的可 行性变量。仅调整可行变量的一个，而不考虑这个变量对其余变量的影响，很难 提高整个软件项目的可行性，为了提高经济可行性，必须降低生产成本，而不牺 牲软件的质量或全寿命期。 纵观软件产业的每次发展和进步，总会出现新的方法来替代或者补充已经存 在的方法，这些方法一开始很缓慢，然后势头越来越猛。这些方法推动质量、全 寿命期和生产成本达到新的平衡点。 ( 1 ) 以机器为中心的计算 早期的程序员以0 和l 书写计算机指令，把本地c u p 使用的指令的比特模式 写出来但是对于某些需要计算机执行快速计算的应用来说这种编码方式在经济 上是可取的。它同时还允许程序员优化可用的内存和处理器速度。但是，这种编 码方式天生就代价高昂，再加上高硬件成本，极大地制约了可计算的任务的数量。 汇编语言的出现延长了以机器为中心的计算方法的寿命。汇编语言允许程序 员使用简单的助记符来表示计算机所能理解的本地指令。用汇编语言编写的程序 对于构成本地指令的0 和l 模式的改变也不太敏感【2 1 。 ( 2 ) 以应用为中心的计算 汇编程序的成功指明了通向以应用为中心的世界的道路。在那个世界中，更 为复杂的应用程序在解决更为广泛的业务问题，这样的问题可能伴随着多个步骤、 更复杂的数据结构、更复杂的人机界面。但是，对更复杂的计算的需求，就在经 济可行性上给“以机器为中心 的计算方式带来了极大压力。汇编语言程序员虽 然不再需要同无聊的0 和l 打交道，但是他们还是用处理器本地指令集来编程【2 】。 第三代编程语言( 3 g l ) 的出现使得生产力出现了飞跃。开发者可以用比汇编更 高层次的结构来编程。第三代编程语言简单指令代替了几十行甚至上百行汇编代 6 第二章基于模型驱动架构的综述 码，这极大地提高了程序员的生产率，从而降低了生产成本。而且，这使得某些 业务分析人员也可以从事编程工作。第三代编程语言使所有3 个可行性变量都朝 正确的方向做出了改变。面向对象语言出现克服了第三代编程语言在某些方面的 不足，适应了满足更为复杂用户需求，为用户在最短的时间创造更大价值的发展 趋势。面向对象语言延长了以应用为中心的计算的生存期。s m a l l t a l k ，j a v a 和c 撑 是这类语言的主要例子。 ( 3 ) 以企业为中心的计算 随着时间的推移，人们对计算所能实现的自动化程度的期望越来越高。人们 已经不再满足于在企业内部建立自动化的“孤岛”。这些“孤岛 有重叠的功能， 这造成了重复的信息，而且将稀缺资源多次用于解决同一问题。因此，有必要在 企业内将这些“孤岛 连接整合。 软件界先后提出了基于组件开发、分布式计算、中间件、说明性规约、企业 构架、企业应用集成、契约式设计等等不同的方法，并且一些己付诸实践，不论 采用何种方法，无不期望能够在整合企业内部这些“孤岛方面有所作为，然而 事实上这些方法在某些方面比较有效，但还不能够从根本上解决软件开发过程所 出现的问题【3 1 。 ( 4 ) 以模型驱动为中心的计算 人们从未停止探索新方法以从根本上解决目前软件在开发的过程中所存在的 问题。对象管理组织o m g 在这方面做了有效的尝试。它于2 0 0 1 年7 月推出了基 于模型驱动的方法m o d e ld r i v e na r c h i t e c t u r e ( m d a ) t 4 1 。使用m d a 的方法可以为 业务功能建立相应的“模型，并允许通过相应的映射关系，将相同的模型映射到 不同的多个平台，允许不同的系统的集成和互操作，支持所开发的系统随着技术 的发展而演变。作为将以企业为中心一系列技术整合在一起的开发方法，m d a 的出现在更大程度上提升了软件开发的抽象层次，增强了软件的可移植性、协同 工作能力和可维护性，提高了软件开发的效率，有助于维持软件产品的质量、全 寿命期、生产成本的平衡。因此有专家预言m d a 将为未来两年里最重要的方法 学【1 1 。 7 电子科技大学硕士学位论文 2 3 2 模型驱动架构的基本原理 2 3 2 1m d a 架构 在m d a 中软件开发过程是由软件系统的建模行为驱动的。m d a 生命周期和 传统生命周期没有大的不同 5 1 ，主要的区别在于开发过程创建的工件。m d a 开 发过程包括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 ，平台无关模型1 、p s m ( p l a t f o r m s p e c i f i cm o d e l ，平台相关模型) 和代码【6 】。p i m 是具有高抽象层次、独立任何实现 技术的模型。p i m 被转换为一个或多个p s m 。p s m 是为某种特定实现技术量身 定做的。例如，e j bp s m 是用e j b 结构表达的系统模型。开发的最后一步是把每 个p s m 转换为代码，p s m 同应用技术密切相关。传统的开发过程从模型到模型 的转换，或者从模型到代码的转换是手工完成的。但是m d a 的转换都是由工具 自动完成的。从p i m 到p s m ，再从p s m 到代码都可以由工具实现【7 】。 p i m 、p s m 和c o d e 模型被作为软件开发生命周期中的设计工件，在传统的 开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不 同的视角来看待我们的系统，将高层次的p i m 转换到p s m 的能力提升了抽象的 层次。能够使得开发人员更加清晰地了解系统的整个架构，而不会被具体的实现 技术所“污染 ，同时对于复杂系统，也减少了开发人员的工作量。 o m g 的构想是将目前的开发行为提升到更高的抽象层级一分析模型级，把 针对特定计算平台的编码工作交由机器自动完成【8 】，这样的情况下，业务逻辑与 实现技术被成功地解藕，二者相对独立变化，因此模型的价值在包容己有技术的 条件下被最大化。这种目的根源在于软件开发的现状，在传统的软件开发方法中， 随着项目的进展，设计阶段产生的u m l 模型和代码之间的同步变得越来越困难 一代码为了应付新增加的需求和新产生的想法而不断变化，模型却一直停留在原 地不动，这使的模型在一段时间之后就失去了它的价值。 o m g 提出了一个最根本的解决方案一在m d a 中，模型不再是一种辅助工 具，而是开发过程的产品。一个完整的m d a 应用包含：一个权威的p i m ；一个 或者多个p s m ；一个或者多个完整的实现，即开发人员决定支持的所有平台上的 8 第二章基于模型驱动架构的综述 应用程序实现9 1 。 2 3 2 2 可重用的模型转换 m d a 的开发过程可能看起来和传统的软件开发过程很相似。但是，其中有 一个非常关键的不同之处。在传统的软件开发过程中，从模型到模型的转换，或 者从模型到代码的转换主要是开发人员手工完成的。许多工具虽然可以生成一些 代码，但是通常生成的代码也只是一些模版代码。其中主要编码工作仍然是要手 工完成。 与之相对的，而在m d a 中，转换是由工具自动完成的。如下图2 1 如示。 许多工具能够直接从p s m 来生成代码，这也是原来已有的代码生成工具已经具有 的功能。既然p s m 已经非常接近代码了，所以这一步的转换并不是什么创新。在 m d a 中新的东西是，从p i m 自动地转换到p s m 。这是m d a 明显的好处。 转换 亘卜 转换 工具工具 图2 - 1m d a 的模型转换过程示意图 自动模型转换最大的好处就是其可重用性。前文提到过，应用m d a 的开发 方法开发第一个应用程序的时候，与传统的开发方法相比，并不会节省很多开发 时间。但是在后继开发相同平台应用程序的时候，就可以节省大量的开发时间。 2 3 3 国内外研究现状 多年来，计算机领域的科学家、工程技术人员都在不断探索能够控制软件复杂 性的开发机制，以降低开发成本、提高软件生产效率、增加软件的可重用性以及 改善软件可维护性等，推出了许多为软件复杂性问题的解决方案的软件开发模型。 传统的面向过程模型和结构化程序设计虽然是相当优秀的软件开发模型，但其由 于对现实世界的描述与客观自然相去较远，其发展已渡过了鼎盛时期。 而八九十年代迅速发展的面向对象的方法则越来越显示出其生命力，8 0 年代 9 电子科技大学硕士学位论文 末，o m g ( o b j e c tm a n a g e m e n tg r o u p - - o m g 是定义、发布对象互操作等各种技术 的工业联盟组织) 提出u m l ，并最终统一为大众所接受的标准建模语言。但目前在 国内外就u m l 的运用情况却不是很好。 在这种背景下，o m g 提出模型驱动架构m o d e ld r i v e na r c h i t e c t u r e ( 以下简称 m d a ) 概念，它支持软件设计和模型的可视化、存储和交换f i o 】。m d a 分离了业务 功能分析设计与实现技术之间紧密耦合的关系，从而使技术变化对系统的影响最 小。从宏观看，m d a 使得应用模型与领域模型在整个软件生命周期中得到了复用。 m d a 核心思想是抽象出与实现技术无关、完整描述业务功能的核心模型平台 无关模型( p l a t f o r m i n d e p e n d e n tm o d e l ，以下简称pi m ) ，对不同实现技术制订多 个映射规则，然后通过这些映射规则及辅助工具将pi m 转换成与具体实现技术相 关的应用模型平台相关模型( p l a t f o r m s p e c i f i cm o d e l ，以下简称p s m ) ，最后 将经过充实的p s m 转换成代码。 虽然m o g 组织在2 0 0 1 年就已经提出了m d a 的概念，但是国内真正开始了 解m d a 还是近一两年的事情，相关研究更是起步很晚。 m d a 还存在很多需要完善的地方，但随着人们对其越来越重视，支持m d a 的各项技术逐渐完备，可互操作、可用、轻便的软件组件、基于标准的数据模型 发展的成熟，m d a 技术会更趋于成熟在更大程度保证开发质量，改进开发效率。 2 4 模型驱动方式与传统设计方式的比较 传统开发方法，如面向过程的y o u r d o n 法、面向数据的j a c k s o n 法，只适合 在软件开发的后期阶段使用( 如详细设计、编码阶段) ，而m d a 是一种面向模型的 开发方法【l l 】，将系统的业务功能信息从特定的技术实现中分离，它适用于软件开 发任何阶段，尤其适用于软件开发的早期，即系统设计阶段。我们可以通过一个 图表来详细的对比一下传统设计方式和模型驱动方式的不同 1 2 1 ，如表2 - 1 所示。 1 0 第二章基于模型驱动架构的综述 表2 1 传统设计方式开发和模型驱动方式开发的比较 传统设计模型驱动对比分析 方式开发方式开发 开发关注点着眼代码关注模型这种改变使得开发工作得到进一步细 分，一些人员可以将精力集中在平台无 关模型的开发上，不需要考虑代码实现 等技术细节。 迭代过程手工完成利用工具在需求发生变更之后，后者只需要变更 自动完成模型并导出实例，就可以实现开发过程 中的快速迭代。 后期维护需要维护只需维护传统开发方法中，维护人员需要了解整 整个系统业务模型个系统的代码结构和技术细节，才能对 的代码需求的变更做出反应；而模型驱动开发 方法只要导出新的模型实例即可。 2 5 本章小结 本章首先阐述了当前企业信息化存在的问题，由此提出了一种新的开发方式， 模型驱动方式的开发。分析了国内外研究现状，阐述了m d a 的基本概念，并对 传统开发方式和模型驱动方式做出了比较，基于模型驱动架构的开发方法更适合 于企业信息化的构建。 电子科技大学硕士学位论文 3 1 模型与元模型 第三章可执行模型的研究 模型是现实世界中的某些事物的一种抽象表示。因此，模型既反映事物的原 型，不完全等于该原型。模型是理解、分析、开发或改造事物原型的一种常用手 段。 元模型是描述模型的语言。在最宽泛的意义上，一个元模型是一个建模语言 的模型，如u m l 或某个特定领域的建模语言的模型。术语“元”意味着超越或 者上面的意思，它强调了一个元模型在一个比模型语言本身更高的抽象层次描述 一个建模语言。 一个元模型也是一个模型，它有两个主要特征。首先，它必须能够捕捉被建 模的模型基本特征和属性。因此，一个元模型应该有能力描述被建模语言的表面 语法、抽象语法和语义。其次，一个元模型一定是一个元模型架构的一部分。我 们能用元模型描述合法的模型，正如一个编程语言的程序被正确解析一样，一个 元模型架构使得一个元模型能被看作是一个模型，元模型自己能被另外一个元模 型描述。这允许所有的元模型能通过一个独立的元模型描述。这个独立的元模型 有时被称谓元元模型( m e t a - m e t am o d e l ) ，也就是描述元模型的语言元建模语 言，这个独立的元模型是元建模的关键，因为它能使得所有的建模语言都能以统 一的方式被描述。 元模型、模型和实例都是以实例化为基础的相对概念，其关键是在不同层次 的类和对象间的实例化的关系，一个类可以被实例化建立一个对象，这个对象是 这个类的实例；一个类也可以是一个对象的子类，即一个类能被另外一个类( 元 类) 实例化。图3 1 说明了之间的关系。 1 2 第三章可执行模型的研究 i 元一元模型 i 元模型 i 模型 i 用户对象 图3 1 元模型、模型和实例之间的关系 这四个层次中，除元一元模型外，每一层都是上一层的实例。 在m d a 标准中，一个模型是对一个系统的功能、行为、性能以及系统结构 等因素的描述或表示，是对系统的功能、行为、性能以及系统结构等因素的形式 化的规约。换句话说，模型是以精确定义的语言系统( 或系统中的一部分) 做出 的描述。 首先，模型是一种系统规约，这种规约可以是对结构的规约也可以是对系统 功能和系统行为的规约；其次，这种规约必须是正式的，即必须使用一种严格定 义没有歧异的语言。所以一个模型必须和一种严格定义了语法和语义的建模语言 绑定在一起。根据模型的这种定义，程序代码也是模型。通常模型以图表或文本 来表现，表现模型的文本可以是模型语言，也可是自然语言，图3 - 2 描述了模型 和它描述的系统、表述它的语言三者之间的关系。 图3 - 2 模型、语言和系统 1 3 电子科技大学硕士学位论文 3 2m d a 规范描述及其问题 3 2 1u m l 元模型概述 u m l ( u n i f i e dm o d e l i n gl a n g u a g e ，统一建模语言) 由许多不同的面向对象方法 学的符号组成，它们能够在开发周期的不同阶段对不同的软件系统视图建模。系 统的静态和动态方面都能被捕捉，并且也提供了模型管理设施和有限的扩展设施。 如用于对模型的状态空间进行更加复杂关系约束的对象约束语言( o b j e c t c o n s t r a i n tl a n g u a g e ，o c l ) n 3 1 。u m l 已经得到了广泛的认同并且已经是事实的软 件建模语言。 3 2 2u m l 元模型的问题 ( 1 ) 不精确的语义 u m l1 x 规范在提供精确的语义方面有缺点。u m l 的表面语法大多数都有着 良好的定义。但是，这些表面语法元素的语义或者是没有、或者采用了非正式英 语的描述。采用一个非正式方法来规定模型语言的语义将会导致开发者和使用者 对模型错误的理解以及由此带来错误的使用，所以没有任何一个工具能宣称是 u m l 兼容的。同样，新发布的u m l 2 0 t 1 4 】在语义上也没有本质的改进。 ( 2 ) 受限的范围和灵活性 u m l 已经成功地应用于软件开发，并且它正日益被应用于非软件领域，如系 统工程和特定软件领域，如实时系统开发。由于各种各样的广泛应用带来的建模 需求，一个统一建模语言应当定义成什么样是一个值得考虑的问题。早期为了增 强u m l 支持新的建模需求，u m l 不断地被修改和添加，包括对u m l 自身庞大 的定义进行修改，这导致u m l 变得日益巨大，难于使用，难于理解和难于移植。 为了克服这些问题，u m l 从一个适应所有应用的建模语言被重构到一个语言家 族。这个u m l 家族的基础是一个稳定的核心u m l 元模型( u m l 2 0 中称为u m l 底层组织，u m l2 0i n f r a s t r u c t u r e ) ，包括基本的建模概念集合，这些概念被所有 1 4 第三章可执行模型的研究 的家族成员支持。每一个u m l 的方言由u m l 元模型和一个或多个对这个元模型 的扩展( 叫做p r o f i l e s ) 组成。这个扩展机制是相当直接、简单的应用，但是由于 基于存在的语言构件基础而不是编辑或添加新的语言构件，因此模型的扩展受到 了限制。为了进一步赋予建模者根据自己需要建立自己的语言的能力，o m g 通 过定义m o f2 0 重用u m l 底层构件克服了u m l 的不灵活问题。 ( 3 ) 不可执行 u m l 本身是不可执行的，因此一个由u m l 建立的模型也是不能被执行的。 u m l 仅仅定义了任何可执行程序必须遵守的规范，但是它定义模型是不可执行的 或从它定义的模型不能产生可执行的代码，而这些又是一个建模者在一个模型应 用中最想要得到的。因此，在1 9 9 8 年，o m g 发布了一个r f p ( r e q u e s tf o r p r o p o s a l ) 请求一个行为语义( a c t i o n s e m a n t i c s ，a s ，目前已经被集成在u m l2 0 内) 标准 用于描述执行行为。但是和u m l 一样，这个行为语义为了定义普遍的适应性， 所以非常庞大而且其语义的定义仍不够精确。 ( 4 ) o c l 作为行为语言的不足 o c l 对于一些模型来说是完全充分有效的，我们也强烈推荐在合适的地方使 用它。但在模型中，经常需要包括一些抽象的算法描述来确保模型的可执行性【1 5 1 。 例如：一个前置状态中的集合，在后置状态中要求集合进行降序排列。一种实现 可能是在前置状态中建立所有可能的有序集合，在后置状态中选择被排序的集合 序列，但这种实现在实际系统中是难于实现的。 其次，o c l 仅仅只是描述了系统的静态模型和模型元素之间的关联。它没有 对许多对象标准行为进行抽象，例如：对于信号的发送，o c l 就没有对此行为进 行定义，所以o c l 不