Chapter 7 基於體系結構的軟件開發
1. MVC解決方案：
●對於界面設計可變性的需求，MVC把交互系統的組成分解成模型、視圖、控制三種構件。
（1）模型構件：獨立於外在顯示內容和形式，是軟件所處理的問題邏輯的內在抽象，它封裝了問題的核心數據、邏輯和功能的計算關係，獨立於具體的界面表達和輸入/輸出操作。
（2）視圖構件：把表現模型數據及邏輯關係和狀態的信息以特定形式展示給用戶，它從模型獲得顯示信息，對於相同的信息可以有多個不同的顯示形式或視圖。
（3）控制構件：處理用戶與軟件的交互操作，其職責是決定軟件的控制流程，確保用戶界面與模型間的對應關係，它接受用戶的輸入，將輸入反饋給模型，進而實現對模型的計算控制，它是使模型和視圖協調工作的部件。
2. 設計模式的定義：
●一套被反覆使用、多人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是爲了可重用代碼，讓代碼更容易被他人理解、保證代碼的可靠性。
3. 設計模式的基本成分：
模式名稱、問題、解決方案、後果。
4. 設計模式的分類：
（1）按照目的，分爲創建型模式、結構型模式、行爲型模式。
●創建型模式：對象的創建過程
●結構型模式：對象類的組合
●行爲型模式：類和對象間的交互方式和任務分佈
（2）按照範圍，分爲類模式、對象模式。
●類模式：處理類和子類之間的關係
●對象模式：處理對象之間的關係
5. 幾種創建型模式：
（1）簡單工廠模式
●特點：根據參數的不同返回不同類的實例。專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。
●結構：工廠角色、抽象產品角色、具體產品角色
●優點：實現對象的創建和對象的使用分離，將對象的創建交給專門的工廠類負責。
●缺點：工廠類不夠靈活，增加新的具體產品需要修改工廠類的判斷邏輯代碼，而且產品較多時，工廠方法代碼將會非常複雜。
●適用：工廠類負責創建的對象比較少；客戶端只知道傳入工廠類的參數，對於如何創建對象不關心。
（2）工廠方法模式
●特點：工廠父類負責定義創建產品對象的公共接口，而工廠子類則負責生成具體的產品對象，這樣做的目的是將產品類的實例化操作延遲到工廠子類中完成。
●結構：抽象產品、具體產品、抽象工廠、具體工廠
●優點：增加新的產品類時無須修改現有系統，並封裝了產品對象的創建細節，系統具有良好的靈活性和可擴展性。
●缺點：增加新產品的同時需要增加新的工廠，導致系統類的個數成對增加，在一定程度上增加了系統的複雜性。
●適用：一個類不知道它所需要的對象的類；一個類通過其子類來指定創建哪個對象；將創建對象的任務委託給多個工廠子類中的某一個，客戶端在使用時可以無須關心是哪一個工廠子類創建產品子類，需要時再動態指定。
（3）抽象工廠模式
●特點：提供一個創建一系列相關或相互依賴對象的接口，而無須指定它們具體的類。
●結構：抽象產品、具體產品、抽象工廠、具體工廠
●優點：隔離了具體類的生成，使得客戶端並不需要知道什麼被創建。當一個產品族中的多個對象被設計成一起工作時，它能夠保證客戶端始終只使用同一個產品族中的對象。增加新的產品族很方便，無須修改已有系統，符合開閉原則。
●缺點：增加新的產品等級結構麻煩，需要對原有系統進行較大的修改，甚至需要修改抽象層代碼，這顯然會帶來較大的不便，違背了開閉原則。
●適用：一個系統不應當依賴於產品類實例如何被創建、組合和表達的細節。系統中有多於一個的產品族，但每次只使用其中某一產品族。屬於同一個產品族的產品將在一起使用，這一約束必須在系統的設計中體現出來。產品等級結構穩定，設計完成之後，不會向系統中增加新的產品等級結構或者刪除已有的產品等級結構。
（4）原型模式
●特點：使用原型實例指定待創建對象的類型，並且通過複製這個原型來創建新的對象。
●結構：抽象原型類、具體原型類、客戶類
●優點：簡化對象的創建過程，通過複製一個已有實例可以提高新實例的創建效率。擴展性較好。提供了簡化的創建結構。可以使用深克隆的方式保存對象的狀態。
●缺點：需要爲每一個類配備一個克隆方法，而且該克隆方法位於一個類的內部，當對已有的類進行改造時，需要修改源代碼，違背了開閉原則。實現深克隆時需要編寫較爲複雜的代碼。
●適用：創建新對象成本較大。對象的狀態變化很小。避免使用分層次的工廠類來創建分層次的對象。
（5）建造者模式
●特點：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。
●結構：抽象建造者、具體建造者、指揮者、產品角色
●優點：客戶端不必知道產品內部組成的細節，將產品本身與產品的創建過程解耦，使得相同的創建過程可以創建不同的產品對象，每一個具體建造者都相對獨立，而與其他的具體建造者無關，因此可以很方便地替換具體建造者或增加新的具體建造者，符合“開閉原則”，還可以更加精細地控制產品的創建過程。
●缺點：由於建造者模式所創建的產品一般具有較多的共同點，其組成部分相似，因此其使用範圍受到一定的限制，如果產品的內部變化複雜，可能會導致需要定義很多具體建造者類來實現這種變化，導致系統變得很龐大。
●適用：需要生成的產品對象有複雜的內部結構，這些產品對象通常包含多個成員屬性；需要生成的產品對象的屬性相互依賴，需要指定其生成順序；對象的創建過程獨立於創建該對象的類；隔離複雜對象的創建和使用，並使得相同的創建過程可以創建不同類型的產品。
（6）單例模式
●特點：確保一個類只有一個實例，並提供一個全局訪問點來訪問這個唯一實例。
●結構：單例
●優點：提供了對唯一實例的受控訪問。節約系統資源，提高系統的性能。允許可變數目的實例（多例類）。
●缺點：擴展困難（缺少抽象層）。單例類的職責過重。自動垃圾回收機制，可能會導致共享的單例對象的狀態丟失。
●適用：系統只需要一個實例對象，或者因爲資源消耗太大而只允許創建一個對象。客戶調用類的單個實例只允許使用一個公共訪問點，除了該公共訪問點，不能通過其他途徑訪問該實例。
6. 面向對象設計原則：
7. 基於體系結構的設計方法（ABSD）：
●相關術語：
（1）設計元素：泛指軟件系統、概念子系統、概念構件。
（2）視角和視圖：使用不同的視角觀察設計元素。選定的特定視角或視圖也就是邏輯視圖、進程視圖、實現視圖和配置視圖。
（3）用例和質量場景：用例用來捕獲功能需求。質量場景用來捕獲質量需求，質量場景捕獲變更、性能、可靠性和交互性，分別稱之爲變更場景、性能場景、可靠性場景和交互性場景。質量場景必須包括預期的和非預期的刺激。
●ABSD方法與生命週期：
（1）ABSD方法與生命週期
（2）ABSD方法的輸入：
抽象功能需求
用例
抽象的質量和商業需求
質量因素
體系結構選項
約束
●ABSD方法的步驟：
8. 體系結構的設計與演化：
●設計和演化過程：
（1）實驗原型階段
第一個開發週期：沒有具體的、明確的目標。結束時形成兩個版本，一個是圖形用戶界面的初始設計，另一個是問題域模型。
第二個開發週期：設計和建立一個正交軟件體系結構。
標識構件
提出軟件體系結構模型
把已標識的構件映射到軟件體系結構中
分析構件之間的相互作用
產生軟件體系結構
軟件體系結構正交化
（2）演化開發階段
9. 基於體系結構的軟件開發模型（ABSDM）：
●傳統的軟件開發過程可以劃分爲從概念直到實現的若干個階段，包括問題定義、需求分析、軟件設計、軟件實現及軟件測試等。如果採用傳統的軟件開發模型，軟件體系結構的建立應位於需求分析之後，概要設計之前。
●傳統軟件開發模型存在開發效率不高，不能很好地支持軟件重用等缺點。ABSDM模型把基於體系結構的軟件過程劃分爲體系結構需求、設計、文檔化、複審、實現、演化等子過程。
●體系結構需求：
●體系結構設計過程：
●體系結構文檔化：主要輸出結果是體系結構需求規格說明書和測試體系結構需求的質量設計說明書這兩個文檔。文檔的完整性和質量是軟件體系結構成功的關鍵因素。
●體系結構複審：目的是標識潛在的風險，及早發現體繫結構設計中的缺陷和錯誤。由外部人員進行復審的目的是保證其能共振地進行檢驗。
●體系結構實現過程：
●體系結構演化過程：
