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

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

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

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

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

6、幫助解釋和驗證文檔OO協作與協作設計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職責與職責分配在面向對象的系統中是由多個對象組成的，這些對象必需能夠向其它對象發送消息或操作，這就是對象的交互和職責分配職責是什么？職責是從需求來的，由體系結構加工后，處理得到職責分配注意什么？職責分配是為了滿足需求，模塊化，信息隱藏，GRASPGRASP模式（或其中之一

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

55、l中分離出去分離復雜的行為分離復雜的數據結構優點：支持高內聚：相關職責被封裝成一個類來處理一系列相關任務。 支持復用because of the presence of fine grained Pure Fabrication classes. 間接性問題：如何分配職責以避免直接耦合？解決方案：分配職責給中間對象以協調組件或服務之間的操作，使得它們不直接耦合。優點：與可變性低耦合，支持復用受保護變化模式問題：如何分配職責給對象、子系統和系統，使得這些元素中的變化或不穩定的點不會對其他元素產生不利影響？解決方案：找出預計有變化或不穩定的元素，為其創建穩定的“接口”而分配職責。類型：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（通用職責軟件模式），核心思想是職責分配，用職責設計對象。主要特征：對象職責分配的基本原則；主要應用在分析和建模上。核心思想理解：自己干自己的事（職責的分配）；自己干自己的能干的事（職責的分配）；自己只干自己的事（職責的內聚）；包含9個基本模式：1 信息專家：解決類的職責分配問題的最基本模式。問題：當我們發現完對對象和職責后，職責的分配原則是什么？解決方案：職責的執行需要某些信息，把職責分配給該信息的擁有者。即某項職責的執行需要某些資源，只有擁有這些資源的對象才有資格執行職責。優點：信息擁有者類同時就是信息的操作

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

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

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