軟體體系結構:定義,發展歷史,套用現狀,影響,體系風格,發展方向,圖書,圖書信息,

軟體體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連線構件。處理構件負責對數據進行加工，數據構件是被加工的信息，連線構件把體系結構的不同部分組合連線起來。這一定義注重區分處理構件、數據構件和連線構件，這一方法在其他的定義和方法中基本上得到保持。

基本介紹

中文名：軟體體系結構
外文名：software architecture
定義：具有一定形式的結構化元素
組成：處理構件、數據構件
套用：軟體工程

定義,發展歷史,套用現狀,影響,體系風格,發展方向,圖書,圖書信息,內容簡介,目錄,

定義

雖然軟體體系結構已經在軟體工程領域中有著廣泛的套用，但迄今為止還沒有一個被大家所公認的定義。許多專家學者從不同角度和不同側面對軟體體系結構進行了刻畫，較為典型的定義有：

（1）Mary Shaw和David Garlan認為軟體體系結構是軟體設計過程中的一個層次，這一層次超越計算過程中的算法設計和數據結構設計。體系結構問題包括總體組織和全局控制、通訊協定、同步、數據存取，給設計元素分配特定功能，設計元素的組織，規模和性能，在各設計方案間進行選擇等。軟體體系結構處理算法與數據結構之上關於整體系統結構設計和描述方面的一些問題，如全局組織和全局控制結構、關於通訊、同步與數據存取的協定，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現等

（2）Kruchten指出，軟體體系結構有四個角度，它們從不同方面對系統進行描述：概念角度描述系統的主要構件及它們之間的關係；模組角度包含功能分解與層次結構；運行角度描述了一個系統的動態結構；代碼角度描述了各種代碼和庫函式在開發環境中的組織。

（3）Hayes Roth則認為軟體體系結構是一個抽象的系統規範，主要包括用其行為來描述的功能構件和構件之間的相互連線、接口和關係。

（4）David Garlan和Dewne Perry於1995年在IEEE軟體工程學報上又採用如下的定義：軟體體系結構是一個程式/系統各構件的結構、它們之間的相互關係以及進行設計的原則和隨時間進化的指導方針。

（5）Barry Boehm和他的學生提出，一個軟體體系結構包括一個軟體和系統構件，互聯及約束的集合；一個系統需求說明的集合；一個基本原理用以說明這一構件，互聯和約束能夠滿足系統需求。

（6）1997年，Bass，Ctements和Kazman在《使用軟體體系結構》一書中給出如下的定義：一個程式或計算機系統的軟體體系結構包括一個或一組軟體構件、軟體構件的外部的可見特性及其相互關係。其中，"軟體外部的可見特性"是指軟體構件提供的服務、性能、特性、錯誤處理、共享資源使用等。

發展歷史

與最初的大型中央主機相適應，最初的軟體結構體系也是Mainframe結構，該結構下客戶、數據和程式被集中在主機上，通常只有少量的GUI界面，對遠程資料庫的訪問比較困難。隨著PC的廣泛套用，該結構逐漸在套用中被淘汰。在80年代中期出現了Client/Server 分散式計算結構，應用程式的處理在客戶（PC機）和伺服器（Mainframe或Server）之間分擔；請求通常被關係型資料庫處理，PC機在接受到被處理的數據後實現顯示和業務邏輯；系統支持模組化開發，通常有GUI界面。Client/Server結構因為其靈活性得到了極其廣泛的套用。但對於大型軟體系統而言，這種結構在系統的部署和擴展性方面還是存在著不足。

Internet的發展給傳統套用軟體的開發帶來了深刻的影響。基於Internet和Web的軟體和套用系統無疑需要更為開放和靈活的體系結構。隨著越來越多的商業系統被搬上Internet，一種新的、更具生命力的體系結構被廣泛採用，這就是為我們所知的“三層/多層計算”。

。客戶層（client tier）用戶接口和用戶請求的發出地，典型套用是網路瀏覽器和胖客戶（如Java程式）

。伺服器層（server tier）典型套用是Web伺服器和運行業務代碼的應用程式伺服器

。數據層（data tier）典型套用是關係型資料庫和其他後端（back-end）數據資源, 如 Oracle和SAP、 R/3等

三層體系結構中，客戶（請求信息）、程式（處理請求）和數據（被操作）被物理地隔離。三層結構是個更靈活的體系結構，它把顯示邏輯從業務邏輯中分離出來，這就意味著業務代碼是獨立的，可以不關心怎樣顯示和在哪裡顯示。業務邏輯層現在處於中間層，不需要關心由哪種類型的客戶來顯示數據，也可以與後端系統保持相對獨立性，有利於系統擴展。三層結構具有更好的移植性，可以跨不同類型的平台工作，允許用戶請求在多個伺服器間進行負載平衡。三層結構中安全性也更易於實現，因為應用程式已經同客戶隔離。應用程式伺服器是三層/多層體系結構的組成部分，應用程式伺服器位於中間層。

如圖所示，應用程式伺服器運行於瀏覽器和數據資源之間，一個簡單的實例是，顧客從瀏覽器中輸入一個定單，web伺服器將該請求傳送給應用程式伺服器，由應用程式伺服器執行處理邏輯，並且獲取或更新後端用戶數據。

興起

六十年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和算法的選擇上，隨著軟體系統規模越來越大、越來越複雜，整個系統的結構和規格說明顯得越來越重要。軟體危機的程度日益加劇，現有的軟體工程方法對此顯得力不從心。對於大規模的複雜軟體系統來說，對總體的系統結構設計和規格說明比起對計算的算法和數據結構的選擇已經變得明顯重要得多。在此種背景下，人們認識到軟體體系結構的重要性，並認為對軟體體系結構的系統、深入的研究將會成為提高軟體生產率和解決軟體維護問題的新的最有希望的途徑。自從軟體系統首次被分成許多模組，模組之間有相互作用，組合起來有整體的屬性，就具有了體系結構。好的開發者常常會使用一些體系結構模式作為軟體系統結構設計策略，但他們並沒有規範地、明確地表達出來，這樣就無法將他們的知識與別人交流。軟體體系結構是設計抽象的進一步發展，滿足了更好地理解軟體系統，更方便地開發更大、更複雜的軟體系統的需要。

事實上，軟體總是有體系結構的，不存在沒有體系結構的軟體。體系結構（Architecture）一詞在英文裡就是"建築"的意思。把軟體比作一座樓房，從整體上講，是因為它有基礎、主體和裝飾，即作業系統之上的基礎設施軟體、實現計算邏輯的主體應用程式、方便使用的用戶界面程式。從細節上來看每一個程式也是有結構的。早期的結構化程式就是以語句組成模組，模組的聚集和嵌套形成層層調用的程式結構，也就是體系結構。結構化程式的程式（表達）結構和（計算的）邏輯結構的一致性及自頂向下開發方法自然而然地形成了體系結構。由於結構化程式設計時代程式規模不大，通過強調結構化程式設計方法學，自頂向下、逐步求精，並注意模組的耦合性就可以得到相對良好的結構，所以，並未特別研究軟體體系結構。

我們可以作個簡單的比喻，結構化程式設計時代是以磚、瓦、灰、沙、石、預製梁、柱、屋面板蓋平房和小樓，而面向對象時代以整面牆、整間房、一層樓梯的預製件蓋高樓大廈。構件怎樣搭配才合理？體系結構怎樣構造容易？重要構件有了更改後，如何保證整棟高樓不倒？每種套用領域需要什麼構件（醫院、工廠、旅館）？有哪些實用、美觀、強度、造價合理的構件骨架使建造出來的建築（即體系結構）更能滿足用戶的需求？如同土木工程進入到現代建築學一樣，軟體也從傳統的軟體工程進入到現代面向對象的軟體工程，研究整個軟體系統的體系結構，尋求建構最快、成本最低、質量最好的構造過程。

軟體體系結構雖脫胎於軟體工程，但其形成同時借鑑了計算機體系結構和網路體系結構中很多寶貴的思想和方法，最近幾年軟體體系結構研究已完全獨立於軟體工程的研究，成為計算機科學的一個最新的研究方向和獨立學科分支。軟體體系結構研究的主要內容涉及軟體體系結構描述、軟體體系結構風格、軟體體系結構評價和軟體體系結構的形式化方法等。解決好軟體的重用、質量和維護問題，是研究軟體體系結構的根本目的。

套用現狀

形成研究熱點，仍處於非形式化水平

自20世紀90年代後期以來，軟體體系結構的研究成為一個熱點。廣大軟體工作者已經認識到軟體體系結構研究的重大意義和它對軟體系統設計開發的重要性，開展了很多研究和實踐工作。

從軟體體系結構研究的現狀來看，當前的研究和對軟體體系結構的描述，在很大程度上來說還停留在非形式化的基礎上。軟體構架師仍然缺乏必要的工具，這種工具應該是顯式描述的、有獨立性的形式化工具。

在目前通用的軟體開發方法中，其描述通常是用非形式化的圖和文本，不能描述系統期望的存在於構件之間的接口，不能描述不同的組成系統的組合關係的意義。難以被開發人員理解，更不能用來分析其一致性和完整性等特性。

當一個軟體系統中的構件之間幾乎以一種非形式化的方法描述時，系統的重用性也會受到影響，在設計一個系統結構過程中的努力很難移植到另一個系統中去。對系統構件和連線關係的結構化假設沒有得到顯式的、形式化的描述時，把這樣的系統構件移植到另一個系統中去將是有風險的，甚至是不可能的。

軟體體系結構的形式化方法研究

軟體體系結構研究如果僅僅停留在非形式化的框圖階段，已經難以適應進一步發展的需要。為支持基於體系結構的開發，需要有形式化建模符號、體系結構說明的分析與開發工具。從軟體體系結構研究的現狀來看，在這一領域近來已經有不少進展，其中比較有代表性的是美國卡耐基梅隆大學（Carnegie Mellon University）的Robert J．A11en於l997年提出的Wright系統。Wright是-種結構描述語言，該語言基於一種形式化的、抽象的系統模型，為描述和分析軟體體系結構和結構化方法提供了一種實用的工具。Wright主要側重於描述系統的軟體構件和連線的結構、配置和方法。它使用顯式的、獨立的連線模型來作為互動的方式，這使得該系統可以用邏輯謂詞符號系統，而不依賴特定的系統實例來描述系統的抽象行為。該系統還可以通過一組靜態檢查來判斷系統結構規格說明的一致性和完整性。從這些特性的分析來說，Wright系統的確適用於對大型系統的描述和分析。

軟體體系結構的建模研究

研究軟體體系結構的首要問題是如何表示軟體體系結構，即如何對軟體體系結構建模。根據建模的側重點的不同，可以將軟體體系結構的模型分為5種：結構模型、框架模型、動態模型、過程模型和功能模型。在這5個模型中，最常用的是結構模型和動態模型。

（1）結構模型

這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連線件和其他概念來刻畫結構，並力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質。研究結構模型的核心是體系結構描述語言。

（2）框架模型

框架模型與結構模型類似，但它不太側重描述結構的細節而更側重於整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。

（3）動態模型

動態模型是對結構或框架模型的補充，研究系統的"大顆粒"的行為性質。例如，描述系統的重新配置或演化。動態可能指系統總體結構的配置、建立或拆除通信通道或計算的過程。這類系統常是激勵型的。

（4）過程模型

過程模型研究構造系統的步驟和過程。因而結構是遵循某些過程腳本的結果。

（5）功能模型

該模型認為體系結構是由一組功能構件按層次組成，下層向上層提供服務。它可以看作是一種特殊的框架模型。

這5種模型各有所長，也許將5種模型有機地統一在一起，形成一個完整的模型來刻畫軟體體系結構更合適。例如，Kruchten在1995年提出了一個"4+1"的視角模型。"4+1"模型從5個不同的視角包括邏輯視角、過程視角、物理視角、開發視角和場景視角來描述軟體體系結構。每一個視角只關心繫統的一個側面，5個視角結合在一起才能夠反映系統的軟體體系結構的全部內容。"4+1"模型如圖1所示。

圖1 "4+1"模型

發展基於體系結構的軟體開發模型

軟體開發模型是跨越整個軟體生存周期的系統開發、運行、維護所實施的全部工作和任務的結構框架，給出了軟體開發活動各階段之間的關係。目前，常見的軟體開發模型大致可分為三種類型:

（1）以軟體需求完全確定為前提的瀑布模型。

（2）在軟體開發初始階段只能提供基本需求時採用的漸進式開發模型,如螺旋模型等。

（3）以形式化開發方法為基礎的變換模型。

所有開發方法都是要解決需求與實現之間的差距。但是，這三種類型的軟體開發模型都存在這樣或那樣的缺陷，不能很好地支持基於軟體體系結構的開發過程。因此，研究人員在發展基於體系結構的軟體開發模型方面做了一定的工作。例如，為了形象地表示體系結構的生命周期，北京郵電大學的周瑩新博士建立了一個軟體體系結構的生命周期模型，該模型如圖2所示。圖2 軟體體系結構的生命周期模型

軟體產品線體系結構的研究

軟體體系結構的開發是大型軟體系統開發的關鍵環節。體系結構在軟體生產線的開發中具有至關重要的作用，在這種開發生產中，基於同一個軟體體系結構，可以創建具有不同功能的多個系統。在軟體產品族之間共享體系結構和一組可重用的構件，可以增加軟體工程和降低開發和維護成本。

一個產品線代表著一組具有公共的系統需求集的軟體系統，它們都是根據基本的用戶需求對標準的產品線構架進行定製，將可重用構件與系統獨有的部分集成而得到的。採用軟體生產線式模式進行軟體生產，將產生巨型編程企業。但目前生產的軟體產品族大部分是處於同一領域的。

影響

軟體體系結構貫穿於軟體研發的整個生命周期內，具有重要的影響。這主要從以下三個方面來進行考察：

利益相關人員之間的交流

：軟體體系結構是一種常見的對系統的抽象，代碼級別的系統抽象僅僅可以成為程式設計師的交流工具，而包括程式設計師在內的絕大多數系統的利益相關人員都藉助軟體體系結構來進行彼此理解、協商、達成共識或者相互溝通的基礎。

系統設計的前期決策

：軟體體系結構是我們所開發的軟體系統最早期設計決策的體現，而這些早期決策對軟體系統的後續開發、部署和維護具有相當重要的影響。這也是能夠對所開發系統進行分析的最早時間點。

可傳遞的系統級抽象

：軟體體系結構是關於系統構造以及系統各個元素工作機制的相對較小、卻又能夠突出反映問題的模型。由於軟體系統具有的一些共通特性，這種模型可以在多個系統之間傳遞，特別是可以套用到具有相似質量屬性和功能需求的系統中，並能夠促進大規模軟體的系統級復用。

體系風格

對軟體體系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用於解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是使用常用的、規範的方法來組織，就可使別的設計者很容易地理解系統的體系結構。例如，如果某人把系統描述為"客戶/伺服器"模式，則不必給出設計細節，我們立刻就會明白系統是如何組織和工作的。

下面是Garlan和Shaw對通用體系結構風格的分類：

（1）數據流風格：批處理序列；管道/過濾器

（2）調用/返迴風格：主程式/子程式；面向對象風格；層次結構

（3）獨立構件風格：進程通訊；事件系統

（4）虛擬機風格：解釋器；基於規則的系統

（5）倉庫風格：資料庫系統；超文本系統；黑板系統

限於篇幅，在本文中，我們將只介紹幾種主要的和經典的體系結構風格和它們的優缺點。有關新出現的軟體體系結構風格，將在後續文章中進行介紹。

C2體系

C2體系結構風格可以概括為：通過連線件綁定在一起的按照一組規則運作的並行構件網路。C2風格中的系統組織規則如下：

（1）系統中的構件和連線件都有一個頂部和一個底部；

（2）構件的頂部應連線到某連線件的底部，構件的底部則應連線到某連線件的頂部，而構件與構件之間的直接連線是不允許的；（3）一個連線件可以和任意數目的其它構件和連線件連線；

（4）當兩個連線件進行直接連線時，必須由其中一個的底部到另一個的頂部。

圖3是C2風格的示意圖。圖中構件與連線件之間的連線體現了C2風格中構建系統的規則。

圖3 C2風格的體系結構

C2風格是最常用的一種軟體體系結構風格。從C2風格的組織規則和結構圖中，我們可以得出，C2風格具有以下特點：

（1）系統中的構件可實現套用需求，並能將任意複雜度的功能封裝在一起；

（2）所有構件之間的通訊是通過以連線件為中介的異步訊息交換機制來實現的；

（3）構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制執行緒之類的相關性假設。

管道/過濾器

在管道/過濾器風格的軟體體系結構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然後產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這裡的構件被稱為過濾器，這種風格的連線件就象是數據流傳輸的管道，將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網路輸出的正確性並不依賴於過濾器進行增量計算過程的順序。

圖4是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程式。Unix既提供一種符號，以連線各組成部分(Unix的進程)，又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編譯器。傳統的編譯器一直被認為是一種管道系統，在該系統中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另一個階段的輸入。

圖4 管道/過濾器風格的體系結構

管道/過濾器風格的軟體體系結構具有許多很好的特點：

（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；

（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；

（3）支持軟體重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連線起來；

（4）系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；

（5）允許對一些如吞吐量、死鎖等屬性的分析；

（6）支持並行執行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務並行執行。

但是，這樣的系統也存在著若干不利因素。

（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。

（2）不適合處理互動的套用。當需要增量地顯示改變時，這個問題尤為嚴重。

（3）因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，並增加了編寫過濾器的複雜性。

數據抽象和面向對象

抽象數據類型概念對軟體系統有著重要作用，目前軟體界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和面向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因為它負責保持資源的完整性。對象是通過函式和過程的調用來互動的。

圖5是數據抽象和面向對象風格的示意圖。圖5 數據抽象和面向對象風格的體系結構

面向對象的系統有許多的優點，並早已為人所知：

（1）因為對象對其它對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其它的對象。

（2）設計者可將一些數據存取操作的問題分解成一些互動的代理程式的集合。

但是，面向對象的系統也存在著某些問題：

（1）為了使一個對象和另一個對象通過過程調用等進行互動，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象。

（2）必須修改所有顯式調用它的其它對象，並消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的。

基於事件的隱式調用

基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中註冊，當一個事件被觸發，系統自動調用在這個事件中註冊的所有過程，這樣，一個事件的觸發就導致了另一模組中的過程的調用。

從體系結構上說，這種風格的構件是一些模組，這些模組既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中註冊一些過程，當發生這些事件時，過程被調用。

基於事件的隱式調用風格的主要特點是事件的觸發者並不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統也包含顯式調用作為構件互動的補充形式。

支持基於事件的隱式調用的套用系統很多。例如，在編程環境中用於集成各種工具，在資料庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變數監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程式，如編輯程式可以卷屏到斷點，變數監視器刷新變數數值。而Debugger本身只聲明事件，並不關心哪些過程會啟動，也不關心這些過程做什麼處理。

隱式調用系統的主要優點有：

（1）為軟體重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它註冊到系統的事件中。

（2）為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其它構件的接口。

隱式調用系統的主要缺點有：

（1）構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其它構件是否會回響它。而且即使它知道事件註冊了哪些構件的構成，它也不能保證這些過程被調用的順序。

（2）數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基於事件的系統必須依靠一個共享的倉庫進行互動。在這些情況下，全局性能和資源管理便成了問題。

（3）既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。

層次系統

層次系統組織成一個層次結構，每一層為上層服務，並作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函式外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連線件通過決定層間如何互動的協定來定義，拓撲約束包括對相鄰層間互動的約束。

這種風格支持基於可增加抽象層的設計。這樣，允許將一個複雜問題分解成一個增量步驟序列的實現。由於每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟體重用提供了強大的支持。

圖6是層次系統風格的示意圖。層次系統最廣泛的套用是分層通信協定。在這一套用領域中，每一層提供一個抽象的功能，作為上層通信的基礎。較低的層次定義低層的互動，最低層通常只定義硬體物理連線。

圖6 層次系統風格的體系結構

層次系統有許多可取的屬性：

（1）支持基於抽象程度遞增的系統設計，使設計者可以把一個複雜系統按遞增的步驟進行分解；

（2）支持功能增強，因為每一層至多和相鄰的上下層互動，因此功能的改變最多影響相鄰的上下層；

（3）支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現方法。

但是，層次系統也有其不足之處：

（1）並不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；

（2）很難找到一個合適的、正確的層次抽象方法。

倉庫

在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互作用在系統中會有大的變化。

控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型資料庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。

圖7是黑板系統的組成。黑板系統的傳統套用是信號處理領域，如語音和模式識別。另一套用是松耦合代理數據共享存取。

圖7 黑板系統的組成

我們從圖4中可以看出，黑板系統主要由三部分組成：

（1）知識源。知識源中包含獨立的、與應用程式相關的知識，知識源之間不直接進行通訊，它們之間的互動只通過黑板來完成。

（2）黑板數據結構。黑板數據是按照與應用程式相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。

（3）控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。

發展方向

信息互換

現有的ADLs大多是與領域相關的，所以不利於對不同領域體系結構的說明。但這些針對不同領域的ADLs在某些方面又大同小異，造成資源的冗餘。其實，大多數ADLs具有一系列的共同概念。如何用一種公共形式把各種語言綜合起來，使得能夠交換各種體系結構描述信息，將是今後軟體體系結構研究和實踐的重點之一。

設計工具和環境

軟體體系結構設計既然作為軟體工程的一部分，它的計算機輔助實現手段是相當重要的。我們應當開發出一些軟體工具來實現體系結構的描述和分析，開發階段轉換工具，以實現階段成果的自動轉換，例如，把需求規格說明自動轉換為構件等。目前關於這方面的研究成果很少，特別是可以套用到實際項目開發中的工具和環境就更少。

體系結構再工程

當今軟體系統的規模變得越來越大，結構也越來越複雜，同時從頭開始構建的大系統數量在急劇地減少，因而很多遺留系統正在被逐步地利用。從遺留系統軟體代碼和系統中抽取結構信息，經過描述、統一、抽象、一般化與實例化等處理，可總結出系統的體系結構。

在這種情況下，軟體再工程變得越來越重要，因為它提供了一條把遺留系統轉換為可進化系統的現實可行的途徑，是一種可以改進人們對軟體的理解和改進軟體本身的活動。這類研究的目的是為一些特定的套用領域的軟體系統提供一些體系結構框架，如控制系統、移動機器人和用戶接口界面等。通過這些框架可以很方便地構造一個新的軟體系統。

圖書

圖書信息

作　者：(美)肖

出版社：清華大學出版社

出版時間： 2007

ISBN: 9787302145509

開本：16

定價: 29.80 元

內容簡介

軟體體系結構作為從軟體設計抽象出來的一門新興學科，目前已經成為軟體工程一個重要研究領域。本書作者MaryShaw和DavidGarlan作為軟體體系結構最早的研究者，在體系結構領域做出了大量先導性的工作。

本書共有8章：緒論、軟體體系結構風格、案例研究、共享信息系統、軟體體系結構描述、軟體體系結構的分析與評估、特定領域的軟體體系結構和流行的軟體體系結構等。本書第1-4章主要譯自MaryShaw和DavidGarlan的著作。根據目前軟體體系結構的現狀、以及編譯者多年的教學實踐經驗，在第1章和第5章加入了部分新的內容，並重新編寫了第6章、第7章和第8章。其中第6，7章是在參考了大量相關研究的基礎上，結合作者在圖書館領域的親身實踐編寫的。

本書可以作為計算機專業研究生和高年級本科生的軟體體系結構課程的教材或參考書，也可作為軟體開發人員的參考手冊。

軟體體系結構