-
軟件體系結構
(學科名稱)
鎖定
- 中文名
- 軟件體系結構
- 外文名
- software architecture
- 定 義
- 具有一定形式的結構化元素
- 組 成
- 處理構件、數據構件
- 應 用
- 軟件工程
軟件體系結構定義
- Hayes Roth則認為軟件體系結構是一個抽象的系統規範,主要包括用其行為來描述的功能構件和構件之間的相互連接、接口和關係。
- David Garlan和Dewne Perry於1995年在IEEE軟件工程學報上又採用如下的定義:軟件體系結構是一個程序/系統各構件的結構、它們之間的相互關係以及進行設計的原則和隨時間進化的指導方針。
- Barry Boehm和他的學生提出,一個軟件體系結構包括一個軟件和系統構件,互聯及約束的集合;一個系統需求説明的集合;一個基本原理用以説明這一構件,互聯和約束能夠滿足系統需求。
軟件體系結構發展歷史
與最初的大型中央主機相適應,最初的軟件結構體系也是Mainframe結構,該結構下客户、數據和程序被集中在主機上,通常只有少量的GUI界面,對遠程數據庫的訪問比較困難。隨着PC的廣泛應用,該結構逐漸在應用中被淘汰。在80年代中期出現了Client/Server分佈式計算結構,應用程序的處理在客户(PC機)和服務器(Mainframe或Server)之間分擔;請求通常被關係型數據庫處理,PC機在接受到被處理的數據後實現顯示和業務邏輯;系統支持模塊化開發,通常有GUI界面。Client/Server結構因為其靈活性得到了極其廣泛的應用。但對於大型軟件系統而言,這種結構在系統的部署和擴展性方面還是存在着不足。
Internet的發展給傳統應用軟件的開發帶來了深刻的影響。基於Internet和Web的軟件和應用系統無疑需要更為開放和靈活的體系結構。隨着越來越多的商業系統被搬上Internet,一種新的、更具生命力的體系結構被廣泛採用,這就是為“三層/多層計算”。
三層體系結構中,客户(請求信息)、程序(處理請求)和數據(被操作)被物理地隔離。三層結構是個更靈活的體系結構,它把顯示邏輯從業務邏輯中分離出來,這就意味着業務代碼是獨立的,可以不關心怎樣顯示和在哪裏顯示。業務邏輯層處於中間層,不需要關心由哪種類型的客户來顯示數據,也可以與後端系統保持相對獨立性,有利於系統擴展。三層結構具有更好的移植性,可以跨不同類型的平台工作,允許用户請求在多個服務器間進行負載平衡。三層結構中安全性也更易於實現,因為應用程序已經同客户隔離。應用程序服務器是三層/多層體系結構的組成部分,應用程序服務器位於中間層。
如下所示,應用程序服務器運行於瀏覽器和數據資源之間,一個簡單的實例是,顧客從瀏覽器中輸入一個定單,web服務器將該請求發送給應用程序服務器,由應用程序服務器執行處理邏輯,並且獲取或更新後端用户數據。
興起
六十年代的軟件危機使得人們開始重視軟件工程的研究。起初,人們把軟件設計的重點放在數據結構和算法的選擇上,隨着軟件系統規模越來越大、越來越複雜,整個系統的結構和規格説明顯得越來越重要。軟件危機的程度日益加劇,現有的軟件工程方法對此顯得力不從心。對於大規模的複雜軟件系統來説,對總體的系統結構設計和規格説明比起對計算的算法和數據結構的選擇已經變得明顯重要得多。在此種背景下,人們認識到軟件體系結構的重要性,並認為對軟件體系結構的系統、深入的研究將會成為提高軟件生產率和解決軟件維護問題的新的最有希望的途徑。自從軟件系統首次被分成許多模塊,模塊之間有相互作用,組合起來有整體的屬性,就具有了體系結構。好的開發者常常會使用一些體系結構模式作為軟件系統結構設計策略,但他們並沒有規範地、明確地表達出來,這樣就無法將他們的知識與別人交流。軟件體系結構是設計抽象的進一步發展,滿足了更好地理解軟件系統,更方便地開發更大、更復雜的軟件系統的需要。
事實上,軟件總是有體系結構的,不存在沒有體系結構的軟件。體系結構(Architecture)一詞在英文裏就是"建築"的意思。把軟件比作一座樓房,從整體上講,是因為它有基礎、主體和裝飾,即操作系統之上的基礎設施軟件、實現計算邏輯的主體應用程序、方便使用的用户界面程序。從細節上來看每一個程序也是有結構的。早期的結構化程序就是以語句組成模塊,模塊的聚集和嵌套形成層層調用的程序結構,也就是體系結構。結構化程序的程序(表達)結構和(計算的)邏輯結構的一致性及自頂向下開發方法自然而然地形成了體系結構。由於結構化程序設計時代程序規模不大,通過強調結構化程序設計方法學,自頂向下、逐步求精,並注意模塊的耦合性就可以得到相對良好的結構,所以,並未特別研究軟件體系結構。
可以作個簡單的比喻,結構化程序設計時代是以磚、瓦、灰、沙、石、預製梁、柱、屋面板蓋平房和小樓,而面向對象時代以整面牆、整間房、一層樓梯的預製件蓋高樓大廈。構件怎樣搭配才合理?體系結構怎樣構造容易?重要構件有了更改後,如何保證整棟高樓不倒?每種應用領域需要什麼構件(醫院、工廠、旅館)?有哪些實用、美觀、強度、造價合理的構件骨架使建造出來的建築(即體系結構)更能滿足用户的需求?如同土木工程進入到現代建築學一樣,軟件也從傳統的軟件工程進入到現代面向對象的軟件工程,研究整個軟件系統的體系結構,尋求建構最快、成本最低、質量最好的構造過程。
軟件體系結構雖脱胎於軟件工程,但其形成同時借鑑了計算機體系結構和網絡體系結構中很多寶貴的思想和方法,最近幾年軟件體系結構研究已完全獨立於軟件工程的研究,成為計算機科學的一個最新的研究方向和獨立學科分支。軟件體系結構研究的主要內容涉及軟件體系結構描述、軟件體系結構風格、軟件體系結構評價和軟件體系結構的形式化方法等。解決好軟件的重用、質量和維護問題,是研究軟件體系結構的根本目的。
軟件體系結構應用現狀
形成研究熱點,仍處於非形式化水平
自20世紀90年代後期以來,軟件體系結構的研究成為一個熱點。廣大軟件工作者已經認識到軟件體系結構研究的重大意義和它對軟件系統設計開發的重要性,開展了很多研究和實踐工作。
從軟件體系結構研究的現狀來看,當前的研究和對軟件體系結構的描述,在很大程度上來説還停留在非形式化的基礎上。軟件構架師仍然缺乏必要的工具,這種工具應該是顯式描述的、有獨立性的形式化工具。
當一個軟件系統中的構件之間幾乎以一種非形式化的方法描述時,系統的重用性也會受到影響,在設計一個系統結構過程中的努力很難移植到另一個系統中去。對系統構件和連接關係的結構化假設沒有得到顯式的、形式化的描述時,把這樣的系統構件移植到另一個系統中去將是有風險的,甚至是不可能的。
軟件體系結構的形式化方法研究
軟件體系結構研究如果僅僅停留在非形式化的框圖階段,已經難以適應進一步發展的需要。為支持基於體系結構的開發,需要有形式化建模符號、體系結構説明的分析與開發工具。從軟件體系結構研究的現狀來看,在這一領域近來已經有不少進展,其中比較有代表性的是美國卡耐基梅隆大學(Carnegie Mellon University)的Robert J.A11en於l997年提出的Wright系統。Wright是-種結構描述語言,該語言基於一種形式化的、抽象的系統模型,為描述和分析軟件體系結構和結構化方法提供了一種實用的工具。Wright主要側重於描述系統的軟件構件和連接的結構、配置和方法。它使用顯式的、獨立的連接模型來作為交互的方式,這使得該系統可以用邏輯謂詞符號系統,而不依賴特定的系統實例來描述系統的抽象行為。該系統還可以通過一組靜態檢查來判斷系統結構規格説明的一致性和完整性。從這些特性的分析來説,Wright系統的確適用於對大型系統的描述和分析。
軟件體系結構的建模研究
研究軟件體系結構的首要問題是如何表示軟件體系結構,即如何對軟件體系結構建模。根據建模的側重點的不同,可以將軟件體系結構的模型分為5種:結構模型、框架模型、動態模型、過程模型和功能模型。在這5個模型中,最常用的是結構模型和動態模型。
- 框架模型:框架模型與結構模型類似,但它不太側重描述結構的細節而更側重於整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。
- 動態模型:動態模型是對結構或框架模型的補充,研究系統的"大顆粒"的行為性質。例如,描述系統的重新配置或演化。動態可能指系統總體結構的配置、建立或拆除通信通道或計算的過程。這類系統常是激勵型的。
- 過程模型:過程模型研究構造系統的步驟和過程。因而結構是遵循某些過程腳本的結果。
- 功能模型:該模型認為體系結構是由一組功能構件按層次組成,下層向上層提供服務。它可以看作是一種特殊的框架模型。
這5種模型各有所長,也許將5種模型有機地統一在一起,形成一個完整的模型來刻畫軟件體系結構更合適。例如,Kruchten在1995年提出了一個"4+1"的視角模型。"4+1"模型從5個不同的視角包括邏輯視角、過程視角、物理視角、開發視角和場景視角來描述軟件體系結構。每一個視角只關心繫統的一個側面,5個視角結合在一起才能夠反映系統的軟件體系結構的全部內容。"4+1"模型如圖1所示。
發展基於體系結構的軟件開發模型
所有開發方法都是要解決需求與實現之間的差距。但是,這三種類型的軟件開發模型都存在這樣或那樣的缺陷,不能很好地支持基於軟件體系結構的開發過程。因此,研究人員在發展基於體系結構的軟件開發模型方面做了一定的工作。例如,為了形象地表示體系結構的生命週期,北京郵電大學的周瑩新博士建立了一個軟件體系結構的生命週期模型,該模型如圖2所示。
軟件產品線體系結構的研究
軟件體系結構的開發是大型軟件系統開發的關鍵環節。體系結構在軟件生產線的開發中具有至關重要的作用,在這種開發生產中,基於同一個軟件體系結構,可以創建具有不同功能的多個系統。在軟件產品族之間共享體系結構和一組可重用的構件,可以增加軟件工程和降低開發和維護成本。
一個產品線代表着一組具有公共的系統需求集的軟件系統,它們都是根據基本的用户需求對標準的產品線構架進行定製,將可重用構件與系統獨有的部分集成而得到的。採用軟件生產線式模式進行軟件生產,將產生巨型編程企業。但目前生產的軟件產品族大部分是處於同一領域的。
軟件體系結構主要影響
- 利於相關人員之間的交流:軟件體系結構是一種常見的對系統的抽象,代碼級別的系統抽象僅僅可以成為程序員的交流工具,而包括程序員在內的絕大多數系統的利益相關人員都藉助軟件體系結構來進行彼此理解、協商、達成共識或者相互溝通的基礎。
軟件體系結構體系風格
對軟件體系結構風格的研究和實踐促進了對設計的複用,一些經過實踐證實的解決方案也可以可靠地用於解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是使用常用的、規範的方法來組織,就可使別的設計者很容易地理解系統的體系結構。例如,如果某人把系統描述為"客户/服務器"模式,則不必給出設計細節,立刻就會明白系統是如何組織和工作的。
下面是Garlan和Shaw對通用體系結構風格的分類:
- 獨立構件風格:進程通訊;事件系統
- 虛擬機風格:解釋器;基於規則的系統
C2體系
C2體系結構風格可以概括為:通過連接件綁定在一起的按照一組規則運作的並行構件網絡。C2風格中的系統組織規則如下:
- 系統中的構件和連接件都有一個頂部和一個底部;
- 構件的頂部應連接到某連接件的底部,構件的底部則應連接到某連接件的頂部,而構件與構件之間的直接連接是不允許的;
- 一個連接件可以和任意數目的其它構件和連接件連接;
- 當兩個連接件進行直接連接時,必須由其中一個的底部到另一個的頂部。
C2風格是最常用的一種軟件體系結構風格。從C2風格的組織規則和結構圖中,可以得出,C2風格具有以下特點:
(1)系統中的構件可實現應用需求,並能將任意複雜度的功能封裝在一起;
(2)所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的;
管道/過濾器
在管道/過濾器風格的軟件體系結構中,每個構件都有一組輸入和輸出,構件讀輸入的數據流,經過內部處理,然後產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成,所以在輸入被完全消費之前,輸出便產生了。因此,這裏的構件被稱為過濾器,這種風格的連接件就象是數據流傳輸的管道,將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體,它不能與其它的過濾器共享數據,而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性並不依賴於過濾器進行增量計算過程的順序。
圖4是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程序。Unix既提供一種符號,以連接各組成部分(Unix的進程),又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編譯器。傳統的編譯器一直被認為是一種管道系統,在該系統中,一個階段(包括詞法分析、語法分析、語義分析和代碼生成)的輸出是另一個階段的輸入。
管道/過濾器風格的軟件體系結構具有許多很好的特點:
- 允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成;
- 支持軟件重用。重要提供適合在兩個過濾器之間傳送的數據,任何兩個過濾器都可被連接起來;
- 允許對一些如吞吐量、死鎖等屬性的分析;
- 支持並行執行。每個過濾器是作為一個單獨的任務完成,因此可與其它任務並行執行。
但是,這樣的系統也存在着若干不利因素。
- 通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據,但它們是獨立的,所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。
- 不適合處理交互的應用。當需要增量地顯示改變時,這個問題尤為嚴重。
- 因為在數據傳輸上沒有通用的標準,每個過濾器都增加了解析和合成數據的工作,這樣就導致了系統性能下降,並增加了編寫過濾器的複雜性。
數據抽象和麪向對象
抽象數據類型概念對軟件系統有着重要作用,軟件界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和麪向對象的基礎上,數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象,或者説是抽象數據類型的實例。對象是一種被稱作管理者的構件,因為它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
面向對象的系統有許多的優點,並早已為人所知:
- 因為對象對其它對象隱藏它的表示,所以可以改變一個對象的表示,而不影響其它的對象。
- 設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
但是,面向對象的系統也存在着某些問題:
- 為了使一個對象和另一個對象通過過程調用等進行交互,必須知道對象的標識。只要一個對象的標識改變了,就必須修改所有其他明確調用它的對象。
- 必須修改所有顯式調用它的其它對象,並消除由此帶來的一些副作用。例如,如果A使用了對象B,C也使用了對象B,那麼,C對B的使用所造成的對A的影響可能是料想不到的。
基於事件的隱式調用
基於事件的隱式調用風格的思想是構件不直接調用一個過程,而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中註冊,當一個事件被觸發,系統自動調用在這個事件中註冊的所有過程,這樣,一個事件的觸發就導致了另一模塊中的過程的調用。
從體系結構上説,這種風格的構件是一些模塊,這些模塊既可以是一些過程,又可以是一些事件的集合。過程可以用通用的方式調用,也可以在系統事件中註冊一些過程,當發生這些事件時,過程被調用。
基於事件的隱式調用風格的主要特點是事件的觸發者並不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序,甚至不知道哪些過程會被調用,因此,許多隱式調用的系統也包含顯式調用作為構件交互的補充形式。
支持基於事件的隱式調用的應用系統很多。例如,在編程環境中用於集成各種工具,在數據庫管理系統中確保數據的一致性約束,在用户界面系統中管理數據,以及在編輯器中支持語法檢查。例如在某系統中,編輯器和變量監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時,它聲明該事件,由系統自動調用處理程序,如編輯程序可以卷屏到斷點,變量監視器刷新變量數值。而Debugger本身只聲明事件,並不關心哪些過程會啓動,也不關心這些過程做什麼處理。
隱式調用系統的主要優點有:
- 為軟件重用提供了強大的支持。當需要將一個構件加入現存系統中時,只需將它註冊到系統的事件中。
- 為改進系統帶來了方便。當用一個構件代替另一個構件時,不會影響到其它構件的接口。
隱式調用系統的主要缺點有:
- 構件放棄了對系統計算的控制。一個構件觸發一個事件時,不能確定其它構件是否會響應它。而且即使它知道事件註冊了哪些構件的構成,它也不能保證這些過程被 調用的順序。
層次系統
層次系統組織成一個層次結構,每一層為上層服務,並作為下層客户。在一些層次系統中,除了一些精心挑選的輸出函數外,內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機(在另一些層次系統中層是部分不透明的)。連接件通過決定層間如何交互的協議來定義,拓撲約束包括對相鄰層間交互的約束。
這種風格支持基於可增加抽象層的設計。這樣,允許將一個複雜問題分解成一個增量步驟序列的實現。由於每一層最多隻影響兩層,同時只要給相鄰層提供相同的接口,允許每層用不同的方法實現,同樣為軟件重用提供了強大的支持。
層次系統有許多可取的屬性:
- 支持功能增強,因為每一層至多和相鄰的上下層交互,因此功能的改變最多影響相鄰的上下層;
- 支持重用。只要提供的服務接口定義不變,同一層的不同實現可以交換使用。這樣,就可以定義一組標準的接口,而允許各種不同的實現方法。
但是,層次系統也有其不足之處:
倉庫
控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇,則倉庫是一傳統型數據庫;另一方面,若中央數據結構的當前狀態觸發進程執行的選擇,則倉庫是一黑板系統。
我們從圖4中可以看出,黑板系統主要由三部分組成:
(1)知識源。知識源中包含獨立的、與應用程序相關的知識,知識源之間不直接進行通訊,它們之間的交互只通過黑板來完成。
(2)黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據,知識源通過不斷地改變黑板數據來解決問題。
(3)控制。控制完全由黑板的狀態驅動,黑板狀態的改變決定使用的特定知識。
軟件體系結構發展方向
信息互換
現有的ADLs大多是與領域相關的,所以不利於對不同領域體系結構的説明。但這些針對不同領域的ADLs在某些方面又大同小異,造成資源的冗餘。其實,大多數ADLs具有一系列的共同概念。如何用一種公共形式把各種語言綜合起來,使得能夠交換各種體系結構描述信息,將是今後軟件體系結構研究和實踐的重點之一。
設計工具和環境
軟件體系結構設計既然作為軟件工程的一部分,它的計算機輔助實現手段是相當重要的。我們應當開發出一些軟件工具來實現體系結構的描述和分析,開發階段轉換工具,以實現階段成果的自動轉換,例如,把需求規格説明自動轉換為構件等。關於這方面的研究成果很少,特別是可以應用到實際項目開發中的工具和環境就更少。
體系結構再工程