第13章软件维护.pptx

第十三章软件维护,软件工程(第三版),齐治昌谭庆平宁洪,第十三章软件维护,13.1软件维护与进化的概念13.2软件维护的过程模型13.3可维护性13.4维护活动及实施策略13.5维护的副作用13.6逆向工程与软件重构,2020/6/1,国防科技大学计算机学院,2,软件维护,我们讨论了构建一个软件系统的全过程，但系统的交付并不意味着其生存周期的结束。系统构建之后通常还会不断地变化，我们面临的挑战是如何维护一个持续演化的系统。演化可能是由于需求和环境发生变化，也可能是软件自身暴露出问题。统计和估测结果表明，信息系统中硬件费用一般占35%，软件费用占65%，而软件后期维护费用有时竟高达软件总费用的80%，所有前期开发费用仅占20%。许多大型软件公司为维护已有软件耗费大量人力、财力。必须建立一套评估、控制和实施软件维护的机制,这就是本章重点讨论的内容。,2020/6/1,国防科技大学计算机学院,3,13.1软件维护与进化的概念,软件维护是软件交付后，保障软件生产活动，发挥软件社会和经济效益的关键。软件交付并投入运行后，任何针对系统变更所做的工作，都是维护(maintenance)。软件维护究其原因可分为：纠错性维护、适应性维护、完善性维护和预防性维护四类。纠错性维护是为诊断和改正软件系统中潜藏的缺陷而进行的活动。测试不可能排除大型软件系统中所有的缺陷,软件交付后,用户在使用软件的过程中会发现软件潜伏的缺陷,他们会向开发人员报告并要求维护。,2020/6/1,国防科技大学计算机学院,4,软件维护与进化的概念,维护人员找出软件失效的原因，进行改正，并根据需要对需求、设计、代码、测试序列以及文档做出相应变更。最初的修改可能是临时性的，即为保持系统运行所采取的一些应急措施。事后应对维护方案仔细推敲，在软件工具的支持下进行回归测试，自动修改相应的文档。适应性维护是为适应软件运行环境变化，如操作系统变更、硬件更新，而修改软件的活动。应用软件的使用寿命很长，多数超过十年,但运行环境更新通常不会超过十年,CPU基本是一年半一代,操作系统不断地推出新版本,外部设备和其他系统元素也频繁升级和变化,因此适应性维护是十分必要的。,2020/6/1,国防科技大学计算机学院,5,软件维护与进化的概念,完善性维护是根据用户在软件使用过程中提出的一些新需求实施的维护活动。应用软件运行期间,用户可能请求增加新功能、建议修改已有功能或提出某些改进意见。完善性维护通常占所有软件维护工作量的一半以上。预防性维护是优化软件系统结构和可理解性，改善可维护性和可靠性。软件长期维护会使体系结构变坏，难以理解，增加维护费用，降低运行效率。这类维护活动涉及逆向工程(reverseengineering)和软件重构。留待13.6节专门讨论。,2020/6/1,国防科技大学计算机学院,6,软件维护与进化的概念,调查表明：约有65%的维护属完善性维护；18%的维护属适应性维护；17%的维护属纠错性维护。修补系统缺陷并不是费用最高的维护活动，适应新环境的系统进化和实现新需求以及需求变更占用了绝大部分的维护工作量。实践中，几类维护之间没有明确界限。如，在使软件适应新环境的同时，还可能增加新功能，充分利用该环境提供的服务；某个软件失误可能是因为系统用事先未预料到的方式工作，修正这类失误的另一种方法是改变系统的这种工作方式，等等。,2020/6/1,国防科技大学计算机学院,7,软件维护与进化的概念,在前几章讨论系统开发时，主要关注如何生产能够实现需求并能正确运行的代码。维护不仅要理解软件制品，而且要了解用户对系统运行的意见，预测可能出现的问题，考虑业务需求变化带来的软件功能的新变更，以及硬件、软件或接口变更带来的系统变化。维护涉及的范围更广，内容更多。,2020/6/1,国防科技大学计算机学院,8,13.2软件维护的过程模型,实践证明，有重要应用价值的软件，生存周期一般很长，软件维护不可避免。从软件开发的螺旋模型看,软件维护是软件开发的继续,是软件的进化。多数维护团队已不再是该软件的开发团队，软件维护面临许多困难。本节主要讨论软件维护的主要内容、软件工程的目标原则对这些活动的影响、软件维护的成本、软件维护存在的问题等。,2020/6/1,国防科技大学计算机学院,9,13.2.1结构化与非结构化的维护,一个维护需求（申请）被接收后,可能发生的事件如图13.1所示。如果软件配置中唯一可用的是源代码,那么维护只能从“苦读”代码开始。由于缺乏内部文档,读代码是一项很枯燥、很困难的工作。软件系统的许多微妙之处(例如软件总体结构、全局数据、系统接口、性能和设计方面的约束等)不是搞不清楚就是常常被误解,以致无法估量对源代码修改所产生的后果。特别是，由于没有保存测试记录,使“回归测试”无法进行。对于没有使用良好开发方法开发的软件,不得不采用非结构化的方式进行维护并为此付出高昂的代价(浪费大量人力,让维护人员有挫折感)。,2020/6/1,国防科技大学计算机学院,10,2020/6/1,国防科技大学计算机学院,11,图13.1非结构化与结构化维护,结构化与非结构化的维护,如果欲维护的软件存在一个完整的软件配置,维护活动将从阅读设计文档开始。首先确定软件的重要结构、性能及接口特征,评估这次维护可能带来的影响并规划出一个具体实施方案;然后从修改设计入手(采用以前讨论过的设计技术)，设计复审通过之后再修改代码,并参照测试规格说明书对软件进行回归测试,测试通过后交付用户使用。上述过程也称为结构化维护,它是采用软件工程方法学开发软件的自然结果。拥有完整的软件配置能减少维护工作量，提高维护质量。,2020/6/1,国防科技大学计算机学院,12,13.2.2维护的成本,过去的四十年,软件维护的成本在不断增长。20世纪70年代,一个信息系统机构用于软件维护的费用占其软件总预算的3540%80年代接近60%若维护方式没有大的改进,未来几年，许多大型软件公司可能要将其预算的80%用于软件系统的维护上。除软件维护耗费的财力外,其他因素也引起人们的注意。如,由于资源(人力、设备)优先用于维护任务,影响新软件系统的开发，要付出无形的代价。,2020/6/1,国防科技大学计算机学院,13,维护的成本,某些貌似合理但实际不能满足的维护请求将引起用户不满;在软件维护过程中引入的潜在缺陷降低了软件的质量;从开发小组中临时抽调工程师从事维护工作冲击正在进行的开发等等。维护旧程序使生产率(按每人月代码行或每人月功能点计算)大幅度下降。据报道,生产率最多可能降低四十倍,即每行用25元开发的软件，维护一行可能耗费1000元。在设计和实现时为提高可维护性投资是值得的。,2020/6/1,国防科技大学计算机学院,14,维护的成本,维护成本与开发成本的比例在不同应用领域中是不同的。对于业务应用系统，维护费用与系统开发成本大体相等。对于嵌入式实时系统，维护费用能达到开发成本的四倍以上，这类系统的高可靠性和高性能需求需要模块间紧密连接，因此变更起来特别困难。软件维护工作量分为生产性(用于分析与评价，修改设计和代码等)和助动性(用于理解代码功能，解释数据结构、接口特征与性能约束等)两类。,2020/6/1,国防科技大学计算机学院,15,维护的成本,下面给出维护工作量的一种估算模型:M=P+K*e(c-d)（13-1）其中M表示维护工作量，P表示生产性工作量，K为经验常数c表示复杂度,标志设计的好坏及文档完整程度d表示对维护软件的熟悉程度模型表明,倘若未用好的软件开发方法(即未遵循软件工程的思想)或软件开发人员不能参与维护,则维护工作量(和成本)将成指数增长。,2020/6/1,国防科技大学计算机学院,16,13.2.3可能存在的问题,软件维护中出现的大部分问题都可归咎于软件规划和开发方法的缺陷。软件开发若不严格遵循软件开发标准,软件维护就会遇到许多困难。影响维护的问题:(1)很难甚至不可能追踪软件版本的进化过程,软件的变化没在相应文档中反映出来;(2)很难甚至不可能追踪软件的整个创建过程；(3)理解他人的程序非常困难,当软件配置不全,仅有源代码时问题尤为严重;(4)软件人员流动性很大,维护他人软件时很难得到开发者的帮助；,2020/6/1,国防科技大学计算机学院,17,可能存在的问题,(5)软件没有文档、或文档不全、或文档不易理解、或与源代码不一致；(6)多数软件设计未考虑修改的需要(有些设计方法采用了功能独立和对象类型等一些便于修改的概念),软件修改不仅困难而且容易出错。(7)软件维护不是一项有吸引力的工作,从事这项工作令人缺乏成就感。许多遗留系统未采用软件工程的思想和方法开发(大都运行了十年以上),问题尤其严重。下面从技术和管理的角度讨论解决这些问题的具体措施。,2020/6/1,国防科技大学计算机学院,18,13.3可维护性,软件可维护性指,理解、改正、调整和改进软件的难易程度。可维护性是软件质量的重要属性，涉及软件开发方法、工具、过程、软件制品、文档、软件管理、资金投入、维护计划、维护团队等。可维护性是指导软件工程活动的一条基本原则，也是软件工程追求的一个目标。,2020/6/1,国防科技大学计算机学院,19,13.3.1影响可维护性的因素,影响软件可维护性的因素：设计、编码和测试不规范，软件配置不全开发环境的因素:训练有素的软件团队；维护团队是否熟悉经过多次维护的系统；软件的可理解性，包括：软件结构、描述软件制品的语言（如UML,程序设计语言等）、文档及标准化程度等；操作系统的标准化程度；维护工具和环境；生成测试用例的能力；对于嵌入式软件系统维护应有专门的调试工具,2020/6/1,国防科技大学计算机学院,20,13.3.2若干量化的测度,软件可维护性与软件质量和可靠性一样是难以量化的概念,然而借助维护活动中可以定量估算的属性,能间接地度量可维护性。面向时间的度量包括：发现问题耗费的时间;收集维护工具耗费的时间;分析问题耗费的时间;形成修改说明书耗费的时间；纠错(或修改)耗费的时间;,2020/6/1,国防科技大学计算机学院,21,若干量化的测度,局部、整体测试耗费的时间;维护复审耗费的时间;系统恢复耗费的时间。收集上述度量数据作为管理者评估人员、工具、技术有效性的依据,除了这些面向时间的度量外,有关设计结构和软件复杂性的度量亦可间接说明软件的可维护性。,2020/6/1,国防科技大学计算机学院,22,13.3.3保证可维护性的复审,可维护性是软件质量标准的基本要素。软件制品的复审活动经常遇到可维护性的内容。在需求分析制品的复审中,应对将来可能修改和可以改进的部分进行注释,注意为软件移植提供方便，并考虑可能影响软件维护的系统界面;在设计阶段的复审中,应从易于维护和提高设计总体质量的角度全面评审数据设计、总体结构设计、过程设计和界面设计;代码复审主要强调编程风格和内部文档，他们是影响可维护性的重要因素;,2020/6/1,国防科技大学计算机学院,23,保证可维护性的复审,最后,在软件正式交付之前,应该进行一次预防性维护，使代码具有良好的结构，并保持文档和代码的一致性。软件维护活动完成时，要进行复审,所用方法下一节讨论。正式的可维护性复审放在测试完成之后,称为配置复审。目的是保证配置中所有成份的完整、协调、易于理解且便于修改控制。软件配置管理在十六章讨论。,2020/6/1,国防科技大学计算机学院,24,13.4维护活动及实施策略,软件维护工作在维护申请提出之前就开始了，包括：建立维护组织,强制报告和评估的过程;为每个维护申请确定标准化的事件序列;制定保存维护活动记录的制度和有关复审及评估的标准。,2020/6/1,国防科技大学计算机学院,25,13.4.1维护组织,软件维护阶段相对来说是漫长且不定期的,长期以来很少建立正式的维护组织,而多采用“抓着谁算谁”的办法组织维护力量。目前人们普遍认识到,即使对于一个小的软件开发队伍而言,非正式地定岗定责也绝对必要。图13.2给出了一种组织模式。,2020/6/1,国防科技大学计算机学院,26,图13.2维护的一种组织模式,2020/6/1,国防科技大学计算机学院,27,维护组织,每个维护申请通过维护管理员转告给系统管理员,系统管理员一般都是对程序(某一部分)特别熟悉的技术人员,他们对维护申请及可能引起的软件修改进行评估,并向修改控制决策机构(一个或一组管理者)报告,由它最后确定是否采取行动。依照这样的组织方式开展维护活动能减少混乱和盲目性,避免因小失大的情况发生。上述各个岗位都不需要专职人员,但必须为胜任者,并且要早在维护活动开始之前就明确各自责任,避免互相推诿,急功近利的现象。,2020/6/1,国防科技大学计算机学院,28,13.4.2维护的报告与评估,所有的软件维护申请都应该采用标准的格式,软件开发人员统一发放的维护申请单(MaintenanceRequestForm)或称为软件问题报告单(SoftwareProblemReport),由用户根据需要填写。如果用户确实发现了缺陷,必须完整地记录出错现场信息(包括输入数据、列表文件和其他有关信息)；如果用户提出适应性或完善性维护请求,需同时提交一个简短的修改规约(即简单的需求规约)。,2020/6/1,国防科技大学计算机学院,29,维护的报告与评估,维护管理员将MRF提交给系统管理员评估。一个维护申请被核准后,MRF文档成为规划本次维护任务的依据,软件组织要另外制定一个软件修改报告单(SoftwareChangeReport)，说明实现MRF所需工作量、维护活动的性质、本次维护请求优先级、本次修改的背景数据。将SCR提交给修改控制决策机构,供进一步规划维护活动使用。,2020/6/1,国防科技大学计算机学院,30,13.4.3维护工作流,当提出一个维护申请之后,发生的工作流程如图13.3所示。首先确定用户请求维护的类型,有时用户认为是改错的请求,开发人员则可能认为是适应性或完善性维护,如果出现这种分歧,必须通过协商达到共识。,2020/6/1,国防科技大学计算机学院,31,2020/6/1,国防科技大学计算机学院,32,图13.3维护工作流,维护工作流,对一项改错性维护申请(图中标为“出错”通路),首先要估计缺陷的严重程度,如果是一项严重缺陷(例如,某关键部分不能工作),则应由系统管理员“调兵遣将”,立即开始分析问题;如果问题并不严重,这项维护申请应与其他任务统筹考虑,根据轻重缓急再行安排。某些场合,维护活动不能按常规进行。如未对潜在的副作用进行估计或未修改文档就急忙动手修改代码。“救火”式维护仅限于少数危难时刻,并且保证只是延迟而不是放弃对维护的控制和评估。一旦危机过去,应立即补行所有的控制和评估过程,防止由此产生的更大危机。,2020/6/1,国防科技大学计算机学院,33,维护工作流,适应性和完善性维护申请执行另一条处理路径首先对所申请的维护进行评估并根据优先级在维护请求队列中排队根据企业本身的策略、可用的、软件当前及未来发展趋势等因素决定完善性维护的优先级。某项维护申请一旦核准并在队列中排列,便开始规划进度,如同接受一项新的开发任务一样。维护的技术工作：修改软件设计，进行设计复审，必要时重新编码；实施单元测试、综合测试(包括回归测试)、确认测试和复查。复查旨在确认软件配置中所有项目完整、协调，并保证满足MRF。软件维护可视为软件工程的一个递归过程。,2020/6/1,国防科技大学计算机学院,34,维护工作流,当一项软件维护任务完成后,进行一次状况复审大有益处。状况复审主要考虑下列问题:依照当前状态,在设计、编码和测试的哪些方面还能用其他方法进行?哪些维护资源可用但未用；这次维护活动中主要(或次要)的障碍有哪些?在维护请求中有预防性维护吗?状况复审的目的在于促进未来的维护工作,同时也为有效管理软件组织提供重要的反馈信息。,2020/6/1,国防科技大学计算机学院,35,13.4.4保存维护记录,长期以来,人们对于保存软件工程各个阶段的记录未给予足够的重视,因此软件维护的历史记录缺乏,以致人们很难估计各种维护技术的有效性,不能确定一个商品化软件的质量,也不能估算维护的实际成本。维护过程需要记录的数据包括:程序信息：程序标志、源程序行数、目标程序指令条数、编程语言;程序运行信息：安装程序的日期、自安装之日起程序运行的次数、自安装之日起程序失败的次数;,2020/6/1,国防科技大学计算机学院,36,保存维护记录,程序维护信息：程序修改处的层数和标志、程序变动增加的源程序行数、程序变动删除的源程序行数、每处改动耗费的人时数、程序改动日期；软件工程师标志;其它维护信息：MRF标志、维护的类型、维护开始和结束日期、此次维护人时数、本次维护的纯利润，等等。每次维护完成后应立即收集上述数据,并以此为基础构造维护数据库,供维护评价用。,2020/6/1,国防科技大学计算机学院,37,13.4.5评价维护活动,如果缺乏真实可信的数据,评估活动毫无意义。在保存维护记录的前提下,可对维护性能进行度量,统计下列数据是必要的:程序每次运行的平均失效次数;各类维护耗费的总人时数;各种程序、各种语言及各类维护的程序平均变维护活动增删一个语句平均花费的人时数;维护每种语言的程序平均花费的人时数;一张MRF的平均周转时间;各类维护请求的百分比。根据这些统计量可对开发技术、编程语言,以及对维护工作量的预测与资源分配等诸多方面的决策进行评价。,2020/6/1,国防科技大学计算机学院,38,13.5维护的副作用,软件修改是一项很危险的工作,对一个复杂的逻辑过程,那怕做一项微小的改动,都可能引入潜在的缺陷,虽然设计文档化和细致的回归测试有助于排除缺陷,但是维护仍然会产生副作用。软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的缺陷,副作用大致可分为三类:(1)代码副作用。虽然每次代码修改都可能引入潜在的缺陷,但下列修改最易出错:修改或删除子程序、语句标号、标识符;为提高程序执行效率而做的修改;修改文件的open、close操作;修改逻辑操作符;由设计变更引起的代码修改;修改对边界条件的测试。,2020/6/1,国防科技大学计算机学院,39,维护的副作用,代码副作用有时通过回归测试即可发现,此时应立即采取补救措施；不幸的是,有时直到交付运行后才暴露出来,故对代码进行上述修改应特别慎重。(2)数据副作用。在此之前我们曾多次强调软件设计中数据结构的重要性。在维护阶段一旦修改了数据结构,软件设计与数据可能就不再吻合,缺陷随即出现。数据副作用指，因修改软件的信息结构而带来的不良后果。,2020/6/1,国防科技大学计算机学院,40,维护的副作用,容易引起数据副作用的修改包括:局部和全局常量、记录或文件格式的再定义增减数据或其他复杂数据结构的体积;修改全局数据;控制标志和指针的重新初始化;重新排列I/O表或子程序参数表。设计文档化有助于限制数据副作用,因为设计文档中详细地描述了数据结构并提供一个交叉访问表,把数据及引用它们的模块一一对应起来。,2020/6/1,国防科技大学计算机学院,41,维护的副作用,(3)文档的副作用。维护应统一考虑整个软件配置,而不仅仅是源代码。否则,由于在设计文档和用户手册中未能准确反映修改情况而引起文档副作用。对软件的任何修改都应在相应的技术文档中反映出来,如果设计文档不能与软件当前的状况对应则比没有文档更糟。对用户来说,若使用说明中未能反映修改后的状况,那么用户在这些问题上必定出错。一次维护完成之后,再次交付软件之前应仔细复审整个配置,有效地减少文档副作用。某些维护申请不必修改设计和代码,只需整理用户文档便可达到维护的目的。,2020/6/1,国防科技大学计算机学院,42,13.6逆向工程与软件重构,软件重构是目前预防性维护采用的主要技术，即通过设法提高现有系统的总体质量来应对维护挑战。它涉及文档重构、重组、逆向工程和再工程四个层次的工作。文档重构是，通过对源代码进行静态分析帮助维护人员理解和引用代码。重组（restructure）是，利用转换规则简化内部表示，将结构不好的代码转换为易于理解和变更的结构化代码。,2020/6/1,国防科技大学计算机学院,43,逆向工程与软件重构,逆向工程(reverseengineer)根据源代码构造软件中间制品，包括重新创建设计和规约。再工程(reengineering)在逆向工程所获信息的基础上，重新进行“正向工程”，重构已有系统的一个新版本，使其更易维护。通常，再工程软件的质量提高了，但功能没有改变。图13.4给出四类软件重构的关系。,2020/6/1,国防科技大学计算机学院,44,图13.4软件重构分类,2020/6/1,国防科技大学计算机学院,45,13.6.1文档重构,文档重构是指对源代码进行静态分析以产生系统文档。检查变量使用、构件调用、控制路径、构件规模、调用参数、测试路径等帮助我们理解代码“做什么”以及“如何做”。静态代码分析产生的这些信息可以用图形或文本来表示。图13.5阐明文档重构的过程。存在文档分析工具支持文档重构，工具通过分析代码，导出构件调用关系、类层次、数据接口表、数据字典、数据流表或数据流图、控制流表或控制流图、伪代码、测试路径、构件和变量的交叉引用表，等等。,2020/6/1,国防科技大学计算机学院,46,图13.5文档重构过程,2020/6/1,国防科技大学计算机学院,47,13.6.2重组,重组的目的是为了使代码更易于理解和变更。一般利用工具解释源代码并产生内部表示（如语义网或有向图），然后利用转换规则简化内部表示，最后解释简化表示并改写为结构化的代码。图13.6展示了三个主要重组活动。尽管一些重组工具仅能产生源代码，但另外一些工具能支持生成结构，给出容量、复杂性及其他信息。这些测度可用于确定代码的可维护性，评估重组的效果。例如，我们总是希望重组后的代码复杂性能够降低。,2020/6/1,国防科技大学计算机学院,48,图13.6重组,2020/6/1,国防科技大学计算机学院,49,13.6.3逆向工程,逆向工程术语源于硬件制造业,相互竞争的公司为了了解对方设计和制造工艺的机密,在得不到设计和制造说明书的情况下,通过拆卸实物获取信息,软件的逆向工程也基本类似,不过通常“解剖”的不仅是竞争对手的程序，而且还包括本公司多年前的制品,此时得不到设计“机密”的主要障碍是缺乏文档。因此,所谓软件的逆向工程就是分析已有的程序,寻求比源代码更高级的抽象表现形式。一般认为，凡是在软件生存周期内，将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。,2020/6/1,国防科技大学计算机学院,50,逆向工程,逆向工程可恢复的信息可分为四个抽象层次：(1)实现级，包括程序模块和变量表、交叉引用等信息；(2)结构级，包括反映程序分量之间相互依赖关系的信息，例如数据和控制流图、结构图等；(3)功能级，包括反映程序段功能及程序段之间关系的信息，例如处理规约、构件调用层次等；(4)领域级，包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。,2020/6/1,国防科技大学计算机学院,51,逆向工程,对于一项具体的维护任务一般并不必导出所有抽象级别上的信息如，欲完成代码重构任务只需获得实现级信息即可，当然若能进行深入分析，产生的代码质量会更好一些。上述信息的抽象级别越高，它与代码的距离就越远，通过逆向工程恢复的难度亦越大，而自动工具支持的可能性相对变小，要求人参与判断和推理的工作增多。图13.7描述了逆向工程可能恢复的信息。,2020/6/1,国防科技大学计算机学院,52,图13.7逆向工程的过程,2020/6/1,国防科技大学计算机学院,53,逆向工程导出信息的四类方法,1.用户制导搜索与变换(User-DirectedSearchandad-hocTransformation)法。维护人员在数据库系统的支持下，针对源代码或与之相近的表示形式，运用询问语言给定待查找的模式(pattern)，根据搜索结果析出所需信息或进行特殊变换。该方法常用于导出实现级和结构级信息，例如模块的概要设计表(Outline)、流程图和交叉访问表。概要设计表列出软件中所有子程序，以及每个子程序的名称、参数表、数据类型甚至包括所用主要数据结构和前缀注释等信息；流程图可视为过程内部操作的一种压缩和直观表示；模块交叉访问表能说明模块之间、模块与数据之间的调用与引用关系，并指明数据定义与后续引用的位置。,2020/6/1,国防科技大学计算机学院,54,逆向工程导出信息的四类方法,2.变换法(TransformationalApproaches)除领域级外所有抽象级别上的信息都可用此类方法推导。变换方法又细分为不需要维护人员过多干涉的自动分析法(如静态分析，调用图、控制流图生成等)和基于特定库的用户制导变换法两类。变换法自动化程度越高，得到的设计信息越粗，因为任何深层次的分析不可避免地要借助人的智力。一般借助变换法得到程序的某种中间表示形式，通过进一步使用其他工具将获得的设计信息精化为完整、一致的软件设计。,2020/6/1,国防科技大学计算机学院,55,逆向工程导出信息的四类方法,3.基于领域知识(DomainKnowledge-Based)的方法用于恢复功能级和领域级信息。领域知识一般用规则库表示，用已确定或假定的领域概念与代码之间的对应关系推导进一步的假设，最后导出程序的功能。该类方法的不确定性大。,2020/6/1,国防科技大学计算机学院,56,逆向工程导出信息的四类方法,4.子恢复(ClicheRecognition)法这类方法适用于推导实现级和结构级信息。这些方法用于识别程序设计“模子”或公共结构，“模子”既可为一个简单成份(如两变量互换值)，亦可为相对复杂的算法(如冒泡分类)。因模子与程序之间可能存在多种匹配形式，所以此类方法还包含大量的推理与决策。四类方法采用的输入形式、搜索策略和推理策略都不同。后两类方法又称为基于知识的方法。,2020/6/1,国防科技大学计算机学院,57,逆向工程导出信息的四类方法,近年来有许多商用逆向工程的工具出现，能够部分地恢复软件系统的设计。它们一般只能识别、展现、分析源代码中的信息，不能重组、获取以及表示没有直接出现在源代码中的设计抽象，这些信息必须通过推理获得。,2020/6/1,国防科技大学计算机学院,58,13.6.4再工程,再工程是逆向工程的扩展。逆向工程抽取出信息后，再工程过程基于对原系统的理解和转换，在不变更整个系统功能的前提下，生产新的软件源代码。图13.8阐明再工程所包含的步骤。若某个软件再工程可以完全依赖于自动化工具，那么通过逆向工程来恢复文档就没有必要了。,2020/6/1,国防科技大学计算机学院,59,图13.8再工程,2020/6/1,国防科技大学计算机学院,60,再工程,再工程的成本取决于重做工作的程度，源代码转换最为便宜，程序结构重构次之，接下来是程序和数据重构，体系结构迁移成本最高。软件再工程与重新开发软件相比成本和风险都较小