トピック

はじめに ページの先頭へ

多くの場合、シーケンス図はユース・ケースの実現 (『成果物: ユース・ケースの実現』を参照) を表すために使用します。すなわち、ユース・ケース全体、またはその一部の振る舞いとオブジェクトとの相互作用方法を表す図です。1 つ以上のシーケンス図によって、ユース・ケースを生成するオブジェクトの相互作用が表現されることもあります。一般的には、主要なイベントのフローのシーケンス図 1 つと、ユース・ケースの独立した各サブフローのシーケンス図 1 つずつで構成されます。

シーケンス図は、フロー中のオブジェクトのロールを明確にし、クラスの責務とインターフェースの決定のための基本的な情報源となるため、設計者にとっては特に重要です。

コミュニケーション図とは異なり、シーケンス図には時系列的なシーケンスが含まれますが、オブジェクトの関係は含まれません。シーケンス図とコミュニケーション図は、類似した情報を表しますが、その表現方法が異なります。シーケンス図は明示的なメッセージ・シーケンスを示し、メッセージを着信時刻順に視覚的に表示する必要のある場合に適しています。一方、相互作用のインスタンス間の構造的関係に関心がある場合は、コミュニケーション図を使います。詳しくは、『ガイドライン: コミュニケーション図』を参照してください。

シーケンス図の内容 ページの先頭へ

シーケンス図には、オブジェクトとアクターを、相互作用方法を記述したメッセージと共に挿入することができます。このダイアグラムでは、描かれているオブジェクトで起きていることが起動の観点から説明され、メッセージ交換によるオブジェクトのコミュニケーション方法が記述されます。シーケンス図は、ユース・ケースの異なるイベント・フローごとに作成できます。

付随するテキスト内で説明される図

単純な「電話交換」におけるユース・ケース「市内電話をかける」のイベント・フローの一部を表すシーケンス図

オブジェクト ページの先頭へ

オブジェクトは、「生存線」と呼ばれる垂直の破線で表されます。 生存線は、特定の時間におけるオブジェクトの存在を表します。オブジェクトの記号は生存線の先頭に描かれ、オブジェクト名と下線付きのクラスがコロンで区切られて表示されます。

オブジェクト名: クラス名

シーケンス図のオブジェクトは次の方法で使用できます。

  • 生存線によってオブジェクト、またはそのクラスが表されます。したがって、生存線はクラスとオブジェクトの振る舞いの両方のモデル化に使用できます。しかし、通常は生存線によって特定のクラスのオブジェクトすべてが表されます。
  • オブジェクトのクラスは指定しなくてもかまいません。通常、オブジェクトを使用してシーケンス図を作成し、その後クラスを指定します。
  • オブジェクトは名前がなくてもかまいませんが、同じクラスの異なるオブジェクトを区別するには、名前を付ける必要があります。
  • 同じダイアグラムの複数の生存線により、同じクラスの異なるオブジェクトを表せますが、2 つのオブジェクトを区別するにはオブジェクトに名前を付けなければなりません。
  • クラスを表す生存線は、そのクラスのオブジェクトを表す生存線と同時に存在できます。クラスを表す生存線のオブジェクト名は、クラス名としても設定できます。

アクター ページの先頭へ

アクターのインスタンスは通常、シーケンス図の最初 (左端) の生存線によって、相互作用の呼び出し側として表されます。同一のダイアグラムに複数のアクターが存在する場合、すべてが左端、または右端の生存線にまとまるようにします。

メッセージ ページの先頭へ

メッセージは、作業が後続するという期待を伴う情報を運ぶ、オブジェクト間のコミュニケーションです。シーケンス図では、メッセージは 1 つのオブジェクトの生存線から別のオブジェクトの生存線に向かう横方向の実線矢印で表されます。メッセージが任意のオブジェクトからそれ自身に送られる場合、矢印は同じ生存線から始まって終わります。矢印にはメッセージ名のラベルとそのパラメーターが付けられます。相互作用全体でのメッセージの順番を表すために、矢印にシーケンス番号のラベルが付けられる場合もあります。シーケンス図では、物理的な矢印の位置が相対的なシーケンスを表す場合、シーケンス番号はしばしば省略されます。

メッセージは割り当てなくてもかまいません。つまり、メッセージ名はメッセージ全体の意味を記述する一時的な文字列であって、受け取るオブジェクトの操作名ではないということです。メッセージの送信先オブジェクトの操作を指定することで、後からメッセージを割り当てることができます。その時点で、メッセージの名前は指定された操作に置き換わります。

スクリプト ページの先頭へ

シーケンス図では、スクリプトによってイベントのフローがテキスト記述されます。

スクリプトは、生存線の左側に記述します。こうすると、フロー全体を上から下まで読むことができます (上の図を参照)。特定のメッセージにスクリプトを添付して、メッセージと共にスクリプトも移動できるようにします。

シーケンス図の「流通管理フローページの先頭へ

イベント・フローの中央制御や、イベント・フローの一部は、少数のオブジェクトが他のオブジェクトとメッセージを送受信することでフローを制御していることを意味しています。このコントロール・オブジェクトによって、他のオブジェクトがユース・ケースにおいて有効化される順番が決められます。その他のオブジェクト間の相互作用は非常に少ないか、まったく存在しません。

リサイクル・マシン・システム」では、ユース・ケース「日次レポートの印刷」によって返却された品物の数と種類が特に追跡され、受け取りに記録が記入されます。「レポート作成」コントロール・オブジェクトによって、合計が抽出され記入される順番が決められます。

付随するテキスト内で説明される図

ユース・ケースの振る舞いの構造「日次レポートの印刷」は「レポート作成」コントロール・オブジェクトに集中されています。

これは、集中的振る舞いの例です。制御構造は基本的に中央集中化されています。これは、イベント・フローの異なるサブイベント・フェーズが独立したものではないためです。このアプローチの主要な利点は、各オブジェクトによって次のオブジェクトの計算が追跡されなくてもよい点です。サブイベント・フェーズの順番の変更は、単にコントロール・オブジェクトで変更を行うだけですみます。例えば、新しい種類のリサイクル品が含まれていた場合など、別のサブイベント・フェーズを追加することも簡単にできます。この構造の別の利点は、別のユース・ケースでいろいろなサブイベント・フェーズを簡単に再利用できることです。これは、振る舞いの順番がオブジェクトに組み込まれているわけではないためです。

かかわっているオブジェクトが、1 つ以上のコントロール・オブジェクトを通すのではなく、互いに直接コミュニケーションを行っている場合、分散制御が発生します。

ユース・ケース「手紙を送る」では、ある人が郵便局を通じて別の国に手紙を送ります。手紙はまず、宛先の国に送られます。その国内で、手紙は指定された町に送られます。 町では、宛先の家に手紙が送られます。

付随するテキスト内で説明される図

ユース・ケース「手紙を送る」の振る舞いの構造は分散されています。

このユース・ケースの振る舞いは、分散されたイベント・フローです。サブイベント・フェーズはグループを成しています。手紙の送り手は「誰かに手紙を出した」と言います。この人物は、手紙の配送方法の詳細を知る必要はありませんし、知りたいとも思っていません。(手紙を国内に送った場合、これらのアクションのすべてが起こるわけではありません。)

使用される制御の種類はアプリケーションによって異なります。一般に、独立したオブジェクトの作成を行うべきです。これは、さまざまなタスクを最もその実行に適したオブジェクトに実行させるためです。

中央制御されたイベント・フローには、「フォーク型」のシーケンス図が含まれます。一方、「階段型」シーケンス図では、制御構造はかかわりを持つオブジェクトに対して分散化されている様子が描かれます。

付随するテキスト内で説明される図

中央制御されたイベント・フローでは、「フォーク型」のシーケンス図が作成されます。分散制御構造では、「階段型」のシーケンス図が作成されます。

ユース・ケースの実現の振る舞いの構造は、多くの場合中央制御された振る舞いと分散された振る舞いの混合から成っています。

分散構造は、次の場合に最適です。

  • サブイベント・フェーズが密接に連結されている場合。これは、かかわりを持っているオブジェクトが次のような場合です。
    • 階層の一部、または階層から成る場合。例えば、国 - 州 - 市が挙げられます。
    • 情報階層から成る場合。例えば、CEO - 部長 - 課長など。
    • 固定されたとき時系列的な連続を表す場合 (サブイベント・フェーズのシーケンスは常に同じ順番で実行されます)。例えば、広告 - 注文 - 請求 - 配達 - 支払いなど。
    • 概念的継承階層から成る場合。例えば、動物 - 哺乳類 - 猫など。
  • 機能をカプセル化したい場合、またそれによって概念化したい場合。これは、振る舞いの構造が中央集中されている場合、機能は必要以上に把握しにくくなるため、常に機能のすべてを使用したい人に向いています。

中央集中構造は次の場合に適しています。

  • サブイベント・フェーズを実行する順番が変更される可能性が高い場合
  • 新規のサブイベント・フェーズが挿入される可能性が高い場合
  • 機能の一部を独立した再利用可能なものとしたい場合


Rational Unified Process   2003.06.15