logo

シーケンス図 |統一モデリング言語 (UML)

統一モデリング言語 (UML) は、システムの設計を視覚化する標準的な方法を確立することを目的としたソフトウェア エンジニアリングの分野のモデリング言語です。 UML は、相互作用図、構造図、動作図などの複数のタイプの図の作成をガイドします。あ シーケンス図 最も一般的に使用される 交流 図。

シーケンス図-2



相互作用図

相互作用図を使用して、 インタラクティブな動作 システムの。システム内のインタラクションを視覚化するのは難しい場合があるため、さまざまなタイプのインタラクション図を使用して、システム内のインタラクションのさまざまな特徴や側面を把握します。

  • シーケンス図は、オブジェクト間の相互作用を連続した順序、つまりこれらの相互作用が発生する順序で単純に描いたものです。
  • シーケンス図を指すために、イベント図またはイベント シナリオという用語を使用することもできます。
  • シーケンス図は、システム内のオブジェクトがどのように、どのような順序で機能するかを記述します。
  • これらの図は、新規および既存のシステムの要件を文書化して理解するために、ビジネスマンやソフトウェア開発者によって広く使用されています。

シーケンス図の重要なトピック

1. シーケンス図の表記

1.1.俳優

UML 図のアクターは、システムおよびそのオブジェクトと対話する役割のタイプを表します。ここで、アクターは常に、UML 図を使用してモデル化しようとしているシステムの範囲外にあることに注意することが重要です。



アクター-11

人間のユーザーやその他の外部の対象を含むさまざまな役割を表現するために俳優を使用します。棒人間記法を使用して UML 図でアクターを表します。シーケンス図には複数のアクターを含めることができます。

例えば:



ここでは、座席予約システムのユーザーは、システムの外部に存在し、システムの一部ではないアクターとして示されています。

ユーザー対話型座席予約システム

1.2.ライフライン

ライフラインは、シーケンス図内の個々の参加者を表す名前付き要素です。したがって、基本的にシーケンス図内の各インスタンスはライフラインによって表されます。ライフライン要素はシーケンス図の上部にあります。ライフラインに名前を付けるための UML の標準は、次の形式に従います。

インスタンス名 : クラス名

シーケンス図

それ以外の場合 Java

という長方形の中にライフラインを表示します。 その名前と種類。上に示すように、ヘッドは垂直の破線 (ステムと呼ばれます) の上にあります。

  • 名前のないインスタンスをモデル化する場合は、ライフラインの名前の部分を空白のままにする点を除いて、同じパターンに従います。
  • ライフラインと俳優の違い
    • ライフラインは常にシステムの内部のオブジェクトを描画しますが、アクターはシステムの外部のオブジェクトを描画するために使用されます。

以下はシーケンス図の例です。

シーケンス図-223

1.3.メッセージ

オブジェクト間の通信はメッセージを使用して表現されます。メッセージはライフライン上に順番に表示されます。

  • 矢印を使用してメッセージを表します。
  • ライフラインとメッセージはシーケンス図の中核を形成します。

さまざまな種類のメッセージ

メッセージは次のカテゴリに大まかに分類できます。

同期メッセージ

同期メッセージは、対話を進める前に応答を待ちます。送信者は、受信者がメッセージの処理を完了するまで待ちます。呼び出し側は、受信側が前のメッセージを処理したことを知っている場合、つまり応答メッセージを受信した場合にのみ続行します。

  • オブジェクト指向プログラミングにおける呼び出しの多くは同期的です。
  • 私たちは 実線の矢印 同期メッセージを表します。

同期メッセージ-22

非同期メッセージ

非同期メッセージは受信者からの応答を待ちません。インタラクションは、受信者が前のメッセージを処理しているかどうかに関係なく、先に進みます。私たちは 並んだ矢じり 非同期メッセージを表します。

非同期メッセージ

1.4.メッセージの作成

Create メッセージを使用して、シーケンス図内の新しいオブジェクトをインスタンス化します。特定のメッセージ呼び出しでオブジェクトの作成が必要になる場合があります。これは点線の矢印で表され、その上に「create word」というラベルが付けられ、これがメッセージ作成シンボルであることを示します。

例えば:

電子商取引 Web サイトで新しい注文を作成するには、Order クラスの新しいオブジェクトを作成する必要があります。

メッセージの作成

1.5。メッセージの削除

オブジェクトを削除するには、削除メッセージを使用します。オブジェクトがメモリの割り当てを解除されるか、システム内で破棄される場合、メッセージ削除シンボルを使用します。これは、システム内のオブジェクトの発生を破壊します。これは、x で終わる矢印で表されます。

例えば:

以下のシナリオでは、ユーザーが注文を受け取ったときに、注文クラスのオブジェクトを破棄できます。

画像の削除

エクタ・カプール俳優

1.6.セルフメッセージ

オブジェクトがそれ自体にメッセージを送信する必要がある特定のシナリオが発生する可能性があります。このようなメッセージはセルフメッセージと呼ばれ、 U字型の矢印

セルフイメージ-1

もう一つの例:

デバイスが Web カメラにアクセスしたいというシナリオを考えてみましょう。このようなシナリオはセルフメッセージを使用して表現されます。

セルフイメージ-2

1.7.返信メッセージ

応答メッセージは、受信者から送信者に送信されるメッセージを示すために使用されます。返信/応答メッセージを表すには、 点線の開いた矢印 。インタラクションは、受信者によって応答メッセージが送信された場合にのみ続行されます。

返信メッセージ

例えば:

デバイスがユーザーに写真を要求するシナリオを考えてみましょう。ここで送信されている写真を示すメッセージが返信メッセージです。

返信メッセージの例

1.8.メッセージが見つかりました

Found メッセージは、不明な送信元がメッセージを送信するシナリオを表すために使用されます。を使用して表されます。 生命線に向けられた矢印 終点から。

例えば:

ハードウェア障害のシナリオを考えてみましょう。

ubuntuのスニッピングツール

見つかったメッセージ

原因は複数考えられますが、ハードウェア障害の原因については明らかではありません。

見つかったメッセージの例

1.9.失われたメッセージ

紛失メッセージは、受信者がシステムに知られていないシナリオを表すために使用されます。これは、ライフラインから終点に向かう矢印を使用して表されます。

例えば:

警告が生成されるシナリオを考えてみましょう。

失われたイメージ

警告は、ライフラインが対話しているユーザーまたは他のソフトウェア/オブジェクトに対して生成される可能性があります。宛先が事前に不明であるため、紛失メッセージのシンボルを使用します。

失われた画像の例

1.10.衛兵

条件をモデル化するには、UML でガードを使用します。これらは、条件が満たされたという口実でメッセージのフローを制限する必要がある場合に使用されます。ガードは、システムまたは特定のプロセスに付随する制約をソフトウェア開発者に知らせるという重要な役割を果たします。

例えば:

現金を引き出すには、以下に示すように、残高がゼロより大きいことが満たされる必要があります。

衛兵

シーケンス図例-2

上のシーケンス図は、感情ベースの音楽プレーヤーのシーケンス図を示しています。

  1. まず、ユーザーがアプリケーションを開きます。
  2. その後、デバイスは Web カメラにアクセスできるようになります。
  3. ウェブカメラはユーザーの画像をキャプチャします。
  4. このデバイスはアルゴリズムを使用して顔を検出し、気分を予測します。
  5. 次に、考えられるムードの辞書をデータベースに要求します。
  6. ムードはデータベースから取得されます。
  7. 気分はユーザーに表示されます。
  8. 音楽はデータベースからリクエストされます。
  9. プレイリストが生成され、最終的にユーザーに表示されます。

2. シーケンス図を作成するにはどうすればよいですか?

シーケンス図の作成にはいくつかの手順が含まれており、通常、さまざまなコンポーネントやオブジェクトが時間の経過とともにどのように相互作用するかを示すために、ソフトウェア開発の設計段階で作成されます。シーケンス図の作成方法に関するステップバイステップのガイドは次のとおりです。

  1. シナリオを特定します。
    • シーケンス図で表現したい特定のシナリオまたはユースケースを理解します。これは、オブジェクト間の特定の相互作用、または特定のプロセスにおけるメッセージ フローである可能性があります。
  2. 参加者をリストします。
    • シナリオに関与する参加者 (オブジェクトまたはアクター) を特定します。参加者はユーザー、システム、または外部エンティティです。
  3. ライフラインを定義します。
    • 各参加者に垂直の破線を描き、時間の経過に伴う各オブジェクトのライフラインを表します。ライフラインは、インタラクション中のオブジェクトの存在を表します。
  4. ライフラインを手配する:
    • インタラクションへの関与の順序に従ってライフラインを水平に配置します。これは、参加者間のメッセージの流れを視覚化するのに役立ちます。
  5. アクティベーションバーを追加します。
    • メッセージごとに、送信側参加者のライフラインにアクティブ化バーを描画します。アクティブ化バーは、参加者がメッセージをアクティブに処理している時間を表します。
  6. メッセージを描画:
    • 矢印を使用して参加者間のメッセージを表します。メッセージはライフライン間を水平に流れ、オブジェクト間の通信を示します。さまざまなタイプのメッセージには、同期 (実線の矢印)、非同期 (破線の矢印)、およびセルフ メッセージが含まれます。
  7. 返信メッセージを含める:
    • 参加者が応答メッセージを送信する場合は、元の送信者に戻る破線の矢印を描画して、返信メッセージを表します。
  8. タイミングと順序を指定します。
    • シーケンス内のメッセージの順序を示すには、数字を使用します。垂直破線を使用して、イベントの発生や時間の経過を表すこともできます。
  9. 条件とループを含める:
    • 組み合わせたフラグメントを使用して、対話内の条件 (if ステートメントなど) とループを表します。これによりシーケンス図が複雑になり、制御フローの詳細を説明するのに役立ちます。
  10. 並列実行を検討してください。
    • 並行して発生するアクティビティがある場合は、平行な垂直破線を描画し、それに応じてメッセージを配置することでそれらを表します。
  11. レビューと絞り込み:
    • シーケンス図を確認して、明確さと正確さを確認してください。意図したインタラクションを正確に表現していることを確認してください。必要に応じて調整します。
  12. 注釈とコメントを追加します。
    • 図内の要素のコンテキストや説明を提供する追加情報、注釈、またはコメントを含めます。
  13. 前提条件と制約を文書化します。
    • 相互作用に関連する仮定や制約がある場合は、図の横にそれらを文書化します。
  14. ツール:
    • UML モデリング ツールまたは作図ソフトウェアを使用して、きちんとした本格的なシーケンス図を作成します。これらのツールは多くの場合、編集、共同作業、文書化を容易にする機能を提供します。

3. シーケンス図の使用例

  • システム動作の視覚化:
    • シーケンス図は、さまざまなコンポーネント、オブジェクト、またはアクターの間の時間の経過に伴う相互作用を示すことによって、システムの動的な動作を説明するために使用されます。
    • これらは、特定のシナリオにおけるメッセージとイベントのフローを明確かつ視覚的に表現します。
  • ソフトウェアの設計とアーキテクチャ:
    • ソフトウェア開発の設計段階において、シーケンス図は、開発者やアーキテクトが特定の機能を達成するためにさまざまなコンポーネントやオブジェクトがどのように相互作用するかを計画し、理解するのに役立ちます。
    • これらは、システムの動作の青写真を提供します。
  • コミュニケーションとコラボレーション:
    • シーケンス図は、開発者、デザイナー、プロジェクト マネージャー、クライアントなどの関係者間のコミュニケーション ツールとして機能します。
    • これらは、複雑な相互作用をわかりやすい視覚的な形式で伝え、コラボレーションと共通の理解を促進するのに役立ちます。
  • 要件の明確化:
    • システム要件を絞り込む場合、シーケンス図を使用して、システム コンポーネント間またはシステムと外部エンティティ間で予想される相互作用を明確にし、指定できます。
    • これらは、すべての関係者間でシステムの動作を共通に理解するのに役立ちます。
  • デバッグとトラブルシューティング:
    • 開発者は、システム対話中のメッセージの順序とタイミングに関連する問題を特定および分析するためのデバッグ ツールとしてシーケンス図を使用します。
    • 制御の流れを視覚的に表現し、問題の特定と解決に役立ちます。

4. シーケンス図を使用する際の課題

  • 複雑さとサイズ:
    • システムが複雑になるにつれて、シーケンス図が大きく複雑になる可能性があります。インタラクションを正確に表現しながら図のサイズを管理することは困難な場合があり、過度に複雑な図は理解が困難になる可能性があります。
  • 抽象化レベル:
    • 抽象化に関して適切なバランスを取るのは難しい場合があります。シーケンス図は、必要な情報を伝えるために十分に詳細である必要がありますが、詳細が多すぎると読者が圧倒されてしまう可能性があります。細かいことにとらわれずに、最も重要なやり取りに集中することが重要です。
  • ダイナミックな性質:
    • シーケンス図はシステムの動的な側面を表すため、開発プロセス中に頻繁に変更される可能性があります。進化するシステムに合わせてシーケンス図を最新の状態に保つことは、特に急速に変化する開発環境や機敏な開発環境では困難になる場合があります。
  • メッセージのあいまいさ:
    • 場合によっては、オブジェクト間のメッセージの正確な性質を定義することが困難な場合があります。メッセージの内容や意味が曖昧であると、関係者間の誤解が生じ、シーケンス図の精度に影響を与える可能性があります。
  • 同時実行性と並列処理:
    • 同時プロセスおよび並列プロセスの表現は複雑になる場合があります。シーケンス図には並列実行を示すメカニズムがありますが、同時に発生する複数のインタラクションを視覚化するのは困難な場合があり、追加の図要素が必要になる場合があります。
  • リアルタイムの制約:
    • リアルタイムの制約と正確なタイミング要件を表現することは困難な場合があります。シーケンス図は逐次的な表現を提供しますが、リアルタイムの側面を正確にキャプチャして伝達するには、追加の文書や補足的な図が必要になる場合があります。