OOAD學習目標：
1.A critical,fundamental ability in OOAD is to skillfully assign responsibilities to software components.（面向對象分析設計種至關重要的的能力是熟練地爲軟件部件分配職能）
2）GRASP patterns ，nine fundamental priciples in object design and responsibilities assignment.
什麼是分析和設計：
1）分析強調對問題的調查研究而非解決方案
2）設計強調滿足需求的概念上解決方案而不是其實現
3）有益的分析和設計可以概括爲做正確的事和正確地做事
什麼是面向對象
面向對象將功能通過對象來實現，將功能封進對象中，讓對象實現具體細節。
什麼是OOAD
1）OOAD 的方法要求設計中要映射現實世界中指定問題域中的對象和實體
2）OOAD的精髓是透過對象（事情、概念、實體）考慮問題域和概念上的解決方案
3）OOA強調在問題域內發現和描述對象
4）OOD強調定義軟件對象以及他們如何協作以實現需求
OOA做的事是
1）對問題域進行理解並抽象成概念（對象）
2）找到概念之間的聯繫
3）找到概念中的屬性
問題域：被開發系統的應用領域，即現實世界中由這個系統進行處理的業務範圍
用例：人們如何使用應用的場景或情節的記錄
面向對象分析的結果可以表示爲領域模型，在領域模型中展示重要的領域概念或對象，領域模型表述了重要的概念及其關聯和屬性。領域模型斌不是對軟件對象的描述，它使真實世界領域中的概念和想象可視化，又叫概念對象模型。
交互圖：面對對象設計關注定義軟件對象以及對象間的協作，交互圖爲描述協作的常見方法，交互圖有通信圖和順序圖。
設計類圖:有效表示類定義的靜態圖視圖。
UML 統一建模語言，是描述、構造和文檔化系統製品的可視化語言，其目標爲使用面向對象的思想建立模型系統
UML三種應用方式：
1）UML作爲草圖
非完整，不正式的圖
2）UML作爲藍圖
相對詳細的設計圖，用於：
1.逆向工程，以UML圖方式對現有代碼進行可視化，使其易於理解。
2.代碼生成，前向工程
3）UML作爲編程語言
1.用UML完成軟件系統可執行規格說明
2.可執行代碼能夠被自動生成
3.UML作爲編程語言仍處於開發階段
UML圖定義
用例圖：描述角色以及角色與用例之間的連接關係
類圖：描述系統中的類，以及對象、接口、協作等事物之間的關係
交互圖：描述對象間如何協作，包括序列圖（順序圖）和協作圖
狀態圖：描述類的對象所有可能的狀態，以及事件發生時狀態的轉移條件
活動圖：描述用例要求所要進行的活動，以及活動間的約束關係
包圖：描述系統的邏輯架構
部署圖：描述系統的硬件配置、部署以及軟件構件和模塊在不同節點上的分佈。
UML五類圖（9種圖形）定義
1）第一類：用例圖
從用戶角度描述系統功能，並指出各功能的操作者
2）第二類：靜態圖
包括類圖、對象圖和包圖
3）第三類：行爲圖
描述系統的動態模型和組成對象間的交互關係
行爲圖包括狀態圖、活動圖
4）第四類：交互圖
描述對象間的交互關係
5）第五類：實現圖
包括構件圖和部署圖
構件圖描述代碼部件的物理結構和部件之間的依賴關係
UML圖分類
UML中的幾種關係
1.泛化（Generalization）：帶三角箭頭的實線，箭頭指向父類
2.實現(Realization)：帶三角箭頭的虛線，箭頭指向接口
3.關聯(Association)：帶普通箭頭的實心線，指向被擁有者
4.聚合(Aggregation):帶空心菱形的實心線，靈性指向整體
5.組合(Composition)：帶實心菱形的實線，菱形指向整體
6.依賴(Dependency)：帶箭頭的虛線，指向被使用者
UML圖關係
迭代、進化和敏捷
敏捷模型（Agile modeling）是有效應用 UML的關鍵
敏捷開發核心原則：簡單、順應變化、可遞增
敏捷開發：通常應用時間定量的迭代和進化式開發、使用自適應計劃、提倡增量交付幷包含其他提倡敏捷性的方法和實踐。
具備進化式精化計劃
短時間定量迭代需求和設計
倡導簡易、輕量等敏捷性的實踐和原則
敏捷建模：
敏捷方法不意味着不進行任何建模
建模的目的主要用於理解和溝通，並不是構建文檔
不要對所有或大多數軟件設計建模使用UML，可以將簡單設計推延到編程階段
儘可能使用最簡單的工具
不要單獨建模，建模目的式發現、理解和共享大家的理解
敏捷建模的特點：
輕量型的開發過程
重視敏捷建模的實踐
迭代式的開發過程
以人爲主導的開發環境
對知識轉移的支持
統一過程 Unified Process UP
UP核心思想：短時間定量迭代、進化和適應性開發
UP項目將工作和迭代組織爲四個主要階段：初細構移
1）初始：大體上的構想，業務案例，範圍和模糊評估
2）細化：已精細化的構想，核心架構的迭代實現，高風險的解決方案，確定大多數需求和範圍以及進行更爲實際的評估
3）構造：對遺留下來的風險較低和比較簡單的元素進行迭代實現，準備部署
4）移交：進行BETA測試和部署
科目:在一個主題域的一組活動。
需求分析
需求就是系統必須提供的能力和必須遵從的條件
需求分析最大的挑戰是尋找、溝通和記錄什麼是真正需要的，並能夠清楚地講解給客戶和開發團隊的成員
需求變更不可避免，所以有效管理是必不可少的。
作用：
客戶與開發人員之間的橋樑
明確系統做什麼的問題
降低開發風險
需求分析過程：
需求獲取
需求建模
需求文檔
OOA 分析方法：以對象爲基本的處理單元，將對象的數據和操作進行封裝，特點是加強了解，改進與分析有關的各類人員間的交流，適應性強，能實現軟件複用，建模技術UML
結構化分析方法：“分解”和“抽象”爲鐘點，以數據流爲核心主要研究數據流動及處理。特點是將複雜問題分解簡單化，抽象問題的本質而暫時忽略細節，通過數據流程圖描述當前系統的邏輯模型，建模技術就數據流圖業務流圖數據字典。
需求複用：
需求複用的思想來源於軟件複用
需求不是獨一無二的
複用的核心是軟件構件技術
統一過程種，需求按"FURPS+"模型分類
Functional:特性，功能，安全性
Usability:人性化因素，幫助，文檔
Reliability:故障頻率、可恢復性、可預測性
Performance:響應時間、吞吐量、準確性、有效性、資源利用率
Supportablity:適應性、可維護性、國際化、可配置性
+爲 實現，接口，操作，包裝，授權等輔助性和次要因素
用例
目標：確定和編寫用例，在一個基本樣式種使用摘要，非正式和詳述等用例形式
用例：一組相關的成功和失敗的場景集合，用來描述參與者如何使用系統來實現其目標
場景：參與者和系統之間一系列特定的活動和交互，也稱爲用例實例
參與者：是某些具有行爲的事物，可以是人、計算機系統或組織
爲什麼使用用例
讓外行人看懂內行人要做什麼
強調用戶的目標和觀點
用例即需求，主要目的是說明系統的功能性或行爲性需求
用例的優越性在於，能夠根據需要對複雜程度和形式化程度進行增減調節。
用例三種常用形式
摘要 brief：簡潔的一段式概要，用於主要成功場景
非正式 casual：非正式的段落格式，用幾個段落覆蓋不同場景
詳述 full-dressed：詳細編寫所有步驟及各種變化，同時具有補充部分，如前置條件和成功保證
用例定義
爲每個用戶目標分別定義用例
用例名稱應同用戶目標類似
用例名稱應該使用動詞開頭
目標級別的用例與用戶目標一一對應
分散的CRUD目標合併成一個CRUD用例
EBP（Elementary Business Process）測試
EBP定義：
一個人於某個時刻在一個地點執行的任務，用以響應業務事件
該任務能夠增加可量化的業務價值，並且以持久狀態留下數據
進行需求分析時，將用例聚焦於基本業務過程級別
用例圖組成
參與者：系統交互角色
用例：變量在內一組動作序列描述，系統執行這些動作併產生傳遞特定參與者價值的可觀察結果
系統邊界：用來表示正在建模的邊界
箭頭：用來表示參與者和系統通過相互發送信號或者消息進行交互的關聯關係
領域模型：對領域內的概念類或現實世界中對象的可視化表示，領域模型也稱爲概念模型，領域對象模型、分析對象模型
目標：
確定當前迭代相關的概念類
創建初始的領域模型
爲建模提供適當的屬性和關聯
使用UML表示法，領域模型被描述爲一組沒有定義操作的類圖，可展示：
領域對象或概念類
概念類關聯
概念類屬性
領域模型是OOA中最重要和經典的模型
確定一組對象或概念類 是 OOA的核心
什麼是概念類
概念類是思想、事物或對象，更正式地將，概念類可以從其符號、內涵和外延來考慮。
OO關鍵思想：
領域層軟件類的名稱要源於領域模型中的名稱，以使對象具有源於領域的信息和職責，可以減少人們思維與軟件模型之間的表示差異。
如何創建領域模型：
以當前迭代中所要設計的需求爲界：
1.尋找概念類
2.將其繪製爲UML類圖中的類
3.添加關聯和屬性
如何找到概念類：
重用和修改現有模型
使用分類列表
確定名詞短語
如何繪製領域模型
根據現有需求使用分類列表和確定名詞的方式列出備選概念類
繪製領域模型
找到並加入必要聯繫
確定並加入概念類屬性
描述類：包含描述其它事物的信息
何時需要描述類？
需要獨立於現有實例的描述
刪除所描述的事物的實例時，這些需要被維護的信息不會被關聯刪除
減少冗餘重複信息
關聯：
在領域模型中考慮如下關聯：
若存在需要保持一定時間的關係，語義表示爲關聯
從常見關聯列表中派生的關聯
關聯命名：類名-動詞短語-類名的格式爲之進行可讀性有序命名
領域模型實例：
系統順序圖(SSD, system sequence diagrams )：爲闡述所討論系統相關的輸入輸出事件而快速簡單地創建的製品
目標：確定系統事件，爲用例場景創建系統順序圖
用例文本及其所示的系統事件是創建SSD的輸入
每個系統時間都對應一個系統操作
SSD操作可以在操作契約中進行分析，在詞彙表中被詳細描述，並且作爲設計協作對象的起點
應爲每個用例的主要成功場景，頻繁發生或複雜的替代場景繪製SSD
處理銷售場景的SSD
系統事件命名以動詞開始
SSD Within the UP
SSD是用例模型的一部分，可視化隱含交互
UP初始階段不引入SSD，大部分創建於細化階段
有利於識別系統事件細節以明確系統必須被處理和設計的操作
有利於編寫系統的操作契約
有利於對估算的支持
操作契約：使用前置或後置條件的形式描述領域模型裏對象的詳細變化，並作爲系統操作的結果，包括操作，交叉引用，前置條件，後置條件。
契約主要輸入爲SSD中確定的系統操作,linguistic模型和領域專家的見解
系統操作：作爲黑盒構件的系統在其公共接口中提供的操作
後置條件：描述了領域模型內對象狀態的變化
領域模型狀態變化包括：
創建或刪除實例
形成或消除關聯
改變屬性
契約在何時有效：
用例是項目需求的主要知識庫，但對用例而言所需狀態變化的細節和複雜性難以處理或過於細節化。
契約創建的指導：
從SSD得出系統操作。
系統操作複雜，結果不明顯，或者用例不明確，爲其創建操作契約。
07 OOD UML迭代圖
邏輯架構：
軟件類宏觀組織結構，將軟件類組織組織爲包（或命名空間）、子系統和層。
層：較爲粗粒度的對類、包或子系統分組，具有對系統主要方面加以內聚的職責。
OO系統中通常包括：UI層，應用邏輯和領域對象層，技術服務層。 嚴格的架構只能調用相鄰下層，寬鬆架構可調用任何其下層
架構：
一組重要決策，其中涉及軟件系統組織，對結構元素及其組成系統所用接口的選擇，這些元素特定於其相互協作的行爲，這些結構和行爲元素到規模更大的子系統的組成，以及指導該組織結構的結構風格。
交互圖：
順序圖：以一種柵欄格式描述交互，其中在右側添加新創建的對象。
通信圖：以圖或網格格式描述對象交互，其中對象可以置於圖中任何位置。
交互圖消息表達式 return:=message(parameter:parametertype):returnType.
GRASP
職責驅動設計 RDD:就對象的角色而言，職責與對象的義務和行爲相關，職責分：行爲和認知。
對象的行爲職責包括：
自身執行一些行爲，如創建對象或計算
初始化其他對象中的動作
控制和協調其它對象中的動作
對象的認知職責包括：
對私有封裝數據的認知
對相關對象的認知
對其能夠導出或者計算的事物的認知。
職責和方法不同，職責是抽象，而方法實現了職責。
模式：模式是成對的問題/解決方案，並且具有廣爲人知的名稱，能用於新的語境中，同時對新情況下的應用、權衡、實現、變化等給出建議。
1.名稱：創建者
問題：誰創建了A
解決方案：若B包含組成聚集了A，B記錄了A，B緊密地使用A，B具有A的初始化數據，則將創建類A的職責分配給B
2.名稱：信息專家
問題：給對象分配職責的基本原則是？
解決方案：把職責分配給具有完成該職責所需信息的那個類。
3.名稱：低耦合
問題：如何減少因變化產生的影響
解決方案：分配職責以使耦合保持在較低水平
4.名稱:控制器
問題：在UI層之上首先接收和協調系統操作對象是什麼
解決方案：把職責分配給能代表下列選擇之一的對象：
代表全部系統、根對象、運行軟件的設備或主要的子系統
代表發生系統操作的用例場景
5.名稱:高內聚
問題：如何使對象保持有內聚、可理解、可管理，同時支持低耦合的附加作用
解決方案：職責分配應保持高內聚，以此評估備選方案
基於GRASP的OOD
用例實現:
描述某個用例基於協作對象如何在設計模型中實現
設計者能夠描述用例的一個或多個場景的設計，每個設計都成爲用例實現
UML是描述用例實現的常用語言
注意，如何通過GRASP進行類之間關聯和職責劃分
對象間的可見性：
可見性是一個對象看見其他對象或引用其他對象的能力。
爲了使發送者能向接收者發送消息，發送者必須具有接收者的可見性，也就是持有接收者對象的某種引用或指針。
可見性：
對象A到B的可見性通常有四種方式：
屬性可見性：B是A的屬性
參數可見性：B是A中方法的參數
局部可見性：B是A中方法的局部對象
全局可見性：B具有某種方式的全局可見性
爲了使對象A能夠向對象B發送消息，對A而言，B必須是可見的。
使用面嚮對象語言將設計製品映射爲代碼：
使用OOL需要爲類、方法和接口定義寫源碼。
DCD Designed Class Diagram設計類圖，設計模型
DCD描述了類或接口名稱、超類、操作的特徵標記以及類屬性，在OO中創建基本類的定義
DCD如果是UML繪製的，從圖形中生成基本類定義。
6.名稱：多態
問題：如何處理基於類型的選擇，如何創建可拔插的軟件構件
解決方案：當選擇或行爲隨類型有所不同時，使用多態操作爲變化的行爲類型分配職責。
7.名稱：純虛構
問題：當你不想違背高內聚和低耦合或其他目標，但是基於專家模式提供的方案有不合適，哪些對象應承擔這一職責。
解決方案：對人爲製造的類分配一組高內聚的職責，該類不代表問題領域概念，虛構的事物，用以支持高內聚、低耦合和複用
8.名稱：間接性
問題：爲了避免兩個或多個事物間直接耦合，應如何分配職責，如何使對象解耦合，以支持低耦合並提高複用性潛力
解決方案：將職責分配給中介對象，使其作爲其他構建或服務之間的媒介，以避免它們之間的直接耦合。中介實現了其他構件之間的間接性。
9.名稱：防止變異
問題：如何設計對象、子系統和系統，使其內部的變化或不穩定不會對其他元素產生不良影響
解決方案：識別預計變化或不穩定之處，分配指責用以在這些變化之外創建穩定接口。
GoF Gang of Four
1.名稱：適配器 （間接，純虛構，多態）
問題：如何解決不相容的接口問題，或者如何爲具有不同接口的相似構件提供穩定接口
解決方案：通過中介適配器對象，將構件的原有接口轉換爲其他接口
適配器模式的宗旨是，保留現有類提供的服務，向客戶提供接口，以滿足用戶的期望。
對於一個已經存在的類，如果它的接口與現有系統的需求不同時，可以考慮設計器模式
接口：一系列方法的 聲明，方法特徵的集合。接口只有方法特徵，而沒有方法的實現，因此這些方法可以在不同的地方被不同的類實現，而這些實現可以具有不同的行爲。
面向對象：功能通過對象實現，功能封裝進對象中，讓對象去實現具體細節。
工廠：這裏是簡單工廠或者具體工廠，不是GoF設計模式，是GoF抽象工廠模式的簡化
工廠返回的是接口而不是類，因此工廠能返回接口的任何實現
分離複雜創建的職責，並將其分配給內聚的幫助者對象，隱藏潛在的複雜創建邏輯，允許引入提高性能的內存管理策略，例如對象緩存或再生。
2.名稱：單實例類（單例模式？）
問題：如何只創建唯一實例的類，即單實例類？如何使對象具有全局可見性且單點訪問
解決方案：對類定義靜態方法用以返回單實例。
作用：保證一個類只有一個實例，並且提供一個訪問該實例的全局訪問點。 常見網站計數器，應用程序日誌應用
特點：單實例類只能有一個實例 單實例類必須自己給自己創建唯一實例 單實例類必須給所有其他對象提供這一實例
單例模式的宗旨在於確保某個類只有一個實例，並且爲之提供一個全局訪問點 通過隱藏構造器和提供對創建對象的單個訪問點，單例模式就能夠將類的職責集中於類的某個單個實例中。
單例模式，工廠，適配器模式
3.名稱：策略
問題：如何設計變化但相關的算法或政策，才能使這些算法或政策具有可變的能力？
解決方案：在單獨的類中分別定義每種算法/政策/策略，並且使其具有共同接口
策略基於多態實現，爲了防止變異，策略通常由工廠創建
本質：分離算法，選擇實現
4.名稱：組合
問題：如何能夠像處理非組合（原子）對象一樣，多態地處理一組對象或者具有組合結構的對象呢？
解決方案：定義組合和原子對象的類，使它們實現相同的接口
組合模式的設計意圖在於，讓用戶能夠用統一的接口處理單個對象以及對象組合
將對象組合成樹形結構以表示“部分-整體”的層次接口。組合模式使得用戶對單個對象和組合使用具有一致性。
組合模式希望用戶可以忽略與單個對象的不同，統一地使用組合結構中的所有對象。
5.名稱：外觀
問題：爲了降低複雜性，往往將系統劃分爲若干個子系統，如何做到各個子系統之間的通信和相互依賴關係達到最小？
解決方案：對子系統定義唯一的接觸點———使用外觀對象封裝子系統，外觀對象提供了唯一和統一的接口，並負責與子系統構件進行協作。
外觀模式爲子系統的一組接口提供了一個一致的界面，定義了一個高層接口，這個接口使這一子系統更加容易使用
外觀模式爲設計粗糙或高度複雜的遺留代碼提供一個簡單的接口，使新系統與該接口對象交互
6.名稱：觀察者 發佈-訂閱
問題：不同類型的訂閱者關注於發佈者對象的狀態變化或事件，並且想要在發佈者產生事件時以自己獨特的方式進行反應。此外發布者想要保持與訂閱者的低耦合。
解決方案：定義訂閱者或監聽器接口，訂閱者實現此接口。發佈者可以動態註冊關注其事件的訂閱者，並在事件發生時通知他們。
觀察者定義了一種一對多的關係，讓多個觀察者對象同時監聽某一個主題對象，這個主題對象在狀態發生變化時，會通知所有觀察者對象，使其能夠自動更新自己。
GoF分類
創建型：
抽象工廠，單實例
結構型：
適配器，組合，外觀
行爲型：
觀察者，策略
設計模式六大原則：
開閉原則：
對擴展開放，對修改關閉
在程序需要進行拓展的時候不能去修改原有的代碼，要實現熱拔插的效果
需要使用接口和抽象類。
里氏代換原則：
任何基類可以出現的地方，子類一定可以出現
只有當衍生類替換掉基類，而軟件單位的功能不受影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行爲
面向對象設計的基本原則之一，是繼承複用的基石
依賴倒轉原則：
高層模塊不應該依賴低層模塊，兩者都應該依賴於其抽象
抽象不應該依賴細節
細節應該依賴抽象。
模塊間的依賴通過抽象發生，實現類不發生直接依賴關係，其依賴關係通過接口或抽象類產生。
接口或抽象類不依賴於實現類
實現類依賴接口或抽象類
接口隔離原則：
使用多個隔離的接口比使用單個接口要好，降低依賴和耦合
迪米特法則：
一個實體應當儘量少與其他實體間發生相互作用，使得系統功能模塊相互獨立
合成複用原則：
儘量使用合成/聚合的方式，而不是使用繼承。