統一モデリング言語UML（統一モデリング言語）とは

UML

UML (統一モデリング言語) は、ソフトウェアシステムの構造、動作、および相互作用を記述するための汎用モデリング言語です。開発者、設計者、関係者間のコミュニケーションと理解を促進する視覚的なグラフィカルモデルを作成するための一連の表記法とルールを提供します。

起源と歴史

UML は 1990 年代初頭に誕生し、James Rumbaugh、Grady Booch、Ivar Jacobson などの著名なソフトウェアエンジニアと協力して開発されました。
この 3 人のエンジニアはそれぞれ独自のモデリング手法 (Rumbaugh の OOA、Booch の OOD、Jacobson の OOSE) を持っていましたが、これらの手法を統合して共通のモデリング言語を提供するために、力を合わせて UML を開発しました。

UML を使用する理由

統一された標準を提供する: UML は統一された標準化されたモデリング言語を提供するため、さまざまなチームや担当者が同じシンボルや表現を使用して通信および交換できます。
視覚的表現: UML は、グラフィックシンボルと図を使用してシステムの構造と動作を表現するため、複雑な概念と関係を直感的な方法で表示でき、理解しやすさが向上します。
学習と使用が簡単: UML のシンボルとルールは比較的単純で、多数のチュートリアルとツールのサポートがあるため、UML の学習と使用は比較的簡単です。
システム設計と分析のサポート: UML は、システム設計、分析、実装のさまざまな段階をサポートする豊富なモデリングツールとテクノロジを提供し、開発者がシステムをよりよく理解して計画できるようにします。
チームのコラボレーションの向上: UML を使用することで、チームメンバーはシステムの理解と設計を共有および伝達し、チーム間のコラボレーションとコミュニケーションを促進し、誤解や間違いを減らすことができます。

UML の利点

統一および標準化されたモデリング言語
複雑な概念と関係を視覚的に表現する
学びやすく使いやすい
システム設計と分析のあらゆる段階をサポート
チームワークとコミュニケーションを向上させる

全体として、UML は汎用モデリング言語として、ソフトウェア開発のための標準化されたシンボルと表現を提供し、開発者がソフトウェアシステムをより深く理解し、設計、実装するのに役立ち、ソフトウェア開発プロセスの効率と品質を向上させます。

クラス図の目的

UML クラス図には次の主な目的があります。

システム内の分類子の静的構造を示します。
基本的な表記法と、UML で指定されているその他の構造図の表記法を提供します。
開発者とチームメンバーにとって役立ちます。
ビジネスアナリストは、クラス図を使用して、ビジネスの観点からシステムをモデル化できます。

UML クラス図のコンポーネント

UML クラス図は次の 2 つの部分で構成されます。

クラスのセット (クラス)
クラス間の関係

クラスとは

クラスは、システム内で同様の役割を持つオブジェクトのグループの説明です。次のものが含まれます。

構造的特徴（属性）

構造的特性は、クラスのオブジェクトがどのようなものを「知っている」かを定義します。次のものが含まれます。

クラスオブジェクトの状態を表します
クラスの構造的または静的な特性を説明します。

行動特性（動作）

行動特性は、クラスのオブジェクトが「できること」を定義します。次のようなものがあります。

オブジェクト間の可能な相互作用を定義します
クラスの動作または動的特性を説明する

クラス表記

クラス表現は次の 3 つの部分で構成されます。

クラス名

クラス名は最初の部門に表示されます。

クラス属性¶

プロパティは 2 番目のセクションに表示されます。
属性のタイプはコロンの後に表示されます。
プロパティは、コード内のメンバー変数 (データメンバー) に対応します。

クラス操作 (メソッド)

操作は 3 番目のパーティションに示されており、クラスによって提供されるサービスです。
メソッドの戻り値の型は、メソッドシグネチャの最後のコロンの後に示されます。
メソッドパラメーターの戻り値の型は、パラメーター名の後のコロンの後に示されます。
アクションは、コード内のクラスメソッドに対応します。

クラス関係

クラス間の関係

クラスは、他のクラスと 1 つ以上の関係を持つことができます。関係は次のいずれかのタイプになります (関係を表す右側の図を参照してください)。

関係タイプ

関係の種類

グラフ表示

図解説明

継承 (または一般化):

「is-a」関係を示します。
抽象クラス名は斜体で表示されます。
SubClass1 と SubClass2 はスーパークラスの特殊化です。
子クラスから親クラスを指す実線の矢印。

単純な関連付け:

2 つのピアクラス間の構造的リンク。
Class1 と Class2 の間には関連があります。
2 つのクラスを結ぶ実線。

集計:

重合：

特殊な種類の関連付け。「部分と全体」の関係を表します。
クラス 2 はクラス 1 の一部です。
Class1 は Class2 の複数のインスタンスに関連付けることができます (* で示されます)。
Class1 と Class2 のライフサイクルは独立しています。
複合クラスの関連エンドポイントに接続された、塗りつぶされていないひし形の実線。

構成：

組み合わせ：

全体が破壊されると部分も破壊されるという特殊な集合関係。
Class2 のライフサイクルは Class1 と接続されています。
Class2 は独立して存在できません。
複合クラスの関連エンドポイントに接続された黒菱形の実線。

依存：

頼る：
ここに画像の説明を挿入

あるクラスの定義を変更すると、別のクラスも変更される可能性がある場合 (その逆はありません)、依存関係が存在します。
クラス 1 はクラス 2 に依存します。
点線と白抜き矢印の線。

ナビゲーション性

矢印は、インスタンスが関係しているときに、インスタンスが関連付けられている別のクラスのインスタンスを決定できるかどうかを示します。

上の図は次のことを示しています。

スプレッドシートがあれば、そこに含まれるすべてのセルを見つけることができますが、
セルからどのスプレッドシートに属しているかを判断することはできません。つまり、セルからスプレッドシートに移動できないため、セルの移動可能性は問題外です。
セルを指定すると、関連付けられた式と値を取得できますが、
- 値 (または式) が与えられた場合、これらのプロパティが属するセルを見つけることができません。つまり、値または式からセルに移動できないため、値または式の移動可能性は問題外です。

つまり、ナビゲーション可能性とは、インスタンスを使用して、関係内でそのインスタンスに関連する他のインスタンスに移動できるかどうかを指します。矢印の有無に基づいて、航行可能性を判断できます。

クラス属性と操作の可視性

クラスの属性と操作の可視性

オブジェクト指向設計では、プロパティと操作の可視性を表す表記法があります。UML は、パブリック (パブリック)、プロテクト (保護)、プライベート (プライベート)、およびパッケージ (パッケージ) の 4 つの可視性タイプを認識します。

属性と操作の可視性は、クラス内の属性名と操作名の前に +、-、#、および ~ 記号を使用して示されます。

+は公開プロパティまたは操作を示します
-プライベートな属性または操作を示します
#保護された属性または操作を示します
~パッケージ内のプロパティまたは操作を示します

参考：https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-class-diagram/

学習目的のみに使用し、営利目的やその他の違法な目的で使用しないでください。

統一モデリング言語 (UML) とは UML と UML クラス図の基本概念