27、软件架构设计理由的捕获与应用

软件架构设计理由的捕获与应用

1. 软件维护难题与设计理由的重要性

在软件维护过程中，确定潜在更改对现有系统的影响是一项极具挑战性的任务。尤其是当原开发人员不可用，或者维护工作交由非初始设计和构建软件的组织时，问题会变得更加复杂。

设计理由（Design Rationale，DR）记录了设计和实现决策背后的意图，以及所考虑的设计替代方案的历史。它还包含开发初始系统时所做的假设以及这些假设如何影响设计。然而，大多数开发人员由于记录设计理由耗时且会干扰设计过程，同时担心记录错误决策带来的潜在责任，往往不愿意捕获这些信息。

2. 设计理由的潜在用途

设计理由在软件开发周期的各个阶段都有潜在用途。在维护阶段，它尤为重要，因为即使原开发人员可用，他们也可能忘记多年开发过程中每个决策的细节。以下是设计理由在不同类型软件维护中的具体用途：
- 纠正性维护 ：用于检测某些类型故障的根源。例如，当某个假设不再有效导致系统故障时，设计理由可以帮助确定设计和代码中依赖该假设的部分，指出可能需要更改的地方。它还可以提供可能的替代方案，避免尝试之前已被拒绝的解决方案，同时跟踪替代方案之间的依赖关系，防止选择不兼容的替代方案。
- 适应性维护 ：为改进提供指导。开发人员可能因短期原因做出某些决策，但这些决策在未来可能需要修订。设计理由可以帮助找出为了方便而做出的决策，并展示更好的替代方案，以便开发人员在更新代码时进行考虑。
- 增强性维护 ：确保扩展功能时所做决策的理由与初始系统的设计理由一致。例如，确保新功能的设计不会违反系统的性能要求。设