一、面向對象

1、基本概念

軟件對象，是一種將狀態和行為有機集合起來形成軟件構造模型

對象和類

對象是狀態和行為構成的

類是相同屬性和操作的一組對象的組合

消息和事件

消息是指描述事件發生的信息，是對象間相互聯繫和作用的方式

事件是指一種由系統預先定義而由用戶或系統發出的動作

2、基本特徵

抽象

封裝

通過公共訪問控制器來限制對象的私有屬性的好處：

幫助保護數據的完整性

當類的私有方法必須修改時，限制了在整個應用程序內的影響

繼承

繼承的目的：

使派生類能夠比不使用繼承直接進行描述的類更加簡潔

能夠重用和擴展現有類庫資源

使軟件易於維護和修改

多態

3、方法論

獲取問題域陳述

建立系統的對象模型

標實和確定類

準備數據字典

確定關聯

確定屬性

使用繼承來細化類

完善對象模型

建立對象的動態模型

準備腳本

確定事件

準備事件跟蹤表

構造狀態圖

建立系統的功能模型

4、面向對象的設計準則

模塊化

抽象

信息隱藏—對象的封裝

低耦合-有助於類的維護

高內聚-一個對象類中應儘量多地匯聚邏輯上相關的計算資源

5、面向對象的實用規則

設計的結果應該清晰易懂

避免模糊的定義

一般到具體結構的深度應適當

儘量設計小而簡單的類

使用簡單的消息協議

使用簡單的函數或方法

把設計變動減至最小

6、系統設計

子系統分解

確定併發性

處理器及任務分配

數據存儲管理

全局資源的處理

選擇軟件控制機制

人機交互接口設計

二、面向對象建模

1、Unified Modeling Language

統一建模語言UML

2、開發模式

瀑布模型

項目計劃->需求分析->軟件設計->軟件實現->軟件測試->軟件運行和維護

缺點：

開發模式呈線性，開發成果尚未經過測試時，用戶無法看到軟件效果，增加項目的風險（數據概覽）

瀑布模型強制固定的完成日期和里程碑進行項目跟蹤，項目開發過程中缺乏足夠的靈活性

軟件需求分析階段，要完全確定系統用戶所需要的所有需求是一件比較困難的事情

噴泉模型

分析->設計->實現->維護->演化

缺點：

大量開發，不利於管理

嚴格的文檔管理，審核難度加大

基於構件的開發模式

軟件計劃->需求分析和定義->軟件的快速原型->原型評審->軟件設計和實現

缺點：

自定義的組裝結構標準，引入了較大的風險

可重用性和軟件高效性不易協調

過分依賴構件

XP方法

核心思想：

交流、簡單、反饋、進取

Communication、Simplicity、Feedback\Aggressiveness

優點：

採用簡單計劃策略，不需要長期計劃和複雜模型，開發週期短

全過程採用迭代增量的開發，反饋修正和反覆測試的方法，軟件質量有保證

能夠適應用戶經常變化的需求，提供用戶滿意的高質量軟件

三、Unified Modeling Language概述

1、視圖

靜態視圖

關聯

泛化

依賴->使用、實現

用例視圖

交互視圖

狀態機視圖

活動視圖

物理視圖

模型管理視圖

2、圖

用例圖

幫助開發團隊以一種可視化的方式理解系統的功能需求，包括基於流程的”角色"關係以及系統用例之間的關係

表達系統或者系統範疇的高級功能

類圖

顯示了系統的靜態結構，表示不同的實體是如何彼此相關聯的

序列圖

顯示一個具體用例或者用例一部分的詳細流程

狀態圖

某個類所處的不同狀態以及該類在這些狀態中的轉換過程

初始狀態：使用一個實心圓來繪製

狀態之間轉換：開箭頭的線段

狀態：圓角矩形

判斷點:空心圓

一個或多個終止點:內部包含實心圓來繪製

活動圖

表示二個或者更多的對象之間在處理某個活動時的過程控制流程

構件圖

指出某些功能實際存在於那些地方

部署圖

該軟件系統如何部署到硬件環境中的

3、模型元素

事物

結構事物

分組事物

註釋事物

關聯

依賴

關聯

泛化

實現

4、UML的通用機制

規格說明

修飾

這裡表示class2對class是1對多的關係

通用劃分

5、UML的擴展機制

構造型

比如：

<><<extends>><<include>>/<include>/<extends>

標記值

約束

四、總結

主要講了面向對象的一些基本概念和設計的方法論（獲取限定上下文，建立對象模型，動態模型，功能模型）和原則，包括設計準則（低耦合高內聚、抽象、模塊化和封裝）和實用原則，介紹了軟件開發的四種模式（瀑布、噴泉、構件、XP），最後簡單介紹了一下UML，包括了UML的視圖、圖、模型元素三個方面，後面還有一部分UML的公共機制，包含了通用機制和擴展機制。

談談自己的一些感悟吧，在平時的工作中，用到比較多的是用例圖、類圖、時序圖、狀態越遷圖，類圖現在其實用到的也不多了，現在有個很概念叫做領域驅動設計(DDD)，類圖畫的越來越少，工作上都在用領域圖。以前都是野路子畫法，2019年的第一個月，我準備把UML系統的學習一遍。還是發現之前畫的圖還是很不規範的，比如說類的約束和修飾，之前的詳細設計中都沒有體現，至於構件圖、活動圖、部署圖，之前也有畫過，不過畫成了四不像，後期主要會針對這些沒有涉及過的UML模型進行學習。

最後分享一下本章的思維導圖