第11章 软件维护.ppt

《第11章 软件维护.ppt》由会员分享，可在线阅读，更多相关《第11章 软件维护.ppt（93页珍藏版）》请在三一文库上搜索。

1、第11章 软件维护,软件维护的3个主要问题： （1）非结构化的维护太多、太难 （2）维护费用开销太大 （3）维护工作是费力不讨好的事，没有创新，学不到新知识,要将软件维护做好，就必须做到： 开发文档、管理文档、维护文档必须齐全，使所有的维护工作都变为集成化维护工作，也就是提高系统的可维护性的问题。,在签订软件合同时必须将软件的维护工作范围、内容、期限和费用增加进去，并明确甲乙双方在维护工作中的责任。 维护人员在缺陷维护（即程序级）维护和功能维护（即设计级维护）上虽然不能随意地创新，但是可以分析维护前系统的缺陷或毛病，收集并整理用户的意见与建议，从而去策划新版本的蓝图，在新版本的升级上做到有所创

2、新。,11.1 软件维护的概念,所谓软件维护，就是指软件项目或产品在安装、运行并交付给用户使用后，在新版本升级之前的这段时间里，软件厂商向客户提供的服务工作。,软件维护的分类 （1）纠错性维护： 产品或项目中存在缺陷或者错误，在测试和验收时未发现，到了使用过程中逐渐暴露出来，需要改正。,（2）适应性维护： 这类维护是为了产品或项目适应变化了的硬件、系统软件的运行环境，如系统升级,（3）完善性维护： 这类维护是为了给软件系统增加一些新的功能，使产品或项目的功能更加完善与合理，又不至于对系统进行伤筋动骨的改造，这类维护占维护活动的大部分。,（4）预防性维护： 这类维护是为了提高产品或项目的可靠性和

3、可维护性，有利于系统的进一步改造或升级换代。,所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。p299,软件维护的特点,结构化维护的前提是：软件产品或软件项目必须有完善的文档，并且文档与程序代码互相匹配，两者完全一致。在这样的前提下，四大类维护不但都会比较省力，而且维护后可以用原来的测试用例进行回归测试。维护文档只要在原来的文档上加上适当修改，形成修改后的新版本文档即可，该新版本只是一个很小的版本号，不构成大

4、版本的升级。,反之，若软件产品或软件项目只有程序而没有文档，或文档很不规范，很不齐全，对这样的软件进行维护就不能叫结构化维护，只能叫非结构化维护。,（1）非结构化维护。 如果软件配置的唯一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和（或）设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试（即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试）。非结构化维护需要付出很大代价（浪费精力并且遭受挫折的打击

5、），这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。,（2）结构化维护。 如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查；接下来编写相应的源程序代码，使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。刚才描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。,维护的代价太大 维护费用只不过

6、是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。,与维护有关的问题很多 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，必然会导致在最后阶段出现问题。,（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。 （2）需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。,（3）当要求对软件进行维护时，不能指望由开发人员给人们仔

7、细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。 （4）绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。 （5）软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。,预防性维护,对老程序的维护可以选择以下几种方法： （1）反复多次地做修改程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改。 （2）通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它。 （3）在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试

8、那些需要变更的软件部分。 （4）以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。,11.2 软件维护过程,软件维护过程又称为软件维护活动。由于在软件的运行过程中，需要不断地进行修改和完善，维护工作量逐年上升。软件维护过程与软件类型、软件开发过程以及人员因素有着密切的关系。,软件维护过程由一系列变更请求触发。变更请求可能来自系统用户、管理层或者客户。对变更请求经过成本和影响分析评估，一旦变更请求获得批准，就要对系统规划一个新版本，然后实现这个变更。,软件维护的工作量,在系统的维护过程中，需要花费很大的工作量。这关系

9、到软件的维护成本问题。与软件维护工作量有关的因素主要有以下几点： （1）系统的大小。 （2）程序设计语言。 （3）系统的年龄。 （4）数据库技术的应用。 （5）先进的软件开发技术。 （6）其他因素。,维护工作量的定量分析 M=P+Kexp（cd） 其中：M维护所用的总工作量；P生产性工作量；K经验常数；c复杂程度（标志设计的好坏及文档完整程度，非结构化设计和缺少文档都会增加软件的复杂程度）；d维护人员对欲维护软件的熟悉程度。 上面的模型表明，如果软件的开发途径不好（即没有使用软件工程方法学），而且原来的开发人员不能参加维护工作，那么维护工作量和费用将以指数倍增加。,软件维护的流程与相关记录,建

10、立适当的维护组织 通常并不需要建立一个正式的维护机构，在一个维护过程中，每一位参加维护的人员都要明确自己的责任，为了减少维护过程的混乱，建立一种非正式的组织还是有必要的。,制定维护报告 维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制订出一个软件修改报告，它给出下述信息。 （1）满足维护要求表中提出的要求所需要的工作量。 （2）维护要求的性质。 （3）这项要求的优先次序。 （4）与修改有关的背景数据。 在拟定进一步的维护计划之前，把软件修改报告提交给修改控制决策机构审查批准。,软件维护的流程,在完成软件维护任务之后，进行复审常常是有好处的。一般说来，这种复审试图回答下

11、述问题： （1）在当前处境下设计、编码或测试的哪些方面能用不同方法进行? （2）哪些维护资源是应该有而事实上却没有的? （3）对于这项维护工作什么是主要的（以及次要的）障碍? （4）要求的维护类型中有预防性维护吗?,保存维护记录 对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。,保存的内容 （1） 程序标识。（2） 源程序行数。（3） 机器指令条数。（4） 使用的程序设计语言。（5） 程序安装的日期。（6） 自从安装以来程序运行的次数。（

12、7） 自从安装以来程序失效的次数。（8） 程序变动的层次和标识。（9） 因程序变动而增加的源语句数。（10） 因程序变动而删除的源语句数。（11） 每个改动耗费的人时数。（12） 程序改动的日期。（13） 软件工程师的名字。（14） 维护要求表的标识。（15） 维护类型。（16） 维护开始和完成的日期。（17） 累计用于维护的人时数。（18） 与完成的维护相联系的纯效益。,维护的副作用,软件修改是一项很危险的工作，对一个复杂的逻辑过程，哪怕做一项微小的改动，都可能引入潜在的错误，虽然设计文档化和细致的回归测试有助于排除错误，但是维护仍然会产生副作用。,（1）代码副作用。 在一个地方发现错误后，

13、要修改程序代码，而修改一段程序代码可能波及别处，由此产生新的错误。修改代码将使编码更加混乱，程序结构更不清晰，可读性更差，而且有连锁反应。 代码副作用有时通过回归测试即可发现，此时应立即采取补救措施。遗憾的是，有时直到交付运行后才暴露出来，故对代码进行上述修改应特别慎重。,（2）数据副作用。 数据结构是系统的骨架，修改数据结构是对系统伤筋动骨的大手术，在数据冗余与数据不一致方面，可能顾此失彼。当需要修改用户数据时要与用户协商，一旦有疏忽，可能使系统发生意外。 数据副作用指因修改软件的信息结构而带来的不良后果。,（3）文档的副作用。 修改文档可能产生的副作用对非结构化维护不适应，对结构化维护要严

14、防程序与文档的不匹配往往会出现这样一种现象，当发现错误后，程序员马上修改程序代码，但没有及时修改文档，这样，便产生程序代码与文档不一致，给以后的技术人员再阅读文档时带来更大的困难。 维护应统一考虑整个软件配置，而不仅仅是源代码。,重新验证程序 由于软件维护会产生副作用，所以，经过修改后的软件，在提交给用户之前，应该进行确认和测试，以确保整个系统的正确性。,（1）静态确认。 （2）计算机确认。 （3）文档验收。,软件维护的最新方法,软件维护方法的划分 p308,软件维护与软件产品版本升级,软件维护工作流程,（1） 分类整理用户意见。（2） 提出维护申请。（3） 评审、审计、批准维护申请。（4）

15、修改需求文档。（5） 维护需求文档评审。（6） 修改设计文档。（7） 维护设计文档评审。（8） 修改源程序。（9） 回归测试。（10） 修改软件产品版本号。（11） 交付用户运行。（12） 收集用户反馈意见，准备进行新一轮维护活动，转向流程的第1个步骤。,UML对软件维护的影响,UML确实对软件开发模型与软件生存周期、软件建模方法、软件文档规范和软件人员分工产生重大影响，这种影响将使得分析、设计、实现、维护人员的岗位界线逐渐趋向模糊，因为软件维护实质上是一次更高层次上的开发，它不但可以发现和解决前人的错误，而且可以总结和继承前人的经验与技术。,CMM/CMMI对软件维护的影响,11.3 软件的

16、可维护性,所谓软件的可维护性，就是维护人员理解、掌握和修改被维护软件的难易程度。 可维护性的软件应具备下列4条性质：,1、可理解性 软件模块化、结构化，代码风格化，文档清晰化 2、可测试性 文档规范化，代码注释化，测试回归化,3、可修改性 模块间低耦合，高内聚，程序块的单入口和单出口，数据局部化，公用模块组件化 4、可移植性 如用ODBC、ADO来屏蔽对数据库管理系统的依赖，用三层结构来简化对客户浏览层的维护,决定软件可维护性的因素,维护就是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定

17、错误的具体位置。,决定软件可维护性的因素主要有5个： （1）可理解性。 可理解性表现为人们理解软件的结构、功能、接口和内部处理过程的难易程度。 （2）可靠性。 可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。,（3）可测试性。 可测试性表明论证程序正确性的容易程度。一个可测试程序应当是可理解的、可靠的、简单的。 诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。,（4）可修改性。 软件可修改

18、性表明程序容易修改的程度。一个可修改的程序，应该具有可理解性、通用性、灵活性等。通用性是指程序适用于各种功能变化而无需修改；灵活性是指能够容易地对程序进行修改。软件容易修改的程度和程序的设计原理和启发规则直接有关。,（5）可移植性。 软件可移植性指的是把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。,（6）效率。 软件的效率表明了一个程序能完成预定的功能，但又不浪费资源的程度。 （7）可用性。 软件的可用性定义为程序方便、实用、易使用的程度。,（8）可重用性。所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。 大量使用可重用的软件构件来开

19、发软件，可以从下述两个方面提高软件的可维护性： 通常，可重用的软件构件在开发时都经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求就越少。 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。,软件可靠性表明了一个程序按照用户的要求和设计的目标，执行其功能的正确程度。一个可靠的程序应要求是正确的、完整的、一致的和健壮的。现实中，一个程序要达到完全可靠是不实际的，要精确地度量它也不现实。在一般情形下只

20、能通过程序测试去度量程序的可靠性。软件可靠性是指在给定的时间内，在规定的环境条件下系统完成所指定功能的概率。软件可靠性与可用性的定量指标，是指能够以数字概念来描述可靠性的数学表达式中所使用的量。,提高软件可维护性的方法,(1)建立明确的软件质量目标和优先级。 (2)使用提高软件质量的工具和技术。 (3)进行明确的质量保证审查。 (4)选择维护性好的程序设计语言。 (5)注重程序的有关文档。,(6)软件开发时应考虑维护。 (7)若干量化的测度。 察觉到问题所耗的时间； 收集维护工具所用的时间； 分析问题所需时间；形成修改说明书所需时间； 纠错（或修改）所用时间；局部测试所用时间；整体测试所用时间

21、；维护复审所用时间； 完全恢复所用时间。,软件文档,软件文档的意义主要体现在以下几点： （1）软件具有好的和完备的文档容易操作，因为，它能增加软件的可读性和可使用性。不正确的和残缺的文档比没有文档更糟糕。 （2）好的文档意味着简洁，风格一致，易于更新，规范化和符合标准。 （3）在程序代码的适当位置插入注解，可以提高对程序自身的理解，程序越长、越复杂，这种需要就越迫切。,历史文档也具有一定的重要性。在软件维护过程中，利用历史文档可以简化维护工作，降低软件维护的难度。例如，通过文档了解软件系统原来的设计思想和技术等，指导维护人员选择适当的方法，制定合理的维护方案，不至于盲目修改程序而危及整个系统的

22、完整性。历史文档主要有：,（1）系统开发日志。 （2）错误记载。 （3）系统维护日志。,软件文档的要求,（1）必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用。 （2）必须描述怎样安装和管理这个系统。 （3）必须描述系统需求和设计。 （4）必须描述系统的实现和测试，以便使系统成为可维护的。,软件文档的分类,软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。,用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根

23、据需要阅读有关的内容。,用户文档至少应该包括下述5方面的内容： （1）功能描述，说明系统能做什么。 （2）安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。 （3）使用手册，简要说明如何着手使用这个系统（应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动）。 （4）参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）。 （5）操作员指南（如果需要有系统操作员的话），说明操作员应该如何处理使用中出现的各种情况。,所谓系统文档指从问题

24、定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。,维护文档和维护管理文档,对于结构化维护来说，软件维护文档就是对原来已有的分析文档、设计文档、实现文档、测试文档、用户指南进行修改，形成新的开发文档。 新的开发文档的组织方式有两种格式：格式1：在先保存好原有的开发文档之后，直接在原来已有的文档上面修改，修改后形成新的小版本号文档，即在原来版本号中小圆点的右一位或右二位上加1。格式2：不直接在原来已有的

25、文档上面修改，而是将修改的内容单独作为一个附录，放在被修改文档的最后面，形成一份新的小版本号文档，即在原来版本号中小圆点的右一位或右两位上加1。,软件维护管理文档有： （1） 用户意见反馈表。（2） 用户意见分类整理表。（3） 维护申请单。（4） 维护文档评审报告。（5） 产品缺陷统计表。（6） 功能扩充统计表。（7） 未答复问题汇总表。（8） 未验证问题汇总表。（9） 已修改问题汇总表。（10） 已验证问题汇总表。（11） 维护费用统计表。,可维护性复审,可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有前面提到的那些可维护因素。在软件工程过程的每一个阶段都应该考虑并努力提高

26、软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。,（1）在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。,（2）在正式的和非正式的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预做准备。 （3）代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。,（4）在设计和编码过程中应该尽量使用可重用的软件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。每个测试步骤都可以暗示在软件正式交

27、付使用前，程序中可能需要做预防性维护的部分。在测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。,（5）在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。,11.4 软件再工程,软件再工程（再生）是软件工程中的一类重新构建活动，它能够增进我们对软件的理解，提高软件自身的可维护性、重用性和演化性等。 软件再工程就是指重新实现系统的功能，并且加入新的

28、功能或性能，以提高软件的整体质量。,再工程与新软件建造之间的重要差别在软件的开发起点上。如果我们把传统的新软件开发称为正向工程，那么，它开始于系统描述（包括设计和实现）。而再工程开始于已有的系统，不再从系统描述开始，开发过程基于对旧系统的理解和转换，把旧系统作为目标系统的描述。,软件再工程活动,典型的软件再工程过程模型包含了多项活动。在某些情况下这些活动以线性顺序发生，但也并非总是这样，例如，为了理解某个程序的内部工作原理，可能在文档重构开始之前必须先进行逆向工程。,一、库存目录分析 每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息（例如，应用系统的名

29、字，最初构建它的日期，已做过的实质性修改次数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，整体可维护性等级，预期寿命，在未来36个月内的预期修改次数，业务重要程度等）。,下述3类程序有可能成为预防性维护的对象： （1）预定将使用多年的程序。 （2）当前正在成功地使用着的程序。 （3）在最近的将来可能要做重大修改或增强的程序。,二、文档重构 （1）建立文档非常耗费时间，不可能为数百个程序都重新建立文档。如果一个程序是相对稳定的，正在走向其有用生命的终点，而且可能不会再经历什么变化，那么，让它保持现状是一个明智的选择。,（2）为了便于今后的维护，必须更新文档，但是由

30、于资源有限，应采用“使用时建文档”的方法，也就是说，不是一下子把某应用系统的文档全部都重建起来，而是只针对系统中当前正在修改的那些部分建立完整文档。随着时间流逝，将得到一组有用的和相关的文档。 （3）如果某应用系统是完成业务工作的关键，而且必须重构全部文档，则仍然应该设法把文档工作减少到必需的最小量。,三、逆向工程 软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程，也就是说，逆向工程是一个恢复设计结果的过程，逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。,四、代码重构 为了完成代码重构活动，首先，用重构工具分析源代码，标注出和结构化程

31、序设计概念相违背的部分。然后，重构有问题的代码（此项工作可自动进行）。最后，复审和测试生成的重构代码（以保证没有引入异常）并更新代码文档。,通常，重构并不修改整体的程序体系结构，它仅关注个体模块的设计细节以及在模块中定义的局部数据结构。如果重构扩展到模块边界之外并涉及软件体系结构，则重构变成了正向工程。,五、数据重构 与代码重构不同，数据重构发生在相当低的抽象层次上，它是一种全范围的再工程活动。在大多数情况下，数据重构始于逆向工程活动，分解当前使用的数据体系结构，必要时定义数据模型，标识数据对象和属性，并从软件质量的角度复审现存的数据结构。,六、正向工程 正向工程也称为革新或改造，这项活动不仅

32、从现有程序中恢复设计信息，而且使用该信息去改变或重构现有系统，以提高其整体质量。 正向工程过程应用软件工程的原理、概念、技术和方法来重新开发某个现有的应用系统。在大多数情况下，被再工程的软件不仅重新实现现有系统的功能，而且加入了新功能并提高了整体性能。,软件再工程的风险,（1）过程风险。 （2）人员风险。 （3）应用问题风险。 （4）技术风险。 （5）工具风险。 （6）策略风险。,系统体系结构的变更,p319 集中式主机型系统被再工程为分布式客户机/服务器系统具有以下特征： （1） 应用功能迁移到每一个客户机。 （2） 一些特殊的功能可以保留在服务器。 （3） 新的GUI界面被实现在客户端。

33、（4） 数据库功能分配给服务器。 （5） 新的通信、安全、归档和控制需求必须在客户端和服务器端同时建立。,软件再工程的相关技术,设计恢复是指借助于工具从已有程序中抽象出有关数据设计、体系结构设计、过程设计等的信息，但它们不一定是原设计。 重构是指在同一个抽象级别上转换系统描述形式。重构工程也称修复或改造工程，它是在逆向工程所获得的信息的基础上修改或重构原来的系统，同时，可能加上一些新的功能和性能，以提高系统的综合质量，从而产生软件系统新的版本。,获取、保存、扩充软件知识,（1）分解。 （2）对象恢复。 （3）程序理解。 （4）知识库及程序变换。,理解软件,（1）浏览。 （2）分析、度量。 （3

34、）逆向工程与设计恢复。,改进软件,（1）软件重构。 （2）文档重写、加注释及文档更新。 （3）重用工程。 （4）重新划分模块。 （5）数据再工程。 （6）业务过程再工程。 （7）可维护性分析。,逆向工程与重构工程,一般认为，凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。 与之相关的概念是：重构（restructuring），指在同一抽象级别上转换系统描述形式；设计恢复（design recovery），指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计的信息（不一定是原设计）； 重构工程（reengineering），也称修复和改造工程，它是在

35、逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本。,恢复信息的级别,（1）实现级，包括程序的抽象语法树、符号表等信息。 （2）结构级，包括反映程序分量之间相互依赖关系的信息，例如，调用图、结构图等。 （3）功能级，包括反映程序段功能及程序段之间关系的信息。 （4）领域级，包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。,恢复信息的方法,第一类为用户指导下的搜索与变换（userdirected search and transformation）。此类方法用于导出实现级和结构级信息。它要求维护人员在数据库系统的支持下，运用询问语言，针对源代码或与之相近的表示形式，

36、指定待查找的句型（pattern），根据搜索结果析出所需信息或进行特殊变换。,第二类方法为变换式方法（transformational approaches），除领域级外所有抽象级别上的信息都可用此类方法推导。变换式方法又细分为不需要维护人员过多干涉的自动分析法（如静态分析和调用图、控制流图生成等）和基于特定库的用户指导变换法两类。,第三类方法是基于领域知识的（domain knowledgebased），主要用于恢复功能级和领域级信息。领域知识一般用规则库表示，用已确定或假定的领域概念与代码之间的对应关系推导进一步的假设，最后导出程序的功能。,最后一类方法称为铅板恢复（cliche recogrition）法，这类方法仅适用于推导实现级和结构级信息。这些方法用于识别程序设计“铅板”或公共结构，“铅板”既可为一个简单算法（如两变量互换值），亦可为相对复杂的成分（如冒泡分类）。,