第5章 軟件體系結(jié)構(gòu)與設(shè)計(jì)模式

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

9.1軟件體系結(jié)構(gòu)的基本概念（2）設(shè)計(jì)模式（designpattern）：為軟件系統(tǒng)的子系統(tǒng)、構(gòu)件或者構(gòu)件之間的關(guān)系提供一個(gè)精煉之后的解決方案，描述了在特定環(huán)境下，用于解決通用軟件設(shè)計(jì)問題的構(gòu)件以及這些構(gòu)件相互通信時(shí)的各種結(jié)構(gòu)。有代表性的設(shè)計(jì)模式是ErichGamma及其同事提出的23種設(shè)計(jì)模式。（3）慣用法（idiom）：是與編程語言相關(guān)的低級模式，描述如何實(shí)現(xiàn)構(gòu)件的某些功能，或者利用編程語言的特性來實(shí)現(xiàn)構(gòu)件內(nèi)部要素之間的通信功能。9.1軟件體系結(jié)構(gòu)的基本概念2．風(fēng)格風(fēng)格是帶有一種傾向性的模式。同一個(gè)問題可以有不同的解決問題的方案或模式，但我們根據(jù)經(jīng)驗(yàn)，通常會強(qiáng)烈傾向于采用特定的模式，這就是風(fēng)格。每種風(fēng)格描述一種系統(tǒng)范疇，該范疇包括：（1）一組構(gòu)件（如數(shù)據(jù)庫、計(jì)算模塊）完成系統(tǒng)需要的某種功能；（2）一組連接件，它們能使構(gòu)件間實(shí)現(xiàn)“通信”、“合作”和“協(xié)調(diào)”；（3）約束，定義構(gòu)件如何集成為一個(gè)系統(tǒng)；（4）語義模型，它能使設(shè)計(jì)者通過分析系統(tǒng)的構(gòu)成成分的性質(zhì)來理解系統(tǒng)的整體性質(zhì)。9.1軟件體系結(jié)構(gòu)的基本概念3．框架隨著應(yīng)用的發(fā)展和完善，某些帶有整體性的應(yīng)用模式被逐漸固定下來，形成特定的框架，包括基本構(gòu)成元素和關(guān)系?？蚣苁翘囟☉?yīng)用領(lǐng)域問題的體系結(jié)構(gòu)模式，框架定義了基本構(gòu)成單元和關(guān)系后，開發(fā)者就可以集中精力解決業(yè)務(wù)邏輯問題。在組織形式上，框架是一個(gè)待實(shí)例化的完整系統(tǒng)，定義了軟件系統(tǒng)的元素和關(guān)系，創(chuàng)建了基本的模塊，定義了涉及功能更改和擴(kuò)充的插件位置。典型的框架例子有MFC框架和Struts框架。5.1軟件體系結(jié)構(gòu)的基本概念體系結(jié)構(gòu)的重要作用（1）體系結(jié)構(gòu)的表示有助于風(fēng)險(xiǎn)承擔(dān)者（項(xiàng)目干系人）進(jìn)行交流。（2）體系結(jié)構(gòu)突出了早期設(shè)計(jì)決策。（3）軟件體系結(jié)構(gòu)是可傳遞和可復(fù)用的模型。

9.2典型的體系結(jié)構(gòu)風(fēng)格管道/過濾器結(jié)構(gòu)

5.2典型的體系結(jié)構(gòu)風(fēng)格1、數(shù)據(jù)流風(fēng)格當(dāng)輸入數(shù)據(jù)經(jīng)過一系列的計(jì)算和操作構(gòu)件的變換形成輸出數(shù)據(jù)時(shí)，可以應(yīng)用這種體系結(jié)構(gòu)。管道/過濾器、批處理序列都屬于數(shù)據(jù)流風(fēng)格。管道/過濾器結(jié)構(gòu)如下圖所示。9.2典型的體系結(jié)構(gòu)風(fēng)格從上圖可看出，管道/過濾器結(jié)構(gòu)擁有一組被稱為過濾器（filter）的構(gòu)件，這些構(gòu)件通過管道（pipe）連接，管道將數(shù)據(jù)從一個(gè)構(gòu)件傳送到下一個(gè)構(gòu)件。每個(gè)過濾器獨(dú)立于其上游和下游的構(gòu)件而工作，過濾器的設(shè)計(jì)要針對某種形式的數(shù)據(jù)輸入，并且產(chǎn)生某種特定形式的數(shù)據(jù)輸出。如果數(shù)據(jù)流退化成為單線的變換，則稱為批處理序列（batchsequential）。這種結(jié)構(gòu)接收一批數(shù)據(jù)，然后應(yīng)用一系列連續(xù)的構(gòu)件（過濾器）變換它。9.2典型的體系結(jié)構(gòu)風(fēng)格管道/過濾器風(fēng)格具有以下優(yōu)點(diǎn)：（1）使得軟構(gòu)件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點(diǎn)。（2）允許設(shè)計(jì)者將整個(gè)系統(tǒng)的輸入/輸出行為看成是多個(gè)過濾器的行為的簡單合成。（3）支持軟件復(fù)用。只要提供適合在兩個(gè)過濾器之間傳送的數(shù)據(jù)，任何兩個(gè)過濾器都可被連接起來。（4）系統(tǒng)維護(hù)和增強(qiáng)系統(tǒng)性能簡單。新的過濾器可以添加到現(xiàn)有系統(tǒng)中來；舊的可以被改進(jìn)的過濾器替換掉。（5）允許對一些如吞吐量、死鎖等屬性的分析。（6）支持并行執(zhí)行。每個(gè)過濾器是作為一個(gè)單獨(dú)的任務(wù)完成，因此可與其他任務(wù)并行執(zhí)行。管道/過濾器風(fēng)格主要缺點(diǎn)如下：（1）通常導(dǎo)致進(jìn)程成為批處理的結(jié)構(gòu)。這是因?yàn)殡m然過濾器可增量式地處理數(shù)據(jù)，但它們是獨(dú)立的，所以設(shè)計(jì)者必須將每個(gè)過濾器看成一個(gè)完整的從輸入到輸出的轉(zhuǎn)換。（2）不適合處理交互的應(yīng)用。當(dāng)需要增量地顯示改變時(shí)，這個(gè)問題尤為嚴(yán)重。（3）因?yàn)樵跀?shù)據(jù)傳輸上沒有通用的標(biāo)準(zhǔn)，每個(gè)過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導(dǎo)致了系統(tǒng)性能下降，并增加了編寫過濾器的復(fù)雜性。2、倉庫結(jié)構(gòu)倉庫或知識庫結(jié)構(gòu)(Repositoryarchitecture)倉庫結(jié)構(gòu)是一種以數(shù)據(jù)為中心的體系結(jié)構(gòu)包含兩種不同的軟件部件：一個(gè)中心數(shù)據(jù)庫和一組相互獨(dú)立的處理中心數(shù)據(jù)的子系統(tǒng)主要適合于數(shù)據(jù)由一個(gè)子系統(tǒng)產(chǎn)生而由其他子系統(tǒng)使用的情形典型應(yīng)用：現(xiàn)代編譯器、管理信息系統(tǒng)、CAD系統(tǒng)和CASE工具集等

倉庫結(jié)構(gòu)143、分層結(jié)構(gòu)層次化是一種概念，它將軟件設(shè)計(jì)組織成為類或組件的層次或集合，在同一個(gè)層次上的類或組件完成一個(gè)特定的目的良好的層次結(jié)構(gòu)可以易于系統(tǒng)的擴(kuò)展與維護(hù)，不同的層次之間通過接口進(jìn)行通信例如：網(wǎng)絡(luò)協(xié)議OSI參考模型

15網(wǎng)絡(luò)協(xié)議OSI參考模型分層體系結(jié)構(gòu)175.3分布式系統(tǒng)結(jié)構(gòu)在集中式計(jì)算技術(shù)時(shí)代廣泛使用的是大型機(jī)/小型機(jī)計(jì)算模型。20世紀(jì)80年代以后，集中式結(jié)構(gòu)逐漸被以PC為主的微機(jī)網(wǎng)絡(luò)所取代。個(gè)人計(jì)算機(jī)和工作站的采用，永遠(yuǎn)改變了大型機(jī)/小型機(jī)計(jì)算模型，從而產(chǎn)生了分布式計(jì)算模型。5.3分布式系統(tǒng)結(jié)構(gòu)分布式系統(tǒng)6個(gè)重要特征：（Coulouris等1994年提出）資源共享允許硬件、軟件資源共享使用開放性允許來自不同廠商的軟/硬兼容產(chǎn)品并發(fā)性許多過程可以在網(wǎng)絡(luò)的不同計(jì)算機(jī)上同時(shí)運(yùn)行，并允許在期間彼此通訊可伸縮性分布式系統(tǒng)至少要有可伸縮性，系統(tǒng)的能力可以通過增加新的資源來滿足對系統(tǒng)的新的需求容錯(cuò)性錯(cuò)誤發(fā)生時(shí)可能降低系統(tǒng)的服務(wù)能力，但徹底喪失服務(wù)能力只有在發(fā)生網(wǎng)絡(luò)錯(cuò)誤時(shí)才會出現(xiàn)透明性對用戶隱藏了系統(tǒng)分布的存在分布式系統(tǒng)的缺點(diǎn)：復(fù)雜性：比集中式系統(tǒng)更復(fù)雜。系統(tǒng)性能涉及網(wǎng)絡(luò)帶寬和運(yùn)行其上的不同計(jì)算機(jī)速度保密性：能從網(wǎng)絡(luò)上的許多計(jì)算機(jī)上進(jìn)入系統(tǒng)，而且網(wǎng)絡(luò)通訊遭到竊聽管理有效性：不同的機(jī)型、操作系統(tǒng)和版本，有可能一臺機(jī)器上的錯(cuò)誤被傳播到其他機(jī)器上，從而產(chǎn)生預(yù)想不到的結(jié)果不可預(yù)見性：系統(tǒng)負(fù)荷、網(wǎng)絡(luò)負(fù)荷等因素是變化的，故直接影響分布式系統(tǒng)的響應(yīng)205.3分布式系統(tǒng)結(jié)構(gòu)分布式系統(tǒng)設(shè)計(jì)中的問題資源識別：如何識別和引用散布在分布式系統(tǒng)中不同計(jì)算機(jī)上的資源？如：URL（UniformResourceLocator）命名模式，用來識別WWW的網(wǎng)頁通信：除TCP/IP外的其他通訊方式以適應(yīng)特殊需求服務(wù)質(zhì)量：影響服務(wù)質(zhì)量的因素包括處理過程在系統(tǒng)中的位置軟件體系結(jié)構(gòu)：為應(yīng)用程序選擇一個(gè)合適的軟件體系結(jié)構(gòu)以達(dá)到期望的服務(wù)質(zhì)量215.3分布式系統(tǒng)結(jié)構(gòu)分布式系統(tǒng)體系結(jié)構(gòu)客戶機(jī)/服務(wù)器體系結(jié)構(gòu)： 系統(tǒng)被看成是提供一組服務(wù)供客戶機(jī)使用，服務(wù)器和客戶機(jī)被區(qū)別對待。分布式對象體系結(jié)構(gòu)： 不再區(qū)分服務(wù)器和客戶機(jī)，而是將系統(tǒng)當(dāng)成交互的一組對象，他們的位置無關(guān)緊要，服務(wù)提供者和服務(wù)消費(fèi)者之間沒有區(qū)別。225.3分布式系統(tǒng)結(jié)構(gòu)5.3分布式系統(tǒng)結(jié)構(gòu)傳統(tǒng)的C/S體系結(jié)構(gòu)分為兩層。在這種體系結(jié)構(gòu)中，一個(gè)應(yīng)用系統(tǒng)被劃分為客戶機(jī)和服務(wù)器兩部分。典型的兩層C/S體系結(jié)構(gòu)如下圖所示。客戶機(jī)/服務(wù)器體系結(jié)構(gòu)在一個(gè)客戶機(jī)/服務(wù)器體系中，一個(gè)應(yīng)用程序建模成一組服務(wù)，這組服務(wù)由服務(wù)器提供，并由客戶機(jī)來使用客戶機(jī)需要知道這些服務(wù)器的存在，但通常不知道其他客戶機(jī)的存在客戶機(jī)和服務(wù)器是不同的過程過程和處理器之間沒有必要一對一地映射24客戶機(jī)/服務(wù)器體系結(jié)構(gòu)客戶機(jī)/服務(wù)器體系結(jié)構(gòu)的邏輯模型25客戶機(jī)/服務(wù)器體系結(jié)構(gòu)分層表示的應(yīng)用結(jié)構(gòu)表示層：將信息表達(dá)給用戶并關(guān)注與用戶的交互應(yīng)用處理層：關(guān)注實(shí)現(xiàn)應(yīng)用邏輯數(shù)據(jù)管理層：關(guān)注所有數(shù)據(jù)庫的操作26客戶機(jī)/服務(wù)器體系結(jié)構(gòu)二層C/S結(jié)構(gòu)最簡單的客戶/服務(wù)器體系結(jié)構(gòu)一個(gè)應(yīng)用被組織成一組客戶機(jī)和一個(gè)服務(wù)器二層C/S結(jié)構(gòu)的兩種形態(tài)：瘦客戶機(jī)模型 所有的應(yīng)用處理和數(shù)據(jù)管理都在服務(wù)器上執(zhí)行，客戶機(jī)只負(fù)責(zé)表示部分胖客戶機(jī)模型 服務(wù)只負(fù)責(zé)對數(shù)據(jù)的管理，客戶機(jī)實(shí)現(xiàn)應(yīng)用邏輯和與用戶的交互27瘦客戶機(jī)和胖客戶機(jī)28客戶機(jī)/服務(wù)器體系結(jié)構(gòu)客戶機(jī)/服務(wù)器體系結(jié)構(gòu)瘦客戶機(jī)缺點(diǎn)：繁重的處理負(fù)荷都放在服務(wù)器和網(wǎng)絡(luò)上，造成C/S之間的網(wǎng)絡(luò)數(shù)據(jù)流量過大胖客戶機(jī)較好地利用的客戶端處理機(jī)的能力，著名的實(shí)例：銀行ATM系統(tǒng)缺點(diǎn)：應(yīng)用分散在許多不同的計(jì)算機(jī)上，當(dāng)更新軟件時(shí)工作量大，系統(tǒng)管理復(fù)雜29客戶機(jī)/服務(wù)器體系結(jié)構(gòu)客戶機(jī)/服務(wù)器ATM系統(tǒng)31三層C/S結(jié)構(gòu)三層C/S結(jié)構(gòu)不意味著有三個(gè)計(jì)算機(jī)系統(tǒng)連到網(wǎng)絡(luò)上，可以僅僅是軟件上的分層，即：一臺服務(wù)器既提供應(yīng)用處理又提供數(shù)據(jù)管理客戶機(jī)/服務(wù)器體系結(jié)構(gòu)三層客戶/服務(wù)器風(fēng)格

32

瀏覽器/服務(wù)器（B/S）風(fēng)格

瀏覽器/服務(wù)器（B/S）風(fēng)格就是上述三層應(yīng)用結(jié)構(gòu)的一種實(shí)現(xiàn)方式，其具體結(jié)構(gòu)為：瀏覽器/Web服務(wù)器/數(shù)據(jù)庫服務(wù)器。

B/S體系結(jié)構(gòu)主要是利用不斷成熟的WWW瀏覽器技術(shù)，結(jié)合瀏覽器的多種腳本語言，用通用瀏覽器就實(shí)現(xiàn)了原來需要復(fù)雜的專用軟件才能實(shí)現(xiàn)的強(qiáng)大功能，并節(jié)約了開發(fā)成本。從某種程度上來說，B/S結(jié)構(gòu)是一種全新的軟件體系結(jié)構(gòu)。

33B/S體系結(jié)構(gòu)

3435互聯(lián)網(wǎng)銀行系統(tǒng)的分布式體系結(jié)構(gòu)B/S體系結(jié)構(gòu)優(yōu)點(diǎn)基于B/S體系結(jié)構(gòu)的軟件，系統(tǒng)安裝、修改和維護(hù)全在服務(wù)器端解決。用戶在使用系統(tǒng)時(shí)，僅僅需要一個(gè)瀏覽器就可運(yùn)行全部的模塊，真正達(dá)到了“零客戶端”的功能，很容易在運(yùn)行時(shí)自動升級B/S體系結(jié)構(gòu)還提供了異種機(jī)、異種網(wǎng)、異種應(yīng)用服務(wù)的聯(lián)機(jī)、聯(lián)網(wǎng)、統(tǒng)一服務(wù)的最現(xiàn)實(shí)的開放性基礎(chǔ)。

36分布式對象體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)在分布式對象體系結(jié)構(gòu)設(shè)計(jì)中客戶機(jī)和服務(wù)器不存在差別構(gòu)成系統(tǒng)的基本組件是對象，一個(gè)對象能向另一個(gè)對象提供服務(wù)，并能接受來自其它對象的服務(wù)接受服務(wù)者即扮演客戶機(jī)角色，提供服務(wù)者就是服務(wù)器37分布式對象體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)分布式對象體系結(jié)構(gòu)對象可能分布在網(wǎng)絡(luò)的多臺計(jì)算機(jī)上，它們通過中間件相互通訊，這個(gè)中間件被稱作“對象請求代理”（也叫：軟總線）對象體系結(jié)構(gòu)的主要缺點(diǎn)是設(shè)計(jì)比C/S結(jié)構(gòu)更復(fù)雜適合使用分布式對象結(jié)構(gòu)的一個(gè)實(shí)例是數(shù)據(jù)挖掘系統(tǒng)，即：在多個(gè)數(shù)據(jù)庫間尋找數(shù)據(jù)間的關(guān)系分布式對象體系結(jié)構(gòu)數(shù)據(jù)挖掘系統(tǒng)的分布式體系結(jié)構(gòu)41其中：數(shù)據(jù)庫——提供只讀訪問功能的對象集成器——專注一種特別類型的關(guān)系，從所有數(shù)據(jù)庫中收集信息試著推出這種關(guān)系可視生成器——與集成器對象交互，提供所發(fā)現(xiàn)關(guān)系的可視化效果圖和報(bào)告分布式對象體系結(jié)構(gòu)415.4體系結(jié)構(gòu)框架1、模型/視圖/控制器結(jié)構(gòu)Modle/View/ControllerArchitecture支持?jǐn)?shù)據(jù)的多重表示要顯示的數(shù)據(jù)被封裝在模型中的對象里每個(gè)模型對象可能與許多的視圖對象關(guān)聯(lián)每個(gè)視圖都有一個(gè)相關(guān)的處理用戶輸入和設(shè)備交互的控制對象9.5體系結(jié)構(gòu)框架用戶交互的MVC模型信息表示示意圖：44J2EE的核心體系結(jié)構(gòu)就是在MVC框架的基礎(chǔ)上進(jìn)行擴(kuò)展得到的，如下圖所示。9.5體系結(jié)構(gòu)框架J2EE體系結(jié)構(gòu)框架

J2EE的核心體系結(jié)構(gòu)框架

客戶層：用戶通過客戶層與系統(tǒng)交互。該層可以是各種類型的客戶端。例如，可編程客戶端（如基于JavaSwing的客戶端或applet），純Web瀏覽器客戶端，WML移動客戶端等。資源層：資源層可以是企業(yè)數(shù)據(jù)庫，電子商務(wù)解決方案中的外部企業(yè)系統(tǒng)，或者是外部SOA服務(wù)。數(shù)據(jù)可以分布在多個(gè)服務(wù)器上。從上圖可看出，J2EE模型是分層結(jié)構(gòu)，中間的3層（表示層，業(yè)務(wù)層，集成層）包含應(yīng)用程序構(gòu)件，客戶層和資源層處于應(yīng)用程序的外圍。

9.5體系結(jié)構(gòu)框架表示層：也稱為Web層或服務(wù)器端表示層，用戶通過表示層來訪問應(yīng)用程序。在基于Web的應(yīng)用系統(tǒng)中，表示層由用戶界面代碼和運(yùn)行于Web服務(wù)器或應(yīng)用服務(wù)器上的過程組成。參考MVC框架，表示層包括視圖構(gòu)件和控制器構(gòu)件。業(yè)務(wù)層：業(yè)務(wù)層包含表示層中的控制器構(gòu)件沒有實(shí)現(xiàn)的一部分應(yīng)用邏輯。它負(fù)責(zé)確認(rèn)和執(zhí)行企業(yè)范圍內(nèi)的業(yè)務(wù)規(guī)則和事務(wù)，并管理從資源層加載到應(yīng)用程序高速緩存中的業(yè)務(wù)對象。集成層：集成層負(fù)責(zé)建立和維護(hù)與數(shù)據(jù)源的連接。例如，通過JDBC與數(shù)據(jù)庫進(jìn)行通信，利用Java消息服務(wù)（JMS）與外部系統(tǒng)聯(lián)合。9.5體系結(jié)構(gòu)框架5.5設(shè)計(jì)模式回顧學(xué)過的數(shù)據(jù)結(jié)構(gòu)Trees,Stacks,Queues它們給軟件開發(fā)帶來了什么？問題在軟件體系結(jié)構(gòu)設(shè)計(jì)中是否存在一些可重用的解決方案？答案是肯定的設(shè)計(jì)模式使我們可以重用已經(jīng)成功的經(jīng)驗(yàn)Pattern＝DocumentedexperienceDesignPatterns:ElementsofReusableObject-OrientedSoftware48在眾多應(yīng)用中普遍存在的軟件結(jié)構(gòu)和結(jié)構(gòu)關(guān)系。它們在不同的領(lǐng)域中獲得應(yīng)用，成為處理特定問題的高效且成熟的設(shè)計(jì)模板，稱為“模式（Pattern）”設(shè)計(jì)模式實(shí)際上是對經(jīng)常重復(fù)出現(xiàn)的類似問題的一個(gè)解決方案（一個(gè)模式），這個(gè)解決方案在其它語境中也同樣適用。面向?qū)ο蟮脑O(shè)計(jì)模式是一組相互協(xié)作以實(shí)現(xiàn)某個(gè)設(shè)計(jì)目標(biāo)的對象或?qū)ο箢惖男〖?95.5設(shè)計(jì)模式一般來說，一個(gè)模式有4個(gè)基本的要素：模式名稱：用于描述模式的名字，說明模式的問題、解決方案和效果。問題：說明在何種場合使用模式。解決方案：描述設(shè)計(jì)的組成成分、它們之間的相互關(guān)系、各自的職責(zé)和合作方式。效果：描述了模式使用的效果及使用模式應(yīng)當(dāng)權(quán)衡的問題。

目前已提出的設(shè)計(jì)模式的類型：創(chuàng)建型模式 抽象工廠、生成器、工廠方法、原型、單件結(jié)構(gòu)型模式 適配器、橋接、組成、裝飾、外觀等行為型模式 職責(zé)鏈、命令、迭代器、狀態(tài)等51抽象工廠(1)目的：提供一個(gè)接口用以創(chuàng)建一個(gè)相聯(lián)系或相依賴的對象族，而無須指定它們的具體類。(2)思路：例如，在創(chuàng)建可支持多種GUI標(biāo)準(zhǔn)（如Motif和PersentationManager）的繪圖用戶界面工具包時(shí)，因?yàn)椴煌腉UI標(biāo)準(zhǔn)會定義出不同外觀及行為的“用戶界面組件”（widget），如滾動條、按鈕、視窗等。為了能夠囊括各種GUI標(biāo)準(zhǔn)，應(yīng)用程序不能把組件寫死，不能限制到特定GUI風(fēng)格的組件類，否則日后很難換成其他GUI風(fēng)格的組件。抽象工廠解決方法是：先定義一個(gè)抽象類WidgetFactory（用斜體字區(qū)分抽象類），這個(gè)類聲明了創(chuàng)建各種基本組件的接口，再逐一替各種基本組件定義相對應(yīng)的抽象類，如ScrollBar、Window等，讓它們的具體子類來真正實(shí)現(xiàn)特定的GUI標(biāo)準(zhǔn)。抽象工廠可支持多種GUI標(biāo)準(zhǔn)的繪圖用戶界面工具包的結(jié)構(gòu)圖

表示了兩種不同的用戶界面工具包，可抽象為一種形式——WindowKit根據(jù)實(shí)現(xiàn)平臺的不同，WindowKit被綁定到不同的實(shí)例中說明：設(shè)計(jì)模式描述了對重復(fù)出現(xiàn)問題的解決方案55抽象工廠(3)結(jié)構(gòu)：抽象工廠模式的結(jié)構(gòu)如圖所示。抽象工廠(4)參與者職責(zé)a)抽象工廠類（AbstractFactory）：聲明創(chuàng)建抽象產(chǎn)品對象的操作的接口。b)具體工廠類（ConcreteFactory）：實(shí)現(xiàn)產(chǎn)生具體產(chǎn)品對象的操作。c)抽象產(chǎn)品類（AbstractProduct）：聲明一種產(chǎn)品對象的接口。d)具體產(chǎn)品類（ConcreteProduct）：定義將被相應(yīng)的具體工廠類產(chǎn)生的產(chǎn)品對象，并實(shí)現(xiàn)抽象產(chǎn)品類接口。e)客戶（Client）：僅使用由抽象工廠類和抽象產(chǎn)品類聲明的接口。抽象工廠(5)協(xié)作在執(zhí)行時(shí)，AbstractFactory將產(chǎn)品交給ConcreteFactory創(chuàng)建。ConcreteFactory類的實(shí)例只有一個(gè)，專門針對某種特定的實(shí)現(xiàn)標(biāo)準(zhǔn)，建立具體可用的產(chǎn)品對象。如果想要建立其他標(biāo)準(zhǔn)的產(chǎn)品對象，客戶程序就得改用另一種ConcreteFactory。適配器(1)目的：適配器模式將一個(gè)類的接口轉(zhuǎn)換為客戶期望的另一種接口，使得原本不匹配的接口而無法合作的類可以一起工作。(2)思路：有時(shí)要將兩個(gè)沒有關(guān)系的類組合在一起使用，一種解決方案是修改各自類的接口，另一種辦法是使用Adapter模式，在兩種接口之間創(chuàng)建一個(gè)混合接口。例如，設(shè)有一個(gè)圖形編輯器，可畫直線、多邊形、文本等。它的接口定義成抽象類Shape，它的子類負(fù)責(zé)畫各種圖形。此外，還有一個(gè)外購的GUI軟件包TextView，用于顯示，但它沒有Shape功能。適配器

如何讓TextView的接口轉(zhuǎn)換成為Shape的接口，有兩種方法：

讓TextShape同時(shí)繼承Shape的接口和TextView的服務(wù)（多重繼承）；

在TextShape中建立TextView的實(shí)例，再通過TextView給出TextShape的接口。前者是適配器的類模式，后者是對象模式。下圖就是適配器的對象模式。適配器(3)結(jié)構(gòu)：適配器模式有類適配器模式和對象適配器模式。類適配器可以通過多繼承方式實(shí)現(xiàn)不同接口之間的相容和轉(zhuǎn)換，如圖所示。適配器而一個(gè)對象適配器則依賴對象組合的技術(shù)實(shí)現(xiàn)接口的相容和轉(zhuǎn)換，如圖所示。

適配器(4)參與者職責(zé)

a)目標(biāo)（Target）：定義客戶使用的與應(yīng)用領(lǐng)域相關(guān)的接口。

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

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

d)適配器（Adapter）：將Adaptee的接口與Target接口匹配。適配器(5)協(xié)作：客戶調(diào)用Adapter對象的操作，然后Adapter的操作又調(diào)用Adaptee對象中負(fù)責(zé)處理相應(yīng)請求的操作。觀察者(1)目的：定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個(gè)對象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對象都得到通知，并被自動更新。(2)思路：例如，許多GUI軟件包都將數(shù)據(jù)顯示部分與應(yīng)用程序底層的數(shù)據(jù)表示分開，以利于分別復(fù)用。但這些類也能合作，如圖所示的計(jì)算表和直方圖都是針對同一數(shù)據(jù)對象的兩種不同表示方式。

觀察者(3)結(jié)構(gòu)：Observer模式的結(jié)構(gòu)如圖所示。觀察者(4)參與者職責(zé)a)主題（Subject）：認(rèn)得它的觀察者。任意數(shù)目的觀察者對象均可訂閱一個(gè)主題。另外，提供一個(gè)連接觀察者對象和解除連接的接口。b)觀察者（Observer）：定義了一個(gè)自我更新的接口。一旦發(fā)現(xiàn)主題有變時(shí)借助接口通知自己隨之改變。c)具體主題（ConcreteSubject）：存儲具體觀察者對象關(guān)心的狀態(tài)；當(dāng)狀態(tài)改變時(shí)向它的觀察者發(fā)送通知。d)具體觀察者（ConcreteObserver）：維持一個(gè)對具體主題對象的引用；存儲要與主題一致的狀態(tài)；實(shí)現(xiàn)觀察者的自我更新接口，確保自己的狀態(tài)與主題的狀態(tài)一致。

觀察者(5)協(xié)作：當(dāng)具體主題發(fā)生會導(dǎo)致觀察者的狀態(tài)不一致的情況時(shí)，就會主動通知所有該通知的觀察者。當(dāng)具體觀察者收到通知后，向主題詢問，根據(jù)所得信息使自己的狀態(tài)與主題的狀態(tài)保持一致。下圖給出了一個(gè)主題和兩個(gè)觀察者對象之間的交互情況。5.6文檔化設(shè)計(jì)

概要設(shè)計(jì)說明書

1引言

2總體設(shè)計(jì)

2．1需求規(guī)定

僅說明系統(tǒng)主要的輸入/輸出、功能、性能要求，詳細(xì)內(nèi)容參見需求規(guī)格。

2．2運(yùn)行環(huán)境

2．3基本設(shè)計(jì)概念和處理流程

傳統(tǒng)方法：數(shù)據(jù)流模型（DFD圖），UML：設(shè)計(jì)視圖（系統(tǒng)最終確定的類圖、交互圖、狀態(tài)圖）69

2．4結(jié)構(gòu)

傳統(tǒng)：軟件體系結(jié)構(gòu)，軟件結(jié)構(gòu)圖（SC）

UML：實(shí)現(xiàn)視圖，實(shí)施視圖，進(jìn)程視圖

2．5功能需求與程序的關(guān)系