软件可维护性综述

1. 软件维护的目标、任务、分类与特点
目标：软件维护是软件生存周期的最后一个阶段，是在软件交付使用后，为了改正错误或满足新的需要而修改软件的过程。软件维护工作的目标是：不断地、持续地改进、扩充、完善软件系统，以提高系统运行效率，并尽量延长系统的使用寿命，为用户创造更大的价值。
任务：延长软件生存期
分类：维护的分类
（1）改正性维护：在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。
（2）适应性维护：在使用过程中，外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。
（3）完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为满求了足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
（4）预防性维护：采用先进的软件采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。
2. 影响软件可维护性的因素
1.可理解性
软件可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。模块化、详细的设计文档、结构化设计、源代码内部的文档和良好的高级程序设计语言等等，都对改进软件的可理解性有重要贡献。
2.可测试性
诊断和测试的难易程度主要取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的。此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。
3.可修改性
软件容易修改的程度和软件设计原理和规则直接有关。耦合、内聚、局部化、控制域与作用域的关系等等，都影响软件的可修改性。
一个软件可维护性较低，也就是说会随着性能要求的变化而“腐烂”的原因有四个：过于僵硬、过于脆弱、复用率低、耦合过高。
1、过于僵硬
指很难在一个软件系统里加入新的功能。因为加入一个新功能不仅意味着建造一个独立的新模块，这个新模块还会影响到其它模块。
这种设计上的不足，导致很难为一个软件加入新的功能，一个软件一旦写好，就不能加入新的功能，成为一个“僵死”的系统。
2、过于脆弱
指在对代码进行修改时，一个地方的修改往往会导致看上去没有什么有关系的另一个地方发生故障。
3、复用率低
指当程序员打算把原有的代码或模块用到新的模块中时，发现这不是一个容易的事，这些已有的代码依赖一大堆其它的东西，以至于很难将它们分开。
4、黏度过高
结合课内试验项目进行提高软件可维护性的分析：
可拓展性、灵活性、可插入性
复用包括：代码的复制和粘贴；算法的使用；数据结构的复用；模型复用
复用，提高可维护性，更改或添加方面，提高效率，尽量将自己所需要编写的例如数据库的操作，或者是文件的解析变成一个工具，之后直管就行了。提高代码的可复用性。
通过类继承实现代码重用不是精确的代码重用技术，因此它并不是最理想的代码重用机制。换句话说，如果不继承整个类的所有方法和数据成员，我们无法重用该类里面的单个方法。继承总是带来一些多余的方法和数据成员，它们总是使得重用类里面某个方法的代码复杂化。另外，派生类对父类的依赖关系也使得代码进一步复杂化：对父类的改动可能影响子类；修改父类或者子类中的任意一个类时，我们很难记得哪一个方法被子类覆盖、哪一个方法没有被子类覆盖；最后，子类中的覆盖方法是否要调用父类中的对应方法有时并不显而易见。任何方法，只要它执行的是某个单一概念的任务，就其本身而言，它就应该是首选的可重用代码。为了重用这种代码，我们必须回归到面向过程的编程模式，把类的实例方法移出成为全局性的过程。为了提高这种过程的可重用性，过程代码应该象静态工具方法一样编写：它只能使用自己的输入参数，只能调用其他全局性的过程，不能使用任何非局部的变量。抽象层是相对稳定的部分，也是复用的焦点，抽象模块相对于具体的模块独立，依赖抽象非具体，提高抽象层的复用
原则：
开闭原则：对扩展开放，对修改关闭；
抽象构建框架。用实现扩展细节。由于抽象灵活性好。适应性广，仅仅要抽象的合理。能够基本保持软件架构的稳定。而软件中易变的细节。我们用从抽象派生的实现类来进行扩展，当软件须要发生变化时，我们仅仅须要依据需求又一次派生一个实现类来扩展就能够了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。用抽象构建框架。用实现扩展细节的注意事项而已：单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系。依赖倒置原则告诉我们要面向接口编程。接口隔离原则告诉我们在设计接口的时候要精简单一。迪米特法则告诉我们要减少耦合。
里氏代换：任何基类可以出现的地方，子类一定可以出现；
依赖倒转原则：依赖抽象、不依赖具体；尽量使用合成聚合达到复用非继承；
　1.抽象不应该依赖于细节，细节应该依赖于抽象。
2.高层模块不依赖底层模块，两者都依赖抽象。　
依赖也叫耦合；零耦合、具体耦合、抽象耦合。针对接口编程
组合、聚合复用原则：尽量使用合成、聚合；不使用继承客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口最小化,过于臃肿的接口依据功能,可以将其拆分为多个接口.
一：单一职责:不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
二：里氏替换原则:所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类可以扩展父类的功能，但不能改变父类原有的功能
三.依赖倒置:高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。简单的说就是尽量面向接口编程.
四.接口隔离:客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口最小化,过于臃肿的接口依据功能,可以将其拆分为多个接口.
五.迪米特法则:一个对象应该对其他对象保持最少的了解,简单的理解就是高内聚,低耦合，一个类尽量减少对其他对象的依赖，并且这个类的方法和属性能用私有的就尽量私有化.
六.开闭原则:一个软件实体如类、模块和函数应该对扩展开放，对修改关闭.当软件需求变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化.