第 6 章

6.6 使用案例圖的表示法

使用案例分析與建模

6.6.1 基本圖形元素

使用案例圖（Use Case Diagram）以圖形方式呈現系統邊界、參與者、使用案例及其關係。它適合用來快速理解系統服務的範圍，但不負責呈現完整操作步驟、資料欄位或時間順序。

元素	常見表示方式	意義
系統邊界	標示系統名稱的長方形	界定模型中的系統責任
參與者	人形符號或帶有`«actor»`標記的長方形	位於邊界外並與系統互動的角色或外部系統
使用案例	邊界內的橢圓	系統為參與者提供的完整服務
關聯	參與者與使用案例間的實線	表示參與者參與該使用案例

參與者通常放在系統邊界之外，而使用案例則放在邊界內部。圖形位置主要用以服務閱讀，不應被解讀為優先順序、資料流向或執行順序。

§ 使用案例圖範例：UC-01 提交競賽報名

下圖以Case M01（專題競賽報名與審查系統）的UC-01為例，呈現一張最基本的使用案例圖。圖中只保留一個參與者及一個使用案例，以便觀察使用案例圖的核心元素。

Mermaid程式碼

text

flowchart LR

Captain["參與者：隊長"]

subgraph M01["專題競賽報名與審查系統"]
  direction TB
  UC01(["UC-01 提交競賽報名"])
end

Captain --- UC01

程式碼產生的使用案例圖

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

flowchart LR

Captain["參與者：隊長"]

subgraph M01["專題競賽報名與審查系統"]
  direction TB
  UC01(["UC-01 提交競賽報名"])
end

Captain --- UC01

此圖可以從四個部分加以解讀：

隊長是參與者：隊長節點位於系統邊界之外，表示其不是系統內部元件，而是與系統互動的參與者角色。標準UML通常使用人形符號表示參與者，但此處因Mermaid 11.13版（含）以前的語法限制，改以標示「參與者」的節點近似呈現。Mermaid 12.0版（含）以後已能支援原生的使用案例圖語法；本書採用Mermaid 11.13版，因此使用此折衷表示方式。
長方形代表系統邊界：標示「專題競賽報名與審查系統」的長方形，界定本次分析的系統範圍。
UC-01是使用案例：圓弧形節點中的「提交競賽報名」代表系統提供的一項完整服務，UC-01則是該使用案例的識別碼。這個節點用來近似UML的橢圓形使用案例。
實線代表關聯：隊長與UC-01之間的實線表示隊長參與「提交競賽報名」使用案例。

這條關聯線只表示隊長會參與UC-01，不代表資料一定由隊長單向流入系統，也不表示完整的執行順序。報名資料如何輸入、系統如何檢查團隊人數與期限，以及提交失敗時如何處理，應記錄在使用案例描述、需求或業務規則中，而不是全部放入使用案例圖。

上述程式碼採用Mermaid 11.13版（含）以前可使用的flowchart語法。由於這些版本尚未提供原生的使用案例圖語法，圖中的系統邊界、參與者及使用案例是以流程圖元素近似呈現。若要嚴格呈現UML的人形參與者、橢圓及關係表示法，仍應使用Mermaid 12.0版（含）以後來繪製，或使用支援UML的專業建模工具。

6.6.2 關聯與泛化

參與者與使用案例之間的關聯（Association）表示該角色參與此項服務，用實線來表示。關聯線通常不表示誰先開始、資訊流向或呼叫方向。

泛化（Generalization）表示較特殊的參與者或使用案例繼承較一般的特性。泛化使用實線及空心三角箭頭，箭頭指向較一般的元素。

泛化只有在確實存在「是一種」關係時才適合使用。不要只為了減少線條而建立抽象的參與者，也不要把組織上的上下級關係直接泛化。

§ 使用案例圖範例：UC-07 確認競賽結果

下圖再次示範系統邊界、參與者、使用案例及相關關聯。UC-07的主要參與者為「主辦單位」，其目標是確認競賽結果可進入公告程序。

Mermaid程式碼

text

flowchart LR

Organizer["參與者：主辦單位"]

subgraph M01B["專題競賽報名與審查系統"]
  direction TB
  UC07(["UC-07 確認競賽結果"])
end

Organizer --- UC07

程式碼產生的使用案例圖

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

flowchart LR

Organizer["參與者：主辦單位"]

subgraph M01B["專題競賽報名與審查系統"]
  direction TB
  UC07(["UC-07 確認競賽結果"])
end

Organizer --- UC07

圖中的「主辦單位」位於系統邊界之外，UC-07則位於系統邊界之內。兩者之間的實線表示主辦單位參與UC-07。這條線不表示主辦單位是系統內部元件，也不表示資料傳送方向。

「主辦單位」與「競賽承辦人員」是不同的參與者角色。兩個角色可以由不同人分別擔任，也可以由同一人同時扮演。使用案例圖呈現的是角色責任，而不是人員編制或個人姓名。

6.6.3 `include`關係

«include»表示一個基礎使用案例在執行時，必定納入另一個使用案例的行為。它常用來從多個使用案例中抽取出共同且必要的行為。

例如，多項受保護的服務都必須確認使用者身分時，可以評估是否建立「驗證使用者身分」並納入相關的使用案例。不過，若此行為只是簡短步驟，抽出後反而使模型難以理解，就不一定需要使用include。

表示時使用虛線箭頭，標示«include»，箭頭由基礎使用案例指向被納入的使用案例。

判斷重點包括：

被納入的行為是否每次都必須發生？
是否確實由多個使用案例共同使用？
抽出後是否有助於一致描述與維護？

§ `include`關係範例：納入身分驗證

本案例假設經需求確認後，Case M01的所有受保護服務在每次執行時都必須透過校園身分驗證系統確認使用者身分。因此，新增下列需求與驗收準則：

FR-13：系統應在使用者執行受保護的系統服務時確認其有效身分；校內使用者透過校園身分驗證系統完成驗證，校外評審的登入方式仍依TBC-10確認。
AC-14：Given使用者提出執行受保護服務的要求，When校園身分驗證系統回覆驗證成功，Then系統允許使用者依其權限繼續執行該服務。
AC-15：Given使用者提出執行受保護服務的要求，When身分驗證失敗或無法取得有效驗證結果，Then系統不得執行該服務，並回覆驗證未完成。

確認需求後，可將共同且必要的行為建立為UC-09「驗證使用者身分」，再由各項受保護的基礎使用案例以«include»關係納入。校園身分驗證系統是UC-09在校內使用者情境中的支援參與者；校外評審如何登入仍保留為TBC-10，不因確認FR-13而自行假定。以下先以UC-01「提交競賽報名」與UC-03「上傳專題文件」示範。

Mermaid程式碼

text

flowchart LR

Captain["參與者：隊長"]
Identity["外部系統：校園身分驗證系統"]

subgraph M01C["專題競賽報名與審查系統"]
  direction TB
  UC01(["UC-01 提交競賽報名"])
  UC03(["UC-03 上傳專題文件"])
  AUTH(["UC-09 驗證使用者身分"])
end

Captain --- UC01
Captain --- UC03
Identity --- AUTH
UC01 -.->|«include»| AUTH
UC03 -.->|«include»| AUTH

程式碼產生的使用案例圖

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

flowchart LR

Captain["參與者：隊長"]
Identity["外部系統：校園身分驗證系統"]

subgraph M01C["專題競賽報名與審查系統"]
  direction TB
  UC01(["UC-01 提交競賽報名"])
  UC03(["UC-03 上傳專題文件"])
  AUTH(["UC-09 驗證使用者身分"])
end

Captain --- UC01
Captain --- UC03
Identity --- AUTH
UC01 -.->|«include»| AUTH
UC03 -.->|«include»| AUTH

兩條標示«include»的虛線箭頭都由基礎使用案例指向被納入的UC-09，表示「驗證使用者身分」是UC-01與UC-03執行時必須發生的共同行為。校園身分驗證系統位於邊界之外，表示身分驗證需要外部系統提供支援。

此處已將「每次執行受保護服務都必須進行身分驗證」視為經確認的案例需求。若其他專案只在登入時驗證一次，或採用不同的工作階段與授權機制，就不應直接套用相同的include關係。

6.6.4 `extend`關係

«extend»表示在特定條件成立時，擴充使用案例可以在基礎使用案例的擴充點加入額外行為。基礎使用案例本身仍應具有完整意義。

表示時使用虛線箭頭，標示«extend»，箭頭由擴充使用案例指向被擴充的基礎使用案例。

extend不等同於：

一般的例外流程
任意的選用步驟
使用案例執行順序
為了讓圖形看起來完整而增加的關係

若替代或例外情境只屬於單一使用案例，直接寫入使用案例描述通常更清楚，不必建立額外使用案例。

§ `extend`關係範例：刪除隊員或指導教師時發送通知

下圖以UC-02「修改報名資料」為例。若修改內容涉及刪除隊員或指導教師，為避免當事人不知情而產生爭議，系統必須以電子郵件（Email）通知被刪除者。只有在刪除隊員或指導教師的條件成立時，才需要執行此項通知行為。

此項行為新增下列需求與驗收準則：

FR-14：當UC-02修改報名資料涉及刪除隊員或指導教師時，系統應在異動核准並生效後，透過電子郵件服務通知被刪除者。
AC-16：Given隊長提出刪除隊員或指導教師的資料異動，When該異動完成核准並生效，Then系統透過電子郵件服務向被刪除者發送異動通知，並保存通知紀錄。

條件式通知配置為UC-10「通知被刪除的隊員或指導教師」，並以«extend»關係連結UC-02。

Mermaid程式碼

text

flowchart LR

Captain["參與者：隊長"]
RemovedMember["參與者：被刪除的隊員"]
RemovedAdvisor["參與者：被刪除的指導教師"]
EmailService["外部服務：電子郵件服務"]

subgraph M01D["專題競賽報名與審查系統"]
  direction TB
  UC02(["UC-02 修改報名資料"])
  Notify(["UC-10 通知被刪除的隊員或指導教師"])
end

Captain --- UC02
Notify --- RemovedMember
Notify --- RemovedAdvisor
EmailService --- Notify
Notify -.->|«extend»：刪除隊員或指導教師| UC02

程式碼產生的使用案例圖

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

flowchart LR

Captain["參與者：隊長"]
RemovedMember["參與者：被刪除的隊員"]
RemovedAdvisor["參與者：被刪除的指導教師"]
EmailService["外部服務：電子郵件服務"]

subgraph M01D["專題競賽報名與審查系統"]
  direction TB
  UC02(["UC-02 修改報名資料"])
  Notify(["UC-10 通知被刪除的隊員或指導教師"])
end

Captain --- UC02
Notify --- RemovedMember
Notify --- RemovedAdvisor
EmailService --- Notify
Notify -.->|«extend»：刪除隊員或指導教師| UC02

圖中的隊長是UC-02的主要參與者；被刪除的隊員與指導教師是通知的接收者；電子郵件服務則是協助系統傳送通知的外部服務。這些角色與服務都位於Case M01的系統邊界之外。

虛線箭頭由擴充使用案例UC-10「通知被刪除的隊員或指導教師」指向基礎使用案例UC-02「修改報名資料」。若修改內容沒有刪除隊員或指導教師，UC-02仍可完整執行；只有在刪除條件成立時，才加入電子郵件通知行為。

這個例子呈現extend與include的重要差異：include表示基礎使用案例每次執行時都必定納入另一項行為；extend則表示只有在特定條件成立時，才將額外行為加入基礎使用案例。

請注意：初學者有時會誤以為與include相對照的是exclude，但UML使用案例關係中並沒有`exclude`。include通常與extend放在一起比較，但兩者並非字面上的相反關係。extend不是「排除」另一個使用案例，也不表示兩個使用案例不能同時發生。若需求要表達某個角色不得執行某項功能，或某個評審不得審查特定專題，應使用權限、前置條件或業務規則表達，而不是建立不存在的exclude關係。

6.6.5 圖面配置與品質檢查

一張清楚的使用案例圖應：

標明系統名稱與邊界。
使用一致且有意義的參與者與使用案例名稱。
避免線條大量交叉。
只呈現符合該圖目的的內容。
必要時建立整體圖與局部圖。
讓同一模型元素在不同圖中維持相同名稱與語意。

Case M01的整體圖可呈現隊長、評審、主辦單位、競賽承辦人員及校園身分驗證系統，並連接到UC-01至UC-08等使用案例。若整體圖過於擁擠，可以另建報名作業、評審作業及結果管理等局部圖，但不應在不同圖中任意改名。

§ Case M01整體使用案例圖

下圖整合Case M01的主要參與者與UC-01至UC-08。為避免過多線條交叉，圖中只呈現主要業務關聯；經FR-13確認的身分驗證include關係另以局部圖呈現。被刪除的隊員、被刪除的指導教師及電子郵件服務等只參與特定情境的次要參與者，則保留在相關局部圖中。

Mermaid程式碼

text

flowchart LR

Captain["參與者：隊長"]
Judge["參與者：評審"]
Organizer["參與者：主辦單位"]
Staff["參與者：競賽承辦人員"]
Identity["外部系統：校園身分驗證系統"]

subgraph M01ALL["專題競賽報名與審查系統"]
  direction TB
  UC01(["UC-01 提交競賽報名"])
  UC02(["UC-02 修改報名資料"])
  UC03(["UC-03 上傳專題文件"])
  UC04(["UC-04 分派評審"])
  UC05(["UC-05 評定參賽專題"])
  UC06(["UC-06 處理評分更正"])
  UC07(["UC-07 確認競賽結果"])
  UC08(["UC-08 公告競賽結果"])
  AUTH(["UC-09 驗證使用者身分"])
end

Captain --- UC01
Captain --- UC02
Captain --- UC03
Judge --- UC05
Organizer --- UC07
Staff --- UC04
Staff --- UC06
Staff --- UC08
Identity --- AUTH

程式碼產生的使用案例圖

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

flowchart LR

Captain["參與者：隊長"]
Judge["參與者：評審"]
Organizer["參與者：主辦單位"]
Staff["參與者：競賽承辦人員"]
Identity["外部系統：校園身分驗證系統"]

subgraph M01ALL["專題競賽報名與審查系統"]
  direction TB
  UC01(["UC-01 提交競賽報名"])
  UC02(["UC-02 修改報名資料"])
  UC03(["UC-03 上傳專題文件"])
  UC04(["UC-04 分派評審"])
  UC05(["UC-05 評定參賽專題"])
  UC06(["UC-06 處理評分更正"])
  UC07(["UC-07 確認競賽結果"])
  UC08(["UC-08 公告競賽結果"])
  AUTH(["UC-09 驗證使用者身分"])
end

Captain --- UC01
Captain --- UC02
Captain --- UC03
Judge --- UC05
Organizer --- UC07
Staff --- UC04
Staff --- UC06
Staff --- UC08
Identity --- AUTH

此圖可以依參與者分成四組主要業務責任：

隊長參與UC-01、UC-02及UC-03，負責競賽報名資料與專題文件。
評審參與UC-05，只能評定被分派的參賽專題。
主辦單位參與UC-07，負責確認競賽結果，並進入公告程序。
競賽承辦人員參與UC-04、UC-06及UC-08，負責評審分派、評分更正處理與結果公告。

校園身分驗證系統是支援參與者，向Case M01提供身分驗證服務。圖中以UC-09「驗證使用者身分」表示此項支援，但沒有把它與每一個業務使用案例全部連接，以維持整體圖的可讀性。FR-13已確認UC-01至UC-08執行時都必須納入身分驗證，因此，相關include關係應保留在局部圖、詳細模型或使用案例描述中；整體概觀圖省略部分線條，不代表關係不存在。

整體圖適合用來掌握系統範圍及主要責任分配， 但不能取代使用案例描述。各使用案例的前置條件、基本流程、替代流程、例外流程及業務規則，仍需由文字文件完整記錄。

使用案例圖不應加入：

畫面欄位與按鈕
資料表名稱
完整流程步驟
不具獨立目標的內部處理
沒有需求依據的參與者或功能

6.6.1 基本圖形元素

§ 使用案例圖範例：UC-01 提交競賽報名

6.6.2 關聯與泛化

§ 使用案例圖範例：UC-07 確認競賽結果

6.6.3 `include`關係

§ include關係範例：納入身分驗證

6.6.4 `extend`關係

§ extend關係範例：刪除隊員或指導教師時發送通知

6.6.5 圖面配置與品質檢查

§ Case M01整體使用案例圖

§ `include`關係範例：納入身分驗證

§ `extend`關係範例：刪除隊員或指導教師時發送通知