实用软件工程软件维护

《实用软件工程软件维护》由会员分享，可在线阅读，更多相关《实用软件工程软件维护（102页珍藏版）》请在金锄头文库上搜索。

1、第十一章第十一章 软件维护软件维护 大约20年前，软件工程人员对做完的程序将不再关心，犹如过时的报纸，程序被束之高阁或弃而不问。到1988年，软件界第一次提出“千年虫问题”，工程人员不得不从洪水般的源代码中去寻找“时间变量”。虽然，所需修改的仅仅是变量的类型或长度，但在全球的软件行业中却掀起了巨大的波澜。 由此可见，软件投入运行后，进行一定的修改和维护是必不可少的。软件维护是软件生命周期的最后一个阶段,最长的一个阶段,也是最为重要的一个阶段，软件维护工作的好坏直接影响到软件使用的成功与否。 对于软件维护工作，我们要有正确的认识，其一、从工作量的角度看，软件维护往往会花费软件开发组织的大量时间，

2、随着用户对软件需求的不断变化及软件环境的改变，软件维护的工作量逐渐递增。当今软件开发人员和维护人员匮乏，如何利用有限的软件工程技术人员去满足节节攀升的软件维护需求是一个亟待解决的严峻问题。其二、从资金投入的角度看,软件属产品范畴，但又不同于普通商品，软件在投入运行后需要追加大量的维护资金，投入量大约是开发成本的四、五倍，甚至更高。 本章我们将主要谈谈软件维护的基本概念和软件维护的过程，以及如何提高软件的可维护性、降低软件维护的时间、经济成本和软件维护的发展趋势。q软件维护的基本概念 q软件的可维护性 q软件维护的过程分析 q基于构件复用的软件再工程第一节 软件维护的基本概念 一、软件维护的定义

3、所谓软件维护(Software Maintenance)就是在软件已经交付使用之后，为了改正错误或满足用户新的需要而修改软件的过程。软件在投入运行之前，往往要经过严格的测试，但事实表明，测试阶段不可能完全暴露软件潜在的错误。同时，用户的需求是发展的，软件能充分满足用户需求是软件工程人员追求的最高目标，也是软件生命力所在。 据美国程序员杂志1995年7月提供的统计资料，全球大约5/6的软件项目存在失败的部分。所以，软件维护是任何软件生命周期必不可少的阶段，忽视软件维护的软件工程是盲目的、危险的。 当今信息技术发展迅猛，计算机软硬件的升级频率越来越快，网络等通讯技术突飞猛进，增加了软件系统环境的复

4、杂性，也使软件维护的方式产生了根本性的变化。诸如电话提供解决方案、定期上门维护和网上指导性维护等方式已经逐渐成为当今软件维护的主要方式。 二、软件维护的分类 ANSI/IEEE在20世纪80年代从软件维护类型的角度给出了软件维护的定义：“软件维护是指软件成品提供使用后，为了修改差错、改善功能和性能、适应环境变化而进行的软件修正。”这个对软件维护的定义给出了软件维护的分类。软件维护通常包括四类：q为了纠正在使用过程中暴露出来的错误而进行的改正性维护；q为了适应外部环境的变化而进行的适应性维护；q为了改进原有的软件而进行的完善性维护；q以及为了提高可维护性和可靠性而进行的预防性维护。( ( ( (

5、一一一一) ) ) )正确性维护正确性维护正确性维护正确性维护（corrective maintenance） 正确性维护又称改正性维护，其主要任务是完成软件潜在错误的改正。 （二）适应性维护（二）适应性维护（二）适应性维护（二）适应性维护(adaptive maintenance) 适应性维护指为适应软件的外界环境变化而进行的修改,它是由软件生存的环境变化引起的。任何系统总是存在于一定的环境之中，环境与系统相辅相成、相互作用。 对软件来说，环境变化源于以下几个方面：(1)用户需求变化。随着企业业务的不断变化和发展，原系统业务流程图已不能准确描述现有企业业务状况，因此，既存软件系统已经无法完全

6、满足用户的需求，原系统的数据变量定义和相关算法要做适当修改。例如，国家税费调整、电话区号调整及千年虫问题等等。 (2)软件环境的变化。其一、硬件和操作系统更新。软件运行的平台变化是软件适应性维护的主要因素之一。由于硬件的更新换代，拓宽了软件的运行空间，为软件运行效率的提高提供了基础，不对软件进行适应性维护将对硬件资源造成巨大的浪费。同时，高版本操作系统的推出，导致了大量应用型软件与操作系统的冲突，必须对现有软件进行适应性维护。其二、系统运行环境的变化。如由主机方式变为客户/服务器方式，由客户/服务器方式变为Web方式，这时的系统体系结构必须做相应的改变。 (3)开发环境的升级。譬如现在常用的V

7、C+、PowerBuilder等开发环境的升级换代如同操作系统一样频繁发生，这样也会对系统提出适应性维护需求。（三）完善性维护（三）完善性维护（三）完善性维护（三）完善性维护(perfective maintenance)完善性维护指为扩充系统的功能和改善系统性能而进行的修改，一般包括增加或修改功能，提高系统的安全性、处理能力等任务。完善性维护通常需要用户领域的介入，并且是一个带反馈的反复的功能追加过程。从现实情况来看，现阶段软件维护的主要形式是完善性维护，据有关统计数据表明：全部维护活动的50%到70%是完善性维护。 完善性维护的的一般模型完善性维护的的一般模型完善性维护的的一般模型完善性维

8、护的的一般模型 ( ( ( (四四四四) ) ) )预防性维护预防性维护预防性维护预防性维护(preventive maintenance) 预防性维护是为减少或避免以后可能需要的前三类维护而对软件配置进行的工作，通过再结构化、再标准化等系统优化方法，提高系统的可维护性，对文档进行维护，对数据进行重组。预防性维护有较强的前瞻性，而且做好预防性维护工作能降低或避免因为维护工作不充分、不及时导致软件系统瘫痪带来的灾难性后果。 随着网络及通讯技术高速发展，我们对软件维护又提出了新的要求。网络环境下软件的安全问题、软件遭受黑客攻击及病毒破坏后的软件系统的恢复工作也纳入软件维护的范畴。所以也可以这样说，

9、软件维护是指软件在交付使用后，为了使软件能正常工作、修改潜在错误和满足用户新需求的一系列对软件的修改及复原工作。 三、三、软件维护的内容软件维护工作一般发生在客户使用软件产品的过程中，由软件维护的分类可以看出，软件维护工作一般由软件的用户和软件开发人员（或专职软件维护人员）共同完成。其主要内容包括如下几点： （一）程序维护程序维护是指根据使用的要求，对程序进行全部或部分修改。程序维护的最终目的是满足用户的需求，对传统的软件工程而言，程序维护要修改用户需求的概念模型和详细设计，并对源代码进行重新修改，所以工作量较大且容易对原有功能产生破坏，这是程序维护中不可忽视的一个问题。另外，根据需要进行修改

10、以后，必须书写修改设计报告。修改设计报告必须和源代码同时维护，只有与程序完全一致的修改设计报告才是真正有价值的文档。 （二）文件备份及修复 文件备份及修复属于数据维护的范畴，包括安装与转换新的数据库出现异常或溢出时的补救和维护工作。我们知道，对计算机系统而言，无论是硬件系统或软件系统都有其脆弱性，所以如何提高其可靠性一直是我们研究的重要课题。定期进行文件和数据的备份和异常情况下的数据修复是提高软件可靠性的一个有效手段。 （三）查杀病毒计算机病毒对计算机软件的正常工作造成巨大的威胁。一九八三年计算机病毒首次被确认，当时人们并没有引起足够的重视。我国于一九八九年在计算机界发现病毒。现在，全世界已发

11、现数万种病毒，并且还在高速度增加。由于计算机软件的脆弱性与互联网的开放性，我们将与病毒长久共存。病毒正朝着能更好的隐蔽自己并对抗反病毒手段的方向发展，同时其破坏性越来越强，CIH病毒开创了对硬件严重破坏的先河。对用户来说，要加强软件系统的可靠性，查毒杀毒是软件维护阶段必不可少的一个环节。降低病毒危害最有效的两个方法是：缩短数据备份周期和加快杀毒软件的升级频率。 （四）硬件维护硬件人员应加强设备的保养以及定期检修，并做好检验记录和故障登记工作。虽然，硬件维护严格意义上不是软件维护的范畴，但是没有硬件的强有力的支持，软件就失去了运行的平台，硬件维护是软件维护的基础工作。硬件维护包括评估现有硬件设备

12、、检测系统老化程度和运行状况、确定升级方案和购买方案等等。 （五）系统优化系统优化是从系统全局出发，协调系统内部各组成单元之间的连接关系，使整个系统按预定目标在整体上达到最优。现在的软件不管操作系统还是应用软件，随着其功能扩充与增强，变得越来越臃肿、缓慢，我们还是只能忍受着，因为不管怎样，我们必须要用它。鉴于此，我们要采用不同的优化方法，针对不同的系统、不同的环节来采用不同的优化策略。 四、软件维护的特点软件维护工作是一个变化的过程，这是由于软件生存的内部环境和外部环境的变化引起的，任何企业业务不可能较长时间的不变化，所以，软件系统需要随着企业业务及管理模式的变化而进行适当调整。当然，软件维护

13、不同于计算机硬件或网络产品，它有自己的维护特点。 （一） 软件维护耗时费力软件维护是一项非常耗时、耗精力的工作。由于现代企业的发展速度快，业务内容及业务流程不断变化，用户不断追加功能需求。这样，软件维护的周期大大缩短，软件开发人员必须投入大量的人力、物力和财力去从事软件的维护工作。另外，软件用户计算机应用的能力及熟练程度不同，造成用户对软件的使用情况参差不齐，本来应该在软件培训阶段完成的工作又要在维护阶段再一次提出来。 近期的调查报告发现软件工程20%的工作量用在开发上，而80%用在维护上。但是，如果对于软件的频繁修改、排错和功能追加，加上没有规范的管理手段、有效的方法和技术，可能很快就会导致

14、软件结构的混乱和质量下降，最终结果是软件的夭折或提前报废。 （二） 软件维护的代价昂贵回顾软件业发展的历史，我们不难看出，软件维护的费用所占软件工程总费用的比重节节攀升。从1970年到1990年的20年间，比重成倍增加，达到80%。软件维护的代价是多方面的，除了经济方面的代价外，软件维护还可能导致用户对软件开发人员的不信任或不满；软件维护的改动，会破坏原有系统的完整性，引入潜在错误，降低了软件质量的可靠性；同时，当今软件开发人员的短缺是导致软件危机的原因之一，软件维护工作花费了软件工程师的大量时间和精力，使软件的生产率无法提高。 （三） 远程维护是现代软件维护的新途径通讯和网络技术的发展为软件

15、的维护提供了便捷的方式。软件使用中会出现各种各样的问题，其中有的问题可以通过电话、E-mail、在线交谈和视频指导等方式加以解决。还有一部分问题，由于用户对软件的开发环境不熟悉，维护人员对用户的使用情况又不了解，所以维护人员必须看到问题发生的实际情况才能解决。 如果软件维护人员到用户的单位去，这样既浪费了时间又给用户添加了经济负担。Symatec公司推出的Pcanywhere软件可以把用户的软件使用实际情况再现于维护人员的计算机上，维护人员可以实现远程维护。Pcanywhere软件提供了文件传输、远程控制和远程网络需求的总体解决方案，它具有如下功能：1 Pc-Pc的远程控制2 文件传输3 运用

16、远程网络连接使一台电脑成为网络中的工作站当然，基于WEB的多媒体软件维护系统也是现代经常使用的一种软件维护方式之一。（四） 软件复用技术简化了软件维护软件的复用以构件为基本单位，构件是可以明确辨识的构成成分，软构件指在软件系统中具有一定意义的相对独立的软件构成成分。特别是完善性维护需要的正是可以被其它软件系统复用的、具有相对独立功能的系统构成成分。基于构件的软件工程的兴起、构件库的建立与维护越来越受到软件工程师的重视，我们可以展望，在不远的将来，完善性维护工作将更加简单化、产业化和自动化。 结构化维护与非结构化维护差异明显对结构化维护而言，起点是评价设计文档，维护步骤如下：1 确定软件结构特点

17、；2 性能特点分析；3 接口特点分析；4 估量改动带来的影响；5 计划实施途径；6 修改设计并仔细复查；7 编写相应的源代码；8 进行回归测试；交付使用。 然而，非结构化维护的起点是评价程序代码，其主要特征是难于评价软件结构、全程数据结构、系统接口和代码改动的后果。非结构化维护的步骤如下： 1 分析用户需求；代码评价；评价反馈；重编程序；复查（含重编程序反馈）交付使用。从两种维护的方式可以看出，非结构化维护以浪费大量的精力为代价，原因是没有使用良好定义的方法论来开发软件；相反，结构化维护能够使维护工作井然有序，减少时间和精力的浪费，并且提高软件维护的质量。 第二节第二节 软件的可维护性软件的可

18、维护性 一、 软件的可维护性软件的可维护性是指软件能够被理解、改正、适应和完善，以适应新的环境的难易程度。可维护性的好坏是衡量一个软件工程成功与否的重要参数，而且在软件开发的每一个阶段可维护性都是一个不容忽视的问题。事实表明，目前现有的很多软件维护工作开展困难甚至无法进行，原因是多方面的，但有一点是共性，原有软件的可维护性较差。软件可维护性研究的主要目的就是提高软件维护的可能性，降低维护的花费，并把软件维护人员从繁琐的维护工作中真正解放出来。 二、软件维护中问题与软件维护有关的绝大多数问题的根源在于计划阶段和开发阶段的工作有缺点,可以这样说，软件的开发阶段潜在的错误和设计、规划的不合理是软件维

19、护阶段问题出现的根本原因。实践表明，绝大多数的软件工程的软件维护阶段均会不同程度的出现如下典型问题： q程序的源代码或算法可读性差，加大了软件维护的难度。q文档丢失或文档不全。q软件的开发人员和软件维护人员分离，软件维护的逆向工程花费软件维护人员的大量时间和精力。q软件本身可修改性差，无法二次开发。q开发方和出资方对软件维护的认识不足，资金追加不够，软件维护工作无法深入。q软件维护工作繁琐，时间长，影响软件的正常使用，容易导致用户对软件维护人员和软件系统的不信任。软件开发人员在软件开发过程中应该力求避免软件维护阶段出现的问题。软件开发的工程化、软件管理的科学化有助于解决与软件维护有关的若干问题

20、，所以，增强软件的可维护性是软件工程人员在软件开发全周期必须时刻考虑的一个重要问题。 三、软件可维护性的决定性因素软件生命周期每个阶段的工作都和软件可维护性有密切的关系。良好的设计、完善的文档资料以及一系列严格的复审和测试，使得一旦发现错误比较容易诊断和纠正。因此，在软件周期的每个阶段都必须充分考虑可维护性问题，并且为软件维护作好准备。从软件自身的角度看，软件的可理解性、可测试性、可修改性和可移植性是决定软件可维护性的基本因素。 （一）文档的健全性文档是影响软件可维护性的最重要因素，有时甚至比可执行代码更为重要。文档可分为用户文档和系统文档两大类。不管是哪一类文档都必须和源代码同时维护，只有与

21、程序完全一致的文档才是真正有价值的文档。(二) 可理解性 可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。我们知道，现在算法描述的工具和编程语言种类繁多，短时间内不可能实现完全统一，所以模块化、详细的设计文档、结构化设计、源代码的内部文档等都是增强软件可读性和可理解性的有效方法。（三）可测试性 可测试性是对软件正确性论证的容易程度。软件工程中，软件修改和测试的难易程度主要取决于软件容易理解的程度。（四）可修改性 可修改性是指软件容易修改的程度，这里的修改主要针对源代码或有关文档。软件的可修改性和软件设计原则直接有关。可修改性好的软件在维护时出现连带错误的概率相对较小。 （

22、五）可移植性随着面向对象的软件工程和基于构件的软件工程技术的发展，软件的可移植性也成为衡量软件可维护性的一个重要方面。可移植性指软件的部分程序和某些模块转移到另一个计算机环境中去并能发挥功能的可能性。可移植性强的软件不依赖于具体的计算机环境，可以在不同的计算机和操作系统中正常工作。 影响软件可维护性的几个因素是紧密相关的。没有健全文档的软件维护几乎无法进行；维护人员在正确理解一个程序之前根本不可能修改它；如果不能进行完善的诊断和测试，则表面正确的修改可能引起其他故障；可移植性强的程序往往可以进行单独测试，也便于软件整体的修改维护。因此，在软件开发的各个时期，我们应该把软件的可维护性作为一个关键

23、目标。只有这样才能保证软件在较长的时间内能正常运行，即使有维护需求，也能在较短时间内实现软件的维护，从而保证软件有较好的可用性。 四、软件开发各阶段的可维护性要求软件的维护是软件工程的最后一个阶段，指在软件交付使用之后为保证软件能正常运行所进行的一系列后期工作。但是，软件的可维护性贯穿软件开发的各个阶段，没有各阶段可维护性保证，交付使用的软件根本不可能实现维护。在软件开发的各阶段应注意如下方面： （一）需求分析分阶段：对用户潜在的需求进行分析并留有实现的空间；对将来可能改进的部分和可能会修改的部分加以注意并指明；应该考虑软件的可移植性问题，软件的复用可以增加软件的可维护性和降低软件维护工作量；

24、考虑可能实现软件维护的系统体系结构。 （二）设计阶段：在设计阶段，代码冗余设计、编写健全的文档等都与可维护性相关；应该从容易修改、模块化和功能独立的目标出发；设计中应该对将来可能修改的部分预先做准备。 （三）编码阶段：编码阶段编码风格和内部说明文档是影响可维护性的两个重要因素；不同的程序设计语言编写的程序可维护性不同，一般情况下，高级语言的程序比低级语言程序易于维护。同样是高级语言，各自的可理解性也不同，目前看来，非过程化语言和面向对象的语言较容易维护 （四）测试阶段：软件测试实现预防性维护，检查所有的软件配置是否完整和可理解。（五）维护阶段：在完成每次维护工作之后，要修改源程序、设计文档和用

25、户手册。单纯的源代码修改会给以后的软件维护带来障碍，产生严重的后果。 五、软件文档对软件可维护性的意义良好的可维护性可以更快、更好地解决软件技术问题；提高软件运行的性能和可靠性；为了从耗时费力的软件维护问题中解放出来，降低用户软件运行成本，减少混乱或瘫痪的时间，我们有必要进一步研究以提高软件的可维护性。然而，软件文档对软件的维护具有举足轻重的作用，软件文档是软件维护的入口。 （一）软件文档的定义软件文档是对软件总目标软件各组成部分之间的关系、软件设计的策略和软件运行过程的历史数据的说明和补充。软件本身不属于软件文档范畴，但是文档和软件的源代码同样重要，缺一不可，相辅相成。 （二）软件文档的内容

26、要求：系统使用说明书系统安装和管理说明系统需求和设计说明系统的实现和测试说明（三）软件文档的分类： （1） 用户文档的内容： 功能描述：说明系统功能 安装文档：说明如何安装系统以及硬件配置需求。 使用手册：简要说明如何使用系统 参考手册：描述用户可以使用的所有系统设施以及它们的使用方法。解释系统可能产生的各种出错信息的含义。 操作员指南：说明操作员应该如何处理使用中出现的各种情况。 （）系统文档的内容：系统文档是指从问题定义、需求说明到验收测试计划等一系列和系统有关的文档。软件维护费用在软件产品的开发费用中占了很大一部分，应该说是最难的工作，开发人员最不愿意作的工作，特别是在没有文档的情况下。

27、要想提高维护效率，首先开发过程中各种文档一定要齐备、同时要保持与代码的同步，此外代码书写过程中遵循一定的规则（命名、注释等）。有了这两部分，维护工作就不会无处下手了。 第三节软件维护的过程分析第三节软件维护的过程分析 一、软件维护的管理体系维护工作中最常见的问题是错误扩散，主要包括纠错性错误扩散与完善性错误扩散。因此，软件维护需要建立一套完整的、科学的管理体系，即维护管理体系。对于产品的维护不能随便进行，要求建立申请判断实施检查的过程，也就是任何维护工作都要向有关部门申请，相关部门判断决定是否实施及实施优先级，维护完成后还需要检查确认，维护工作都要有记录。 在纠错过程中，往往纠正了这里的错误又

28、引发了其它地方发生错误，特别是全局性的函数、变量、过程、结构体的修改一定要慎重，此外各种接口的修改也要慎重，千万不要引发其他的错误。完善性维护增加了新的功能，也增加了出错的可能，对此一定要反复测试，最基本的要求就是不要破坏已有的正常功能。维护活动完成后，一般要进行回归测试，回归测试完成后才可交付用户使用。其具体过程如下图： 软件维护管理体系软件维护管理体系软件维护管理体系软件维护管理体系 然而，如何实现新旧系统的转换呢？到底是直接取代用户现在使用的老系统，还是新旧两套一起并行运行呢？如果系统不是很重要，则可以马上取代旧系统，应用修改过的新版本；如果对用户利益重大则最好新旧一起用，互相参照监督，

29、防止新版本出现了老版本没有的问题，直到用户确认了新系统。维护版本交付前，涉及软件的数据库等相关资源都要备份，保证安全。 二、软件的维护过程（一）建立维护组织软件维护组织不是一个正式的常设组织，往往是根据维护要求的提出而临时成立，它是一个为实现软件维护而成立的人员团体。软件维护组织通常由用户、技术员、维护管理员、高级系统管理员和局部系统管理员组成，如下图所示： 软软件件维维护护组组织织原软件系统+维护需求用户技术人员维护管理员各级系统管理员维护后的软件系统（二）编写维护报告首先，我们要获得用户提出的维护需求，其方法可以让用户填写用户维护申请表。维护需求有四类，不同的维护需求表述的方式不同。对适应

30、性和完善性的维护需求，用户应该给出尽可能简洁的、准确的需求描述。改正性维护往往是由于遇到软件运行的错误，则用户必须详尽的描述错误发生的原因、导致的相关后果，以及错误发生时软件运行的环境。软件维护报告申请表设计如下图所示： 软件维护申请表申请表编号:申请日期: 年 月 日项目编号项目名称维护类别软件维护硬件维护改正性完善性适应性预防性系统设备外围设备问题说明:维修要求:维修优先级申请人维护方式远程/现场申请评价结论:评价负责人: 评价时间: 软件维护申请表根据用户给出的维护需求描述（表格或说明书），软件组织要给出针对用户提出的维护需求的软件修改报告，软件修改报告的内容比软件维护申请报告的批复要详

31、细。软件维修报告要求给出维护工作量需求、维护要求的性质和与修改有关的数据。软件修改报告交系统变化授权人审查后生效，软件组织可以进行下一步详细的软件修改计划的制定和软件修改的实施。 （三）进行软件修改软件的维护是对正在使用的软件进行修改，它对软件系统的正常使用造成影响，所以在软件修改实施前必须提交申请报告。获准的对软件的修改才是合法的，软件修改的主要内容和步骤如下： (1)由系统管理员提出软件修改请求报告； (2)由有关领导审批请求报告； (3)源程序清单存档； (4)手续完备后，实施软件的修改； (5)软件修改后形成新的文档资料； (6)发出软件修改和使用变更通知； (7)进行软件修改后的试运

32、行； (8)根据运行情况作总结调整并修改文档资料； (9)发出软件修改后，正式运行通知； (10)软件做新的备份，并同定稿的文档资料一起存档，这里的文档主要应包括以下内容：维护的审批人、提请人、维护人的姓名、维护时间、修改原因、修改的内容、修改后的现状。（四）保存维护记录为了能正确的计算软件维护的代价，评估维护技术的有效性，我们要求完整的保存维护记录。维护记录作为重要的文档为再次软件维护增强了可维护性。维护记录的保存到底选取哪些数据呢？ Swanson提出了十八点内容： 1.程序标识；2.源语句数；3.机器指令条数；4.使用的程序设计语言；5.程序安装的日期；6.安装程序后运行的次数；7.安装

33、程序后失效的次数；8.程序变动的层次和标识；9.因为程序变动而增加的源语句数；10.因为程序变动而删除的源语句数；11.每个改动耗费的人时数；12.程序改动的日期；13.软件工程师的名字；14.维护要求表的识别；15.维护类型；16.维护开始和完成的日期；17.累计用于维护的人时数；18.与完成的维护相联系的纯效益。以上18条是保存维护记录的主要内容，可以针对具体的维护状况适当增减记录的数据。总之，维护记录的保存是为了健全文档，便于维护代价的计算、维护技术的评估和增强软件的可维护性。 （五）评价维护结果 这是软件维护的最后一个阶段，其主要目的是对维护的结果进行评价。维护结果的评价建立在相关数据

34、的基础之上，所以，维护的档案记录要做好。根据档案记录的数据可以对维护工作做定量的计算和评估。软件维护的评估可根据保存的维护记录从七个方面进行，如下图所示：软件维护定量评价方式软件维护定量评价方式软件维护定量评价方式软件维护定量评价方式 二、软件维护引起的系统价值变化计算机系统的组成分两大类，一是硬件系统，另一个是软件系统。软件系统由系统软件和应用型软件组成。软件维护对硬件的价值不发生影响，但是，随着硬件技术的飞速发展和硬件设备生产的规模化，硬件的更新加快而且价格的下降趋势迅速。 再者，操作系统平台的升级换代周期越来越短，换代比例越来越高。半个世纪以来，大部分软件资产并没能像硬件那样频繁地经历彻

35、底的更新换代，为了适应硬件的飞速换代，环境适应性维护周期也越来越短，范围越来越大，加之用户的需求变化，完善性维护的频率越来越快。软件维护的人、财、物的投入必影响计算机系统的价格构成。从软件的价值随着生存期而递增的特点来看，这并不违背市场经济的价值规律。随着维护的深入，软件价值总体呈递增趋势。软件维护对系统价值的构成的影响情况如下图所示： 20多年前曾有人预言：软件进入维护期的比例将随软件递增率一起增长，进入21世纪后将有80%的软件人员从事维护性开发。由此可见，软件财富的绝大部分是由软件维护阶段创造的，那么应该重视软件维护，提高软件运行的可靠性，实现软件维护的真正目标。 软件维护对系统价值比的

36、影响软件维护对系统价值比的影响软件维护对系统价值比的影响软件维护对系统价值比的影响 第四节第四节 基于构件复用的软件再工程基于构件复用的软件再工程几十年来，硬件发展速度和更新换代的周期呈指数型递增，而软件生产率表现为螺旋形发展，总也追不上硬件。同时，社会对软件的需求飞速增长，软件的开发能力不能满足社会需求的矛盾越来越突出。因此，以软件复用（Software Reuse）和软件构件(Software component)为核心的软件再工程方法应运而生。 软件再工程（Software Re-engineering）是指对既存对象系统进行调查，并将其重构为新形式代码的开发过程。最大限度地重用既存系统

37、的各种资源是再工程最重要的特点之一。显然，软件再工程的关键技术是软件复用，软件构件是再工程的核心与基础，也是软件复用的基本单位。我们认为，软件再工程是未来一段时间软件工程的主流，它是解决软件维护的有效手段，也是软件生产率提高的最佳方式之一。 一、软件再工程的起源软件产品在其有限的生命周期后将会失去其原有的功能与市场，虽然不同于日常生活中的普通商品给环境带来巨大的污染，但是我们认为，只有可以经过加工再利用的产品才能称为“绿色的环保的产品”。现阶段，一面是人们日夜增长的软件需求，一面是软件的开发能力相对不足，大量的既存软件系统被弃之不用，带给人们的是巨大的资源浪费。 与其它的商品不同，越是庞大的、

38、历史悠久的软件系统越是宝贵的无形遗产。对既存软件系统的浪费就是对宝贵遗产的损害，有人说，继承过去是软件的立身之本，身后的历史越长，前面的路就越宽。如果我们能轻松的重用过去，就能使软件工程产生一次巨大的飞跃。 二、软件再工程的定义软件危机导致了软件再工程的产生和发展。软件再工程的主要任务是优化软件体系结构，增强软件的可维护性和可移植性，提高软件产品的生产效率和产品质量。Linda H.Rosenberg博士这样定义了软件再工程：“软件再工程是为了以新的形式重构已经存在的软件系统而进行的检测、分析和更替，以及随后的对新形式的实现”。 三、软件再工程的过程模型软件再工程是一个过程，但不同于传统软件工

39、程。再工程经过抽象、改造、精化三个阶段，其过程可以用下图描述： 基于构件的软件再工程的一般模型基于构件的软件再工程的一般模型基于构件的软件再工程的一般模型基于构件的软件再工程的一般模型现存系统源代码原概念世界改造用户世界用户需求目标概念世界目标系统源代码抽象构件库精化整合构件实例搜索引擎可见，软件再工程的过程源于源代码，以构建目标系统源代码为终点。通常，我们把从现存系统的代码分析、结构设计、实际需求分析到抽象出概念世界的过程称为逆向过程，因为它与传统软件工程的开发过程相反。在改造阶段，往往考虑到对系统新功能的添加，需要用户领域的介入。 另外，我们把从目标概念世界到实际需求分析、结构设计和目标源

40、代码的生成过程称为正向过程。所以说，软件再工程实际上属于软件生命周期中软件维护的范畴，这种维护的主动性更强，它不是单纯的改正性维护，相反，它是注重适应性、完善性和预防性的维护。 四、软件构件（一）构件的定义相对系统而言，构件是可以明确辨识的构成成分，软构件指在软件系统中具有一定意义的相对独立的软件构成成分。软件再工程需要的正是可以被其它软件系统复用的、具有相对独立功能的系统构成成分。 （二）构件模型一般情况下，构件由构件规约与构件实现两部分构成。构件规约主要由构件模型来进行描述，给出构件的本质特性。目前国内外已经形成许多构件模型，诸如C模型、CORBA模型和青鸟构件模型等等。它们几乎都详尽地描

41、述了构件的名称、功能、对外接口和相关参数化属性，向构件复用者提供了关于构件的大量信息。当然，有时候构件的内部结构对于构件的有效复用也是必不可少的。构件实现由构件的生产者完成，复用者可不去关心它的细节，对复用者而言，关键是构件模型中的构件规约。 对大量的构件进行有效的、科学的管理和建模，以期方便构件的存储、检索、推理，是成功复用构件的保证。在此，我们着重于构件描述、构件分类和构件库组织的讨论与研究，它们也是构件建模的核心内容。 五、构件模型的描述与构件复用方法研究从软件再工程的角度看，构件描述是对构件本质的抽象描述，为构件的制作和复用提供依据；从构件模型的角度看，诸如实现方式、实现体、关联构件、

42、大小和生产日期等等信息也是构件模型的具体内容。在此，我们介绍几种构件模型的描述的方法： （一）构件模型的特征向量法对于任意构件X的所有属性a1,a2,ai,an采用向量法描述：a1(x),a2(x),ai(x),an(x)；ai及ai(x)是属性-值的对偶。在构件的相似性研究中，可以把任意构件看作n维空间中的一个点。显然，匹配任务转化为求解在n维空间中与给定点距离最近的点的问题。 给定的构件X与构件库中的任意构件Y的相似度可以通过欧氏距离或麦考斯距离求得。针对事实上单个属性对整体上的相似度有不同贡献，可以用带权麦考斯距离求解目标构件和构件实例的相似度。很显然，最大相似度的构件实体的获得需要全体

43、构件实例和理想构件的比较，这依赖于大量运算，算法效率较低。 因此，我们提出一个改进的求解算法，在构件模型采用特征向量描述的条件下，考虑便于实现构件自学习和构件匹配算法，根据用户给出的理想构件，把其属性分解为前置属性和后续属性，从构件库中获取与理想构件模型完全或部分匹配的构件实例。如下图所示： 构构件件特特征征向向量量表表示示法法的的匹匹配配res1res2pre1pre2pre3pre4pre5resres1pre_x1pre_x2构件实例目标构件（2）构件模型的语义表示法这种模型以语义为核心，给出构件的结构模型。构件的结构模型约定了构件的组成，它是对构件实体的抽象。对构件而言，它能提供一些功

44、能，同时其功能的实现以一定的所需构件为基础。为此，我们必须给出构件的接口，用于描述通讯约束和构件间通讯实现。其次，我们要给出对构件的功能和属性的语义描述，语义描述的主要内容是构件的含义和使用方法，它最终决定构件的复用价值。构件接口的标准化实质上是构件语义形式化描述措施的一个重要方面。 除此以外，还有前置和后续条件定义操作、命名服务中命名和命名上下文标准、目录和目录上下文标准、事务服务描述符、部署描述符等，同时有命名规则、目录和命名绑定规则、事务语义定义、资源分布部署说明等。在不同标准中，它们都有自己的形式化语义规定。基于语义的构件结构模型如下图所示： 实 例 集构 件 属 性 抽 象构 件 功

45、 能 抽 象接 口 体 集 合语 义 体 集 合实 现 体 集 合基 于 语 义 的 构 件 结 构 模型成功的软件构件复用需要对构件功能在语义上有精确的定义，还需构件在特定使用环境中得到质量和可靠性认证。没有这些保证，复用将是不可预见的和冒险的。基于语义的构件模型表示如下：构件: /*实现对装配透明*/规约:接口规约:机构规约:构件的语义模型的建立促进了构件的描述和构件组装的实施，为构件的检索、评价、剪裁和扩展奠定了坚实的基础。 六、软件复用的前景构件技术已经成为当今计算机领域的重要组成，许多常用的开发工具提供了对不同构件模型的实现支持，特别在一些分布式软件系统中，已经把软件的构件化作为解决维护、扩展和升级的一种重要手段；同时，伴随着用户对既存软件系统的需求递增，在现在及将来的一段时间内，软件再工程进一步发展还需要强大构件库支撑。 构件数据库的建立对构件复用具有重大意义，它是用户或软件开发组织的一笔宝贵财富，构件可以来源于历史上开发的软件模块，关键是在开发过程中注意收集软件模块以及其完整的文档资料。另外，其实构件可以迈向商业化道路，作为商品在市场上流通，促进再工程的实施。但是，要使基于构件的软件再工程成为现代软件工程的主流，构件的建模还要在降低构件之间的相关性和提高构件内元素之间的相关性等等方面作进一步研究，当然这本身也是软件维护研究的课题。