14種類のUML図の包括的なガイド - サイバーメディアン

Table of Contents hide

1 質問：UMLは巨大で複雑ですか？

2 回答：最も重要なUML図と表記法を学ぶ

3.15 無料のオンラインソフトウェア設計ツールをお探しですか？

統一モデリング言語は、標準化された汎用モデリング言語であり、現在、 Object Management Group（OMG）によって事実上の業界標準として管理されています。UMLには、ソフトウェアを多用するシステムのビジュアルモデルを作成するための一連のグラフィック表記技術が含まれています。

UML 2.2には、14種類のUMLダイアグラムがあり、2つのカテゴリに分類されます。

7種類の図は構造情報を表します
別の7つは、相互作用のさまざまな側面を表す4つを含む、動作モデリングの一般的なUML図のタイプを表します。

これらの図は、次のUML図マップに示すように階層的に分類できます。

質問：UMLは巨大で複雑ですか？

UMLは本当に大きなトピックです。UMLは、14の異なるUMLダイアグラムタイプにグループ化された大量のダイアグラム表記を提供し、それぞれが異なるUMLモデルを持ち、さまざまな目的を果たし、開発ニーズのさまざまな側面に対応します。

14のUML図タイプの各UML図は、ほとんどのソフトウェア開発プロジェクトのさまざまなニーズをカバーする構成と表記の大規模なセットを提供します。
UML仕様は700ページを超えており、明らかに複雑すぎると見なされており、UMLの認識と採用に悪影響を及ぼします。
通常、ユーザーはUMLの図/構成の一部のみを検討して使用する傾向があります。

回答：最も重要なUML図と表記法を学ぶ

統一モデリング言語の最も重要な開発者の1人であるGradyBoochは、「すべてのソフトウェアの80％には、UMLの20％しか必要ありません」と述べています。

UMLサーベイ*の状態とは何ですか？

UML調査の結果は、図が

ソースの60％以上の場合、広く使用されています
ソースの40％以下の場合はほとんど使用されません

この記事では、上記の使用頻度の順に、14種類すべてのUML図を紹介します。

たとえば、クラス図は最も広く使用されているものであるため、このセクションで最初に説明します。

クラス図

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

クラス図の目的

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

UMLクラス図は、次のもので構成されています。

クラスのセットと
クラス間の一連の関係

クラス図—ダイアグラムツールの例

クラス図には、クラスまたは関係にメモが添付されている場合もあります。メモは灰色で表示されます。

上記の例では：

上記のクラス図の意味は、次のようにポイントを読むことで解釈できます。

Shapeは抽象クラスです。斜体で表示されます。
Shapeはスーパークラスです。Circle、Rectangle、PolygonはShapeから派生しています。言い換えれば、円は-形です。これは一般化/継承の関係です。
DialogBoxとDataControllerの間には関連付けがあります。
形状はウィンドウの一部です。これは集約関係です。形状はウィンドウなしで存在できます。
ポイントはサークルの一部です。これは構成関係です。ポイントはサークルなしでは存在できません。
ウィンドウはイベントに依存しています。ただし、イベントはウィンドウに依存しません。
Circleの属性は、半径と中心です。これはエンティティクラスです。
Circleのメソッド名は、area（）、circum（）、setCenter（）、setRadius（）です。
Circleのパラメータradiusは、float型のinパラメータです。
クラスCircleのメソッドarea（）は、double型の値を返します。
Rectangleの属性とメソッド名は非表示になっています。ダイアグラム内の他のいくつかのクラスにも、属性とメソッド名が非表示になっています。

UMLで2番目に人気のあるタイプの図は、アクティビティ図です。

アクティビティ図

アクティビティ図は、システムの動的な側面を説明するためのUML図のもう1つの重要な動作図です。アクティビティ図は、基本的に、あるアクティビティから別のアクティビティへのフローをモデル化するフローチャートの高度なバージョンです。

アクティビティ図を使用する場合

アクティビティ図は、さまざまな抽象化レベルのサービスを提供するためにアクティビティがどのように調整されるかを示しています。通常、イベントは一部の操作で達成する必要があります。特に、操作が調整を必要とするさまざまなことを達成することを目的としている場合、または単一のユースケースのイベントが相互にどのように関連しているか、特にアクティビティが重複し、調整が必要になる場合があります。また、ユースケースのコレクションがビジネスワークフローを表すためにどのように調整するかをモデル化するのにも適しています

ビジネスワークフローの調査を通じて、候補となるユースケースを特定します
ユースケースの事前条件と事後条件（コンテキスト）を特定する
ユースケース間/ユースケース内のワークフローをモデル化する
オブジェクトの操作で複雑なワークフローをモデル化する
高レベルのアクティビティ図で複雑なアクティビティを詳細にモデル化する

アクティビティ図—例で学ぶ

基本的なアクティビティ図—次のようなフローチャート

アクティビティ図の例—プロセスの順序

注文を処理するためのワークフローに関連する問題の説明を前提として、アクティビティ図を使用して視覚的な表現で説明をモデル化しましょう。

プロセスの順序—問題の説明

注文を受け取ると、アクティビティは2つの並列セットのアクティビティに分割されます。一方が注文を処理して送信し、もう一方が請求を処理します。

フィルオーダー側では、配送方法が条件付きで決定されます。状態に応じて、オーバーナイトデリバリーアクティビティまたはレギュラーデリバリーアクティビティのいずれかが実行されます。

最後に、並列アクティビティを組み合わせて注文を閉じます。

以下のアクティビティ図の例は、フローをグラフ形式で視覚化したものです。

3番目に広く使用されているUML図のタイプは、シーケンス図です。

シーケンス図

UML シーケンス図は、操作の実行方法を詳しく説明する相互作用図です。これらは、コラボレーションのコンテキストでオブジェクト間の相互作用をキャプチャします。シーケンス図は時間に焦点を当てており、図の縦軸を使用して、どのメッセージがいつ送信されるかを表すために、対話の順序を視覚的に示します。

シーケンス図の例：ホテルシステム

シーケンス図は、操作がどのように実行されるか（どのメッセージがいつ送信されるか）を詳細に示す相互作用図です。シーケンス図は時間に従って編成されています。ページを下に行くにつれて時間が進みます。操作に関係するオブジェクトは、メッセージシーケンスに参加するタイミングに従って、左から右に一覧表示されます。

以下はホテル予約のシーケンス図です。メッセージのシーケンスを開始するオブジェクトは、予約ウィンドウです。

注：クラス図とオブジェクト図は静的モデルビューです。相互作用図は動的です。オブジェクトがどのように連携するかを説明します。

4番目に広く使用されているUML図のタイプ（96％）は次のとおりです。

ユースケース図
ステートマシン図

ユースケース図

UMLのユースケース図は、開発が不十分な新しいソフトウェアプログラムのシステム/ソフトウェア要件の主要な形式です。ユースケースは、期待される動作（何）を指定し、それを実現する正確な方法（方法）ではありません。

一度指定されたユースケースは、テキスト表現と視覚的表現の両方で表すことができます（つまり、ユースケース図）。ユースケースモデリングの重要な概念は、エンドユーザーの観点からシステムを設計するのに役立つということです。これは、外部から見えるすべてのシステム動作を指定することにより、ユーザーの用語でシステム動作を伝達するための効果的な手法です。

ユースケース図の概要

以下のユースケース図の例に示すように、標準形式のユースケース図は統一モデリング言語で定義されています。

ユースケース図—車両販売システム

次の図は、車両システムのユースケース図の例を示しています。ご覧のとおり、自動車販売システムと同じくらい大きなシステムでも、10個以下のユースケースが含まれています。それがユースケースモデリングの美しさです。

ユースケースモデルは、extendとincludeの使用法も示しています。さらに、アクターとユースケースを結び付ける関連付けがあります。

状態図

エンティティの動作は、その入力の直接的な結果であるだけでなく、その前の状態にも依存します。エンティティの過去の履歴は、有限状態マシン図または従来はオートマトンと呼ばれていたものによって最もよくモデル化できます。

UML ステートマシン図（またはステートダイアグラム、ステートマシン、またはステートチャートと呼ばれることもあります）は、エンティティのさまざまな状態を示します。ステートマシン図は、ある状態から別の状態に変化することによって、エンティティがさまざまなイベントにどのように応答するかを示すこともできます。ステートマシン図は、システムの動的な性質をモデル化するために使用されるUML図です。

単純なステートマシン図の表記

単純な状態とは、下部構造を持たない状態です。サブステート（ネストされた状態）を持つ状態は、複合状態と呼ばれます。サブステートは、任意のレベルにネストできます。ネストされたステートマシンは、最大で1つの初期状態と1つの最終状態を持つことができます。サブステートは、一部の状態が特定のコンテキスト（囲んでいる状態）内でのみ可能であることを示すことにより、複雑なフラットステートマシンを単純化するために使用されます。

サブステートの例—ヒーター

歴史の州

特に指定がない限り、遷移が複合状態に入ると 、ネストされたステートマシンのアクションは、初期状態から最初からやり直します （遷移がサブ状態を直接対象としている場合を除く）。履歴状態により、ステートマシンは、複合状態を終了する前にアクティブだった最後のサブ状態に再び入ることができます。履歴状態の使用例を次の図に示します。

調査によると、コミュニケーション図の使用率は82％です。

コミュニケーション図

シーケンス図（一種の相互作用図）のようなUML 通信図は、オブジェクトがどのように相互作用するかを示します。通信図は、オブジェクト図の拡張であり、オブジェクトと、あるメッセージから別のメッセージに移動するメッセージを示します。オブジェクト間の関連付けに加えて、通信図には、オブジェクトが相互に送信するメッセージが表示されます。

一目でわかるコミュニケーション図

通信図の表記例では、オブジェクト（ユースケースではアクター）は長方形で表されます。例（一般的な通信図）では：

オブジェクトは、Object1、Object2、Object…、ObjectN-1…、およびObjectNです。
オブジェクト間で受け渡されるメッセージは、送信オブジェクト（アクター）で始まり、受信オブジェクトで終わるラベル付きの矢印で表されます。
オブジェクト間で渡されるサンプルメッセージには、1：message1、2：message2、3：message3などのラベルが付けられます。ここで、メッセージ名の数字のプレフィックスは、シーケンス内の順序を示します。
Object1は最初にObject2にメッセージmessage1を送信し、Object2はObjectN-1にメッセージmessage2を送信します。
オブジェクトがそれ自体に送信するメッセージは、ループとして示されます（例：メッセージmessage5）。

コミュニケーション図とシーケンス図

通信図とシーケンス図は似ています。それらは意味的に同等です。つまり、同じ情報を提示し、通信をシーケンス図に、またはその逆に変えることができます。それらの主な違いは、通信図が空間に従って要素を配置し、シーケンス図が時間に従って配置されていることです。

2種類の相互作用図のうち、シーケンス図はコミュニケーション図よりもはるかに多く使用されているようです。では、なぜコミュニケーション図を使用するのでしょうか。まず第一に、それらは特定のタスクを実行するために協力しているオブジェクト間の関係を視覚化するのに非常に役立ちます。これは、シーケンス図から判断するのは困難です。さらに、通信図は、静的モデル（つまり、クラス図）の精度を判断するのにも役立ちます。

コンポーネント図と配置図の両方の使用率は80％です。

コンポーネント図

UML コンポーネント図は、コンポーネントベースのシステムの視覚化、指定、および文書化に使用されるオブジェクト指向システムの物理的側面のモデリング、およびフォワードエンジニアリングとリバースエンジニアリングによる実行可能システムの構築に使用されます。

コンポーネント図は、基本的に、システムの静的実装ビューをモデル化するためによく使用されるシステムのコンポーネントに焦点を当てたクラス図です。

コンポーネント図の概要

コンポーネント図は、開発中の実際のシステムをさまざまな高レベルの機能に分解します。各コンポーネントは、システム全体の1つの明確な目的に責任があり、知る必要がある場合にのみ他の重要な要素と相互作用します。

配置図

UML 配置図は、ランタイム処理ノードとそれらに存在するコンポーネントの構成を示す図です。配置図は、オブジェクト指向システムの物理的側面をモデル化する際に使用される一種の構造図です。これらは、システムの静的配置ビュー（ハードウェアのトポロジ）をモデル化するためによく使用されます。

一目でわかる配置図

配置図は、組み込み、クライアント/サーバー、および分散システムを視覚化、指定、および文書化するため、またフォワードエンジニアリングおよびリバースエンジニアリングを通じて実行可能システムを管理するために重要です。

配置図は、システムのノードに焦点を当てた特別な種類のクラス図です。グラフィカルに、配置図は頂点と円弧のコレクションです。配置図には通常、次のものが含まれます。

ノード

3Dボックスは、ソフトウェアまたはハードウェアのいずれかのノードを表します
HWノードは<<ステレオタイプ>>で表すことができます
ノード間の接続は、オプションの<<ステレオタイプ>>を使用して線で表されます。
ノードはノード内に存在できます

その他の表記

依存
アソシエーション関係。
メモや制約が含まれる場合もあります。

調査によると、UMLオブジェクト図の使用率は71％です。

オブジェクト図

オブジェクトは、オブジェクトやデータ値など、実行時の特定の瞬間のインスタンスです。静的 UML オブジェクト図は、クラス図のインスタンスです。ある時点でのシステムの詳細な状態のスナップショットが表示されるため、オブジェクト図には、ある時点でのオブジェクトとその関係が含まれます。

オブジェクト図の概要

オブジェクト図は、インスタンス化されたクラスと定義されたクラスの間のこの関係、およびシステム内のこれらのオブジェクト間の関係を示しています。これらは、システムクラス図が非常に複雑な場合に、システムのより小さな部分を説明するのに役立ちます。また、図で漸化式をモデル化する場合もあります。

オブジェクト図がどのように見えるかを説明する最良の方法は、対応するクラス図から派生したオブジェクト図を表示することです。

次の注文管理システムは、それらの関係を示しています。この小さなクラス図は、大学の学部に他の多くの学部を含めることができることを示しています。以下のオブジェクト図は、クラス図を具体的な例に置き換えてインスタンス化します。

クラスからオブジェクト図の例—注文システム

パッケージ図の使用率は70％です。

パッケージ図

構造図の一種であるパッケージ図は、中規模から大規模のプロジェクトにおけるモデル要素の配置と編成を示しています。パッケージ図は、サブシステムまたはモジュール間の構造と依存関係の両方を示すことができ、たとえば、多層（別名多層）アプリケーション（多層アプリケーションモデル）として、システムのさまざまなビューを示します。

パッケージ図の概要

パッケージ図は、複雑なクラス図を単純化するために使用されます。クラスをパッケージにグループ化できます。パッケージは、論理的に関連するUML要素のコレクションです。

次の図は、クラスがパッケージにグループ化されているビジネスモデルです。

パッケージは、上部に小さなタブが付いた長方形として表示されます。
パッケージ名は、タブまたは長方形の内側にあります。
点線の矢印は依存関係です。
他のパッケージの変更が最初のパッケージの変更を強制する可能性がある場合、1つのパッケージは別のパッケージに依存します。

複合構造図の使用率は52％です。

複合構造図

複合構造図は、UML2.0に追加された新しいアーティファクトの1つです。複合構造図は、クラス、インターフェース、パッケージ、およびそれらの関係を含み、ソフトウェアシステムのすべてまたは一部の論理ビューを提供するUML構造図です。構造化された分類子またはコラボレーションの内部構造（パーツとコネクタを含む）を示します。

複合構造図はクラス図と同様の役割を果たしますが、複数のクラスの内部構造を記述し、それらの間の相互作用を示す際に、さらに詳細に入ることができます。内部のクラスとパーツをグラフィカルに表現し、クラス間とクラス内の両方の関連付けを表示できます。

一目でわかる複合構造図

複合構造図は、クラスの内部部分を示しています。
パーツの名前は次のとおりです。partName：partType [multiplicity]
集約されたクラスはクラスの一部ですが、パーツは必ずしもクラスである必要はありません。パーツは、含まれているクラスを構成するために使用される要素です。

タイミング図の使用率はわずか40％で、平均的なユーザーが使用することはめったにありません

タイミング図

タイミング図は、図の主な目的が時間について推論することである場合に相互作用を示すために使用されるUML相互作用図です。それらは、線形時間軸に沿ってライフライン内およびライフライン間で変化する条件に焦点を合わせています。タイミング図は、個々の分類子の動作と分類子の相互作用の両方を記述し、ライフラインのモデル化された条件の変化を引き起こすイベントの発生時間に注目します。

一目でわかる時間図

州のタイムライン表現

ある 状態から別の状態への変化は、ライフラインのレベルの変化 によって表されます。オブジェクトが特定の状態である期間、タイムラインはその状態と並行して実行されます。状態の変化は、あるレベルから別のレベルへの垂直方向の変化として表示されます。状態図やシーケンス図の場合と同様に、変更の原因は、メッセージの受信、変更を引き起こすイベント、システム内の状態、または時間の経過ですらあります。

価値のライフライン表現

次の図は、UMLタイミング図の代替表記を示しています。状態が変化するたびに交差する2本の水平線の間のオブジェクトの状態を示します。

インタラクティブ概要図は、UML2.0で追加された新しい図です。

インタラクティブな概要図

UML相互作用の概要図は、相互作用モデルの高レベルの抽象化を提供します。これは、ノードが相互作用または相互作用の発生であるアクティビティ図の変形です。

相互作用の概要図は、相互作用の制御の流れの概要に焦点を当てており、図間の活動の流れを示すこともできます。つまり、「実際の」図をリンクして、インタラクション概要図内の図間で高度なナビゲーションを実現できます。

インタラクション概要図の概要

相互作用の概要図は、統一モデリング言語（UML）の14種類の図の1つであり、さまざまなシナリオでフラグメントのセットがどのように開始されるかを示す相互作用図を含むことができるノードを持つ制御フローを描くことができます。相互作用の概要図は、ノードが 相互作用 （sd）または 相互作用の使用 （ref）である制御フローの概要に焦点を当てています。

相互作用の概要図の他の表記要素は、アクティビティおよびシーケンス図の場合と同じです。これらには、初期、最終、決定、マージ、フォーク、および結合ノードが含まれます。

最も使用頻度の低いUMLダイアグラムはプロファイルダイアグラムであり、11％しか得られませんでした。

プロファイル図

汎用モデリング言語として、UMLはさまざまな要件に対する安定した基盤を提供します。特定のアプリケーションドメインや特定のテクノロジーに対しては定義されていません。ただし、状況によっては、UMLは一般的すぎて、それを使用するにはかなりの労力が必要になります。このような場合、特定のドメインに最適化された言語を使用して、特別な概念を提供することが有利です。

統一モデリング言語（UML）の一種の構造図であるプロファイル図は、特定のドメインおよびプラットフォーム用にUMLモデルをカスタマイズするための一般的な拡張メカニズムを提供します。拡張メカニズムにより、標準のセマンティクスを厳密に付加的な方法で改良し、標準のセマンティクスと矛盾しないようにすることができます。プロファイルは、ステレオタイプ、 タグ付き値の定義、およびクラス、属性、操作、アクティビティなどの特定のモデル要素に適用される制約を使用して定義されます。プロファイルは、特定のドメイン（航空宇宙、ヘルスケア、金融など）またはプラットフォーム（J2EE、.NET）用にUMLを集合的にカスタマイズする拡張機能のコレクションです。

プロファイル図の例—IT管理

プロファイル内のステレオタイプをそのパッケージで使用できるようにするために、プロファイルが別のパッケージに適用されます。次の図は、ITManagementパッケージに適用されているネットワーク、テレコム、およびソフトウェアのプロファイルを示しています。