用例圖：實用指南

一個用例圖是一種 UML 行為圖，顯示外部使用者或系統如何與系統互動。它著重於從參與者的角度來看系統做什麼而非內部實作細節。

用例圖在需求分析階段特別有用，因為它們提供了系統功能與範圍的高階視圖。

1. 用例圖顯示什麼

用例圖通常包含：

• 系統邊界— 定義被建模系統內部的內容。

• 參與者— 與系統互動的外部使用者、組織、裝置或系統。

• 用例— 系統提供的目標或服務。

• 關聯— 參與者與用例之間的通訊連結。

• 用例之間的關係— 例如<<包含>>與<<延伸>>.

• 泛化— 參與者或用例之間的繼承關係。

用例圖通常不顯示：

• 演算法步驟

• 資料庫資料表

• 程式類別

• 內部工作流程

• 詳細的用戶介面佈局

• 隨時間變化的訊息序列

這些細節以活動圖、類別圖、序列圖或狀態圖來呈現會更為恰當。

2. 關鍵概念

系統邊界

系統邊界是一個圍繞屬於該系統的用例的矩形。

例如，在一個線上購物系統中：

+--------------------------------------+
|        線上購物系統        |
|                                      |
|  (瀏覽商品)                   |
|  (下訂單)                       |
|  (進行付款)                      |
+--------------------------------------+

參與者保持在邊界之外，因為它們是系統外部的實體。

邊界有助於釐清範圍的系統。若某項功能位於邊界之外，則該被建模的系統不會實現此功能。

參與者

一個參與者是指任何與系統互動以達成目標的外部實體。

參與者可能包括：

• 人類使用者

• 外部應用程式

• 硬體裝置

• 其他組織

• 時間或排程事件（當被建模為外部觸發器時）

範例：

• 顧客

• 圖書館員

• 金流閘道

• 管理員

• 電子郵件服務

參與者代表一個角色，不一定是特定的人。例如，「客戶」通常比「亞歷克斯」更好。

參與者可以是：

• 主要參與者——啟動互動以達成目標。

• 支援參與者——為系統提供服務。

例如，客戶可能啟動「下訂單」，而支付閘道則支援「處理付款」。

使用案例

一個「使用案例」代表系統所提供的有意義的目標或服務。

良好的使用案例名稱通常遵循以下格式：

動詞 + 名詞

範例：

• 註冊帳戶

• 搜尋目錄

• 提交申請

• 產生報表

• 取消預約

• 處理付款

使用案例應描述可觀察的結果，而非內部實作步驟。

建議使用：

下訂單

而非：

驗證訂單物件

第二項描述的是內部作業，而非使用者目標。

關聯

關聯是參與者與使用案例之間的通訊連結。

這表示該參與者參與或啟動該使用案例。

客戶 ---- (下訂單)

關聯通常不表示順序、控制流程或方向。若互動的順序至關重要，請使用序列圖或活動圖。

3. 使用案例之間的關係

<<include>>

使用「<<include>>」，當一個使用案例「總是使用另一個使用案例時。

例如，下訂單可能總是需要驗證：「

（下訂單）..>（驗證客戶）: <<include>>

基礎使用案例依賴於被包含的使用案例。

使用「include」，當：「

• 行為是強制性的。

• 行為被多個使用案例重複使用。

• 將行為抽取出來可提升清晰度。

範例：「

（提領現金）..>（驗證卡片）: <<include>>
（檢查餘額）..>（驗證卡片）: <<include>>

兩個使用案例都必須進行卡片驗證。

<<extend>>

使用「<<extend>>」，當額外行為是選填的，或條件式地插入至基礎使用案例時。

（套用折扣）..>（下訂單）: <<extend>>

折扣行為僅在符合資格條件時才會發生。

使用「extend」，當：「

• 行為是選填的。

• 它僅在特定條件下發生。

• 基礎用例無需它即可完整完成。

範例：

• 「新增禮品包裝」擴充「下訂單」。

• 「申請退款」擴充「取消訂閱」。

• 「發送促銷郵件」擴充「完成註冊」。

箭頭從擴充用例指向基礎用例。

泛化

泛化表示參與者或使用案例之間的「是一種」關係。

例如：

高級客戶 --|> 客戶

高級客戶是一種客戶，並繼承客戶的互動。

當多個參與者共享共同行為時，參與者泛化可能很有用：

管理員 --|> 員工
圖書館員 --|> 員工

謹慎使用泛化。若關係僅為「使用」或「參與」，關聯通常更為合適。

4. 主要參與者與支援參與者

考慮一個線上付款情境：

• 「客戶」是主要參與者，因為他們啟動購買行為。

• 「付款閘道」是支援參與者，因為它根據系統請求處理付款。

一個簡單的模型可能如下所示：

客戶 ---- (下訂單)
(下訂單) ---- 付款閘道

此區分很有用，因為它釐清了誰從用例中受益，以及涉及哪些外部系統。

5. 如何識別用例

發現用例的實用方法是詢問：

1. 誰使用該系統？

2. 每個參與者希望達成什麼目標？

3. 該系統提供哪些服務？

4. 哪些事件會觸發系統行為？

5. 該系統必須與哪些外部系統進行互動？

6. 哪些行為是必須執行的？

7. 哪些行為是選填或條件性的？

針對每個參與者，列出其目標：

目標應對參與者有意義。避免將每個小型系統操作都轉化為用例。

6. 命名準則

使用清晰且以目標為導向的名稱。

良好範例：

• 建立帳戶

• 更新個人資料

• 提交索賠

• 追蹤貨運

• 核准請求

• 產生發票

避免使用模糊的名稱：

• 系統處理

• 處理資料

• 使用者功能

• 執行作業

避免過度技術細節：

• 執行 SQL 查詢

• 呼叫 REST 端點

• 建立 PaymentService 執行個體

這些可能是有效的實作步驟，但通常不適合用作高階使用案例。

7. 範例：圖書館管理系統

假設圖書館系統支援以下功能：

• 會員搜尋書籍

• 會員借書

• 會員還書

• 館員管理目錄

• 逾期通知

• 罰款處理

可能的參與者：

• 會員

• 館員

• 通知服務

• 付款服務

可能的使用案例：

• 搜尋目錄

• 借書

• 歸還書籍

• 計算罰款

• 繳納罰款

• 管理目錄

• 發送逾期通知

關係：

• 借書包含檢查會員資格。

• 借書包含檢查書籍可用性。

• 歸還書籍包含計算罰款。

• 繳納罰款與付款服務互動。

• 發送逾期通知與通知服務互動。

8. PlantUML 範例

以下 PlantUML 程式碼會建立圖書館系統的用例圖：

@startuml
left to right direction

title 圖書館管理系統 - 用例圖

actor 會員
actor 圖書館員
actor "通知服務" as Notification
actor "付款服務" as Payment

rectangle "圖書館管理系統" {

  usecase "搜尋目錄" as UC_Search
  usecase "借書" as UC_Borrow
  usecase "歸還書籍" as UC_Return
  usecase "檢查會員資格" as UC_CheckMember
  usecase "檢查書籍可用性" as UC_CheckAvailability
  usecase "計算罰款" as UC_CalculateFine
  usecase "繳納罰款" as UC_PayFine
  usecase "管理目錄" as UC_ManageCatalog
  usecase "發送逾期通知" as UC_Notify
}

會員 --> UC_Search
會員 --> UC_Borrow
會員 --> UC_Return
會員 --> UC_PayFine

圖書館員 --> UC_ManageCatalog
圖書館員 --> UC_Borrow
圖書館員 --> UC_Return

付款 --> UC_PayFine
通知 --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>
UC_Return ..> UC_CalculateFine : <<include>>

UC_Notify ..> UC_Return : <<extend>>

@enduml

9. 範例說明

參與者

actor 會員
actor 圖書館員
actor "通知服務" as Notification
actor "付款服務" as Payment

此圖形模擬了兩位人類參與者與兩個外部服務。

別名，例如as Notification可讓較長的名稱在後續更容易引用。

系統邊界

矩形「圖書館管理系統」{
    ...
}

該矩形定義了系統的範圍。矩形內的使用案例由圖書館系統提供。

參與者關聯

會員 --> UC_搜尋
會員 --> UC_借閱

這些關聯顯示會員可以搜尋目錄並借閱書籍。

在基本的使用案例圖中，箭頭方向通常不具有語意上的重要性；其主要用途是使圖表更易於閱讀。

包含關聯

UC_借閱 ..> UC_檢查會員 : <<include>>
UC_借閱 ..> UC_檢查可用性 : <<include>>

借閱書籍始終需要會員資格與可用性檢查，因此這些被建模為包含的使用案例。

擴展關聯

UC_通知 ..> UC_歸還 : <<extend>>

這表示逾期通知行為是與歸還書籍相關的額外行為。

然而，在實際的需求模型中，更自然的设计可能是將「發送逾期通知」與排程流程或參與者（例如「圖書館排程員」）關聯。最佳的關係取決於實際的業務規則。

10. 更詳細的使用案例規格

圖表提供概覽，但每個重要的使用案例通常都應附有文字規格。

使用案例：借閱書籍

用例圖不應試圖包含所有細節。圖表提供地圖；規格說明提供行為。

11. PlantUML 語法參考

宣告參與者

actor Customer
actor "Payment Gateway" as Gateway

宣告用例

usecase "Place Order" as PlaceOrder
usecase "Process Payment" as ProcessPayment

建立系統邊界

rectangle "線上商店" {
    usecase "瀏覽產品" as Browse
    usecase "下訂單" as Order
}

連接參與者與使用案例

Customer --> Browse
Customer --> Order

包含

Order ..> ProcessPayment : <<include>>

延伸

ApplyCoupon ..> Order : <<extend>>

參與者泛化

PremiumCustomer --|> Customer

套件分組

套件可視覺化地分組相關的使用案例：

rectangle "銀行系統" {
  package "帳戶管理" {
    usecase "開立帳戶" as OpenAccount
    usecase "關閉帳戶" as CloseAccount
  }

  package "付款" {
    usecase "轉帳" as TransferFunds
    usecase "繳費" as PayBill
  }
}

註解

note right of PlaceOrder
  客戶在下單前必須經過身份驗證。
end note

12. 改善圖表佈局

PlantUML 會自動佈局圖表，但有多種技巧可提升可讀性。

控制方向

由左至右的方向

當參與者應顯示在兩側、用例顯示在中心時，這通常很有用。

其他常見方向包括：

由上至下的方向

使用別名

與其重複長名稱：

usecase "驗證客戶身份" 作為 VerifyIdentity

然後引用：

RegisterAccount ..> VerifyIdentity : <<include>>

歸納相關的使用案例

使用套件或巢狀矩形來區分功能區域：

package "訂單管理" {
    usecase "建立訂單" as CreateOrder
    usecase "取消訂單" as CancelOrder
}

避免過度交叉

當過多線條交叉時，圖表將難以閱讀。您可以透過以下方式改善：

• 將相關參與者置於其使用案例附近

• 將使用案例分組至套件中

• 將單一大型圖表拆分為多個較小的圖表

• 使用別名以建立清晰的參照

• 避免不必要的關聯

13. 常見錯誤

將內部功能建模為使用案例

這通常過於技術性：

驗證資料庫連線
序列化請求
呼叫付款 API

優先選擇具有外部意義的目標：

進行付款
提交申請
產生報表

將每個參與者視為人類

外部系統與裝置也可作為參與者：

• 付款閘道

• 身分提供者

• 倉儲系統

• 條碼掃描器

• 通知服務

使用「include」來表示可選行為

若行為為可選，請使用「延伸 而非 包含.

不正確：

下訂單 ..> 套用優惠券 : <<包含>>

若套用優惠券為可選，請使用：

套用優惠券 ..> 下訂單 : <<延伸>>

使用 延伸 用於必要行為

若某行為必然發生，通常應以 包含.

下訂單 ..> 驗證客戶 : <<包含>>

無意義地直接連接使用案例

兩個使用案例之間的連線應代表有效的 UML 關係。避免僅暗示使用案例之間存在某種關聯的任意連線。

建立單一龐大圖表

使用案例圖應在高層級清晰傳達資訊。若包含數十個參與者與使用案例，請建立多個圖表，並依子系統或業務領域進行組織。

顯示順序

使用案例圖無法顯示某使用案例發生於另一使用案例之前。如需表達順序，請使用序列圖或活動圖。

14. 何時使用其他 UML 圖表

使用案例圖最適合用於系統範圍與使用者目標。當需要更多細節時，請將其與其他圖表結合使用：

15. 建議的建模流程

1. 定義系統邊界。

2. 識別所有外部參與者。

3. 識別每個參與者的目標。

4. 將這些目標轉換為使用案例。

5. 將參與者連結至其參與的使用案例。

6. 識別必須的重用行為，並使用以下內容進行建模：<<include>>.

7. 識別可選或條件式行為，並使用以下內容進行建模：<<extend>>.

8. 僅在存在真正的「是-a」關係時才新增泛化。

9. 與利害關係人檢視該圖。

10. 為重要使用案例新增文字規格說明。

11. 若圖面變得擁擠，請將其分割。

16. 精簡型 PlantUML 範本

您可以將此作為起點：

@startuml
left to right direction

title 系統使用案例圖

actor 使用者
actor "外部系統" as ExternalSystem

rectangle "系統名稱" {
  usecase "主要使用者目標" as MainGoal
  usecase "必要共用行為" as RequiredBehavior
  usecase "可選行為" as OptionalBehavior
}

User --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

@enduml

核心原則是建模「外部可見的目標」，而非內部實作細節。一個強而有力的使用案例圖能立即讓人理解系統邊界、參與者、功能與重要相依關係。

參考資料