（计算机软件与理论专业论文）软件再工程中设计模式识别的研究.pdf

摘要 软件再工程作为能够增进对现有软件的理解，改进软件自身质量以提高其可 维护性、可复用性和可演化性的一类活动，在软件工业中占据了越来越重要的地 位。通过软件再工程，可以发掘出遗产系统中各个层次的设计和实现信息，从而 为遗产系统的维护、构件的提取、领域知识的获取以及软件的复用提供帮助。 作为恢复软件系统设计信息的一种方式，在逆向工程中识别和恢复能在较高 抽象层次上反映系统特征的设计模式，有助于正确理解遗产系统，也为迸一步的 系统维护、系统重构和系统演化打下基础。但国内外在这方面已经开展的一些研 究工作大多局限于静态分析，没有充分考虑动态分析的重要性，因此具有较大的 局限性。 本文提出一个综合利用静态分析和动态分析从j a v a 遗产系统中识别设计模 式实例的方法：将复杂的模式结构层层分解为子模式和基本原语元素，并引入形 式化的方式来定义和描述：在对遗产系统进行静态分析的基础之上，给出一个模 式实例的推导识别算法，根据模式静态结构特征的形式化定义，可以自动地进行 模式实例的识别和推导；在自动的模式实例识别的基础之上，通过运用面向方面 编程( a o p ) 技术对遗产系统进行动态分析来获取系统运行时交互信息，结合模 式的动态交互行为特征，实现了对自动识别出的模式实例进一步的验证。 【关键词】 软件再工程、遗产系统、设计模式、子模式、静态结构特征、动态交互行为 特征、形式化定义、自动推导、面向方面编程 【分类号】 t p 3 1 1 5 a b s t r a c t s o f t w a r er e e n g i n e e r i n g , w h i c hi se f f i c i e n t l yh e l p f u lf o rp r o g r a mu n d e r s t a n d i n g a n ds o f t w a r eq u a l i t yi m p r o v e m e n tt oi n c r e a s em a i n t a i n a b i l i t y , r e u s a b i l i t y , e v o l v a b i l i t y , i st a k i n gam o r ea n dm o r ei m p o r t a n tr o l ei ns o f t w a r ei n d u s t r y s o f t w a r er e e n g i n e e r i n g c a nr e c o v e rt h em u l t i - l e v e ld e s i g na n di m p l e m e n t a t i o ni n f o r m a t i o no ft h el e g a c y s y s t e m ，a n dt h e nh e l pw i t ht h em a i n t e n a n c eo fs y s t e m ，c o m p o n e n te x t r a c t i o n , a c q u i r e m e n to fd o m a i nk n o w l e d g ea n ds o f t w a r er e u s e a saw a yo fd e s i g ni n f o r m a t i o nr e c o v e r y , r e c o g n i t i o na n dr e c o v e r yo fd e s i g n p a t t e r n s ，w h i c hc a ns h o ws y s t e mp r o p e r t i e si nah i 曲a b s t r a c t i o nl e v e l ，i sv e r yh e l p f u l t os y s t e mu n d e r s t a n d i n ga n dw o r k s 镐t h eb a s eo fs y s t e mm a i n t e n a n c e r e u s e , a n d e v o l v e m e n t b u tm a j o r i t yo fc u r r e n tr e s e a r c h e sf o c u s e do nt h es t a t i ca n a l y s i so f s o f t w a r e , w h i l ea r el a c ko fc o n c e r n i n gw i t hd y n a m i ca n a l y s i s , w h i c hr e s u l ti ng r e a t l i m i t a t i o n t h i sp a p e rp r e s e n t sam e t h o do fr e c o g n i s i n gd e s i g np a t t e mi n s t a n c e sf r o mj a v a l e g a c ys y s t e m sw h i c hu t i l i z e sb o t hs t a t i ca n dd y n a m i ca n a l y s i s t h ec o m p l i c a t e d s t r u c t u r e so fp a t t e r n sa r ed e c o m p o s e di n t os u b - p a t t e r n sa n db a s i cp r o t o t y p ee l e m e n t s ， a n dt h e na r ed e f i n e di naf o r m a l i z e dw a y a na l g o r i t i n ni si n t r o d u c e dw h i c h r e c o g n i z e s a n dd e d u c t s a u t o m a t i c a l l y t h e p a t t e r n i n s t a n c e s a c c o r d i n gt o t h e f o r m a l i z e dd e f i n i t i o no ft h es t a t i cs t r u c t u r a lf e a t u r e so ft h ep a t t e r n s ，b a s e do nt h e s t a t i ca n a l y s i so nt h es y s t e m a f t e rp a t t e mi n s t a n c e sa r ea u t o m a t i c a l l yr e c o g n i z e d ， t h e ya r ev a l i d a t e df u r t h e rw i t ht h em r t i m ei n t e r a c t i n gi n f o r m a t i o ng a t h e r e db yt h e d y n a m i ca n a l y s i so nt h eo r i g i n a ls y s t e mw h i c hu s i n ga s p e c t - o r i e n t e dp r o g r a m m i n g t e c h n i q u e s ，a n dt h ed y n a m i ci n t e r a c t i n gb e h a v i o r a lf e a t u r e so f t h ep a t t e r n s k e yw o r d s s o f t w a r er e e n g i n e e r i n g 、l e g a c ys y s t e m s 、d e s i g np a t t e m 、s u b - p a t t e r n 、s t a t i c s t r u c t u r a l f e a t u r e 、d y n a m i ci n t e r a c t i n g b e h a v i o r a lf e a t u r e 、a u t o m a t i c d e d u c t i o n 、f o r m a l i z e dd e f i n i t i o n 、a s p e c t - o r i e n t e dp r o g r a m m i n g 复旦大学硕士学位论文 软件再工程中设计模式识别的研究 第一章引言 1 1 软件再工程的背景 1 , 1 1 软件维护 软件开发始终未曾摆脱危机，经过半个世纪的发展，软件危机愈演愈烈软 件危机包含下述两方面的问题：第一是如何开发软件，以满足日益增长的对软件 的需求；第二是如何维护数量不断膨胀的已有软件。后者成为软件的维护危机， 软件再工程是克服维护危机的一个比较有效的手段。【1 1 软件交付使用后的变更称为软件维护。软件维护是由于在特定的使用条件下 暴露的一些潜在错误或设计缺陷、使用过程中软硬件或数据环境发生变化、以及 用户提出改进现有系统的要求，对软件产品所进行的修改活动。 根据维护产生的原因可以将软件维护分为以下四类【2 】： 1 ) 纠错性维护 也称改正性维护。在软件交付使用后，由于开发测试的不彻底、不细致，必 然会有一部分隐患的错误被带到运行阶段来，这些隐藏下来的错误在某次特定的 使用环境下就会暴露。为了识别和纠正软件错误、改正软件性能的缺陷、排除实 施中的误使用，应当进行的诊断和改j 下错误的过程，就叫做纠错性维护。 2 ) 适应性维护 随着r r 技术的发展，外部环境( 新的软、硬件配置) 或数据环境( 数据库、 数据格式、数据输入输出方式、数据存储介质) 可能发生变化，为了使软件适 应这种变化，而修改软件的过程就叫做适应性维护。 完善性或增强性维护 在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满 足这些需求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进运 行效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。 4 ) 预防性维护 为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。 通常预防性维护定义为：。把今天的方法学用于昨天的系统以满足明天的需要” 也就是说，采用先进的软件工程方法对需要维护的软件或软件中的一部分( 重新) 复旦大学硬士学位论文 软件再工程中设计模式识别的研究 进行设计、编制和维护。 软件维护曾被描述为“冰山”经过半个世纪的发展，软件产品数量急剧增 长，等待维护的软件数量也随之增长，维护危机加剧。与软件开发相比较，软件 维护更缺乏系统的方法和技术，使得维护工作显得更加困难。软件维护是软件工 程中最消耗资源的活动，目前对现存软件的维护已经占据软件开发组织所花费整 个软件生存期工作量的7 0 以上，其中纠错性维护大约占整个维护工作量的2 0 ，其余8 0 都花费在其他三种维护活动上。维护危机已经严重束缚了软件开 发组织和软件工业的发展，由于文档过时或不完整，没有采用优良的软件工程技 术等各种原因造成系统可维护性差，而最初的开发人员又不知去向，许多软件开 发组织疲于旧系统的维护，无暇从事新的软件开发。【1 】 同时，对许多现存软件进行维护很必要，因为这些软件是一些组织业务工作 的关键，其中渗入了许多业务知识和工作经验，这些知识和经验除在软件中体现 外并没有其他记载，因此必须在这些软件基础上开展工作，如果将这些软件抛弃、 重新开发新的软件会冒很大的风险。而这些系统通常是早期开发的，可维护性很 一 z l a 在这种背景下，旨在提高系统的可维护性的软件再工程也就营运而生了。软 件再工程是软件维护领域的一个分支，属于维护中的“预防性维护”。软件再工 程通过挖掘、整理现存的软件系统以得到有用的软件构件，或对已有软件构件进 行维护以延长其生存期。软件再工程在解决可维护性问题上很彻底，能对现存系 统进行设计恢复，发现业务规则，重写文档，将有利于维护的新技术集成到现存 系统中。 1 1 2 软件复用 进入九十年代以来，软件系统的规模变得越来越大，结构也越来越复杂。与 此同时，软件的生命周期也越来越长。过去的软件生命周期模型认为软件在开发 完成之后，经过若干年的维护过程，会慢慢退出历史舞台，被新的软件系统所取 代。然而，当前的生命周期模型趋向于把系统看作能够随时间而进行连续演化的 模型。同时还可以看到，从头开始构建的大系统数量在急剧减少，很多遗产系统 正在被逐步地利用起来。但在利用遗产系统的时候，会遇到许多困难。由于时间 的流逝，这些寿命已有1 0 - 2 5 年的系统具有许多这样或那样的缺点而其中最重 要的一个问题就是：现有的遗产系统没有好的可演化性，这样就使得无法利用简 单的方法把遗产系统转化为一个新的系统。【3 1 近几年来，人们开始认识到，要真正实现软件的工业化生产方式，保证软件 2 复旦大学硕士学位论文 软件再工程中设计模式识别的研究 生产的高效率和高质量，软件复用是一条现实可行的途径。对软件复用技术的研 究已成为软件工程界的主攻方向之一。 所谓软件复用是指在开发新的应用系统时使用以前开发的软件资源，如设 计、代码、文档等，从而提高系统开发效率及软件质1 1 4 。软件复用的概念是 在1 9 6 8 年n a t o 软件工程会议上由m c u r o y 第一次提出的【5 】 软件复用通常可分为两类：产品复用和过程复用产品复用指复用已有的软 件构件，通过构件的集成( 组装) 得到新系统。过程复用指复用已有的软件开发 过程，使用可复用的应用生成器自动或半自动的生成所需系统。完全通用的过程 复用意味着软件生产的自动化，这在目前还是难以实现的。目前主要的研究课题 主要集中在产品复用上。 就产品复用而言，又可分为直接复用和间接复用两类。直接复用是指对那些 可表示为某种程序设计语言代码的构件的复用。间接复用是指对需求规约、功能 规约、设计思想、测试计划等文档型知识的复用。 对已有软件资源的复用也存在两种情形，一种情形是对已有构件不作修改直 接进行复用，这种复用称为黑盒复用；另一种情形是指已有构件并不能完全符合 用户需求，需要根据用户需求进行适应性修改后才可使用，这种复用称为白盒复 用。在大多数情况下，对构件的复用是白盒复用【4 】。 当前，软件复用已经成为软件工程的重要部分，不但是对编程本身复用，而 且涉及到软件开发的每个阶段，它的不断发展完善必将成为软件开发的主流。 1 2 软件再工程概述 1 2 1 软件再工程的定义 i e e e 计算机协会软件工程技术委员会( i e e ec o m p u t e rs o c i e t yt e c h n i c a l c o u n c i lo ns o f t w a r ee n g i n e e d n g ) 在其“再工程资料目录”( r e e n g i n e e r i n g b i b l i o g r a p h y ) 中采用了这一定义：软件再工程是这样一类活动，它能够使我们： 增进对软件的理解；准备和直接提高软件自身的可维护性、复用性和演化性。【6 】 软件再工程是对现有软件系统进行验证、评价，重新设计、构造成为一个新 的形式并加以实现，使其满足新的需要和( 或) 适合于新的运行环境的软件工程 活动软件再工程是任何可以改进人们对软件的理解和( 或) 改进软件本身的活 动啊。它是一个工程过程，它将逆向工程，重构和正向工程组合起来，将现存 系统重新构造为新的形式【8 】。 3 复旦大学硕士学位论文软件再工程中设计模式识别的研究 1 2 2 软件再工程的目标 软件再工程的对象，即某些使用中的系统，常常被称为“遗产系统”( 1 e g a c y s y s t e m ) 它们往往缺乏良好的设计结构和编程风格，因此使软件的修改费时费 力同时，相关的公司或组织由于长久依赖它们，不忍将它们完全抛弃。这样， 软件再工程所面临的挑战就是对这些系统进行分析研究，利用好的软件开发方 法，重新构造一个新的目标系统，这样的系统将保持原系统需要的功能并易于维 护和演化。一般来说，软件再工程的具体目标有以下三个方面【9 】： 1 ) 维护 软件再工程的主要目标是提高系统的可维护性，软件的可维护性是指维护人 员理解、改正、改动和改进软件系统的难易程度。提高可维护性是支配软件工程 方法论所有步骤的关键目标。可维护性有三个评价标准：可理解性，可测试性， 可修改性。这三个因素都体现在文档中，因此文档是影响系统可维护性的关键因 素原有系统由于不断维护日趋复杂，系统的稳定性和可靠性逐渐降低，直至让 人无法忍受，经过软件的再工程和再设计，其模块划分会更趋合理，接口定义更 加清晰、文档更齐全，从而更易维护。在软件再工程的许多活动都可以提高可维 护性，尤其是逆向工程。 复用 也称重用和再用。是指同一事务不做修改和稍加改动就多次重复使用。大多 数工程项目都尽可能采用可以复用的部件，但是计算机软件的工程项目有很大的 特殊性。在软件行业里，大量的软件项目都是一切从头开始，也许这种特有的现 象正是软件开发效率和质量问题的根源所在，也是软件成本高昂的因素之一。软 件可以在各个级别上进行复用：代码级、功能级、模块和对象级、子系统级，甚 至应用系统级。软件再工程是软件复用的主要手段之一。软件再工程在实旌过程 中，很大一部分工作就是识别现存系统中可复用的部件，并深入研究如何将其集 成到新的系统中。 3 1 演化 根据市场要求及用户需求的变化和环境的变化扩充功能，改善性能；同时随 着信息技术的不断进步，许多现有系统要适时地移植到性能更为强大的软硬件平 台、操作系统或语言环境上，需要将新的技术方法和工具集成到现存的软件系统 中去，继续为用户创造效益；同时通过对原系统用新的设计思想重新实现，对原 有文档的更新，使今后能方便地对系统进行功能的追加和增强。 4 复旦大学硕士学位论文软件再工程中设计模式识别的研究 1 2 3 软件再工程的过程 根据用户对现有软件改进要求的不同，再工程活动一般可分为系统级、数据 级和源程序级三个层次 i o i 。多数情况下的再工程过程都会涉及到系统级的再工 程活动。数据级和程序级的再工程既然已经超出常规维护所能解决的范围，那么 就很难局限于数据和程序的层次来开展。只有从系统的底层形态( 代码、文档等) 经过多次抽象提升回到概念世界，并以此为起点结合再工程改进要求，逐步实现 成为新的底层形态，遗产系统到新系统的转换才会平稳的进行。 再工程必须充分发掘遗产系统中可加以利用的各方面，否则再过程将蜕化为 一般的二次开发。特别是在面向对象环境下，软件复用技术将促使再工程在各抽 象层次上通过充分复用的形式完成向目标系统的转化。图i , i 是面向对象系统再 图i i 面向对象系统的再工程模型 软件再工程包括逆向工程、重构、正向工程三个部分： 1 ) 逆向过程是一个抽象过程，通过对源代码、原有文档的分析，逐步重建 出系统的逻辑结构、概念世界，是一个设计恢复的过程。逆向工程通过分析现有 系统，识别出其中的模块、组件及它们之间的关系，并以另一种形式，或在更高 的抽象层次上创建出系统表示。逆向工程的目的就是要在缺少文档说明的情况 下，还原出软件系统的设计结构、需求实现，并尽可能地找出内部的各种联系， 相应的接口等，从而恢复出已遗失的信息，侦测出存在的缺陷，生成可变换的系 5 复旦大学硕士学位论文 软件再工程中设计模式识别的研究 统视图，综合出较高的抽象表示。需要注意的是，这一过程并不涉及到原系统代 码的任何修改。【1 2 】 2 ) 重构是在同一层次上变更系统表达以适应需求，可分为文档重构、代码 重构和数据重构。在再工程的过程中，重构是真正意义上的“变更”和真正意义 上的。复用”变更是指重构修改原始系统。逆向工程中所恢复的设计结果，为 重构提供可供变更的对象；正向工程则是根据重构结果进行一个新的软件开发系 统的实现过程。所以，重构是连接逆向工程和正向工程之间的桥梁。重构活动需 要对原有系统做相应的修改，它是整个再工程过程中同原有系统关系最紧密的阶 段。 3 ) 正向工程活动主要是在前两步活动的基础上，产生目标代码的过程，可 以采用一般软件开发的技术和方法。由于有现存系统可以复用，所以正向工程的 工作量比全新的软件开发要小。在大多数情况，正向工程并不仅仅是创建某旧程 序的一个等价物，而是将新的用户需求和方法技术集成到再工程中，重新开发的 程序扩展了旧应用的能力。 1 3 本文的研究意义与动机 在设计模式【1 3 】一书中，g o f ( e r i c h g a m m a , r i c h a r d h e l m ，r a l p hj o h n s o n ， j o h l l v l i s s i d e s ) 将面向对象软件的设计经验作为设计模式，以人们能够有效利用 的方式记录并展示出来。每一个设计模式系统地命名、解释和评价了面向对象系 统中一个重要的和重复出现的设计。它是对某些面向对象软件设计中的常见问题 的一个良好的解决方案，并在已有的实践中经过了测试和验证。设计模式使人们 可以更加简单方便地复用成功的设计和体系结构，帮助你做出有利于系统的复用 选择，甚至能有效地提高系统的文档管理和系统维护的有效性。使用设计模式， 不仅可以加快软件设计开发的进度，而且也能在一定程度上保证软件的质量。 而设计模式不仅仅用可以用于正向工程( 软件设计开发) 中，在逆向工程中 也能发挥巨大作用。作为一种良好的一种文档形式，设计模式能在一个较高的抽 象层次上反映系统的特征和信息，能反映出一个模块甚至多个模块的特征及其之 间的关系，可以被用来记录和保存系统某些部分的设计信息。因此，作为恢复系 统设计信息的一种方式，识别和恢复设计模式对于正确理解遗产系统是非常有帮 助的，也为进一步的系统维护、系统重构和系统演化打下基础。 从另一方面来说，如果能从系统中识别出一些不良的模式，反映出原系统的 一些不良的设计和编码问题，在此基础之上可以对这些不良的结构进行改造或者 6 复旦大学硕士学位论文 软件再工程中设计模式识别的研究 重构，改良软件的质量，也使其更加易于维护和演化。如 1 4 1 n 1 5 0 0 就记录了 一些不良的设计模式。 目前的软件再工程研究方向很多，也出现了不少有用的方法和工具。从静态 方面而言，获取遗产系统的静态结构特征的技术已经很成熟，相应的工具也很多 而从动态方面而言，缺乏一套通用的动态分析方法，也没有很有效的工具。而在 更高层次上，由于缺乏对于程序特性的完全、准确的理解，更高层次的抽象信息 ( 如模式和构架) 的提取技术都还在探索之中，并没有很成熟和完整的技术或者 自动支持工具的出现。 国内外在设计模式识别方面已经开展了一些研究，取得了一些成果，同时也 产生了一些有效的方法和辅助工具。但也存在以下一些缺陷和不足之处： 1 1 这些工作大多仅利用静态分析，没有充分考虑动态分析的重要性，因此 具有较大的局限性。 往往只根据模式的静态结构特征来进行模式实例的识别，忽视了模式的 动态行为特征，而是动态行为特征是设计模式( 尤其是行为型和创建型模式) 的 重要属性。 3 ) 大部分工作只能识别出结构型模式的实例，而对于行为型和创建型模式 实例识别的支持不够。 基于以上原因，本文提出一个综合利用静态分析和动态分析从j a v a 遗产系 统中识别设计模式的方法，根据模式的静态结构特征和动态交互行为特征来进行 模式实例的识别。 1 4 设计模式识别方法的主要步骤 本文提出的综合利用静态分析和动态分析设计模式识别的方法，主要分为以 下三个主要步骤或阶段： 1 ) 模式的形式化定义 化整为零，将复杂的模式结构层层分解为子模式和基本原语元素，并引入形 式化的方式来定义和描述。 2 1 利用静态分析获取模式实例 在对遗产系统进行静态分析的基础之上，给出一个模式的推导识别算法，根 据模式结构的分层的形式化定义，实现自动的模式实例的识别和推导。 3 1 利用动态分析验证模式实例 7 复旦大学硕士学位论文 软件再工程中设计模式识别的研究 在模式实例的自动识别的基础之上，提出一个运用面向方面编程( a o p ) 技 术对遗产系统进行动态分析获取系统动态行为信息的方法，利用获取的系统动态 行为信息和模式的动态行为特征对自动识别出的模式实例进行进一步的验证 这三个步骤将在第三章到第五章依次分别详细讨论和介绍。 1 5 论文的组织结构 第二章介绍了本文所用到的背景知识和相关技术。第三章到第五章依次分别 详细讨论设计模式识别方法的三个主要步骤。第三章详细叙述了对模式的静态结 构特征进行形式化定义的方法。第四章介绍了对遗产系统静态结构信息的抽取， 给出一个自动模式实例识别的推导算法，以及利用形式化定义来进行设计模式实 例的自动识别的方法和过程。第五章给出了利用a o p 来获取遗产系统动态行为 信息的方法，并介绍如何利用动态分析获取的系统行为信息来进一步验证自动识 别出的模式实例。最后是总结和展望。 8 复旦大学硕士学位论文软件再工程中设计模式识别的研究 第二章背景知识和相关技术 2 1 设计模式 建筑设计师c h r i s t o p h e r a l e x a n d e r 提出：“每一个模式描述了一个在我们周 围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一 次地使用该方案而不必做重复劳动。”【1 6 】上述的定义是对设计模式的广义定 义。我们将其应用到面向对象软件的领域内，就形成了对设计模式的狭义定义。 设计模式 1 3 1 ，即d e s i g np a t t e r n ，是在面向对象的系统设计过程中反复出现 的问题的解决方案，也就是解决某一类问题的方法论。通过这种方式，软件开发 人员可以无数次地使用那些已有的解决方案，无需再重复相同的工作。术语设计 模式是在9 0 年代由e r i c hg a m m a 等人从建筑设计领域引入到计算机科学中来的。 这表现了软件设计领域的逐渐成熟。 模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你做出 一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。 算法不是设计模式，因为算法致力于解决实现问题而非设计问题。设计模式 通常描述了一组相互紧密作用的类与对象，以及它们如何组合和交互为某个设计 问题提供解决方案。设计模式提供一种讨论软件设计的公共语言，使得熟练设计 者的设计经验可以破初学者和其他设计者掌握。设计模式还为软件重构提供了目 标。 一般而言，一个模式有四个基本要素： 1 ) 模式名称( p a t t e r n n a m e ) ，一个助记名，它用一两个词来描述模式的问 题、解决方案和效果。基于一个模式词汇表，程序员之间就可以讨论模式并在编 写文档时使用它们，便于相互交流设计思想及设计结果。 2 ) 问题( p r o b l e m ) ，描述了应该在何时使用模式。它解释了设计问题和问题 存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也 可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式 必须满足的一系列先决条件。 3 1 解决方案( s o l u t i o n ) ，描述了设计的组成成分，它们之间的相互关系及各 自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解 决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和 9 复旦大学硕士学位论文软件再工程中设计模式识别的研究 怎样用一个具有一般意义的元素组合( 类或对象组合) 来解决这个问题。 4 ) 效果( c o n s e q u e n c e s ) ，描述了模式应用的效果及使用模式应权衡的问题。 软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复 用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或 可移植性的影响，显式地列出这些效果对理解、评价和选择这些模式具有重要意 义 根据目的( 即模式是用来完成什么工作的) 的不同，设计模式可以分为三类： 1 ) 创建型( c r e a t i o n a l ) ：解决如何创建对象的问题。 结构型( s t r u c t u r a l ) ：解决如何正确的组合类或对象的问题。 3 ) 行为型( b e h a v i o r a l ) ：解决类或对象之间如何交互和如何分配职责的 问题。 一个设计模式是通过模式名和分类、意图、别名、动机、适用性、结构、参 与者、协作、效果、实现、代码示例、已知应用和相关模式等多个角度和方面来 描述的。 2 2 设计模式识别的相关研究 a u t o n i o l 1 7 ，1 8 1 用源代码和设计信息为输入，第1 步转换为a o l ( a b s t r a c t o b j e c tl a n g u a g e ) 。在a o l 的基础上进行处理，因此可以独立于具体语言。第2 步是对a o l 进行解析得到a s t ( a b s t r a c ts y n t a xt r e e ) 。第3 步是对a s t 进行抽取 得到系统关系数据、软件度量数据等。最后是具体的搜索、模式匹配过程。在搜 索中依次利用软件度量限制条件、设计模式的最短路径限制、设计模式的结构限 制和设计模式的指派关系限制来减少搜索空间，防止在模式匹配中出现组合爆 炸。文中还建立了用元组形式表示的设计模式的形式化特性库。此方法能找到程 序中舳的设计模式，但是仅限于结构型模式。 k r a m e r 和p r e c h e l t 1 9 开发了自动发现设计模式的p a t 系统。它用0 0c a s e 工具抽取c 程序的头文件信息并转化为o m t 表达的格式，然后自动转化为 p r o l o g 表达方法。面向对象设计模式也是由系统自动将o m t 表示格式转化为一 个p r o l o g 规则。在抽取的信息中设计模式的具体搜索采用了p r o l o g 查询的方法， 是由r r o l o g 引擎来完成的。p a t 系统是用来发现程序中关于系统结构方面的设计 模式，能找到程序中1 4 - 5 0 的设计模式，其精确度依赖于抽取工具得到信息 的精确度。 r u d o l fk k e l l e r 等【2 0 】指出了在大型软件系统中发现设计模式的重要性，认 1 0 复旦大学硕士学位论文软件再工程中设计模式识别的研究 为许多设计模式由于应用域的不同而有不同的程序表现形式，因此更需要人工的 参与。他们实现了一个逆向工程环境s p o o l ，可以由人工方法或自动方法在程 序抽取信息中发现模式s p o o l 中在程序源代码抽取得到更详细程序信息，并 有可视化的浏览工具来辅助信息查询。文中还以t e m p l a t em e t h o d ，f a c t o r y m e t h o d ，b r i d g e 三个设计模式分别在3 个实验系统中的发现过程为例说明了 s p 0 0 l 的具体应用。 h e t v 6a l b i n - a m i o t 等人【2 1 】引入了p d l 对模式进行描述，使用j a v a x l 将 j a v a 源代码向相应设计模式进行转换，c s p 用于定义设计模式监测的规则，p a l m 用于解析c s p 。并在此基础上研究了两个原型系统：p a t t e r n s b o x 使用p d l 来操 作和匹配设计模式模型并且产生源代码，j a v a x l 来转换现存代码。p t i d e j 使用 p d l 操作设计模式模型，c s p 和p a l m 组成的约束系统用于监测设计模式， j a v a x l 用于整理被扭曲的设计模式。 r a d e r m a c h e r 2 2 利用图形重绘系统p r o g r e s 来匹配模式实例。模式被定义为 图形转换的规则，然后利用p r o g r e s 系统的执行机制来进行模式实例的识别，因 此不能增加自己的执行机制。 k e l l e r 等人【2 3 1 利用一个通用的u m l 的抽象语法图( a b s t r a c ts y n t a xg r a p h ) 模型来表示模式和源码信息。模式的语法图和源码的语法图之间的匹配由脚本 ( s c r i p t s ) 来完成，而这些脚本并非自动生成而又程序员来完成，于是容易变得 数量庞大而难以维护和重用。 n i e r e 等人【2 4 】同样使用了图形匹配和转换的技术来进行模式的匹配。首先 利用j a v a c c 来进行源码的分析，得到源码的抽象语法图( a b s t r a c ts y n t a xg r a p h ) 的表示，然后为模式定义一些了一系列的基于抽象语法图的推导规则，利用这些 推导规则来对原始的抽象语法图进行转换和改造，最终实现模式实例匹配。仅仅 关注静态结构特征，仅限于结构型模式 2 2 面向方面编程( a o p ) 技术 一个关注点就是一个特定目的，块我们感兴趣的区域。例如业务逻辑、性 能、数据存储、安全性，每一个都可以作为一个关注点。我们可以把一个复杂的 系统看作是由多个关注点来组合实现的，由不同模块实现的一批关注点组成了一 个系统。从技术的角度看，一个典型的软件系统包括一些核心关注点和系统级关 注点。举例来说，一个信用卡处理系统的核心关注点是借贷存入处理，系统级 的关注点就是日志、事务完整性、授权、安全性及性能问题等。 许多关注点我们叫它横切关注点( c r o s s c u t t i n gc o n c e r n s ) 会在多个 1 1 复旦大学硕士学位论文 软件再工程中设计模式识别的研究 模块中出现( 例如日志记录、错误处理、性能优化等) ，使用现有的程序开发方 法，横切关注点会横越多个模块，结果是使系统难以设计、理解、实现和演化。 0 0 技术的一大局限性就是：它对软件职责的划分是“垂直”的在一个标 准的对象继承体系中，每一株继承树负责软件系统中一个特定部分的功能，对象 的行为是在编译期决定的。但是，在实际问题中，常常有一些“水平”的功能需 求，例如：一个容器( c o n t a i n e r ) 对象应该可以容纳各种各样的对象；一个日志 ( 1 0 9 9 e r ) 对象应该可以记录所有对象的行为。这些。水平”的功能需求有一个 共同的特点：它们的操作对象横跨了多株继承树，并且操作本身对于操作对象是 透明的。这就向软件开发者提出了“功能正交分解”的要求在标准0 0 技术的 环境下，人们想出了一些解决方案( 例如单根继承体系和某些结构型设计模式) ， 但结果都不能令人满意。 因此，面向方面的编程( a s p e c t o r i e n t e dp r o g r a m m i n g ，a o p ) 应运而生 它是o o p 的延续和补充【2 5 】。a o p 为开发者提供了以一种松散偶合的、相互独 立的模块化方法实现横切关注点的机制，并能够自动将横切关注点织入到面向对 象的软件系统中。这些模块化单元叫“方面( a s p e c t ) ”。通过划分a s p e c t 代码， 横切关注点变得容易处理。开发者可以在编译时更改、插入或除去系统的a s p e 斌， 甚至重用系统的a s p e c t 。a o p 的目的在于，清晰地分离关注点，实现横切关注 点的模块化。而a o p 的本质就是用松散耦合的方式实现独立的关注点，然后组 合这些实现来建立最终系统。【2 6 面向方面编程的组件包括：通知拦截器( a d v i c e i n t e r c e p t o r ) , 导言 ( i n t r o d u c t i o n ) 、元数据( m c m d a t a ) 和p o i n t c u t s 。r 2 7 1 一个通知是被某一事件触发的程序逻辑。它是可以被插入一个方法调用者和 被调用者实际的方法之间的行为。通知是面向方面编程的关键。通知允许你 定义横切( c r o s s - c u t t i n g ) 行为，并透明地应用到现有的对象模型中。拦截器即 通知的一种实现方式。 导言是一个增加方法或者域到一个存在的类中的途径。它们甚至允许你改变 当前存在的类实现的接口，并且引入一个混合的类来实现新的接口。导言允许你 带入多继承的功能到一般的j a v a 类。导言能够是一个方法，它将一个新的a p i 附加于一个存在的对象模型 元数据是可以附属于一个类的附加信息，以静态方式或者在运行时间动态 地把元数据附上到一个对象时，它将更加有效。当你正在编写可用于任何对象的 一般的方面的时候，元数据显得特别重要，但是程序逻辑必须知道指定类的信息。 如果拦截器、导言和元数据是a o p 的特征，那么p o i n t c u t s 就是粘合剂。 复旦大学硕士学位论文软件再工程中设计模式识别的研究 p o i n t c u t s 告诉a o p 框架，哪些拦截器绑定到哪些类，什么元数据将应用于哪些 类或者哪一个导言将被传入哪些类。p o i n t c u t s 定义各种a o p 特征将怎样应用于 你系统中的类。 复旦大学硕士学位论文软件再工程中设计模式识别的研究 第三章模式的形式化定义 一个设计模式是通过模式名、分类、意图、别名、动机、适用性、结构、参 与者、协作、效果、实现、代码示例、已知应用和相关模式等多个角度和方面来 描述的，其中大部分的方面的描述都是非形式化的。其中最为形式化的部分一 结构，是通过u m l 图来进行展示的，而u m l 并不能算是一种完全形式化的表 述方式。u m l 具有对复杂的软件单元和系统结构进行高度抽象和直观的表示， 以直观简单的图形展示大量的信息，易于程序员的理解和相互之间的交流等优 点。然而作为非形式化的图形符号，u m l 又存在以下一些问题：语义和信息不 精确或者含糊不清，无法在其基础之上进行完全自动化的分析，推导和转换；如 果人为地进行上述工作，根据的是程序员的经验和能力，于是容易产生很多问题， 不能保证得到准确的结果，同时也会花费很多的时间和精力。 因此如果要根据模式的结构特征进行模式实例的自动化地识别和获取，必须 首先提供模式结构特征的形式化定义。 本章首先引入一个子模式的概念来用于模式结构的分解；然后介绍了模式形 式化定义的规范；接下来用c o m p o s i t e 模式和m e d i a t o r 模式来详细说明如果对模 式结构特征进行形式化定义：最后给出了其他一些重要模式的形式化定义。 3 1 模式结构特征的形式化 3 1 1 子模式 原语信息位于一个较低的抽象层次，是源码中信息的简单抽象和直接反映， 包括了面向对象程序中基本元素，如类、方法、属性等。设计模式位于一个比较 高的抽象层次，结构复杂，可能关联了多个类以及类的方法、属性等。要直接在 原语信息中进行模式实例的识别，即寻找符合该设计模式特征的类、方法、属性 等，是比较困难的。因此，我们在原语信息和设计模式的抽象层次之间引入一个 新的抽象层次子模式，在二者之问架起一座桥，填补了原本巨大的抽象层次 间隙和差距。子模式建构在原语信息层之上，同是也是模式的组成部分。予模式 又可能分为多层，高层的子模式将依赖于低层子模式并由低层子模式实例组成。 引入子模式的意义在于；通过将一个复杂的模式划分为多个较为简单的子模 式，子模式又可以划分为更小的子模式，层层细化，使得识别过程容易进行；两 1 4 复旦大学硕士学位论文软件再工程中设计模式识别的研究 个设计模式实例可能包括了相同的子模式实例，这样在识别过程中只需进行一次 该子模式实例的识别，并同时运用于两个模式实例的识别中，避免了重复的工作， 简化了识别过程，提高效率。 3 1 2 形式化定义规范 如下为模式或子模式的形式化定义的规范形式： d e f ：p a t t e r n n a m e ( r o t e _ l i s t ) i n ：p r o t o e l e m c n c l i s t c o n d i t i o n ：c o n d i f i o n _ l c o n d i t i o n _ n d e f 后面跟着模式的或者子模式的定义，p a t t e r n n a m e 为模式或子模式名， 模式名后面的圆扩号中为该模式中角色的列表r o l ef i s t 。r o l e _ l i s t 的每一个元素为 一个原语，以“n a m e ：t y p e ”的形式来定义，其中n a m e 为原语元素名，t y p e 为其 的原语类型( 如类c l a s s ) h 后面是与该模式关联的原语元素列表p r o t o e l e m e n t _ l i s t ，即该模式是定义 于这样一组原语元素之上的。r o l e _ l i s t 的每一个元素为一个原语，同样以 “n a m e ：t y p e ”的形式来定义。 c o n d i t i o n 定义了满足该模式的一系列条件，其中每一个条件可能是一个子 模式实例或者一个条件语句。当( 且仅当) 这些条件语句都成立且一系列子模式 的实例都存在的前提下，该模式的实例存在，即可以识别出一个该模式的实例。 下面以组合( c o m p o s i t e ) 模式和中介者( m e d i a t o r ) 模式为例，来详细说明 如何对模式结构特征来进行形式化地定义。 3 1 3c o m p o s i t e 模式的形式化 c o m p o s i t e ( 组合) 模式是一个典型的结构型设计模式。其意图在于将对象 以树形结构组织起来，以达成“部分一整体”的层次结构，使得客户端对单个 对象和组合对象的