第8章维护要点解析.ppt

(3) 源代码标准 ① 尽可能使用最高级的程序设计语言，且只使用语言的标准版本； ② 所有的代码都必须具有良好的结构； ③ 所有的代码都必须文档化，在注释中说明它的输入、输出、以及便于测试／再测试的一些特点与风格。 (4) 文档标准 文档中应说明： 程序的输入／输出、 使用的方法／算法、 错误恢复方法、 所有参数的范围、 缺省条件等。 8.5 提高可维护性的方法 3.3 周期性地维护审查 对已有的软件系统进行的。 软件在运行期间进行修改，会导致软件质量有变坏的危险，破坏程序概念的完整性。 维护审查的结果可以同以前的维护审查的结果，以前的验收检查的结果、检查点检查的结果相比较，任何一种改变都表明在软件质量上或其它类型的问题上可能起了变化。 对于改变的原因应当进行分析。 8.5 提高可维护性的方法 3.4 对软件包进行检查 软件包是一种标准化的，可为不同单位、不同用户使用的软件。一般源代码和程序文档不会提供给用户。 对软件包的维护采取以下方法。 使用单位的维护人员首先要仔细分析、研究卖主提供的用户手册、操作手册、培训教程等，以及卖方提供的验收测试报告等。 在此基础上，深入了解本单位的希望和要求，编制软件包的检验程序。 8.5 提高可维护性的方法 4、选择可维护的程序设计语言 程序设计语言的选择，对程序的可维护性影响很大。 机器语言 汇编语言 高级语言 (JAVA C#等) 查询语言 图形语言 8.5 提高可维护性的方法 5、改进程序的文档 程序文档是对程序总目标、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。 文档是影响软件可维护性的决定因素。 由于长期使用的大型系统在使用过程中必然会受多次修改，所以文档比程序代码更重要 8.5 提高可维护性的方法 对于程序维护人员来说，要想按程序编制人员的意图重新改造程序，并对今后变化的可能性进行估计，缺了文档是不行的。 利用历史文档，可以大大简化维护工作。通过了解原设计思想，可以判断出错之处，指导维护人员选择适当的方法修改代码而不危及系统的完整性。 历史文档有： 系统开发日志、 错误记载、系统维护日志。 从用户角度分为用户文档和系统文档两类 8.5 提高可维护性的方法 总的来说，软件文档应该满足下述要求： 必须描述如何使用这个系统 必须描述怎样安装和管理这个系统 必须描述系统需求和设计 必须描述系统的实现和测试，以便使系统成为可维护的 8.5 提高可维护性的方法 为了提高未来的可维护性或可靠性，而主动地修改软件。预防性维护定义为：把今天的方法学应用到昨天的软件系统上，以支持明天的需求。 初看起来，在一个正在工作的程序版本已经存在的情况下，重新开发这个大型程序似乎是一种浪费？ 8.6 预防性维护 维护成本高昂的事实； 使用现代设计概念重新设计软件体系结构，对未来的维护工作将有帮助； 由于软件原型已经存在，软件开发生产率将远远高于平均水平； 现在用户已经有比较丰富的使用该软件的经验，因此，很容易确定新的需求和变更方向； 利用软件再工程工具可以自动完成部分工作； 在完成预防性维护的过程中，可以建立起完整的软件配置。 8.6 预防性维护 预防性维护也为软件再工程。 典型的软件再工程过程模型定义了6类活动。 每个活动都可能重复进行而且对于某个特定的循环来说，过程可以在完成任意一个活动之后终止 8.7 软件再工程过程 1. 库存目录分析 所有每个应用系统都进行预防性维护是不现实的，也是不必要的。下述3类程序有可能成为预防性的对象： 该程序将在今后数年内继续维护的对象 当前正在成功地使用着该程序 可能在最近的将来要对该程序做较大程度的修改或扩充 应该仔细的、分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用排序，从中选出再工程的侯选者。然后合理地分配再工程所需要的资源。 8.7 软件再工程过程 2. 文档重构 老程序固有的特点缺乏文档，根据具体情况可采用下述3种方法之一来处理这个问题： 1)如果一个程序是相对稳定的，正在走向生命的终点，而且可能不会再修改它，则不必为它建立文档。 2)为了便于今后的维护，必须更新文档，但是由于资源有限，应该采用“使用时建立文档”的方法，也就是说，不是一下子把某应用系统的文档全部都重建起来，而是只建立系统中当前正在修改的那些部分的完整文档。 3)如果某应用系统是用户完成业务工作的关键，而且必须重构全部文档，则仍然应该尽量把文档工作减少到必需的最小量。 8.7 软件再工程过程 3. 逆向工程 软件的逆向工程是，分析程序以便在比源程序更高的抽象层次上创建出程序的某种描述的过程，也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比