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

一、 軟體質量特性

1.1 軟體質量特性主要包括

1.功能性(適合性、準確性、互操作性、依從性、安全性)
2.可靠性（成熟性、容錯性、易恢復性）
3.易用性（易理解性、易學性、易操作性）
4.效率（時間特性、資源特性）
5.可維護性（易分析性、易改變性、穩定性、易測試性）
6.可移植性（適應性、易安裝性、遵循性、易替換性）

• 系統架構風險是指架構設計中，潛在的、存在問題的架構決策所帶來的隱患。
• 敏感點是為了實現某種特定的質量屬性，一個或多個系統元件所具有的特性。
• 權衡點是指影響多個質量屬性，並對多個質量屬性來說都是敏感點的系統屬性.

1.2 常見質量屬性

常見的軟體質量屬性有多種,例如效能(Performance)、可用性(Availability)、可靠性(Reliability)、健壯性(Robustness)、安全性(Security)、可修改性(Modification)、可變性(Changeability)、易用性(Usability)、可測試性(Testability)、功能性(Functionality)和互操作性(Inter-operation)等
這些質量屬性的具體含義是:
1.效能是指系統的響應能力，即要經過多長時間才能對某個事件做出響應，或者在某段時間內系統所能處理事件的個數.
2.可用性是系統能夠正常執行的時間比例.
3.可靠性是指軟體系統在應用或錯誤面前，在意外或錯誤使用的情況下維持軟體系統功能特性的基本能力.
4.健壯性是指在處理或環境中，系統能夠承受壓力或變更能力。
5.安全性是指系統向合法使用者提供服務的同時能夠阻止非授權使用者使用的企圖或拒絕服務
6.可修改性是指能夠快速地以較高的效能價格比對系統進行變更的能力
7.可變性是指體系結構經擴充或變更成為新體系結構的能力
8.易用性是衡量使用者使用有一個軟體產品完成指定任務的難易程度
9.可測試性是指軟體開發發現故障並隔離、定位其故障的能力特，以及在一定時間和成本前提下，進行測試設計、測試執行的能力。
10.功能性是系統所能完成所期望工作的能力
11.互操作性是系統所能完成所期望工作的能力

二、 常見的質量屬性分類

• 常見的質量屬性，可以按照執行期與開發期進行分類：

2.1 執行期質量屬性

效能：效能是指軟體系統及時提供相應服務的能力。包括速度、吞吐量和持續高速性三個方面；
安全性：指軟體系統同時兼顧向合法使用者提供服務，以及阻止非授權使用的能力；
易用性：指軟體系統易於使用的程度
可伸縮性：指當前使用者數和數量增加時，軟體系統維持高服務質量的能力。例如，通過增加伺服器來提高能力
互操作性：指本軟體系統與其他系統交換資料和相互呼叫服務的難易程度
可靠性：軟體系統在一定的時間內無故障執行的能力
持續可用性：指系統長時間無故障執行的能力。
魯棒性：指軟體系統在一些非正常情況（如使用者進行了非法操作、相關軟硬體系統發生故障）下仍能正常執行的能力。也稱健壯性或容錯性。

2.2 開發期質量屬性

易理解性：指設計被開發人員理解的難易程度
可擴充套件性：軟體因適應新需求或需求變化而增加新功能的能力。也稱靈活性。
可測試性：對軟體測試以證明其滿足需求規範的難易程度
可維護性：當需要修改缺陷、增加功能、提高質量屬性時，定位修改點並實施修改的難易程度。
可移植性：將軟體系統從一個執行環境轉移到另一個不同的執行環境的難易程度。

架構師在追求質量屬性常常陷入“魚和熊掌”的兩難境地，這就需要架構設計師的決策智慧了。

注 上表中“+”表示促進作用，“-”則相反

2.3 質量需求怎麼描述

在軟體系統架構設計中，如何描述軟體的質量屬性需求呢？ 一般採用場景的方式進行描述，主要包括6種場景。
本節“場景”指的是軟體系統設計中通用的場景。

質量屬性場景包括6個元素。

刺激源：生成該刺激的實體（人、計算機系統或其他勵志器）；
刺激：刺激達到系統時可能產生的影響（即需要考慮和關注的情況）；
環境：該刺激在某條件內發生。如系統可能正處於過載情況；
製品：系統中受刺激的部分；
響應：刺激到達後所採取的行動；
響應度量：當響應發生時，以某種方式對響應的效果進行度量。

通過對每一類質量屬性進行場景化描述，然後，分別制定應對各個場景的策略。

2.3.1 可用性的場景描述以及策略

可用性的策略目標是阻止錯誤發展成故障，至少能夠把錯誤的影響限制在一定範圍內，從而使修復成為可能。主要包括：錯誤檢測、錯誤恢復、錯誤預防。

2.3.2 可修改性的場景描述以及策略

可修改性的場景描述如下

為了應對系統的可修改性需求，主要有三種方法：

1. 區域性修改。在軟體架構設計的時候，對系統進行分解，將預期的變更限定在一定的範圍內，從而降低修改的成本。
2. 防止連鎖反應。模組之間往往存在依賴性，在修改時要保持介面的一致性。通過限制模組間的通訊線路，可以在修改某模組後再恢復通行線路。
3. 推遲繫結時間。系統在執行時進行繫結並允許非開發人員進行修改（配置）。
   執行時註冊、配置檔案、多型（在方法呼叫的後期繫結）、構件更換（允許載入時繫結）。

3.2.3 效能的場景描述以及策略

效能主要與時間有關，影響事件的響應時間有兩個基本因素：資源消耗，閉鎖時間（指事件處理碰到資源爭用、資源不可用或對其他計算的依賴等情況，產生的等待）。

針對性能要求主要有一下幾種應對策略：

資源需求
①減少處理事件流所需的資源：提高計算效率、減少計算開銷
②減少處理事件的數量：管理事件率、控制取樣頻率。
③控制資源的使用：限制執行時間（如減少迭代次數）、限制佇列大小

資源管理
引入併發：併發對負載平衡很重要
維持資料或計算的多個副本：C/S結構中客戶機C就是計算的副本，它能減少伺服器計算的壓力；快取記憶體可以存放資料副本。
增加可用資源：在成本允許時，儘量使用速度更快的處理器、記憶體和網路。

資源仲裁
資源仲裁是通過如下排程策略來實現的：
①先進先出FIFO
②固定優先順序排程
③動態優先順序排程，輪轉排程、時限時間最早優先
④靜態排程，離線確定排程

3.2.4 安全性的場景描述以及策略

針對安全性要求的策略主要包括：

1. 抵抗攻擊
   對使用者進行身份驗證：動態密碼、一次性密碼、數字證書、生物識別
   對使用者進行授權：即對使用者的訪問進行控制管理
   維護資料的機密性：一般通過對資料和通訊鏈路進行加密來實現
   維護完整性：對資料新增校驗或雜湊值；限制暴露的資訊
   限制訪問：如用防火牆、DMZ策略

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

從攻擊中恢復
恢復：與可用性中的戰術相同；
識別攻擊者：作為審計追蹤，用於預防性或懲罰性目的。

3.2.5 可測試性的場景描述以及策略

可測試性策略：

1. 輸入/輸出
   ①記錄/回放：指捕獲跨介面的資訊，並將其作為測試專用軟體的輸入；
   ②介面與實現分離：允許使用實現的替代（模擬器）來支援各種測試目的；
2. 內部監控
   當監視器處於啟用狀態時，記錄時間（如通過介面的資訊）。

3.2.6 易用性的場景描述以及策略

針對易用性要求的策略，主要包括：

1. 執行時策略
   任務模型：維護任務的資訊，使系統瞭解使用者試圖做什麼，並提供各種協助；
   使用者模型：維護使用者的資訊，例如使用以使用者可以閱讀頁面的速度滾動頁面
   系統的模型：維護系統的資訊，它確定了期望的系統行為，並向用戶提供反饋。

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

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

3.3 軟體體系架構——質量屬性分析

以《淘寶網》為例，描繪質量屬性的六個常見屬性場景，將上述整理為一篇部落格發表。

3.3.1 可用性分析

可用性分析所關注的方面包括：如何檢測系統故障，系統故障發生的頻度，出現故障時會發生什麼情況，允許系統有多長時間非正常執行，什麼時候可以安全地出現故障，如何防止故障的發生以及發生故障時要求進行哪種通知。
場景：雙十一或者春晚抽獎導致淘寶使用者猛增
刺激源：淘寶使用者
刺激：登入人數過多，導致淘寶無法響應，淘寶癱瘓，網頁無法向下進行
製品：淘寶的處理器、通訊通道、儲存器、程序
環境：使用者的正常瀏覽操作
響應：淘寶頁面呈現“網路出現故障，重新重新整理”等的提示資訊，提示使用者下一步操作
響應度量：系統降級模式下繼續執行，使用者重新整理頁面或者重新登入之後可繼續正常使用。

3.3.2 可修改性分析

可修改性是有關變更的成本問題。可以修改什麼（製品）和何時進行變更以及由誰進行變更（環境）。
場景：新年來臨，淘寶app要修改自己的系統頁面，並且新增一些其他的功能
刺激源：系統開發人員
刺激：系統介面要修改為新年主題，增加抽獎紅包等功能
製品：淘寶介面即抽獎領取紅包介面
環境：淘寶正常登入執行時
響應：針對頁面查詢構架中需要修改的位置，進行修改新增並且不影響其他功能，對修改進 行測試，部署所做修改
響應度量：系統人員後臺更新，測試部署成功自動更新，使用者登入即可

3.3.3 效能分析

效能與時間有關。事件（中斷、訊息、使用者請求或時間已到）發生時，系統必須做出響應。事件到達和相應有很多特性，但效能基本上與事件發生時，將要耗費系統多長時間做出響應有關。
場景：淘寶使用者購買商品
刺激源：淘寶使用者
刺激：購買商品
製品：系統生成訂單
環境：淘寶正常執行
響應：淘寶生成訂單，提示使用者進行支付，檢測網路環境
響應度量：在短時間內顯示商品狀態以及支付狀態，顯示交易的完成度

3.3.4 安全性分析

安全性是衡量系統在向合法使用者提供服務的同時，阻止非授權使用的能力。試圖突破安全防線的行為被稱為攻擊，它可以是未經授權試圖訪問資料或服務，或試圖修改資料，也可能是試圖使系統拒絕向合法使用者提供服務。

場景：一個通過身份驗證的人試圖從外部站點更改系統資料
刺激源：淘寶使用者
刺激：試圖從外部站點修改系統資料
製品：系統服務、系統中的資料
環境：線上連線有防火牆
響應：對使用者身份進行驗證，阻止其對資料的訪問
響應度量：短時間內稽核身份，拒絕其訪問，並限制系統可用性

3.3.5 可測試性分析

軟體可測試性是指通過測試揭示軟體缺陷的容易程度。
場景：單元測試人員測試商品瀏覽查詢模組
刺激源：單元測試人員
刺激：測試人員輸入商品關鍵詞，進行商品查詢
製品：商品搜尋模組的程式碼
環境：在開發時進行
響應：通過商品關鍵詞查詢，所檢索出的商品資訊呈列表顯示
響應度量：在較短的時間內完成對商品的檢索

3.3.6 易用性分析

易用性關注的是對使用者來說完成某個期望任務的容易程度和系統所提供的使用者支援的種類。
場景：使用者取消自己即將生成的交易
刺激源：淘寶使用者
刺激：使用者放棄自己的商品交易，選擇取消交易
製品：淘寶系統
環境：系統正常執行，使用者正常購買商品
響應：取消交易成功，淘寶系統刪除交易，恢復到以前頁面
響應度量：取消在一秒內發生，且不影響後序操作