OOAD(Object-Oriented Analysis and Design)介紹

OOAD方法論的定義:
 
   1) 面向對象是一種系統建模技術;
   2) 將系統描述爲許多相互作用的有關係對象;
   3) 系統中相互作用的對象被組織成類;
   4) OO方法論由以下三部分組成：
      . 一個過程
      . 一個符號
      . 一系列規則

在一個OOAD軟件開發過程，我們要完成二個不同的工作：
   1) 分析階段我們主要： （要做什麼？what to do?）
      . 建立一個清晰的商業問題的視圖;
      . 概述系統必須執行的任務;
      . 建立商業問題描述的通用詞彙;
      . 概述商業問題的最佳方案。
   2) 設計階段我們主要：（怎麼做？how to do?）
      . 解決商業問題;
      . 定義“how”代替“what”;
      . 介紹將使系統工作的支撐元素;
      . 定義系統的實現策略。

對象
   1) 是單個的、唯一確認的實體或項目;
   2) 作爲面向對象的構建塊被使用;
   3) 有身份、數據和行爲;
   4) 可以是簡單或複雜的;
   5) 可以是真實或想象的;
   6) 有屬性和操作;
   7) 是一個類的動態實例;

類 ，多個相同對象的一種抽象，多個對象共性的抽取，對象都創建自類

面向對象編程的特徵  (OOA,OOD,OOP)
   1) Abstraction(抽象):
      . 忽略細節，處理對象或實體本質的特徵，抽取共性;
      . 簡化功能以及信息;
      . 幫助用戶和對象交互;
   2) Encapsulation(封裝):
      . 控制對象的邊界；
      . 控制對象對外的藉口；
      . 隱藏對象的數據;
      . 處理每個對象的二種視圖：
        a. 外部視圖：顯示一個對象做什麼;
        b. 內部視圖：顯示對象如何完成它的任務;
   3) Association(關聯)
      . 對象間交互的方式;
      . 對象間相互使用其功能;
      . 一個對象使用另一個對象的服務或操作另一個對象，這時候對象相互關聯。
      . 一個對象通過另外一對象的引用來訪問這個對象。（對象間的引用）
   4) Aggregation(聚合)
      . 定義一個對象是另一個對象的一個組成部分;
      . 是一種比較強的關聯;
      . 一個對象是另外一個對象的組成部分（特殊的關聯）。
      . 通過“Has A”關係可進行確認。一輛車有輪子、座椅以及門，它們是一部車的組成部分。假如你移除其間的任何一部分，車沒有了相應的功能，但仍是一部車。
   5) Composition(合成)
      . 一個對象包含另一個對象（has a的關係）;
      . 是最強的關聯形式;
      . 外部對象全程負責內部對象的生命週期（特殊的聚合）
      . 通過“contain”關係可進行確認。
      . 假設部件不存在，對象亦不存在。
   6) Inheritance(繼承)
      . 是一種根據既存類定義新類的機制;
      . 通過“Is A”或者“Kind of”關係可進行確認;
      . 允許你組織相關類，這樣這些類可共同地被管理以及重用。
   7) Cohesion(內聚)和Coupling(耦合)
      . 組件之間依賴關係的度量;
      . 內聚: 一個組件獨立完成工作的能力;
      . 耦合: 組件之間依賴關係的度量;
      . 系統的耦合性越小越好，系統的內聚性越高越好。
   8)Polymorphism(多態)
      . 一種行爲在不同的環境下所變現出來不同的行爲；
      . 不同對象完成相同語義上的結果;
      . 基於繼承或實現;
      . 多態功能的實現依賴於它應用的對象;
      . 舉例：足球-扔-需二隻手、網球-扔-只需一隻手，同樣是扔，有不同的實現。當你將不同的球給一個小孩子，他知道是用一隻手還是二隻手。小孩都知道多態。

開發過程，軟件開發過程的控制。
   1) 傳統開發過程：
      . 瀑布式開發：需求->分析->設計->實現->測試。每個步驟完成和文檔化後才進入下一個階段。
      . 假設在後期階段出現問題，很難返回到先前階段。
      . 項目組成員花費大量時間和精力於每個階段確保它是正確的.
      . 各階段所用符號和術語均是變化的。完成的軟件雖然正確，但與它所表現的商業邏輯相關甚少。
   2) OOAD開發過程
      . 典型的處理方式是將一個項目作爲一系列的小項目;
      . UML(Unified Modeling Language)是一種符號，不是一個處理過程;
      . USDP(Unified Software Development Process)是迭代增量式的;
    初啓->細化->構建->移交，每個階段都有特定的目標
      . USDP和RUP(Rational Unified Process)都是流行的OOAD過程。

迭代增量式項目生命週期
   1) “迭代”指生命週期中每一個步驟;
   2) 迭代的結果便是整個項目功能完成的一步步增長;
   3) 在每個迭代的構建階段，你應該：
      . 選擇並分析相關的用例;
      . 使用選擇的體系結構創建一個設計;
      . 用組件實現設計;
      . 檢驗組件滿足用例。

迭代增量生命週期的主要階段
   1) Inception(開始)階段：
      . 這個階段的增長集中在：
        a. 開始項目;
        b. 爲這個項目建立起商業原則;
        c. 定義一個商業問題;
        d. 識別潛在的風險;
        e. 定義對問題更好理解的範圍;
        f. 創建對商業問題的解釋文檔。
      . 每個循環包括一至多個反覆，每個階段的完成結果都是里程碑式的。
   2) Elaboration(細節)階段：
      . 這個階段的增長集中在：
        a. 高水平的分析和設計;
        b. 爲項目建立一個架構體系的基線;
        c. 監測潛在的風險;
        d. 創建一個實現項目目標的構建計劃;
   3) The Construction(構建)階段：
      . 這個階段的增長集中在軟件項目日益成型;
   4) The Transition(躍遷)階段:
      . 這個階段的增長集中在:
        a. 發佈產品給客戶;
        b. 完成beta測試;
        c. 實現性能調整、用戶培訓以及接受度測試。

階段期間的工作步驟
   1) 每個階段由以下五個工作步驟組成：
      . 需求
      . 分析
      . 設計
      . 實現
      . 測試
   2) 不同的反覆對每個工作步驟完成的程度不同;
   3) 早期的反覆在深度上覆蓋了第一個工作步驟，以後的反覆在深度上覆蓋了最後的工作步驟。
   4) 8/2原則：假如完成了80%, 即可進入下一個反覆。

反覆和工作步驟
   1) 在每個反覆過程，根據需求你可以包括五個工作步驟中的任何一個。
   2) 早期的反覆過程集中在靠前的工作步驟，後期的反覆過程集中在靠後的工作步驟。
   3) 當你發現應該修改早先工作步驟中的某些錯誤，你可以：
      . 繼續並在下一個反覆過程中修正;
      . 繼續並增加一個新的反覆過程修正問題;
      . 假如時間允許，返回到當前的反覆並修正這個問題。
   4) 不同的反覆執行每個工作步驟於不同的程度。

迭代增量生命週期的好處
   1) 錯誤提早發現，降低成本;
   2) 對項目進度的更好保證;
   3) 對於開發團隊而言開發速度更快;
   4) 便於適應用戶需求的動態改變;

UML(Unified Modeling Language,統一的建模語言)介紹

UML定義 ：圖形化的建模語言

   1) UML是一種圖形化語言用於：
      . 說明;
      . 構建;
      . 肉眼觀察;
      . 文檔化系統原型;
   2) 在分析階段，你創建類圖以幫助你理解商業概念(還沒有實現的細節);
   3) 在構建階段，我們通過爲相同的類圖增加附加的細節——實現商業細節;

UML和藍圖的關係
開發OOAD程序——UML（程序的結構），藍圖——整體的規劃

UML圖形類型
   1) 靜態模型：代表你正在建模的軟件系統的基本結構;
   2) 動態模型：強調了系統的行爲;

靜態模型
   1) 構建以及文檔化一個系統的靜態方面;
   2) 反映了一個軟件系統基本的、穩定的框架;
   3) 創建問題主要元素的代表;
   4) 由以下圖形組成：
      . 用例圖
      . 類圖
      . 對象圖
      . 組件以及部署圖

動態圖
   1) 構建顯示系統行爲的圖形;
   2) 由以下圖形組成：
      . 時序圖
      . 協作圖
      . 狀態圖
      . 活動圖

用例圖 ：表示系統的功能，用戶和系統之間的交互關係
   1) 顯示誰或什麼使用系統以及它的特徵;
   2) 一個用例圖中特徵的用戶稱爲“actors”;
   3) 用例用橢圓表示;
   4) 爲使建模容易，用例圖需區分先後順序;
用例：表示系統功能的部分

類圖：表示類之間的關係，和類的信息
   1) 代表一系列包含普通屬性和特徵的對象;
   2) 結構化的圖形顯示了一系列的類、接口、對象間的協作以及關係;
   3) 由一至多個描述了以下信息的矩形組成：
      . 類型(類名)
      . 可選擇的屬性
      . 操作部分
    private用"-"表示，public用"+"表示，protected用"#"表示，defult不用加符號。
    抽象類，抽象方法的方法名用斜體字表示。
    ________________
       |     class      |
       |________________|
       |    age:int     |
       |______屬性______|
       | +getAge():int  |
       |______方法______|

對象圖 ：表示對象關係的，對象的信息。
   1) 代表一個明確的對象
   2) 結構化的圖形顯示了一系列對象以及他們之間的關係
         ______________
        |    gergo:    |
        |______________|
        |    Person    |
        |____類型名____|
    |初始化屬性的值|

組件圖 ，顯示軟件組件間的關係 ，組件，是功能相同或相近的類組成的。

部署圖 ，顯示能用於部署軟件應用程序的物理設備 ，表示物理設備的關係，網絡的拓撲結構，以及物理設備上部署的軟件，以及物理設備節點間信息交換的協議。

時序圖：在時間上，表示系統組件或對象間相互調用或是相互發送信息的順序。（表示單個用例的流程，或是詳細的組件間、對象間的發送信息的順序）。
   1) 不同對象一定時間範圍發生的消息;
   2) 強調消息或組件間的調用的時間順序

協作圖 ：和時序圖的邏輯一致，它主要表示組件或對象間的調用關係，可以清晰分辨系統的組織結構。
   1) 顯示了使用消息期間對象間的協作;
   2) 強調發送和接收消息的結構化組織;

狀態轉換圖 ，強調對象行爲的事件順序，主要是對對象狀態進行描述，也可以在對象狀態間加上狀態轉換條件 。

活動圖：描述用例的流程
   1) 描述一項活動到另外一項間的流程
   2) 強調一項活動到另外一項間的流程

包的符號（包圖）
   1) 指組織項目的一種方式
   2) 通常用於控制類的名域空間
   3) 在UML中使用包組織類、軟件組件、硬件組件、其它包以及和你模型相關的任何其它東西

需求和初始化分析

開始開發過程
   1) 分析最初的工作流;
   2) 收集信息;
   3) 創建一個問題的狀態;
   4) 創建用例;
   5) 引介組件以及部署圖;

收集信息
 
你可從許多資源中收集信息，這些資源包括：
   . 用戶的初始化需求詳情 （需求說明書）
   . 顧客和用戶 （需求會議）
   . 客戶的管理人員
   . 市場信息
   . 以前類似項目的經驗
   . 領域專家

避免習慣性的假設
   1) 你必須避免習慣性的假設，包括：
      . 用戶是天真的，開發者最清楚
      . 需求是靜態的
      . 一開始便能建立正確的方案
   2) 記住項目的發展以及客戶的需求均是變化的。
   3) 爲了避免這些假設，我們應該：
      . 明確用戶的需求
      . 確保你的模型能適應不斷變化的需求
      . 確保你能修改你的模型
    
行業專家
   1) 指某個特定商業領域的專家
   2) 可大致細分爲：
      . 行業專家
      . 特定應用程序行業專家以及當前商業領域專家
      . 相關業務領域專家
   3) 沒有行業專家，從其它領域抽象通用元素很困難

問題聲明
   1) 文檔清楚地描述了客戶和系統需求嗎？
   2) 用戶輸入對於文檔很重要
   3) 使用客戶熟悉的語言詞彙
   4) 句義清楚，不用行話
   5) 函蓋項目範圍內的細節
   6) 詳細說明問題的背景
   7) 詳細說明所知的約束
   問題聲明提供了關於商業背景、範圍以及計算機術語無關方面的約束。它用於作爲確認問題範圍的基礎。
 
對象和類的侯選值
   1) 可從問題聲明中確定
   2) 給問題聲明中的名詞短語加下劃線以建設對象和類侯選值列表
   3) 在接下去的分析階段，你需要確定你係統中所需的對象和類的列表

數據字典
   1) 描述了用於項目所有詞彙的文檔
   2) 通過和用戶溝通積累所得的條款
   3) 用於整個項目和系統
   4) 在整個項目期間會不斷地加入新的術語
   5) 幫助消除歧義
   6) 必須對所有項目組成員可用
   7) 數據字典對於大型項目中各團隊溝通非常重要。這時，它既是商業文檔也是系統文檔。

創建用例
   1) 一個用例是用戶和系統交互的圖形化的表現形式;
   2) 是定義和理解系統需求和背景的工具;
   3) 是任何系統某一方面的簡單印象。當你將所有印象收集在一塊，你便擁有了系統的整個描述;
   4) 圖形具體表現爲實線的橢圓。

用例場景，用例場景中不包括條件，同一出發點，但有不同結果。

用例圖中的“include”和“extend”
   1) “include”集中於包含關係，完成某個模塊之前，你必須使用另一個模塊;
   2) “extend”集中於擴展關係，也許或也許不基於某個模塊，不是強制性的;

用例中的情節假設
   1) 用例從用戶的角度顯示了軟件的功能。也許存在超過一種方式完成一指定功能。
   2) 一個假設情節指用例的一個實例——從開始到結束的一個邏輯路徑。
   3) 情節假設不包括有條件的聲明——因爲它們描述了用戶多個可能路徑中的一種。
   4) 所有的情節假設從相同的方式開始，但結果卻不同。
   5) 一個用例中成功或不成功的路徑都應該顯示出來——在一個ATM中，你必須考慮一些情節諸如用戶個人身份號碼輸入不對或者金額不足。

用例表單
   1) 每個用例的摘要
   2) 用例表單不是UML的內容，但是建議完成它。
   3) 在這個表單中，包括以下項目：
      . 用例名稱
      . 參與者
      . 優先權
      . 狀態
      . 擴展內容部分
      . 預處理/假想情節
      . 提交條件
      . 事件流
      . 可選路徑
      . 執行
      . 頻率

活動圖
   1) 創建用例圖後，你可以使用圖形說明活動或工作流
   2) 圖形化了所有用例假想情節
   3) 顯示活動、過程或工作流

風險評估和管理
   1) 有必要對項目進行風險評估
   2) 用例可以是風險評估的起點
   3) 高風險的用例應該在早期的迭代中開發
   4) 風險能出現在以下方面：
      . 需求風險
      . 技術風險
      . 技能風險
      . 資源風險
      . 政策風險

需求風險
   1) 需求風險指沒完全滿足客戶需求
   2) 你應該使工作於該系統的所有用戶和管理者都參與進來

技術風險 ,記住已證實過的技術比未證實的技術所冒風險要小

技能風險 ,確信你有所需的全部技能

資源和政策風險
   1) 資源風險指超出時間和資金預算
   2) 政治風險指與現行的政治規則衝突

包圖
   1) UML中存在符號以包裝任何邏輯相關的UML元素(類、對象、用例等等);
   2) 就像Java一樣，相關的類組織成不同的包;
   3) 這個符號像文件夾圖標;
   4) 有助於降低複雜性;
   5) 包間可存在依賴關係;
   6) 包有助於：
      . 查看沒有太多細節的大圖;
      . 查看獨立的小部分;
      . 創建部件中的一小部分;
      . 顯示組件間的依賴性;
      . 組件圖顯示了代碼物理組織形式，可以是一個類文件、Java源文件、jar文件、Java中的包、共享庫、對象代碼、RDB等等;
      . 當一個組件改變，它能影響其它——依賴性;
      . 組件應該有一個良好的接口，這樣你可以使用其它實現該接口的組件去替換它。

部署圖介紹
   1) 顯示了硬件組件間的物理關係;
   2) 每個符號代表了一些硬件設備：服務器、工作站、個人PC、傳感器、時鐘、電話交換機等。
   3) 當你獲得信息的時候可在任何階段添加以及修正。
   4) 符號間的連接伴隨着協議一起顯示。

系統對象和類分析

分析階段的理解
   1) 定義系統必須做什麼;
   2) 避免描述和實現的問題;
   3) 專注於系統的組件;
   4) 分析階段確定對象在運行時需要什麼以確保系統正確的功能;
   5) 分析階段在需求收集階段和用例階段之後，在系統設計階段之前;
   6) 在確定哪些是類和對象的時候，你應該回答以下問題：
      . 什麼對象組成了這個系統?
      . 什麼是可能的類?
      . 每個對象或類的責任是什麼？
      . 對象和類間是如何相聯繫的？
   7) 記住將所有新項目加入數據字典;

關鍵字的提取
   1) 當你定義組成系統的對象時，你應該創建一個滿足系統功能對象的列表;
   2) 列表中的對象稱爲對象侯選值;
   3) 然後你可以爲這個列表中最重要的對象準備一個子列表;
   4) 關鍵字代表了系統中主要或第一位的對象;

用UML表示對象和類
   1) 對象模型顯示了邏輯和特理的靜態視圖;
   2) 對象模型有二種圖：
      . 類圖：顯示了你必須創建一個系統所需的類。在運行時你可使用一個類創建許多對象。類圖必須顯示類間所有可能關係。
      . 對象圖：代表了系統中真實的對象，描述了特定案例中外在關係。
   3) 你可以使用主鍵去創建類圖和對象圖。
   4) 類圖在整個分析階段都會被更新和修正。

屬性和方法
   1) 對象包含了定義對象狀態的屬性;
   2) 方法定義了對象能執行的操作;
   3) 因此類必須定義這些屬性和方法;
   4) 在類執行之前，你必須定義所有的屬性和方法;
   5) 但是很多屬性和方法到設計階段才知道，加上所有你能加的先;
   6) 在設計階段存在的屬性和方法足夠了，但是他們的類型和參數還不夠。

屬性和方法
二種類型的屬性:
   . 普通屬性：是一個類中固有的屬性。一個普通屬性將會存儲對象中一些有意義的值。
   . 推導屬性：可以通過類中其它屬性推導得出。