什麼是序列圖？
一個序列圖是一種行為UML 圖詳細描述了軟體操作如何隨時間進行。作為統一建模語言（UML）規範的核心標準，它模擬了物件、程序或微服務交換訊息的精確時間順序。透過將生命線垂直排列，並以水平方式呈現順序互動，這種特定的UML 圖類型讓軟體工程師與系統架構師能在撰寫生產程式碼之前，清楚地視覺化複雜的 API 呼叫序列、網路資料交握，以及資料庫交易邊界。
使用VPasCode您不必花費數小時來對齊平行箭頭、拉長訊息線，或移動邊框框以騰出新步驟的空間。我們的佈局引擎會在您輸入純文字宣告式指令時，動態計算整個時間軸網格。
核心語法指南：元素與構造
要在 PlantUML 中設計出可執行且符合標準的 UML 序列圖，您必須掌握元件宣告、訊息箭頭樣式、生命線，以及邏輯控制結構。
1. 聲明 UML 參與者與形狀
預設情況下，此 UML 圖中的元件會繼承標準的方形框形狀。然而，您可以透過使用特定的 UML 關鍵字，改變實體的視覺原型，讓讀者立即了解系統邊界之架構脈絡。
actor Client
boundary "API Gateway" as Gateway
control Controller
database "PostgreSQL" as DB
2. 訊息箭頭與同步性
您的箭頭線條與箭頭頭部的樣式，根據 UML 圖標準，確立了跨基礎設施管道的通訊協定：
- 同步請求（阻塞式）：以實線與實心箭頭頭表示。發送者會等待回應：
A -> B - 非同步訊息（非阻塞式）：以實線與空心細箭頭頭表示。發送者傳遞資料後立即繼續：
A ->> B - 回應／回傳值：以虛線與空心箭頭頭表示：
B --> A
3. 管理生命线（激活與停用）
為了防止您的組件看起來像扁平的條狀，您應該明確顯示當一個流程正在積極消耗 CPU 線程或記憶體容量時的情況。使用 activate 和 deactivate 標記，或使用簡寫的內聯遞增語法（++ / --):
Gateway -> Controller ++ : "processPayment()"
Controller --> Gateway -- : "返回收據"
4. 邏輯區塊：替代方案、迴圈與平行
複雜的業務邏輯（例如 if/else 分支、資料庫重試或平行執行線程）必須包裝在 UML 圖表規範中稱為組合片段的結構化全域框架邊界內：
- 條件邏輯（alt / else）： 模型條件分支。
Plantuml Edit Plantuml in VPasCode
alt 成功條件 A -> B : "繼續處理請求" else 失敗狀態 A -> B : "拋出錯誤代碼" end
- 重複迴圈（loop）： 模型迭代、重試或佇列處理區塊，直到條件滿足為止。
Plantuml Edit Plantuml in VPasCode
loop 直到佇列為空 Worker -> Queue : "取得下一個工作" end
- 平行執行（par）： 模型將在獨立線程中同時執行的操作分開。
Plantuml Edit Plantuml in VPasCode
par 並行執行流程 A -> LogService : "寫入追蹤分析" else A -> DB : "提交客戶資料檔" end
清晰序列的最佳實務
- 使用分隔線分組訊息： 使用雙等號 (“
== 您的階段 ==) 來將龐大的驗證至結帳序列拆分成明確的邏輯里程碑。 - 使用自動編號： 將
autonumber指令直接放在@startuml。這會強制工作區在每個箭頭上標記步驟編號，使程式碼審查變得更容易。 - 保持回應簡潔： 避免在回傳箭頭上寫下冗長的描述性句子 (
-->)。相反地，只需標示傳回的原始資料物件或 HTTP 狀態碼 (例如，"201 建立 Token").
真實世界的 PlantUML 序列圖範例
範例 1：微服務驗證迴圈 (Alt 區塊與生命線)
此範本處理標準安全流程，其中客戶端對網關進行驗證，展示明確的生命線以及在標準 UML 圖表格式內的替代條件結果框架。
@startuml
autonumber
actor 使用者
boundary "Web 應用程式" as App
control "驗證服務" as Auth
使用者 -> App ++ : "提交憑證"
App -> Auth ++ : "POST /v1/auth"
alt #LightGreen 成功登入
Auth --> App : "200 OK (JWT Token)"
App --> 使用者 : "顯示儀表板"
else #LightPink 憑證無效
Auth --> App : "401 未授權"
App --> 使用者 : "顯示錯誤提示"
end
deactivate Auth
deactivate App
@enduml
語法解析： 這 自動編號 標籤會自動管理 1 到 5 的編號。這 alt 和 else 模塊會附加自訂的十六進位顏色標籤（例如 #LightGreen），以立即在成功與失敗的執行路徑之間添加視覺強調。這 ++ 標籤確保生命線在網路呼叫區塊期間保持活躍。
範例 2：進階訂單處理（迴圈、平行與分隔）
此企業架構藍圖模擬了一個強大的結帳系統，可將任務分割至平行工作人員，執行資料庫寫入，並依賴外部系統的同步迴圈。
@startuml
autonumber
boundary "結帳 API" as API
database "訂單資料庫" as DB
control "工作佇列" as Queue
boundary "Stripe" as Stripe
== 階段 1：交易帳本驗證 ==
API -> DB ++ : "寫入待處理訂單"
DB --> API -- : "訂單 ID 已確認"
== 階段 2：付款與非同步履行 ==
API -> Stripe ++ : "扣款客戶帳戶"
Stripe --> API -- : "付款已授權"
par 平行背景作業
API -> Queue ++ : "發布 'Order_Placed' 事件"
deactivate Queue
else
API -> DB ++ : "更新狀態為 '已付款'"
deactivate DB
end
loop 網路故障時最多重試 3 次
API -> API : "Ping 通知同步 Webhook"
end
API --> Client : "回傳 HTTP 200（成功）"
@enduml
語法解析： 這 == 分隔符將佈局分割為不同的操作階段。這 par 區塊會乾淨地從訊息箭頭路徑分出兩條獨立的水平路徑，顯示事件發佈與資料庫狀態更新同時發生，彼此不會阻塞。自指向箭頭（API -> API）能完美對應到本地內部實例函數迴圈。