クラス図

ソフトウェア工学において、統一モデリング言語（UML）のクラス図^[1]は、システムのクラス、その属性、操作（またはメソッド）、およびオブジェクト間の関係を示すことによってシステムの構造を記述する静的構造図の一種です。

クラス図は、オブジェクト指向モデリングの主要な構成要素です。アプリケーション構造の一般的な概念モデリングや、モデルをプログラミングコードに変換する詳細なモデリングに使用されます。クラス図は、データモデリングにも使用できます。^[2]クラス図のクラスは、主要な要素、アプリケーション内の相互作用、およびプログラムされるクラスの両方を表します。

図では、クラスは 3 つのコンパートメントを含むボックスで表されます。

上部のコンパートメントにはクラス名が入っています。太字で中央揃えに印刷され、最初の文字は大文字です。
中央のコンパートメントにはクラスの属性が含まれます。属性は左揃えで、最初の文字は小文字です。
下部のコンパートメントには、クラスが実行できる操作が含まれています。これらも左揃えで、最初の文字は小文字です。

システムの設計では、多数のクラスが識別され、クラス図にグループ化され、クラス間の静的な関係を決定するのに役立ちます。詳細なモデリングでは、概念設計のクラスはサブクラスに分割されることがよくあります。^[3]

システムの動作をさらに記述するために、これらのクラス図は状態図またはUML状態マシンによって補完されることができる。^[4]

メンバー

UML は、属性やメソッドなどのクラスメンバーと、コンストラクターなどの追加情報を表すメカニズムを提供します。

可視性

クラスメンバー（つまり、任意の属性やメソッド）の可視性を指定するには、メンバー名の前に次の表記法を置く必要があります。^[5]

派生プロパティとは、他のプロパティの値を使用するなどして、他の情報から値が生成または計算されるプロパティです。

派生プロパティは、その名前の前にスラッシュ「/」が付きます。^[6]

範囲

UMLでは、メンバーのスコープとしてインスタンスとクラスの2種類が指定されています。クラス名は、インスタンス名（存在する場合）、コロン（':'）、実際のクラス名を下線付きで連結したものとして表示されます。^[1]

インスタンスメンバーのスコープは特定のインスタンスに限定されます。
- 属性値はインスタンスごとに異なる場合があります
- メソッドの呼び出しはインスタンスの状態に影響を与える可能性がある（つまり、インスタンスの属性を変更する）
クラスメンバーは、多くのプログラミング言語で一般的に「静的」として認識されます。スコープの終了はクラス自体です。
- 属性値はすべてのインスタンスで等しい
- メソッドの呼び出しは分類器の状態に影響を与えない

メンバーの分類子スコープを示すには、その名前に下線を付ける必要があります。そうでない場合は、デフォルトでインスタンススコープが想定されます。

人間関係

関係とは、クラス図やオブジェクト図にある特定の種類の論理接続を表す一般的な用語です。UML では次の関係が定義されています。

インスタンスレベルの関係

依存

依存関係は、依存モデル要素と独立モデル要素の間に意味的なつながりがあるタイプの関連付けです。^[7]依存関係は、1 つの要素 (サーバーまたはターゲット) の定義の変更が、もう 1 つの要素 (クライアントまたはソース) の変更を引き起こす可能性がある場合に、2 つの要素間に存在します。この関連付けは一方向です。依存関係は、クライアントからサプライヤーを指す開いた矢印が付いた破線として表示されます。

協会

2つのクラス間の関連のクラス図の例

関連は、構造的なリンクのファミリーを表します。バイナリ関連は、2 つのクラス間の実線として表されます。再帰関連は、クラスとそれ自体の間のバイナリ関連です。2 つ以上のクラス間の関連は、関連する各クラスに実線で接続されたダイヤモンドとして表されます。3 つのクラス間の関連は、3 項関連です。より多くのクラス間の関連は、n 項関連と呼ばれます。

関連には名前を付けることができ、関連の端にはロール名、集約インジケータ、多重度、可視性、ナビゲーション可能性、その他のプロパティを付加することができます。たとえばドット表記法では、一方のクラスの側に小さなドットを付けて、関連の端がもう一方の側によって所有されていることを表すことができます。^[8]

関連には、単純な関連、共有集約、複合集約 (コンポジション) の 3 つのタイプがあります。関連は、1 つ以上の方向にナビゲートできます。ナビゲート可能性を明示的に指定する必要はありません。クラスの横にある開いた矢印は、実行時に反対側から効率的にクラスに到達できることを示します。単方向のナビゲーションは、到達できないクラスの横にある関連線に小さな十字で示されます。たとえば、フライトクラスは、飛行機クラスと双方向に関連付けられています。

集約

2 つのクラス間の集約を示すクラス図。ここでは、教授が教えるクラスがあります。

集約は「～を持つ」という関連関係の変形です。集約は関連よりも具体的です。集約は、部分と全体、または一部の関係を表す関連です。画像に示されているように、教授は「～を持つ」クラスを教えます。集約は関連の一種であるため、名前を付けることができ、関連と同じ装飾を施すことができます。ただし、集約には 2 つ以上のクラスを含めることはできません。集約はバイナリ関連である必要があります。さらに、実装中に集約と関連の間に違いはほとんどなく、図では集約関係を完全に省略できます。^[9]

集約は、クラスが他のクラスのコレクションまたはコンテナーであるが、含まれているクラスがコンテナーに対して強いライフサイクル依存関係を持たない場合に発生する可能性があります。コンテナーが破棄されても、コンテナーの内容は引き続き存在します。

UMLでは、包含クラス上の中空の ダイヤモンド形としてグラフィカルに表現され、包含クラスと 1 本の線で結ばれます。集合体は、物理的には複数のより小さなオブジェクトで構成されていますが、意味的には多くの操作で単位として扱われる拡張オブジェクトです。

構成

複合集約 (口語ではコンポジションと呼ばれる) 関係は、集約が集約する要素のライフサイクルを制御する、より強力な集約形式です。グラフィカルな表現は、包含クラスを包含クラスに接続する線の包含クラスの端に ある塗りつぶされたダイヤモンド形です。

合成と集約の違い

構成関係: 1. 現実世界の全体と部分の関係を表現しようとする場合、たとえば、エンジンは車の一部です。; 2. コンテナが破壊されると、その内容物も破壊されます（例：大学とその学部）。

集約関係: 1. ソフトウェアやデータベースの関係を表す場合、例えば自動車モデルのエンジンENG01は自動車モデルCM01の一部であり、エンジンENG01も別の自動車モデルの一部である可能性がある。^[10]; 2. 容器が破壊されても、その中身は通常破壊されません。例えば、教授には学生がいますが、教授が大学を去っても、学生も教授と一緒に去ることはありません。

したがって、集約関係は、コンポジションの「物理的な」包含と区別するために、多くの場合「カタログ」包含になります。UML 2 では、単純な関連付けと比較して、集約のセマンティクスは指定されていません。

階級レベルの関係

一般化/継承

スーパークラス*Person*と 2 つのサブクラス*Student*および*Professor間の一般化を示すクラス図*

一般化関係 (継承または「is a」関係とも呼ばれる) は、一方のクラス (いわゆるサブクラス) がもう一方のクラス (スーパークラス、スーパータイプ、または基本クラス)の特殊化された形式であるという考えを表します。この関係が成り立つ場合、スーパークラスはサブクラスの一般化と見なされます。実際には、これはサブクラスのインスタンスがスーパークラスのインスタンスでもあることを意味します。この形式の一般化の典型的なツリーは、生物学的分類に見られます。たとえば、人間はサルのサブクラスであり、サルは哺乳類のサブクラスです。この関係は、「 AはBである」(人間は哺乳類であり、哺乳類は動物である) というフレーズで最も簡単に理解できます。

一般化の UML グラフィカル表現は、スーパークラスを 1 つ以上のサブタイプに接続する線 (または線のツリー) のスーパークラスの端にある中空の三角形です。

   実現の象徴（サブクラス）_______▻（スーパークラス）

一般化の双対は、特殊化関係です。より一般的なスーパークラスの（特殊化された）サブクラスを表すその他の用語には、サブタイプ、派生クラス、派生型、継承クラス、継承型、子、子クラスなどがあります。

この関係は、生物学的な親子関係に似ていますが、異なるものであることに注意してください。親と子という用語の使用は示唆的ですが、誤解を招く可能性があります。

AはBのタイプである

たとえば、「オークは木の一種です」、「自動車は乗り物の一種です」

一般化はクラス図とユースケース図でのみ表示できます。

実現/実装

UML モデリングでは、実現関係は 2 つのモデル要素間の関係であり、一方のモデル要素 (クライアント) がもう一方のモデル要素 (サプライヤー) が指定する動作を実現 (実装または実行) します。

実現の UML グラフィカル表現は、1 つ以上の実装者と接続する破線 (または線のツリー) のインターフェイスエンドにある中空の三角形です。破線をユーザーと接続するインターフェイスエンドには、単純な矢印が使用されます。コンポーネント図では、ボールとソケットのグラフィック規則が使用されます (実装者はボールまたはロリポップを公開し、ユーザーはソケットを表示します)。実現は、クラス図またはコンポーネント図にのみ表示できます。実現とは、クライアント要素とサプライヤ要素を接続する、クラス、インターフェイス、コンポーネント、およびパッケージ間の関係です。クラス/コンポーネントとインターフェイス間の実現関係は、クラス/コンポーネントがインターフェイスによって提供される操作を実現することを示します。

   実現の象徴（実装者）--------▻（インターフェース）

一般的な関係

依存

依存関係は、ある時点でクラスが別のクラスを使用しているため、そのクラスが別のクラスに依存していることを示す、より弱い形式の結合である場合があります。独立クラスが依存クラスのメソッドのパラメータ変数またはローカル変数である場合、1 つのクラスは別のクラスに依存します。2 つのクラスの関係が非常に弱い場合があります。メンバー変数でまったく実装されていない場合があります。むしろ、メンバー関数の引数として実装されている場合があります。

多様性

この関連関係は、関連する 2 つのクラスのうち少なくとも 1 つが他のクラスを参照していることを示します。この関係は通常、「A には B がある」(母猫には子猫がいて、子猫には母猫がいる) と説明されます。

関連の UML 表現は、2 つの関連クラスを接続する線です。線の各端には、オプションの表記があります。たとえば、矢印を使用して、先端が矢印の尾から見えることを示すことができます。ボールを配置することで所有権を示し、役割に名前を付けることでその端の要素が果たす役割を示し、そのエンティティのインスタンスの多重度(もう一方の端から見て、関連に参加するオブジェクトの数の範囲) を示すことができます。

分析ステレオタイプ

エンティティ

エンティティクラスは、システムによって処理される長期間有効な情報、および場合によってはその情報に関連付けられた動作をモデル化します。これらは、データベーステーブルやその他のデータストアとして識別されるべきではありません。

これらは、円の下部に短い線が付いた円として描画されます。または、クラス名の上に「エンティティ」ステレオタイプ表記が付いた通常のクラスとして描画することもできます。

参照

関連図

参考文献

^ ab "クラス"。統一モデリング言語 2.5.1。OMG文書番号 formal/2017-12-05。オブジェクト管理グループ標準化機構 (OMG SDO)。2017 年 12 月。p. 194 。
^ Sparks, Geoffrey. 「UML でのデータベースモデリング」。2011年9 月 8 日閲覧。
^ Flatt, Amelie; Langner, Arne; Leps, Olof (2022)、「フェーズ I: 法的概念を技術的オブジェクトにマッピングする」、Akoma Ntoso アプリケーションプロファイルのモデル駆動型開発、Cham: Springer International Publishing、pp. 13–17、doi :10.1007/978-3-031-14132-4_3、ISBN 978-3-031-14131-7、 2023-01-07取得
^ Scott W. Ambler (2009) UML 2 クラス図。Webdoc 2003-2009。2009 年 12 月 2 日にアクセス
^ UML リファレンスカード、バージョン 2.1.2、Holub Associates、2007 年 8 月、 2011 年3 月 12 日取得
^ 「UML 派生プロパティは、他のプロパティを使用するなどして、他の情報から値が生成または計算されるプロパティです」。www.uml-diagrams.org 。2019年 1 月 24 日閲覧。
^ Fowler (2003) UML Distilled: 標準オブジェクトモデリング言語の簡潔なガイド
^ Selic, Bran (2013-04-18). 「Getting it right on the dot」(PDF) . www.omg.org . Object Management Group . 2023-11-26に取得。
^ 「UML チュートリアルパート 1: クラス図」(PDF)。2007 年 1 月 3 日のオリジナル(PDF)からアーカイブ。2015年 7 月 18 日に取得。
^ Goodwin, David. 「モデリングとシミュレーション、p. 26」(PDF)。ウォーリック大学。 2015年11月28日閲覧。

外部リンク

UML 2 クラス図入門
UML 2 クラス図ガイドライン
IBM クラス図の概要

「クラス」。統一モデリング言語 2.5.1。OMG文書番号 formal/2017-12-05。オブジェクト管理グループ標準化機構 (OMG SDO)。2017 年 12 月。194ページ。

UML 2 クラス図

[OMG-1] "クラス"。統一モデリング言語 2.5.1。OMG文書番号 formal/2017-12-05。オブジェクト管理グループ標準化機構 (OMG SDO)。2017 年 12 月。p. 194 。

[2] Sparks, Geoffrey. 「UML でのデータベースモデリング」。2011年9 月 8 日閲覧。

[3] Flatt, Amelie; Langner, Arne; Leps, Olof (2022)、「フェーズ I: 法的概念を技術的オブジェクトにマッピングする」、Akoma Ntoso アプリケーションプロファイルのモデル駆動型開発、Cham: Springer International Publishing、pp. 13–17、doi :10.1007/978-3-031-14132-4_3、ISBN 978-3-031-14131-7、 2023-01-07取得

[SWA09-4] Scott W. Ambler (2009) UML 2 クラス図。Webdoc 2003-2009。2009 年 12 月 2 日にアクセス

[HOL07-5] UML リファレンスカード、バージョン 2.1.2、Holub Associates、2007 年 8 月、 2011 年3 月 12 日取得

[6] 「UML 派生プロパティは、他のプロパティを使用するなどして、他の情報から値が生成または計算されるプロパティです」。www.uml-diagrams.org 。2019年 1 月 24 日閲覧。

[7] Fowler (2003) UML Distilled: 標準オブジェクトモデリング言語の簡潔なガイド

[8] Selic, Bran (2013-04-18). 「Getting it right on the dot」(PDF) . www.omg.org . Object Management Group . 2023-11-26に取得。

[9] 「UML チュートリアルパート 1: クラス図」(PDF)。2007 年 1 月 3 日のオリジナル(PDF)からアーカイブ。2015年 7 月 18 日に取得。

[10] Goodwin, David. 「モデリングとシミュレーション、p. 26」(PDF)。ウォーリック大学。 2015年11月28日閲覧。