クラス図は次のタイプです。 UML (統一モデリング言語) システム内のクラスの構造と関係を視覚的に表現するためにソフトウェア エンジニアリングで使用される図。 UML は、ソフトウェア システムの設計と文書化に役立つ標準化されたモデリング言語です。これらはソフトウェア開発プロセスの不可欠な部分であり、設計段階と文書化段階の両方で役立ちます。

クラス図の重要なトピック

• クラス図とは何ですか?
• クラスとは何ですか?
• UML クラス表記法
• クラス間の関係
• クラス図の目的
• クラス図の利点
• クラス図の描き方
• クラス図の使用例

クラス図とは何ですか?

クラス図は、ソフトウェア エンジニアリングでシステム内のクラスの構造と関係を視覚的に表現するために使用される UML (統一モデリング言語) 図の一種です。つまり、オブジェクト指向システムを構築および視覚化するために使用されます。

これらの図では、クラスはボックスとして示されており、それぞれのボックスにはクラス名、属性、メソッドの 3 つのコンパートメントが含まれています。クラスを接続する線は関連付けを示し、1 対 1 または 1 対多などの関係を示します。

クラス図はシステム設計の高レベルの概要を提供し、ソフトウェアの構造の伝達と文書化に役立ちます。これらはオブジェクト指向設計の基本ツールであり、ソフトウェア開発ライフサイクルにおいて重要な役割を果たします。

クラスとは何ですか?

オブジェクト指向プログラミング (OOP) では、クラスはオブジェクトを作成するための設計図またはテンプレートです。オブジェクトはクラスのインスタンスであり、各クラスは、そのクラスから作成されたオブジェクトが持つ属性 (データ メンバー) とメソッド (関数またはプロシージャ) のセットを定義します。属性はオブジェクトの特性やプロパティを表し、メソッドはオブジェクトが実行できる動作やアクションを定義します。

UML クラス表記法

クラス表記は、オブジェクト指向モデリングでクラスとその関係を表すために使用されるグラフィカル表現です。

ラドヤード・キプリングの言葉を言い換えると

1. クラス名：
   • クラスの名前は通常、クラス ボックスの上部のコンパートメントに中央揃えで太字で書かれます。
2. 属性:
   • 属性はプロパティまたはフィールドとも呼ばれ、クラスのデータ メンバーを表します。これらはクラス ボックスの 2 番目のコンパートメントにリストされ、多くの場合、各属性の可視性 (パブリック、プライベートなど) とデータ型が含まれます。
3. 方法:
   • メソッドは関数または操作とも呼ばれ、クラスの動作または機能を表します。それらはクラス ボックスの 3 番目のコンパートメントにリストされ、各メソッドの可視性 (パブリック、プライベートなど)、戻り値の型、およびパラメーターが含まれます。
4. 可視性の表記:
   • 可視性の表記は、属性とメソッドのアクセス レベルを示します。一般的な可視性の表記には次のものがあります。
     • +>公開用（全クラスが閲覧可能）
     • ->プライベート用 (クラス内でのみ表示)
     • #>protected の場合 (サブクラスから参照可能)
     • ~>パッケージまたはデフォルトの可視性 (同じパッケージ内のクラスに可視)

パラメータの方向性

クラス図では、パラメーターの方向性は、メソッド パラメーターを介したクラス間の情報の流れの指示を指します。パラメーターが入力であるか、出力であるか、またはその両方であるかを指定するのに役立ちます。この情報は、メソッド呼び出し中にオブジェクト間でデータがどのように受け渡されるかを理解するために重要です。

クラス図で使用される主なパラメーターの方向性表記法は 3 つあります。

• (入力):
  • 入力パラメータは、メソッドの呼び出し中に呼び出し側オブジェクト (クライアント) から呼び出されるオブジェクト (サーバー) に渡されるパラメータです。
  • これは、受信側クラス (メソッドを所有するクラス) を指す矢印で表されます。
• 出力 (出力):
  • 出力パラメータは、メソッドの実行後に、呼び出されたオブジェクト (サーバー) から呼び出したオブジェクト (クライアント) に返されるパラメータです。
  • これは、受信側クラスから離れる方向を指す矢印で表されます。
• 入出力 (入力と出力):
  • InOut パラメータは入力と出力の両方として機能します。呼び出し側オブジェクトから呼び出されたオブジェクトへ、またはその逆に情報を伝達します。
  • これは、受信クラスに向かう方向と受信側クラスから遠ざかる方向を指す矢印で表されます。

クラス間の関係

クラス図では、クラス間の関係は、システム内でクラスがどのように接続または相互作用するかを記述します。オブジェクト指向モデリングにはいくつかのタイプの関係があり、それぞれが特定の目的を果たします。クラス図における一般的なタイプの関係を次に示します。

1.協会

アソシエーションは、2 つのクラス間の双方向の関係を表します。これは、あるクラスのインスタンスが別のクラスのインスタンスに接続されていることを示します。通常、関連付けはクラスを接続する実線として表され、オプションで矢印が関係の方向を示します。

例を使用して関連付けを理解しましょう。

ライブラリを管理するための簡単なシステムを考えてみましょう。このシステムには、次の 2 つの主要なエンティティがあります。Book>そしてLibrary>。それぞれLibrary>複数含まれていますBooks>、そしてそれぞれBook>特定のに属しますLibrary>。この間の関係は、Library>そしてBook>協会を表します。

Library クラスは、Book クラスの複数のインスタンスへの参照が含まれているため、ソース クラスとみなすことができます。 Book クラスは特定のライブラリに属しているため、ターゲット クラスとみなされます。

bash 環境変数が設定されているかどうかを確認する

2. 指示された関連付け

UML クラス図の有向関連付けは、関連付けに方向がある 2 つのクラス間の関係を表し、あるクラスが特定の方法で別のクラスに関連付けられていることを示します。

• 有向関連付けでは、関係の方向を示すために矢印が関連付け線に追加されます。矢印は、関連付けを開始するクラスから、関連付けの対象となるクラスまたは関連付けの影響を受けるクラスを指します。
• 有向関連付けは、どのクラスが関連付けの開始を担当しているか、どのクラスが他のクラスに依存しているかを示すなど、関連付けに特定のフローまたは方向性がある場合に使用されます。

大学システムで Teacher クラスが Course クラスに関連付けられているシナリオを考えてみましょう。有向関連付け矢印は、Teacher クラスから Course クラスを指し、教師が特定のコースに関連付けられているか、または特定のコースを教えていることを示します。

• ソース クラスは Teacher クラスです。 Teacher クラスは、特定のコースを教えることによって関連付けを開始します。
• 対象クラスは Course クラスです。 Course クラスは特定の教師によって教えられているため、関連付けの影響を受けます。

3. 集計

集約は、全体と部分の関係を表す特殊な形式の関連付けです。これは、あるクラス (全体) が別のクラス (部分) を含む、または別のクラス (部分) で構成される、より強い関係を示します。集合は、クラス全体の側面にあるひし形の形で表されます。この種の関係では、子クラスは親クラスから独立して存在できます。

例を使用して集計を理解しましょう。

会社は全体であると考えることができますが、従業員は部分であると考えられます。従業員は会社に所属しており、会社は複数の従業員を抱えることができます。しかし、会社が消滅しても従業員は独立して存続することができます。

4. 構成

構成は、より強力な形式の集約であり、より重要な所有権または依存関係を示します。合成では、部分クラスがクラス全体から独立して存在することはできません。構成は、クラス全体の側面の塗りつぶされたひし形で表されます。

例を使用して構成を理解しましょう:

デジタル連絡帳アプリケーションを想像してください。連絡帳は全体であり、各連絡先エントリは一部です。各連絡先エントリは連絡先帳によって完全に所有され、管理されます。連絡先帳が削除または破棄されると、関連付けられているすべての連絡先エントリも削除されます。

これは、連絡先エントリの存在が連絡帳の存在に完全に依存するため、構成を示しています。連絡帳がなければ、個々の連絡先エントリは意味を失い、単独で存在できなくなります。

5. 一般化(継承)

継承はクラス間の is-a 関係を表し、あるクラス (サブクラスまたは子) が別のクラス (スーパークラスまたは親) のプロパティと動作を継承します。継承は、サブクラスからスーパークラスを指す閉じた中空の矢印が付いた実線で表されます。

ステートメントの対象範囲

銀行口座の例では、一般化を使用して、当座預金口座、普通預金口座、クレジット口座などのさまざまな種類の口座を表すことができます。

Bank Account クラスは、すべてのタイプの銀行口座の一般化された表現として機能しますが、サブクラス (当座預金口座、普通預金口座、信用口座) は、基本クラスの機能を継承および拡張する特殊なバージョンを表します。

6. 実現（インターフェース実装）

実現とは、クラスがインターフェイスの機能を実装することを示します。インターフェースで定義された動作をクラスで実現する場合によく使われます。実現は、実装クラスからインターフェイスを指す白抜きの矢印が付いた破線で示されています。

個人と法人の両方が所有者インターフェイスを実現するシナリオを考えてみましょう。

• オーナーインターフェース: このインターフェイスには、プロパティの取得と破棄に関連するアクションを表すacquire(property)やdispose(property)などのメソッドが含まれるようになりました。
• 人物クラス (実現): Person クラスは Owner インターフェイスを実装し、acquire(property) メソッドと destroy(property) メソッドの具体的な実装を提供します。たとえば、ある人は家の所有権を取得したり、車を処分したりできます。
• 法人クラス (実現): 同様に、Corporation クラスも Owner インターフェイスを実装し、acquire(property) メソッドと destroy(property) メソッドの特定の実装を提供します。たとえば、企業は不動産の所有権を取得したり、社用車を処分したりできます。

Person クラスと Corporation クラスは両方とも Owner インターフェイスを実現します。つまり、インターフェイスで定義されているacquire(property) メソッドとdispose(property) メソッドの具体的な実装を提供します。

7. 依存関係

あるクラスが別のクラスに依存する場合、2 つのクラス間に依存関係が存在しますが、その関係は関連付けや継承ほど強力ではありません。これは、クラス間のより疎結合な接続を表します。依存関係は、多くの場合、破線の矢印で表されます。

データベース

人が本に依存するシナリオを考えてみましょう。

• 人物クラス: 本を読む個人を表します。 Person クラスは、コンテンツにアクセスして読み取るために Book クラスに依存します。
• 書籍クラス: 人が読む内容を含む本を表します。 Book クラスは独立しており、Person クラスがなくても存在できます。

内容を読み取るにはブックへのアクセスが必要であるため、Person クラスは Book クラスに依存します。ただし、Book クラスは Person クラスに依存しません。これは独立して存在することができ、その機能は Person クラスに依存しません。

8. 使用(依存)関係

UML クラス図の使用依存関係は、あるクラス (クライアント) が別のクラス (サプライヤー) を利用または依存して、特定のタスクを実行したり、特定の機能にアクセスしたりすることを示します。クライアント クラスはサプライヤー クラスが提供するサービスに依存しますが、そのインスタンスを所有したり作成したりしません。

• 使用依存関係は、特定のニーズまたは要件を満たすために、あるクラスが別のクラスに依存する依存関係の形式を表します。
• クライアント クラスは、サプライヤー クラスが提供する特定の機能またはサービスにアクセスする必要があります。
• UML クラス図では、使用依存関係は通常、クライアント クラスからサプライヤー クラスを指す破線の矢印で表されます。
• 矢印は依存関係の方向を示し、クライアント クラスがサプライヤー クラスによって提供されるサービスに依存していることを示しています。

Car クラスが燃料消費を管理するために FuelTank クラスに依存するシナリオを考えてみましょう。

• Car クラスは、燃料レベルの確認、燃料の補充、または燃料消費量の監視を行うために、FuelTank クラスのメソッドまたは属性にアクセスする必要がある場合があります。
• この場合、Car クラスはそのサービスを利用して燃料管理に関連する特定のタスクを実行するため、FuelTank クラスに対する使用依存関係があります。

クラス図の目的

クラス図を使用する主な目的は次のとおりです。

• これは、OOP の概念のさまざまな側面を適切に表現できる唯一の UML です。
• アプリケーションを適切に設計および分析すると、より迅速かつ効率的になります。
• これは、展開およびコンポーネント図のベースとなります。
• フォワードエンジニアリングとリバースエンジニアリングが組み込まれています。

クラス図の利点

• クラス構造のモデリング:
  • クラス図は、クラスとその属性、メソッド、および関係を表すことにより、システムの構造をモデル化するのに役立ちます。
  • これにより、システムのアーキテクチャが明確に整理されたビューが提供されます。
• 関係を理解する:
  • クラス図は、関連付け、集約、構成、継承、依存関係などのクラス間の関係を表します。
  • これは、開発者、設計者、ビジネス アナリストなどの関係者が、システムのさまざまなコンポーネントがどのように接続されているかを理解するのに役立ちます。
• コミュニケーション：
  • クラス図は、チーム メンバーと関係者間のコミュニケーション ツールとして機能します。これらは、技術者と非技術者の両方が簡単に理解できる、視覚的で標準化された表現を提供します。
• 実装の青写真:
  • クラス図は、ソフトウェア実装の青写真として機能します。これらは、クラス、その属性、メソッド、およびそれらの間の関係を説明することにより、開発者がコードを作成できるようにガイドします。
  • これは、設計と実際の実装の間の一貫性を確保するのに役立ちます。
• コード生成:
  • 一部のソフトウェア開発ツールおよびフレームワークは、クラス図からのコード生成をサポートしています。
  • 開発者は視覚的表現からコードの大部分を生成できるため、手動エラーの可能性が減り、開発時間が節約されます。
• 抽象化とカプセル化の識別:
  • クラス図は、抽象化の識別と、クラス内のデータと動作のカプセル化を促進します。
  • これは、モジュール性や情報隠蔽などのオブジェクト指向設計の原則をサポートします。

クラス図の描き方

クラス図を描くには、クラス、その属性、メソッド、関係を含むシステムの構造を視覚化することが含まれます。クラス図を描画する手順は次のとおりです。

1. クラスを特定する:
   • まず、システム内のクラスを特定することから始めます。クラスはオブジェクトの設計図を表し、関連する属性とメソッドをカプセル化する必要があります。
2. 属性とメソッドをリストします:
   • 各クラスについて、その属性 (プロパティ、フィールド) とメソッド (関数、操作) をリストします。データ型や可視性 (パブリック、プライベート、保護) などの情報を含めます。
3. 関係を特定する:
   • クラス間の関係を決定します。一般的な関係には、関連付け、集約、構成、継承、依存関係が含まれます。これらの関係の性質と多様性を理解してください。
4. クラスボックスを作成します。
   • 識別されたクラスごとに長方形 (クラス ボックス) を描画します。クラス名をボックスの上部のコンパートメントに配置します。ボックスを属性とメソッドのコンパートメントに分割します。
5. 属性とメソッドを追加します。
   • 各クラス ボックス内で、それぞれのコンパートメントの属性とメソッドをリストします。可視性表記を使用します (+ はパブリック、- はプライベート、# は保護、~ はパッケージ/デフォルト)。
6. 関係を描く:
   • 線を引いてクラス間の関係を表します。矢印を使用して、関連付けまたは依存関係の方向を示します。さまざまな関係にさまざまな線の種類や表記を使用できます。
7. ラベルの関係:
   • 必要に応じて、関係に多重度とロール名をラベル付けします。多重度は関係に関与するインスタンスの数を示し、ロール名は関係における各クラスの役割を明確にします。
8. レビューと絞り込み:
   • クラス図を見直して、システムの構造と関係が正確に表現されていることを確認します。フィードバックと要件に基づいて、必要に応じて図を調整します。
9. デジタル描画用のツールを使用します。
   • 紙にクラス図を描くこともできますが、デジタル ツールを使用すると、柔軟性が高まり、変更が容易になります。 UML モデリング ツール、描画ソフトウェア、さらには特殊な作図ツールも役立つ場合があります。

クラス図の使用例

• システムデザイン：
  • システム設計段階では、クラス図を使用してソフトウェア システムの静的構造をモデル化します。これらは、クラス、その属性、メソッド、関係の視覚化と整理に役立ち、システム実装の青写真を提供します。
• コミュニケーションとコラボレーション:
  • クラス図は、開発者、デザイナー、プロジェクト マネージャー、クライアントなどの関係者間の視覚的なコミュニケーション ツールとして機能します。これらはシステムの構造と設計についてのディスカッションを促進し、チームメンバー間の共通理解を促進します。
• コード生成:
  • 一部のソフトウェア開発環境およびツールは、クラス図に基づくコード生成をサポートしています。開発者はコードのスケルトンを生成できるため、手動によるコーディング作業が軽減され、設計と実装の一貫性が確保されます。
• テストとテスト計画:
  • テスターはクラス図を使用してクラス間の関係を理解し​​、それに応じてテスト ケースを計画します。クラス構造を視覚的に表現すると、徹底的なテストが必要な領域を特定するのに役立ちます。
• リバースエンジニアリング：
  • クラス図は、開発者が既存のコードを分析してソフトウェア構造の視覚的表現を作成するリバース エンジニアリングに使用できます。これは、ドキュメントが不足している場合や古い場合に特に役立ちます。