1、什麼是架構風格
軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式。
軟件架構設計的一個核心問題是能否使用重複的架構模式，即能否達到架構級的軟件重用。
架構風格反映了領域中衆多系統所共有的結構和語義特性，並指導如何將各個模塊和子系統有效滴組織成一個完整的系統。
2、常用軟件架構
- 數據流風格：批處理序列，管道/過濾器。
- 調用/返回風格：主程序/子系統，面向對象風格，層次結構。
- 獨立構件風格：進程通信，事件系統。
- 虛擬機風格：解釋器，基於規則的系統。
- 倉庫風格：數據庫系統，超文本系統，黑板系統。
3、架構優缺點，簡述
3.1 數據流風格 -> 管道/過濾器
--
每個構件都有一組輸入輸出，構件讀輸入的數據流，經過內部處理，然後產生輸出數據流。因此，這裏的構件被稱爲過濾器，這種風格的連接件就像是數據流的管道，將一個過濾器的輸出傳到另一個過濾器的輸入。此風格中特別重要的過濾器必須是獨立的實體，它不能與其他的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。
**應用**
unix shell編寫的程序
傳統的編譯器
**優點**
- 使得構件具有良好的隱蔽性和高內聚、低耦合的特點。
- 允許設計者將整個系統的I/O行爲看成是多個過濾器行爲的簡單合成。
- 支持軟件重用。只要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來。
- 系統維護簡單，可擴展性好。
- 允許對一些屬性，如吞吐量、死鎖等進行分析。
- 支持並行執行。每個過濾器是作爲一個單獨的任務完成，因此可與其他任務並行執行。
**缺點**
- 通常導致進程稱爲批處理的結構。
- 不適合處理交互的應用。
- 因爲在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，並增加了編寫過濾器的複雜性
3.2 調用/返回風格 -> 面向對象風格
--
面向對象風格建立在數據抽象和麪向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。
**優點**
- 因爲對象對其他對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其他對象。
- 設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
**缺點**
- 爲了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象。
- 必須修改所有顯示調用它的其他對象，並消除由此帶來的一些副作用。例如，如果A使用了對象B，C也是用了對象B，那麼C對B的使用所造成的對A的影響可能是料想不到的。
3.3 調用/返回風格 -> 分層系統
--
層次系統組織成一個層次結構，每一層爲上層服務，並作爲下層的客戶。
在一些層次系統中，處理一些精心挑選的輸出函數外，內部的層紙對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機，連接件通過決定層間如何交互的可以來定義。
這種架構風格支持基於可增加抽象層的設計。這樣，允許將一個複雜問題分解成一個增量步驟序列的實現。由於每一層最多隻影響兩層，同時只要給相鄰層提供的接口，允許每層用不同的方法實現，同樣爲軟件重用提供了強大的支持。
**優點**
- 支持基於抽象程度遞增的系統設計，使設計者可以把一個複雜系統按遞增的步驟進行分解。
- 支持功能增強，因爲每一個層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層。
- 支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。
**缺點**
- 並不是每個系統都可以很容易地劃分爲分層的模式，甚至即使一個系統的邏輯機構是層次化的，出於對系統性能的考慮，架構設計師不得不把一些低級或高級的功能綜合起來。
- 很難找到一個合適的、正確的層次抽象方法。
3.4 獨立構件風格 -> 基於事件的隱式調用
--
基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個多事件。系統中的其他構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
從架構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中註冊一些過程，當發生這些事件時，過程被調用。
基於事件的隱式調用風格的主要特點是事件的觸發者並不知道那些構件會受到這些事件影響。由於不能假定構件的處理順序，甚至不知道那些過程會被調用，因此，許多隱式調用的系統也包含顯示調用作爲構件交互的補充形式。
**優點**
- 爲軟件重用提供了強大的支持。
- 爲改進系統帶來了方便。
**缺點**
- 構件放棄了對系統計算的控制。
- 數據交換的問題。
- 既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理就存在問題。
3.5 倉庫風格
--
在倉庫（repository）風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存儲上執行。控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
黑板系統的傳統應用是信號處理領域，主要由3部分組成：
- 知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通信，它們之間的交互只通過黑板來完成。
- 黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。
- 控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
3.6 C2風格
--
通過連接件綁定在一起的按照一組規則運作的並行構件網絡。
**規則如下**
- 系統中的構件和連接件都有一個頂部和一個底部。
- 構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的。
- 一個連接件可以和任意數目的其他構件和連接件連接。
- 當兩個連接件進行直接連接時，必須由其中一個的底部連接到另一個的頂部。
**特點**
- 系統中的構件可實現應用需求，並能將人意複雜度的功能封裝在一起。
- 所有構件之間的通信是通過以連接件爲中介的異步消息交換機制來實現的。
- 構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
## 客戶機/服務器風格
C/S架構可以是二層的，也可以是三層的。
## 多層架構風格
- 三層C/S架構模型
- B/S架構，三層架構
## 富互聯網應用
- ajax
## 正交軟件架構
**優點**
- 結構清晰，易於理解。由於線索功能相互獨立，不進行互相調用，結構簡單、清洗，構件在結構圖中的位置已經說明它所實現的是哪一級抽象，負擔的是什麼功能。
- 易修改，可維護性強。由於線索之間是相互獨立的，所以對一個線索的修改不會影響到其他線索。因此，當軟件需求發生變化時，可以將新需求分解爲獨立的子需求，然後以線索和其中的構件爲主要對象分別對各個子需求進行處理，這樣軟件修改就很容易實現。系統功能的增加或減少，只需要相應的增刪線索構件族，而不影響整個正交架構，因此能方便地實現結構調整。
- 可移植性強，重用粒度大。因爲正交結構可以爲一個領域內的所有應用程序所共享，這些軟件有着相同或類似的層次和線索，可以實現架構級的重用。
喜歡就支持一波哦...
