システムの相互作用を可視化することは、開発者やアーキテクトにとって重要なスキルです。コードは論理を定義する一方で、図は流れを定義します。統一モデリング言語（UML）のなかで、通信図はオブジェクトが特定の振る舞いを達成するためにどのように協働するかという独自の視点を提供します。時系列を重視する順序図とは異なり、通信図はオブジェクト間の構造的関係やリンクに注目します。このガイドでは、明確で効果的な図を描くために必要な記号、ルール、ベストプラクティスを包括的に解説します。
通信図とは何か？ 🤔
通信図（以前は協調図と呼ばれていた）は、順序付きメッセージの観点からオブジェクト間の相互作用を示します。システムの静的構造に注目します。主な要素には以下が含まれます：
- オブジェクト：相互作用に参加するクラスのインスタンス。
- リンク：オブジェクト間の構造的接続。
- メッセージ：オブジェクト間の情報または制御の流れ。
- アクティベーション：オブジェクトが動作を実行している期間。
開発者は、時系列ではなく誰が誰と話しているかに注目する場合、この表記に頼ることが多いです。に注目する場合、この表記に頼ることが多いです。いつこの構造的視点は、システムアーキテクチャのトポロジーを理解するのに役立ちます。
基本的な記号と表記法 🔍
これらの図を効果的に読み書きするには、標準的な表記法を理解する必要があります。以下に、基本的な構成要素の詳細な解説を示します。
1. オブジェクトとインスタンス 📦
オブジェクトは長方形で表されます。インスタンス名とそれが属するクラス名がコロンで区切られて表示されます。たとえば、クラスOrderのインスタンス名orderProcessorはorderProcessor : Order.
- 名前： 特定のインスタンスを識別する。しばしば斜体で表される。
- クラス名： 型を定義する。常に標準フォントで表示される。
- 配置： オブジェクトはキャンバス上に自由に配置されるが、シーケンス図では垂直の列に揃えて配置される。
2. リンクと関連 🔗
リンクはメッセージが伝わる構造的経路を表す。クラス図で定義された関連に対応する。
- 方向： 単方向または双方向のどちらかである。
- ラベル： ナビゲーション経路にはラベルを付けることで、メッセージがどの方向に流れることを示すことができる。
- 多重度： リンクの端に接続できるインスタンスの数を示す（例：1、0..*、1..*）。関係の制約を理解する上で非常に重要である。
3. メッセージと相互作用 💬
メッセージは図の生命線である。オブジェクトを結ぶ矢印として描かれる。矢印は送信者から受信者へ向かう。
- 番号付け： 連番（1、2、3）は実行順序を示す。ネストされた番号（1.1、1.2）は主メッセージ内のサブメッセージを示す。
- テキスト： 矢印のラベルは呼び出される操作または送信される信号を説明する。
- 戻りメッセージ： 送信者に戻る破線の矢印で表される。
メッセージの種類について説明 📥
すべての矢印が同じではない。矢印の先端のスタイルと線のスタイルが特定の行動的意味を伝える。
| 記号のスタイル | メッセージの種類 | 説明 |
|---|---|---|
| 実線の矢印先端 | 呼び出し | 標準的なメソッド呼び出し。送信者は応答を待つ。 |
| 開放型矢印先端 | シグナル | 非同期メッセージ。送信者は応答を待たない。 |
| 破線矢印 | 戻り | 呼び出しやシグナルに対する応答。しばしば暗黙的だが、明示的に示すこともできる。 |
| 開放矢印 + ‘create’ | 生成 | 新しいオブジェクトのインスタンス化を示す。 |
| 開放矢印 + ‘destroy’ | 破棄 | オブジェクトインスタンスの削除を示す。 |
呼び出しメッセージ
呼び出しメッセージは同期操作を表す。送信者は受信者がタスクを完了するまで、自身の処理を一時停止する。これは標準的な手続き型フローにおける最も一般的な相互作用のタイプである。
シグナルメッセージ
シグナルは非同期である。送信者はメッセージを送信した後、すぐに自身の実行を継続する。これは、分離が必要なイベント駆動型アーキテクチャで一般的である。
自己メッセージ
オブジェクトが自身のメソッドを呼び出す場合、矢印は同じオブジェクトに戻る。これは外部の協調を伴わない内部処理ステップを示すためによく使われる。
活性化とタイミング ⏱️
通信図はシーケンス図のように時間に基づいてはいないが、依然として実行時間の長さを以下を通じて伝える。活性化バー.
- 外観：オブジェクトに接続するリンク上に描かれた細い長方形。
- 意味：受信したメッセージに関連する処理をオブジェクトが実行している期間を示す。
- 期間：バーの長さは実時間ではなく、他のタスクと比較した相対的な複雑さや処理時間の長さを示す。
活性化を理解することで、開発者はボトルネックを特定できる。オブジェクトに複数の重複する活性化がある場合、高い並行性または複雑な内部処理を示唆する。
オブジェクトのライフサイクル：生成と破棄 🔄
システム内のオブジェクトは静的ではない。生成され、使用され、破棄される。図記法はこのライフサイクルを明示的にサポートしている。
生成の記号
メッセージによって新しいオブジェクトが生成される場合、破線で描かれた矢印と開放的な矢印の先端が使用されます。ラベルは通常、”<<create>>または単にcreate。ターゲットオブジェクトは、新たに生成されたインスタンスです。
破壊の記号
逆に、オブジェクトがもはや必要でなくなった場合、破棄されます。これは、破線で描かれた矢印と開放的な矢印の先端がオブジェクトを指し、ラベルに”<<destroy>>またはdestroy。これは、リンク上に小さな‘X’を付けることで終了を示すことがよくあります。
制御構造と論理 🧠
現実世界のシステムには論理分岐、ループ、条件が含まれます。通信図はこれらを相互作用断片.
- Alt（代替）：if-else構造を表します。複数の断片は、”
altとラベルされたボックスで囲まれます。各断片にはガード条件（例：[条件が真]）があります。 - Opt（オプション）：オプションの相互作用を表します。”
optとガード条件を伴うボックスで囲まれます。 - Loop（ループ）：標準的なループを表します。”
loopと反復条件を伴うボックスで囲まれます。 - Break（例外）：例外または早期終了を表します。”
中断.
これらの構造により、図は多くの独立した矢印で視覚がごちゃごちゃにならないように、複雑なフローを記述できます。これらはそれらの内部に含まれるメッセージの文脈を定義します。
明確性のためのベストプラクティス ✨
読みにくい図は無意味です。図が目的を果たすことを確実にするために、これらのガイドラインに従ってください。
1. オブジェクト数を制限する
システム内のすべてのオブジェクトを含めるべきではありません。文書化している特定のシナリオやユースケースに焦点を当ててください。オブジェクトが多すぎると視覚的なノイズが生じ、主な相互作用の経路が見えにくくなります。
2. 一貫した名前付けを使用する
オブジェクト名がコードベースと一致していることを確認してください。クラスがUserServiceである場合、インスタンスをHelperとラベル付けしないでください。一貫性があることで、後に図を読む開発者の認知負荷が軽減されます。
3. メッセージに論理的な番号を付ける
メッセージの番号付けは論理的な流れを反映するべきです。メッセージがサブプロセスをトリガーする場合は、小数点表記（1.1、1.2）を使用してください。これにより、順序を推測せずに実行経路を追跡できます。
4. 冗長な戻りメッセージを避ける
戻り値が重要または複雑でない限り、すべての戻り矢印を描くべきではありません。それは図を混雑させます。データの戻りよりも制御フローに注目してください。
5. 関連する相互作用をグループ化する
1つのトランザクションまたは論理単位に属する相互作用を、フレームやボックスでグループ化してください。これにより、複雑なフローを扱いやすい部分に分解できます。
通信図 vs. シーケンス図 🆚
開発者はよく、どの図を使うべきか尋ねます。両者は同じ意味を持ちますが、表現方法が異なります。
- シーケンス図： 時間を優先する。縦軸が時間を表す。複雑なタイミングのシナリオや厳密な順序が必要な場合に最適。
- 通信図： 構造を優先する。水平／2次元レイアウトがリンクを表す。オブジェクトのトポロジーやナビゲーション経路を理解するのに最適。
Object AがObject Cと通信する前にObject Bと通信しなければならないことを示す必要がある場合、シーケンス図の方が明確です。Object AがObject B、C、D、Eとスター構造で通信していることを示す必要がある場合、通信図はしばしばよりコンパクトです。
避けたい一般的な落とし穴 ⚠️
経験豊富な実務家ですらミスを犯します。これらの一般的な誤りに注意してください。
- 記法の混在： シーケンス図の垂直ライフラインと通信図のリンクを組み合わせてはいけません。1つのスタイルを選んで、それを一貫して使用してください。
- 過密化： システム全体のアーキテクチャを1つの図に収めようとする。機能やモジュールごとに図を分割する。
- 曖昧なラベル： 「
プロセス」や「ハンドル」といった一般的な用語を使用し、メソッド名を明示しない。具体的に記述する。 - 多重性の無視： リンクが複数のオブジェクトを許容することを示さない。実装が単一の関係を想定している場合、実行時エラーにつながる可能性がある。
ステップバイステップ作成ガイド 🛠️
図を描く際は、このワークフローに従ってください。
- シナリオの特定： あなたがモデル化しようとしている特定のユーザー操作またはシステムイベントを定義する。
- エクスプレスとオブジェクトをリストアップする： この特定のフローに関与するクラスを特定する。
- オブジェクトを描く： 図面に長方形を配置する。関連するオブジェクトを空間的にグループ化する。
- リンクを描く： クラス図の関連に基づいてオブジェクトを接続する。
- メッセージを追加する： 実行順に矢印を描く。順番に番号を付ける。
- リファイン： 活性バー、ガード条件、ラベルを追加して明確にする。
- レビュー： コードの論理と照合して正確性を確認する。
高度なシナリオ 🔥
一部の相互作用には、より高度な表記が必要となる。
再帰
オブジェクトが自分自身のメソッドを繰り返し呼び出す場合、セルフループ矢印を使用する。これは木の走査や再帰的アルゴリズムでよく見られる。ループにラベルを付けて、ベースケースの条件を示す。
例外処理
次のbreak例外が通常の流れを中断するタイミングを示すために、このフラグメントを使用してください。これは、開発者が見過ごしがちなエラー経路を文書化する上で非常に重要です。
パラメータの渡し方
メッセージラベルにパラメータ値を含めることができます。たとえば、login(username, password)。これにより正確性が向上しますが、ごちゃごちゃにならないように控えめに使用してください。
結論 🎯
通信図の記号を習得することで、複雑なシステムを正確かつ明確に文書化できます。オブジェクト、リンク、メッセージの微細な違いを理解することで、チームにとって信頼できる参照資料となる図を描くことができます。目的は文書化ではなく、コミュニケーションであることを忘れないでください。図はシンプルで、一貫性を持ち、特定の振る舞いに焦点を当てるようにしてください。
複雑な相互作用の流れに遭遇した際には、このチートシートを参照してください。システムの進化に伴い、図を定期的に更新してください。動的な図は、文書化における技術的負債が蓄積されるのを防ぐ貴重な資産です。
練習を重ねることで、これらの図の読み方や作成は自然な感覚になります。早期に設計上の欠陥を発見でき、アーキテクチャの意思決定をより効果的に伝えるのに役立つことに気づくでしょう。