1、第一章 軟件體系結構概述（5分）一、 軟件體系結構的定義l 國內普遍接受的定義：軟件體系結構包括構件、連接件和約束，它是可預制和可重構的軟件框架結構。l 軟件體系結構 = 構件 + 連接件 + 約束二、 軟件體系結構的優勢l 容易理解l 重用l 控制成本l 可分析性第二章 軟件體系結構風格（10分）一、 軟件體系結構風格定義l 軟件體系結構風格是描述某一特定應用領域中系統組織方式的慣用模式。An architectural style defines a family of systems in terms of a pattern of structural organization.l 體

2、系結構風格定義了一個系統家族，即一個體系結構定義一個詞匯表和一組約束。詞匯表中包含一些構件和連接件類型，而這組約束指出系統是如何將這些構件和連接件組合起來的。An architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined.二、 常見的體系結構風格l 管道和過濾器 每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然后產生輸出數據流。 過濾器風格的連接件就像是數據流傳輸的管道，將一個過濾

3、器的輸出傳到另一個過濾器的輸入。l 數據抽象和面向對象組織 數據的表示方法和它們的相應操作被封裝在一個抽象數據類型或對象中。 這種風格的構件是對象或者說是抽象數據類型的實例。 對象通過函數和過程的調用來進行交互。l 基于事件的隱式調用 構件不直接調用一個過程，而是觸發或廣播一個或多個事件。 事件的觸發者并不知道哪些構件會被這些事件影響。l 分層系統 組織成一個層次結構。 每一層都為上一層提供了相應的服務，并且接受下一層提供的服務。l 倉庫系統 構件：中心數據結構（倉庫）和一些獨立構件的集合。 倉庫和在系統中很重要的外部構件之間的相互作用。l 過程控制環路 源自于控制理論中的模型框架，將事務處理

4、看成輸入、加工、輸出、反饋、再輸入的一個持續的過程模型。 通過持續性的加工處理過程將輸入數據轉換成既定屬性的“產品”。l C2風格通過連接件綁定在一起的按照一組規則運作的并行構件網絡。l C/S風格 基于資源不對等，且為實現共享而提出來的。 有三個主要組成部分：數據庫服務器、客戶應用程序和網絡。 優點： 具有強大的數據操作和事務處理能力，模型思想簡單，易于人們理解和接受。 對于硬件和軟件的變化顯示出極大的適應性和靈活性，而且易于對系統進行擴充和縮小。 將大的應用處理任務分布到許多通過網絡連接的低成本計算機上，以節約大量費用。 缺點： 開發成本較高。 客戶端程序設計復雜。 信息內容和形式單一。

5、用戶界面風格不一，使用繁雜，不利于推廣使用。 軟件移植困難。 軟件維護和升級困難。 新技術不能輕易應用。l 三層C/S風格 優點： 能提高系統和軟件的可維護性和可擴展性。 具有良好的可升級性和開放性。 可以并行開發。 有效地隔離開表示層與數據層，為嚴格的安全管理奠定了堅實的基礎。 缺點： 各層間的通信效率不高。 設計時必須慎重考慮三層間的通信方法、通信頻率及數據量。l B/S風格（瀏覽器/Web服務器/數據庫服務器） 優點： 基于B/S體系結構的軟件，系統安裝、修改和維護全在服務器端解決。用戶在使用系統時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升

6、級。 提供了異種機、異種網、異種應用服務器的聯機、聯網、統一服務的最現實的開放性基礎。 缺點： 缺乏對動態頁面的支持能力，沒有集成有效的數據庫處理功能。 系統擴展能力差，安全性難以控制。 數據查詢等響應速度上，要遠遠低于C/S體系結構。 數據提交一般以頁面為單位，數據的動態交互性不強，不利于在線事務處理(OLTP)應用。第三章 軟件需求與架構（15分）一、 軟件需求的概念需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。二、 軟件需求的流程三、 軟件需求的分類l 按層分： 業務需求：反映組織機構或客戶對系統、產品高層次的目標要求，通常問題定義本身就是

7、業務需求。領域專家 用戶需求：描述用戶使用產品必須要完成什么任務，怎么完成的需求。用戶 系統需求：從系統的角度來說明軟件的需求。開發人員l 按類分： 功能需求：系統必須完成的那些事，即為了向它的用戶提供有用的功能，產品必須執行的動作。 非功能需求：產品必須具備的屬性或品質，如正確性、可靠性、性能、容錯性和可擴展性等。 設計約束：對解決方案的一些約束說明。四、 軟件需求面臨的主要困難l 知識技能問題l 態度問題l 合作關系l 用戶說不清楚需求l 雙方誤解需求l 開發人員寫不好需求文檔l 用戶經常變更需求五、 需求工程l 定義：把所有與需求直接相關的活動通稱為需求工程。l 需求工程創建的第一份文檔

8、是需求陳述，用于在項目開發之初理解客戶的需求。l 分類： 需求開發：目的是通過調查與分析，獲取用戶需求并定義產品需求。包括： 需求調查（需求獲取）的目的是通過各種途徑獲取用戶的需求信息（原始材料），產生需求陳述。 需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類。 需求定義的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生軟件需求規格說明書。 需求管理：目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。包括： 需求確認是指開發方和客戶共同對需求文檔進行評審，雙

9、方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。 需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據需求文檔進行開發。 需求變更控制是指依據“變更申請審批更改重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。l 需求工程結構圖：六、 需求獲取技術l 獲取需求的方法 面談（訪談）：開放式問題和封閉式問題 問卷調查：潛在使用者太多或分布太廣時 會議（需求討論會、重點問題討論會、業務專題討論會、設計專題討論會） 文檔研究 任務示范（觀察）：通過觀察可以獲得第一手的資料。 用例與角色扮演 原型設計（小規模試驗） 研究類似

10、公司l 需求陳述 是一份文檔，陳述用戶對軟件的期望和需要，并對可能的規格要求加以說明。 需求陳述用來明確軟件的用途，它不僅要說明軟件有什么用，還要在宏觀層次上明確軟件應具備的特性。 核心內容 開發該軟件的動機（愿景）是什么？ 該項目的主要涉眾是誰？ 希望該軟件具備哪些主要功能和特性？七、 需求建模l 需求模型分類： 功能模型如UC見下章 業務流程模型如DFD 數據流圖(Data Flow Diagram, DFD)是結構化方法中用于表示系統邏輯模型的一種工具，它以圖形的方式描繪數據在系統中流動和處理的過程。 數據建模模型如ER ER建模用于對數據進行建模（概念模型） 在ER圖中包含三個圖形符號

11、，分別表示：實體（矩形）、屬性（橢圓）、聯系（菱形）八、 編寫軟件需求規格說明書l 需求分析的主要成果：軟件需求規格說明書(Software Requirement Specification, SRS)l 要求的屬性： 正確：最重要的屬性。 清楚：讓人易讀易懂，不在于文檔的厚度。 無二義性：是指每個需求只有唯一的含義。 一致：指軟件需求規格說明書中各個需求之間不會發生矛盾。 必要：其中的各項需求對用戶而言應當都是必要的。 完備：指軟件需求規格說明書中沒有遺漏一些必要的需求。 可實現：其中各項需求對開發方而言應當都是可實現的。 可驗證：其中的各項需求對用戶方而言應當都是可驗證的。 確定優先級：

12、先做優先級高的需求，后做（甚至放棄）優先級低的需求，這樣可以將風險降到最低。l 闡述“做什么”而不是“怎么做”九、 需求確認l 需求確認是指開發方和客戶方共同對軟件需求規格說明書進行評審，雙方對需求達成共識后作出承諾。l 包含兩個重要工作： 需求評審 需求承諾十、 需求跟蹤技術l 需求跟蹤的目的是建立與維護“需求-設計-編程-測試”之間的一致性，確保所有的工作成果符合用戶需求。l 跟蹤有兩種方式： 正向跟蹤。檢查軟件需求規格說明書中的每個需求是否都能在后繼工作成果中找到對應點。 逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在軟件需求規格說明書中找到出處。l 跟蹤矩陣 源跟蹤矩陣（需

13、求與需求來源） 功能跟蹤矩陣（需求與功能） 依賴跟蹤矩陣（一個需求與另一個需求）十一、 需求變更控制l 需求發生變更的起因主要有： 隨著項目的進展，人們（包括開發方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。 市場發生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。l 需求變更控制的目的： 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。l 需求基線 已經通過正式評審和批準的規格說明或產品，它可以作為進一步開發的基礎，并且只有通過正式

14、的變更控制過程才能修改它。 是被明確和固定下來的需求集合，是項目團隊需要在某一特定產品版本中實現的特征和需求集合。第五章 統一建模語言UML（20分）（Unified Modeling Language）（重點看實驗1）一、 用例圖（Use Case Diagram）l 執行者和用例之間的關聯關系（Association）：一根直線來表示l 執行者之間的泛化關系（Generalization）（或繼承關系）用例之間的關系：l 包含關系：描述在多個用例中都有的公共行為，由用例A指向用例B，表示用例A中使用了用例B中的行為或功能，包含關系是通過在依賴關系上應用構造型（衍型）來表示的。l 擴展關系：

15、擴展用例可以在基用例之上添加新的行為，但是基用例必須聲明某些特定的“擴展點”，并且擴展用例只能在這些擴展點上擴展新的行為。擴展關系是通過在依賴關系上應用構造型（衍型）來表示的。l 泛化關系： 當多個用例共同擁有一種類似的結構和行為的時候，可以將它們的共性抽象成為父用例，其他的用例作為泛化關系中的子用例。 在用例的泛化關系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結構、行為和關系。 泛化關系一般很少使用。二、 狀態圖(State Diagram)l 定義：用來描述一個特定對象的所有可能狀態及其引起狀態轉移的事件。 通常用狀態圖來描述單個對象的行為 只有那些具有重要交互行為的類，才

16、會使用狀態圖來描述。 一個狀態圖包括一系列對象的狀態及狀態之間的轉換。l 組成元素： 初始狀態 終止狀態 狀態 轉移 守護條件 事件 動作三、 活動圖（Activity Diagram）l 定義：用來表示系統中各種活動的次序，它的應用非常廣泛，既可用來描述用例的工作流程，也可以用來描述類中某個方法的操作行為。l 作用： 描述業務流程 描述用例路徑 描述方法執行流程（程序流程圖）l 組成元素： 起始活動(Start Activity) 終止活動(End Activity) 活動(Activity) 轉移(Transition)或流(Flow) 決策(Decision) 守護條件(Conditio

17、n) 同步條(Synchronization) 泳道(Swimlane)四、 順序圖l 定義： 用于確認和豐富一個使用情境的邏輯。 將交互關系表現為一個二維圖，縱向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協作中各獨立對象的類元角色，類元角色的活動用生命線表示。l 組成元素： 生命線：用一條縱向虛線表示。 對象：表示為一個矩形，其中對象名稱標有下劃線。 激活：是過程的執行，包括等待過程執行的時間。激活部分替換生命線，使用長條的矩形表示。 消息：對象之間的通信 調用消息：對應于激活，表示它將會激活一個對象。 發送消息：沒有對應激活框，表示它不是一個調用消息，不會引發其他對象的活動。 返回消息

18、自身消息 創建消息 銷毀消息 同步消息 異步消息 交互片段：一個復雜的順序圖可以劃分為幾個小塊，每一個小塊稱為一個交互片段。 alt:多條路徑，條件為真時執行。 opt:任選，僅當條件為真時執行。 par:并行，每一片段都并發執行。 loop:循環，片段可多次執行。 critical:臨界區，只能有一個線程對它立即執行。五、 類圖l 類之間的關系： 關聯關系(Association) 用于表示一類對象與另一類對象之間有聯系 用實線連接有關聯的對象所對應的類 通常將一個類的對象作為另一個類的屬性 自關聯 一些類的屬性對象類型為該類本身 多重性關聯 表示一個類的對象與另一個類的對象連接的個數。 聚

19、合關系(Aggregation) 表示一個整體與部分的關系。 成員類是整體類的一部分，即成員對象是整體對象的一部分，但是成員對象可以脫離整體對象獨立存在。 在UML中，聚合關系用帶空心菱形的直線表示。 組合關系(Composition) 部分和整體具有統一的生存期。 部分對象與整體對象之間具有同生共死的關系。 整體類可以控制成員類的生命周期，即成員類的存在依賴于整體類。 在UML中，組合關系用帶實心菱形的直線表示。 依賴關系(Dependency) 使用關系。 體現在某個類的方法使用另一個類的對象作為參數。 在UML中，依賴關系用帶箭頭的虛線表示。 泛化關系(Generalization) 用

20、于描述父類與子類之間的關系，父類又稱作基類或超類，子類又稱作派生類。 在UML中，泛化關系用帶空心三角形的直線來表示。 接口與實現關系(Realization) 類實現了接口，類中的操作實現了接口中所聲明的操作。 在UML中，類與接口之間的實現關系用帶空心三角形的虛線來表示。六、 包圖l 定義 一種把元素組織到一起的通用機制 用于描述包與包之間的關系 包的圖標是一個帶標簽的文件夾。l 包之間的關系 引入關系： 一個包中的類可以被另一個指定包（以及嵌套于其中的那些包）中的類引用。 在依賴線上增加一個衍型。 泛化關系：表示一個包繼承了另一個包的內容，同時又補充自己增加的內容。 嵌套關系：一個包中可

21、以包含若干個子包，構成了包的嵌套層次結構。七、 組件圖（Component Diagram）l 定義： 顯示編譯、鏈接或執行時組件之間的依賴關系，以及組件的接口和調用關系。 組件就是一個實際文件，可以有以下幾種類型： 源代碼組件：一個源代碼文件或者與一個包對應的若干個源代碼文件。 二進制組件：一個目標碼文件，一個靜態的或者動態的庫文件。 可執行組件：在一臺處理器上可運行的一個可執行的程序單位，即所謂可執行程序。l 組件間關系：泛化關系、依賴關系l 組成元素： 組件：系統中可以替換的部分，一般對應一個實際文件，如exe、jar、dll等文件，它遵循并提供了一組接口的實現。 接口：一組操作的集合，

22、它指明了由類或組件所請求或者所提供的服務。 部件：組件的局部實現。 端口：被封裝的組件與外界的交互點，遵循指定接口的組件通過它來收發消息。 連接件：在特定語境下組件中兩個部件之間或者兩個端口之間的通信關系。 供(Provided)接口與需(Required)接口八、 部署圖(Deployment Diagram)l 定義： 描述系統硬件的物理拓撲結構及在此結構上執行的軟件。 顯示了系統的硬件和安裝在硬件上的軟件，以及用于連接異構計算機之間的中間件。l 組成元素： 節點和連接：節點(Node)代表一個物理設備。在 UML 中，使用一個立方體表示一個節點。節點之間的連線表示系統之間進行交互的通信路

23、徑，在 UML 中被稱為連接。 組件：在部署圖中，組件代表可執行的物理代碼模塊，如一個可執行程序，邏輯上它可以與類或包對應。九、 對象圖l 定義：對象圖是類圖在某一時刻的一個實例。十、 組合結構圖l 定義： 將每一個類放在一個整體中，從類的內部結構來審視一個類。 組合結構圖可用于表示一個類的內部結構。l 組成元素： 部件(Part)：表示被描述事物所擁有的內部成分。 連接件(Connector)：表示部件之間的關系。 端口(Port)：表示部件和外部環境的交互點。十一、 通信圖l 定義： 通信圖強調參與一個交互對象的組織。 它與順序圖是同構圖，也就是它們包含了相同的信息，只是表達方式不同而已，

24、通信圖與順序圖可以相互轉換。 當對象及其連接有利于理解交互時，選擇通信圖；當只需了解交互的次序時，選擇順序圖。l 組成元素：執行者(Actor)、對象(Object)、連接(Link，也稱為鏈)、消息(Message)和守護條件(Condition)。十二、 定時圖l 定義： 采用一種帶數字刻度的時間軸來精確地描述消息的順序 可視化地表示每條生命線的狀態變化 可以把狀態發生變化的時刻以及各個狀態所持續的時間具體地表示出來。十三、 交互概覽圖l 定義： 交互圖與活動圖的混合物，可以把交互概覽圖理解為細化的活動圖，在其中的活動都通過一些小型的順序圖來表示；也可以將其理解為利用標明控制流的活動圖分解

25、過的順序圖。 用于將一些零散的順序圖組織在一起，它采用了活動圖的構造方式，利用了活動圖的各種控制節點，并把活動圖的每個活動結點替換為一個交互或者交互使用。每個交互或者交互使用都使用一個順序圖表示。面向對象設計原則1、 單一職責原則(Single Responsibility Principle, SRP)定義：一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中。Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the

26、 class.2、 開閉原則(Open-Closed Principle, OCP)定義：一個軟件實體應當對擴展開放，對修改關閉。Software entities should be open for extension, but closed for modification.3、 里氏代換原則(Liskov Substitution Principle, LSP)定義：所有引用基類（父類）的地方必須能透明地使用其子類的對象。Functions that use pointers or references to base classes must be able to use objec

27、ts of derived classes without knowing it.4、 依賴倒轉原則(Dependence Inversion Principle, DIP)定義：高層模塊不應該依賴低層模塊，它們都應該依賴抽象。抽象不應該依賴于細節，細節應該依賴于抽象。High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend

28、 upon abstractions.5、 接口隔離原則(Interface Segregation Principle, ISP)定義：客戶端不應該依賴那些它不需要的接口。Clients should not be forced to depend upon interfaces that they do not use.6、 合成復用原則(Composite Reuse Principle, CRP)定義：盡量使用對象組合，而不是繼承來達到復用的目的。Favor composition of objects over inheritance as a reuse mechanism.7、

29、迪米特法則(Law of Demeter, LoD)定義：一個軟件實體應當盡可能少的與其他實體發生相互作用。設計模式（重點看實驗2、3）一、 創建型模式l 簡單工廠模式（Simple Factory） 定義：根據參數的不同返回不同類的實例，專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。 優點： 實現了對責任的分割，它提供了專門的工廠類用于創建對象。 客戶端無須知道所創建的具體產品類的類名，只需要知道具體產品類所對應的參數即可。 通過引入配置文件，可以在不修改任何客戶端代碼的情況下更換和增加新的具體產品類，在一定程度上提高了系統的靈活性。 缺點： 工廠類集中了所有產品創

30、建邏輯，職責過重，不符合單一職責原則。 增加系統中類的個數。 系統擴展困難，不符合開閉原則。 由于使用了靜態工廠方法，造成工廠角色無法形成基于繼承的等級結構。 適用范圍： 工廠類負責創建的對象比較少。 客戶端只知道傳入工廠類的參數，對于如何創建對象不關心。l 工廠方法模式(Factory Method Pattern) 定義： 工廠父類負責定義創建產品對象的公共接口，而工廠子類則負責生成具體的產品對象，這樣做的目的是將產品類的實例化操作延遲到工廠子類中完成，即通過工廠子類來確定究竟應該實例化哪一個具體產品類。 Define an interface for creating an object

31、, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. 優點： 用戶只需要關心所需產品對應的工廠，無須關心創建細節，甚至無須知道具體產品類的類名。 工廠可以自主確定創建何種產品對象，而如何創建這個對象的細節則完全封裝在具體工廠內部。 在系統中加入新產品時，無須修改抽象工廠和抽象產品提供的接口，無須修改客戶端，也無須修改其他的具體工廠和具體產品，而只要添加一個具體工廠和具體產品就可以了。 缺點： 在添加新產品時，需要

32、編寫新的具體產品類，而且還要提供與之對應的具體工廠類，系統中類的個數將成對增加，在一定程度上增加了系統的復雜度。 增加了系統的抽象性和理解難度。 適用范圍： 一個類不知道它所需要的對象的類。 一個類通過其子類來指定創建哪個對象。 將創建對象的任務委托給多個工廠子類中的某一個，客戶端在使用時可以無須關心是哪一個工廠子類創建產品子類，需要時再動態指定。l 抽象工廠模式(Abstract Factory Pattern) 定義： 提供一個創建一系列相關或相互依賴對象的接口，而無須指定它們具體的類。 Provide an interface for creating families of relat

33、ed or dependent objects without specifying their concrete classes. 優點： 隔離了具體類的生成。 可以實現高內聚低耦合的設計目的。 能夠保證客戶端始終只使用同一個產品族中的對象。 增加新的具體工廠和產品族很方便，無須修改已有系統，符合“開閉原則”。 缺點： 難以擴展抽象工廠來生產新種類的產品。 開閉原則的傾斜性（增加新的工廠和產品族容易，增加新的產品等級結構麻煩） 適用范圍： 一個系統不應當依賴于產品類實例如何被創建、組合和表達的細節。 系統中有多于一個的產品族，而每次只使用其中某一產品族。 屬于同一個產品族的產品將在一起使用。

34、 系統提供一個產品類的庫，所有的產品以同樣的接口出現，從而使客戶端不依賴于具體實現。l 單例模式(Singleton Pattern) 定義： 確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例，這個類稱為單例類，它提供全局訪問的方法。 Ensure a class has only one instance and provide a global point of access to it. 優點： 提供了對唯一實例的受控訪問。 可以節約系統資源 允許可變數目的實例。 缺點： 單例類的擴展有很大的困難。 單例類的職責過重。 濫用單例將帶來一些負面問題。 適用范圍： 系統只需要

35、一個實例對象。 客戶調用類的單個實例只允許使用一個公共訪問點。二、 結構型模式l 適配器模式(Adapter Pattern) 定義： 將一個接口轉換成客戶希望的另一個接口，適配器模式使接口不兼容的那些類可以一起工作，其別名為包裝器(Wrapper)。適配器模式既可以作為類結構型模式，也可以作為對象結構型模式。 Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldnt otherwise because of in

36、compatible interfaces.類適配器對象適配器 優點： 將目標類和適配者類解耦。 增加了類的透明性和復用性。 靈活性和擴展性都非常好。 缺點： 類適配器模式的缺點是適配器類在很多編程語言中不能同時適配多個適配者類。 對象適配器模式的缺點是很難置換適配者類的方法。 適用范圍： 系統需要使用現有的類，而這些類的接口不符合系統的需要。 想要建立一個可以重復使用的類，用于與一些彼此之間沒有太大關聯的一些類一起工作。l 橋接模式(Bridge Pattern) 定義： 將抽象部分與它的實現部分分離，使它們都可以獨立地變化。 Decouple an abstraction from its

37、 implementation so that the two can vary independently. 優點： 分離抽象接口及其實現部分。 橋接模式是比多繼承方案更好的解決方法。 提高了系統的可擴充性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統。 實現細節對客戶透明，可以對用戶隱藏實現細節。 缺點： 會增加系統的理解與設計難度。 其使用范圍具有一定的局限性。 適用范圍： 需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承聯系。 抽象化角色和實現化角色可以以繼承的方式獨立擴展而互不影響。 一個類存在兩個獨立變化的維度，且這兩個維度都需要進

38、行擴展。 設計要求需要獨立管理抽象化角色和具體化角色。 不希望使用繼承或因為多層次繼承導致系統類的個數急劇增加的系統。l 組合模式(Composite Pattern) 定義：組合多個對象形成樹形結構以表示“整體-部分”的結構層次。組合模式對單個對象（即葉子對象）和組合對象（即容器對象）的使用具有一致性。Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objec

39、ts uniformly. 優點： 可以清楚地定義分層次的復雜對象。 客戶端可以一致的使用組合結構或其中單個對象。 更容易在組合體內加入對象構件。 缺點： 設計變得更加抽象。 很難對容器中的構件類型進行限制。 適用范圍： 需要表示一個對象整體或部分層次。 客戶端可以針對抽象構件編程，無須關心對象層次結構的細節。 對象的結構是動態的并且復雜程度不一樣，但客戶需要一致地處理它們。l 外觀模式(Facade Pattern) 定義： 外部與一個子系統的通信必須通過一個統一的外觀對象進行，為子系統中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。 Prov

40、ide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. 優點： 對客戶屏蔽子系統組件，減少了客戶處理的對象數目并使得子系統使用起來更加容易。 實現了子系統與客戶之間的松耦合關系。 降低了大型軟件系統中的編譯依賴性，并簡化了系統在不同平臺之間的移植過程。 只是提供了一個訪問子系統的統一入口，并不影響用戶直接使用子系統類。 缺點： 不能很好地限制客戶使用子系統類。 在不引

41、入抽象外觀類的情況下，增加新的子系統可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”。 適用范圍： 當要為一個復雜子系統提供一個簡單接口時可以使用外觀模式。 客戶程序與多個子系統之間存在很大的依賴性。 使用外觀模式定義系統中每一層的入口，層與層之間不直接產生聯系，而通過外觀類建立聯系，降低層之間的耦合度。l 代理模式(Proxy Pattern) 定義： 給某一個對象提供一個代理，并由代理對象控制對原對象的引用。 Provide a surrogate or placeholder for another object to control access to it. 優點： 協調調用者

42、和被調用者。 遠程代理使得客戶端可以訪問在遠程機器上的對象。 虛擬代理通過使用一個小對象來代表一個大對象，可以減少系統資源的消耗，對系統進行優化并提高運行速度。 保護代理可以控制對真實對象的使用權限。 缺點： 有些類型的代理模式可能會造成請求的處理速度變慢。 實現代理模式需要額外的工作，有些代理模式的實現非常復雜。 適用范圍： 遠程(Remote)代理。 虛擬(Virtual)代理。 Copy-on-Write代理。 保護(Protect or Access)代理。 緩沖(Cache)代理。 防火墻(Firewall)代理。 同步化(Synchronization)代理。 智能引用(Smart

43、 Reference)代理。三、 行為型模式l 職責鏈模式(Chain of Responsibility Pattern) 定義：避免請求發送者與接收者耦合在一起，讓多個對象都有可能接收請求，將這些對象連接成一條鏈，并且沿著這條鏈傳遞請求，直到有對象處理它為止。Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request a

44、long the chain until an object handles it. 優點： 降低耦合度。 可簡化對象的相互連接。 增強給對象指派職責的靈活性。 增加新的請求處理類很方便。 缺點： 不能保證請求一定被接收。 系統性能將受到一定影響，而且在進行代碼調試時不太方便；可能會造成循環調用。 適用范圍： 有多個對象可以處理同一個請求，具體哪個對象處理該請求由運行時刻自動確定。 在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。 可動態指定一組對象處理請求。l 命令模式(Command Pattern) 定義： 將一個請求封裝為一個對象，從而使我們可用不同的請求對客戶進行參數化；對請求排隊或者記錄請求日志，以及支持可撤銷的操作。 Encapsulate a request as an object, thereby letting you parameterize clients with di