软件体系结构
目錄
- 前言
- 概述
- 軟件重用
- 可重用的元素
- 構件
- 構件模型（規模——越大越好？越小越好？）
- 構件獲取
- 可重用技術和領域之間的關系
- 構件管理
- 軟件體系結構
- 軟件體系結構的反作用
- 軟件體系結構的商業周期
- 軟件體系結構建模
- 4+1模型視圖
- 邏輯視圖（靜態）
- 開發視圖（靜態）
- 進程視圖（動態）
- 物理視圖（動態）
- 場景
- 軟件體系結構的生命周期
- 軟件體系結構設計核心模型
- 構件
- 構件之間的關系
- 連接件
- 配置
- 軟件體系結構
- 軟件體系結構風格
- 管道過濾器風格
- 數據抽象和面向對象組織
- 事件驅動風格
- 分層系統
- 倉庫系統及知識庫
- 黑板系統
- C2（層次網絡+消息驅動）
- 全局軟件體系結構
- C/S結構
- 三層C/S結構
- CORBA（公共對象請求代理）
- 正交體系結構
- 層次消息總線（HMB）
- 接口
- 消息總線
- 構件靜態結構
- 構件的動態行為
- 異構結構風格
- 內外有別
- 查改有別
- 互聯系統構成的系統
- 軟件體系結構評估
- 軟件體系結構的質量屬性
- 性能（*）
- 可靠性（*）
- 可用性（*）
- 安全性（*）
- 可修改性（*）
- 功能性
- 可變性
- 集成性
- 互操作性
- 基本概念
- 基于場景的評估方式（ATAM）
- 描述ATAM方法
- 描述業務動機
- 描述體系結構
- 確定體系結構方法
- 生成質量屬性效用樹
- 分析體系結構描述方法
- 討論和分級場景
- 分析體系結構方法
- 描述評估結果
- 基于度量的評估方式（SAAM）
- 形成場景
- 描述體系結構
- 對場景進行分類和確定優先級
- 對間接場景的單個評估
- 評估場景的相互作用
- 形成總體評估
- 基于體系結構的軟件設計方法（ABSD）
- ABSD方法定義的設計元素
- 設計元素的產生順序
- 設計元素的活動
- 基于體系結構的軟件開發模型
- 體系結構需求
- 體系結構設計
- 體系結構文檔化
- 體系結構復審
- 體系結構實現
- 體系結構演化
前言
按照慣例，在這里寫下我對軟件體系結構的一點理解和認識
軟件工程是一門研究利用工程化的方法，構建維護有效的實用的高質量的軟件的學科，東北林業大學軟件工程專業核心課，就是按照軟件生命周期的課來安排的，將每一個生命周期中的過程都抽象成一門課來給學生講解，軟件體系結構這門課是繼需求分析和系統分析之后的一門課
需求分析教會了我們如何進行需求獲取、需求分析和需求驗證，最后形成需求規格說明書，系統分析教會了我們如何抽象出合理的類圖，而軟件體系結構講的是如何把類抽象成構件以及如何合理的安排這些構件（或者類）
概述
軟件重用
在兩次或多次開發的過程中，重復使用相同或相近的元素的過程
可重用的元素
- 代碼
- 設計文檔
- 測試用例
- 需求分析文檔
- 框架
- 設計過程
- 領域知識
構件
- 語義完整、語法正確、有可重用價值的單位軟件
- 是軟件重用過程中可明確辨識的系統
- 結構上是語義描述、通信接口和實現代碼的復合體
構件模型（規模——越大越好？越小越好？）
青鳥模型：外部接口+內部接口
構件獲取
- 開發新的構件
- 購買
- 從歷史遺留工程中提取
- 去構件庫中查找需要的構件
- 由現有構件做適應性修改
可重用技術和領域之間的關系
領域具有內聚性和穩定性——前提
可重用信息具有領域特定性——約束
構件管理
對大量的構件進行有效的管理，方便構建的存儲、檢索和提取
構件的描述；名稱、功能、參考函數、版本號等
關鍵詞法
優點：簡單易行
缺點：不便于查詢
刻面法
優點：方便查找相似構件
缺點：查詢程序太難做
超文本法
優點：操作人性化
缺點：容易差跑題了
軟件體系結構
軟件體系結構為軟件系統提供了一個結構、行為和屬性的高級抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素集成的模式以及這些模式的約束組成。
軟件體系結構不僅指定了系統的組織結構和拓撲結構，并且顯示了系統需求和構成系統的元素之間的對應關系，提供了一些設計決策的基本原理。
軟件體系結構的反作用
- 影響開發組織結構
- 影響開發組織目標
- 影響客戶對下一個系統的要求
- 構建過程中豐富團隊經驗，影響后續設計
- 改變行業人員學習和實踐的技術環境
軟件體系結構的商業周期
軟件體系結構建模
軟件體系結構的建立應位于需求分析之后，軟件設計之前，在建立軟件體系結構時，設計師主要從結構的角度對整個系統進行分析，選擇恰當的構件、構件間的相互作用以及他們的約束，最后形成一個系統框架以滿足用戶的需求，為軟件設計奠定基礎。
4+1模型視圖
每個視圖只關心系統的一個側面，結合在一起才能反映系統的軟件體系結構的全部內容
在每個視圖上均獨立地應Perry & Wolf 的公式，即定義一個所使用的元素集合（構件、容器、連接件）
邏輯視圖（靜態）
主要是整個系統的抽象結構表述
關注系統提供最終用戶的功能
不涉及具體的編譯即輸出和部署
通常用BOOCH標記法，或在UML中用類圖表示
開發視圖（靜態）
主要側重軟件模塊的組織和管理，為編程人員服務
軟件可以通過程序庫或子程序進行組織，從而可以由不同的人員進行開發
主要考慮軟件內部需求，要充分考慮軟件開發的容易程度，重用性，軟件的通用性，充分考慮由于具體開發工具不同而帶來的局限性。
- 常用層次風格
- 采用4-6層子系統
- 僅進行相鄰交互
- 層次越低，通用性應越強
進程視圖（動態）
側重系統的運行特性
關注非功能需求（性能、可用性、并發性）
定義邏輯視圖中的各個類的操作是在哪一個線程中被執行
可以描述成多層抽象
每個級別分別關注不同的方面
最高層抽象中：進程結構＝構成一個執行單元的一組任務 | 獨立、分布 | 通過邏輯網絡相互通信
物理視圖（動態）
如何把軟件映射到硬件上
關注系統性能、規模、可靠性等
場景
重要系統活動的抽象
最重要的需求抽象
聯系4個視圖
軟件體系結構的生命周期
需求分析階段
體系結構需求包括需求獲取、生成類圖、對類分組、將類打包成構件和需求評審等過程。
建立軟件體系結構階段
選擇合適的體系結構風格，把體系結構需求階段已確認的構件映射到體系結構中，產生一個中間結構，分析構件之間的相互作用和關系，對中間結構進行細化。
設計階段
主要是對系統進行模塊化并決定描述各個構件間的詳細接口、算法和數據類型的選定，對上支持建立體系結構階段形成的框架，對下提供實現基礎。
實現階段
設計階段設計的算法及數據類型進行程序語言表示，滿足設計體系結構和需求分析的要求，從而得到滿足設計需求的目標系統。
軟件體系結構設計核心模型
構件
構件定義：構件是一個數據單元或一個計算單元，它由構件的對象的集合、屬性的集合、動作的集合和端口的集合組成。
抽象表示為C = （O,A,X,P），
O 是構件的所有對象的集合；
A 是構件屬性的集合；
X 是構件動作的集合；
P 是構件端口的集合。
構件是具有某種功能的可重用的軟件模版單元
從其內容角度看，表現為：計算元素、數據存儲
從其形式角度看，表現為：原子構件、復合構件
構件的接口：一組端口
構件之間的關系
順序結構（順序運算）
選擇結構（選擇運算）
循環結構
順序運算定理：
連接件
構件間的交互依據內容分類：
表現為：管道、過程調用、事件廣播……
連接件的接口：一組角色
連接件是構件運算的實現，它是一個6元組
<ID,Role,Beha,Msgs,Cons,Non-Func>
其中，Role為連接件和構件的交互點的集合，它由一個四元組定義
Role=<Id,Action,Event,LConstrains>
配置
拓撲邏輯和約束
軟件體系結構
定義：設論域為U，
(1)構件是一個軟件體系結構
(2)連接件是一個軟件體系結構
(3)構件經有限次連接（運算）后是軟件體系結構。
軟件體系結構記為A=<C,O>,其中C表示組成體系結構的構件集合，O表示構件運算的集合
性質：
- 封閉性：即構件與構件、構件與體系結構、體系結構與體系結構連接后仍是一個體系結構。
- 層次性：即體系結構可由構件連接而成，而體系結構又可以再經過連接組成新的更大的體系結構。
- 可擴充性：即一個滿足條件的新構件可以通過連接加入到結構中。
軟件體系結構風格
什么決定了軟件體系結構風格？控制原則、質量屬性
管道過濾器風格
優點：
構件間耦合關系降低，易于分解問題，實現重用
易于維護和擴展
為系統的運行分析提供便捷條件
支持并發計算
缺點：
不適合處理交互頻繁的應用
數據解析、合成麻煩
擴展形式：管線、有界管道、批處理
數據抽象和面向對象組織
優點：
封裝性、便于重用
可實現交互
缺點：
調用使得修改被傳播
事件驅動風格
事件：監聽事件、聲明事件
構成：事件消費者、事件生產者、事件管理器
基本結構：
事件監聽接口和事件監聽器
事件監聽的注冊和注銷
特征：
是面向對象風格的變體
事件接觸者不知道哪些構件會被這些事件影響
無法預知和假定構件的處理順序
優點：
為重用提供支持
為系統改進提供方便
缺點：
弱化了對系統計算的控制能力
有數據共享的負擔
系統邏輯關系復雜
分層系統
每個層次為上一層提供服務
它同時作為用戶調用下層的功能
嚴格的分層
半透明的分層
優點：
支持基于抽象程度遞增的系統設計
良好的擴展性
支持重用
缺點：
層次劃分困難
適用性受限
倉庫系統及知識庫
要素：
兩類構件：中央數據單元+外部構件
控制策略：兩類構件間的交互方式
分類：
傳統數據庫型（被動）
黑板系統（主動）
黑板系統
中央數據單元是系統的核心，存儲數據和系統狀態數據
知識源是相互獨立的，通過黑板系統完成交互
控制單元是非獨立單元
優點：
易于增加數據的生產者和消費者
良好的知識庫擴展性
易于保證數據的同步、一致性
C2（層次網絡+消息驅動）
組織規則：
頂、底
構件不能直接相連
連接件之間自由連接
連接件的直接相連是有序的
工作方式：請求＋通知
特點：
基底獨立性
構件只見交互只能通過消息傳遞實現
多線程
全局軟件體系結構
C/S結構
服務器任務：
保證數據庫安全性
控制數據庫并發訪問
確保數據的一致性
數據備份與恢復
客戶端任務：
提供交互界面
提交請求，接收信息
對客戶端數據執行應用邏輯要求
三層C/S結構
兩層C/S的弊端：
軟硬件的組合和集成能力有限，難以擴展至大型項目中
軟硬件的組合及集成能力有限
客戶機負荷過重
數據安全性不好
表示層（用戶接口部分）：
用戶與應用間的對話
檢查用戶的輸入和顯示數據（只檢查形式和取值范圍）
功能層（應用本體）：
處理業務邏輯
數據層：
數據庫的讀寫
優點：
在邏輯上保持相對獨立性，能提高系統和軟件的可維護性和可擴展性
允許更靈活有效地選用相應的平臺和硬件系統，在處理負荷能力上與處理特性上分別適應于結構清晰的三層
應用的各層可以并行開發，可以選擇各自最適合的開發語言
利用功能層有效地隔離開表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫工具或黑客手段去非法地訪問數據層
關鍵問題：
三層C/S結構各層間的通信效率若不高，即使分配給各層的硬件能力很強，其作為整體來說也達不到所要求的性能
設計時必須慎重考慮三層間的通信方法、通信頻度及數據量
CORBA（公共對象請求代理）
CORBA體系結構是對象管理組織（OMG）為解決分布式處理環境(DCE)中，硬件和軟件系統的互連而提出的一種解決方案
ORB：carba展開工作的核心，是關鍵的通信機制，處理對象間的消息分布，是一種透明機制
主要任務：對象定位、對象激活、對象通訊
接口定義語言：統一的描述服務器對象接口，不涉及對象的具體實現，面向對象語言
接口池：分布式計算環境中所有可用服務器對象的接口表示
使得動態搜索接口和動態構造請求即參數成為可能
動態調用接口：提供標準函數供用戶動態創建請求動態構造請求參數
對象適配器：屏蔽內部實現細節，為服務器提供抽象接口
特點：
引入中間件作為事務代理，完成客戶機向服務對象方提出的業務請求
實現客戶與服務對象的完全分開，客戶不需要了解服務對象的實現過程以及具體位置
提供軟總線機制，使得在任何環境下、采用任何語言開發的軟件只要符合接口規范的定義，均能夠集成到分布式系統中
CORBA規范軟件系統采用面向對象的軟件實現方法開發應用系統，實現對象內部細節的完整封裝，保留對象方法的對外接口定義
正交體系結構
組成原則：
1 線索可看成是子系統，它由完成不同層次功能的構件組成，同一線索上的構件相互間是一種調用關系，每一條線索完成整個系統中相對獨立的一部分功能
2 層是具有相同抽象級別的構件構成的
3 每一條線索的實現與其他線索的實現無關或關聯很少，在同一層中的構件之間是不存在相互調用的
4 如果線索是相互獨立的，即不同線索中的構件之間沒有相互調用，那么這個結構就是完全正交的
三層線索 五層結構
優點：
結構清晰，易于理解
易修改，可維護性強
可移植性強，重用粒度大
層次消息總線（HMB）
HMB風格基于層次消息總線、支持構件的分布和并發，構件之間通過消息總線進行通信
消息總線是系統的連接件，負責消息的分派、傳遞、過濾及處理結果的返回
各個構件掛接在消息總線上，向總線登記感興趣的消息類型；構件發送的消息由總線傳送到其他構件，處理結果也由總線返回
不要求各個構件具有相同的地址空間或局限在同一臺機器上，可較好地刻畫分布式并發系統
在對系統持續可用性要求較高時，需要在不必對軟件進行重新編譯和加載的前提下，為最終用戶提供系統定制和擴展的能力
動態刪除和增加構件：
系統功能需要擴充時，增加新的構件，只需登記消息響應
系統功能裁減或某構件出現問題時，刪除構件，需阻塞一些消息
用增強功能或改正錯誤的新構件替換舊構件
動態改變構件響應的消息類型：
構件可以動態地改變對外提供的服務
消息過濾：
通過消息過濾機制，解決某些構件集成的不匹配問題
HMB風格的構件模型包括接口、靜態結構和動態行為
接口
HMB風格的構件接口是一種基于消息的互聯接口，可以較好地支持體系結構設計。構件之間通過消息進行通訊，接口定義了構件發出和接收的消息集合
HMB有兩個顯著的特點：
一是降低構件之間的耦合：構件只對消息本身感興趣，不關心消息如何產生；切斷構件之間的直接聯系
二是構件對外來消息進行響應后，可能導致狀態的變遷；同一構件在不同狀態下收到同樣消息可能作出不同的響應
當某個事件發生后，系統或構件發出相應的消息，消息總線負責把該消息傳遞到此消息感興趣的構件
按照響應方式的不同，消息可分為同步消息和異步消息
互補端口（通過消息總線進行通信）：除消息進出構件的方向不同外，消息的名稱、參數、返回結果類型完全相同的兩個端口
消息總線
消息登記：構件需要向總線登記響應的消息集合
消息分派和傳遞：總線負責消息的分派、傳遞，并負責處理結果的返回；總線是邏輯上整體，物理上可跨越多個機器(位置透明)
消息過濾：總線提供消息的轉換和阻塞
構件靜態結構
HMB風格支持自頂向下的層次化分解，復合構件由簡單子構件構成；
子構件通過復合構件內部的消息總線連接，各層次的消息總線在邏輯功能上一致；
子構件還可進一步再分，整個系統用統一的方式描述。
構件的動態行為
構件的行為就由外來消息的類型唯一確定，即一個消息和構件的某個操作之間存在著固定的對應關系
更通常的情況是，構件的行為同時受外來消息類型和自身當前所處狀態的影響
可用有限狀態自動機來描述
異構結構風格
不同結構有不同的處理能力的優點和缺點，系統應根據實際需要來選擇，以解決實際問題
內外有別
優點：外部用戶不直接訪問數據庫服務器，能保證企業數據庫的相對安全。企業內部用戶的交互性較強，數據查詢和修改的響應速度較快
缺點：企業外部用戶修改和維護數據時，速度較慢，較煩瑣，數據的動態交互性不強
查改有別
凡是維護和修改都是c/s結構，凡是查詢都是b/s結構
體現了B/S體系結構和C/S體系結構的共同優點。但因為外部用戶能直接通過Internet連接到數據庫服務器，企業數據容易暴露給外部用戶，給數據安全造成了一定的威脅
互聯系統構成的系統
系統是總分結構，可分成若干部分，每個部分作為單獨的系統開發；整個系統通過一組互連系統實現，互連系統之間相互通信，履行
上級系統(superordinate system)：體現整體性能
從屬系統(subordinate system)：子系統，上級系統模型中所指定內容的一個實現
關鍵點
上級系統獨立于其從屬系統，每個從屬系統僅僅是上級系統模型中所指定內容的一個實現，并不屬于上級系統功能約束的一部分
軟件體系結構評估
軟件體系結構的質量屬性
性能（*）
系統的響應能力
可靠性（*）
容錯性：發成錯誤行為時進行內部修復
健壯性：保護程序不受錯誤輸入和錯誤使用的影響
可用性（*）
系統能夠正常運行的時間的比例
安全性（*）
系統在向合法用戶提供服務的同時能夠阻止非授權用戶使用的企圖和拒絕服務的能力
可修改性（*）
能夠快速地以較高的性能價格比對系統進行變更的能力
可維護性：在錯誤發生后“修復”軟件系統，對其他構件的負面影響最小化
可擴展性：使用新特性擴展軟件系統，使用改進版本替換構件并刪除不需要或不必要的特性和構件
結構重組：重新組織軟件系統的構件及構件間的關系
可移植性：使軟件系統適用于多種硬件平臺、用戶界面、操作系統、編程語言或編譯器
功能性
系統所能完成所期望的工作的能力
可變性
體系結構經擴充或變更而成為新體系結構的能力
集成性
系統能與其他系統協作的程度
互操作性
作為系統組成部分的軟件不是獨立存在的，經常與其他系統或自身環境相互作用
基本概念
敏感點：體系結構決策采用不同的性能屬性,同時這些屬性在風險評估中是一些關鍵性的因素,當進行評價時,它們是體系結構的敏感點，一個或多個構件，或構件之間的關系的特性
權衡點：(加密級別-安全性、性能)是影響多個質量屬性的特性，是多個質量屬性的敏感點
風險承擔者：
在項目管理領域中指“項目干系人”或“涉眾”
場景：
要進行體系結構評估時，一般首先要精確地得出具體的質量目標，并以之作為判定該體系結構優劣的標準。為得出這些目標而采用的機制叫做“場景”
場景用刺激、環境和響應進行描述
刺激：場景中解釋或描述風險承擔者怎樣姻法與系統的交互部分
環境：描述刺激發生時的情況
響應：系統如何通過體系結構對刺激做出反應
基于場景的評估方式（ATAM）
ATAM不但揭示了體系結構如何滿足特定的質量目標，而且提供了這些質量目標如何交互，即他們之間是如何權衡的
6個步驟不是瀑布過程，中途可以跳轉迭代
描述ATAM方法
向風險承擔者介紹評估方法
介紹ATAM方法步驟簡介
介紹獲取分析技術
介紹評估結果
描述業務動機
產品經理要使參會人員理解待評估系統
包括系統的功能需求、約束條件、目標環境和體系結構的驅動因素
描述體系結構
設計師對體系結構進行相對應的描述
內容包括技術約束、與本系統交互的其他系統、用以滿足質量要求的軟件結構方法
確定體系結構方法
設計師通過理解體系結構方法來確定體系結構
生成質量屬性效用樹
分析體系結構描述方法
通過效用樹對體系結構的方法進行考察
討論和分級場景
集體討論用例場景和改變場景（成長場景、考察場景）
成長場景：體系結構中短期的改變
考察場景：體系結構根本性改變
分析體系結構方法
每人30%場景數量的票數進行投票
對比得票數最高的場景和效用樹中優先級最高的節點、對存在的差異進行調整和解釋
得到對每個場景影響最大的質量屬性
描述評估結果
文檔化的體系結構方法
場景及其優先級
基于屬性的問題
效用樹
風險決策
文檔化的無風險決策
敏感點和權衡點
基于度量的評估方式（SAAM）
形成場景
描述體系結構
對場景進行分類和確定優先級
直接場景：體系結構可直接支持該場景，不需要修改
間接場景：必須對體系結構進行一些修改，如：增加構件、刪除構件、修改接口等
確定優先級還是投票，可參考ATAM的投票方式
對間接場景的單個評估
對于直接場景，體系結構設計師需要講清所評估的體系結構如何執行這些場景
對于間接場景，體系結構設計師應說明需要對體系結構進行什么修改
對于間接場景，預估修改、涉及到的構件數量和工作量
評估場景的相互作用
當兩個或多個間接場景要求更改體系結構的一個構件的時候，就稱這些場景在一組構件上相互作用
場景的相互作用暴露了功能分配
語義上不相關的場景相互作用可能說明是功能分離的不夠好
形成總體評估
將場景和業務目標聯系起來，評價是否達到標準
基于體系結構的軟件設計方法（ABSD）
設計元素
ABSD是一個遞歸的方法，體系結構通過該方法得到細化直到產生構件和類
視角和視圖
考慮體系結構時，重要的是從不同的視角來檢查，促使設計師考慮體系結構不同的屬性
視圖與4+1模型視圖類似
用例和質量屬性
在使用用例捕獲動能需求的同時，通過特定場景來捕獲質量需求，這些場景稱為質量場景
質量場景必須包括預期的刺激和非預期的刺激
ABSD的生命周期
ABSD方法的輸入：
抽象功能需求，包括變化的需求和通用的需求
用例
質量因素
約束
ABSD方法定義的設計元素
按照下圖進行分解，一個實際構件反映了一個軟件元素（類）
設計元素的產生順序
廣度遍歷
深度遍歷
設計元素的活動
邏輯視圖、并發視圖、配置視圖都可以開始
注意：
注重領域知識
新技術的融合
個人經驗
反饋環用于保證各種視圖都在考慮的范圍之內
邏輯視圖
創建并發視圖
創建配置視圖
基于體系結構的軟件開發模型
體系結構需求
體系結構設計
體系結構文檔化
體系結構需求規格說明
測試體系結構需求的質量設計說明書
體系結構復審
外部人員參加復審（沒參與設計的）
識別潛在風險，發現設計的錯誤
體系結構實現
體系結構演化
總結
- 上一篇： 软件体系结构基础
- 下一篇： 软件质量管理体系-ISO 9000