設計レビューで「シーケンス図で描いて」と言われて手が止まる人向けに、使う図形と描き方のルールをまとめた。
記法はUMLに沿い、図はすべてMermaidで再現できる形で載せる。
縦が時間、横が登場人物
シーケンス図は「誰が、どの順番で、誰にメッセージを送るか」を表す図。
横に参加者を並べ、時間は上から下へ流れる。下にある矢印ほど後に起こる。
フローチャートが「処理の手順」を描くのに対し、シーケンス図は「やりとり」を描く。
この違いを押さえておくと、何を図に入れるべきか迷いにくい。
基本の図形
| 図形 | 名前 | 意味 |
|---|---|---|
| 上部の四角 | ライフラインの頭（参加者） | 登場するオブジェクトや人。名前:クラス名 と書くこともある |
| 棒人間 | アクター | システム外の人間。四角で描いても間違いではない |
| 下に伸びる破線 | ライフライン | その参加者が存在している時間 |
| 縦長の細い四角 | 実行仕様（活性区間） | その参加者が処理をしている最中 |
| 実線＋塗りつぶし三角 | 同期メッセージ | 呼び出して、返事が来るまで待つ |
| 実線＋開いた矢じり | 非同期メッセージ | 送りっぱなしで待たない |
| 破線＋開いた矢じり | 戻りメッセージ | 呼び出しへの返事 |
| 自分に戻る矢印 | 自己メッセージ | 自分自身の処理を呼ぶ |
| 左上に見出し付きの枠 | 複合フラグメント | 条件分岐やループの範囲 |
全部入りの例：ログイン処理
上の図形をひととおり使うとこうなる。
+ と - は実行仕様（活性区間）の開始と終了。
->>+W で Webサーバー の処理が始まり、deactivate W で終わる。
矢印の描き分け
矢印の種類で意味が変わるので、ここが一番大事。
| 種類 | 見た目 | Mermaid記法 | 使いどころ |
|---|---|---|---|
| 同期メッセージ | 実線＋塗り矢じり | A->>B |
関数呼び出し、HTTPリクエスト |
| 戻りメッセージ | 破線＋矢じり | B-->>A |
戻り値、レスポンス |
| 非同期メッセージ | 実線＋開いた矢じり | A-)B |
キュー投入、イベント発行 |
| 自己メッセージ | 自分へ戻る矢印 | A->>A |
内部メソッド呼び出し |
手書きだと同期と非同期の矢じりが曖昧になりやすい。
「待つのか、待たないのか」はレビューで必ず突っ込まれるので描き分けること。
複合フラグメント
条件分岐や繰り返しは枠で囲み、左上に種類を書く。
| 種類 | 意味 | コードでいうと |
|---|---|---|
alt |
条件分岐。破線で区切り、各区画に [条件] を書く |
if / else |
opt |
条件を満たす時だけ実行 | elseのない if
|
loop |
繰り返し。loop [3回] のように条件を添える |
for / while |
par |
並行処理 |
Promise.all など |
描くときのルール
- 時間は必ず上から下に流す
- 矢印には送る内容（メソッド名、リクエスト内容）を書く
- 最初に動き出す参加者を左端に置く
- 1枚の図には1つのシナリオだけを描く
最後の項目は特に重要。「ログイン成功時」「パスワード誤り時」のようにシナリオ単位で分けると読みやすくなる。
初心者がやりがちなミス
戻りメッセージを全部描こうとして図が煩雑になる。
戻り値が自明なら省略してよい。UMLでも戻りの記載は任意。
alt を入れ子にしすぎる。
分岐が3段以上になったら、シナリオを分けて別の図にしたほうがいい。
フローチャートと混同して、判断の手順まで細かく書いてしまうことも多い。
「AがBに何を頼むか」に絞り、内部の判断ロジックは別の図か本文に回す。
手で描くのが面倒なら、MermaidやPlantUMLのようにテキストから生成するツールを使うと、矢印の種類を間違えにくい。
差分がGitで追えるので、設計書に貼る図としても扱いやすい。