本章探討 UML 圖的正確使用方式——何時該畫、何時不該畫、畫了之後怎麼處理。核心觀點是：圖本身不是目的，溝通才是。
為什麼要建模？#
在其他工程領域，模型（Model）的價值在於用低成本驗證設計是否可行。建築師用藍圖確認結構強度，電子工程師用電路圖模擬信號行為。然而軟體模型的價值並不如此明確：
- 軟體的 UML 圖無法像建築藍圖那樣被驗證——你無法在圖上跑測試
- UML 圖能否有效檢驗設計，取決於設計者的經驗與判斷力
- 在編寫程式碼之前畫出完整的 UML 設計，其成本效益並不總是正面的
注意： 不要因為「流程規定」或「心理上覺得該有文件」就畫 UML。UML 圖的唯一正當理由是：它比直接寫程式碼更能幫助你思考或溝通。
有效使用 UML#
UML 擅長的事#
- 溝通設計概念：在白板上用幾個方框和箭頭向同事解釋一個設計想法
- 提供路線圖（Road Map）：幫助新成員理解系統的高層架構
Figure 14.4: Road map diagram
UML 不擅長的事#
- 演算法細節：序列圖表達不了複雜的條件邏輯與迴圈，程式碼本身更加清楚
- 完整的系統規格：大量的 UML 圖最終會與程式碼脫節，變成維護負擔
Figure 14.1: LoginPage
Figure 14.2: BubbleSorter
Figure 14.3: BubbleSorter sequence diagram
技巧： 像
BubbleSorter這樣的演算法，用序列圖反而比程式碼更難理解。遇到這種情況，直接看程式碼才是最有效的溝通方式。
迭代式精煉（Iterative Refinement）#
設計 UML 圖時，應採用快速迭代的方式，而非一次畫到完美。作者推薦以下步驟：
- 先畫行為：用協作圖或序列圖描述一個使用場景
- 再畫結構：根據行為圖推導出對應的類別圖
- 快速循環：每輪迭代約五分鐘，動態圖與靜態圖交替精煉
Figure 14.5: A bad but all too common example
手機範例#
以設計手機軟體為例，展示了如何從一個簡單的協作圖出發，逐步推導出類別結構：
Figure 14.6: A simple sequence diagram
Figure 14.8: Continuation of Figure 14-7
Figure 14.9: Collaboration diagram
Figure 14.10: Cell phone collaboration diagram
Figure 14.11: Cell phone class diagram
當發現 Button 直接依賴 Dialer 會造成耦合問題時，透過引入抽象介面來隔離依賴：
Figure 14.12: Isolating Button from Dialer
Figure 14.13: Adapting Buttons to Dialers
Figure 14.14: Adding adapters to the dynamic model
何時該畫圖#
以下情境適合使用 UML：
- 團隊需要達成共識：多人對設計有歧見時，白板上的圖有助於聚焦討論
- 探索設計方案：快速比較不同設計的優劣
- 向他人解釋設計：新成員入職、程式碼審查、設計分享會
何時不該畫圖#
以下情境不適合使用 UML：
- 因為流程規定所以畫圖——這產出的是無用的文件
- 因為覺得應該有文件所以畫圖——出於罪惡感的產出品質不佳
- 試圖在寫程式碼之前畫出完整設計——這是瀑布式思維
- 畫給別人去實作——設計者本人不寫程式碼的圖通常脫離現實
重點： 大多數 UML 圖都應該是短命的。在白板上畫、討論完、拍照存檔（甚至不存），然後擦掉。持久保存的圖需要持續維護成本，而這個成本通常被低估。
CASE 工具#
作者對 CASE（Computer-Aided Software Engineering）工具持保留態度：
- 大多數情況下，白板 + 拍照就足夠了
- CASE 工具產出的圖往往過於精美，反而阻礙了快速迭代
- 除非團隊確實需要長期維護某些設計文件，否則不建議投資 CASE 工具
文件#
軟體文件應該遵循以下原則：
- 簡短：一個百萬行程式碼的系統，25 到 200 頁的設計文件就夠了
- 重點明確：只記錄最重要的設計決策與架構概念
- 程式碼是最終的真相：文件只是輔助，不要試圖讓文件取代程式碼
補充： Martin 的文件第一定律同樣適用於 UML 圖：除非需求迫切且具重要性，否則不要產出文件。