UML クラス図

クラス

クラス名
+ メンバー名: 型 ~ メンバー名: 型 - メンバー名: 型 # メンバー名: 型
+ メソッド名(引数: 型): 型 ~ メソッド名(引数: 型): 型 - メソッド名(引数: 型): 型 # メソッド名(引数: 型): 型

スコープは +: public; ~: package; -: private; #: protected

スタティック変数／メソッドを示す場合はアンダーラインで修飾する。

インスタンス同士の関係

Dependency（依存）

independent <- - - - - - - - - - dependent

どちらが「依存する側（dependent / client）」で、どちらが「依存される側（independent / server）」なのかを表す。依存する側から依存される側に向かう破線矢印。

Association（関連）

label
independent <------------------- dependent
    1                 1,*

実線で結ばれ、関係名を付す場合には、線の中央の上にテキストを記す。また、多重度（multiplicity）を表す場合には、各ノードの付け根に m..n といった形式で範囲を示す。

さらに、関連性に方向性がある場合には、双方向（bi-directional）か片方向（uni-directional）かによって、矢印で示すことができる。また、自分で自分を参照するような反射的（reflexive）な関連の記述も可能である。

Aggregation（集約）

bag ◇------------------- item

集約は関連の中でも特殊なケースで、has-a で表される全体←部分の関係のこと。ただし、合体（Composition）と違って、部分側は全体のライフサイクルに依存せず、独立して存在する。ショッピングバッグに入った色々な野菜のようなもの。

白抜きの菱形で集約先を示す。

Composition（合体）

puzzle ◆------------------- piece

合体も関連の中でも特殊なケースで、has-a で表される全体←部分の関係のこと。ただし、集約（Aggregation）と違って、部分側は全体のライフサイクルに依存し、独立して存在しない。ジグソーパズルのピースのようなもの。

塗り潰した菱形で合体先を示す。

Aggregation vs Composition

例えば（オブジェクトではなく手続き的な例え方なので、理想的な例えではないかもしれないが）、ある一つのルーチンを、メインルーチンとサブルーチンに分けて、おおまかな流れと、各部分の細かい長れに、記述を分離するとする。そういう場合には、Composition になると言えようか。

一方、同じようにサブルーチンを分離する場合でも、下のメインルーチンだけではなく、一般的な関数として使い回すために、public なメソッドとして定義するような場合は、Aggregation になると言えるかもしれない。

もちろん、この例では、スコープの話と混ざっている面があるので、あまり適切ではないかもしれないが、コーディングの流れの中でどちらに持っていくかという観点で例えてみた一例に過ぎない。

クラス同士の関係

Generalization/Inheritance（一般化／継承）

super class ◅------------------- sub class

スーパークラスとサブクラスの関係（is-a）を示す。

白抜きの三角矢印と実線で一般化先（上位クラス）を示す。クラス同士を垂直に並べた方がより感じが出るかもしれない。

Realization/Implementation（実現化／実装）

interface ◅- - - - - - - - - - user

インターフェースと実装側の関係（implements）を示す。

白抜きの三角矢印と破線で実装対象（インターフェース）を示す。クラス同士を垂直に並べた方がより感じが出るかもしれない。