10.2 UML互動圖、循序圖與基本組成元素

10.2.1 互動情境與循序圖的閱讀方式

一張循序圖通常描述一個具體情境，而不是整個系統。整個系統會有很多的循序圖。主要情境、替代情境與例外情境可使用組合片段呈現；若互動時序複雜，也可分成多張局部圖呈現。

循序圖有固定的閱讀方式，生命線由左至右排列，時間軸由上向下推進。訊息的垂直位置表示先後順序。但必須注意的是：一般循序圖不直接代表精確經過時間，只代表順序；若需求涉及逾時或期限，例如必須在10分鐘內完成認證，否則認證碼失效，這些時間限制仍需另行註記，或使用時序圖。循序圖標示順序，時序圖則處理與時間密切相關的互動，例如即時處理、逾時限制與時間敏感行為。

10.2.2 UML互動圖的種類與比較

UML的互動圖是一個總稱，並非只有一種圖，互動圖主要包含四種圖：

四種圖都描述互動，但觀察角度不同。本章以循序圖為主要工具，以通訊圖作為結構觀點的補充；互動概觀圖與時序圖則介紹其用途，不深入語法細節。

以下用「隊長查詢報名狀態」比較循序圖與通訊圖。循序圖以垂直位置表達時間先後：

sequenceDiagram
  actor Captain as 隊長
  participant System as 報名與審查系統
  Captain->>System: 查詢報名狀態
  System-->>Captain: 回覆目前報名狀態

sequenceDiagram
  actor Captain as 隊長
  participant System as 報名與審查系統
  Captain->>System: 查詢報名狀態
  System-->>Captain: 回覆目前報名狀態

通訊圖使用連結與訊息編號表達相同內容。1與2表示兩則訊息依序發生。若使用1.1，通常表示處理訊息1期間所發出的下一層訊息，不專門表示回覆：

flowchart LR
  Captain[隊長]
  System[報名與審查系統]
  Captain -->|1：查詢報名狀態| System
  System -.->|2：回覆目前報名狀態| Captain

flowchart LR
  Captain[隊長]
  System[報名與審查系統]
  Captain -->|1：查詢報名狀態| System
  System -.->|2：回覆目前報名狀態| Captain

本書使用Mermaid來繪製各種圖形，但是本書撰稿時，Mermaid並沒有專用的UML通訊圖語法，因此上圖以流程圖語法模擬物件連結與編號訊息。若正式建模工具支援通訊圖，可使用UML原生符號，或使用PlantUML語法。使用Mermaid或PlantUML來繪製圖形時，很容易將程式碼提供給AI來進行Vibe Coding，而標準的UML則有助於系統分析師與程式設計師間的溝通。

循序圖與通訊圖描述同一情境時，不應出現不同的參與者、訊息或順序；差異只在呈現重點。

10.2.3 系統循序圖、參與者與責任邊界

系統循序圖與一般循序圖之間的區別很容易混淆。UML並沒有另外定義一種稱為「系統循序圖」的圖；系統循序圖（SSD）是循序圖在系統分析上的一種應用。SSD把待分析系統視為一個黑箱，著重外部參與者如何對整體系統提出要求，以及系統提供什麼可觀察的回應，暫不展開系統內部由哪些物件、服務或資料庫共同完成工作。

理解系統循序圖時，除了訊息之外，還需要掌握參與者、生命線及系統邊界等概念，說明如下：

參與者代表與系統互動的外部角色，不一定是具體個人。例如「隊長」是人員角色，「校園身分驗證系統」與「電子郵件服務」則是外部系統；只要它們位於本次分析的系統之外，並與系統交換訊息，都可以出現在SSD中。

生命線是參與者、系統或物件在互動圖中的表示方式。生命線上方標示角色或物件名稱，向下延伸的線表示該對象在互動期間持續存在。生命線不是一項工作，因此應命名為「隊長」「專題競賽報名與審查系統」或「校園身分驗證系統」，不宜命名為「上傳文件」或「進行驗證」。後兩者是行為，應以訊息表達。

系統邊界用來區分「系統應負責的工作」與「系統外部環境的工作」。建立Case M01的SSD時，「專題競賽報名與審查系統」是一條代表整體系統的生命線；隊長、評審、主辦單位、競賽承辦人員及校園身分驗證系統均位於其外部。隊長可以向系統傳送「要求上傳專題文件」，系統也可以向校園身分驗證系統傳送「驗證使用者身分」，因為這些都是跨越系統邊界、可以觀察到的事件。

相對地，「查詢某資料表」「呼叫某個控制器方法」或「建立某個內部物件」屬於系統內部如何實現功能的問題。在尚未進入設計層級時，不應讓外部參與者直接呼叫這些內部元件。若必須在SSD中交代重要的內部檢查，可以用系統生命線的自我訊息概括表示，例如「檢查檔案格式與容量」，但不必因此公開尚未確定的內部結構。

系統邊界並非永遠固定，而是取決於本次建模的對象。舉例來說，在Case M01，分析範圍是「專題競賽報名與審查系統」，校園身分驗證系統就是外部系統。但是，如果分析範圍擴大為整個校園資訊環境，它也可能成為較大系統內部的一部分。因此，繪圖前應先說明「本圖所分析的系統是什麼」，才能判斷哪些對象應位於邊界內或邊界外。

生命線有時會和活動圖的泳道混淆，因為兩者都可能使用「隊長」或「競賽承辦人員」等角色名稱。然而，兩者所回答的問題不同：生命線回答「誰與誰依序交換訊息」，泳道回答「流程中的各項活動由誰負責」。

例如，在活動圖中，「隊長」泳道內可以放置「選擇PDF檔案」及「送出上傳要求」等活動；在循序圖中，「隊長」則是一條生命線，並以「要求上傳專題文件」訊息連到系統生命線。泳道中的活動不會因為名稱相同就自動成為循序圖訊息，仍須根據使用案例情境判斷哪些活動會跨越系統邊界並形成互動。

10.2.4 訊息的命名與表達方式

訊息名稱應表達接收者被要求完成的工作，例如「提交報名」「驗證身分」或「取得報名狀態」。避免使用「處理資料」等模糊名稱，也不要把畫面按鈕文字直接當成業務事件。

同步訊息表示傳送者通常等待接收者完成處理；非同步訊息表示傳送者不必等待。是否同步屬於重要互動語意，若需求沒有決定，不應僅憑技術習慣定案。FR-14要求透過電子郵件服務通知被刪除者，但沒有決定通知呼叫採同步或非同步方式。

回覆訊息可用來呈現處理結果或重要資料，但不必為每個呼叫都畫出回覆。應優先呈現對需求理解有幫助的成功、拒絕或錯誤資訊。執行規格（Execution Specification）是生命線上的細長矩形，表示該參與者或物件正在執行行為；分析層級若不需要討論執行期間，可以省略，不能把矩形長度當成精確時間。