系统架构设计师教程 第10章 10.7 软件架构维护 笔记
10.7 软件架构维护 ★★☆☆☆
软件架构的开发和维护是基于架构软件生命周期中的关键环节，
软件架构的维护与演化密不可分，维护需要对软件架构的演化过程进行追踪和控制
10.7.1 软件架构知识管理
1.架构知识的定义
架构知识= 架构设计 + 架构设计决策。
2.架构知识管理的含义
侧重于软件开发和实现过程所涉及的架构静态演化，从架构文档等信息来源中捕捉架构知识，进而提供架构的质量属性及其设计依据以进行记录和评价。架构知识管理要涵盖架构的解决方案，产生该方案的架构设计决策、设计依据与其他信息，以有助于架构进一步的演化。
3.架构知识管理的需求
架构知识的可获得性能够极大地提升软件开发流程。
4.架构知识管理的现状
侧重于对架构信息的整理、存储和恢复。
10.7.2 软件架构修改管理
建立一个隔离区域 (Rcgion of Quiescence), 保障该区域中任何修改对其他部分的影响比较小，甚至没有影响。
10.7.3 软件架构版本管理
软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据，并为架构演化量化度量奠定了基础。
10.7.4 软件架构可维护性度量实践
架构可维护性评估针对架构组件图进行度量，评估高层次上的架构复杂程度
据可维护性的6个子度量指标的度量公式，利用解析得到的架构评估数据分别进行度量。其中
圈复杂度 (CCN) 度量整个架构的独立执行路径的条数，该结果值即为待评估架构的最终度量结果；
对于扇入扇出度 (FFC)、 模块间耦合度 (CBO)、 模块的响应 (RFC)、 紧内聚度 (TCC)、 松内聚度 (LCC) 这5个度量指标，它们针对每个组件进行度量，则待评估架构的最终度量结果为所有组件结果的平均值。
- 圈复杂度 (CCN)
对 架构的组件图进行圈复杂度的度量，可以对整个系统的复杂程度做出初步评估，在设计早期发 现问题和做出调整，并预测待评估系统的测试复杂度，及早规避风险，提高软件质量。圈复杂 度高的程序往往是最容易出现错误的程序，实践表明程序规模以 C C N ≤ 1 0 为宜。
2)扇入扇出度 (FFC)
扇入是指直接调用该模块的上级模块的个数，
扇出指该模块直接调用的下级模块的个数。
3)模块间耦合度 (CBO)
模块间耦合度CBO度量模块与其他模块交互的频繁程度。
CBO越大的模块，越容易受到其他模块中修改和错误的影响，因而可维护性越差，风险越高。
4)模块的响应 (RFC)
RFC度量组件执行所需的功能的数量，包括接口提供的功能、依赖的其他模块提供的功能以及子模块提供的功能。
5)模块间内聚度TCC和 LCC
遵循“高内聚-低耦合”原则，提高模块的独立性，降低模块间接口调用的复杂性。
原文地址：https://blog.csdn.net/z2014z/article/details/142433641
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！