基本介紹
分類,出現原由,系統分析,結構範式,管道和過濾器,面向對象的體系,事件驅動的體系,分層次的體系,知識庫體系,解釋器體系,開發觀點,常見結構,嚴格的層次結構,事件驅動的體系,知識庫的體系,基於解釋器的體系,微處理器,
分類
體系結構風格有9大類：
1. 數據流系統，包括順序批處理、管道和過濾器；
3. 獨立部件，包括通信進程、事件隱式調用；
6. 特殊領域風格；例如過程控制、模擬器；
7. 特殊結構的風格，例如分散式處理、狀態轉移系統；
8. 不同風格合成建立的異構結構；
9. 最初始、最基本的主程式/子程式。
出現原由
在傳統的程式設計領域中，人們使用流程圖來表達系統的基本功能和實現的具體邏輯，但是，流程圖實際上僅僅是源程式的圖形化表示，無法給系統的分析和開發者提供更多的信息，所以沒有在實際的系統開發過程中得到廣泛的套用。
隨著軟體系統的規模和複雜性的增加，對軟體系統的整體結構（數據和控制的邏輯）進行分析和描述成為大型系統開發的一個不可缺少的重要部分，顯然，使用流程圖是無法達到這個目標的，我們必須使用新的方法和概念來對系統的整體結構進行把握。
系統分析
系統分析實際上包括兩個階段的工作，首先是需求的分析，也就是說，劃分出系統和環境之間的界面，將所研究（或者是將要開發）的系統和周圍的環境分離，這就是從使用者的觀點，將整個系統作為一個整體來考察。其次是系統的設計，根據系統的整體功能和數據，參考實際的物理系統或者類似的系統，設計實際運行的軟體系統，這一步驟實際上就是體系結構的分析和確定。
從系統工程的觀點看來，任何複雜的系統都是由相對簡單的，在當前所分析的系統層次是原始的基本元素（雖然在更進一步的分析中，這些元素可能具有非常複雜的內部結構）組成的，這些基本元素之間存在複雜的相互作用。所以，軟體系統的分析和設計的基本任務是：確立系統中的基本元素（完成系統的功能所必不可少的成分）；確定這些元素之間相互作用的方式（這就是系統的體系結構）。
結構範式
管道和過濾器
每個組件具有輸入和輸出的集合，從流中讀出數據作為輸入，產生輸出數據的流。整個系統可以看成多個過濾器複合形成的數據處理組件。
過濾器A
過濾器B
過濾器C
管道
特點：
- 過濾器之間是相互獨立的（不能共享狀態），其中一個過濾器的操作和行為不能影響另外過濾器的操作和行為，流的傳送沒有副作用。
- 過濾器對所輸入流的來源和輸出流的去向不關心，不需要知道流的來源和流的去向，來源和去向對於過濾器的數據處理沒有任何影響。
- 過濾和流的傳送可以是並發的，可以同時有多個流的傳送存在於系統之中。
實例：
一個最著名的實例是unix的shell編程，多個對數據進行處理的程式（組件）通過管道聯結起來，產生總和的效果；還有傳統的編譯器，原始碼經過詞法分析、語法分析、中間代碼生成、目標代碼生成等步驟生成輸出的目標代碼。
優點：
- 整個系統的功能是多個過濾器作用的總和，這樣可以簡化系統的分析和設計，可以經過需求的分析之後將整個系統作為一個過濾器處理，然後再逐步的細化成為多個相互連線的過濾器。
- 支持組件的重用，同一個過濾器可以多次出現在系統的不同位置。
- 易於維護和增強，過濾器可以被替換，可以增加新的過濾器到系統中而不改變原有的過濾器，不改變原來系統的基本功能。
- 本質上的並發性支持，這種體系結構由於本質上是與各個獨立的過濾器的狀態無關的，與並行的流的通過次序也是無關的，所以並發是一個基本的體系結構自然具有的特性。
缺點：
- 由於過濾器之間本質上是獨立的，所以設計者必須獨立考慮每一個過濾器的輸入、處理和輸出的過程，對於過濾器邏輯上的共同點和相互關係無法在設計中加以體現。
- 由於這種體系的批處理特性，所以不適合開發和用戶互動的應用程式。
- 系統的多個處理流之間的共同特性無法提取、多個過濾器之間的共同特性也無法提取，所以增加了設計的複雜性。
面向對象的體系
在這種體系中，數據和數據上的操作被封裝成抽象數據類型或者對象。系統由大量的對象組成，在物理上，對象之間通過函式或者過程調用相互作用；在邏輯上，對象之間通過集成、複合等方式實現設計的復用。
對象D
對象B
對象A
對象E
對象C
對象調用
對象調用
對象調用
類A
類B
類C
類G
對象A
對象E
類F
複合
繼承
特點：
優點：
由於封裝，實現了靈活性和擴充性，隱藏了實現的細節，提高代碼的質量；
使用繼承和多態、提高了軟體的可重用性。
缺點：
最主要的缺點是，由於對象之間的互動是通過明確的對象函式調用進行的，所以當一個對象需要實現一個特定功能的時候，必須知道哪一個對象提供這種服務，這就降低了系統的靈活性。管道和過濾器模型不需要明確指明數據的來源和去向。
事件驅動的體系
對象E
對象E
對象E
事件分發的匯流排
事件的創建
事件接收者的註冊的創建
對象E
這是面向對象和數據抽象體系的一種變形，系統同樣是由大量的對象組成的，但是對象之間的互動不是通過明確指明對象的函式或者過程調用進行的，相反，系統提供事件的創建和發布的機制，對象產生事件，一個或者多個對象通過向系統註冊關注這個事件並由此觸發出相應的行為或者產生新的事件。
實例：
一個最著名的例子是GUI的模型，滑鼠、鍵盤或者其他輸入設備產生各種事件，視窗、程式或者其他對象有這些事件所觸發，產生新的事件、進行數據處理或者其他操作。
優點：
用於函式和過程的調用調用不需要指明特定的對象，所以系統具有非常好的靈活性和擴展性，新的組件只需要向系統的事件處理部分註冊就可以立刻加入系統中，同樣，老的組件也可以方便的從系統中刪除。對於動態性要求特別高的系統，特別是如果需要在運行時對系統進行擴充，應該採用該結構。
缺點：
由於函式調用是通過事件傳送進行的，所以，發出事件的對象不能確認是否有對象處理了這個事件、是否是期望的對象處理了這個事件、是否獲得期望的結果，同樣也無法控制事件發生的次序，系統的邏輯和時序的正確性必須通過複雜的時序邏輯和前後條件的斷言加以保證。
分層次的體系
下面是一個基本的商務處理系統的層次結構：
用戶界面層
事務邏輯層
核心層
實例：
優點：
- 系統的開發和設計可以逐步的分層次的進行，從底層的簡單的功能逐步建立高層的複雜和抽象的功能。
- 靈活性和擴展性，由於相鄰層次之間通過清晰的接口互動，所以特定的層次可以被替換和增強，甚至可以增加新的層次。
缺點：
- 不是所有的系統都可以分解成為清楚的層次
- 劃分清晰、邏輯上一致的層次是非常困難的（OSI的失敗和TCP/IP的成功說明了這一點）
- 嚴格的層次調用結構會降低系統的性能。
知識庫體系
使用一個中心數據結構表示系統的當前狀態，一組相互獨立的組件在中心資料庫上進行操作。如果組件負責對中心數據進行選擇、處理，這種體系就是傳統的資料庫模型；如果中心數據結構自主的引發一系列的行為，則這種體系可以看成一個黑板模型。
中心資料庫（知識庫）
客戶組件A
客戶組件B
客戶組件C
實例：
大量的傳統資料庫應用程式實際上就是這一體系的具體實例。在很多研究系統中，使用的基於知識庫的黑板模型，實際上也是這種體系
優點：
以數據為中心的體系結構，可以自然的表示大量的數據和事務處理的邏輯，適合表達以數據為重新的應用程式。
缺點：
只有很少一部分簡單的資料庫存儲套用可以完全採用這種體系結構表示，在大量實際的商業套用中，完成師傅處理和其他邏輯的應用程式必須採用其他的體系結構表達
解釋器體系
用戶
如果應用程式的邏輯非常複雜，例如，AutoCAD的各種繪圖指令，而且，用戶可能以非常複雜的方式使用這個系統，一個較好的體系就是提供面向領域的一組指令（語言），系統解釋這種語言，產生相應的行為，用戶使用這種指令（語言）完成複雜的操作。
使用虛擬機語言描述的業務邏輯
虛擬機解釋器
完成實際操作任務的基本指令
實際的問題領域
實例：
大量的開發工具、二次開發工具體現了這一思想：微軟在其產品中大量使用的Visual Basic for Application，以及在AutoDesk產品中大量使用的AutoLisp語言，實際上就是給用戶提供了一種面向領域的語言，然後核心解釋執行這一語言的指令和指令序列。從而擴充產品的功能，方便用戶按照自己的需要定製系統。
優點：
非常好的擴展性，用戶可以實現對軟體系統的二次開發。
缺點：
軟體開發複雜，特別是這種指令集的設計非常困難。
是否可以採用一種成熟的語言作為二次開發的基礎（例如，基於Java）
開發觀點
在實際開發過程中，簡單的判斷某一個具體的套用應該採取何種體系結構是非常困難的，簡單的管道、過濾器體系已經非常少見，面向對象的思想已經融合在幾乎所有的體系結構之中，而層次化的思想同樣也被廣泛使用，所以，一個基本的系統分析方法應該是功能和複雜性的分解，也就是說，從橫向分解（分模組、子系統），縱向分解中得到系統的基本組件（分類、分層次的功能和對象）。然後根據問題領域的特性選擇系統的行為模式（具體的體系結構）。
常見結構
嚴格的層次結構
（系統可以清楚的分解成為不同的功能層次，例如基本的圖形庫，提供不同層次的繪圖接口） 這種體系結構適合於系統的功能相對簡單，並且可以按照複雜的程度、抽象的程度、和硬體平台的關係等方面的特性加以分層的軟體中。
事件驅動的體系
對互操作性、特別是異構環境下的互操作性要求非常高的情況下，可以採用這種體系，當整個系統中存在大量的並發的，相互之間沒有邏輯聯繫的組件的時候（例如作業系統或者圖形用戶界面）可以使用這種體系結構。現代軟體技術中微軟的COM和ISO的CORBA實際上都是這種體系結構的例子。
知識庫的體系
以大量數據為核心的系統採用這種體系，一些人工智慧的套用同樣需要這種體系結構，面向對象的知識庫是這種體系結構的一個發展方向。將面向對象和層次化的思想引入知識庫系統中，將得到一種非常強大的體系結構。
基於解釋器的體系
如果套用系統和用戶的互動非常複雜，採用這種體系結構是最適合的方案，只有將系統的基本操作以指令的形式提供給用戶，同時，提供一種簡單明了的語法和基本的數據操作、處理的功能，才能得到功能最強大、最靈活、具有最佳擴充新的套用系統；一個非常合適的例子是瀏覽器，一開始，瀏覽器只是簡單的下載和顯示HTML的頁面，隨著用戶對界面互動要求的發展，開發出javascript，提供一種語言和基本的界面元素操縱的指令來得到擴充性和強大的功能。
絕大多數實際運行的系統都是上面幾種體系結構的複合：在系統的某些部分採用一種體系結構而在其他的部分採用另外的體系，我們可以將複合幾種基本體系結構的系統稱作複合體系結構。在實際的系統分析和設計中，可能首先將整個系統作為一個功能體進行分析和權衡，得到適宜的、最上層的體系結構，如果該體系結構中的元素較為複雜，可以繼續進行分解，得到某一部分的，局部的體系。
分析的層次應該在可以清晰的使用簡單的功能和界面描述表達結束，這樣，可以將我們在分析和設計的這一階段將焦點集中在系統的總體結構上，而避免引入和所使用的語言、實現所具體需要的技術等實現的細節上。
微處理器
體系結構(architecture)規定了處理器的功能性行為，是處理器設計的規範。
微體系結構（microarchitecture)是體系結構的具體設計，即處理器實現。
某種體系結構在其生命周期內可以有多種邏輯實現。比如，Intel的IA-32架構，也稱為“x86”架構，是一種設計規範。基於該規範下的產品包括包括Intel 8086、80186、80286、80386以及80486等。
