1、第5章 軟件體系結構與設計模式,軟件體系結構的基本概念 典型的軟件體系結構風格 分布式系統(tǒng)結構 體系結構框架 設計模式,5.1 軟件體系結構的基本概念,什么是體系結構 Bass、Clements和Kazman給出了如下定義：“一個程序或計算機系統(tǒng)的軟件體系結構是指系統(tǒng)的一個或者多個結構。結構中包括軟件的構件、構件的外部可見屬性以及它們之間的相互關系。外部可見屬性則是指軟件構件提供的服務、性能、使用特性、錯誤處理、共享資源使用等。” 這一定義強調(diào)在任一體系結構表述中“軟件構件”的角色。,5.1 軟件體系結構的基本概念,Dewayne Perry和A1exander Wo1f曾這樣定義：“軟件體系

2、結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數(shù)據(jù)構件和連接構件。處理構件負責對數(shù)據(jù)進行加工，數(shù)據(jù)構件是被加工的信息，連接構件把體系結構的不同部分組合連接起來。” 這一定義注重區(qū)分處理構件、數(shù)據(jù)構件和連接構件。 體系結構設計是一系列決策和基本原理的集合，這些決策的目標在于開發(fā)高效的軟件體系結構。在體系結構設計中所強調(diào)的基本原理是系統(tǒng)的可理解性、可維護性和可擴展性。,1模式 軟件設計模式是從軟件設計過程中總結出來的，是針對 特定問題的解決方案。建筑師C.Alexander對模式給出的 經(jīng)典定義是：每個模式都描述了一個在我們的環(huán)境中不斷 出現(xiàn)的問題及該問題解決方案的核心。在軟件系統(tǒng)中

3、，可 以將模式劃分為以下3類。 （1）體系結構模式（architectural pattern）：表達了軟 件系統(tǒng)的基本結構組織形式或者結構方案，包含了一組預 定義的子系統(tǒng)，規(guī)定了這些子系統(tǒng)的責任，同時還提供了 用于組織和管理這些子系統(tǒng)的規(guī)則和向?qū)?。典型的體系結 構模式如OSI參考模型。,5.1 軟件體系結構的基本概念,體系結構模式、風格和框架的概念,9.1 軟件體系結構的基本概念,（2）設計模式（design pattern）：為軟件系統(tǒng)的子系 統(tǒng)、構件或者構件之間的關系提供一個精煉之后的解決方 案，描述了在特定環(huán)境下，用于解決通用軟件設計問題的 構件以及這些構件相互通信時的各種結構。有代表

4、性的設 計模式是Erich Gamma及其同事提出的23種設計模式。 （3）慣用法（idiom）：是與編程語言相關的低級模式， 描述如何實現(xiàn)構件的某些功能，或者利用編程語言的特性 來實現(xiàn)構件內(nèi)部要素之間的通信功能。,9.1 軟件體系結構的基本概念,2風格 風格是帶有一種傾向性的模式。同一個問題可以有不同 的解決問題的方案或模式，但我們根據(jù)經(jīng)驗，通常會強烈 傾向于采用特定的模式，這就是風格。 每種風格描述一種系統(tǒng)范疇，該范疇包括： （1）一組構件（如數(shù)據(jù)庫、計算模塊）完成系統(tǒng)需要的某 種功能； （2）一組連接件，它們能使構件間實現(xiàn)“通信”、“合作”和“協(xié)調(diào)”； （3）約束，定義構件如何集成為一個

5、系統(tǒng)； （4）語義模型，它能使設計者通過分析系統(tǒng)的構成成分的 性質(zhì)來理解系統(tǒng)的整體性質(zhì)。,9.1 軟件體系結構的基本概念,3框架 隨著應用的發(fā)展和完善，某些帶有整體性的應用模式被逐漸固定下來，形成特定的框架，包括基本構成元素和關系。 框架是特定應用領域問題的體系結構模式，框架定義了基本構成單元和關系后，開發(fā)者就可以集中精力解決業(yè)務邏輯問題。 在組織形式上，框架是一個待實例化的完整系統(tǒng)，定義了軟件系統(tǒng)的元素和關系，創(chuàng)建了基本的模塊，定義了涉及功能更改和擴充的插件位置。典型的框架例子有MFC框架和Struts框架。,5.1 軟件體系結構的基本概念,體系結構的重要作用 （1）體系結構的表示有助于風險

6、承擔者（項目干系人）進行交流。 （2）體系結構突出了早期設計決策。 （3）軟件體系結構是可傳遞和可復用的模型。,9.2 典型的體系結構風格,管道/過濾器結構,5.2 典型的體系結構風格,1、數(shù)據(jù)流風格 當輸入數(shù)據(jù)經(jīng)過一系列的計算和操作構件的變換形成輸出 數(shù)據(jù)時，可以應用這種體系結構。管道/過濾器、批處理序 列都屬于數(shù)據(jù)流風格。 管道/過濾器結構如下圖所示。,9.2 典型的體系結構風格,從上圖可看出，管道/過濾器結構擁有一組被稱為過濾器（filter）的構件，這些構件通過管道（pipe）連接，管道將數(shù)據(jù)從一個構件傳送到下一個構件。每個過濾器獨立于其上游和下游的構件而工作，過濾器的設計要針對某種形

7、式的數(shù)據(jù)輸入，并且產(chǎn)生某種特定形式的數(shù)據(jù)輸出。 如果數(shù)據(jù)流退化成為單線的變換，則稱為批處理序列（batch sequential）。這種結構接收一批數(shù)據(jù)，然后應用一系列連續(xù)的構件（過濾器）變換它。,9.2 典型的體系結構風格,管道/過濾器風格具有以下優(yōu)點： （1）使得軟構件具有良好的隱蔽性和高內(nèi)聚、低耦合的特 點。 （2）允許設計者將整個系統(tǒng)的輸入/輸出行為看成是多個過 濾器的行為的簡單合成。 （3）支持軟件復用。只要提供適合在兩個過濾器之間傳送 的數(shù)據(jù)，任何兩個過濾器都可被連接起來。 （4）系統(tǒng)維護和增強系統(tǒng)性能簡單。新的過濾器可以添加 到現(xiàn)有系統(tǒng)中來；舊的可以被改進的過濾器替換掉。 （5）

8、允許對一些如吞吐量、死鎖等屬性的分析。 （6）支持并行執(zhí)行。每個過濾器是作為一個單獨的任務完 成，因此可與其他任務并行執(zhí)行。,管道/過濾器風格主要缺點如下： （1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數(shù)據(jù)，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉(zhuǎn)換。 （2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。 （3）因為在數(shù)據(jù)傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導致了系統(tǒng)性能下降，并增加了編寫過濾器的復雜性。,2、倉庫結構,倉庫或知識庫結構(Repository architecture) 倉

9、庫結構是一種以數(shù)據(jù)為中心的體系結構 包含兩種不同的軟件部件：一個中心數(shù)據(jù)庫和一組相互獨立的處理中心數(shù)據(jù)的子系統(tǒng) 主要適合于數(shù)據(jù)由一個子系統(tǒng)產(chǎn)生而由其他子系統(tǒng)使用的情形 典型應用：現(xiàn)代編譯器、管理信息系統(tǒng)、CAD系統(tǒng)和CASE工具集等,倉庫結構,14,3、分層結構,層次化是一種概念，它將軟件設計組織成為類或組件的層次或集合，在同一個層次上的類或組件完成一個特定的目的 良好的層次結構可以易于系統(tǒng)的擴展與維護，不同的層次之間通過接口進行通信 例如：網(wǎng)絡協(xié)議OSI參考模型,15,網(wǎng)絡協(xié)議OSI參考模型,分層體系結構,17,5.3 分布式系統(tǒng)結構,在集中式計算技術時代廣泛使用的是大型機/小型機計算模型。

10、 20世紀80年代以后，集中式結構逐漸被以PC為主的微機網(wǎng)絡所取代。個人計算機和工作站的采用，永遠改變了大型機/小型機計算模型，從而產(chǎn)生了分布式計算模型。,5.3 分布式系統(tǒng)結構,分布式系統(tǒng)6個重要特征：（ Coulouris 等1994年提出） 資源共享 允許硬件、軟件資源共享使用 開放性 允許來自不同廠商的軟/硬兼容產(chǎn)品 并發(fā)性 許多過程可以在網(wǎng)絡的不同計算機上同時運行，并允許在期間彼此通訊 可伸縮性 分布式系統(tǒng)至少要有可伸縮性，系統(tǒng)的能力可以通過增加新的資源來滿足對系統(tǒng)的新的需求 容錯性 錯誤發(fā)生時可能降低系統(tǒng)的服務能力，但徹底喪失服務能力只有在發(fā)生網(wǎng)絡錯誤時才會出現(xiàn) 透明性 對用戶隱藏

11、了系統(tǒng)分布的存在,分布式系統(tǒng)的缺點： 復雜性：比集中式系統(tǒng)更復雜。系統(tǒng)性能涉及網(wǎng)絡帶寬和運行其上的不同計算機速度 保密性：能從網(wǎng)絡上的許多計算機上進入系統(tǒng)，而且網(wǎng)絡通訊遭到竊聽 管理有效性：不同的機型、操作系統(tǒng)和版本，有可能一臺機器上的錯誤被傳播到其他機器上，從而產(chǎn)生預想不到的結果 不可預見性：系統(tǒng)負荷、網(wǎng)絡負荷等因素是變化的，故直接影響分布式系統(tǒng)的響應,20,5.3 分布式系統(tǒng)結構,分布式系統(tǒng)設計中的問題 資源識別：如何識別和引用散布在分布式系統(tǒng)中不同計算機上的資源？如：URL（Uniform Resource Locator）命名模式，用來識別WWW的網(wǎng)頁 通信：除TCP/IP外的其他通訊

12、方式以適應特殊需求 服務質(zhì)量：影響服務質(zhì)量的因素包括處理過程在系統(tǒng)中的位置 軟件體系結構：為應用程序選擇一個合適的軟件體系結構以達到期望的服務質(zhì)量,21,5.3 分布式系統(tǒng)結構,分布式系統(tǒng)體系結構 客戶機/服務器體系結構： 系統(tǒng)被看成是提供一組服務供客戶機使用，服務器和客戶機被區(qū)別對待。 分布式對象體系結構： 不再區(qū)分服務器和客戶機，而是將系統(tǒng)當成交互的一組對象，他們的位置無關緊要，服務提供者和服務消費者之間沒有區(qū)別。,22,5.3 分布式系統(tǒng)結構,5.3 分布式系統(tǒng)結構,傳統(tǒng)的C/S體系結構分為兩層。在這種體系結構中，一個應用系統(tǒng)被劃分為客戶機和服務器兩部分。典型的兩層C/S體系結構如下圖所

13、示。,客戶機/服務器體系結構,在一個客戶機/服務器體系中，一個應用程序建模成一組服務，這組服務由服務器提供，并由客戶機來使用 客戶機需要知道這些服務器的存在，但通常不知道其他客戶機的存在 客戶機和服務器是不同的過程 過程和處理器之間沒有必要一對一地映射,24,客戶機/服務器體系結構,客戶機/服務器體系結構的邏輯模型,25,客戶機/服務器體系結構,分層表示的應用結構 表示層： 將信息表達給用戶 并關注與用戶的交互 應用處理層： 關注實現(xiàn)應用邏輯 數(shù)據(jù)管理層： 關注所有數(shù)據(jù)庫的操作,26,客戶機/服務器體系結構,二層C/S結構 最簡單的客戶/服務器體系結構 一個應用被組織成一組客戶機和一個服務器

14、二層C/S結構的兩種形態(tài)： 瘦客戶機模型 所有的應用處理和數(shù)據(jù)管理都在服務器上執(zhí)行，客戶機只負責表示部分 胖客戶機模型 服務只負責對數(shù)據(jù)的管理，客戶機實現(xiàn)應用邏輯和與用戶的交互,27,瘦客戶機和胖客戶機,28,客戶機/服務器體系結構,客戶機/服務器體系結構,瘦客戶機 缺點：繁重的處理負荷都放在服務器和網(wǎng)絡上，造成C/S之間的網(wǎng)絡數(shù)據(jù)流量過大 胖客戶機 較好地利用的客戶端處理機的能力，著名的實例：銀行ATM系統(tǒng) 缺點：應用分散在許多不同的計算機上，當更新軟件時工作量大，系統(tǒng)管理復雜,29,客戶機/服務器體系結構,客戶機/服務器ATM系統(tǒng),31,三層C/S結構 三層C/S結構不意味著有三個計算機系

15、統(tǒng)連到網(wǎng)絡上，可以僅僅是軟件上的分層，即：一臺服務器既提供應用處理又提供數(shù)據(jù)管理,客戶機/服務器體系結構,三層客戶/服務器風格,32,瀏覽器/服務器（B/S）風格,瀏覽器/服務器（B/S）風格就是上述三層應用結構的一種實現(xiàn)方式，其具體結構為：瀏覽器/Web服務器/數(shù)據(jù)庫服務器。 B/S體系結構主要是利用不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器就實現(xiàn)了原來需要復雜的專用軟件才能實現(xiàn)的強大功能，并節(jié)約了開發(fā)成本。從某種程度上來說，B/S結構是一種全新的軟件體系結構。,33,B/S體系結構,34,35,互聯(lián)網(wǎng)銀行系統(tǒng)的分布式體系結構,其間通訊可不基于互聯(lián)網(wǎng)標準，可以使用支持

16、數(shù)據(jù)庫查詢的有效中間件負責提取數(shù)據(jù),B/S體系結構優(yōu)點,基于B/S體系結構的軟件，系統(tǒng)安裝、修改和維護全在服務器端解決。用戶在使用系統(tǒng)時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級 B/S體系結構還提供了異種機、異種網(wǎng)、異種應用服務的聯(lián)機、聯(lián)網(wǎng)、統(tǒng)一服務的最現(xiàn)實的開放性基礎。,36,分布式對象體系結構,分布式對象體系結構 在分布式對象體系結構設計中客戶機和服務器不存在差別 構成系統(tǒng)的基本組件是對象，一個對象能向另一個對象提供服務，并能接受來自其它對象的服務 接受服務者即扮演客戶機角色，提供服務者就是服務器,37,分布式對象體系結構,分布式對象體系

17、結構,分布式對象體系結構,對象可能分布在網(wǎng)絡的多臺計算機上，它們通過中間件相互通訊，這個中間件被稱作“對象請求代理”（也叫：軟總線） 對象體系結構的主要缺點是設計比C/S結構更復雜 適合使用分布式對象結構的一個實例是數(shù)據(jù)挖掘系統(tǒng)，即：在多個數(shù)據(jù)庫間尋找數(shù)據(jù)間的關系,分布式對象體系結構,數(shù)據(jù)挖掘系統(tǒng)的分布式體系結構,41,其中： 數(shù)據(jù)庫提供只讀訪問功能的對象 集成器專注一種特別類型的關系，從所有數(shù)據(jù)庫中收集信息試著推出這種關系 可視生成器與集成器對象交互，提供所發(fā)現(xiàn)關系的可視化效果圖和報告,分布式對象體系結構,41,5.4 體系結構框架,1、模型/視圖/控制器結構 Modle/View/Cont

18、roller Architecture 支持數(shù)據(jù)的多重表示 要顯示的數(shù)據(jù)被封裝在模型中的對象里 每個模型對象可能與許多的視圖對象關聯(lián) 每個視圖都有一個相關的處理用戶輸入和設備交互的控制對象,9.5 體系結構框架,用戶交互的MVC模型,信息表示示意圖：,44,J2EE的核心體系結構就是在MVC框架的基礎上進行擴展得到的，如下圖所示。,9.5 體系結構框架,J2EE體系結構框架,J2EE的核心體系結構框架,客戶層：用戶通過客戶層與系統(tǒng)交互。該層可以是各種類型的客戶端。例如，可編程客戶端（如基于Java Swing的客戶端或applet），純Web瀏覽器客戶端，WML移動客戶端等。 資源層：資源層可

19、以是企業(yè)數(shù)據(jù)庫，電子商務解決方案中的外部企業(yè)系統(tǒng)，或者是外部SOA服務。數(shù)據(jù)可以分布在多個服務器上。,從上圖可看出，J2EE模型是分層結構，中間的3層（表示層，業(yè)務層，集成層）包含應用程序構件，客戶層和資源層處于應用程序的外圍。,9.5 體系結構框架,表示層：也稱為Web層或服務器端表示層，用戶通過表示層來訪問應用程序。在基于Web的應用系統(tǒng)中，表示層由用戶界面代碼和運行于Web服務器或應用服務器上的過程組成。參考MVC框架，表示層包括視圖構件和控制器構件。 業(yè)務層：業(yè)務層包含表示層中的控制器構件沒有實現(xiàn)的一部分應用邏輯。它負責確認和執(zhí)行企業(yè)范圍內(nèi)的業(yè)務規(guī)則和事務，并管理從資源層加載到應用程序

20、高速緩存中的業(yè)務對象。 集成層：集成層負責建立和維護與數(shù)據(jù)源的連接。例如，通過JDBC與數(shù)據(jù)庫進行通信，利用Java消息服務（JMS）與外部系統(tǒng)聯(lián)合。,9.5 體系結構框架,5.5 設計模式,回顧學過的數(shù)據(jù)結構 Trees, Stacks, Queues 它們給軟件開發(fā)帶來了什么？ 問題 在軟件體系結構設計中是否存在一些可重用的解決方案？ 答案是肯定的 設計模式使我們可以重用已經(jīng)成功的經(jīng)驗 PatternDocumented experience Design Patterns: Elements of Reusable Object-Oriented Software,48,在眾多應用中普遍

21、存在的軟件結構和結構關系。它們在不同的領域中獲得應用，成為處理特定問題的高效且成熟的設計模板，稱為“模式（Pattern）” 設計模式實際上是對經(jīng)常重復出現(xiàn)的類似問題的一個解決方案（一個模式），這個解決方案在其它語境中也同樣適用。 面向?qū)ο蟮脑O計模式是一組相互協(xié)作以實現(xiàn)某個設計目標的對象或?qū)ο箢惖男〖?49,5.5 設計模式,一般來說，一個模式有4個基本的要素： 模式名稱：用于描述模式的名字，說明模式的問題、解決方案和效果。 問題：說明在何種場合使用模式。 解決方案：描述設計的組成成分、它們之間的相互關系、各自的職責和合作方式。 效果：描述了模式使用的效果及使用模式應當權衡的問題。,目前已提

22、出的設計模式的類型： 創(chuàng)建型模式 抽象工廠、生成器、工廠方法、原型、單件 結構型模式 適配器、橋接、組成、裝飾、外觀等 行為型模式 職責鏈、命令、迭代器、狀態(tài)等,51,抽象工廠,(1) 目的：提供一個接口用以創(chuàng)建一個相聯(lián)系或相依賴的對象族，而無須指定它們的具體類。 (2) 思路：例如，在創(chuàng)建可支持多種GUI標準（如Motif和Persentation Manager）的繪圖用戶界面工具包時，因為不同的GUI標準會定義出不同外觀及行為的“用戶界面組件”（widget），如滾動條、按鈕、視窗等。為了能夠囊括各種GUI標準，應用程序不能把組件寫死，不能限制到特定GUI風格的組件類，否則日后很難換成其

23、他GUI風格的組件。,抽象工廠,解決方法是：先定義一個抽象類WidgetFactory（用斜體字區(qū)分抽象類），這個類聲明了創(chuàng)建各種基本組件的接口，再逐一替各種基本組件定義相對應的抽象類，如 ScrollBar、Window等，讓它們的具體子類來真正實現(xiàn)特定的GUI標準。,抽象工廠,可支持多種GUI標準的繪圖用戶界面工具包的結構圖,表示了兩種不同的用戶界面工具包，可抽象為一種形式WindowKit 根據(jù)實現(xiàn)平臺的不同， WindowKit被綁定到不同的實例中 說明：設計模式描述了對重復出現(xiàn)問題的解決方案,55,抽象工廠,(3) 結構：抽象工廠模式的結構如圖所示。,抽象工廠,(4) 參與者職責 a

24、) 抽象工廠類（AbstractFactory）：聲明創(chuàng)建抽象產(chǎn)品對象的操作的接口。 b) 具體工廠類（ConcreteFactory）：實現(xiàn)產(chǎn)生具體產(chǎn)品對象的操作。 c) 抽象產(chǎn)品類（AbstractProduct）：聲明一種產(chǎn)品對象的接口。 d) 具體產(chǎn)品類（ConcreteProduct）：定義將被相應的具體工廠類產(chǎn)生的產(chǎn)品對象，并實現(xiàn)抽象產(chǎn)品類接口。 e) 客戶（Client）：僅使用由抽象工廠類和抽象產(chǎn)品類聲明的接口。,抽象工廠,(5) 協(xié)作 在執(zhí)行時，AbstractFactory將產(chǎn)品交給ConcreteFactory創(chuàng)建。 ConcreteFactory類的實例只有一個，專門針

25、對某種特定的實現(xiàn)標準，建立具體可用的產(chǎn)品對象。 如果想要建立其他標準的產(chǎn)品對象，客戶程序就得改用另一種ConcreteFactory。,適配器,(1)目的：適配器模式將一個類的接口轉(zhuǎn)換為客戶期望的另一種接口，使得原本不匹配的接口而無法合作的類可以一起工作。 (2)思路：有時要將兩個沒有關系的類組合在一起使用，一種解決方案是修改各自類的接口，另一種辦法是使用Adapter模式，在兩種接口之間創(chuàng)建一個混合接口。 例如，設有一個圖形編輯器，可畫直線、多邊形、文本等。它的接口定義成抽象類Shape，它的子類負責畫各種圖形。此外，還有一個外購的GUI軟件包TextView，用于顯示，但它沒有Shape功

26、能。,適配器,如何讓TextView的接口轉(zhuǎn)換成為Shape的接口，有兩種方法： 讓TextShape同時繼承Shape的接口和TextView的服務（多重繼承）； 在TextShape中建立TextView的實例，再通過TextView給出TextShape的接口。 前者是適配器的類模式，后者是對象模式。下圖就是適配器的對象模式。,適配器,(3) 結構：適配器模式有類適配器模式和對象適配器模式。類適配器可以通過多繼承方式實現(xiàn)不同接口之間的相容和轉(zhuǎn)換，如圖所示。,適配器,而一個對象適配器則依賴對象組合的技術實現(xiàn)接口的相容和轉(zhuǎn)換，如圖所示。,適配器,(4) 參與者職責 a) 目標（Target）

27、：定義客戶使用的與應用領域相關的接口。 b) 客戶（Client）：與具有Target接口的對象合作。 c) 被匹配者（Adaptee）：需要被轉(zhuǎn)換匹配的一個已存在接口。 d) 適配器（Adapter）：將Adaptee的接口與Target接口匹配。,適配器,(5) 協(xié)作：客戶調(diào)用Adapter對象的操作，然后Adapter的操作又調(diào)用Adaptee對象中負責處理相應請求的操作。,觀察者,(1)目的：定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知，并被自動更新。 (2)思路：例如，許多GUI軟件包都將數(shù)據(jù)顯示部分與應用程序底層的數(shù)據(jù)表示分開，以利于分

28、別復用。但這些類也能合作，如圖所示的計算表和直方圖都是針對同一數(shù)據(jù)對象的兩種不同表示方式。,觀察者,(3) 結構：Observer模式的結構如圖所示。,觀察者,(4) 參與者職責 a) 主題（Subject）：認得它的觀察者。任意數(shù)目的觀察者對象均可訂閱一個主題。另外，提供一個連接觀察者對象和解除連接的接口。 b) 觀察者（Observer）：定義了一個自我更新的接口。一旦發(fā)現(xiàn)主題有變時借助接口通知自己隨之改變。 c) 具體主題（ConcreteSubject）：存儲具體觀察者對象關心的狀態(tài)；當狀態(tài)改變時向它的觀察者發(fā)送通知。 d) 具體觀察者（ConcreteObserver）：維持一個對具體主題對象的引用；存儲要與主題一致的狀態(tài)；實現(xiàn)觀察者的自我更新