软件架构维护过程设计以下内容：架构知识管理、架构修改管理、架构版本管理

1. 软件架构知识管理

1.1 概念

• 架构知识 = 架构设计 + 架构设计决策

即，需要说明在进行架构设计时采用此种架构的原因

• 涵盖内容：
  • 架构的解决方案
  • 产生该方案的架构设计决策、设计依据

1.2 架构知识的获取

• 侧重于架构静态演化
• 从架构文档等信息来源中捕捉架构知识

1.3 作用

• 有助于架构进一步的演化
• 为其他软件架构的相关活动提供参考

1.4 架构知识管理的现状

• 架构相关利益者因为动机不足，不会使用文档记录架构知识
  • 相对成本高
  • 利益相关者对工程短期兴趣大于架构知识重用的兴趣
  • 开发者对创造性工作的兴趣大于反思设计决策长远影响的兴趣。
• 即使实现了文档化，通常架构知识也不能在整个组织中得到充分的分享

如果不进行管理，关键的设计知识就会“沉没”在软件架构之中，人员发生变动，将会使“沉没”的架构知识“腐蚀”

2 软件架构修改管理

• 思路：
  • 是建立一个隔离区域 (Rcgion of Quiescence)
  • 保障该区域中任何修改对其他部分的影响比较小，甚至没有影响
• 做法：
  • 为此，需要明确修改规则、修改类型，可能的影响范围、副作用等

3 软件架构版本管理

• 作用：
  • 为版本演化的控制、使用、评价等提供了可靠的依据
  • 为架构演化量化度量奠定了基础

4. 示例

4.1 背景

• 待评估的 Web读写系统的组件图如下：
  

4.2 数据获取

• 操作：
  • 将组件图转换为XML文件
  • 将XML文件输入架构评估系统
  • 解析出可维护度量所需的数据，如下：

上表说明：

• L：组件图数目
• totalN ：外部组件数目
• totalE ：与外部组件相连的边的数据
• S：组件内部组件数目
• E：依赖出边数目
• X：依赖入边数目
• R：使用接口数目
• W：提供接口数目

4.3 数据计算

根据可维护性的6个子度量指标的度量公式，利用解析得到的架构评估数据分别进行度量

• 圈复杂度 (CCN)
  度量整个架构的独立执行路径的条数，直接得出最终度量结果
• 扇入扇出度 (FFC)、 模块间耦合度 (CBO)、 模块的响应 (RFC)、 紧内聚度 (TCC)、 松内聚度 (LCC)
  针对每个组件进行度量，最终度量结果取所有组件的平均值

• 组件Client Application为各个子度量指标的计算方法:
  
• 其他组件的度量方法：
  • 与Client Application相同
  • 由于均没有子组件，P(S) 的果为0, 无法计算该组件模块的内聚度，以 “not applied” 表示（即，没有子组件，内聚度最小）

• 度量结果如图所示：
  

4.4 结果分析

4.4.1 圈复杂度 (CCN)

• 目的：
  • 对整个系统的复杂程度做出初步评估
  • 并预测待评估系统的测试复杂度
  • 及早规避风险，提高软件质量
• 标准： CCN≤10 为宜。

4.4.2 扇入扇出度 (FFC)

• 概念：
  • 扇入：指直接调用该模块的上级模块的个数
  • 扇出：指该模块直接调用的下级模块的个数
• 目的：综合评估组件主动调用以及被调用的频率
  • 扇入扇出度越大，表明该组件与其他组件间的接口关联或依赖关联越多

4.4.3 模块间耦合度 (CBO)

• 目的：度量模块与其他模块交互的频繁程度

CBO越大可维护性越差，风险越高

4.4.4 模块的响应 (RFC)

• 目的：度量组件执行所需的功能的数量
  • 包括：接口提供的功能、依赖的其他模块提供的功能、子模块提供的功能
    

DB、RemoteDB、LocalDB等没有对其他模块的依赖和调用，且不包含子模块，因而其 RFC度量值为0

4.4.5 模块间内聚度TCC和 LCC

只有组件ClientApplication 具有子模块，因而对该组件进行度量，并将该组件的度量值作为待评估系统的最终结果

---