在上兩篇文章中，我們介紹了軟件體系結構的概念、現狀及發展方向，讀者可能會覺得"軟件體系結構太抽象、太理論化，沒有什么實際的東西"。然而，任何實踐都必須接受理論的指導，如果拋棄理論基礎，一味地追求實用，那也只能是囫圇吞棗。
　　軟件體系結構設計的一個核心問題是能否使用重復的體系結構模式，即能否達到體系結構級的軟件重用。也就是說，能否在不同的軟件系統中，使用同一體系結構。基于這個目的，學者們開始研究和實踐軟件體系結構的風格和類型問題。
　　軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。它反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組織成一個完整的系統。按這種方式理解，軟件體系結構風格定義了用于描述系統的術語表和一組指導構件系統的規則。
　　對軟件體系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是使用常用的、規范的方法來組織，就可使別的設計者很容易地理解系統的體系結構。例如，如果某人把系統描述為"客戶／服務器"模式，則不必給出設計細節，我們立刻就會明白系統是如何組織和工作的。
　　下面是Garlan和Shaw對通用體系結構風格的分類：
　　（1）數據流風格：批處理序列；管道/過濾器
　　（2）調用/返回風格：主程序/子程序；面向對象風格；層次結構
　　（3）獨立構件風格：進程通訊；事件系統
　　（4）虛擬機風格：解釋器；基于規則的系統
　　（5）倉庫風格：數據庫系統；超文本系統；黑板系統
　　限于篇幅，在本文中，我們將只介紹幾種主要的和經典的體系結構風格和它們的優缺點。有關新出現的軟件體系結構風格，將在后續文章中進行介紹。
一、C2風格
　　C2體系結構風格可以概括為：通過連接件綁定在一起的按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下：
　　（1）系統中的構件和連接件都有一個頂部和一個底部；
　　（2）構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；
　　（3）一個連接件可以和任意數目的其它構件和連接件連接；
　　（4）當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
　　圖1是C2風格的示意圖。圖中構件與連接件之間的連接體現了C2風格中構建系統的規則。

圖1 C2風格的體系結構
　　C2風格是最常用的一種軟件體系結構風格。從C2風格的組織規則和結構圖中，我們可以得出，C2風格具有以下特點：
　　（1）系統中的構件可實現應用需求，并能將任意復雜度的功能封裝在一起；
　　（2）所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的；
　　（3）構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
二、管道/過濾器風格
　　在管道/過濾器風格的軟件體系結構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然后產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這里的構件被稱為過濾器，這種風格的連接件就象是數據流傳輸的管道，將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性并不依賴于過濾器進行增量計算過程的順序。
　　圖2是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程序。Unix既提供一種符號，以連接各組成部分(Unix的進程)，又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編譯器。傳統的編譯器一直被認為是一種管道系統，在該系統中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另一個階段的輸入。

圖2 管道/過濾器風格的體系結構
　　管道/過濾器風格的軟件體系結構具有許多很好的特點：
　　（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；
　　（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；
　　（3）支持軟件重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；
　　（4）系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；
　　（5）允許對一些如吞吐量、死鎖等屬性的分析；
　　（6）支持并行執行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務并行執行。
　　但是，這樣的系統也存在著若干不利因素。
　　（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。
　　（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。
　　（3）因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，并增加了編寫過濾器的復雜性。
三、數據抽象和面向對象風格
　　抽象數據類型概念對軟件系統有著重要作用，目前軟件界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和面向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因為它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
　　圖3是數據抽象和面向對象風格的示意圖。


圖3 數據抽象和面向對象風格的體系結構
　　面向對象的系統有許多的優點，并早已為人所知：
　　（1）因為對象對其它對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其它的對象。
　　（2）設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
　　但是，面向對象的系統也存在著某些問題：
　　（1）為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象。
　　（2）必須修改所有顯式調用它的其它對象，并消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的。
四、基于事件的隱式調用風格
　　基于事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
　　從體系結構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中注冊一些過程，當發生這些事件時，過程被調用。
　　基于事件的隱式調用風格的主要特點是事件的觸發者并不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統也包含顯式調用作為構件交互的補充形式。
　　支持基于事件的隱式調用的應用系統很多。例如，在編程環境中用于集成各種工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變量監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程序可以卷屏到斷點，變量監視器刷新變量數值。而Debugger本身只聲明事件，并不關心哪些過程會啟動，也不關心這些過程做什么處理。
　　隱式調用系統的主要優點有：
　　（1）為軟件重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它注冊到系統的事件中。
　　（2）為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其它構件的接口。
　　隱式調用系統的主要缺點有：
　　（1）構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件注冊了哪些構件的構成，它也不能保證這些過程被 調用的順序。
　　（2）數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基于事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
　　（3）既然過程的語義必須依賴于被觸發事件的上下文約束，關于正確性的推理存在問題。
五、層次系統風格
　　層次系統組織成一個層次結構，每一層為上層服務，并作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
　　這種風格支持基于可增加抽象層的設計。這樣，允許將一個復雜問題分解成一個增量步驟序列的實現。由于每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件重用提供了強大的支持。
　　圖4是層次系統風格的示意圖。層次系統最廣泛的應用是分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作為上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。

圖4 層次系統風格的體系結構
　　層次系統有許多可取的屬性：
　　（1）支持基于抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解；
　　（2）支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；
　　（3）支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現方法。
　　但是，層次系統也有其不足之處：
　　（1）并不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出于對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；
　　（2）很難找到一個合適的、正確的層次抽象方法。
六、倉庫風格
　　在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互作用在系統中會有大的變化。
　　控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
　　圖4是黑板系統的組成。黑板系統的傳統應用是信號處理領域，如語音和模式識別。另一應用是松耦合代理數據共享存取。

圖4 黑板系統的組成
　　我們從圖4中可以看出，黑板系統主要由三部分組成：
　　（1）知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只通過黑板來完成。
　　（2）黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。
　　（3）控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
七、結束語
　　軟件體系結構風格為大粒度的軟件重用提供了可能。然而，對于應用體系結構風格來說，由于視點的不同，系統設計師有很大的選擇空間。要為系統選擇或設計某一個體系結構風格，必須根據特定項目的具體特點，進行分析比較后再確定，體系結構風格的使用幾乎完全是特化的。
　　在本文中，我們只講述了"純"的體系結構。但是，從上面的介紹中，我們知道，不同的結構有不同的處理能力的強項和弱點，一個系統的體系結構應該根據實際需要進行選擇，以解決實際問題。事實上，也存在一些系統，它們是由這些純體系結構組合而成，即采用了異構軟件體系結構。關于軟件體系結構的異構問題，我們將在后續文章中進行介紹。

總結

以上是生活随笔為你收集整理的软件体系结构的风格（转载）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。