第13章软件演化Word下载.docx
《第13章软件演化Word下载.docx》由会员分享，可在线阅读，更多相关《第13章软件演化Word下载.docx（10页珍藏版）》请在冰点文库上搜索。
2）改善性维护则是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
这样做的基础是，因为开发者要使软件有用，用户接触到的新情况会超出软件最初的开发范围。
需求的扩展，可以以现有系统功能增强的形式出现，也可以以提高计算效率的形式出现。
3）适应性维护则是为适应环境的变化而修改软件的活动。
这里的环境是指外部施加给系统的所有条件和影响的总和，例如业务规则，政府政策，工作模式，软件和硬件操作平台。
4）预防性维护是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。
预防性更改的例子包括代码结构调整，代码优化和文档更新。
图给出了不同类型软件更改之间的潜在关系。
图各种软件维护之间的关系由此可见软件维护决不仅仅是改错。
改错只是软件维护中一个很小的部分。
不过在实践中，软件维护各种活动常常交织在一起的。
尽管这些维护在性质上有些重叠，但是还是有充分的理由区分这些更改。
只有正确区分这些更改能够更有效地确定更改需求的优先级。
介绍了软件维护的基本概念以后，下一节将主要介绍软件维护的活动。
13.1.2软件维护的过程软件维护过程是指在软件维护期间所采取的影响更改的一系列活动，跟软件的生产过程相同，软件维护过程也需要首先确立软件维护过程的模型,然后实施具体的软件维护活动。
1）软件维护模型过去,系统开发的问题是压倒性的，软件维护则在很大程度上被忽略。
软件维护模型,与软件维护一样,与软件开发模型相比,维护模型既没有被充分开发,也没有被充分理解。
前面一节讲到了软件开发与软件维护不同,实际上软件维护模型与软件开发模型也存在区别。
软件维护比软件开发模型在早期阶段需要的工作量更大,关注点也非常不同,而后续阶段需要的工作量较少。
现阶段比较有代表性模型有1）快速修改模型，2）Boenm模型,3）Oshorne模型,4）迭代增强模型和5）面向重用模型。
其中快速修改模型基本上是一种软件维护的临时定制方法，它等待问题出现，然后尽可能迅速地解决；
Boenm模型则根据经济学原理和模型,把维护过程表示为闭合环路。
Osborne模型直接面对维护环境的现实，允许实际情况是什么样的就是什么样的；
迭代加强模型刚开始是作为一个软件开发的模型提出来的，后来发现这种模型非常适合维护,模型假设有完整的文档，并且整个团队有能力全面地分析现有产品；
面向重用模型把维护看作是包含重用现有程序组件的一种活动。
2）软件维护活动软件维护的活动通常情况下包括建立维护团队，强制报告和评估的过程；
为每个维护申请确定标准化的事件序列；
制定保存维护纪录的制度和有关复审及评估的标准。
如何维护团队本身的结构是决定生产率水平的一个重要因素。
维护团队根据时间的不同,可以分为短期团队和长期团队。
短期团队一般是当需要执行相关具体任务时，适应性更改适应性更改适应性更改适应性更改其中－表示导致临时一起工作来解决手头的问题。
长期团队则更正式，能够专业化创建沟通渠道，可以管理软件系统整个生存期的成功进化。
特别地，无论是短期团队还是长期团队，都要把有经验的员工和新员工混合起来。
维护的报告与评估应该采用标准化的格式，软件开发人员统一发放维护申请单，由用户根据需要填写。
维护活动的事件流首先需要确定用户请求维护的类型，不同类型的维护要求采用不同策略。
例如对纠错性维护和适应性维护处理的策略不同，前者要求考虑所有的软件中存在的错误，而后者则并不用考虑所有的适应性维护的请求。
不过，如果两者都要进行软件维护，则必须修改软件设计，进行设计复审，必要时重新编码，实施单元测试，确认测试和复查。
维护记录的保存和维护的评审是两个相关的过程，只有保存了软件维护的记录，才能对维护的过程进行评审。
维护过程的评审，可以为以后项目的开发技术，编程语言，以及对维护工作量的预测与资源分配等诸多方面的决策提供一个参考通过对软件维护过程模型的选择以及软件维护活动的管理，已经基本上完成了软件维护的整个过程。
当然如何将软件维护过程的模型应用到实际的软件维护过程中，理论知识并不能自动地导致实践中有效地运用。
比较有名的软件能力成熟度模型和软件经验库。
下一节主要介绍一下如何进行维护测量以及如何提高软件的可维护性。
3）软件维护的工具对于维护问题来说也许没有撒手锏，但是使用能够支持软件维护人员的工具，可以显著简化维护任务，提高效率和生产率，支持整个软件系统的进化。
在选择工具的时候，需要考虑工具的能力，工具的功能，工具的成本和收益，工具的平台，工具的程序设计语言，工具的易用性，工具的体系结构的开放性，已有工具的使用情况等。
根据不同的任务将维护工具分成四大类:
程序理解和逆向工程：
由于在维护之前，需要大量的时间来理解和研究程序。
因此有必要使用促进理解的工具。
这些工具包括程序切分器，静态分析器，动态分析器转换工具和交叉引用器。
软件维护的一个主要问题是对付程序源代码的规模。
程序员要能够将程序进行切分，把握更改的程序部件,这时程序切分器就能切分源程序，并且还能显示数据链和相关特征。
测试：
测试是软件开发和软件维护中一种最昂贵，要求最严格的任务。
这些工具主要包括测试模型器，测试用例生成器，测试路径生成器。
配置管理支持工具：
配置管理支持工具主要包括源代码控制系统以及其它实用程序。
大多数维护环境中，如果没有某种自动化的支持工具进行有效的配置管理是不可能的。
跟踪在修改软件系统期间产生的对象并不是件平凡的任务。
其它实用程序包括用于查找文件和搜索文件的工具，例如Linux下的Find和grep命令,还有ls和dir命令。
其他任务:
文档在软件开发中扮演了非常重要的角色，它在软件维护中仍然是非常重要的。
缺乏文档，将使得以后的维护变得非常的困难。
复杂度评估是在对软件实施更改前做出的，复杂度量化器是一种用于测量程序复杂度的工具，这种复杂度测量的基础通常是程序的内部算法或程序结构等因素来决定的。
因此，文档和复杂度评估成也成为软件维护的主要工具。
有各种各样的工具可以供软件维护人员使用。
主要因为其他文献已经大量讨论过。
13.1.3软件可维护性软件的可维护性是指，软件被理解，改正，调整和改进的难易程度。
可维护性是指导软件工程各个阶段工作的一条基本原则，也是软件工程的目标之一。
下面主要讲述软件可维护性的测量以及提高软件可维护性。
（1）软件的可维护性与软件质量和可靠性一样是难于量化的概念，一般认为软件可维护性是软件能够被理解，改正，适配或增强的容易程度。
软件可维护性可以认为是一种软件的外部属性。
可以通过平均修复时间（MTTR）来衡量。
平均修复时间可能与下面各个因素相关:
（a）有关问题的识别时间（b）管理延迟时间（c）维护工具收集时间（d）问题分析时间（e）更改描述时间（f）更改时间的信息（g）所有测试所用的时间（h）维护复审所用的时间软件可维护性也可以认为是一种内部属性。
程序中源代码的多个内部属性会影响到软件的可维护性。
例如代码的规模以及代码的复杂度。
不过，目前还没有确定软件可维护性的模型。
一般人们使用诸如复杂度和可读性这样的指标来预测软件的可维护性。
（2）如何提高软件的可维护性?
目前认为软件维护中出现的大部分问题都可以归咎于软件规划和开发方法的缺陷。
下面从开发方法和开发环境两个方面出发讲述如何提高软件的可维护性。
开发方法开发方法是指在开发软件本身的过程中涉及的一些技术和方法。
（a）是否采用了结构化的软件开发方法（b）是否采用高级程序设计语言（c）是否拥有良好的文档记录（d）是否具有良好的软件配置开发环境开发环境是指除了开发过程本身之外的所有因素的综合。
（a）是否拥有一组训练有素的软件开发人员（b）是否使用标准的程序设计语言（c）文档结构是否标准化（d）调试用例是否合适通过不断地对软件开发方法改进和开发环境的改善，软件的可维护性将得到不断的提高。
但是人们只能不断提高软件的可维护性，而不能完全解决软件的可维护性问题。
13.2再工程技术人们常常有这样的体会，一些经常使用的软件经常出现故障,需要经常对其修复。
随着使用时间的增长，修复软件故障所化费的时间远远超出了忍耐，因此，需要对整个软件进行重建，使它具有更多的功能，更好的性能。
这就是常说的再工程技术。
再工程的主要目的是为遗留系统转化为可演化系统提供一条现实可行的途径。
再工程是一个工程过程，它将逆向工程、重构和正向工程组合起来，将现存系统重新构造为新的形式[37]。
再工程的过程包括决策分析、系统理解和系统演化三个子过程。
当实施软件的再工程时，软件理解是再工程的基础和前提。
而对于软件过程来说，需要对软件过程进行再工程时，也必须全面到位的理解该软件过程，这也是开展软件过程再工程的首要条件图正向工程、逆向工程、再工程等概念的关系[5]13.2.1业务过程再工程（BPR）对业务过程进行再工程开始于MichaelHammer[HAM90]的HarvardBusinessReview的文章，Hammer在文章中大力呼吁使用业务过程再工程技术。
不过，在21世纪初，对于业务过程再工程的宣传已经不太常见，但是这种过程已经在很多公司中得到使用。
一个业务过程是一组逻辑相关的任务，它们被执行以达到符合预定义的业务结果[DAV90]。
业务过程存在于生活的各个方面中，例如，购买服务，雇佣新的职员等。
业务过程再工程的关键标准有知识管理，时间，清理，环境控制，质量，调节性库存储备，标识核心竞争力，融合，全球化，互操作，汇聚，乐趣，价值流分析。
对一个业务过程进行再工程需要服从一定的原则。
Hammer在1990年提出一组原则，用于指导BPR活动:
围绕结果而不是任务进行组织。
让那些使用过程结果的人来执行流程将信息处理工作合并到生产原始信息的现实工作中将地理分散的资源视为好像它们是集中的连接并行的活动以代替集成它们的结果在工作完成的地方设置决策点，并将控制加入过程中在其源头一次性获取数据上面每一条原则代表一个视图。
和大多数工程活动一样，业务过程再工程是迭代的。
因此业务过程再工程没有开始和结束,只有不断的演化。
整个业务过程再工程模型可用下面图表示:
表13-1BPR模型软件规模的扩大导致软件的管理，质量等出现的一些严重的问题，人们开始寻找软件业中的银弹。
BPR的出现，使人们误以为BPR就是传说中的银弹。
然而经过几年的夸大宣传后，BRP陷于严重的批评中，被人们认为一文不值。
因此有必要树立一种对BRP认识的正确观点。
BRP不是银弹，当然BRP确实可以提高软件的质量。
13.2.2逆向工程逆向工程来源于硬件世界。
硬件厂商总想弄到竞争对手产品的设计和制造奥秘。
但是又得不到现成的档案，只好拆卸对手的产品并进行分析，企图从中获取有价值的东西。
我的很多同学从事集成电路设计工作，他们经常解剖国外的集成电路，甚至不作分析就原封不动地复制该电路的版图，然后投入生产，并美其名曰反向设计（ReverseDesign）[7]。
软件的逆向工程在道理上与硬件的相似。
但在很多时候，软件的逆向工程并不是针对竞争对手的，而是针对自己公司多年前的产品。
期望从老产品中提取系统设计、需求说明等有价值的信息。
逆向工程是把软件源程序还原为软件文档或软件设计的过程。
通过逆向工程，可以从更业务定义过程标识过程评估过程规约和设计原型实现求精和实例化高的抽象度来观察软件。
抽象度的多少可能由抽象的层次，文档的完整性，工具和分析员工一起工作的程序等因素决定。
理想的说，抽象度越高越好。
最好逆向工程应该能够导出过程的设计表示（一种低层的抽象）,程序和数据结构信息（稍高一点层次的抽象）,数据和控制流模型（一种相对高层的抽象）以及实体-关系（一种高层抽象）。
逆向工程使得无结构的源代码被重构使得它仅包含结构化设计元素，这使得源代码容易阅读并为后续的逆向工程活动提供基础。
逆向工程根据其源程序的类别的不同，可以分为以下几类:
对用户界面的逆向工程，现代的软件一般都拥有华丽的界面，当准备对旧的软件进行用户界面的逆向工程时,必须先完全解旧软件的用户界面,并且刻画出界面的结构和行为。
现在由于用户界面的普及，这种类型的逆向过程已经成为最常见的再工程活动。
对数据的逆向工程,由于程序中存在许多不同种类的数据，例如内部的数据结构，以及低层的数据库和外部的文件。
其中对内部的数据结构的逆向工程主要是对类的定义，可以通过检查程序代码以及变量而完成;
而对数据库结构的重构可通过建立一个初始的对象模型，确定侯选键，精化实验性的类，定义一般化，以及发现关联来完成。
对理解的逆向工程，为了去理解过程的抽象，代码的分析必须在不同的层次进行：
系统，程序，构件，模式和语句。
对于大型系统，逆向工程通常用半自动化的方法来完成。
在UML用户指南书中提到逆向工程（reverseengineering）[6]是通过特定语言的映射而把代码转换为模型的过程。
逆向工程会导致大量的多余信息，其中的一些信息属于细节层次，对于建造有用的模型来说过于详细。
同时，逆向工程是不完整。
但是也存在一些在逆向工程中策略。
比如说在类图的逆向工程中，可以遵循如下的策略:
识别从实现语言或所选的语言进行映射的规则使用工具，指向要进行逆向工程的代码。
用工具生成新的模型或修改以前的模型。
使用工具，通过查询模型创建类图。
例如对下面13.2.3.1的代码将生成13.2.3.2的UML图publicabstractclassEventHandler{EventHandlersuccessor;
privateIntegercurrentEventID;
privateStringsource;
EventHandler（）{}publicvoidhandleRequest（）{}}图13.2.3.1类EventHandler的代码图13.2.3.2使用正向工程后生成的EventHandler类图13.2.3重构所谓重构是这样一个过程：
在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构」。
重构是一种有纪律的、经过训练的、有条不紊的程序整理方法，可以将整理过程中不小心引入错误的机率降到最低。
本质上说，重构就是在代码写好之后改进它的设计[4]。
通常，重构并不修改整体的程序体系结构，它趋向于关注个体模块的设计细节以及定义在模块中的局部数据结构。
如果重构努力扩展到模块边界之外并涉及软件体系结构，则重构就变成正向工程。
一般情况下,需要进行重构的原因可能有如下几个:
其中第一个原因是：
需要继承为某个古老产品而开发的年代久远的代码，或者突然碰到这些代码。
最初的开发团队已经不在了。
我们必须创建增加了新特性的新版本软件，但是这些代码已经无法理解了。
新的开发队伍夜以继日地工作，破译代码然后映射代码，经过大量的规划与设计之后，人们将这些代码分割成碎片。
历经重重磨难之后，所有这些东西都按照新版本的要求归位了。
这是英雄般的重构故事，几乎没有人能在经历了这些之后活着讲述这样的故事；
第二个原因还有一种现实一些的情况是项目中加入了新的需求，需要对设计进行修改。
至于是因为在最初的规划过程中失察，还是由于采用了迭代式的开发过程（比如敏捷开发，或者是测试驱动的开发）而在开发过程中有意引入需求，这两者并没有实质性的区别。
这样的重构的规模要小得多，其内容一般涉及通过引入接口或者抽象类来更改类的继承关系，以及对类进行分割和重新组织，等等；
重构的最后一个原因是，当存在可用的自动重构工具时，可以有一个用来预先生成代码的快捷方式就好比在您无法确定如何拼写某个单词的时候，可以用某种拼写检查工具输入这个单词。
比如说，您可以用这种平淡无奇的重构方法生成getter和setter方法，一旦熟悉了这样的工具，它就可以为您节省很多的时间。
现有的许多IDE软件都提供了重构,例如eclispe提供的java重构。
其提供的菜单功能如下:
图13-3Eclipse提供的重构功能部分菜单现在一般都支持IDE都支持对以下重构：
1.对代码进行重命名以及改变代码的物理结构，包括对属性、变量、类以及接口重新命名，还有移动包和类等。
2.改变类一级的代码逻辑结构，包括将匿名类转变为嵌套类，将嵌套类转变为顶级类、根据具体的类创建接口，以及从一个类中将方法或者属性移到子类或者父类中。
MoveAlt+Shift+V__________________________PullUpExtractInterfaceUseSupertypewherepossible3.改变一个类内部的代码，包括将局部变量变成类的属性、将某个方法中选中部分的代码变成一个独立的方法、以及为属性生成getter和setter方法。
对于第一个功能,在程序你多次使用了一个变量count,现在你需要改变这个变量的名字，但是并不想没有变量一个一个地去改，并且由于其它变量可能也会包含count这个词汇，在这种情况下，使用重构就能显著地解决这个问题。
只需要让变量进行重构改名，就可以对这个变量进行重构。
对于第二个功能，下面例子将匿名类转变为嵌套类：
publicclassRefactorExample{voidprocessMessage（Stringmsg）{Refactorfactor=newRefactor（）{Objecto;
publicObjectget（）{returno;
}publicvoidset（Objecto）{this.o=o;
}};
Refactor.set（msg）;
MessagePipepipe=newMessagePipe（）;
pipe.send（factor）;
}}图重构前的代码publicclassRefactorExample{privatefinalclassRefactorImplimplementsBag{Objecto;
}publicvoidset（Objecto）{this.o=o;
}}voidprocessMessage（Stringmsg）{Refactorfactor=newRefactorImpl（）;
bag.set（msg）;
MessagePipepipe=newMessagePipe（）;
pipe.send（factor）;
}}图重构后的代码13.2.4正向工程随着软件迅速发展，软件本身也变得越来越大。
软件的维护以及软件的再更新成为一个非常严重的问题。
维护一行代码的成本可能是该行代码初始开发成本的30倍，而对于软件的重新开发则要求采用现代的设计概念来进行设计，但是原始的代码肯定不符合要求，而且原始的软件原型已经存在，如果能有效地利用这个原型将使得开发生产率远高于平均水平，再者，用户对已经软件的使用有经验，因此，新的需求和变化的方向可以很容易地确定。
正向工程是通过到实现语言的映射而把模型转换为代码的过程：
由于用UML描述的模型在语义上比当前的任何面向对象的编程语言都要丰富，所以正向工程将导致一定信息的损失。
事实上，这是为什么除了代码之外还需要模型的主要原因。
目前很多软件提供了正向工程的功能，它们允许用户设计ＵＭＬ时，自动生成相对应的代码。
用户对UML的更改，将会直接反应对代码。
利用这种正向工程的功能，用户能够非常快速地构建整个软件的架构，并且对应需求有非常大的弹性。
Eclipse提供了正向工程的支持，用户只要安装togetherplug-in以后，就可以在图中图出UML图，下图就是一个著名设计模式Singleton的UML图。
图13.2.4.1正向工程UMLpublicclasstest{/***Holdssingletoninstance*/privatestatictestinstance;
publicstaticvoidmain（String[]args）{}/***preventsinstantiation*/privatetest（）{//preventcreation}/***Returnsthesingletoninstance.@returnthesingletoninstance*/staticpublictestgetInstance（）{if（instance==null）{instance=newtest（）;
}returninstance;
}}图13.2.4.2UML对应的代码通过正向工程，程序员可以非常方便地使用UML等工具来构建整个工程的框架，而且非常易于再工程。
现在比较流行的MDA就是应用了正向工程这
升级会员 