UMLシーケンス図は、システムの動的挙動を理解するための重要なツールです。オブジェクトどうしがどのように相互作用するか、そしてその相互作用がどの順序で発生するかをモデル化し、メッセージの時間順序を強調しています。メッセージの時間順序の流れこれは、ユースケースの定義、API呼び出しの文書化、複雑なトランザクションフローの追跡において不可欠です。
このチュートリアルでは、シーケンス図の基本的な要素とモデリング技術についてご案内します。
コア構造と目的
シーケンス図は二つの軸に沿って構成されています：
- 水平軸：参加するオブジェクト（またはアクター、クラス、コンポーネント）。
- 垂直軸（時間軸）：時間の流れを表し、下向きに進みます。図の下部に送信されたメッセージは、順序上後に発生します。
その目的は、次の問いに答えることです：「この特定のシナリオ（ユースケース）において、これらのオブジェクトが情報を交換する順序はどのようになりますか？目的の結果を達成するために。」
シーケンス図の基本要素
シーケンスをモデル化するには、3つの主要な要素が必要です：ライフライン、メッセージ、アクティビティバー。
A. ライフライン（参加者）
ライフラインは、相互作用における単一の参加者（オブジェクト、インスタンス、またはクラス）を表します。
- 表記法：図の上部に、オブジェクト名を含む長方形のボックスがあり、垂直方向の破線が下向きに延びます。
- 構文：
参加者名（オブジェクトがインスタンスの場合、例としてuser)インスタンス名: クラス名（例としてauthService: AuthenticationService)
- 目的：破線は、シーケンスの範囲内で参加者の時間経過にわたる存在を示しています。
B. メッセージ（相互作用）
メッセージはライフラインの間に描かれる水平の矢印です。オブジェクト間の通信、たとえばメソッド呼び出し、シグナル、またはAPIリクエストを表しています。
メッセージの種類：
| メッセージの種類 | 表記法 | 説明 |
|---|---|---|
| 同期呼び出し | 矢じりが塗りつぶされた実線 | 送信者は続行する前に応答を待つ。これにより受信者のライフライン上にアクティベーションバーアクティベーションバーが生成される。 |
| 返信／戻り値 | 矢じりが空洞の破線 | 同期呼び出しに対する応答であり、制御が送信者に戻ることを示す。通常、これによりアクティベーションバーが閉じられる。 |
| 非同期メッセージ | 矢じりが空洞の実線 | 送信者は応答を待たず、直ちに自身の処理を継続する。イベント駆動型アーキテクチャで一般的である。 |
| 自己呼び出し | 同じライフラインに戻る矢印 | オブジェクトが自身のメソッドの一つを呼び出すこと。 |
| 発信者不明メッセージ | エンドポイントから出発しライフラインに到達する矢印 | メッセージの送信者が不明または図の範囲外である（例：外部トリガー）。 |
C. アクティベーションバー（実行仕様）
アクティベーションバー（制御の焦点とも呼ばれる）は、ライフラインの上に描かれる細い垂直矩形である。
- 表記法：ライフライン上の実線の垂直矩形。
- 目的： これは、オブジェクトがアクティブに操作を実行中（つまり、そのメソッドが実行中）または同期的な戻り値を待機している期間を示します。同期メッセージが受信されたときに開始され、応答メッセージが送信されたときに終了します。
論理と制御フローのモデリング
複雑なビジネスロジックをモデル化するには、図の一部を囲むために断片（またはボックス）を使用します。
A. 組み合わせ断片
組み合わせ断片を使用すると、条件付きロジック、繰り返し、オプションステップをモデル化できます。最も一般的な断片には以下があります：
- 代替（alt）： 以下に使用されます：if-else ロジック。断片は点線で分割され、各セクションには四角かっこ内の条件（「ガード」）が含まれます。一つのパスしか選択できません。
- 例：
[ユーザーの認証情報が有効である場合]および[それ以外 / 認証情報が無効].
- 例：
- オプション（opt）： 以下に使用されます：if 文。断片内のインタラクションはオプションであり、条件（ガード）が真である場合にのみ実行されます。
- 例：
[ユーザーがカートに商品を持っている場合].
- 例：
- ループ（loop）： 繰り返しに使用します。ガードは反復の条件を指定します（例：
[各商品について]または[while (再試行回数 < 3)]). - 参照（ref）：別の独立したシーケンス図で定義されたインタラクションシーケンスを参照することで、図をモジュール化します。これにより、図が複雑になりすぎることを防ぎます。
- 重要（crit）： 中断してはならないセクションを示すために使用され、しばしば並行処理をモデル化するために使用される。
ステップバイステップのモデリング例
簡略化されたものをモデル化しましょうユーザーのチェックアウトプロセス コア要素を使用して：
| ステップ | アクション | メッセージタイプ |
|---|---|---|
| 1. | ユーザーが「チェックアウト」をクリックする。 | 同期呼び出し |
| 2. | フロントエンドがカートを検証する。 | セルフコール（フロントエンド上） |
| 3. | フロントエンドが支払い処理を要求する。 | 同期呼び出し |
| 4. | 決済ゲートウェイが資金を確認する。 | 同期呼び出し |
| 5. | 決済ゲートウェイが「成功」を返す。 | 戻りメッセージ |
| 6. | フロントエンドは在庫を減らすためにインベントリサービスに非同期メッセージを送信する。 | 非同期メッセージ |
| 7. | フロントエンドは注文を確定するためにオーダーサービスに同期メッセージを送信する。 | 同期呼び出し |
| 8. | 注文サービスは「注文ID」を返す。 | 返信メッセージ |
| 9. | フロントエンドは確認ページを表示する。 | 返信メッセージ（ユーザーへ） |
論理のモデリング（代替フラグメント）
失敗を処理するために、私たちは代替フラグメント：
- 以下のものを配置する決済ゲートウェイのチェック（ステップ4および5）を
altフラグメント内に。 - 最初のセクションは
[成功]によって保護されている。このセクションにはステップ6、7、8、9が含まれる。 - 2番目のセクションは破線によって区切られており、
[失敗]によって保護されている。このセクションには新しい同期メッセージが含まれる：paymentService -> frontend: 「支払い失敗」を返すそしてフロントエンドはエラーページを表示する。
シーケンス図のベストプラクティスの要約
- 焦点を絞る：単一のシーケンス図は通常、単一のユースケースまたは単一の原子的な操作（例：「ログイン」、「カートに商品を追加」）をモデル化すべきである。サブプロセスには参照フラグメントを使用する。
- メッセージを明確にラベル付けする：メッセージには動詞句を使用し、メソッド名やAPIエンドポイントを反映させる（例：
processPayment(amount, token)). - 参加者を正しく特定する： 以下のものを区別する：アクター （外部エンティティ）とオブジェクト （内部システムコンポーネントまたはインスタンス）。
- 時間の流れは下向き： メッセージが常に上から下へと一貫して順序付けられていることを確認する。
- 制御にはフラグメントを使用する： メッセージフロー内に複雑な決定ノードやループを描かないようにする。代わりに
alt,opt、およびloopフラグメントを使用する。
UMLおよびそのAI駆動の可視化手法の詳細を知るには、当社のUMLリソースハブ.