10.4 組合片段、互動參照與圖形分解

10.4.1 `alt`條件分支

除了成功情境之外，還會有其他情境。alt、opt、loop及par是循序圖常用的組合片段運算子，分別表示替代、選用、重複及平行互動。重複出現的身分驗證或通知互動則可建立為獨立互動，再以ref進行互動參照；ref不是組合片段運算子。

除了成功情境之外，還會有其他情境。alt表示互斥的替代路徑，每個區段應有可判斷的守衛條件。

sequenceDiagram
  actor Captain as 隊長
  participant System as 報名與審查系統
  Captain->>System: 提交專題文件
  alt 格式不是PDF
    System-->>Captain: 拒絕並說明格式不符
  else 格式為PDF且檔案超過20 MB
    System-->>Captain: 拒絕並說明容量超限
  else 格式為PDF且檔案不超過20 MB
    System-->>Captain: 完成上傳
  end

sequenceDiagram
  actor Captain as 隊長
  participant System as 報名與審查系統
  Captain->>System: 提交專題文件
  alt 格式不是PDF
    System-->>Captain: 拒絕並說明格式不符
  else 格式為PDF且檔案超過20 MB
    System-->>Captain: 拒絕並說明容量超限
  else 格式為PDF且檔案不超過20 MB
    System-->>Captain: 完成上傳
  end

10.4.2 `opt`選用互動

opt是另一種情境，用於表示條件成立時才執行的互動。例如，UC-02涉及刪除隊員或指導教師時，異動申請須依FR-02送交競賽承辦人員審核；異動核准並生效後，才依FR-14執行UC-10通知被刪除者。

sequenceDiagram
  actor Captain as 隊長
  actor Staff as 競賽承辦人員
  participant System as 報名與審查系統
  participant Email as 電子郵件服務
  Captain->>System: 提交涉及刪除人員的異動申請
  System->>Staff: 送交異動申請審核
  Staff->>System: 核准異動申請
  System->>System: 使異動生效
  System-->>Captain: 回覆異動已核准並生效
  opt 已刪除隊員或指導教師
    System->>Email: 寄送刪除通知
    System->>System: 保存通知紀錄
  end

sequenceDiagram
  actor Captain as 隊長
  actor Staff as 競賽承辦人員
  participant System as 報名與審查系統
  participant Email as 電子郵件服務
  Captain->>System: 提交涉及刪除人員的異動申請
  System->>Staff: 送交異動申請審核
  Staff->>System: 核准異動申請
  System->>System: 使異動生效
  System-->>Captain: 回覆異動已核准並生效
  opt 已刪除隊員或指導教師
    System->>Email: 寄送刪除通知
    System->>System: 保存通知紀錄
  end

這段互動追溯至FR-02、FR-14、AC-16、UC-02與UC-10。競賽承辦人員負責審核異動，系統則在異動核准並生效後寄送通知及保存通知紀錄。圖中只表達通知發生的條件，並未自行決定電子郵件服務是否採用同步或非同步呼叫。

10.4.3 `loop`重複互動

loop情境可用於同一互動依明確條件重複進行，例如逐一處理多個評分項目。重複次數與終止條件應依需求而來，不應任意填入。例如評審針對每一個既定評分項目評分，直到完成每一個既定評分項目。

sequenceDiagram
  actor Reviewer as 評審
  participant System as 報名與審查系統
  loop 每一個既定評分項目
    Reviewer->>System: 輸入評分項目分數與評語
    System-->>Reviewer: 回覆暫存結果
  end

sequenceDiagram
  actor Reviewer as 評審
  participant System as 報名與審查系統
  loop 每一個既定評分項目
    Reviewer->>System: 輸入評分項目分數與評語
    System-->>Reviewer: 回覆暫存結果
  end

「逐一處理多個評分項目」是說明loop語意的候選情境；評分項目數量與暫存方式仍須由需求支持。

10.4.4 `par`平行互動

par表示數段互動可以並行，但不代表所有訊息可以任意交換順序。只有在需求或系統語意允許平行時才使用。

例如系統完成結果公告後，若需求允許同時更新公開頁面及寄送通知，可用par表示；但Case M01目前尚未確認這兩項工作可平行執行，因此只能視為候選圖例，不能列入正式模型。

sequenceDiagram
  actor Staff as 競賽承辦人員
  participant System as 報名與審查系統
  participant Web as 公開頁面
  participant Email as 電子郵件服務
  Staff->>System: 要求公告競賽結果
  par 更新公開頁面
    System->>Web: 發布競賽結果
  and 寄送公告通知
    System->>Email: 寄送結果公告通知
  end
  System-->>Staff: 回覆公告完成

sequenceDiagram
  actor Staff as 競賽承辦人員
  participant System as 報名與審查系統
  participant Web as 公開頁面
  participant Email as 電子郵件服務
  Staff->>System: 要求公告競賽結果
  par 更新公開頁面
    System->>Web: 發布競賽結果
  and 寄送公告通知
    System->>Email: 寄送結果公告通知
  end
  System-->>Staff: 回覆公告完成

圖中的兩個區段可以並行，但每個區段內仍保有自己的訊息順序。系統應在兩個區段都完成後才回覆「公告完成」。若日後確認電子郵件可延後寄送，回覆時點與訊息型態仍需依正式需求重新調整。

10.4.5 圖形分解與模型一致性

當一張圖包含太多生命線、條件或訊息時，應依使用案例或局部情境進行分解。圖形分解的目標是提升可理解性，而不是隱藏重要例外。

被分解的圖仍須共用一致的參與者名稱、系統事件、守衛條件與需求編號。相同訊息若在不同圖使用不同名稱，應先確認是否代表同一事件，也就是要確保模型一致性。

10.4.6 `ref`互動參照

重複出現的身分驗證或通知互動可以建立獨立圖，再以ref參照。參照名稱與輸入輸出必須清楚，避免讀者無法判斷被引用的內容。

例如UC-01至UC-08均納入UC-09「驗證使用者身分」，重複出現，因此可以建立獨立圖，再以ref參照。在支援ref的UML工具中，各SSD可以參照「UC-09驗證使用者身分」，避免重複畫出相同細節。ref只是重用互動定義，不代表使用案例關係本身被改成另一種關係。

下圖以「提交報名」為例，將身分驗證視為另行定義的互動。為相容本書採用的Mermaid版本，圖中使用陰影區塊及註記模擬UML的ref框，只標示被參照的互動名稱，不在主圖重複展開其內部訊息；在完整支援UML的建模工具中，則應使用正式的互動參照框。

sequenceDiagram
  actor Captain as 隊長
  participant System as 報名與審查系統
  participant IdP as 校園身分驗證系統
  Captain->>System: 要求提交報名
  rect rgb(245, 245, 245)
    Note over System,IdP: ref：UC-09 驗證使用者身分
  end
  System->>System: 檢查提交條件
  System-->>Captain: 回覆提交結果

sequenceDiagram
  actor Captain as 隊長
  participant System as 報名與審查系統
  participant IdP as 校園身分驗證系統
  Captain->>System: 要求提交報名
  rect rgb(245, 245, 245)
    Note over System,IdP: ref：UC-09 驗證使用者身分
  end
  System->>System: 檢查提交條件
  System-->>Captain: 回覆提交結果

ref框的重點不是把原互動複製一次，而是指出此處會執行另一張已命名的互動。因此，被參照圖應清楚定義參與者、輸入、成功結果及失敗結果；若這些介面改變，所有參照該互動的圖也必須一併檢查。

10.4.7 不要混淆`include`與`extend`

使用案例的include、extend描述使用案例之間的關係；循序圖的alt、opt及ref則描述特定情境中的訊息結構。兩者可能彼此呼應，但分屬不同模型，不能只看名稱就直接一對一轉換。

下圖呈現Case M01的兩種使用案例關係。UC-01至UC-08都必須使用UC-09驗證身分，因此由受保護使用案例群組指向被納入的UC-09；UC-10則只在UC-02刪除隊員或指導教師時才擴充其行為，因此由UC-10指向UC-02。由於Mermaid沒有原生的UML使用案例圖語法，本圖以流程圖語法表達關係方向；其中矩形只是「UC-01至UC-08」的簡化群組，不代表一個新的使用案例。

flowchart LR
  ProtectedCases[UC-01至UC-08<br/>受保護使用案例群組]
  UC09([UC-09<br/>驗證使用者身分])
  UC02([UC-02<br/>修改報名資料])
  UC10([UC-10<br/>通知被刪除者])
  ProtectedCases -.->|include| UC09
  UC10 -.->|extend：刪除隊員或指導教師| UC02

flowchart LR
  ProtectedCases[UC-01至UC-08<br/>受保護使用案例群組]
  UC09([UC-09<br/>驗證使用者身分])
  UC02([UC-02<br/>修改報名資料])
  UC10([UC-10<br/>通知被刪除者])
  ProtectedCases -.->|include| UC09
  UC10 -.->|extend：刪除隊員或指導教師| UC02

這些使用案例關係不會自動決定循序圖應使用哪一種組合片段。例如，UC-10在UC-02的某個情境中可能以opt呈現；UC-09也可能在細部循序圖中以ref參照。然而，extend不等於opt，include也不等於ref：前者表達使用案例層級的目標與重複使用關係，後者表達單一互動情境如何安排訊息。