UML – 総合ガイド
UMLとは何ですか？
UMLは、オブジェクト指向手法のための標準的な表記法であり、オブジェクトモデリング技法を統合して作成されました。システムの分析、設計、展開に使用されます。統合モデリング言語は、ソフトウェアの生産を自動化し、品質を向上させ、コストと市場投入までの時間を削減するビジネスのニーズに応えるために設計されました。また、モデリング言語を理解するための形式的な基盤を提供します。
なぜUMLなのか？
大規模な企業向けアプリケーションは、スケーラビリティ、セキュリティ、ストレス状態下での堅牢な実行を可能にするように構造化される必要があります。良好に設計されたアーキテクチャはコードの再利用を可能にし、保守担当者が元の開発者が他のプロジェクトに移った後も長期間経って発生するバグを発見・修正できるようにします。モデリングは大規模なソフトウェア開発プロジェクトにとって不可欠であり、中規模および小規模プロジェクトにも役立ちます。モデルにより、ビジネス機能が完全かつ正確であることが保証され、エンドユーザーのニーズが満たされ、スケーラビリティ、堅牢性、セキュリティ、拡張性、その他の特性を満たすプログラム設計が実現されます。
- モデルは、詳細を隠蔽またはマスキングすることで、より高い抽象度で作業を可能にし、全体像を浮き彫りにしたり、プロトタイプの異なる側面に注目したりします。
- UMLは、あらゆる種類のハードウェア、オペレーティングシステム、プログラミング言語、ネットワーク上で実行されるあらゆる種類のアプリケーションをモデル化できます。また、オブジェクト指向ではないアプリケーションのモデリングにも使用できます。
- 一部のツールは既存のソースコード（あるいは、一部の主張ではオブジェクトコード！）を分析し、それを一連のUML図に逆工程化します。一方、他のツールはUMLモデルを実行し、通常、コードジェネレータがベストプラクティスに基づくスケーラブルなパターンを組み込んでいる場合、高速に実行可能なプログラム言語コードを生成します。
- アプリケーションの要件を収集・分析し、それをプログラム設計に組み込むプロセスは複雑です。UMLは、分析や設計の結果を表現できる言語です。
どこから来たのか？
UMLは1980年代後半から1990年代初頭に開発されたオブジェクト指向プログラミング手法に由来しています。ジム・ルンバウ、グレイディ・ブーチ、イヴァル・ヤコブソンがそれぞれのアイデアを統合し、統合手法（Unified Method）を構築しました。その後、これは統合モデリング言語（UML）と呼ばれるようになりました。オブジェクト管理グループ（OMG）が発行した最初の提案要請（RFP）が、複数の組織が共同でRFPへの対応を進めるきっかけとなりました。RFPへの対応として発表されたUML 1.0は、明確で表現力に富み、強力かつ一般的に適用可能であり、1.1から1.5へと改良され、その後2001年から2006年にかけてUML 2.1へと進化しました（現在のUMLの最新バージョンは2.5です）
UMLの利点
UMLを使用する最大の利点は、図のコードが、プログラムのわずかな部分しか理解していなくても、どのプログラマーにも容易に読めるということです。
- UMLはプログラムを視覚的に記述するために使用される標準です。広く使用され、プログラムの概要を記述する言語として広く受け入れられています。
- UML図は、コンピュータプログラム内のクラスやエンティティ間の関係を示します。図を見ることで、プログラムの関係性を簡単に理解できます。
- UML図は、プログラム内の関係を直感的に説明し、既存のコードの一部を再利用することで、関数を再記述する必要を減らすことができます。
- UMLはオブジェクト指向プログラミング言語における現在の標準です。プログラミングを行う前にプログラムを計画するのを助け、コードを生成モデルで設定されたクラスに基づいてコードを生成します。
UML図とモデル – 構造と振る舞い
UML図は、システムのコンポーネントが他のコンポーネントとどのように相互作用するか、そしてどのように動作するかを示します。UMLモデルはシステムモデルの完全なグラフィカルな表現であり、図は部分的な表現です。
静的視点と動的視点
静的モデリングは、オブジェクト、属性、操作、関係性を使ってシステムの構造を示すのに対し、動的モデリングは、オブジェクト間の協働やオブジェクトの内部状態の変化を使ってシステムの振る舞いを示します。
- 構造図はソフトウェアシステムの静的側面を表します。ソフトウェアシステムのソフトウェアアーキテクチャを文書化するために使用されます。
- 行動図はシステムの動的側面を記述します。ソフトウェアシステムの機能を記述するために使用されます。
UML図の14種類
UML 2.2には14種類の図そのうち7つは構造情報、残り7つは相互作用の一般的な側面を表しています。
構造図
構造図は構造を表すため、ソフトウェアシステムのソフトウェアアーキテクチャを文書化するために広く使用されます。構造図はシステム内の要素の静的構造を示します。UMLの7つの構造図は、システムをモデル化する際に見つかる主要なグループのものに基づいて大まかに整理されています。
たとえば、コンポーネント図はソフトウェアシステムがコンポーネントにどのように分割されているかを記述し、これらのコンポーネント間の依存関係を示します。
| 構造的 図 | 簡単な説明 |
| 複合構造図 | 分類子の内部構造、ポートを通じた分類子と環境との相互作用、または協働の動作を示します。 |
| 配置図 | ノードとその関係の集合を示し、アーキテクチャの静的配置ビューを示します。 |
| パッケージ図 | 関連するUML要素を論理的に関連するUML構造の集まりにグループ化します。 |
| プロファイル図 | |
| クラス図 | クラス、インターフェース、協働関係およびそれらの関係を示し、オブジェクト指向システムのモデル化で一般的に見られるものです。 |
| オブジェクト図 | オブジェクトとそれらの関係を示し、クラス図に見られるもののインスタンスの静的スナップショットです。 |
| コンポーネント図 | コンポーネントとそれらの関係を示し、システムの静的実装ビューを示します。 |
行動図
UMLの5つの行動図はシステムの動作をモデル化するために使用されます。データがシステム内でどのように移動するか、オブジェクトがどのように相互に通信するか、時間の経過がシステムにどのように影響するか、そしてどのようなイベントがシステムの内部状態の変化を引き起こすかを示します。
| 行動的 図 | 簡単な説明 |
| アクティビティ図 | 選択、反復、並行性をサポートする段階的な活動やアクションのワークフローの図式表現です |
| ユースケース図 | システムの機能要件を、システムがその要件をどのように満たすかを関連付けることができるユースケースの観点から記述します。 |
| 状態機械図 | 有限状態遷移を通じて、設計されたシステムの一部の離散的な動作を示します。 |
| シーケンス図 | シナリオの機能を実行するために必要なオブジェクト間で交換されるメッセージの順序を示します。 |
| 通信図 | 自由な配置で順序付きメッセージを使用して、オブジェクトおよび/または部品（ライフラインとして表現）間の相互作用を示します。 |
| 相互作用概要図 | 他のノードを含むことができるノードを用いた制御フローを描画します相互作用図. |
| タイミング図 | 時間軸に沿ってライフライン内およびライフライン間で変化する条件に注目し、時間についての推論を目的とする場合に、相互作用を示します。 |
1. クラス図
A クラス図アプリケーションの静的ビューを示し、実行可能なソフトウェアコードの構築を支援します。属性、クラス、関数、関係性を示し、ソフトウェアシステムの概要を提供します。アプリケーションの静的ビューを構築するために使用されます。オブジェクトモデル図は、コーディングの前にアプリケーションの一般的な概略を提供することで、保守時間を短縮できます。
システムの複雑さに応じて、単一のクラス図で全体のシステムをモデル化することも、複数のクラス図でシステムの構成要素をモデル化することもできます。クラス図はオブジェクトモデリングプロセスの基盤であり、システムの静的構造をモデル化します。分析段階では、クラス図は問題領域の要件を理解し、その構成要素を特定するのに役立ちます。
The クラス図クラス図はオブジェクト指向モデリングの主要な構成要素です。クラス、その属性、操作、オブジェクト間の関係性を示すことで、オブジェクト指向システムの構造を示します。上部のコンパートメントにはクラス名が含まれ、中央のコンパートメントには属性が、下部のコンパートメントには操作が含まれます。
関係性は関連線の中央に記述されます。関係性を読み取る方向を示すために、小さな矢印頭が付くことが多いです。関係性におけるオブジェクトの多重度は、次のように表されます：正確に1つ、0つ、1つ、多数、1つ以上。
- クラスはオブジェクトの設計図であり、オブジェクト指向設計のポイントはオブジェクトそのものではなく、クラスにあります。なぜなら、私たちはクラスを使ってオブジェクトを作成するからです。
- 視点の選択は、開発プロセスの進行度に依存します。分析モデルは、概念的視点と仕様的視点の両方を含んでいます。
- UMLのクラス関係は、図からコードをどのように実装すべきかを伝えるために使用されます。正確に解釈された場合、実装されたコードはデザイナーの意図を正確に反映します。
- 関連は、2つのクラスを結ぶ線で表されます。各端では、所有権、その端の要素が果たす役割、インスタンスの多重度を示すことができます。
- 一般化は2つのクラス間の関係です。特定クラスの各インスタンスは、一般クラスの間接的なインスタンスでもあります。
- 集約は、部分-全体または部分-もの関係を表す関連の一種です。これは、包含クラス上に空のダイヤモンド型を描き、それを包含されるクラスに結ぶ単一の線で視覚的に表現できます。
- あるクラスのオブジェクトが別のクラスのオブジェクトを使用する場合、依存関係が存在します。
- 抽象クラスは、クラス間で共通する機能を表現するために使用され、その名前は斜体で記述されます。
2. オブジェクト図
オブジェクトは、実行時における特定の時点でのクラスのインスタンスであり、オブジェクト図は、ある時点におけるシステムの詳細な状態を示します。データ構造の例を示すために使用され、クラス図はその正確性と完全性を検証するために使用されます。オブジェクト図.
（Visual Paradigm (Desktop) の オブジェクト図ツールで作成）
- オブジェクト図は、システム内のオブジェクト間の関係を示し、複雑なシステムのクラス図を説明するために使用できます。
- UMLでは、オブジェクト図はモデル内の分類子のインスタンスとその関係を示します。クラス図、配置図、コンポーネント図、ユースケース図のモデル要素をインスタンス化することで、オブジェクト図を作成できます。
- オブジェクト図を作成するには、システムを構成するメカニズムを特定し、そのメカニズムに参加するクラス、インターフェース、その他の要素を特定し、それらの間の関係を特定する必要があります。
- オブジェクト図は、特定の時点におけるオブジェクトの状態を示すために使用できます。
3. コンポーネント図
A コンポーネント図は、大きなオブジェクト指向システムをより小さなコンポーネントに分割するために使用されます。システム内のコンポーネント間の関係および組織を可視化します。コンポーネント図は、ソフトウェアシステムの論理的コンポーネントとその関係を表したものであり、システムの静的実装ビューです。通常、コンポーネントの可視化、実行可能ファイルの構築、コンポーネントの組織と関係の記述に使用されます。
- The コンポーネント図は、コンポーネントの提供されるインターフェースと必要なインターフェースを示します。
- コンポーネントは、システムのモジュール化された部分です。縦方向にスタックされたオプションのコンパートメントを持つ長方形として描かれます。
- ラッキーロールまたはソケットは、コンポーネントからインターフェースへの依存関係を示すために使用され、半円は、コンポーネントから必要なインターフェースへの依存関係を示すために使用されます。
4. 配置図
配置図は、実行時システムの構造およびソフトウェアが配置される異なるハードウェアアイテム間の通信経路を示します。配置図は、システム内のノード間の関係を示す頂点と弧の集合です。システムエンジニアがパフォーマンス、スケーラビリティ、保守性、移植性を制御するために役立ちます。
配置図は、ソフトウェアアーティファクトを配置先に配置することとして、システムのアーキテクチャを示します。これらは、仕様レベル（別名：タイプレベル）またはインスタンスレベル（クラス図やオブジェクト図と同様）のいずれかです。
配置図 vs コンポーネント図
- 配置図は、システム内でソフトウェアコンポーネントを配置するために使用されるハードウェアコンポーネントを記述するために使用されます。
- コンポーネント図は、システムのソフトウェアアーティファクトを記述するために使用され、配置図は、システムのハードウェアトポロジーを記述するために使用されます。
5. パッケージ図
パッケージは、複雑なシステムの高レベルなシステム要素を整理するために、意味的に関連する要素をグループ化するために使用されます。A パッケージ図は、要素をグループ化し、それらの相互依存関係を定義するためのパターンです。これらはモデル要素やコンポーネントを一貫性のある単位やシステムに分離します。これらの図は、システムのアクセス制御、モデルのナビゲーション、構成管理、その他の意味的考慮事項を簡素化します。
- パッケージはフォルダ記号で示され、モデルは右上隅に三角形で示されます。
- パッケージ図は、ネストされたパッケージの階層構造に従います。たとえば、パッケージ図は使用ケースを論理的に関連するサブシステムにグループ化することもできます。
- パッケージA内の任意のクラスがパッケージB内の任意のクラスに依存する場合、または2つのクラスの間にクライアント-サーバ関係が存在する場合、2つのパッケージの間に依存関係が存在します。
- パッケージ図は、パッケージ間の依存関係を指定できるようにします。依存関係は破線の矢印でモデル化されます。
- パッケージインポート関係は、ターゲットパッケージからソースパッケージへ要素をインポートすることとして解釈されます。
- パッケージマージは、2つのパッケージ間の有向関係です。これは、ターゲットパッケージの特性をソースパッケージの特性に追加します。
- パッケージは他のモデル要素のコンテナです。パッケージは階層的にネストでき、コンテナを削除またはコピーしても、含まれる要素は削除されません。
6. コンポジット構造図
UMLモデルにおいて、コンポジット構造図は、部品、ポート、接続子を使用して、構造化分類子の内部構造を示します
（Visual Paradigm (Desktop) のコンポジット構造図ツール)
-
部品：コンテナとなる構造化分類子が所有する1つ以上のインスタンスの集合を表す図要素
- 接続子はポートを結合し、協働はインスタンスを結合し、構造化分類子は部品間の相互作用によって記述できるクラスを表し、封入分類子はポートを含みます。
-
ポート：分類子インスタンスとその環境の間、または分類子の振る舞いとその内部部品の間の相互作用ポイントを定義します
- インターフェース：クラスとしてモデル化できますが、インスタンス化されません。具体的なクラスはインターフェースを実装しなければならず、外部エンティティは内部実装を気にせずにインターフェースを使用できます。
-
協働：協働の特定の目的を達成するために必要な役割と接続のみを定義するために、協働利用を使用します
クラス図 vs オブジェクト図 vs コンポジット構造図
- クラス図は、複雑な構造を構成するクラス間の関係を示しますが、オブジェクト図はその構造の特定のインスタンスを示します。
- コンポジット構造図は、コンポーネントどうしがどのように相互作用するかを示します。
7. プロファイル図
UMLは汎用的なモデリング言語です。しかし、ある状況では、特定のドメインに最適化された言語が有利です。プロファイル図特定のドメインやプラットフォーム向けにUMLモデルをカスタマイズできる。これらの図は、スタereotype、タグ付き値の定義、制約を使用して定義される。
AUMLプロファイル以下の3つの方法で作成できる：新しいメタモデルを作成する、既存のメタモデルを拡張する、または言語固有のメカニズムを使用する。
- スタereotypeを使用すると、新しい構成要素を定義することでUMLの語彙を拡張でき、それらは基本的な見た目を持ち、ドメインの言語を話すことができる。
- タグ付き値は、UMLモデル要素に情報を追加するために使用される。コード生成、バージョン管理、構成管理、著者情報などに利用できる。
- 制約を使用すると、新しいプロトコルを追加することでUMLの構成要素の意味を拡張できる。これらは、関連する要素の近くに括弧で囲まれた文字列として表示される。
振る舞い図
UMLの振る舞い図は、システムの動的側面を可視化、指定、構築、文書化する。振る舞い図は以下の通りに分類される：ユースケース図、インタラクション図、状態図、アクティビティ図。
1. ユースケース図
ユースケース図ソフトウェアプログラムの振る舞いを視覚的に表現するものである。外部から見えるシステムの振る舞いを指定することで、設計者がシステムの振る舞いをユーザーに伝えるのを助ける。ユースケースはシステムの機能要件のみを表す。ビジネスルール、サービス品質要件、実装制約は別途表現する必要がある。ユースケース図は、システム内の個人の役割を記述するために使用される。要件計画、ハードウェア設計の検証、ソフトウェア製品のテスト、オンラインヘルプリファレンスの作成などに利用できる。
ユースケースモデリングは1986年にイヴァル・ヤコブソンによって導入された。1992年に彼の著書『オブジェクト指向ソフトウェア工学』がこの手法を広めた。ユースケース図はシステムの高レベルなビューである。必要な場合に限り、詳細を減らして粗い粒度でユースケースを記述することが有益である。ユースケース図は通常、要件の把握、アーキテクチャの検証、実装の促進のために開発の初期段階で作成される。
- ユースケース図はアクターの視点から構造化され、『どうやって』ではなく『何を』に焦点を当てるべきである。
- 拡張関係は、拡張されるユースケースに、拡張するユースケースのオプションの振る舞いを含めるために使用される。
- 一般化関係は2つのユースケースを接続する。子は親の振る舞いを追加または上書きできる。
- システムのアクターとは、システムを使用し、インストールし、起動し、保守し、停止し、情報を取得し、情報を提供する人々である。
2. アクティビティ図
アクティビティ図は、システム内の制御の流れを描写し、ユースケースの実行に含まれるステップを説明するために使用される。アクティビティ図は、選択、反復、並行性をサポートするワークフローの図式表現である。アクティビティ間のデータの流れを示す要素も含めることができる。フローチャートに似ており、システムの動的側面を描写するために使用される。たとえば、アクティビティ図は、初期状態から最終状態への制御の流れを示すのに使用できる。
アクティビティ図は、ビジネスプロセスやワークフローをモデル化するためにも使用される。システムの動的振る舞いを捉え、オブジェクト指向または分散システムのワークフローをモデル化するために使用される。
- アクティビティ図は、システム内の一連のアクションや制御の流れをモデル化するために使用される。
- ダイアモンドは、複数の選択肢がある決定を表す。選択肢には条件をラベルとして付けるべきである。
- フォークノードは、単一の入力フローを複数の並行フローに分割する。
- ジョインノードは、複数の並行フローを再び結合する。
- ピンは、ごちゃごちゃしたアクティビティ図を整理するために使用される。アクションの入力または出力を表す。
- シグナルは、システム内のアクティビティを変更するために使用される。アクティビティを変更する前に、応答が必要である。
- スイムレーンはアクティビティ図におけるアクションをグループ化するために使用されます。
3. シーケンス図
シーケンス図は、システムの部分（すなわちサブシステムやオブジェクト）間の相互作用を示すために使用される単純な図です。UMLシーケンス図は、縦軸を時間として用いて、オブジェクトが時間とともにどのように相互作用するかを示します。シーケンス図は、システムとユーザー間、またはシステム間の相互作用を記録します。シーケンス図は、操作がどのように実行されるかを示します。時間はページを下に進むにつれて進行します。
シーケンス図では、メッセージはオブジェクト間の相互作用を表します。コールメッセージは操作を呼び出すリクエストを表し、リターンメッセージは受信者から呼び出し元への情報の流れを表し、再帰的メッセージは呼び出し元への呼び出しを表します。
- シーケンス図は、システムの異なる部分が単一のユースケースを実行するためにどのように相互作用するかをモデル化するために使用できます。たとえば、シーケンス図はクラス間の相互作用を可視化し、新しいシステムにおける責任を発見するのに役立ちます。
- シーケンス図では、オブジェクトが別のオブジェクトにメッセージを送信します。メッセージのやり取り中、両方のオブジェクトがアクティブです。
- メッセージ矢印は、シーケンス図でメッセージを示すために使用されます。メッセージ矢印には、メッセージシグネチャと呼ばれる説明が付いています。
- メッセージの送信者がメッセージの処理を待たない場合、非同期メッセージが送信されます。
4. 状態機械図
状態機械図（状態チャート、状態遷移図とも呼ばれる）は、システム内のコンポーネントの異なる状態を記述するために使用されます。外部または内部イベントによって制御されます。システムの動的性をモデル化するために使用されます。一つの状態から別の状態への制御の流れを記述し、オブジェクトの作成から終了までの寿命をモデル化するために使用されます。たとえば、状態図はクラスのオブジェクトのすべての可能な動作とイベントの順序を示し、システムの理解にとって不可欠です。
ほとんどのシステムでは、複雑さは異なるクラスのオブジェクト間の相互作用から生じるため、すべてのクラスに状態図が必要なわけではありません。しかし、プロセス制御や通信システムなどの複雑なクラスでは、オブジェクトの振る舞いをモデル化するために状態図が必要です。
- システムまたはクラスの初期状態を表す黒い塗りつぶされた円。
- 一つの状態から別の状態への遷移を表す実線矢印。
- 状態を表す丸い長方形。
- 状態の遷移は、イベントによって引き起こされます。
- ガードは特定の遷移が通過することを防ぎ、内部遷移は状態遷移に影響しません。
- 状態図には初期状態、中間状態、遷移、および最終状態が含まれます。また、角が丸いボックス、名前、状態変数、各状態で実行されるアクションも含まれます。
状態とは何か？
状態は、オブジェクトの寿命中の状態や状況を指します。イベントは、状態遷移を引き起こす刺激です。ガード条件はブール式の評価であり、遷移には複数のガード条件を設定できます。状態図は、電子部品の振る舞いを記述するためによく使用されます。状態図には、状態を複数の状態に分割する、状態を結合する、歴史的状態、複合状態などを含めることができます。
アクティビティ図 vs 状態図
- UMLでは、アクティビティ図は高レベルの活動を表します。特に、アクティビティ図は並行性と調整を表現できます。
- 状態機械図では、頂点はオブジェクトの状態を表し、辺はイベントの発生を表します。追加の記法により、活動の調整方法が記録されます。
5. コミュニケーション図
コミュニケーション図は、オブジェクト間の相互作用を示します。また、オブジェクト間を伝わるメッセージも示します。ユースケースや操作の機能を提供するオブジェクト間のメッセージ伝達をモデル化し、渡されたメッセージを示す相互作用を記録します。コミュニケーション図では、オブジェクト（ユースケースにおけるアクター）は長方形で表され、オブジェクト間を渡されるメッセージは、送信元のオブジェクトから出発し、受信元のオブジェクトで終了するラベル付き矢印で表されます。メッセージが番号でラベル付けされているため、読みやすいです。
（Visual Paradigmのコミュニケーション図ツールで作成）)
- UMLコミュニケーション図は、システムやソフトウェア内のオブジェクト間でメッセージがどのように送受信されるかを示します。
- 線はリンクを表し、矢印はメッセージを表します。
- メッセージは順序番号で番号付けされ、数字と小数点で記述されます。
通信図とシーケンス図
通信図とシーケンス図は似ています。同じ情報を提示していますが、通信図は空間的に配置され、シーケンス図は時間的に配置されています。
たとえば、アクティビティ図とシーケンス図を統合し、システム内の特定のタスクを達成するためにエンティティ間で交換されるメッセージを示すことがあります。
- シーケンス図はメッセージの時間的順序を示し、
- 通信図はオブジェクト間の関係を示します。
6. インタラクション概要図
インタラクション概要図はアクティビティ図に似ていますが、各個別のアクティビティはフレームとして描かれ、その中にはネストされたインタラクション図を含めることができます。UMLインタラクション概要図はインタラクションモデルの高い抽象度を提供します。また、図間のアクティビティの流れを示すこともできます。言い換えれば、インタラクション図はメッセージの時系列順序とメッセージを送受信するオブジェクトの構造的組織を記述することで、システムの動的動作を示します。
（Visual Paradigmのインタラクション概要図ツール)
インタラクション概要図はアクティビティ図に似ていますが、各個別のアクティビティは、ネストされたインタラクション図を含むことができるフレームとして描かれます。UMLインタラクション概要図はインタラクションモデルの高い抽象度を提供します。また、図間のアクティビティの流れを示すこともできます。言い換えれば、インタラクション図はメッセージの時間的順序とメッセージを送受信するオブジェクトの構造的組織を記述することで、システムの動的動作を示します。
インタラクション概要図にはインタラクション図を表すノードが含まれます。たとえば、インタラクション発生（または参照シーケンス図）により、シーケンス図内から別のシーケンス図を参照できます。この機能により、複雑なシナリオを再利用可能な小さなシナリオに分解できます。各シナリオは「インタラクション」となります。
7. 時間図
時間図は、線形のタイムラインに沿ってライフライン内およびライフライン間で条件がどのように変化するかを示すインタラクション図の一部です。オブジェクトが特定の期間にわたってどのように相互作用するかを示し、プロセスの各ステップがどのくらいの時間を要するかを示すことができ、改善点を特定するために使用できます。
（Visual Paradigm（デスクトップ）の時間図エディタ)
- 時間図は線形の時間軸に沿って相互作用を示し、メッセージ、ライフライン、タイムライン、オブジェクトまたは役割などの要素を含みます。
- ライフラインは、相互作用における個別の参加者を表します。図のフレーム内またはスイムレーン内に配置できます。
- 期間制約は、制約が期間中に満たされているかどうかを判断するために使用されます。
- 時間制約は、時間間隔を表す区間制約です。時間制約が違反されたということは、システムが失敗したことを意味します。
