一、設(shè)計模式 design paternal

1.MVC model view controller 模型-視圖-控制器

?????MVC把交互系統(tǒng)的組成分解成模型、視圖、控制三種構(gòu)件。

? ? ?模型：獨立于外在顯示內(nèi)容和形式，是軟件所處理的問題邏輯的內(nèi)在抽象，它封裝了問題的核心數(shù)據(jù)、邏輯和功能的計算關(guān)系，獨立于具體的界面表達和輸入、輸出操作。

? ? ?視圖：模型數(shù)據(jù)及邏輯關(guān)系和狀態(tài)的信息以特定的形式展示給用戶，從模型獲得顯示信息，對于相同的信息有不同的顯示形式或試圖。

? ? ? 控制：處理用戶與軟件的交互操作，職責是決定軟件的控制流程，確保用戶界面與模型間的對應(yīng)關(guān)系，接收用戶的輸入，將輸入反饋給模型，進而實現(xiàn)對模型的計算控制，是使模型和視圖協(xié)調(diào)工作的部件。

2.面向?qū)ο笤O(shè)計原則

設(shè)計原則名稱	設(shè)計原則簡介
單一職責原則 (Single Responsibility Principle, SRP)	類的職責要單一，不能將太多的職責放在一個類中
開閉原則 (Open-Closed Principle, OCP)	軟件實體對擴展是開放的，但對修改是關(guān)閉的，即在不修改一 個軟件實體的基礎(chǔ)上去擴展其功能
里氏代換原則 (Liskov Substitution Principle, LSP)	在軟件系統(tǒng)中，一個可以接受基類對象的地方必然可以接受一 個子類對象
依賴倒轉(zhuǎn)原則 (Dependency Inversion Principle, DIP)	要針對抽象層編程，而不要針對具體類編程
接口隔離原則 (Interface Segregation Principle, ISP)	使用多個專門的接口來取代一個統(tǒng)一的接口
合成復用原則 (Composite Reuse Principle, CRP)	在系統(tǒng)中應(yīng)該盡量多使用組合和聚合關(guān)聯(lián)關(guān)系，盡量少使用甚 至不使用繼承關(guān)系
迪米特法則 (Law of Demeter, LoD)	一個軟件實體對其他實體的引用越少越好，或者說如果兩個類 不必彼此直接通信，那么這兩個類就不應(yīng)當發(fā)生直接的相互作 用，而是通過引入一個第三者發(fā)生間接交互

（1）單一職責原則(Single Responsibility Principle,SRP)

????一個對象應(yīng)該只包含單一的職責，并且該職責被完整地封裝在一個類中。

（2）開閉原則(Open-Closed Principle, OCP)

????一個軟件實體應(yīng)當對擴展開放，對修改關(guān)閉。也就是說在設(shè)計一個模塊的時候，應(yīng)當使這個模塊可以在不被修改的前提下被擴展，即實現(xiàn)在不修改源代碼的情況下改變這個模塊的行為。

（3）里氏代換原則(Liskov SubstitutionPrinciple, LSP)

????所有引用基類（父類）的地方必須能透明地使用其子類的對象。

（4）依賴倒轉(zhuǎn)原則(Dependence InversionPrinciple, DIP)

? ? 高層模塊不應(yīng)該依賴低層模塊，它們都應(yīng)該依賴抽象。抽象不應(yīng)該依賴于細節(jié)，細節(jié)應(yīng)該依賴于抽象。要針對接口編程，不要針對實現(xiàn)編程。

（5）接口隔離原則(Interface SegregationPrinciple, ISP)

? ? 客戶端不應(yīng)該依賴那些它不需要的接口，使用多個專門的接口，而不使用單一的總接口。每一個接口應(yīng)該承擔一種相對獨立的角色。

（6）合成復用原則(Composite Reuse Principle,CRP)

? ? ?盡量使用對象組合，而不是繼承來達到復用的目的，在一個新的對象里通過關(guān)聯(lián)關(guān)系（包括組合關(guān)系和聚合關(guān)系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調(diào)用已有對象的方法達到復用其已有功能的目的。簡言之：要盡量使用組合/聚合關(guān)系，少用繼承。

（7）迪米特法則(Law of Demeter, LoD)

? ? ?一個軟件實體應(yīng)當盡可能少的與其他實體發(fā)生相互作用。

3.設(shè)計模式的定義

????設(shè)計模式(Design Pattern)是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計經(jīng)驗的總結(jié)，使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

4.設(shè)計模式的關(guān)鍵元素

???????模式名稱 (Pattern name)

???????問題 (Problem)

???????解決方案 (Solution)

???????效果 (Consequences)

5.設(shè)計模式的分類

????根據(jù)其目的（模式是用來做什么的）可分為創(chuàng)建型(Creational)，結(jié)構(gòu)型(Structural)和行為型(Behavioral)三種：

????????創(chuàng)建型模式主要用于創(chuàng)建對象。

????????結(jié)構(gòu)型模式主要用于處理類或?qū)ο蟮慕M合。

????????行為型模式主要用于描述對類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊煛?/p>

????根據(jù)范圍，即模式主要是用于處理類之間關(guān)系還是處理對象之間的關(guān)系，可分為類模式和對象模式兩種：

????????類模式處理類和子類之間的關(guān)系，這些關(guān)系通過繼承建立，在編譯時刻就被確定下來，是屬于靜態(tài)的。

????????對象模式處理對象間的關(guān)系，這些關(guān)系在運行時刻變化，更具動態(tài)性。

6.設(shè)計模式的優(yōu)點

????設(shè)計模式融合了眾多專家的經(jīng)驗，并以一種標準的形式供廣大開發(fā)人員所用，它提供了一套通用的設(shè)計詞匯和一種通用的語言以方便開發(fā)人員之間溝通和交流，使得設(shè)計方案更加通俗易懂。對于使用不同編程語言的開發(fā)和設(shè)計人員可以通過設(shè)計模式來交流系統(tǒng)設(shè)計方案，每一個模式都對應(yīng)一個標準的解決方案，設(shè)計模式可以降低開發(fā)人員理解系統(tǒng)的復雜度。

????設(shè)計模式使人們可以更加簡單方便地復用成功的設(shè)計和體系結(jié)構(gòu)，將已證實的技術(shù)表述成設(shè)計模式也會使新系統(tǒng)開發(fā)者更加容易理解其設(shè)計思路。設(shè)計模式使得重用成功的設(shè)計更加容易，并避免那些導致不可重用的設(shè)計方案。

????設(shè)計模式使得設(shè)計方案更加靈活，且易于修改。

????設(shè)計模式的使用將提高軟件系統(tǒng)的開發(fā)效率和軟件質(zhì)量，且在一定程度上節(jié)約設(shè)計成本。

????設(shè)計模式有助于初學者更深入地理解面向?qū)ο笏枷?#xff0c;一方面可以幫助初學者更加方便地閱讀和學習現(xiàn)有類庫與其他系統(tǒng)中的源代碼，另一方面還可以提高軟件的設(shè)計水平和代碼質(zhì)量。

7.簡單工廠、工廠（重點掌握）、抽象工廠、建造者、原型、單例模式（元素、組成、特點、優(yōu)點、缺點、適用場合詳細見作業(yè)）

二、基于體系結(jié)構(gòu)的設(shè)計方法 architecture-based software design ABSD

1.基本概念

設(shè)計元素：泛指軟件系統(tǒng)、概念子系統(tǒng)、概念構(gòu)件

視角和視圖：

用例：用來捕獲功能需求，給用戶一個結(jié)果值的功能點

質(zhì)量場景：定義特定場景來捕獲質(zhì)量需求

2.ABSD生命周期（知道ABSD的輸入和輸入分別是什么）

3.ABSD步驟

（1）分解一個設(shè)計元素的步驟

（2）定義邏輯視圖

（3）整體步驟

?

• 功能分解
• 選擇體系結(jié)構(gòu)風格
• 為風格分配功能
• 細化模板
• 功能校驗
• 創(chuàng)建并發(fā)視圖
• 創(chuàng)建配置視圖
• 創(chuàng)建質(zhì)量場景
• 驗證約束

4.體系結(jié)構(gòu)的設(shè)計與演化

? ? 基于體系結(jié)構(gòu)的軟件開發(fā)過程可以分為獨立的兩個階段，這兩個階段分別是實驗原型階段和演化開發(fā)階段。

? ? 實驗原型階段分為兩個周期，第一個周期完成圖形用戶界面的初始設(shè)計和問題域模型，第二個周期是設(shè)計和建立一個正交軟件體系結(jié)構(gòu)。第二個周期分為六個階段：

（1）標識構(gòu)件

（2）提出軟件體系結(jié)構(gòu)模型

（3）構(gòu)件映射到軟件體系結(jié)構(gòu)中

（4）分析構(gòu)件之間的相互作用

（5）產(chǎn)生軟件體系結(jié)構(gòu)

（6）軟件體系結(jié)構(gòu)的正交化

? ? ?演化開發(fā)階段分為八個步驟：

（1）需求變動歸類

（2）指定體系結(jié)構(gòu)演化計劃

（3）修改、增加或刪除構(gòu)件

（4）更新構(gòu)件的相互作用

（5）產(chǎn)生演化后的體系結(jié)構(gòu)

（6）迭代

（7）階段性技術(shù)評審

（8）對所做的標記進行處理

三、基于體系結(jié)構(gòu)的軟件開發(fā)模型

1.ABSD與傳統(tǒng)軟件開發(fā)模型的區(qū)別（掌握）

? 傳統(tǒng)軟件開發(fā)過程：問題定義、需求分析、軟件體系結(jié)構(gòu)建立、軟件設(shè)計、軟件實現(xiàn)、軟件測試。

? ABSDM(基于體系結(jié)構(gòu)的軟件開發(fā)模型)

2.體系結(jié)構(gòu)需求（以下內(nèi)容了解）

3.體系結(jié)構(gòu)設(shè)計

4.體系結(jié)構(gòu)實現(xiàn)

5.體系結(jié)構(gòu)演化

?

?

?

總結(jié)

以上是生活随笔為你收集整理的《软件体系结构》 第七章 基于体系结构的软件开发的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。