物件導向設計 (Object-Oriented Design)

1. 物件導向設計(Object-Oriented Design) • 使用自身定義完整(self-contained)的物件(object)及物件類別(object class)來設計系統

2. 主題 • 物件及物件類別(object and object class) • 物件導向設計(object-oriented design)的行程 • 設計的演進(design evolution)

3. 物件導向設計的特徵 (Characteristics of OOD) • 物件(object)是抽象的(abstraction)真實世界(real-world)或系統實體(system entities) • 物件是各自獨立的，並將狀態(state)及表達資訊(representation information) 封裝(encapsulate)起來 • 系統功能是以物件服務(object service)來表示

4. 不使用共享資料的區塊(shared data areas)，物件透過訊息傳遞(message passing)互相溝通 • 物件可以是分散式(distributed)的，可以循序(sequentially)或並行(parallel)的方式執行

5. 互動的物件 (Interacting Objects)

6. 物件導向設計的優點 • 容易維護，物件可視為獨立的實體 • 物件是可被適度重覆使用(reuse)的元件 • 對於某些系統而言，從真實世界的實體(real world entities)到系統的物件(system objects)有明顯的對應(mapping)

7. 物件導向的開發 (Object-Oriented Development) • 物件導向分析(analysis)、設計(design)及程式設計(programming)是相關但有區別 • 物件導向分析(OOA)是關於發展(developing)應用領域的物件模型(object model) • 物件導向設計(OOD)是關於發展(developing)物件導向系統模型(object-oriented system model)以實作需求(implement requirements) • 物件導向程式設計(OOP)是關於利用物件導向的程式語言，如Java或C++，以實現物件導向設計

8. 1. 物件(Object) 及物件類別(Object class) • 物件(object)是軟體系統中的實體(entities)，表示真實世界的實例(instances) • 物件類別(object class)是物件的樣板(templates)，可被用來產生(create)物件 • 物件類別可從其它的物件類別繼承(inherit)屬性(attribute)及服務(services)

9. 物件 (Object) • 一個物件是一個實體，它具有一個狀態(state)及一組被定義好可作用在此狀態的操作(operations) • 狀態是由一組物件屬性來表示 • 與物件相關聯的操作，可提供服務給其它物件 (用戶端)在需要計算(computation)時使用

10. 物件是根據某些物件類別的定義所建立 • 物件類別的定義被視為物件的樣板 • 它包含所有屬性(attributes)的宣告(declaration)及所有與該類別物件有所關聯的服務(services)

11. 統一塑模語言(Unified Modelling Language) • 在1980及1990年代，有幾種不同用以描述物件導向設計的表示法(notations)被提出 • 統一塑模語言(UML)是這些表示法的整合(integration) • UML用以描述在OO分析和設計時，可能用到之不同模型的表示法(notations) • 統一塑模語言如今是物件導向塑模的業界標準(de facto standard)

12. 員工的物件類別(UML)

13. 物件的溝通(Object Communication) • 概念上，物件是透過訊息傳遞(message passing)來溝通 • 物件溝通是透過其它物件提出要求服務(request services)(呼叫方法(calling methods))，透過交換所需要的資訊提供服務 • 執行服務所需要的資訊及執行服務後的結果會被當作參數來傳遞(passed as parameters)

14. Message Examples(訊息的例子) //呼叫(call)與暫存物件(buffer object)相關聯的方法(method)，並回傳暫存器中的下一個值 v = circularBuffer.Get () ; //呼叫與自動調溫器物件(thermostat object)相關聯的方法，並設定維持的溫度 thermostat.setTemp (20) ;

15. 一般化和繼承(Generalisation and Inheritance) • 物件是類別的成員(members)，類別定義屬性類型(attribute types)和操作(operations) • 類別可被排列成類別階層(class hierarchy)架構，其中一個類別(父類別(super-class))是其它一個或多個類別(子類別)的一般化(generalization) • 子類別繼承父類別的屬性和操作，自己也可增加新的方法(methods)或屬性(attributes) • 在UML中，一般化(generalisation)是實作成OO程式語言中的繼承(inheritance)

16. 一般化的階層架構(Generalisation Hierarchy)

17. 繼承的優點 • 繼承是抽象(abstraction)的機制，被用來分類實體(classify entities) • 繼承是在設計(design)和程式設計(programming)層次中重覆使用的機制 • 繼承圖(inheritance graph)是組織領域(domains)和系統(systems)知識的源頭(source)

18. 繼承的問題 • 物件類別不能自身完整說明(not self-contained)，若無參照它們的父類別(super-classes)無法獨立的被理解

19. UML關聯(UML Association) • 物件與物件類別可參與和其它物件與物件類別的關係(relationships) • 在UML中，一般化關係(generalized relationship) 是由關聯(association)來表示 • 關聯(association)可以加註(annotate)一些描述此關聯的資訊 • 關聯(association)雖是一般性的(general)，但可指出一個物件的屬性(object attribute)是一個關聯物件(associated object)，或一個方法(method)必須依賴(rely on)一個關聯物件

20. 關聯模型(Association Model)

21. 2. 物件導向設計行程(Object-Oriented Design) • 定義系統使用的內容(context)和模型(model) • 設計系統架構(system architecture) • 辨識主要的系統物件(principal system objects) • 發展設計模型(design model) • 指定物件介面(specify object interface)

22. 天氣系統描述(Weather System Description) A weather data collection system is required to generate weather maps on a regular basis using data collected from remote, unattended weather stations and other data sources such as weather observers, balloons and satellites. Weather stations transmit their data to the area computer in response to a request from that machine. The area computer validates the collected data and integrates it with the data from different sources. The integrated data is archived [把...存檔] and, using data from this archive and a digitised map database, a set of local weather maps is created. Maps may be printed for distribution on a special-purpose map printer or may be displayed in a number of different formats.

23. 氣象台描述(Weather Station Description) • 氣象台(weather station) • 受軟體程式控制的儀器，用來收集資料、處理資料和傳輸資料，以做進一步的處理 • 儀器(instrument) • 包括空氣和地面溫度計(air and ground thermometer)、風速計(anemometer)、風向標(wind vane)、氣壓計(barometer)和測量儀器(rain gauge) • 資料(data) • 每五分鐘採樣一次

24. 當下達命令(command)要傳送氣象資料時 • 氣象站開始處理和彙整採樣的資料 • 當接收到要求時，彙整的資料被傳送到圖象電腦(mapping computer)

25. 分層架構(Layered Architecture) • 分層架構反應系統在不同階段時的處理(processing) • 資料收集(data collection) • 資料整合(data integration) • 資料記錄(data archiving) • 氣象圖的產生(map generation)

26. 天氣圖系統的分層架構(Layered Architecture for Weather Mapping System)

27. 系統內容和系統使用模型(System Context and Models of Use) • 系統內容 • 一個靜態模型，用來描述在環境中的其它系統 • 用子系統模型(subsystem model)展示其它系統 • 接續的投影片展示氣象站系統周圍的系統 • 系統使用的模型 • 一個動態的系統，描述系統如何和它所在環境的溝通(interface) • 利用”使用案例”(use-cases)來描繪互動(interactions)的情形

28. 氣象圖系統的子系統(Subsystems in the Weather Mapping System)

29. 氣象台使用案例(Use-Cases for the Weather Station)

30. 使用案例描述

31. 架構設計(Architecture Design) • 在了解系統和系統環境的互動後，開始系統架構設計 • 分層式架構(layered architecture)適用於氣象台系統 • 介面層(interface layer)負責處理溝通(handle communications) • 資料收集層(data collection layer)負責管理儀器(manage instruments) • 儀器層(instrument)負責採樣資料(collect date)

32. 氣象台架構(Weather Station Architecture)

33. 物件識別(Object Identification) • 物件導向設計最困難的部份是識別物件(object)或物件類別(object class) • 物件識別(object identification)沒有神奇的公式(magic formula) • 它依賴系統設計者的技巧(skill)、經驗(experience)及對該領域所具備的知識 • 物件識別是一個反覆的行程(iterative process) • 不可能第一次就識別的完全

34. 識別方法(Approaches to Identification) • 對系統用自然語言的描述，使用符合語法(grammatical)的方法 • 在應用領域中識別可觸摸的實體 • 利用行為方法(behavior approach)，識別哪些物件參與哪些行為 • 利用情境為基礎的分析(scenario-based analysis) • 識別在各情境中的物件(objects)、屬性(attributes)和方法(methods)

35. 氣象台物件類別(Weather Station Object Classes) • 地面溫度計(ground thermometer)、風速計(anemometer)和氣壓計(barometer) • 應用領域的物件，是在系統中與儀器相關的硬體物件 • 氣象台(weather station) • 氣象台和其環境的基本介面(basic interface) • 它反映使用案例模型(use-case model)中識別出的互動(interactions)

36. 氣象資料 • 封裝(encapsulate)來自儀器的彙整資料

37. 氣象台物件類別(Weather Station Object Classes)

38. 更深一層的物件和物件的細緻化(Further Objects and Object Refinement) • 使用領域知識以識別更多物件和操作 • 氣象台需要有唯一(unique)的識別碼 • 氣象台坐落於遙遠的地區，必須自動回報儀器的錯誤，因此必須有自我檢查的屬性和操作 • 主動或被動物件(active or passive objects) • 本例中，物件是被動的，當被要求時才進行採集資料，而非獨立自主的(autonomously)

39. 設計模型(Design Models) • 設計模型表示物件、物件類別及這些實體間的關係(relationships) • 靜態模型(static model) • 以物件類別和關係描述系統的靜態架構(static structure) • 動態模型(dynamic model) • 描述物件間的動態互動(dynamic interactions)

40. 設計模型的實例 • 子系統模型(sub-system model) • 表示將物件邏輯性地組成緊密結合的子系統(logical groupings of objects into coherent subsystems) • 循序模型(sequence model) • 表示物件互動的順序(sequence of object interactions) • 狀態機模型(state machine model) • 展示個別物件(individual objects)如何因回應事件而改變狀態(change state in response to events)

41. 其他模型，包括使用案例模型(use-case models)、聚集模型(aggregation models)和一般化模型(generalization models)等

42. 子系統模型(Subsystem Models) • 展示如何把設計組織成邏輯相關的物件群組(logically related groups of objects) • 在UML中，它用套件(package)來表示，是一種封裝結構(encapsulation construct) • 它是一個邏輯模型(logical model) • 實際物件的組織(organization)可能會有所不同

43. 氣象台子系統(Weather Station Subsystems)

44. 循序模型(Sequence Model) • 循序模型表示物件互動發生的順序 • 物件水平式地排列在最頂端 • 垂直方向則代表時間，模型是由上而下(top to bottom)閱讀 • 標示的箭頭(labeled arrows)代表物件間的互動，不同樣式的箭頭代表不同型態的互動 • 物件時間軸(object lifeline)上的細長方形代表系統中主控物件的時間

45. 資料採集順序(Data Collection Sequence)

46. 狀態圖(Statecharts) • 表示物件如何回應(respond)不同的服務請求(service request)以及這些請求如何觸發(trigger)狀態轉換(state transition) • 若物件狀態是Shutdown，則回應Startup()訊息(message) • 若物件處於等待狀態(waiting state)，則該物件是等待後續的訊息(further message)

47. 若reportWeather()被呼叫，則系統轉移到彙整狀態(summarizing state) • 若calibrate()被呼叫，則系統移轉到calibrating狀態 • 當接受到系統時鐘(clock)的訊號，則進入收集狀態(collecting state)

48. 氣象台狀態圖(Weather Station State Diagram)

49. 物件介面規格(Object Interface Specification) • 物件介面須被指定(specified)，以便同時設計物件和其它元件 • 物件可能會有許多介面(several interfaces)，他們是方法(methods)所提供的觀點(viewpoints) • UML使用類別圖(class diagrams)制訂介面規格(interface specification)

50. 氣象台介面(Weather Station Interface)