軟件架構維護過程設計以下內容：架構知識管理、架構修改管理、架構版本管理

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 具有子模塊，因而對該組件進行度量，并將該組件的度量值作為待評估系統的最終結果

---