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

軟工概論軟件體系結構與設計模式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．模式軟件設計模式是從軟件設計過程中總結出來的，是針對特定問題的解決方案。建筑師對模式給出的經(jīng)典定義是：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題及該問題解決方案的核心。在軟件系統(tǒng)中，可以將模式劃分為以下3類。（1）體系結構模式（architecturalpattern）：表達了軟件系統(tǒng)的基本結構組織形式或者結構方案，包含了一組預定義的子系統(tǒng)，規(guī)定了這些子系統(tǒng)的責任，同時還提供了用于組織和管理這些子系統(tǒng)的規(guī)則和向?qū)А５湫偷捏w系結構模式如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ù)據(jù)經(jīng)過一系列的計算和操作構件的變換形成輸出數(shù)據(jù)時，可以應用這種體系結構。管道/過濾器、批處理序列都屬于數(shù)據(jù)流風格。管道/過濾器結構如下圖所示。9.2典型的體系結構風格數(shù)據(jù)流風格管道/過濾器結構

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

從上圖可看出，管道/過濾器結構擁有一組被稱為過濾器（filter）的構件，這些構件通過管道（pipe）連接，管道將數(shù)據(jù)從一個構件傳送到下一個構件。每個過濾器獨立于其上游和下游的構件而工作，過濾器的設計要針對某種形式的數(shù)據(jù)輸入，并且產(chǎn)生某種特定形式的數(shù)據(jù)輸出。如果數(shù)據(jù)流退化成為單線的變換，則稱為批處理序列（batchsequential）。這種結構接收一批數(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）允許對一些如吞吐量、死鎖等屬性的分析。（6）支持并行執(zhí)行。每個過濾器是作為一個單獨的任務完成，因此可與其他任務并行執(zhí)行。9.2典型的體系結構風格軟工概論軟件體系結構與設計模式管道/過濾器風格主要缺點如下：（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數(shù)據(jù)，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉(zhuǎn)換。（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。（3）因為在數(shù)據(jù)傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導致了系統(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)用它的對象。（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)按遞增的步驟進行分解。（2）支持功能增強，因為每一層至多和相鄰的上下層交互，因此，功能的改變最多影響相鄰的內(nèi)外層。9.2典型的體系結構風格軟工概論軟件體系結構與設計模式（3）支持復用。只要提供的服務接口定義不變，同一層的不同實現(xiàn)可以交換使用。這樣，就可以定義一組標準的接口，從而允許各種不同的實現(xiàn)方法。其缺點如下:（1）并不是每個系統(tǒng)都可以很容易地劃分為分層的模式，甚至即使一個系統(tǒng)的邏輯結構是層次化的，出于對系統(tǒng)性能的考慮，系統(tǒng)設計師不得不把一些低級或高級的功能綜合起來。（2）很難找到一個合適的、正確的層次抽象方法。9.2典型的體系結構風格軟工概論軟件體系結構與設計模式數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)和黑板系統(tǒng)都屬于倉庫風格。在這種風格中，數(shù)據(jù)倉庫（如文件或數(shù)據(jù)庫）位于這種體系結構的中心，其他構件會經(jīng)常訪問該數(shù)據(jù)倉庫，并對倉庫中的數(shù)據(jù)進行增加、修改或刪除操作。右圖為一個典型的倉庫風格的體系結構。9.2典型的體系結構風格倉庫風格軟工概論軟件體系結構與設計模式

上圖中,可把中心存儲庫變換成“黑板”，黑板構件負責協(xié)調(diào)信息在客戶間的傳遞，當用戶感興趣的數(shù)據(jù)發(fā)生變化時，它將通知客戶軟件。黑板系統(tǒng)的組成如下圖所示。黑板系統(tǒng)的傳統(tǒng)應用是信號處理領域，如語音和模式識別。另一應用是松耦合代理數(shù)據(jù)共享存取。9.2典型的體系結構風格軟工概論軟件體系結構與設計模式特定的應用還需要特定的體系結構模型。這些體系結構模型稱為領域相關的體系結構。有兩種領域相關的體系結構模型：類屬模型（genericmodel）和參考模型（referencemodel）。9.3特定領域的軟件體系結構軟工概論軟件體系結構與設計模式9.3特定領域的軟件體系結構類屬模型類屬模型是從許多實際系統(tǒng)中抽象出來的一般模型，它封裝了這些系統(tǒng)的主要特征。例如，許多圖書館開發(fā)了自己的圖書館館藏/流通系統(tǒng)，若把它們的共同功能抽取出來并創(chuàng)建一個讓所有圖書館都認可的系統(tǒng)體系結構模型，這就是類屬模型。軟工概論軟件體系結構與設計模式9.3特定領域的軟件體系結構類屬模型的一個最著名的例子是編譯器模型，由這個模型已開發(fā)出了數(shù)以千計的編譯器。軟工概論軟件體系結構與設計模式參考模型源于對應用領域的研究，它描述了一個理想化的包含了系統(tǒng)應具有的所有特征的軟件體系結構。它是更抽象且是描述一大類系統(tǒng)的模型，并且也是對設計者有關某類系統(tǒng)的一般結構的指導。

9.3特定領域的軟件體系結構參考模型軟工概論軟件體系結構與設計模式9.3特定領域的軟件體系結構參考模型的典型例子是開放式系統(tǒng)互聯(lián)（OSI）參考模型。軟工概論軟件體系結構與設計模式9.3特定領域的軟件體系結構

以上兩種不同類型的模型之間并不存在嚴格的區(qū)別，也可以將類屬模型視為參考模型。區(qū)別之一是類屬模型可以直接在設計中復用，而參考模型一般是用于領域概念間的交流和對可能的體系結構做出比較。另外，類屬模型通常是經(jīng)過“自下而上”地對已有系統(tǒng)的抽象，而參考模型是“由上到下”地產(chǎn)生的。軟工概論軟件體系結構與設計模式9.4分布式系統(tǒng)結構在集中式計算技術時代廣泛使用的是大型機/小型機計算模型。20世紀80年代以后，集中式結構逐漸被以PC為主的微機網(wǎng)絡所取代。個人計算機和工作站的采用，永遠改變了大型機/小型機計算模型，從而產(chǎn)生了分布式計算模型。軟工概論軟件體系結構與設計模式9.4分布式系統(tǒng)結構分布式計算模型主要具有以下優(yōu)點：(1)資源共享。分布式系統(tǒng)允許硬件、軟件等資源共享使用。(2)經(jīng)濟性。(3)性能與可擴展性。(4)固有分布性。(5)健壯性。軟工概論軟件體系結構與設計模式

分布式系統(tǒng)的一個最簡單的模型是多處理器系統(tǒng)，系統(tǒng)由許多進程組成，這些進程可以在不同的處理器上并行運行，可以極大地提高系統(tǒng)的性能。由于大型實時系統(tǒng)對響應時間要求較高，這種模型在大型實時系統(tǒng)中比較常見。大型實時系統(tǒng)需要實時采集信息，并利用采集到的信息進行決策，然后發(fā)送信號給執(zhí)行機構。雖然，信息采集、決策制定和執(zhí)行控制這些進程可以在同一臺處理器上統(tǒng)一調(diào)度執(zhí)行，但使用多處理器能夠提高系統(tǒng)性能。9.4分布式系統(tǒng)結構多處理器體系結構軟工概論軟件體系結構與設計模式

客戶機/服務器（client/server，C/S）體系結構是基于資源不對等，且為實現(xiàn)共享而提出來的，由服務器、客戶機和網(wǎng)絡三部分組成。在C/S體系結構中，客戶機可以通過遠程調(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ù)據(jù)的管理?？蛻魴C上的軟件實現(xiàn)應用邏輯和與系統(tǒng)用戶的交互。胖客戶機模型能夠利用客戶機的處理能力，比瘦客戶機模型在分布處理上更有效。但另一方面，隨著企業(yè)規(guī)模的日益擴大，軟件的復雜程度不斷提高，胖客戶機模型逐漸暴露出了以下缺點：開發(fā)成本較高。用戶界面風格不一，使用繁雜，不利于推廣使用。軟件移植困難。軟件維護和升級困難。9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式

為了解決以上問題，三層C/S體系結構應運而生。三層C/S體系結構中增加了應用服務器?？梢詫⒄麄€應用邏輯駐留在應用服務器上，而只有表示層存在于客戶機上。9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式

三層C/S體系結構將整個系統(tǒng)分成表示層、應用邏輯層和數(shù)據(jù)層三個部分，其數(shù)據(jù)處理流程如下圖所示。9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式9.4分布式系統(tǒng)結構（1）表示層：表示層是應用系統(tǒng)的用戶界面部分，擔負著用戶與應用程序之間的對話功能。它用于檢查用戶從鍵盤等輸入的數(shù)據(jù)，顯示應用程序輸出的數(shù)據(jù)，一般采用圖形用戶界面（graphicuserinterface，GUI）。（2）應用邏輯層：應用邏輯層為應用系統(tǒng)的主體部分，包含具體的業(yè)務處理邏輯。通常在功能層中包含有確認用戶對應用和數(shù)據(jù)庫存取權限的功能以及記錄系統(tǒng)處理日志的功能。（3）數(shù)據(jù)層：數(shù)據(jù)層主要包括數(shù)據(jù)的存儲及對數(shù)據(jù)的存取操作，一般選擇關系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）。軟工概論軟件體系結構與設計模式

瀏覽器/服務器（browser/server，B/S）風格是三層體系結構的一種實現(xiàn)方式，其具體結構為瀏覽器/Web服務器/數(shù)據(jù)庫服務器。B/S體系結構如下圖所示。9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式B/S體系結構主要是利用不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器就實現(xiàn)了原來需要復雜的專用軟件才能實現(xiàn)的強大功能，并節(jié)約了開發(fā)成本。從某種程度上來說，B/S結構是一種全新的軟件體系結構。B/S體系結構具有以下優(yōu)點：（1）基于B/S體系結構的軟件，系統(tǒng)安裝、修改和維護全在服務器端解決。（2）B/S體系結構還提供了異種機、異種網(wǎng)、異種應用服務的聯(lián)機、聯(lián)網(wǎng)和統(tǒng)一服務的最現(xiàn)實的開放性基礎。

9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式與C/S體系結構相比，B/S體系結構也有許多不足之處。（1）B/S體系結構缺乏對動態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能。（2）采用B/S體系結構的應用系統(tǒng)，在數(shù)據(jù)查詢等響應速度上，要遠遠地低于C/S體系結構。（3）B/S體系結構的數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務處理（OLTP）應用。9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式

在客戶機/服務器模型中，客戶機和服務器的地位是不同的。為了消除客戶機與服務器之間的差別，提高系統(tǒng)的伸縮性以及有效地均衡負載，可采用分布式對象體系結構來設計系統(tǒng)。分布式對象的實質(zhì)是在分布式異構環(huán)境下建立應用系統(tǒng)框架和對象構件，它將應用服務分割成具有完整邏輯含義的獨立子模塊（稱為構件），各個子模塊可放在同一臺服務器或分布在多臺服務器上運行，模塊之間通過中間件互相通信。9.4分布式系統(tǒng)結構分布式對象體系結構軟工概論軟件體系結構與設計模式

通常將這個中間件稱為軟件總線或?qū)ο笳埱蟠?，它的作用是在對象之間提供一個無縫接口。9.4分布式系統(tǒng)結構

分布式對象技術的應用目的是為了降低主服務器的負荷、共享網(wǎng)絡資源、平衡網(wǎng)絡中計算機業(yè)務處理的分配，提高計算機系統(tǒng)協(xié)同處理的能力，從而使應用的實現(xiàn)更為靈活。軟工概論軟件體系結構與設計模式分布式對象技術的基礎是構件。構件是一些獨立的代碼封裝體，在分布計算的環(huán)境下可以是一個簡單的對象，但大多數(shù)情況下是一組相關的對象組合體，提供一定的服務。分布式環(huán)境下，構件是一些靈活的軟件模塊，它們可以位置透明、語言獨立和平臺獨立地互相發(fā)送消息，實現(xiàn)請求服務。構件之間并不存在客戶機與服務器的界限，接受服務者扮演客戶機的角色，提供服務者就是服務器。9.4分布式系統(tǒng)結構軟工概論軟件體系結構與設計模式9.4分布式系統(tǒng)結構當前主流的分布式對象技術規(guī)范有OMG的CORBA、Microsoft公司的.NET和Sun公司的J2EE。它們都支持服務端構件的開發(fā)，都有其各自的特點。軟工概論軟件體系結構與設計模式

代理可以用于構建帶有隔離組件的分布式軟件系統(tǒng)，該軟件通過遠程服務調(diào)用進行交互。代理者負責協(xié)調(diào)通信，諸如轉(zhuǎn)發(fā)請求以及傳遞結果和異常等。

1991年，OMG基于面向?qū)ο蠹夹g，給出了以對象請求代理（ORB）為中心的分布式應用體系結構。9.4分布式系統(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)結構軟工概論軟件體系結構與設計模式MVC框架即模型—視圖—控制器（model-view-controller）框架，它強調(diào)將用戶輸入、數(shù)據(jù)模型和數(shù)據(jù)表示的方式分開設計，一個交互式應用系統(tǒng)由模型、視圖和控制器3個部件組成，分別對應于內(nèi)部數(shù)據(jù)、數(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í)行的動作；同時，模型的更新與修改也將通過控制器來通知視圖，從而保持各個視圖與模型的一致性。

9.5體系結構框架軟工概論軟件體系結構與設計模式9.5體系結構框架MVC的處理過程為：首先控制器接收用戶的請求，并決定應該調(diào)用哪個模型來進行處理；然后模型用業(yè)務邏輯來處理用戶的請求并返回數(shù)據(jù)；最后控制器用相應的視圖格式化模型返回的數(shù)據(jù)，并通過表示層呈現(xiàn)給用戶。其中，模型是核心數(shù)據(jù)和功能，視圖只關心顯示數(shù)據(jù)，控制只關心用戶輸入，這種結構由于將數(shù)據(jù)和業(yè)務規(guī)則從表示層分開，因此可以最大化地重用代碼。

軟工概論軟件體系結構與設計模式J2EE的核心體系結構就是在MVC框架的基礎上進行擴展得到的，如下圖所示。9.5體系結構框架J2EE體系結構框架J2EE的核心體系結構框架

軟工概論軟件體系結構與設計模式客戶層：用戶通過客戶層與系統(tǒng)交互。該層可以是各種類型的客戶端。例如，可編程客戶端（如基于JavaSwing的客戶端或applet），純Web瀏覽器客戶端，WML移動客戶端等。資源層：資源層可以是企業(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ī)則和事務，并管理從資源層加載到應用程序高速緩存中的業(yè)務對象。集成層：集成層負責建立和維護與數(shù)據(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é)調(diào)實體類和基礎類的通信通道。基礎層:負責與數(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ù)類和值對象。除了用戶輸入外，bean數(shù)據(jù)由實體對象（實體層）創(chuàng)建。表示層：表示屏幕以及呈現(xiàn)bean對象的UI對象?？刂破鲗樱罕硎緫眠壿?。實體層：響應控制器和中介者。中介者層：建立了充當實體類和資源類媒介的通信管道。資源層：負責所有與外部持久數(shù)據(jù)資源（數(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ū)分抽象類），這個類聲明了創(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)品對象，客戶程序就得改用另一種ConcreteFactory。軟工概論軟件體系結構與設計模式單件(1)目的：一個類只有一個實例并提供一個訪問它的全局訪問點。該實例應在系統(tǒng)生存期中都存在。(2)思路：例如，通常情況下，用戶可以對應用系統(tǒng)進行配置，并將配置信息保存在配置文件中，應用系統(tǒng)在啟動時首先將配置文件加載到內(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)之間的通信和相互的依賴性。一種方法就是引進一個外觀（facade）對象，為子系統(tǒng)內(nèi)各種設施提供一個簡單的單一界面。軟工概論軟件體系結構與設計模式外觀(3)結構：外觀模式的結構如圖所示。軟工概論軟件體系結構與設計模式外觀(4)參與者職責

a)外觀（Fa?ade）：知道子系統(tǒng)中哪個類負責處理哪種信息；并負責把外界輸入的信息轉(zhuǎn)交給適當?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再把這些信息轉(zhuǎn)交給適當?shù)淖酉到y(tǒng)對象。雖然實際處理工作是子系統(tǒng)對象在做，但Facade會居中做接口轉(zhuǎn)換工作。軟工概論軟件體系結構與設計模式適配器(1)目的：適配器模式將一個類的接口轉(zhuǎn)換為客戶期望的另一種接口，使得原本不匹配的接口而無法合作的類可以一起工作。(2)思路：有時要將兩個沒有關系的類組合在一起使用，一種解決方案是修改各自類的接口，另一種辦法是使用Adapter模式，在兩種接口之間創(chuàng)建一個混合接口。例如，設有一個圖形編輯器，可畫直線、多邊形、文本等。它的接口定義成抽象類Shape，它的子類負責畫各種圖形。此外，還有一個外購的GUI軟件包TextView，用于顯示，但它沒有Shape功能。軟工概論軟件體系結構與設計模式適配器

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

軟工概論軟件體系結構與設計模式適配器(4)參與者職責

a)目標（Target）：定義客戶使用的與應用領域相關的接口。

b)客戶（Client）：與具有Target接口的對象合作。

c)被匹配者（Adaptee）：需要被轉(zhuǎn)換匹配的一個已存在接口。

d)適配器（Adapter）：將Adaptee的接口與Target接口匹配。軟工概論軟件體系結構與設計模式適配器(5)協(xié)作：客戶調(diào)用Adapter對象的操作，然后Adapter的操作又調(diào)用Adaptee對象中負責處理相應請求的操作。軟工概論軟件體系結構與設計模式責任鏈(1)目的：通過一條隱式的對象消息鏈傳遞處理請求。該請求沿著這條鏈傳遞，直到有一個對象處理它為止。其核心是避免將請求的發(fā)送者直接耦合到它的接受者。(2)思路：以GUI系統(tǒng)的聯(lián)機幫助系統(tǒng)為例。用戶可以在軟件中任一位置按下help鍵，軟件就可以根據(jù)該信息和當前上下文環(huán)境彈出適當?shù)恼f明。如果用戶在PrintDialog對話框里“打印”按鈕上按了幫助鍵，幫助信息的順序圖如圖所示。軟工概論軟件體系結構與設計模式責任鏈聯(lián)機幫助系統(tǒng)定義了一個抽象類HelpHandler和抽象操作HandleHelp()，所有想處理信息的類可以繼承該類。HelpHandler的HandleHelp()操作的內(nèi)定做法是把信息傳遞給后繼者去處理，由各個子類分別來實現(xiàn)具體的打印功能。如圖所示。軟工概論軟件體系結構與設計模式責任鏈(3)結構：責任鏈模式的結構如圖所示。軟工概論軟件體系結構與設計模式責任鏈典型的對象間的結構如圖所示。軟工概論軟件體系結構與設計模式責任鏈(4)參與者職責

a)處理者（Handler）：定義處理請求的接口；實現(xiàn)對后繼者的鏈接