2011年軟考系統架構設計師學習筆記第五章
軟件架構設計
Software Architecture 簡稱 SA
5.1.1 軟件架構設計與生命周期
1、需求分析階段
需求 和 SA設計 面臨的是不同的對象：一個是問題空間;另一個是解空間。保持二者的可跟蹤性和轉換。
2、設計階段
1.傳統的設計概念只包括 構件，隨著研究的深入，構件間的 互聯機制 逐漸獨立出來，成為與構件同等級別的實體，稱為 連接子。
2.體系結構描述語言(Architecture Description Language ADL)對 連接子 的重視成為區分 ADL和其他建模語言的重要特征之一。
3.不同的視角 得到多個視圖，組織起來以描述整體的SA模型;不同側面的視圖反映所關注的系統的特定方面，體現了關注點分離的思想。
3、實現階段
團隊的 結構 應該和體系結構模型有一定的對應關系，提高軟件開發 效率和質量。
分析和記錄 不同版本構件和連接子之間的演化。
填補高層 SA模型 和 底層實現 之間的鴻溝，典型的方法如下：
1.引入實現階段的概念。
2.SA模型 逐步精化。
3.封裝底層稱為較大粒度構件。
4、構件組裝階段
可復用構件 組裝 可以在較高層次上實現系統，研究內容包括：
1.如何互聯。
2.如何檢測并消除體系結構失配問題。
中間件跨平臺交互。
產品化的中間件更好地保證最終系統的質量，中間件導向的體系結構風格。
失配是指復用過程中，待復用構件對最終系統的體系結構和環境的架設(Assumption)與實際狀況下不同而導致的沖突。
5、部署階段
軟件構件的互聯性、硬件的拓撲結構、硬件資源占用。
6、后開發階段
實現中的軟件往往具有動態性，一類是軟件內部執行所導致的體系結構改變，另一類變化是軟件系統外部的請求對軟件進行的重配置。
升級或進行其他修改時 不能停機。
SA重建是指 從已實現的系統中 獲取體系結構的過程。
5.2 基于架構的軟件開發方法
5.2.1 體系結構的設計方法概述
基于體系結構的軟件設計(Architecture-Based Software Design ABSD)方法。
體系結構驅動，指 構成體系結構的 商業、質量、功能 需求的組合驅動。
設計活動的開始 并不意味著 需求抽取和分析活動 就可以終止，而應該 并行，快速開始設計 至關重要。
ABSD 方法有三個基礎，功能分解、選擇體系結構風格、軟件模板的使用。
5.2.2 概念與術語
1、設計元素
ABSD方法是一個 自頂向下，遞歸細化 的方法。
2、視角與視圖
重要的是從不同的視角(perspective)來檢查，考慮體系結構的不同屬性。
3、用例和質量場景
在使用用例捕獲功能需求時，通過定義特定場景來捕獲質量需求，稱為質量場景。捕獲變更、性能、可靠性、交互性，質量場景必須包括 預期的 和 非預期的。
5.2.3 體系結構需求
可以從需求庫中取出，加以利用和修改。
獲取需求，體系結構需求一般來自三個方面：系統的質量目標、系統的商業目標、開發人員的商業目標。
5.2.4 體系結構文檔化
體系結構規格說明 和 測試體系結構需求的質量設計說明書。
需求模型構件的 精確形式化描述，作為 用戶和開發者 之間的一個協約。
從使用者的角度進行編寫，必須保證開發者手上的文檔是最新的。
5.2.5 體系結構復審
根據架構設計，搭建一個可運行的最小化系統 用于 評估 和 測試 體系架構是否滿足需要。是否存在可識別的技術和協作風險。
復審的目的是 標識潛在風險，及早發現 缺陷和錯誤。
5.2.6 體系結構實現
分割成規定的構件，按規定方式互相交互。
5.3 軟件架構風格
體系結構設計 核心目標是 重復的體系結構模式，體系結構級的 軟件重用。
5.3.1 軟件架構風格概述
一個體系結構 定義 一個詞匯表 和 一組約束。詞匯表中包含 構件和連接件類型約束指出 如何 組合起來。
體系結構風格 反映了 共有的結構和語義特性，并指導如何 組織成一個完整的系統。
5.3.2 經典軟件體系結構風格
每個構件都有一組輸入和輸出，數據輸入構件，經過內部處理，然后產生數據輸出。這里的構件稱為 過濾器。
構件是對象。
分層系統，每一層為上層提供服務，并作為下層的客戶。除一些精心挑選的 輸出函數外，內部的層接口只對 相鄰層可見。由于一層最多只影響兩層，為軟件重用提供了強大的支持。
倉庫風格中，兩種不同的構件：中央數據結構、獨立構件。
若構件控制共享數據，則倉庫是一傳統型數據庫;若中央數據結構 的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
C2 體系結構 通過連接件綁定在一起 按照一組規則運作的并行構件網絡。構件與構件之間的連接是不允許的。
5.3.3 客戶/服務器 風格
宿主機應用程序 既負責與用戶的交互(前端)，又負責對數據的管理(后端)。
C/S 體系結構 定義了工作站如何與服務器相連，實現部分數據和應用 分布到多個處理機上。
C/S三個主要組成部分：服務器、客戶機、網絡。
易于對系統進行擴充和縮小。
功能構件充分隔離，客戶應用程序的開發集中于數據的顯示和分析，數據庫服務器的開發集中于數據的管理，將大應用處理任務分布到許多通過網絡連接的低成本計算機上，模型思想簡單。
開發成本高，尤其是軟件不斷升級，客戶端變得越來越臃腫。
信息內容和形式單一，用戶獲得的只是單純的字符和數字。
軟件移植困難，維護升級困難。
5.3.4 三層 C/S 結構風格。
三層 C/S 體系結構中，可以將 整個應用邏輯 駐留在應用服務器上，只有表示層存在于客戶機上，稱為“瘦客戶機”。表示層、功能層、數據層。
表示層一般要使用圖形用戶界面 GUI。
功能層之間的數據交互 要 盡可能簡潔，一次性傳輸。
數據層不同層構件 相互獨立，層間接口簡潔，適合復雜事務處理。
5.3.5 瀏覽器/服務器風格
瀏覽器/服務器 風格 就是 三層應用結構的一種實現方式。瀏覽器/web服務器/數據庫服務器。
系統安裝、修改、維護 全在服務器端解決。僅僅需要一個瀏覽器就可運行全部模塊。
B/S 體系結構還提供了 異種機、異種網、異種應用服務 的 連機、聯網 等。
擴展能力差。響應速度慢。交互性不強，不利于在線事務處理 OLTP。
5.4.1 特定領域軟件體系結構
主要目的 在一組相關的應用中 共享 體系結構。
DSSA的必備特征：
1、一個嚴格定義的 問題域 和 解域。
2、具有普遍性。
3、對整個領域的 構件 組織模型 其當抽象。
4、具備該領域 固定的、典型的 可重用元素。
5.4.2 DSSA 的基本活動
1、領域分析
主要目標是 獲得 領域模型，描述領域中 系統之間的共同需求，定義領域的邊界。從而明確分析的對象，識別信息源，確定哪些需求是領域中的系統廣泛共享的，從而建立領域模型。
2、領域設計
目標是獲得 DSSA，DSSA描述在領域模型中表示的需求 的解決方案。不是單個系統的表示，而是能夠適應領域中 多個系統的需求的 一個高層次設計。
3、領域實現
主要目標是 依據 領域模型 和 DSSA 開發和組織 可重用信息。領域模型 和 DSSA 定義了這些可重用信息的 重用時機。
以上過程是 反復的、逐漸求精 的過程。
5.4.3 參與 DSSA 的人員
4種角色：領域專家、領域分析師、領域設計人員、領域實現人員。
1、領域專家 可能包括 有經驗的用戶、從事該領域中系統的需求分析、設計、實現 以及項目管理的有經驗的軟件工程師等。
主要任務 提供 需求規約和實現的知識，組織規范的、一致的領域字典，選擇樣本系統，復審領域模型、DSSA。
應該 熟悉該領域 軟件設計和實現、硬件限制、未來的用戶需求、技術走向 等。
2、領域分析人員 應由 系統分析員來擔任。
知識獲取 組織到領域模型中，根據 現有系統、標準規范 等 驗證模型的 準確性 和 一致性。
應熟悉軟件重用和領域分析方法，具有一定的該領域經驗，較高的 抽象、關聯、類比 能力，較高的 交互合作能力。
3、領域設計人員 控制整個軟件設計過程，根據領域模型和現有系統 開發出DSSA，對DSSA的準確性和一致性進行驗證，建立領域模型和DSSA之間的聯系。
應熟悉軟件重用和領域設計方法，熟悉軟件設計方法，有一定的該領域經驗。
4、領域實現人員 根據領域模型和DSSA，從頭開發可重用構件，或 利用再工程技術 從現有系統中提取可重用構件。
5.4.4 DSSA 的建立過程
一般情況下，需要用 開發者習慣使用的工具和方法 建立DSSA模型。
DSSA建立過程分為5個階段，過程是 并發的、遞歸的、反復的，可能每個階段經歷幾遍，每次增加更多的細節。
1、定義領域范圍，一系列用戶的需求。
2、定義領域特定的元素，編譯領域字典、領馭屬于的同義詞詞典。
3、定義特定的設計和實現需求約束，不僅要識別出約束，并且要 記錄 約束對設計和實現 造成的后果，還要記錄對處理這些問題時所產生的所有問題的討論。
4、定義領域模型和體系結構，產生一般的體系結構，并說明構成它們的模塊或構件的語法、語義。
5、搜集可重用的產品單元，為DSSA增加構件。
5.5.1 系統架構的評估
評估 可以只針對一個體系結構，也可以針對一對一組體系結構。關注的是 質量屬性。
1、性能，是指系統的響應能力，多長時間 對某個事件做出響應，或者 某段時間內系統所能處理的事件的個數。
2、可靠性，是最重要的軟件特性，平均失效等待時間 MTTF，平均失效間隔時間 MTBF
1.容錯，內部修復。
2.健壯性，不受錯誤使用和錯誤輸入的影響。
3、可用性，正常運行的時間比例。經常用兩次故障之間的時間長度或恢復正常的速度來表示。
4、安全性，阻止非授權用戶。分為 機密性、完整性、不可否認性、可控性 等特性。
5、可修改性，通過考察 變更的代價 衡量可修改性。
1.可維護性，主要體現在問題修復上，做局部性的修改并能使對其他否見的負面影響最小化。
2.可擴展性，新特性來擴展軟件系統，改進版本來替換構件并刪除不需要的特性構件，需要松散耦合的構件。
3.結構重組，需要精心設計構件之間的關系。
4.可移植性。
6、功能性，完成所期望的工作 的能力。
7、可變性。
8、互操作性，精心設計的軟件入口。
5.5.2 評估中重要概念
敏感點 權衡點，是關鍵的體系結構決策。
敏感點是 構件(和/或 構建之間的關系)的特性。研究敏感點可使人員明確在實現質量目標時 應注意什么。
權衡點 是多個質量屬性的 敏感點。
風險承擔著 或稱為 收益相關人。
場景，首先要精確地得出具體的質量目標，為得出這些目標采用的機制叫做場景。從風險承擔者的角度與系統的交互的簡短描述。
刺激、環境、響應，三個方面描述場景。
5.5.3 主要評估方法
1、SAAM 非功能質量屬性的體系結構分析方法，是最早形式成文檔并得到廣泛使用的分析方法。最初它用于比較不同的軟件體系結構，以分析SA的可修改性。
1.特定目標，目標是對描述應用程序屬性的文檔，驗證假設和原則，有利于評估固有的風險。
2.評估技術，使用場景技術，描述了各種系統 必須支持的活動 和 將要發生的變化。
3.質量屬性，可修改性 是 SAAM分析的主要 質量屬性。
4.風險承擔者，SAAM 協調不同參與者所感興趣的方面，作為后續決策的基礎，提供了對系統結構的 公共理解。
5.體系結構描述，描述形式 應該被所有參與者理解。功能、結構、分配，三個主要方面。
6.方法活動，SAAM 的主要輸入問題是 描述、需求聲明、體系結構描述。
SAAM 分析評估 體系結構過程包括 5個 步驟：場景開發、體系結構描述、單個場景評估、場景交互、總體評估。
通過各類 風險承擔者協商討論，開發一些 任務場景，體現系統所支持的 各種活動。
通過對場景交互的分析，得出系統中所有場景對系統中構件所產生影響的列表。總體的 權衡 和 評價。
2、ATAM
體系結構權衡分析方法，主要針對 性能、實用性、安全性、可修改性。
確定多個質量屬性之間 這種 的必要性。
體系結構空間 受到 歷史遺留系統、互操作性 和 以前失敗的項目 約束。
邏輯視圖被分為 功能結構 和 代碼結構。這些結構加上他們之間適當的映射可以完整地描述一個體系結構。
用一組 消息順序圖 顯示運行時的 交互 和 場景。
從不同的體系結構角度，有三種不同場景，用例、增長場景、探測場景。
ATAM 使用定性的 啟發式分析方法 QAH，構造 精確分析模型時 要進行分析。
4個主要的活動領域(或階段)，場景和需求收集、結構視圖和場景實現、屬性模型構造和分析、分析、折中。
屬性分析是互相依賴的。獲得屬性交互的方法有兩種，敏感度分析來發現折中點、通過檢查假設。
迭代的改進。除了通常從場景派生而來的需求，還有很多對 行為模式和執行環境的 假設。
由于屬性之間存在折中，每一個架設都要被 檢查、驗證、提問，完成所有操作后，把分析的 結果和需求 進行對比。
領馭知識庫通過基于屬性的 體系結構風格ABAS 維護，變得更為慣例化、更可預測，得到一個標準問題集合。
【編輯推薦】
