在物件導向設計的世界裡，使用案例圖（Use Case Diagram）的包含（<>）與擴展（<>）關係，絕對是讓模型變得「乾淨、可重用、不爆炸」的關鍵技巧。很多團隊一開始畫圖時都直接把所有步驟塞進同一個用例，結果後期改需求就像拔河，改一個地方整個圖都得重畫。
我這幾年帶過不少專案，也在 Visual Paradigm（VP）上面反覆實戰，今天就用比較口語、經驗分享的方式，來談談這兩個關係的真實用法、心得、常犯的錯，以及在 VP 裡怎麼用工具讓自己少踩雷。
1. 核心概念：什麼時候用哪一個？（最重要的一句話）
- <<include>> 包含：「一定會發生」的共用行為，基底用例少了它就不完整。 → 箭頭從基底 → 被包含（Base → Included）
- <<extend>> 擴展：「可能發生」的選項或變形，基底用例本身是完整的，擴展只是額外插進來。 → 箭頭從擴展 → 基底（Extending → Base），而且基底要標出明確的擴展點（Extension Point）。
一句話口訣： 「沒有它不行 → include」 「有它更好，但沒有也OK → extend」
2. 真實專案常見例子（附血淚教訓）
情境：線上購物系統
- 包含（include） 幾乎所有「結帳」、「查訂單」、「取消訂單」都需要「登入會員」。 → 把「登入會員」抽成獨立的用例，然後用 <<include>> 連到各個基底用例。 經驗：如果沒抽出來，後來加了「支援 Google 登入 + 手機驗證」，你得改十幾個用例的敘述，超崩潰。抽出來後只要改一個地方就好。
- 擴展（extend） 「結帳」這個基底用例，正常流程是信用卡付款。 但當使用者輸入「折扣碼」時，才會跳出「套用優惠券」的額外步驟。 → 「套用優惠券」做成 <<extend>>，擴展點命名為「有輸入折扣碼時」。 經驗：很多人忘記定義擴展點，導致箭頭畫了也沒意義，後來 review 時被資深架構師打槍。
另一個常見的血淚案例： 有人把「處理退貨」畫成 <<include>> 到「結帳」，結果邏輯完全錯，因為退貨根本不是結帳一定會做的動作，應該是 <<extend>>（在「收到貨後不滿意」這個條件下才發生）。
3. 優點 vs. 真實痛點（與 VP 如何救你）
優點（真的很爽）
- 包含 → 一次寫共用邏輯，到處重用，測試也只要測一次。
- 擴展 → 核心流程保持乾淨，選配功能獨立開發、獨立測試、上線時 feature toggle 超好控。
- 溝通時老闆一看就懂：「這個是必做，那個是加值服務」。
痛點（常見地雷）
- 包含層層包太多 → 變成「用例 spaghetti」，追蹤超痛苦。
- 擴展點沒寫清楚 → 開發看不懂什麼時候才會觸發。
- 方向畫反 → 最經典的錯誤，review 直接扣分。
- 圖太亂，超過 12 個用例就看不懂誰依賴誰。
Visual Paradigm 怎麼幫你避雷？（我最愛的幾招）
- Resource Catalog：hover 在用例上直接選「Include → Use Case」或「Extend → Use Case」，自動畫對方向，extend 時還會幫你產生一個可編輯的擴展點，超省事。
- AI Use Case Diagram Refinement：畫完一堆後，按一下 AI 精煉，它會直接告訴你「這個應該是 extend 而不是 include」、「這裡可以再抽一個共用包含」，準確率很高，省下 60% 以上整理時間。
- Extend and Include Use Case Analyzer（免費 AI 工具）：這是我現在專案必跑的。 它會自動產生：
- 關係總覽表格（誰包含誰、誰擴展誰）
- 針對單一基底用例的「聚焦子圖」
- 還能吐出 PlantUML 程式碼，方便放進 git 做版本控制。
- Flow of Events 編輯器：寫步驟時可以直接 reference 包含的用例，guard condition 也寫得很清楚，後面轉給開發時幾乎不用再解釋。
4. 實戰 Tips & Tricks（VP 使用者專屬）
- 先別急著畫關係，先把所有主要用例（primary use cases）列出來，標註「必做步驟」與「選配步驟」。
- 命名擴展點要夠具體，例如「Invalid Coupon Code」「After Peak Hour」「Guest Checkout」而不是泛泛的「Special Condition」。
- 包含層級最好控制在 2 層以內，超過就考慮用 Activity Diagram 或 Sequence Diagram 細化，而不是一直疊用例。
- 超過 10 個用例就立刻跑 Analyzer，產生子圖給 PM / 客戶看，否則他們會說「這什麼鬼圖」。
- 用 VP Online 協作時，開啟版本歷史 + 留言功能，改關係時大家可以即時討論，避免來回拉鋸。
- AI Chatbot 超好用，直接問它：「這個登入跟驗證要用 include 還是 extend？」它會給你理由 + 建議畫法。
5. 小結：從理論到落地，就差這幾步
包含與擴展不是 UML 的裝飾品，而是真正能讓你的需求模型「活得久、不用一直大改」的結構化利器。 但純手畫很容易畫歪、畫亂；用了 Visual Paradigm 的 AI 輔助 + Analyzer 之後，真的像開外掛一樣，畫圖速度快 2–3 倍，出錯率大幅下降，後續維護也輕鬆很多。
如果你現在正在畫使用案例圖，建議先：
- 把所有「一定會做」的共用片段找出來 → include
- 把「看情況才做」的變形列出來 → extend + 明確擴展點
- 畫完立刻跑一次 AI Refinement + Analyzer
這樣畫出來的圖，才是真的能幫助團隊，而不是變成牆上的裝飾。