软件的维护与升级

软件维护

软件维护：在软件发布后，修改软件以修正错误和提升性能
维护包含两点：

• 确定错误位置
• 测试、修正和文档

代码可维护性的指标

• CC（Cyclomatic Complexity，圈复杂度）：代码里面的环数，如图
  
• HV(Halstead Volume,运算符和操作数的数目）
• LOC(The average number of lines of code per module ,每个模块的代码行数）
• COM(The percentage of comment lines per module ，注释行的百分比)

这里提示，深度地继承会使得代码难以理解，同时注意高内聚低耦合，注意测试。

模块设计

模块设计是要将程序的功能分散到独立可交互的模块中

评价模块性的五个标准
▪可分解性

• 较大的组件是否分解为较小的组件？

▪可组合性

• 较大的部件是否由较小的部件组成？

▪可理解性

• 组件是否可以单独理解？

▪连续性（可持续性）

• 规格的微小变化是否会影响本地化和有限数量的组件？对规格说明的改动，其影响是否是局部和有限的

▪保护性

• 运行时异常的影响是否仅限于少数相关组件

模块设计的五个规则
▪ Direct Mapping (直接映射)：模块的结构与现实世界中问题领域的结构保持一致
影响持续性和可分解性

▪ Few Interfaces (尽可能少的接口)：模块应尽可能少的与其他模块通讯
影响：可持续性、保护性、可理解性、可组合性

▪ Small Interfaces (尽可能小的接口)：如果两个模块通讯，那么它们应交换尽可能少的信息
对“可持续性”和“保护性”产生影响

▪ Explicit Interfaces (显式接口)：当A与B通讯时，应明显的发生在A与B的接口之间)
可分解性、可组合性、可持续性、 可理解性

▪ Information Hiding (信息隐藏)：经常可能发生变化的设计决策应尽可能隐藏在抽象接口后面
可持续性

SOLID

单一责任原则
开放封闭原则
Liskov替换原则
接口隔离原则
依赖转置原则

GRASP（通用责任分配软件模式）

控制者

信息专家

创造者

低耦合

高内聚

间接的

多态性

受保护的变体

纯粹的制造