UMLでは、図は大きく二つの主要なカテゴリに分類される：構造図と振る舞い図。以下に、14種類の図のそれぞれについての簡単な説明とその分類を示す：
構造図（静的モデリング）:
- クラス図 （構造）：
- システムの静的構造、すなわちクラス、属性、関係を表す。
- オブジェクト図 （構造）：
- 特定の時点におけるインスタンスのスナップショットを示し、オブジェクトとその関係を描写する。
- パッケージ図 （構造）：
- 要素をパッケージに整理し、システムの構成の高レベルな視点を提供する。
- コンポーネント図 （構造）：
- システムのコンポーネントとその相互作用に焦点を当て、システムアーキテクチャに有用である。
- 複合構造図 （構造）：
- クラスの内部構造、すなわち部品、ポート、接続子を表す。
- 配置図 （構造）：
- システム内のコンポーネントとノードの物理的配置を描写する。
振る舞い図（動的モデリング）:
- ユースケース図 （振る舞い）：
- ユーザーの視点からシステムの機能を示し、アクターとユースケースを描写する。
- アクティビティ図 （振る舞い）：
- システム内の活動やアクションの流れをモデル化し、並列的および条件付きの振る舞いを含む。
- 状態機械図（振る舞い）：
- オブジェクトまたはシステムの振る舞いを、状態と遷移を持つ有限状態機械として表す。
- シーケンス図（振る舞い）：
- 時間の経過に伴うオブジェクト間の相互作用を示し、メッセージの順序に注目する。
- コミュニケーション図（振る舞い）：
- オブジェクト間の関係性と、タスクを達成するためにどのように協働するかに注目する。
- 相互作用概要図（振る舞い）：
- アクティビティ図とシーケンス図を組み合わせて、複雑な相互作用の概要を提供する。
- タイミング図（振る舞い）：
- 相互作用のタイミング制約に注目し、ライフラインやイベントを含む。
- プロファイル図 （構造）
- カスタムスタereotype、タグ付き値、制約を定義することで、UMLメタモデルを拡張するために使用される特別なUML図。プロファイル図はUMLの拡張メカニズムの一部であり、特定のモデリングニーズやドメインに合わせてUMLをカスタマイズできる。
これらのUML図は、ソフトウェアシステムのモデリングにおいて異なる目的を果たし、構造図は静的側面に注目し、振る舞い図は動的側面に注目する。適切な図の種類を選ぶことは、システムの特定の側面を表現または伝えるかどうかに依存する。
構造図と振る舞い図の違い
構造図はシステムの静的ビューを提供し、そのコンポーネント、関係性、組織に注目するのに対し、振る舞い図は動的ビューを提供し、実行時の振る舞い、相互作用、プロセスに注目する。これらの2つの図のカテゴリーはそれぞれ異なる目的を持ち、ソフトウェアシステムの包括的なモデリングとドキュメント作成に不可欠であり、静的および動的側面の両方に対応する。
以下は、14種類のUML図を2つのカテゴリーに分類し、それぞれに簡単な例を示した表である。
構造図（静的モデリング）：
| 図の種類 | 説明 | 例 |
|---|---|---|
| クラス図 | 静的クラス構造と関係性を表す。 | 例：「Book」などのクラスを用いて図書館システムをモデリングする。Book, 著者、および図書館. |
| オブジェクト図 | 特定の瞬間におけるインスタンスとその関係を示す。 | 例：特定の本および会員図書館システム内のオブジェクト。 |
| パッケージ図 | 要素をパッケージまたは名前空間に整理する。 | 例：関連するクラスを図書管理パッケージにグループ化する。 |
| コンポーネント図 | 物理的または論理的なシステムコンポーネントとその接続を示す。 | 例：Webシステム内のデータベース、Webサーバー、クライアントアプリケーションなどのソフトウェアコンポーネントを図示する。 |
| 複合構造図 | 部品、ポート、接続子を用いてクラスの内部構造を詳細に示す。 | 例：CPU、RAM、マザーボードなどのコンポーネントを用いたコンピュータシステムの内部構造を示す。 |
| 配置図 | ノードまたはサーバー上のコンポーネントの物理的配置を表示する。 | 例：Webサーバーソフトウェアコンポーネントが物理サーバーにどのように配置されているかを表す。 |
振る舞い図（動的モデリング）：
| 図の種類 | 説明 | 例 |
|---|---|---|
| ユースケース図 | ユースケースを通じて、アクターとシステムとの相互作用を定義する。 | 例：顧客が現金を引き出すためにATMシステムとどのようにやり取りするかをモデル化する。 |
| アクティビティ図 | システム内のワークフロー、プロセス、およびアクションを、分岐や並列性を含めて描写する。 | 例：オンライン注文の処理に必要なステップを説明する。 |
| ステートマシン図 | オブジェクトまたはシステムの振る舞いを、状態と遷移を持つ有限状態機械として表現する。 | 例：交通信号システムの状態と遷移をモデル化する。 |
| シーケンス図 | メッセージを通じて、時間経過に伴うオブジェクトやコンポーネント間の相互作用を表示する。 | 例：ログインプロセス中にユーザーとデータベースシステムとの間で送信されるメッセージの順序を示す。 |
| コミュニケーション図 | オブジェクト間の相互作用およびシステム内の協働を重視する。 | 例：チャットアプリケーション内のオブジェクトがメッセージをどのようにやり取りするかを可視化する。 |
| インタラクション概要図 | アクティビティ図とシーケンス図の要素を組み合わせて、複雑な相互作用の概要を提供する。 | 例：小売システムにおける複雑な注文処理ワークフローを簡略化する。 |
| タイミング図 | 相互作用のタイミング制約、包括的にライフラインとイベントを指定する。 | 例：ネットワーク内のデバイス間でのデータ送信のタイミングを示す。 |
これらの表は、各UML図を「構造図（静的モデリング）」または「振る舞い図（動的モデリング）」のカテゴリに分類し、各タイプの簡単な説明と例のシナリオを併記している。
ソフトウェア設計におけるUML図の多面的役割
ソフトウェア設計におけるさまざまな種類の図は、それぞれ特定の目的を持ち、ソフトウェアシステムに対するさまざまな視点を提供する。以下は、なぜ異なる種類の図が必要なのかという主な理由である。
- 明確さとコミュニケーション：ソフトウェアプロジェクトにおける異なるステークホルダー、開発者、アーキテクト、テスト担当者、ビジネスアナリストなどは、システムを理解する上で異なるニーズを持つ。異なる種類の図を使用することで、それぞれの役割に応じた情報をカスタマイズでき、コミュニケーションがより効果的になる。
- 抽象度のレベル：ソフトウェアシステムは複雑であり、異なる側面は異なる抽象度のレベルで考慮する必要がある。クラス図のような図は高レベルの構造的視点を提供するが、シーケンス図のような図は詳細な振る舞いに関する洞察を提供する。
- 問題解決：ソフトウェア設計および開発における異なる問題には、それぞれ異なるアプローチが必要となる。たとえば、システムの静的構造をモデル化する際にはクラス図がより適しているが、動的振る舞いを理解するにはシーケンス図が適している。
- システムの理解: 異なる図は、システムを観察するための異なる視点を提供する。これにより、システムのアーキテクチャ、動作、相互作用、展開などを含む包括的な理解が得られる。
- ドキュメント作成: 総合的なドキュメントはソフトウェアプロジェクトにとって不可欠である。さまざまな種類の図を用いることで、開発の各段階でチームメンバーが簡単に参照できる、構造的で視覚的なドキュメントを作成できる。
- 要件分析: ユースケース図とアクティビティ図は、システム要件やワークフローを把握・分析するのに有効である。これらはソフトウェアがユーザーのニーズと一致することを確保するのに役立つ。
- アーキテクチャ設計: コンポーネント図とデプロイメント図はアーキテクチャ設計に不可欠である。これらはシステムの構造を計画し、実世界の環境での展開方法を検討するのに役立つ。
- テストと検証: シーケンス図と状態機械図は、テストケースの設計や要件との整合性を確認するためのシステム動作の検証に役立つ。
- 意思決定: 異なる種類の図は、異なる洞察を提供する。意思決定プロセスにおいて、アーキテクトやプロジェクトマネージャーはこれらの図を用いてトレードオフを評価し、情報に基づいた選択を行うことができる。
- 保守のしやすさ: 図はソフトウェアの保守と進化を助ける。開発者がシステムを変更または拡張する際、これらの視覚的表現は既存の構造や動作を理解するための貴重な参考となる。
要約
ソフトウェア設計におけるUML図の多様性は、ソフトウェアシステムの多面的な性質に対応している。各図の種類には特定の目的があり、独自の視点を提供するため、初期設計から実装、テスト、保守に至るまで、ソフトウェア開発のさまざまな段階において不可欠なツールとなる。