The UMLクラス図はしばしばオブジェクト指向設計の出発点となる。システムの語彙——クラス、その属性、振る舞い、そしてそれらを結びつける関係——を捉える。概念モデルを描く場合でも、実装用の詳細な図面を構築する場合でも、クラス図の構文を理解することは不可欠である。
このガイドでは、主要な記法、主要な関係の種類、そしてUMLを日常の設計課題と結びつける明確な例を紹介する。
クラス図が表すもの
クラス図は静的構造を記述する。行動図とは異なり、流れやタイミングに注目しない。代わりに、システムがどのように構成されているかを説明する：
- どのようなクラスが存在するか
- どのようなデータを保持しているか
- どのような操作を実行するか
- どのように互いに接続されているか
多くのUMLモデルの基盤となっているのは、オブジェクト指向の思考を視覚的で構造的な方法で形式化するためである。
クラス図の構文：基本的な要点
クラスの表記法
クラスは、最大3つの領域に分けられた長方形として描かれる：
- クラス名（必須）
- 属性（オプション）
- 操作（オプション）
例：
属性
属性はオブジェクトの状態を表す。
構文：
可視性 名前 : 型 = デフォルト
可視性の記号：
+公開-秘密#保護
例：
操作は、クラスが提供する振る舞いまたはサービスを表します。
構文：
例：
クラス図における関係の種類
クラス図の力は、クラス間の接続にあります。最も一般的な関係の種類は、オブジェクトがどのように相互作用するか、または互いに依存するかを表します。
関連
関連は、クラス間の構造的リンクを示します。
- 含むことができる役割, 多重度、またはナビゲーション性.
- 安定した、長期的な接続を表す。
例：
A 顧客は多くの注文.
集約
集約は、部分が独立して存在できる「全体-部分」関係を表す。
に空洞のダイヤモンド全体側にマークされる。
例：
A チームは複数の選手があるが、選手はチーム外に存在できる。
組成
部分のライフサイクルが全体に依存する、より強い集約の形。
に実心のダイヤモンド.
例：
A 注文は含む注文行 項目があり、注文を削除するとそのすべての行が削除されます。
一般化（継承）
あるクラスが別のクラスを拡張していることを示します。
- 矢印は親クラスを指しています。
- 共有される属性やポリモーフィックな振る舞いに使用されます。
例：貯蓄口座 → 口座
依存関係
あるクラスが一時的に別のクラスを使用または依存していることを示します（例：パラメータ）。
通常、破線の矢印で示されます。
実装
クラスがインターフェースを実装するときに使用されます。
実践的なオブジェクト指向の例
以下の例は、クラス図の構文が実際の設計作業でどのように現れるかを示す、シンプルだが現実的なシナリオです。
例：電子商取引注文システム
クラス：
- 顧客
- 注文
- 注文項目
- 商品
主要な関係：
- 顧客 作成する 注文（関連）
- 注文 構成する 注文項目（合成）
- 注文項目 は次のものを指す 商品（関連）
この構造は明確に示している：
- 注文明細項目の所有権
- 注文された項目と商品データとの関係
- 取引プロセスにおける顧客の役割
例：図書館管理
クラス：
- 書籍
- コピー
- 会員
- 貸出
関係：
- 書籍 集約する コピー（コピーは書籍のメタデータとは独立して存在する）
- コピー 構成する 貸出（貸出はコピーが貸し出されることが前提で存在する）
- 会員 借りる 貸出（関連）
このモデルは、書籍の抽象的概念と物理的なコピーを分離している。
クラス図が重要な理由
クラス図はUMLの中心に残り続けるのは、あなたが次のことを助けるからである：
- コーディングの前にオブジェクト指向構造を明確にする
- 責任と境界を洗練する
- 欠落している概念や過度に複雑な設計を検出する
- 技術的アイデアを効果的に伝える
- ドキュメントを実装と一致させる
UMLを頻繁に使うか、たまに使うかに関わらず、クラス図の表記法を習得することは、より強固な設計を構築するのに役立ちます。
UMLおよびAIがその可視化をどのように支援するかの詳細な説明については、当社のUMLリソースハブ.