管道/過濾器
在 管道/過濾器風格的軟件體系結構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然後產生輸出數據流。這個過程通常通過對輸入流的變 換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這裏的構件被稱爲過濾器，這種風格的連接件就象是數據流傳輸的管道，將一個過濾器的 輸出傳到另一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道 /過濾器網絡輸出的正確性並不依賴於過濾器進行增量計算過程的順序。
下圖是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程序。Unix既提供一種符號，以連接各組成部分(Unix的進程)，又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編譯器。傳統的編譯器一直被認爲是一種管道系統，在該系統中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另一個階段的輸入。
管道/過濾器風格的體系結構
管道/過濾器風格的軟件體系結構具有許多很好的特點：
（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；
（2）允許設計者將整個系統的輸入/輸出行爲看成是多個過濾器的行爲的簡單合成；
（3）支持軟件重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；
（4）系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；
（5）允許對一些如吞吐量、死鎖等屬性的分析；
（6）支持並行執行。每個過濾器是作爲一個單獨的任務完成，因此可與其它任務並行執行。
但是，這樣的系統也存在着若干不利因素。
（1）通常導致進程成爲批處理的結構。這是因爲雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。
（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤爲嚴重。
（3）因爲在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，並增加了編寫過濾器的複雜性。
數據抽象和麪向對象組織
抽象數據類型概念對軟件系統有着重要作用，目前軟件界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和麪向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因爲它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
下圖是數據抽象和麪向對象風格的示意圖。
面向對象的系統有許多的優點，並早已爲人所知：
（1）因爲對象對其它對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其它的對象。
（2）設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
但是，面向對象的系統也存在着某些問題：
（1）爲了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象。
（2）必須修改所有顯式調用它的其它對象，並消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那麼，C對B的使用所造成的對A的影響可能是料想不到的。
基於事件的隱式調用
基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
從體系結構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中註冊一些過程，當發生這些事件時，過程被調用。
基於事件的隱式調用風格的主要特點是事件的觸發者並不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統也包含顯式調用作爲構件交互的補充形式。
支持基於事件的隱式調用的應用系統很多。例如，在編程環境中用於集成各種工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變量監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程序可以卷屏到斷點，變量監視器刷新變量數值。而Debugger本身只聲明事件，並不關心哪些過程會啓動，也不關心這些過程做什麼處理。
隱式調用系統的主要優點有：
（1）爲軟件重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它註冊到系統的事件中。
（2）爲改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其它構件的接口。
隱式調用系統的主要缺點有：
（1）構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件註冊了哪些構件的構成，它也不能保證這些過程被 調用的順序。
（2）數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基於事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
（3）既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。
分層系統
層 次系統組織成一個層次結構，每一層爲上層服務，並作爲下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統 中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
這種風格支持基於可增加抽象層的設計。這樣，允許將一個複雜問題分解成一個增量步驟序列的實現。由於每一層最多隻影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣爲軟件重用提供了強大的支持。
上圖是層次系統風格的示意圖。層次系統最廣泛的應用是分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作爲上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。
層次系統有許多可取的屬性：
（1）支持基於抽象程度遞增的系統設計，使設計者可以把一個複雜系統按遞增的步驟進行分解；
（2）支持功能增強，因爲每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；
（3）支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現方法。
但是，層次系統也有其不足之處：
（1）並不是每個系統都可以很容易地劃分爲分層的模式，甚至即使一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；
（2）很難找到一個合適的、正確的層次抽象方法。
倉庫系統及知識庫
在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互作用在系統中會有大的變化。
控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
下圖是黑板系統的組成。
黑板系統的傳統應用是信號處理領域，如語音和模式識別。另一應用是鬆耦合代理數據共享存取。
我們從圖中可以看出，黑板系統主要由三部分組成：
（1）知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只通過黑板來完成。
（2）黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。
（3）控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
C2體系結構
C2體系結構風格可以概括爲：通過連接件綁定在一起的按照一組規則運作的並行構件網絡。C2風格中的系統組織規則如下：
（1）系統中的構件和連接件都有一個頂部和一個底部；
（2）構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；
（3）一個連接件可以和任意數目的其它構件和連接件連接；
（4）當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
下圖是C2風格的示意圖。圖中構件與連接件之間的連接體現了C2風格中構建系統的規則。
C2風格是最常用的一種軟件體系結構風格。從C2風格的組織規則和結構圖中，我們可以得出，C2風格具有以下特點：
（1）系統中的構件可實現應用需求，並能將任意複雜度的功能封裝在一起；
（2）所有構件之間的通訊是通過以連接件爲中介的異步消息交換機制來實現的；
（3）構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
C/S體系結構
C/S 結構的基本原則是將計算機應用任務分解成多個子任務，由多臺計算機分工完成，即採用“功能分佈”原則。客戶端完成數據處理，數據表示以及用戶接口功能；服務器端完成DBMS（數據庫管理系統）的核心功能。這種客戶請求服務、服務器提供服務的處理方式是一種新型的計算機應用模式。
下圖是C/S 風格的示意圖
C/S結構的優點是能充分發揮客戶端PC的處理能力，很多工作可以在客戶端處理後再提交給服務器。對應的優點就是客戶端響應速度快。具體表現在以下兩點：
（1）應用服務器運行數據負荷較輕。
（2）數據的儲存管理功能較爲透明。
C/S結構主要暴露的缺點有以下幾點：
（1）開發成本較高。
（2）客戶端程序設計複雜。
（3）軟件移植，維護和升級困難。
三層C/S體系結構
針對二層C/S體系結構的缺點，三層C/S體系結構應運而生。其結構如下圖所示。在三層C/S體系結構中，增加了一個應用服務器。可以將整個應用邏輯駐留在應用服務器上，而只有表示層存在於客戶機上。這種結構被稱爲"瘦客戶機"。三層C/S體系結構是將應用功能分成表示層、功能層和數據層三個部分。
三層C/S體系結構的優點如下：
（1）由於數據訪問是通過中間層進行的，因此客戶端不再與數據庫直接建立數據連接。也就是說，建立在數據庫服務器上的連接數量將大大減少。例如一個500個客戶端的應用系統，500個客戶端分別與中間層服務器建立DCOM連接，而DCOM通訊所佔用的系統資源極爲有限，並且是動態建立與釋放連接，因此客戶端數量將不再受到限制。同時，中間層與數據庫服務器之間的數據連接通過“連接池”進行連接數量的控制，動態分配與釋放數據連接，因此數據連接的數量將遠遠小於客戶端數量。
（2）可維護性得以提高。因爲業務規則、合法性校驗存在於中間層，因此當業務規則發生改變時，只需更改中間層服務器上的某個組件（如某個DLL文件），而客戶端應用程序不需做任何處理，有些時候，甚至不必修改中間層組件，只需要修改數據庫中的某個存儲過程就可以了。
（3）良好的可重用性。同樣，如果需要開發B/S應用，則不必要重新進行數據訪問、業務規則等的開發，可以直接在WEB服務器端調用現有的中間層（如可以採用基於IIS的WebClass開發，或直接編寫ASP代碼）。
（4）事務處理更加靈活，可以在數據庫端、組件層、MTS（或COM+）管理器中進行事務處理。
B/S體系結構
B/S結構（Browser/Server，瀏覽器/服務器模式），是WEB興起後的一種網絡結構模式，WEB瀏覽器是客戶端最主要的應用軟件。這種模式統一了客戶端，將系統功能實現的核心部分集中到服務器上，簡化了系統的開發、維護和使用。客戶機上只要安裝一個瀏覽器，如Netscape Navigator或Internet Explorer，服務器安裝SQL Server、Oracle、MYSQL等數據庫。瀏覽器通過Web Server 同數據庫進行數據交互。B/S結構如下:
它的特點有：
（1）維護和升級方式簡單。
（2）成本降低，選擇更多。
（3）應用服務器運行數據負荷較重。由於B/S架構管理軟件只安裝在服務器端（Server）上，網絡管理人員只需要管理服務器就行了，用戶界面主要事務邏輯在服務器（Server）端完全通過WWW瀏覽器實現，極少部分事務邏輯在前端（Browser）實現，所有的客戶端只有瀏覽器，網絡管理人員只需要做硬件維護。但是，應用服務器運行數據負荷較重，一旦發生服務器“崩潰”等問題，後果不堪設想。因此，許多單位都備有數據庫存儲服務器，以防萬一。
CORBA體系結構
CORBA（Common Object Request Broker Architecture,公共對象請求代理體系結構，通用對象請求代理體系結構）是由OMG組織制訂的一種標準的面向對象應用程 序體系規範。或者說 CORBA體系結構是對象管理組織（OMG）爲解決分佈式處理環境(DCE)中，硬件和軟件系統的互連而提出的一種解決方案；OMG組織是一個國際性的非盈利組織，其職責是爲應用開發提供一個公共框架，制訂工業指南和對象管理規範，加快對象技術的發展。
結構如下：
它是面向對象的軟件，以數據爲中心設計，對象類既具有模塊的封裝性和類屬等特性，還具有繼承特性，極大地提高了類的可擴充性和可再用能力。對象類較之於傳統軟件的功能模塊而另具有的優點是：
（1）易於理解，具有完整的語義特徵；
（2）易於擴充和修改，具有較高的通用性和適應性；
（3）易於構造組裝，具有規範的外部接口。
正交軟件體系結構
正交軟件結構的基本思想是把應用系統的結構按功能的正交相關性。垂直分割爲多個線索。線索又分爲幾個層次。每個線索由多個具有不同層次功能和不同抽象水平的組件構成。而各線索的相同層次的組件。即同一層中的組件具有相同的抽象水平。對於大型複雜軟件系統。每一條線索又可以按類似的方法劃分爲若干條子線索。其子線索還可劃分爲更低一級的子線索。形成多級正交結構。
正交結構對於降低軟件進化的複雜性具有以下優點：
（1）易理解性!結構十分清晰。擁有本應用領域一些專業知識的用戶能夠通過閱讀結構功能說明來了解每一個組件的功用。
（2）自適應性!組件是軟件的基本量子。它既足夠大。因而有功能的。能重用的。又足夠小。因而易於維護/修改和進化。因而對組件的局部修改不會影響整個軟件的體系結構。
（3）結構易調整性!由於採用垂直線索組件族結構。當要增加或刪除一個功能時。只要增加或刪除一個線索組件族就可以了。
（4）結構可重用性!對於軟件環境的較大變更。體系結構是可重用的。
JB/HMB（基於層次消息總線）的體系結構
JB/HMB 風格基於層次消息總線支持構件的分佈和併發, 構件之間通過消息總線進行通訊,如圖1 所示。 消息總線是系統的連接件, 負責消息的分派傳遞和過濾以及處理結果的返回。 各個構件掛接在消息總線上, 向總線登記感興趣的消息類型。 構件根據需要發出消息, 由消息總線負責把該消息分派到系統中所有對此消息感興趣的構件, 消息是構件之間通訊的唯一方式。 構件接收到消息後, 根據自身狀態對消息進行響應, 並通過總線返回處理結果。 由於構件通過總線進行連接, 並不要求各個構件具有相同的地址空間或侷限在一臺機器上。
對JB/HMB 風格的主要特點作一總結。
(1) 從接口結構和行爲方面對構件進行刻畫。 在JB/HMB 風格中, 構件的描述包括接
口靜態結構和動態行爲3 個方面。
(2) 接口: 構件可以提供一個或多個接口, 每個接口定義了一組發送和接收的消息集合,
刻畫了構件對外提供的服務以及要求的環境服務, 接口之間可以通過繼承表達相似性。
(3) 靜態結構: 複合構件是由子構件通過局部消息總線連接而成的, 形成該複合構件的
內部結構。
(4) 動態行爲: 構件行爲通過帶輸出的有限狀態機刻畫, 構件接收到外來消息後, 不但根據消息類型, 而且根據構件當前所處的狀態對消息進行響應, 並導致狀態的變遷。
(5) 基於層次消息總線。 消息總線是系統的連接件, 負責消息的傳遞過濾和分派, 以及
處理結果的返回。 各個構件掛接在總線上, 向系統登記感興趣的消息。 構件根據需要發出消息,由消息總線負責把該消息分派到系統中對此消息感興趣的所有構件。 構件接收到消息後, 根據自身狀態對消息進行響應, 並通過總線返回處理結果。 由於構件通過總線進行連接, 並不要求各個構件具有相同的地址空間或侷限在一臺機器上, 系統具有併發和分佈的特點。 系統和複合構件可以逐層分解, 子構件通過(局部)消息總線相連。 每條消息總線分別屬於系統和各層次的複合構件, 我們把這種特徵的總線稱爲層次消息總線。 在系統開發方面, 由於各層次的總線局部在相應的複合構件中, 因此可以更好地支持系統的構造性和演化性。
(6) 統一描述系統和組成系統的構件。 組成系統的構件通過消息總線進行連接, 複雜構
件又可以分解爲比較簡單的子構件, 通過局部消息總線進行連接, 如果子構件仍然比較複雜,可以進一步分解。 系統呈現出樹狀的拓撲結構。 另外, 整個系統也可以作爲一個構件, 集成到更大的系統中。 於是, 就可以對整個系統和組成系統的各層構件採用統一的方式進行描述。
(7) 支持運行時刻的系統演化。 系統的持續可用性是許多重要的應用系統的一個關鍵性
要求, 運行時刻的系統演化可減少因關機和重新啓動而帶來的損失和風險。 JB/HMB 風格方便地支持運行時刻的系統演化, 主要包括動態增加或刪除構件動態改變構件響應的消息類型和消息過濾。
異構結構
不同的體系結構有不同的處理能力，面對具體問題，混合軟件體系結構處理問題能夠結合各自的優點，這種體系結構被稱爲異構結構。
異構結構風格特點主要體現在構建協調上，它有這樣幾種形式：
（1）形式A改變成B的形式。
（2）公佈A的形式的抽象化信息。
（3）在數據傳輸過程中從A的形式轉變到B的形式。
（4）通過協商，達到一個統一的形式。
（5）使B成爲支持多種形式。
（6）爲B提供進口/出口轉換器
（7）引入中間形式。
（8）在A上添加一個適配器或安裝包。
（9）保持對A和B的版本並行一致。
SASIS軟件體系結構
SIS（互聯繫統構成的系統）是指系統可分爲若干不同部分，每個部分作爲獨立系統開發。整個系統通過一組互聯繫統實現，而互聯繫統之間互相通信，履行系統的職責。其中一個系統體現整體性能，稱爲上級系統；其餘系統代表整體的一個部分，稱爲從屬系統。從上級系統角度看，從屬系統是子系統，上級系統獨立於其從屬系統，每個從屬系統僅僅是上級系統模型中所指定內容的一個實現，並不屬於上級系統功能約束的一部分。這樣的系統的軟件體系結構稱爲SASIS。
SASIS具有以下優點：
（1）使用“分而治之”的原則來理解系統，能有效地降低系統的複雜性。
（2）因爲各從屬系統相對獨立，自成系統，提高了系統開發的並行性。
（3）當某從屬系統的需求發生變化事務，不必開發新版本的上級系統，只需對該從屬系統內部構件進行變更，提高了系統的可維護性。
然而，SASIS也有固定的缺點，如資源管理開銷增大，各從屬系統的開發進度無法同步等等。
DSSA軟件體系結構
簡單的說，DSSA就是在一個特定應用領域中爲一組應用提供組織結構參考的標準軟件體系結構。它有如下特點：
（1）一個嚴格定義的問題域/解決域。
（2）具有普遍性，使其可以用於領域中某個特定應用的開發。
（3）對整個領域合適程度的抽象。
（4）具備該領域固定的、典型的在開發過程中可重用元素。