Embed Size (px)
Citation preview
作业（第 7 章）
序号
判定 输入 预期的输出
1 2 3 A B C X Y Z
1 F F F 1 1 1 1 2 32 T T T 20 40 60 10 20 30
语句覆盖的测试用例
作业（第 7 章）序号
判定 输入 预期的输出
1 2 3 A B C X Y Z
1 F F F 1 1 1 1 2 3
2 F F T 1 1 60 1 2 30
3 F T F 1 40 1 1 20 3
4 F T T 1 40 60 1 20 30
5 T F F 20 1 1 10 2 3
6 T F T 20 1 60 10 2 30
7 T T F 20 40 1 10 20 3
8 T T T 20 40 60 10 20 30
路径覆盖的测试用例
第八章 软 件 维 护普通人轻视软件维护工作， 会失掉极其宝贵的机会； 维护人员轻视软件维护工作， 会失掉本应精彩的人生； 老板轻视软件维护工作， 会丢掉大片本来属于自己的市场……
第八章 软件维护
8.1 软件维护的定义软件维护 ---- 就是在软件已经交付使用之后，为保证软件在相当长的时期能够正常运作所进行的软件活动。 维护的类型有四种：：
改正性维护 适应性维护 完善性维护 预防性维护
改正性维护 --- Corrective Maintenance
• 在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。
• 在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。
• 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程就叫做改正性维护。
适应性维护 --- --- Adaptive Maintenance
• 在使用过程中，– 外部环境（新的硬、软件配置）可
能发生变化。– 增加或修改外部设备和其他系统部件– 应用软件的使用寿命远远长于最初开
发这个软件时的运行环境的寿命• 为使软件适应这种变化，而去修改软件
的过程就叫做适应性维护。
完善性维护 --- Perfective Maintenance
• 在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。
• 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
• 这种情况下进行的维护活动叫做完善性维护。
预防性维护 --- Preventive Maintenance
• 预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。
• 预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
各种维护所占比例 :
其它维护 4 %适应性维护18% ～ 25%
改正性维护 17% ～ 21%
完善性维护 50% ～ 66%
用户的维护请求
配置 苦读代码
理解？
重新编写代码
测 试
交付用户使用
非结构化维护
研读设计
计划实施途径
修改设计
复审
重新编写代码
回归测试
交付用户使用
结构化维护
8.2 软件维护的特点 -- 影响维护工作量的因素
• 系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。
• 程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。
• 系统年龄：– 老系统随着不断的修改，结构越来越乱；– 维护人员经常更换，程序又变得越来越难于理解– 许多老系统在当初并未按照软件工程的要求进行
开发，因而没有文档，或文档太少。– 在长期的维护过程中文档在许多地方与程序实现
变得不一致，在维护时就会遇到很大困难。
• 先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。
• 其它：– 应用的类型– 数学模型– 任务的难度
对维护工作量都有影响。• 许多软件在开发时并未考虑将来的修改，为软件
的维护带来许多问题。
二 . 维护的成本• 维护成本占软件总预算的比例不断增加：
70 年代： 35 ％－ 40 ％80 年代： 40 ％～ 60 ％现在： 80 ％甚至更多
• 软件维护的工作量可分为二类： 生产性： 用于分析和评价软件系统，修改软件设计和代码
非生产性： 用于理解代码功能、结构特征以及性能约束
维护成本
• 有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。– 可用的资源必须供维护任务使用 ,以致耽误甚至丧失开发的良机 ;
– 一些合理的修复或修改请求不能及时安排，使得客户不满意；
– 变更的结果引入新的故障，使得软件整体质量下降；
– 把软件人员抽调到维护工作中，干扰了软件开发工作。
维护工作维护工作量的模型量的模型
• M 是维护中消耗的总工作量• P 是生产性工作量• K 是一个经验常数• c 是因缺乏好的设计和文档而导致复杂性的度量• d 是维护人员对软件熟悉程度的度量
• 模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。
dcKepM
8.2.3 维护中的典型问题
(1) 难以读懂他人程序 .
(2) 无合格的文档或不全 .
(3) 软件人员流动性大 .
(4) 设计时未考虑修改需要 ,修改困难 .
(5) 维护工作无吸引力 ,缺乏成就感 .
采用软件工程方法至少可部分地解决与维护有关的每一个问题。
8.3 软件维护过程
• 维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。
• 为了有效地进行软件维护，应事先就开始做组织工作。– 首先建立维护组织– 确定维护报告的过程及评价的过程– 为每一个维护申请规定标准的处理步骤– 建立维护活动的记录保管过程– 并规定复审的标准
1 、维护组织
• 除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。
• 虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。
维护管理员 变化授权人系统管理员
维护申请
接受维护申请
对修改进行评
估
决定是否采取行动（如人员配置、任务的分配
）
1 、维护组织
• 每个维护要求都通过维护管理员转交给相应的系统管理员去评价（系统管理员是被指定去熟悉一小部分产品程序的技术人员）。
• 系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。
2. 维护报告• 应该用标准化的格式表达所有软件维护申请（要求）。
• 维护申请报告或称软件问题报告，由申请维护的用户填写。
• 用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。
• 如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。
• 维护申请报告将由维护管理员和系统管理员来评价。
• 他们应相应地做出软件修改报告，指明：– 所需修改变动的性质；– 申请修改的优先级；– 为满足某个维护申请报告，所需的工作量– 预计修改后的数据 .
• 软件修改报告应提交给变化授权人（修改负责人），经批准后才能开始进一步安排维护工作。
23
3. 维护的事件流
• 尽管维护类型不同，但都要进行同样的技术工作。– 修改软件需求说明– 修改软件设计– 设计评审– 对源程序做必要的修改– 单元测试– 集成测试 ( 回归测试 )– 确认测试– 软件配置评审等。
在软件维护任务完成后进行处境复查，对以下问题做一总结：(1) 在目前处境下，设计、编码、测试中的哪一方面可以改进 ?(2) 哪些维护资源应该有但没有 ?(3) 维护工作中主要的或次要的障碍是什么 ?(4) 从维护类型来看是否应当有预防性维护 ?处境复查对将来的维护工作如何进行会产生重要的影响。
• 记录维护活动过程中的各种信息，如增加源程序的行数，耗费的人力、财力、利润。
• 目的： 估算维护技术的有效性和实际成本
4 、保存维护记录
4 、保存维护记录①程序标识； ②源语句数； ③机器指令条数； ④使用的程序设计语言； ⑤程序安装的日期； ⑥自从安装以来程序运行的次数； ⑦自从安装以来程序失效的次数； ⑧程序变动的层次和标识； ⑨因程序变动而增加的源语句数；
⑽ 因程序变动而删除的源语句数； ⑾ 每个改动耗费的人时数； ⑿ 程序改动的日期； ⒀ 软件工程师的名字； ⒁ 维护要求表的标识； ⒂ 维护类型； ⒃ 维护开始和完成的日期； ⒄ 累计用于维护的人时数； ⒅ 与完成的维护相联系的纯效益。
55 、评价维护活动、评价维护活动• 评价维护活动比较困难，因为缺乏可靠的数据。• 如果维护记录做得比较好，可以得出一些维护工作的定量度
量。 (1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序
变动数； (4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。• 根据对维护工作定量度量的结果，可以做出关于开发技术、
语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。
8.4 软件的可维护性• 许多软件的维护十分困难，原因在于这些软件
的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。
• 许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的。
• 为了使得软件能够易于维护，必须考虑使软件具有可维护性。
• 软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。
• 目前广泛使用的是用如下的五个特目前广泛使用的是用如下的五个特性来衡量程序的可维护性。性来衡量程序的可维护性。
可理解性可理解性 可测试性可测试性
可修改性可修改性 可移植性可移植性 可重用性可重用性
1. 可理解性• 可理解性表明人们通过阅读源代码和相关可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易文档，了解程序功能及其如何运行的容易程度。程度。
• 一个可理解的程序应具备以下一些特性：一个可理解的程序应具备以下一些特性：模块化模块化，，风格一致性风格一致性，，不使用令人捉摸不不使用令人捉摸不定或含糊不清的代码定或含糊不清的代码，，使用有意义的数据使用有意义的数据名和过程名名和过程名，，结构化结构化，，完整性完整性等。等。
8.4.1 决定软件可维护性的因素
2. 2. 可测试性可测试性• 可测试性表明程序容易测试程度可测试性表明程序容易测试程度。而。而且设计合用的测试用例，取决于对程且设计合用的测试用例，取决于对程序的全面理解。序的全面理解。
• 一个可测试的程序应当是一个可测试的程序应当是可理解的可理解的，，可靠的可靠的，，简单的简单的。。
• 用于可测试性度量的检查项目如下：用于可测试性度量的检查项目如下：– 程序是否模块化程序是否模块化 ? ? 结构是否良结构是否良好好 ??
– 程序是否可理解程序是否可理解 ? ? 程序是否可靠程序是否可靠 ??– 程序是否能显示任意中间结果程序是否能显示任意中间结果 ??– 程序是否能以清楚的方式描述它程序是否能以清楚的方式描述它的输出的输出 ??
– 程序是否能及时地按照要求显示程序是否能及时地按照要求显示所有的输入所有的输入 ??
– 程序是否有跟踪及显示逻辑控制程序是否有跟踪及显示逻辑控制流程的能力流程的能力 ??
– 程序是否能从检查点再启动程序是否能从检查点再启动 ??– 程序是否能显示带说明的错误信程序是否能显示带说明的错误信息息 ??
3. 3. 可修改性可修改性• 可修改性表明程序容易修改的程度可修改性表明程序容易修改的程度。。
• 与本书第 5 章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。
4. 4. 可移植性可移植性• 可移植性表明程序转移到一个新的计算可移植性表明程序转移到一个新的计算环境的难易程度环境的难易程度。或者它表明程序可以。或者它表明程序可以容易地、有效地在各种各样的计算环境容易地、有效地在各种各样的计算环境中运行的容易程度。中运行的容易程度。
• 一个可移植的程序应具有一个可移植的程序应具有结构良好结构良好、、灵灵活活、、不依赖于某一具体计算机或操作系不依赖于某一具体计算机或操作系统的性能统的性能。。
• 用于可移植性度量的检查项目如下：用于可移植性度量的检查项目如下：
– 是否是用高级的独立于机器的语言来是否是用高级的独立于机器的语言来编写程序编写程序 ??
– 是否仅使用了这种语言的标准版本和特是否仅使用了这种语言的标准版本和特性性 ??
– 程序中是否使用了标准的普遍使用的程序中是否使用了标准的普遍使用的库功能和子程序库功能和子程序 ??
– 程序中是否极少使用或根本不使用操程序中是否极少使用或根本不使用操作系统的功能作系统的功能 ??
– 程序是否把与机器相关的语句分离了程序是否把与机器相关的语句分离了出来，集中放在了一些单独的程序模块出来，集中放在了一些单独的程序模块中，并有说明文件中，并有说明文件 ??
5. 5. 可重用性可重用性• 重用（ reuse ）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性：
(1) 通常，可重用的软件构件在开发时经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。
（ 2 ） 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。
• 而且对于不同类型的维护，这五种而且对于不同类型的维护，这五种特性的侧重点也不相同特性的侧重点也不相同。
在各类维护中的侧重点 在各类维护中的侧重点
改改正正性性维维护护 适适应应性性维维护护 完完善善性性维维护护
可可理理解解性性
可可测测试试性性
可可修修改改性性
可可移移植植性性
可可重重用用性性
8.4.2 文 档
• 文档是影响软件可维护性的决定因素。往往文档比程序代码更重要。
• 软件系统的文档可以分为用户文档和系统文档两类。
---- 用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；
---- 系统文档描述系统设计、实现和测试等各方面的内容。
• 软件文档应该满足下述要求：
(1) 必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用；
(2) 必须描述怎样安装和管理这个系统；
(3) 必须描述系统需求和设计；
(4) 必须描述系统的实现和测试，以便使系统成为可维护的。
42
1. 用户文档 用户文档是用户了解系统的第一步，它应该能使用
户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。
用户文档至少应该包括下述5 方面的内容： (1) 功能描述； (2) 安装文档； (3) 使用手册； (4) 参考手册； (5) 操作员指南 ( 如果需要有系统操作员的话 ) 。 上述内容可以分别作为独立的文档， 也可以作为一个文档的不同分册， 具体做法应该由系统规模决定。
2. 系统文档 ---- 所谓系统文档指从问题定义、需求说明
到验收测试计划这样一系列和系统实现有关的文档。
---- 描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。
---- 和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。
8.4.3 可维护性复审• 在软件工程过程的每一个阶段都应该考虑并努力提
高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。
• 在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。
--- 维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。
--- 每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。
--- 用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。
8.5 预防性维护• 预防性维护方法是由Miller 提出来的，他
把这种方法定义为：“把今天的方法学应用到昨天的系统上，以支持明天的需求。”
• 开发和维护者不应等待用户的维护申请 ,在条件具备时应该主动地进行预防性维护。
• 预防性维护对象 :
•预计若干年内将继续使用的程序•当今正成功使用的程序•最近的将来要进行大修改和完善的程序
• 再工程是一个重构活动（类比 重建一所房子） 开始重建前，首先检查一下房子。确定它是否确实需
要重建？ 在拆掉并重建房子前，确定其结构是否牢固。若结构
良好，则可能是“改造”。 在开始重建前，确保你已经了解房子最初是如何建造
的。（墙内部，了解布线、管道以及内部结构。） 如果决定重建，一定要采用严格的方式，使用现在及将来都将获得高质量的做法。
如果开始重建，应该使用最现代的，耐久的材料。
8.6 软件再工程过程（ Software Reengineerin
g ）
8.6 软件再工程过程 （ Software Reengineering ）
软件再工程过程模型
软件再工程是一类软件工程活动，是一个工程过程 , 它将逆向工程、重构和正向工程组合起来 , 将现存系统重新构造为新的形式。
软件再工程过程模型所定义的 6 类活动
1. 库存目录分析2. 文档重构3. 逆向工程4. 代码重构5. 数据重构6. 正向工程
1. 1. 库存目录分析库存目录分析
对软件组织的每个应用系统都进行预防性对软件组织的每个应用系统都进行预防性
维护是不现实的，也是不必要的。一般说来，下维护是不现实的，也是不必要的。一般说来，下
述述 33 类程序有可能成为预防性维护的对象：类程序有可能成为预防性维护的对象：
该程序将在今后数年内继续维护的对象该程序将在今后数年内继续维护的对象
当前正在成功地使用着该程序当前正在成功地使用着该程序
可能在最近的将来要对该程序做较大程度的修可能在最近的将来要对该程序做较大程度的修
改或扩充改或扩充
应该仔细的、分析库存目录，按照业应该仔细的、分析库存目录，按照业
务重要程度、寿命、当前可维护性、预期务重要程度、寿命、当前可维护性、预期
的修改次数等标准，把库中的应用系统排的修改次数等标准，把库中的应用系统排
序，从中选出再工程的侯选者。然后合理序，从中选出再工程的侯选者。然后合理
地分配再工程所需要的资源。地分配再工程所需要的资源。
2. 2. 文档重构文档重构
老程序固有的特点缺乏文档，根据具体情况老程序固有的特点缺乏文档，根据具体情况
可采用下述可采用下述 33种方法之一来处理这个问题：种方法之一来处理这个问题：
1)1)如果一个程序是相对稳定的，正在走向如果一个程序是相对稳定的，正在走向
生命的终点，而且可能不会再修改它，则不生命的终点，而且可能不会再修改它，则不
必为它建立文档。必为它建立文档。
2)2)为了便于今后的维护，必须更新文为了便于今后的维护，必须更新文
“档，但是由于资源有限，应该采用 使用时建“档，但是由于资源有限，应该采用 使用时建
”立文档 的方法，也就是说，不是一下子把某”立文档 的方法，也就是说，不是一下子把某
应用系统的文档全部都重建起来，而是只建立应用系统的文档全部都重建起来，而是只建立
系统中当前正在修改的那些部分的完整文档。系统中当前正在修改的那些部分的完整文档。
3)3)如果某应用系统是用户完成业务工作如果某应用系统是用户完成业务工作
的关键，而且必须重构全部文档，则仍然应该的关键，而且必须重构全部文档，则仍然应该
尽量把文档工作减少到必需的最小量。尽量把文档工作减少到必需的最小量。
3. 3. 逆向工程逆向工程
软件的逆向工程是，分析程序以便在比软件的逆向工程是，分析程序以便在比
源程序更高的抽象层次上创建出程序的某源程序更高的抽象层次上创建出程序的某
种描述的过程，也就是说，逆向工程是一种描述的过程，也就是说，逆向工程是一
个恢复设计结果的过程。个恢复设计结果的过程。
4. 4. 代码重构代码重构某些老程序的体系结构比较合理，但是，一些模块的某些老程序的体系结构比较合理，但是，一些模块的
编码方式却是难于理解、测试和维护的。编码方式却是难于理解、测试和维护的。
在这种情况下，可以重构这些模块的代码。在这种情况下，可以重构这些模块的代码。
通常，代码重构并不修改程序的体系结构，它只关注通常，代码重构并不修改程序的体系结构，它只关注
个体模块的设计细节以及在模块中定义的局部数据结个体模块的设计细节以及在模块中定义的局部数据结
构。构。
如果重构扩展到模块边界之外并涉及软件体系结构，如果重构扩展到模块边界之外并涉及软件体系结构，
则重构变成了正向工程。则重构变成了正向工程。
5. 5. 数据重构数据重构
对数据体系结构差的程序很难进行适应对数据体系结构差的程序很难进行适应
性和完善性维护，因此，数据体系结构比源代性和完善性维护，因此，数据体系结构比源代
码对程序的长期生存力有更大的影响。码对程序的长期生存力有更大的影响。
数据重构是一种全范围的再工程活动。数据重构是一种全范围的再工程活动。
由于数据结构对程序体系结构及程序中的算由于数据结构对程序体系结构及程序中的算
法有很大影响，对数据的修改必然会导致程序法有很大影响，对数据的修改必然会导致程序
体系结构或代码层的改变。体系结构或代码层的改变。
6. 6. 正向工程正向工程正向工程也称为更新或再造。正向工程也称为更新或再造。
正向工程过程应用现代软件工程的概正向工程过程应用现代软件工程的概
念、原理、技术和方法，重新开发现有的某念、原理、技术和方法，重新开发现有的某
些应用系统。些应用系统。
在大多数情况下，经过正向工程过程后在大多数情况下，经过正向工程过程后
的软件，不仅重新实现了现有系统的功能，的软件，不仅重新实现了现有系统的功能，
而且增加了新功能，提高了整体性能。而且增加了新功能，提高了整体性能。
本章小结
• 软件维护的 4 类活动 （改正性、适应性、完善性、预防性）• 决定软件可维护性的基本要素 （可理解、可测试、可修改、可移植和可重
用性）• 文档是影响软件可维护性的决定因素• 软件再工程（预防性维护）
59
