系统架构设计师教程 第10章 10.4 软件架构演化原则 笔记

10.4 软件架构演化原则 ★★★☆☆

18种软件架构可持续演化原则，并针对每个原则设计了相应的度量方案。
1.演化成本控制原则(Evolution Cost Control,ECC)
● 解释：演化成本要控制在预期的范围之内，即演化成本要明显小于重新开发成本。
● 用途：用于判断架构演化的成本是否在可控范围内，以及用户是否可接受。
● 度量方案：CoE<<CoRD
● 方案说明：CoE为演化成本， CoRD为重新开发成本， CoE远小于CoRD最佳。

2.进度可控原则 (Schedule Control)
● 解释：架构演化要在预期时间内完成，即时间成本可控。
● 用途：规划每个演化过程的任务量；体现一种迭代、递增(持续演化)的演化思想。
● 度量方案：ttask=|Ttask-T’task|
● 方案说明：某个演化任务的实际完成时间 (Ttask) 和预期完成时间 (T’task) 的时间差，时间差ttask越小越好。

3.风险可控原则 (Risk Control)
● 解释：架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。
● 用途：用于判断架构演化过程中各种风险是否易于控制。
● 度量方案：分别检验。
● 方案说明：时间风险、经济风险、人力风险、技术风险都不存在。

4.主体维持原则
● 解释：对称稳定增长 (the Average Incremental Growth,AIG) 原则所有其他因素必须与软件演化协调，开发人员、销售人员、用户必须熟悉软件演化的内容，从而达到令人满意的演化。因此，软件演化的平均增量的增长须保持平稳，保证软件系统主体行为 稳定。
● 用途：用于判断架构演化是否导致系统主体行为不稳定。
● 度量方案：计算AIG 即可，AIG=主体规模的变更量/主体的规模。
● 方案说明：根据度量动态变更信息(类型、总量、范围)来计算。

5.系统总体结构优化原则(Optimization of Whole Structure)
● 解释：架构演化要遵循系统总体结构优化原则，使演化后的软件系统整体结构 (布局)更加合理。
● 用途：用于判断系统整体结构是否合理，是否最优。
● 度量方案：检查系统的整体可靠性和性能指标。
● 方案说明：判断整体结构优劣的主要指标是系统的可靠性和性能。

6.平滑演化原则(Invariant Work Rate,IWR)
● 解释：在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对固定。
● 用途：用于判断是否存在剧烈架构演化。
● 度量方案：计算IWR即可，IWR=变更总量/项目规模。
● 方案说明：根据度量动态变更信息(类型、总量、范围等)来计算。

7.目标一致原则 (Objective Conformance)
● 解释：架构演化的阶段目标和最终目标要一致。
● 用途：用于判断每个演化过程是否达到阶段目标，所有演化过程结束是否能达到最 终目标。
● 度量方案：otask=|Otask-O’task|
● 方案说明：阶段目标的实际达成情况 (Otask) 和预期目标 (O’task) 的差， Otask越小越好。

8.模块独立演化原则 或称为修改局部化原则 (Local Change)。
● 解释：软件中各模块(相同制品的模块，如Java的某个类或包)自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小。
● 用途：用于判断每个模块自身的演化是否相互独立。
● 度量方案：检查模块的修改是否是局部的。
● 方案说明：可以通过计算修改的影响范围来进行度量。

9.影响可控原则(Impact Limitation)
● 解释：软件中模块发生变更，其给其他模块带来的影响要在可控范围内， 即影响范围可预测。
● 用途：用于判断是否存在对某个模块的修改导致大量其他修改的情况。
● 度量方案：检查影响的范围是否可控。
● 方案说明：可以通过计算修改的影响范围来进行度量。

10.复杂性可控原则(Complexity Controllability)
● 解释：架构演化必须要控制架构的复杂性，保障软件的复杂性在可控范围内。
● 用途：用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。
● 度量方案：C C<某个阈值；方案说明：C C增长可控。

11.有利于重构原则(Useful for Refactoring)
● 解释：架构演化要遵循有利于重构原则，使演化后的软件架构更便于重构。
● 用途：用于判断架构易重构性是否得到提高。
● 度量方案：检查系统的复杂度指标。
● 方案说明：系统越复杂越不容易重构。

12.有利于重用原则 (Useful for Reuse)
● 解释：架构演化最好能维持，甚至提高整体架构的可重用性。
● 用途：用于判断整体架构可重用性是否遭到破坏。
● 度量方案：检查模块自身的内聚度、模块之间的耦合度。
● 方案说明：模块的内聚度越高，该模块与其他模块之间的耦合度越低，越容易重用。

13.设计原则遵从性原则 (Design Principles Conformance)
● 解释：架构演化最好不能与架构设计原则冲突。
● 用途：用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结， 要保障其得到充分使用)。
● 度量方案：RCP=|CDP|/|DP|
● 方案说明：冲突的设计原则集合 (CDP) 和总的设计原则集合 (DP) 的比较， RCP越小 越好。

14.适应新技术原则 (Technology Independence,TI)
● 解释：软件要独立于特定的技术手段，让软件运行于不同平台。
● 用途：用于判断架构演化是否存在对某种技术依赖过强的情况。
● 度量方案：TI=1-DDT, 其中DDT=|依赖的技术集合||用到的技术合集|。
● 方案说明：根据演化系统对关键技术的依赖程度进行度量。

15.环境适应性原则(Platform Adaptability)
● 解释：架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。
● 用途：用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置。
● 度量方案：硬件/软件兼容性。
● 方案说明：结合软件质量中兼容性指标进行度量。

16.标准依从性原则 (Standard Conformance)
● 解释：架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标 准等)。
● 用途：用于判断架构演化是否具有规范性，是否有章可循；而不是胡乱或随意地 演化。
● 度量方案：需要人工判定。

17.质量向好原则(Quality Improvement,QI)
● 解释：通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或 者更满意，例如可靠性提高了。
● 用途：用于判断架构演化是否导致某些质量指标变得很差。
● 度量方案：EQI>= Q
● 方案说明：演化之后的质量 (EQI) 比原来的质量 (SQ) 要好。

18.适应新需求原则 (New Requirement Adaptability)
● 解释：架构演化要很容易适应新的需求变更；架构演化不能降低原有架构适应新需求的能力；架构演化最好可以提高适应新需求的能力。
● 用途：用于判断演化之后的架构是否降低了架构适应新需求的能力。
● 度量方案：RNR=|ANR|/|NR|
● 方案说明：适应的新需求集合 (ANR) 和实际新需求集合 (NR) 的比较， RNR越小越好。