架構需求與軟體質量屬性

    架構的基本需求主要是在滿足功能屬性的前提下，關注軟體質量屬性，架構設計則是為滿足架構需求（質量屬性）尋找適當的“戰術”。

    軟體屬性包括功能屬性和質量屬性，但是，軟體架構（及軟體架構設計師）重點關注的是質量屬性。因為，在大量的可能結構中，可以使用不同的結構來實現同樣的功能性，即功能性在很大程度上是獨立於結構的，架構設計師面臨著決策（對結構的選擇），而功能性所關心的是它如何與其他質量屬性進行互動，以及它如何限制其他質量屬性。

1 軟體質量屬性 

    《GB/T16260-1996(idt ISO／IEC9126：1991)資訊科技軟體產品評價質量特性及其使用指南》中描述的軟體質量特性包括功能性、可靠性、易用性、效率、可維護性、可移植性等 6 個方面，每個方面都包含若干個子特性。

• 功能性：適合性、準確性、互操作性、依從性、安全性；

• 可靠性：成熟性、容錯性、易恢復性；

• 易用性：易理解性、易學性、易操作性；

• 效率：時間特性、資源特性；

• 可維護性：易分析性、易改變性、穩定性、易測試性；

• 可移植性：適應性、易安裝性、遵循性、易替換性；

    正如上述列舉與分類，軟體的質量屬性很多，也有各種不同的分類法和不同的表述。雖然術語沒有統一的定義，但其含義可以認為業界已有共識。下面選取常用的質量屬性術語，並做逐一說明。

    1．執行期質量屬性 

• 效能：效能是指軟體系統及時提供相應服務的能力。包括速度、吞吐量和持續高速性三方面的要求。

• 安全性：指軟體系統同時兼顧向合法使用者提供服務，以及阻止非授權使用的能力。

• 易用性：指軟體系統易於被使用的程度。

• 可伸縮性：指當用戶數和資料量增加時，軟體系統維持高服務質量的能力。例如，通過增加伺服器來提高能力。

• 互操作性：指本軟體系統與其他系統交換資料和相互呼叫服務的難易程度。

• 可靠性：軟體系統在一定的時間內無故障執行的能力。

• 持續可用性：指系統長時間無故障執行的能力。與可靠性相關聯，常將其納入可靠性中。

• 魯棒性：是指軟體系統在一些非正常情況（如使用者進行了非法操作、相關的軟硬體系統發生了故障等）下仍能夠正常執行的能力。也稱健壯性或容錯性。

    2.開發期質量屬性 

• 易理解性：指設計被開發人員理解的難易程度。

• 可擴充套件性：軟體因適應新需求或需求變化而增加新功能的能力。也稱為靈活性。

• 可重用性：指重用軟體系統或某一部分的難易程度。

• 可測試性：對軟體測試以證明其滿足需求規範的難易程度。

• 可維護性：當需要修改缺陷、增加功能、提高質量屬性時，定位修改點並實施修改的難易程度；

• 可移植性：將軟體系統從一個執行環境轉移到另一個不同的執行環境的難易程度。

    在實踐中，架構設計師追求質量屬性常常陷入“魚和熊掌”的兩難境地，這就需要架構設計師的決策智慧了。表 9-1 反映了質量屬性之間的相互制約關係（正相關或負相關），其中“+”代表“行屬性”能促進“列屬性”；而“-”則相反。例如，第一列符號說明許多屬性（行）對效能（列）有副作用，第一行符號說明效能（行）對許多屬性（列）有副作用，認識這一點，對於架構決策的權衡很重要。

6個質量屬性及實現

    本節從架構關注點來研究質量屬性實現，將質量屬性分為 6 種：可用性、可修改性、效能、安全性、可測試性、易用性。其他的質量屬性一般可納入這幾個屬性中（在其他文獻中為了強調常單列出來），例如，可擴充性可歸入可修改性中（修改系統容量），可移植性也可以作為平臺的可修改性來獲得。對於未能納入的其他質量屬性，可以用本章的方法進行研究。

    那麼，如何描述質量屬性需求呢？採用質量屬性場景作為一種描述規範，它由以下6個部分組成，如圖 9-2 所示。

• 刺激源：生成該刺激的實體（人、計算機系統或其他激勵器）；

• 刺激：刺激到達系統時可能產生的影響（即需要考慮和關注的情況）；

• 環境：該刺激在某條件內發生。如系統可能正處於過載情況；

• 製品：系統中受刺激的部分（某個製品被刺激）；

• 響應：刺激到達後所採取的行動；

• 響應度量：當響應發生時，應能夠以某種方式對應其度量，用於對是否滿足需求的測試。

    需要將一般的質量屬性場景（一般場景）與具體的質量屬性場景（具體場景）區別開來，前者是指獨立於具體系統、適合於任何系統的一般性場景；而後者是指適合於正在考慮的某個特定系統的場景，具體場景通常是指從一般場景中抽取特定的、面向具體系統的內容。下面幾個小節中為每個質量屬性提供一張表，該表中給出了質量屬性場景每部分的一些可能取值，整體上形成一個一般場景的表格描述。在實際應用時，根據系統的具體情況，從該表中選取適當的值，就能變成具體場景（可讀性強、可應用），可以把具體場景的集合作為系統的質量屬性需求。

     實現這些質量屬性的基本設計決策，稱為“戰術”，而把戰術的集合稱為“架構策略”。這些架構策略供架構設計師選擇。下面幾個小節將對各質量屬性的戰術進行示例性的總結。

    “戰術”作為邏輯部件位於圖 9-2 的製品中，它旨在控制對刺激的響應。

     1．可用性及其實現戰術 

    （1）可用性的描述。可用性的描述如表 9-2 所示。

    可用性一般場景可以用圖 9-3 表示。

    對一般場景進行具體化可以得到可用性具體場景，如圖 9-4 所示。

    （2）可用性戰術。可用性戰術的目標是阻止錯誤發展成故障，至少能夠把錯誤的影響限制在一定範圍內，從而使修復成為可能。戰術分為：錯誤檢測、錯誤恢復、錯誤預防。

    ① 錯誤檢測

• 命令/響應：一個構件發出一個命令，並希望在預定義的時間內收到一個來自審查構件的響應，例如遠端錯誤的檢測。

• 心跳（計時器）：一個構件定期發出一個心跳訊息，另一個構件收聽到訊息，如果未收到心跳訊息，則假定構件失敗，並通知錯誤糾正構件。

• 異常：當出現異常時，異常處理程式開發執行。

    ② 錯誤恢復

• 表決：通過冗餘構件（或處理器）與表決器連線，構件按相同的輸入及演算法計算輸出值交給表決器，由表決器按表決演算法（如多數規則）確定是否有構件出錯，表決通常用在控制系統中。

• 主動冗餘（熱重啟、熱備份）：所有的冗餘構件都以並行的方式對事件做出響應。它們都處在相同的狀態，但僅使用一個構件的響應，丟棄其餘構件的響應。錯誤發生時通過切換的方式使用另一個構件的響應。

• 被動冗餘（曖重啟/雙冗餘/三冗餘）：一個構件（主構件）對事件做出響應，並通知其他構件（備用的）必須進行的狀態更新（同步）。當錯誤發生時，備用構件從最新同步點接替主構件的工作。

• 備件：備件是計算平臺配置用於更換各種不同的故障構件。

• 狀態再同步：主動和被動冗餘戰術要求所恢復的構件在重新提供服務前更新其狀態。更新方法取決於可以承受的停機時間、更新的規模及更新的內容多少。

• 檢查點/回滾：檢查點就是使狀態一致的同步點，它或者是定期進行，或者是對具體事件做出響應。當在兩檢查點之間發生故障時，則以這個一致狀態的檢查點（有快照）和之後發生的事務日誌來恢復系統（資料庫中常使用）。

    ③ 錯誤預防

• 從服務中刪除：如刪除程序再重新啟動，以防止記憶體洩露導致故障的發生。

• 事務：使用事務來保證資料的一致性，即幾個相關密切的步驟，要麼全成功，要麼都不成功。

• 程序監視器：通過監視程序來處理程序的錯誤。

    2．可修改性及其實現戰術

    （1）可修改性的描述。可修改性的描述如表 9-3 所示。

    對於可修改性一般場景的圖示及可修改性具體場景，讀者可仿照前面可用性的描述方式，自行練習。

    （2）可修改性戰術。包括區域性化修改、防止連鎖反應、推遲繫結時間。

     ① 區域性化修改。在設計期間為模組分配責任，以便把預期的變更限制在一定的範圍內，從而降低修改的成本。

• 維持語義的一致性：語義的一致性指的是模組中責任之間的關係，使這些責任能夠協同工作，不需要過多地依賴其他模組。耦合和內聚指標反映一致性，應該根據一組預期的變更來度量語義一致性。使用“抽象通用服務”（如應用框架的使用和其他中間軟體的使用）來支援可修改性是其子戰術。

• 預期期望的變更：通過對變更的預估，進行預設、準備，從而使變更的影響最小。

• 泛化該模組：使一個模組更通用、更廣泛的功能。

• 限制可能的選擇：如在更換某一模組（如處理器）時，限制為相同家族的成員。

    ② 防止連鎖反應。由於模組之間有各種依賴性，因此，修改會產生連鎖反應。防止連鎖反應的戰術如下。

• 資訊隱藏：就是把某個實體的責任分解為更小的部分，並選擇哪些資訊成為公有的，哪些成為私有的，通過介面獲得公有責任。

• 維持現有的介面：儘可能維持現有介面的穩定性。例如通過新增介面（通過新的介面提供新的服務）可以達到這一目的。

• 限制通訊路徑：限制與一個給定的模組共享資料的模組。這樣可以減少由於資料產生/使用引入的連鎖反應。

• 仲裁者的使用：在具有依賴關係的兩個模組之間插入一個仲裁者，以管理與該依賴相關的活動。仲裁者有很多種型別，例如：橋、調停者、代理等就是可以提供把服務的語法從一種形式轉換為另一種形式的仲裁者。

    ③ 推遲繫結時間。系統具備在執行時進行繫結並允許非開發人員進行修改（配置）。

• 執行時註冊：支援即插即用。

• 配置檔案：在啟動時設定引數。

• 多型：在方法呼叫的後期繫結。

• 構件更換：允許載入時繫結。

    3．效能及其實現戰術 

    （1）效能的描述。效能描述如表 9-4 所示。

    對於效能一般場景的圖示及效能具體場景，讀者可仿照前面可用性的描述方式，自行練習。

    （2）效能戰術。效能與時間相關，影響事件的響應時間有兩個基本因素。

• 資源消耗：事件到達後進入一系列的處理程式，每一步處理都要佔用資源，而且在處理過程中訊息在各構件之間轉換，這些轉換也需要佔用資源。

• 閉鎖時間：指對事件處理時碰到了資源爭用、資源不可用或對其他計算的依賴等情況，就產生了等待時間。

    效能的戰術有如下幾種。

    ① 資源需求

• 減少處理事件流所需的資源：提高計算效率（如改進演算法）、減少計算開銷（如在可修改性與效能之間權衡，減少不必要的代理構件）。

• 減少所處理事件的數量：管理事件率、控制取樣頻率。

• 控制資源的使用：限制執行時間（如減少迭代次數）、限制佇列大小。

    ② 資源管理

• 引入併發：引入併發對負載平衡很重要。

• 維持資料或計算的多個副本：C/S 結構中客戶機 C 就是計算的副本，它能減少伺服器計算的壓力；快取記憶體可以存放資料副本（在不同速度的儲存庫之間的緩衝）。

• 增加可用資源：在成本允許時，儘量使用速度更快的處理器、記憶體和網路。

   ③ 資源仲裁

    資源仲裁戰術是通過如下排程策略來實現的。

• 先進/先出（FIFO）；

• 固定優先順序排程：先給事件分配特定的優先順序，再按優先順序高低順序分配資源；

• 動態優先順序排程：輪轉排程、時限時間最早優先；

• 靜態排程：可以離線確定排程。

    4．安全性及其實現戰術 

    （1）安全性的描述。安全性的描述如表 9-5 所示。

    對於安全性一般場景的圖示及安全性具體場景，讀者可仿照前面可用性的描述方式，自行練習。

    （2）安全性戰術：包括抵抗攻擊、檢測攻擊和從攻擊中恢復。

     ① 抵抗攻擊

• 對使用者進行身份驗證：包括動態密碼、一次性密碼、數字證書及生物識別等；

• 對使用者進行授權：即對使用者的訪問進行控制管理；

• 維護資料的機密性：一般通過對資料和通訊鏈路進行加密來實現；

• 維護完整性：對資料新增校驗或雜湊值；

• 限制暴露的資訊；

• 限制訪問：如用防火牆、DMZ 策略。

    ② 檢測攻擊。一般通過“入侵檢測”系統進行過濾、比較通訊模式與歷史基線等方法。

    ③ 從攻擊中恢復。

• 恢復：與可用性中的戰術相同；

• 識別攻擊者：作為審計追蹤，用於預防性或懲罰性目的。

   5．可測試性及其實現戰術

    （1）可測試性的描述。可測試性的描述如表 9-6 所示。

     對於可測試性一般場景的圖示及可測試性具體場景，讀者可仿照前面可用性的描述方式，自行練習。

    （2）可測試性戰術：包括輸入/輸出和內部監控。

    ① 輸入/輸出

• 記錄/回放：指捕獲跨介面的資訊，並將其作為測試專用軟體的輸入；

• 將介面與實現分離：允許使用實現的替代（模擬器）來支援各種測試目的；

• 優化訪問線路/介面：用測試工具來捕獲或賦予構件的變數值。

    ② 內部監控。當監視器處於啟用狀態時，記錄事件（如通過介面的資訊）。

    6．易用性及其實現戰術

    （1）易用性的描述。易用性的描述如表 9-7 所示。

    對於易用性一般場景的圖示及易用性具體場景，讀者可仿照前面可用性的描述方式，自行練習。

    （2）易用性戰術：包括執行時戰術、設計時戰術和支援使用者主動操作。

    ① 執行時戰術

• 任務的模型：維護任務的資訊，使系統瞭解使用者試圖做什麼，並提供各種協助；

• 使用者的模型：維護使用者的資訊，例如使系統以使用者可以閱讀頁面的速度滾動頁面；

• 系統的模型：維護系統的資訊，它確定了期望的系統行為，並向用戶提供反饋。

    ② 設計時戰術。將使用者介面與應用的其餘部分分離開來，預計使用者介面會頻繁發生變化，因此，單獨維護使用者介面程式碼將實現變更區域性化。這與可修改性相關。

    ③ 支援使用者主動操作。支援使用者的主動操作，如支援“取消”、“撤銷”、“聚合”和 “顯示多個檢視”。