體系結構:一組部件以及部件之間的聯系-中文百科頻道

分類

體系結構風格有9大類：n1.數據流系統，包括順序批處理、管道和過濾器；

2.調用－返回系統，包括主程序和子程序、面向對象系統、層次結構；

3.獨立部件，包括通信進程、事件隐式調用；

4.虛拟機，包括解釋器、規則基系統；

5.以數據為中心的系統（庫），包括數據庫、超文本系統、黑闆系統；

6.特殊領域風格；例如過程控制、模拟器；

7.特殊結構的風格，例如分布式處理、狀态轉移系統；

8.不同風格合成建立的異構結構；

9.最初始、最基本的主程序/子程序。

出現原由

在傳統的程序設計領域中，人們使用流程圖來表達系統的基本功能和實現的具體邏輯，但是，流程圖實際上僅僅是源程序的圖形化表示，無法給系統的分析和開發者提供更多的信息，所以沒有在實際的系統開發過程中得到廣泛的應用。随着軟件系統的規模和複雜性的增加，對軟件系統的整體結構（數據和控制的邏輯）進行分析和描述成為大型系統開發的一個不可缺少的重要部分，顯然，使用流程圖是無法達到這個目标的，我們必須使用新的方法和概念來對系統的整體結構進行把握。

系統分析

系統分析實際上包括兩個階段的工作，首先是需求的分析，也就是說，劃分出系統和環境之間的界面，将所研究（或者是将要開發）的系統和周圍的環境分離，這就是從使用者的觀點，将整個系統作為一個整體來考察。其次是系統的設計，根據系統的整體功能和數據，參考實際的物理系統或者類似的系統，設計實際運行的軟件系統，這一步驟實際上就是體系結構的分析和确定。

結構範式

管道和過濾器

每個組件具有輸入和輸出的集合，從流中讀出數據作為輸入，産生輸出數據的流。整個系統可以看成多個過濾器複合形成的數據處理組件。

過濾器A

過濾器B

過濾器C

管道

特點：

過濾器之間是相互獨立的（不能共享狀态），其中一個過濾器的操作和行為不能影響另外過濾器的操作和行為，流的傳送沒有副作用。

過濾器對所輸入流的來源和輸出流的去向不關心，不需要知道流的來源和流的去向，來源和去向對于過濾器的數據處理沒有任何影響。

過濾和流的傳送可以是并發的，可以同時有多個流的傳送存在于系統之中。

實例：

一個最著名的實例是unix的shell編程，多個對數據進行處理的程序（組件）通過管道聯結起來，産生總和的效果；還有傳統的編譯器，源代碼經過詞法分析、語法分析、中間代碼生成、目标代碼生成等步驟生成輸出的目标代碼。

優點：

整個系統的功能是多個過濾器作用的總和，這樣可以簡化系統的分析和設計，可以經過需求的分析之後将整個系統作為一個過濾器處理，然後再逐步的細化成為多個相互連接的過濾器。

支持組件的重用，同一個過濾器可以多次出現在系統的不同位置。

易于維護和增強，過濾器可以被替換，可以增加新的過濾器到系統中而不改變原有的過濾器，不改變原來系統的基本功能。

本質上的并發性支持，這種體系結構由于本質上是與各個獨立的過濾器的狀态無關的，與并行的流的通過次序也是無關的，所以并發是一個基本的體系結構自然具有的特性。

缺點：

由于過濾器之間本質上是獨立的，所以設計者必須獨立考慮每一個過濾器的輸入、處理和輸出的過程，對于過濾器邏輯上的共同點和相互關系無法在設計中加以體現。

由于這種體系的批處理特性，所以不适合開發和用戶交互的應用程序。

系統的多個處理流之間的共同特性無法提取、多個過濾器之間的共同特性也無法提取，所以增加了設計的複雜性。

面向對象的體系

在這種體系中，數據和數據上的操作被封裝成抽象數據類型或者對象。系統由大量的對象組成，在物理上，對象之間通過函數或者過程調用相互作用；在邏輯上，對象之間通過集成、複合等方式實現設計的複用。

對象D

對象B

對象A

對象E

對象C

對象調用

類A

類B

類C

類G

對象A

對象E

類F

複合

繼承

物理結構邏輯結構

特點：

面向對象系統分析和設計的資料已經太多，這裡就不再詳細說明了。

優點：

由于封裝，實現了靈活性和擴充性，隐藏了實現的細節，提高代碼的質量；

使用繼承和多态、提高了軟件的可重用性。

缺點：

最主要的缺點是，由于對象之間的交互是通過明确的對象函數調用進行的，所以當一個對象需要實現一個特定功能的時候，必須知道哪一個對象提供這種服務，這就降低了系統的靈活性。管道和過濾器模型不需要明确指明數據的來源和去向。

事件驅動的體系

對象E

事件分發的總線

事件的創建

事件接收者的注冊的創建

對象E

這是面向對象和數據抽象體系的一種變形，系統同樣是由大量的對象組成的，但是對象之間的交互不是通過明确指明對象的函數或者過程調用進行的，相反，系統提供事件的創建和發布的機制，對象産生事件，一個或者多個對象通過向系統注冊關注這個事件并由此觸發出相應的行為或者産生新的事件。

實例：

一個最著名的例子是GUI的模型，鼠标、鍵盤或者其他輸入設備産生各種事件，窗口、程序或者其他對象有這些事件所觸發，産生新的事件、進行數據處理或者其他操作。

優點：

用于函數和過程的調用調用不需要指明特定的對象，所以系統具有非常好的靈活性和擴展性，新的組件隻需要向系統的事件處理部分注冊就可以立刻加入系統中，同樣，老的組件也可以方便的從系統中删除。對于動态性要求特别高的系統，特别是如果需要在運行時對系統進行擴充，應該采用該結構。

缺點：

由于函數調用是通過事件發送進行的，所以，發出事件的對象不能确認是否有對象處理了這個事件、是否是期望的對象處理了這個事件、是否獲得期望的結果，同樣也無法控制事件發生的次序，系統的邏輯和時序的正确性必須通過複雜的時序邏輯和前後條件的斷言加以保證。

分層次的體系

将系統功能和組件分成不同的功能層次，一般而言，隻有最上層的組件和功能可以被系統外的使用者訪問，隻有相鄰的層次之間才能夠有函數調用。

下面是一個基本的商務處理系統的層次結構：

用戶界面層

事務邏輯層

核心層

實例：

顯然，ISO的OSI（開放系統互連）參考模型是最著名的層次模型的例子，通過将開放系統的功能和組件劃分成7個層次，定義清晰的（很多時候是過于複雜的）層次之間的接口，實現複雜的互操作性。

優點：

系統的開發和設計可以逐步的分層次的進行，從底層的簡單的功能逐步建立高層的複雜和抽象的功能。

靈活性和擴展性，由于相鄰層次之間通過清晰的接口交互，所以特定的層次可以被替換和增強，甚至可以增加新的層次。

缺點：

不是所有的系統都可以分解成為清楚的層次劃分清晰、邏輯上一緻的層次是非常困難的（OSI的失敗和TCP/IP的成功說明了這一點）嚴格的層次調用結構會降低系統的性能。

知識庫體系

使用一個中心數據結構表示系統的當前狀态，一組相互獨立的組件在中心數據庫上進行操作。如果組件負責對中心數據進行選擇、處理，這種體系就是傳統的數據庫模型；如果中心數據結構自主的引發一系列的行為，則這種體系可以看成一個黑闆模型。

中心數據庫（知識庫）

客戶組件A

客戶組件B

客戶組件C

實例：

大量的傳統數據庫應用程序實際上就是這一體系的具體實例。在很多研究系統中，使用的基于知識庫的黑闆模型，實際上也是這種體系

優點：

以數據為中心的體系結構，可以自然的表示大量的數據和事務處理的邏輯，适合表達以數據為重新的應用程序。

缺點：

隻有很少一部分簡單的數據庫存儲應用可以完全采用這種體系結構表示，在大量實際的商業應用中，完成師傅處理和其他邏輯的應用程序必須采用其他的體系結構表達

解釋器體系

用戶

如果應用程序的邏輯非常複雜，例如，AutoCAD的各種繪圖指令，而且，用戶可能以非常複雜的方式使用這個系統，一個較好的體系就是提供面向領域的一組指令（語言），系統解釋這種語言，産生相應的行為，用戶使用這種指令（語言）完成複雜的操作。

使用虛拟機語言描述的業務邏輯

虛拟機解釋器

完成實際操作任務的基本指令

實際的問題領域

實例：

大量的開發工具、二次開發工具體現了這一思想：微軟在其産品中大量使用的Visual Basic for Application，以及在AutoDesk産品中大量使用的AutoLisp語言，實際上就是給用戶提供了一種面向領域的語言，然後核心解釋執行這一語言的指令和指令序列。從而擴充産品的功能，方便用戶按照自己的需要定制系統。

優點：

非常好的擴展性，用戶可以實現對軟件系統的二次開發。

缺點：

軟件開發複雜，特别是這種指令集的設計非常困難。

是否可以采用一種成熟的語言作為二次開發的基礎（例如，基于Java）。

開發觀點

在實際開發過程中，簡單的判斷某一個具體的應用應該采取何種體系結構是非常困難的，簡單的管道、過濾器體系已經非常少見，面向對象的思想已經融合在幾乎所有的體系結構之中，而層次化的思想同樣也被廣泛使用，所以，一個基本的系統分析方法應該是功能和複雜性的分解，也就是說，從橫向分解（分模塊、子系統），縱向分解中得到系統的基本組件（分類、分層次的功能和對象）。然後根據問題領域的特性選擇系統的行為模式（具體的體系結構）。

常見結構

嚴格的層次結構

（系統可以清楚的分解成為不同的功能層次，例如基本的圖形庫，提供不同層次的繪圖接口）這種體系結構适合于系統的功能相對簡單，并且可以按照複雜的程度、抽象的程度、和硬件平台的關系等方面的特性加以分層的軟件中。

事件驅動的體系

對互操作性、特别是異構環境下的互操作性要求非常高的情況下，可以采用這種體系，當整個系統中存在大量的并發的，相互之間沒有邏輯聯系的組件的時候（例如操作系統或者圖形用戶界面）可以使用這種體系結構。現代軟件技術中微軟的COM和ISO的CORBA實際上都是這種體系結構的例子。

知識庫的體系

以大量數據為核心的系統采用這種體系，一些人工智能的應用同樣需要這種體系結構，面向對象的知識庫是這種體系結構的一個發展方向。将面向對象和層次化的思想引入知識庫系統中，将得到一種非常強大的體系結構。

基于解釋器的體系

如果應用系統和用戶的交互非常複雜，采用這種體系結構是最适合的方案，隻有将系統的基本操作以指令的形式提供給用戶，同時，提供一種簡單明了的語法和基本的數據操作、處理的功能，才能得到功能最強大、最靈活、具有最佳擴充新的應用系統；一個非常合适的例子是浏覽器，一開始，浏覽器隻是簡單的下載和顯示HTML的頁面，随着用戶對界面交互要求的發展，開發出javascript，提供一種語言和基本的界面元素操縱的指令來得到擴充性和強大的功能。

絕大多數實際運行的系統都是上面幾種體系結構的複合：在系統的某些部分采用一種體系結構而在其他的部分采用另外的體系，我們可以将複合幾種基本體系結構的系統稱作複合體系結構。在實際的系統分析和設計中，可能首先将整個系統作為一個功能體進行分析和權衡，得到适宜的、最上層的體系結構，如果該體系結構中的元素較為複雜，可以繼續進行分解，得到某一部分的，局部的體系。分析的層次應該在可以清晰的使用簡單的功能和界面描述表達結束，這樣，可以将我們在分析和設計的這一階段将焦點集中在系統的總體結構上，而避免引入和所使用的語言、實現所具體需要的技術等實現的細節上。