（计算机应用技术专业论文）交易管理系统重构.pdf

浙江人学硕i ：学位论文 摘要 摘要 软件产品交付使用以后，为了保持稳定运行并适应新的要求，必须进行维护。 在维护的过程中，为了提高软件可维护性并延长软件寿命，需要引进新的技术方 法作预防性维护。重构是预防性维护中的重要手段之一，它不改变软件对外行为 但改善软件结构，因而得到广大软件设计者和工程技术人员的重视，正在软件维 护中发挥越来越重要的作用。 本文分析了一个实际的金融交易软件产品的架构。针对预防性维护中质量改 善和业务合并这两个目标，对软件中的交易规则管理器、对象持久层等进行了重 构。通过和开源规则引擎d r o o l s 比较，指出交易规则管理器的缺陷，并给出相应 重构方案；对于持久层机制，剖析其在实现数据访问的封装中存在的不足，并结 合d a o 设计模式和o r m 技术进行重构。最后基于确定型有限状态机模型，对 m 组件进行再设计。 关键词： 重构，预防性维护，规则引擎，持久层 浙江人学硕+ ：学位论文 a b s t r a e t a b s t r a c t s o f t w a r em u s tb em a i n t a i n e da f t e rd e l i v e r yt ok e e pi ts t a b l ea n du p t o d a t e d u r i n gt h ep r o c e d u r eo fs o f t w a r em a i n t e n a n c e ，n e wm e t h o d o l o g ya n dt e c h n o l o g yn e e d t ob ei n t r o d u c e db yp r e v e n t i v em a i n t e n a n c ei no r d e rt or a i s em a i n t a i n a b i l i t ya n dl i f eo f t h es o f t w a r ep r o d u c t r e f a c t o r i n ga st h ei m p o r tm e t h o d o l o g yo fs o f t w a r ep r e v e n t i v e m a i n t e n a n c e ，i m p r o v e sc o d es t r u c t u r ew h i l ek e e p se x t e r n a lb e h a v i o ru n c h a n g e d i ti s i n c r e a s i n g l yr a i s i n gt h ea t t e n t i o no fs o f t w a r ed e s i g n e ra n de n g i n e e r $ ，w i t hag r o w i n g i m p o r t a n tr o l ei ns o f t w a r em a i n t e n a n c ea c t i v i t y t h i sa r t i c l ea n a l y z e st h ea r c h i t e c t u r eo far e a l - l i f ep r o j e c t ，t r a d em a n a g e m e n t s y s t e m w i t hf o c u so nq u a l i t yi m p r o v e m e n ta n df u n c t i o na c q u i s i t i o n ，i tk e e p s t h et r a d e r u l em a n a g e rf i r m ) a st h em a i nr e f a c t o ro b j e c t d i s c u s s i n gt h ei m p l e m e n t a t i o no f e v e r yp a r ta n dc o m p a r e dw i t ht h es t r u c t u r eo fo p e n s o u r c er u l ee n g i n e ，d r o o l s ，t h e d e s i g nw e a k n e s so ft r m i sp o i n t e do u t ，t o g e t h e rw i t har e f a c t o rp l a n t od e a lw i t ht h e p e r s i s t e n tl a y e ro ft r a d em a n a g e m e n ts y s t e m ，t h ei n a p p r o p r i a t ed e s i g ni nd a t aa c c e s s o b j e c t si se x a m i n e d t h er e f a c t o r i n gp l a ni st oi m p r o v ei t w i 廿ld a t aa c c e s so b j e c t p a t t e r na n do b j e c t r e l a t i o n s h i pm a p p i n g f i n a l l y , f o rt h en i mc o m p o n e n tr e f a c t o r i n g ， ad e t e r m i n i s t i cf i n i t ea u t o m a t am o d e li sa p p l i e da n de x p l a i n e d k e y w o r d s ：r e f a c t o r , p r e v e n t i v em a i n t e n a n c e ，r u l ee n g i n e ，p e r s i s t e n tl a y e r 浙江人学硕 j 学位论文图目录 图2 1 图2 2 图2 3 图3 1 图3 2 图3 3 图3 4 图3 5 图3 6 图3 7 图3 8 图3 9 图3 1 0 图3 1 1 图4 1 图4 2 图4 3 图4 4 图4 5 图5 1 图5 2 图5 3 图目录 交易管理系统与外围系统接口7 交易管理系统架构9 交易管理系统缺陷统计1 2 o r a c l e b r m s 产品界面18 基于规则的系统1 9 d r o o l s 编译系统2 2 r e t e o o 算法2 4 r e t e o o 网络中二输入节点2 7 d r o o l s 匹配和执行部分3 0 t r m 架构3l 规则管理界面。3 8 业务规则执行流程图4 1 移植d r o o l s 解决方案4 5 改进后的移植方案4 6 数据访问类封装5 0 对象一关系映射5 l 交易对象持久化实现。5 4 d a o 模式重构持久层6 0 应用h i b e r n a t e 改进的重构方案6 2 n i m 基本架构6 4 n i mp r o c e s s o r 部分流程图e t s 6 6 e t x 状态图6 8 浙江人学硕：t 学位论文 表目录 表目录 表2 1为交易管理系统提供数据的系统8 表2 2接受交易管理系统数据的系统8 表3 1c o n f i gk e y s 3 9 表3 2v e ti 沁l e s 3 9 表3 3规则引擎优化前后对比4 3 l v 浙江大学研究生学位论文独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的 研究成果。除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发 表或撰写过的研究成果，也不包含为获得澎姿盘堂或其他教育机构的学位或 证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文 中作了明确的说明并表示谢意。 学位论文作者签名： 1 蚕叼 签字日期： 洳莎年g 月7 日 学位论文版权使用授权书 本学位论文作者完全了解澎姿态堂有权保留并向国家有关部门或机构 送交本论文的复印件和磁盘，允许论文被查阅和借阅。本人授权逝姿盘堂可 以将学位论文的全部或部分内容编入有关数据库进行检索和传播，可以采用影 印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文作者躲嗨粤 签字日期：五加3 年月7 日 导师签名： 签字眺础多月夕日 浙江人学硕l ：学位论文 第l 章绪论 第1 章绪论 为了使软件持续稳定的运行，适应新的需要，软件维护是软件工程中必不可 少的一环。并非所有的软件都需要投入大量的成本在软件维护上，但是经验表 明，行业软件，特别是为大型企业量身定做的应用系统，其维护费用比起昂贵的 开发费用有过之而无不及【2 1 。随着多数大型企业的全面信息化，在软件维护上的 投入在信息支出的比例中大幅度上升，软件维护作为一门实践性强的学科受到越 来越多的学者和工程技术人员的重视。 1 1 课题背景 软件维护通常指在软件交付以后对系统或组件的更改，以改正错误，提高性 能等等【引。按照其目的可以分为四类【4 】： 纠错性维护( c o r r e c t i v e ) 顾名思义，就是修正软件中不正确的地方。随着编程经验的积累，程序语言 的进步和测试理论和技术的发展，代码本身的质量已经有了很大的提高。经验性 研究表明，需求理解产生的偏差所导致的软件问题是主要的维护原因。纠错性维 护一般可以在总的维护成本中占到2 0 。 完善性维护( p e r f e c t i v e ) 完善性维护在总成本中占5 0 以上。随着业务的发展，用户会对软件的功能， 易用性，性能等提出新的要求。完善性维护正是为了满足用户的需求，延长软件 寿命所作的维护工作。 适应性维护( a d a p t i v e ) 适应性维护是针对外部环境变化所进行的修改。这可以是硬件上的变化，比 如服务器升级，需要针对多核c p u 做更多优化，或者用户显示器分辨率从 1 0 2 4 7 6 8 更换到了1 6 0 0 1 2 0 0 ，部分w e b 界面需要重新设定最佳显示效果；还可 以是软件上的变化，像数据库的升级导致接口函数需要相应调整等。在所有的维 护活动中，适应性维护占2 5 左右。 i 浙江大学硕士学位论文 第l 章绪论 预防性维护( p r e v e n t i v e ) 预防性维护和其他三种维护目有显著的不同。行业软件的重要特点之一是生 命周期很长，在整个维护过程中，外部世界不断有新的更优秀的软件工程方法和 软件技术产品诞生。使用这些新的技术产品可以提高软件的可维护性、可靠性和 寿命，因此有必要引入这些超前性质的维护工作，来对已有的软件重新设计和编 码。m i l l e r 把预防性维护总结为：“把今天的方案应用到昨天的系统上，以适应将 来的需求”。1 5 】 由于软件开发进度和成本上的压力，相比前三种必需的维护行为，预防性维 护在软件维护的初期常常被置于次要的地位。但是随着维护的深入，维护者开始 面临一系列具有典型性的问题： 架构不适应业务发展的需要； 系统进行初期架构设计时，往往无法预见到未来的业务需求变动和增长，成 为软件开发的瓶颈，增加了维护的难度，降低系统的可扩展性。 组件设计缺陷使增量改动陷入困境； 不少系统架构由专业设计人员开发，具有很好的可扩展性。但是组件直接按 照业务工作流设计，偏重于流程。随着维护的进行和维护人员的变动，代码风格 的不一致使组件越来越难以被设计人员所全面理解和掌握，增量改动的质量难以 保证。 不良的接口定义导致大量的冗余代码； 对于复杂的应用软件来说，关键的接口被大量的类所继承和使用。接口定义 的改动需要进行大量的测试才能保证质量，高额的成本使得管理者倾向于接受冗 余代码，但这些冗余代码进一步增加维护成本。 复杂的业务逻辑规则难以被正确理解和使用。 对于采用业务规则的软件来说，业务规则本身是最难以维护的地方之一。这 些业务规则往往数量巨大又具有很高的正相关性，在应用中难以被正确的理解和 使用。 为了提高软件的可理解性和可维护性，a r n o l d 定义了软件的重建r e s t r u c t u r e 2 浙江人学硕上学位论文第1 章绪论 理论【6 1 。o p d y k e 在面向对象程序中进一步提出了重构( r e f a c t o r ) 这个概念【7 】从 工程技术人员的角度思考面向对象程序的维护和进化问题，受到软件工程界的极 大重视，成为预防性维护最为重要的方法论之一。 1 2 重构 重建是同一抽象层面上表现形式的转换，但保留对象系统的外向行为( 功能 和语义) 。这样的转换往往是程序外观上的，比如结构化程序设计中代码结构的 改善。虽然重建产生了一个新的软件版本或者提出更改的方向，但是它不包含因 为新的需求所作的变动。反过来，它的意义更在于使程序更容易被阅读，从而为 系统改善创造条件。【8 】 f o w l e r 对重构r e f a c t o r 的定义一脉相承【9 1 。他认为这是一个不改变程序外向 行为，而优化内部结构的软件系统过程方法。主要的思路是整理类、方法、变量， 以创造更高的适应性和扩展性。 技术 冗余代码和层次优化是重构的传统技术关注点，f l o w e r 总结了3 2 种重构的 一般性思路【9 1 。随着面向方面编程a o p 的兴起，利用横切点对面向对象程序进行 改造的研究越来越得到各方面的重视。在横切关注点的检测和封装技术上产生了 许多新的工作，成为重构研究的热点。由于面向对象编程中的方法应用到a o p 中可能会破坏切点和与之相连的方面代码，因此有必要对其进行补充和完善l m l 。 工具支持 为了让重构得到更多的工业级应用，拥有一定自动化程度，可以减轻人力负 担的重构工具是必不可少的。根据其智能程度的高低，既有半自动化的如r e f a c t o r b r o w s e r ( s m a l lt a 【) ，也有实现了对继承对象和方法作全自动重构处理的g u r u ( s e l f ) 。把重构工具集成到开发工具中是大势所趋，e c l i p s e 中的w s a d 插件， v i s u a l s t u d i a o 的c 群r e f a c t o r y 。这些工具普遍可以做到对属性、变量、类以及接口 重新命名、移动、抽取等。【l i 】 值得一提的是，从更高抽象层次上的u m l 建模重构工具也开始出现了，可 3 浙江人学硕十学位论文第l 章绪论 以为类图、状态图的重构提供帮助。1 1 2 1 软件重构的意义 软件可维护性是对于软件维护活动的重要指标，主要指维护人员理解、改动 或改进软件的难易程度。i s o i e c9 1 2 6 定义了作为软件质量一部分的软件可维护 性的四个衡量标准：稳定性，可分析性，可更改性，可测试性。软件重构在这 四个方面提高了软件的可维护性。 1 ) 提高可更改性 在进行重构工作的时候，不需要过多地考虑将来的变化，可以把注意力集中 在现在的需求上；对新的需求的更改，可以在已经重构优化的程序上，进行扩展 设计。这样就在一定程度上降低了软件更改的难度，减少了软件维护的成本。 2 ) 提高稳定性 软件重构工作优化了软件的结构，提高了软件的扩展性，更容易引入新的需 求。软件更改的规模更多的决定与需求的复杂度而不是软件本身的结构，更改的 成本更容易被预测，从而提高软件的稳定性。 3 ) 提高可分析性 重构以后的代码具有结构清晰，意义明确的特点。有利于后续开发人员对程 序的理解，缩短对代码的学习时间，从而降低维护成本。 4 ) 提高可测试性 f o w l e r 认为，重构的每一步工作都必须经过严格的测试，当发现问题的时候， 可以在最短的时间内找到引入b u g 的改动点而进行恢复，从而避免了大量的调试 时间。【9 】一个好的重构工作以完善的回归测试为基础，即保证了软件的质量，又 降低了测试的难度。 随着软件丌发越来越强调敏捷性和对需求的反应时间，作为先进开发方法的 重构，由于其在分析和测试上时间短、难度低的优点，也在敏捷开发方法中发挥 越来越重要的作用。1 1 4 】 4 浙江人学硕上学位论文第1 章绪论 1 3 研究内容和目标 交易管理系统是一个已经被维护多年的金融交易软件产品。为了能使系统更 稳定的运行，降低维护的成本，需要对其进行阶段的预防性维护，重构代码，以 改善质量和提高可扩展性。本文分析了该系统的软件架构，针对预防性维护的两 个目标，剖析了软件中的交易规则管理器t r m 、持久层、第三方知会交互模块 n i m 模块等部分存在的缺陷，并给出相应的重构方案。 t r m 维护系统的业务逻辑。本文通过比较它和功能类似的开源规则引擎，分 析t r m 在设计上存在的缺陷并给出重构设计。 持久层封装了交易管理系统访问数据源的方法，但是这种封装和优化设计相 比有相当的距离，有很大改进空间。本文并结合d a o 设计模式和o r m 技术，在 不影响上层组件接口的前提下，提出重构的方案。 n i m 是交易管理系统中一个面向消息的组件，其各个版本经过多名程序员不 同时期的改动，内部的代码结构很不清晰，难以理解和维护。本文应用确定型有 穷自动机的模型，对n i m 进行再设计。 1 4 论文组织 第二章对交易管理系统的软件架构作了分析。针对预防性维护的两个目标， 质量改善和对旧系统的业务替代，选择了架构中相对独立的交易规则管理器和持 久层作为重构的主要对象。 第三章通过比较交易规则管理器和d r o o l s 的实现，分析前者在设计上存在的 问题并提出解决方案。 第四章分析交易管理系统的持久层机制，以交易处理器组件中典型业务对象 i m s t r a d e 的持久化为例，剖析其在实现数据访问的封装中存在的不足，并结合 d a o 设计模式和o r m 技术，进行重构和改进。 第五章应用确定型有限状态机模型，对n i m 组件运行时产生的状态和状态之 间的转换格局作了提炼，给出对这个组件进行再设计的方案。 5 浙江人学硕卜学位论文 第l 章绪论 第六章对交易管理系统的重构工作做一个总结，并展望今后的挑战和目标。 6 浙江人学硕士学位论文第2 章交易管理系统的预防性维护 第2 章交易管理系统的预防性维护 作为知名的机构投资服务提供者，t 银行拥有从投资决策到会计的一系列电 子化服务系统。 交易管理系统在t 银行的机构投资服务系统中扮演中间业务员( m i d d l e o f f i c e ) 的角色。交易管理系统最主要的功能是交易执行和全程控制，拥有丰富 的交易跟踪界面和异常处理机制，使商业用户及其操作员可以实时了解交易的状 态并采取必要的措施。 2 1 交易管理系统介绍 如图2 1 ，交易管理系统把从多个“交易系统”获得来自投资经理的各类x m l 格式的交易单，进行归纳整理后产生会计、托管等业务组件可以处理的输入单据。 图2 1交易管理系统与外嗣系统接口 为了实现这一功能，交易管理系统需要从客户或者第三方输入的参考数据中 7 浙江人学坝1 学位论文 第2 章交易管理系统的颅防性维护 对交易信息进行验讪f 、补充和转译；而从经纪人那里扶得的s w i f t 确认消息叮 以和投资人的交易单进行匹配，为交易的最终确认提供依据：另外，住送达下游 业务系统以后，交易管理系统根据他们的反馈，及时对交易单的信息进行更新； 最后交易管理系统作为直接和操作员打交道的应用系统，可以输入各种奄询条什 查询交易信息，或者在错误处理的界面l ：，接受操作员的授权更f 等等。表2 。1 列出了为交易管理系统提供数据的系统。 表2 1为交易管理系统提供数据的系统 i 鬻囊鹫曛壤囊鬻錾j 数糖类鹜甄铡! 攀鬻。艟二囊媒多f 爹黪i ；撼矗蓊鹾i 麟鬻? r ? 二j = “一 ：，撇i 张。：。糍糟“? 一嚣- 酬劳# 。董三“。：v 。必! 交易系统( 多个) x m l m q 参考数据系统远科凋川返川i c o r b a 经纪人系统 s w i f t 文什 第二力。知会系统i 、。j 户 s w i f tm q 存档管理系统i 、。 户 s w i f tm o 操作员各类人l ：输入 w e bu i 交易管理系统最本质的业务就是对消息格式的转换和信息内容的更新，这些 整理后的信息，冉次被编写为x m l 消息，发往下游系统( 存档，第三方结算， 第三方清算) ；对每1 个和交易管理有业务往来的系统，交易管理以a c k n a k 的形式和他们进j j ：苯本的确认反馈；此外，交易管理拥有直接面向用户的界面， 提供各种查询、跟踪的工具，依据用户的需求，在网页卜产生查询信息。表2 。2 列出了接受交易管卫卫系统数据的系统。 表2 2接受交易管理系统数据的系统 爨黪辫尊霪i 蘩纛鬻 ”数碧民豢赠鬻攀器二瓣鬻i 妻繁瓣鬻囊蒌鬻黪= 篓篓羚鬻： ”i 囊并：；：i | ；j 一二誊、“曩i # “曩警? 一“。i ” | 、_ c 一“一。黛奠 存档箭理系统i j 户 x m l m q 第二力知会系统i j 户 x m lm q 经纪人系统 s w i f ，1 1m q u ij s p | i t m lw e bu i 浙江人学硕士学位论文 第2 章交易管理系统的预防住维护 2 2 架构分析 交易管理系统使用j a v a 语言编写，以适应跨平台的开发和部署环境，是一个 分布式j 2 e e 系统。其架构如图2 2 所示，可以分为五层。 表现层 控制层 业务层 集成层 数据层 图2 2交易管理系统架构 表现层 h t m l 页面是用户基本的交互平台，由s s l 提供会话安全；a p p l e t 和 j a v a s c r i p t 表现动念内容，丰富用户的体验；置于w e b a g e n t 服务器中的j s p ，通 过c o r b a 调用s e r v l e t 实现和后台的数据交换，s e r v l e t 之间的接口也全部使用 c o r b a 实现，耦合度低。 控制层 控制层需要响应两种事件： 9 浙江人学硕上学位论文第2 章交易管理系统的预防性维护 一种是来自w e b 应用层j s p 页面的事件，除了交易监视器发出的简单数据查 询请求外，异常处理和人工确认都会对交易的状态做出改变。 第二种是来自于业务层的事件。作为协调交易管理系统所有组件的中心，事 件管理器几乎和所有其他组件都有接口相连，负责维护交易的各阶段状态。当某 一个组件处理完后，它会把更新信息放入一个公用的m q 中，供事件管理器读取； 而当事件管理器处理完某个事件以后，或者完成一阶段的工作，要交给下一个组 件，他也会通过特定的m q 发给对方；此外，异常处理也是通过类似的机制在事 件管理器中处理。 业务层 业务层的工作流组件面向消息，以服务( 可以是多个) 的形式独立存在于系 统中，通过对m q 的读写，避免了大量的直接a p i 调用；每一个服务内部的错误 不会导致镇整个系统的瘫痪，甚至不会影响到同一个组件内的其他服务，整体可 靠性也得到了提高，具有面向服务架构s o a 的特征。另外，每个服务都可以用 配置文件定义内部的处理器个数，通过简单的增加或者减少处理器，可以优化组 件级别的并行性，平衡系统资源。 集成层 业务层的各个工作流组件在处理交易参数时都需要经过大量的业务逻辑。为 了分离业务逻辑和技术型代码，交易管理系统实现了一套业务规则管理系统，称 之为交易规则管理器t r a d er u l e sm a n a g e r ，把业务逻辑作为单独的对象来维护。 为了业务层可以方便的访问和操作数据库中的信息，即实现对象的持久化， 交易管理系统实现了专门的数据访问接口，分离业务处理和数据库访问的细节， 形成一个对象持久层。 控制层和业务层交互使用m q ，表现层和后台系统交互使用c o r b a ，避免 了对平台的依赖性，大大降低了各个组件之间的耦合度，也易于维护升级。 数据层 交易捕捉器把初步验证后的x m l 信息完整存储卜来( l o b ) ，这是交易第一 次出现在交易管理的数据库中，以后都是通过存储增量信息来更新它；业务规则 l o 浙江人学硕士学位论文 第2 章交易管理系统的预防性维护 库存储被分离出来的业务逻辑，供交易规则管理器使用：其他的一些数据，如参 考数据，则由外部系统提供。 2 3 预防性维护目标 进入2 0 0 6 年以后，交易管理系统的业务量持续增大，服务客户由l o 个增加 到1 9 个，需要处理的交易类型也从证券、外汇拓宽到包括基金、现金、回购( r e p o ) 等。 2 3 1 质量改善 需求的快速增长使得系统代码和复杂度急剧增加。部分组件由于初始结构不 理想，在系统维护的过程中成为可维护性的瓶颈，出现了“牵一发而动全身 的 状况，不但影响了整个系统的开发进程，也难以保证开发的质量。根据开发辅助 工具上的数据，交易管理系统b u g 数量呈现逐年增长的趋势，如图2 3 所示： 浙江人学顺i j 学位论文 第2 争交易管理系统的预防r l 维护 图2 3交易管理系统缺陷统计 ( 数据来源：开发及技术支持i ：具c a s et r a c k e r ) 在交易管理系统开发和维护人员数量没有明显增加的情况下，单位时间缺陷 数量的增长势必导致维护成本中纠错性维护的比例上升，这是管理者所不愿意看 到的。增量改动无法改善这种趋势，必须从代码本身的结构和可维护性上着手重 构，进行预防性质的维护。所以预防性维护的首要目标就是减少系统缺陷产生的 【1 j 能性，降低纠错性维护成本。 2 3 2 业务合并 另方而，交易管理系统由_ j 二增加了新的、i p 务功能，已经完全具备了处理姊 妹系统金融交易系统的全部、l k 务的能j 。 金融交易系统丌发二j i1 9 9 8 年，其、i k 务功能和交易管：e e f ! 系统f 分千f 1 似，只是 、l k 务范围局限r 现金和托管。 会融交易系统作为款十对门：发较早的软件，和交易管邢系统相比存在着以 浙江人学硕士学位论文第2 章交易管理系统的预防性维护 下几个问题： 可维护性 金融交易系统初期开发人员已经离开，由于文档和注释不全面，给维护人员 的理解和更改造成很多的困难。相比之下，在4 年后开始计划的新系统具有很大 的优势。 性能 性能始终是困扰两个系统的重大问题，而以金融交易系统更甚。金融交易系 统占据和新系统同等规模的资源，但是处理能力却只有新系统的1 2 左右，常常 因为处理速度受到客户的抱怨。 兼容性 金融交易系统开始写于1 9 9 8 年，编码语言是j a v a l 1 。此时的j a v a 语言尚未 完全成熟，使用的大量a p i 在后来的j d k 版本中已经不再获得支持( d e p r e c a t e d ) ， 系统本身也很难通过j a v av m 的升级得到性能、稳定性方面的提升，制约整个系 统的进一步发展。 金融交易系统虽然可以继续正常工作，但是其维护成本不在交易系统之下， 也需要单独的技术支持体系，加上性能和兼容性上的问题，继续保持它的运作已 经得不偿失。为了能够把业务部门和投资者的利益最大化，以交易管理系统承担 这个旧系统的所有业务是最为理想的选择。由于两个系统在架构相似，吸纳旧系 统具有很高的可操作性。作为交易管理系统一方，预防性维护的第二个目标是提 高系统的可扩展性，降低适应性维护的成本。 2 4 重构对象的选择 要实现质量改善和业务替代的维护目标，必须要有适合目前维护模式的重构 过程来推动对交易管理系统的重构工作。 交易管理系统目前拥有6 0 人左右的开发团队，分布在全球5 个城市，分别 属于4 个时区，各个组件的负责人分散在各地，甚至一个组件的开发人员也会不 在一个时区，这是一个跨国公司典型的全球协同研发体系。对于同常的维护任务， 浙江人学硕士学位论文第2 章交易管理系统的预防性维护 通常有各个组件负责人分析属于自己的工作需求，讨论公共接口，然后各自开发 完成并有专门的测试团队进行集成测试后交付s q a 。这样的维护模式，很大程度 上依靠严格的开发流程来维持开发活动的紧凑。但是这样的异地协同开发在沟通 和协调上存在很多困难【l6 1 。这种困难在重构工作中则更为突出： 没有统一而明确的需求。 为预防性维护所作的重构倾向于自发性质的自我改善活动，没有任务明确的 开发需求文档。组件负责人和开发人员难以确定自己的工作范围。 初期代价高，难以检验和纠正。 组件间大量的知识交换和提炼是整体重构的前提。在目前的异地协同开发模 式中，这样的知识交换是一个漫长的过程，各个组件的步调无法协调一致，加上 预防性维护本身的低优先级，项目很容易陷入不可控的状态而失败。 如果换一种思路，能不能在没有或者有很少组件知识的情况下，进行重构? 由于交易管理系统采用了以c o r b a 和m q 为主要消息传递机制的松耦合价格， 各个层面的改动相对来说可以独立。为此可以选择和整体耦合度较小但是处于重 要地位的部分作为重构工作的切入点。 2 4 1 业务规则管理器 事实上，重构的需求在交易规则管理器t r m 最为迫切。 t r m 的业务规则语言难以被业务人员理解和开发，目前依靠普通程序员 维护，周期长代价高； 规则管理模式完全依靠手工，需要大量的人力和时间且错误率高； 系统性能不能满足未来的业务增长； 代码重复频率高，增加了维护的难度； 旧系统中同样存在大量的以不同格式撰写的业务规则，合并开发所需要 的人力和时间超过了一般代码；交易规则管理器的优劣，将对业务的合并带 来重大的影响。 由于交易规则管理器使用特殊的语言设计，独立于组件运行。其重构可以在 1 4 浙江大学硕 二学位论文第2 章交易管理系统的预防性维护 不影响对应组件功能的情况下进行，占用维护资源少，非常适合重构活动的开始 阶段。 2 4 2 持久层 在目前的架构中，对数据的访问主要在各个组件的内部实现，有很多局限性： 持久化接口不统一，冗余代码多； 类结构不合理，传递对象没有提取，难以理解； s q l 语句需要各个组件手工编写，维护难度大。 数据访问的机制相对独立于具体的业务代码，容易进行统一的规划，对质量 改善产生比较好的重构效果，也可以为1 日系统的合并打下基础。 2 5 本章小结 交易管理系统是一个企业级j 2 e e 软件系统，架构基于松耦合的m q 和 c o i m a 消息传递机制，各层之间相互独立性高。针对系统预防性维护的两个目 标，质量改善和对旧系统的业务替代，选择了交易规则管理器及持久层作为重构 的开始对象。这两个组件的重构可以在不影响外部功能的情况下进行。在交易管 理系统全球协同研发体系中，这样的特征可以让维护人员在较少的重构经验和系 统知识上开始，并且适用范围广，重构效果易于体现。 浙江人学硕上学位论文第3 章交易规则管理器重构 第3 章交易规则管理器重构 金融交易涉及大量的金额，遵循严格的流程，不允许出现任何差错，并且要 准确按照时间交易，不能提早或推迟。交易管理系统为多个机构提供金融交易中 间业务员( m i d d l eo f f i c e ) 的服务，需要遵循不同的交易逻辑；对于来自上游系 统的交易单，交易管理系统需要对上面的信息进行验证、补充和翻译，这些验证、 补充和翻译逻辑常常需要根据机构客户要求、业界规范和国家政策进行改动，频 率很高。 为了分离业务逻辑和技术型代码，交易管理系统实现了一套业务规则管理系 统，称之为交易规则管理器t r a d er u l e sm a n a g e r ，把业务逻辑作为单独的对象来 维护。 3 1 业务规则管理系统 业务规则与业务规则管理系统 业务规则管理系统b u s i n e s sr u l e sm a n a g e m e n ts y s t e m ( b r m s ) 由业务规则 商业解决方案的领导者f a i ri s s a c 公司最先提出，并获得业界的认可。作为一个企 业，必然有着确定的业务范围和运作流程，比如每一个企业都要定期为员工发工 资，在发工资的时候需要根据事先签订的合同、员工的表现、企业的经营状况等 因素来确定金额的多少。这个决策的过程就是在企业的业务规则b u s i n e s sr u l e s ( b r ) 基础上进行的。 概括来说，一个业务规则是定义了一组条件和在此条件下执行的操作，用来 表示业务流程上的逻辑。实现一定业务功能的一组业务规则称为规则库r u l e b a s e 。当一个企业成长到一定规模，它的业务规则库就会更加复杂，变化更加频 繁。这要求企业的信息系统具备高度的适应性和灵活性。但是如果当包含业务逻 辑的代码隐藏在大量其他代码中的时候，修改系统就变得缓慢而且容易出错。 在这样的背景下，人们希望业务规则不再成为企业信息中一般性应用程序的 一部分。当业务规则发生变化是，系统的非业务相关部分的设计和编码不需要进 1 6 浙江人学硕j ：学位论文第3 章交易规则管理器重构 行改变。业务逻辑能够进行专门的维护，并且适应现在和将来的业务需求，具有 良好的可扩展性。为此，b r m s 作为管理企业内部和外部业务规则的独立信息系 统应运而生。b r m s 以管理数据的方式管理业务规则，而将业务规则间复杂的逻 辑交给规则引擎去处理。 经过近2 0 年的发展，目前商用b r m s 已经走向成熟，出现了一大批性能优 良，解决方案灵活的产品。这其中有久负盛名的p e g a s y s t e m 公司的p e g a r u l e s ， f a i ri s s a c 公司的b l a z ea d v i s o rb r m s ，i l o g 公司的多平台b r m s 系列，也有后 来居上的开源规则管理产品如d r o o l s ( 现已被j b o s s 收购) 。国内的b r m s 随着 经济形势和企业的跨越式发展也开始涌现，杭州旗正的v r u l e s 规则定制产品是 这方面的代表之一【1 7 】。 p e g a s y s t e m 公司的p c g a r u l e s 和f a i ri s s a e 公司的b l a z ea d v i s o rb r m s 持续领 跑市场。这两家公司的b r m s 都有着从规则引擎、业务流程管理到业务分析工具 的完整解决方案【1 酊。 i l o g 公司拥有面向j a v a 、n e t 、c o b o l 的多个平台的专门产品。其中j r u l c s 遵循j a v a 平台规则引擎接口标准j s r 9 4 ，曾在多次性能和可靠性对比试验中名列 前茅。 国外商用b r m s 的规则语言均基于英文，应用到国内企业内部有诸多不便。 v r u l e s 的一大特色就是支持中文，可以用更为自然的语言编写业务规则。 3 1 1b 础s 组成 b r m s 要实现管理和运行业务规则的功能，一般要包括以下两个部分。 规则开发和管理工具 b r m s 中的规则语法不同于一般编程开发语言，在实际应用中要求有专门的 开发工具来支持。开发工具要像普通i d e 一样正常识别、编译规则语言。由于业 界还没有个统一的语言规范，所以现在几乎没有两个b r m s 的语言可以通用， 成为业务规则编写方法发展中的一大障碍。此外，为了对编写的规则进行版本控 制等管理，一个好的b r m s 必须要有一个适合业务人员而非程序员的管理界面。 浙；i ：人学坝i 学位论文第3 章交易规则管理器重构 闷i 订这种r 具的一个趋势是幽形界面，o r a c l e 公司的b r m s 产品1 1 9 1 就使用了 如图3 1 所示的下拉框式界而，更加符合业务人员j i ：发、l k 务规则的习惯。 图3 1o r a c l e b r m s 产品界向 规则引擎 规则引擎起源于基于规则的系统( r u l e b a s e ds y s t e m s ) ，街基于规则的系统 又足k b ( k n o w l e d g e b a s e d ) 系统的一个分支1 2 。摹于规则的系统属于人工智能 的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理 解的术语解释和证明它的推理结沦。 皋j i 规则的系统包括三嗣5 分：知识库( k n o w l e d g eb a s e ) 、i ：作记忆( w o r k i n g m e m o r y ) 和推理引擎( i n f e r e n c ee n g i n e ) 。它们的结构如图3 2 所示【2 1 1 ： 浙江人学硕。t ：学位论文第3 章交易规则管理器重构 图3 2基于规则的系统 推理引擎包括三部分：模式匹配器( p a t t e r nm a t c h e r ) 、议程( a g e n d a ) 和规 则解释器( r u l ei n t e r p r e t e r ) 。模式匹配器决定哪些规则符合执行条件并写入议程； 议程为挑选出来的规则赋予优先级；规则解释器负责执行规则并产生输出。 和人类的思维相对应，推理引擎有两种推理方式：演绎法和归纳法。演绎法 从事实出发，应用规则得出结论。而归纳法则是根据假设，寻找符合假设的事实。 使用演绎法的推理引擎的推理步骤如下： 1 ) 初始事实和规则激活模式匹配器； 2 ) 使用模式匹配器比较知识库中的规则和事实与工作记忆中的数据，寻找 符合条件的规则； 3 ) 将可以执行的规则按顺序放入议程； 4 ) 使用解释器执行议程中的规则，更新工作记忆； 5 ) 重复步骤2 至4 ，直到没有可以匹配的事实和规则为止，产生输出。 对规则引擎的研究与应用始于上个世纪7 0 年代，斯坦福大学用l i s p 开发的 1 9 浙江人学硕上学位论文 第3 章交易规则管理器重构 m y c i n 2 2 】是第一个基于规则的系统，用于血液疾病的诊断，并推荐治疗方法。 在这个系统中，以规则表示的知识与用于执行的控制逻辑分离。 8 0 年代，规则引擎随着人工智能的研究热潮达到第一个高峰，但是由于性 能差，不容易和企业的信息系统集成，规则引擎的开发陷入停顿。随着软件和硬 件技术的进步，这些问题逐步得到解决。面向对象程序设计使规则引擎这样的大 型软件开发的代价降低，质量提高；j a v a 这样的跨平台语言为无缝联结奠定了基 础：摩尔定律下计算机硬件性能的成倍提高也使得规则引擎可以应用到实时性要 求高的场合，如电话计费系统。 为了更好的理解规则引擎的作用，下面以d r o o l s 为例，介绍规贝l j 引擎的实现。 3 1 2 规$ 1 j z j l 擎d r o o l s d r o o l s 是一个基于j a v a 语言的开源b r m s ，在最新的4 0 版本中，拥有一个 实现了r e t e 2 3 1 和l e a p s 2 4 1 匹配算法的规则引擎，遵循j s r 9 4 标准【2 卯，以及和 e c l i p s e 集成的规则开发工具，用于开发和编译调试自定义的规则语言d r l 。相比 上一个版本，它还加入了基于a j a x 技术的w e b 页面式规则版本控制和管理系统， 以适应业务人员的使用需求【2 6 】。 3 1 2 1d r o o l s 规则引擎的组成 d r o o l s 规则引擎包含5 个部分： c o r e 一引擎核心，联系规则和事实进行推理，并进行对应的动作： c o m p i l e r - - - 解释器，将规则文件解释成可以被引擎解读的代码； d e c i s i o nt a b l e - - - s p r e a d s h e e t 型规则的支持： i d e - - e c l i p s e 开发插件，可以实时编译d r l 文件； j s r 9 4 _ 对j a v a x r u l e s ( j s r 9 4 ) a p i 接口的实现。 d r o o l s 中对规则的执行主要包括两个大的步骤： 3 1 2 2 解释并编译 规则文件 d r o o l s 的规则文件在3 0 版本以后可以使用两种语法形式：x m l 和d r l 的。 2 0 相比x m l ，d r l 语法更为简洁，符合非程序员的阅读习惯，便于理解和开发。 p a c k a g eo r g d r o o l s e x a m p i e s i i 粤o r 七o r g - d r o o l s e x a m p l e s h e l l o w o r l d e x a m p l e m e s s a g e 7 r u l e ”h e l i ow o r l d ” w h e n 。 ， m ：m e 8 8 a g e ( s t a t u s = = m e s s