統一モデリング言語（UML）の概要

Table of Contents hide

統一モデリング言語（UML）は、あらゆる目的に使用できるモデリング言語です。UMLの主な目標は、システムの設計を視覚化するための標準を確立することです。他のエンジニアリング部門の設計とよく似ています。

UMLは、プログラミング言語ではなく視覚言語です。UMLダイアグラムは、システムの動作と構造を表すために使用されます。UMLは、ソフトウェアエンジニア、ビジネスマン、およびシステムアーキテクト向けのモデリング、設計、および分析ツールです。統一モデリング言語は、1997年にObject Management Group（OMG）によって標準として承認されました。それ以来、OMGがそれを担当しています。2005年、国際標準化機構（ISO）はUMLを標準として受け入れました。UMLは常に更新されており、定期的に検査されます。

UMLとは何ですか？

統一モデリング言語（UML）は、大規模なソフトウェアシステムの構造と動作のアーキテクチャ、設計、および実装のための共通のビジュアルモデリング言語を確立するために開発されました。UMLには、産業プロセスなど、ソフトウェア開発以外のアプリケーションがあります。

これは多くの種類の図で構成されており、他のドメインで使用されている青写真に似ています。一般に、UMLダイアグラムは、システムの境界、構造、動作、およびシステム内に含まれるオブジェクトを示します。

UMLはプログラミング言語ではありませんが、UML図を使用して複数の言語でコードを生成するツールが存在します。

UMLの歴史

UMLは、ソフトウェア開発とドキュメントを取り巻く障害から生じました。1990年代を通じて、ソフトウェアシステムを表現および文書化するためのさまざまな手法がありました。その結果、1994年から1996年に3人のRationalSoftwareソフトウェア開発者がUMLを作成しました。その後、1997年に標準として認識され、それ以来、非常に小さな改訂が加えられたままです。

UMLは本当に必要ですか？

複雑なアプリケーションでは、さまざまなチームのコラボレーションと計画が必要であり、チーム間の明確で直接的なコミュニケーション手段が必要です。
コードはビジネスマンには理解されていません。その結果、UMLは、プログラマー以外の人がシステムの基本的な要件、機能、および操作を理解するために不可欠になります。
チームがプロセス、ユーザーインタラクション、およびシステムの静的構造を視覚化できる場合、チームは多くの時間を節約できます。

オブジェクト指向の設計と分析はUMLにリンクされています。ダイアグラムを作成するために、UMLはアイテムを取得し、それらの間に関連付けを作成します。以下は、UML図の例です。

構造図は、システムの静的特性または構造を示しています。構造図を示します。コンポーネント図、オブジェクト図、クラス図、および配置図はすべて、ソフトウェア開発で使用される図の例です。
動作図は、システムの動的な機能または動作を示しています。動作図が含まれています。ユースケース図、状態図、アクティビティ図、および相互作用図を使用して、アイデアを視覚化するのに役立ててください。

UMLによる概略階層を次の図に示します。

UMLの主要なオブジェクト指向の概念

オブジェクト指向（OO）の分析と設計は、UMLに取って代わられました。

オブジェクトは、それを制御するデータとメソッドで構成されています。データは、オブジェクトの現在のステータスを表します。クラスは、実際のシステムを模倣するために使用できる階層を持つオブジェクトのタイプです。階層は継承によって表現され、クラスはニーズに応じてさまざまな方法でリンクできます。

オブジェクトは私たちの周りに存在する現実世界のエンティティであり、UMLは抽象化、カプセル化、継承、ポリモーフィズムなどの基本原則を表す場合があります。

UMLは、オブジェクト指向の分析と設計に見られるすべての概念を表すことができます。

UMLダイアグラムでは、オブジェクト指向の概念のみが表されます。そのため、UMLを学習する前に、オブジェクト指向の概念を完全に理解することが重要です。

クラス：クラスは、ブループリント、つまりオブジェクトの構造と機能を定義し、UMLで使用されます。
オブジェクト：オブジェクトは、複雑なシステムの分解とモジュール化を支援します。モジュール性により、システムをわかりやすいコンポーネントに分解し、1つずつ作成することができます。システムの基本単位（ビルディングブロック）はオブジェクトであり、エンティティを記述するために使用されます。
継承：子クラスがその親クラスのプロパティを継承できるようにするメカニズム。
抽象化：実装の詳細からユーザーを保護する方法。
カプセル化：データをまとめて外界から保護するプロセス。
ポリモーフィズム：関数またはエンティティが複数のバージョンに存在できるようにする方法。

UMLでの追加：

元のUML定義の範囲が拡大され、アジャイルなどのソフトウェア開発アプローチが追加されました。
当初、UMLは9つの図を要求しました。UML 2.xの図の数は、9から13に増えました。タイミング図、通信図、相互作用の概要図、および複合構造図は、4つの新しい図です。状態図は、UML2.xでステートマシン図に名前が変更されました。
ソフトウェアシステムは、UML2.xを使用してコンポーネントとサブコンポーネントに分解できるようになりました。

UML構造図

クラス図–クラス図は、最も広く使用されているUML図です。これは、すべてのオブジェクト指向ソフトウェアシステムの基盤として機能します。クラス図は、クラス、メソッド、およびプロパティを表示することにより、システムの静的構造を表すために使用されます。クラス図は、さまざまなクラスまたはオブジェクト間のリンクを決定するのにも役立ちます。

複合構造図–複合構造図は、クラスの内部構造と、システムの他のコンポーネントとの相互作用のポイントを示すために使用されます。ピースとその構成の間のリンクによって、分類子（クラス、コンポーネント、またはデプロイメントノード）の動作が決まります。パーツ、ポート、および接続は、構造化された分類子の内部構造を説明するために使用されます。複合構造図を使用して、協力をモデル化することもできます。これらはクラス図に似ていますが、クラス全体を表す代わりに、特定の要素を詳細に表示します。

オブジェクト図–オブジェクトグラフは、システム内のインスタンスとそれらの間に存在する関係のスクリーンショットとして参照できます。オブジェクト図は、インスタンス化された後のオブジェクトの動作を表すため、特定の時点でのシステムの動作を調べることができます。オブジェクト図は、システム内のクラスのインスタンスを表示することを除いて、クラス図に似ています。クラス図を使用して、実際の分類子とそれらの関係を説明します。一方、オブジェクトグラフは、クラスの特定のインスタンスと、ある時点でのそれらの間の関係を表します。

コンポーネント図–コンポーネント図は、システムの物理コンポーネントがどのように接続されているかを示すために使用されます。これらは、実装の詳細をシミュレートするために使用されます。コンポーネント図は、ソフトウェアシステムの各部分間の構造的な関係を示しており、計画された開発がすべての機能要件を満たしているかどうかを判断するのに役立ちます。複雑なシステムを設計および構築する場合、コンポーネント図が不可欠です。システムの多くのコンポーネントは、インターフェースを介して相互に通信します。

配置図–配置図は、システムのハードウェアとソフトウェアを示す図です。そこにあるハードウェアコンポーネントと、それらで実行されているソフトウェアコンポーネントを通知します。システムソフトウェアによって生成された情報は、アーティファクトと呼ばれます。これらは、ソフトウェアがさまざまな構成の多数のデバイスで使用、配布、または展開されるときに最も一般的に使用されます。

パッケージ図–パッケージ図は、パッケージとそのコンポーネントがどのように配置されているかを示すために使用されます。パッケージ図は、個別のパッケージの相互依存性とパッケージの内部構造を単純に示しています。パッケージは、UML図を意味のあるグループに編成し、図を理解するのに役立ちます。これらは主に、クラス図とユースケース図を整理するために使用されます。

UML動作図

ステートマシン図–特定の時点でのシステムまたはシステムのセクションのステータスを表すために使用されます。これは、動作が有限数の状態遷移によって表される動作図です。ステートマシンとステートダイアグラムは、ステートダイアグラムの別名です。これらの用語は頻繁に交換されます。簡単に説明すると、状態図は、時間と外部入力の変化に応じたクラスの動的な動作を視覚的に表したものです。

アクティビティ図–アクティビティ図を使用して、システムの制御フローがどのように機能するかを示します。アクティビティ図を使用して、ユースケースの実行に関連する段階を参照することもできます。アクティビティ図は、順次および同時のアクティビティを表すために使用されます。その結果、アクティビティ図を使用してワークフローを視覚的に表現します。フローの状況とそれらが発生する順序は、アクティビティ図の焦点です。アクティビティ図は、特定のイベントにつながるイベントを表現または説明するために使用されます。

ユースケース図は、システムまたはシステムのコンポーネントの機能を説明するために使用されます。これらは、システムの機能要件と外部エージェント（アクター）との相互作用を表すために頻繁に使用されます。ユースケースは、システムを適用できるさまざまなコンテキストを示す図です。ユースケース図は、実装の要点に飛び込むことなく、システムまたはシステムの要素が実行する内容の概要を示します。

シーケンス図は、一連のアイテム間の相互作用、つまりこれらの相互作用が発生する順序を単純に示しています。シーケンス図は、イベント図またはイベントシナリオと呼ばれることもあります。シーケンス図は、システムのコンポーネントがどのように、どのような順序で連携するかを示しています。ビジネスマンやソフトウェアエンジニアは、これらの図を頻繁に使用して、新しいシステムと現在のシステムのニーズを文書化して理解します。

通信図 （UML 1.xではコラボレーション図とも呼ばれます）は、オブジェクト間の情報の順次送信を表すために使用されます。オブジェクトとそれらの関係は、コミュニケーション図の焦点です。シーケンス図を使用して同様の情報を記述することができますが、通信図は自然な状態のオブジェクトとリンクを表します。

タイミング図 –タイミング図は、設定された期間におけるオブジェクトの動作を表すシーケンス図の一種です。これらは、オブジェクトの状態と動作の変化を制御する時間と期間の制約を表すために使用されます。

相互作用の概要図–相互作用の概要図は、複雑な相互作用をより単純なイベントに分解するために使用できる一連のイベントのモデルです。これは、アクティビティとシーケンス図のクロスです。

UML用語集

抽象クラス –インスタンス化されることのないクラス。このクラスのインスタンスは存在しません。
アクター –システムが関与するイベントを開始するオブジェクトまたは人。
アクティビティ：アクティビティ図内のステップまたはアクション。システムまたはアクターによって実行されるアクションを表します。
アクティビティ図：アルゴリズムやビジネスプロセスなどのプロセス内のステップと決定、および並列操作を示す、見栄えのするフローチャート。
集約 –別のクラスの一部です。図の包含クラスの横にある中空のひし形で示されています。
アーティファクト –設計プロセスのステップの出力を説明するドキュメント。説明は、グラフィック、テキスト、またはいくつかの組み合わせです。
アソシエーション –モデルの2つの要素間の接続。これは、コード内のメンバー変数、または人事レコードとそれが表す人との間の関連付け、または2つのカテゴリーのワーカー間の関係、または同様の関係を表す場合があります。デフォルトでは、アソシエーションの両方の要素は等しく、アソシエーションを通じて相互に認識しています。アソシエーションは、ナビゲート可能なアソシエーションにすることもできます。つまり、アソシエーションのソースエンドはターゲットエンドを認識しますが、その逆はできません。
アソシエーションクラス：他の2つのクラス間のアソシエーションを表し、情報を追加するクラス。
属性 –他のオブジェクトを参照したり、オブジェクトの状態情報を保存したりするために使用できるオブジェクトの特性。
基本クラス：一般化関係を介してサブクラスによって継承される属性と操作を定義するクラス。
ブランチ：アクティビティ図の決定ポイント。複数のトランジションがブランチから出現し、それぞれにガード条件があります。コントロールがブランチに到達すると、1つのガード条件が真である必要があります。制御は対応する遷移に従います。
クラス：類似したオブジェクトのカテゴリ。すべて同じ属性と操作で記述され、すべて割り当て互換です。
クラス図 –システムクラスとそれらの間の関係を示します。
分類子：属性と操作を持つUML要素。具体的には、アクター、クラス、およびインターフェース。
コラボレーション：通信図内の2つのオブジェクト間の関係。これは、メッセージがオブジェクト間を行き来できることを示します。
コミュニケーション図 –オブジェクトの役割を強調しながら操作がどのように行われるかを示す図。
コンポーネント：システム内のデプロイ可能なコード単位。
コンポーネント図：さまざまなコンポーネントとインターフェイス間の関係を示す図。
概念 –ドメインモデルに含まれる名詞または抽象的なアイデア。
構築フェーズ –機能のいくつかの反復が構築中のシステムに組み込まれるRational UnifiedProcessの第3フェーズ。ここで主な作業が行われます。
依存関係：1つの分類子が別の分類子の属性と操作を知っているが、2番目の分類子のインスタンスに直接接続されていないことを示す関係。
配置図：さまざまなプロセッサ間の関係を示す図。
ドメイン -システムが関与している宇宙の部分。
精緻化フェーズ –建設フェーズの反復を含む追加のプロジェクト計画を可能にするRational UnifiedProcessの第2フェーズ。
要素：モデルに表示されるすべてのアイテム。
カプセル化 –オブジェクトのデータはプライベートです。
一般化 –あるクラスが別のクラス（スーパークラス）のサブクラスであることを示します。中空の矢印はスーパークラスを指しています。
イベント：状態図では、これは、システムにアクションを実行させたり、状態を切り替えたりする信号、イベント、または入力を表します。
最終状態：状態図またはアクティビティ図では、これは図が完成するポイントを示します。
フォーク：複数の並列制御スレッドが開始するアクティビティ図のポイント。
一般化：継承関係。サブクラスは、基本クラスの属性と操作を継承して追加します。
GoF –4 セットのデザインパターンのギャング。
高凝集度 –クラスが複雑すぎず、無関係な機能を実行していることを確認するGRASP評価パターン。
低結合 – 1つのクラスが別のクラスに依存している、または別のクラスに接続されている量を測定するGRASP評価パターン。
開始フェーズ –元の概念化とプロジェクトの開始を処理するRational UnifiedProcessの最初のフェーズ。
継承 –サブクラスは、親（スーパークラス）クラスの属性または特性を継承します。これらの属性は、サブクラスでオーバーライドできます。
初期状態：状態図またはアクティビティ図では、これは図が始まるポイントを示します。
インスタンス –クラスは、オブジェクトを作成するためのテンプレートのように使用されます。このオブジェクトは、クラスのインスタンスと呼ばれます。クラスのインスタンスはいくつでも作成できます。
インターフェイス：動作のコントラクトを形成する属性と操作を定義する分類子。プロバイダーのクラスまたはコンポーネントは、インターフェースの実現（つまり、その属性と操作の実装）を選択できます。クライアントのクラスまたはコンポーネントは、インターフェイスに依存する可能性があるため、プロバイダーの実際のクラスの詳細なしでプロバイダーを使用できます。
イテレーション –プロジェクトにいくつかの小さな機能が追加されるミニプロジェクトセクション。分析、設計、コーディングの開発ループが含まれています。
参加：複数の並列制御スレッドが同期して再参加するアクティビティ図のポイント。
メンバー：分類子内の属性または操作。
マージ：さまざまな制御パスが一緒になるアクティビティ図のポイント。
メッセージ –メッセージを受信するオブジェクトに何かをするように求める1つのオブジェクトから別のオブジェクトへの要求。これは基本的に、受信オブジェクトのメソッドの呼び出しです。
メソッド –オブジェクト内の関数またはプロシージャ。
モデル –中心的なUMLアーティファクト。パッケージによって階層に配置されたさまざまな要素で構成され、要素間の関係も含まれます。
多重度 –ドメインモデルに表示され、概念ボックスの外側に表示されます。これは、他のオブジェクトの分位数に対するオブジェクトの数量の関係を示します。
ナビゲーション可能性：関係のどちらの端がもう一方の端を認識しているかを示します。関係には、双方向のナビゲーション可能性（両端が他方を認識している）または単一方向のナビゲーション可能性（一方の端が他方を認識しているが、その逆は認識していない）があります。
表記法 –分析および設計方法を作成するためのルールを含むグラフィカルドキュメント。
注：図をより詳細に説明するために図に追加されたテキストメモ。
オブジェクト –オブジェクト：アクティビティ図で、アクティビティから情報を受け取ったり、アクティビティに情報を提供したりするオブジェクト。コラボレーション図またはシーケンス図で、図に示されているシナリオに参加しているオブジェクト。一般的に：特定の分類子（アクター、クラス、またはインターフェース）の1つのインスタンスまたは例。
パッケージ –論理的にグループ化する必要があるUML要素のグループ。
パッケージ図：すべての要素がパッケージと依存関係であるクラス図。
パターン –相互作用するオブジェクトの責任割り当てを決定するために使用されるソリューション。これは、よく知られている一般的な問題の解決策を成功させるための名前です。
パラメータ：操作への引数。
ポリモーフィズム –同じメッセージ、異なる方法。パターンとしても使用されます。
プライベート：属性または操作に適用される可視性レベル。メンバーを含む分類子のコードのみがメンバーにアクセスできることを示します。
プロセッサ：配置図では、これはコードが展開される可能性のあるコンピュータまたはその他のプログラム可能なデバイスを表します。
保護：属性または操作に適用される可視性レベル。メンバーを含む分類子またはそのサブクラスのコードのみがメンバーにアクセスできることを示します。
パブリック：属性または操作に適用される可視性レベル。すべてのコードがメンバーにアクセスできることを示します。
読み取り方向矢印 –ドメインモデルの関係の方向を示します。
実現：コンポーネントまたはクラスが特定のインターフェースを提供することを示します。
ロール –ドメインモデルで使用され、アクターのロールに関するオプションの説明です。
シーケンス図：時間の経過に伴うオブジェクトの存在と、何らかの動作を実行するために時間の経過とともにそれらのオブジェクト間を通過するメッセージを示す図。状態チャート図–考えられるすべてのオブジェクトの状態を示す図。
状態：状態図では、これはシステムまたはサブシステムの1つの状態、つまり、ある時点で何をしているか、およびそのデータの値を表します。
状態図：システムまたはサブシステムの状態、状態間の遷移、および遷移を引き起こすイベントを示す図。
静的：分類子のすべてのインスタンス間で共有される属性のコピーが1つだけであることを示す属性の修飾子。オペレーションの修飾子。オペレーションが独立していて、分類子の特定のインスタンスで動作しないことを示します。
ステレオタイプ：モデル要素に適用される修飾子で、通常はUMLで表現できないものを示します。本質的に、ステレオタイプを使用すると、UMLの独自の「方言」を定義できます。
サブクラス：一般化関係を介してサブクラスによって定義された属性と操作を継承するクラス。
スイムレーン：システムまたはドメインのどの部分が特定のアクティビティを実行するかを示すアクティビティ図の要素。スイムレーン内のすべてのアクティビティは、スイムレーンによって表されるオブジェクト、コンポーネント、またはアクターの責任です。
タイムボックス –各反復には、特定の目標を持つ時間制限があります。
遷移：アクティビティ図で、あるアクティビティまたはブランチ、マージ、フォーク、または別のアクティビティへの制御のフローを表します。状態図では、ある状態から別の状態への変化を表します。
移行フェーズ –ユーザーが新しいシステムの使用についてトレーニングを受け、システムがユーザーに提供される、Rational UnifiedProcessの最後のフェーズ。
UML –統一モデリング言語は、テキストとグラフィックドキュメントを利用して、オブジェクト間のより緊密な関係を可能にすることにより、ソフトウェアプロジェクトの分析と設計を強化します。
ユースケース：ユースケース図では、アクターからの要求に応じてシステムが実行するアクションを表します。
ユースケース図：アクターとユースケースの関係を示す図。
可視性：どのコードがメンバーにアクセスできるかを示す属性または操作の修飾子。可視性レベルには、パブリック、保護、およびプライベートが含まれます。
ワークフロー –特定の結果を生み出す一連のアクティビティ。