呈現系統互動不僅僅是顯示組件之間有對話，更需要清楚地呈現何時他們對話的時機，以及他們等待回應的等待回應的方式。序列圖是捕捉這種時間流動的標準工具。若缺乏精確的時序與同步規則，圖表將變成靜態地圖，無法傳達軟體執行的動態特性。本指南探討互動模型中時間、順序與狀態變化的運作機制。
🕰️ 理解互動模型中的時間軸
序列圖的基本軸是時間。與專注於決策邏輯的流程圖不同，序列圖強調時間上的順序。頁面上從左到右的每個元素都代表事件的演進。然而，真正的關鍵在於垂直軸。它定義了每個參與者的生命週期，以及動作發生的具體時刻。
要準確建模時序，必須理解以下核心元素：
- 生命線： 這些垂直的虛線代表物件或參與者在時間上的存在。它們是圖表的骨幹。
- 訊息： 連接生命線的箭頭代表通訊。箭頭的方向與樣式表示互動的類型。
- 激活條： 出現在生命線上的矩形方塊，顯示物件執行動作或等待結果的時段。
- 控制焦點： 這表示物件正在積極執行程式碼的期間。
當這些元素正確對齊時，圖表便講述了一段執行的敘事。若對齊錯誤，系統的邏輯將變得模糊。例如，若回應訊息在請求訊息尚未完全處理前就發出，模型便暗示了一種邏輯上不可能的情況。
🔄 訊息類型與同步
同步是參與者協調行動的機制。在序列圖的脈絡中，這通常指一個參與者等待另一個參與者完成任務後才繼續進行。所使用的箭頭類型決定了同步行為。
1. 同步呼叫
同步呼叫是最常見的互動模式。當參與者A向參與者B發送訊息時，A會等待B完成任務並回傳回應。這會產生阻塞行為，即A必須等到工作完成後才能繼續。
- 視覺指示： 一條實線搭配實心箭頭。
- 行為： 發送者暫停執行。
- 使用情境： 取得資料、處理交易、驗證輸入。
在同步情境中，發送者的激活條向下延伸，與接收者的激活條重疊。此重疊視覺上確認了發送者處於活躍狀態（等待中），而接收者正在處理。
2. 異步呼叫
非同步互動允許發送方在發送訊息後立即繼續其工作。這對於性能要求高的系統或背景任務至關重要。發送方不會阻塞；它觸發事件後便繼續執行。
- 視覺指示： 一條實線，箭頭為開放式。
- 行為： 發送方在不等待的情況下繼續執行。
- 使用案例： 記錄事件、發送通知、背景處理。
由於發送方不會等待，發送方的激活條通常在接收方的激活條開始之前結束，或延續到接收方仍在工作之處。這種視覺上的分離是區分非同步流程的關鍵。
3. 回應訊息
回應訊息代表回傳給呼叫者的回應。這些通常以虛線搭配開放式箭頭表示。它們完成了互動的迴圈。
- 時機： 必須在接收方處理時間之後出現。
- 內容： 通常攜帶一個值或狀態碼。
| 訊息類型 | 箭頭樣式 | 是否阻塞？ | 典型用途 |
|---|---|---|---|
| 同步呼叫 | 實線，實心箭頭頭 | 是 | 資料檢索、命令執行 |
| 非同步呼叫 | 實線，開放式箭頭頭 | 否 | 事件觸發、通知 |
| 回應訊息 | 虛線，開放式箭頭頭 | 不適用 | 回應資料、狀態確認 |
| 自我呼叫 | 同一直線上的曲線箭頭 | 是（內部） | 遞迴邏輯，內部處理 |
📊 活動條與控制焦點
活動條是……的視覺化表示控制焦點。它們清楚地顯示物件何時處於忙碌狀態。正確放置這些條狀圖對於理解同步點至關重要。
重疊的活動
當發生同步呼叫時，發送者的活動條會繼續向下延伸，而接收者的活動條則開始出現。這種重疊表示發送者處於等待狀態。如果發送者的活動條在接收者的活動條開始前就結束，則意味著發送者已經繼續執行，這與同步呼叫的定義相矛盾。
巢狀活動
複雜系統通常涉及更深層的處理層級。如果接收者呼叫另一個組件，就會出現一個嵌套在第一個活動條內部的新活動條。這形成了一種視覺層級結構，與呼叫堆疊相呼應。
- 第 1 層：使用者介面發送請求。
- 第 2 層：控制器處理邏輯。
- 第 3 層：資料庫取得資料。
每一層都必須明確地嵌套，以顯示依賴關係鏈。如果這些條狀圖被畫成並排而非嵌套，則暗示為平行執行，而非順序依賴。
⏳ 處理時間限制與依賴關係
標準的順序圖顯示邏輯順序，但現實世界中的系統通常具有嚴格的時間要求。建模這些限制可確保設計符合性能與可靠性目標。
時間區間
可以指定訊息必須在另一個事件發生後的某個時間範圍內傳送。這通常以註解或訊息箭頭附近的特定標籤來表示。
- 範例：「回應必須在 500 毫秒內到達」。
- 視覺化： 附加在回應訊息上的虛線或註解。
截止時間與例外情況
如果發生逾時會怎麼樣？一個穩健的圖表應考慮失敗情境。如果訊息未在定義的時間內收到，則應觸發例外流程。
| 約束類型 | 符號 | 含義 |
|---|---|---|
| 時間間隔 | [0..100毫秒] | 動作必須在0到100毫秒之間發生。 |
| 截止時間 | [截止時間: 1秒] | 動作必須在1秒過期前完成。 |
| 等待時間 | [等待: 5秒] | 系統在重試前等待5秒。 |
這些限制不僅僅用於文件記錄；它們還會影響測試策略。如果圖表中指定1秒的截止時間，自動化測試必須驗證系統是否在該時間窗內作出回應。
📡 異步與同步互動
區分這兩種模式對系統架構至關重要。混淆它們可能導致效能瓶頸或競爭條件。
何時使用同步
當操作結果立即需要用於下一步時，使用同步互動。
- 當前流程若無資料則無法繼續。
- 各組件之間需要立即保持一致性。
- 呼叫者需要在繼續之前知道成功或失敗。
何時使用異步
當操作可與主流程解耦時，使用異步互動。
- 頻繁發生的事件，不應拖慢使用者。
- 背景任務，例如發送電子郵件或生成報告。
- 需要獨立擴展的系統。
在圖表中，區別十分明確。同步呼叫會形成依賴鏈，使下一步無法進行。異步呼叫則會建立平行路徑，使下一步可以獨立進行。
❌ 時間表示中的常見錯誤
即使經驗豐富的設計師在建模時間時也會犯錯。識別這些陷阱有助於維持文件的完整性。
- 遺漏回傳訊息： 忘記繪製回傳箭頭會暗示該操作為「發射後忘記」，這對於同步呼叫可能不正確。
- 錯誤的激活重疊： 如果發送方的激活條在同步呼叫期間過早停止，這表示發送方在接收方開始之前就已完成工作，這在邏輯上是不可能的。
- 混合訊息類型： 使用實線箭頭表示背景任務，虛線箭頭表示關鍵回應，可能會讓讀者對流程的緊急程度和阻塞性產生混淆。
- 忽略逾時： 忽略網路呼叫失敗時的處理方式，會導致系統設計不完整。錯誤路徑是時序流程的一部分。
- 並行性模糊： 將訊息繪製在同一垂直層級上，暗示並行執行。如果它們本應是順序執行，則必須垂直錯開。
✨ 清晰度的最佳實務
序列圖的清晰度是透過一致性與遵循標準來達成的。遵循這些指引，可確保利害關係人能清楚理解時序與同步，不會產生混淆。
1. 維持垂直對齊
盡可能將相關訊息垂直對齊。如果訊息 A 導致訊息 B，B 應直接出現在 A 下方。這能降低追蹤流程所需的認知負荷。
2. 限制複雜度
一個圖表不應試圖呈現所有可能的互動。應將複雜流程拆分為多個圖表。
- 主要流程： 正常情況下的流程。
- 替代流程： 處理錯誤或例外情況。
- 擴展流程： 可選功能或副作用。
3. 使用合併片段
對於迴圈或條件時序等複雜邏輯，應使用合併片段（框架）。這些框體可讓您將相關互動分組，而不會使主流程混亂。
- alt： 替代路徑（if/else）。
- loop： 迴圈處理過程。
- opt： 選擇性互動。
4. 明確標註時序
不要假設讀者了解延遲預期。應在圖表中加入註解，明確標示時間限制，特別是針對外部系統。
🛠️ 建模現實情境
將這些概念應用於實際情境中，有助於鞏固理解。以下是時序與同步在不同情境中表現的範例。
情境 1：使用者登入
當使用者輸入憑證時，系統必須將請求與資料庫進行同步。
- 用戶端發送登入請求（同步）。
- 伺服器驗證憑證（處理中）。
- 伺服器查詢資料庫（同步）。
- 資料庫回傳結果（回傳訊息）。
- 伺服器發送驗證金鑰（回傳訊息）。
每個步驟都會阻塞前一個步驟。如果資料庫反應緩慢，使用者便需等待。圖表必須透過激活條來反映這段等待時間。
情境 2：訂單處理
訂單處理通常包含多個獨立的步驟。
- 用戶端提交訂單。
- 系統發送付款請求（同步）。
- 系統發送庫存檢查（非同步）。
- 系統發送確認郵件（非同步）。
在此情境中，庫存檢查與郵件發送不會阻塞付款確認。圖表應顯示付款回傳訊息結束主動等待，而庫存與郵件的激活條則可獨立繼續或啟動。
🧩 高階時序概念
對於高度複雜的系統，基本箭頭可能不足以表達。高階符號有助於傳達細微的時序行為。
訊息順序
並非所有訊息都會按照發送順序到達，尤其是在分散式系統中。您可以使用註解來表示訊息傳遞無法保證，或可能發生重新排序。
逾時處理
明確建模逾時可避免系統會無限等待的假設。以虛線表示逾時事件，並導向錯誤處理程序或重試機制。
可重入性
在某些系統中，元件在處理舊請求的同時可能收到新的請求。這需要在同一生命線中使用嵌套的激活條，以顯示第二個請求在第一個請求結束前就已進入。
🔍 審查您的圖表
在最終確定序列圖之前，請逐一核對檢查清單，以確保時序與同步正確無誤。
- 所有同步呼叫是否都顯示重疊的激活條？
- 非同步呼叫是否顯示發送者在接收者完成前就已繼續執行？
- 所有回傳訊息是否都與呼叫明確區分？
- 訊息的垂直順序是否與邏輯流程一致？
- 時間限制是否在必要時已標記？
- 錯誤路徑是否具有相應的時間表示？
定期審查可確保文件持續成為開發團隊可靠的真相來源。隨著系統的演進，圖表也必須隨之演進，以維持準確性。
🏁 最後的考量
時間與同步是維繫序列圖邏輯的隱形線索。它們將互動的靜態清單轉化為系統行為的動態呈現。透過仔細管理激活條、訊息類型與時間限制，您將建立一份能有效引導開發與測試的藍圖。
著重於清晰度而非複雜性。若圖表過於擁擠，應予以拆分；若時間限制至關重要，則應加以標示。目標是以精確的方式傳達控制與資料的流動。這種精確性可減少歧義，降低實作過程中的錯誤，並確保所有利害關係人對系統在時間壓力下的運作方式有共同的理解。
投入時間確保時間設定正確。這正是僅僅看起來正確的圖表與真正準確模擬系統的圖表之間的差別。
