軟件架構風格

# 軟件架構風格

軟件架構設計的一個核心問題是可否使用重複的架構模式，即可否達到架構級的軟件重用。

也就是說，可否在不一樣的軟件系統中，使用同一架構。

軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式。

架構風格反映了領域中衆多系統所共有的結構和語義特性，並指導如何將各個模塊和子系統有效滴組織成一個完整的系統。

- 數據流風格：批處理序列，管道/過濾器。
- 調用/返回風格：主程序/子系統，面向對象風格，層次結構。
- 獨立構件風格：進程通訊，事件系統。
- 虛擬機風格：解釋器，基於規則的系統。
- 倉庫風格：數據庫系統，超文本系統，黑板系統。

### 管道/過濾器
--
每一個構件都有一組輸入輸出，構件讀輸入的數據流，通過內部處理，而後產生輸出數據流。所以，這裏的構件被稱爲過濾器，這種風格的鏈接件就像是數據流川叔的管道，將一個過濾器的輸出傳到另外一個過濾器的輸入。此風格中特別重要的過濾器必須是獨立的實體，它不能與其餘的過濾器共享數據，並且一個過濾器不知道它上游和下游的標識。

**應用**

unix shell編寫的程序

傳統的編譯器

**優勢**

- 使得構件具備良好的隱蔽性和高內聚、低耦合的特色。
- 容許設計者將整個系統的I/O行爲當作是多個過濾器行爲的簡單合成。
- 支持軟件重用。只要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器均可被鏈接起來。
- 系統維護簡單，可擴展性好。
- 容許對一些屬性，如吞吐量、死鎖等進行分析。
- 支持並行執行。每一個過濾器是做爲一個單獨的任務完成，所以可與其餘任務並行執行。

**缺點**

- 一般致使進程稱爲批處理的結構。
- 不適合處理交互的應用。
- 由於在數據傳輸上沒有通用的標準，每一個過濾器都增長了解析和合成數據的工做，這樣就致使了系統性能降低，並增長了編寫過濾器的複雜性

### 面向對象風格
--
面向對象風格創建在數據抽象和麪向對象的基礎上，數據的表示方法和它們的相應操做封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。

**優勢**

- 由於對象對其餘對象隱藏它的表示，因此能夠改變一個對象的表示，而不影響其餘對象。
- 設計者可將一些數據存取操做的問題分解成一些交互的代理程序的集合。

**缺點**

- 爲了使一個對象和另外一個對象經過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改全部其餘明確調用它的對象。
- 必須修改全部顯示調用它的其餘對象，並消除由此帶來的一些反作用。例如，若是A使用了對象B，C也是用了對象B，那麼C對B的使用所形成的對A的影響多是料想不到的。

### 基於事件的隱式調用
--
基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個多事件。系統中的其餘構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的全部過程，這樣，一個事件的觸發就致使了另外一模塊中的過程的調用。

從架構上說，這種風格的構件是一些模塊，這些模塊既能夠是一些過程，又能夠是一些事件的集合。過程能夠用通用的方式調用，也能夠在系統事件中註冊一些過程，當發生這些事件時，過程被調用。

基於事件的隱式調用風格的主要特色是事件的觸發者並不知道那些構件會受到這些事件影響。因爲不能假定構件的處理順序，甚至不知道那些過程會被調用，所以，許多隱式調用的系統也包含顯示調用做爲構件交互的補充形式。

**優勢**

- 爲軟件重用提供了強大的支持。
- 爲改進系統帶來了方便。

**缺點**

- 構件放棄了對系統計算的控制。
- 數據交換的問題。
- 既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理就存在問題。

### 分層系統
--
層次系統組織成一個層次結構，每一層爲上層服務，並做爲下層的客戶。
在一些層次系統中，處理一些精心挑選的輸出函數外，內部的層紙對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機，鏈接件經過決定層間如何交互的能夠來定義。
這種架構風格支持基於可增長抽象層的設計。這樣，容許將一個複雜問題分解成一個增量步驟序列的實現。因爲每一層最多隻影響兩層，同時只要給相鄰層提供的接口，容許每層用不一樣的方法實現，一樣爲軟件重用提供了強大的支持。

**優勢**

- 支持基於抽象程度遞增的系統設計，使設計者能夠把一個複雜系統按遞增的步驟進行分解。
- 支持功能加強，由於每個層至多和相鄰的上下層交互，所以功能的改變最多影響相鄰的上下層。
- 支持重用。只要提供的服務接口定義不變，同一層的不一樣實現能夠交換使用。

**缺點**

- 並非每一個系統均可以很容易地劃分爲分層的模式，甚至即便一個系統的邏輯機構是層次化的，出於對系統性能的考慮，架構設計師不得不把一些低級或高級的功能綜合起來。
- 很難找到一個合適的、正確的層次抽象方法。

### 倉庫系統及知識庫
--
在倉庫（repository）風格中，有兩種不一樣的構件：中央數據結構說明當前狀態，獨立構件在中央數據存儲上執行。控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另外一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。

黑板系統的傳統應用是信號處理領域，主要由3部分組成：

- 知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只經過黑板來完成。
- 黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源經過不斷地改變黑板數據來解決問題。
- 控制。控制徹底由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。

### C2風格
--
經過鏈接件綁定在一塊兒的按照一組規則運做的並行構件網絡。

**規則以下**

- 系統中的構件和鏈接件都有一個頂部和一個底部。
- 構件的頂部應鏈接到某鏈接件的底部，構件的底部則應鏈接到某鏈接件的頂部，而構件與構件之間的直接鏈接是不容許的。
- 一個鏈接件能夠和任意數目的其餘構件和鏈接件鏈接。
- 當兩個鏈接件進行直接鏈接時，必須由其中一個的底部鏈接到另外一個的頂部。

**特色**

- 系統中的構件可實現應用需求，並能將人意複雜度的功能封裝在一塊兒。
- 全部構件之間的通訊是經過以鏈接件爲中介的異步消息交換機制來實現的。
- 構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。

## 客戶機/服務器風格

C/S架構能夠是二層的，也能夠是三層的。

## 多層架構風格

- 三層C/S架構模型
- B/S架構，三層架構

## 富互聯網應用

- ajax

## 正交軟件架構

**優勢**

- 結構清晰，易於理解。因爲線索功能相互獨立，不進行互相調用，結構簡單、清洗，構件在結構圖中的位置已經說明它所實現的是哪一級抽象，負擔的是什麼功能。
- 易修改，可維護性強。因爲線索之間是相互獨立的，因此對一個線索的修改不會影響到其餘線索。所以，當軟件需求發生變化時，能夠將新需求分解爲獨立的子需求，而後以線索和其中的構件爲主要對象分別對各個子需求進行處理，這樣軟件修改就很容易實現。系統功能的增長或減小，只須要相應的增刪線索構件族，而不影響整個正交架構，所以能方便地實現結構調整。
- 可移植性強，重用粒度大。由於正交結構能夠爲一個領域內的全部應用程序所共享，這些軟件有着相同或相似的層次和線索，能夠實現架構級的重用。

## 基於層次消息總線的架構