（计算机应用技术专业论文）基于j2ee和ria技术的再工程方法与实践.pdf

浙江人学硕士学位论文y 8 7 6 9 3 6 摘要 当软件系统随着长时间的使用变得难以修改和演化的时候，就成为了遗留 系统。如果这些系统仍然具有相当重要的业务价值，那么就必须对它们进行再 工程，即通过使用新的技术和再工程实践来改善遗留系统各方面的能力、提高 其可维护性。某金融公司的a 系统已经使用了近2 0 年，是一个典型的遗留系 统，它采用的一些技术在现在看来比较落后，但是具有的商业价值却很高，因 此需要应用新技术对其进行再工程。 本文首先介绍软件再工程领域的最新发展( 包括遗留系统的理论，软件再 工程理论等) ，j 2 e e 技术的框架结构及其在电子商务系统等应用方面的优势， 一种r i a 技术m a c r o m e d i af l e x 技术，c i t r i x 技术，以及本次再工程的主要 任务。在结合项目背景介绍了如何运用再工程方法对原有系统进行分析的基础 上，本文详细分析和探讨了如何在风险分析的基础上制订正向工程的策略，在 提出j 2 e e f l e x 方案的基础上，鉴于该方案实现周期较长，又提出短期的c i t r i x 方案以满足短时期的关键需求。接下来介绍了主要的方案_ j 2 e e f 1 e x 解决方 案的架构设计和代码模块划分，以及对该解决方案的实现：代码实现过程，测 试过程和发布计划：对c i t r i x 解决方案也进行了讨论。然后，从项目管理和技 术两个角度总结了在这个项目中比较有创造性的想法和实践。最后，总结了前 一阶段的工作，并对未来的工作做出了展望。 关键词：软件再工程，j 2 e e ，r i a 第1 页共6 2 页 浙江大学硕士学位论文 a b s t r a c t w h e ns o f t w a r es y s t e m sb e c o m eh a r dt ob em o d i f i e da n de v o l v e da f t e rl o n gt i m e u s a g e ，t h e yb e c o m el e g a c ys y s t e m s i ft h o s es y s t e m ss t i l lh a v es i g n i f i c a n tb u s i n e s s v a l u e ，t h e ys h o u l db er e e n g i n e e r e d ( u s en e wt e c h n o l o g i e sa n dr e e n g i n e e r i n g p r a c t i c e st oe n h a n c et h ef u n c t i o n a l i t ya n dm a i n t a i n a b i l i t yo ft h es y s t e m ) as y s t e mo f af i n a n c i a lc o m p a n yi sa t y p i c a ll e g a c ys y s t e mt 1 1 a th a se x i s t e df o rt w e n t yy e a r s s o m e o ft h et e c h n o l o g i e su s e di nas y s t e ma r eo u to fd a t en o w , b u tt h eb u s i n e s sv a l u ei t c o n t a i n si sh i g h ，s oi tm u s tb er e e n g i n e e r e du s i n gn e w t e c h n o l o g i e s t h i sa r t i c l ef i r s ti n t r o d u c e st h el a t e s t u p d a t e so fs o f t w a r er e e n g i n e e r i n g ( i n c l u d i n gl e g a c ys y s t e ma n ds o f t w a r er e e n g i n e e r i n gt h e o r i e s ) ，t h ej 2 e ef r a m e w o r k a n di t s a d v a n t a g e s i ne l e c t r o n i cb u s i n e s s a p p l i c a t i o n s ，ar i at e c h n o l o g y 一一 m a c r o m e d i af l e x ，c i t r i xt e c h n o l o g y ，a n dt h em a i nt a s ko ft h i sr e e n g i n e e r i n gp r o j e c t t h e ni td e s c r i b e sh o wt oa n a l y z et h ee x i s t i n gs y s t e mu s i n gr e e n g i n e e r i n gm e t h o d s b a s e do nt h a t ，i td i s c u s s e sh o wt od e c i d et h es t r a t e g yo f f o r w a r d e n g i n e e r i n gu s i n gt h e r e s u l t so fr i s ka n a l y z i n g ，p r o p o s e st h ej 2 e e f l e xs o l u t i o n ，a n da l s op r o p o s e st h e c i t r i xs o l u t i o nt os o l v et h ec r i t i c a ln e e d si nt h es h o r t t e r m ( b e c a u s et h ej 2 e e f l e x s o l u t i o nn e e d sl o n g e rt i m et ob ei m p l e m e n t e d ) t h e ni ti n t r o d u c e st h ea r c h i t e c t u r e d e s i g na n d c o d em o d u l es t r u c t u r eo ft h em a i ns o l u t i o n ( j 2 e e f l e x ) ，a n dt h e i m p l e m e n t a t i o n ：c o d ei m p l e m e n t a t i o n ，t e s tp r o c e s sa n dp r o d u c t i o np l a n ；i ta l s o i n t r o d u c e st h ec i t r i xs o l u t i o n n e x ti tc o n c l u d e st h ec r e a t i v ei d e a sa n dp r a c t i c e si nt h i s p r o j e c tf r o mb o t hm a n a g e r i a la n dt e c h n i c a lp e r s p e c t i v e s i nt h ee n d ，i td r a w s c o n c l u s i o no nt h el a s tp h a s ea n dp r o s p e c t sf o rt h ef u t u r ew o r k k e y w o r d s ：s o f t w a r er e e n g i n e e r i n g ，j 2 e e ，r i a 第2 页共6 2 页 浙江大学硕士学位论文 第一章背景 现今计算机科学技术的发展日新月异，在金融应用领域中，许多承担核心 功能的系统都因技术和体系架构过时，逐渐不能满足金融业务上的需要，因此 需要用新技术对其进行再工程。近年来j 2 e e 技术逐渐兴起并成为业界标准，基 于j 2 e e 的企业应用日益增加，越来越多的企业将其作为新系统的标准开发平 台。而“丰富因特网应用程序”( r i a ) 是近年来业界流行的一个新理念，即 在界面上给用户更好的视觉感受。m a c r o m e d i a 公司推出的f l e x 技术，成为很多 希望让用户界面更友好的软件开发商的选择。 a 系统是某金融公司开发和维护的一个遗留系统。从业务上看，a 系统有 很高的商业价值，和公司的业务紧密结合在一起：从技术上看，该系统是2 0 年 前开始开发的，并且经历了很多并不规范的修改，它所采用的技术和架构设计 都已经不能满足业务上的需要，特别表现在系统性能、系统可靠性和与其它系 统集成等方面。a 系统中的子系统b 是给客户使用的一个子系统，是a 系统改 造中首当其冲的部分。 1 1 软件再工程( s o f t w a r er e e n g i n e e r i n g ) 1 1 1 遗留系统和软件再工程 遗留系统 对于遗留系统，学术界有着多种不同的定义，最简单的定义来自于 b e n n e t ：“遗留系统是对组织很重要，但我们又不知道该如何去对付它的大型 软件系统。” 在线字典f o l d o c 从经济和技术的角度将其定义为“一种( 相对现代技术 而言) 缺乏竞争力和兼容性，但是由于替换或重新设计的成本很高，又不得不 持续使用的计算机系统或应用程序。这意味着，该系统是庞大，高耦合和难以 修改的。” 第5 页共6 2 页 浙江大学硕士学位论文 b r o d i e 和s t o n e b r a k e r 从商业需求的角度给出的定义则是， “任何难以修改 和演化以满足不断产生的新的商业需求的信息系统。” 遗留系统一般来讲，具有以下几种特征： 系统庞大。这样的系统往往不仅代码量庞大，并且包含多种( 各个时期 的) 平台和技术。 系统使用的是陈旧的专有的技术( 如平台，程序设计语言等) ，与其它 的外部系统和新系统越来越难以集成，甚至很难找到合适的技术人员来 从事维护工作。 运行和维护了很长时间，并且在这个过程中，由于担心破坏原有功能， 新的功能零散地、以一种破坏原有系统设计的方式被集成到原有系统中 去，导致原有的体系结构不断退化。 信息的丢失。由于文档缺失或未及时更新以及人员变化等因素使得有关 系统需求、设计和实现等信息不断丢失，以至后来的人员越来越难以理 解原有系统，也更加重了上面一种情况发生的可能。 该系统有很重要的商业价值，任何停止或危害到系统运行的行为都是不 可接受的。这不仅导致系统一直不能被淘汰或被替换，并且使决策者出 于风险的考虑很难决定对系统进行根本性的改造。 遗留系统既然称之为系统，从广义上讲既包含软硬件等技术上的因素，也 包括决策人员、运行维护人员以及系统所处的商业环境。本文主要结合具体再 工程任务，从其狭义上进行讨论，即一个陈旧的、难以修改和维护的关键软件 系统。 软件再工程 由于遗留系统所具有的重要商业价值，建设这些系统就能提供可观的业务 价值，所以必须对它们进行现代化改造或者替换。软件再工程就是在这样的一 个背景下诞生的。 软件再工程是改造软件的一种方法，即通过使用新的技术和工程实践来改 善遗留系统各方面的能力、提高遗留系统的可维护性。美国c a r n e g i em e l l o n 大 学r e e n g i n e e r i n gc e n t e r 的专家们曾这样定义 6 ： “软件再工程是对一个既存系 第6 页共6 2 页 浙江大学硕士学位论文 统进行体系改造，以实现运转质量、系统承受力、功能性、表现性能、在低成 本条件下的可扩展性、时间安排和客户风险等方面的改进。” 再工程所面对的不是建立一个系统的原始需求，而是已经存在的遗留系 统，是从遗留系统到新系统的过程。为了与软件系统从无到有的第一。次开发相 区别，有必要引入以下概念：【1 4 逆向工程( r e v e r s ee n g i n e e r i n g ) ：即对既存系统的分析过程，明确系统 各组成部分及其相互间的关系，并将系统以其它形式来表现。 正向工程( f o r w a r de n g i n e e r i n g ) ：由抽象的、逻辑性的设计逐步展开， 直至具体代码实现的开发活动，即从需求规格设计到产品初次发布的过 程或子过程。 再工程( r e e n g i n e e r i n g ) ：是对既存软件系统进行调查，并将其重构为 新形式代码的开发过程。逆向过程从源代码出发，旨在取得高一级抽象 成果，再工程根据对对象系统更深层次的理解将其重构为另一种形式的 软件产品。即：再工程= 逆向工程+ 正向工程。 在过去的几十年中，很多大型商用系统经过长时间的使用变成了遗留系 统，因而对他们进行再工程的需求也是非常大的。 虽然这些遗留系统各自的情形都不尽相同，但对他们进行的再工程可以主 要分为三类【1 4 】： ( 1 ) 适应性维护的再工程 伴随硬件和操作系统更新换代的软件维护。例如p c 机换u n i x 工作站、 w i n 9 5 换w i n x p 所带来的软件维护。 业务环境变化带来的软件维护。例如由于企业业务的发展和系统使用年 限的增加，既存系统的存储媒体和数据管理系统满足不了数据量及其种 类剧增的要求，需要更新数据库系统；随外部条件变化而必须修改部分 数据变量定义或算法，例如征收消费税的法律修订、邮政编码位数改 变、千年虫问题等。 系统运行环境变化带来的软件修正。如由主机方式变为客户端服务器方 第7 页共6 2 页 浙江人学硕士学位论文 式，由客户端且臣务器方式变为w e b 方式，这时的系统体系结构必须做相 应的改变。 适应系统开发环境变化的软件维护。有一些软件，主要是定制软件，如 e r p 软件等，其软件再工程常伴随企业的b p r 发生，所以丌发环境也需 随经常性的系统完善性再工程而更新，譬如p o w e r b u i l d e r 等开发环境的 升级换代如同操作系统一样频繁发生。 ( 2 ) 完善性维护的再工程增加或修改功能t 以提高系统的安全性、处理能 力等性能。 ( 3 ) 预防性维护的再工程为了提高可维护性而对系统进行优化( 再结构 化、再标准化等) ，对文档进行重构，对数据进行重组。 1 1 2 改造策略分析 改造一个遗留系统可以有很多方法，取决于系统的技术质量、业务价值、 以及维护和操作该系统的组织的特点等多种因素。【1 n o l a n n o r t o n & c o 【2 】提供了一种比较技术质量和商业价值的实践方法， 即把对技术质量和商业价值的评价投射到一张象限图上。绘制一张这样的象限 图( 如图1 所示) ，并将4 个象限的交叉点定为优劣临界点。把一个系统定位 在其中一个象限中，并根据系统所处的象限，制定一种合适的改造策略。 技术质量 象限2象限l 业务价值 优劣临界点 象限3象限4 图1 第8 页共6 2 页 浙江大学硕士学位论文 1 2 2j 2 e e 的四层模型 j 2 e e 平台使用多层分布式应用程序模型，根据功能的不同把应用程序逻辑 划分为各个组件，j 2 e e 应用包含的各个应用组件根据他们所在的层分布在不同 的机器上。现在j 2 e e 的多层企业级应用模型将两层化模型中的不同层面分成许 多层，一个多层化应用能够为的每种不同服务提供一个独立的层。下面介绍 j 2 e e 典型的四层结构： 1 6 运行在客户端机器上的客户层组件 运行在j 2 e e 服务器上的w e b 层组件 运行在j 2 e e 服务器上的业务逻辑层组件 运行在e i s 服务器上的企业信息系统( e i s ，e n t e r p r i s ei n f o r m a t i o ns y s t e m 、 层软件 j 2 e e 应用程序1 j 2 e e 应用程序2 _ 。一 客户层j 衰矿 圈圈雎层 图2 j 2 髓 服务器 数据库 服务器 客户层组件：j 2 e e 应用程序可以是基于w e b 方式的，也可以是基于传统方 式的。j 2 e ew e b 层组件可以是纯粹的h t m l 页面或混和( 动态) h t m l 。对于 终端用户来说，纯粹的h t m l 方法效率不高，因为所有的操作都会需要服务器 的干预。相对来讲，混和客户端的方法更加方便用户，因为与服务器之间的信 息往返相对较少。 第】o 页共6 2 页 层 层 b 懒 崎 回虽习 浙江大学硕士学位论文 表示层组件：表示层生成了w e b 层的页面及页面中的动态内容。动态内容 通常从数据库获得。表示层的另外一个任务是把客户端传来的w e b 页面所包含 的请求进行打包。 业务层组件：很多应用逻辑都位于业务逻辑层中，由运行在业务逻辑层上 的e n t e r p r i s eb e a n 进行处理。有三种企业级的b e a n s ：会话( s e s s i o n lb e a n s ， 实体( e n t i t y ) b e a n s 和消息驱动( m e s s a g e d r i v e n ) b e a n s 。这些b e a n s 完成的 业务逻辑包括：执行全部必须的计算和动作，工作流管理( 包括跟踪会话数 据) 和表示层中全部数据访问的管理。比如，e n t e r p r i s e b e a n 从客户端程序接收 数据，进行处理( 如果必要的话) ，并发送到e i s 层储存，这个过程也可以逆 向进行。 e i s 层( 数据访问层) ：数据访问层负责数据管理。设计人员应该尽量把 动作和业务逻辑与数据访问层分开，这样不仅使e i s 层的开发人员可以专注于 保证数据库访问模块的坚固性和高效性，更使得业务逻辑和数据的访问都成为 可以重用的独立模块，大大降低了程序之间的耦合度，从而提高了开发的效 率。 正是j 2 e e 的这种基于组件并且具有平台无关性的结构使得j 2 e e 程序的编 写大大简化，因为如上所述，数据库操作和业务逻辑被封装成可重用的组件， 整个业务逻辑层被从资源管理的需求中分离出来，并且j 2 e e 服务器以容器的形 式为所有的组件类型提供后台服务。这样，相当一部分的工作被j 2 e e 体系架构 封装或是由专门的开发人员来完成，其他的开发人员在开发中就可以直接使用 这些组件和服务，从而更方便地构建各自负责的模块。 基于上述原因，j 2 e e 成为很多开发大型商用系统的公司的标准开发技术， 也成为我们进行再工程的首选技术。 第1 1 页共6 2 页 浙江大学硕士学位论文 1 3m a c r o m e d i af l e x 技术 “丰富因特网应用程序”( r 1 a r i c hi n t e m e ta p p l i c a t i o n ) 是一个近年来 被提出的新概念，即给用户更丰富的界面观感等体验。m a c r o m e d i a 公司的f l e x 技术就是一种比较流行的r i a 技术，开发者可以用它来开发新一代的“丰富因 特网应用程序”。 如【5 中介绍，m a c r o m e d i af l e x ( 以下简称f l e x ) 是一个在j 2 e e 应用服务 器或s e r v l e t 容器中安装的展现服务器。它拥有丰富的用户界面组件，用于排布 这些组件的标记语言，以及可以处理用户交互的面向对象编程语言。这些技术 使我们既可以使用f l a s h 播放器来支持丰富因特网应用程序，又可以使用工业标 准和开发者熟悉的方式进行开发。f l e x 语言利用了两个流行的开发范例：标记 语言( 例如h t m l ) 和面向对象程序设计语言( 例如j a v a ) 。标记语言被证明 是成功的，并且在布置应用程序用户界面时相对容易。m x m l 是由f l e x 引入 的、基于x m l 的标记语言，将延续其成功。和h t m l 类似，可以用m x m l 来 排布应用程序的用户界面。作为基于x m l 的标记语言，m x m l 比h t m l 有更 完备的结构和更少的歧义。m x m l 还引入了比h t m l 更丰富的标签集，如 d a t ag r i d ，t r e e ，t a bn a v i g a t o r ，a c c o r d i o n 和m e n u 等等，这些都是标准标签 集中的一部分。根据需要，开发人员还可以扩展m x m l 标签，创建自己的组 件。但二者最大的区别是，m x m l 定义的用户界面是用f l a s h 播放器运行的， 相对传统的基于h t m l 、页面为中心的w e b 应用而言，这将更具吸引力。当一 个用户首次请求访问某个m x m l 页面的时候，服务器会将m x m l 代码编译为 f l a s h 字节码( 一个s w f 文件) 。然后服务器将产生的s w f 文件发往客户端， 让f l a s h 播放器执行。后来的对同一个m x m l 页面的请求，服务器将跳过编译 过程，直接返回相同的编译结果，因此f l e x 的用户往往会发现同一个程序的紧 接着的第二次访问会比第一次访问快，就是因为省去了编译的时间。 标记语言提供的编程逻辑仍难以满足用户交互的需求，因此通常用a c t i o n s c r i p t 编程语言来编写事件监听器来满足此种需求。a c t i o ns c r i p t 是一种基于 e c m a 一2 6 2 标准的、区分数据类型的面向对象语言，和j a v a 有些相似，因此也 比较容易学习和掌握。 第1 2 页共6 2 页 浙江大学硕士学位沦文 当编写一个f l e x 的应用时，需要用m x m l 来设置用户界面，并用一个相 应的a c t i o ns c r i p t 来编写响应用户交互的逻辑。开发者可以用自己所熟悉的 1 d e 或者文本编辑器来手工编写m x m l ，也可以使用f l e x 支持的“所见即所 得”的集成开发环境f l e xb u i l d e r 。f l e xb u i l d e r 提供可视化的集成开发环境，开 发人员可以将界面组件直接拖动到页面上需要的位置，并通过设置栏调整界面 组件的属性。在完成一个页面的设计后，可以预览该页面，也可以使用s p l i t ( 拆分) 视图，同时显示代码和该代码对应的预览。 1 4c i t r i x 技术 w e b 程序的最大好处是用户不需要在本地安装软件，更不需要考虑软件的 版本控制等问题，而对于单机版的程序和架构不好的客户端服务器结构的程 序，使用c i t r i x 技术对其进行向w e b 方式( 浏览器朋匣务器结构) 的改造是一种 简便的选择。 c i t r i xm e t a f r a r n e 是一种可以将企业应用以w e b 化方式快速部署的新兴技 术。通过这种技术，可以在很短的时间之内将企业的往妊懿泓誉矗韩譬：基涝搿潆灌国 x 浙江人学硕士学位论文 1 5 再工程任务描述 1 5 1a 系统 a 系统是一个典型的遗留系统，已有近2 0 年的历史。a 系统承担着为客户 产生每季度的投资分析报表的任务。每个季度结束时，客户公司需要对其管理 的投资经理的投资效益做出评价，a 系统就是根据从客户公司和其它一些来自 外部的数据输入，经过复杂的计算，然后通过专门的报表生成引擎根据用户的 不同要求产生各种不同的报表。 由于这个系统存在的时间很长，已经经历了数次大的修改，而这些修改大 多没有很详尽的文档描述，再加上a 系统的几个子系统采用的大多是十几年前 的老技术，现在已经很少能找到懂这些技术的人员，所以已经成了一个高度不 可维护的系统。因此，在考虑了现有系统维护和新需求的实现等方面的问题 后，业务部门提出了对a 系统进行技术改造的要求。 1 5 2b 系统及其再工程任务 b 系统是a 系统的子系统，主要供用户输入每季度的交易数据和对需要产 生的报表进行定制。 现有的系统主要存在三大问题： 第一，原有的系统采用m i c r o s o f tv i s u a lb a s i c 技术，数据库使用m i c r o s o f t a c c e s sd a t a b a s e ，主要是一个单机版的客户端j n 上处理上传和下载过程的服务 器，勉强构成一个客户端服务器结构，由于客户端需要安装，因此保证各个用 户( 大概有1 0 0 多个) 使用的版本统一成了很大的问题。尤其是每个用户的系 统环境都有所不同，在很多情况下会出现安装失败的问题，这也使新版本的发 布有了非常大的障碍，从而用户的新需求得不到很好的满足。 第二，原有系统对用户输入数据的上传处理速度很慢。当季度末，所有的 用户都在向系统中输入数据，而且都在向服务器上传时，服务器处理的速度远 远达不到用户的期望值。而按原有系统的设计，用户甚至不能查询处理的进 度，因而更加重了用户的不满。业务部门的同事希望通过我们技术部门的努 力，解决旧技术或是旧体系结构带来的性能问题。 第1 4 页共6 2 页 浙江大学硕士学位论文 第二章再工程方案 软件再工程过程中存在着四种软件的抽象层次：公理系统( a x i o m s ) ，需求 ( r e q u i r e m e n t s ) ，设计( d e s i 9 1 1 ) ，实现( i m p l e m e n t a t i o n ) 。我们可以认为 这些抽象层次是再工程过程中三种基本操作的产品，即：r e v e r s ee n g i n e e r i n g ( 逆向工程) ，f o n a r d e n g i n e e r i n g ( 正向工程) ，以及t r a n s f o m a t i o n ( 转 化) 。 图3 是一个通用的软件再工程模型的图示： 髫 重新思考 。 重新制定 。 重新设计 。 实现 重新编码 实现 遗留系统目标系统 图3 它形象地描述了软件再工程实践的三个主要阶段，依次分别是逆向工程阶 段、转化阶段和正向工程阶段。从分析的力度出发，可以将再工程的实践过程 分为三个层次，由具体到抽象分别是代码层次、功能层次和架构层次。 2 1 原有系统的逆向工程 在项目刚开始的阶段，由于对既存系统一无所知，很重要的一件事是理解 和学习这个系统是怎样运作的。因此不仅要从技术上理解软件所用到的各种技 术( 编程语言、编程环境等) 以及代码的结构，更要从业务上理解软件的业务 功能和蕴涵的商业价值。在软件工程中，逆向：f 程( r e v e r s ee n g i n e e r i n g ) 可用 于描述分析和理解软件系统和其结构原理的过程，更多的应用于辅助系统的维 第1 6 页共6 2 页 浙江大学硕士学位论文 咨询相关开发人员：在研究代码的过程中，往往会碰到无法理解原有代 码的情况，这时咨询原来的开发人员就是很好的办法了。但是在过去的 十几年中，开发该系统的技术人员有了很大的变动，即使是资历很老的 开发人员，个人所掌握的知识也是不完全的。于是我们安排了每周一次 和原来的开发人员轮流进行交流( 电话会议) ，以期获得更完整的技术 方面的帮助。 我们在结合上述目标和途径的基础上，经过三个阶段的工作来完成该系统 的逆向工程： 代码分析阶段：这个阶段主要是读懂代码。经过这个阶段，对该系统所 采用的主要技术、源代码结构等有了一个总的了解，并且把代码按功能 模块进行整理。 业务功能分析阶段：这个阶段主要是理解系统的各种业务功能，了解相 关业务领域，理解业务功能蕴涵的商业价值。对于一些功能的细节，可 参考代码分析的结果进行还原。经过这个阶段，基本上还原了系统的需 求，以功能说明书( f l l i l c t i o n a ls p e c i f i c a t i o n ) 的形式来描述。 重建系统架构：在上述两个阶段的基础上重新构建软件架构，我们的目 标是绘制软件架构设计分析图来表示系统原有的架构。 2 1 1 代码分析阶段 该系统是一个通过文件传输实现沟通的客户端服务器结构的软件，客户端 是用v b 编写的，并在客户端配有一个m i c r o s o ra c c e s s 的用户数据库，服务器 端是用a l p h a 平台上的c 和f o n r a l l 编写的，数据库是用r d b ，有大量嵌入在 f o n r a l l 代码中的s q l 代码。代码分析从客户端和服务器两个方面入手。 客户端代码 该系统的客户端代码是在w i n d o w s 平台上用v b 实现的。这部分代码是 我们需要移植的主要部分。经过分析，我们得到代码的主要结构如图4 所 刁： 第1 8 页共6 2 页 浙江大学硕士学位论文 各种不同的f o r m ( 表单) 文件 t m 1s d 0 n s o ra c c o u n tr e d o n i n i d a o 和d e f d a o ( d a o 层) 图4 如图4 所示，用户可见的是一些f o m ( 表单) 文件，而这些程序调用各 自相应的模块( m 1 ，s p o n s o r ，a c c o u n t ，r c p o r t ) ，进而调用底层的d a 0 完成 数据库操作，将数据读出或存入本地的a c c e s s 数据库。 服务器代码 服务器端的代码是在a l p h a 平台上用c 和f o n r a n 实现的。代码的功能很 简单，就是完成用户上传文件的处理。但由于代码量大等原因，移植成了一 个很大的问题，在4 1 2 节中将详细讨论该问题。 2 1 2 业务功能分析阶段 业务功能分析阶段发生在代码分析阶段完成之后。在这个阶段，不但要整 理出系统支持的所有业务功能，而且要理解每个功能以及它的商业价值。 在和美国业务部门的同事讨论后，我们得到了该系统的一个大致的商业流 程，如图5 所示： 第1 9 页共6 2 页 浙江人学预+ 露待荔誊 岩溪鲺戮f l e x 图鞠兰添；淄滞m x m l 叫澎潘溺哆滴鏊：哩囊“峨嘲 刍薹| 薹a c t i o ns c r i p t 露冀蓠鎏譬鹭誓熬黔鞲，卢璃。哥壤嚣嚣鲦毯芝k 翳霞蠢蘑 1 d e 甏嚣鞫鞠登盼誓铋日月藕揣测m x m l i 醴m 疆醴翳f l e x 黻潺爱8 豁强掣叁 藉。希耐瞄霉蹦爱葡f l e xb u i l d e r 。f l e xb u i l d e r 萋璧雾蕊蕤囊萋蠢强麓鄹翳j 是 奁不稳塌篓蒸罄鬻军妻蕊橥箨嚣瑟疆擐铡垡墨瑟器软= 擎裂矧削霸翳邑疳耄嘲 硐强j 崾瞪。强删一嘿啷4 撼遵瀚磺二鲤秀发结构与艨j 啦而妊樨曩s p l i t i 舔弘；鲷静，瑚醪翘鳓敛褂骄髟髓潞汹霸辩镌餐。 1 4c i t r i x 羹鋈 w e b 稍潆淄圆髑捌噌喧遂茹唱灞澎疆煤臻淫滗窖型j 引琵器习蔼翟蟮曦瞪 礴固滋澎登霎| 楚j 每誊涸簸疆薹黪彰酲苗晒髫懿秘赣秘舞酯弘潍登骥黟文翼懿 舅j 瑟瓣c i t r i x 碧静瞪燮蟊霎w e b 艋治鲤皋努魈霉盟荔辖誊l 鹾明目则秘 陋驯毽杰； c i t r i xm e t a f r a r n e 垒一勰麓冬萋霉金鍪鏊麓w e b 螽豢写京耀这冗令强熏爨 嚣j 这辑毽薷驻并；彰疋鼾博m 爱戮羹鸶剁翟未 往妊懿泓誉矗韩譬：基涝搿潆灌国 x 浙江人学硕士学位论文 d 系统主要给业务部门的c l i e n ts e r v i c e ( 客户服务) 人员使用。当用户使 搿察户溃滋现趣题融，客户鼹务人爨霹以遁过d 系统嫠用户诊叛瓣蘧，或磐壹 按帮用户完成失败的操作。 定期数摇楚毽模袋是鞠当重要躯一个舔台模块，蠲户簿季度一次自系统孛 输入该季度的投资数据，系统也会从一些其它的途径获得一些相应的金融数 描，然后数据处理模块会对这些规模庞大酌数据进行处理，并产生相应的标准 报表( s t a n d a r dr e p o n ) 。 c 系统是另一个有客户端的软件，用户在通过客户端输入数据后，可以通 过c 系统产生定剖擐表( c u s t o mr e p o r t ) ，并显示蠛下载。 作为个投资效益分析系统，a 系统需要大量的数据来得出结论。b 系统 楚这些数捺最主要瓣寒源，磊另一罄分裂怒乡 部数据输入。当这些数据被扶终 部母入时，a 系统的后台穰序有相应的模块处理它们并存放在a 系统的数据库 串。 2 。l 。5 整体架构秘运佟方式 综上所述，我们大致了解了b 系统的繁体架构和运作方式： 该系统的整体架构包含两部分：前端( 客户端) 和后端( 数据处理端) 。 客户端是一个用v b 开发的零枫舨程序，竣入蛇数擐存放在客户彰1 芝夔a c c e s s 数据库中。后端是一组用c 和f o r t r a n 编写的可执行程序。最终由c 和f o r t r a n 编写熬霹执行程寒将建户主转葭数攘夺入黻务器上熬r d b 数撵瘁中。 第2 2 页共6 2 页 浙江大学硕士学位论文 系统内部工作方式及运行环境如图7 所示 服务器端c 程序进行 处理 一 _ i - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 一 服务器端c 程序产生 用户所需的文件 a c c e s s 数据库 客户端 服务器端 a 系统 r d b 数据库 幽7 用户通过前端输入数据，并保存在本地的a c c e s s 数据库中。当数据经过验 证无误后，用户操作客户端程序产生相应的数据文件( d a t af i l e s ) 并通过实现 在客户端程序中的模块通过f t p 协议上传至服务器端，然后客户端程序会自动 通过远程调用( r e m o t ec a l l ) 唤起服务器端的可执行程序，这些可执行程序负 责解析上传的文件，将其数据进行相关的计算，并存入数据库。 用户可以通过前端下载( 同步) 服务器端的数据：用户选择下载后，本地 程序产生指定格式的请求文件( r e q u e s tf i l e ) ，并上传到f r p 服务器上。服务 器扫描到这些请求文件后，从数据库选出相应的数据，产生用户需要的数据文 件并存放到f t p 服务器上。而本地的程序负责从f t p 服务器端将这些数据文件 下载到本地。这些标准格式的数据文件可以被导入到客户端的a c c e s s 数据库 中，或者导入到用户所需的其它系统中。 a 系统的主要功能就是为客户产生报表。经过分析，b 系统和a 系统中其 它组件协调工作产生一个报表的过程如图8 所示： 第2 3 页共6 2 页 浙江大学硕十学位论文 图8 在b 系绞受黉将本季凌熬擐表数据积掇表定剿绩惠都辕天裂r d b 数援疼 后，一个预先提交到队列( q u e u e ) 里并被定期唤起的处理报表的横块对这些数 爨送行受爨豹处理帮诗算，菇产生s a s 弓| 擎能够谈臻静中麓文律。s a s 弓 擎在 处理了这些中间文件后，产生出一定格式的报表，如果用户需要p d f 格式的报 表，鲻再经过专门的裰务器上静p d f 弓i 擎将报表转换成p d f 格式，最终这些产 生好的文件存放在文件服务器上，并通知用户。( 用户通：i 建客户端也可以适上 服务器，看到自己的文件夹下是否有已经产生的报寝) 2 2 业务新需求分析 在我们对原有系统进行逆向工程的同时，业务部门也给我们提出了功能、 蛙熊方蘑静一些瑟敬要求，墓蘧，我髓在辩添毒系统进行数务嚣求建攘豹鏊臻 上，也需要考虑对新的业务需求建模。与逆向过程中的业务劝能建模不同，对 薪需求稳分季厅和建模寒溪予潼务部门疆据熏户豹需爨撵击静盈务需求。 业务需求建模魁一个对系统业务需求深刻理解的过程。业务对象和业务过 程( 韭务逻辑) 是建模过耧中必须整考虑到的两个蕊要因素。业务对象是对业 务中各种出耀的实体的描述和定义，比如a c c o u n t ( 投资帐户) 、h o l d i n g ( 持 有的股票或其它投资工具) 簿；业务过程则是业务人员操作这些业务对象的一 第2 4 页共6 2 页 潺汪火学硬士学位论文 就像这样，我们对每个新需求郡作了详细的分析，直到弄清每步用户操作 所对应的系统反应动俸，并采嗣6 1 2 节详细讨论静需求确认流程辩需求的了解 进行完善，确认我们对新需求的理解和业务部门以及用户都蹩一致的。这样就基本完成了对新需求静分轿阶段工律。 2 。3 正觑工程策赡分析 软件开发是一个型新耍茧掣基划j 明瞪馑煺琴蒿珏离辩翳甄鞭列馨髂x 醯盟 委琴雕蛩饱南嘎嗡嘞滋趣羹”戛。 薹i 誉j i 蓥耋羹鬟螽 禚薹i 葫活耋耋蚓霸河融磋弛谚携塑静霓融! 面甜时 囊骱疑嚣糖雅肚吵蚓醣! 青淄臻篇舔稍信霪蓬；耧蘑薷骄锺则置要惺证簧璎墨匿晴终幂一击訾器銎跫嚣 絮。籼d 赫骺抹涨为始祥疑瀚艉丽。艨菌澜薛潲斟鞫静偶薹h 弼“艘理即殂； 掣珏绥甑矮警簟矗 开发阶段的分 工问题，尽量使模块的划分和接口的定义符合单独编码、协同开发、模块尽量 重用的原则。最终我们把多层结构的设计表示在一张架构图中，以使参与各个 部分的技术人员都能对项目有整体上的把握 。 3 2新系统的架构 在综合考虑上述各种设计因素后，我们按照2 4 1 节提出的j 2 e e f l e x 解决 方案，设计出新系统的 4 1 节提出的j 2 e e f l e x 解决 方案，设计出新系统的架构，如图1 2 所示： 第35页共62页 x 浙江大学硕七学位论文 险策略实施的有效悔。c r m 模型要求在项目生命期的所有阶段都关注 强黢识别鄂蛰理，它将冤睑管理划分先五个步骤：风险识别、分摄、计 划、跟踪、控制。 s b r t m ( s o f t w a r ee n g i n e e r i n gr i s km o d e l ) 模壅 s e r i m 从技术和商业两个角度对软件风险蛰理进行剖析，考虑的问题涉 及开销、遂发、技术性能等。它还擒供了一筵指标和模型采估量和预测 风险，由于这些数据来源于大量的实际经验，因此具商很强的说服力。 b 系统的蘑工攫是一个风险缀离但是可控的项强。因此，在项强数簧港验 制定过程中借鉴了上述风险管理模型提出的分析原则，而且结合实际情况进行 了改造。参考f 1 1 0 2 ，我 | 、】分援了这次豹霉工程矮嚣中霹缝存在熬最险，著对 各个可能的方面的风险总结如下： 诗捌编翻燕猃 由于不确定因素较多，加上我们对将疆使用的新技术f l e x 的了解也 狠有限，估算顼霹时间表就帮一定的风险。项目开始一段时阀后我们会 给客户傲一个d e m o ( 演示) ，客户的反应如何也是寒知数，计划必须根 据客户的反馈作相应的修改。 人员风险 因为项目涉及到一些a l p h a 平台上的技术，能否找到相关的技术人员就 是令缀太豹瓣蘧。魏莱不戆撬到有经验赘技术久员，鄂藏需婺授入入力 物力在相关技术的培训上。 舜爱环境风羧 由于对原有系统在a l p h a 平台上所使用的技术( f o r t r a n ，r d b 等) 不了 解，我们也存在着开发环境的风险。 客户风险 由于我们的客户在美国，而麒我们是通过美圈的业务部门与客户交流， 繇毁容户答笈豹爨瀛( 魏露答或澄潼与嚣求撵关窝透煞 x 浙江大学硕士学 征论文 设计和实现风险 由于原来开发v b 的代码时使用了第三方库( t h i r dp a r t yl i b r a r y ) ，在 f l e x 技术中不一定能找到这样的组件，可能需要自己开发。由于我们对 f l e x 技术还不够了解，在设计整体架构时不一定能一开始就做到最优， 可能以后还需要调整。 下面着重讨论一下因需求导致的风险。因为我们对老系统还不了解，应该 说再工程的初始需求就不够明确。而业务部门也有提出新需求的需要，其中有 很多的不确定因素。因此而导致的风险主要有两点： 时间风险：该需求需要多久能完成，即对需求的任务量的估计。 需求的准确性：用户到底需要的是什么。 对软件需求的“量”的分析，控制了项目进度，从而能减少软件项目的时 间风险。对软件需求的“准确性”的分析，澄清了软件使用者对系统的预期是 什么，从而减少了需求准确性的风险。许多软件项目就是由于需求确认过程不 够严密，或者对需求的描述不够充分，从而项目无法按时完成，或者做完的项 目无法满足用户的需要，导致了失败。 在遗留系统的再工程中，大多数现有的业务规则和知识需要保留，所以大 多数需求都是从遗留系统本身派生而来。在很大程度上，遗留系统具有固定的 标准需求。因此，典型情况下，再工程是向着改进系统质量，例如可维护性、 易于使用或者改善性能而努力。从遗留系统派生需求的风险在于，过时的或低 效的模块不能被改进或淘汰。 在a 系统这样的金融系统中，就存在着这方面的情况，部分原因是业务流 程的变化。由于该系统的初次建立是在近2 0 年前，当时的业务流程和业务逻 辑，到了今天必然有很多的变化。当时的整个体系架构，都是为适应当时的业 务流程和业务逻辑而建立的，而在这些年中历经的多次修改，大多是只针对表 面的功能，而没有对基本的体系结构有根本性的改造。而这次的软件再工程项 目中，区别于以往“补丁”式的修改，我们被要求对a 系统做根本性的改造， 即对体系架构进行调整。而原有的体系架构中有很多对今天的使用者来说是冗 余的部分，我们也要将其准确地剔除，而不能将其也一并重新实现到新的架构 第2 8 页共6 2 页 浙江大学硕+ 学位论文 中去。而要做到这点，必须对业务上的变化有非常清楚的认识。这样，对业务 流程和业务逻辑的新旧对比，就成了一项附加的重要任务。 2 3 2 整体策略 根据上节分析的各种可能的风险，我们讨论制订了项目的整体策略，用流 程图的形式表示如下： 原有系统的代 码结构、业务 逻辑和需求