案例研究：食物外送平台的用例圖

使用UML建模現實世界的需求——實用指南

---

1. 簡介

在現代軟體開發中，用例圖是從使用者觀點捕捉功能需求的基礎工具。本案例研究詳細分析了一個真實的用例圖用於一個食物外送平台，使用PlantUML語法作為建模語言。目標是不僅展示圖中使用了哪些元素，還展示選擇這些元素的緣由——強調什麼元素被使用，而且為什麼它們被選擇的原因——強調實務上的建模決策, 慣例，以及常見的陷阱.

本案例研究同時適用於學習UML的初學者以及致力於提升其建模技巧的實務工作者它剖析圖中的每一項元素，說明其目的，並探討現實世界的影響。

---

2. 系統概觀

這個食物外送平台是一個數位市場平台，連接：

• 顧客（訂購餐點的個人），

• 餐廳（餐點供應者），

• 駕駛員（送餐人員），

• 外部支付網關（處理交易的第三方系統）。

該平台使使用者能夠瀏覽餐廳、下單、追蹤送達、管理付款並套用優惠。系統整合外部服務，例如支付處理器，且不會在內部處理支付邏輯。

PlantUML程式碼：

@startuml
skinparam monochrome true
skinparam shadowing false

從左到右方向

‘ 所有參與者均定義於矩形之外
actor 顧客
actor “註冊顧客” as RegCustomer
actor “餐廳員工” as Restaurant
actor 駕駛員
actor “支付處理器” as PaymentGW

rectangle “餐食送達平台” {

（瀏覽餐廳）
（下單）
（追蹤訂單）
（管理菜單）
（接受／準備訂單）
（送達訂單）
（處理付款）
（發放退款）
(應用優惠碼)
(使用錢包)
(信用卡支付)
(數位錢包支付)

‘ 關聯 – 箭頭跨越邊界
顧客 –> (瀏覽餐廳)
註冊顧客 –> (下訂單)
註冊顧客 –> (追蹤訂單)

餐廳 –> (管理菜單)
餐廳 –> (接受 / 準備訂單)

駕駛 –> (送達訂單)

支付網關 –> (處理支付)
支付網關 –> (發放退款)

‘ 包含
(下訂單) ..> (處理支付) : <<包含>>

‘ 延伸
(下訂單) <.. (應用優惠碼) : <<延伸>>
(處理支付) <.. (使用錢包) : <<延伸>>

‘ 專化
(處理支付) <|– (信用卡支付)
(處理支付) <|– (數位錢包支付)
}

‘ 行動者專化 (亦適用於外部)
顧客 <|– 註冊顧客

note right of PaymentGW
外部支付網關
(Stripe、PayPal、Adyen、…)
結束註解

note bottom of (Apply Promo Code)
可選 – 僅在輸入有效碼時
結束註解

@enduml

✅ 關鍵洞察: 該圖表著重於外部互動——它顯示系統所做的事提供給使用者與系統的內容，而非其實作方式。

---

3. 圖表元素：結合實際意義的深入探討

以下是圖表中所使用每個 UML 元素的完整解析，並附上現實世界的詮釋與建模考量。

#	元素	符號	含義與目的	建模決策／註解
1	系統邊界	矩形「外送平台」	定義系統的範圍被建模系統的範圍。所有內部的使用案例皆屬於此系統。	名稱簡潔且具描述性。在企業環境中，可能會使用較長的名稱（例如「客戶訂單管理系統」）。
2	主要人類參與者	參與者 客戶, 參與者 駕駛員	代表外部角色啟動或參與使用案例的。	名稱簡單直觀，避免不必要的範疇標記，例如<<人物>>除非大型模型需要。
3	帶別名的參與者	參與者「餐廳員工」作為餐廳	允許將較長且具描述性的參與者名稱縮短，以在連接中保持清晰。	當參與者名稱包含空格或較為冗長時非常有效。可減少雜亂並提升可讀性。
4	外部系統參與者	參與者「付款處理器」作為付款網關	模型第三方系統平台所互動的。	無範疇標記«系統»被使用——在輕量級圖表中可接受。然而，加入«系統»可在複雜系統中明確意圖。
5	參與者泛化	`客戶 <	— 登記客戶`	表示註冊客戶是訪客客戶.
6	普通關聯	顧客 --> (瀏覽餐廳)	顯示該參與者啟動或參與該用例。	實線 = 通訊。方向由參與者指向用例（不需要箭頭）。
7	«包含» 關係	(下訂單) ..> (處理付款) : <<包含>>	處理付款是總是必要在下訂單時。	箭頭指向從包含 → 被包含。這非常重要：下訂單 包含 處理付款作為必要步驟。
8	«延伸» 關係	(下訂單) <.. (套用促銷代碼) : <<延伸>>	套用促銷代碼是可選的且僅在特定條件下發生。	箭頭指向從延伸 → 基底。基本用例（下訂單）可以擴展條件性地.
9	用例泛化	（處理付款）<	—（信用卡付款）<br>（處理付款）<	—（數位錢包付款）`
10	註解	PaymentGW 右側的註解 （套用優惠碼）底部的註解	提供上下文說明關於實作或商業規則的說明。	註解被低估但極其珍貴。它們可防止誤解（例如，說明 PaymentGW 是外部系統）。
11	邊界外的參與者	所有參與者參與者的宣告位於矩形之前	強調沒有參與者屬於系統—— 清晰的關注點分離。	兩個標準佈局之一。當參與者眾多或為外部時較為適合。
12	圖示方向	從左到右方向	當左側有多个參與者時，可改善佈局。	提升可讀性。在4至8個參與者時特別有效。替代方案：參與者較少時使用自上而下的佈局。

---

4. 關鍵建模決策與理由

✅ 為何參與者位於系統邊界之外

• 最佳實務：參與者代表角色在系統之外系統之外。

• 為何重要：避免系統組件與外部實體之間產生混淆。

• 範例: 駕駛員並非平台的模組——他們是與平台互動的第三方角色。

📌 專業提示：若所有參與者都在邊界內，會讓人誤以為系統包含他們——這會造成誤解。

---

✅ 為何使用Customer <|-- RegCustomer而非重複連結

• 若無泛化，你必須繪製：

  Customer --> (瀏覽餐廳)
  RegCustomer --> (瀏覽餐廳)
  RegCustomer --> (下訂單)
  

• 使用泛化時，僅需：

  Customer <|-- RegCustomer
  Customer --> (瀏覽餐廳)
  RegCustomer --> (下訂單)
  

• 結果：更乾淨、更容易維護的圖示。

📌 最佳實務：當特定的參與者繼承較一般參與者的全部行為時，請使用參與者泛化。

---

✅ 為什麼 <<包含>> 和 <<延伸>> 被正確使用

關係	目的	方向	範例
<<包含>>	必要子流程	來自 包括 → 被包含	下訂單 必須 包含 處理付款
<<延伸>>	選擇性延伸	來自 延伸 → 基底	套用優惠代碼 擴展 下訂單僅在代碼有效時

❗ 常見錯誤：反轉箭頭方向。請始終記住：

• 包含: 基底 ..> 包含

• 擴展: 擴展 <.. 基底

---

✅ 為什麼 處理付款具有泛化

• 信用卡付款和數位錢包付款是專用形式的處理付款.

• 這顯示平台支援多種付款方式，但它們都遵循相同的基礎流程。

• 泛化允許共享行為 和 未來的可擴展性.

📌 使用案例：新增一種付款方式（例如 Apple Pay）僅是對 的另一種泛化處理付款.

---

5. 實際情境的解釋與問題解答

此圖表不僅是視覺輔助工具——它回答了關鍵的商業與技術問題：

問題	圖表中的答案
主要使用者是誰？	顧客、註冊顧客、餐廳員工、司機、付款網關
未註冊的使用者可以下訂單嗎？	❌ 否——僅有 註冊顧客 可以 下訂單. 顧客 只能 瀏覽餐廳.
付款是否總是必需的？	✅ 是—— 下訂單 包含 處理付款. 必須的。
顧客可以使用促銷代碼嗎？	✅ 是的——但僅限於可選地透過<<擴展>>。僅在輸入有效代碼時才適用。
支援哪些付款方式？	信用卡與數位錢包（透過通用化）。外部系統負責實際處理。
誰負責付款？	外部支付網關——並非平台的一部分。
餐廳可以管理其菜單嗎？	✅ 是的——餐廳參與者與管理菜單以及接受／準備訂單.

✅ 商業價值：此圖表清楚地傳達了系統的功能, 誰在使用它，以及哪些行為是必須的與可選的.

---

6. 展示常見的建模指南

此圖示範了幾個最佳實務在UML用例建模中的

指南	應用方式
使用以目標為導向的用例名稱	下訂單, 追蹤訂單, 套用促銷代碼——全部以動詞開頭，並描述使用者目標。
保持圖示清晰易讀	僅顯示10個用例——對於大多數商業領域而言是理想的（建議範圍為5至12個）。
將外部系統作為參與者	PaymentGW被建模為參與者而非用例，正確地分離了關注點。
使用註解來澄清模糊之處	註解說明PaymentGW是外部系統，且促銷代碼為可選——對於避免誤解至關重要。
使用參與者泛化以減少雜亂	「客戶 <
使用包含和擴展正確地	明確區分強制性與可選行為。

📌 警告：許多圖示誤用<<extend>>來表示「可選」，卻未理解其條件性質延伸的性質。此圖示避免了此錯誤。

---

7. 潛在改進與評論

雖然此圖示很強，但以下是一些建設性建議用於優化：

🔧 1. 增加綱要以提高清晰度

角色「付款處理器」作為 PaymentGW <<系統>>

• 原因：明確指出這是一個外部系統，而非人類角色。

• 好處：減少歧義，特別是在大型模型中。

🔧 2. 明確套用優惠碼延伸條件

目前：

註解位於（套用優惠碼）下方
  可選——僅在輸入有效碼時
結束註解

• 更好：使用條件符號或守護在……之中<<延伸>>箭頭：

（下訂單）<..（套用優惠碼）：<<延伸>> [有效的優惠碼]

• 為什麼：比註解更精確——直接將延伸與條件連結。

🔧 3. 考慮新增一個檢視訂單歷史使用案例

• 目前缺失，但對顧客和餐廳來說可能都很重要。

• 可以作為一個新增註冊顧客使用案例。

🔧 4. 群組相關的使用案例（可選）

對於較大的圖表，將使用案例分組為套件:

套件「訂單管理」{
    （下訂單）
    （追蹤訂單）
    （套用優惠碼）
}
套件「付款」{
    （處理付款）
    （使用錢包）
    （信用卡付款）
    （數位錢包付款）
}

• 好處：提升可擴展性和可讀性。

---

8. 下一步是什麼？

本案例研究顯示了如何透過一個結構良好的使用案例圖能清楚且簡潔地捕捉複雜的商業邏輯。為了加深理解，以下是建議的下一步建議的下一步:

🔄 選項 1：以餐廳為中心的觀點

從以下角度建模相同的領域餐廳的觀點:

• 著重於管理菜單, 接受／準備訂單, 檢視訂單, 更新狀態.

• 顯示餐廳作為主要參與者。

• 包含顧客作為次要參與者（例如顧客送出訂單 →餐廳接收訂單）。

✅ 優勢：揭示不同的系統目標與參與者角色。

🔄 選項 2：增加更多擴展點

增強下訂單 與:

• 應用優惠券 (如果促銷代碼無效 → <<延伸>> 並顯示錯誤訊息)

• 請求特殊指示 (可選)

• 安排訂單 (用於未來送達)

🔄 選項 3：比較 包含 對比 延伸 附範例

使用案例	<<包含>>	<<延伸>>
下訂單 → 處理付款	✅ 必要	❌ 非可選
下訂單 → 應用促銷代碼	❌ 非必要	✅ 條件性
登入 → 驗證身份	✅ 始終需要	❌ 不適用
結帳 → 套用折扣	✅ 始終	✅ 僅當折扣存在時

📌 經驗法則:

• 使用 <<包含>> 當行為發生時 必須發生.

• 使用 <<延伸>> 當行為發生時 可能發生 在某些條件下。

🔄 選項 4：轉換為序列圖或活動圖

用於更深入的分析：

• 序列圖：顯示流程 下訂單 → 處理付款 → 交付訂單 透過參與者與系統之間的訊息傳遞。

• 活動圖：模擬流程中的決策點處理付款 （例如：卡片被拒 → 重新嘗試或切換至錢包）。

---

9. 結論

本案例研究顯示一個精心設計的用例圖 遠不止於視覺草圖——它是一種戰略性溝通工具，其功能包括：

• 明確系統範圍，

• 捕捉業務規則，

• 引導開發，

• 避免誤解。

這個外送平台圖表是一個強而有力的範例，包括：

• 正確使用UML符號，

• 穩妥的建模決策，

• 清晰的關注點分離，

• 有效運用註解與泛化。

透過遵循此處所展示的原則——以目標為導向的命名, 正確使用include/擴展, 演員泛化，以及策略性地使用註解——你可以建立既符合以下條件的使用案例圖準確又可執行.

---

✅ 最終重點

原則	在此適用嗎？	為什麼重要
使用以目標為導向的使用案例名稱	✅ 是	提升清晰度與使用者焦點
保持圖表大小可管理	✅ 是（10個使用案例）	防止認知負荷過重
將外部系統作為參與者	✅ 是	正確的關注點分離
使用註解提供背景資訊	✅ 是	防止誤解
使用泛化以減少重複	✅ 是	使圖表可擴展且易於維護
正確<<包含>> 和 <<擴展>> 方向	✅ 是	確保準確的行為建模

---