程式碼與 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)。