掌握用例驅動方法：需求與設計的全面指南 - IT 觀察者隨筆

引言

在軟體工程中，填補利害關係人需求與技術實現之間的差距，往往是開發過程中最具挑戰性的階段。用例驅動方法 提供了一種結構化、迭代式的 methodology 來解決此問題。透過專注於使用者如何與系統互動以達成特定目標，此方法確保需求清晰、可測試，並能直接追蹤至設計產出物。

本指南將完整 walkthrough 此用例驅動方法，從高階需求逐步推進至詳細設計。我們將使用單一持續運作的範例——一個線上訂單管理系統——來說明每個階段，確保整個過程的一致性與清晰度。

方法論概述

用例驅動方法遵循自然的由上而下演進過程。每個階段都會精化前一階段，增加精確度並減少歧義。

方法論概覽：結合 AI 與 VPasCode 的用例驅動方法

為何此順序至關重要？

用例圖:提供能力與範圍的完整清單。它快速易讀，非常適合利害關係人就系統的功能進行共識。
用例描述:透過明確界定前置條件、後置條件、參與者與優先級來消除歧義。它將行為契約「凍結」。
事件流程:將契約轉化為具體、可測試的步驟。這同時作為測試案例與技術設計的原始素材。
活動/序列圖:作為通往程式碼的橋樑。它識別參與的物件、它們的職責、訊息交換以及確切的分支規則。

階段 1：使用案例圖（需求）

使用案例圖捕捉誰與系統互動（參與者）以及什麼他們能做的（使用案例），以及它們之間的關係。

關鍵概念

主要參與者：啟動使用案例（置於左側）。
次要參與者：支援系統或接收通知（置於右側）。
系統邊界：定義系統範圍的矩形。
<<包含>>:代表強制性的共用行為。如果使用案例 A 包含使用案例 B，則 B必須發生，A 才能完成。
<<延伸>>:代表可選行為。使用案例 B 僅在特定條件下延伸使用案例 A。

範例：線上訂單管理系統

線上訂單管理系統的用例圖，顯示客戶與倉庫之間的互動。

@startuml
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam vpDiagramType UseCaseDiagram
skinparam actor {
  BackgroundColor #E8F5E9
}
skinparam usecase {
  BackgroundColor #BBDEFB
  BorderColor #1976D2
  ArrowColor #1976D2
}

left to right direction
actor "Customern(Primary)" as cust
actor "Warehousen(Secondary)" as wh

rectangle "Order Management System" {
  usecase "Place Order" as UC1
  usecase "Cancel Order" as UC2
  usecase "Track Order" as UC3
  usecase "Login" as UC4
  usecase "Print Invoice" as UC5
}

cust -[#black]- UC1
cust -[#black]- UC2
cust -[#black]- UC3
UC1 -[#crimson]- wh
UC2 -[#crimson]- wh
UC1 ...> UC4 : <<include>>
UC2 ...> UC4 : <<include>>
UC3 ...> UC4 : <<include>>
UC1 <... UC5 : <<extend>>
@enduml

圖表分析：

該客戶發起下單、取消訂單及追蹤訂單。
該倉庫參與下單與取消訂單（可能用於庫存更新）。
登入包含在下單、取消訂單及追蹤訂單中，表示執行這些動作必須進行身份驗證。
列印發票 延伸自下單，表示這是一個可選步驟，可能在下單後發生。

階段 2：使用案例描述（規格說明）

圖表僅列出使用案例名稱，但缺乏細節。該使用案例描述表明確定義每個使用案例的精確合約。

範例：UC-01 下單

欄位	值
使用案例識別碼	UC-01
名稱	下單
主要參與者	客戶
次要參與者	倉庫
前置條件	客戶已登入；購物車內至少有一項商品；商品有庫存
後置條件（成功）	訂單已儲存，狀態為`已確認`；款項已扣款；已發行追蹤編號
後置條件（失敗）	未建立訂單；購物車未變更；使用者已獲知原因
主要流程	→ 參見第三階段
替代流程 / 異常流程	庫存不足；付款遭拒
優先級	高

目的：本階段定義必須為真的內容在使用案例執行前（前置條件），以及執行後必須成立的內容之後（後置條件），以建立明確的成功/失敗標準。

第三階段：事件流程（情境）

這是該方法行為的核心。「下訂單」使用案例擴展為一個情境腳本——在尚未建立任何詳細設計圖之前撰寫的編號步驟序列。

主要成功情境（基本流程）

客戶登入。
客戶提交包含已選項目的購物車。
系統驗證購物車內容與庫存可用性。
系統透過支付閘門收取總金額。
系統儲存訂單，狀態為已確認.
系統回傳包含訂單編號的訂單確認訊息。
系統通知倉庫進行揀貨、包裝與出貨。

替代情境

3a. 庫存不足：系統報告無法提供的項目並返回購物車。
4a. 付款遭拒：系統通知客戶並不建立訂單。

主要慣例：每個情境直接對應描述中的一個步驟。這些流程將成為下一階段活動圖與序列圖的基礎。

階段 4：詳細設計（序列圖與活動圖）

在此階段，您應根據希望強調的系統面向來選擇記號。

序列圖:強調生命線、訊息順序以及物件之間的責任。非常適合用於發現類別與方法。
活動圖：強調透過泳道/參與者來強調控制流程與決策。非常適合用於記錄流程與角色責任。

4A. 序列圖（互動觀點）

序列表，說明包含客戶、訂單服務、支付閘道與訂單資料庫互動的下單工作流程。

@startuml
title 下訂單序列圖
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam sequenceParticipant underline
skinparam vpDiagramType InteractionDiagram
skinparam {
  FontSize 14
  ArrowColor #4A4A4A
  ArrowFontColor #4A4A4A
  BackgroundColor #FFFFFF
  BorderColor #DEDEDE
  FontColor #333333
  Participant {
    BorderColor #0077B6
    BackgroundColor #F0F8FF
    FontColor #005691
  }
  Actor {
    BorderColor #6A057F
    BackgroundColor #F5EEF8
    FontColor #510363
  }
  Sequence {
    ArrowThickness 2
    LifeLineBorderColor #444444
    LifeLineBackgroundColor #F7F7F7
    BoxBorderColor #AAAAAA
    BoxBackgroundColor #FFFFFF
    BoxFontColor #333333
  }
}

actor "客戶" as USR
participant "訂單服務" as OS
participant "付款閘道" as PG
database "訂單資料庫" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt 驗證與付款
  OS -> OS : validateCart(items)
  OS -> PG : charge(total)
  activate PG
  PG --> OS : paymentOk
  deactivate PG
  OS -> DB : saveOrder(status=confirmed)
  activate DB
  DB --> OS : orderId
  deactivate DB
  OS --> USR : orderConfirmation(orderId)
else 庫存不足
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("Out of stock")
else 付款失敗
  PG --> OS : paymentFailed
  OS --> USR : error("Payment declined")
end
deactivate OS
@enduml

主要概念：

同步呼叫：實線箭頭（->).
回覆：虛線箭頭（-->).
活化條：顯示物件處理的生命週期。
alt組合片段：包裝三種情境（成功、庫存不足、付款失敗），直接對應第三階段的流程。

4B. 活動圖（流程觀點）

VPasCode 介面顯示下單活動圖，其中包含客戶、系統與倉庫的泳道。

@startuml
<style>
  element { MaximumWidth 150 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title 下訂單活動圖

|#F0F8FF|客戶|
start
:登入;
:瀏覽目錄;
:將商品加入購物車;

if (準備結帳？) then (是)
  :前往結帳;
else (否)
  :返回瀏覽;
  stop
endif

|#E8F5E9|系統|
:驗證購物車;
:處理付款;

if (付款已核准？) then (是)
  :建立訂單（狀態=已確認）;
else (否)
  :通知付款失敗;
endif

|#F5EEF8|倉庫|
if (付款已核准？) then (是)
  :揀貨與包裝商品;
  :寄送訂單;
  :傳送追蹤號碼;
  stop
else (否)
  stop
endif
@enduml

下單活動圖，說明跨越客戶、系統與倉庫泳道的流程。 關鍵概念：

泳道:將每個動作指派給負責方（客戶、系統、倉庫）。
決策節點： if/then/else/endif結構用於編碼分支情境。
開始/結束標記：界定流程的開始與結束。

PlantUML 關鍵重點

要有效使用 PlantUML 建立此模型，請記住以下語法重點：

使用案例圖:
- 使用usecase來表示功能。
- 使用...>來表示<<include>>關係。
- 使用<...來<<延伸>>關係。
- 使用rectangle "系統名稱" {}來定義系統邊界。
序列圖：
- 使用參與者（actor）, 參與者（participant）、或資料庫.
- 使用->來表示同步呼叫，並使用-->來表示回覆。
- 使用activate與deactivate來顯示物件的生命週期。
- 使用alt, else，以及end用於表示替代流程的組合片段。
活動圖：
- 使用|#color|LaneName|來定義泳道。
- 使用:action;來表示活動。
- 使用if/else/endif來表示決策節點。
- 使用start和stop來標記流程邊界。

結論

「用例驅動方法」不僅僅是一種文檔技術；它是一個漸進式優化的框架。從整體視圖（用例圖）開始，並深入探討具體行為（事件流程）和技術互動（序列/活動圖），團隊可以確保每一行程式碼都能追溯到已驗證的用戶需求。

此方法降低了利益相關者與開發人員之間溝通誤解的風險，透過清晰的場景促進更簡易的測試，並產生穩健且以用戶為中心的系統設計。無論您是在構建簡單的電子商務平台還是複雜的企業系統，遵循此結構化進程將帶來更清晰的規格說明與更高品質的軟體。

引言