軟件與軟件工程-軟件體系結(jié)構(gòu)與設(shè)計模式

軟件體系結(jié)構(gòu)與設(shè)計模式本章概述本章首先介紹軟件體系結(jié)構(gòu)的概念，包括什么是軟件體系結(jié)構(gòu)、軟件體系結(jié)構(gòu)建模、軟件體系結(jié)構(gòu)的分層模型和軟件體系結(jié)構(gòu)的作用。然后講述典型的軟件體系結(jié)構(gòu)風(fēng)格，包括數(shù)據(jù)流風(fēng)格、調(diào)用/返回風(fēng)格、獨立構(gòu)建風(fēng)格、虛擬機風(fēng)格和倉庫風(fēng)格。接著講述軟件質(zhì)量屬性，再介紹分布式系統(tǒng)結(jié)構(gòu)。此外還講述體系結(jié)構(gòu)框架，包括模型-視圖-控制器、模型-視圖-表示器、J2EE框架，PCMEF框架，PCBMER框架。最后針對軟件系統(tǒng)的設(shè)計模式作簡要闡述本章目標：了解軟件體系結(jié)構(gòu)的定義和建模方法熟悉典型的軟件體系結(jié)構(gòu)風(fēng)格了解軟件的質(zhì)量屬性了解體系結(jié)構(gòu)框架了解軟件系統(tǒng)的設(shè)計模式軟件體系結(jié)構(gòu)的概念第一節(jié)典型的軟件體系結(jié)構(gòu)風(fēng)格第二節(jié)軟件質(zhì)量屬性第三節(jié)目錄content分布式系統(tǒng)結(jié)構(gòu)第四節(jié)體系結(jié)構(gòu)框架第五節(jié)軟件系統(tǒng)的設(shè)計模式第六節(jié)軟件體系結(jié)構(gòu)的概念第一節(jié)軟件體系結(jié)構(gòu)建模軟件體系結(jié)構(gòu)的分層模型什么是軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的作用什么是軟件體系結(jié)構(gòu)?軟件體系結(jié)構(gòu)是系統(tǒng)的一個或多個結(jié)構(gòu)，它包括：1)軟件的組成元素（組件）；2)這些（組件）元素的外部可見特性；3)這些元素（組件）之間的相互關(guān)系。軟件體系結(jié)構(gòu)不僅指定了系統(tǒng)的組織結(jié)構(gòu)和拓撲結(jié)構(gòu)，也顯示了系統(tǒng)需求和構(gòu)成系統(tǒng)的元素之間的對應(yīng)關(guān)系，提供了一些設(shè)計決策的基本原理。什么是軟件體系結(jié)構(gòu)?軟件體系結(jié)構(gòu)描述的對象是直接構(gòu)成系統(tǒng)的抽象組件。它由功能各異、相互作用的部件按照層次構(gòu)成，包含了系統(tǒng)的基礎(chǔ)構(gòu)成單元、單元之間的相互作用關(guān)系、在構(gòu)成系統(tǒng)時它們的合成方法以及對合成約束的描述。具體來說，部件包括客戶端、服務(wù)器、數(shù)據(jù)庫、程序包、過程、子程序等一切軟件的組成部分。相互作用的關(guān)系可以是過程調(diào)用、消息傳遞、共享內(nèi)存變量、客戶端/服務(wù)器的訪問協(xié)議、數(shù)據(jù)庫的訪問協(xié)議等。軟件體系結(jié)構(gòu)的概念第一節(jié)軟件體系結(jié)構(gòu)建模軟件體系結(jié)構(gòu)的分層模型什么是軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的作用

針對某一具體的軟件系統(tǒng)研發(fā)項目，需要以某種可視化/形式化的形式將軟件體系結(jié)構(gòu)的設(shè)計結(jié)果顯式地表達出來，進而支持：用戶、軟件架構(gòu)師、開發(fā)者等各方人員之間的交流。分析驗證軟件體系結(jié)構(gòu)設(shè)計的優(yōu)劣。指導(dǎo)軟件開發(fā)組進行系統(tǒng)開發(fā)。為日后的軟件維護提供基本文檔。軟件體系結(jié)構(gòu)建模

根據(jù)建模的側(cè)重點的不同，可以將軟件體系結(jié)構(gòu)的模型分為結(jié)構(gòu)模型、框架模型、動態(tài)模型、過程模型和功能模型5種。1）結(jié)構(gòu)模型

這是一個最直觀、最普遍的建模方法。這種方法以體系結(jié)構(gòu)的構(gòu)件、連接件和其他概念來刻畫結(jié)構(gòu)，并力圖通過結(jié)構(gòu)來反映系統(tǒng)的重要語義內(nèi)容，包括系統(tǒng)的配置、約束、隱含的假設(shè)條件、風(fēng)格、性質(zhì)。研究結(jié)構(gòu)模型的核心是體系結(jié)構(gòu)描述語言。2）框架模型

框架模型與結(jié)構(gòu)模型類似，但它不太側(cè)重描述結(jié)構(gòu)的細節(jié)而更側(cè)重于整體的結(jié)構(gòu)?？蚣苣Ｐ椭饕砸恍┨厥獾膯栴}為目標建立只針對和適應(yīng)該問題的結(jié)構(gòu)。軟件體系結(jié)構(gòu)建模

3）動態(tài)模型

動態(tài)模型是對結(jié)構(gòu)模型或框架模型的補充，研究系統(tǒng)的"大顆粒"的行為性質(zhì)。例如，描述系統(tǒng)的重新配置或演化。動態(tài)可能指系統(tǒng)總體結(jié)構(gòu)的配置、建立或拆除通信通道或計算的過程。這類系統(tǒng)常是激勵型的。4）過程模型

過程模型研究構(gòu)造系統(tǒng)的步驟和過程，因此結(jié)構(gòu)是遵循某些過程腳本的結(jié)果。5）功能模型

該模型認為體系結(jié)構(gòu)是由一組功能構(gòu)件按層次組成，下層向上層提供服務(wù)。它可以看作是一種特殊的框架模型。軟件體系結(jié)構(gòu)建模

軟件體系結(jié)構(gòu)建?？煞譃?個層次。1）軟件體系結(jié)構(gòu)核心元模型：軟件體系結(jié)構(gòu)模型由哪些元素組成，這些組成元素之間按照何種原則組織；2）軟件體系結(jié)構(gòu)模型的多視圖表示：從不同的視角描述特定系統(tǒng)的體系結(jié)構(gòu)，從而得到多個視圖，并將這些視圖組織起來以描述整體的軟件體系結(jié)構(gòu)模型；3）軟件體系結(jié)構(gòu)描述語言：在軟件體系結(jié)構(gòu)基本概念的基礎(chǔ)上，選取適當?shù)男问交虬胄问交姆椒▉砻枋鲆粋€特定的體系結(jié)構(gòu)；4）軟件體系結(jié)構(gòu)文檔化：記錄和整理上述3個層次的描述內(nèi)容。軟件體系結(jié)構(gòu)建模軟件體系結(jié)構(gòu)的概念第一節(jié)軟件體系結(jié)構(gòu)建模軟件體系結(jié)構(gòu)的分層模型什么是軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的作用軟件體系結(jié)構(gòu)的分層模型

計算機硬件層是軟件實現(xiàn)的物質(zhì)基礎(chǔ)，比如存儲器、時鐘、高速緩存等。軟件硬件層實現(xiàn)了軟件與硬件的分離，既是對軟件實現(xiàn)的最底層的描述，也是對硬件實現(xiàn)的操作和控制的描述。基礎(chǔ)控制描述層、資源和管理調(diào)度層是體系結(jié)構(gòu)構(gòu)件和連接的內(nèi)在構(gòu)成模型。系統(tǒng)結(jié)構(gòu)模式層是軟件的上層體系結(jié)構(gòu)，它是最高層次的軟件結(jié)構(gòu)概念，其涉及的概念通常有客戶端/服務(wù)器、解釋器、編譯器、框架等。應(yīng)用層是建立在軟件概念之上的領(lǐng)域問題描述，它是基于純粹的應(yīng)用領(lǐng)域的。軟件體系結(jié)構(gòu)的概念第一節(jié)軟件體系結(jié)構(gòu)建模軟件體系結(jié)構(gòu)的分層模型什么是軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的作用軟件體系結(jié)構(gòu)的作用

設(shè)計軟件的體系結(jié)構(gòu)在設(shè)計階段非常重要。軟件體系結(jié)構(gòu)就好比軟件系統(tǒng)的骨骼，如果骨骼確定了，那么軟件系統(tǒng)的框架就確定了。設(shè)計軟件體系的過程中應(yīng)當包含以下幾項：1）定義基本構(gòu)件、構(gòu)建打包方式以及相互作用的方式。2）明確系統(tǒng)如何實現(xiàn)功能、性能、可靠性、安全性等各個方面需求。3）盡量使用已有的構(gòu)件軟件體系結(jié)構(gòu)的作用

軟件體系結(jié)構(gòu)在軟件開發(fā)過程中的作用如下。1）規(guī)范軟件開發(fā)的基本架構(gòu)體系結(jié)構(gòu)一般與需求密切相關(guān)，明確的需求可以產(chǎn)生明確的規(guī)格，使設(shè)計出來的軟件結(jié)構(gòu)更清晰。需求的變更也需要考慮，明確的變更趨勢可以提早在設(shè)計中體現(xiàn)。2）便于開發(fā)人員與用戶的溝通開發(fā)人員與系統(tǒng)設(shè)計人員、用戶以及其他有關(guān)人員之間進行有效溝通，可以達成某些一致。應(yīng)用軟件體系結(jié)構(gòu)的思想方法可以更好劃分范圍，規(guī)劃時間成本，應(yīng)對客戶不夠明確的需求。

軟件體系結(jié)構(gòu)的作用

3）模塊化、層次化設(shè)計有利于減少返工提高效率模塊越獨立越好，盡量把有明確需求的應(yīng)用劃分為獨立模塊，減少模塊之間的交集。層次化設(shè)計就是一層一層分割，利用分層處理復(fù)雜功能，下層執(zhí)行簡單功能，上層調(diào)用功能，可以有效杜絕層次之間的交集。4）便于系統(tǒng)開發(fā)前后期的籌備與服務(wù)利用體系結(jié)構(gòu)的思想開發(fā)產(chǎn)品不僅可以規(guī)范流程，節(jié)省時間，還能留下大量開發(fā)文檔、產(chǎn)品類型框架、軟件開發(fā)標準流程等資料，為今后的售前咨詢和售后服務(wù)提供參考。

兩種常用的軟件體系結(jié)構(gòu)如圖所示。樹形結(jié)構(gòu)網(wǎng)狀結(jié)構(gòu)軟件體系結(jié)構(gòu)的作用典型的軟件體系結(jié)構(gòu)風(fēng)格第二節(jié)調(diào)用∕返回風(fēng)格獨立構(gòu)件風(fēng)格數(shù)據(jù)流風(fēng)格虛擬機風(fēng)格倉庫風(fēng)格

典型的軟件體系結(jié)構(gòu)風(fēng)格

所謂軟件體系結(jié)構(gòu)風(fēng)格，是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式。軟件體系結(jié)構(gòu)風(fēng)格包含4個關(guān)鍵要素：1)提供一個詞匯表；2)定義一套配置規(guī)則；3)定義一套語義解釋規(guī)則；4)定義對基于這種風(fēng)格的系統(tǒng)進行的分析。

根據(jù)以上4要素框架，Garlan和Shaw對通用軟件體系結(jié)構(gòu)風(fēng)格的進行分類，每種體系結(jié)構(gòu)風(fēng)格有各自的應(yīng)用領(lǐng)域和優(yōu)缺點。數(shù)據(jù)流風(fēng)格

數(shù)據(jù)到達即被激活處理工作，無數(shù)據(jù)時不工作。一般來說，數(shù)據(jù)的流向是有序的。在純數(shù)據(jù)流系統(tǒng)中，處理之間除了數(shù)據(jù)交換，沒有任何其他的交互。主要研究近似線性的數(shù)據(jù)流，或在限度內(nèi)的循環(huán)數(shù)據(jù)流。其中包括批處理序列、管道/過濾器。典型的軟件體系結(jié)構(gòu)風(fēng)格第二節(jié)調(diào)用∕返回風(fēng)格獨立構(gòu)件風(fēng)格數(shù)據(jù)流風(fēng)格虛擬機風(fēng)格倉庫風(fēng)格調(diào)用

∕

返回風(fēng)格

各個構(gòu)件通過調(diào)用其他構(gòu)件和獲得返回參數(shù)來進行交互，配合完成功能。包括主程序/子程序、面向?qū)ο箫L(fēng)格、層次結(jié)構(gòu)。主程序子程序子程序子程序典型的軟件體系結(jié)構(gòu)風(fēng)格第二節(jié)調(diào)用∕返回風(fēng)格獨立構(gòu)件風(fēng)格數(shù)據(jù)流風(fēng)格虛擬機風(fēng)格倉庫風(fēng)格獨立構(gòu)件風(fēng)格

這種風(fēng)格的主要特點是：事件的觸發(fā)者并不知道哪些構(gòu)件會被這些事件影響，相互保持獨立，這樣不能假定構(gòu)件的處理順序，甚至不知道哪些過程會被調(diào)用；各個構(gòu)件之間彼此無連接關(guān)系，各自獨立存在，通過對事件的發(fā)布和注冊實現(xiàn)關(guān)聯(lián)，其中包括進程通訊、事件系統(tǒng)。典型的軟件體系結(jié)構(gòu)風(fēng)格第二節(jié)調(diào)用∕返回風(fēng)格獨立構(gòu)件風(fēng)格數(shù)據(jù)流風(fēng)格虛擬機風(fēng)格倉庫風(fēng)格虛擬機風(fēng)格

它創(chuàng)建了一種虛擬的環(huán)境，將用戶與底層平臺隔離開來，或者將高層抽象和底層實現(xiàn)隔離開來。其中包括解釋器、基于規(guī)則的系統(tǒng)。典型的軟件體系結(jié)構(gòu)風(fēng)格第二節(jié)調(diào)用∕返回風(fēng)格獨立構(gòu)件風(fēng)格數(shù)據(jù)流風(fēng)格虛擬機風(fēng)格倉庫風(fēng)格倉庫風(fēng)格

倉庫是存儲和維護數(shù)據(jù)的中心場所。在倉庫風(fēng)格中存在兩類構(gòu)件，表示當前數(shù)據(jù)的狀態(tài)的中心數(shù)據(jù)結(jié)構(gòu)和一組對中心數(shù)據(jù)進行操作的獨立構(gòu)件。其中包括數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)、黑板系統(tǒng)。軟件質(zhì)量屬性第三節(jié)

軟件質(zhì)量屬性

軟件質(zhì)量屬性是指軟件系統(tǒng)在其生存周期過程中所表現(xiàn)出的各種特征。質(zhì)量屬性既和軟件體系結(jié)構(gòu)有關(guān)，也和具體實現(xiàn)有關(guān)。但軟件設(shè)計是保證軟件質(zhì)量的重要階段，而軟件體系結(jié)構(gòu)是獲取許多質(zhì)量屬性的基礎(chǔ)，因此在軟件體系結(jié)構(gòu)設(shè)計時就應(yīng)考慮到這些質(zhì)量屬性，并在軟件體系結(jié)構(gòu)層次上進行評估。質(zhì)量屬性可以分為3類：系統(tǒng)屬性、商業(yè)屬性和構(gòu)架屬性。

系統(tǒng)屬性按運行時是否可見又分為：

運行時可觀察到的：包括性能、安全性、可用性、易用性；

運行時不可觀察的：包括可修改性、可移植性、可測試性、可集成性、可重用性。

商業(yè)屬性包括投放市場時間、成本和預(yù)計的系統(tǒng)生命周期長短。

構(gòu)架屬性包括軟件體系結(jié)構(gòu)本身的概念完整性、正確性和可構(gòu)建性。

在軟件體系結(jié)構(gòu)設(shè)計時除了考慮到系統(tǒng)要實現(xiàn)的功能外，還應(yīng)充分考慮到系統(tǒng)所要求的各類質(zhì)量屬性。

軟件質(zhì)量屬性分布式系統(tǒng)結(jié)構(gòu)第四節(jié)分布式系統(tǒng)結(jié)構(gòu)

1990年代以前，計算機主要采用集中式結(jié)構(gòu)，通過一臺物理宿主機，連接多個非智能終端來完成應(yīng)用程序。由于數(shù)據(jù)的爆炸性增長，對宿主機的要求越來越高，導(dǎo)致部署成本嚴重升高，難以普及。目前，硬件技術(shù)的發(fā)展有兩個主要趨勢：（1）多處理器的計算機系統(tǒng)正在更廣泛地進入小型辦公場所，例如基于x96/x64結(jié)構(gòu)的WindowsNT、UNIX/Linux、macOS等，甚至是如今正在興起的移動設(shè)備（如高端智能手機）都已經(jīng)有多核產(chǎn)品在市場上流行。（2）這些設(shè)備通過網(wǎng)絡(luò)互聯(lián)在一起，形成無數(shù)的物理局域網(wǎng)或虛擬局域網(wǎng)（如VPN）。分布式系統(tǒng)結(jié)構(gòu)

隨著網(wǎng)絡(luò)技術(shù)的成熟，個人計算機和工作站的分布式組網(wǎng)結(jié)構(gòu)，產(chǎn)生了分布式計算模型。它具有如下優(yōu)點：①資源共享。②經(jīng)濟型。③性能和可擴展性。④固有分布性。⑤健壯性（某些節(jié)點問題不會影響整個系統(tǒng)）分布式系統(tǒng)結(jié)構(gòu)第四節(jié)客戶機/服務(wù)器體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)多處理器體系結(jié)構(gòu)對等端體系結(jié)構(gòu)代理多處理器體系結(jié)構(gòu)

多處理器系統(tǒng)是分布式系統(tǒng)的最簡單模型，系統(tǒng)同時運行許多進程，這些進程分布在不同的處理器上，可以極大地提高系統(tǒng)的性能。由于大型實時系統(tǒng)對響應(yīng)時間要求很高，多采用這種模型。大型實時系統(tǒng)需要實時采集信息，并利用采集到的信息進行決策，然后發(fā)送信號給執(zhí)行機構(gòu)。雖然，信息采集、決策和執(zhí)行可以在一個處理器上統(tǒng)一調(diào)度完成，但多處理器的并行計算比單處理器的分時片計算能夠極大地提高系統(tǒng)的性能，而且可靠度也相對較高。分布式系統(tǒng)結(jié)構(gòu)第四節(jié)客戶機/服務(wù)器體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)多處理器體系結(jié)構(gòu)對等端體系結(jié)構(gòu)代理客戶機/服務(wù)器體系結(jié)構(gòu)

客戶機/服務(wù)器（Client/Server，簡稱C/S）體系結(jié)構(gòu)是為了共享不對等的資源而提出來的，是20世紀90年代成熟起來的技術(shù)，C/S體系結(jié)構(gòu)定義了客戶機如何與服務(wù)器連接，以將數(shù)據(jù)和應(yīng)用系統(tǒng)分部到多個處理機上。C/S體系結(jié)構(gòu)有3個主要的組成部分。服務(wù)器。負責(zé)給其子系統(tǒng)提供服務(wù)，如數(shù)據(jù)庫服務(wù)器提供數(shù)據(jù)存儲和管理服務(wù)，文件服務(wù)器提供文件管理服務(wù)，搜索服務(wù)器提供數(shù)據(jù)檢索等?？蛻魴C。通常是獨立的子系統(tǒng)，通過向服務(wù)器請求約定的資源獲取數(shù)據(jù)。一臺服務(wù)器可以同時為許多客戶機提供服務(wù)。網(wǎng)絡(luò)。連接服務(wù)器和客戶機。有時客戶機和服務(wù)器位于同一臺物理主機上，但多數(shù)情況下它們分布在不同主機上。網(wǎng)絡(luò)可以有各種形式，包括有線和無線等。

C/S系統(tǒng)的設(shè)計必須考慮應(yīng)用系統(tǒng)的邏輯結(jié)構(gòu)。在邏輯上，我們通常將應(yīng)用系統(tǒng)劃分為3層，即數(shù)據(jù)管理層、應(yīng)用邏輯層和表示層。數(shù)據(jù)管理層主要處理數(shù)據(jù)存儲和管理操作。應(yīng)用邏輯層處理與業(yè)務(wù)相關(guān)的邏輯。表示層處理用戶界面以及用戶的交互。在集中式系統(tǒng)中，不需要將這些清楚地分離，但在分布式系統(tǒng)中，不同層常常被部署在不同的主機上，因此必須嚴格地分離不同層。C/S體系結(jié)構(gòu)通常有兩層或三層，也可根據(jù)需要劃分為更多層。兩層C/S結(jié)構(gòu)一般有兩種形態(tài)。瘦客戶機模型。在瘦客戶機模型中，數(shù)據(jù)管理和應(yīng)用邏輯都在服務(wù)器端執(zhí)行，客戶機只負責(zé)表示部分。胖客戶機模型。在這種模型中，服務(wù)器只負責(zé)對數(shù)據(jù)的管理?？蛻魴C上的軟件實現(xiàn)應(yīng)用邏輯以及與系統(tǒng)的交互。客戶機/服務(wù)器體系結(jié)構(gòu)

客戶機/服務(wù)器體系結(jié)構(gòu)C/S體系結(jié)構(gòu)

隨著軟件復(fù)雜度不斷提高，胖客戶端模型逐漸暴露出以下缺點：開發(fā)成本高。C/S體系對客戶機的配置要求較高，增加系統(tǒng)成本，且會使客戶端越來越臃腫。用戶界面風(fēng)格不一，使用繁雜，不利于推廣使用。軟件移植困難，采用不同開發(fā)工具和平臺開發(fā)的軟件之間一般不兼容，有時不得不因此開發(fā)針對另一平臺的版本。軟件維護和升級困難，由于應(yīng)用程序安裝在客戶機上，需要維護時必須升級和維護所有客戶端兩層C/S結(jié)構(gòu)需要考慮如何將三個邏輯層映射到兩個系統(tǒng)，在瘦客戶機模型存在伸縮性和性能問題，在胖客戶機模型則存在系統(tǒng)管理問題?？蛻魴C/服務(wù)器體系結(jié)構(gòu)

三層C/S結(jié)構(gòu)就避免了這個問題，將數(shù)據(jù)管理層和應(yīng)用邏輯層分別放在兩個物理層或物理主機上，客戶端仍然保留在客戶機上。對于三層C/S結(jié)構(gòu)，各層的功能或指責(zé)如下：表示層。表示層是應(yīng)用系統(tǒng)的用戶界面部分，擔(dān)負著用戶與應(yīng)用程序之間的對話功能。通常采用圖形界面的方式呈現(xiàn)。應(yīng)用邏輯層。應(yīng)用邏輯層為應(yīng)用系統(tǒng)的主體，包含全部的業(yè)務(wù)邏輯。比如數(shù)據(jù)處理，用戶管理，與其他系統(tǒng)交互，以及記錄系統(tǒng)日志等。通常是應(yīng)用服務(wù)器。數(shù)據(jù)層。數(shù)據(jù)層一般只負責(zé)數(shù)據(jù)的存取、管理和維護（如備份等），通常是關(guān)系型數(shù)據(jù)庫服務(wù)器。瀏覽器/服務(wù)器（Browser/Server，簡稱B/S）結(jié)構(gòu)是三層應(yīng)用結(jié)構(gòu)的一種實現(xiàn)，其具體結(jié)構(gòu)為瀏覽器/Web服務(wù)器/數(shù)據(jù)庫服務(wù)器?？蛻魴C/服務(wù)器體系結(jié)構(gòu)

三層結(jié)構(gòu)的優(yōu)點：通過合理劃分三層結(jié)構(gòu)，使之在邏輯上保持相對獨立，提高系統(tǒng)的可維護性和可擴展性。能夠更靈活選用相應(yīng)的平臺和應(yīng)用系統(tǒng)，使之在處理負荷能力和處理特性上分別適應(yīng)各層的要求，并具有良好的可升級性和開放性。應(yīng)用各層可以獨立并行開發(fā)，每層可以根據(jù)特點選用合適的開發(fā)語言。安全性相對較高，因為應(yīng)用層屏蔽了用戶直接訪問數(shù)據(jù)庫的權(quán)利，使得未授權(quán)用戶或黑客難以繞過應(yīng)用層獲取數(shù)據(jù)但三層結(jié)構(gòu)必須精心設(shè)計通信模塊，以避免通信稱為瓶頸限制服務(wù)器的發(fā)揮?？蛻魴C/服務(wù)器體系結(jié)構(gòu)分布式系統(tǒng)結(jié)構(gòu)第四節(jié)客戶機/服務(wù)器體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)多處理器體系結(jié)構(gòu)對等端體系結(jié)構(gòu)代理分布式對象體系結(jié)構(gòu)

分布式系統(tǒng)設(shè)計的更一般方法是去掉客戶機與服務(wù)器之間的差異，用分布式對象體系結(jié)構(gòu)來設(shè)計系統(tǒng)。分布式對象的實質(zhì)是在分布式異構(gòu)環(huán)境下建立應(yīng)用程序系統(tǒng)框架和對象構(gòu)件，將應(yīng)用服務(wù)分割成功能獨立的構(gòu)件，各個構(gòu)件可以放在同一臺或不同的多臺服務(wù)器上運行。構(gòu)件之間的通信最通常的設(shè)計方法是通過一個中間件通信，類似計算機中主板上的數(shù)據(jù)總線。中間件一般稱為軟件總線或?qū)ο笳埱蟠?，它的作用是在對象之間提供一個無縫接口。分布式對象技術(shù)的應(yīng)用目的主要是為了降低服務(wù)器負荷、共享網(wǎng)絡(luò)的資源、平衡分配計算任務(wù)到不同的主機，提高系統(tǒng)的協(xié)同處理能力。分布式系統(tǒng)結(jié)構(gòu)第四節(jié)客戶機/服務(wù)器體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)多處理器體系結(jié)構(gòu)對等端體系結(jié)構(gòu)代理對等端體系結(jié)構(gòu)

對等端體系結(jié)構(gòu)可以視為客戶端/服務(wù)器體系結(jié)構(gòu)和分布式對象體系結(jié)構(gòu)的融合。它沒有嚴格的客戶機、服務(wù)器劃分，所有的分布的對等端根據(jù)需要既能充當服務(wù)器，又能充當客戶端。但有些情況下，對等端體系結(jié)構(gòu)仍然需要設(shè)計一個端節(jié)點服務(wù)器，用于存儲端節(jié)點信息。在通信之時，對等端首先連接到端節(jié)點服務(wù)器上，下載可用的對等端節(jié)點信息。之后的通信就是根據(jù)這些端節(jié)點信息連接到其他對等端請求信息，這時，該節(jié)點常常充當客戶端，其它被請求的端充當服務(wù)器。對等端體系結(jié)構(gòu)常常用于數(shù)據(jù)共享類系統(tǒng)的設(shè)計。對等端體系結(jié)構(gòu)

對等端體系結(jié)構(gòu)常常用于數(shù)據(jù)共享類系統(tǒng)的設(shè)計，例如P2P模式：下載開始時，首先從服務(wù)器請求資源列表，然后連接到列表中的資源上請求數(shù)據(jù)分包，如果有很多節(jié)點擁有資源，就能同時請求分包。所以理論上P2P模式的速度上限就是請求節(jié)點的網(wǎng)絡(luò)速度上限。對等端體系結(jié)構(gòu)也用于設(shè)計一些在難以存在穩(wěn)定服務(wù)器的特殊環(huán)境中使用的系統(tǒng)，例如車載網(wǎng)絡(luò)數(shù)據(jù)傳輸，所有車輛位置是無法提前精確預(yù)測的，此時通信節(jié)點只能自組織連接。分布式系統(tǒng)結(jié)構(gòu)第四節(jié)客戶機/服務(wù)器體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)多處理器體系結(jié)構(gòu)對等端體系結(jié)構(gòu)代理代理

代理可以用于構(gòu)件包含隔離組件的軟件系統(tǒng)，軟件通過遠程服務(wù)調(diào)用進行交互。代理者負責(zé)協(xié)調(diào)通信，諸如轉(zhuǎn)發(fā)請求和傳遞結(jié)果、異常等。在ORB上有4個對象接口。對象服務(wù)。定義加入ORB的系統(tǒng)級服務(wù)，如安全性、命名、事務(wù)處理，這類與應(yīng)用領(lǐng)域無關(guān)。公共設(shè)施。定義應(yīng)用程序級服務(wù)。領(lǐng)域接口。面向特定領(lǐng)域接口。應(yīng)用接口。面向指定的外界應(yīng)用，一般是供應(yīng)商或用戶借助ORB、公共對象服務(wù)以及公共設(shè)施而開發(fā)的特定產(chǎn)品。體系結(jié)構(gòu)框架第五節(jié)模型-視圖-表示器J2EE體系結(jié)構(gòu)框架模型-視圖-控制器PCMEF框架PCBMER框架模型-視圖-控制器

MVC（Model-View-Controller）模型由TrygveReenskaug博士在20世紀70年代提出，并最早在面向?qū)ο缶幊陶Z言Smalltalk-80中實現(xiàn)。MVC強調(diào)將用戶的輸入、數(shù)據(jù)模型和數(shù)據(jù)表示方式分開設(shè)計，一個交互式應(yīng)用系統(tǒng)由模型、視圖、控制器3部分組成，分別對應(yīng)內(nèi)部數(shù)據(jù)、數(shù)據(jù)表示和輸入/輸出控制部分。模型-視圖-控制器

模型。模型對象代表應(yīng)用領(lǐng)域中的業(yè)務(wù)實體和業(yè)務(wù)邏輯規(guī)則，是整個模型的核心，獨立于外在的顯示內(nèi)容和顯示形式。模型對象的變化通過事件通知視圖和控制器對象。采用了發(fā)布者/訂閱者方式，模型是發(fā)布者，視圖和控制器是訂閱者。對于模型來說，并不知道自己對應(yīng)的視圖控制器；但控制器可以通過模型提供的接口改變模型對象，接口內(nèi)封裝了業(yè)務(wù)數(shù)據(jù)和行為。

視圖。視圖對象代表GUI對象，以用戶熟悉和需要的格式表現(xiàn)模型信息，是系統(tǒng)與外界的交互接口。視圖訂閱模型可以感知模型的數(shù)據(jù)變化，并更新自己的顯示。視圖對象也可以包含子視圖，用于顯示模型的不同部分。在多數(shù)的MVC實現(xiàn)技術(shù)中，視圖和控制器常常是一一對應(yīng)的。

控制器?？刂破鲗ο筇幚碛脩舻妮斎?，并給模型發(fā)送業(yè)務(wù)事件，再將業(yè)務(wù)事件解析為模型應(yīng)執(zhí)行的動作；同時，模型的更新與修改也將通過控制器來通知視圖，保持視圖與模型的一致。模型-視圖-控制器

MVC的整個處理流程為：系統(tǒng)攔截到用戶請求，根據(jù)相應(yīng)規(guī)則（多數(shù)采用路由技術(shù)），將用戶請求交給控制器，控制器決定哪個模型來處理用戶的請求；模型根據(jù)業(yè)務(wù)邏輯處理完畢后將結(jié)果返回給控制器；然后控制器將數(shù)據(jù)提交給視圖；視圖把數(shù)據(jù)組裝之后，呈現(xiàn)給用戶。其中，模型處理所有的業(yè)務(wù)邏輯和規(guī)則，視圖只負責(zé)顯示數(shù)據(jù)，控制器負責(zé)用戶的請求，這樣將業(yè)務(wù)和表現(xiàn)層分離，以便業(yè)務(wù)代碼可以被用于任何相似的業(yè)務(wù)中，視圖代碼也可以根據(jù)需要隨意替換。模型-視圖-控制器體系結(jié)構(gòu)框架第五節(jié)模型-視圖-表示器J2EE體系結(jié)構(gòu)框架模型-視圖-控制器PCMEF框架PCBMER框架模型-視圖-表示器

模型-視圖-表示器（Model-View-Presenter，簡稱MVP）是近年來流行起來的一種體系結(jié)構(gòu)。從名字上就可以看出，MVP與MVC十分類似，事實也確實如此。甚至有程序員開玩笑說MVP不過是將MVC中的C換成了字母P，這種說法一定程度上確實有其道理。MVP與MVC的的主要差異體現(xiàn)在“請求在何處訪問系統(tǒng)”以及“各部分如何聯(lián)系在一起”。MVP中的視圖比MVC中的視圖更加“被動”，視圖引發(fā)事件，但是由表示器讀取并設(shè)置UI的值。事實上，MVP模式設(shè)計的目的就是為了增強MVC模式，以嘗試使視圖更加被動，以便更換視圖更加容易。

MVP的處理流程如圖所示。用戶直接與視圖進行交互（圖中步驟1）。視圖通過引發(fā)一個事件，通知表示器有事件發(fā)生（步驟2），然后表示器訪問視圖通過其IView接口公開的屬性（步驟3）。這些屬性是視圖實際UI元素的包裝器。此后表示器調(diào)用模型（步驟4），再返回結(jié)果（步驟5）。表示器轉(zhuǎn)換數(shù)據(jù)，然后設(shè)置UI的值，該操作通過IView接口完成（步驟6）。視圖將最終頁面顯示給用戶。模型-視圖-表示器體系結(jié)構(gòu)框架第五節(jié)模型-視圖-表示器J2EE體系結(jié)構(gòu)框架模型-視圖-控制器PCMEF框架PCBMER框架J2EE體系結(jié)構(gòu)框架

MVC是很多現(xiàn)代體系結(jié)構(gòu)框架的基礎(chǔ)，主要應(yīng)用于企業(yè)和電子商務(wù)系統(tǒng)中。J2EE的核心體系結(jié)構(gòu)就是在MVC框架的基礎(chǔ)上進行擴展得到的，如圖所示。J2EE模型是分層結(jié)構(gòu)，中間是3層（表示層、業(yè)務(wù)層和集成層）包含應(yīng)用構(gòu)件，客戶層和資源層處于應(yīng)用的外圍。J2EE體系結(jié)構(gòu)框架

客戶層：用戶與系統(tǒng)交互的入口。該層可以是各種類型的客戶端，如C/S，瀏覽器，移動設(shè)備等。資源層：可以是企業(yè)數(shù)據(jù)庫、電子商務(wù)解決方案中的外部系統(tǒng)等。數(shù)據(jù)可以分布式地部署在多個服務(wù)器上。表示層：是用戶與應(yīng)用之間的橋梁。在基于Web的系統(tǒng)中，表示層由用戶界面代碼和運行在服務(wù)器上的程序組成。業(yè)務(wù)層：包含業(yè)務(wù)邏輯和應(yīng)用邏輯，負責(zé)確認和執(zhí)行企業(yè)范圍內(nèi)的業(yè)務(wù)規(guī)則和事務(wù)，并管理從資源層加載到應(yīng)用程序中的業(yè)務(wù)對象。集成層：負責(zé)建立和維護與數(shù)據(jù)源的連接。體系結(jié)構(gòu)框架第五節(jié)模型-視圖-表示器J2EE體系結(jié)構(gòu)框架模型-視圖-控制器PCMEF框架PCBMER框架PCMEF框架

表示-控制-中介-實體-基礎(chǔ)（Presentation-Control-Mediator-Entity-Foundation，簡稱PCMEF）是一個垂直層次的分層體系結(jié)構(gòu)框架。每一層是可以包含子包的包。PCMEF框架包含4層：表示層、控制層、領(lǐng)域?qū)雍突A(chǔ)層。領(lǐng)域?qū)影瑑蓚€預(yù)定義的包：實體（Entity）和中介（Mediator）。參考MVC框架，表示層對應(yīng)MVC中的視圖，控制層對應(yīng)MVC中的控制器，領(lǐng)域?qū)拥膶嶓w對應(yīng)MVC中的模型。MVC中沒有與中介和基礎(chǔ)層對應(yīng)的部分，因為MVC本身只是上層框架，中介和基礎(chǔ)層多使用底層框架實現(xiàn)。PCMEF框架中包的依賴性主要是向下依賴。表示層依賴于控制層，控制層依賴于領(lǐng)域?qū)樱薪閷右蕾囉趯嶓w和基礎(chǔ)層。PCMEF框架

表示層：包含定義GUI對象的類?？刂茖樱禾幚肀硎緦拥恼埱螅撠?zé)大多數(shù)程序邏輯、算法、業(yè)務(wù)計算以及維護用戶會話等、領(lǐng)域?qū)樱涸搶影怼皹I(yè)務(wù)對象”的類，很多實體類是容器類。領(lǐng)域?qū)拥膶嶓w包處理控制請求，中介包創(chuàng)建協(xié)調(diào)實體類和基礎(chǔ)類的通信信道。協(xié)調(diào)工作一方面是為了隔離包，避免相互影響；一方面是當需要從數(shù)據(jù)庫中提取新的實體對象時，控制類不需要之間與基礎(chǔ)類通信?；A(chǔ)層：負責(zé)Web服務(wù)于數(shù)據(jù)庫的所有通信，管理應(yīng)用程序所需要的所有數(shù)據(jù)。體系結(jié)構(gòu)框架第五節(jié)模型-視圖-表示器J2EE體系結(jié)構(gòu)框架模型-視圖-控制器PCMEF框架PCBMER框架PCBMER框架

現(xiàn)在主流使用的是PCMEF框架的擴展，劃分為6個層次，意思是表示-控制器-Bean-中介-實體-資源（Presentation-Controller-Bean-Mediator-Entity-Resource，簡稱PCBMER），如圖所示。PEBMER遵循了當前體系結(jié)構(gòu)設(shè)計中廣泛認可的發(fā)展趨勢。和PCMEF類似，PCBMER體系中，各層也用包來表示并具有向下依賴關(guān)系。比如，表示層依賴于控制器層和Bean層，控制器層向下依賴于Bean、中介和實體層等。但PCBMER框架中，各層之間并不是嚴格線性依賴的，一個上層可以依賴多個相鄰下層。PCBMER框架

表示層：表示呈現(xiàn)給用戶的UI對象，依賴于bean層。Bean層：表示那些預(yù)定呈現(xiàn)給用戶界面的實體類和對象。除了用戶輸入外，bean數(shù)據(jù)由實體對象創(chuàng)建。Bean層不依賴于其他層?？刂破鲗樱罕硎緫?yīng)用邏輯，相應(yīng)來自表示層的UI請求。中介層：建立實體類和資源類媒介的信道，管理業(yè)務(wù)處理，