軟件體系結構與設計模式概述

本資料來源第9章軟件體系結構與設計模式軟件體系結構的基本概念典型的軟件體系結構風格特定領域的軟件體系結構分布式系統(tǒng)結構體系結構框架設計模式9.1軟件體系結構的基本概念什么是體系結構目前還沒有一個公認的關于軟件體系結構的定義，許多專家學者從不同角度對軟件體系結構進行了描述。Bass、Clements和Kazman給出了如下定義：“一個程序或計算機系統(tǒng)的軟件體系結構是指系統(tǒng)的一個或者多個結構。結構中包括軟件的構件、構件的外部可見屬性以及它們之間的相互關系。外部可見屬性則是指軟件構件提供的服務、性能、使用特性、錯誤處理、共享資源使用等?！边@一定義強調(diào)在任一體系結構表述中“軟件構件”的角色。DewaynePerry和A1exanderWo1f曾這樣定義：“軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數(shù)據(jù)構件和連接構件。處理構件負責對數(shù)據(jù)進行加工，數(shù)據(jù)構件是被加工的信息，連接構件把體系結構的不同部分組合連接起來?！边@一定義注重區(qū)分處理構件、數(shù)據(jù)構件和連接構件。雖然軟件體系結構的定義在變化，但其意圖是清晰的。體系結構設計是一系列決策和基本原理的集合，這些決策的目標在于開發(fā)高效的軟件體系結構。在體系結構設計中所強調(diào)的基本原理是系統(tǒng)的可理解性、可維護性和可擴展性。9.1軟件體系結構的基本概念1．模式軟件設計模式是從軟件設計過程中總結出來的，是針對特定問題的解決方案。建筑師C.Alexander對模式給出的經(jīng)典定義是：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題及該問題解決方案的核心。在軟件系統(tǒng)中，可以將模式劃分為以下3類。（1）體系結構模式（architecturalpattern）：表達了軟件系統(tǒng)的基本結構組織形式或者結構方案，包含了一組預定義的子系統(tǒng)，規(guī)定了這些子系統(tǒng)的責任，同時還提供了用于組織和管理這些子系統(tǒng)的規(guī)則和向?qū)?。典型的體系結構模式如OSI參考模型。9.1軟件體系結構的基本概念體系結構模式、風格和框架的概念

（2）設計模式（designpattern）：為軟件系統(tǒng)的子系統(tǒng)、構件或者構件之間的關系提供一個精煉之后的解決方案，描述了在特定環(huán)境下，用于解決通用軟件設計問題的構件以及這些構件相互通信時的各種結構。有代表性的設計模式是ErichGamma及其同事提出的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）約束，定義構件如何集成為一個系統(tǒng)；（4）語義模型，它能使設計者通過分析系統(tǒng)的構成成分的性質(zhì)來理解系統(tǒng)的整體性質(zhì)。9.1軟件體系結構的基本概念

體系結構風格定義了一個系統(tǒng)家族，即一個體系結構定義一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型，而這組約束指出系統(tǒng)是如何將這些構件和連接件組合起來的。體系結構風格反映了領域中眾多系統(tǒng)所共有的結構和語義特性，并指導如何將各個模塊和子系統(tǒng)有效地組織成一個完整的系統(tǒng)。對體系結構風格的研究和實踐為大粒度的軟件復用提供了可能。9.1軟件體系結構的基本概念9.1軟件體系結構的基本概念3．框架隨著應用的發(fā)展和完善，某些帶有整體性的應用模式被逐漸固定下來，形成特定的框架，包括基本構成元素和關系?？蚣苁翘囟☉妙I域問題的體系結構模式，框架定義了基本構成單元和關系后，開發(fā)者就可以集中精力解決業(yè)務邏輯問題。在組織形式上，框架是一個待實例化的完整系統(tǒng)，定義了軟件系統(tǒng)的元素和關系，創(chuàng)建了基本的模塊，定義了涉及功能更改和擴充的插件位置。典型的框架例子有MFC框架和Struts框架。

體系結構的重要作用體現(xiàn)在以下三個方面：（1）體系結構的表示有助于風險承擔者（項目干系人）進行交流。（2）體系結構突出了早期設計決策。（3）軟件體系結構是可傳遞和可復用的模型。

9.1軟件體系結構的基本概念體系結構的重要作用當輸入數(shù)數(shù)據(jù)經(jīng)過過一系列列的計算算和操作作構件的的變換形形成輸出出數(shù)據(jù)時，，可以應應用這種種體系結結構。管道/過濾器、批處理序序列都屬于數(shù)數(shù)據(jù)流風風格。管管道/過濾器結結構如下下圖所示示。9.2典型的體體系結構構風格數(shù)據(jù)流風風格管道/過濾器結結構從上圖可可看出，，管道/過濾器結結構擁有有一組被被稱為過濾器（filter）的構件件，這些些構件通通過管道（pipe）連接，，管道將將數(shù)據(jù)從從一個構構件傳送送到下一一個構件件。每個個過濾器器獨立于于其上游游和下游游的構件件而工作作，過濾濾器的設設計要針針對某種種形式的的數(shù)據(jù)輸輸入，并并且產(chǎn)生生某種特特定形式式的數(shù)據(jù)據(jù)輸出。。如果數(shù)據(jù)據(jù)流退化化成為單單線的變變換，則則稱為批處理序列（batchsequential）。這種結構構接收一批數(shù)數(shù)據(jù)，然后應應用一系列連連續(xù)的構件（（過濾器）變變換它。9.2典型的體系結結構風格管道/過濾器風格具具有以下優(yōu)點：（1）使得軟構件件具有良好的的隱蔽性和高高內(nèi)聚、低耦耦合的特點。（2）允許設計者者將整個系統(tǒng)統(tǒng)的輸入/輸出行為看成成是多個過濾器的行為的的簡單合成。。（3）支持軟件復復用。只要提提供適合在兩兩個過濾器之之間傳送的數(shù)據(jù)，任何何兩個過濾器器都可被連接接起來。（4）系統(tǒng)維護和和增強系統(tǒng)性性能簡單。新新的過濾器可可以添加到現(xiàn)有系統(tǒng)中中來；舊的可可以被改進的的過濾器替換換掉。（5）允許對一些些如吞吐量、、死鎖等屬性性的分析。（6）支持并行執(zhí)執(zhí)行。每個過過濾器是作為為一個單獨的的任務完成，因此可與與其他任務并并行執(zhí)行。9.2典型的體系結結構風格管道/過濾器風格主要缺點如下：（1）通常導致進進程成為批處處理的結構。。這是因為雖雖然過濾器可增量式地地處理數(shù)據(jù)，，但它們是獨獨立的，所以以設計者必須須將每個過濾器器看成一個完完整的從輸入入到輸出的轉轉換。（2）不適合處理理交互的應用用。當需要增增量地顯示改改變時，這個問題尤為為嚴重。（3）因為在數(shù)據(jù)據(jù)傳輸上沒有有通用的標準準，每個過濾濾器都增加了解析和合合成數(shù)據(jù)的工工作，這樣就就導致了系統(tǒng)統(tǒng)性能下降，，并增加了編寫寫過濾器的復復雜性。9.2典型的體系結結構風格在此類體系結結構中，存在在以下3種子風格。1．主程序/子程序體系結結構這種傳統(tǒng)的程程序結構將功功能分解為一一個控制層次次，其中“主”程序序調(diào)用一組程程序構件，這這些程序構件件又去調(diào)用別別的程序構件，，如下圖所示示。這種結構構總體上為樹樹狀結構，可以在底底層存在公共共模塊。9.2典型的體系結結構風格調(diào)用—返回風格主程序/子程序體系結結構的優(yōu)點如下:（1）可以使用自自頂向下，逐逐步分解的方方法得到體系系結構圖，典型的拓拓撲結構為樹樹狀結構?；诙x—使用關系對子子程序進行分解解，使用過程程調(diào)用作為程程序之間的交交互機制。（2）采用程序設設計語言支持持的單線程控控制。其主要缺點如下:（1）子程序的正正確性難于判判斷。需要運運用層次推理理來判斷子程序的正確確性，因為子子程序的正確確性取決于它它調(diào)用的子程程序的正確性。。（2）子系統(tǒng)的結結構不清晰。。通常可以將將多個子程序序合成為模塊。9.2典型的體系結結構風格2．面向?qū)ο箫L格格系統(tǒng)的構件封封裝了數(shù)據(jù)和和必須應用到到該數(shù)據(jù)上的的操作，構件間通通過消息傳遞遞進行通信與與合作。與主主程序/子程序的體系結構構相比，面向向?qū)ο箫L格中中的對象交互互會復雜一些。面向?qū)ο笙箫L格與網(wǎng)絡絡應用的需求求在分布性、、自治性、協(xié)作性、演化化性等方面具具有內(nèi)在的一一致性。面向?qū)ο箫L格格具有以下優(yōu)點:（1）因為對象對對其他對象隱隱藏它的表示示，所以可以以改變一個對象的表示示，而不影響響其他對象。。（2）設計者可將將一些數(shù)據(jù)存存取操作的問問題分解成一一些交互的代理程序的的集合。9.2典型的體系結結構風格其缺點如下:（1）為了使一個個對象和另一一個對象通過過過程調(diào)用等等進行交互，必須知知道對象的標標識。只要一一個對象的標標識改變了，就必必須修改所有有其他明確調(diào)調(diào)用它的對象象。（2）必須修改所所有顯式調(diào)用用它的其他對對象，并消除除由此帶來的一些副副作用。例如如，如果A使用了對象B，C也使用了對象象B，那么，C對B的使用所造成成的對A的影響可能是是料想不到的的。9.2典型的體系結結構風格3．層次結構層次結構的基基本結構如下下圖所示。在在這種體系結結構中，整個系統(tǒng)被組織織成一個分層層結構，每一一層為上層提提供服務，并并作為下一層的的客戶。9.2典型的體系結結構風格這種風格支持持基于可增加加抽象層的設設計。允許將將復雜問題分解成一個個增量步驟序序列的實現(xiàn)。。由于每一層層最多只影響響兩層，同時只只要給相鄰層層提供相同的的接口，允許許每層用不同同的方法實現(xiàn)，，同樣為軟件件復用提供了了強大的支持持。層次結構具有有以下優(yōu)點:（1）支持基于抽抽象程度遞增增的系統(tǒng)設計計，使設計者者可以把一個復雜系統(tǒng)統(tǒng)按遞增的步步驟進行分解解。（2）支持功能增增強，因為每每一層至多和和相鄰的上下下層交互，因此，功功能的改變最最多影響相鄰鄰的內(nèi)外層。。9.2典型的體系結結構風格（3）支持復用。。只要提供的的服務接口定定義不變，同同一層的不同實現(xiàn)可以以交換使用。。這樣，就可可以定義一組組標準的接口口，從從而允允許各各種不不同的的實現(xiàn)現(xiàn)方法法。其缺點如下:（1）并不不是每每個系系統(tǒng)都都可以以很容容易地地劃分分為分分層的的模式式，甚至即即使一一個系系統(tǒng)的的邏輯輯結構構是層層次化化的，，出于于對系系統(tǒng)性能能的考考慮，，系統(tǒng)統(tǒng)設計計師不不得不不把一一些低低級或或高級級的功能能綜合合起來來。（2）很難難找到到一個個合適適的、、正確確的層層次抽抽象方方法。。9.2典型的的體系系結構構風格格數(shù)據(jù)庫庫系統(tǒng)統(tǒng)、超文本本系統(tǒng)統(tǒng)和黑板系系統(tǒng)都屬于于倉庫庫風格。在在這種種風格格中，，數(shù)據(jù)據(jù)倉庫（（如文文件或或數(shù)據(jù)據(jù)庫））位于這這種體體系結結構的的中心心，其他構構件會會經(jīng)常常訪問問該數(shù)數(shù)據(jù)倉庫庫，并并對倉倉庫中中的數(shù)數(shù)據(jù)進行行增加加、修修改或或刪除除操作。。右圖圖為一一個典典型的的倉庫風風格的的體系系結構構。9.2典型的的體系系結構構風格格倉庫風風格上圖中中,可把中中心存存儲庫庫變換換成““黑板板”，，黑板板構件件負責責協(xié)調(diào)信息息在客客戶間間的傳傳遞，，當用用戶感感興趣趣的數(shù)數(shù)據(jù)發(fā)發(fā)生變變化時時，它將通通知客客戶軟軟件。。黑板板系統(tǒng)統(tǒng)的組組成如如下圖圖所示示。黑黑板系系統(tǒng)的傳統(tǒng)統(tǒng)應用用是信信號處處理領領域，，如語語音和和模式式識別別。另另一應應用是松耦耦合代代理數(shù)數(shù)據(jù)共共享存存取。。9.2典型的的體系系結構構風格格特定的的應用用還需需要特特定的的體系系結構構模型型。這這些體體系結結構模模型稱稱為領域相相關的的體系系結構構。有兩種種領域域相關關的體體系結結構模模型：：類屬模模型（genericmodel）和參考模模型（referencemodel）。9.3特定領領域的的軟件件體系系結構構9.3特定領領域的的軟件件體系系結構構類屬模模型類屬模模型是是從許許多實實際系系統(tǒng)中中抽象象出來來的一一般模模型，，它封封裝了了這些些系統(tǒng)統(tǒng)的主主要特特征。。例如，，許多多圖書書館開開發(fā)了了自己己的圖圖書館館館藏藏/流通系系統(tǒng)，，若把把它們們的共共同功功能抽抽取出出來并并創(chuàng)建建一個個讓所所有圖圖書館館都認認可的的系統(tǒng)統(tǒng)體系系結構構模型型，這這就是是類屬屬模型型。9.3特定領領域的的軟件件體系系結構構類屬模模型的的一個個最著著名的的例子子是編譯器器模型型，由這這個模模型已已開發(fā)發(fā)出了了數(shù)以以千計計的編編譯器器。參考模模型源源于對對應用用領域域的研研究，，它描述了了一個個理想想化的的包含含了系系統(tǒng)應應具有有的所所有特特征的的軟件件體系系結構構。它是更更抽象象且是是描述述一大大類系系統(tǒng)的的模型型，并并且也也是對對設計計者有有關某某類系系統(tǒng)的的一般般結構構的指指導。。9.3特定領領域的的軟件件體系系結構構參考模模型9.3特定領領域的的軟件件體系系結構構參考模模型的的典型型例子子是開放式式系統(tǒng)統(tǒng)互聯(lián)聯(lián)（OSI）參考考模型型。9.3特定領領域的的軟件件體系系結構構以上兩兩種不不同類類型的的模型型之間間并不不存在在嚴格格的區(qū)區(qū)別，，也可可以將將類屬屬模型型視為為參考考模型型。區(qū)別之之一是是類屬屬模型型可以以直接接在設設計中中復用用，而而參考考模型型一般般是用用于領領域概概念間間的交交流和和對可可能的的體系系結構構做出出比較較。另外，，類屬屬模型型通常常是經(jīng)經(jīng)過““自下下而上上”地地對已已有系系統(tǒng)的的抽象象，而而參考考模型型是““由上上到下下”地地產(chǎn)生生的。。9.4分布式式系統(tǒng)統(tǒng)結構構在集中中式計計算技技術時時代廣廣泛使使用的的是大大型機機/小型機機計算算模型型。20世紀80年代以以后，，集中中式結結構逐逐漸被被以PC為主的的微機機網(wǎng)絡絡所取取代。。個人人計算算機和和工作作站的的采用用，永永遠改改變了了大型型機/小型機機計算算模型型，從從而產(chǎn)產(chǎn)生了了分布布式計計算模模型。。9.4分布布式式系系統(tǒng)統(tǒng)結結構構分布布式式計計算算模模型型主主要要具具有有以以下下優(yōu)優(yōu)點點：：(1)資源源共共享享。。分分布布式式系系統(tǒng)統(tǒng)允允許許硬硬件件、、軟軟件件等等資資源源共共享享使使用用。。(2)經(jīng)濟濟性性。。(3)性能能與與可可擴擴展展性性。。(4)固有有分分布布性性。。(5)健壯壯性性。。分布布式式系系統(tǒng)統(tǒng)的的一一個個最最簡簡單單的的模模型型是是多多處處理理器器系系統(tǒng)統(tǒng)，，系系統(tǒng)統(tǒng)由由許多多進進程程組組成成，，這這些些進進程程可可以以在在不不同同的的處處理理器器上上并并行行運運行行，，可以以極極大大地地提提高高系系統(tǒng)統(tǒng)的的性性能能。。由于于大大型型實實時時系系統(tǒng)統(tǒng)對對響響應應時時間間要要求求較較高高，，這這種種模模型型在在大大型型實時時系系統(tǒng)統(tǒng)中中比比較較常常見見。。大大型型實實時時系系統(tǒng)統(tǒng)需需要要實實時時采采集集信信息息，，并并利用用采采集集到到的的信信息息進進行行決決策策，，然然后后發(fā)發(fā)送送信信號號給給執(zhí)執(zhí)行行機機構構。。雖雖然，，信信息息采采集集、、決決策策制制定定和和執(zhí)執(zhí)行行控控制制這這些些進進程程可可以以在在同同一一臺臺處理理器器上上統(tǒng)統(tǒng)一一調(diào)調(diào)度度執(zhí)執(zhí)行行，，但但使使用用多多處處理理器器能能夠夠提提高高系系統(tǒng)統(tǒng)性性能。。9.4分布布式式系系統(tǒng)統(tǒng)結結構構多處處理理器器體體系系結結構構客戶戶機機/服務務器器（（client/server，C/S）體體系系結結構構是是基基于于資源不對對等，且且為實現(xiàn)現(xiàn)共享而而提出來來的，由由服務器、客戶機和網(wǎng)絡三部分組組成。在C/S體系結構構中，客客戶機可可以通過過遠程調(diào)調(diào)用來獲獲取服務器提供供的服務務，因此此，客戶戶機必須須知道可可用的服服務器的的名字及它它們所提提供的服服務，而而服務器器不需要要知道客客戶機的的身份，也也不需要要知道有有多少臺臺服務器器在運行行。9.4分布式系系統(tǒng)結構構客戶/服務器體體系結構構9.4分布式系系統(tǒng)結構構傳統(tǒng)的C/S體系結構構分為兩兩層。在在這種體體系結構構中，一一個應用系系統(tǒng)被劃劃分為客客戶機和和服務器器兩部分分。典型型的兩層層C/S體系結構構如下圖圖所示。。兩層C/S體系結構構可以有有兩種形形態(tài)：（1）瘦客戶機機模型。在瘦客客戶機模模型中，，數(shù)據(jù)管管理部分分和應用邏邏輯都在在服務器器上執(zhí)行行，客戶戶機只負負責表示示部分。。瘦客戶機機模型的的主要缺缺點：它將繁重重的處理理負荷都都放在了了服務器器和網(wǎng)絡絡上，服服務器負負責所有有的計算算，這將將增加客客戶機和和服務器器之間的的網(wǎng)絡流流量。目前個人人計算機機所具有有的處理理能力在在瘦客戶戶機模型型中用不不上。9.4分布式系系統(tǒng)結構構（2）胖客戶機機模型。在這種種模型中中，服務務器只負負責對數(shù)數(shù)據(jù)的管理。?？蛻魴C機上的軟軟件實現(xiàn)現(xiàn)應用邏邏輯和與與系統(tǒng)用用戶的交交互。胖客戶機機模型能能夠利用用客戶機機的處理理能力，，比瘦客客戶機模型在分分布處理理上更有有效。但但另一方方面，隨隨著企業(yè)業(yè)規(guī)模的的日益擴大大，軟件件的復雜雜程度不不斷提高高，胖客客戶機模模型逐漸漸暴露出了了以下缺缺點：開發(fā)成本本較高。。用戶界面面風格不不一，使使用繁雜雜，不利利于推廣廣使用。。軟件移植植困難。。軟件維護護和升級級困難。。9.4分布式系系統(tǒng)結構構為了解決決以上問問題，三層C/S體系結構構應運而生生。三層層C/S體系結構構中增加加了應用用服務器器?？梢砸詫⒄麄€個應用邏邏輯駐留留在應用用服務器器上，而而只有表表示層存存在于客客戶機上上。9.4分布式系系統(tǒng)結構構三層C/S體系結構構將整個個系統(tǒng)分分成表示層、應用邏輯輯層和數(shù)據(jù)層三個部分分，其數(shù)數(shù)據(jù)處理理流程如如下圖所所示。9.4分布式系系統(tǒng)結構構9.4分布式系系統(tǒng)結構構（1）表示層：表示層層是應用用系統(tǒng)的的用戶界界面部分分，擔負負著用戶與應應用程序序之間的的對話功功能。它它用于檢檢查用戶戶從鍵盤盤等輸入的數(shù)數(shù)據(jù)，顯顯示應用用程序輸輸出的數(shù)數(shù)據(jù)，一一般采用用圖形用用戶界面（graphicuserinterface，GUI）。（2）應用邏輯輯層：應用邏邏輯層為為應用系系統(tǒng)的主主體部分分，包含具體的業(yè)業(yè)務處理邏邏輯。通常常在功能層層中包含有有確認用戶戶對應用和數(shù)據(jù)據(jù)庫存取權權限的功能能以及記錄錄系統(tǒng)處理理日志的功功能。（3）數(shù)據(jù)層：數(shù)據(jù)層主主要包括數(shù)數(shù)據(jù)的存儲儲及對數(shù)據(jù)據(jù)的存取操作，一般般選擇關系系型數(shù)據(jù)庫庫管理系統(tǒng)統(tǒng)（RDBMS）。瀏覽器/服務器（browser/server，B/S）風格是三三層體系結構的一一種實現(xiàn)方方式，其具具體結構為為瀏覽器/Web服務器/數(shù)據(jù)庫服務務器。B/S體系結構如如下圖所示示。9.4分布式系統(tǒng)統(tǒng)結構B/S體系結構主主要是利用用不斷成熟熟的.瀏覽器技術術，結合瀏瀏覽器的多多種腳本語語言，用通通用瀏覽器器就實現(xiàn)了了原來需要要復雜的專專用軟件才才能實現(xiàn)的的強大功能能，并節(jié)約約了開發(fā)成成本。從某某種程度上上來說，B/S結構是一種種全新的軟軟件體系結結構。B/S體系結構具具有以下優(yōu)優(yōu)點：（1）基于B/S體系結構的的軟件，系系統(tǒng)安裝、、修改和維維護全在服務器端端解決。（2）B/S體系結構還還提供了異異種機、異異種網(wǎng)、異異種應用服服務的聯(lián)機、、聯(lián)網(wǎng)和統(tǒng)統(tǒng)一服務的的最現(xiàn)實的的開放性基基礎。9.4分布式系統(tǒng)統(tǒng)結構與C/S體系結構相相比，B/S體系結構也也有許多不不足之處。。（1）B/S體系結構缺缺乏對動態(tài)態(tài)頁面的支支持能力，，沒有集成成有效的數(shù)據(jù)據(jù)庫處理功功能。（2）采用B/S體系結構的的應用系統(tǒng)統(tǒng)，在數(shù)據(jù)據(jù)查詢等響響應速度上，要遠遠遠地低于于C/S體系結構。。（3）B/S體系結構的的數(shù)據(jù)提交交一般以頁頁面為單位位，數(shù)據(jù)的的動態(tài)交互性性不強，不不利于在線線事務處理理（OLTP）應用。9.4分布式系統(tǒng)統(tǒng)結構在客戶機/服務器模型型中，客戶戶機和服務務器的地位位是不同的。為了消消除客戶機機與服務器器之間的差差別，提高高系統(tǒng)的伸伸縮性以及有有效地均衡衡負載，可可采用分布布式對象體體系結構來來設計系統(tǒng)。。分布式對象象的實質(zhì)是在在分布式異異構環(huán)境下下建立應用用系統(tǒng)框架和對象象構件，它它將應用服服務分割成成具有完整整邏輯含義義的獨立子模模塊（稱為為構件），各個子子模塊可放放在同一臺服務器器或分布在在多臺服務務器上運行行，模塊之之間通過中中間件互相通通信。9.4分布式系統(tǒng)統(tǒng)結構分布式對象象體系結構構通常將這個個中間件稱稱為軟件總線或?qū)ο笳埱蟠?，它的作用用是在對象象之間提供供一個無縫縫接口。9.4分布式系統(tǒng)統(tǒng)結構分布式對象象技術的應應用目的是為了降低低主服務器器的負荷、、共享網(wǎng)絡資資源、平衡衡網(wǎng)絡中計計算機業(yè)務務處理的分分配，提高高計算機系統(tǒng)協(xié)協(xié)同處理的的能力，從從而使應用用的實現(xiàn)更更為靈活。。分布式對象象技術的基基礎是構件件。構件是一些獨立立的代碼封封裝體，在在分布計算算的環(huán)境下下可以是一個簡單的的對象，但大多數(shù)數(shù)情況下是是一組相關的的對象組合合體，提供一定定的服務。。分布式環(huán)境境下，構件件是一些靈靈活的軟件件模塊，它它們可以位位置透明、、語言獨立立和平臺獨獨立地互相相發(fā)送消息息，實現(xiàn)請請求服務。。構件之間并并不存在客客戶機與服服務器的界界限，接受受服務者扮扮演客戶機機的角色，，提供服務務者就是服服務器。9.4分布式系統(tǒng)統(tǒng)結構9.4分布式系統(tǒng)統(tǒng)結構當前主流的的分布式對對象技術規(guī)規(guī)范有OMG的CORBA、Microsoft公司的.NET和Sun公司的J2EE。它們都支持持服務端構構件的開發(fā)發(fā)，都有其其各自的特特點。代理可以用用于構建帶帶有隔離組組件的分布布式軟件系系統(tǒng)，該軟件通過遠遠程服務調(diào)調(diào)用進行交交互。代理理者負責協(xié)協(xié)調(diào)通信，，諸如轉發(fā)請請求以及傳傳遞結果和和異常等。。1991年，OMG基于面向?qū)ο蠹夹g，，給出了以以對象請求求代理（ORB）為中心的的分布式應應用體系結結構。9.4分布式系統(tǒng)統(tǒng)結構代理在OMG的對象管理理結構中，，ORB是一個關鍵鍵的通信機機制，它以實實現(xiàn)互操作作性為主要要目標，處處理對象之之間的消息息分布。在ORB之上有4個對象接口口：（1）對象服務：定義加入入ORB的系統(tǒng)級服服務，如安安全性、命名和和事務處理理，它們是是與應用領領域無關的的。（2）公共設施：水平級的的服務，定定義應用程程序級服務務。（3）領域接口：面向特定定的領域。。（4）應用接口：面向指定定的現(xiàn)實世世界應用。。是指供應應商或用戶借助于于ORB、公共對象象服務及公公共設施而而開發(fā)的特定產(chǎn)品。。9.4分布式系統(tǒng)統(tǒng)結構MVC框架即模型型—視圖—控制器（model-view-controller）框架，它它強調(diào)將用用戶輸入、、數(shù)據(jù)模型型和數(shù)據(jù)表表示的方式式分開設計計，一個交交互式應用用系統(tǒng)由模型、視圖和控制器3個部件組成成，分別對對應于內(nèi)部部數(shù)據(jù)、數(shù)數(shù)據(jù)表示和和輸入/輸出控制部部分。9.5體系結構框框架MVC框架9.5體系結構框框架MVC框架1.模型對象模型對象獨獨立于外在在顯示內(nèi)容容和形式，，代表應用用領域中的的業(yè)務實體和和業(yè)務規(guī)則則，是整個模型的的核心。模型對象象的變化通過事件處處理通知視視圖和控制制器對象。。2.視圖對象視圖對象代代表GUI對象，并且且以用戶需需要的格式式表示模型型狀態(tài)，是交交互系統(tǒng)與與外界的接接口。視圖圖對象可以以包含子視視圖，子視圖圖用于顯示示模型的不不同部分。。通常，每每個視圖對對象對應一個控控制器對象象。9.5體系結構框框架3.控制器對象象控制器對象象代表鼠標標和鍵盤事事件。它處處理用戶的的輸入行為為并給模型型發(fā)送業(yè)務務事件，再再將業(yè)務事事件解析為為模型應執(zhí)執(zhí)行的動作作；同時，，模型的更更新與修改改也將通過過控制器來來通知視圖圖，從而保保持各個視視圖與模型型的一致性性。9.5體系結構框框架9.5體系結構框框架MVC的處理過程程為：首先控制制器接收用用戶的請求求，并決定定應該調(diào)用用哪個模型型來進行處處理；然后后模型用業(yè)業(yè)務邏輯來來處理用戶戶的請求并并返回數(shù)據(jù)據(jù)；最后控控制器用相相應的視圖圖格式化模模型返回的的數(shù)據(jù)，并并通過表示示層呈現(xiàn)給給用戶。其中，模型型是核心數(shù)數(shù)據(jù)和功能能，視圖只只關心顯示示數(shù)據(jù)，控控制只關心心用戶輸入入，這種結結構由于將將數(shù)據(jù)和業(yè)業(yè)務規(guī)則從從表示層分分開，因此此可以最大大化地重用用代碼。J2EE的核心體系系結構就是是在MVC框架的基礎礎上進行擴擴展得到的，如如下圖所示示。9.5體系結構框框架J2EE體系結構框框架J2EE的核心體系系結構框架架客戶層：用戶通過過客戶層與與系統(tǒng)交互互。該層可可以是各種種類型的客客戶端。例例如，可編編程客戶端端（如基于于JavaSwing的客戶端或或applet），純Web瀏覽器客戶戶端，WML移動客戶端端等。資源層：資源層可可以是企業(yè)業(yè)數(shù)據(jù)庫，，電子商務務解決方案案中的外部部企業(yè)系統(tǒng)統(tǒng)，或者是是外部SOA服務。數(shù)據(jù)據(jù)可以分布布在多個服服務器上。。從上圖可看看出，J2EE模型是分層結構，中間的3層（表示層層，業(yè)務層層，集成層層）包含應應用程序構構件，客戶戶層和資源源層處于應應用程序的的外圍。9.5體系結構框框架表示層：也稱為Web層或服務器器端表示層層，用戶通通過表示層層來訪問應應用程序。。在基于Web的應用系統(tǒng)統(tǒng)中，表示示層由用戶戶界面代碼碼和運行于于Web服務器或應應用服務器器上的過程程組成。參參考MVC框架，表示示層包括視視圖構件和和控制器構構件。業(yè)務層：業(yè)務層包含含表示層中中的控制器器構件沒有有實現(xiàn)的一一部分應用用邏輯。它它負責確認認和執(zhí)行企企業(yè)范圍內(nèi)內(nèi)的業(yè)務規(guī)規(guī)則和事務務，并管理理從資源層層加載到應應用程序高高速緩存中中的業(yè)務對對象。集成層：集成層負責責建立和維維護與數(shù)據(jù)據(jù)源的連接接。例如，，通過JDBC與數(shù)據(jù)庫進進行通信，，利用Java消息服務（（JMS）與外部系系統(tǒng)聯(lián)合。。9.5體系結構框框架1．PCMEF框架表示—控制—中介者—實體—基礎（presentation-control-mediator-entity-foundation，PCMEF）是一個垂垂直層次的的分層體系系結構框架架。每一層層是可以包包含其他包包的包。PCMEF框架包含4層：表示層層、控制層層、領域?qū)訉雍突A層層。領域?qū)訉影瑑蓚€個預定義包包：實體（（entity）包和中介介者（mediator）包。PCMEF框架中包的依依賴性主要是是向下依賴性性。表示層依依賴于控制層層，控制層依依賴于領域?qū)訉樱薪檎甙蕾囉趯嶓w體包和基礎層層,如下圖所示。PCMEF與PCBMER框架9.5體系結構框架架表示層:包含定義GUI對象的類。控制層:處理表示層的的請求，負責責大多數(shù)程序序邏輯、算法法、主要計算算以及為每個個用戶維持會會話狀態(tài)。領域?qū)?其實體包處理理控制請求,中介者包用于于創(chuàng)建一個協(xié)協(xié)調(diào)實體類和和基礎類的通通信通道?；A層:負責與數(shù)據(jù)庫庫和Web服務的所有通通信。9.5體系結構框架架PCMEF框架2.PCBMER框架PCBMER框架由PCMEF框架擴展而成成,代表著表示—控制器—Bean——中介者—實體—資源（presentation-control-bean-mediator-entity-resource，PCBMER）。其核心體體系結構框架架如右圖所示示。9.5體系結構框架架PCBMER的核心框架在上圖中，把把層表示為UML包（子系統(tǒng)，，層），帶箭箭頭的虛線表示依賴賴關系。例如如，表示層依依賴控制器層層和bean層，控制器層依賴bean層。PCBMER的層次不是嚴嚴格線性的，，上層可以依賴多個相相鄰下層。bean層：表示那些預預先確定要呈呈現(xiàn)在用戶界界面上的數(shù)據(jù)據(jù)類和值對象象。除了用戶戶輸入外，bean數(shù)據(jù)由實體對對象（實體層層）創(chuàng)建。表示層：表示屏幕以及及呈現(xiàn)bean對象的UI對象?？刂破鲗樱罕硎緫眠夁壿嫛嶓w層：響應控制器和和中介者。中介者層：建立了充當實實體類和資源源類媒介的通通信管道。資源層：負責所有與與外部持久數(shù)數(shù)據(jù)資源（數(shù)數(shù)據(jù)庫、Web服務等）的通通信。9.5體系結構框架架面向?qū)ο笤O計計模式最初出出現(xiàn)于70年代末80年代初。ErichGamma等4人合著的“DesignPatterns:ElementsofReusableObject-OrientedSoftware”被認為是設計計模式方面的的經(jīng)典著作。。目前，設計模模式已經(jīng)被廣廣泛應用于多多種領域的軟軟件設計和構構造中，許多多當代的先進進軟件中已大大量采用了軟軟件設計模式式的概念。9.6設計模式9.6設計模式一般來說，一一個模式有4個基本的要素素：模式名稱：用于描述模模式的名字，，說明模式的的問題、解決決方案和效果果。問題：說明在何種種場合使用模模式。解決方案：描述設計的的組成成分、、它們之間的的相互關系、、各自的職責責和合作方式式。效果：描述了模式式使用的效果果及使用模式式應當權衡的的問題。抽象工廠(1)目的：提供一一個接口用以以創(chuàng)建一個相相聯(lián)系或相依依賴的對象族族，而無須指指定它們的具具體類。(2)思路：例如，，在創(chuàng)建可支支持多種GUI標準（如Motif和PersentationManager）的繪圖用戶戶界面工具包包時，因為不不同的GUI標準會定義出出不同外觀及及行為的“用用戶界面組件件”（widget），如滾動條條、按鈕、視視窗等。為了了能夠囊括各各種GUI標準，應用程程序不能把組組件寫死，不不能限制到特特定GUI風格的組件類類，否則日后后很難換成其其他GUI風格的組件。。抽象工廠解決方法是：：先定義一個個抽象類WidgetFactory（用斜體字區(qū)區(qū)分抽象類）），這個類聲聲明了創(chuàng)建各各種基本組件件的接口，再再逐一替各種種基本組件定定義相對應的的抽象類，如如ScrollBar、Window等，讓它們的的具體子類來來真正實現(xiàn)特特定的GUI標準。抽象工廠可支持多種GUI標準的繪圖用用戶界面工具具包的結構圖圖抽象工廠(3)結構：抽象工工廠模式的結結構如圖所示示。抽象工廠(4)參與者職責a)抽象工廠類（（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類的實例只有有一個，專門門針對某種特特定的實現(xiàn)標標準，建立具具體可用的產(chǎn)產(chǎn)品對象。如果想要建立立其他標準的的產(chǎn)品對象，，客戶程序就就得改用另一一種ConcreteFactory。單件(1)目的：一個類類只有一個實實例并提供一一個訪問它的的全局訪問點點。該實例應應在系統(tǒng)生存存期中都存在在。(2)思路：例如，，通常情況下下，用戶可以以對應用系統(tǒng)統(tǒng)進行配置，，并將配置信信息保存在配配置文件中，，應用系統(tǒng)在在啟動時首先先將配置文件件加載到內(nèi)存存中，這些內(nèi)內(nèi)存配置信息息應該有且僅僅有一份。應應用單件模式式可以保證Configure類只能有一個個實例。單件(3)結構：單件模模式的結構如如圖所示。單件(4)參與者職責a)單件（Singleton）：能夠創(chuàng)建建它唯一的實實例；同時定定義了一個Instance操作，允許外外部存取它唯唯一的實例。。Instance是一個靜態(tài)成成員函數(shù)(5)協(xié)作：客戶只只能通過Singleton的Instance()存取這唯一的的實例。外觀(1)目的：給子系系統(tǒng)中的一組組接口提供一一套統(tǒng)一的高高層界面，使使得子系統(tǒng)更更容易使用。。(2)思路：將系統(tǒng)統(tǒng)劃分為若干干子系統(tǒng)，雖雖然可以降低低整體的復雜雜性，但還需需設法降低子子系統(tǒng)之間的的通信和相互互的依賴性。。一種方法就就是引進一個個外觀（facade）對象，為子子系統(tǒng)內(nèi)各種種設施提供一一個簡單的單單一界面。外觀(3)結構：外觀模模式的結構如如圖所示。外觀(4)參與者職責a)外觀（Fa?ade）：知道子系系統(tǒng)中哪個類類負責處理哪哪種信息；并并負責把外界界輸入的信息息轉交給適當當?shù)淖酉到y(tǒng)對對象。b)子系統(tǒng)中的類類（subsystemclasses）：實現(xiàn)子系系統(tǒng)的功能；；處理Facade對象分派的工工作；如果不不受Facade的控制，則也也不會有返回回Facade的引用存在。。(5)協(xié)作：使用Facade的客戶不用直直接訪問子系系統(tǒng)對象。外外界想與子系系統(tǒng)交互時，，把信息傳送送給Facade，F(xiàn)acade再把這些信息息轉交給適當當?shù)淖酉到y(tǒng)對對象。雖然實實際處理工作作是子系統(tǒng)對對象在做，但但Facade會居中做接口口轉換工作。。適配器(1)目的：適配器器模式將一個個類的接口轉轉換為客戶期期望的另一種種接口，使得得原本不匹配配的接口而無無法合作的類類可以一起工工作。(2)思路：有時要要將兩個沒有有關系的類組組合在一起使使用，一種解解決方案是修修改各自類的的接口，另一一種辦法是使使用Adapter模式，在兩種種接口之間創(chuàng)創(chuàng)建一個混合合接口。例如如，，設設有有一一個個圖圖形形編編輯輯器器，，可可畫畫直直線線、、多多邊邊形形、、文文本本等等。。它它的的接接口口定定義義成成抽抽象象類類Shape，它它的的子子類類負負責責畫畫各各種種圖圖形形。。此此外外，，還還有有一一個個外外購購的的GUI軟件件包包TextView，用用于于顯顯示示，，但但它它沒沒有有Shape功能能。。適配配器器如何何讓讓TextView的接接口口轉轉換換成成為為Shape的接接口口，，有有兩兩種種方方法法：：讓TextShape同時時繼繼承承Shape的接接口口和和TextView的服服務務（（多多重重繼繼承承））；；在TextShape中建建立立TextView的實實例例，，再再通通過過TextView給出出TextShape的接接口口。。前者者是是適適配配器器的的類類模模式式，，后后者者是是對對象象模模式式。。下下圖圖就就是是適適配配器器的的對對象象模模式式。。適配配器器(3)結構構：：適適配配器器模模式式有有類類適適配配器器模模式式和和對對象象適適配配器器模模式式。。類類適適配配器器可可以以通通過過多多繼繼承承方方式式實實現(xiàn)現(xiàn)不不同同接接口口之之間間的的相相容容和和轉轉換換，，如如圖圖所所示示。。適配配器器而一一個個對對象象適適配配器器則則依依賴賴對對象象組組合合的的技技術術實實現(xiàn)現(xiàn)接接口口的的相相容容和和轉轉換換，，如如圖圖所所示示。。適配器(4)參與者職職責a)目標（Target）：定義義客戶使使用的與與應用領領域相關關的接口口。b)客戶（Client）：與具具有Target接口的對對象合作作。c)被匹配者者（Adaptee）：需要要被轉換換匹配的的一個已已存在接接口。d)適配器（（Adapter）：將Adaptee的接口與與Target接口匹配配。適配器(5)協(xié)作：客客戶調(diào)用用Adapter對象的操操作，然然后Adapter的操作又又調(diào)用Adaptee對象中負負責處理理相應請請求的操操作。責任鏈(1)目的：通通過一條條隱式的的對象消消息鏈傳傳遞處理理請求。。該請求求沿著這這條鏈傳傳遞，直直到有一一個對象象處理它它為止。。其核心心是避免免將請求求的發(fā)送送者直接接耦合到到它的接接受者。。(2)思路：以以GUI系統(tǒng)的聯(lián)聯(lián)機幫助助系統(tǒng)為為例。用用戶可以以在軟件件中任一一位置按按下help鍵，軟件件就可以以根據(jù)該該信息和和當前上上下文環(huán)環(huán)境彈出出適當?shù)牡恼f明。。如果用戶戶在PrintDialog對話框里里“打印印”按鈕鈕上按了了幫助鍵鍵，幫助助信息的的順序圖圖如圖所所示。責任鏈聯(lián)機幫助助系統(tǒng)定定義了一一個抽象象類HelpHandler和抽象操操作HandleHelp()，所有想想處理信信息的類類可以繼繼承該類類。HelpHandler的HandleHelp()操作的內(nèi)內(nèi)定做法法是把信信息傳遞遞給后繼繼者去處處理，由由各個子子類分別別來實現(xiàn)現(xiàn)具體的的打印功功能。如如圖所示示。責任鏈(3)結構：責責任鏈模模式的結結構如圖圖所示。。責任鏈典型的對對象間的的結構如如圖所示示。責任鏈(4)參與者職職責a)處理者（（Handler）：定義義處理請請求的接接口；實實現(xiàn)對后后繼者的的鏈接（（可選））。b)具體處理理者（ConcreteHandler）：處理理它所負負責的請請求；可可訪問它它的后繼繼；如果果它能夠夠處理請請求，就就處理該該請求，，否則將將請求傳傳送給后后繼者。。c)客戶（Client）：將處處理請求求提交給給職責鏈