《软件体系结构》 第七章 基于体系结构的软件开发
一、設計模式 design paternal
1.MVC model view controller 模型-視圖-控制器
?????MVC把交互系統的組成分解成模型、視圖、控制三種構件。
? ? ?模型：獨立于外在顯示內容和形式，是軟件所處理的問題邏輯的內在抽象，它封裝了問題的核心數據、邏輯和功能的計算關系，獨立于具體的界面表達和輸入、輸出操作。
? ? ?視圖：模型數據及邏輯關系和狀態的信息以特定的形式展示給用戶，從模型獲得顯示信息，對于相同的信息有不同的顯示形式或試圖。
? ? ? 控制：處理用戶與軟件的交互操作，職責是決定軟件的控制流程，確保用戶界面與模型間的對應關系，接收用戶的輸入，將輸入反饋給模型，進而實現對模型的計算控制，是使模型和視圖協調工作的部件。
2.面向對象設計原則
| 設計原則名稱 | 設計原則簡介 |
| 單一職責原則 (Single Responsibility Principle, SRP) | 類的職責要單一，不能將太多的職責放在一個類中 |
| 開閉原則 (Open-Closed Principle, OCP) | 軟件實體對擴展是開放的，但對修改是關閉的，即在不修改一 個軟件實體的基礎上去擴展其功能 |
| 里氏代換原則 (Liskov Substitution Principle, LSP) | 在軟件系統中，一個可以接受基類對象的地方必然可以接受一 個子類對象 |
| 依賴倒轉原則 (Dependency Inversion Principle, DIP) | 要針對抽象層編程，而不要針對具體類編程 |
| 接口隔離原則 (Interface Segregation Principle, ISP) | 使用多個專門的接口來取代一個統一的接口 |
| 合成復用原則 (Composite Reuse Principle, CRP) | 在系統中應該盡量多使用組合和聚合關聯關系，盡量少使用甚 至不使用繼承關系 |
| 迪米特法則 (Law of Demeter, LoD) | 一個軟件實體對其他實體的引用越少越好，或者說如果兩個類 不必彼此直接通信，那么這兩個類就不應當發生直接的相互作 用，而是通過引入一個第三者發生間接交互 |
（1）單一職責原則(Single Responsibility Principle,SRP)
????一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中。
（2）開閉原則(Open-Closed Principle, OCP)
????一個軟件實體應當對擴展開放，對修改關閉。也就是說在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展，即實現在不修改源代碼的情況下改變這個模塊的行為。
（3）里氏代換原則(Liskov SubstitutionPrinciple, LSP)
????所有引用基類（父類）的地方必須能透明地使用其子類的對象。
（4）依賴倒轉原則(Dependence InversionPrinciple, DIP)
? ? 高層模塊不應該依賴低層模塊，它們都應該依賴抽象。抽象不應該依賴于細節，細節應該依賴于抽象。要針對接口編程，不要針對實現編程。
（5）接口隔離原則(Interface SegregationPrinciple, ISP)
? ? 客戶端不應該依賴那些它不需要的接口，使用多個專門的接口，而不使用單一的總接口。每一個接口應該承擔一種相對獨立的角色。
（6）合成復用原則(Composite Reuse Principle,CRP)
? ? ?盡量使用對象組合，而不是繼承來達到復用的目的，在一個新的對象里通過關聯關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到復用其已有功能的目的。簡言之：要盡量使用組合/聚合關系，少用繼承。
（7）迪米特法則(Law of Demeter, LoD)
? ? ?一個軟件實體應當盡可能少的與其他實體發生相互作用。
3.設計模式的定義
????設計模式(Design Pattern)是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。
4.設計模式的關鍵元素
???????模式名稱 (Pattern name)
???????問題 (Problem)
???????解決方案 (Solution)
???????效果 (Consequences)
5.設計模式的分類
????根據其目的（模式是用來做什么的）可分為創建型(Creational)，結構型(Structural)和行為型(Behavioral)三種：
????????創建型模式主要用于創建對象。
????????結構型模式主要用于處理類或對象的組合。
????????行為型模式主要用于描述對類或對象怎樣交互和怎樣分配職責。
????根據范圍，即模式主要是用于處理類之間關系還是處理對象之間的關系，可分為類模式和對象模式兩種：
????????類模式處理類和子類之間的關系，這些關系通過繼承建立，在編譯時刻就被確定下來，是屬于靜態的。
????????對象模式處理對象間的關系，這些關系在運行時刻變化，更具動態性。
6.設計模式的優點
????設計模式融合了眾多專家的經驗，并以一種標準的形式供廣大開發人員所用，它提供了一套通用的設計詞匯和一種通用的語言以方便開發人員之間溝通和交流，使得設計方案更加通俗易懂。對于使用不同編程語言的開發和設計人員可以通過設計模式來交流系統設計方案，每一個模式都對應一個標準的解決方案，設計模式可以降低開發人員理解系統的復雜度。
????設計模式使人們可以更加簡單方便地復用成功的設計和體系結構，將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。設計模式使得重用成功的設計更加容易，并避免那些導致不可重用的設計方案。
????設計模式使得設計方案更加靈活，且易于修改。
????設計模式的使用將提高軟件系統的開發效率和軟件質量，且在一定程度上節約設計成本。
????設計模式有助于初學者更深入地理解面向對象思想，一方面可以幫助初學者更加方便地閱讀和學習現有類庫與其他系統中的源代碼，另一方面還可以提高軟件的設計水平和代碼質量。
7.簡單工廠、工廠（重點掌握）、抽象工廠、建造者、原型、單例模式（元素、組成、特點、優點、缺點、適用場合詳細見作業）
二、基于體系結構的設計方法 architecture-based software design ABSD
1.基本概念
設計元素：泛指軟件系統、概念子系統、概念構件
視角和視圖：
用例：用來捕獲功能需求，給用戶一個結果值的功能點
質量場景：定義特定場景來捕獲質量需求
2.ABSD生命周期（知道ABSD的輸入和輸入分別是什么）
3.ABSD步驟
（1）分解一個設計元素的步驟
（2）定義邏輯視圖
（3）整體步驟
?
- 功能分解
- 選擇體系結構風格
- 為風格分配功能
- 細化模板
- 功能校驗
- 創建并發視圖
- 創建配置視圖
- 創建質量場景
- 驗證約束
4.體系結構的設計與演化
? ? 基于體系結構的軟件開發過程可以分為獨立的兩個階段，這兩個階段分別是實驗原型階段和演化開發階段。
? ? 實驗原型階段分為兩個周期，第一個周期完成圖形用戶界面的初始設計和問題域模型，第二個周期是設計和建立一個正交軟件體系結構。第二個周期分為六個階段：
（1）標識構件
（2）提出軟件體系結構模型
（3）構件映射到軟件體系結構中
（4）分析構件之間的相互作用
（5）產生軟件體系結構
（6）軟件體系結構的正交化
? ? ?演化開發階段分為八個步驟：
（1）需求變動歸類
（2）指定體系結構演化計劃
（3）修改、增加或刪除構件
（4）更新構件的相互作用
（5）產生演化后的體系結構
（6）迭代
（7）階段性技術評審
（8）對所做的標記進行處理
三、基于體系結構的軟件開發模型
1.ABSD與傳統軟件開發模型的區別（掌握）
? 傳統軟件開發過程：問題定義、需求分析、軟件體系結構建立、軟件設計、軟件實現、軟件測試。
? ABSDM(基于體系結構的軟件開發模型)
2.體系結構需求（以下內容了解）
3.體系結構設計
4.體系結構實現
5.體系結構演化
?
?
?
總結
以上是生活随笔為你收集整理的《软件体系结构》 第七章 基于体系结构的软件开发的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LeetCode OJ - Popula
- 下一篇： 如何管理软件测试环境