系统架构设计师:软件架构的演化和维护--软件架构演化原则
本节列举了18种软件架构可持续演化原则，并针对每个原则设计了相应的度量方案。这些度量方案看似简单，但每个方案都能紧抓该原则的本质，可以做到从架构（系统的整体结构）层面提供有价值的信息，帮助对架构进行有效观察。
1.演化成本控制原则
原则名称：演化成本控制（Evolution Cost Control，ECC）原则。
原则解释：演化成本要控制在预期的范围之内，也就是演化成本要明显小于重新开发成本
原则用途：用于判断架构演化的成本是否在可控范围内，以及用户是否可接受。
度量方案：CoE<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<某个阈值；
方案说明：CC增长可控。
11.有利于重构原则
原则名称：有利于重构（Useful for Refactoring）原则。
原则解释：架构演化要遵循有利于重构原则，使得演化之后的软件架构更便于重构。
原则用途：用于判断架构易重构性是否得到提高。
度量方案：检查系统的复杂度指标。
方案说明：系统越复杂越不容易重构。
12.有利于重用原则
原则名称：有利于重用（Useful for Reuse）原则。
原则解释：架构演化最好能维持，甚至提高整体架构的可重用性。
原则用途：用于判断整体架构可重用性是否遭到破坏。
度量方案：检查模块自身的内聚度、模块之间的耦合度。
方案说明：模块的内聚度越高，该模块与其他模块之间的耦合度越低，越容易重用。
13.设计原则遵从性原则
原则名称：设计原则遵从性（Design Principles Conformance）原则。原则解释：架构演化最好不能与架构设计原则冲突。
原则用途：用于判断架构设计原则是否遭到破坏（架构设计原则是好的设计经验总结，要保障其得到充分使用）。
度量方案：RCP=ICDP//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越小越好。
- 发表于:
- 原文链接：https://page.om.qq.com/page/Obspoj9AacxLfeu9C2gX3_2g0
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
