程式碼與 UML 設計圖之間的關聯性

從抽象的角度思考 類別(Class)/物件(Object) 的關係

  • 物件是活的!
  • 但是,類別可不是死的 (更不是活的);因為,它僅是對系統的設計契約而已。

問題思考!?
程式原始碼 (Source Code) 對應的是 UML 哪一張設計圖?

推導-1
程式碼 = 靜態結構 = 設計契約 = 類別設計

所以 程式碼 對應的是:UML 類別圖 (Class Diagram)

Ex. 程式碼與類別圖的對應

範例-靜態的程式碼設計契約
範例-程式碼與類別圖的對應關係

使用 UML 類別圖 (Class Diagram)的好處

  • 快速定義類別的結構 (包括類別名稱、屬性與行為)。
  • 過濾程式碼實做的細節,容易聚焦於類別的責任分派 (responsibility assign)設計議題。
  • 可以透過工具,將類別圖轉出至對應的程式碼 (反之亦然)骨架 (skeleton)。

類別圖無法作到 …

  • 無法呈現系統執行期間 (run-time),程序單位之間的呼叫情形。
  • 無法追蹤為完成某一特定功能案例,物件之間的動態相依呼叫關係。
  • 無法掃瞄物件之間的動態連結,是否有違背類別圖的結構設計。


UML 循序圖的作用

  • 循序 (sequence)圖與溝通(communication)圖均屬於物件合作 (collaboration)的呈現。
  • 兩者僅在於呈現的方式不一樣。循序圖呈現的是從上而下循序的訊息傳遞;溝通圖呈現的是自由排列的訊息傳遞格式。
  • 循序圖僅呈現某一特定的功能案例,一般稱之為劇本 (scenario)。為實現該案例,主要參與物件與物件之間的訊息 (message)互動描述。

Ex. 循序圖的範例呈現

圖、循序圖的範例呈現
(點擊圖片鏈接看原圖)圖、循序圖的範例呈現

推導-2
執行期間 (run-time)的應用程式 = 動態關連 = 物件合作

所以 編譯後的程式碼 在系統執行期間所呈現的物件互動,對應的是:
  UML 合作(循序 or 溝通)圖 (Collaboration Diagram)。

繪製循序圖的重點

  • 只表達值得關注的參與物件。
  • 瞭解主要參與物件之間的訊息 (message)傳遞。

如同腳本,表達出某一場戲所安排的主要演員,以及演員之間的互動對話。

※ 延伸參考
o 程式碼與 UML 類別_循序圖 的關係探討 (1)