分析与设计阶段–物件导向设计ood.pptVIP

第八章 分析與設計階段 – 物件導向設計(OOD) 軟體工程 -物件導向程式設計與UML系統分析實作 綱要 前言 類別的規劃 物件導向設計階段 (OOD) 建立動態模型 建立設計模型 總結 前言 OOD目標： 將OOA階段的分析模型，繼續透過反覆的修正與演進，使得整個模型能更趨於完備。(即：足以拿來實作之完整類別模型) 手段： 以圖7-4為藍圖，繼續以各種基於好的物件導向設計原則進行檢視。 主要任務 建構互動圖(Interaction Diagram) 建構狀態圖(Statechart Diagram) 建構詳細的類別模型(Detailed Class Diagram) 撰寫虛擬程式碼(Pseudo-Code) 在這之前…類別的規劃 問題： 在OOA階段，「使用者與系統的互動媒介」似乎並不明顯？ 人機介面(Human Interface)： ATM(自動提款機)的輸入裝置 圖形使用者介面(Graphical User Interfaces) 範例探討(1) 一般商務系統至少具備了… 核心類別：”訂單” 功能：顯示訂單明細 假設以GUI為人機介面 (Cont.) 就物件設計的角度來看，顯示訂單明細的功能由”訂單”物件自己來負責，似乎是理所當然！不過… 考慮以下的狀況： 若系統中存在上百個有需要跟使用者直接做輸入輸出的類別，一旦使用者與系統互動的介面需求有所變更時，套用此設計方法將有何影響？ (Cont.) 主要影響： 此時會有很多的類別需要跟著修改(如：上例中的”訂單”) 。 問題根源： 核心類別與使用者介面之間的過度耦合(核心類別被使用者介面綁住了！) 典型解法 隔離核心類別與使用者介面 邊界類別(Boundary Class) 專司使用者介面 實體類別(Entity Class) 即核心類別 (通常為永續物件(Persistent Object)) 注意圖中的相依關係 理論上，核心類別對邊界類別一無所悉。 (Cont.) 變更訂單介面等邊界類別(如：Form/Frame、Edit、 Button)，並不用跟著修改”訂單”類別。 範例探討(2) 基於上例，考慮另一個需求： 假設透過邊界類別需要完成的是 - ”替某顧客建立訂單的程序” 可能之類別結構以及物件合作關係如下… (Cont.) 部分流程控制的工作將落到邊界類別 邊界類別需協調多個實體類別(如”顧客”、”訂單”以及”訂購明細”)來完成登錄程序。 考慮同樣的狀況：當使用者介面需求有所變更時… 儘管實體類別不需修改，但邊界類別中的部分商務邏輯(控制流程)卻還是得重新撰寫! 再次隔離… 在實體類別與邊界類別間加上控制類別(Control Class) 由控制類別包辦商務邏輯相關的控制流程 (Cont.) 此時邊界物件便不需涉及特定之控制流程，就算邊界物件有所變更時，嵌在控制物件中的控制流程仍可被保留下來。 此外，許多錯誤處理的相關動作，也可由控制物件集中處理，不需分散在邊界物件中。 小結 對類別作如此細膩的切割動作固然需要不少時間成本，但將有利於系統日後的擴充與維護。 依照類別(物件)的性質可區分成： 邊界類別(Boundary Class)： 負責使用者介面 實體類別(Entity Class)： 負責問題領域的核心資料 控制類別(Control Class)： 負責邊界物件與實體物件的協調(流程控制) (Cont.) 其他應用： 資料庫存取 (更換不同的資料庫系統也是很常見的事情) Note：此概念源自於MVC (Model-View-Controller) Pattern。 物件導向設計階段 (OOD) 主要執行步驟，細分如下： 加入邊界類別與控制類別 建構互動圖(Interaction Diagram) 建構狀態圖(Statechart Diagram) 建構詳細的類別模型(Detailed Class Diagram) 決定類別行為(Operation) 加入設計階段的類別 決定可見度(Visibility) 決定資料型態 撰寫虛擬程式碼(Pseudo-Code) Case-Study：加入邊界類別與控制類別 考量是否需要控制類別 被協調的兩端在性質上是否有明顯分野 例如：邊界類別與實體類別之間 被協調的兩端是否有需求變更之虞 例如：軟體元件或(類別)函示庫 通常… 使用者(Actor)與Use Case之間，會是置入控制類別的適當位置 以訂房程序為例 訂房邊界類別 泛指所有相關的視窗元件 (為簡化起見) 資料庫控制類別 專司資料庫存取動作 降低實體類別與資料庫介面之間的耦合性 (Cont.) Note: “訂房控制類別”與”資料庫控制類別”均有機會指涉到許多實體類別，這跟實際運作的流程有關，在此暫時省略這些關係。 C