（计算机软件与理论专业论文）将遗留web应用系统转换为mvc结构研究.pdf

摘要 在许多公司内部，存在着使用多年、积累了丰富的数据，从过去到当前一直发挥着重 要作用的遗留系统。由于需求改变、平台升级以及新技术出现使得我们不得不对一些过去 证明是成功的遗留系统进行相应的升级改造以满足新形势要求，我们把这种升级改造工作 称为软件再工程。软件再工程提供了一条有效利用遗留系统的现实可行途径。 本文提出了一种软件再工程方案将既存的独立自主的j s p 应用系统( 遗留w e b 应用系 统) 转换为基于) ( m l x s l t 的m v c 结构的系统( 新系统) 。 本文首先介绍了j 2 e e 、w e b 应用软件设计模式、软件再工程的基本技术和方法。进而 在分析了目前国内外相关研究成果的基础上，提出了采用半自动方式的软件再工程方案， 并介绍了该方案的实施方法。最后以电子商务的购物车模块为例，按所设计的方案执行转 换。 关键词：m v c 、w e b 、遗留系统、软件再工程、转换 齑塞邮电太堂亟婴塞生堂僮论塞 坠! ! 签! a bs t r a c t i nm a n yc o m p a n i e s ，t h e r ea r em a n ye x i s t i n gs o f t w a r e si nu s eh a v eb e e np r o v e d t ob ev e r ys u c c e s s f u l b u ti ns o m ec a s e ss u c ha sr e q u i r e m e n t sc h a n g i n g ，r u n n i n g p l a t f o r mb e i n go u to fd a t e ，a n dn e wt e c h n o l o g ya p p e a r i n g ，t h e s es o f t w a r e sn e e d t ob er e d e s i g n e da n d o rr e c o d e d t h e s ea r ec a l l e dr e e n g i n e e r i n g s o f t w a r e r e e n g i n e e r i n gi sa l s oa ni m p o r t a n tw a yt oc o n s t r u c tr e u s a b l er e s o u r c e s 。 i nt h i sp a p e r ，w ep r o p o s eas c h e m ao ft r a n s f o r m i n gal e g a c yw e ba p p li c a t i o n t oh a v ea 辩ea r c hit e c t u r e 。 w ed is c u s sf i r s tj 2 e e ，d e s i g np a t t e r no fw e ba p p lic a ti o n sa n dt h ec o n c e p t s o fs o f t w a r er e e n g i n e e r 主n g t h e nw ep r e s e n tas e m i a u t o m a t i cs o l u t i o no f r e e n g i n e e r i n gp r o f i to nt h ed o m e s t i ca n do v e r s e a sc o r r e l a t i v es t u d yw o r k s ，a n d w ea l s op r e s e n td e s i g ni d e ao ft h ep r o t o t y p e a tl a s t ，w ep r o v e dt h ef e a s i b i l i t y a n dv a l i d i t yo ft h i sm e t h o dt h r o u g hp r a c t i c eo ft h ea c t u a lp r o j e c t k e yw o r d s ：m v c ，w e b ，l e g a c ys y s t e m s ， s o f t w a r er e e n g i n e e r i n g ，t r a n s f o r m i n g i i 南京邮电大学学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究 工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢的 地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包 含为获得南京邮电大学或其它教育机构的学位或证书而使用过的材 料。与我同工作的同志对本研究所做的任何贡献均已在论文中作了 明确的说明并表示了谢意。 研究生签名： 哗嗍： 南京邮电大学学位论文使用授权声明 南京邮电大学、中国科学技术信息研究所、国家图书馆有权保留 本人所送交学位论文的复印件和电子文档，可以采用影印、缩印或其 他复制手段保存论文。本人电子文档的内容和纸质论文的内容相一 致。除在保密期内的保密论文外，允许论文被查阅和借阅，可以公布 ( 包括刊登) 论文的全部或部分内容。论文的公布( 包括刊登) 授权 南京邮电大学研究生部办理。 研究生签名：导薅签名：潞磬l 勺魄 第l 章引言 1 1 课题背景 随着面向对象和w e b 技术的发展，越来越多的人们将各种应用加以扩展，使之适合基 于w e b 的运行模式。由于企业应用的发展以及新技术的不断出现，那些长时间运行良好的 遗留系统相应的应用必须重新实现，或者改造原有的程序，以适应现代应用的需要。而这 些多年来运行良好的遗留系统在其使用维护中，受到了实践的长期检验，凝聚了众多领域 专家的心血，证明是对企业业务逻辑的正确描述。完全抛弃遗留系统而全面开发新系统面 临较高的开发代价以及新应用风险，对原有的遗留系统进行维护、重构以及再工程的需求 就显得越来越重要了。本文提出了一种半自动方式的软件再工程方案将遗留w e b 应用系统 改造为具有m v c 结构的新系统，不改变原有的商业逻辑。 1 2 研究现状 从九十年代开始，无论在国外还是在国内，对于软件再工程领域的研究都有十几年的 时间了，已经形成了一定的研究规模，发表了不少的研究文献。i e e e 发起的欧洲软件维 护和再工程会议( e u r o p e a nc o n f e r e n c eo ns o f t w a r em a i n t e n a n c ea n dr e e n g i n e e r i n g ) 迄今为止已经举行了十届。第十一届会议( c s m r2 0 0 7 ) 将于2 0 0 7 年3 月2 1 日至2 3 日在 荷兰阿姆斯特丹举行，会议的议题包括w e b 维护和再工程( w e bm a i n t e n a n c ea n d r e e n g i n e e r i n g ) 、模型驱动的软件演化工具( w o r k s h o po nm o d e l d r i v e ns o f t w a r e e v o l u t i o n ) 、系统的质量和可维护性( s y s t e mq u a l i t ya n dm a i n t a i n a b i l i t y ) 、面向 服务结构的维护的研究日程( r e s e a r c ha g e n d af o rs e r v i c e o r i e n t e da r c h i t e c t u r e m a i n t e n a n c e ) 等。 在国内，由于遗留系统还不够多而且对软件的后期维护也不太重视，所以对软件再工 程的研究也比较少。北京大学以杨芙清教授为首开发的青鸟软件生产线系统中的青鸟程序 理解系统j b p a s 是其中一项实质性的成果 2 8 。j b p a s 包含一组分析工具它可以针对c + + 语言采用增量分析技术静态分析源程序代码用e e r ( e n h a n c e de n t i t y r e l a t i o n s h i p ) 为 c + + 程序建立概念模型并抽取程序信息将信息保存在数据库中按照不同的用户需求组织程 序信息辅助用户理解c + + 程序逆向生成源程序的o o n ( o b j e c to r i e n t e dd e s i g n ) 文档从而 进一步从中提取出构件构架。在由国防科学技术大学计算机学院承办的第五届全国软件与 应用学术会议( n a s a c2 0 0 6 ) 上，软件再工程被列入为其中一项重要议题，开展了一 些研究与讨论工作。 1 3 本文章节安排 第一章为绪论，介绍本文的背景及研究现状。第二章相关理论介绍，包括w e b 应用软 件的设计模式以及软件再工程的一些基本理论。第三章为本文提出的将遗留系统转换为 m v c 结构的具体方案，包括了相关研究文献的介绍、本方案的提出理由、方法论以及实现 的描述。第四章为案例研究，用一个具体的案例来测试及验证本方案的优缺点。第五章为 结论与展望，总结了本文优缺点、价值以及对未来的展望。第六章为索引文献，列举了本 文当中引用的参考文献。 2 第2 章相关理论介绍 2 1j 2 e e 概述 2 1 1 概念 j 2 e e ( j a v a 2p l a t f o r m ，e n t e r p r i s ee d i t i o n ) 是s u n 公司定义的一个开发分布式企业 级应用的规范。它提供了一个多层次的分布式应用模型和一系列开发技术规范。多层次分 布式应用模型是指根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组 件，组件在分布式服务器的组件容器中运行( 如s e r v l e t 组件在s e r v l e t 容器上运行，e j b 组件在e j b 容器上运行) ，容器间通过相关的协议进行通讯，实现组件间的相互调用。遵 从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单，快速。 j 2 e e 技术的基础就是核心j a v a 平台或j a v a 2 平台的标准版，j 2 e e 不仅巩固了标准版 中的许多优点，包括“编写一次、随处运行”的特性、方便存取数据库的j d b ca p i ，c o r b a 技术以及能够在i n t e r n e t 应用中保护数据的安全模式等等，同时还提供了对 e j b ( e n t e r p r i s ej a v a b e a n s ) ，j a v a s e r v l e t ，j s p 以及x m l 技术的全面支持。j 2 e e 体系结构 所提供的中间层集成框架可以满足高可重用性、高可靠性以及高可扩展性的应用需求。 2 1 - 2j 2 e e 体系结构 j 2 e e 使用多层的分布式应用模型，应用逻辑按功能划分为组件，包括客户端组件、 w e b 层组件、商业逻辑层组件、企业信息系统层组件等。各个组件根据他们所在的层分布 在不同的机器上。j 2 e e 体系结构如图2 - 1 所示。 j 2 e e 规范定义了如下组件： 客户端组件：应用客户端程序和h p p l e t s ； w e b 组件：j a v as e r v l e t 和j a v as e r v e rp a g e s ； e i b 组件：e n t e r p ris ej a v a b e a n ； j 2 e e 架构是一共多层的结构，包括以下四个层次： ( 1 ) 客户端层( c 1 i e n tt i e r ) 客户端层用来实现企业级应用系统的操作界面和显示层。另外，某些客户端程序 也可实现业务逻辑河分为基于w e b 的和非基于w e b 的客户端两种情况。基于w e b 的情况下 主要作为企业w e b 服务器的浏览器。非基于w e b 的客户层则是独立的应用程序，可以完成 瘦客户机无法完成的任务。 3 ( 2 ) w e b 层( w e bt i e r ) 为企业提供w e b 服务。包括企业信息发布等。w e b 层由w e b 组件组成。j 2 e ew e b 组件包括j s p 页面和s e r v l e t 。w e b 层也可以包括一些j a v a b e a n 。w e b 层主要用来处理客 户请求，调用相应的逻辑块，并把结果以动态网页的形式返回到客户端。 ( 3 ) 业务层( b u s i n e s st i e r ) 业务层也叫e j b 层或应用层，它由e j b 服务器和e j b 组件组成。一般情况下许多开发 商把w e b 服务器和e t b 服务器产品结合在一起发布，称为应用服务器。e j b 层用来实现企 业级信息系统的业务逻辑。这是企业级应用的核心，由运行在业务层中的e j b 来处理。一 个b e a n 从客户端接收数据并进行处理，然后把数据送到企业信息系统层存储起来。同样， 一个b e a n 也可以从企业信息系统取出数据，发送到客户端程序。业务层中的e j b 要运行 在容器中，容器解决了底层的问题，如事务处理、生命周期、状态管理、多线程安全管理、 资源池等。 ( 4 ) 企业信息系统层( e n t e r p r i s ei n f o r m a t i o ns y s t e mt i e r ) 处理企业系统软件，包括企业基础系统、数据库系统及其他遗留的系统。j 2 e e 将来 的版本支持连接架构( c o n n e c t o ra r c h i t e c t u r e ) 。它是连接j 2 e e 平台和企业信息系统层 的标准a p i 。其中，业务层和w e b 层共同组成了三层j 2 e e 应用的中间层，其他两层是客 户端层和存储层或企业信息系统层。 图2 一l ：j 2 e e 结构示意图 4 2 2w e b 应用软件设计模式 设计模式的概念最初来自于城市建筑专家c h r i s t o p h e ra l e x a n d e r 对建筑模式的定义： “每一个模式描述了一个在人们周围不断重复发生的问题，以及该问题解决方案的核心。 这样，你就能一次又一次地使用该方案而不必做重复劳动。 在软件开发中我们也经常会 遇到这样的问题：我们不断重复地做着不同项目中相似的设计工作，我们已经解决过了一 个这样的问题但就是不能确切知道是在什么地方或具体怎么解决的? 如果我们能记起以前 问题的细节和解决方法，我们就可以复用以前的经验而不需要重新设计它。 把以前经常遇到的问题进行归纳总结，得出通用的解决方案，就形成了设计模式。尽 管a l e x a n d e r 所指的是城市和建筑模式，但他的思想也同样适用于面向对象的软件开发 中。只是在面向对象的解决方案里，我们用对象和接口代替了墙壁和门窗，两类模式的核 心都在于提供了相关问题的解决方案。 一般而言，一个设计模式有四个基本要素： ( 1 ) 模式名称( p a t t e r nn a m e ) 一个助记名，它用一两个词来描述模式的问题，解决方案和效果。如果有一个统一的 模式词汇表，开发人员就可以讨论模式并在编写文档时使用他们。模式名可以帮助我们思 考，便于我们与其他人交流设计思想以及设计结果。 ( 2 ) 问题( p r o b l e m ) 描述了应该在何时使用设计模式。它解释了设计问题和问题存在的前因后果，它可能 描述了特定的设计问题，也可能描述了导致不灵活设计的类或对象结构。有时候，问题部 分会包括使用模式必须满足的一系列先决条件。 ( 3 ) 解决方案( s o l u t i o n ) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模 式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计 或实现，而是提供设计问题的抽象描述和怎么用一个具有一般意义的元素组合( 类或对象 组合) 来解决这个问题。 ( 4 ) 效果( c o n s e q u e n c e s ) 描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总 提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。 在最初的软件开发阶段，由于种种客观原因并没有考虑应用良好的模式。而且，在设 5 计初期就使用模式的话，有可能注意力会被集中到如何使用模式上而不是如何满足需求 上，增大了开发的风险软件，再工程是使系统架构具有良好模式的重要途径。 2 2 1m v c m v c ，即m o d e l v i e w c o n t r o l l e r ，是8 0 年代s m a l l t a l k 出现的一种软件设计模式的 缩写，是一种常用的设计模式。m v c 减弱了业务逻辑接口和数据接口之间的耦合，以及让 视图层更富于变化，现在已经被广泛地使用。m v c 由以下几个逻辑结构组成： 1 ) 模型( m o d e l ) 模型是应用程序的主体部分。模型表示业务数据或者业务逻辑。 2 ) 视图( v i e w )视图是应用程序中用户界面相关的部分，是用户看到并与之交户 的界面。 3 ) 控制器( c o n t r o l l e r ) 控制器是模型和视图的联系纽带。作用是提取通过视图 传输进来的外部信息，并更新相应模型状态。 m v c 组件类型的关系和功能如图2 2 所示。 控制器 一选择视图 定义应用程序行为 用户动作映射成模型更新 f _ _ 一- - -选择响应的视图 状态 改变 用户请求 1r1r 视图 查询状态 模型 发送用户输入给控制器封装应用程序功能和状态 允许控制器选择视图 响应状态查询 模型更新请求 通知改变 通知视图改变 解释模型 - 卜事件 图2 - 2 ：m v c 示意图 2 2 2 独立自主的j s p 尽管m v c 设计模式很早就出现了，但在w e b 应用的开发中引入m v c 却是颇费周折。主 要原因在于在早期的w e b 应用开发中。程序语言和h t m l 的分离一直难于实现。例如在j s p 网页中执行业务逻辑的程序代码和h t m l 表示层数据混杂在一起，因而很难分离出单独的 6 业务模型。这使得维护j s p 网页非常困难，很难满足用户的变化性需求。 在早期的j a v aw e b 应用中，j s p 文件负责业务逻辑、控制网页流程并创建h t m l ，如 图2 3 。j s p 文件是一个独立的、自主完成所有任务的模块，这给w e b 开发带来一系列问 题： h t m l 代码和j a v a 程序强耦合在一起：j s p 文件的编写者必须既是网页设计者，又是 开发者。但实际情况是，多数w e b 开发人员要么只精通网页设计，能够设计出漂亮的网页 外观，但是编写的j a v a 代码很糟糕；要么仅精通j a v a 编程，能够编写健壮的j a v a 代码， 但是设计的网页外观很难看。具有这两种才能的开发人才很少见。 内嵌的流程逻辑：要理解应用程序的整个流程，必须浏览所有网页，试想一下拥有 1 0 0 个网页的网站的错综复杂的逻辑。 调试困难：除了很糟的外观之外，h t m l 标记、j a v a 代码和j a v a s c r i p t 代码都集中在 一个网页中，使调试变得相当困难。 强耦合：更改业务逻辑或数据可能牵涉相关的网页。 美学：设想有1 0 0 0 行代码的网页，其编码样式看起来杂乱无章。即使有彩色语法显 示，阅读和理解这些代码仍然比较困难。 浏览器 求 应 j s p 改数 取数 图2 - 3 ：早期j a v aw e b 应用结构图 2 2 3j s pm o d e l1 与j s pm o d e l2 ( m v c ) 为了解决以上问题，s u n 公司先后制定了两种规范，称为j s pm o d e l1 和j s pm o d e l2 ， 如图2 - 4 和2 5 。 虽然m o d e ll 在一定程度上实现了m v c ，但是它的运用并不理想。在j s pm o d e ll 中， j s p 页面负责响应用户请求并将处理结果返回用户。j s p 既要负责业务流程控制又要负责 提供表示层数据，同时充当视图和控制器，未能彻底地实现这两个模块之间的独立和分离， 使得j s p 页面上有大量的j a v a 代码。程序逻辑开发与页面设计纠缠在一起，既不便于分 工合作也不利于代码的重用，这样的程序其健壮性和可伸缩性都不好，维护会非常不方便， 给项目管理带来很大麻烦。j s pm o d e ll 简单易学，对一些规模很小的项目，往往效率很 7 高。例如，初学者在用j s p 访问数据库时，往往喜欢别人能提供一个包含所有数据库功能 的单个j s p 页面，因为这样在一个页面上就可以把握全局，便于理解。但是，用m o d e l1 模式开发大型w e b 应用软件时，程序流向由一些互相能够感知的页面决定，当页面很多时 要清楚地把握其流向将是很复杂的事情，当修改一页时可能会影响相关的很多页面，大有 牵一发而动全身的感觉，使得程序的修改与维护变得异常困难。 直到基于j 2 e e 的j s pm o d e l2 问世才得以改观。j s pm o d e l2 用j s p 技术实现了视 图的功能，用s e r v l e t 技术实现了控制器的功能，用j a v a b e a n 技术实现了模型的功能。 j s pm o d e l2 体系结构是一种联合使用j s p 和s e r v l e t 来提供动态内容服务的方法。 它吸取了j s p 和s e r v l e t 两种技术各自的突出优点，用j s p 生成表示层的内容，让s e r v l e t 完成深层次的处理任务。在这里，s e r v l e t 充当控制器的角色，负责处理用户请求，创建 j s p 需要使用的j a v a b e a n 对象，根据用户请求选择合适的j s p 页返回给用户。在j s p 页 内没有处理逻辑，它仅负责检索原先由s e r v l e t 创建的j a v a b e a n 对象，根据用户请求选 择合适的j s p 返回给用户。从s e r v l e t 中提取动态内容插入到静态模版。这是一种有突破 性的设计方法，它清晰地分离了表达和内容，明确了角色定义以及开发者与网页设计者的 分工。事实上，项目越复杂，使用m o d e l2 设计模式的好处越大。 浏 览 器 图2 4 ：j s pm o d e l1 8 浏 览 器 应用服务器和数据库 图2 5 ：j s pm o d e l2 2 2 4 基于x m l i x s l t 的m v c j s pm o d e l2 可以支持多种客户端浏览器类型，但针对每一种特定的客户端类型都需 要一个表示层接口。例如相同的的业务逻辑，针对桌面浏览器，需要一套j s p 页面形成 h t m l 格式的表示层视图。而对于支持w m l 的手机，则需要另外一套j s p 页面生成1 】l m l 格 式的表示层视图。代码冗余，不易扩展。 考虑到m v c 模型显示和业务逻辑的特点，可以将跨平台的多样化工作放到显示部分来 做，而控制器和模型的请求接收和业务逻辑处理都可以保持不变。 x s l 样式表用于定义一系列的转换规则，描述如何显示x m l 文档。x s l t 处理器提供了 一种通用的方法，可以将源x m l 文档转换成为各种客户终端能识别的输出格式，包括 h t m l 、删l 等格式。x s l t 处理器的输出格式是由x s l 样式定义的转换规则决定。不同的客 户端类型，对应的x s l 样式表不同。 文献m “町描述了在w e b 应用中使用x m l x s l t 技术实现多视图。基于x m l x s l t 的m v c 结构1 ，是在某些应用要求下对j s pm o d e l2 的改进，完全满足j s pm o d e l2 的要求，并 能较好地满足视图部分多样性要求。如图2 - 6 。 软件体系结构方面不是本论文要讨论的重点，因此不再赘述。 9 w e b 服务器 图2 - 6 ：基于潮l x s l t 的m v c 结构 应用服务器和数据库 2 。3 软件再工程 2 3 1 软件再工程的一般概念 在不同的文献中，对于再工程的概念有着许多不同的定义：通过对遗留系统的审查和 改造将其重组为一种新的形式，以及这种新形式的实现过程乜5 1 。不改变一个系统的功能， 只改变它的环基于x m l x s l t 的m v c 结构境或技术而对其进行改造的过程；对遗留系统的 修改或可能的进一步开发；通过逆向工程( 和重构) 以及之后的正向过程来改进一个系统 的过程；修改一个系统或程序的内部机制或数据结构而不改变其功能的过程乜刚。 目前，软件再工程主要分为三类： ( 1 ) 适应性维护的再工程。例如：系统运行环境变化带来的软件修正，如由主机方式 变为客户机服务器方式、由客户机服务器方式变为w e b 方式，这时的系统体系结构必 须相应变化。 ( 2 ) 完善性维护的再工程。例如：提高安全性及处理能力等系统性能。 ( 3 ) 预防性维护的再工程。例如：为了提高可维护性而对系统进行优化、再结构化、 再标准化、对文档进行重构、对数据进行重组。 软件再工程所使用的方法主要分为两类： 1 0 ( 1 ) 黑盒方法 只从系统的外部分析其接口和功能，并进行包装和重组。例如，用w e bs e r v i c e 对遗 留系统进行包装。 ( 2 ) 白盒方法 从代码级开始分析，据此构造新的结构形式。例如，将面向过程的遗留系统改造为面 向对象的系统。 2 3 2 软件再工程的目标 软件再工程的目标是： ( 1 ) 为功能追加、增强做准备 软件再工程用新的设计思想来重新实现，是对原有的文档的更新，使今后能方便地对 系统进行功能的追加和增强。 ( 2 ) 提高可维护性 经过软件的再工程和再设计，其模块划分会更合理，接口定义更清晰，从而更易于维 护。 ( 3 ) 软件的移植 软件再工程将一些优秀软件移植到新的硬件平台、操作系统中，从而使它们能够利用 新环境的新特性，更好地满足用户的需求。 ( 4 ) 提高可靠性 软件的维护修改容易引起连锁反应，导致系统的稳定性和可靠性逐渐降低，软件再工 程可以较好地解决这一问题。 2 3 3 遗留系统的定义 关于遗留系统( l e g a c ys y s t e m ) ，c a f a s s o 在1 9 9 3 年作了如下的定义乜2 1 ：遗留系 统是一个使用较旧的技术开发的应用系统，它的主要用途已经过时了，但如果中断使用会 造成损失。b e n n e t t 在1 9 9 5 年作了如下的定义：遗留系统是大家不知道如何处理但对组 织又是至关重要的系统砼引。b r o d i e 对遗留系统的定义如下：遗留系统是指任何基本上不 能进行修改和进化以满足新的变化了的业务需求的信息系统乜钔。 遗留系统应该具有以下特点： ( 1 ) 系统虽然完成企业中许多重要的业务管理工作，但已经不能完全满足要求。 11 ( 2 ) 系统在性能上已经落后，采用的技术已经过时。 ( 3 ) 通常是大型的软件系统，已经融入企业的业务运行和决策管理机制之中，维护 工作十分困难。 ( 4 ) 系统没有使用现代软件工程方法进行管理和开发，现在基本上已经没有文档， 很难理解。 在企业信息系统升级改造过程中，如何处理和利用遗留系统，成为新系统建设的重 要组成部分。处理恰当与否，直接关系到新系统的成败和开发效率。 2 3 4 对遗留系统进行再工程的意义 在许多公司内部，仍然存在着使用多年、功能及效率已经越来越不适应需求的遗留系 统。这些系统一般没有完整的规范，缺乏系统文件，很多都是利用过时的语言所开发完成。 虽然老的系统问题很多，但因为重新开发的昂贵成本以及不能确保新的系统能够完全取代 老系统完整的功能。因此，很多企业仍然被迫持续沿用老系统来提供重要的商业服务，这 也导致了所花费的时间与成本较原先开发时高出很多。依赖遗留系统的公司，必须在有限 的预算之下选择最符合商业利益的策略来对这些老的系统实施软件变更( s o f t w a r e c h a n g e ) 。 软件变更有几种不同的策略：软件维护( s o f t w a r em a in t e n a n c e ) 、架构转换 ( a r c h i t e c t u r et r a n s f o r m a t i o n ) 、软件再工程( s o f t w a r er e e n g i n e e r i n g ) 等。其中采用 软件再工程的方法，对系统发展( s y s t e me v o l u t i o n ) 而言，具有以下的两个主要优点：降 低风险( r e d u c e dr is k ) 重新开发系统具有高风险，可能会在系统发展阶段产生错误，而 导致新系统无法顺利取代旧系统的功能。因为一个运行良久的遗留系统，最起码的价值 是在操作方法和正确性上已被用户接受。而再高明的程序员在软件没有经过用户一段时间 的使用验证之前都不敢保证自己的程序正确无误。更何况越是有经验的程序员越是知道对 一个处于局部变更地位的程序进行重新编写远比一次工程的原始编程复杂得多，因为他需 要对应无数的“副作用”。减少成本( r e d u c e dc o s t ) 对于某些项目而言，在程序的初始 开发人员或者程序的设计文档比较齐备的情况下，进行再工程所耗费的成本远比重新开发 新系统来得低。当然，另一种情况就是可能程序的初始开发人员己经离开了，而且也没有 留下系统的详细设计文档或者是初始的设计文档跟目前的系统相比已经面目全非的情况 下，进行再工程耗费的人力物力可能比重新开发新系统要更大。 从技术的角度来看，软件再工程是系统进化问题和一个解决方案。从业务角度来看， 1 2 软件再工程可能是保证遗留系统能继续提供服务惟一可行的方法。再工程是一种相对新的 软件进化方法，它界于系统替换和继续维护之间，它的一个系统的成本比替换一个系统 的成本要低，能降低与替换系统和继续维护所带来的巨大风险。再工程不是从写系统描述 开始，而是将遗留系统作为新系统的描述，因此你能降低由于丢失包含在系统中关键的业 务知识所带来的风险。再工程的目的就是以低成本进化一个能满足用户新需求的系统。 2 3 5 再工程的一般步骤 再工程的一般步骤包括逆向工程、重构、正向工程等步骤。 1 逆向工程 “逆向工程( r e v e r s ee n g i n e e r i n g ) 来自于硬件领域，一个公司分解某竞争者的硬 件产品去了解竞争者的设计和制造“秘密”。如果得到了竞争者的设计和制造规约，则这 些秘密可以很容易地理解，以达到复制硬件系统的目的。 随着软件业的发展，逆向工程这一术语被引入软件工程领域，软件逆向工程可以用于 描述揭示已有系统工作原理的过程，或者是用于描述创建现有文档的联机文档的过程等。 当然逆向工程还适用于软件的其它领域，比如图象滤波、自由曲面建模等。国家自然科学 学科发展战略报告计算机科学技术部分中这样定义软件逆向工程的：从可运行的程序系统 出发，生成对应的源程序、系统结构以及相关设计原理和算法思想的文档等。一般将软件 逆向工程定义为包含抽取和抽象这两个步骤过程盯3 ：第一步分析目标系统，标识目标系统 的组件以及它们之间相互关系，比较常见的分析技术包括静态分析、程序切片等技术。第 二步创建不同形式或更高抽象层次的系统表示。s c o t tr t i l l y 将将两个步骤进一步细 化为建模、抽取和抽象三个步骤表示1 ： 1 ) 建模( m o d e l ) ：采用概念建模技术构造应用程序领域模型。 2 ) 抽取( e x t r a c t ) ：利用适当的抽取机制从目标系统中收集原始数据。 3 ) 抽象( a b s t r a c t ) ：对目标系统进行抽象，以辅助系统理解并浏览、分析和表示抽象 结果。 从以上定义可以看出，软件逆向工程可以用于较低级的抽象层次，例如把可执行程序 转换为源代码，但主要是用于将源代码转换为更高抽象层次上的表示，如控制图、数据流图 和类关系图等。 对一个软件系统实施逆向工程，通常是为了获得对这个系统在设计层次上的理解，以 便于系统的维护、巩固、移植。与软件工程密切相关的三个概念是正向工程、逆向工程、 13 再工程。软件工程通常被认为是开发一个新的系统，尽管软件工程也包括逆向工程和再工 程。为了避免对软件工程含义的误解，引进了正向工程的概念。正向工程是从系统的高层 抽象和逻辑上独立于实现的设计到系统的物理设计的传统过程。具体地说是从用户的需求 到高层设计，再到低层设计，最后到实现的过程。逆向工程是对系统进行分析，以确定系统 的组件和组件之间的交互作用，以其他形式表示系统，或在较高的抽象层次上表示系统的 过程。值得说明的是，在对一个系统实施逆向工程时，并不改变这个系统本身，也不包括在 此系统上构建新的系统的过程。逆向工程对系统实施的是一个检查过程，它把正向工程作 为要逆转的对象。正向工程、逆向工程和再工程三者之间的关系如图2 - 5 所示。 正 向 工 程 图2 5 ：正向工程、逆向工程和再工程关系图 逆向工程的目标是从程序源代码、文档和其他可用的资源中抽象出设计信息、功能描 述和需求。软件人员在程序理解过程中依赖于内在的文档，把文档作为辅助。不幸的是， 大多数程序的文档是过时的和不可信的。如果没有可信的文档，程序理解过程中惟一可以 依赖的客观信息就是源代码自身了，软件人员必须花费大量的时间分析低级的源代码，以 便获得对系统功能的理解。 再工程通常先进行某种逆向工程( 完成更多的抽象描述) ，然后进行某种形式的正向 工程或结构重组。这可能包括修改原系统，以便添加新的功能。可见，逆向工程的最基本目 标是为了系统的维护和进一步开发而增加对系统的全面理解能力。 在没有文档或者文档与源代码不一致的情况下，单独从程序的源代码出发，理解一个 1 4 大型复杂系统是很困难的。逆向工程为程序的理解提供了便利。例如，逆向工程工具x d r e 就可以辅助用户很好地理解面向对象的c + + 程序。使用这个工具可以自动获得程序的静 态结构，如设计类图、进程结构图、系统的体系结构图等，这些图可以帮助用户很好地理解 系统的静态结构。x d r e 还可以自动获得系统运行时的动态信息，如序列图、状态图、活 动图等，从这些图中可以看出系统各组成部件之间的交互行为，以及各部件在系统中的状 态变化。由于x d r e 提供了很好的用户交互方式，用户可以在不同的抽象层次上选择需要 关注的系统部件，从而有重点地理解系统。 2 重构 ， 重构( r e c o n s t r u c t i o n ) ：在不改变原有系统功能的前提下，重新安排程序的逻辑流 程和业务流程。例如，随着i n t e r n e t 的发展，许多过去的业务领域已经扩展到i n t e r n e t 上进行，由于许多遗留系统都不直接支持w e b 访问，所以运用w e b 化再工程的方案对其 进行重构时，往往需要使用支持w e b 访问的编程语言重新编写程序去实现既存系统的功 能。w e b 化再工程也需要对已有系统实施逆向工程，建立适当的再工程模型。利用模型和 一些再工程辅助工具对原系统进行二次开发。w e b 化再工程后的软件系统的可扩展性、负 载平衡、容错性等性能的优劣均取决于再工程的实施质量。 重构包括文档重构( d o c u m e n tr e s t r u c t u r i n g ) 、代码重构( c o d er e s t r u c t u r i n g ) 、数 据重构( d a t ar e s t r u c t u r i n g ) 。 ( 1 ) 文档重构：贫乏的文档是很多遗产系统的显著标志。建立文档也是非常耗费时间 的，因此对于关键的业务，必须要重新构建文档，并且设法将文档工作减少到必需的最 小量。在我们针对某一个系统进行再工程时，对于系统当前正在进行改变的那些部分建立 完整的文档。而对于其他运行正常的部分，则将继续保持原样，无需重新构建文档。 ( 2 ) 代码重构：这是最常见的重构类型。为了完成该活动，我们需要首先去分析源代 码，和结构化程序设计概念相背的部分被标记，然后代码被重构。生成的重构代码被评审 和测试以保证没有引入异常和不规则，内部的代码也相应被修订。 ( 3 ) 数据重构：数据体系结构差的程序是难以进行适应性的修改和增强的。事实上， 对于很多应用来说，数据体系结构对程序的长期生存力的影响比源代码要大。和代码重 构不同，数据重构发生在相当低的抽象层次上，数据重构是一种全范围的再工程活动。 重构的一些好处如下： 1 ) 使软件的质量更高，或使软件顺应新的潮流( 标准) 。 1 5 2 ) 使软件的后续( 升级) 版本的生产率更高。 3 ) 降低盾媲的维护代价，使得软件易于测试与调试。 3 正向工程 覆向工程( f o r w a r de n g i n e e r i n g ) 对逆向工程巾所 ! 譬到的信息进行分析处理，并利用 得到的信息去改变或重构现存系统，以改善其整体质量。逆向工程进行的工作是把一个既 有豹系统敏实际代码提炼出高层的软件撼象，例如程序和数据的结构信息、系统的e - r ( 实 体e n t i t y 一关系r e l a t i o n ) 模型等。是一个自下而上的行为。而正向工程进行的工作是 利用我们从逆向工程褥到的系统高层的信息，面进行新的设计、新的编码麴行为，是翔上 而下的。 匿囱工程相比较重构葱言，重构趋向予关注个体模块的设计细节以及定义在模块审的 局部数据结构。而正向工程则扩展到模块边界之外并涉及软件体系构。 1 6 第3 章将w e b 遗留系统转换为m v c 结构 3 1 简介 本论文研究的是将前面提到的既存的独立自主的j s p 应用系统( w e b 遗留系统) 转换 为基于) ( m l x s l t 的m v c 结构的系统( 新系统) 。 3 2 与本方案相关的研究工作 文献n 瑚将基于c o b o l 的遗留系统转换为采用m v c 结构的w e b 系统，并在此基础上开 发出一套工具集。论文焦点集中在遗留程序的包装以及用户界面的再实现。方法是从c o b o l 源代码中提取所需信息，自动为业务逻辑、数据模型产生包装器，并将g u i 用户界面转换 为j s p 。基本属于黑盒方法。 文献口3 提出了将遗留w e b 应用系统移植到j 2 e e 环境的方法、步骤以及工具。此处的 遗留w e b 应用系统是用i b mn e t d a t a 开发的，包含其独有的脚本语言。 文献h 1 将传统的基于静态h t m l 的w e b 网站改造为以控制器为中心的基于j s p 的w e b 网站，以提升其灵活性和可维护性。改造的策略主要包括页面依赖分析、页面流建模和以 控制器为中心的系统结构实现。 文献聆3 综合了前面两种方案，提出了方案将遗留w e b 应用系统转换为基于j 2 e e 环境 的具有m v c 结构的新应用系统。主要步骤包括s q l 语句的抽取及封装，系统结构改造为以 控制器为中心以及用户界面改造为j s p 。 文献哺1 提出了用面向网格服务的再工程方法改造基于静态h t m l 的w e b 网站以实现在 分布式环境中用户对资源的无缝获取。 文献p 3 提出了将遗留软件系统改造为面向服务的结构，使得用户可用浏览器来访问。 主要方法是将遗留软件模块封装为w e bs e r v i c e s ，属于黑盒方法。 国内的关于w e b 应用系统的软件再工程，大多停留在人工整理、理解源文件以及参考 文档的基础上，较少结合自动化方法，导致再工程过程冗长，花费巨大，甚至比开发新系 统更复杂。 3 3 本论文提出的方案 3 3 1 方案介绍 本文在总结国内外相关研究成果的基础上提出了将独立自主的j s p 遗留系统转换为 蜜枣唑电丕堂亟硒巍生堂僮迨塞 筮墨重擅蛭垦遗鱼丕统整逸盏型g 结塑 基于煳l x s l t 的m v c 结构新系统的方案。方案采用半自动方式( s e m i a u t o m a t i cm o d e ) ， 分为五个阶段依次展开。第一个阶段为预处理，需要人工参与。第二个阶段为文件解析， 实现对遗留系统的逆向理解过程。第三个阶段为页面间关联分析。通过对页面依赖关系的 分析，形成页面流模型。第四个阶段为分离业务逻辑和显示逻辑。通过将业务逻辑从页面 中分离出来，使得产生的新结构符合j s pm o d e l2 的要求。第五个阶段为用户界面的生成。 通过使用x m l x s l t 技术，使得改造后的系统支持多客户端。整个方案除了第一个阶段需 要人工参与外，其他阶段均是采用自动方式开展。 3 3 2 提出此方案的理由 文献n 儿2 的原始系统是c s 结构的，通过再工程成为b s 结构。与本论文的原始系统 差别较大。 文献刀的目标系统是s o a 结构的，s o a 结构主要用于解决基于异构应用平台程序之 间的互操作问题，与本论文的目标系统差别比较大。 文献啼1 提出的方案与本论文提出的方案有某些相似的地方，都是将遗留的w e b 应用系 统改造为具有m v c 结构的新系统。笔者认为文献酶3 所作的工作虽然具有开拓性并提出了解 决此类问题的方法论，能满足当时的要求，但随着新技术的发展，产生了需要改进的空间。 文献啼1 中所使用的原始系统是用i b mn e t d a t a 开发的，在其独有的脚本语言中可以 直接使用s q l 语句来执行数据库操作，因此在原始系统中包含了大量的s q l 语句。为了实 现向j 2 e e 环境的移植，作者将s q l 语句用j a v a b e a n s 进行了封装。i b mn e t d a t a 是较 早的、专用的w e b 应用系统开发平台，目前比较流行w e b 应用系统则多为基于j 2 e e 平台。 因此，本论文选用的原始系统是j z e e 平台上的采用独立自主j s p