案例研究：外送平台之使用案例圖

以 UML 模擬現實需求——實用指南

1. 引言

在現代軟體開發中，使用案例圖是從使用者觀點捕捉功能需求的基本工具。本案例研究對一個真實的使用案例圖進行詳細分析，該圖適用於外送平台，並採用PlantUML 語法作為建模語言。其目標不僅是展示哪些元素被用於圖中，還包括為何它們被選中——強調實務建模決策, 慣例，以及常見陷阱.

本案例研究同時服務於初學者學習 UML與從業者精進其建模實務。它將圖中的每個元素拆解，說明其目的，並探討現實世界的影響。

2. 系統概覽

該外送平台是一個數位市場，連接：

• 顧客（訂購食物的個人），
• 餐廳（餐點提供者），
• 司機（送貨人員），
• 外部支付閘道（處理交易的外部系統）。

該平台允許用戶瀏覽餐廳、下單、追蹤送貨、管理付款並套用優惠活動。該系統與外部服務（如支付處理商）整合，內部不處理付款邏輯。

PlantUML 程式碼：

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

' 所有參與者均在矩形外定義
actor Customer
actor "已註冊顧客" as RegCustomer
actor "餐廳員工" as Restaurant
actor Driver
actor "支付處理商" as PaymentGW

rectangle "外送平台" {

(瀏覽餐廳)
(下單)
(追蹤訂單)
(管理菜單)
(接受/準備訂單)
(送達訂單)
(處理付款)
(發出退款)
(套用優惠碼)
(使用錢包)
(卡片付款)
(數位錢包付款)

' 關聯 – 箭頭跨越邊界
Customer --> (瀏覽餐廳)
RegCustomer --> (下單)
RegCustomer --> (追蹤訂單)

Restaurant --> (管理菜單)
Restaurant --> (接受/準備訂單)

Driver --> (送達訂單)

PaymentGW --> (處理付款)
PaymentGW --> (發出退款)

' 包含
(下單) ..> (處理付款) : <<include>>

' 延伸
(下單) <.. (套用優惠碼) : <<extend>>
(處理付款) <.. (使用錢包) : <<extend>>

' 泛化
(處理付款) <|-- (卡片付款)
(處理付款) <|-- (數位錢包付款)
}

' 參與者泛化（也在外部）
Customer <|-- RegCustomer

note right of PaymentGW
外部支付閘道
(Stripe, PayPal, Adyen, ...)
end note

note bottom of (套用優惠碼)
選填 – 僅在輸入有效碼時適用
end note

@enduml

✅ 關鍵洞察：此圖表著重於外部互動——它顯示系統為其用戶和系統所做的，而非其實現方式。

3. 圖表元素：深入探討與實際意義

以下為圖表中使用的每個 UML 元素的完整解析，包含現實世界的詮釋與建模理由。

4. 關鍵建模決策與理由

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

• 最佳實踐：參與者代表角色外部的系統。
• 為何重要：可避免系統組件與外部實體之間的混淆。
• 範例: 駕駛員並非該平台的模組——他們是與平台互動的第三方角色。

📌 專業提示：如果所有參與者都在邊界內，則會暗示系統包含了他們——這具有誤導性。

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

• 若無泛化，您必須繪製：
  PlantUML
  
  
  在 VPasCode 中編輯 PlantUML
  

  PlantUML Edit PlantUML in VPasCode

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

  Edit PlantUML in VPasCode

  
  
  在 VPasCode 中編輯 PlantUML
  
• 若有泛化，您只需：
  PlantUML
  
  
  在 VPasCode 中編輯 PlantUML
  

  PlantUML Edit PlantUML in VPasCode

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

  Edit PlantUML in VPasCode

  
  
  在 VPasCode 中編輯 PlantUML
  
• 結果：更清晰、更易維護的圖表。

📌 最佳實踐：當專業參與者繼承了更一般參與者的所有行為時，請使用參與者泛化。

✅ 為何<<include>>與<<extend>>被正確使用

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

• 包含: 基礎 ..> 已包含
• 擴展: 擴充 <.. 基礎

✅ 為什麼 處理付款具有一般化

• 卡片付款 和 數位錢包付款是 專門形式 的 處理付款.
• 這顯示該平台支援 多種付款方式，但它們都遵循相同的核心流程。
• 一般化允許 共用行為 和 未來的可擴展性.

📌 使用案例：新增另一種付款方式（例如 Apple Pay）將只是對「處理付款」的又一項一般化處理付款.

5. 現實世界的詮釋與已回答的問題

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

✅ 商業價值：該圖表清楚地傳達了系統做什麼, 誰使用它，以及哪些行為是強制性的，哪些是選擇性的.

6. 展示的常見建模準則

該圖表展示了幾項最佳實踐在 UML 用例建模中的應用：

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

7. 潛在改進與評析

雖然該圖表相當強健，但以下為建設性建議用於改進：

🔧 1. 新增標記以增進清晰度

actor "Payment Processor" as PaymentGW <<system>>

• 原因: 明確指出這是外部系統，而非人類角色。
• 效益: 減少歧義，特別是在大型模型中。

🔧 2. 釐清 套用優惠碼延伸條件

目前：

note bottom of (Apply Promo Code)
  選填 – 僅在輸入有效代碼時顯示
end note

• 更佳做法: 使用 條件標記或 保護條件於 <<extend>>箭頭上：

(下訂單) <.. (套用優惠碼) : <<extend>> [有效優惠碼]

• 為什麼: 比註解更精確——直接將延伸關聯至條件。

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

• 目前遺漏，但對顧客和餐廳而言很可能都很重要。
• 可作為一個 註冊顧客 使用案例。

🔧 4. 將相關使用案例分組（選填）

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

package "訂單管理" {
    (下訂單)
    (追蹤訂單)
    (套用優惠碼)
}
package "付款" {
    (處理付款)
    (使用錢包)
    (卡片付款)
    (數位錢包付款)
}

• 效益: 提升可擴展性與可讀性。

8. 接下來要做什麼？

本案例研究已展示如何透過一個 結構良好的使用案例圖 清晰且簡潔地捕捉複雜的業務邏輯。為了加深您的理解，以下是 建議的後續步驟:

🔄 選項 1：以餐廳為中心的視角

從「餐廳的觀點」來建模同一領域:

• 聚焦於「管理菜單」, 接受／準備訂單」, 查看訂單」, 更新狀態」.
• 顯示「餐廳」作為主要參與者。
• 包含「顧客」作為次要參與者（例如，「顧客」發送訂單 → 「餐廳」接收訂單）。

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

🔄 選項 2：新增更多延伸點

強化「下訂單 與：

• 套用優惠券（若促銷代碼無效 → <<延伸>> 並顯示錯誤訊息)
• 請求特殊說明（選填）
• 排程訂單（用於未來配送）

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

📌 經驗法則:

• 使用 <<include>> 當行為 必須發生.
• 使用 <<extend>> 當行為 可能發生 在特定條件下。

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

用於更深入的分析：

• 序列圖：顯示 下訂單 → 處理付款 → 交付訂單包含參與者與系統之間的訊息。
• 活動圖: 模擬其中的決策點處理付款（例如：卡片被拒 → 重試或切換至電子錢包）。

9. 結論

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

• 釐清系統範圍，
• 捕捉業務規則，
• 指導開發工作，
• 預防誤解。

「外送平台」圖表是一個有力的範例，展現了：

• 正確使用 UML 標記，
• 合理的建模決策，
• 清晰的關注點分離，
• 以及註解與泛化的有效運用。

透過遵循此處所示的原則——以目標為導向的命名, 以及正確使用包含/擴展, 參與者泛化，以及 策略性地使用註解 — 您可以建立同時兼具 準確 以及 可執行.

✅ 最終重點