第 10 章

10.6 狀態圖與物件生命週期

系統行為與互動建模

10.6.1 狀態圖回答的問題

狀態圖（State Diagram）描述單一物件在生命週期中可能具有的狀態，以及哪些事件會觸發狀態轉換。循序圖回答「多個參與者或物件如何交換訊息」，狀態圖則回答「某一物件收到事件後，狀態如何改變」。兩種模型都屬行為觀點，但不能互相取代。

10.6.2 狀態、事件、轉換與守衛條件

狀態： 物件在一段期間內符合的業務情況，例如「評分草稿」。
事件： 可能觸發狀態改變的發生事項，例如「正式送出評分」。
轉換： 物件由一個狀態移至另一個狀態。
守衛條件： 轉換發生前必須成立的條件，例如「結果已由主辦單位確認」。
初始與終止節點： 表示所建模生命週期的開始與結束，不一定等同資料被建立或刪除。

狀態名稱應描述一段持續情況，事件名稱則應描述發生的事情。不要把「檢查結果」等動作誤當成狀態，也不要把尚未確認的狀態值直接寫成正式需求。

10.6.3 Case M01評分與更正申請狀態圖

Case M01已確認評分可先保存為草稿，正式送出後不得直接修改，因此「評分」本身可以建立下列分析層級狀態圖：

text

stateDiagram-v2
  [*] --> 草稿
  草稿 --> 草稿 : 修改並儲存
  草稿 --> 已正式送出 : 正式送出評分

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

stateDiagram-v2
  [*] --> 草稿
  草稿 --> 草稿 : 修改並儲存
  草稿 --> 已正式送出 : 正式送出評分

這張圖追溯至FR-08、FR-16及BR-11。正式評分送出後，即使有人提出更正申請，評分也不會因此退回草稿狀態。既有的資料模型與領域模型已將「評分」和「評分更正申請」分別建模，因此不應把「更正處理中」直接當成評分本身的正式狀態。

FR-09、FR-10、BR-12及DR-06支持建立獨立的「評分更正申請」，但尚未完整定義其處理狀態與處理結果值。下圖只用來展示候選生命週期，圖中的狀態名稱均為待確認事項（To Be Confirmed，簡稱TBC），不能直接視為正式需求：

text

stateDiagram-v2
  state "已提出（TBC）" as Submitted_TBC
  state "處理中（TBC）" as Processing_TBC
  state "已處理（TBC）" as Processed_TBC
  [*] --> Submitted_TBC : 提出更正申請
  Submitted_TBC --> Processing_TBC : 經授權人員開始處理
  Processing_TBC --> Processed_TBC : 完成處理並保存紀錄

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

stateDiagram-v2
  state "已提出（TBC）" as Submitted_TBC
  state "處理中（TBC）" as Processing_TBC
  state "已處理（TBC）" as Processed_TBC
  [*] --> Submitted_TBC : 提出更正申請
  Submitted_TBC --> Processing_TBC : 經授權人員開始處理
  Processing_TBC --> Processed_TBC : 完成處理並保存紀錄

需求目前只確認申請必須由經主辦單位授權的競賽承辦人員處理，並保存處理人員、時間、更正前後內容及處理結果；是否需要「已提出」「處理中」「已處理」等狀態，以及處理結果有哪些允許值，都必須再由領域人員確認。

10.6.4 Case M01競賽結果狀態圖

競賽結果的確認與公告具有明確先後限制，可用狀態圖表達：

text

stateDiagram-v2
  [*] --> 待確認
  待確認 --> 已確認 : 主辦單位確認結果
  已確認 --> 已公告 : 競賽承辦人員公告結果

Mermaid 圖形預覽Mermaid 11.12

查看並複製 Mermaid 程式碼

mermaid

stateDiagram-v2
  [*] --> 待確認
  待確認 --> 已確認 : 主辦單位確認結果
  已確認 --> 已公告 : 競賽承辦人員公告結果

這張圖追溯至UC-07、UC-08、FR-17、FR-18及BR-10。從「待確認」不能直接轉為「已公告」，正是BR-10所限制的非法轉換。

10.6.5 報名狀態的候選模型與TBC

既有需求提到報名草稿、正式提交、期限與狀態更新，但尚未完整定義所有報名狀態及轉換。因此，報名狀態圖應先列出需求可支持的片段，其他如「退回補件」「取消」或「資格不符」不可僅憑常識加入。缺漏的狀態、觸發事件與可逆性應建立TBC，再由領域人員確認。

10.6.6 狀態圖與互動圖的一致性

循序圖中的事件若會改變物件狀態，應能在相應狀態圖中找到合法轉換。例如UC-08的「公告競賽結果」訊息，只能在競賽結果已確認時成功；若循序圖允許公告未確認結果，就與狀態圖及BR-10衝突。反過來，狀態圖中的每個重要轉換，也應能追溯至使用案例、需求或其他事件來源。