【正文】 層次結構的基本結構如下圖所示。由于每一層最多只影響 兩層，同時只要給相鄰層提供相同的接口，允許每層用不同 的方法實現，同樣為軟件復用提供了強大的支持。只要提供的服務接口定義不變，同一層的 不同實現可以交換使用。 典型的體系結構風格 數據庫系統(tǒng) 、 超文本系統(tǒng) 和 黑板系統(tǒng) 都屬于倉庫風 格 。黑板系統(tǒng)的組成如下圖所示。這些體系結構模型稱為 領域相關的體系結構 。 特定領域的軟件體系結構 ? 類屬模型的一個最著名的例子是 編譯器模型 ，由這個模型已開發(fā)出了數以千計的編譯器。 特定領域的軟件體系結構 以上兩種不同類型的模型之間并不存在嚴格的區(qū)別，也可以將類屬模型視為參考模型。 ? 20世紀 80年代以后，集中式結構逐漸被以 PC為主的微機網絡所取代。 (2) 經濟性。 分布式系統(tǒng)的一個最簡單的模型是多處理器系統(tǒng)，系統(tǒng)由 許多進程組成，這些進程可以在不同的處理器上并行運行， 可以極大地提高系統(tǒng)的性能。 分布式系統(tǒng)結構 ? 多處理器體系結構 客戶機 /服務器 （ client/server， C/S） 體系結構是基于 資源不對等 ， 且為實現共享而提出來的 ， 由 服務器 、 客戶 機 和 網絡 三部分組成 。 典型的兩層 C/S體系結構如下圖所示 。 ? 目前個人計算機所具有的處理能力在瘦客戶機模型中用不上。 胖客戶機模型能夠利用客戶機的處理能力，比瘦客戶機 模型在分布處理上更有效。 ? 軟件維護和升級困難。 分布式系統(tǒng)結構 三層 C/S體系結構將整個系統(tǒng)分成 表示層 、 應用邏輯層 和 數據層 三個部分，其數據處理流程如下圖所示。通常在功能層中包含有確認用戶對 應用和數據庫存取權限的功能以及記錄系統(tǒng)處理日志的功 能。 分布式系統(tǒng)結構 B/S體系結構主要是利用不斷成熟的 .瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器就實現了原來需要復雜的專用軟件才能實現的強大功能，并節(jié)約了開發(fā)成本。 分布式系統(tǒng)結構 與 C/S體系結構相比， B/S體系結構也有許多不足之處。 分布式系統(tǒng)結構 在客戶機 /服務器模型中，客戶機和服務器的地位是不同 的。 分布式系統(tǒng)結構 分布式對象技術的應用目的 是為了降低主服務器的負荷、 共享網絡資源、平衡網絡中計算機業(yè)務處理的分配，提高計 算機系統(tǒng)協(xié)同處理的能力，從而使應用的實現更為靈活。 ? 構件之間并不存在客戶機與服務器的界限，接受服務者扮演客戶機的角色，提供服務者就是服務器。代理者負責協(xié)調通信， 諸如轉發(fā)請求以及傳遞結果和異常等。 （ 2） 公共設施 ：水平級的服務，定義應用程序級服務。 分布式系統(tǒng)結構 MVC框架即模型 — 視圖 — 控制器（ modelviewcontroller）框架，它強調將用戶輸入、數據模型和數據表示的方式分開設計，一個交互式應用系統(tǒng)由 模型 、 視圖 和 控制器 3個部件組成，分別對應于內部數據、數據表示和輸入 /輸出控制部分。視圖對象可以包含子視 圖，子視圖用于顯示模型的不同部分。 體系結構框架 體系結構框架 MVC的處理過程為 ：首先控制器接收用戶的請求，并決定應該調用哪個模型來進行處理；然后模型用業(yè)務邏輯來處理用戶的請求并返回數據；最后控制器用相應的視圖格式化模型返回的數據，并通過表示層呈現給用戶。該層可以是各種類型的客戶端。 從上圖可看出， J2EE模型是 分層結構 ，中間的 3層（表示層，業(yè)務層，集成層）包含應用程序構件，客戶層和資源層處于應用程序的外圍。 ? 業(yè)務層： 業(yè)務層包含表示層中的控制器構件沒有實現的一部分應用邏輯。 體系結構框架 1． PCMEF框架 表示 — 控制 — 中介者 — 實體 — 基礎（ presentationcontrolmediatorentityfoundation， PCMEF）是一個垂直層次的分層體系結構框架。 PCMEF框架中包的依賴性主要是向下依賴性。 ? 領域層 :其實體包處理控制請求 ,中介者包用于創(chuàng)建一個協(xié)調實體類和基礎類的通信通道。 體系結構框架 PCBMER的核心框架 在上圖中，把層表示為 UML包（子系統(tǒng)，層），帶箭頭的 虛線表示依賴關系。除了用戶輸入外， bean數據由實體對象（實體層）創(chuàng)建。 ? 中介者層： 建立了充當實體類和資源類媒介的通信管道。 ? 目前，設計模式已經被廣泛應用于多種領域的軟件設計和構造中，許多當代的先進軟件中已大量采用了軟件設計模式的概念。 (4) 效果 ：描述了模式使用的效果及使用模式應當權衡的問題。 抽象工廠 ? 解決方法是：先定義一個抽象類 WidgetFactory（用斜體字區(qū)分抽象類），這個類聲明了創(chuàng)建各種基本組件的接口，再逐一替各種基本組件定義相對應的抽象類，如 ScrollBar、 Window等，讓它們的具體子類來真正實現特定的 GUI標準。 c) 抽象產品類（ AbstractProduct）：聲明一種產品對象的接口。 ? ConcreteFactory類的實例只有一個，專門針對某種特定的實現標準，建立具體可用的產品對象。 (2) 思路：例如，通常情況下，用戶可以對應用系統(tǒng)進行配置，并將配置信息保存在配置文件中，應用系統(tǒng)在啟動時首先將配置文件加載到內存中，這些內存配置信息應該有且僅有一份。 Instance是一個靜態(tài)成員函數 (5) 協(xié)作：客戶只能通過 Singleton的 Instance() 存取這唯一的實例。 外觀 (3) 結構：外觀模式的結構如圖所示。 (5)協(xié)作：使用 Facade的客戶不用直接訪問子系統(tǒng)對象。 (2)思路：有時要將兩個沒有關系的類組合在一起使用，一種解決方案是修改各自類的接口，另一種辦法是使用Adapter模式，在兩種接口之間創(chuàng)建一個混合接口。 適配器 如何讓 TextView的接口轉換成為 Shape的接口，有兩種方法： ? 讓 TextShape同時繼承 Shape的接口和 TextView的服務（多重繼承）； ? 在 TextShape中建立 TextView的實例，再通過 TextView給出TextShape的接口。類適配器可以通過多繼承方式實現不同接口之間的相容和轉換，如圖所示。 c) 被匹配者（ Adaptee）：需要被轉換匹配的一個已存在接口。該請求沿著這條鏈傳遞，直到有一個對象處理它為止。 如果用戶在 PrintDialog對話框里“打印”按鈕上按了幫助鍵，幫助信息的順序圖如圖所示。 責任鏈 (3) 結構：責任鏈模式的結構如圖所示 。 c) 客戶（ Client）：將處理請求提交給職責鏈中的ConcreteHandler對象。 (2) 思路：以 GUI系統(tǒng)的對話框為例，對話框中會布置許多窗口組件，如按鈕、菜單、文字輸入欄等。這些對象只認得中介者，因而可降低交互行為的數目。 中介者 ? 下圖顯示了加入 FontDialogDirector后的類結構。 c) 同事類（ Colleague classes）：這些同事類的對象都了解中介者；一個同事對象與另一個同事對象之間的通信都需要通過中介者來間接實現。但這些類也能合作，如圖所示的計算表和直方圖都是針對同一數據對象的兩種不同表示方式。另外，提供一個連接觀察者對象和解除連接的接口。 d) 具體觀察者（ ConcreteObserver）：維持一個對具體主題對象的引用；存儲要與主題一致的狀態(tài)；實現觀察者的自我更新接口，確保自己的狀態(tài)與主題的狀態(tài)一致。 演講完畢，謝謝觀看！