軟件架構(gòu)與設計模式

1、軟件架構(gòu)與設計模式曾令秋 博士、副教授2013年6月l 軟件架構(gòu)n 軟件架構(gòu)定義n 架構(gòu)設計方法與過程n 軟件架構(gòu)的設計要點l 模式簡介n 模式的定義n 模式的分類l 常用模式n 從混沌到結(jié)構(gòu)n 分布式基礎設施n 事件多路分離和分派n 接口分割n 組件分割l 典型面向服務的架構(gòu)SOA2目錄1. 軟件架構(gòu)1.1 架構(gòu)定義l軟件體系結(jié)構(gòu)通常被稱為架構(gòu)，指可以預制和可重構(gòu)的軟件框架結(jié)構(gòu)，Garlan & Shaw模型的基本思想是：軟件體系結(jié)構(gòu)=構(gòu)件(component)、連接件(connector)和約束(constrain)：n 構(gòu)件可以是一組代碼，如程序的模塊；也可以是一個獨立的程序；n

2、 連接件可以是過程調(diào)用、管道、遠程過程調(diào)用(RPC)等，用于表示構(gòu)件之間的相互作用；n 約束一般為對象連接時的規(guī)則，或指明構(gòu)件連接的形式和條件，例如，上層構(gòu)件可要求下層構(gòu)件的服務，反之不行；兩對象不得遞規(guī)地發(fā)送消息；代碼復制遷移的一致性約束；什么條件下此種連接無效等。4架構(gòu)定義l 軟件架構(gòu)不僅僅注重軟件本身的結(jié)構(gòu)和行為, 還注重其他特性:使用, 功能性, 性能, 彈性, 重用, 可理解性, 經(jīng)濟和技術(shù)的限制及權(quán)衡。5例: ACE的分層架構(gòu)6架構(gòu)的范圍l 軟件架構(gòu)本門課程的主關注點。l 硬件架構(gòu)包括CPU, 內(nèi)存，硬盤，周邊設備例如打印機，與連接這些元素的部分。l 組織架構(gòu)是一些關于商業(yè)進程，組

3、織結(jié)構(gòu)，規(guī)則和職責，與組織核心能力的部分。l 信息架構(gòu)包含組織好的信息結(jié)構(gòu)。l 軟件架構(gòu)、硬件架構(gòu)、組織架構(gòu)和信息架構(gòu)是全部系統(tǒng)架構(gòu)的子結(jié)構(gòu)。l 企業(yè)架構(gòu)與系統(tǒng)架構(gòu)很相似，包括硬件，軟件，人員等。7l 企業(yè)架構(gòu)師EA (Enterprise Architect) 的職責是決定整個公司的技術(shù)路線和技術(shù)發(fā)展方向。蓋茨給自己的Title是首席軟件架構(gòu)師，實際上就是EA角色;l 基礎結(jié)構(gòu)架構(gòu)師IA (Infrastructure Architect) 的工作是提煉和優(yōu)化技術(shù)方面積累和沉淀形成的基礎性的、公共的、可復用的框架和組件，這些是技術(shù)型公司傳承下來的最寶貴的財富;l 特定技術(shù)架構(gòu)師TSA (Te

4、chnology-Specific Architect)主要從事類似安全架構(gòu)、存儲架構(gòu)等專項技術(shù)的規(guī)劃和設計工作;l 解決方案架構(gòu)師SA (Solution Architect)的工作則專于解決方案的規(guī)劃和設計，所謂解決方案，就是把產(chǎn)品、技術(shù)或理論，不斷地進行組合，來創(chuàng)造出滿足用戶需求的選擇。 軟件架構(gòu)師基本上是EA+TSA+IA,是程序員向上發(fā)展的道路,系統(tǒng)架構(gòu)師實際上是SA+TSA，更著力于綜合運用已有的產(chǎn)品和技術(shù)，來實現(xiàn)客戶期望的需求。架構(gòu)師分類81.2 架構(gòu)設計基本過程概念化階段概念化階段分析階段分析階段架構(gòu)設計階段架構(gòu)設計階段并行開發(fā)和測試階段并行開發(fā)和測試階段驗收與交互階段驗收與交

5、互階段愿景需求架構(gòu)可執(zhí)行系統(tǒng)交付的系統(tǒng)9架構(gòu)設計基本過程分析階段需求分析領域建模確定關鍵需求概念性架構(gòu)設計細化架構(gòu)驗證架構(gòu)架構(gòu)設計階段10軟件需求l 需求n 系統(tǒng)必須滿足的情況或提供的能力. 可以直接來自客戶需要, 也可以來自合同,標準,規(guī)范或其他有正規(guī)約束力的文檔軟件需求軟件需求功能需求功能需求非功能需求非功能需求質(zhì)量屬性質(zhì)量屬性約束約束運行期質(zhì)量屬性運行期質(zhì)量屬性開發(fā)期質(zhì)量屬性開發(fā)期質(zhì)量屬性11軟件系統(tǒng)架構(gòu)要素l 它是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。一個系統(tǒng)通常是由組件組成的，而這些組件如何形成、相互之間如何發(fā)生作用，則是關于這個系統(tǒng)本身結(jié)構(gòu)的重要信息。系統(tǒng)包括架構(gòu)組件、連接器、

6、任務流。架構(gòu)組件是組成系統(tǒng)的核心“磚瓦”，而連接器則描述這些 組件之間通訊的路徑、通訊的機制、通訊的預期結(jié)果，任務流則描述系統(tǒng)如何使用這些組件和連接器完成某一項需求。l 它是建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。這樣的決定必定是有關系統(tǒng)設計成敗的最重要決定，必須經(jīng)過非常慎重的研究和考察。在決定時，要考慮獨特的架構(gòu)風格和恰當?shù)募軜?gòu)模式。1.3 軟件架構(gòu)的設計要素12軟件架構(gòu)的目標l 可靠性（Reliable）。軟件系統(tǒng)對于用戶的商業(yè)經(jīng)營和管理來說極為重要，因此軟件系統(tǒng)必須非?？煽?。l 安全性（Secure）。軟件系統(tǒng)所承擔的交易的商業(yè)價值極高，系統(tǒng)的安全性非 常重要

7、。l 可擴展性（Scalable）。軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能，才能適應用戶的市場擴展得可能性。 l 可定制化（Customizable）。同樣的一套軟件，可以根據(jù)客戶群的不同和市場需求的變化進行調(diào)整。13軟件架構(gòu)的目標l 可延伸性（Extensible）。在新技術(shù)出現(xiàn)的時候，一個軟件系統(tǒng)應當允許導入新技術(shù)，從而對現(xiàn)有系統(tǒng)進行功能和性能的擴展；l 可維護性（Maintainable）。軟件系統(tǒng)的維護包括兩方面：1。排除現(xiàn)有的錯 誤，2。將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個易于維護的系統(tǒng)可以有效 地降低技術(shù)支持的花費l 客戶體驗（Customer E

8、xperience）。軟件系統(tǒng)必須易于使用。l 市場時機（Time to Market）。軟件用戶要面臨同業(yè)競爭，軟件提供商也要面 臨同業(yè)競爭。以最快的速度爭奪市場先機非常重要。14軟件架構(gòu)的種類軟件系統(tǒng)的邏輯架構(gòu)圖邏輯架構(gòu)：軟件系統(tǒng)中元件之間的關系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件，等等15軟件架構(gòu)的種類物理架構(gòu)：軟件元件是怎樣放到硬件上的軟件系統(tǒng)的物理架構(gòu)圖16軟件架構(gòu)的種類l 系統(tǒng)架構(gòu)系統(tǒng)架構(gòu)：系統(tǒng)的非功能性特征，如可擴展性、可靠性、強壯性、靈活性、 性能等。系統(tǒng)架構(gòu)的設計要求架構(gòu)師具備軟件和硬件的功能和性能的過硬知識，是架 構(gòu)設計工作中最為困難的工作。架構(gòu)的兩要素：元件

9、劃分和設計決定。 l 元件劃分元件劃分 一個軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以 及這些元件如何為整個系統(tǒng)的可擴展性、可靠性、強壯性、靈活性、性能等 做出貢獻，是非常重要的信息。l 設計決定設計決定 進行軟件設計需要做出的決定中，必然會包括邏輯結(jié)構(gòu)、物理結(jié)構(gòu)，以及它 們?nèi)绾斡绊懙较到y(tǒng)的所有非功能性特征。這些決定中會有很多是一旦作出， 就很難更改的。17視圖可以表示系統(tǒng)的整體設計，但構(gòu)架與以下幾個具體方面相關：l模型的結(jié)構(gòu)，即組織模式，例如分層。 l基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。l幾個關鍵場景，它們表示了整個系統(tǒng)的主要控制流程。 l記

10、錄模塊度、可選特征、產(chǎn)品線狀況的服務。 l構(gòu)架視圖在本質(zhì)上是整體設計的抽象或簡化，它們通過舍棄具體細節(jié)來突出重要的特征。在考慮以下方面時，這些特征非常重要： n系統(tǒng)演進，即進入下一個開發(fā)周期。 n在產(chǎn)品線環(huán)境下復用構(gòu)架或構(gòu)架的一部分。 n評估補充質(zhì)量，例如性能、可用性、可移植性和安全性。 n向團隊或分包商分配開發(fā)工作。 n決定是否包括市售構(gòu)件。 n插入范圍更廣的系統(tǒng)。 構(gòu)架重點 182. 模式 Pattern19模式簡介l要素n背景 contextn問題 problemn作用力 (約束) forcen解決方案 solution202.1 模式定義lPOSA1的定義:nA pattern for

11、 software architecture describes a particular recurring design problem that arise in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by its constituent components, their relationships, and the ways in which they collaborate.21模式的

12、特性l 最佳實踐的記錄n 更高一級的抽象n 設計的公共詞匯表n 記錄軟件架構(gòu)的工具n 支持具有良好屬性的軟件構(gòu)建n 與項目細節(jié), 實現(xiàn)方法, 編程語言無關22例子：簡單的模式Explicit Interface (顯式接口)l 背景n 軟件架構(gòu)工作的主要關注點之一: 有效恰當?shù)乇硎鼋M件接口 問題一個組件代表一個自含的功能單位及其發(fā)布的使用契約. 客戶可以使用它來建立自己的功能, 但是直接訪問組件的完全實現(xiàn), 則會導致客戶依賴組件的內(nèi)部表示, 最終增加了應用程序內(nèi)部的耦合度 作用力(force)客戶只能依賴組件發(fā)布的接口, 對實現(xiàn)的修改不能影響客戶客戶不倚賴組件的地理位置組件提供的方法對客戶有意

13、義, 能有效正確使用將組件接口的聲明與實現(xiàn)分離, 只對客戶曝露組件接口, 同時隱藏實現(xiàn)和位置23Method _Bmethod _AExplicit Interface (顯式接口)method _B _impmethod _A_ imp客戶客戶接口接口實現(xiàn)實現(xiàn)多態(tài)分派組件組件24誤解與陷阱l 企圖將所有軟件開發(fā)活動和工件變成模式n 企圖將每個新穎的和復雜的設計貼上模式的標簽n 將模式看成一些固定不變的事物: 如特定的類配置n 將模式看作編碼指南n 有限或誤解的模式詞匯導致對給定問題使用了錯誤的模式n 企望機械應用模式就可以得到精致的架構(gòu)25誤解與陷阱n 企圖在需要新思想的軟件開發(fā)中使用現(xiàn)成模

14、式n 對模式如何起作用以及怎樣起作用企望過高n 企圖完全基于自動化工具使用模式n 將模式當作組件的簡單集合n 認為基于模式的設計排斥或替代重構(gòu)262.2 模式分類l 按粒度分類n 架構(gòu), 設計, 慣用法l 按效果好壞分類n 模式, 反模式l 按問題域(使用目的)分類 (以分布式計算為例)n 從混沌到結(jié)構(gòu)n 分布式基礎設施n 事件多路分離和分派n 接口分割n 組件分割27n 應用程序控制n 并發(fā)n 同步n 對象交互n 適配與擴展n 模態(tài)(modal)行為n 資源管理 (對象生命周期管理)n 數(shù)據(jù)庫訪問3. 常用模式28常用模式l 從混沌到結(jié)構(gòu)l 分布式基礎設施l 事件多路分離和分派l 接口分割l

15、 組件分割l 應用程序控制l 并發(fā)l 同步l 對象交互l 適配與擴展l 模態(tài)(modal)行為l 資源管理l 數(shù)據(jù)庫訪問293.1 從混沌到結(jié)構(gòu)303.1 從混沌到結(jié)構(gòu)l從混沌到結(jié)構(gòu)n將需求和約束轉(zhuǎn)換為粗粒度的軟件結(jié)構(gòu) 各部分定義清晰,可操作 抽象與劃分, 忽略細節(jié)n關注 性能, 持續(xù)可用性 可擴展性, 可維護性 支持變化313.1 從混沌到結(jié)構(gòu)l 領域建模n滿足應用領域的功能性需求, 同時適應變化 功能屬性 業(yè)務流程 業(yè)務算法選擇Domain Model32Domain Model (領域模型)l 背景n 為應用建立初始結(jié)構(gòu)l 問題需求和約束只是隱含了功能, 但還不能為應用提供直接具體的開發(fā)

16、結(jié)構(gòu)對系統(tǒng)范圍和應用領域缺乏精確和合理的洞見, 會使實現(xiàn)成為一團爛泥,難于理解, 難于開發(fā), 不易交付l 作用力(force)需求列表只是應用的問題域, 而不是解域, 需要映射為軟件實體建立一個模型建立一個模型, 定義系統(tǒng)的業(yè)務職責范圍以及可能的變化定義系統(tǒng)的業(yè)務職責范圍以及可能的變化:模型元素是對應用領域的概念抽象模型元素是對應用領域的概念抽象, 它們的角色和交互反它們的角色和交互反映了應用領域的工作流映了應用領域的工作流33從混沌到結(jié)構(gòu)l 分解領域模型n 應用與環(huán)境怎樣交互?n 應用怎樣處理數(shù)據(jù)?n 應用支持什么變化?n 應用的預期生命周期如何?34Domain Model (領域模型)內(nèi)

17、部劃分數(shù)據(jù)流處理數(shù)據(jù)驅(qū)動處理系統(tǒng)演進用戶界面變化功能變化遠程通信Domain ModelDomain ObjectPipes and FiltersShared RepositoryBlackboardLayersDatabaseAccess LayerModel-View-ControllerPresentationAbstraction-ControlMicrokernelReflectionBrokerMessagingPublisher-Subscriber35Layers (分層)l 背景n 必須支持系統(tǒng)的不同部分獨立開發(fā)和演進l 問題l 由于受系統(tǒng)大小, 上市時間等需求約束, 需要

18、考慮系統(tǒng)不同部分的獨立開發(fā)和演進l 如果系統(tǒng)架構(gòu)不能清晰合理分離關注點, 則各部分的交互得不到很好的支持, 也不能獨立開發(fā)l 作用力(force)l 如何尋求平衡,能夠l 合理劃分系統(tǒng), 使各部分可以獨立開發(fā)和部署l 不陷于細節(jié)的泥淖對開發(fā)中的系統(tǒng)定義一個或多個層級對開發(fā)中的系統(tǒng)定義一個或多個層級, 每一層都具有清晰每一層都具有清晰特定的職責特定的職責36Layers (分層)Function 1Function 1Function 1Function AFunction BFunction CFunction XFunction YFunction Z接口接口實現(xiàn)實現(xiàn)Layer 3Layer

19、 2Layer 1典型應用典型應用: TCP/IP等通信協(xié)議等通信協(xié)議37Layers (分層)l可沿不同維度指定分層的準則n 抽象, 粒度, 硬件距離, 變化速度l層數(shù)適當l注意層中每個內(nèi)聚的職責l層內(nèi)如何隔離變化l控制和數(shù)據(jù)流可以在層間雙向流動l層間依賴關系是單向向下的: 下層不能依賴上層的功能38Layers :問題 層內(nèi)分解接口和實現(xiàn)分離 連接借口和實現(xiàn)自底向上層間通信Layers什么模式可以提供解決方案什么模式可以提供解決方案?39Model-View-Controller (MVC)l 背景n 要考慮應用的用戶界面比領域功能變化快l 問題l 用戶界面比應用的核心功能變化快, 但界面

20、的變化不能對核心功能造成不良影響l 作用力l 用戶界面的改變應該容易, 并局限于系統(tǒng)界面部分l 界面顯示的內(nèi)容要與內(nèi)部狀態(tài)一致，能立即響應內(nèi)部狀態(tài)的變化l 對支持多種skin外觀的系統(tǒng)，每種skin的變化快慢不一樣將交互式系統(tǒng)劃分為解耦的三部分：處理，輸入和輸將交互式系統(tǒng)劃分為解耦的三部分：處理，輸入和輸出通過某種變化傳播機制保證三部分狀態(tài)的一致出通過某種變化傳播機制保證三部分狀態(tài)的一致40Model-View-Controller (MVC)displayupdatedo somethingupdateget datafunction 2function1data 1data 2data 3

21、notifyUser InterfaceModelViewController1. invoke2. modify3. start change notification4. notify5. updatestateApplicationFunctionality41Presentation-Abstraction-Control (PAC)l 背景n 有時要考慮應用的不同功能職責需要不同范式的用戶界面l 問題n 通過一種界面如表單,菜單,對話框等, 應用程序就可以提供人機交互, 但是有時候某些應用程序需要對不同的功能提供不同范式的界面, 以達到最佳的操作性l 作用力(force)n 比如在機

22、器人控制系統(tǒng)中, 定義某項任務和控制機器人完成該任務需要不同的用戶界面, 但是必須保證所有的功能及其對應的用戶界面內(nèi)聚一致n 某一界面的改變不能影響其對應的功能和其他功能-界面n 某一功能實現(xiàn)的改變也不能影響其對應的界面和其他的功能-界面 將交互式應用劃分為解耦的代理將交互式應用劃分為解耦的代理agents層級結(jié)構(gòu)層級結(jié)構(gòu): 一個頂層根代理一個頂層根代理, 幾個中間級代理幾個中間級代理,以及許多底層代理以及許多底層代理. 每個代理完成應用的某項功能每個代理完成應用的某項功能, 并提供對應的用戶界面并提供對應的用戶界面42Presentation-Abstraction-Control (PAC

23、)do somethingdisplaymediatefunction_2function_1PresentationControlAbstractiondo somethingdisplaymediatefunction_2function_1do somethingdisplaymediatefunction_2function_1do somethingdisplaymediatefunction_2function_1do somethingdisplaymediatefunction_2function_1協(xié)調(diào)協(xié)調(diào)協(xié)調(diào)協(xié)調(diào)協(xié)調(diào)協(xié)調(diào)協(xié)調(diào)協(xié)調(diào)頂層頂層 PAC Agent中間層中間層 PA

24、C Agent底層底層PAC Agent43MVC and PAC: 問題用戶界面分離視圖種類控制器種類請求處理用戶界面分離變化傳播模型劃分數(shù)據(jù)交換OS/庫獨立變化傳播代理劃分數(shù)據(jù)交換請求路由控制設計子系統(tǒng)設計Model-ViewControllerPresentationAbstractionControlDomain Model什么模式可以提供解決方案什么模式可以提供解決方案?44Microkernel (微內(nèi)核)l 背景n 設計支持不同部署環(huán)境下功能的可伸縮性和的適應性l 問題n 某些系統(tǒng)有多個版本, 每個版本或者提供不同的功能集, 或者在某一方面與前一版本不同. 但是所有的版本應該基于

25、共同的架構(gòu)和核心功能l 作用力(force)n 避免架構(gòu)在不同版本間產(chǎn)生漂移, 使共享功能的開發(fā)和維護代價降到最小n 應用的版本升級不需要修改系統(tǒng), 或使修改降到最小n 方便地提供針對不同界面, 不同平臺的版本, 以滿足客戶的環(huán)境提供一個公用的最小的核心架構(gòu)提供一個公用的最小的核心架構(gòu). 應用的不同版本通過一應用的不同版本通過一種即插即用的基礎設施種即插即用的基礎設施, 在此架構(gòu)上進行擴展在此架構(gòu)上進行擴展. 45Microkernel (微內(nèi)核)route requestregister_ svrunregister_ svrfunction_1function_2function_3dis

26、playdo somethingfunction_2function_1function_3External Server (GUI)External Server (API)MicrokernelInternal ServerSystemUser46Microkernel: 問題標準和可選功能分離微內(nèi)核以及內(nèi)部服務器劃分微內(nèi)核以及內(nèi)部服務器劃分數(shù)據(jù)交換外部服務器設計微內(nèi)核配置請求路由MicrokernelLayers什么模式可以提供解決方案什么模式可以提供解決方案?47Reflection (反射)l 背景n 提供一種設計, 為預期之外變化的演進和集成做準備 問題對長生命周期應用, 支持變化

27、是可持續(xù)演進架構(gòu)的關鍵. 但是通常很難預測什么會變化以及什么時候發(fā)生變化. 作用力(force)變化可能在任何時候發(fā)生變化可能在任何尺度上發(fā)生對維護者隱藏變化的復雜性, 提供統(tǒng)一的機制支持各種變化將屬性將屬性, 應用的結(jié)構(gòu)、行為以及狀態(tài)等的易變方面抽象為應用的結(jié)構(gòu)、行為以及狀態(tài)等的易變方面抽象為一組元對象一組元對象. 使用兩層架構(gòu)分離元對象和核心應用邏輯使用兩層架構(gòu)分離元對象和核心應用邏輯: 元層次包含元對象元層次包含元對象, 基本層包含應用邏輯基本層包含應用邏輯. 48Reflection (反射)Userconfigureaspect configurepropertyproperty_1

28、Metalobject ProtocolMaintaineraspect_2Metalobjectsdo something function_1User Interfacefunction_1CoreApplicationLogicusesusesMetalLevelBaseLevel49Reflection: 問題監(jiān)管控制與應用功能分離基本層以及元層的劃分元層訪問元對象生命周期管理ReflectionDomain Model什么模式可以提供解決方案什么模式可以提供解決方案?50Pipes and Filters (管道-過濾器)l 背景n 提供一種設計, 使應用適合處理數(shù)據(jù)流 問題某些應用

29、需要處理數(shù)據(jù)流:輸入數(shù)據(jù)逐級變換為輸出數(shù)據(jù)流使用通常的請求應答式結(jié)構(gòu)不可行，為此要建立一種數(shù)據(jù)流模型. 作用力(force)系統(tǒng)的各部分對數(shù)據(jù)流執(zhí)行明確的不同的動作有些時候需要顯式訪問中間數(shù)據(jù)結(jié)果數(shù)據(jù)流模型應該支持增量式讀寫和處理持續(xù)時間長的處理不應成為性能瓶頸將應用任務劃分為幾個自含的數(shù)據(jù)處理步驟將應用任務劃分為幾個自含的數(shù)據(jù)處理步驟,這些步驟通這些步驟通過其間的數(shù)據(jù)緩沖區(qū)連接成一個數(shù)據(jù)處理管道過其間的數(shù)據(jù)緩沖區(qū)連接成一個數(shù)據(jù)處理管道.51inputPipes and Filters (管道-過濾器)bufferinputbufferinputInput DeviceOutput Devic

30、eFilter 1Pipe 1Filter 2Filter 2Pipe N-1Filter N52Pipes and Filters :問題層間通過數(shù)據(jù)流交互管道以及過濾器的劃分遠程通信數(shù)據(jù)交換Pipes and FiltersDomain Model什么模式可以提供解決方案什么模式可以提供解決方案?53Shared Repository (共享倉庫)l 背景n 提供一種設計, 使應用的各部分操作一組共享數(shù)據(jù), 并通過共享數(shù)據(jù)進行協(xié)調(diào) 問題某些應用本質(zhì)上使數(shù)據(jù)驅(qū)動的: 組件之間的交互不是通過特定的業(yè)務流程, 而是依賴其所處理的數(shù)據(jù). 即便如此, 仍然需要一種機制來控制這種交互. 作用力(for

31、ce)比如網(wǎng)絡管理和控制系統(tǒng), 它們需要操作大量現(xiàn)場數(shù)據(jù). 其核心職責如監(jiān)控,報警,匯報等相互獨立, 是數(shù)據(jù)狀態(tài)決定了任務流程及其交互. 將這些任務直接聯(lián)系起來會導致硬編碼的業(yè)務流程為所有數(shù)據(jù)維持一個中心倉庫為所有數(shù)據(jù)維持一個中心倉庫, 以供各功能組件共享以供各功能組件共享. 數(shù)數(shù)據(jù)的可用性據(jù)的可用性,質(zhì)量以及狀態(tài)等觸發(fā)和協(xié)調(diào)應用的控制流質(zhì)量以及狀態(tài)等觸發(fā)和協(xié)調(diào)應用的控制流.54Shared Repository (共享倉庫)Application Componentsfunction_1function_2function_3function_4Shared RepositoryOperat

32、es on55Blackboard (黑板)l 背景n 提供一種設計, 使應用在沒有確定性解決方案的時候可以完成任務 問題某些任務沒有確定性算法, 但是試誤技術(shù)足夠勝任, 因此需要開發(fā)針對這種任務的軟件產(chǎn)品. 作用力(force)輸入的數(shù)據(jù)模糊不精確需要探索各種方案路徑, 每個中間步驟都可能產(chǎn)生可選結(jié)果, 通常不知道最佳解在合理的時間內(nèi), 計算出有價值的解決方案運用啟發(fā)式計算運用啟發(fā)式計算, 通過多個具有確定性算法的組件通過多個具有確定性算法的組件, 對假對假定的中間解決方案逐步改進定的中間解決方案逐步改進.56Blackboard (黑板)checkactivatecheckactivate

33、checkactivateIntermediate SolutionHypothesis 1-Intermediate SolutionHypothesis 2-Intermediate SolutionHypothesis 3Knowledge SourcesBlackboardrunControl.1.確定最佳的知識源, 以修改黑板中的數(shù)據(jù)2. 激活選中的知識源, 使之修改黑板中的數(shù)據(jù)57Blackboard , Shared Repository : 問題分離數(shù)據(jù)與功能分離數(shù)據(jù)與功能傳播變化線程安全數(shù)據(jù)訪問功能劃分數(shù)據(jù)訪問數(shù)據(jù)交換數(shù)據(jù)交換數(shù)據(jù)訪問功能劃分Shared Rep

34、ositoryBlackboardDomain Model什么模式可以提供解決方案什么模式可以提供解決方案?58Domain Object (領域?qū)ο?l 背景n 所有設計的關鍵: 分離應用職責, 每個職責應自我包含, 內(nèi)聚 問題組成軟件的各部分具有復雜的相互作用, 未經(jīng)仔細設計會導致系統(tǒng)結(jié)構(gòu)極其復雜 作用力(force)關注點分離, 適當合理的劃分系統(tǒng)不同部分的實現(xiàn)和交互必須有效且高效, 特別是關鍵屬性如性能, 錯誤處理以及安全性等將每個不同的功能封裝進一個自我包含的構(gòu)成塊將每個不同的功能封裝進一個自我包含的構(gòu)成塊Domain Object (領域?qū)ο箢I域?qū)ο?中中59Domain Obje

35、ct (領域?qū)ο?Function AFunction BFunction CFunction ZDomain Object 1Function XFunction YDomain Object 2Domain Object 3Domain Object 4Domain Object InterfaceDomain Object Implementation60Domain Object (領域?qū)ο?分離接口和實現(xiàn)內(nèi)部劃分內(nèi)部劃分通用領域?qū)ο筮B接接口和實現(xiàn)生命周期控制領域?qū)ο笈渲肈omain ObjectDomain ModelLayersModel-View-ControllerPresen

36、tationAbstractionControlMicrokernelReflectionPipes and FiltersShared RepositoryBlackboard什么模式可以提供解決方案什么模式可以提供解決方案?613.2 分布式基礎設施62分布式基礎設施l 分布式基礎設施軟件是一種中間件 (middleware)n 應用程序之下, 操作系統(tǒng)和網(wǎng)絡之上n 屏蔽來自不同操作系統(tǒng)和網(wǎng)絡的固有復雜性和偶發(fā)復雜性 固有復雜性: 選擇合適的通信機制, 并設計良好的協(xié)議來有效使用這些機制 設計合理的網(wǎng)絡服務, 以有效利用現(xiàn)有計算資源, 并降低將來的維護成本 有效使用并發(fā)機制, 使系統(tǒng)獲得可

37、預計的, 可靠的高性能 管理和配置服務, 以獲得最大程度的系統(tǒng)可用性和靈活性63偶發(fā)復雜性:缺乏類型安全, 可移植, 可擴充的原始OS API算法分解的廣泛使用, 無謂造成網(wǎng)絡應用程序在維護和擴充上的困難網(wǎng)絡應用中, 核心概念和功能的不斷發(fā)現(xiàn)和創(chuàng)造, 造成軟件生命周期的成本無謂地居高不下l 有各種中間件可供選擇n CORBA, .Net Remoting, the Microsoft Communication Framework, JMSl 了解這些中間件使用的設計模式, 有助于選擇正確的中間件l 這些中間件使用了三種基本的通信方式: messaging, publish/subscribe

38、, remote method invocation , 基本上對應三種模式分布式基礎設施64分布式基礎設施模式模式通信方式通信方式通信關系通信關系組件依賴性組件依賴性Broker (代理者)遠程方法調(diào)用一對一組件接口Messaging (消息傳遞)消息多對一通訊終點, 消息格式Publisher-Subscriber (發(fā)布者-訂閱者)事件一對多事件格式65Messaging (消息傳遞)l 背景n 需要一個通信的基礎設施, 將獨立開發(fā)的服務組成一個統(tǒng)一的系統(tǒng) 問題某些分布式系統(tǒng)是由獨立開發(fā)的服務組成, 這些服務必須可靠地交互, 但又不能導致過緊的依賴關系 作用力(force)集成現(xiàn)有的、獨

39、立的特定服務以構(gòu)成企業(yè)級解決方案被集成的服務需要可靠地協(xié)調(diào)工作, 但這些服務是獨立開發(fā)的, 并不知道彼此的功能接口每個服務可能要被多個集成環(huán)境使用, 服務對不同的集成環(huán)境不能具有排他性 將服務通過一個消息總線連接起來將服務通過一個消息總線連接起來, 并通過它異步傳輸數(shù)據(jù)并通過它異步傳輸數(shù)據(jù)消息消息. 對消息編碼對消息編碼, 使發(fā)送者和接受者能夠可靠地通信使發(fā)送者和接受者能夠可靠地通信, 而不而不需要知道數(shù)據(jù)的所有靜態(tài)類型信息需要知道數(shù)據(jù)的所有靜態(tài)類型信息.66Messaging (消息傳遞)Message BusService 1Service 2Service 3Service 4data

40、msg 1data msg 2data msg3data msg 4關鍵應用關鍵應用: Enterprise Application Integration, Service Oriented Architecture67Messaging (消息傳遞)Publisher-Subscriber (發(fā)布者-訂閱者):問題進程間通信進程間通信數(shù)據(jù)轉(zhuǎn)移數(shù)據(jù)封裝數(shù)據(jù)格式轉(zhuǎn)換數(shù)據(jù)路由錯誤通知MessagingPublisher-SubscriberDomain Model組件連接數(shù)據(jù)格式轉(zhuǎn)換數(shù)據(jù)路由錯誤通知事件封裝事件轉(zhuǎn)移組件連接事件過濾什么模式可以提供解決方案什么模式可以提供解決方案?68Publis

41、her-Subscriber (發(fā)布者-訂閱者)l 背景n 需要一種通信基礎設施, 當某事件發(fā)生時, 系統(tǒng)中感興趣的組件可以彼此通告 問題某些分布式系統(tǒng)是由松散耦合,基本獨立的組件構(gòu)成. 如果這種系統(tǒng)需要在各組件間傳播信息, 則需要某種機制來通知各組件有關系統(tǒng)狀態(tài)的變化, 或其他事件, 這些事件會影響各組件本身的計算或組件間的協(xié)調(diào)工作 作用力(force)通告機制不能造成各組件的耦合過于緊密接收事件的那些組件只知道系統(tǒng)中有某個組件處于特定狀態(tài), 但不關心具體是哪個組件處于該狀態(tài)散布事件的組件也不關心哪個組件會接收它 各組件不知道彼此的位置定義一種變化傳播基礎設施定義一種變化傳播基礎設施, 發(fā)布

42、者發(fā)布者(publisher)通過它發(fā)通過它發(fā)布事件布事件, 其他發(fā)布者可能對該事件包含的信息感興趣其他發(fā)布者可能對該事件包含的信息感興趣. 事事件發(fā)生時要告知對該事件感興趣的訂閱者件發(fā)生時要告知對該事件感興趣的訂閱者(subscriber).69Change Propagation InfrastructurePublisher 1Subscriber 2Subscriber 3Publisher 2State changeState changeState changeState changePublisher-Subscriber (發(fā)布者-訂閱者)應用應用: CORBA Notific

43、ation Service70Messaging (消息傳遞)Publisher-Subscriber (發(fā)布者-訂閱者):問題進程間通信進程間通信數(shù)據(jù)轉(zhuǎn)移數(shù)據(jù)封裝數(shù)據(jù)格式轉(zhuǎn)換數(shù)據(jù)路由錯誤通知MessagingPublisher-SubscriberDomain Model組件連接數(shù)據(jù)格式轉(zhuǎn)換數(shù)據(jù)路由錯誤通知事件封裝事件轉(zhuǎn)移組件連接事件過濾什么模式可以提供解決方案什么模式可以提供解決方案?71Broker (代理者)l 背景n 需要一種通信基礎設施, 以之屏蔽組件位置和進程間通信的復雜性 問題分布式應用要面對許多單進程應用未有的挑戰(zhàn), 但是應用不應該自己直接去處理這些挑戰(zhàn). 應用應該使用模塊化

44、的編程模型, 力求簡化, 以屏蔽網(wǎng)絡連接和空間位置等細節(jié) 作用力(force)將不同語言寫的各類服務移植到不同的操作系統(tǒng)平臺, 是一項極其復雜的任務在何處以什么方式部署服務, 也是一項復雜費力的事情服務之間通過方法調(diào)用的協(xié)作應該以一種與位置無關的方式進行使用代理者使用代理者(broker)聯(lián)盟封裝分布式系統(tǒng)通信基礎設施的聯(lián)盟封裝分布式系統(tǒng)通信基礎設施的細節(jié)細節(jié), 并與應用系統(tǒng)的功能分離并與應用系統(tǒng)的功能分離. 要定義一種基于組件的編要定義一種基于組件的編程模型程模型, 以使客戶應用調(diào)用遠程服務的方法時就象在本地調(diào)以使客戶應用調(diào)用遠程服務的方法時就象在本地調(diào)用一樣用一樣.72method_1me

45、thod_2Broker (代理者)sendreceiverequestdiscoverreceivesendinvokeregistermethod_1method_2clientClientProxyClient-sideBrokerServer-sideBrokerApplicationComponentDiscover client proxyRegister componentNetwork73Broker (代理者): 問題進程間通信BrokerDomain Object請求分派請求分派代理者訪問組件訪問組件訪問發(fā)布-訂閱通信組件創(chuàng)建內(nèi)部劃分OS 抽象發(fā)出請求接收請求封裝請求錯誤通

46、知代理者配置組件發(fā)現(xiàn)什么模式可以提供解決方案什么模式可以提供解決方案?743.3 事件多路分離和分派l 分布式計算的核心: 響應和處理來自網(wǎng)絡的事件事件處理的復雜性:事件異步到達多個事件同時到達事件到達順序不確定多種類型的事件隱藏事件多路分離和分派的復雜性事件處理軟件通常采用Layers架構(gòu)模式 事件源:sockets 事件多路分離器: WaitForMultipleObjects, select, et al 事件處理器 +應用程序75事件多路分離和分派l模式提供高效，可擴展，可復用解決方案 Reactor(反應器)模式 對事件執(zhí)行同步多路分離并分派給應用程序 Proactor(前攝器)模式

47、 對事件執(zhí)行異步多路分離和分派, 可獲得并發(fā)處理的好處并規(guī)避其缺點 Acceptor-Connector(接收器-連接器)模式 將連接和初始化工作與其后的一般事件處理分離 Asynchronous Completion Token(異步完成令牌)模式 對異步服務請求的響應提供高效的多路分離和處理76Reactor (反應器)l 背景n 開發(fā)事件驅(qū)動應用時, 需要將事件的檢測, 多路分離和分派等與處理時間短的服務分離 問題事件驅(qū)動軟件接受來自多個源的服務請求事件, 并對之實行多路分離, 分派給事件處理器 做進一步處理. 多個事件可能同時到達, 但是為簡化軟件開發(fā), 這些事件需要順序處理, 并同步

48、返回處理結(jié)果. 作用力(force)高效靈活處理多個源的并發(fā)事件容易集成新的或改進的事件處理器提供一種事件處理基礎設施提供一種事件處理基礎設施, 它可以同時等待多個源的服務它可以同時等待多個源的服務請求事件請求事件, 但是每次只分離一個事件但是每次只分離一個事件, 并將該事件分派給相并將該事件分派給相應的事件處理器去執(zhí)行對應的服務應的事件處理器去執(zhí)行對應的服務77event loopReactor (反應器)A clientdemux eventevent _loop()begin # run an infinite event loop for (ever) # block waiting

49、for events to occur event = demux _events(); # dispatch the event handler = identify _handler (event); handler. handle _event (event); rofendhandle eventhandle eventhandle eventEvent handlersStart event processingReactorOperating SystemSend service request event132478Proactor (前攝器)l 背景n 開發(fā)事件驅(qū)動應用時, 需

50、要將事件的檢測, 多路分離和分派等與處理時間長的服務分離 問題為獲得高性能和高吞吐量, 事件驅(qū)動軟件需要同時處理多個事件, 但是又不希望使用多線程 作用力(force)對服務請求的處理不能延遲太久性能和吞吐量要最大化容易集成新的和改進的組件將應用程序功能分為異步操作和完成處理器兩部分將應用程序功能分為異步操作和完成處理器兩部分. 異步操作針對事件異步操作針對事件源執(zhí)行某些活動源執(zhí)行某些活動, 而完成處理器使用異步操作的結(jié)果而完成處理器使用異步操作的結(jié)果. 異步操作和完成異步操作和完成處理器共同實現(xiàn)應用的服務邏輯處理器共同實現(xiàn)應用的服務邏輯. 異步操作由操作系統(tǒng)執(zhí)行異步操作由操作系統(tǒng)執(zhí)行, 而完

51、成處而完成處理器在應用的控制線程中執(zhí)行理器在應用的控制線程中執(zhí)行79event loopProactor (前攝器)A clientdemux eventhandle _event (Event event)begin # Process the received event if (event. type=Request) # read request asynchronously # and return control async _read(); elseif (event. Type =READ_COMPLETE) # Process event, deliver results #

52、 asynchronously, and return control process_ data(); async _write(); fiendhandle eventhandle eventCompletion handlersStart event processingProactorOperating SystemSend service request event1324async writeasync read80Reactor (反應器), Proactor (前攝器):問題ReactorProactorServer Request HandlerClient RequestH

53、andler同步事件處理異步事件處理異步事件處理同步事件處理實現(xiàn)的變化實現(xiàn)的變化事件處理器類型事件處理器類型事件源封裝事件源封裝并發(fā)事件處理并發(fā)事件處理并發(fā)事件處理事件處理器分派完成處理器分派什么模式可以提供解什么模式可以提供解決方案決方案?81Acceptor-Connector(接受器-連接器)l 背景n 在面向連接的網(wǎng)絡系統(tǒng)中實現(xiàn)事件處理器時, 建立連接以及初始化事件處理器等基本活動需要與處理應用特定服務的功能分離 問題網(wǎng)絡系統(tǒng)中對等的事件處理器在執(zhí)行其服務功能前需要先建立連接并初始化, 建立連接以及初始化代碼與其服務功能基本無關 作用力(force)事件處理器服務的變化比連接建立和初始

54、化策略的變化快事件處理器可能動態(tài)改變其在連接中的角色在網(wǎng)絡系統(tǒng)中在網(wǎng)絡系統(tǒng)中, 將對等事件處理器的連接和初始化與之后執(zhí)將對等事件處理器的連接和初始化與之后執(zhí)行的服務解耦行的服務解耦82connect134serviceinitAcceptor-Connector (接受器-連接器)acceptserviceinitconnectoracceptorService handlerConnect mePass connection3Pass connectionPerform work2AcceptconnectionService handlerA peer componentAnother p

55、eer component83Acceptor-Connector (接受器-連接器):問題Acceptor-ConnectorServer Request HandlerClient RequestHandlerProactor事件處理器類型Reactor事件處理器類型完成處理器類型創(chuàng)建服務處理器封裝IPC機制管理事件處理器連接管理的變化并發(fā)服務處理器84Asynchronous Completion Token (異步完成令牌)l 背景n 在使用異步通信的系統(tǒng)中, 需要高效地多路分離和處理對異步服務請求的響應 問題客戶端異步調(diào)用服務, 其響應通過完成事件返回, 并在客戶端處理. 客戶端調(diào)用

56、服務后不能被阻塞, 客戶端在完成事件到達時的狀態(tài)與調(diào)用服務時的狀態(tài)不同 作用力(force)客戶需要在合適的背景下處理異步響應客戶判斷如何處理異步響應的時間要盡可能短異步響應到達的順序與請求發(fā)起的順序可能不同客戶在發(fā)起每個異步服務請求的同時客戶在發(fā)起每個異步服務請求的同時, 傳輸一個異步完成令牌傳輸一個異步完成令牌, 該令牌該令牌包含足夠的信息包含足夠的信息, 可以讓客戶知道如何處理服務完成后的返回結(jié)果可以讓客戶知道如何處理服務完成后的返回結(jié)果85dispatch134dispatchserviceAsynchronous Completion Token (異步完成令牌)Client2pro

57、cess resultasync_ operationSend requestReturn responseDispatch resultProcess resultACTService86Asynchronous Completion Token (異步完成令牌): 問題AsynchronousCompletion TokenFuture未來通告完成處理器通告ProactorACT管理873.4 接口分割l 組件接口要告知客戶其職責, 提供的服務, 以及使用契約l 利于客戶正確有效地與之合作l 設計高質(zhì)量的組件接口, 需要解決的問題 組件的職責與契約規(guī)范 質(zhì)量屬性 描述性和簡單性 松耦合和穩(wěn)

58、定性 組件的分布性 組件及其客戶的異質(zhì)性 88接口分割l 相關模式n Explicit Interface (顯式接口)n Extension Interface (擴展接口)n Introspective Interface (內(nèi)省接口)n Dynamic Invocation Interface (動態(tài)調(diào)用接口)n Business Delegate (業(yè)務代理)n Proxy (代理)n Faade (外觀)n Combined Method (組合方法)n Iterator (迭代器)n Enumeration Method (枚舉方法)n Batch Method (批處理方法)89

59、Explicit Interface (顯式接口)l 背景n 軟件架構(gòu)工作的主要關注點之一: 有效恰當?shù)乇硎鼋M件接口 問題一個組件代表一個自含的功能單位及其發(fā)布的使用契約. 客戶可以使用它來建立自己的功能, 但是直接訪問組件的完全實現(xiàn), 則會導致客戶依賴組件的內(nèi)部表示, 最終增加了應用程序內(nèi)部的耦合度 作用力(force)客戶只能依賴組件發(fā)布的接口, 對實現(xiàn)的修改不能影響客戶客戶不倚賴組件的地理位置組件提供的方法對客戶有意義, 能有效正確使用將組件接口的聲明與實現(xiàn)分離將組件接口的聲明與實現(xiàn)分離, 只對客戶曝露組件借口只對客戶曝露組件借口, 同同時隱藏實現(xiàn)和位置時隱藏實現(xiàn)和位置90Method

60、_Bmethod _AExplicit Interface(顯式接口)method _B _impmethod _A_ impClientInterfaceImplementationPolymorphic dispatchComponent91Explicit Interface (顯式接口): 問題Explicit InterfaceDomain ObjectReactorProactorCommandInterceptorChain of ResponsibilityIteratorBridgeCompositeObject AdapterLayersDecoratorStrategyObser