（计算机应用技术专业论文）央行会计核算系统前台代码自动生成的研究与实现.pdf

摘要摘要央行会计核算系统( c e n t r a l b a n k a c c o u n t b o o k i n gs y s t e m 以下简写为a b s )是人民银行中心支行及其以上辖区内会计核算集中处理，并通过中国现代化支付系统连接，实现中央银行资金清算的计算机网络系统。u n i x 环境下的银行客户端软件，多年来一直存在着开发工作量大，重复度高和任务繁琐的问题，需要一种直观而简介的解决方案，很多专家为之付出了艰辛的努力。本文将元数据方案和模型驱动的理论进行结合，提出了一个基于模型驱动的前台代码自动生成的方法该方法将系统的业务设计和系统的具体实现基本分离，使两者处于松耦合关系，提高软件设计的复用性；代码自动生成工具通过在央行会计核算系统中的推广使用。取得比较好的效果，使得前台子系统的开发效率得到了数十倍的提高本文的代码自动生成是以模型驱动架构( 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 )为理论基础的。它是由o m g ( o b j e c tm a n a g e m e n tg r o u p ) 定义的一个软件开发框架。它可以应对于任何软件的开发，不用受到应用平台，开发语言等因素的影响。m d a 将软件系统的模型分离为平台无关模型p i m 和特定平台模型p s m ，同时又能通过转换规则将它们统一起来。p i m 模型在介于需求分析与设计之间，负责将需求转换为设计；而p s m 模型则是介于设计与编码之间，它的目的是将设计转换成代码由此看出m d a 贾穿了整个软件开发始末，它在软件开发中扮演了非常重要的角色。本文遵循m d a 的开发思路，从平台无关模型出发，结合模板方法，通过映射规则，产生能够直接编译运行的源代码。本文在m d a 的应用中，采取了较容易的实现m d a - l i g h t ，平台相关模型这一步可以说是被跳过了，直接从高度抽象的平台无关模型生成源代码。m d a 毕竟只是o m g 所定义的开发框架，虽说各大软件厂商都在着力研究基于m d a 的产品，不过目前为止还没有任何一个产品真正意义上的完全支持m d a 。本文所提出的代码自动生成技术是基于m d a 思想，不过它是针对于特定领域、特定模型、进行研究的。模型是m d a 的核心，同样是代码自动器的输入。我们采用自定义格式化文本来创建模型文档，直接易于使用。目前，整个代码自动生成工具系统己经完成，最先使用在a b s 开发之中，生成可在u n i x 平台下运行的c + + 源代码并且取得了不错的效果，实践表明该设计方案是可行的。不过代码自动生成技术仍不是非常完善，还需要进一步的调试与改进。关键词模型驱动：代码自动生成；平台无关模型；模板a b s t r a c ta b s t r a c tc e n t r a lb a n ka c c o u n tb o o k i n gs y s t e mi sac o m p u t e rn e t w o r ks y s t e mu s e dt oi m p l e m e n tt h ef u n ds e t t l e m e n to ft h ep e o p l e sb a n ko fc h i n a t h e r eh a v eb e e nm a n yp r o b l e m ss u c h 勰b i gd e v e l o p m e n tw o r k l o a d , m u c hr e p e t i t i v ew o r k , a n dc u m b e r s o m ew o r ki nb a n k i n gc l i e n tp r o g r a mu n d e ru n i xo p e r a t m gs y s t e mo v e ry e a r s m a n ye x p e r t sh a v ed o n eh a r de f f o r t st of i n daw a yt os o l v et h ep r o b l e m t h ea w a t l o rs u g g e s t sac o d eg e n e r a t i o nm e t h o db a s e do n i d a d a l aa n dm d a , w h i c hs e p a r a t e st h eb u s i n e s sd e s i g nf r o mt h er e a l t r a n gm e t h o da n dm a k e st h e ml o o s ec o u p l i n gr e l a t i o n t h u s t h em e t h o dm a k e si te a s yt o 瑶撇t h es o f l w 骶d e s i g n 。t h ec o d eg e n e r a t o rh a sb e e nu s e di nt h ea c c o u n tc e n t r a lb 0 0 k i n gs y s t e m , w h i c ha c h i e v e dg o o dr e s u l t s t h ec o d eg e n e r a t o rh a sm u c hi m p r o v e dt h ee f f i c i e n c yo fs o f t w a r ep r o d 啦t h ec o d eg e n e r a t o ri sb a s e do nt h ei d e ao f m o d e ld r i v e n a r c h i t e c t u r e ( m a d )i nt h i s 彤i p e r m d ai sas o 觚t a l ed e v e l o p m e n tf r a m e w o r kd e f i n e db yt h eo b j e c tm a n a g e m e n tg r o u p ( o m o ) ，w h i c hc a na d a p ti t s e l f t od e v e l o pa n ys o f t w a r en o tb e i n ga f f e c t e db ys u c he l e m e n t sa sa p p l i c a t i o np l a t f o r m sa n dd e v e l o p m e n th n g u a g e s s o f t w a r es y s t e mm o d e l sc a nb ed i v i d e di n t op i m , p s m a tt h es a m et i m e ,m d ac a nu n i f yt h e mt h r o u g ht h et r a n s f o r m a t i o nr u l e s p i mi nt h er a n g eb 目h v e e nr e q u i r e m e n ta n a l y s i sa n dd e s i g nw i l lb er e s p o n s i b l ef o rt h ec o n v e r s i o nf t o mr e q u i r e m e n tt od e s i g n ；a n dp s ml i e sb e l 3 v e e nd e s i g na n dc o d m g ，w h i c hi sd e s i g n e dt oc o n v e r s ed e s i g nt oc o d e m d al 由a c e st h r o u g h o u tt h ee n t i r es o r w a r ed e v e l o p m e n tp i o c 冶s s ，p l a y i n gav e r yi m p o r t a n tr o l ei ni t i nt h i sp a l e r 9w ed e v e l o ps o f t w a r ef o l l o w i n gt h ei d e ao fm d a w ec 缸a t o m i c a l l yg e n e r a t ee x e c u t a b l es o u i v 君c o d ef r o mp i mc o m b i n i n gt e m p l a t ea n dm a p p i n gr u l e s t h eu s eo fm d ai nt h i sp a p e r ，w ei m p l e m e n ti ti na l le a s i e rw a y ：m d a - l i g h t , w h i c hg e n e r a t e ss o u f c ec o d ef r o mp i md i r e c t l ye u d m gp s m t h eo m g sd e f i n i t i o no fm d ai sj u s tt h ed e v e l o p m e n tf r a m e w o r k a l t h o u g ht h em a j o rm a n u f a c t u r e r sh a v em a d eg r e a te f f o r t st os t u d yt h eb a s e do nm d as o r w a r ep r o d u c t s b u ts of a rt h e r ei sn or e a ls a 嘶o f ap r o d u c t sf u l ls u p p o r tm d a a u t o m a t i cc o d eg e n e r a t i o na u t h o r si d e o l o g yi sb a s e d 伽t h em d a , b u ti t i st a r g e t e dt o w a r ds p e c i f i ca r e a s , s p e c i f i cm o d e lu n d e rs p e c i f i cj a n l ；i l a g es t u d y m o d e li st h ec o 心o fm d a a n di ti st h ei n p u to ft h ec o d eg e n e r a t o ra sw e l l w ed e f i n em o d e ld o c u m e n t si no l u o w nw a y , w h i c ha r ee a s i l yu s e d c u r r e n t l y , t h ea u t o m a t i cc o d eg e n e r a t i o nt o o lh a sb e e nc o m p l e t e d , a n di tw a sm北京工业大学工学硕士学位论文i m p l i c a t e di na b sd e v e l o p m e n t , a t o m i c a l l yg e n e r a t i n ge x c i t a b l ec + + s o u r c o d er u n n i n gi nu n i x ，a n da c h i e v e dg o o dr e s u l t s p r d c t i c ep r o v e st h a tt h ed e s i g ni sf e a s i b l ea n dr e l i a b l e b u ta u t o m a t i cc o d eg e n e r a t i o nt e c h n o l o g yi sn o tp e r f e c t , s t i l ln e e df u l t h g rt e s t i n ga n di m p r o v e m e n t k e y w o r d sm d a ；a u t o m a t i cc o d eg e n e r a t i o n ；f i m ；t e m p l e s独创性声明本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均己在论文中作了明确的说明并表示了谢意。签名：地至日期：超生：! 三关于论文使用授权的说明本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有权保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部分内容，可以采用影印、缩印或其他复制手段保存论文。( 保密的论文在解密后应遵守此规定)第1 章绪论第1 章绪论1 1 论文的研究背景及意义1 1 1 课题的提出中国人民银行会计核算的信息化改造已经进行了很多年，由于行业自身的特殊性，其基本的软件应用环境并没随着计算机、互联网的发展而有根本性的变化。目前银行核心应用软件仍然建立在u n i x 环境下，基本的软件体系结构仍然是c s 结构。软件的开发方法也没有根本性的变化，很多的软件开发商仍然采用了基本的c 或c h 的程序语言进行开发，使缛银行会计核心应用软件的开发效率依然没有大的提高，特别是在人机界面和业务流程程序的开发上。而银行行业应用软件具有界面丰富、业务规则变化快、新业务的增长比较快的特点，繁琐的人机界面和业务流程程序的开发己经越来越不能适应业务发展的需要。a b s 包含大量的用户界面和打印输出的账表，输出格式复杂，数据变化大但是其实现有一定的相似性，整个过程包含大量的重复劳动；如果能够定义一个抽象的、独立于任何技术的模型，再通过代码生成器生成相关代码，那么这将会使编程人员从繁复的代码中解放出来。使得设计开发人员能够专注于业务逻辑的设计，不需要疲于奔命于掌握日新月异的新技术、新平台：软件产品的生产和其他商品的生产一样都有一套工厂化的生产模式，产品质量、生产工期等一切都在掌控之中，不会由于需求变更、软件质量低下或新技术使用等等传统软件开发问题的产生而导致产品的不合格或不能按时交货。o m g ( o b j e c tm a n a g e m e n tg r o u p ) 组织提出m d a 能够解决以上问题。o m g 提出，一个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 ) 开始，然后使用相应的m d a 工具，结合具体技术，将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 ，使用代码自动生成器，自动生成大部分的特定平台上的应用程序代码。m d a 分离业务模型与实现技术之间的耦合的关系，最小化技术变化对系统的影响。模型在软件开发过程中扮演非常重要的角色。在m d a 中，软件开发过程是对软件系统的建模行为驱动的【“。当前基于模型驱动的软件开发方法日渐得到企业界的承认，一该方法也已经应用到界面开发中；近十年来，界面设计和系统功能设计的分离成为一种趋势，界面代码根据界面描述模型来自动生成已成为开发人员的目标北京工业大学工学硕士学位论文另外，传统的代码生成方法是面向业务过程的，根据业务过程编写代码；m d a 的代码生成方法是面向业务模型的，针对同一业务模型进行不同的技术实现。因此，研究代码生成器有其现实意义。1 1 2 模型驱动架构的提出近年来，中间件技术蓬勃发展，它带给应用系统的不仅是开发周期的缩短，系统维护、运行和管理工作量的减少，而且还减少了资金的投入。中间件的本意是要屏蔽不同厂商产品之间的差异，但随之而来的新问题却把人们搞得焦头烂额。常见的诸如c o r b a 、e j b 、c o m + 、n e t 等中间件技术，它们之间不能相互兼容，要使它们之间建立联系需要耗费大量的精力和财力。例如，一个大型企业的应用软件可能建立在不同的中间件平台上，而跨平台的应用软件之间的集成将耗资巨大。为了解决需求、文档以及异构系统的集成和互操作等闯题，同时将现有的新技术或趋势以全新方式融合在一起，对象管理组织模型驱动构架m d a 的关键之处就是将模型作为软件开发的核心制品，严格区分系统的功能规约与实现细节【2 j 。在m d a 中，软件开发过程是由对软件系统的建模行为驱动的。它把建模语言当作编程语言而不仅仅是设计语言。它能够创建出机器可读和高度抽象的业务模型，这些模型以独立于实现的技术开发，以标准化的方式存储，然后根据不同的平台，对业务模型进行模型编译，生成相应平台的实现模型。这样就分离了传统的业务模型和平台相关的实现模型，从而摆脱了对技术平台的依赖。1 1 3m d a 自动生成工具研究现状代码生成技术不是一项新兴的技术，近些年来，对于代码生成技术，国际上有专门的项目或机构在进行研究，国内的研究也在兴起，而且，国内有不少公司将该技术应用于开发过程中取得了很好的效果，同时对传统的开发过程产生了不小的冲击。但是，就在各种技术大显身手的同时，可扩展性、可移植性、可维护性等等一系列的问题暴露出来。问题的解决不但要靠技术手段，而且还要靠建立各软件厂商共同遵守的行为规范。因此，软件业的o m g 组织提出了l v l d a ，希望在一个更高的抽象层次上解决问题，通过更抽象的高层描述，整合现有的诸多技术和方法；与此同时，一些支持m d a 实现的技术手段不断提出，如x m i ( m e t a - d a t a i n t e r c h a n g e ，x m l 元数据交换标准) 、q v t 等等。虽然m d a 在分布式和嵌入式系统中已初见端倪，但目前对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 - 1 - 具，它声称是第第1 章绪论一个完全支持m d a 方法的工具。诸如此类的产品还有i n t e r a c t i v eo b j e c t s 公司的a r c s t y l e r , t o g e t h c r s o f i 公司的t o g e t h e rc o n t r o l c c n t c r , c o m p u w a r e 公司的o p t i m a u ，国内楚凡公司的t r u f u n k a n t 等等，其中o p t i m a l 和a r e s t y l c r 是目前开发j 2 e e 平台的首选。国内e r p 软件领袖企业之一的金蝶软件也声称在其b o s 系统中成功地应用了m d a 的思想。因此毫无疑问m d a 将成为未来软件开发的必然趋势 3 1 。现存的工具提供了大量的解决方案，如a t e s t y l e r ，它是实现m d a 较好的一种工具，提供了从p i m 到p s m 转换和从p s m 到代码的转换：但是，如果想把它的方案和我们己有的系统进行集成，就会遇到很多困难。m d a 毕竟只是o m g 所定义的开发框架，虽说各大软件厂商都在着力研究基于m d a 的产品，不过目前为止还没有任何一个产品真正意义上的完全支持m d a 。m d a 在不断发展和完善之中，如u m l 以( u n i l i c dm o d e l i n gl 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 ，元对象设施) 都在推出新的版本。为了适应这些变化，追踪国际先进技术，必须研制自己的代码生成器，这也意味着可以根据自己的设计，将代码生成系统集成到自己的软件开发周期中去。1 1 4 课题意义本文将模型驱动的思想用于前台子系统的开发中，根据系统本身特点研发了支持m d a 的自动生成工具。该自动生成工具是针对比较局限的领域而言的，即需求已经被正确的理解并由人转化为解决方案领域中的抽象模型，即平台无关模型，将此作为代码生成器的输入。将模型和程序模板结合，将具体的业务模型映射成应用程序源代码，从而实现快速开发系统。使得开发重点集中到模型的创建，模型驱动整个开发的过程。自动生成技术意义在于：一是快速生成原型，就是说根据需求快速的实现用户的功能，构建出原型系统，并且在原型系统基础上进行开发。二是随需应变的功能，一旦客户的需求变更，能够很及时的应对。三是保持代码风格的统一，因为代码的好坏直接影响系统的功能实现，代码自动生成技术就是保证每个程序员都能写出高质量的代码。代码自动生成技术给技术人员带来的好处是：开发不再需要从零开始，可以利用代码生成技术去生成代码。技术人员可以从重复的编码工作中解放出来，把精力放在理解客户需求上，开发出一个符合客户需求的软件。1 2 主要研究工作本课题来源于中国人民银行会计核算系统，将模型驱动设计思想应用到该北京工业大学工学硕士学位论文系统前台子系统设计中，抽象出前台实现模型，并基于该模型文档，自动生成前台子系统可直接运行源代码及配置脚本。将系统设计与具体技术分离，提升了软件开发的抽象层次，提高软件开发的效率。课题的研究过程主要作了以下工作。( 1 ) 对自动生成的基本原理和模型驱动思想相关理论进行研究。( 2 ) 对a b s 业务流程深入研究，分析前台子系统功能需求，实现逻辑，由此设计前台模型。( 3 ) 用于代码生成的元数据的定义方法的研究。( 4 ) 代码生成映射方法的研究。本文采用系统模型结合程序模板库和映射规则库自动生成的方法。，( 5 ) 代码生成的模板定义方法。1 3 论文组织结构本文共分六个部分，第一部分引入课题并对课题的研究背景、意义以及国内外相关研究进行了综述。第二部分阐述了模型驱动的代码自动生成工具实现的理论及方法。第三部分对央行会计核算系统作了概况介绍。第四部分对央行会计核算系统前台系统进行分析提出模型驱动自动生成前台系统的方法，介绍自动生成工具的总体设计与模块详细设计。第五部分给出了代码生成工具使用实例，阐明代码自动生成工具的使用方法及带来效率。第六部分为文章的结束语，总结了本文所做的工作和下一步需要完善的工作。第2 章模型驱动的代码自动生成第2 章模型驱动的代码自动生成代码自动生成的研究已经经历了一段时间。起初，这一思想提出的主要原因是应用系统的规模越来越大，其中存在大量的重复性代码模块，使得编写与维护的工作量很大。但是随着软件体系结构与设计模式的研究与发展，以及它们在应用系统开发中所发挥的作用，在一定程度上减少了设计开发中重复代码过多这一问题的影响。随着软件工程的进一步发展，对软件开发提出了更高的要求。目前软件开发平台多样，应用软件系统需求变化性强。因此，近年来出现了对模型驱动架构( m d a ) 的研究，提出了模型化系统设计，以提高软件开发抽象层次以及代码自动生成的工程实现。本文将模型驱动思想应用到央行会计核算系统前台代码自动生成中。2 1 代码自动生成2 1 1 领域工程从根本上说，实际项目中采用代码自动生成技术并不是凭空而生的。其基本的理论依据是项目的领域工程。有关领域工程的详细内容可参见文献 4 】。项目的域分析有时候会导致代码生成器的开发和使用领域工程( d o m a i ne n g 毓g ) 创建一组相似系统应用工程的过程。是一种软件设计规程，注重对业务( 一个领域) 的抽象，形成软件系统族，目的是实现设计和工件的复用。领域工程覆盖了所有构建软件核心价值的活动。领域工程包括领域分析、领域设计和领域实现。在整个领域应用范围中，各个应用之间存在着相同点和不同点这些称之为共性和可变性【卯共性是指在领域工程期间关于什么是整个域的共同性问题所做出的决策或假设。共性可以确定域的范围、软件的功能、与其它域的分界面、操作环境、软件的限制、标准以及应用软件公共部分实现的细节。共性的重要性在于它说明了一个应用程序族中什么是共同的或共享的。它代表着正在被使用的。域知识”。这种域知识可以被分析并封装成工具、组件、模板、模式以及框架等等。而可变性是一个需要在域分析期间确认，而直到构建或运行时间才确认的决策。可变性代表了一个应用程序族内部之间的差别。构建时的可变性集合是为建立一个程序生成器所需要的信息中最重要的部分。这个集合可用于定义一个规范北京工业大学工学硕士学位论文语言和一个结构或框架。运行时的可变性则是在运行时间内确定的决策，这些信息包括配置文件、数据库、用户定制等等。可用于建立应用软件的公共部分。2 1 2 什么是代码自动生成传统意义上的代码生成，首先识别应用源代码中经常出现的重复性代码，然后自动生成这些重复部分来代替手工编写的目标代码。所谓目标代码，是指应用相关的系列产品，例如源程序，脚本等。如果没有代码生成工具，开发者将手工书写所有代码，虽然这样可以得到灵活性较高的产品，但是使用代码自动生成可以更加降低成本，减少出错率，使可靠性更强 6 1 。代码自动生成过程是分为模型建立、生成代码、运行代码三部分。这里的模型建立是针对那些特定的业务需求所建立的模型，而且这类模型代表了某种抽象意义的操作。第二部分是代码自动生成的过程。依靠先前建立的模型，输入相应的数据，最后产生代码。第三部分是代码运行的过程。光有代码是没有用的，还需要由运行框架来执行这些的代码。目前自动生成的代码是运行在一个特定的环境中，它主要由公共组件库构建而成。有了这个框架的好处在于减少生成不必要的代码。因为如果代码生成过多，对于将来的维护也是件十分困难的事情。代码自动生成是一种开发方法，而不仅仅是一个工具它的重点在于需求分析价段，因为模型往往在这个时候要被确定下来。前面提到了m d a ，它的重点也在于需求分析阶段，因为p i m 模型也是建立在需求分析基础上的。所以需求阶段也正是模型挖掘建立的时候。2 1 3 代码自动生成原理一个典型的代码生成的处理原理为：输入文件通过语法分析转换为输入文件的语法分析树，语法分析树再通过代码生成器的分析，转换成生成代码的语法分析树，这样代码书写器就可以通过生成代码的语法分析树获取输入文件的信息，生成所需要的代码川。图2 1 是一个代码自动生成的处理原理。语法分析器该语法分析器。解析读入文本格式的文件，并将代码按照可以让其他工具使用的模型形式保存在模型仓库l l 】。在这儿输入文件是描述业务模型文本文件。如果模型文本是x m l 格式，文件的语法分析可以直接采用x s l t 处理器中的语法分析器。而对于自定义文本文档，我们则需要使用专门的语法分析器解析自动生成工具的输入语法分析树第2 章模型驱动的代码自动生成图2 1 代码生成器的原理。f i g u r e2 - ! t h ep r i n c i p l eo f c o d eg e n e r a t o f创建语法分析树结构，将解析后的格式文件，提取信息存入语法分析树结构中。语法分析树的转换转换是按照变换定义从源到目标的自动生成。转换定义是一组变换规则，这些规则共同描述了用源语言表述的模型如何变换为用目标语言。代码书写器该生成器读入模型仓库中的代码产生代码以各种文件形式输出。2 1 4 代码自动生成的选择依据在实际的项目开发中决定使用代码生成器或者选择己有的代码生成器需要从以下的几方面来进行衡量。质量( q u a l i t y )是指生成代码的质量。在一个项目的开发周期中，由于软件工程师的编码能力的不同，手工编码会形成代码质量上的参差不齐。面使用代码生成器则可以在整个开发周期中提高代码质量，这是因为程序的许多b e g 可以通过修订代码模板来完善整个代码库。生成代码的质量直接影响到生成器的可用性闱。一致性( c o n s i s t e n c y )是指所设计的生成器的生成a p i 的类结构，变量命名以及方法签名是否容易保持其稳定性，从而使得软件设计人员可以在较高层次上进行使用，而不太需要考虑底层的变动。一致性决定了一个生成器向下的兼容性，是否设计得稳定可靠，北京工业大学工学硕士学位论文不会因为引入了生成器反而增加了系统的太多不确定性。效率( ( p r o d u c t i v i t y )是指生成器可以在多大程度上替代人工的编码工作能力。代码生成器可以节省大量的人工时间，可以使软件工程师尽可能避免烦琐的重复开发工作，从而可以把精力放在更需要创造性的任务当中。效率的大小决定了是否需要创建或选择生成器的决策。抽象性( a b s t r a c t i o n )是生成代码所具有的层次性，是否清晰，是否容易划分业务逻辑等能力，而不是将代码混作一团。代码生成器在软件的设计和代码基( c o d eb a s e ) 之间提供了一个抽象层。在实际的软件开发应用中，常常发现会比较容易陷入到代码的各种细节中，从而忽视了业务逻辑规则1 7 j 。生成器所产生的确定代码可以以一种明确的形式来保持这些业务模式和业务规则。同时，这些文件可以独立出来并且文档化。此外，这些代码和文件也可以被域专家检察和分析。抽象性使得生成代码可以运用其它的c a s e 技术来进行分析，例如可以导入到r a t i o nr o s e 中进行0 0分析等。有人认为代码生成是一种不好的设计观念，认为它其实是一种反模式( a n t i - p a t t e r n ) 9 1 。他们认为代码生成仅仅是另外一种形式上的拷贝一粘贴式的编程方式虽然从某种角度上来看的确如此，但相比拷贝- 粘贴而言它依然有着许多的可取之处。我们在编程实践中发现一些类似的功能模块或方法函数时，总会想着去某个地方把它拷贝粘贴过来，并做一些必要的更动。至此，这两处的代码其实己经失去了相关性的联系，虽然它们是很相似。通常拷贝粘贴的代码中如果发现有b u g ，就需要对所有拷贝粘贴的代码进行修订，这很容易遗漏和疏忽。而由一个设计良好的代码生成器所产生的代码则可以保持这些代码间的有机联系，从而比较容易的修正这些错误此外，在现代软件开发中，开发框架的应用越来越普遍，同时也越来越复杂，人们不得不加入更多的手工代码。这也导致了代码的复杂性，选择代码生成器可以降低复杂性再则，代码生成器用抽象的设计模型来产生代码，这种方式具有即使是最好的纯手工编制系统也很难具有的便利性和可维护性。如果需要业务规则写到代码中的话，最好就是将它们重构( r e f r a c t o r y ) 到独立的一层中【。事实上，如果使用代码生成器的理由并不充分和必要的话，就不应该使用它来生成大量的代码。一个良好设计和实现的生成器并不应该只用来替换眼前烦琐的代码编制，更应该从整个应用域的角度来考虑和设计1 1 1 1 第2 章模型驱动的代码自动生成2 2 模型驱动思想砌d a ( m o d e ld r i v e n a r c h i t e c t u r e ) 是模型驱动架构，它是由0 m g 定义的一个软件开发框架。它是一种基于u v 皿以及其他工业标准的框架。支持软件设计和模型的可视化、存储和交换。和i m ，相比，m d a 能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。m d a 把建模语言用作一种编程语言而不仅仅是设计语言。m d a 的关键之处是模型在软件开发中扮演了非常重要的角刨1 犁3 1 。m d a 源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，m d a 提供了一种途径( 通过相关的工具) 来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。m d a 的三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性【1 4 1 。在m d a 中软件开发过程是由软件系统的建模行为驱动的。图2 2 是m d a的软件开发周期。图2 - 2l 吼开发过程f i g u m2 - 2p r o c e s so f m d ad e v e l o p m e n tm d a 生命周期和传统生命周期没有大的不同，主要的区别在于开发过程创建的工件，包括p i m 、p s m 和代码删是具有高抽象层次、独立任何实现技术的模型p i m 被转换为一个或多个p s m ，p s m 是为某种特定实现技术量身定做。开发的最后一步是把每个p s m 变化为代码，p s m 同应用技术密切相关传统的开发过程从模型到模型的变换，或者从模型到代码的变换是手工完成的。但是m d a 的变换都是由工具自动完成的。从p i m 到p s m ，再从p s m 到代码都可以由工具实现【”p i m ，p s m ，和c o d e 模型被作为软件开发生命周期中的设计工件，在传统的开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不同的视角来看待m d a 的系统，将高层次的p i m 转换到p s m 的能力提升了抽象的层次。能够使得开发人员更加清晰地了解系统的整个架构，而不会被具体的实现技术所“污染”。同时对于复杂系统，也减少了开发人员的工作北京工业大学工学硕士学位论文量【1 5 】m d a 的出现，为提高软件开发效率，增强软件的可移植性、协同工作能力和可维护性，以及文档编制的便利性指明了解决之道。m d a 被面向对象技术界预言为未来两年里最重要的方法学。当今建模的主要问题在于，对于很多企业来说它只是纸面上的练习。这就造成了模型和代码不同步的问题，代码会被不断修改，而模型不会被更新，这样模型就失去了意义弥补建模和开发之间的鸿沟的关键就在于将建模变为开发的一个必不可少的部分。m d a 是模型驱动开发的框架，m d a 的前景是定义一种描述和创建系统的新的途径。m d a 使得u m l 的用途走得更远，而不仅仅是美丽的图画。很多专家预言m d a 有可能会带领这个行业进入软件开发的另一个黄金时代n 6 1 2 2 1m d a 框架m d a 将软件系统的模型分离为平台无关模型p i m 和特定平台模型p s m ，同时又能通过转换规则将它们统一起来，以这样的方式试图去摆脱需求变更所带来的困境。平台无关模型p i m 是对系统高层次的抽象，其中不包括任何与实现技术相关的信息；特定平台模型p s m 是特定平台相关的模型。在m d a 框架中，首先使用平台无关的建模语言来搭建平台无关的模型p i m ，然后根据特定平台和实现语言的映射规则，将p i m 转换以生成平台相关的模型p s m ，最终生成应用程序代码和测试框架。m d a 框架的“建筑材料”包括：高层次模型；一种或多种标准、精确定义的语言，用来编写高层次模型：如何把p i m 变换到p s m 的定义；编写这些定义的语言，这种语言能够被变换工具执行；能够执行变换定义的工具；能够执行p s m到代码的变换工具。图2 3 是m d a 的框架。它的主要元素有模型、p i m , p s m 、语言、变换、变换定义、以及变换工具。m d a 是一个开放的，中立于软件供应商的架构，它广阔地支持不同的应用领域和技术平台，能够成为应用领域和具体技术平台之间的杠杆。在m d a 开发途径中，p i m 代表对需求的建模，p s m 代表应用具体技术后的模型，这使得m d a 成为需求和技术之间的杠杆；它们各自的改交都可以是相互独立的，不会造成商业逻辑和实现技术的紧密藕合，同时m d a 又可以通过转换来弥补它们之间的鸿沟，从而保护了投资。m d a 开发途径使得系统能够灵活地被实现、集成、维护和测试，系统的轻便性、互操作性和可重用性都是可以长期保持的能够应对未来的变化。第2 章模型驱动的代码自动生成l 髑靴个l圈一一囤2 2 2m d a 基本概念图2 - 3 m d a 框架【i jf i g u r e2 - 3 也ef r a m e w o r ko f m d a( 1 ) 模型：是对现实存在实体的抽象和简化，是对系统的功能、结构、行为及其环境的描述和规约。首先，模型是一种系统规约。这种规约可以是对结构的规约也可以是对系统功能或系统行为的规约；其次，这种规约必须是正式的。即必须使用一种没有歧义的语言来严格定义。所以一个模型必须和一种严格定义了语法和语义的建模语言绑定在一起。在m d a 中，它要求模型必须用精确定义没有歧义的语言来描述，以便支持模型间的自动转换。而这种精确定义没有歧义的语言是具有严格的形式( 语法) 和含义( 语义) 的语言，以适合计算机自动解释。图2 4 描述了模型和它表述的系统、表述它的语言三者之间的关系。蛄图2 - 4 模型与语言f i g u r e2 - 4m o d e la n di i g l l a g c( 2 ) 抽象：从冯诺依曼发明了存储程序式计算机以来，抽象是入们解决计算机问题的最重要的方法，抽象在很多情况下可以理解成透明，即略去无关的细节。通过在软件开发中加强模型的作用来提升抽象高度，使系统模型在包括理解、设计、构建、部署、运行、维护、修改的整个软件开发的生命周期中起指导作用。不管i t 业如何发展，从目前的趋势来看将来不可能只存在一种编程语言、一种操作系统或一个中间件的理想环境。面对如此复杂的环境，为了能在变化多北京工业大学工学硕士学位论文端的环境中寻求稳定的解决方案，o m g 给出的答案就是抽象。它认为利用m d a可以得到更好的高层抽象设计架构，更好地得到针对今天各种语言的通用化代码( 3 ) 视角：就是根据不同的抽象层次去观察系统，使得到的模型更简单，设计人员的思想聚焦于他所关注的问题，而屏蔽过滤掉其余不关心的细节。m d a 指导的开发过程中最核心的部分就是把软件设计的复杂性分散到不同层面上，在每一个层面上只关心一类问题，使从简单性进化来的复杂性重新还原多个层次上，在每一个层面上只关心一类问题，使从简单性进化来的复杂性重新还原成多个层次上的简单性。由于在开发过程的不同时期关心的问题不同，就需要从不同的角度去观察系统，所以这些层次在m d a 中被称为视角。( 4 ) 模型驱动：模型驱动就是为了实现系统的目标，将系统划分为若干层级，在每一个层级上对相关对象进行建模并建立各层模型之间的映射关系，采用人工或计算机软件按照映射规则完成信息从一个层级向另一个层级之闯的转换，最终获得系统的目标结剿1 3 1 模型驱动的系统开发过程应具备以下4 个特征：开发过程主要是通过利用不同抽象层次的概念模型和多种视角来完成：它x c - v - 台无关模型p i m 和平台相关模型p s m 作出了清楚的区分；模型不仅在开发的初始阶段，而且在维护、复用以及进一步开发的过程中都扮演着基础性的重要角色；模型记录了各种模型间的关系，因而为模型的精化和转换提供了准确的基础( 5 ) 平台无关模型( p i m ) 与平台相关模型( p s m ) ：m d a 将软件系统的模型分为平台无关模型( p i m ) 和平台相关模型( p s m ) op i m 是对系统高层次的抽象，它是一个不带有任何特定技术细节并且与实现技术无关的业务模型。其中包括组织模型、功能模型、信息模型、流程模型等。而包括了特定技术细节并且与具体的实现技术相关的模型，就是p s m 。当然，在实际应用中很难为模型的平台无关性和平台相关性划分一个明确的界限。也就是说p i m 和p s m 是两个相对的概念。一个模型在特定环境中可以被看作与平台无关，但在另一特定环境又可以是平台相关的。当说某个模型或建模语言是平台独立的，往往要指明独立于什么样的平台，否则没有任何意义。因此在基于m d a 的开发中，可以说是把一个较为平台独立的模型变换为一个较为平台相关的模型。( 6 ) 模型映射：模型映射简单说就是模型转换，映射是将一个模型转换成另一个模型的一组规约和技术，它规定了源模型中的元素如何对应到目标模型中的元素。m d a 是由不同层次模型之间的映射技术所构成的，借助层问映射技术，上层模型经过一定的转换规则可以转换成多个不同的下层模型。m d a 模型的映射关系如图2 5 所示。第2 章模型驱动的代码自动生成图2 - 5m d a 中模型的映射关系f i g u r e2 - 5m a p p i n gr e l a t i o n s h i po f m d am o d e l s从上图可以看出，在m d a 中不同的模型之闻存在映射关系，p i m 可以通过一定的映射技术对自身进行完善，p i m 也可以通过转换工具自动地转换为p s m ，生成的p s m 既可以通过一定的映射进行自身的细化，也可以从p i m 中生成与具体实现技术无关的模型。具体来说，m d a 中存在以下4 种模型映射关系-p d “到p i m 的映射在软件开发过程中，开发人员会根据用户需求的不断变更或其它因素对p i m进行增强、过滤或细化，以便它能够更加精确地描述系统。例如从分析模型到设计模型的转换。p i m 到p s m 的映射该映射是从业务模型转换到与具体实现技术相关的应用模型。在m d a 的实际应用中，根据不同的实现技术或平台通常一个p i m 会对应多个p s m 。例如从逻辑的组件模型到现实的商业组件模型。p s m 到p s m 的映射该映射是对p s m 模型的精化，用来精练构件实现和部署过程中相关模型间的关系，以便生成质量更高的代码。比如e j b 组件中具体服务的选择和属性配置。p s m 到p i m 的映射p s m 到p i m 的映射过程类似逆向工程操作，主要是从现有的应用模型p s m中提取与平台无关的模型信息，通常难以自动实现；传统上，从模型到模型的变换，或者从模型到代码的变换，主要是手工完成的。与此相反，m d a 变换总是由工具执行的，许多工具可以把p s m 变换成代码，这并不令人惊奇。m d a 的创新之处是把p i m 到p s m 的变换也自动化了。p i m ,p s m , 和c o d e 模型被作为软件开发生命周期中的设计工件，在传统的开发方式中是文档和图表。重要的是，它们代表了对系统不同层次的抽象，从不同的视角来看待我们的系统，将高层次的p i m 转换到p s m 的能力提升了抽象的层次。能够使得开