物件導向設計

1. 物件導向設計 使用獨立且自給自足的物件和物件類別來設計系統

2. 本章目的 • 說明如何以能夠管理自己狀態和操作的互動物件進行軟體設計 • 描述一般物件導向設計中幾個重要的活動 • 介紹物件導向設計的幾個不同模型 • 說明如何以統一塑模語言（UML）來表示這些模型

3. 本章內容 • 物件和物件類別 • 物件導向設計過程 • 設計演化

4. OOD 的特性 • 物件是現實世界或系統實體的抽象，它們可以自我管理 • 物件互相獨立且可以封裝狀態與表示的資訊 • 系統的功能是以物件的服務來表示 • 不使用共用資料區域，物件的溝通是以訊息傳遞的方式來達成 • 物件可以分散，也可以循序或並行的執行

5. 互動的物件

6. OOD 的優點 • 容易維護，物件可以理解為獨立的實體 • 物件是一個可以適當再利用的元件 • 對某些系統而言，現實世界的實體和系統的物件有明顯的對應關係

7. 物件導向式開發 • 物件導向分析(OOA)、設計(OOD)與程式設計(OOP)都是互相有關係，但是各有區別的 • OOA 是與開發應用領域的物件模型有關 • OOD 是與開發物件導向系統模型以實作需求有關 • OOP 則是與利用 OO 程式設計語言(如 Java 或 C++)來實現 OOD 有關

8. 物件與物件類別 • 物件(Object)是軟體系統中的實體，用來表示現實世界中的實例和系統實體 • 物件類別(Object Class)則是這些物件的樣板，利用這些樣板可以建立物件 • 物件類別可以繼承其他物件類別的屬性和服務

9. 物件 「物件」(object)是一個實體，此實體具有一個狀態以及一組定義好的對此狀態的操作，此狀態則是以一組物件的屬性來表示。與此物件相關的操作則可提供服務給其他物件使用，當這些物件(用戶端)需要某些計算時便可以向提供服務的物件提出要求。 物件是根據某些「物件類別」(object class)的定義建立而成。物件類別的定義可以當成這些物件的樣板，它提供了依此類別所建之物件所應該具有的所有屬性和服務的宣告。

10. 統一塑模語言 (UML) • 1980和1990年代提出了許多用來描述物件導向設計的表示法 • 最後由統一塑模語言(Unified Modeling Language)將這些表示法整合 • UML可以描述在OO分析和設計中可能產生的各種不同模型表示法 • UML目前已經成為OO塑模的實際標準

11. Employee 物件類別 (UML)

12. Object 之間的溝通 • 概念上，物件是以訊息傳遞的方式進行溝通。 • 訊息(Messages) • 呼叫的物件必須以服務的名稱提出要求。 • 包括執行服務所需的複製資訊，以及接收服務結果的保存者名稱。 • 事實上，訊息通常會被實作成程序呼叫 • Name = 程序名稱。 • Information = 參數列。

13. 訊息範例 // 呼叫 buffer 物件的方法，傳回 buffer 中// 的下一個值 v = circularBuffer.Get () ; // 呼叫 thermostat 物件的方法，設定溫度 thermostat.setTemp (20) ;

14. 一般化與繼承 • 物件是類別的成員，類別則會定義屬性型態和操作 • 類別也可以排列成類別階層架構，以一個類別(父類別)當成一個或多個其他類別(子類別)一般化(generalisation) • 子類別可以繼承其父類別的屬性和操作，也可以加入自己新的方法或屬性 • UML中的一般化在OO程式語言中是實作成繼承 (inheritance)

15. 一般化的階層架構

16. 繼承的優點 • 它是一個抽象的機制，可以用來對實體做分類 • 它是一個再利用的機制，可以同時在設計和程式設計的層級進行重複利用 • 繼承圖可以當成是領域和系統方面的組織性知識來源

17. 繼承的問題 • 物件類別並不能獨立說明一切，有時候必須參考到他們的父類別 • 設計師習慣重複使用分析階段所產生的繼承圖，如此可能會嚴重的影響到效率 • 分析、設計與實作的繼承圖有不同的功能，應該分別做維護

18. 繼承與 OOD • 繼承是否為OOD的基礎有下列兩個不同觀點 • 觀點 1: 識別繼承架構或網路是物件導向設計的基礎。很顯然的這只能使用OOPL進行實作。 • 觀點 2: 繼承是一個有用的實作概念，它允許再利用屬性和操作的定義。在設計階段識別出繼承架構可能會對實作加諸一些不必要的限制。 • 繼承會讓系統變複雜，這當然不是我們所希望的，尤其對關鍵系統更是如此

19. UML的結合關係 • 結合 (Association)是物件和物件類別與其他物件和物件類別之間的關係 • 在UML中最普通的關係就是由結合關係來表示 • 結合關係上可以加註一些說明此關係的資訊 • 結合關係雖然普通，但是可以用來指示某個物件的屬性是一個結合物件，或是某個方法必須依賴某個結合的物件

20. 結合模型

21. 並行物件 • 物件本質上是一個獨立的實體，因此適合運用於並行實作 • 如果不同物件分別放在分散系統中的不同處理器上執行，就可以直接實作物件的訊息傳遞溝通方式

22. 伺服器與主動物件 • 伺服器(Servers) • 物件是以平行處理(伺服器)的方式實作，各個進入點對等於物件的操作。如果這些物件沒有被呼叫，它們會將自己暫停，然後等待別人提出服務要求 • 主動物件(Active objects) • 物件也是以平行處理的方式實作，但是物件可以變更自己的內部狀態，不一定需要透過外部的呼叫

23. 主動的轉發器物件 • 主動物件的屬性值可以經由某些操作進行修改，也可以自發性的使用內部操作進行修改 • 轉發器物件可以對外廣播飛行器的位置。這些位置座標可以經由衛星定位系統做更新，而物件本身也會利用衛星的三角量測定期更新這些座標位置

24. 主動的轉發器物件

25. Java 執行緒 • Java的執行緒(Thread)是實作並行物件最簡單的建構方式 • 執行緒中必須包含一個稱為 run() 的方法，這個方法是由Java的執行時期系統啟動執行 • 主動物件基本上會包含一個無窮迴圈，如此讓此物件可以持續執行運算

26. 物件導向設計程序 • 定義系統使用的環境與模式 • 定義系統架構 • 辨識主要的系統物件 • 發展設計模型 • 指定物件介面

27. 氣象系統的描述 氣象圖繪製系統必須能夠以規定的方式將從遠端、無人氣象台和其他資料來源收集而來的資料繪製成氣象圖，可能的資料來源如氣象觀察員、氣象氣球以及衛星資料等。氣象台會根據該區域控制電腦的要求將收集到的資料傳送到該區域電腦。 區域電腦系統會對這些收集到的資料做確認，並且整合從不同地方傳來的資料。整合後的資料會被存檔，利用這些存檔的資料以及數位化後的地圖資料庫就能夠產生一組區域性的氣象圖。氣象圖可以送到特殊應用的印表機做列印，或是以各種不同格式來顯示。

28. 氣象台的描述 氣象台中包括了一些受軟體控制的儀器，這些儀器是用來收集資料、執行某些資料處理動作以及將這些資料傳送到其他地方做進一步的處理。這些儀器包括有空中與地面的溫度計、風速計、風向標、氣壓計以及雨量計等。這些資料的收集動作每五分鐘執行一次。 當傳送氣象資料的指令發出之後，氣象台就會開始處理與彙整收集到的資料。而當氣象台收到要求時就會將這些彙整資料傳送到氣象圖繪製電腦。

29. 分層式架構

30. 系統環境與使用模型 • 瞭解想要設計的軟體和外部環境的關係 • 系統環境(System context) • 它是一個靜態模型，用來描述環境中的其他系統。其他系統可以使用子系統模型來表示，下一頁將展示氣象台系統周圍的其他子系統。 • 系統使用模型(Model of system use) • 它是一個動態模型，用來描述系統如何與它所處的環境互動。這些互動是以使用個案(use-case)來描述。

31. 氣象圖繪製系統的子系統

32. 氣象台的使用個案

33. 使用個案的描述

34. 架構設計 • 瞭解了系統和環境之間的互動之後，就可以利用這些資訊進行系統架構的設計 • 氣象台比較適合使用分層式架構 • 介面層負責處理溝通的部份 • 資料收集層負責管理各項儀器 • 儀器層負責收集資料 • 一個架構模型中最好不要超過7個實體

35. 氣象台架構

36. 物件識別 • 識別物件(或物件類別)是物件導向設計中最困難的部份 • 物件識別沒有什麼特別的訣竅，完全根據系統設計者對該領域的知識、能力與經驗而 • 物件識別是一個反覆的程序，不太可能一次就搞定

37. 識別物件的方法 • 對系統的自然語言描述做文法的分析 (為Hood方法所採用) • 以該應用領域有形的東西做為識別的基礎 • 根據設計者對系統整體行為的瞭解，以行為學的方法來識別 • 使用情境分析法(scenario-based analysis)，輪流辨識與分析系統使用的各種不同情境

38. 氣象台系統中的物件類別 • Ground thermometer, Anemometer, Barometer • 應用領域的物件，系統中與儀器有關的「硬體」物件 • Weather station • 氣象台和其環境的基本介面，可以用來反映使用個案模型中所識別出的互動情形 • Weather data • 封裝來自氣象台中各個不同儀器的彙整資料

39. 氣象台系統中的物件類別

40. 其他物件與物件的調整 • 以領域知識為基礎識別出更多的物件和操作 • 每一個氣象台應該有唯一的識別碼 • 氣象台通常位於偏遠的地區，儀器有時可能會出錯，這些儀器的故障情況應該能夠自動回報 。因此，需要有檢查儀器功能是否正常的屬性和操作 • 主動或被動物件 • 此例中，物件都是被動的，它們會依據要求來收集資料，而非自動收集。如此可以讓控制器的處理時間更加彈性

41. 設計模型 • 設計模型可以展示物件和物件類別，以及這些實體之間的關聯 • 靜態模型(Static models)是以物件類別和它們之間關聯來描述系統的靜態結構 • 動態模型(Dynamic models)則用來描述物件之間的動態互動

42. 設計模型的範例 • 子系統模型(Sub-system models)，以相關的子系統表示物件的邏輯群組。 • 循序模型(Sequence models)，展示物件互動的順序。 • 狀態機器模型(State machine models)，展示各別物件如何改變其狀態以回應發生的事件。 • 其他模型，包括使用個案模型(use-case models)、聚合模型(aggregation models)以及一般化模型(generalisation models)等。

43. 子系統模型 • 展示設計如何組織成邏輯上相關的物件群組 • 在UML表示法裡是以套件(package)來表示，套件是一種封裝的概念。它是一個邏輯模型，系統中的物件在實際組織上可能會有所不同。

44. 氣象台子系統

45. 循序模型 • 循序模型用來表示物件互動所發生的順序 • 物件水平的排列在最頂端 • 垂直方向則表示時間，所以這種模型必須由上而下解讀 • 物件之間的互動是以帶有標示的箭頭，不同樣式的箭頭表示不同型態的互動 • 物件時間軸上的窄長方形表示此物件為此時系統中的主控物件

46. 資料收集的順序

47. 狀態圖(Statecharts) • 展示物件如何回應不同的服務要求，以及由這些要求所觸發的狀態移轉情形 • 如果物件狀態為 Shutdown，那麼它只能回應 Startup()訊息 • waiting 狀態中的物件正在等待新進的訊息 • 如果接收到 reportWeather()，系統便移向彙整狀態 • 如果收到calibrate()訊息，系統將會移動到calibrating狀態 • 如果收到來自系統時鐘的訊號，系統則移動到正在收集儀器資料的collecting狀態

48. 氣象台的狀態圖

49. 物件介面規格 • 物件介面指定之後，物件和其他元件才可以平行的進行設計 • 設計師應該避免直接設計介面的表示法，而應該將它們隱藏在物件中 • 物件可能會有許多介面，用來表示方法所提供的各項觀點 • 介面的規格通常是使用UML的類別圖來指定，有時候也會使用Java來指定

50. 氣象台的介面