什么是軟件體系結構風格？

軟件體系結構風格（Architectural Styles）是描述特定系統組織方式的慣用范例，強調了軟件系統中通用的組織結構。

一個軟件體系結構風格定義了構件和連接件類型的符號集，及規定了它們怎樣組合起來的約束集合。

主程序 - 子程序 風格

主程序-子程序風格是結構化程序設計的一種典型風格，從功能的觀點設計系統，通過逐步分解和細化，形成整個系統的體系結構。

管道-過濾器風格

構件：過濾器。它對輸入流進行處理、轉換。處理后的結果在輸出端流出。
【過濾器之間是相互獨立的，無需進行狀態信息的交互（主要特點）。每個過濾器都有輸入輸出，過程是：輸入流->進行處理->輸出流】
連接件：管道。位于過濾器之間，起到信息流的導管作用

• 當處理數據流時，每一處理步驟都由一個過濾器（構件）完成，這些過濾器由攜帶數據的管道（連接件）連接起來
  過濾器：從輸入源讀入一個數據流，并從輸出池寫出另一個數據流
  管道：把一個過濾器的輸出傳送到另一個過濾器作為輸入
• 用不同的組合方式連接過濾器可以提供處理數據流的不同方式

可以解決的問題：

• 處理數據流，自然的分為幾個步驟（可理解為需要做一系列獨立的增量計算/轉換）
• 可能需要重組步驟
• 不連續的步驟不共享信息/狀態

解決方案：

• 過濾器逐漸消耗或傳遞數據
• 過濾器可以有參數
• 數據源輸入（數據文件等）
• 輸出至數據接收器
• 從數據源到數據接收器的過濾器序列給出一個處理管道

優點：

a. 使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點，系統中已有的過濾器很容易用于新的待設計系統。
【隱蔽性：構件本身是封裝好的實體，高內聚、低耦合：因為構件彼此之間是獨立的】
b. 允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成【便于劃分功能】
c. 支持軟件重用。
【只需要控制過濾器的輸入流，就可以將兩個過濾器連接起來】
d. 具有較強的可維護性和可擴展性。
【可維護性：更新和升級–增加、修改過濾器，只需要考慮涉及到的過濾器，其他不相關的不受影響】
【可擴展性：添加新的功能，只需要在原有基礎上添加新的端口】
e. 支持并行執行。
【構件之間相互獨立，所以可以并行執行】
f. 為系統的性能分析提供了方便?！就掏铝?、死鎖、計算機正確性等屬性】

缺點：
a. 通常導致進程成為批處理的結構。
【過濾器是對輸入的批量轉換處理，對輸入和輸出有相應的說明限制】
b. 全局變量的共享很困難，通信、交互性不強
【過濾器對輸入流有著嚴格的限制】
c. 當數據傳輸量很大而又有很多小的過濾器時代價較大
【因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，并增加了編寫過濾器的復雜性。】
d. 并行效果并不理想
【數據傳輸占用系統的執行時間】
f . 出現錯誤時如何做處理比較困難

舉例1：（媒體播放器）

舉例2：（編譯器）

面向對象的體系結構風格

構件：對象，或者說是抽象數據類型的實例
連接件：通過函數和過程的調用

●主要特點
一對現實世界的自然建模方法
一封裝(數據表示和相關的基本操作被封裝，限制訪問)
一繼承(共享功能定義，可以在繼承一個已定義好的類的所有特征的基礎上逐漸定義更具體的對象)-重用
●對象(構件實例)
一負責維護自身表示的完整性
一這種表示對其他對象是隱藏的
一通過消息調用通信

優點：

強調設計，全面的系統考慮，和現實世界的對應關系

對象對客戶隱藏了實現的細節，可以在不影響客戶的情況下改變對象的實現(低耦合，高重用，可維護)，方便系統升級

內部表達的保護(封裝數據/狀態的完整)

缺點：

對象交互時需要知道彼此的標識

• 與此相反，管道過濾器系統中的過濾器之間的交互不需要知道系統中其他過濾器的存在
• 一個對象標識改變時，必須修改每一個顯示調用了它的對象(導入/import了該對象的名字的模塊)

多個對象對同一資源的訪問(A和B同時需要使用C)

• 狀態的改變和維護
• 需要做更改時(B對C需求的影響，可能會對A有牽連)

采用面向對象，分解出的是小粒度的基本類或對象。從系統總體結構到構件的設計，缺乏有效的描述和設計方法。
【就是一開始做體系結構設計，分解出的構件很難做到對象這么精準】

分層的體系結構風格

典型范例（內、外分層）

典型范例另一表現方法（上、下分層）

構件：組織為層次結構，每一層給外層提供服務，又作為它內層的客戶；某些系統中，內層只對相鄰的層可見
連接件：層間的協議，定義了層次間的交互方式

可以解決的問題：
●系統有不同級別的抽象層
●請求向下傳遞，通知向上傳遞
●層間需要穩定的界面
●,不同層次將來可能會變化
●團隊編程可能需要分解，細化

解決方案：
●從最底層開始
●逐漸向上建立高層
● 同一級別的抽象放在同一層
●無組件跨越兩層
●各層規范接口界面
●盡量維持下層簡單
●盡量在下層做錯誤處理

優點
a.支持基于抽象程度逐漸遞增的系統設計
【就是可以由簡單到復雜】
b.層重用
【層與層之間通過服務接口進行交互，所以只要接口不變，層就可以重用】
c.支持功能增強
【因為每一層基本只影響相鄰兩層，所以對功能的修改最多影響相鄰兩層】
e.擴展性，可維護性
【可以添加新層，改變當前層】

缺點
a.行為改變的傳遞性
b.效率低下
【上面的層過分依賴下面的層提供服務，相關數據傳達時間長，數據傳輸低效】
c.層次大小的難以清晰界定
【并不是每個系統都可以很容易地劃分為分層的模式，有時候為了性能考慮，要把一些綜合起來，避免功能模塊跨越多層較難】
d. 缺少公認合適的、正確的層次抽象方法。
【層次太少，分層不能完全發揮這種風格的可重用性、可更改性和可移植性上的潛力。層次太多，會引入不必要的復雜性和層間隔離冗余以及層間傳輸的開銷。】

舉例：分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作為上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。

倉庫風格
構件：

• 中央數據單元，代表系統當前的各種狀態
• 相對獨立的構件集合，對中央數據單元進行操作

兩種控制策略的選取產生兩個主要的子類

• 輸入數據流中的事務指令觸發系統相應進程的執行:則倉庫是傳統
  數據庫體系結構
• 中央數據結構的當前狀態觸發系統相應進程的執行:則倉庫是一個黑板體
  系結構;黑板體系結構是倉庫體系結構的特殊化

黑板系統

3大組成元素：
（1）知識源：包含獨立的、與應用程序相關的知識。

• 知識源之間不直接通信，它們之間的交互通過黑板完成
• 它們可以讀當時的不完全解決方案
• 它們可以建議對該方案進行修改
  （2）黑板數據結構：黑板數據是按照與應用程序相關的層次來組織的解決問題的數據。知識源通過不斷的改變黑板數據來解決問題。一個中央黑板數據結構用來描述對一個問題的不完全解決方案（問題求解狀態）。
  （3）控制組件：監視黑板狀態，安排知識源活動進程

需要解決的問題

• 需要對復雜數據解釋（比如信號處理，語音識別）
• 對某問題沒有決定性的解決方案
• 對該問題的不同部分可能需要不同代表性的解決框架
• 對于不同的問題解決者，可能沒有合理組合它們的固定策略
• 可能需要和不確定的知識打交道

*解決方案 *

• 問題解決者獨立解決部分問題
• 共享一個數據結構（黑板）
• 一個中心控制器管理對黑板的訪問
• 黑板可以被結構化（比如抽象為不同層），這樣問題解決者可以在不同層次上工作

典型范例：信號處理領域中的語音和模式識別。另一應用是松耦合代理數據共享存取。

語音識別

優點

• 在有限的范圍內容易實驗不同的問題解決者和誘導啟發式的控制方法
• 知識源可以重用；規模伸縮性好（方便添加新數據）
• 系統在有限的范圍內可以容忍哪些不可靠的問題解決者，這可以通過保護/修改黑板實現

缺點

• 測試困難
• 難以保障最佳解決方案
• 控制策略通常需要啟發誘導
• 計算開銷大（工作量可能比較大，浪費多）
• 并行處理可行，可實際上需要同步/加鎖機制保證數據結構的完整性和一致性，這增加了系統的復雜度
• 不同數據源對于共享數據結構要達成一致，這使得對黑板數據結構的修改較為困難。

獨立組件風格
之
通信進程

• 消息在命名的參與者間傳播
  AND 事件驅動
• 未命名的參與者間隱式調用

通信進程風格
構件：獨立進程
連接件：消息傳遞(點對點、同步或異步、RPC)

事件驅動

基本思想

• 不直接調用一個過程，而是發布或廣播一個或多個事件
• 其他構件通過注冊與事件關聯的進程來表示對該事件的興趣
• 事件發生時，系統會調用所有注冊了該事件的過程
• 這樣一個事件的激發導致其他模塊中過程的隱式調用
  主要特點
• 事件發布者不知道哪些構件會受到事件的影響
• 構件不能對事件的處理順序或者事件發生后的處理結果做任何假設

構件：對象或進程

• 接口定義了允許的接受事件和發布事件
  連接器：事件-過程的綁定
• 過程注冊感興趣的事件
• 構件通過宣布事件來交互
• 當接收到事件時，關聯的過程被隱式調用
• 調用順序不確定

顯示調用和隱式調用

優點：

問題分解

• 計算和協作分開來:對象更加獨立

系統維護和重用

• 沒有靜態，固定的對對象名字的依賴
• 系統重用比較容易:需要用新構件時只需要注冊一個系統事件就可以引入到系統中
• 系統演化比較容易:不改變其他構件接口的情況下，構件間的互相取代很容易;替換某構件不影響其他構件，升級簡單
• 集成容易

效率

• 可并行調用

缺點：
1.問題分解

• 構件放棄了自身對系統計算的控制:當發布事件時，無法保證其他構件會做出反應，也無法保證事件被處理的先后順序
• 數據交換問題:有時數據可被一個事件傳遞，但另一些情況下，基于事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，整體性能和資源管理可能會成為問題
• 很難對系統正確性進行推理:和傳統調用功能行為檢驗不同，不能只考慮過程前后的條件，而是發布事件時事件激發的上下文

系統維護和重用

• 需要一個關于誰對什么感興趣的中心黃頁服務:事件，注冊，策略調度

效率

• 間接通信意味著一些性能損失

常見案例
●數據庫管理系統中數據-致性約束的實現
●程序調試工具中變量監視器對變量值的刷新
【在某系統中，編輯器和變量監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下來時，它聲明該事件，由系統自動調用處理程序。
Debugger本身只聲明事件，并不關心哪些過程會啟動，也不關心這些過程做什么處理?！?br /> ●集成開發環境中編譯器支持的自動語法檢查
●天氣預報手機短信

完成這篇博文參考了許多資料，感謝肖亮老師提供的PPT
還有簡書上的Mikito_k參考
以及知乎上的王boy參考

總結

以上是生活随笔為你收集整理的软件体系结构风格整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。