序列圖是系統設計文檔中的基本組成部分。它們展示了物件隨時間互動的方式，提供工作流程邏輯的清晰視覺表示。理解序列圖符號對於架構師、開發人員和利益相關者來說至關重要，可確保以無歧義的方式溝通複雜的系統行為。本指南涵蓋了創建有效互動圖所需的語法、語義和最佳實踐。
🧩 理解基礎知識
序列圖用於描繪特定情境中參與者之間的互動。時間從上到下流動。水平軸代表不同的參與者，而垂直軸代表時間的流逝。該符號系統依賴於物件管理集團（OMG）為統一建模語言（UML）所定義的一套標準符號。
主要特徵包括：
- 時間順序：訊息按時間順序出現。
- 參與者：參與互動的實體（物件、角色、系統）。
- 訊息：參與者之間傳遞的訊號，用以觸發行為。
- 生命線：表示參與者在時間中存在性的垂直虛線。
🏗️ 核心符號元素
在深入複雜邏輯之前，必須掌握基礎符號。每個元素在定義系統組件的生命週期與通訊方面都具有特定用途。
1. 生命線與參與者
生命線代表參與者的一個實例。它以從圖表頂部延伸的垂直虛線繪製。線條頂端有一個矩形，內含物件或角色的名稱。此矩形用來固定生命線並識別實體。
- 角色：以人形圖示表示。通常代表人類使用者或外部系統。
- 物件：以包含物件名稱的矩形表示，通常以斜體標示（例如，OrderProcessor).
- 系統邊界：有時用於將屬於特定子系統的多個物件分組。
2. 活動條
活動條（或控制焦點）是放置在生命線上的細長矩形。它表示物件正在積極執行操作的期間。當收到訊息時，活動條開始；當操作完成或將控制權返回給呼叫者時結束。
- 執行控制：顯示物件正在忙碌處理的時刻。
- 堆疊深度： 多個激活條可以堆疊以顯示嵌套呼叫。
- 可見性： 有助於識別物件長時間等待的瓶頸。
3. 消息箭頭
消息以水平方式連接生命線。箭頭樣式定義了通信機制。標準類型包括：
- 同步呼叫： 實線搭配實心箭頭頭。發送者會等待接收者完成。
- 非同步呼叫： 實線搭配空心箭頭頭。發送者不會等待。
- 回應訊息： 虛線搭配空心箭頭頭。表示回應或資料回傳。
- 自我呼叫： 箭頭從同一條生命線開始並結束。用於內部方法呼叫。
⚙️ 進階邏輯與合併片段
現實世界的系統很少遵循單一的線性路徑。合併片段允許在圖表中進行條件邏輯、迴圈和並行處理。這些片段以矩形框起來，標籤位於左上角。
表格：常見的合併片段運算子
| 運算子 | 符號 | 用途 |
|---|---|---|
| alt | alt | 替代路徑（if/else 邏輯）。 |
| opt | opt | 選擇性路徑（若存在時）。 |
| loop | loop | 迭代過程（針對每個項目）。 |
| par | par | 平行執行（並行執行緒）。 |
| 中斷 | 中斷 | 例外處理（中止流程）。 |
| 關鍵 | 關鍵 | 資源鎖定（同步）。 |
1. 選項（alt）
該alt片段根據條件將互動分割成不同的部分。每個部分由一條水平虛線分隔。僅根據布林守衛條件的評估結果執行其中一個部分。
- 使用案例：驗證使用者輸入，其中成功與失敗路徑不同。
- 結構： 條件 1 | 條件 2 | 否則。
2. 選擇性（opt）
該opt片段代表一條可能發生也可能不發生的單一路徑。對於選擇性功能或非阻塞操作非常有用。
- 使用案例：僅在使用者選擇加入時發送通知郵件。
- 結構： [條件：使用者有權限]。
3. 迴圈
該loop片段表示封裝的訊息會重複執行。條件通常指定迭代次數或終止條件。
- 使用案例：處理來自資料庫的項目清單。
- 結構：[當 (items.hasNext()) 時].
4. 並行 (par)
該par片段顯示多個訊息同時發生。這在多執行緒環境或透過事件總線通訊的微服務中很常見。
- 使用案例：在同時記錄事件的過程中，將記錄儲存至資料庫。
- 結構： [並行].
🛠️ 物件生命週期管理
物件在系統執行期間會動態地被建立與銷毀。序列圖捕捉這些轉換，以顯示組件的生命週期。
物件建立
當產生新實例時，會向目標生命線傳送特殊訊息。箭頭頭部為帶有粗塊的實線，目標生命線從建立點開始。
- 建構函式呼叫：表示新物件的初始化。
- 工廠方法：通常用於抽象建立邏輯。
物件銷毀
當物件不再需要時，它將被銷毀。這以生命線上的一個「X」標記來表示。激活條在此點結束。
- 垃圾回收：標示局部變數作用域的結束。
- 交易回滾：表示暫時資源的清理。
📏 符號的最佳實務
建立圖表不僅僅是畫線；更重要的是清楚地傳達意圖。遵守標準可確保任何開發人員都能無歧義地閱讀文件。
1. 命名的一致性
為訊息和物件使用一致的命名慣例。如果物件在類圖中命名為OrderService在類圖中，它應命名為OrderService 在序列圖中。訊息名稱應反映正在執行的方法或動作。
- 動詞-名詞： 使用
getOrderDetails()而不是取得資訊. - 範圍：如果上下文不明確，請以物件名稱前置訊息。
2. 關注行為
序列圖描述的是行為，而非結構。除非資料庫表格或檔案系統路徑對邏輯流程至關重要，否則應避免顯示它們。應將焦點放在軟體組件之間的互動上。
- 抽象：除非圖表的重點在於查詢邏輯，否則應將資料庫視為黑箱。
- 狀態變更：不要試圖顯示每個狀態變數的變更；應專注於觸發條件。
3. 避免雜亂
過於擁擠的圖表是無用的圖表。如果序列圖變得過於複雜，請使用呼叫框架將其拆分為較小的子圖。
- 呼叫框架：將複雜的互動封裝為單一訊息方塊。
- 細化：為被呼叫的互動建立獨立的圖表。
4. 限制範圍
不要試圖在一個圖表中記錄整個系統。應專注於特定的使用案例或關鍵流程。圖表應回答一個具體問題，例如「付款是如何處理的？」，而不是「系統是如何運作的？」。
🚫 應避免的常見陷阱
即使經驗豐富的實務者也可能引入模糊性。請留意這些會降低文件品質的常見錯誤。
- 抽象層級混雜：不要在同一流程中同時顯示高階 API 呼叫與低階資料庫查詢。這會讓讀者對架構層級感到混淆。
- 忽略回傳訊息： 忘記顯示回傳訊息會讓圖表顯得不完整，並隱藏資料流。
- 過度使用迴圈： 在大段區域周圍放置迴圈會使圖表難以閱讀。建議改用呼叫框架來表示迴圈內容。
- 含糊的守衛條件： 寫成「if error」而非「if error code is 500」會降低精確度。
- 斷開的生命線： 確保所有參與者在邏輯上都相互連接。若某條生命線出現卻沒有任何訊息，很可能並不需要。
📝 文件策略
序列圖是更大文件生態系統的一部分。它們應與類圖、狀態圖和活動圖相輔相成。
與類圖的整合
序列圖中的參與者應對應於類圖中的類。若某參與者在類圖中不存在，則序列圖正在定義一個新的依賴關係，必須以結構化方式進行建模。
與狀態圖的整合
雖然序列圖顯示的是隨時間變化的互動，狀態圖則顯示單一物件狀態的變化。應使用序列圖描述系統流程，狀態圖則用於複雜物件邏輯。
🔄 維護與演進
文件並非一次性任務。隨著系統的演進，圖表必須持續更新。與當前程式碼不符的圖表，甚至比沒有圖表更糟糕。
- 版本控制： 將圖表視為程式碼。儲存在版本控制系統中。
- 審查流程： 在程式碼審查的拉取請求中包含圖表更新。
- 自動化： 在可能的情況下，從程式碼註解生成圖表，以減少實作與文件之間的偏差。
🎨 視覺風格與可讀性
雖然顏色與風格不會改變符號的語義，但對可讀性有顯著影響。使用視覺提示來區分不同類型的元件。
- 色彩編碼： 為外部系統（例如灰色）與內部服務（例如藍色）分配不同顏色。
- 字型粗細： 使用粗體文字表示關鍵訊息或高優先級的參與者。
- 對齊： 確保訊息箭頭對齊整齊。歪斜的線條暗示混亂。
🔍 深入探討：非同步通訊
理解非同步訊息傳遞對於現代分散式系統至關重要。在非同步呼叫中，發送者啟動訊息後立即繼續執行，接收者則在背景中處理訊息。
特徵：
- 發送即忘記： 發送者不會等待回應。
- 鬆耦合： 減少發送者與接收者之間的依賴性。
- 事件驅動： 常用於事件驅動的架構中。
在符號表示上，這以一條實線搭配開放箭頭表示。需要注意的是，雖然發送者不會等待，接收者仍需擁有生命線與激活條來處理傳入的任務。
🔍 深入探討：同步通訊
同步通訊意味著阻塞呼叫。發送者會暫停執行，直到接收者返回結果為止。這是在物件導向程式設計中大多數方法呼叫的預設假設。
特徵：
- 阻塞： 執行在呼叫點停止。
- 依賴性： 發送者依賴於立即的結果。
- 需要回應： 呼叫後必須有回應訊息。
在符號表示上，這以一條實線搭配實心箭頭表示。發送者的激活條會延續到收到回應訊息為止，視覺上呈現出等待時間。
🧠 符號語義總結
掌握序列圖符號需要理解每個符號的語法與背後意圖。以下重點總結了核心要點：
- 時間為垂直方向： 從上到下表示時間的推進。
- 參與者為水平方向： 從左到右表示不同的實體。
- 箭頭定義流程： 箭頭形狀定義阻塞與非阻塞。
- 框架定義邏輯：
alt,loop，以及平行定義控制結構。 - 激活定義工作：條形圖顯示物件忙碌時的狀態。
遵循這些標準，團隊可以確保其設計文件在整個軟體開發週期中保持清晰、可維護且具有價值。
