Uml-quick-guide

UML-概要

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

UMLはObject Management Group（OMG）によって作成され、UML 1.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を学習する前に、OOの概念を詳細に理解することが重要になります。

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

• オブジェクト-オブジェクトは、エンティティと基本的な構成要素を表します。
• クラス-クラスはオブジェクトの青写真です。
• 抽象-抽象化は、実世界のエンティティの動作を表します。
• カプセル化-カプセル化は、データを結合するメカニズムであり、 それらを外の世界から隠します。
• 継承-継承は、既存のクラスから新しいクラスを作成するメカニズムです。
• ポリモーフィズム-さまざまな形式で存在するメカニズムを定義します。

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

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

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

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

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

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

OO Analysis → OO Design → OO implementation using OO languages

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

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

OOデザインにおけるUMLの役割

UMLは、ソフトウェアシステムと非ソフトウェアシステムのモデリングに使用されるモデリング言語です。 UMLは非ソフトウェアシステムに使用されますが、OOソフトウェアアプリケーションのモデリングに重点が置かれています。 これまでに説明したUML図のほとんどは、静的、動的などのさまざまな側面をモデル化するために使用されます。 アスペクトに関係なく、アーティファクトはオブジェクトに過ぎません。

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

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

UML-ビルディングブロック

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

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

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

• 物事
• 関係
• 図

物事

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

• 構造的
• 行動的
• グルーピング
• 注釈付き

構造的なもの

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

• クラス-*クラスは、同様の役割を持つオブジェクトのセットを表します。

クラス

• Interface-* Interfaceは、クラスの責任を指定する一連の操作を定義します。

インターフェース

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

コラボレーション

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

ユースケース

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

コンポーネント

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

ノード

行動的なもの

• 振る舞い*は、UMLモデルの動的な部分で構成されています。 以下は行動的なものです-

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

インタラクション

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

ステートマシン

グループ化

• グループ化*は、UMLモデルの要素をグループ化するメカニズムとして定義できます。 利用可能なグループ化は1つだけです-

• パッケージ-*パッケージは、構造的および動作的なものを収集するために使用できる唯一のグループ化されたものです。

パッケージ

注釈事項

注釈事項*は、UMLモデル要素の発言、説明、およびコメントをキャプチャするメカニズムとして定義できます。 *注-これは、利用可能な唯一の注釈事項です。 メモは、コメント、制約などを表示するために使用されます。 UML要素の

注

関係

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

使用可能な関係には4つの種類があります。

依存

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

依存関係

協会

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

関連付け

一般化

汎化は、特殊化された要素と汎用化された要素を接続する関係として定義できます。 基本的に、オブジェクトの世界における継承関係を記述します。

一般化

実現

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

実現

UML図

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

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

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

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

UML-アーキテクチャ

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

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

• 設計
• 実装
• プロセス
• 展開

中央は、これら4つすべてをつなぐ Use Case ビューです。 *ユースケース*は、システムの機能を表します。 したがって、他のパースペクティブはユースケースに関連しています。

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

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

• プロセス*は、システムのフローを定義します。 したがって、デザインで使用されているものと同じ要素が、このパースペクティブをサポートするためにも使用されます。

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

UML-モデリングタイプ

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

構造モデリング

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

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

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

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

行動モデリング

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

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

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

建築モデリング

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

UML-基本的な表記

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

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

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

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

構造的なもの

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

• クラス
• 対象
• インタフェース
• コラボレーション
• 使用事例
• アクティブなクラス
• コンポーネント
• ノード

クラス表記

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

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

クラス表記

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

オブジェクト表記

_object_は、クラスと同じ方法で表されます。 唯一の違いは、次の図に示すように下線が引かれた_name_です。

オブジェクト表記

オブジェクトはクラスの実際の実装であり、クラスのインスタンスとして知られています。 そのため、クラスと同じ使用法があります。

インターフェイス表記

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

インターフェース表記

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

コラボレーション表記

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

コラボレーション表記

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

ユースケース表記

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

ユースケース表記法

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

俳優記法

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

俳優表記法

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

初期状態表記

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

初期状態表記

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

最終状態表記

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

最終状態の表記法

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

アクティブなクラス表記

アクティブなクラスは、実線のクラスのように見えます。 アクティブクラスは通常、システムの同時動作を記述するために使用されます。

アクティブクラス表記法

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

コンポーネント表記

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

コンポーネント表記

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

ノード表記

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

ノード表記

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

行動的なもの

ダイナミックパーツは、UMLで最も重要な要素の1つです。 UMLには、ソフトウェアシステムと非ソフトウェアシステムの動的部分を表す強力な機能セットがあります。 これらの機能には、_interactions_および_state machines_が含まれます。

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

• シーケンシャル（シーケンス図で表される）
• Collaborative（コラボレーション図で表されます）

インタラクション表記

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

相互作用表記法

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

ステートマシン表記

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

ステートマシン表記法

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

グループ化

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

パッケージ表記

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

パッケージ表記

注釈事項

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

ノート表記

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

注記表記

関係

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

• 依存
• 協会
• 一般化
• 拡張性

依存関係表記

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

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

依存関係表記

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

協会表記

関連付けは、UMLダイアグラム内の要素がどのように関連付けられるかを示します。 簡単な言葉で言えば、インタラクションに参加している要素の数を表します。

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

関連付け表記

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

汎化表記

汎化は、オブジェクト指向の世界の継承関係を記述します。 親子関係です。

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

一般化表記法

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

拡張性表記

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

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

拡張性表記

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

UML-標準ダイアグラム

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

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

複雑なシステムを理解するには、何らかの図や図を作成するのが一番です。 これらの図は、理解に良い影響を与えます。 見てみると、ダイアグラムは新しい概念ではなく、さまざまな業界のさまざまな形で広く使用されていることがわかります。

システムをより良く簡単に理解するために、UMLダイアグラムを準備します。 単一の図では、システムのすべての側面をカバーするには不十分です。 UMLは、システムのほとんどの側面をカバーするさまざまな種類の図を定義します。

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

図の2つの広いカテゴリがあり、それらは再びサブカテゴリに分けられます-

• 構造図
• 行動図

構造図

構造図は、システムの静的な側面を表しています。 これらの静的な側面は、図のこれらの部分を表します。これらは主要な構造を形成し、したがって安定しています。

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

• クラス図
• オブジェクト図
• コンポーネント図
• 展開図

クラス図

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

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

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

オブジェクト図

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

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

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

コンポーネント図

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

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

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

配置図

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

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

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

行動図

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

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

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

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

ユースケース図

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

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

シーケンス図

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

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

コラボレーション図

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

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

ステートチャート図

リアルタイムシステムは、何らかの内部/外部イベントによって反応することが期待されています。 これらのイベントは、システムの状態変更を担当します。

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

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

アクティビティ図

アクティビティ図は、システムの制御の流れを説明しています。 アクティビティとリンクで構成されています。 フローは、順次、並行、または分岐のいずれかです。

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

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

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

UML-クラス図

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

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

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

クラス図の目的

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

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

クラス図の目的は次のように要約することができます-

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

クラス図の描き方

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

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

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

クラス図を描くとき、​​次の点を覚えておく必要があります-

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

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

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

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

UMLクラス図

クラス図の使用場所

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

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

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

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

一言で言えば、それは言うことができる、クラス図が使用されます-

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

UML-オブジェクト図

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

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

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

オブジェクト図の目的

図を実際に実装するには、図の目的を明確に理解する必要があります。 オブジェクト図の目的は、クラス図に似ています。

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

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

オブジェクト図の目的は次のように要約することができます-

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

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

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

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

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

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

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

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

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

この後、図の構築を開始する前に、次のことを決定する必要があります-

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

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

• 顧客
• 注文
• 特別注文
• 通常注文

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

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

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

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

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

UMLオブジェクト図

オブジェクト図の使用場所

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

さて、実行中の列車のスナップを撮ると、次のような静的な写真が見つかります-

• 実行中の特定の状態。
• 乗客の特定の数。 別の時間にスナップを撮ると変化します

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

一言で言えば、オブジェクト図が使用されていると言うことができます-

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

UML-コンポーネント図

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

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

コンポーネント図の目的

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

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

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

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

コンポーネント図の目的は次のようにまとめることができます-

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

コンポーネント図の作成方法

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

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

最初に、システムは異なるUML図を使用して設計され、その後、成果物の準備ができたら、コンポーネント図を使用して実装のアイデアを取得します。

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

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

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

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

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

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

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

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

UMLコンポーネント図

コンポーネント図の使用場所

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

これらの図は、システムの物理コンポーネントを示しています。 それを明確にするために、コンポーネント図はシステム内のコンポーネントの組織を記述すると言うことができます。

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

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

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

コンポーネント図を使用することができます-

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

UML-配置図

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

展開図は、システムの静的な展開ビューを記述するために使用されます。 展開図は、ノードとその関係で構成されます。

配置図の目的

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

コンポーネント図はコンポーネントの説明に使用され、配置図はハードウェアでの配置方法を示します。

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

ほとんどのUML図は論理コンポーネントの処理に使用されますが、展開図はシステムのハードウェアトポロジに焦点を当てるために作成されます。 展開図は、システムエンジニアが使用します。

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

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

展開図の作成方法

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

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

• パフォーマンス
• スケーラビリティ
• 保守性
• 移植性

配置図を描く前に、次のアーティファクトを特定する必要があります-

• ノード
• ノード間の関係

以下は、注文管理システムの展開ビューのアイデアを提供するサンプル展開図です。 ここでは、ノードを次のように示しています-

• モニター
• モデム
• キャッシュサーバー
• サーバ

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

上記のすべてのポイントを考慮して、次の展開図を作成しました。

UML展開図

配置図の使用場所

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

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

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

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

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

展開図を使用することができます-

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

UML-ユースケース図

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

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

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

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

ユースケース図の目的

ユースケース図の目的は、システムの動的な側面を把握することです。 ただし、他の4つの図（アクティビティ、シーケンス、コラボレーション、およびステートチャート）も同じ目的を持つため、この定義は目的を説明するには一般的すぎます。 他の4つの図と区別するために、特定の目的を検討します。

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

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

簡単に言えば、ユースケース図の目的は次のように言うことができます-

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

ユースケース図の作成方法

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

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

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

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

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

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

以下は、注文管理システムを表すサンプルユースケース図です。 したがって、ダイアグラムを調べると、3つのユースケース*（Order、SpecialOrder、およびNormalOrder）*と、顧客である1つのアクターが見つかります。

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

UMLユースケース図

ユースケース図の使用場所

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

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

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

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

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

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

ユースケース図を使用することができます-

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

UML-相互作用図

相互作用という用語から、ダイアグラムがモデル内のさまざまな要素間の相互作用のあるタイプを記述するために使用されていることは明らかです。 この相互作用は、システムの動的な動作の一部です。

このインタラクティブな動作は、UMLでは*シーケンス図*および*コラボレーション図*と呼ばれる2つの図で表されます。 両方の図の基本的な目的は似ています。

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

相互作用図の目的

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

シーケンス図とコラボレーション図は、動的な性質を異なる角度からキャプチャするために使用されます。

相互作用図の目的は-

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

相互作用図の作成方法

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

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

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

• 相互作用に参加するオブジェクト。
• オブジェクト間でメッセージが流れます。
• メッセージが流れる順序。
• オブジェクト編成。

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

シーケンス図

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

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

最初の呼び出しは、_Order object_のメソッドである_sendOrder（）_です。 次の呼び出しは、_SpecialOrder_オブジェクトのメソッドである_confirm（）_です。最後の呼び出しは、_SpecialOrder_オブジェクトのメソッドである_Dispatch（）_です。 次の図は、1つのオブジェクトから別のオブジェクトへのメソッド呼び出しを主に説明しています。これは、システムが実行されているときの実際のシナリオでもあります。

UMLシーケンス図

コラボレーション図

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

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

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

UMLコラボレーション図

相互作用図の使用場所

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

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

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

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

相互作用図を使用することができます-

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

UML-ステートチャート図

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

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

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

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

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

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

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

以下は、ステートチャート図を使用する主な目的です-

• システムの動的な側面をモデル化するため。
• リアクティブシステムの寿命をモデル化する。
• ライフタイム中のオブジェクトのさまざまな状態を記述するため。
• 状態マシンを定義して、オブジェクトの状態をモデル化します。

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

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

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

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

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

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

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

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

UMLステートチャート図

ステートチャート図の使用場所

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

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

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

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

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

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

UML-アクティビティ図

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

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

制御フローは、ある操作から別の操作に描画されます。 このフローは、シーケンシャル、ブランチ、またはコンカレントです。 アクティビティ図は、フォーク、結合などのさまざまな要素を使用して、すべてのタイプのフロー制御を処理します

アクティビティ図の目的

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

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

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

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

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

アクティビティ図の作成方法

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

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

活動図を描く前に、次の要素を特定する必要があります-

• アクティビティ
• 協会
• 条件
• 制約

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

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

次の図は、4つの主要な活動で描かれています-

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

注文リクエストを受け取った後、通常の注文か特別注文かを確認する条件チェックが実行されます。 注文の種類が特定されると、ディスパッチアクティビティが実行され、プロセスの終了としてマークされます。

UMLアクティビティ図

アクティビティ図の使用場所

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

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

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

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

アクティビティ図を使用することができます-

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

UML 2.0-概要

UML 2.0は、統一モデリング言語の世界ではまったく異なる次元です。 本質的にはより複雑で広範なものです。 ドキュメントの範囲も、UML 1.5バージョンと比較して増加しています。 UML 2.0には新しい機能が追加されているため、その使用方法はより広範囲になります。

UML 2.0は、正式で完全に定義されたセマンティクスの定義を追加します。 この新しい可能性はモデルの開発に利用でき、対応するシステムはこれらのモデルから生成できます。 しかし、この新しい次元を活用するには、知識を獲得するためにかなりの努力が必要です。

UML 2.0の新しい次元

UML 2.0の最新バージョンでは、UMLの構造とドキュメントが完全に改訂されました。 UMLを説明する2つのドキュメントが利用可能になりました-

• UML 2.0インフラストラクチャは、UMLのベースとなる言語の基本的な構成要素を定義します。 このセクションは、UMLのユーザーには直接関係ありません。 これは、モデリングツールの開発者向けです。 この領域はこの範囲内ではありません チュートリアル。
• UML 2.0上部構造は、UML 2.0のユーザー構成を定義します。 これは、ユーザーが即時レベルで使用するUMLの要素を意味します。 これは、UMLのユーザーコミュニティの主な焦点です。

このUMLの改訂は、使いやすさ、実装、および適応が簡素化されるように、UMLを再構築および改良するという目標を達成するために作成されました。

UMLインフラストラクチャを使用して-

• 再利用可能なメタ言語コアを提供します。 これは、UML自体を定義するために使用されます。
• 言語を調整するメカニズムを提供します。

UML上部構造はに使用されます-

• コンポーネントベースの開発のサポートを改善します。
• アーキテクチャの仕様の構造を改善します。
• 動作のモデリングのためのより良いオプションを提供します。

注意すべき重要な点は、上記の主要な区分です。 これらの区分は、UMLの使いやすさを高め、その使用法の明確な理解を定義するために使用されます。

この新しいバージョンで既に提案されている別の次元があります。 これは、まったく新しいオブジェクト制約言語（OCL）とダイアグラム交換の提案です。 これらの機能はすべて完全なUML 2.0パッケージを形成します。

UML 2.0でのモデリング図

相互作用のモデリング

UML 2.0で説明されている相互作用図は、以前のバージョンとは異なります。 ただし、基本的な概念は以前のバージョンと同じままです。 主な違いは、UML 2.0の図に追加された機能強化と追加機能です。

UML 2.0は、次の4つの異なる方法でオブジェクトの相互作用をモデル化します。

• *シーケンス図*は、システムの動作目標を達成するためのオブジェクト間の相互作用の時間依存ビューです。 時間シーケンスは、シーケンス図の以前のバージョンに似ています。 相互作用は、サブシステムの相互作用からインスタンスレベルまで、システム設計内の任意の抽象化レベルで設計できます。
• *通信図*は、UML 2.0で追加された新しい名前です。 コミュニケーション図は、オブジェクト間のメッセージングの構造図であり、UML 1.4およびそれ以前のバージョンのコラボレーション図の概念から取ったものです。 これは、コラボレーション図の修正版として定義できます。
• *相互作用の概要図*は、UML 2.0の新しい追加機能です。 インタラクションの概要図は、インタラクション間を移動するフロー制御ロジックを含む、ロジックシーケンスに結合されたインタラクションのグループの高レベルのビューを示します。
• *タイミング図*もUML 2.0に追加されました。 これは、対話の過程で送受信されるメッセージの時間制限を指定するために設計されたオプションの図です。

上記の説明から、すべての図の目的はメッセージの送受信であることに注意することが重要です。 これらのメッセージの処理は、オブジェクトの内部にあります。 そのため、オブジェクトにはメッセージを送受信するオプションもあり、インターフェイスと呼ばれるもう1つの重要な側面があります。 現在、これらのインターフェースは、相互にメッセージを送受信する役割を担っています。

したがって、UML 2.0の相互作用は別の方法で記述されていると結論付けることができ、それが新しいダイアグラム名が登場した理由です。 新しい図を分析すると、すべての図が以前のバージョンで説明した相互作用図に基づいて作成されていることは明らかです。 唯一の違いは、UML 2.0で追加された機能で、図をより効率的で目的指向にします。

コラボレーションのモデリング

すでに説明したように、コラボレーションはオブジェクト間の一般的な相互作用をモデル化するために使用されます。 コラボレーションは、一連のメッセージが事前に定義された役割を持つ一連のオブジェクトによって処理される相互作用であると言えます。

重要な点は、以前のバージョンとUML 2.0バージョンのコラボレーション図の違いです。 区別するために、コラボレーション図の名前はUML 2.0で変更されました。 UML 2.0では、 Communication diagram として名前が付けられています。

したがって、コラボレーションは、属性（プロパティ）と動作（操作）を持つクラスとして定義されます。 コラボレーションクラスのコンパートメントはユーザー定義でき、相互作用（シーケンス図）および構造要素（複合構造図）に使用できます。

次の図は、オブザーバブルとしてのオブジェクトと、オブザーバーとしての任意の数のオブジェクトとの間のコラボレーションとして、オブザーバーの設計パターンをモデル化しています。

コラボレーション図

コミュニケーションのモデリング

コミュニケーション図は、以前のバージョンのコラボレーション図とわずかに異なります。 これは、以前のUMLバージョンの縮小バージョンであると言えます。 コミュニケーション図の特徴的な要素は、オブジェクト間のリンクです。

これは視覚的なリンクであり、シーケンス図にはありません。 シーケンス図では、オブジェクト間にリンクがない場合でも、オブジェクト間で渡されるメッセージのみが表示されます。

コミュニケーション図は、オブジェクト図形式をメッセージングの基礎として使用することにより、モデラーがこの間違いを防ぐために使用されます。 コミュニケーション図の各オブジェクトは、オブジェクトライフラインと呼ばれます。

コミュニケーション図のメッセージタイプは、シーケンス図と同じです。 コミュニケーション図は、同期、非同期、リターン、ロスト、ファウンド、オブジェクト作成メッセージをモデル化できます。

次の図は、コミュニケーション図の基礎となる3つのオブジェクトと2つのリンクを持つオブジェクト図を示しています。 コミュニケーション図の各オブジェクトは、オブジェクトライフラインと呼ばれます。

通信図

相互作用のモデリングの概要

実際の使用では、シーケンス図を使用して単一のシナリオをモデル化します。 多数のシーケンス図を使用して、アプリケーション全体を完成させます。 したがって、単一のシナリオをモデル化する際に、全体のプロセスを忘れることがあり、これによりエラーが発生する可能性があります。

この問題を解決するために、新しい相互作用の概要図は、アクティビティ図の制御フローとシーケンス図のメッセージング仕様を組み合わせています。

アクティビティ図では、アクティビティとオブジェクトフローを使用してプロセスを記述します。 相互作用の概要図では、相互作用と相互作用の発生を使用しています。 シーケンス図にあるライフラインとメッセージは、インタラクションまたはインタラクションオカレンス内でのみ表示されます。 ただし、インタラクションの概要図に参加しているライフライン（オブジェクト）は、図名とともにリストされる場合があります。

次の図は、決定のひし形、フレーム、および終了ポイントを含む相互作用の概要図を示しています。

相互作用図

タイミング図のモデリング

この図自体の名前は、図の目的を説明しています。 基本的には、ライフサイクル全体にわたるイベントの時間を扱います。

したがって、タイミング図は、オブジェクトのライフタイム中のイベントに焦点を当てるために作成された特別な目的の相互作用図として定義できます。 基本的には、ステートマシンと相互作用図が混在しています。 タイミング図は、次のタイムラインを使用しています-

• 州のタイムライン
• 一般的な値のタイムライン

タイミング図のライフラインは、フレームのコンテンツ領域内に長方形のスペースを形成します。 通常、左から右に読むために水平に配置されます。 同じフレーム内に複数のライフラインを積み重ねて、それらの間の相互作用をモデル化できます。

タイミング図

概要

UML 2.0は、新しい機能が追加され、より使いやすく効率的になる拡張バージョンです。 UML 2.0には2つの主要なカテゴリがあります。1つはUMLのスーパー構造で、もう1つはUMLインフラストラクチャです。 新しい図は古い概念に基づいていますが、まだいくつかの追加機能があります。

UML 2.0は、シーケンス図、通信図、相互作用概要図、オプションのタイミング図の4つの相互作用図を提供します。 4つの図はすべて、フレーム表記を使用して相互作用を囲みます。 フレームを使用すると、インタラクションの発生としてインタラクションを再利用できます。

UML-知識テスト

この章では、このチュートリアルで学習したUMLの概念に関する簡単な質問をリストします。 与えられた一連の質問に基づいて、UMLの専門家になるための自信を築くために自分を評価できます。

• クラス図はシステムの動的な振る舞いを示すことができますか？
• 展開図をフォワードエンジニアリングとリバースエンジニアリングに使用できますか？
• フォワードエンジニアリングとリバースエンジニアリングに使用できますか？
• アクティビティの並行フローを表すことができますか？
• ステートチャート図をアクティビティ図に変換できますか？
• コンポーネント図でフォワードエンジニアリングを使用できますか？
• ユースケース図をフォワードエンジニアリングとリバースエンジニアリングに使用できますか？
• ユースケース図の目的を説明してください
• オブジェクト指向の概念はどのようにUMLと関連していますか？
• コンポーネント図はシステムの動的なビューを表していますか？
• UMLの主要な構成要素に名前を付けますか？
• オブジェクト図が使用されるいくつかのシナリオに名前を付けますか？
• ステレオタイプの3つのメカニズムに名前を付けますか？
• 配置図の成果物は何ですか？
• コンポーネント図の作成に使用されるアーティファクトは何ですか？
• 異なるUML図とは何ですか？
• ユースケース図のさまざまな要素は何ですか？
• UMLで使用されるさまざまなモデリングとは何ですか？
• オブジェクト図の要素は何ですか？
• UMLの目標は何ですか？
• 配置図の主な用途は何ですか？
• 行動に使用される表記法は何ですか？
• 関係で使用される表記法は何ですか？
• 構造的なもので使用される表記法は何ですか？
• システムの動的な動作をキャプチャするためにUMLで使用される他の4つの図は何ですか？
• 構造図と動作図とは何ですか？
• シーケンス図とコラボレーション図の使用法は何ですか？
• システムの動的な挙動とはどういう意味ですか？
• オブジェクト図は何をキャプチャしますか？
• オブジェクト指向分析とは何ですか？
• オブジェクト指向デザインとは何ですか？
• ステートチャート図とは何ですか？
• クラス図とは何ですか？
• 制約ルールとは何ですか？
• 配置図とは何ですか？
• ノードとは何ですか？
• リアクティブシステムとは何ですか？
• 状態とは何ですか？
• ユースケース図とは何ですか？
• アクティビティ図とは何ですか？
• イベントとは何で、オブジェクトの状態にどのように影響しますか？
• 相互作用図とは何ですか？
• オブジェクト図とは何ですか？
• コラボレーション図とは何ですか？
• コンポーネント図とは何ですか？
• 構成と集約とは何ですか？
• 分析と設計の違いは何ですか？
• 汎化とは何ですか？
• 同型とはどういう意味ですか？
• オブジェクトの責任は何ですか？
• オブジェクト指向の分析と設計におけるUMLの役割は何ですか？
• シーケンス図とは何ですか？
• システムの静的および動的ビューとは何ですか？
• 構造図とは何ですか？
• クラス図とオブジェクト図の違いは何ですか？
• フローチャートとアクティビティ図の違いは何ですか？
• 集約と構成の違いは何ですか？
• シーケンス図とコラボレーション図の違いは何ですか？
• UMLで使用される相互作用図は何ですか？
• ステートチャート図の主な用途は何ですか？
• アクティビティ図の主な用途は何ですか？
• UMLで利用できる唯一のグループ化は何ですか？
• 概念モデルが重要な理由
• なぜステートチャート図を使用したのですか？

UML-ツールとユーティリティ

このページにウェブサイト、本、その他のリソースをリストアップしたい場合は、webmaster @ finddevguides.comまでご連絡ください。

• StarUML-StarUMLは、Win32プラットフォームで実行される、高速で、柔軟で、拡張可能で、機能が豊富で、自由に利用できるUML/MDAプラットフォームを開発するためのオープンソースプロジェクトです。
• ArgoUML-ArgoUMLは、主要なオープンソースUMLモデリングツールであり、すべての標準UML図のサポートが含まれています。
• Umbrello UML Modeller-Umbrello UML Modellerは、KDE用の統合モデリング言語ダイアグラムプログラムです。
• Acceleo-Acceleoは簡単に使用できます。 _off the shelf_ジェネレーター（JEE、.Net、Php …​）およびEclipse用のテンプレートエディターを提供します。
• UML Tools List @ Wiki-UMLツールとユーティリティの包括的なリスト。
• https://www.genmymodel.com [GenMyModel]-オンラインUMLモデリングツール