36 维护与再工程¶

说明

本文档由 AI 生成

这一章（Chapter 36: Maintenance and Reengineering）是软件工程生命周期的“后半段”内容。如果说前面的章节是关于“如何从无到有构建软件”，那么这一章就是关于“软件交付后如何生存”以及“老旧系统如何重生”。

这一章的逻辑非常清晰，遵循了从**基础**到**环境**，再到**核心活动（再工程）**，最后落实到**经济决策**的递进关系：

首先**定义了软件维护 (Software Maintenance)，并强调了**可维护性 (Maintainability) 和 可支持性 (Supportability) 的重要性。
**其次**介绍了业务流程再工程 (BPR)，这是再工程的宏观背景。
**核心部分**详细介绍了软件再工程 (Software Reengineering) 的模型，特别是逆向工程 (Reverse Engineering) 和重构 (Restructuring) 的具体步骤。
**最后**用经济学模型 (Economics) 来论证“重写还是重构”的决策依据。

以下是为你整理的详细笔记（Markdown格式），专有名词后均已附上英文对照，非常适合用来复习备考。

🛠️ 软件工程 Chapter 36: 维护与再工程 (Maintenance and Reengineering)¶

1. 软件维护 (Software Maintenance)¶

定义：软件发布给最终用户 (End-users) 后的所有工作。
- Bug修复：发布后几天内收到错误报告。
- 适应性修改：发布后几周内，用户要求适应特殊环境。
- 完善性修改：发布后几个月内，其他部门要求新增功能。
可维护软件的特征 (Maintainable Software)：
- 具有有效的**模块化 (Modularity)**。
- 使用易于理解的设计模式 (Design patterns)。
- 遵循良好的编码标准 (Coding standards)，代码具有自文档化 (Self-documenting) 特性。
- 经历过多种质量保证 (Quality assurance) 活动。
- 开发者意识到自己可能不在现场，因此设计必须“辅助”未来的修改者。

2. 软件可支持性 (Software Supportability)¶

定义：在软件整个产品生命周期 (Product life) 内支持该软件系统的能力。
包含内容：设备、支持基础设施 (Infrastructure)、额外软件、设施、人力等资源。
关键点：
- 软件应包含辅助支持人员的设施（当缺陷出现时）。
- 支持人员应能访问**缺陷数据库 (Defect database)**，记录所有已遇到的缺陷特征、原因和解决方案。

3. 再工程 (Reengineering)¶

背景：涉及业务流程 (Business processes)、IT系统和软件应用。
核心思想：不是简单的修改，而是彻底的改造。

4. 业务流程再工程 (Business Process Reengineering, BPR)¶

定义：对企业的业务流程进行根本性的再思考和彻底的再设计。
六个步骤：
1. 业务定义 (Business definition)：确定目标（成本降低、时间减少、质量改进、人员发展）。
2. 流程识别 (Process identification)：识别关键流程。
3. 流程评估 (Process evaluation)：分析和测量现有流程。
4. 流程说明与设计 (Process specification and design)：为重设计的流程准备用例。
5. 原型化 (Prototyping)：在全面集成前必须进行原型测试。
6. 精化与实例化 (Refinement and instantiation)：基于反馈进行精化并实例化。
七大原则 (Principles)：
- 围绕**结果 (Outcomes)** 而不是任务组织。
- 让**使用者 (Users)** 执行流程。
- 将信息处理工作纳入产生原始信息的实际工作中。
- 将地理上分散的资源视为集中的。
- 链接并行活动，而不是集成结果。
- 将决策点放在执行工作的地方，并将控制内置到流程中。
- 在源头捕获数据一次。

5. 软件再工程 (Software Reengineering)¶

模型 (Model)：
- 正向工程 (Forward engineering)：基于旧系统开发新系统。
- 逆向工程 (Reverse engineering)：从代码中提取抽象 (Abstractions)。
- 重构 (Restructuring)：代码重构、数据重构、文档重构。
- 库存分析 (Inventory analysis)：建立所有应用程序的清单。

6. 库存分析 (Inventory Analysis)¶

目的：建立包含所有应用程序的表格，筛选再工程候选者。
评估标准 (Criteria)：
- 应用程序名称。
- 创建年份。
- 实质性更改次数。
- 总修改工作量。
- 上次实质性更改日期。 import effort for the last change.
- 所在系统及接口应用。
操作：分析并优先排序 (Prioritize)。

7. 重构 (Restructuring)¶

文档重构 (Document Restructuring)：
- 选项1：如果系统能用，且创建文档太耗时，则维持现状。
- 选项2：“被触及时再文档化 (Document when touched)”——资源有限时的折中方案。
- 选项3：完全重新文档化——仅针对业务关键系统，且应精简到最低限度。
代码重构 (Code Restructuring)：
- 使用重构工具 (Restructuring tool) 分析源代码。
- 重新设计 poorly designed code segments。
- 自动修正违反结构化编程 (Structured programming) 的地方。
- 评审和测试重构后的代码，更新内部文档。
数据重构 (Data Restructuring)：
- 特点：比代码重构更高级别的活动。
- 过程：从逆向工程开始，定义必要的数据模型 (Data models)。
- 改进：当现有数据结构薄弱（如扁平文件 Flat files）时，改为关系型 (Relational) 方法。
- 影响：数据架构的变更必然导致程序架构或代码的变更。

8. 逆向工程 (Reverse Engineering)¶

过程：
- 输入：脏代码 (Dirty source code)。
- 处理：提取抽象 (Extract abstractions)、简化 (Refine & simplify)。
- 输出：干净的源代码 (Clean source code) 和接口信息。

9. 正向工程 (Forward Engineering)¶

定义：基于现有系统进行新开发。
优势 (Advantages)：
1. 维护成本高：维护一行代码的成本可能是初始开发成本的20到40倍。
2. 架构改进：使用现代设计概念重新设计软件架构，便于未来维护。
3. 生产力高：因为已有原型 (Prototype)，开发生产力更高。
4. 需求明确：用户已有经验，新需求和变更方向更容易确定。
5. 工具支持：CASE工具可以自动化部分工作。
6. 配置完整：完成后拥有完整的软件配置 (Software configuration)。

10. 再工程的经济学 (Economics of Reengineering)¶

模型参数 (Parameters)：
- $P_1$：当前年度维护成本。
- $P_2$：当前年度运行成本。
- $P_3$：当前年度业务价值。
- $P_4, P_5, P_6$：再工程后的对应成本和价值。
- $P_7$：再工程成本。
- $P_8$：再工程日历时间。
- $P_9$：再工程风险因子 (Risk factor)。
- $L$：系统预期寿命 (Expected life)。
成本计算公式：
- 继续维护成本 ($C_{maint}$)： $$C_{maint} = [P_3 - (P_1 + P_2)] \times L$$
- 再工程成本 ($C_{reeng}$)： $$C_{reeng} = P_6 - (P_4 + P_5) \times (L - P_8) - (P_7 \times P_9)$$
- 成本效益 (Cost benefit)： $$Cost\ benefit = C_{reeng} - C_{maint}$$

💡 复习重点总结 (Key Takeaways for Exam)¶

维护 vs 再工程 (Maintenance vs Reengineering)：维护是修修补补，再工程是推倒重来或深度改造。
BPR 原则 (BPR Principles)：重点复习那7条原则，特别是“围绕结果组织”、“使用者执行”、“在源头捕获数据”。
重构的分类 (Restructuring Types)：区分代码重构（低级、工具自动）、数据重构（高级、影响架构）和文档重构（策略选择）。
经济学计算 (Economics Calculation)：考试可能会给出一组数据，让你代入公式计算 $C_{maint}$ 和 $C_{reeng}$，从而判断是否值得再工程。注意公式中 $P_9$ (风险因子) 对成本的放大作用。

评论区

欢迎在评论区指出文档错误，为文档提供宝贵意见，或写下你的疑问