1、chapter 模塊化理解模塊化（結構化）模塊化的設計思想使得我們能夠從簡單的、獨立的、可復用的模塊開始，構建復雜的系統，從而達到復雜系統的易開發、易修改、易復用。模塊化的優點從簡單性考慮：減少了調試和修改的時間。通過將系統劃分為獨立的各個模塊，每個模塊能夠在極少的去考慮對其他模塊的影響下，獨立的被考慮、實現、修改。從可觀察性考慮：每個模塊在邏輯上是清楚正確的，能夠很容易的看出邏輯行為是如何以及為何發生。減少了開發和修改的時間。從模塊的角度考慮：系統的其他部分可以通過模塊的名字對該模塊進行調用。每個模塊只專注于解決一個問題，減少了問題的復雜度，易于實現和修改。在模塊化的思想下，每個模塊能夠得到

2、獨立的對待：獨立理解獨立使用或復用獨立被構建一個模塊的失效不會影響到其他模塊一個模塊的修改不會影響到其他模塊降低耦合：最小化模塊之間的聯系耦合：模塊之間建立的聯系的強度的度量耦合分為兩大類：模塊與公共環境之間的聯系、模塊與模塊之間的聯系。-原則1：共享變量是有害的！參照公共耦合。-原則2：語法語義清晰，降低隱式關系理解一個模塊不需要依賴其他模塊的含義。（PPT例子）-原則3：避免重復否則，外部的修改會導致各個模塊中重復的部分也需要修改。-原則4：面向接口編程接口：模塊自身實現：模塊內部通過模塊的名字與整個模塊建立的聯系產生的耦合 公共耦合 控制耦合 = 印記耦合 數據耦合內容耦合最差公共耦合也

3、不可接受數據耦合好一些提高內聚：最大化模塊內部元素的關系偶然內聚隨意放在一起。main函數？邏輯內聚在邏輯上相似（加減乘除）。if-else switch-caseEDIT ALL DATA EDIT: PROC (TYPE, DATA)/* do some common edits */IF TYPE = “A”THEN /* edit by type A rules */IF TYPE = “B”THEN /* edit by type B rules */時間內聚一系列的事務在同一時間段內完成。例如：所有的初始化通信內聚由于對共同數據的引用而建立的內聚。如果一個模塊的所有成分都操作同一數

4、據集或生成同一數據集，則稱為通信內聚?！癛ead” and “Print” input data順序內聚為解決某個問題而實現一系列順序的步驟。如果一個模塊的各個成分和同一個功能密切相關，而且一個成分的輸出作為另一個成分的輸入，則稱為順序內聚。read deal update output功能內聚具有一個共同的目標，完成一個功能。信息內聚信息內聚 功能內聚 順序內聚 = 通信內聚 = 時間內聚 邏輯內聚 偶然內聚【面向對象】中的耦合關系交互耦合同結構化思想中的耦合關系相同，包括：共享數據變量訪問方法調用隱式關系組件耦合：類之間的關系，一個類使用另一個類的實例對象（PPT例子）組件耦合的四種類型：

5、全局的變量：聚合關系參數：方法調用之間的傳參創建：方法內部的局部變量隱式關系：由其他對象供給組件耦合又可分為以下三種類型：隱式組件耦合：（PPT）例子最差的耦合關系。C的對象出現在C的某個方法實現中，但是C在C的規格說明和實現中都沒有說明。分散的組件耦合：C作為局部變量或實例變量在C的實現中出現，但是沒有在C的規格中說明。表現：聚合關系：全局變量局部變量分散式組件耦合是可以接受的。規格化組件耦合：C在C的規格中說明。繼承耦合修改式繼承耦合：（P+C=1+N）最差的繼承耦合。子類對父類進行沒有任何規則的修改。如果外界擁有父類的引用，必須知道父類+子類所有方法。改進式繼承耦合：（P+C重寫的一些方

6、法=1+小N）在預定義的基礎上的修改。如果外界擁有父類的引用，必須知道父類+子類修改的。擴展式繼承耦合：（ONLY P=1）繼承的都沒有修改，只是添加方法和變量。如果外界擁有父類的引用，只需要知道父類。chapter 信息隱藏信息隱藏的含義每個模塊都隱藏了關于一個設計決策的實現。所有的設計決策都是相對獨立的。KWIC的兩種模塊化劃分方法第一種模塊化劃分方法：按照【處理流程】的方法進行劃分，處理過程中每個主要的處理步驟封裝成一個模塊。必須在并行工作之前設計好所有的數據結構，并需要復雜的描述。第二種模塊化劃分方法：按照【信息隱藏】的思想進行劃分，每個模塊封裝一個或幾個“秘密”，每個模塊都隱藏了一個

7、獨立于其他模塊的設計決策。必須在并行工作之前設計好所有的接口，只需要簡單的描述。兩種模塊化劃分的結果，可能都共享相同的數據結構和相同的算法，不同的是職責分配時模塊劃分的方式。系統運行是的表現可能是相同的，但是在可修改性、文檔化、可理解性等方面的展現不同。-設計定律1：不要按照處理流程中的步驟分解模塊。Module Guide針對復雜的系統-設計定律2：創建一個層次化結構的文檔module guide（自頂向下的居多，也可以改成自底向上的）按照module guide的思想，每個模塊包括以下3個部分：秘密：主要秘密和次要秘密主要秘密（來自SRS軟件需求規格）軟件設計時希望隱藏的信息。次要秘密（來

8、自變化）實現隱藏主要秘密的模塊的設計時的實現決策。模塊在系統運作用扮演的角色（功能）模塊提供的接口（？面向接口編程）chapter 體系結構設計風格【部件】【連接件】【約束】模塊層次的設計風格調用返回風格（主程序子程序風格、面向對象風格）主程序子程序風格描述主程序/子程序風格將系統組織成層次結構，包括一個主程序和一系列子程序。主程序是系統的控制器，負責調度各子程序的執行。各子程序又是一個局部的控制器，調度其子子程序的執行。主程序/子程序風格的重要設計決策與約束有：基于程序調用關系建立連接件，以層次分解的方式建立系統部件，共同組成層次結構。不允許逆方向調用：上層部件可以“使用”下層部件，但下層部

9、件不能“使用”上層部件。 單線程執行：主程序部件擁有最初的執行控制權，將控制權轉移給下層子程序。子程序只能夠通過上層轉移來獲得控制權，可以在執行中將控制權轉交給下層的子子程序，并在自身執行完成之后必須將控制權還交給上層部件。抽象規格【主程序部件】：它的實例是整個系統的控制器，控制權的發起者和終結者。subroutine端口包含需求接口，定義了對子程序的功能與交互期望?！咀映绦虿考浚禾幱谥鞒绦蛳聦?，controller端口描述了對上層部件提供的服務?！境绦蛘{用連接件】：程序調用機制。caller定義了給調用者提供的交互機制，callee定義了給被調用者提供的交互機制。面向對象式風格描述面向對象

10、式風格借鑒面向對象的思想，組織整個系統的高層結構。面向對象式風格將系統組織為多個獨立的對象，每個對象封裝其內部的數據，并基于數據對外提供服務。不同對象之間通過協作機制共同完成系統任務。面向對象式風格的重要設計決策及約束有：依照對數據的使用情況，用信息內聚的標準，為系統建立對象部件。每個對象部件基于內部數據提供對外服務接口，并隱藏內部數據的表示?；诜椒ㄕ{用機制建立連接件，將對象部件連接起來。每個對象負責維護其自身數據的一致性與完整性，并以此為基礎對外提供“正確”的服務。每個對象都是一個自治單位，不同對象之間是平級的，沒有主次、從屬、層次、分解等關系。抽象規格【對象部件】：自治的對象?！痉椒ㄕ{用

11、連接件】：典型的方法調用機制。管道過濾器風格描述管道-過濾器風格將系統的功能邏輯建立為部件集合。每個部件實例完成一個對數據流的獨立功能處理，它接收數據流輸入，進行轉換和增量后進行數據流輸出。連接件是管道機制，它將前一個過濾器的數據流輸出傳遞給后一個過濾器作為數據流輸入。連接件也可能會進行數據流的功能處理，進行轉換或增量，但連接件進行功能處理的目的為了適配前一個過濾器的輸出和后一個過濾器的輸入，而不是為了直接承載軟件系統的需求。管道-過濾器風格最重要的設計決策與約束是保證過濾器的獨立性，即：每個過濾器都獨立工作，無需知道通過管道與其相連的其他過濾器的特征。也就是說，每個過濾器只需要了解輸入數據流

12、和保證輸出數據流即可，不用關心一起工作的其他過濾器的實現細節。過濾器之間不能共享任何狀態，更不能共享數據。整個過濾網絡的正確輸出不能依賴于各過濾器的執行順序。各個過濾器可以并發執行。每個過濾器都可以在數據輸入不完備的情況下就開始進行處理，每次接到一部分數據流輸入就處理和產生一部分輸出。這樣，整個的過濾器網絡就形成了一條流水線。抽象規格【過濾器部件】：對數據流進行轉換或增量的功能處理部件?！竟艿肋B接件】：傳遞數據流的連接件。隱式調用風格描述隱式調用風格將系統中的不同功能部分建立為部件，并使用事件（而不是程序調用）來實現不同部件之間的連接，也就是說隱式調用風格使用事件傳播機制事件路由，來建立連接件

13、。隱式調用風格中的行為者仍然會聲明可調用程序來提供對外的服務，但是這些程序卻不會直接被外界調用。隱式調用風格采用的機制是將特定的事件類型與行為者的程序聯系起來，在相應事件發生后，通過聯系可以找到需要調用的程序并將其調用執行，這就是該風格被稱為“隱式調用”的原因。對可調用程序接口的管理及其與事件類型的匹配都是連接件的工作。隱式調用風格的重要設計決策與約束有：如果部件A和部件B需要相互協作，實現A調用B的效果，那么隱式調用風格的協作機制為：（1）部件A向部件路由R聲明它將要拋出的事件類型e；（2）部件B在事件路由R中注冊“事件-程序”的映射關系，表明如果發生事件e，事件路由R可以調用B的程序p；（

14、3）在部件A需要與部件B協作時，部件A向事件路由廣播事件e；（4）事件路由根據注冊的映射關系，將部件B的程序p調入執行。多個部件可以聲明同一個事件類型，每一個部件的事件廣播都有相同的調用效果。多個部件可以注冊同一個事件類型，并在事件發生后同時被調用執行；事件的廣播者不知道哪些部件會受到影響，不能假設事件對部件的影響關系，甚至不能假設事件一定會有接收者。部件不能假設對事件的處理順序，也不能假設對事件的處理結果。抽象規格【Agent部件】：需要利用隱式調用機制實現協作的部件。declaration端口含有需求接口，描述了對事件聲明服務的期望，事件生命服務允許部件聲明自己將要廣播的事件類型。regi

15、ster端口含有需求接口，描述了對事件注冊服務的期望，時間注冊服務允許部件注冊自己感興趣的事件類型。端口announce含有需求接口，描述了對事件廣播服務的期望，事件廣播服務允許部件將一個事件廣播出去。端口calledProcedure含有供給接口，描述了相關聯事件發生后將會執行的部件服務?！臼录酚蛇B接件】：角色publisher描述了EventRouter為事件聲明者提供的交互協議。角色subscriber描述了EventRouter為事件注冊者提供的交互協議。角色announcer描述了EventRouter為事件廣播者提供的交互協議。角色listener描述了EventRouter對事

16、件接收者的行為期望。在隱式調用風格中，部件實例對交互的參與只依賴于事件類型，不受接口規格的影響。存儲庫風格描述存儲庫風格將系統的功能處理建立為一系列的知識源部件，它們收集和處理系統的數據信息，完成系統的功能任務。存儲庫風格還建立了一個共享數據部件，它儲存系統所有的數據信息，代表了系統的狀態。知識源部件并不儲存數據，所以在它們進行數據收集與處理時，需要訪問共享數據區，這是通過直接進行存儲區訪問實現的，存儲庫風格將對存儲區的直接訪問建立為連接件。存儲庫風格的重要設計決策與約束有：所有的知識源相互獨立，它們彼此不互相調用，它們的活動也沒有預先確定順序。所有的知識源都依賴于共享數據，不僅它們處理的數據

17、來自于共享數據，而且它們的執行流程和順序也要取決于共享數據的狀態。知識源負責實時檢查共享數據的狀態，并在必要時做出合理的反應。抽象規格【知識源部件】：收集和處理系統信息，完成系統功能任務的部件。端口accessData包含需求接口，描述了它期望外界所能提供的數據訪問交互?！竟蚕頂祿考浚簝Υ嫦到y所有數據信息的部件。端口user包含供給接口，定義了它對外提供的數據訪問交互。【內存訪問連接件】：典型的存儲器訪問機制。角色accessor定義了給訪問者提供的交互行為。角色memory定義了對存儲器的交互行為期望。人們經常將交互分為“拉（pull）”和“推（push）”兩種模式，它們都是站在交互發起

18、者的立場來描述的?！袄保愃朴诶膭幼鳎┦侵附换グl起者主動從外界查詢和獲得信息給自己，然后自行決定下一步行動。而“推”（類似于推的動作）則是指交互發起者將自己的信息告知給外界，由外界決定下一步行動。存儲庫風格采用的是“拉”模式，由知識源主動發起查詢，并根據共享數據狀態決定下一步行動。如果將知識源與共享數據的交互變為“推（push）”模式，由共享數據監控狀態的變化，并在需要時通知知識源，然后再由知識源決定下一步行動，那么這種變體形式就是黑板風格（Blackboard Style）。因為要監控狀態變化，所以黑板風格需要強化共享數據部件的控制功能，或者在共享數據部件之外，再建立一個控制部件。假設黑

19、板風格除共享數據部件之外又建立了一個控制部件，那么它就擁有了三種部件類型（知識源、共享數據、控制）和3種連接件類型（數據訪問：連接知識源與共享數據；監控：連接共享數據與控制；事件通知：連接控制與數據源），其交互機制為：（1） 知識源部件A首先在控制部件中注冊感興趣的數據及其狀態條件；（2） 控制部件持續監控被注冊了興趣的數據及其狀態條件；（3） 另一個知識源部件B對共享數據的修改使得被注冊了興趣的數據滿足了狀態條件；（4） 控制部件廣播事件，通知所有注冊了相應數據及其狀態條件的知識源；（5） 知識源A接收到事件，進行功能處理。因為黑板風格對共享數據進行了全局性的控制，所以它能夠更好地解決模糊性

20、與不確定性問題。實際應用中，專家系統、集成開發環境、聊天室等都采用了黑板風格。存儲庫風格與黑板風格的比較存儲庫風格使用“拉”模型：組件向存儲庫中寫數據組件從存儲庫中讀數據容易實現客戶端復雜，且必須回滾數據黑板風格使用“推”模型：組件注冊訂閱數據數據可獲取是組件被通知客戶端程序簡單需要復雜的基礎分層風格描述分層風格根據不同的抽象層次，將系統組織為層次式結構。每個層次被建立為一個部件，不同部件之間通常用程序調用方式進行連接，因此連接件被建立為程序調用機制。分層風格的重要設計決策與約束有：從最底層到最高層，部件的抽象層次逐漸提升。每個下層為鄰接上層提供服務，每個上層將鄰接下層作為基礎設施使用。也就是

21、說，在程序調用機制中上層調用下層。兩個層次之間的連接要遵守特定的交互協議，該交互協議應該是成熟、穩定和標準化的。也就是說，只要遵守交互協議，不同部件實例之間是可以互相替換的。跨層次的連接是禁止的，不允許第I層直接調用I+N（N1）層的服務。逆向的連接是禁止的，不允許第I層調用第J（JI）層的服務。抽象規格【層次部件】：service端口為上層部件提供服務，包含供給接口，infrastructure端口對下層部件提供服務期望，包含需求接口?！境绦蛘{用】：遵守特定交互協議的程序調用機制。支持并發。進程層次的設計風格點對點風格分布式系統中的同步消息傳遞機制。松耦合，組件相互獨立。發布訂閱風格 多個應

22、用希望接收相同的消息（廣播）。發布者和訂閱者是解耦的消息傳遞是基于事件訂閱的物理單元層次的設計風格客戶端服務器風格描述客戶端/服務器風格將系統的功能進行了劃分。劃分后的一部分功能被建立為服務器部件，它們通常有較高的資源要求。系統中另一部分功能被建立為客戶端部件，它們需要處理更多的用戶交互。網絡連接被建立為連接件，它將客戶端的請求發送到服務器，服務器提供服務滿足請求，網絡連接再將服務的結果返還回客戶端?？蛻舳?服務器風格的重要設計決策與約束有：服務器較為固定，每個客戶端都知道服務器的標識；客戶端可以動態增減，服務器不知道客戶端的標識；各個客戶端之間相互獨立，它們都依賴于服務器。抽象規格【客戶端部

23、件】：主要承載用戶交互功能的部件?！痉掌鞑考浚撼休d復雜功能的部件。【網絡連接連接件】：典型的網絡連接機制。變化形式三層風格依據客戶端和服務器分擔職責的不同，客戶端/服務器風格可以分為“瘦（Thin）”客戶端和“胖（Fat）”客戶端兩種類型?！笆荩═hin）”客戶端類型將更多的功能部署到服務器上，減輕客戶端負擔的同時，也加重了服務器的負載，使得服務器的瓶頸缺點越發明顯。B/S風格就是典型的“瘦（Thin）”客戶端類型?！芭帧笨蛻舳祟愋蛯⒏嗟墓δ懿渴鸬娇蛻舳松?，以減輕服務器的壓力。但是客戶端功能過多又會增加系統的網絡通信復雜度，使得系統開發更加困難，同時修改之后的程序更新工作也會更加繁雜。為

24、了解決“瘦”與“胖”之間的兩難選擇，人們提出了一種客戶端/服務器風格的變體形式三層（3-Tier）。三層風格在客戶端與服務器之間加入一個新的層次業務邏輯層，如圖三層風格分為三個層次：表現層類似于C/S的瘦客戶端，主要負責業務表現和用戶交互，部署在網絡中眾多用戶使用的物理單元上。業務邏輯層負責系統的功能邏輯，完成系統任務，部署在網絡中的業務邏輯服務器節點。表現層與業務邏輯層是C/S關系，表現層為Client，業務邏輯層為Server。數據服務層負責系統的數據服務，部署在網絡中的數據服務器節點。業務邏輯層與數據服務層是C/S關系，業務邏輯層為Client，數據服務層為Server。按照同樣的道理，

25、業務邏輯層也可以進行分解，分為多層部署，以減輕每一層的服務器負載，此時該變體稱為N層（N-Tier）風格。最后需要強調的是，這里的“層”與分層風格的“層”是不同的概念，分層風格的“層”英文為Layer，是模塊的組織，三層的“層”英文為“Tier”，是網絡部署的組織。端到端風格前面所述的C/S風格及其變體形式都明確區分了客戶端和服務器，主要的功能都由服務器來承擔。但是，有些系統的功能負載非常高，很難由一個或幾個服務器來承擔。因此，又產生了一種類似于分布式系統風格的端到端（Peer to Peer）風格。在端到端風格中，每個參與者都既是客戶端，又是服務器分布式系統chapter 理解軟件體系結構軟

26、件體系結構的三個方面：高層次結構、關注點、設計決策詳細設計機制的不足關注點偏差（載體失配）作為載體，程序語言可以描述數據結構+算法，以及由此衍生的模塊、類等結構，能夠描述功能邏輯，但無法描述可靠性、性能等整體結構的質量要求 根據最初的設計，程序設計語言不承載質量要求 無法實現交互信息本地化（信息隱藏局限性）單詞匹配的需求使得模塊間必須依賴于對方的接口，導致信息隱藏的局限性 模塊間復雜連接邏輯被分散到其內部類之間，既突破了”NO INSIDE”的限制，又使得理解變得困難無法有效抽象部件的整體特性（無法描述module自身）總是進行模塊內部的描述接口聯合起來能夠表現module的功能，但無法表現一

27、個module的質量特性接口的定義缺乏結構性模塊的眾多接口之間太獨立無法實現區別對待：為不同的其他模塊公開不同的接口，尤其是不同的質量要求不能有效適應大型軟件的特殊開發方法復用與單次匹配多語言/多范型與聯合編譯遺留資產與module inside使用高層次結構的特點部件+連接件+配置模塊本身包含質量屬性（部件）模塊之間的交互由一個獨立的組件完成（連接件）部件和連接件通過配置進行關聯高層次結構理解軟件體系結構的三個方面之一部件關注處理和數據；連接件關注部件之間的交互。連接件單獨作為一個組件被考慮的原因：The definition of a connector should be localiz

28、ed連接件可能非常的復雜。系統中的交互信息很難放在某個部件中所有的元素都應該被獨立出來【部件】軟件體系結構中封裝處理和數據的組件。部件包括抽象規格與具體實現兩個部分。抽象規格：包括端口和特征集。特征集：包括部件的類型、功能性、約束、質量屬性等特征。端口：對外可見、可被外界引用的接口實體，代表了部件對外承諾的一種職責。部件可分為兩種類型：原始部件和復合部件。原始部件可以直接被實現為響應的軟件實現機制。軟件實現機制 示例 模塊(Module) Routine, SubRoutine 層(Layer) View, Logical, Model 文件(File) DLL, EXE, DAT 數據庫(D

29、atabase) Repository, Center Data 進程(Process) Sender, Receiver 網絡節點(Physical Unit) Client, Server 復合部件由更細粒度的部件和連接件組成，復合部件通過局部配置將其內部的部件和連接件連接起來，構成一個整體?！具B接件】連接件是軟件體系結構中承載部件之間交互的中介，連接件并不直接關聯到部件，這個工作將由配置來完成。連接件包括抽象規格與具體實現兩個部分。抽象規格：包括角色和特征集。特征集：包括類型、接口規則、交互斷言、交互協議等。角色：對外可見、可被外界引用的接口實體，每個角色代表一個交互參與方需要滿足的一些

30、條件，基本的條件是匹配該角色的端口所應復合的規則，復雜的條件可能會包括加密通信、負載均衡等?！九渲谩坎考瓦B接件都是軟件體系結構獨立的元素，相互之間沒有直接的關聯，配置是將部件和連接件整合起來的專門的機制。配置通過部件端口與連接件角色相匹配的方式，將系統中部件和連接件的關系定義為一個關聯集合，這個關聯集合可以形成系統整體結構的一個拓撲描述。利用配置將相互獨立的部件和連接件聯系起來，而不是之直接指定部件與連接件的關系的好處：可以實現部件和連接件的一次定義，多處使用在具體交互中，參與的部件不在固定，可以隨時發生變化對具體部件而言，其所參與的交互也不在固定，部件隨時可以參與或退出一個交互關注點理解軟

31、件體系結構的三個方面之二質量屬性是影響軟件系統復雜度的關鍵因素，軟件體系結構是處理質量屬性和控制復雜度的主要手段，質量屬性是軟件體系結構最為重要的關注點。軟件體系結構的主要關注點：系統質量，項目環境，商業目標設計決策理解軟件體系結構的三個方面之三軟件體系結構需要表現關注點，關注點對軟件體系結構的最終的樣式有著重要的影響，但是關注點并不能直接的反映為軟件體系結構的高層結構元素，關注點與高層結構之間存在差距，關注點必須通過設計決策才能轉化到高層結構上。軟件體系結構是重要設計決策的集合。設計決策的定義：設計決策對元素、特征和處理的選擇，它們涉及一個或多個關注點，直接或間接的影響到軟件體系結構。設計決

32、策的核心知識可以分為四個部分：關注點、解決方案、策略和理由。chapter 4+1 View邏輯視圖：關注系統的邏輯結構和重要的設計機制，描述系統提供的功能和服務。開發視圖：關注系統的實現結構，描述系統開發的組織。進程視圖：關注系統的運行時表現，描述系統的并發進程組織。物理視圖：關注系統的基礎設施，描述系統的部署與分布。場景視圖：關注系統最為重要的需求，描述系統應該實現的場景與用例。場景視圖（用例視圖）用例視圖關注的是軟件體系結構的需求，它們一方面說明軟件體系結構設計的出發點，驅動其他4個視圖的設計；另一方面用于驗證和評估其他4個視圖的設計，保證它們的正確性。用例視圖只是描述了軟件體系結構的需

33、求，并不涉及軟件體系結構的抽象規格，也不涉及軟件體系結構的實現，所以與其他4個視圖不同的是，它沒有直接貢獻于軟件體系結構自身的描述，以至于被稱為“+1”。用例視圖中的用例既包括【功能需求用例】，還包括軟件體系結構關注點【質量屬性】和【項目環境】的用例。邏輯視圖用戶角度考慮邏輯視圖描述的是一個滿足了需求的軟件體系結構設計，其主要內容是軟件體系結構的抽象規格，主要關注點是滿足用戶的各項需求，尤其是功能需求、質量屬性需求和約束。也就是說，邏輯視圖從總體功能組織的角度來描述軟件系統的高層結構，說明用戶需求在軟件體系結構元素中的分解與分配，解釋軟件系統保證需求實現的設計機制。邏輯視圖的內容是軟件體系結構

34、的抽象規格，其主要結構實體為部件、連接件、端口、角色、特征、配置等。但是在描述復雜軟件系統時，可能還需要詳細描述部件與連接件的功能規格和交互協議。以對基本結構元素的擴展為基礎，可以用下列機制來實現：為部件類型建立行為狀態圖，描述部件類型的詳細功能規格；為連接件類型建立行為狀態圖，描述連接件類型的交互機制；為端口建立協議狀態機，描述部件端口和連接件角色的交互協議；為配置和復合類型建立順序圖，描述配置和復合類型所包含的功能規格。開發視圖開發者角度考慮開發視圖關注軟件體系結構的模塊實現，體現軟件系統的模塊組織。因此，軟件體系結構的實現既要能夠合理劃分，建立模塊化程度較好的模塊集，以利于各個模塊的獨立

35、開發與復用，又要能夠將基礎模塊集組織成層、子系統等層次結構，以輔助項目管理活動的開展。在邏輯視圖的基礎上，強調使用模塊化和信息隱藏的思想劃分出易于開發實現的模塊。每個模塊對外存在需求或供給接口。進程視圖集成開發者角度考慮進程視圖關注軟件體系結構的運行時表現，考慮在靜態結構中難以分析的性能、可靠性等非功能需求，也會描述為保障系統完整性和容錯性而需要的進程并發及其分布，還要說明軟件體系結構的抽象規格是如何被進程實現的可執行的進程、線程及其負責的操作與控制邏輯。軟件系統的功能可以劃分為一系列相對獨立的任務。在任務內部，實現元素之間的聯系比較頻繁，結合比較緊密。但是在任務之間，雙方的實現元素之間只保持

36、較少的連接，相對比較獨立。因此，不同任務可能會被實現為不同的可執行單元進程或者線程，這種分割實現的方式可以幫助降低軟件系統的實現復雜度，所以在復雜的軟件系統開發中是一種重要的設計機制。進程就是由任務組形成的一個可執行單元，它是軟件體系結構進程實現的基礎元素。進程的并發與分布情況可以體現軟件體系結構對性能和可靠性的處理機制。部署視圖系統工程師角度考慮將軟件映射到硬件上部署視圖關注可靠性、容錯性、吞吐量、容量等與基礎設施相關的非功能需求（例如，雙機熱備份系統的可靠性要高于單機系統，多機之間互相校驗的系統要具有更高的容錯性），描述軟件體系結構的基礎設施和網絡分布，明確任務、進程、構件、重要制品（Ar

37、tifact）以及環境的部署與分布。chapter 體系結構設計體系結構設計的考慮方面結構高層結構多視圖結構（4+1 View）關注點質量屬性項目環境商業目標設計決策關注點產生的問題因素的解決方案風格一組設計決策形成的風格體系結構設計的步驟體系結構分析體系結構需求分析功能需求關注點質量屬性項目環境商業目標定義體系結構需求定義需求的場景描述定義初始體系結構利用4+1 view表示建立體系結構確定設計決策，修正體系結構chapter 設計模式面向接口編程通過模塊的名字與整個模塊建立的聯系產生的耦合 與模塊內部元素產生的耦合。普通面向接口編程的手段封裝繼承集合類型中實現面向接口編程的手段迭代器模式為

38、遍歷不同類型的集合提供統一的接口，隱藏了集合類型數據結構的內部結構信息。體現了【面向接口編程】【信息隱藏】的思想。集合類型的內部結構是可變的，不影響迭代器對外的接口。迭代器對外的接口是可拓展的，可以隨意添加集合類型的遍歷方式。代理模式為其他對象提供了一種代理，來控制對目標對象的訪問，通過代理實現間接的訪問。原型模式？【集合類型中實現面向接口編程的手段？】解耦的手段避免重復：重復的出現會導致一個地方的修改引發另一個地方也需要修改。DIP 依賴倒置原則：高層模塊不應該依賴于底層模塊的實現，而是依賴于高層抽象。抽象不應該依賴與具體實現，具體實現應該依賴于抽象。間接訪問：代理模式協作設計：中介者模式橋

39、接模式中介者模式問題：一組對象的交互遵從同一規則，但是十分復雜。中介者模式將對象之間的交互封裝起來，通過減少對象與對象之間的引用來解耦。使得對象之間的交互可以獨立變化。【集中式控制風格】橋接模式將接口與實現分離，提高了可拓展性，對客戶端隱藏實現。信息隱藏每個模塊都擁有一個基本的秘密：外部行為和內部實現。每個模塊都隱藏了一個重要設計決策的實現，所以只有模塊自身知道實現細節。每個模塊可能擁有一個額外的秘密：變化或修改。一個模塊信息隱藏的兩種基本手段信息隱藏的兩種基本類型：（隱藏設計決策、隱藏變化）外觀模式隱藏設計決策外觀模式提供了一個統一的接口，用來訪問子系統中的一群接口。它提供了一個高層接口，讓

40、子系統更容易的使用，隱藏了內部實現。實現了客戶端與子系統之間的解耦。【外觀模式】與【協作設計】的異同：【外觀模式】可以作為集中式的控制器?！緟f作設計】封裝的是由多個對象協作完成的一個task?！就庥^模式】可以僅僅封裝關系緊密的對象，不一定是封裝形成一個task。【外觀模式】與【中介者模式】在協作設計方面的異同：【外觀模式】封裝了關系緊密的幾個對象，提供一個高層次的接口，供外界進行訪問，主要作用是對外提供服務?！局薪檎吣Ｊ健繉ο笾g的交互進行封裝，并不對外提供服務。策略模式隱藏變化針對變化。實現了可修改性和可復用性共性和差異性繼承關系：共性放在父類中，差異性放在子類中，實現多選一的關系。聚合關

41、系：共性放在整體中，差異性放在部分中，實現多選多的關系。實現共性和可變性（差異性）的手段隱藏變化？策略模式狀態模式橋接模式OCP原則隱藏變化？對拓展開放，對修改封閉。對拓展開放：模塊的行為是可以拓展的對修改封閉：模塊的內部實現的代碼是不可修改的裝飾者模式裝飾者模式動態給一個對象添加一些額外的職責。 我們通常使用繼承來實現功能的拓展，但如果需要拓展的功能的種類繁多，那么會生成很多子類，從而增加了系統的復雜性。同時，使用繼承實現功能拓展，我們必須可預見這些拓展的功能，即功能在編譯時就是確定的，是靜態的。 使用裝飾者模式，功能的拓展可以由用戶動態決定加入的方式和時機，在運行期間決定何時增加何種功能，

42、相比使用生成子類方式達到功能的擴充顯得更為靈活。適配器模式運行時注冊觀察者模式命令模式對象創建單體模式工廠模式抽象工廠模式原型模式chapter 職責分配（GRASP模式）職責：職責是對象的功能，維護對象對外的協議和狀態。職責對設計的影響：單一職責原則：每個模塊只完成一個職責，實現一個功能。信息隱藏：每個模塊隱藏一個獨立的設計決策。module guide的來源：SRS和變化職責分配：把職責分配給體系結構中的一個或多個類。GRASP模式專家模式問題：面向對象設計中職責分配最基本的原則是什么？【職責應該分配給誰？】解決：把職責分配給擁有完成該職責所必須的信息的類。效果：維護信息的封裝降低耦合提高

43、內聚會導致一個類過于復雜創建者模式問題：將創建對象的職責分配給誰？解決：在決定哪個類負責對象的創建時，考慮潛在的創建者類和被創建的類之間的關系。B負責創建A，如果：B由A聚合而成；B包含A；（B包含一個屬性為A）B中創建A供來使用；B包含創建A的初始化信息。效果：通過讓一個類負責創建它需要引用的對象，來降低耦合。自己使用，自己創建，可以不依賴與其他類為自己創建。低耦合模式問題：如何降低依賴，提高復用？解決：通過職責分配降低耦合。效果：變化的部分可以被鎖定。容易理解，容易復用。高內聚模式問題：如何維護復雜的管理？解決：通過職責分配提高內聚。效果：類易于維護，易于理解，通常支持低耦合，支持復用。控制者模式問題：處理系統外部事件的職責應該如何分配？解決：如果系統從外部或圖形化界面接收事件，那么添加一個響應事件的類來與處理事件的類解耦