軟考高級系統架構設計師-第12章系統質量屬性與架構評估

【本章學習建議】

根據考試大綱，本章不僅考查系統架構設計師單選題，預計考11分左右，而且案例分析和論文寫作也是必考，對應第二版教材第8章，屬于重點學習的章節。

12.1 軟件系統質量屬性

12.1.1 質量屬性概念

軟件系統質量屬性（Quality Attribute）是一個系統的可測量或者可測試的屬性，用來描述系統滿足利益相關者（Stakeholders）需求的程度。基于軟件系統的生命周期，可以將軟件系統的質量屬性分為開發期質量屬性和運行期質量屬性2個部分。

1. 開發期質量屬性

開發期質量屬性主要指在軟件開發階段所關注的質量屬性，主要包含6個方面。

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

（2）可擴展性：軟件因適應新需求或需求變化而增加新功能的能力，也稱為靈活性。

（3）可重用性：指重用軟件系統或某一部分的難易程度。

（4）可測試性：對軟件測試以證明其滿足需求規范的難易程度。

（5）可維護性：當需要修改缺陷、增加功能、提高質量屬性時，識別修改點并實施修改的難易程度。

（6）可移植性：將軟件系統從一個運行環境轉移到另一個不同的運行環境的難易程度。

2. 運行期質量屬性

運行期質量屬性主要指在軟件運行階段所關注的質量屬性，主要包含7個方面。

（1）性能：性能是指軟件系統及時提供相應服務的能力，如速度、吞吐量和容量等的要求。

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

（3）可伸縮性：指當用戶數和數據量增加時，軟件系統維持高服務質量的能力。例如，通過增加服務器來提高能力。

（4）互操作性：指本軟件系統與其他系統交換數據和相互調用服務的難易程度。

（5）可靠性：軟件系統在一定的時間內持續無故障運行的能力。

（6）可用性：指系統在一定時間內正常工作的時間所占的比例。可用性會受到系統錯誤，惡意攻擊，高負載等問題的影響。

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

12.1.2 面向架構評估的質量屬性

在架構評估過程中，所普遍關注的質量屬性有以下幾種。

（1）性能：指系統的響應能力，即要經過多長時間才能對某個事件做出響應，或者在某段時間內系統所能處理的事件的個數。如響應時間、吞吐量。設計策略：優先級隊列、增加計算資源、減少計算開銷、引入并發機制、采用資源調度等。

（2）可靠性：是軟件系統在應用或系統錯誤面前，在意外或錯誤使用的情況下維持軟件系統的功能特性的基本能力。可靠性通常用平均失效等待時間（Mean Time To Failure，MTTF）和平均失效間隔時間（Mean Time Between Failure，MTBF）來衡量。在失效率為常數和修復時間很短的情況下，MTTF 和MTBF幾乎相等。可分為容錯和健壯性。容錯是指在錯誤發生時確保系統正確的行為，并進行內部“修復”。健壯性是指系統不受錯誤使用和錯誤輸入的影響，按既定程序忽略錯誤。設計策略：冗余、心跳、選舉、Ping/Echo。

（3）可用性：是系統能夠正常運行的時間比例，經常用兩次故障之間的時間長度或在出現故障時系統能夠恢復正常的速度來表示。如故障間隔時間。設計策略：冗余、心跳、選舉、Ping/Echo。

（4）安全性：是指系統在向合法用戶提供服務的同時能夠阻止非授權用戶使用的企圖或拒絕服務的能力。可分為機密性、完整性、不可否認性、可控性。機密性保證信息不泄露給未授權的用戶、實體或過程；完整性保證信息的完整和準確，防止信息被非法修改；不可否認性是指信息交換的雙方不能否認其在交換過程中發送信息或接收信息的行為；可控性保證對信息的傳播及內容具有控制的能力，防止為非法者所用。設計策略：入侵檢測、用戶認證、用戶授權、追蹤審計。

（5）可修改性：指能夠快速的以較高的性能價格比對系統進行變更的能力。通常以某些具體的變更為基準，通過考查這些變更的代價來衡量可修改性。可分為可維護性、可擴展性、結構重組和可移植性。

可維護性：在錯誤發生后“修復”軟件系統的難易程度。

可擴展性：軟件因適應新需求或需求變化而增加新功能的能力。

結構重組：重新組織軟件系統的構件及構件之間的關系。

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

設計策略：接口-實現分類、抽象、信息隱藏。

（6）功能性：是系統所能完成所期望的工作的能力。一項任務的完成需要系統中許多或大多數構件的相互協作。

（7）可變性：指架構經擴充或變更而成為新架構的能力。這種新架構應該符合預先定義的規則，在某些具體方面不同于原有的架構。當要將某個架構作為一系列相關產品的基礎時，可變性是很重要的。

（8）互操作性：作為系統組成部分的軟件不是獨立存在的，通常與其他系統或自身環境相互作用。為了支持互操作性，軟件架構必須為外部可視的功能特性和數據結構提供精心設計的軟件入口。程序和用其他編程語言編寫的軟件系統的交互作用就是互操作性的問題，這種互操作性也影響應用的軟件架構。

12.1.3 質量屬性場景描述

為了精確描述軟件系統的質量屬性，通常采用質量屬性場景（Quality Attribute Scenario）作為描述質量屬性的手段。質量屬性場景是一種面向特定質量屬性的需求。它由6部分組成：

·刺激源（Source）：這是某個生成該刺激的實體（人、計算機系統或者任何其他刺激器）。

·刺激（Stimulus）：該刺激是當刺激到達系統時需要考慮的條件。

·環境（Environment）：該刺激在某些條件內發生。當激勵發生時，系統可能處于過載、運行或者其他情況。

·制品（Artifact）：某個制品被激勵。這可能是整個系統，也可能是系統的一部分。

·響應（Response）：該響應是在激勵到達后所采取的行動。

·響應度量（Measurement）：當響應發生時，應當能夠以某種方式對其進行度量，以對需求進行測試。

可修改性質量屬性場景描述實例（以淘寶APP為例）：

刺激源：淘寶APP進行更新，開發人員修改代碼；刺激：淘寶APP暫時維護，增加部分功能；

環境：APP平臺；制品：新版本的淘寶APP；響應：增添部分功能或修復部分BUG；

響應度量：過去的BUG消失或增加了新功能。

可修改性質量屬性場景描述實例：

場景要素	可能的情況
刺激源	最終用戶、開發人員、系統管理員
刺激	希望增加、刪除、修改、改變功能、質量屬性、容量等
環境	系統設計時、編譯時、構建時、運行時
制品	系統用戶界面、平臺、環境或與目標系統交互的系統
響應	查找架構中需要修改的位置，進行修改且不會影響其他功能，對所做的修改進行測試，部署所做的修改
響應度量	根據所影響元素的數量度量的成本、努力、資金；該修改對其他功能或質量屬性所造成影響的程度

質量屬性場景舉例：

·性能場景：①數據傳遞時延不大于1S，并提供相應的優先級管理。②網站在并發用戶數量10萬的負載情況下，用戶請求的平均響應時間應小于3秒。

·可用性場景：①系統采用雙機熱備，主備機必須實時監測對方狀態，以便完成系統的實時切換。②主站宕機后，系統能夠在10秒內自動切換至備用站點并恢復正常運行。

·安全性場景：系統應能夠防止99%的黑客攻擊。

·可修改性場景：系統完成上線后，少量的外圍業務功能和界面的調整與修改不超過10人·月。

質量屬性場景主要關注可用性、可修改性、性能、可測試性、易用性和安全性等6類質量屬性。

·可用性質量屬性場景所關注的方面包括系統故障發生的頻率、出現故障時會發生什么情況、允許系統有多長時間是非正常運行、什么時候可以安全地出現故障、如何防止故障的發生以及發生故障時要求進行哪種通知。

·可修改性質量屬性場景主要關注系統在改變功能、質量屬性時需要付出的成本和難度，可修改性質量屬性場景可能發生在系統設計、編譯、構建、運行等多種情況和環境下。

·性能質量屬性場景主要關注系統的響應速度，可以通過效率、響應時間、吞吐量、負載來客觀評價性能的好壞。

·可測試性質量屬性場景主要關注系統測試過程中的效率，發現系統缺陷或故障的難易程度等。

·易用性質量屬性場景主要關注用戶在使用系統時的容易程度，包括系統的學習曲線、完成操作的效率、對系統使用過程的滿意程度等。

·安全性質量屬性場景主要關注系統在安全性方面的要素，衡量系統在向合法用戶提供服務的同時，阻止非授權用戶使用的能力。

12.2 系統架構評估

12.2.1 系統架構評估中的重要概念

系統架構評估是在對架構分析、評估的基礎上，對架構策略的選取進行決策。

系統架構評估中的重要概念：

（1）敏感點和權衡點。敏感點和權衡點是關鍵的架構決策。敏感點：是指為了實現某種特定的質量屬性，一個或多個構件所具有的特性。權衡點：是影響多個質量屬性的特性，是多個質量屬性的敏感點。改變加密級別可能會對安全性和性能產生非常重要的影響。提高加密級別可以提高安全性，但可能要耗費更多的處理時間，影響系統性能。如果某個機密消息的處理有嚴格的時間延遲要求，則加密級別可能就會成為一個權衡點。

（2）風險承擔者或者稱為利益相關人。系統的架構涉及很多人的利益，這些人都對架構施加各種影響，以保證自己的目標能夠實現。例如，風險承擔者是軟件系統架構師，職責是負責軟件架構的質量需求間進行權衡的人，所關心的問題是對其他風險承擔者提出的質量需求的折中和調停。

（3）場景。在進行架構評估時，一般首先要精確地得出具體的質量目標，并以之作為判定該架構優劣的標準。為得出這些目標而采用的機制稱之為場景。場景是從風險承擔者的角度對與系統的交互的簡短描述。在架構評估中，一般采用刺激、環境和響應三方面來對場景進行描述。

系統架構評估在架構設計之后，系統設計之前，因此與設計、實現、測試都沒有關系。評估的目的是為了評估所采用的架構是否能解決軟件系統需求。

系統架構評估的方法有3種：

·基于調查問卷或檢查表的方法：類似于需求獲取中的問卷調查方式，只不過是架構方面的問卷，要求評估人員對領域熟悉。

·基于場景的評估方法：主要方法。它是通過分析軟件架構對場景（也就是對系統的使用或修改活動）的支持程度，從而判斷該架構對這一場景所代表的質量需求的滿足程度。從三個方面對場景進行設計：刺激（事件）；環境（事件發生的環境）；響應（架構響應刺激的過程）。應用在架構權衡分析方法（Architecture Tradeoff Analysis Method，ATAM）和軟件架構分析方法（Software Architecture Analysis Method，SAAM）中。

·基于度量的評估方法：制定一些定量指標來度量架構，如代碼行數等。要制定質量屬性和度量結果之間的映射，要求評估人員對架構熟悉。它是建立在軟件架構度量的基礎上的，涉及3個基本活動，首先需要建立質量屬性和度量之間的映射原則，然后從軟件架構文檔中獲取度量信息，最后根據映射原則分析推導出系統的質量屬性。

12.2.2 系統架構評估方法

1. 基于場景的架構分析方法SAAM

SAAM是一種非功能質量屬性的架構分析方法，是最早形成文檔并得到廣泛使用的軟件架構分析方法。

（1）特定目標。SAAM的目標是對描述應用程序屬性的文檔，驗證基本的架構假設和原則。

（2）評估技術。SAAM所使用的評估技術是場景技術。場景代表了描述架構屬性的基礎，描述了各種系統必須支持的活動和可能存在的狀態變化。

（3）質量屬性。這一方法的基本特點是把任何形式的質量屬性都具體化為場景，但可修改性是SAAM分析的主要質量屬性。

（4）風險承擔者。SAAM協調不同參與者之間感興趣的共同方面，作為后續決策的基礎，達成對架構的共識。

（5）架構描述。SAAM用于架構的最后版本，但早于詳細設計。架構的描述形式應當被所有參與者理解。功能、結構和分配被定義為描述架構的3個主要方面。

（6）方法活動。SAAM的主要輸入是問題描述、需求聲明和架構描述。下圖描繪了SAAM分析活動的相關輸入及評估過程。SAAM分析評估架構的過程包括5個步驟，即場景開發、架構描述、單個場景評估、場景交互評估和總體評估。

（7）已有知識庫的可重用性：SAAM不考慮這個問題。

（8）方法驗證：SAAM是一種成熟的方法，己被應用到眾多系統中，這些系統包括空中交通管制、嵌入式音頻系統、WRCS （修正控制系統）、KWIC （根據上下文查找關鍵詞系統）等。

2. 架構權衡分析方法ATAM

架構權衡分析方法ATAM是在SAAM的基礎上發展起來的，主要針對性能、安全性、可修改性和可用性，在系統開發之前，對這些質量屬性進行評價和折中。

架構權衡分析法ATAM，讓架構師明確如何權衡多個質量目標，參與者有評估小組、項目決策者和其他項目相關人。

ATAM被分為四個主要的活動領域，分別是場景和需求收集、體系結構視圖和場景實現、屬性模型構造和分析、折中。整個評估過程強調以質量屬性作為架構評估的核心。

用ATAM方法評估軟件架構，其工作分為4個基本階段，即演示、調查和分析、測試和報告，如圖所示。

（1）階段1--演示

這是使用ATAM評估軟件體系結構的初始階段。

①介紹ATAM。描述ATAM的評估過程。

②介紹業務驅動因素。著重業務視角，提供有關系統功能、主要利益

相關方、業務目標和其他限制等信息。

③介紹要評估的體系結構。側重可用性以及體系結構的質量要求。

（2）階段2--調查和分析

在這個階段，人們對評估期間需要重點關注的一些關鍵問題進行徹底調查。

①確定架構方法：涉及能夠理解系統關鍵需求的關鍵架構方法。

②生成質量屬性效用樹：確定最重要的質量屬性，并確定有限次序。

③分析體系結構方法：徹底調查和分析，找出處理相應質量屬性架構的方法。包括4個主要階段：調查架構方法->創建分析問題->分析問題的答案->找出風險、非風險、敏感點和權衡點。

（3）階段3--測試

①頭腦風暴和優先場景：將頭腦風暴的優先列表與生成質量屬性效用樹中所獲取的優先方案進行比較。利益相關者需要使用頭腦風暴的三種場景：

·用例場景：在這種情況下，利益相關者就是最終用戶。

·增長情景：代表了架構發展的方式。

·探索性場景：代表架構中極端的增長形式。

②分析架構方法。

（4）階段4--報告ATAM

提供評估期間收集的所有信息，呈現給利益相關者。

質量屬性效用樹：

ATAM方法采用效用樹（Utility tree）這一工具來對質量屬性進行分類和優先級排序。效用樹的結構包括：樹根--質量屬性--屬性分類--質量屬性場景（葉子節點）。需要注意的是，ATAM主要關注4類質量屬性：性能、安全性、可修改性和可用性，這是因為這4個質量屬性是利益相關者最為關心的。

3. 成本效益分析法CBAM

成本效益分析法CBAM是在ATAM上構建，用來對架構設計決策的成本和收益進行建模，讓決策者根據投資回報率ROI來選擇合適的架構，在ATAM確定質量合理的基礎上，再對效益進行分析。有以下8個步驟：

（1）整理場景（確定場景，并確定優先級，選擇優先級最高的1/3場景進行分析）；

（2）對場景進行細化（對每個場景詳細分析，確定最好、最壞的情況）；

（3）確定場景的優先級（項目干系人對場景投票，根據投票結果生成場景的權值）；

（4）分配效用（對場景響應級別確定效用表，建立策略、場景、響應級別的表格)；

（5）形成“策略-場景-響應級別”的對應關系；

（6）使用內插法確定期望的質量屬性響應級別的效用（根據效用表確定所對應的具體場景的效用表）；

（7）計算各架構策略的總收益；

（8）根據受成本限制影響的投資回報率ROI選擇架構策略（估算成本，用上一步的收益減去成本，計算ROI并排序，從而選擇收益最高的架構策略）。

4. 其他評估方法（僅了解）

1.SAEM方法。將軟件架構看作一個最終產品以及設計過程中的一個中間產品，從外部質量屬性和內部質量屬性兩個角度來闡述它的評估模型，旨在為軟件架構的質量評估創建一個基礎框架。

外部屬性指用戶定義的質量屬性，而內部屬性指開發者決定的質量屬性。該軟件架構評估模型包含以下幾個流程。

（1）對待評估的質量屬性進行規約建模。

（2）為外部和內部的質量屬性創建度量準則，先從評估目的（如軟件架構比較、最終產品的質量預測），評估角度（如開發者、用戶、維護者），評估環境（架構作為最終產品或設計中間產品）出發來定義架構評估的目標，再根據目標相關的屬性來提出問題，然后回答每個問題并提出相應的度量準則。

（3）評估質量屬性，包括數據收集、度量和結果分析3個活動。

2.SAABNet方法。是一種用來表達和使用定性知識以輔助架構的定性評估。該方法來源于人工智能，允許不確定、不完整知識的推理。該方法使用BBN來表示和使用開發過程中的知識，包含定性和定量的描述，其中定性的描述是所有結點的圖，定量的描述是每個結點狀態相關的條件概率。其中的變量可分為3類，即架構質量屬性變量（如可維護性、靈活性等）、質量屬性的度量準則變量（如容錯性、響應性等）和架構特征變量（如繼承深度、編程語言等），高層抽象的質量屬性變量分解為低層抽象的度量準則變量，度量準則變量則分解為更低層抽象的架構特征變量。

3.SACMM方法。是一種軟件架構修改的度量方法。

4.SASAM方法。通過對預期架構（架構設計階段的相關描述材料）和實際架構（源代碼中執行的架構）進行映射和比較來靜態地評估軟件架構。

5.ALRRA方法。是一種軟件架構可靠性風險評估方法，該方法使用動態復雜度準則和動態耦合度準則來定義組件和連接件的復雜性因素，其中，動態復雜度準則在某個場景的執行中分析組件的動態行為來度量組件的復雜性，動態耦合度準則在某個場景的執行中分析連接件的消息傳遞協議來度量連接件的復雜性。利用失效模式和影響分析（FMEA）技術。

6.AHP方法（層次分析法）。是對定性問題進行定量分析的一種簡便、靈活而又實用的多準則決策方法。AHP方法的特點是把復雜問題中的各種因素通過劃分為相聯系的有序層次使之條理化，并在一般情況下通過兩兩對比，根據一定客觀現實的主觀判斷結構，把專家意見和分析者的客觀判斷結果直接、有效地結合起來，將一定層次上元素的某些重要性進行定量描述，之后利用數學方法計算反映每一層次元素的相對重要性次序的權值，并最后通過所有層次之間的總排序計算所有元素的相對權重及對權重進行排序。

7.COSMIC+UML方法。基于度量模型來評估軟件架構可維護性的方法。針對不同表達方式的軟件架構，采用統一的軟件度量COSMIC方法來進行度量和評估。該方法主要是為了輔助分析軟件架構的演化方案是否可行，并在開源軟件DCMMS的軟件架構UML組件圖上得以驗證。