軟件體系結構的五種主要風格類型分析

　　摘要： 本文簡述了軟件體系結構的定義，探討了Mary shaw和Daviad Garlan所提出的五種風格，即數據流風格、調用/返同風格、獨立組件風格、獨立組件風格、虛擬機風格、倉庫風格軟件體系結構。
　　關鍵詞： 軟件體系結構定義風格類型
　　
　　一、什么是軟件體系結構
　　在所有對于軟件體系結構的定義中，我認為最有代表性的就是Hayes Roth所提出的：“認為軟件體系結構是一個抽象的系統規范，主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關系。”這樣的定義，我認為從根本上描述了軟件體系結構所要做的事情，是一個很概括的規范化公式。與此同時，在定義各式各樣的“構件”的時候，人們似乎一直在默認Dewayne Perry和A1ex Wo1f的定義，也就是：“軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連接構件把體系結構的不同部分組組合連接起來。”這一定義將處理構件、數據構件和連接構件區分了開來，明確了這三者在軟件體系結構中的組件性質，將這三者視為軟件體系結構的標準組成及探討對象。
　　在此基礎上，反復提到的則是Mary Shaw和David Garlan所提出的：“軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數據結構設計。體系結構問題包括總體組織和全局控制、通訊協議、同步、數據存取，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案間進行選擇等。軟件體系結構處理算法與數據結構之上關于整體系統結構設計和描述方面的一些問題，如全局組織和全局控制結構、關于通訊、同步與數據存取的協議，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現等。”這樣的定義，我認為進一步地提出了軟件體系結構的地位和所研究內容的具體情況，它提出了一個對于“控制”和“協議”的具體化要求，在以上定義的基礎上強調了軟件體系結構對于構架的調配和規劃功能，細分了軟件體系結構的內容。
　　除去Kruchten對于軟件體系結構“四個角度”，即概念角度、模塊角度、運行角度、代碼角度的定義，以及Barry Boehm和他的學生提出的關于強調“互聯及約束的集合”的概念之外，還有其他的定義方式。如Bass，Ctements和Kazman在1997年的《使用軟件體系結構》書中提出的：“關于一個程序或計算機系統的軟件體系結構包括一個或一組軟件構件、軟件構件的外部的可見特性及其相互關系。”其強調了“軟件外部的可見特性”，是指軟件構件提供的服務、性能、特性、錯誤處理、共享資源使用等。這一定義的特點在于把軟件體系結構提升，或者也可以說是限制在了軟件的“表征特性”上，這使得軟件體系結構有了更緊縮、健康的概念。
　　我在思考對于軟件體系結構的定義的時候，并沒有一個標準的答案，因為我在拜讀其他名家的定義的時候發現，它們有著很多相似之處，也各自有著突出的特點與不足，這使得我無論是出于尊敬還是出于對自己認識層次的保留，都不愿意給出一個自己所謂的“定義”，但是可以說的是，所謂軟件體系結構，是一種思想方式，也是一種分析方式和控制方式，這種方式的對象，是軟件（廣義）的——主要是創建過程中的—結構和統一規范的建議，其表現形式是構件化的描述體系。這樣的一種理解方式，也就是我上面所提及的在前輩們定義的軟件體系結構中的三個要素：（1）構件性——軟件體系結構由三個構件組成：處理構件、數據構件和連接構件；（2）控制性——軟件體系結構的作用是在“控制”和“協議”層次上；（3）表征性——軟件體系結構的對象，是“軟件外部的可見特性”。
　　二、常見軟件體系結構風格
　　所謂軟件體系結構風格是指：“描述某一特定應用領域中系統組織方式的慣用模式。”它反映了領域中眾多系統所共有的結構和語義特性，并指導如何將各個模塊和子系統有效地組65eeb92b2f48f684fae477c3a96da689織成一個完整的系統。按這種方式理解，軟件體系結構風格是指：“定義了用于描述系統的術語表和一組指導構件系統的規則。”對軟件體系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是采用常用的、規范的方法來組織，就可使別的設計者很容易地理解系統的體系結構。
　　軟件體系結構風格有很多種，現在我主要分析的是Mary Shaw和David Garlan所提出的五種主要風格類型，也就是：（1）數據流風格，包括批處理序列，管道/過濾器形式等；（2）調用/返回風格，包括主程序/子程序，面向對象風格，分層結構等；（3）獨立組件風格，包括進程通訊，事件系統等；（4）虛擬機風格，包括解釋器，基于規則的系統等；（5）倉庫風格，包括中心數據庫系統，黑板系統等。
　　這五種風格各有各的特點，也有共同之處，下面我將逐一分析這些風格。
　　1.數據流風格
　　這是一種最常見、結構最為簡單的軟件體系結構。在這樣的結構體系下，所有的數據按照流的形式在執行過程中前進，不存在結構的反復和重構。在流動過程中，數據經過序列間的數據處理組件進行處理，然后將處理結果向后傳送，最后進行輸出，這也就是說，最簡單和直接的數據流風格是單向的，沒有返回的流水線系統。但是在實際應用中，并不一定限制數據處理組件的順序，其運算的先后順序不影響最終系統結構的正確性。這種風格很容易用管道/過濾器的形式（見下圖）來解釋。
　　
　　
　　
　　
　　
　　
　　
　　上圖所表示的就是一個管道/過濾器的形式，我在隨處可見的理論圖的原型基礎上只保留了其中必要的過濾器塊，而用三種不同形式的數據流表示了數據的行進過程，這三種情況分別是單向流水、非順序流水和回流。其中：
　　表示了一種正向的流水方式，也就是最常見的、最直觀的數據流方式，在這種方式中，正向數據管道引導數據的正向流動，在此時，我們可以將整個的上方三個過濾器所組成的正向通道作為一個完整的“管道”，這是一種廣義的管道。此時，數據從左方，也就是管道的入口處進入，再經過過濾器的處理，最終由“管道”的結尾處流出。
　　表示了一種打亂（更改）了順序的管道方式，交換了其中兩個過濾器的順序，這樣的結構在實際中是允許的，并且不影響管道/過濾器輸出的正確性。其前提條件是，每個過濾器必須是獨立的實體，它不能與其他的過濾器共享數據，而且一個過濾器不知道它上游和下游的標志。同樣，也可以把這樣的結構視為廣義的“管道”。
　　表示了一種回流方式，即某些數據可能經由一些管道回流，以通過過濾器的結果數據形式，重新通過過濾器，這種情況下的回流發生在上述廣義“管道”內部，而不是像上述兩種情況。在上述兩種情況之中，也可以存在這種回流方式，只不過回流的情況是返回源頭，重新參加數據的流動過程，略有不同。
　　此種風格的優點：（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；（3）支持軟件重用。主要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；（4）系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來，舊的可以被改進的過濾器替換掉；（5）允許對一些如吞吐量、死鎖等屬性的分析；（6）支持并行執行。每個過濾器是作為一個單獨的任務完成，因此可與其他任務并行執行。
　　
　　此種風格的缺點：（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換；（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重；（3）因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，并增強了編寫過濾器的復雜性。
　　總之，此種風格最大的特點在于簡單獨立，這就使其具備簡便易用的優勢及不夠豐富靈活的劣勢，是一種很基礎的風格。
　　2.調用/返回風格
　　這是一種相對更為常用的風格，在這種風格之中，程序之間不再像“過濾器”那樣“必須是獨立的實體”，而是有了更為豐富的相互聯系，此種情況分很多種，具體到實際應用中的類型，比如子程序調用，面向對象結構化設計，以及分層式系統結構等。這些風格有一個共同的特點，也就是存在一個類似與軟件體系結構之對于軟件開發的關系的一種迭代關系，即我理解的這種風格，實際上是一種在軟件體系結構中套用軟件體系結構的過程。
　　比如對于主/子程序的調用，在一定環境中，子程序是一段段獨立存在的，負責承擔相應功能模塊功能的個體，而事實上，主程序并不能（指廣泛意義上講）實現其所需要的功能，或者需要重復冗余代碼來實現，在此時，采用子程序的調用會給這種情況帶來比較好的解決方法，對于一個程序來說，特別是當該程序是由相對獨立的功能模塊組成的時候，特別是在這種功能模塊的調用成為一種長期的、多次的情況的時候，采用將模塊設計成子程序由主程序視情況而進行調用，是一種很好的解決辦法。
　　在面向對象的設計中更是如此，最明顯的例子就是抽象數據類型的提出，對于抽象數據類型（A.D.T.）這種描述方式來說，更可以將此種方式作為一種對于軟件體系結構的深層套用。而在分層系統中，按照功能模塊所處的功能層次進行分解，并由高級調用低級，最終形成金字塔形的整體結構，這樣的環境其實在現實的程序環境中是很常見的。對比我們現存的語言環境的分層結構，即高級語言對低級語言的透明調用，也就是這種情況的廣義示例，只不過在現實的應用中，我們更多的是在統計的語言環境中，對于所需開發的軟件進行功能應用上的分層，而不再注重語言環境上的層次關系（如下圖所示）。
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　以上說明的是主/子程序的調用過程，也是最為廣泛應用的設計模型。數據抽象和面向對象的風格特點：抽象數據類型概念對軟件系統有著重要作用，目前軟件界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和面向對象的基礎上，“數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中”。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因為它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
　　此種風格的優點：（1）其可以改變一個對象的表示，而不影響其他的對象，因為該對象對其他對象隱藏其表示，這可以使該對象更獨立，對象的更新更安全；（2）設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合，而不必一切都堆放在一起，提高了進程效率。
　　此種風格的缺點：（1）為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象，造成了結構修改的復雜；（2）“必須修改所有顯式調用它的其他對象，并消除由此帶來的一些副作用”也就是說，同時調用一個對象的兩者，并不能保證他們對這個對象的操作會不會帶來同步上的問題及相互的影響。
　　3.獨立組件風格
　　獨立組件的風格很常用常見，在互聯網上廣為流傳的集群計算就是這樣的風格，但是不管什么樣的表現形式，都有統一的特點，也就是組件的獨立性和獨立組件間的協同性。在這種風格中，最簡單常見，卻容易被人忽視的就是基于事件的隱式調用，下面進行具體分析。
　　“基于事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件”。系統中的其他構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣一個事件的觸發就導致了另一模塊中的過程的調用。從體系結構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。“過程可以用通用的方式調用，也可以在系統事件中注冊一些過程，當發生這些事件時，過程被調用”。基于事件的隱式調用風格的主要特點是事件的觸發者并不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統包含顯式調用作為構件交互的補充形式。支持基于事件的隱式調用的應用系統很多，“例如，在編程環境中用于集成各種工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查”。
　　此種風格的優點：（1）為軟件重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它注冊到系統的事件中；（2）為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其他構件的接口。
　　此種風格的缺點：（1）構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其他構件是否會響應它。而且即使它知道事件注冊了哪些構件的構成，也不能保證這些過程被調用的順序；（2）數據交換的問題。有時數據可被一個事件傳遞，但在另一些情況下，基于事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題；（3）既然過程的語義必須被觸發事件的上下文約束，關于正確性的推理就存在問題。
　　4.虛擬機風格
　　虛擬機的風格在討論中并沒有作為重點，是因為它其實更像是一種軟件體系結構中的應用層次。層次系統組織成一個層次結構，每一層為上層服務，并作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。在這樣的系統中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
　　這種風格支持基于可增加抽象層的設計，這樣允許將一個復雜問題分解成一個增量步驟序列的實現。每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件重用提供強大的支持。
　　此種風格的優點：（1）支持基于抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解；（2）支持功能增強，因為每一層至多和相鄰的上下層交互，所以功能的改變最多影響相鄰的上下層；（3）支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣就可以定義一組標準的接口，而允許各種不同的實現方法。
　　此種風格的缺點：（1）并不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出于對系統性能的考慮，也不得不把一些低級或高級的功能綜合起來；（2）很難找到一個合適的、正確的層次抽象方法。
　　5.倉庫風格
　　倉庫風格事實上就是一種基于數據庫的體系結構，“在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存儲上執行，倉庫與外構件間的相互作用在系統中會有大的變化”。控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型數據庫；若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
　　對于這種結構的討論也不需要太多，因為這種結構太過常用和標準，甚至不用去分析它的優缺點，因為就現實的情況來說，還沒有什么系統有可能或者說有希望取代這樣的一種風格，其必然會在相當長的時間段里占據主導地位。
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　其組成：（1）知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只通過黑板來完成；（2）黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題；（3）控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
　　至此，軟件體系結構是一門很抽象的學科，值得研究和大膽探求，接下來需要更加深入地學習其他的相關知識。
　　
　　參考文獻：
　　［1］覃征，何堅，謝國彤，王志敏，張麗，王向華.軟件體系結構［M］.西安：西安交通大學出版社，2002.12.
　　［2］Frank Buschmann等著，賁可榮等譯.面向模式的軟件體系結構［M］.卷1：模式系統.北京：機械工業出版社，2003.1.
　　［3］謝曉芹，梁邦勇.框架不是框框——應用框架的基本思想［J］.計算機世界報，第04期B6、B7．http:∥www.huihoo.com/patterns/framework/4.html.