體系結(jié)構復習資料

1、名詞解釋：設計的5個準則設計復雜度=事物復雜度+載體與事物的適配復雜度設計重在內(nèi)部結(jié)構，不是外在表現(xiàn)內(nèi)部結(jié)構：為了實現(xiàn)外部的功能，進行的內(nèi)部的安排，主要關注質(zhì)量外部表現(xiàn)：對外的功能（能力），滿足職責（二玉答疑）外部表現(xiàn)是對外表現(xiàn)的能力，外部表現(xiàn)是為了滿足職責；內(nèi)部結(jié)構則是為了完成的質(zhì)量，通過羅列方式完成外部表現(xiàn)的內(nèi)部結(jié)構不是好的內(nèi)部結(jié)構。設計的目的就是為了保證質(zhì)量，因此其重在內(nèi)部結(jié)構。只有高層設計良好，底層設計才可能良好The better early design, the easier detailed design will be高層設計的質(zhì)量要到最底層才能準確驗證層次間是迭代而非瀑布，

2、線性關系不要在完成高層設計之后再進行底層設計要盡早有可驗證的原型只有寫完測試代碼之后，才能算是完成了設計4+1 ViewLogical ViewEnd-user FunctionalityImplementation ViewProgrammers Configuration management Pocess ViewPerformanceScalabilityThroughput System integratorsDeployment ViewSystem topologyCommunication ProvisioningSystem engineeringConceptualPhys

3、icalUse Case ViewIBM提出的一種multi-point的體系結(jié)構模型，共有5個viewpoint，關注點在設計上，特別適用于迭代設計過程，由4個View（邏輯、開發(fā)、進程和物理）以及1個特殊viewpoint場景來描述體系結(jié)構，不同的涉眾可選取自己關系的view來理解。邏輯視圖為面向?qū)ο蟮姆纸?，由關鍵的抽象部件連接件以及配置組成，考慮功能需求，針對終端用戶；進程視圖為進程分解，有多個層次，包含一個進程網(wǎng)絡，軟件分解為一組可執(zhí)行的工作單元，考慮非功能需求，針對集成人員；開發(fā)視圖為子系統(tǒng)分解，是產(chǎn)品線的基礎，有模塊和子系統(tǒng)圖組成，考慮軟件模塊的組織層次、管理、重用以及工具，層次式

4、風格，針對編程人員和軟件管理者；物理視圖將軟件映射到硬件，包含網(wǎng)絡、task以及對象映射為節(jié)點時的拓撲結(jié)構和通信，考慮與硬件相關的肺功能呢個需求，針對系統(tǒng)工程師；場景將上面的視圖元素組織在一起，通過一小組重要的場景來表現(xiàn)各視圖的工作，考慮系統(tǒng)一致性和驗證，針對其他視圖和評估者等所有用戶。邏輯視圖：面向?qū)ο蠓纸?，系統(tǒng)將問題域分解成一系列關鍵的抽象，以對象或類的形式表現(xiàn)。view：最終用戶consider：功能需求不僅是功能性分析，還可以識別系統(tǒng)不同部分之間共同的機制和設計元素。進程視圖：進程分解view：Integratorconsider：非功能需求（并發(fā)、性能、scalability）sty

5、le：幾個風格都可以滿足這個視圖使用多層次的抽象，最高時進程的邏輯網(wǎng)；系統(tǒng)被分成幾個相互獨立的任務：主要任務是體系結(jié)構相關的任務、次要任務是幫助類的任務重點關注系統(tǒng)運行起來之后的特征開發(fā)視圖：子系統(tǒng)分解viewer：程序員和軟件經(jīng)理consider：軟件模塊組織（層次結(jié)構、軟件管理、復用、工具約束等）style：分層風格物理視圖：將軟件映射到硬件上viewer：系統(tǒng)集成師consider：非功能需求（可用性、可靠性（容錯性）、性能（吞吐量）、scalcbility）場景：將所有放在一起viewer：其他視圖所有人和評價者consider：四個視圖間的一致性、可驗證性體系結(jié)構設計階段幫助架構師；

6、幫助解釋和驗證文檔OO協(xié)作與協(xié)作設計Whats CollaborationAn application can be broken down into a set of many different behaviors.Each such behavior is implemented by a distinct collaboration between the objects of the applicationEvery collaboration, no matter how small or large, always implements a behavior of the app

7、licationImagine an object-oriented application as a network of objects connected by relationships. Collaborations are the patterns of messages that play through that network in pursuit of a particular behavior. The collaboration is distributed across the network of objects, and so does not exist in

8、any one placeCollaboration DesignIdentify collaboration:system behavior from use-casefrom software architecture design(Module interface and Process communication)Design collaboration(of system behaviors: control structures):two ways:DispersedandCentralizedDispersed: Logics of a system behavior is sp

9、read widely through the objects networkCentralized: One extra controller record all logics of a system behaviorControl Styles:Dispersed,Centralized,DelegatedCentralized Control:Easy to find where the decision are madeEasy to see how decision are made and to alter the decision-making processControlle

10、rs may become bloated (large, complex and hard to understand, maintain, test)Controller may treat other components as data repositoriesIncrease coupling destroys information hidingDelegated Control:Controller are coupled to fewer components, reducing couplingInformation is hidden bettereasier to div

11、ide into layersDelegated control is thepreferred controlstyleDispersed Control:having many components holding little data and having few responsibilitieshard to understand the flow of controlunable to do much on their own, increasing couplinghard to hide informationcohesion is usually poorfew modula

12、rity principles can be satisfiedHeuristics:Avoid interaction designs where most messages orginate from a single componentKeep component smallMake sure operational responsibilities are not all assigned to just a few componentsMake sure operational responsibilities are consistent with data responsibil

13、itiesAbstract tasks in multi-levelHave components delegate as many low-level tasks as possibleAvoid interactions that require each component to send many messagesOO職責與職責分配在面向?qū)ο蟮南到y(tǒng)中是由多個對象組成的，這些對象必需能夠向其它對象發(fā)送消息或操作，這就是對象的交互和職責分配職責是什么？職責是從需求來的，由體系結(jié)構加工后，處理得到職責分配注意什么？職責分配是為了滿足需求，模塊化，信息隱藏，GRASPGRASP模式（或其中之一

14、）是General Responsibility Assignment Software Patterns的縮寫，這些模式不是設計模式，而是對象設計的基本原則，關注對象設計最重要的方面分配職責給類，并不強調(diào)體系結(jié)構的設計； HYPERLINK l _GRASP模式 詳見5.2軟件設計的審美標準有哪些？列舉已知的軟件設計方法與技術（至少5種: 模塊化（簡潔性。），信息隱藏，設計模式，）并說明它們促進了哪些審美標準的達成？審美標準是什么簡潔性：模塊化一致性（概念完整性）：體系結(jié)構的風格，模塊化堅固性（高質(zhì)量）：最重要的是體現(xiàn)在體系結(jié)構上，設計模式所要解決的問題，模塊化易復用易修改易讀易理解易維護可

15、靠性 (availability 可以正常工作, reliability 故障和故障修復)性能，質(zhì)量相關易開發(fā)列舉已知的設計方法與技術（至少5中），他們促進了那些審美標準的達成模塊化：促進了結(jié)構一致性，堅固性（易維護，易復用等），促進了簡潔性信息隱藏：促進了簡潔性，堅固性（易維護，易復用），破壞了簡潔性設計模式：促進了堅固性（易復用，易維護等等），一致性？體系結(jié)構風格：促進了一致性，堅固性職責分配（GRASP）：促進了堅固性，一致性協(xié)作設計：促進了堅固性，一致性？設計的層次性（2,3必有一個）高層設計、中層設計和低層設計各自的出發(fā)點、主要關注因素（即哪些審美要素）、主要方法與技術和最終制品低層

16、設計（代碼設計）出發(fā)點：程序語言所提供的數(shù)據(jù)結(jié)構等東西太少了為了解決類型的適配的問題將基本的語言單位（類型與語句），組織起來，建立高質(zhì)量的 數(shù)據(jù)結(jié)構+算法 屏蔽程序中復雜數(shù)據(jù)結(jié)構與算法的實現(xiàn)細節(jié)對一個方法/函數(shù)的內(nèi)部代碼進行設計 關注點：質(zhì)量：數(shù)據(jù)結(jié)構合理易用，算法可靠、高效、易讀 評價：易讀，易維護簡潔性部分堅固性，包括堅固性的，易讀，易維護，數(shù)據(jù)結(jié)構易用，算法可靠、易讀主要技術：防御式編程Defensive Programming斷言式編程Assertive programmingDesign-by-Contract測試驅(qū)動開發(fā)Test-Driven programming異常處理Erro

17、r handling, exception handling配置式編程Configuring Programming表驅(qū)動編程Table-driven Programming基于狀態(tài)機編程State-machine based Programming前面四個是關于可靠性的，后面三個是關于數(shù)據(jù)結(jié)構帶來易讀性內(nèi)部結(jié)構是算法和數(shù)據(jù)類型，外在表現(xiàn)是抽象數(shù)據(jù)類型最終制品：源程序，中層，底層共享了詳細設計文檔中層設計（模塊與類結(jié)構設計）出發(fā)點：模塊劃分 將系統(tǒng)分成簡單片段 片段有名字，可以被反復使用 名字和使用方法稱為模塊的抽象與接口 模塊內(nèi)部的程序片段為精華與實現(xiàn) 模塊劃分隱藏一些程序片段（數(shù)據(jù)結(jié)構+算

18、法）的細節(jié)，暴露接口于外界 關注點：簡潔性（易開發(fā)，易修改，易復用）可觀察性看上去“顯然是正確的”（易開發(fā)，易調(diào)試，易復用）目標完全獨立理解 使用與復用 開發(fā) 修改 評價質(zhì)量標準：模塊化信息隱藏OO設計原則 問題困難：程序片段不可能完全獨立方法：實現(xiàn)盡可能的獨立（低耦合，高內(nèi)聚）模塊化信息隱藏面向?qū)ο笞罱K制品：類和模塊高層設計（體系結(jié)構）出發(fā)點：主要為了解決整體功能組織的問題組織的時候設計和功能大型軟件開發(fā)的一個根本不同是它更關注如何將大批獨立模塊組織形成一個“系統(tǒng)”，也就是說更重視系統(tǒng)的總體組織 關注點:總體結(jié)構 質(zhì)量屬性 方法：場景驅(qū)動體系結(jié)構風格為什么要高層設計:名稱匹配, 導入導出（問

19、題）Inside 接口（獨立，區(qū)別對待）詳細設計的不足載體適配（無法描述可靠性，性能）無法實現(xiàn)交互信息本地化（信息隱藏的局限性）無法有效抽象部件的整體特性接口定義缺乏結(jié)構性（交互的規(guī)則，如果A調(diào)用是B必須調(diào)用）不能有效適應大型軟件的特殊開發(fā)方法最終制品：體系結(jié)構的設計軟件體系結(jié)構風格描述或比較相關風格 對給定場景，判斷需要使用的風格軟件體系結(jié)構風格定義：用結(jié)構化組織的模式來定義一系列系統(tǒng)，并定義組件和連接件的vocabulary以及其如何結(jié)合的限制；描述一類體系結(jié)構或重要的體系結(jié)構片段，實踐過程中被重復發(fā)現(xiàn)，是一組緊密相關的設計決策，具有允許重用的已知屬性不同組件的風格：對象（設計模式）、模塊

20、、進程、物理單元模塊風格：進程風格模塊風格描述點：簡要規(guī)則流程敘述，組件連接件和限制是什么，優(yōu)缺點，適用系統(tǒng)；比較點：算法變化，數(shù)據(jù)表示變化，附加特性（功能），性能空間時間，復用Call-and-ReturnMain-program-and-subroutine：層次式分解程序，單線程控制，子系統(tǒng)結(jié)構隱藏，每個組件接受父組件的控制；組件是過程、函數(shù)或者模塊，連接件是他們之間的調(diào)用，限制是控制始于調(diào)用層次的頂層然后向下移動；過程清晰易于理解，正確性控制強，變更和復用困難，可能是公共耦合，適用順行系統(tǒng)和正確性攸關系統(tǒng)Object-oriented（數(shù)據(jù)抽象）：通過封裝數(shù)據(jù)表示和相關的操作幫助提高修

21、改性，對象保證自己數(shù)據(jù)表示的完整性，每個對象都是匿名的代理，只能通過固定格式的過程調(diào)用來使用對象；組件是對象或模塊，連接件是函數(shù)或調(diào)用；在不影響使用者的情況下可以修改實現(xiàn)，系統(tǒng)分解為一系列匿名代理，但一個對象要與另一個對象交互必須知道對方的標識符，并且會有副作用問題，從而產(chǎn)生不可預期的操作，適用于有一個中心問題并須保護相關信息（數(shù)據(jù)）的應用Pipe and Filter：每個過濾器處理數(shù)據(jù)然后傳遞給下一個過濾器，每當有數(shù)據(jù)需要處理時過濾器都會運行，數(shù)據(jù)共享嚴格控制在管道的傳遞上；組件是過濾器，連接件是管道，限制是過濾器之間不共享狀態(tài)，過濾器不知道上下游的標識符，輸出正確性不依賴于過濾器順序；適

22、易于理解，支持重用，維護和增強容易，允許特定種類的專門分析，支持并發(fā)，交互不佳，需要額外空間，解析增加性能流失和過濾器編寫的復雜性，用于在有序數(shù)據(jù)上定義一系列獨立計算的應用；特化形式Pipelines（線性拓撲）和Batch Sequential（pipeline退化版）Implicit Invocation：組件發(fā)起一至多個事件，也可以注冊某個方法來響應某個事件，當時間發(fā)生時，連接件調(diào)用所有注冊該事件的方法，封裝共享數(shù)據(jù)，避免暴露存儲格式給計算模塊，數(shù)據(jù)更改時計算被隱式調(diào)用，典型應用事件；組件是agent（對象，過程，進程），連接件是廣播中介（事件處理器），限制是事件發(fā)起者不知道事件影響那些

23、組件，無法假設處理順序以及處理結(jié)果；復用支持極佳，系統(tǒng)演化容易，但難以保證正確性和完整性，且測試和診斷困難，適用于擁有松散耦合的組件集、每個都可能執(zhí)行一些使其他組件進行處理的操作的應用上面四種比較Main-program-and-subroutineObject-OrientedPipe and FilterImplicit InvocationChange in algorithmBadMediumGoodGoodChange in data representationBadGoodMediumMediumChang in functionsMediumMediumGoodMediumMa

24、ke system interactiveMediumMediumBadMediumSpace performanceGoodGoodBadGoodTime performanceBadBadMediumGoodReuse componentsBadMediumGoodGoodRepository（Blackboard）：組件是一個表示系統(tǒng)正確狀態(tài)的中心數(shù)據(jù)結(jié)構，一組操作中心數(shù)據(jù)結(jié)構的獨立組件（agent），連接件是過程調(diào)用和直接內(nèi)存存取，限制是所有agent應當獨立并且依賴共享數(shù)據(jù)，檢查數(shù)據(jù)狀態(tài)并做出反應（Pull vs. Push）；存儲大量數(shù)據(jù)的方便方式，集中化管理，必須先對數(shù)據(jù)模型達成

25、一致，中心數(shù)據(jù)體會成為瓶頸，數(shù)據(jù)演化昂貴，適用于中心問題是建立擴充和維護阻隔復雜中心信息體的應用Repository vs. Blackboard：前者使用pull模型，易于實現(xiàn)但客戶端復雜并且需要輪詢數(shù)據(jù)；后者使用push模型，客戶端編程簡化但需要復雜的結(jié)構Layered：組件是一組過程或?qū)ο?，連接件是過程調(diào)用和限制可見性的方法調(diào)用，限制是系統(tǒng)組織成層次結(jié)構，每層給上層提供服務并作為下層的client，躍層是不允許的；設計基于不同層次的抽象，更改一層最多再影響兩層，同層可互換提供服務增強復用，但不是所有系統(tǒng)都有明確的層次結(jié)構，并且性能可能會需要躍層訪問以及實現(xiàn)部分訪問，適用于擁有明確的服務種

26、類從而可層次式組織的應用，例如層次式通信協(xié)議和操作系統(tǒng)，特例是異常一般是無層次直接交互的Model-View-Controller：model子系統(tǒng)設計為不依賴任何view子系統(tǒng)和controller子系統(tǒng)，其狀態(tài)的變化會傳遞給view子系統(tǒng)；model組件負責維護領域知識和通知view變化，view組件負責顯示信息并傳遞用戶指示給controller，controller負責更改model狀態(tài)和選擇響應view，連接件是過程調(diào)用、消息、事件、直接內(nèi)存存?。辉试S一個model上建立多個獨立view，view可同步，可“插拔”（易于修改）的view和controller，但增加了復雜性，view

27、獲取數(shù)據(jù)效率不高，與流行UI工具不十分兼容，適用于UI修改容易并且可以運行時修改、UI的修改不應該影響功能部分設計和代碼的應用比較進程風格Point-to-point：消息被發(fā)送給一個唯一可確定的接收者，空間上雙方需要互相了解，時間上必須是同步激活Publish-Subscribe：多個應用接受相同消息，發(fā)布者和訂閱者松散耦合，消息傳送基于事件發(fā)布，事件類型層次化組織；組件是發(fā)布者和訂閱者，連接件是事件Router復雜并且負責失??；物理單元風格Client-Server：分布式系統(tǒng)的特例；組件是client，連接件是RPC-based interaction protocols；server不

28、知道client的數(shù)量或identities，而client知道server的identityThree-Tier（N-Tier）：表示層（接口層或前端）、應用業(yè)務邏輯層、數(shù)據(jù)層（存儲層或后端），像是在client/server間再加一層，提供了用戶接口和業(yè)務邏輯的分離Peer-to-Peer：client/server的泛化，更難實現(xiàn)；組件是匿名的既作為client又作為server，連接件是同步或異步消息傳遞但一般不共享內(nèi)存，交互的拓撲結(jié)構差異性和動態(tài)性較大Distributed SystemDistributed Objects（middleware）Distributed Resour

29、ces（http）Distributed Services（web service）比較詳解1以模塊為對象的體系結(jié)構風格Main Program and Subroutine Style結(jié)構：Components: 程序，功能，模塊Connectors: 函數(shù)間的調(diào)用特點：控制從頂層開始，逐漸細化至最低層，不允許同級和向上調(diào)用層次化分解：先聲明后定義單線程控制隱含“子系統(tǒng)結(jié)構“，分解結(jié)構，子路徑屬于上個模塊的聚合但又無法調(diào)用回去層次化推理：只要子過程正確，即可保證整個鍋程正確，串行調(diào)度，正確性極好優(yōu)點：處理清晰，容易理解可強正確性控制，部分正確即可得整體正確缺點：不利于修改復用；處理不好會變成

30、公共耦合使用情景：順序系統(tǒng)，對系統(tǒng)正確性要求高的系統(tǒng)Object-Oriented Style結(jié)構：Components: 對象或模塊Connectors: 函數(shù)或調(diào)用特點：所有數(shù)據(jù)信息封裝與隱藏每個對象都是自治的，互不干涉，彼此獨立對象有義務維護自己封裝信息的一致性和完整性所有component平等，可以任意調(diào)用，無層次限制優(yōu)點：因為對象對其它對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其它的對象。只要不改變接口，相互修改性較好。數(shù)據(jù)表示和相關操作封裝為抽象數(shù)據(jù)類型設計者可將一些數(shù)據(jù)存取操作的問題分解成一些自治的交互代理程序的集合。 每部分獨立，每部分正確性易于確定，方法在對象中被

31、調(diào)用，可以將問題分解為交互的代理缺點：為了使一個對象和另一個對象通過過程調(diào)用等進行交互，必須知道對象的接口標識，有依賴性。只要一個對象的標識改變了，就必須修改所有其他明確調(diào)用它的對象。必須修改所有顯式調(diào)用它的其它對象，并消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的。有重入問題。使用情景：核心問題是識別并保護相關信息體的程序Pipe and Filter Architectural Style結(jié)構：Components: Filter,提供數(shù)據(jù)局部轉(zhuǎn)化，并且使用增量處理，已使得輸出數(shù)據(jù)再所有輸入數(shù)據(jù)完成之前產(chǎn)生Conn

32、ectors: Pipe，作為流傳輸?shù)耐ǖ?，把一個Filter的輸出傳到另一個的輸入特點：Filter之間不共享狀態(tài)和數(shù)據(jù)Filter不知道它上下游Filter，只知道自己的功能單個filter不需依賴要知道其他filter才能構建的假設整個網(wǎng)絡的正確性不應該依賴于Filter的排列順序完全獨立，可以隨時增減filter，可以并行開發(fā)優(yōu)點：使得軟構件具有良好的隱蔽性和高內(nèi)聚、低耦合的特點；易于理解，允許設計者將整個系統(tǒng)的輸入/輸出行為看成是多個過濾器的行為的簡單合成；支持軟件重用。只要提供適合在兩個過濾器之間傳送的數(shù)據(jù)，任何兩個過濾器都可被連接起來；系統(tǒng)維護和增強系統(tǒng)性能簡單。對順序無依賴性，

33、新的過濾器可以添加到現(xiàn)有系統(tǒng)中來；舊的可以被改進的過濾器替換掉；允許對一些如吞吐量、死鎖等屬性的特殊分析；支持并行執(zhí)行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務并行執(zhí)行。缺點：通常導致進程成為批處理的結(jié)構。這是因為雖然過濾器可增量式地處理數(shù)據(jù)，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉(zhuǎn)換。傳輸數(shù)據(jù)需要額外的空間。不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。各部分獨立，難以全局控制。因為在數(shù)據(jù)傳輸處理的不一致性，每個過濾器都增加了打包，封裝和分解數(shù)據(jù)的工作，這樣就導致了系統(tǒng)性能下降，并增加了編寫過濾器的復雜性。使用情景：對有序數(shù)據(jù)進行

34、一系列獨立運算處理的程序，如Shell，Compiler特殊：流水線和批處理Implicit invocation (Event based ) Style結(jié)構：Components: agent代理程序(對象、程序、進程)Connectors: broadcast mediums廣播媒介(事件處理器)特點：一個組件可聲明事件，另一些組件以函數(shù)去注冊事件，當事件觸發(fā)時，廣播媒介根據(jù)注冊分發(fā)事件，Connector自動觸發(fā)注冊的函數(shù)調(diào)用。一個或者多個事件拋出者不知道誰接受事件，不需假設一定有處理和誰處理不能假定事件是否被處理以及被處理的順序優(yōu)點：為軟件重用提供了強大的支持。當需要將一個構件加入現(xiàn)

35、存系統(tǒng)中時，只需將它注冊到系統(tǒng)的事件中。為改進系統(tǒng)帶來了方便。當用一個構件代替另一個構件時，不會影響到其它構件的接口。缺點：正確性和完整性無法保證難以測試和調(diào)試構件放棄了對系統(tǒng)計算的控制。一個構件觸發(fā)一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件注冊了哪些構件的構成，它也不能保證這些過程被調(diào)用的順序。數(shù)據(jù)交換的問題。有時數(shù)據(jù)可被一個事件傳遞，但另一些情況下，基于事件的系統(tǒng)必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。既然過程的語義必須依賴于被觸發(fā)事件的上下文約束，關于正確性的推理存在問題。使用情景：一系列松耦合的組件，一些組件在執(zhí)行操作時，影響另一些

36、組件松散耦合的系統(tǒng)：調(diào)用不能太多；可以分成幾個部分相互處理Repository (Blackboard) Style結(jié)構：Components: 代表系統(tǒng)正確狀態(tài)的中心數(shù)據(jù)結(jié)構一系列操作中心數(shù)據(jù)結(jié)構的獨立組件監(jiān)視狀態(tài)改變并回應的代理Connectors: 過程調(diào)用或內(nèi)存讀取特點：除了blackboard，任何兩個agent部件獨立新的通訊必須基于blackboard實現(xiàn)，每個部件強依賴于中心blackboard，共享數(shù)據(jù)每個agent的行為方式：Blackboard（推模式），如Chat room，被動，結(jié)構復雜但客戶端易實現(xiàn)Repository (拉模式)，如Web log，主動，結(jié)構簡單但

37、客戶端復雜 優(yōu)點：充分存儲利用大量數(shù)據(jù)的有效方式共享模型被發(fā)布到倉庫中心減少了數(shù)據(jù)的復制分片集中管理：備份、安全、并發(fā)控制缺點：需要預先對數(shù)據(jù)模型達成共識黑板成為瓶頸數(shù)據(jù)演化非常昂貴使用情景：中心問題是建立、增強和維護一個復雜、穩(wěn)定的信息體，如數(shù)據(jù)庫，黑板專家系統(tǒng)，編程環(huán)境Layered Style 結(jié)構：Components: 一系列過程和對象的集合Connectors: 函數(shù)或引用，可見特點：嚴格的層次結(jié)構：底層為上層提供服務，調(diào)用下一層，上層作為底層的客戶可以允許跨層，當效率很重要的時候優(yōu)點：設計：支持基于抽象程度遞增的系統(tǒng)設計，使設計者可以把一個復雜系統(tǒng)按遞增的步驟進行分解；支持功能增

38、強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；易于修改支持重用。只要提供的服務接口定義不變，同一層的不同實現(xiàn)可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現(xiàn)方法。缺點：并不是每個系統(tǒng)都可以很容易地劃分為分層的模式，甚至即使一個系統(tǒng)的邏輯結(jié)構是層次化的，出于對系統(tǒng)性能的考慮，系統(tǒng)設計師不得不把一些低級或高級的功能綜合起來；很難找到一個合適的、正確的層次抽象方法。使用情景：可以按照抽象程度功能劃分為多個層次，包含一系列可被分層服務的程序，如分層通訊協(xié)議，操作系統(tǒng)MVC Style結(jié)構：Components: Model: 維護領域模型，并通知View相

39、關變化Controller：改變model狀態(tài)，并選擇返回的視圖View：把信息顯示給用戶，并把用戶的操作發(fā)送給ControllerConnectors: 函數(shù)調(diào)用，消息，事件，直接內(nèi)存訪問優(yōu)點：允許同一模型的多個視圖存在視圖可同步可插式視圖和控制器缺點：增加的復雜度view中數(shù)據(jù)訪問的低效可能和當前流行的UI工具兼容使用情景：界面在運行時可以被隨時更換，改變或者使用用戶接口不影響應用的功能部分的設計和代碼。如Web程序2 以進程為對象的體系結(jié)構風格：點對點point to point分布式系統(tǒng)中的異步消息傳遞：松散耦合的體系結(jié)構，組件隨意機器內(nèi)或者跨網(wǎng)絡：機器內(nèi)：共享數(shù)據(jù) 跨網(wǎng)絡：遠程過程調(diào)

40、用，中間件，基于同步過程調(diào)用的CORBA/RMI消息發(fā)送給唯一的接受者Publish-Subscribe Architecture StyleComponents: publisher/subscriberConnector: event router特點：類似事件，進城消息而非模塊控制：多進程需接受同樣信息發(fā)布者訂閱者：松散耦合，時間上必須同時，空間上不一定，信息發(fā)送基于時間訂閱靈活參與對象，一對多發(fā)布內(nèi)容可按照內(nèi)容進行組織Event router可對消息轉(zhuǎn)換封裝處理消息總線：實現(xiàn)多對多優(yōu)點：方便利用subscriber的信息缺點：Event router結(jié)構復雜，容易失敗3以物理單元為對象

41、的體系結(jié)構風格Client-ServerThree-Tier (N-Tier)Peer-to-PeerDistributed SystemDistributed Objects (middleware)Distributed Resources (http)Distributed Services (web service)Client-Server結(jié)構：Components: 客戶、服務器Connectors: 基于RPC的交互協(xié)議（遠程過程調(diào)用或者網(wǎng)絡協(xié)議）特點：服務器不知道客戶機的身份，客戶端必須知道服務器地址優(yōu)點：client可以隨意變更，server不變?nèi)秉c：server設計困難，成

42、為瓶頸舉例：File server, web server, ftp server, e-mail serverThree-Tier (N-Tier)三個子系統(tǒng)層：接口層 (或者前端)：和用戶交互的子系統(tǒng)，包括接口，網(wǎng)頁，表單etc.應用邏輯層 : 包括處理單元存儲層 ( 或者后端): 處理持久層數(shù)據(jù)的查詢和存取相當于在C/S結(jié)構中加入了一個中間層，提供了用戶界面和控制邏輯的分離優(yōu)點：性能高，修改好Peer-to-Peer結(jié)構：Components:自治區(qū)，可以扮演客戶端和服務器的角色Connectors: 同步和異步消息（遠程過程調(diào)用），沒有共享內(nèi)存（除非配置允許優(yōu)化）特點：網(wǎng)絡拓撲結(jié)構可以

43、是任意，動態(tài)的C/s結(jié)構的一種推廣：每個子系統(tǒng)可以扮演客戶端和服務器的角色相對難以實現(xiàn)：控制流較復雜，每個控制流都必須被同步舉例：eMule, eDonkey, Gnutella, Freenet, On Share, etc. are examples of a P2P systemsDistributed System：分布式對象（Middleware）、分布式資源（http）、分布式服務（SOA） Middleware-Oriented Distributed System Architecture Style 職責分配與協(xié)作設計協(xié)作設計（控制風格）的比較和場景判定對給定場景和要求的控制

44、風格，根據(jù)GRASP模式，判斷特定職責的分配根據(jù)分析類圖和體系結(jié)構模塊接口，建立基本的設計類圖控制風格有幾種控制流處理方式？進行比較（集中，委托，分散，特點區(qū)別和比較；把4和5合起來，比如說給一個不好的順序圖是集中式控制的，結(jié)合grasp，重新建立一個委托式的。）控制器在交互作用設計中具有重要的地位，因為它們在協(xié)作中是中心角色。它們通常是啟動和結(jié)束交互作用，把任務委托給其他組件并返回結(jié)果的組件控制器：做出決策并指導其他組件的程序組件，因為他們在交互中的中心地位而十分重要控制啟示：避免大部分消息產(chǎn)生于一個單一組件的交互設計；保持組件小型；確保操作職責不僅僅分配給少數(shù)組件；確保操作職責與數(shù)據(jù)職責一

45、致；讓組件代理盡可能多的低層任務；避免需要每個組件發(fā)送許多信息的交互Demeter法則：一個對象obj的操作只應當向以下實體發(fā)送信息：obj，obj的屬性，該操作的參數(shù)，所屬集合為該操作的參數(shù)或者obj的屬性的元素，該操作創(chuàng)建的對象，全局類或?qū)ο罂刂骑L格（Control Styles）：決策制定在組件之間分布的方式；有以下幾種集中式（Centralized）： 少數(shù)控制器做出所有重大的決定。非控制器組件只是保存數(shù)據(jù)或執(zhí)行簡單功能。 優(yōu)點：易于判定決定是哪里做出來的，易于保證正確性（邏輯思路明確） 易于修改決策過程 缺點：控制器可能變得太大，太復雜，難以理解，維護，測試等等。這樣的控制器被稱為膨

46、脹式控制器。其內(nèi)聚性不高，而且是大型模塊，這違背了兩條模塊性設計原則 控制器可能把其他組件視為數(shù)據(jù)倉庫，只是在其中存儲或者從中檢索數(shù)據(jù)。這樣往往會增強耦合性，并破壞信息的隱藏，因此違背了另外兩條模塊性設計原則 適用情況：僅當程序只需要做出少量的決定時才應該使用集中式控制樣式規(guī)則：在交互作用設計中，避免使大多數(shù)消息都源自同一個組件。 使組件保持小型化。 確保不把操作職責都分配給少量組件。操作職責的集中是集中控制樣式的特征。 確保操作職責與數(shù)據(jù)職責一致。委托式（Delegated）決策權分布在整個程序中，控制器做出事關全局的決定，并協(xié)調(diào)其他組件的活動，但把較低級別的決策委托給其他組件來做出。即只關

47、心發(fā)起后面的決策并不關心，類似于中介代理。 優(yōu)點：控制器只與較少的組件耦合，程序的總體耦合性降低。在委托職責的時候，控制器不需要知道那些與受托組件協(xié)作的組件，因此降低了耦合性。信息得到更好的隱藏。與從組件中獲取數(shù)據(jù)，修改數(shù)據(jù)之后再返回給組件不同，委托控制式鼓勵組件自己修改自己的數(shù)據(jù)使程序易于分層。正如我們以后將看到的那樣，分層體系結(jié)構樣式是一種非常重要和強大的組織程序模塊的方式。委托控制樣式使分層的組織更易于實現(xiàn)。適用情況：委托控制樣式確實沒有任何缺點，這是首選的控制樣式，尤其適合于面向?qū)ο蟮南到y(tǒng)。規(guī)則：使組件把盡可能多的低級任務委托出去。組件負責一些高級任務，而完成高級任務通常需要完成若干低

48、級任務。換句話說，可以把功能分解為更簡單的功能。這些低級任務通常是通過協(xié)作完成。分散式（Dispersed）決策權廣泛散布在整個程序中，只有很少或者沒有組件做出自己的決策，識別出哪些組件式控制器是困難的。 在這樣的設計中，有很多容納少量數(shù)據(jù)，擁有少量小型操作的小型組件。每項任務都必須通過數(shù)十個交互作用進行跟蹤。 缺點：理解控制流程很難。必須跟蹤大量的消息，才能弄清某項任務時如何完成的。這樣的設計既難以理解，又非常難以修改。 當把組件分割得太小時，他們往往不能獨立做任何事情，結(jié)果就是耦合性增強。 隱藏信息是困難的，因為每個組件的工作過程嚴重依賴其他組件的實現(xiàn)方式 內(nèi)聚性差（低內(nèi)聚） 有些模塊化原

49、則不能被滿足。 規(guī)則：避免每個組件都需要發(fā)送很多信息的交互（如果每個對象都需要發(fā)出很多消息，則表明控制樣式過于分散）GRASP模式（重點掌握）對外部事件交互，應該如何處理？（控制器模式）對給定場景，判斷職責的分配。（通常給一個系統(tǒng)順序圖，每個箭頭都是一個職責，每個職責怎么分配，職責通常需要分解，怎么分解看上課例子）高聚合，低耦合 面向?qū)ο蟮淖罡咴瓌t！多態(tài) Adapter, Command, Composite, Proxy, State, and Strategy模式其實都使用多態(tài)來實現(xiàn)。純虛構行為對象，功能為中心的對象。Adapter, Strategy, Command都是這一模式的具體實

50、現(xiàn)。間接性計通過引入中間層加以解決 ；Adapter, Bridge, Facade, Observer, Mediator，都是具體實現(xiàn)。 差異性保護隔離封裝變化。將變化，不確定的東西用穩(wěn)定不變的接口封裝隔離保護起來。信息隱藏 和 開閉原則具有相同的含義模式名稱問題，解決方案，優(yōu)缺點信息專家模式問題：對象設計和職責分配的一般原則是什么？解決方案：將職責分配給擁有履行一個職責所必需信息的類即信息專家。（也就是將職責分配給一個類，這個類必須擁有履行這個職責所需要的信息。）優(yōu)點：維護信息影藏，支持高內(nèi)聚低耦合，缺點：讓類變得復雜創(chuàng)建者模式問題：誰應該負責產(chǎn)生類的實例（對應于GoF設計模式系列里的“

51、工廠模式”）解決方案：如果符合下面的一個或多個條件，則將創(chuàng)建類A實例的職責分配給類B.類B聚合類A的對象。（prefer）.類B包含類A的對象。（prefer）.類B記錄類A對象的實例。.類B密切使用類A的對象。.類B初始化數(shù)據(jù)并在創(chuàng)建類A的實例時傳遞給類A（類B是創(chuàng)建類A實例的一個專家)。在以上情況下，類B是類A對象的創(chuàng)建者。優(yōu)點：支持低耦合：將創(chuàng)建實例的職責分配給需要對象引用的類 降低依賴：通過自己創(chuàng)建對象避免了依賴其它類幫他們創(chuàng)建對象控制器模式問題：誰處理一個系統(tǒng)事件？解決方案：當類代表下列一種情況時，為它分配處理系統(tǒng)事件消息的職責。.代表整個系統(tǒng)、設備或子系統(tǒng)（外觀控制器）。.代表系統(tǒng)

52、事件發(fā)生的用例場景（用例或回話控制器）。 專門設計一個類處理事件：1（功能）針對業(yè)務 或overall organization(a faade controller).（集中式） 2（系統(tǒng)）針對系統(tǒng) (a faade controller).（集中式） 3（角色）針對模塊 （a role controller）（近似集中式）4（用例）針對一個用例 (a use case controller)（近似分散式）優(yōu)點：使外部事件源和內(nèi)部事件處理器不相互依賴對方的類型和行為 缺點：？The controller objects can become highly coupled and uncohe

53、sive with more responsiblities （不是很懂）低耦合問題：如何支持低依賴性以及增加重用性？解決方案：分配職責時使（不必要的）耦合保持為最低。OO中耦合的種類：Y是X的屬性X的方法中有Y（參數(shù)，局部變量，返回值）X是Y的子孫類X實現(xiàn)Y接口優(yōu)點：類更易維護，易復用，將change本地化高內(nèi)聚問題：如何讓復雜性可管理？解決方案：分配職責時使內(nèi)聚保持為最高。內(nèi)聚的不同程度：非常低內(nèi)聚:一個類的職責包括很多功能低內(nèi)聚: 一個類職責包含一個功能中的復雜的任務高內(nèi)聚. 一個類在一個功能上有適中的職責，和其他類協(xié)作完成任務。 優(yōu)點：類易維護，易理解，支持低耦合，支持復用多態(tài)模式問題

54、：當行為隨類型變化而變化時誰來負責處理這些變化？解決方案：當類型變化導致另一個行為或?qū)е滦袨樽兓瘯r，應用多態(tài)操作將行為的職責分配到引起行為變化的類型。優(yōu)點：更簡單可靠，對比復雜的選擇邏輯（判斷語句）更易添加額外的行為在設計中增加類的數(shù)量使代碼更易理解純虛構模式問題：當不想破壞高內(nèi)聚和低耦合的設計原則時，誰來負責處理這些變化？解決方案：將一組高內(nèi)聚的職責分配給一個虛構的或處理方便的“行為”類，它并不是問題域中的概念，而是虛構的事務，以達到支持高內(nèi)聚、低耦合和重用的目的。典型適用場景：將representation 從 model中分離出去將platforms(facilities) 從 mode

55、l中分離出去分離復雜的行為分離復雜的數(shù)據(jù)結(jié)構優(yōu)點：支持高內(nèi)聚：相關職責被封裝成一個類來處理一系列相關任務。 支持復用because of the presence of fine grained Pure Fabrication classes. 間接性問題：如何分配職責以避免直接耦合？解決方案：分配職責給中間對象以協(xié)調(diào)組件或服務之間的操作，使得它們不直接耦合。優(yōu)點：與可變性低耦合，支持復用受保護變化模式問題：如何分配職責給對象、子系統(tǒng)和系統(tǒng)，使得這些元素中的變化或不穩(wěn)定的點不會對其他元素產(chǎn)生不利影響？解決方案：找出預計有變化或不穩(wěn)定的元素，為其創(chuàng)建穩(wěn)定的“接口”而分配職責。類型：Inform

56、ation HidingData driven (configuration files)Service lookup (runtime registration)Interpreter-Driven(generalize module)Reflective or Meta-Level Designs (Component replace)Uniform Access (adherence to protocols)LSP (polymorphism)Law of Demeter (restrict communication paths) GRASP模式（或其中之一）： General Re

57、sponsibility Assignment Software patterns（通用職責軟件模式），核心思想是職責分配，用職責設計對象。主要特征：對象職責分配的基本原則；主要應用在分析和建模上。核心思想理解：自己干自己的事（職責的分配）；自己干自己的能干的事（職責的分配）；自己只干自己的事（職責的內(nèi)聚）；包含9個基本模式：1 信息專家：解決類的職責分配問題的最基本模式。問題：當我們發(fā)現(xiàn)完對對象和職責后，職責的分配原則是什么？解決方案：職責的執(zhí)行需要某些信息，把職責分配給該信息的擁有者。即某項職責的執(zhí)行需要某些資源，只有擁有這些資源的對象才有資格執(zhí)行職責。優(yōu)點：信息擁有者類同時就是信息的操作

58、類，可以減少不必要的類之間的關聯(lián)；各個類的職責單一明確，容易理解；保持信息的封裝性；促進低耦合和高內(nèi)聚；造成某個類過于復雜。2 創(chuàng)建者：解決類的實例和創(chuàng)建職責問題的模式。問題：類的實例的創(chuàng)建職責，應該分配給什么樣的類？或者說類的實例應該由誰來創(chuàng)建？解決方案：B包含A，或B聚集A，或B記錄A，或B頻繁使用A或B有A初始化數(shù)據(jù)時，類A的實例的創(chuàng)建職責就分配給B。（其中，最提倡聚集和包含）一般用工廠模式或抽象工廠模式作為替代方案。優(yōu)點：整個結(jié)構清晰易懂；有利于類或組件的重用；防止職責的分散；降低耦合性。避免依賴其他的類來創(chuàng)建自己的對象。3 高內(nèi)聚：為降低類的復雜程度，簡化控制而提出的面向?qū)ο笤O計的原

59、則性模式。（其他模式的根本）問題：怎么做才能降低類的復雜程度，簡化控制？解決方案：緊密相關的功能（職責）應該分配給同一個類。優(yōu)點：聚集相關功能，結(jié)構清晰，容易理解；只聚集相關功能，使得類的職責單一明確，從而降低類的復雜程度，使用簡單。類易于維護；支持低耦合；支持復用。4 低耦合：為降低類之間的關聯(lián)程度，適應可變性而提出的面向?qū)ο笤O計的原則性模式。（其他模式的根本）問題：怎樣做才能降低類之間關聯(lián)程度，適應需求的變化呢？解決方案：為類分配職責時，應該盡量降低類之間的關聯(lián)關系（耦合性）。亦即，應該以降低類之間的耦合關系作為職責分配的原則。優(yōu)點：獨立性，有利于重用和維護；適應需求變化，一旦發(fā)生變化時，

60、可以把影響范圍縮小到最小范圍。5 控制器：解決事件處理職責問題的模式。問題：在UI層之外，應該由哪個類來處理（控制）系統(tǒng)操作（事件）呢？解決方案：把系統(tǒng)事件的處理職責分配給控制器類。擔當控制器類角色的候補類可能為：系統(tǒng)全體，設備，子系統(tǒng)等的表現(xiàn)類（Faade Controller）；系統(tǒng)實踐發(fā)生的用例的控制類，通常被命名為Handler，Coordinator，Session等。優(yōu)點：防止同類職責的分散。滿足高內(nèi)聚，低耦合原則；有利于共通處理；變化的高適應能力，能把變化的修改范圍控制在最小范圍內(nèi)。增加復用的潛力，基本思想是控制器對象使外部事件源和內(nèi)部事件處理的類型和行為相互獨立（解耦）；隨時查