UML-クイックガイド

UMLは、ソフトウェアシステムの成果物を指定、視覚化、構築、および文書化するための標準言語です。

UMLはObjectManagement Group（OMG）によって作成され、UML1.0仕様ドラフトが1997年1月にOMGに提案されました。

OMGは、真の業界標準を作成するために継続的に努力しています。

UMLは Unified Modeling Language。
UMLは、C ++、Java、COBOLなどの他の一般的なプログラミング言語とは異なります。
UMLは、ソフトウェアの青写真を作成するために使用される画像言語です。
UMLは、ソフトウェアシステムを視覚化、指定、構築、および文書化するための汎用ビジュアルモデリング言語として説明できます。
UMLは一般的にソフトウェアシステムのモデル化に使用されますが、この境界内に限定されません。また、ソフトウェア以外のシステムのモデル化にも使用されます。たとえば、製造ユニットのプロセスフローなど。

UMLはプログラミング言語ではありませんが、ツールを使用して、UML図を使用してさまざまな言語でコードを生成できます。UMLは、オブジェクト指向の分析および設計と直接的な関係があります。いくつかの標準化の後、UMLはOMG標準になりました。

UMLの目標

写真は千の言葉の価値があります、このイディオムはUMLを説明するのに完全に適合します。オブジェクト指向の概念は、UMLよりもはるかに早く導入されました。その時点では、オブジェクト指向開発を編成および統合するための標準的な方法論はありませんでした。その時、UMLが登場しました。

UMLの開発にはいくつかの目標がありますが、最も重要なのは、すべてのモデラーが使用できる汎用モデリング言語を定義することです。また、理解と使用を簡単にする必要があります。

UMLダイアグラムは、開発者だけでなく、ビジネスユーザー、一般の人々、およびシステムの理解に関心のあるすべての人のために作成されています。システムは、ソフトウェアシステムでも非ソフトウェアシステムでもかまいません。したがって、UMLは開発方法ではなく、システムを成功させるためのプロセスを伴うことを明確にする必要があります。

結論として、UMLの目標は、今日の複雑な環境で考えられるすべての実用的なシステムをモデル化するための単純なモデリングメカニズムとして定義できます。

UMLの概念モデル

UMLの概念モデルを理解するには、まず概念モデルとは何かを明確にする必要があります。なぜ概念モデルが必要なのですか？

概念モデルは、概念とそれらの関係で構成されるモデルとして定義できます。
概念モデルは、UML図を描く前の最初のステップです。実世界のエンティティと、それらが互いにどのように相互作用するかを理解するのに役立ちます。

UMLはリアルタイムシステムを説明しているため、概念モデルを作成してから徐々に進めることが非常に重要です。UMLの概念モデルは、次の3つの主要な要素を学習することで習得できます。

UMLビルディングブロック
ビルディングブロックを接続するためのルール
UMLの一般的なメカニズム

オブジェクト指向の概念

UMLは、オブジェクト指向（OO）分析および設計の後継として説明できます。

オブジェクトには、データとデータを制御するメソッドの両方が含まれています。データはオブジェクトの状態を表します。クラスはオブジェクトを記述し、実際のシステムをモデル化するための階層も形成します。階層は継承として表され、クラスは要件に応じてさまざまな方法で関連付けることもできます。

オブジェクトは私たちの周りに存在する現実世界のエンティティであり、抽象化、カプセル化、継承、ポリモーフィズムなどの基本的な概念はすべて、UMLを使用して表すことができます。

UMLは、オブジェクト指向の分析と設計に存在するすべての概念を表すのに十分強力です。UMLダイアグラムは、オブジェクト指向の概念のみを表したものです。したがって、UMLを学習する前に、オブジェクト指向の概念を詳細に理解することが重要になります。

以下は、オブジェクト指向の世界のいくつかの基本的な概念です-

Objects −オブジェクトは、エンティティと基本的な構成要素を表します。
Class −クラスはオブジェクトの青写真です。
Abstraction −抽象化は、実世界のエンティティの動作を表します。
Encapsulation −カプセル化は、データを結合して外界から隠すメカニズムです。
Inheritance −継承は、既存のクラスから新しいクラスを作成するメカニズムです。
Polymorphism −さまざまな形で存在するメカニズムを定義します。

オブジェクト指向分析と設計

OOは調査として定義でき、より具体的には、オブジェクトの調査です。デザインとは、識別されたオブジェクトのコラボレーションを意味します。

したがって、オブジェクト指向分析と設計の概念を理解することが重要です。オブジェクト指向分析の最も重要な目的は、設計するシステムのオブジェクトを特定することです。この分析は、既存のシステムに対しても実行されます。現在、効率的な分析は、オブジェクトを識別できる方法で考え始めることができる場合にのみ可能です。オブジェクトを特定した後、それらの関係が特定され、最終的にデザインが作成されます。

オブジェクト指向分析と設計の目的は、次のように説明できます。

システムのオブジェクトを識別する。
それらの関係を特定する。
オブジェクト指向言語を使用して実行可能ファイルに変換できる設計を作成します。

オブジェクト指向の概念が適用および実装される3つの基本的なステップがあります。ステップは次のように定義できます。

OO Analysis → OO Design → OO implementation using OO languages

上記の3つのポイントは、次のように詳細に説明できます。

オブジェクト指向分析中の最も重要な目的は、オブジェクトを識別し、適切な方法でそれらを記述することです。これらのオブジェクトが効率的に識別されれば、次の設計作業は簡単です。オブジェクトは責任を持って識別される必要があります。責任は、オブジェクトによって実行される機能です。すべてのオブジェクトには、実行する必要のあるある種の責任があります。これらの責任が連携することで、システムの目的が果たされます。
2番目のフェーズはオブジェクト指向設計です。このフェーズでは、要件とその履行に重点が置かれます。この段階では、オブジェクトは意図された関連付けに従ってコラボレーションされます。関連付けが完了すると、デザインも完了します。
3番目のフェーズはOOの実装です。このフェーズでは、Java、C ++などのオブジェクト指向言語を使用して設計が実装されます。

オブジェクト指向設計におけるUMLの役割

UMLは、ソフトウェアおよび非ソフトウェアシステムのモデリングに使用されるモデリング言語です。UMLはソフトウェア以外のシステムに使用されますが、OOソフトウェアアプリケーションのモデリングに重点が置かれています。これまでに説明したUMLダイアグラムのほとんどは、静的、動的などのさまざまな側面をモデル化するために使用されます。現在、側面が何であれ、アーティファクトはオブジェクトに他なりません。

クラス図、オブジェクト図、コラボレーション図、相互作用図を見ると、基本的にすべてオブジェクトに基づいて設計されます。

したがって、オブジェクト指向設計とUMLの関係を理解することは非常に重要です。OO設計は、要件に応じてUML図に変換されます。UMLを詳細に理解する前に、オブジェクト指向の概念を適切に学習する必要があります。オブジェクト指向分析と設計が完了すると、次のステップは非常に簡単です。オブジェクト指向分析および設計からの入力は、UML図への入力です。

UMLビルディングブロック
ビルディングブロックを接続するためのルール
UMLの一般的なメカニズム

この章では、すべてのUMLビルディングブロックについて説明します。UMLの構成要素は、次のように定義できます。

Things
Relationships
Diagrams

物事

ThingsUMLの最も重要な構成要素です。物事はすることができます-

Structural
Behavioral
Grouping
Annotational

構造的なもの

Structural thingsモデルの静的部分を定義します。それらは、物理的および概念的な要素を表しています。以下は、構造的なものの簡単な説明です。

Class − クラスは、同様の責任を持つオブジェクトのセットを表します。

Interface − インターフェイスは、クラスの責任を指定する一連の操作を定義します。

Collaboration −コラボレーションは、要素間の相互作用を定義します。

Use case −ユースケースは、特定の目標のためにシステムによって実行される一連のアクションを表します。

Component −コンポーネントは、システムの物理的な部分を記述します。

Node − ノードは、実行時に存在する物理要素として定義できます。

行動的なもの

A behavioral thingUMLモデルの動的部分で構成されています。以下は行動的なものです-

Interaction − 相互作用は、特定のタスクを実行するために要素間で交換されるメッセージのグループで構成される動作として定義されます。

State machine −ステートマシンは、ライフサイクルにおけるオブジェクトの状態が重要な場合に役立ちます。これは、イベントに応答してオブジェクトが通過する状態のシーケンスを定義します。イベントは状態変化の原因となる外部要因です

物事のグループ化

Grouping thingsUMLモデルの要素をグループ化するメカニズムとして定義できます。利用できるグループ化は1つだけです-

Package − パッケージは、構造的および行動的なものを収集するために利用できる唯一のグループ化のものです。

注釈的なもの

Annotational things UMLモデル要素のコメント、説明、コメントをキャプチャするメカニズムとして定義できます。 Note-これは、利用可能な唯一の注釈付きのものです。メモは、UML要素のコメントや制約などをレンダリングするために使用されます。

関係

RelationshipUMLのもう1つの最も重要な構成要素です。これは、要素が互いにどのように関連付けられているかを示し、この関連付けはアプリケーションの機能を説明します。

利用可能な関係には4種類あります。

依存

依存関係は、一方の要素の変更がもう一方の要素にも影響を与える2つの要素間の関係です。

協会

アソシエーションは基本的に、UMLモデルの要素を接続するリンクのセットです。また、その関係に参加しているオブジェクトの数についても説明します。

一般化

一般化は、特殊な要素と一般化された要素を接続する関係として定義できます。基本的に、オブジェクトの世界における継承関係について説明します。

実現

実現は、2つの要素が接続されている関係として定義できます。1つの要素は、実装されていない責任を記述し、もう1つの要素はそれらを実装します。この関係は、インターフェースの場合に存在します。

UML図

UMLダイアグラムは、ディスカッション全体の最終的な出力です。すべての要素、関係は完全なUMLダイアグラムを作成するために使用され、ダイアグラムはシステムを表します。

UMLダイアグラムの視覚効果は、プロセス全体の中で最も重要な部分です。他のすべての要素は、それを完成させるために使用されます。

UMLには、次の9つの図が含まれています。詳細については、以降の章で説明します。

クラス図
オブジェクト図
ユースケース図
シーケンス図
コラボレーション図
アクティビティ図
ステートチャート図
配置図
コンポーネント図

実際のシステムは、さまざまなユーザーによって使用されます。ユーザーは、開発者、テスター、ビジネスマン、アナリストなど、さまざまです。したがって、システムを設計する前に、アーキテクチャはさまざまな視点を念頭に置いて作成されます。最も重要な部分は、さまざまな視聴者の視点からシステムを視覚化することです。理解が深まるほど、システムを構築できるようになります。

UMLは、システムのさまざまな視点を定義する上で重要な役割を果たします。これらの視点は-

Design
Implementation
Process
Deployment

中心は Use Caseこれら4つすべてをつなぐビュー。AUse Caseシステムの機能を表します。したがって、他の視点はユースケースに関連しています。

Designシステムのは、クラス、インターフェース、およびコラボレーションで構成されます。UMLは、これをサポートするクラス図、オブジェクト図を提供します。

Implementation完全な物理システムを作成するために一緒に組み立てられるコンポーネントを定義します。UMLコンポーネント図は、実装の観点をサポートするために使用されます。

Processシステムのフローを定義します。したがって、この観点をサポートするために、デザインで使用されているものと同じ要素も使用されます。

Deploymentハードウェアを形成するシステムの物理ノードを表します。UML配置図は、この観点をサポートするために使用されます。

UMLモデルを区別することは非常に重要です。さまざまなタイプのUMLモデリングにさまざまな図が使用されます。UMLモデリングには3つの重要なタイプがあります。

構造モデリング

構造モデリングは、システムの静的機能をキャプチャします。それらは以下から構成されます-

クラス図
オブジェクト図
配置図
パッケージ図
複合構造図
コンポーネント図

構造モデルはシステムのフレームワークを表し、このフレームワークは他のすべてのコンポーネントが存在する場所です。したがって、クラス図、コンポーネント図、配置図は構造モデリングの一部です。それらはすべて、要素とそれらを組み立てるメカニズムを表しています。

構造モデルは、システムの動的な動作を説明することはありません。クラス図は、最も広く使用されている構造図です。

行動モデリング

行動モデルは、システム内の相互作用を記述します。これは、構造図間の相互作用を表します。行動モデリングは、システムの動的な性質を示しています。それらは以下から構成されます-

アクティビティ図
相互作用図
ユースケース図

上記はすべて、システム内のフローの動的シーケンスを示しています。

建築モデリング

アーキテクチャモデルは、システムの全体的なフレームワークを表します。これには、システムの構造要素と動作要素の両方が含まれています。アーキテクチャモデルは、システム全体の青写真として定義できます。パッケージ図は、アーキテクチャモデリングの下にあります。

UMLは、その図式表記で人気があります。UMLは、ソフトウェアおよび非ソフトウェアシステムのコンポーネントを視覚化、指定、構築、および文書化するためのものであることは誰もが知っています。したがって、視覚化は、理解して覚えておく必要がある最も重要な部分です。

UML表記は、モデリングで最も重要な要素です。完全で意味のあるモデルを作成するには、表記法を効率的かつ適切に使用することが非常に重要です。その目的が適切に描写されていない限り、モデルは役に立たない。

したがって、表記法の学習は最初から強調する必要があります。物事や関係にはさまざまな表記法があります。UMLダイアグラムは、物事と関係の表記法を使用して作成されます。拡張性は、UMLをより強力で柔軟にするもう1つの重要な機能です。

この章では、基本的なUML表記について詳しく説明します。これは、第2章で説明したUMLビルディングブロックセクションの拡張にすぎません。

構造的なもの

構造的なもので使用されるグラフィック表記は、UMLで最も広く使用されています。これらはUMLモデルの名詞と見なされます。以下は構造的なもののリストです。

Classes
Object
Interface
Collaboration
使用事例
アクティブなクラス
Components
Nodes

クラス表記

UMLクラスは次の図で表されます。この図は4つの部分に分かれています。

上部のセクションは、クラスに名前を付けるために使用されます。
2つ目は、クラスの属性を表示するために使用されます。
3番目のセクションは、クラスによって実行される操作を説明するために使用されます。
4番目のセクションはオプションで、追加のコンポーネントを表示します。

クラスはオブジェクトを表すために使用されます。オブジェクトは、プロパティと責任を持つものであれば何でもかまいません。

オブジェクト表記

オブジェクトは、クラスと同じように表されています。唯一の違いは、次の図に示すように下線が引かれた名前です。

オブジェクトはクラスの実際の実装であるため、クラスのインスタンスと呼ばれます。したがって、クラスと同じ使用法になります。

インターフェイス表記

次の図に示すように、インターフェイスは円で表されます。それは一般的に円の下に書かれている名前を持っています。

インターフェイスは、実装せずに機能を説明するために使用されます。インターフェイスは、実装ではなく、さまざまな関数を定義するテンプレートのようなものです。クラスがインターフェースを実装するとき、要件に従って機能も実装します。

コラボレーション表記

次の図に示すように、コラボレーションは点線の日食で表されます。日食の中に名前が書かれています。

コラボレーションは責任を表しています。通常、責任はグループにあります。

ユースケース表記

ユースケースは、名前が入った日食として表されます。追加の責任が含まれる場合があります。

ユースケースは、システムの高レベルの機能をキャプチャするために使用されます。

アクター表記

アクターは、システムと相互作用する内部または外部のエンティティとして定義できます。

アクターは、ユースケース図で内部エンティティまたは外部エンティティを説明するために使用されます。

初期状態表記

初期状態は、プロセスの開始を示すために定義されます。この表記は、ほとんどすべての図で使用されています。

初期状態表記の使用法は、プロセスの開始点を示すことです。

最終状態表記

最終状態は、プロセスの終了を示すために使用されます。この表記は、ほとんどすべての図で終わりを説明するためにも使用されます。

最終状態表記の使用法は、プロセスの終了ポイントを示すことです。

アクティブクラス表記

アクティブなクラスは、境界線がしっかりしているクラスに似ています。アクティブクラスは通常、システムの同時動作を説明するために使用されます。

アクティブクラスは、システムの並行性を表すために使用されます。

コンポーネント表記

次の図に、UMLのコンポーネントに名前を付けて示します。必要に応じて、要素を追加できます。

コンポーネントは、UML図が作成されるシステムの任意の部分を表すために使用されます。

ノード表記

UMLのノードは、次の図に示すように、名前の付いた四角いボックスで表されます。ノードは、システムの物理コンポーネントを表します。

ノードは、サーバー、ネットワークなどのシステムの物理的な部分を表すために使用されます。

行動的なもの

動的パーツは、UMLの最も重要な要素の1つです。UMLには、ソフトウェアシステムと非ソフトウェアシステムの動的な部分を表す一連の強力な機能があります。これらの機能には、インタラクションとステートマシンが含まれます。

相互作用には2つのタイプがあります-

シーケンシャル（シーケンス図で表されます）
コラボレーティブ（コラボ図で表されます）

相互作用表記

相互作用は基本的に、2つのUMLコンポーネント間のメッセージ交換です。次の図は、インタラクションで使用されるさまざまな表記法を表しています。

相互作用は、システムのコンポーネント間の通信を表すために使用されます。

ステートマシン表記

ステートマシンは、コンポーネントのライフサイクルにおけるさまざまな状態を記述します。表記は次の図で説明されています。

ステートマシンは、システムコンポーネントのさまざまな状態を記述するために使用されます。状態は、状況に応じて、アクティブ、アイドル、またはその他のいずれかになります。

物事のグループ化

UMLモデルの編成は、設計の最も重要な側面の1つです。UMLでは、グループ化に使用できる要素は1つだけで、それはパッケージです。

パッケージ表記

パッケージ表記は次の図に示され、システムのコンポーネントをラップするために使用されます。

注釈的なもの

どの図でも、さまざまな要素とその機能の説明が非常に重要です。したがって、UMLには、この要件をサポートするための注記表記があります。

注表記

この表記を次の図に示します。これらの表記は、システムに必要な情報を提供するために使用されます。

関係

要素間の関係が適切に記述されていない限り、モデルは完全ではありません。関係は、 UMLモデルに適切な意味を与えます。以下は、UMLで使用可能なさまざまなタイプの関係です。

Dependency
Association
Generalization
Extensibility

依存関係の表記

依存関係はUML要素の重要な側面です。依存要素と依存の方向について説明します。

次の図に示すように、依存関係は点線の矢印で表されます。矢印の頭は独立した要素を表し、もう一方の端は従属要素を表します。

依存関係は、システムの2つの要素間の依存関係を表すために使用されます

アソシエーション表記

関連付けは、UML図の要素がどのように関連付けられるかを記述します。簡単に言えば、相互作用に参加している要素の数を表します。

関連付けは、両側に矢印のある（ない）点線で表されます。次の図に示すように、両端は2つの関連する要素を表します。多重度は、関連付けられているオブジェクトの数を示すために、末尾（1、*など）にも記載されています。

アソシエーションは、システムの2つの要素間の関係を表すために使用されます。

一般化表記

一般化は、オブジェクト指向の世界の継承関係を表します。それは親子関係です。

一般化は、次の図に示すように、中空の矢印の頭を持つ矢印で表されます。一方の端は親要素を表し、もう一方の端は子要素を表します。

一般化は、システムの2つの要素の親子関係を説明するために使用されます。

拡張性表記

すべての言語（プログラミングまたはモデリング）には、構文、セマンティクスなどの機能を拡張するためのメカニズムがあります。UMLには、拡張機能を提供するための次のメカニズムもあります。

ステレオタイプ（新しい要素を表します）
タグ付きの値（新しい属性を表します）
制約（境界を表します）

拡張性表記は、言語の能力を強化するために使用されます。これは基本的に、システムの追加の動作を表すために使用される追加の要素です。これらの追加の動作は、使用可能な標準の表記法ではカバーされていません。

前の章では、UMLの構成要素とその他の必要な要素について説明しました。次に、これらの要素をどこで使用するかを理解する必要があります。

要素はコンポーネントのようなもので、さまざまな方法で関連付けて、ダイアグラムと呼ばれる完全なUML画像を作成できます。したがって、実際のシステムに知識を実装するには、さまざまな図を理解することが非常に重要です。

複雑なシステムは、ある種の図や写真を作成することで最もよく理解できます。これらの図は、私たちの理解により良い影響を与えます。周りを見渡してみると、図は新しい概念ではなく、さまざまな業界でさまざまな形で広く使用されていることがわかります。

より良く簡単な方法でシステムを理解するためにUML図を準備します。システムのすべての側面を網羅するには、1つの図だけでは不十分です。UMLは、システムのほとんどの側面をカバーするためにさまざまな種類の図を定義します。

要件を満たすために、独自の図のセットを作成することもできます。ダイアグラムは通常、増分的かつ反復的な方法で作成されます。

ダイアグラムには大きく2つのカテゴリがあり、それらは再びサブカテゴリに分類されます-

構造図
行動図

構造図

構造図は、システムの静的な側面を表しています。これらの静的な側面は、ダイアグラムのこれらの部分を表しており、主要な構造を形成しているため、安定しています。

これらの静的パーツは、クラス、インターフェイス、オブジェクト、コンポーネント、およびノードによって表されます。4つの構造図は次のとおりです。

クラス図
オブジェクト図
コンポーネント図
配置図

クラス図

クラス図は、UMLで使用される最も一般的な図です。クラス図は、クラス、インターフェイス、関連付け、およびコラボレーションで構成されます。クラス図は基本的に、システムのオブジェクト指向ビューを表します。これは本質的に静的です。

アクティブクラスは、システムの同時実行性を表すためにクラス図で使用されます。

クラス図は、システムのオブジェクト指向を表します。したがって、一般的に開発目的で使用されます。これは、システム構築時に最も広く使用されている図です。

オブジェクト図

オブジェクト図は、クラス図のインスタンスとして説明できます。したがって、これらの図は、システムを実装する実際のシナリオにより近いものです。

オブジェクト図はオブジェクトのセットであり、それらの関係はクラス図と同じです。また、システムの静的ビューも表します。

オブジェクト図の使用法はクラス図に似ていますが、実用的な観点からシステムのプロトタイプを作成するために使用されます。

コンポーネント図

コンポーネント図は、一連のコンポーネントとそれらの関係を表しています。これらのコンポーネントは、クラス、インターフェイス、またはコラボレーションで構成されています。コンポーネント図は、システムの実装ビューを表します。

設計段階では、システムのソフトウェア成果物（クラス、インターフェイスなど）は、それらの関係に応じてさまざまなグループに配置されます。現在、これらのグループはコンポーネントとして知られています。

最後に、コンポーネント図は実装を視覚化するために使用されていると言えます。

配置図

配置図は、ノードとそれらの関係のセットです。これらのノードは、コンポーネントがデプロイされる物理エンティティです。

配置図は、システムの配置ビューを視覚化するために使用されます。これは通常、展開チームによって使用されます。

Note−上記の説明と使用法を注意深く観察すれば、すべての図が互いに何らかの関係を持っていることは非常に明白です。コンポーネント図は、クラス/オブジェクト図の一部であるクラス、インターフェースなどに依存しています。この場合も、配置図は、コンポーネント図の作成に使用されるコンポーネントに依存します。

行動図

どのシステムにも、静的と動的の2つの側面があります。したがって、両方の側面が完全にカバーされている場合、モデルは完全であると見なされます。

動作図は基本的に、システムの動的な側面をキャプチャします。動的な側面は、システムの変化/移動部分としてさらに説明できます。

UMLには、次の5種類の動作図があります-

ユースケース図
シーケンス図
コラボレーション図
ステートチャート図
アクティビティ図

ユースケース図

ユースケース図は、ユースケース、アクター、およびそれらの関係のセットです。これらは、システムのユースケースビューを表します。

ユースケースは、システムの特定の機能を表します。したがって、ユースケース図を使用して、機能とその内部/外部コントローラー間の関係を説明します。これらのコントローラーは、actors。

シーケンス図

シーケンス図は相互作用図です。名前から、図がいくつかのシーケンスを扱っていることは明らかです。これは、あるオブジェクトから別のオブジェクトに流れるメッセージのシーケンスです。

システムのコンポーネント間の相互作用は、実装と実行の観点から非常に重要です。シーケンス図は、特定の機能を実行するためにシステム内の呼び出しのシーケンスを視覚化するために使用されます。

コラボレーション図

コラボレーション図は、相互作用図のもう1つの形式です。これは、システムの構造的構成と送受信されるメッセージを表します。構造組織は、オブジェクトとリンクで構成されます。

コラボレーション図の目的は、シーケンス図に似ています。ただし、コラボレーション図の特定の目的は、オブジェクトの編成とそれらの相互作用を視覚化することです。

ステートチャート図

リアルタイムシステムは、ある種の内部/外部イベントによって反応することが期待されています。これらのイベントは、システムの状態変化に関与します。

ステートチャート図は、システムのイベント駆動型の状態変化を表すために使用されます。基本的に、クラスやインターフェースなどの状態変化を記述します。

状態チャート図は、内部/外部要因によるシステムの反応を視覚化するために使用されます。

アクティビティ図

アクティビティ図は、システム内の制御の流れを示しています。それは活動とリンクで構成されています。フローは、順次、同時、または分岐にすることができます。

活動はシステムの機能に他なりません。システム内のフロー全体をキャプチャするために、多数のアクティビティ図が用意されています。

アクティビティ図は、システム内の制御の流れを視覚化するために使用されます。これは、実行時にシステムがどのように機能するかを理解するために用意されています。

Note−システムの動的な性質を把握することは非常に困難です。UMLは、さまざまな角度からシステムのダイナミクスをキャプチャする機能を提供しています。シーケンス図とコラボレーション図は同形であるため、情報を失うことなく相互に変換できます。これは、ステートチャートとアクティビティ図にも当てはまります。

クラス図は静的な図です。これは、アプリケーションの静的ビューを表します。クラス図は、システムのさまざまな側面を視覚化、説明、および文書化するためだけでなく、ソフトウェアアプリケーションの実行可能コードを構築するためにも使用されます。

クラス図は、クラスの属性と操作、およびシステムに課せられる制約について説明しています。クラス図は、オブジェクト指向言語で直接マッピングできる唯一のUMLダイアグラムであるため、オブジェクト指向システムのモデリングで広く使用されています。

クラス図は、クラス、インターフェイス、関連付け、コラボレーション、および制約のコレクションを示しています。構造図とも呼ばれます。

クラス図の目的

クラス図の目的は、アプリケーションの静的ビューをモデル化することです。クラス図は、オブジェクト指向言語で直接マッピングできる唯一の図であり、したがって、構築時に広く使用されます。

アクティビティ図やシーケンス図などのUML図は、アプリケーションのシーケンスフローしか提供できませんが、クラス図は少し異なります。これは、コーダーコミュニティで最も人気のあるUML図です。

クラス図の目的は次のように要約できます。

アプリケーションの静的ビューの分析と設計。
システムの責任を説明します。
コンポーネントと配置図のベース。
フォワードエンジニアリングとリバースエンジニアリング。

クラス図を描く方法は？

クラス図は、ソフトウェアアプリケーションの構築に使用される最も一般的なUML図です。クラス図の描画手順を学ぶことは非常に重要です。

クラス図には、描画時に考慮すべき多くのプロパティがありますが、ここでは、図をトップレベルのビューから検討します。

クラス図は基本的に、システムの静的ビューをグラフィカルに表現したものであり、アプリケーションのさまざまな側面を表しています。クラス図のコレクションは、システム全体を表します。

クラス図を描くときは、次の点に注意してください。

クラス図の名前は、システムの側面を説明するのに意味のあるものでなければなりません。
各要素とそれらの関係は、事前に特定する必要があります。
各クラスの責任（属性とメソッド）を明確に特定する必要があります
不要なプロパティは図を複雑にするため、クラスごとに最小数のプロパティを指定する必要があります。
ダイアグラムのある側面を説明するために、必要に応じてメモを使用してください。図面の最後では、開発者/コーダーが理解できるはずです。
最後に、最終バージョンを作成する前に、図を普通紙に描き、それを正しくするために可能な限り何度も作り直す必要があります。

次の図は、アプリケーションの注文システムの例です。アプリケーション全体の特定の側面について説明します。

まず、注文と顧客はシステムの2つの要素として識別されます。顧客は複数の注文を行うことができるため、これらは1対多の関係にあります。
Orderクラスは抽象クラスであり、SpecialOrderとNormalOrderの2つの具象クラス（継承関係）があります。
2つの継承されたクラスには、Orderクラスとしてのすべてのプロパティがあります。さらに、ディスパッチ（）やレシーブ（）などの追加機能があります。

以下のクラス図は、上記のすべての点を考慮して描かれています。

クラス図はどこで使用しますか？

クラス図は静的な図であり、システムの静的なビューをモデル化するために使用されます。静的ビューは、システムの語彙を記述します。

クラス図は、コンポーネント図と配置図の基盤としても考慮されます。クラス図は、システムの静的ビューを視覚化するために使用されるだけでなく、任意のシステムのフォワードエンジニアリングおよびリバースエンジニアリング用の実行可能コードを構築するためにも使用されます。

一般に、UMLダイアグラムは、オブジェクト指向プログラミング言語に直接マッピングされませんが、クラスダイアグラムは例外です。

クラス図は、Java、C ++などのオブジェクト指向言語とのマッピングを明確に示しています。実際の経験から、クラス図は一般に構築目的で使用されます。

一言で言えば、クラス図は-に使用されます

システムの静的ビューを説明します。
静的ビューの要素間のコラボレーションを表示します。
システムによって実行される機能の説明。
オブジェクト指向言語を使用したソフトウェアアプリケーションの構築。

オブジェクト図はクラス図から派生しているため、オブジェクト図はクラス図に依存しています。

オブジェクト図は、クラス図のインスタンスを表します。基本的な概念は、クラス図とオブジェクト図で似ています。オブジェクト図もシステムの静的ビューを表しますが、この静的ビューは特定の時点でのシステムのスナップショットです。

オブジェクト図は、オブジェクトのセットとそれらの関係をインスタンスとしてレンダリングするために使用されます。

オブジェクト図の目的

ダイアグラムの目的は、それを実際に実装するために明確に理解する必要があります。オブジェクト図の目的は、クラス図に似ています。

違いは、クラス図がクラスとその関係で構成される抽象的なモデルを表すことです。ただし、オブジェクトダイアグラムは、特定の瞬間のインスタンスを表します。これは、本質的に具体的です。

これは、オブジェクト図が実際のシステム動作に近いことを意味します。目的は、特定の瞬間におけるシステムの静的ビューをキャプチャすることです。

オブジェクト図の目的は、次のように要約できます。

フォワードエンジニアリングとリバースエンジニアリング。
システムのオブジェクト関係
相互作用の静的ビュー。
オブジェクトの動作とそれらの関係を実用的な観点から理解する

オブジェクト図を描く方法は？

オブジェクト図はクラス図のインスタンスであることはすでに説明しました。これは、オブジェクト図がクラス図で使用されるもののインスタンスで構成されていることを意味します。

したがって、両方の図は同じ基本要素で構成されていますが、形式が異なります。クラス図では、要素は青写真を表すために抽象的な形式であり、オブジェクト図では、要素は実世界のオブジェクトを表すために具体的な形式です。

特定のシステムをキャプチャするために、クラス図の数は制限されています。ただし、オブジェクトダイアグラムを検討すると、インスタンスの数に制限はなく、本質的に一意です。システムに影響を与えるインスタンスのみが考慮されます。

上記の説明から、単一のオブジェクト図で必要なすべてのインスタンスをキャプチャすることはできず、システムのすべてのオブジェクトを指定することはできないことは明らかです。したがって、解は次のようになります。

まず、システムを分析し、どのインスタンスに重要なデータと関連付けがあるかを判断します。
次に、機能をカバーするインスタンスのみを検討します。
第三に、インスタンスの数は無制限なので、いくつかの最適化を行います。

オブジェクト図を描く前に、次のことを覚えて明確に理解する必要があります-

オブジェクト図はオブジェクトで構成されます。
オブジェクト図のリンクは、オブジェクトを接続するために使用されます。
オブジェクトとリンクは、オブジェクト図を作成するために使用される2つの要素です。

この後、ダイアグラムの作成を開始する前に、次のことを決定する必要があります。

オブジェクト図には、その目的を示す意味のある名前を付ける必要があります。
最も重要な要素を特定する必要があります。
オブジェクト間の関連を明確にする必要があります。
オブジェクト図に含めるには、さまざまな要素の値をキャプチャする必要があります。
より明確にする必要があるポイントに適切なメモを追加します。

次の図は、オブジェクト図の例です。これは、クラス図の章で説明した注文管理システムを表しています。次の図は、特定の購入時のシステムのインスタンスです。以下のオブジェクトがあります。

Customer
Order
SpecialOrder
NormalOrder

これで、顧客オブジェクト（C）が3つの注文オブジェクト（O1、O2、およびO3）に関連付けられました。これらの注文オブジェクトは、特別注文および通常注文オブジェクト（S1、S2、およびN1）に関連付けられています。顧客は、考慮される特定の時間に、異なる番号（12、32、および40）の次の3つの注文を持っています。

顧客は将来的に注文数を増やすことができ、そのシナリオではオブジェクト図にそれが反映されます。order、special order、およびnormal orderオブジェクトが観察される場合、それらにはいくつかの値があることがわかります。

注文の場合、値は12、32、および40です。これは、インスタンスがキャプチャされた特定の瞬間（ここでは、購入が行われた特定の時間が瞬間と見なされます）のオブジェクトがこれらの値を持っていることを意味します。

注文数が20、30、60の特別注文オブジェクトと通常注文オブジェクトについても同じことが言えます。異なる購入時期を考慮すると、これらの値はそれに応じて変化します。

以下のオブジェクト図は、上記のすべての点を考慮して描かれています。

オブジェクト図はどこで使用しますか？

オブジェクト図は、特定の時点で実行中のシステムのスナップショットとして想像できます。走っている電車の例を考えてみましょう

さて、走っている電車のスナップを撮ると、次のような静止画が見つかります。

実行中の特定の状態。
特定の数の乗客。スナップが別の時間に撮影されると変更されます

ここで、走っている電車のスナップは、上記の値を持つオブジェクトであると想像できます。そして、これは実際の単純または複雑なシステムに当てはまります。

一言で言えば、オブジェクト図は-に使用されていると言えます。

システムのプロトタイプを作成します。
リバースエンジニアリング。
複雑なデータ構造のモデリング。
実用的な観点からシステムを理解する。

コンポーネント図は、性質と動作の点で異なります。コンポーネント図は、システムの物理的側面をモデル化するために使用されます。さて、問題は、これらの物理的側面は何ですか？物理的側面は、ノードに存在する実行可能ファイル、ライブラリ、ファイル、ドキュメントなどの要素です。

コンポーネント図は、システム内のコンポーネント間の編成と関係を視覚化するために使用されます。これらの図は、実行可能システムの作成にも使用されます。

コンポーネント図の目的

コンポーネント図は、UMLの特殊な種類の図です。目的も、これまでに説明した他のすべての図とは異なります。システムの機能については説明していませんが、それらの機能を作成するために使用されるコンポーネントについては説明しています。

したがって、その観点から、コンポーネント図はシステム内の物理コンポーネントを視覚化するために使用されます。これらのコンポーネントは、ライブラリ、パッケージ、ファイルなどです。

コンポーネント図は、システムの静的な実装ビューとして説明することもできます。静的実装は、特定の時点でのコンポーネントの編成を表します。

単一のコンポーネント図でシステム全体を表すことはできませんが、図のコレクションを使用してシステム全体を表します。

コンポーネント図の目的は、次のように要約できます。

システムのコンポーネントを視覚化します。
フォワードエンジニアリングとリバースエンジニアリングを使用して実行可能ファイルを構築します。
コンポーネントの構成と関係を説明します。

コンポーネント図を描く方法は？

コンポーネント図は、システムの物理的なアーティファクトを説明するために使用されます。このアーティファクトには、ファイル、実行可能ファイル、ライブラリなどが含まれます

この図の目的は異なります。コンポーネント図は、アプリケーションの実装フェーズで使用されます。ただし、実装の詳細を視覚化するために、事前に十分に準備されています。

最初に、システムはさまざまなUMLダイアグラムを使用して設計され、アーティファクトの準備ができたら、コンポーネントダイアグラムを使用して実装のアイデアを取得します。

この図がないとアプリケーションを効率的に実装できないため、この図は非常に重要です。十分に準備されたコンポーネント図は、アプリケーションのパフォーマンスやメンテナンスなどの他の側面でも重要です。

コンポーネント図を描く前に、次のアーティファクトを明確に特定する必要があります-

システムで使用されるファイル。
アプリケーションに関連するライブラリおよびその他のアーティファクト。
アーティファクト間の関係。

アーティファクトを特定した後、次の点に注意する必要があります。

意味のある名前を使用して、図を描画するコンポーネントを識別します。
使用ツールを作成する前に、メンタルレイアウトを準備してください。
重要なポイントを明確にするためにメモを使用してください。

以下は、注文管理システムのコンポーネント図です。ここでは、アーティファクトはファイルです。この図は、アプリケーション内のファイルとそれらの関係を示しています。実際には、コンポーネント図にはdll、ライブラリ、フォルダなども含まれています。

次の図では、4つのファイルが識別され、それらの関係が生成されます。コンポーネント図は、まったく異なる目的で描かれている限り、説明されている他のUML図と直接一致させることはできません。

次のコンポーネント図は、上記のすべての点を考慮して描かれています。

コンポーネント図はどこで使用しますか？

コンポーネント図は、システムの静的実装ビューを視覚化するために使用されることはすでに説明しました。コンポーネント図は、さまざまな目的で使用される特殊なタイプのUML図です。

これらの図は、システムの物理コンポーネントを示しています。明確にするために、コンポーネント図はシステム内のコンポーネントの構成を説明していると言えます。

組織は、システム内のコンポーネントの場所としてさらに説明できます。これらのコンポーネントは、システム要件を満たすために特別な方法で編成されています。

すでに説明したように、これらのコンポーネントはライブラリ、ファイル、実行可能ファイルなどです。アプリケーションを実装する前に、これらのコンポーネントを整理する必要があります。このコンポーネント編成も、プロジェクト実行の一部として個別に設計されています。

コンポーネント図は、実装の観点から非常に重要です。したがって、アプリケーションの実装チームは、コンポーネントの詳細について適切な知識を持っている必要があります。

コンポーネント図は、次の目的で使用できます。

システムのコンポーネントをモデル化します。
データベーススキーマをモデル化します。
アプリケーションの実行可能ファイルをモデル化します。
システムのソースコードをモデル化します。

配置図は、ソフトウェアコンポーネントが展開されるシステムの物理コンポーネントのトポロジを視覚化するために使用されます。

配置図は、システムの静的配置ビューを説明するために使用されます。配置図は、ノードとその関係で構成されます。

配置図の目的

デプロイメントという用語自体は、図の目的を説明しています。配置図は、ソフトウェアコンポーネントが展開されるハードウェアコンポーネントを説明するために使用されます。コンポーネント図と配置図は密接に関連しています。

コンポーネント図はコンポーネントを説明するために使用され、配置図はそれらがハードウェアにどのように展開されるかを示します。

UMLは主に、システムのソフトウェアアーティファクトに焦点を当てるように設計されています。ただし、これら2つの図は、ソフトウェアおよびハードウェアコンポーネントに焦点を当てるために使用される特別な図です。

ほとんどのUMLダイアグラムは論理コンポーネントの処理に使用されますが、配置図はシステムのハードウェアトポロジに焦点を合わせて作成されています。配置図は、システムエンジニアによって使用されます。

配置図の目的は次のように説明できます。

システムのハードウェアトポロジを視覚化します。
ソフトウェアコンポーネントの展開に使用されるハードウェアコンポーネントについて説明します。
ランタイム処理ノードについて説明します。

配置図を描く方法は？

配置図は、システムの配置図を表します。コンポーネントは配置図を使用して配置されるため、コンポーネント図に関連しています。配置図はノードで構成されます。ノードは、アプリケーションのデプロイに使用される物理ハードウェアに他なりません。

配置図は、システムエンジニアに役立ちます。効率的な配置図は、次のパラメータを制御するため、非常に重要です。

Performance
Scalability
Maintainability
Portability

配置図を描く前に、次の成果物を特定する必要があります-

Nodes
ノード間の関係

以下は、注文管理システムの配置図のアイデアを提供するためのサンプル配置図です。ここでは、ノードを-として示しています。

Monitor
Modem
キャッシュサーバー
Server

アプリケーションは、サーバー1、サーバー2、およびサーバー3を使用してクラスター環境に展開されるWebベースのアプリケーションであると想定されます。ユーザーはインターネットを使用してアプリケーションに接続します。制御は、キャッシングサーバーからクラスター環境に流れます。

次の配置図は、上記のすべての点を考慮して描かれています。

配置図はどこで使用しますか？

配置図は、主にシステムエンジニアによって使用されます。これらの図は、物理コンポーネント（ハードウェア）、それらの分布、および関連付けを説明するために使用されます。

配置図は、ソフトウェアコンポーネントが存在するハードウェアコンポーネント/ノードとして視覚化できます。

ソフトウェアアプリケーションは、複雑なビジネスプロセスをモデル化するために開発されています。効率的なソフトウェアアプリケーションは、ビジネス要件を満たすのに十分ではありません。ビジネス要件は、増加するユーザー数、迅速な応答時間などをサポートする必要性として説明できます。

これらのタイプの要件を満たすには、ハードウェアコンポーネントを効率的かつ費用効果の高い方法で設計する必要があります。

今日のソフトウェアアプリケーションは、本質的に非常に複雑です。ソフトウェアアプリケーションは、スタンドアロン、Webベース、分散型、メインフレームベースなど、さまざまなものがあります。したがって、ハードウェアコンポーネントを効率的に設計することが非常に重要です。

配置図を使用できます-

システムのハードウェアトポロジをモデル化するため。
組み込みシステムをモデル化する。
クライアント/サーバーシステムのハードウェアの詳細をモデル化するため。
分散アプリケーションのハードウェアの詳細をモデル化するため。
フォワードエンジニアリングおよびリバースエンジニアリング用。

システムをモデル化するための最も重要な側面は、動的な動作をキャプチャすることです。動的な動作とは、実行中/動作中のシステムの動作を意味します。

システムをモデル化するには、静的な動作だけでは不十分であり、静的な動作よりも動的な動作の方が重要です。UMLには、動的な性質をモデル化するために使用できる5つの図があり、ユースケース図はその1つです。ここで、ユースケース図は本質的に動的であると説明する必要があるため、相互作用を行うための内部または外部の要因がいくつかあるはずです。

これらの内部および外部エージェントは、アクターとして知られています。ユースケース図は、アクター、ユースケース、およびそれらの関係で構成されます。この図は、アプリケーションのシステム/サブシステムをモデル化するために使用されます。単一のユースケース図は、システムの特定の機能をキャプチャします。

したがって、システム全体をモデル化するために、いくつかのユースケース図が使用されます。

ユースケース図の目的

ユースケース図の目的は、システムの動的な側面をキャプチャすることです。ただし、他の4つの図（アクティビティ、シーケンス、コラボレーション、およびステートチャート）にも同じ目的があるため、この定義は一般的すぎて目的を説明できません。他の4つの図と区別するために、いくつかの特定の目的を調べます。

ユースケース図は、内部および外部の影響を含むシステムの要件を収集するために使用されます。これらの要件は主に設計要件です。したがって、システムを分析してその機能を収集すると、ユースケースが準備され、アクターが特定されます。

最初のタスクが完了すると、ユースケース図がモデル化されて外観が表示されます。

簡単に言えば、ユースケース図の目的は次のように言えます。

システムの要件を収集するために使用されます。
システムの外観を取得するために使用されます。
システムに影響を与える外部要因と内部要因を特定します。
要件間の相互作用がアクターであることを示します。

ユースケース図を描く方法は？

ユースケース図は、システムの高レベルの要件分析のために考慮されます。システムの要件を分析すると、ユースケースで機能がキャプチャされます。

ユースケースは、組織化された方法で記述されたシステム機能に他ならないと言えます。ユースケースに関連する2番目のものは、アクターです。アクターは、システムと相互作用するものとして定義できます。

アクターは、人間のユーザー、一部の内部アプリケーション、または一部の外部アプリケーションの場合があります。ユースケース図を作成する場合は、次の項目を特定する必要があります。

ユースケースとして表される機能
Actors
ユースケースとアクター間の関係。

ユースケース図は、システムの機能要件を把握するために作成されています。上記の項目を特定した後、効率的なユースケース図を作成するには、次のガイドラインを使用する必要があります

ユースケースの名前は非常に重要です。名前は、実行される機能を識別できるように選択する必要があります。
俳優にふさわしい名前を付けてください。
関係と依存関係を図に明確に示します。
図の主な目的は要件を特定することであるため、すべてのタイプの関係を含めようとしないでください。
重要な点を明確にするために、必要に応じてメモを使用してください。

以下は、注文管理システムを表すサンプルのユースケース図です。したがって、図を見ると、3つのユースケースが見つかります。(Order, SpecialOrder, and NormalOrder) そして顧客である1人の俳優。

SpecialOrderおよびNormalOrderのユースケースは、Orderのユースケースから拡張されています。したがって、彼らは拡張された関係を持っています。もう1つの重要なポイントは、図に示されているシステム境界を特定することです。アクターCustomerは、システムの外部ユーザーであるため、システムの外部にあります。

ユースケース図はどこで使用しますか？

すでに説明したように、UMLには、システムの動的ビューをモデル化するための5つの図があります。現在、すべてのモデルには、使用する特定の目的があります。実際、これらの特定の目的は、実行中のシステムのさまざまな角度です。

システムのダイナミクスを理解するには、さまざまなタイプの図を使用する必要があります。ユースケース図はその1つであり、その特定の目的はシステム要件とアクターを収集することです。

ユースケース図は、システムのイベントとそのフローを指定します。ただし、ユースケース図では、それらがどのように実装されているかを説明することはありません。ユースケース図は、入力、出力、およびブラックボックスの機能のみがわかっているブラックボックスとして想像できます。

これらの図は、非常に高いレベルの設計で使用されます。この高レベルの設計は、システムの完全で実用的な全体像を得るために何度も洗練されています。適切に構成されたユースケースでは、前提条件、事後条件、および例外についても説明します。これらの追加要素は、テストを実行するときにテストケースを作成するために使用されます。

ユースケースはフォワードエンジニアリングとリバースエンジニアリングの適切な候補ではありませんが、それでもフォワードエンジニアリングとリバースエンジニアリングを行うためにわずかに異なる方法で使用されます。同じことがリバースエンジニアリングにも当てはまります。ユースケース図は、リバースエンジニアリングに適したものにするために異なる方法で使用されます。

フォワードエンジニアリングでは、ユースケース図を使用してテストケースを作成し、リバースエンジニアリングでは、ユースケースを使用して既存のアプリケーションから要件の詳細を準備します。

ユースケース図は次の目的で使用できます-

要件分析と高レベルの設計。
システムのコンテキストをモデル化します。
リバースエンジニアリング。
フォワードエンジニアリング。

相互作用という用語から、この図がモデル内のさまざまな要素間のある種の相互作用を説明するために使用されていることは明らかです。この相互作用は、システムの動的な動作の一部です。

このインタラクティブな動作は、UMLでは次の2つの図で表されます。 Sequence diagram そして Collaboration diagram。両方の図の基本的な目的は似ています。

シーケンス図はメッセージの時系列を強調し、コラボレーション図はメッセージを送受信するオブジェクトの構造的編成を強調します。

相互作用図の目的

対話図の目的は、システムの対話動作を視覚化することです。相互作用を視覚化することは難しい作業です。したがって、解決策は、さまざまなタイプのモデルを使用して、相互作用のさまざまな側面をキャプチャすることです。

シーケンス図とコラボレーション図は、動的な性質を別の角度から捉えるために使用されます。

相互作用図の目的は次のとおりです。

システムの動的な動作をキャプチャします。
システム内のメッセージフローを説明します。
オブジェクトの構造的構成を説明します。
オブジェクト間の相互作用を説明します。

相互作用図を描く方法は？

すでに説明したように、相互作用図の目的は、システムの動的な側面をキャプチャすることです。したがって、動的な側面をキャプチャするには、動的な側面とは何か、そしてそれがどのように視覚化されるかを理解する必要があります。動的アスペクトは、特定の時点で実行中のシステムのスナップショットとして定義できます。

UMLには2種類の相互作用図があります。1つはシーケンス図で、もう1つはコラボレーション図です。シーケンス図は、あるオブジェクトから別のオブジェクトへのメッセージフローの時系列をキャプチャし、コラボレーション図は、メッセージフローに参加しているシステム内のオブジェクトの編成を示します。

相互作用図を描く前に、次のことを明確に特定する必要があります

相互作用に参加しているオブジェクト。
メッセージはオブジェクト間を流れます。
メッセージが流れる順序。
オブジェクトの編成。

以下は、注文管理システムをモデル化した2つの相互作用図です。最初の図はシーケンス図で、2番目の図はコラボレーション図です。

シーケンス図

シーケンス図には、4つのオブジェクト（Customer、Order、SpecialOrder、およびNormalOrder）があります。

次の図は、SpecialOrderオブジェクトのメッセージシーケンスを示しています。これは、NormalOrderオブジェクトの場合にも使用できます。メッセージフローの時系列を理解することが重要です。メッセージフローは、オブジェクトのメソッド呼び出しに他なりません。

最初の呼び出しは、OrderオブジェクトのメソッドであるsendOrder（）です。次の呼び出しはSpecialOrderオブジェクトのメソッドであるconfirm（）であり、最後の呼び出しはSpecialOrderオブジェクトのメソッドであるDispatch（）です。次の図は、主に1つのオブジェクトから別のオブジェクトへのメソッド呼び出しを示しています。これは、システムが実行されているときの実際のシナリオでもあります。

コラボレーション図

2番目の相互作用図はコラボレーション図です。次の図に示すように、オブジェクトの編成を示しています。コラボレーション図では、メソッド呼び出しシーケンスはいくつかの番号付け手法で示されています。番号は、メソッドが次々に呼び出される方法を示しています。コラボレーション図を説明するために、同じ注文管理システムを採用しました。

メソッド呼び出しは、シーケンス図の呼び出しに似ています。ただし、シーケンス図との違いはオブジェクト構成を説明していませんが、コラボレーション図はオブジェクト構成を示しています。

これら2つの図から選択するには、要件のタイプに重点が置かれます。時系列が重要な場合は、シーケンス図が使用されます。編成が必要な場合は、コラボレーション図が使用されます。

相互作用図はどこで使用しますか？

相互作用図を使用してシステムの動的な性質を説明することについては、すでに説明しました。次に、これらの図が使用される実際のシナリオを調べます。実際のアプリケーションを理解するには、シーケンスとコラボレーション図の基本的な性質を理解する必要があります。

両方の図の主な目的は、システムの動的な動作をキャプチャするために使用されるため、類似しています。ただし、特定の目的は、明確にして理解するためにより重要です。

シーケンス図は、あるオブジェクトから別のオブジェクトに流れるメッセージの順序をキャプチャするために使用されます。コラボレーション図は、相互作用に参加するオブジェクトの構造的編成を説明するために使用されます。システム全体の動的な側面を説明するには、単一の図では不十分であるため、一連の図を使用してシステム全体をキャプチャします。

相互作用図は、メッセージの流れと構造的な構成を理解したい場合に使用されます。メッセージフローとは、あるオブジェクトから別のオブジェクトへの制御フローのシーケンスを意味します。構造的編成とは、システム内の要素の視覚的な編成を意味します。

相互作用図を使用できます-

時系列による制御の流れをモデル化する。
構造組織による制御の流れをモデル化する。
フォワードエンジニアリング用。
リバースエンジニアリング用。

ダイアグラム自体の名前は、ダイアグラムの目的およびその他の詳細を明確にします。システム内のコンポーネントのさまざまな状態を記述します。状態は、システムのコンポーネント/オブジェクトに固有です。

ステートチャート図は、ステートマシンを表しています。ステートマシンは、オブジェクトのさまざまな状態を定義するマシンとして定義でき、これらの状態は外部イベントまたは内部イベントによって制御されます。

次の章で説明するアクティビティ図は、特殊な種類のステートチャート図です。ステートチャート図は状態を定義するため、オブジェクトの存続期間をモデル化するために使用されます。

ステートチャート図の目的

ステートチャート図は、システムの動的な性質をモデル化するために使用される5つのUML図の1つです。それらは、オブジェクトの存続期間中のさまざまな状態を定義し、これらの状態はイベントによって変更されます。ステートチャート図は、リアクティブシステムをモデル化するのに役立ちます。リアクティブシステムは、外部または内部のイベントに応答するシステムとして定義できます。

ステートチャート図は、ある状態から別の状態への制御の流れを示しています。状態は、オブジェクトが存在し、何らかのイベントがトリガーされると変化する条件として定義されます。ステートチャート図の最も重要な目的は、オブジェクトの作成から終了までの存続期間をモデル化することです。

ステートチャート図は、システムのフォワードエンジニアリングとリバースエンジニアリングにも使用されます。ただし、主な目的は、リアクティブシステムをモデル化することです。

ステートチャート図を使用する主な目的は次のとおりです-

システムの動的な側面をモデル化すること。
リアクティブシステムの寿命をモデル化する。
オブジェクトの存続期間中のさまざまな状態を説明すること。
オブジェクトの状態をモデル化するステートマシンを定義します。

ステートチャート図を描く方法は？

ステートチャート図は、ライフサイクルにおけるさまざまなオブジェクトの状態を説明するために使用されます。いくつかの内部または外部のイベントによる状態変化に重点が置かれます。オブジェクトのこれらの状態は、それらを正確に分析および実装するために重要です。

ステートチャート図は、状態を説明するために非常に重要です。状態は、特定のイベントが発生したときのオブジェクトの状態として識別できます。

ステートチャート図を描く前に、次の点を明確にする必要があります。

分析する重要なオブジェクトを特定します。
状態を特定します。
イベントを特定します。

以下は、Orderオブジェクトの状態が分析されるステートチャート図の例です。

最初の状態は、プロセスが開始されるアイドル状態です。次の状態は、要求の送信、要求の確認、ディスパッチ順序などのイベントに到着します。これらのイベントは、注文オブジェクトの状態変化を担当します。

オブジェクト（ここではオーダーオブジェクト）のライフサイクル中に、次の状態になり、異常な終了が発生する場合があります。この異常終了は、システムの問題が原因で発生する可能性があります。次の図に示すように、ライフサイクル全体が完了すると、完全なトランザクションと見なされます。次の図には、オブジェクトの初期状態と最終状態も示されています。

ステートチャート図はどこで使用しますか？

上記の説明から、ステートチャート図の実際のアプリケーションを定義できます。ステートチャート図は、このチュートリアルで説明する他の4つの図と同様に、システムの動的な側面をモデル化するために使用されます。ただし、動的な性質をモデル化するためのいくつかの際立った特徴があります。

ステートチャート図はコンポーネントの状態を定義し、これらの状態変化は本質的に動的です。その特定の目的は、イベントによってトリガーされる状態変化を定義することです。イベントは、システムに影響を与える内部または外部の要因です。

ステートチャート図は、システムで動作している状態とイベントをモデル化するために使用されます。システムを実装する場合、オブジェクトの存続期間中のさまざまな状態を明確にすることが非常に重要であり、ステートチャート図がこの目的で使用されます。これらの状態とイベントが識別されると、それらはそれをモデル化するために使用され、これらのモデルはシステムの実装中に使用されます。

ステートチャート図の実際の実装を調べると、主にイベントの影響を受けるオブジェクトの状態を分析するために使用されます。この分析は、実行中のシステムの動作を理解するのに役立ちます。

主な使用法は次のように説明できます-

システムのオブジェクト状態をモデル化すること。
反応性システムをモデル化する。リアクティブシステムは、リアクティブオブジェクトで構成されています。
状態変化の原因となるイベントを特定するため。
フォワードエンジニアリングとリバースエンジニアリング。

アクティビティ図は、システムの動的な側面を説明するためのUMLのもう1つの重要な図です。

アクティビティ図は基本的に、あるアクティビティから別のアクティビティへのフローを表すフローチャートです。アクティビティは、システムの操作として説明できます。

制御フローは、ある操作から別の操作に引き出されます。このフローは、順次、分岐、または同時のいずれかになります。アクティビティ図は、フォーク、結合などのさまざまな要素を使用して、すべてのタイプのフロー制御を処理します

アクティビティ図の目的

アクティビティ図の基本的な目的は、他の4つの図と同様です。システムの動的な動作をキャプチャします。他の4つの図は、あるオブジェクトから別のオブジェクトへのメッセージフローを示すために使用されますが、アクティビティ図は、あるアクティビティから別のアクティビティへのメッセージフローを示すために使用されます。

アクティビティは、システムの特定の操作です。アクティビティ図は、システムの動的な性質を視覚化するために使用されるだけでなく、フォワードエンジニアリングおよびリバースエンジニアリングの手法を使用して実行可能システムを構築するためにも使用されます。アクティビティ図で欠落しているのはメッセージ部分だけです。

あるアクティビティから別のアクティビティへのメッセージフローは表示されません。アクティビティ図は、フローチャートと見なされる場合があります。ダイアグラムはフローチャートのように見えますが、そうではありません。並列、分岐、同時、単一などのさまざまなフローが表示されます。

アクティビティ図の目的は、次のように説明できます。

システムのアクティビティフローを描画します。
あるアクティビティから別のアクティビティへのシーケンスを説明します。
システムの並列、分岐、および並行フローについて説明します。

アクティビティ図を描く方法は？

アクティビティ図は、主にシステムによって実行されるアクティビティで構成されるフローチャートとして使用されます。アクティビティ図は、いくつかの追加機能があるため、正確にはフローチャートではありません。これらの追加機能には、分岐、平行流、スイムレーンなどが含まれます。

アクティビティ図を描く前に、アクティビティ図で使用される要素について明確に理解する必要があります。アクティビティ図の主な要素は、アクティビティ自体です。アクティビティは、システムによって実行される機能です。アクティビティを特定した後、それらが制約や条件にどのように関連付けられているかを理解する必要があります。

アクティビティ図を描く前に、次の要素を特定する必要があります-

Activities
Association
Conditions
Constraints

上記のパラメータが特定されたら、フロー全体のメンタルレイアウトを作成する必要があります。次に、このメンタルレイアウトはアクティビティ図に変換されます。

以下は、注文管理システムのアクティビティ図の例です。この図では、条件に関連付けられている4つのアクティビティが識別されています。重要な点の1つは、アクティビティ図をコードと正確に一致させることはできないことを明確に理解する必要があります。アクティビティ図は、アクティビティの流れを理解するために作成され、主にビジネスユーザーによって使用されます

次の図は、4つの主要なアクティビティで描かれています-

顧客による注文の送信
注文の受領
注文を確認する
注文を発送します

注文依頼を受け取った後、条件チェックを行い、通常注文か特別注文かを確認します。注文のタイプが識別された後、ディスパッチアクティビティが実行され、プロセスの終了としてマークされます。

アクティビティ図はどこで使用しますか？

アクティビティ図の基本的な使用法は、他の4つのUML図と同様です。具体的な使用法は、あるアクティビティから別のアクティビティへの制御フローをモデル化することです。この制御フローにはメッセージは含まれません。

アクティビティ図は、システムのアクティビティフローをモデル化するのに適しています。アプリケーションは複数のシステムを持つことができます。アクティビティ図は、これらのシステムもキャプチャし、あるシステムから別のシステムへのフローを説明します。この特定の使用法は、他の図では使用できません。これらのシステムは、データベース、外部キュー、またはその他のシステムにすることができます。

次に、アクティビティ図の実際のアプリケーションを調べます。上記の議論から、アクティビティ図が非常に高いレベルから描かれていることは明らかです。したがって、システムの高レベルのビューを提供します。この高レベルのビューは、主にビジネスユーザーまたは技術者ではないその他の人を対象としています。

この図は、ビジネス要件に他ならないアクティビティをモデル化するために使用されます。この図は、実装の詳細よりもビジネスの理解に大きな影響を与えます。

アクティビティ図は次の目的で使用できます-

アクティビティを使用したワークフローのモデリング。
ビジネス要件のモデリング。
システムの機能に関する高レベルの理解。
後の段階でビジネス要件を調査します。