1、北京理工大学 软件工程实践,汤铭端 中国航天科工集团公司204所,第九讲,软件维护和软件重用,内容和目的,了解软件维护的概念 掌握软件维护的种类 了解再工程的概念 了解逆向工程的概念 了解软件重用的内容和方法,维护的必要性,改正在运行中新发现的错误和缺陷 改进设计，以增强功能，提高性能 要求已运行的软件适应特定的工作环境，或已变动的数据和文件 使投入运行的软件与其它相关系统有良好的接口 使运行的软件的应用范围得到必要的补充,维护的起因,故障改正错误 新要求增加功能和优化 环境变化迁移,软件维护,软件维护是在软件产品交付之后，为纠正故障，改进性能和其它属性，或使产品适应改变了的环境所进行的修改活
2、动。 软件的维护不完全同于硬件的维护。对软件的维护就意味着修改，它不存在如硬件那样更换备件的维护工作。 软件维护一般分为完善性维护、适应性维护和改正性维护三种类型。,四类维护,完善性维护是为扩充功能和改善性能而进行修改和扩充，以满足用户变化了的需求。 适应性维护是为适应软件运行环境的变化而作的修改。例如因为硬件配置、系统软件的变化而要求进行的修改。 改正性维护是为了维持系统操作运行，针对在开发过程产生但在测试和验收时没有发现的错误而进行的改正。 第四种维护预防性维护，是为了进一步改进软件的维护性和可靠性，或者为进一步的提高提供一种更好的基础，而对软件进行的更改。,维护面临的问题,技术人员重开发
3、、轻维护 维护缺乏创造自由 维护是“无期”的 用户对维护了解不多，问题被搁置 将维护和开发混为一谈 如何维持旺盛士气，改善支援环境,影响维护各种的因素,系统大小 系统年龄 输入/输出数据项个数 应用类型 程序设计语言 结构化程度,维护任务,建立维护机构 提出维护申请报告 进行维护 记录和保持维护信息 维护评价,维护机构,正式和非正式的维护机构 维护管理员：管理维护工作 修改负责人：评价维护申请 系统监督员：决定如何进行修改,维护报告,外部：维护申请表（软件问题报告），由申请维护的用户填写，说明错误情况或新需求规格说明 内部：软件修改报告，指出 为满足某个维护申请表所需的工作量 所需修改变动的性
4、质 申请的优先级 预计修改后的状态,维护工作流程,维护记录保持,程序名称 源程序的数目 机器代码指令的数目 使用的编程语言 程序投入使用的日期 从投入使用以来，程序运行过的数目 与上有关的故障处理次数 程序改变的级别及名称 修改程序所增加的源语句数,修改程序所减少的源语句数 每次修改所付出的人时数 修改程序的日期 软件工程师的姓名 维护申请表名称 维护类型 维护开始和结束的日期 累计花费在维护上人时数 维护工作的净收益,维护评价,根据以下度量对维护进行评价： 每次程序运行的平均出错次数 花费在每类维护上的总人时数 每个程序、每个语言、每种维护类型的平均修改次数 花费在由于维护所增加或删除的每条
5、源语句上的平均人时数 用于每个语言的平均人时数 一个维护申请表的平均处理时间 各类维护申请的百分比,结构性维护,维护策略,减少改正性维护工作量的策略 减少适应性维护工作量的策略 减少完善性维护工作量的策略 将维护成本和延误减少到最低限度的措施,改正性维护策略,通过采用新技术，可大大提高软件的可靠性，减少进行改正性维护的需要 可在开发时考虑如下的方法： 利用应用软件包，所开发出的程序比用户完全自己开发的系统可靠性更高 使用结构化技术所开发的软件系统易于理解和测试 假如防错性程序设计,适应性维护策略,在进行配置管理时，把硬件、操作系统及其相关环境因素的可能变化考虑在内，可以减少某些适应性维护工作量
6、 如果把硬件、操作系统、各种外围设备的相关程序都归到特定的程序模块中，则可将因环境变化而需要修改的程序局限于一些特定模块，减少适应性维护工作量 使用内部程序列表、外部文件等，可为维护提供方便,完善性维护策略,使用数据库管理系统、程序生成系统、应用软件包等，可以减少维护工作量 开发时使用原型，让用户先期对系统进行评价，可以减少完善性维护的需求,将维护成本和延误减少到最低限度的措施,对于不断变化着的应用问题，要明确区分哪些是预先规定的，哪些是由用户支配的，懂得随着应用的变化，需要完全不同的技术 理解数据库技术的重要性 理解第四带语言对维护过程的作用 在作出一个系统的计划时，要估计长期维护的费用，并
7、选择一种能将这一费用降低到最小程度的技术 估计出用户在完善性维护方面潜在的作用 在最后进行程序设计之前，使用原型技术，以确保系统尽可能地适应用户的要求,维护的成本,软件维护的费用不断增加 典型的占结构的40%-60% 不及时合理的修改降低用户满意度 引发新问题降低重量 占用资源影响开发 维护的生产性活动 维护的“兜圈子”活动,M=p+Kec-d M=用于维护的总工作量 p=生产性工作量 K=经验常数 c=复杂性度量 d=对该软件的熟悉程度,维护工作存在的问题,根源主要在软件计划和开发方法方面的缺陷 “现在付钱呢？还是以后付钱。”,取理解他人的程序常是极为困难的，缺乏文档增加了困难 编码人员不经
8、常说明软件，人员流动使得无法由编码者维护 没有合适的文档或文档太少 大多数软件不是为以后的修改进行设计 人们没有把维护性工作看作有吸引力的工作,软件的维护性,软件的维护性是软件能够被理解、被校正、被修改和（或）被改善的容易程度 软件维护工作量的超线性增长是引起软件危机的一个重要原因，提高和保证软件的维护性是软件工程的一个关键目的,影响维护性的因素,在开发过程中粗心大意 文档质量低下 最重要因素是在需求分析时是否将提高软件的维护性作为一项重要要求明确地提了出来，并采取相应的办法来保证 采用的开发方法对软件的维护性也有影响,与开发环境有关的因素： 能否得到有经验的软件设计人员 系统结构是否易于理解
9、 系统是否便于使用 是否采用标准的编程语言 是否采用标准的操作系统 是否采用标准的文档格式 能否得到各种测试用例 有没有提供排错手段,维护性的实现,因为维护性是软件必不可少的特征，必须保证在软件开发时就认真考虑影响软件维护性的因素 在每个阶段的评审中，要对软件的维护性进行审查 在评审软件需求时，应注明将来可能要修改的地方 要讨论软件移植的问题，以及考虑会影响软件维护的系统接口 在设计评审中，要从易于修改、模块性及功能独立性方面去评价软件结构和模块过程 代码审查要强调程序风格和内部的文档资料 通过软件测试也可以知道，哪个程序在交付前应进行预防性维护,维护的副作用,修改软件是危险的。每当对一个复杂
10、的逻辑过程作了一处修改，出错的可能性就提高了。虽然文档化、评审、回归测试可以帮助消除错误，但是仍然会遇到维护的副作用。 与软件维护有关的副作用是指由于修改软件而造成的错误或其它不希望的事情。 维护有三种主要的副作用,修改程序的副作用,简单地改变一个语句有时会产生灾难性的后果。虽然每次对源程序的修改都有可能引起错误，但下列的修改更易产生错误： 1）删去或改变一个子程序； 2）删去或改变一个语句标号； 3）删去或改变一个标识符； 4）为改进运行性能所作的修改； 5）改变了文件打开或关闭情况； 6）改变了逻辑运算符； 7）设计的变动造成了较大的程序变动； 8）改变了边界判别。 修改程序的副作用范围有
11、大有小，大的可造成运行时的软件失效。 墨菲规律：“如果对一个源语句的更改可能引入错误，那么它将会引入错误”,修改数据的副作用,数据改变了，它可能不再与原先的软件设计相适应而产生错误。 修改数据的副作用是修改软件信息结构所引起的。 下述数据改变往往产生副作用： 1）重新定义局部的及全局的常数； 2）重新定义记录和文件的格式； 3）改变一个数组的大小或改变高层数据结构的大小； 4）改变全局数据； 5）对控制标志或指针的重新初始化； 6）重新安排IO或子程序参量。 修改数据的副作用可以通过完善的设计文档资料加以限制,文档资料的副作用,维护不应只注意修改源程序而应注意整个软件配置 修改了源程序而没有相
12、应地修改文档就会出现文档副作用 改动数据流、数据结构、模块过程或任何其它有关特征时，有关的技术文档资料必须要相应地更新 结构化的维护要求先维护设计，再依此维护软件的源代码 不能准确地反映软件现状的文档，可能比完全没有文档更糟糕。 在以后的维护工作中将出现副作用，那时仔细地阅读文档将得到对软件特性的错误认识。 用户认为软件就象描述其使用的文档中所介绍的那样。如果对可执行软件的改动没有在用户文档中得到反映，那就一定要产生副作用。 在重新交付前审计整个软件的文档，将可大大减少文档的副作用 有时维护工作的重点就是维护文档,维护“异常程序”,采用软件工程方法开发的软件，可以采用结构化维护方法来维护 对没
13、有按工程化要求开发的老程序（“异常程序”）的维护建议： 1)维护前先研究，力图得到尽可能多的背景信息。 2)努力熟悉（重画）总的控制流程，开始时先忽略细节。 3)分析现有文档确定其是否合理；在源程序清单中插入的注解。 4)充分使用编译/汇编所提供的交叉引用表、符号表等有用信息。 5)极为谨慎地修改，尊重此程序的风格格式，注释修改。 6)不要删除程序语句，除非你完全肯定它是没用的。 7)不要试图共用程序中已有的临时变量及工作区。为了避免麻烦，应该自行设置你自己的变量。 8)保存详细的记录（维护工作及结果）。 9)不要过于积极地劝说抛弃此程序而重新编写。 10)插入错误检验。,比“异常程序”更糟的
14、程序,当一类程序其控制流程图象一碗面条，其“模块”有2000行语句那么长，在9000行语句中只有3 行有意义的注释，而且再也没有其它的软件文档了，这个时候如何去对它进行维护？ 1)可以反复修改，不断地同软件和源程序“搏斗”，以实现必要的更改。 2)可以重新设计、重新编写和测试需要修改的那部分软件，在改写时，要采用软件工程方法。 3)可以重新设计，重新编写和测试该程序。 没有唯一“正确”的办法。即使第二种或第三种办法看来更好一些，但客观情况往往选定第一种办法。,预防性维护,第二、三种办法中体现了预防性维护的思想 软件的预防性维护还是一个有争议的问题，其概念为“把今天的方法学用于昨天的系统以满足明
15、天的需要”。 与其等待用户提出维护申请，不如事先就选择这样一些程序采用第二种或第三种方法进行预防性的维护： （1）它还将要继续运行若干年； （2）它现在的运行是成功的； （3）很可能在不远的将来就要进行大的修改或提高。,预防性维护是否太浪费,1)维护一行源语句的费用可能多达原先开发该行语句所花费用的40倍。 2)采用新的设计概念重新设计软件结构，可以使将来的维护工作十分方便。 3)由于已经有了一个软件模型，因而开发的生产率必然远高于平均生产率。 4)用户对这些软件已有经验，因此可以比较方便地确定新的要求以及定出修改的方向。 5)在预防性维护完成的时候，就可以得到一套系列的软件文档。 很多软件开
16、发机构在对他们的软件产品推出新一代的版本时，可以看得出其中已经作过预防性维护了。,再工程（Re-engineering）,业务再工程：“搜寻并首先业务过程中的根本性改变以达到突破性结果。” 软件再工程：对软件产品的再工程，软件的重新构建。 对软件再工程的强调源于30年不断形成的软件维护冰山。,一个软件再工程过程模型,软件再工程,库存目录分析：分析现有产品使用维护信息，选出再工程的候选者 文档重构：对文档进行选择性的重构 逆向工程：最常见的再工程类型 代码重构：通过检查软件产品导出比源代码更高抽象层次的表示 数据重构：对数据结构进行重构，全范围的再工程 正向工程：革新或改造，重新生成就系统的功能
17、，预防性维护,逆向工程过程,软件重用（Reuse）,重复使用软件的部分或整体,软件重用的益处,节省费用和（或）时间 提高质量可靠型 减少项目风险 提高开发效率,软件重用的障碍,公司和组织没有任何的软件重用计划 开发者不使用软件重用辅助工具 缺乏培训 认为重用相对于其价值来说带来更多麻烦 公司鼓励采用对重用无促进作用的开发方法？ 对重用没有激励措施,建立重用途径的建议,建立内部的软件重用计划 要求将软件重用作为任何技术和管理培训的一个不可缺少的部分 按照内部的软件重用计划，寻求对软件重用有最积极贡献的工具和库 鼓励采用已经被证明为可以促进软件重用的方法和工具 跟踪并测量软件重用以及软件重用的影响
18、 管理上必须显示它积极地鼓励软件重用 认识到模块外，工具、数据、设计、计划、环境、其它软件项均可重用 认识到软件重用是一项革新、改进,基于构件的开发,识别候 选结构,在库中 查找构件,如果存在 则提取构件,如果不存在 则建造构件,将新构件 放入库中,建造系统的 第N次迭代,可重用的软件制品,项目计划 成本估计 体系结构 需求模型和规格说明 设计,源代码 用户和技术文档 用户界面 数据 测试用例,重用数据,程序不做任何修改，甚至输入输出数据也无需改动，就可以从一个环境移到另一个中使用 大多数数据库管理系统商品软件允许许多共享数据库中的数据 但还不存在一种万能的数据交换格式，能很方便地把数据从一个
19、系统移到另一个系统中 在数据的定义扩展到包括声音、图形、图像等的情况下，共享数据的困难越来越大，标准的数据交换格式对于数据的重用越为越重要 随着数据重用程度的增加，数据的安全保密问题更加突出,重用模块,早期可重用模块的概念是单个函数，它们不需要逐行编码就可以连接到一个程序中去，如许多高级程序语言中的标准函数就是实例 后来这个概念又有扩充，重用模块不仅包括将模块连接到大程序中去，而且包括程序生成器和第四代语言，在那里实际的函数对使用者是隐蔽的，但它们在实现用户要求中做了有用的工作 还有非常高级的语言，如面向问题的语言，它们有很多强有力的函数，由简单的表达式调用,重用结构,有效的重用应有一个结构上
20、的考虑，而不仅是将模块连接在一起。这样的结构应有以下一些属性： 重用模块或程序的所有数据描述应当作为模块或程序的外部量说明； 重用模块或程序的所有字符或常量应当作为模块或程序的外部量说明； 重用模块或程序的输入/输出控制应当在模块或程序的外部执行； 重用模块或程序应当只由应用逻辑组成 如果能够得到满足上述属性的通用功能的基本集，就可以利用这些集合中的元素构造出新的系统。,重用设计,软件设计与实现是两个不同的阶段 若对于同一设计，可以采用不同的实现方法，则这样的设计就是可重用的 近年来，许多科学家在尝试使用不同的程序设计语言来编写通用应用问题的实现 通用应用程序设计类型的构造方法的可用描述，目前
21、还在探讨中,重用规格说明,在基本需求不改变，或某一新问题与过去的某一软件在某个抽象层次上层同一类的情况下，原规格说明仍可使用或可参照使用,重用之前先设计重用,什么东西可能可以被重用 但经验表明，只有当设计软件时以可重用为设计目标，认真考虑本软件将来如何方便其它软件对自己的重用，才可能得到可重用的软件。 要实现软件重用，就必须将已被验证的、确实会有用的各软件组成部分先做成是可重用的,软件重用的技术,进行软件重用的技术可分为两大类： 合成技术 生成技术 构件方法（合成技术）支持自底向上的软件开发方法 变换方法（生成技术）侧重于程序的推导方式、推理规则，支持自顶向下的软件开发技术,合成技术,在合成技
22、术中，构件(Building Blocks)是重用的基石 构件方法以抽象数据为理论基础，借用了硬件中集成电路芯片的思想：即将功能细节和数据结构封装隐蔽在构件内部，有着精心设计的接口，而所有关于功能性及接口的知识都足以使其在开发中像芯片那样来使用，以组装成更大的构件。 一个构件可以是对某一函数、过程、子程序、数据、算法等可重用软件成分的抽象。 使用构件块概念的软件合成重用技术，有较高的生产率和较短的开发周期。 在IBM系统软件的开发中使用了以上基于构件概念的合成重用技术，取得了很好的效果。,生成技术,生成技术利用可重用的模式(Patterns)通过生成程序产生一个新的程序或程序段，产生的程序可以
23、看成是模式的实例 可重用的模式有两种不同的形式：代码模式和规则模式 代码模式的例子是应用生成器，可重用的代码就存在于生成器自身。通过特定的参数替换，生成抽象软件模式的具体实体。 规则模式的例子是变换系统，它利用变换规则集合。其变换方法中通常采用超高级的规格说明语言，形式化地给出软件需求规格说明，利用程序变换系统（有时要经过一系列的变换），把用超高级规格说明语言编写的程序转化成某种可执行语言的程序。这种超高级语言抽象能力强，逻辑性强，形式化好，便于使用软件者维护。,谢谢！,68389085（O） 68389504（H） ,序号 姓名 性别 年龄 职称 单位 通讯地址 邮政编码 EMAIL，传真,
