[UML] クラス図を完璧に理解する
ソフトウェア開発は複雑なシステムを構築するプロセスです。複数の開発者が協業し、システムの構造を一目で把握しなければならないことも多いですよね。このとき、統一された約束事でシステムを視覚的に表現するツールがあったらどうでしょうか？そこに登場するのがまさに UML（Unified Modeling Language）です。
UML はオブジェクト指向ソフトウェアシステムを**視覚化（Visualize）**し、**仕様化（Specify）**し、**文書化（Document）**する標準モデリング言語です。特にマイクロサービスアーキテクチャや大規模システム設計が普及する中で、UML の重要性はさらに増しています。数多くの UML 図の中でも、**クラス図（Class Diagram）**はシステムの静的構造を明確に示すコアなツールです。
本稿では、クラス図の基本概念から構成要素、そして実際の活用法に至るまで順を追って見ていきます。このガイドを通して、システム構造をより明確に理解し、チームメンバーと効果的にコミュニケーションする能力を身に着けましょう。
クラス図の核となる要素
クラス図は、システムを構成するクラスとそれらの間の関係を視覚的に表現します。まるで建物の設計図のようにシステムの構造を一目で示すツールです。図を正しく読み、描くためにはまず基本構成要素を理解しておく必要があります。
1. クラス（Class）
クラスは同じ特徴と振る舞いを共有するオブジェクト群を表します。図では属性（attributes）とオペレーション（operations）を含む長方形で表現されます。
- クラス名：長方形の最上部に配置されます。名前は太字かつ中央揃えを用い、先頭文字を大文字で表記するのが慣例です。
- 属性（Attributes）：クラスが持つ静的データまたはフィールドを表します。中段に位置し、左揃えで表記します。普通はアクセス修飾子、名前、データ型を併記します。
+：public-：private#：protected~：default（パッケージプライベート）
例：
userId、totalPriceなど
- オペレーション または メソッド（Operations または method）：クラスが遂行できる動作、すなわちメソッドを意味します。最下部に位置し、属性と同様に左揃えで表記します。
例：
login()、calculateTotal()、cancelOrder()など
- 静的（Static）メンバー：静的属性やオペレーションは名前を下線を引いて表現します。
UML 標準では属性とメソッドの順序や改行も一貫して維持するべきです。実際の開発チーム内でのドキュメンテーションにおいては「チーム内 UML ネーミングルール」を別途定義しておくと良いでしょう。
2. 関係（Relationships）
クラス図の真価は、クラス間の関係を明確に示すことにあります。関係は主に矢印で表記され、異なる形の矢印が異なる意味を持ちます。矢印の方向はあるクラスが別のクラスをどのように使うかを示しています。
| 関係の種類 | 意味 | 矢印／記号の形状 | 説明 |
|---|---|---|---|
| 一般化（Generalization） | 継承関係 |  |
親クラス（Superclass）と子クラス（Subclass）間の関係を表します。 |
| 実体化（Realization） | インターフェース実装関係 |  |
クラスがインターフェースを implements する際に使用します。点線矢印で表現されます。 |
| 連関（Association） | 参照関係 |  |
あるクラスが他のクラスのオブジェクトを属性として参照している場合です。方向性は参照の流れを表します。 |
| 依存（Dependency） | 一時的使用関係 |  |
あるクラスが別のクラスをメソッドのパラメータや戻り値として使用する関係です。 |
| 集約（Aggregation） | 弱い全体―部分関係 |  |
「全体」が「部分」を含みますが、部分のライフサイクルは全体に依存しません。 |
| 合成（Composition） | 強い全体―部分関係 |  |
部分のライフサイクルが全体に完全に依存する時に使用されます。 |
例
ショッピングモールシステムを開発すると仮定してみましょう。‘ユーザー（User）’、‘商品（Product）’、‘注文（Order）’ クラスとそれらの相互作用をクラス図で表現できます。
classDiagram class User { - userId: int - name: string - email: string + login(): void + logout(): void } class Product { - productId: int - name: string - price: float + getInfo(): string } class Order { - orderId: int - date: Date - total: float + calculateTotal(): float } User "1" --> "1..*" Order : places > Order "1..*" --> "1..*" Product : contains >
クラス図はシステムの設計図の役割を果たし、開発初期段階でチームメンバーと構造を共有するのに非常に効果的です。
高度な概念：抽象クラスとインターフェース
オブジェクト指向設計において、**抽象化（Abstraction）**は核心的な概念です。クラス図でもこれを表現する方法があります。
- 抽象クラス（Abstract Class）：直接インスタンス化できないクラスです。クラス名を イタリック体 で表記するか、名前の下に
{abstract}キーワードまたは«abstract»ガーメットで表示します。 - インターフェース（Interface）：クラスが必ず実装すべきオペレーションの集合です。クラス名の上に
«interface»キーワードを付けて明確に区別します。
「実体化（Realization）」と「実装（Implementation）」は同じ概念です。UML 標準では Realization という用語を公式に使用しています。
クラス図はいつ使うか？
クラス図は開発段階に応じて様々な目的で活用できます。
- 概念段階（Conceptual）：システムの核心クラスと関係のみを単純に表現します。ビジネスロジックの理解に焦点を当てます。
- 仕様段階（Specification）：実際の開発前に、クラスのすべての属性・メソッド・関係を詳細に設計します。開発者がコードを記述できるレベルの設計図です。
- 実装段階（Implementation）：実際のコード構造をそのまま反映した図で、保守や他者へのコード構造説明時に有用です。
より良い開発への第一歩
これまでUML クラス図の基本概念から高度な活用法まで見てきました。クラス図を描くことは単なる図作成作業ではなく、システム構造を深く考え、複雑な関係を明確に整理するプロセスです。最初は違和感があるかもしれませんが、継続的に練習すれば、コードを書くより前に構造を設計する習慣が身に付きます。現在進行中のプロジェクトやサイドプロジェクトに、ぜひクラス図を適用してみてください。この小さな試みが皆さんの開発生産性と設計能力を一段階引き上げることでしょう。
《UML Distilled》 は UML を実務観点から最も効率的に習得できる入門書で、 :contentReference[oaicite:1]{index=1} が執筆した古典です。