OOAD（Object Oriented Analysis and Design)：面向對象分析與設計。
1.OOA：
定義OOA階段：
分析階段主要解決以下問題：
1.建立針對業務問題域的清晰視圖
2.列出系統要完成的核心任務
3.針對問題域建立公共詞彙表
4.列出解決問題域的最佳方案
此階段要解決的核心問題是“What to do ?”
2.OOD：
定義OOD階段：
設計階段主要解決以下問題:
如何解決具體的業務問題
引入系統工作所需的支持元素
定義系統的實現策略
此階段要解決的核心問題是“How to do ?”
3.OOP的主要特徵：
抽象（abstract） 封裝（encapsulation） 繼承（inheritance） 多態（ploymorphism）
關聯（association）聚合（aggregation）組合（composition） 內聚與耦合（cohesion&coupling）
抽象：
忽略一個對象的或實體的細節而只關注其本質特徵的過程。
簡化功能及格式。
幫助用戶與對象交互。
封裝：
隱藏數據和實現
提取公共方法供用戶調用功能
對象的兩種視圖
外部視圖：對象能做的工作
內部視圖：對象如何完成工作
繼承:
通過存在的類型來定義新的類型的機制；
通常在兩個類型之間存在“is a （什麼是什麼）”或“kind of（一種） ”的關係。
通過繼承可實現代碼重用，另外繼承也是多態的基礎。
如蘋果“is a”水果。
多態：
一個名稱，多種形式
基於繼承的多態
調用方法時，根據所給對象的不同而選擇不同的處理方式
如Football——play():使用腳來完成。
Basketball——play():使用手來完成。
給定一個具體的足球或籃球，用戶自動知道該使用誰的方式去執行play()。
關聯：
對象之間交互時的一種引用方式
當一個對象通過對另一個對象的引用去使用另一個對象的服務或操作時，兩個對象之間 便產生了關聯。
如person使用computer，person與computer之間就存在了關聯關係。
聚合：
關聯關係的一種，一個對象成爲另外一個對象的組成部分
是一個關係較強的關聯
在兩個對象之間存在“has a ”這樣的關係，一個對象作爲另一個對象的屬性存在，在 外部對象被生產時，可由客戶端指定與其關聯的內部對象
如汽車與輪胎，輪胎作爲汽車的一個組成部分，他和汽車可以分別生產以後裝配起來使 用，但汽車可以換新輪胎，輪胎也可以卸下來給其它汽車使用
組合：
當一個對象包含另一個對象時，外部對象負責管理內部對象的生命週期的情況
關聯關係中最強的一種。
內部對象的創建由外部對象自己控制
外部對象不存在時，內部對象也不能存在。
如電視機與顯示器。
4. 域模型
域模型是面向對象的。在面向對象術語中，域模型也稱爲設計模型。模型由以下內容組 成：
具有狀態和行爲的域對象
對象之間的關係
關聯（association）
依賴(dependency)
聚集(aggregation)
一般化（泛化）(generation)
一對多：一要獲得對方（多）的服務或操作，就要在自己的類裏面定義集合的方法。“n”方要關聯一方，就要在自己類裏定義“1”的一個成員變量,通過成員變量關聯。
內聚與耦合
內聚：度量一個類獨立完成某項工作的能力
耦合：度量系統內或系統之間依賴關係的複雜度
設計原則：增加內聚度，降低耦合度。
5.開發過程概述
傳統開發過程
瀑布模型
統一軟件開發過程（USDP）
6.OOAD的開發過程
大項目分解爲一些子項目
使用UML工具
統一軟件開發過程是一個迭代、遞增的開發過程
迭代、遞增項目的生命週期（現在，開始是完成基礎的功能，後逐漸添加新的功能）
項目是迭代、遞增的
迭代指生命週期中的一個步驟
迭代導致“遞增”或者是整過項目的增長
大項目迭代爲子項目
每一個迭代的階段，應該完成以下工作（迭代能很好的適應用戶的需求變化）
選擇並分析相關用例
根據所選架構進行設計
在組件層次實現設計
驗證組件滿足用例的需要
當迭代滿足目標後，開發進入下一個迭代週期
迭代、遞增的項目生命週期主要階段
每一個週期包含一次或多次的迭代
一個階段的結束稱之爲“里程碑（milestone）”
初始化階段
該階段的增量集中於：
項目啓動
建立業務模型
找到主要的風險因素
定義項目需求的外延
創建業務問題域的相關說明文檔
細化階段
本階段的增量集中於：
高層的分析與設計
建立項目的基礎框架
監督主要的風險因素
制訂達成項目的創建計劃
構建階段
本階段的增量集中於：
代碼及功能的實現
移交階段
本階段的增量集中於：
向用戶發佈產品
Beta測試（公司）
執行性能調優，用戶培訓和接受測試（用戶）
7.每個階段所含的工作流
每一次遞增都由5部分工作流組成
需求與初始分析
分析
設計
實現
測試
每一次迭代執行工作流的深度不同
早期的迭代在深度上覆蓋初始工作流，後期迭代在深度上覆蓋後期工作流
80/20原則：系統中80%的代碼被訪問的機率是20%，而20%的代碼的訪問機率是80%。
每個階段完成後又回到開始。
8.迭代、遞增生命週期的優勢
降低成本
編譯更好地維護項目進度
便於團隊的協作開發
便於適應用戶需求的動態變化
UML簡介1.UML（Unified Modeling Language），統一建模語言。圖形化的語言表示。
2.定義：統一建模語言是一種圖形化的語言，它可以幫助我們在OOAD過程中標識元素、 構建模塊、分析過程並可通過文檔說明系統中的重要細節。
3.UML圖的分類：靜態模型（static ）和動態模型
靜態模型：
創建並記錄一個系統的靜態特徵
反映一個軟件系統基礎、固定的框架結構
創建相關問題域主要元素的視圖
靜態建模包括
用例圖（use case diagrams）
類圖(class diagrams)
對象圖(object diagrams)
組件圖(component digrams)
部署圖(deployment diagrams)
動態建模
動態建模用來展示系統的行爲
動態建模包括：
時序圖（sequence diagrams）
協作圖(collaboration diagrams)
狀態圖(state chart diagrams)
活動圖(activity diagrams)
4.UML其他重要的元素
包（package）
UML的展示機制
註釋(comments)
構造型(stereotypes)
標記值(tagged value)
限制(constraints)
核心UML圖靜態建模：
1.用例圖
展現系統的核心功能及與其交互的用戶
用戶被稱爲“活動者”（actor）
用例圖使用橢圓表示
爲簡化建模過程，用戶可標註優先級
操作過程：starUML》模式瀏覽器》選擇下邊一項》右鍵》點擊用例圖》 雙擊修改組件的描述》結果。
2.類圖
表現類的特徵：
類圖描述了多個類，接口的特徵，以及對象之間的協作與交互。
由一個或多個矩形區域構成，內容包括：
類型（類名）
屬性（可選）
操作（可選）
實踐：
關聯
在模型瀏覽器中點擊右鍵》增加圖形》選擇類圖》開始創建》添加類名（雙擊）》添加屬性（也可在屬性欄中操作）（移到類上，右鍵》增加》屬性/操作（行爲/方法））
泛化（繼承（箭頭指向父類））
類實現接口：
3.對象圖
表現對象的特徵
對象圖展現了多個對象的特徵及對象之間的交互。
模式瀏覽器》右鍵》增加圖形》類圖》工具條下邊有對象選項》對象（類名用後邊的圖標添加）。鏈接用“連接”（對象下）
4.組件圖
同樣，在模型瀏覽器中的增加圖形中添加“組件/構件”（雙擊左鍵添加註釋）
5.部署圖
添加部署圖》節點》關聯關係（右上角可調節對齊）
動態建模：
1.時序圖（Sequence Diagram）重點
捕捉一段時間範圍內多個對象指尖的交互信息
強調消息交互的時間順序
創建時序圖：Object/類規則（創建對象）》用stimulus/消息（表示類之間的調用、自身調用使用selfstimulus/自身消息，如method3()）》
2.協作圖
表現一定範圍內對象之間的協作信息
強調參與信息交流的對象之間的組織結構
使用調用時，要先選中連線，後點擊調用添加箭頭
3.狀態轉換圖
傳輸：狀態之間
4.活動圖（與C語言的流程圖相似）
連接用傳輸：
5.包
引用一組相關實體
通常可用來劃分類的命名空間
包可用於
命名（Naming）
成員可見度（Member visibility）
導入(Importing)
繼承(Extends)
泛化(Generalization)
6.觀察者模式（Observer）
觀察者模式定義了一種一對多的依賴關係，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態發生變化時，會通知所有觀察者對象，讓他們能夠自動更新自己。
觀察者模式的組成
抽象主題角色：把所有對觀察者的引用保存在一個集合中，每個抽象主題提供一個接口，可以增加和刪除觀察者角色。一般用一個抽象類或接口來實現。
抽象觀察者角色：爲所有具體的觀察者定義一個接口，在的到主題的通知時更新自己。
具體的主題角色：在具體主題內部狀態改變時，給所有的登記過的觀察者發出通知。具體主題角色通用一個類實現。
具體觀察者角色：該角色實現抽象觀察者角色所有要求的更新接口，以便使本身的狀態與主題的狀態相協調。如果需要，具體主題角色的引用。通常用一個子類實現。
7.模板方式
模版方法模式的組成
父類角色：提供模版
子類角色：爲模版提供實現。
8. 組合模式
9.裝飾模式（Decorator）
裝飾模式的角色：
抽象構件角色（component）：給出一個抽象接口，以規範準備接收附加責任的對象。
具體構件角色（concrete Component）：定義一個將要接受附加責任的類。
裝飾角色（Decorator）：持有一個構建對象的引用，並定義一個與抽象構件接口一致的接口。
具體裝飾角色（Concrete Decorator）：負責給構件對象“貼上”附加的責任。
10.適配器模式（按對象組合）
11.Proxy（代理模式）
代理模式一般涉及到的角色有
抽象角色：聲明真實對象和代理對象的共同接口
代理角色：代理對象角色內部含有對真實對象的引用，從而可以操作真實對象，同時代理對象提供與真實對象的相同的接口以便在任何時刻都能代替真實對象。同時，代理對象可以在執行真實對象操作時，附加其他的操作，相當於對真實對象進行封裝。
真實對象：代理角色所代表的真實對象，是我們最終要引用的對象。
