一、 認識軟體架構

• 本書的主旨： 闡明企業目標、產品需求、設計師的經驗、構架和最終系統之間的關係——它們構成帶有迴路的、可由開發組織實施管理的週期
• 架構商業週期(ABC)： 軟體架構是技術、商業和社會等諸多因素作用的結果，而軟體架構的存在反過來又會影響技術、商業和社會環境，從而影響到未來的架構（從環境到架構又返回到環境）
• 架構也是若干商業和技術決策的結果

1. 軟體架構的概念

1. 定義：

是系統的一個或多個結構，他們由軟體元素、這些元素的外部可見屬性以及元件之間的關係組成，元件的外部可見性屬性是指其他元素對該元素所做的假設

從下面六個方面來理解：

• 軟體架構定義了軟體元素
• 系統可能由多個結構組成
• 每個軟體系統都有自己的架構
• 架構應建立在一定的設計原則之上
• 只要某個元件的行為可以從其它元件的角度觀察到或區別開，這樣的行為就是軟體架構的內容
• 軟體架構是抽象的，集中研究“黑盒”元件的行為和互動，是設計第一步

2. 其它觀點

• 軟體架構是高層次的設計
• 軟體架構是軟體系統的總體結構
• 構架是元件和聯結器
• 軟體架構是一個程式或系統的元件結構、元件之間的相互聯絡及管理其設計和演變的原則和方針的結構
• 軟體架構是具有一定形式的結構化元素，包括處理元素、資料元素和連線元素。處理元素負責對資料進行加工，資料元素是被加工的資訊，連線元素把架構的不同部分組合連線起來(Perry和Wo1f提出)
• 軟體體系結構是軟體設計過程中的一個層次
  ，這一層次超越計算過程中的演算法設計和資料結構設計(Mary Shaw和David Garlan)
• 軟體體系結構有四個角度(Kruchten)：
  • 概念角度描述系統的主要構件及它們之間的關係
  • 模組角度包含功能分解與層次結構
  • 執行角度描述了一個系統的動態結構
  • 程式碼角度描述了各種程式碼和庫函式在開發環境中的組織
    

2. 軟體架構的多個結構

P31 頁圖片（和PPT不一樣）：

1. 靜態的角度：

• 模組結構 —— 體現了任務的劃分，每個模組有其介面描述、程式碼和測試計劃等，各模組通過父子關係聯絡起來，在開發和維護階段用於分配任務和資源
• 分析類結構 ——子系統圖、包圖
• 類結構 —— 物件之間的繼承或例項關係

2. 動態的角度：

• 程序結構 —— 執行系統的動態特徵，包括程序間的同步關係、缺少不能執行、存在不能執行、先後等關係，與模組結構、概念結構成垂直正交關係
• 資料流 —— 模組之間可能傳送資料的關係，最適合用於系統需求的追蹤
• 控制流 —— 程式、模組或系統狀態之間的“之後啟用”的關係，適合於對系統功能行為和時序關係的驗證
• 使用結構 —— 描述過程或模組之間的聯絡，這種聯絡是“假設正確存在”的關係，用於設計可輕鬆擴充套件的系統。如果過程A的執行必須以過程B的正確執行為前提，則說過程A使用過程B
• 呼叫結構 ——（子）過程之間呼叫和被呼叫的關係，可用來跟蹤系統的執行過程
• 層次結構 —— 是一種特殊的使用結構，層就是相關功能的一致集合，在嚴格的分層結構中，第n層僅能使用第n-1層提供的服務

3. 部署的角度：

• 物理結構 —— 軟體與硬體之間的對映關係，在分散式或並行系統中有重要意義

各種結構間的相互關係

• 各個結構都是從不同角度考察系統，但它們並不完全獨立，它們之間的聯絡是多對多的
• 每個專案在開發時一般是注重一個結構，按照這一主要結構來考慮和運用其它結構
• 經驗表明，系統規模越大，結構之間的差異越明顯

3. 軟體架構的影響

1. 架構受系統涉眾的影響

涉眾就是對系統構建感興趣的人或組織

如：客戶、終端使用者、開發人員、專案經理、維護人員、對系統進行市場營銷活動的人

2. 不同客戶(開發組織)對軟體構架的影響

• 直接影響： 如直接進行商業投資，希望向產品線發展
• 長遠影響： 如行業佈局
• 組織結構的影響： 如軟體外包
• 間接影響： 開發組織的開發團隊的經驗對設計師有影響

3. 構架受設計師的素質和經驗的影響

4. 構架受技術環境的影響

5. 構架受設計的溝通能力的影響

設計師會受到產品需求（從涉眾獲得）、所在開發組織的結構和目標、可利用的技術環境及自身素質和經驗的影響

軟體架構的影響：（下圖）

4. 軟體架構對影響的反作用

軟體架構的商業週期：（下圖）

該商業週期的運作：

• 軟體架構影響開發組織的內部結構和經營目標
• 構架影響開發組織的目標
• 軟體架構可能會影響客戶對下個系統的需求
• 軟體架構的過程豐富了整個開發團隊的經驗，從而影響設計師對後繼系統的設計
• 有些系統甚至會影響並實際改變軟體工程的發展，以及開發人員學習和實踐的技術環境

5. 軟體過程

軟體過程：對軟體開發活動的組織、規範和管理

軟體過程中涉及的活動：

• **為系統構建商業案例：**問題的解決必須要有系統設計師的參與
• 理解系統需求： a. 要先了解已有系統的特性，b. 建立原型
• 建立或選擇構架： 概念完整性是成功設計系統的關鍵，只有通過以小組的形式共同設計系統構架才能真正實現概念完整性
• 構架的交流：
  • 開發人員必須理解構架對他們的要求
  • 測試人員必須清楚自己所面臨的任務
  • 管理層必須明確構架要求做出什麼樣的規劃
• 構架的分析和評審：
  • 基於質量屬性的評估：確保滿足該構架的系統滿足涉眾的需求
  • 基於場景技巧的評估：是對構架最有效、最通用的方法（如：ATAM）
• 實現基於構架的系統：
• **使構架符合原來的表述：**當架構建立完畢並投入使用後，開發就進入維護階段

6. 軟體架構的重要性

• 風險承擔者(涉眾)之間的交流： 有關各方可藉助它表達和協商各自的需求，並理性找到解決方案

• 早期設計決策

  • 構架明確了對系統實現的約束條件
  • 構架決定了開發組織的組織結構
  • 構架阻止或支援系統的質量屬性的實現
  • 通過研究構架來預測系統質量
  • 構架使推理判斷和控制更改更簡單
  • 構架有助於循序漸進的原型設計
  • 可以通過構架進行更準確的成本和進度估計

• 可傳遞、可重用的系統抽象

  • 產品線共享一個公共的構架

  • 系統開發可以使用大型的、由其他組織開發的元素

  • 少就是多：限制選擇範圍值得

    優點：重用程度更高、更易於理解和交流的簡單規範的設計、更為透徹的分析、更短的選擇時間、更強的可互操作性

  • 構架使基於模板的開發成為可能

  • 構架作為培訓的基礎

二、質量屬性

• 構架是實現質量需求的軟體建立中的第一個階段
• 構架是軟體功能到軟體結構的對映
• 軟體結構確定了構架對質量屬性的支援

1. 概念

軟體系統的質量屬性是指系統在整個生命週期中所具有的特徵

2. 需求分析與架構的關係

需求是架構設計的基礎，但在需求階段是無法弄清全部需求的，因此需求和架構設計之間的迭代是必要和有意義的

需求包括三要素

• 功能： 指系統能夠完成所期望的工作的能力（功能性和質量屬性是正交的）
• 質量
• 限制條件

3. 功能和架構的關係

功能是構架設計的必要條件，因為不同架構具有相同的功能，它們的差別在於質量

• 功能： 功能是指系統所能完成的工作

構架設計主要考慮如何滿足質量上的要求，但軟體構架會限制各模組的功能劃分，功能對架構設計有間接的影響

4. 構架和質量屬性的關係

質量屬性： 系統在其生命週期過程中所表現出的各種特徵

必須在從設計、實現、部署的整個過程中考慮質量屬性的實現

• 架構和質量屬性的關係
  • 架構是獲取許多質量屬性的基礎，即不能獨自實現質量屬性
  • 質量屬性既和架構有關，也和具體實現有關
• 質量屬性之間的關係
  • 一個質量屬性的獲取對其他質量屬性可能產生正面或負面的影響
  • 任何質量屬性都不可能在不考慮其他屬性情況下單獨獲取

5. 質量屬性及其場景描述

1. 質量屬性的類別

• 執行時可見屬性

  • 可用性： 系統正常執行時間的比例，是通過兩次故障之間的時間長度或在系統崩潰情況下能夠恢復正常執行的速度來衡量的

    可靠性是指系統能夠保持正常執行的能力，通常用平均無故障工作時間來衡量

    

  • 效能： 指系統的響應能力——即對外部刺激（事件）做出反應時所需要的時間或在某段時間內所處理的事件個數

    • 服務請求的到達速率
    • 處理時間
    • 佇列大小
    • 延遲時間長短

    

  • 安全性： 衡量系統在向合法使用者正常提供服務的情況下，阻止非授權使用和抗拒拒絕服務攻擊的能力

    

  • 易用性：

    • 可學習性
    • 可記憶性
    • 錯誤避免
    • 錯誤處理
    • 滿意度

    

• 維護時可見屬性

  • 可修改性： 進行快速修改並使修改代價儘可能低的能力，這種能力直接受到構架的限制

    • 涉及一個元件的修改
    • 涉及幾個元件的修改
    • 涉及整個構架的修改

    更改由於商業目的的變化：

    • 功能的擴充套件或改變
    • 刪除不需要的功能
    • 適應新的操作環境
    • 結構的重新調整

    

  • 可測試性： 指通過測試（通常是基於執行的測試）揭示軟體缺陷的容易程度

    可測試性：指假設軟體中至少有一個錯誤，軟體在”下次“測試執行時不能正常工作的可能性

    

  • 可移植性： 系統能夠在不同計算環境下執行的能力， 這裡所說的環境可能是硬體、軟體或兩者的組合

  • 可重用性：指要合理地設計系統，使系統的結構或其某些元件能夠在以後的應用開發中重複使用

  • 可整合性： 使獨立開發的系統元件能夠協同執行的能力

    可整合性表明了一個系統內各個元件之間相互協作的能力

    互操作性衡量的則是一個系統與另一個系統的協作能力

    • 元件的外部複雜性
    • 元件之間的互動機制和協議
    • 元件功能劃分的清晰程度
    • 元件介面的定義是否完整、合理

2. 質量屬性場景描述及場景圖

質量屬性場景就是通過對某個實體與系統的一次互動的簡要描述說明一個有關質量屬性的特定需求

• 刺激源：可以是風險承擔者、計算機系統等
• 刺激：可以看作是一個事件
• **環境：**系統當前的狀態
• **製品：**系統中對事件作出反應的部分，可以是整個系統或系統的某一部分
• **反應：**事件到達後系統的相關行為
• **反應度量：**對反應結果提供某種形式的衡量

生成質量屬性場景的目的和意義：

• 幫助構架師生成有意義的質量屬性需求
• 使質量屬性需求的描述規範化
• 某一場景是一類場景的代表，系統將以完全相同的方式對這些場景做出反應

質量場景建立的參與人員：

• 負責軟體執行的人員—— 終端使用者
• 負責管理系統的人員—— 系統管理員
• 負責更改系統執行時功能的人員—— 維護人員
• 負責系統規劃的單位 —— 客戶
• 負責專案實施的單位 —— 開發組織

5. 限制條件

• 商業限制（構架的商業屬性）：
  • 投放市場時間
  • 成本和收益
  • 預計的系統生命週期的長短
  • 目標市場
  • 推出計劃
  • 遺留系統整合
• 技術限制
• 法律限制
• 社會限制

6. 架構本身的質量屬性

• 一致性（概念完整性）：

  • 構架應該以類似的方式做類似的事情
  • 邁向一致性的最重要一步是有一個系統構架師

• **正確性和完整性：**構架能夠滿足系統的各種需求及執行時的資源要求

• **可構建性：**保證能夠由指定的開發小組在規定時間完成，並允許在開發過程中做某些更改

  指的是構建某個所期望的系統難易程度

7. 構架的商業屬性

• 上市時間
• 成本和收益
• 所希望的系統生命週期的長短
• 目標市場
• 推出計劃
• 與老系統的整合

三、軟體架構的樣式與框架

• 樣式即模式

1. 軟體架構樣式的概念

是對各元件型別和執行控制/資料傳送模式的描述

從四個方面理解構架樣式：

• 一組在系統執行時執行一定功能的元件型別
• 能夠表明在系統執行時元件的相互關係的拓撲結構
• 一組語義約束條件的集合
• 一組連線件的集合，這些連線件為元件之間的通訊提供中介

2. 軟體架構樣式的種類

1. 以資料為中心的樣式

• 優點： 客戶端相對獨立
• 缺點： 資料中心的效能要高，響應速度要快，並且要有災難備份等

2. 資料流樣式

• 目標 是實現可重用性和可更改性
• 特點 是把系統看作是對相繼輸入資料的一系列變換

• 成批順序式：順序執行，各個步驟之間，資料是作為一個整體傳送
• 管道—過濾式 ：管道負責資料傳遞，過濾器對資料進行漸進的轉換

3. 虛擬機器樣式

目標是實現可移植性

4. 呼叫–返回樣式

• 大型軟體系統的主流構架樣式
• 目標是實現系統的可更改性和可擴充套件性

• 主程式-子程式構架
• 遠過程呼叫構架
• 面向物件構架
• 分層構架

5. 獨立元件樣式

通過解除各運算部分之間的耦合實現可更改性

• 事件系統樣式
• 通訊程序樣式

6. C/S樣式

• 二層C/S結構：

  侷限：

  • 二層C/S結構是單一伺服器且以區域網為中心的，所以難以擴充套件至大型企業廣域網或Internet
  • 軟、硬體的組合及整合能力有限
  • 伺服器的負荷太重，難以管理大量的客戶機，系統的效能容易變壞
  • 資料安全性不好

• 三層C/S結構：

  • 表示層： 使用者介面部分
  • 業務層： 應用的本體
  • 資料層： 資料庫管理系統，負責管理對資料庫資料的讀寫

  優點：

  • 允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統的可維護性和可擴充套件性
  • 允許更靈活有效地選用相應的軟硬體平臺，使之在處理能力和處理特性上分別適應於結構清晰的三層；並且這些平臺和各個組成部分可以具有良好的可升級性和開放性
  • 三層C/S結構中，各層可以並行開發，可以選擇各自最適合的開發語言，維護也會更容易些
  • 允許充分利用業務層有效地隔離開表示層與資料層，未授權的使用者難以繞過業務層而利用資料庫工具或黑客手段去非法地訪問資料層，這就為嚴格的安全管理奠定了堅實的基礎；整個系統的管理層次也更加合理和可控制

7. C2樣式

基於構件和訊息的體系結構模式，用於構建靈活的、可伸縮的軟體系統

• 設計規則： 構件和連線件

  • 構件的“頂域”與連線件的“底域”相連線
  • 構件的“底域”與連線件的“頂域”相連線
  • 對連線到某一個連線件上的構件數量沒有限制，但構件與構件之間不能直接相連

• **通訊規則： ** 所有構件間的通訊必須通過訊息來實現

• 最重要的特徵： 底層無關性，以連線件為中介的非同步訊息交換機制來實現

• **體系結構風格： ** 通過連線件繫結在一起的按照一組規則運作的並行構件網路

• 特點：

  • 系統中的構件可實現應用需求，並能將任意複雜度的功能封裝在一起
  • 所有構件之間的通訊是通過以連線件為中介的非同步訊息交換機制來實現的
  • 構件相對獨立，構件之間依賴性較少，系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制執行緒之類的相關性假設

8. 正交體系結構

由層和線索的構件構成

• 層： 是由一組具有相同抽象級別的構件構成
• 線索： 是子系統的特例，它是由完成不同層次功能的構件組成（通過相互呼叫來關聯），每一條線索完成整個系統中相對獨立的一部分功能

主要特徵：

• 正交軟體體系結構由完成不同功能的n（n > 1）個線索（子系統）組成
• 系統具有m（m > 1）個不同抽象級別的層
• 線索之間是相互獨立的（正交的）
• 系統有一個公共驅動層（一般為最高層）和公共資料結構（一般為最低層）

優點：

• 結構清晰，易於理解
• 易修改，可維護性強
• 可移植性強，重用粒度大

9. 構架的異質性

• 區域性異質
• 層次異質
• 並行異質

3. 構架模式、參考模型與參考構架

• 構架模式 —— 是對元素和關係型別以及一組對其使用方式的限制的描述
• 參考模型 —— 是一種考慮資料流的功能劃分，是對已知問題的標準分解，分解所得的各個部分相互協作，構成問題的解決方案
• 參考構架 —— 是對映到軟體元件及元件之間資料流上的參考模型 ，即將功能劃分與系統分解對應起來，這種對應不一定是一一對映

構架模式，參考模型和參考構架都不是構架，但都是早期設計決策的產物，都對構架設計有幫助

4. 軟體架構、框架和設計模式

• 定義： 軟體框架是提取特定領域軟體的共性部分形成的體系結構，不同領域的軟體專案有著不同的框架型別
• 作用： 開發過程中程式碼不需要從頭編寫，提高軟體的質量，降低成本，縮短開發時間，形成良性迴圈

1. 框架和平臺的關係：

• 平臺在應用層面主要指提供特定服務的系統軟體
• 框架更側重設計和開發過程，框架可通過呼叫平臺提供的服務而起的作用

2. 框架和類庫的關係：

• 框架構成了通用的、具有一般性的系統主體部分
• 二次開發人員根據具體業務，完成特定應用系統中與眾不同的特殊部分

3. 框架和架構的關係：

• 構架確定了系統整體結構、層次劃分、不同部分之間的協作等設計考慮
• 框架更偏重於技術，確定框架後，其所對應的架構也隨之確定，但在一個系統架構中可以整合多種框架

4. 框架和設計模式的關係：

• 設計模式研究的是一個設計問題的解決方法，一個模式可應用於不同的框架和被不同的語言所實現
• 框架則是一個應用的體系結構，是一種或多種設計模式和程式碼的混合體

共性： 共同致力於使人們的設計可以被重用（計模式的思想可以在框架設計中進行應用）

區別：

• 從應用領域上分，框架給出的是整個應用的體系結構；而設計模式則給出了單一設計問題的解決方案
• 從內容上分，設計模式僅是一個單純的設計；而框架則是設計和程式碼的一個混合體
• 設計模式比框架更容易移植

四、實現質量屬性的戰術

1. 戰術介紹

• 戰術是對質量屬性的控制產生影響的設計決策
• 架構策略是架構中所採用的戰術的集合

特點：

• 根據一種戰術可以求精其他戰術，並可以組織成層次的形式
• 模式可以把戰術打包，如冗餘戰術通常還會使用同步戰術

2. 可用性的戰術

1. 錯誤檢測

• 砰/回聲
• 心跳
• 異常

砰/回聲和心跳戰術用來檢測另一個程序的錯誤，異常是程序本身的錯誤處理

2. 錯誤恢復

• 表決
• 主動冗餘
• 被動冗餘
• 備件
• shadow操作
• Windows的安全模式
• 狀態再同步
• 檢查點/回滾

3. 錯誤預防

• 程序監視器
• 從服務中刪除
• 事務

3. 可修改性的戰術

1. 區域性化修改

是在設計期間為模組分配責任，以把預期的變更限制在一定的範圍內，以降低修改成本

• 維持語義的一致性
• 預期期望的變更
• 泛化模組
• 限制可能的選擇

2. 防止連鎖反應

修改沒有直接影響到的模組也需要改變，這是由於模組間存在依賴關係

依賴關係有：

• 語法
• 語義
• 順序

防止連鎖反應的戰術有：

• 資訊隱藏
• 維持現有的介面
• 新增介面
• 新增介面卡
• 提供一個佔位程式A

3. 推遲繫結時間

可以允許非開發人員進行修改，也可以延遲部署時間

• 執行時註冊 —— 支援即插即用
• 配置檔案 —— 啟動時設定引數
• 多型 —— 允許方法呼叫的後期繫結
• 元件更換 —— 允許載入時間繫結
• 遵守已定義的協議 —— 允許獨立程序的執行時繫結

4. 效能的戰術

1. 影響響應時間的兩個基本因素

• 資源消耗
• 阻塞時間
  • 資源爭用
  • 資源的可用性
  • 對其他計算的依賴性

2. 控制對資源需求

• 減少處理一個事件所需要的資源：
  • 提高計算效率
  • 減少計算開銷
• 減少需要同時處理事件的數量：
  • 管理事件率
  • 控制取樣頻率
• 控制資源的使用：
  • 限制執行時間
  • 限制佇列的大小

3. 資源管理

• 引入併發
• 維持資料或計算的多個副本
• 增加可用資源

4. 資源仲裁

• 先進/先出
• 固定優先順序
  • 語義重要性
  • 時限時間單調
  • 速率單調
• 動態優先順序排程
  • 輪轉
  • 時限時間最早優先
• 靜態排程

5. 安全性的戰術

1. 抵抗攻擊

• 對使用者進行身份驗證
• 對使用者進行授權
• 維護資料的機密性
• 維護完整性
• 限制暴露的資訊
• 限制訪問
• 在外部使用者和提供服務的系統之間設定認證伺服器
• 把要保護的系統置於通訊防火牆之後
• 在某個可信核心的基礎上構建系統，由該核心提供安全

2. 檢測攻擊

• 誤用情況的檢測是把通訊模式與已知攻擊的歷史模式進行比較
• 異常情況的檢測是把通訊模式與其本身的歷史基線（情況）進行比較

3. 從攻擊中恢復

• 恢復狀態
• 識別攻擊者

6. 易用性戰術

1. 執行時戰術

• 維持任務的一個模型
• 維持使用者的一個模型
• 維持系統的一個模型

2. 設計時戰術

將使用者介面與應用的其餘部分分離開來

• 模型-檢視-控制器
• 表示-抽象-控制
• Seeheim
• Arch/Slinky

7. 軟體架構樣式與戰術的關係

• 軟體架構樣式從戰略層面解決質量問題
• 戰術是從具體部署上給出解決質量問題的區域性策略

8. 戰術舉例

採用戰術	敏感點	有風險決策
超出限制訪問量的請求放在等待佇列中	提高了系統的穩定性和可用性，減少了崩潰的可能	會降低對打併發數目，使得使用者的等待時間過長，可能造成使用者不滿
快取	提高系統的訪問速度和效能	單伺服器提供的快取數目有限，併發使用者數多的情況下，系統處理緩慢
每個IP每次只允許發出一個請求	合理的要求，避免了非法使用者的惡意攻擊	可能降低了易用性，但系統的安全性提高了
資料庫連線池	資料庫連線池允許應用程式重複使用一個現有的資料庫連線，而不是重新建立一個，提高應用系統的效能
容錯性	能夠對使用者出現的誤操作進行檢測和處理，並給出相應的處理資訊，提高系統的可用性
系統備份與恢復	增強系統的容錯能力	作業系統和資料庫軟體發生崩潰時，恢復時間較長

五、設計構架

1. 構架的設計

1. 基於構架的開發步驟：

• 為軟體系統構建一個商業案例
• 弄清系統需求
• 構建或選用構架
• 正確表述此構架，並與有關各方進行交流
• 對此構架進行分析和評價
• 實現基於構架的系統並保證與構架相一致
• 系統維護時，構架文件應同步維護

2. 何時開始設計：

對需求有初步瞭解就可以開始設計

3. 構架驅動因素的組成：

比較重要的功能、質量屬性、商業屬性

4. 如何確定構架驅動因素：

業務目標優先順序較高的要求

2. 良好架構的評判原則

1. 設計構架過程的建議：

• 構架的設計應該由一位設計師來完成，或在某位設計師領導下的小組來完成
• 設計師應全面掌握對系統的技術需求，以及對各項定性指標優先順序的清單
• 構架的文件完備，至少有一個靜態檢視和動態檢視，並採用所有人員認可的文件形式
• 構架設計方案應讓各風險承擔者積極參與評估
• 通過對構架分析，得出明確的定性與定量指標
• 構架設計應有助於增量式實現
• 允許構架帶來一定的資源爭用，並給出可行的解決方案

2. 構架結構的建議：

• 構架由定義良好的模組組成
• 模組的劃分應體現出資訊隱藏和相互獨立的原則
• 採用特定於每個屬性的眾所周知的構架戰術來實現質量屬性
• 構架不依賴於某個特定版本的商用產品或工具
• 產生資料的模組和使用資料的模組分離
• 對併發系統，構架應採用定義良好的程序或任務
• 任務或程序編寫要考慮到與特定處理器的關係，並容易改變關係
• 構架應採用少量的、簡單的設計模式

3. 屬性驅動的設計(ADD)

屬性驅動的設計(Attribute Driven Design, ADD)把一組質量屬性場景作為輸入，利用對質量屬性實現與構架設計之間的關係的瞭解，對構架進行設計

ADD構架設計的步驟如下：

• 樣本輸入
• 選擇要分解的模組
• 根據下列步驟對模組進行求精：
  • 從具體的質量場景和功能需求集合中選擇構架驅動因素
  • 選擇滿足構架驅動因素的構架模式
  • 例項化模組並根據用例分配功能，使用多個檢視進行表示
  • 定義子模組的介面
  • 驗證用例和質量場景並對其進行求精，使它們成為子模組的限制
• 對需要進一步分解的每個模組重複上述步驟

4. 建立骨架系統

建立骨架系統的思想是提供一種基本能力，以一種對專案有力的順序實現系統的功能

1. 原因：

• 提高開發效率，鼓舞士氣
• 能更早發現複雜的依賴關係
• 使開發人員更多關注在設想中最難以實現的部分
• 能夠縮短系統整合時間，降低其成本，並使整合成本更明確
• 便於評審和測試

2. 步驟：

• 實現處理構架元件的執行和互動的軟體部分
• 實現規則引擎（帶有規則的原型集）以控制在基於規則的系統中規則的激發
• 逐步進行測試

5. 團隊結構的形成

• 開發小組的結構反映了構架的模組結構
• 開發小組要做到鬆耦合，高內聚
• 開發組織對構架也會有影響

6. 架構師的職責

• 瞭解所在組織的業務目標，使架構更好地支援業務目標
• 規劃產品的開發與演進
• 規劃和建設架構級的重用，如產品線等
• 領導並負責架構設計，定義系統的高層結構和介面
• 為專案管理提供支援，如技術可行性、任務劃分、人員招聘
• 領導和協調專案組的主要技術活動，對主要技術產品負責實際參與架構原型的開發實現
• 講解架構、指導詳細設計和開發、協調衝突以實現既定的構架目標
• 規劃和協助軟體架構的評審
• 評估新技術並提出採用建議

六、構架評審的一般方法

1. 成本與收益

1. 成本

• 人員時間成本
• 構架評審部門的組織開銷構
• 架評審部門要求高階設計人員參與的代價

2. 收益(優點)

• 及早發現現有構架中存在的問題
• 構架的改進
• 財務收益
• 強制為評審做準備
• 捕獲構架設計的基本思想
• 驗證需求的有效性

2. 評審的一般技巧

1. 定性分析

是指憑分析者的直覺、經驗，憑分析物件過去和現在的延續狀況及最新的資訊資料，對分析物件的性質、特點、發展變化規律作出判斷的一種方法

定性技巧——提問技巧

• 場景—描述風險承擔者和系統之間的具體互動
• 評審清單—對同一領域的若干系統進行評估後提出的一組詳細的問題
• 問卷—適用於所有構架的若干問題的清單

2. 定量分析

是依據實際統計資料，建立數學模型，並用數學模型計算出分析物件的各項指標及其數值的一種方法

定量技巧

• 指標—對構架可觀察到的引數的量化解釋
• 模擬、原型與實驗

3. 評審實踐

1. 評審前提

• 評審環境—預先規劃
• 專案代表—風險承擔者，子系統或元件負責人
• 評審小組
  • 評審小組的人員公證、客觀、受尊重
  • 成員必須專門從事評審工作
  • 有對構架相關問題熟悉的人，其領導具有設計、評價經驗
  • 至少有一位該系統所屬領域的專家
  • 有專人負責文件、後勤，辦公地點離評審物件近，有學徒
• 組織的期望—用合同明確
  • 構架評審結束時應向誰報告什麼內容
  • 評審的標準是什麼
  • 向評審小組提供那些資源及人力
  • 對評審小組和專案組以後的工作有什麼期望
  • 預計評審持續的最長時間
• 評審的準備—制定評審日程
  • 系統需求文件
  • 架構文件，包括架構描述及介紹構架決策思想的材料
  • 將系統的質量屬性和功能要求按重要程度排序出前面3-5個

2. 評審實施

• 按問題的重要性進行分類
• 強調那些與構架相符或相悖的重要問題
• 必須記載評審中所提的每個問題

3. 評審結果

• 對評審中的各個問題都要做出正式的闡述，同時也要對賴以確定這些問題的資料做出相應的說明

4. 總結

構架評審的主要指導原則如下：

• 把由獨立部門實施的正規的構架評審作為專案開發週期規劃的一部分
• 選擇評審的最佳時間，儘早預審一次
• 選擇恰當的評審技巧
• 簽署評審合同
• 限制所要評審的質量屬性的個數
• 要保證評審小組中有構架方面的專家、領域專家、資料員及後勤員
• 一定要有系統設計師
• 收集各種場景資料，並在此基礎上形成評審清單

5. 評審（分析）軟體架構的原因

• 架構師風險承擔者交流的平臺、是早期設計決策的體現、是可傳遞的系統抽象（架構級重用）
• 系統的質量屬性不可能在系統實現的最後階段追加上去，必須在設計之初就考慮到

七、架構權衡分析法(ATAM)

• 目標：

  • 用於獲取系統以及構架的業務目標
  • 用於使用這些目標和涉眾參與來使評估人員把注意力放到對實現這些目標重要的構架部分上

• 特點是不僅可以揭示出構架滿足特定質量目標的情況，而且可以使我們更清楚地認識到質量目標之間的聯絡

• 中心問題是對用於構架評估的有限時間進行管理

1. ATAM的參與人員

• **評估小組：**通常由3-5人組成，每個人要扮演多個角色
• **專案決策人 ：**客戶、專案管理人員、委託進行評審的人
• 構架風險承擔者（構架涉眾）

2. ATAM的結果

1. 輸入——用場景集合捕獲的質量要求

2. 輸出——粗糙的評價

• 一個簡潔的構架表述
• 表述清楚的業務目標
• 構架決策到質量需求的對映
• 所確定的敏感點和權衡點集合
• 有風險決策和無風險決策
• 風險主題的集合

3. ATAM的階段

1. 活動階段

• **第0階段（合作關係和準備）：**評估小組和專案決策者共同確定評估細節
• **第1階段（評估階段）：**評估小組收集資訊和分析
• **第2階段（評估階段）：**風險承擔者參與評估
• **第3階段（後續階段）：**評估小組自我檢查和改進，提交書面報告

2. 分析評估階段(ATAM 方法)

• ATAM方法的表述

• 商業動機的表述

  • 系統最重要的功能
  • 任何相關的技術、管理、經濟和政治限制
  • 與該專案相關的商業目標和上下文
  • 主要的涉眾
  • 構架的驅動因素

• 構架的表述

  • 祥略適當，在有限時間內傳達構架的本質
  • 技術約束條件

• 對構架方法進行分類

• 說明構架中涉及的樣式和戰術對質量的影響

• 生成質量屬性效用樹

• 效用樹的作用是使質量屬性需求具體化，從而迫使設計師和客戶代表準確地定義出他們的質量需求

• “效用”是效用樹的根結點，表示系統的總體適宜性

• 中間結點是質量屬性及其求精

• 葉結點是與質量屬性對應的場景

屬性效用樹：

質量屬性	屬性求精	場景
安全性	訪問的安全性	在web服務中，應該有防火牆保護，防止網路上的非法資料請求**( M, H )**
安全性	資料的完整性	當出現異地訂票點同時需要對通一張票請求操作時，系統必須保證資料庫內資料的完整性**(H, L)**
可用性	異常檢測和丟擲	使用者企圖輸入不符合系統條件的查詢或者訂購不存在的票務的時候，系統必須檢測出，並且丟擲相應的異常，轉入掛起操作
可修改性	資訊管理	為了適應變化得票務資料，系統必須提供一個後臺管理介面**( M, L )**
效能	等待時間	使用者在介面上進行票務查詢或者進行訂購操作的時候，系統必須在規定的時間內做出反應，不能出現使用者無故長時間等待的情況。( H, M )

• 分析構架方法

• 集體討論並確定場景優先順序

• 再次分析構架方法

• 結果的表述

3. 有效利用有限的評估時間

• 業務目標被作為收集效用樹場景的動機
• 劃分場景優先順序
• 自頂向下生成效用樹場景，自底向上進行分析
• 僅分析優先順序高和較難實現的場景

八、架構文件的寫作

1. 架構編檔的使用

最渴望使用架構文件的人是設計師

• **構架編檔的目的與作用：**讓不同的風險承擔者都能快速找到和理解他們所需要的資訊
• 構架文件寫作的基本規則是： 就是從讀者的角度出發

2. 選擇相關檢視

選擇專案檢視的過程：

• 產生一個候選檢視列表
• 組合檢視
• 劃分優先順序

3. 檢視編檔

1. 文件通常包括七部分內容

• 展示檢視中的元件和元件之間關係的主要表示****，常用圖形方式
• 元件目錄祥述在元件和元件之間的相互關係，還包括元件的介面和行為
• 系統與其環境相關的上下文圖
• 可變性指南
  • 要在其中做出選擇的選項
  • 做出選擇的時間
• 解釋檢視設計的構架背景，包括：
  • 基本原理
  • 分析結果
  • 設計中所反映的假定
• 檢視中所選擇的術語表
• 其他資訊，取決於組織的標準實現

2. 對行為進行編檔

• 結構僅提供了系統的組成資訊
• 行為描述可以提供元素間的互動順序、併發機會以及互動的時間依賴性的資訊
• 在UML中，順序圖和狀態圖用於行為描述

3. 對介面進行編檔

• 介面就是兩個獨立的實體相遇並進行互動或通訊的邊界
• 元件介面就是其他元件可對該元件所做的假設

• 介面身份
• 所提供的資源
  • 資源語法：資源的簽名，包括資源名、引數的名稱和邏輯資料型別
  • 資源語義：描述了呼叫該資源的結果
  • 資源使用限制
• 資料型別定義
• 異常定義
• 該介面提供的可變性
• 介面的質量屬性特徵
• 基本原理和設計問題
• 使用指南

4. 跨檢視的文件

1. 構架概述

• 系統概述
• 結檢視之間的對映
• 元件列表
• 專案詞彙

2. 構架基本原理

• 關於滿足需求或滿足限制條件的系統範圍內設計決策的含義
• 預計可能的修改對構架的影響
• 在實現解決方案中對開發人員的限制
• 拒絕採用的決策方案

3. 文件組織

• 結檢視目錄
  • 檢視的名稱和它說明的樣式
  • 檢視中的元件型別、關係型別和屬性的描述
  • 檢視目的的描述
  • 檢視文件的管理資訊
• 結檢視模板： 是檢視的標準組織結構