軟件體系結構Chap03風格(上)課件

課程內容第1第2章軟件體系結構概論第3章軟件體系結構風格第4章軟件體系結構建模第5章軟件體系結構描述第6章基于體系結構的軟件開發(fā)第7章流行的軟件體系結構第8章案例分析1第三章軟件體系結構風格§

3.1概述§

3.2經(jīng)典軟件體系結構風格§

3.3公共對象請求代理體系結構§

3.4正交體系結構§

3.5基于層次消息總線的體系結構風格§

3.6異構結構風格§

3.7互聯(lián)系統(tǒng)構成的系統(tǒng)及其體系結構§

3.8面向體系結構的架構（SOA）2§3.1

概述軟件體系結構風格(Style)：描述特定系統(tǒng)組織方式的慣用范例，強調組織模式和慣用范例。組織模式即靜態(tài)表述的樣例，慣用范例則是反映群眾多系統(tǒng)共有的結構和語義。軟件體系結構設計的核心問題：能否達到體系結構級的軟件重用；對軟件體系結構風格的研究和實踐促進了對設計的復用，一些經(jīng)過實踐證實的解決方案也可以可靠地用于解決新的問題。PS：體系結構模式體系結構慣用描述和體系結構風格是同一個意思目的：展示軟件體系結構豐富的選擇空間，在此基礎上對風格選擇的一些權衡3

在體系結構層次上，常出現(xiàn)客戶機－服務器系統(tǒng)、管道過濾器設計或者分層體系結構等軟件風格術語，這些術語一般與特定的設計方法和符號相關，如面向對象和數(shù)據(jù)流等，雖然還沒有對體系結構慣用模式實現(xiàn)分類，但是這種分類的輪廓已開始出現(xiàn)，如下部分主要種類：

5軟件體系結構風格是反復出現(xiàn)的組織模式和習慣用法，是對一系列體系結構設計的抽象；軟件體系結構風格是描述某一特定應用領域中系統(tǒng)組織方式的慣用模式。體系結構風格定義了一個系統(tǒng)家族，即一個體系結構定義一個詞匯表和一組約束；詞匯表包括一些構件和連接件，約束指出系統(tǒng)如何將這些構件和連接件組合起來；一個軟件體系結構風格定義了構件和連接件類型的符號集，以及規(guī)定它們怎樣組合起來的約束集合。6討論體系結構風格時要回答的問題：設計詞匯表是什么？構件和連接件的類型是什么？可容許的結構模式是什么？基本的計算模型是什么？風格的基本不變性是什么？其使用的常見例子是什么？其優(yōu)缺點是什么？體系結構風格最關鍵的四個要素：提供一個詞匯表、定義一套配置規(guī)則、定義一套語義解釋原則和定義對基于這種風格的系統(tǒng)所進行的分析。分析7種通用的風格7§3.2

經(jīng)典軟件體系結構3.2.1管道和過濾器3.2.2數(shù)據(jù)抽象和面向對象組織3.2.3基于事件的隱式調用3.2.4分層系統(tǒng)3.2.5知識庫3.2.6模型-視圖-控制器(MVC)風格3.2.7解釋器風格3.2.8客戶/服務器風格(C/S)3.2.9三層C/S結構風格3.2.10瀏覽器/服務器風格(B/S)93.2.1管道和過濾器(PIPESANDFILTER)產(chǎn)生于UNIX操作系統(tǒng)，適用于對有序數(shù)據(jù)進行一系列已經(jīng)定義的獨立計算的應用程序；每個構件(過濾器)都有一組輸入和輸出，構件讀輸入的數(shù)據(jù)流，經(jīng)內部處理，產(chǎn)生輸出數(shù)據(jù)流；連接件位于過濾器之間，起到信息流導管的作用，稱為管道；管道和過濾器系統(tǒng)的輸出的正確性不依賴于過濾器的遞進處理順序。10管道過濾器通用結構：過濾器是一個獨立實體，其間無需共享狀態(tài)管線（Pipelines）：限制系統(tǒng)的拓撲結構只能是過濾器的線性序列有界管線（BoundedPipes）：限制了在管道中能容納的數(shù)據(jù)量類型定義管道（TypePipes）：明確定義在兩個過濾器間的數(shù)據(jù)類型11管道和過濾器的實現(xiàn)：將系統(tǒng)任務分成幾個獨立的處理階段；定義每個管道傳輸?shù)臄?shù)據(jù)格式；決定管道的連接；設計和實現(xiàn)過濾器；設計出錯處理；建立處理流水線。13管道和過濾器的優(yōu)點：每個過濾器都是獨立的整體，相互之間的狀態(tài)互不影響；只要具備輸入條件即可獨立地完成自己的處理支持功能模塊的重用；過濾器并不知道它的上游和下游的過濾器的特性；它的設計和實現(xiàn)不會對與它相連的過濾器加以限制。系統(tǒng)容易維護和擴展支持某些特定的分析，如吞吐量和死鎖檢測并發(fā)性14管道和過濾器的缺點：管線或流水線(PipeLine)：過濾器嚴格限制為單輸入、單輸出類型，系統(tǒng)拓撲結構只能是線性序列；交互性比較弱兼容性相對弱；維持兩個相對獨立但又存在某種關系的數(shù)據(jù)流之間的通信可能比較困難；有名管道：在過濾器之間通過有名的管道來進行數(shù)據(jù)傳送，增加了解析或反饋工作，從而降低系統(tǒng)的效率。15面向對象風格的優(yōu)點：

封裝：對象具有信息隱藏特性，內部結構對外不可見；

繼承：從具有通用特征的對象開始，逐漸定義更具體對象多態(tài)：不同類型的對象可以對相同的激勵做出不同的響應17PS:數(shù)據(jù)抽象是特殊化的面向對象風格：ADT(AbstractDataType)只有封裝特點，沒有繼承和多態(tài)的特點。面向對象風格的缺點：

1、對象調用過程中必須要知道對象的標識，只要一個對象的標識改變，就必須修改所有其他明確調用它的對象。

2、同時要修改每一個引用了這個模塊的“導入”列表，這樣會帶來不可預料的副作用。183.2.3基于事件的隱式調用基于事件(Event-Based)的風格又稱為隱式調用(ImplicitInvocation)風格，構件不直接調用一個過程，而是觸發(fā)或廣播一個或多個事件，由系統(tǒng)調用為這一事件注冊的其他構件的過程；每個構件的接口不僅提供一個過程的集合，也提供一個事件的集合；一個構件可注冊多個事件，一個事件可觸發(fā)對多個構件過程的調用；適用于涉及低耦合構件集合的應用程序，如在用戶界面系統(tǒng)中管理數(shù)據(jù)，在數(shù)據(jù)庫管理系統(tǒng)中確保數(shù)據(jù)的一致性，在編輯器中支持語法檢查。193.2.4

分層系統(tǒng)系統(tǒng)組織為層次結構，每一層為上層提供服務，作為下層的客戶，通常不允許跨層交互；適應于可以按照層次結構來組織不同類別的相關服務的應用程序；系統(tǒng)中構件在一些層實現(xiàn)了虛擬機的功能；連接件通過決定層間如何交互的協(xié)議來定義，拓撲約束包括對相鄰層間交互的約束；如分層通信協(xié)議，每一層提供一個抽象的功能作為上層通信的基礎，最低層只定義硬件物理連接。21例：ISO的OSI/RM(OpenSystemsInterconnectionReferenceModel)7層模型22分層系統(tǒng)的實現(xiàn)：為分層定義抽象準則，定義抽象層次；給每一層命名并指定它們的任務和提供的服務；為每個層定義接口、實現(xiàn)獨立的層；確定相鄰層通信、降低相鄰層的耦合程度；設計錯誤處理策略。23分層系統(tǒng)風格的優(yōu)點可以把一個復雜系統(tǒng)按遞增的步驟進行分解支持功能強，因為每一個層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層。支持重用，定義一組標準接口允許各種不同的實現(xiàn)方法。分層系統(tǒng)風格的缺點層次的劃分不太容易很難找到一個合適的、正確的層次抽象方法

253.2.5

知識庫適用于無確定性求解策略的問題：實踐中許多復雜問題難以用數(shù)學精確地描繪和嚴格地分析，如醫(yī)療診斷、法律推理、軍事分析等；解決方法依賴于積累了人類知識和經(jīng)驗的知識庫；知識庫風格的體系結構由兩種構件組成：一個中央數(shù)據(jù)結構，表示系統(tǒng)當前狀態(tài)；一個獨立構件的集合，對中央數(shù)據(jù)結構進行操作。26對于系統(tǒng)中數(shù)據(jù)和狀態(tài)的控制方法分兩種：由輸入事務選擇進行何種處理，并把執(zhí)行結果作為當前狀態(tài)存儲到中央數(shù)據(jù)結構中，知識庫為傳統(tǒng)的數(shù)據(jù)庫型知識庫；由中央數(shù)據(jù)結構的當前狀態(tài)決定進行何種處理，知識庫為一黑板體系結構。黑板反映的一種信息共享的系統(tǒng)，傳統(tǒng)應用是信號處理領域，源于1970’s人工智能的自然語言處理系統(tǒng)HEARSAY-II。27黑板結構實現(xiàn)：定義問題：指出問題的領域、確定系統(tǒng)輸入、輸出，細化系統(tǒng)與用戶的交互要求；定義問題解空間：確定目標解的構成，列出解決方案的不同抽象等級，找出能獨立工作的完整解的部分解；求解過程：如何將低級中間解轉換成高等解，定義在某抽象層上如何進行啟發(fā)性搜索，定義黑板詞匯集，設計系統(tǒng)控制，實現(xiàn)知識庫。黑板系統(tǒng)傳統(tǒng)上應用在復雜信號處理解釋上，如語音和模式識別，現(xiàn)代編譯器也是以共享信息為基礎的29解釋器風格中通常有一個虛擬機，彌合程序語義所期望的與硬件提供的計算引擎之間的差距解釋器包括正在被解釋執(zhí)行的偽碼和解釋引擎本身偽碼由需要解釋的源代碼和解釋引擎分析所得到的中間代碼組成。解釋引擎：語法、解釋器的定義和解釋器當前執(zhí)行狀態(tài)3.2.6解釋器303.2.7模型-視圖-控制器(MVC)風格許多應用系統(tǒng)使用圖形用戶界面，MVC主要用于處理軟件用戶界面開發(fā)中所面臨的問題：用戶界面需要經(jīng)常改變；不同的用戶對用戶界面的表示和使用有不同的要求；同樣的數(shù)據(jù)希望能以不同的形式顯示給用戶；為方便界面修改和移植，應把計算模型和顯示模型獨立。31Model-View-Controller將交互式應用劃分為3種構件：模型：應用程序的核心，封裝內核數(shù)據(jù)與狀態(tài)；視圖：為用戶顯示模型信息，一個模型可對應多個視圖；控制器：提供給用戶進行操作的接口，每個視圖與一個控制器構件相關聯(lián)。例：Microsoft提供的Windows應用程序的文檔視圖結構(Document-ViewArchitecture)。32MVC的實現(xiàn)：分析應用問題，將人機交互從核心功能中分離開來；設計應用程序的模型構件；設計和實現(xiàn)每個視圖；設計和實現(xiàn)每個控制器；創(chuàng)建“可安裝”的控制器，增加系統(tǒng)靈活性。333.2.8客戶/服務器風格(C/S)客戶/服務器風格(Client/Server)：數(shù)據(jù)和處理分布在一定范圍內的多個構件上，構件通過網(wǎng)絡連接。特征：服務器構件：向多個客戶提供服務，永遠處于激活狀態(tài)，監(jiān)聽用戶請求；客戶構件：向服務器構件請求服務；連接件：某種通信機制，通常是基于RPC(RemoteProcedureCallprotocol)的交互協(xié)議；理解情況下，訪問是透明的。34服務器負責有效地管理系統(tǒng)的資源：數(shù)據(jù)庫安全性的要求；數(shù)據(jù)庫訪問并發(fā)性的控制；數(shù)據(jù)庫前端的客戶應用程序的全局數(shù)據(jù)完整性規(guī)則；數(shù)據(jù)庫的備份與恢復；客戶應用程序的主要任務：提供用戶與數(shù)據(jù)庫交互的界面；向數(shù)據(jù)庫服務器提交用戶請求并接收來自數(shù)據(jù)庫服務器的信息利用客戶應用程序對存在于客戶端的數(shù)據(jù)執(zhí)行應用邏輯要求。C/S特點C/S結構將應用一分為二，服務器(后臺)負責數(shù)據(jù)管理，客戶機(前臺)完成與用戶的交互任務服務器為多個客戶應用程序管理數(shù)據(jù)，而客戶程序發(fā)送、請求和分析服務器接收的數(shù)據(jù)，屬“胖客戶機(fatclient)”，或稱為“瘦服務器(thinserver)”體系結構35C/S體系結構風格的優(yōu)點強大的數(shù)據(jù)操作和事務處理能力通過局域網(wǎng)絡連接低成本計算機，可以節(jié)約大量費用易于系統(tǒng)的擴充和縮小C/S體系結構風格的缺點開發(fā)成本高客戶端程序設計復雜信息內容和形式單一用戶界面風格不一，使用繁雜，不易推廣使用軟件移植困難軟件維護和升級困難新技術不能輕易應用363.2.9

三層C/S結構風格傳統(tǒng)二層C/S結構的局限性：以單一服務器為局域網(wǎng)中心，難以擴展至大型企業(yè)廣域網(wǎng)或Internet；軟、硬件的組合及集成能力有限；客戶機的負荷重，難以管理大量的客戶機，系統(tǒng)性能容易變壞；客戶端程序可直接訪問數(shù)據(jù)庫服務器，數(shù)據(jù)安全性不好；三層C/S結構增加一個應用服務器，分為表示層、功能層和數(shù)據(jù)層；37表示層應用的用戶接口部分，擔負著用戶與應用間的對話功能；方便用戶使用，如GUI；檢查輸入數(shù)據(jù)合法性；功能層應用的主體，具體的業(yè)務處理邏輯；用戶對應用和數(shù)據(jù)的存取權限，處理日志。數(shù)據(jù)層數(shù)據(jù)庫管理系統(tǒng)，負責管理對數(shù)據(jù)庫數(shù)據(jù)的讀寫如通過SQL訪問的關系型數(shù)據(jù)庫管理系統(tǒng)RDBMS；PS：對三層進行明確分割，并在邏輯上使其獨立。38中間件(middleware)用API定義的軟件層，具有強大通信能力和良好可擴展性的分布式軟件管理框架；在客戶機和服務器用、或服務器和服務器之間傳送數(shù)據(jù)，實現(xiàn)客戶機群和服務器群之間的通信。三層C/S結構提供了良好的結構擴展能力，其本質上是一種開發(fā)分布式應用程序的框架，在系統(tǒng)實現(xiàn)時可采用支持分布式應用的構件技術實現(xiàn)，如微軟的.net、OMG的CORBA、SUN的JAVABEANS等39三層C/S結構的優(yōu)點提高系統(tǒng)和軟件的可維護性和可擴展性允許靈活有效地選用相應的平臺和硬件系統(tǒng)，具有良好的可升級性和開放性可以并行開發(fā)，提高性能價格比三層C/S結構的缺點各層間的通信效率若不高，即使分配給各層的硬件能力很強，其做為整體來說也