ユースケース図からシーケンス図を作成する

ユースケース図からシーケンス図を作成する

次に、ユースケースごとのシーケンス図をユースケース記述から作成していく手順を見てみましょう。

ユースケース記述には、アクターによるシステムの画面操作と、そのイベントに対するシステムの応答が記されています。シーケンス図のモデリングでは、この画面操作イベントから開始される応答として行われるシステム処理の解決方法を、オブジェクト間のメッセージによってクラスに責務（操作）を割り当てながら定義していきます。

この責務の割当先を選択する基準は、クラスが持つ属性（情報）と構造（関連をたどって取得できるオブジェクトの属性）に強く関係しています。

責務は「操作に必要な情報（属性値や関連をたどって取得できるオブジェクトの属性値）を取得するのに必要十分なオブジェクトに対して割り当てる」、言い換えると「処理に必要な情報を最も一意に特定できるオブジェクトに割り当てる」必要があります。必要な情報がなければ処理ができませんし、必要以上の情報を持つオブジェクトは、どの情報を使用するべきかを特定し難くなってしまいます。

ステートマシン図とは

次はステートマシン図です。ステートマシン図は、1つのオブジェクトに注目して、そのオブジェクトの状態が相互作用の中でどのように遷移していくのかを表現するための図です。

業務系のシステム開発では、あまり登場する機会がないと言われることもありますが、必要に応じて、複雑な状態を持つオブジェクトを分析する際に記述されたり、プロセスに密接するオブジェクトとして、ワークフローの定義として用いられたりします。

イベント駆動型のプログラミングこそがオブジェクト指向プログラミングであると言えるのであれば、イベントに応じた状態遷移を表現するステートマシン図によるモデリングは、まさにオブジェクト指向モデリングであると言えるでしょう。

図2は、前回も登場した「出張申請」クラスのオブジェクトの状態遷移をモデリングしたステートマシン図の例です。「開始状態」は、状態遷移の開始を表現します。「終了状態」が表現するのは、（開始状態とは反対で）状態遷移の終了です。終了状態に到達すると、対象のオブジェクトが破棄されることを意味します。中には、終了状態を記述しないステートマシン図もあります。

（画像をクリックすると別ウィンドウに拡大図を表示します）

「状態」は、オブジェクトのある時点の状況です。状態の内部には、アクティビティと呼ばれる処理を指定することができます。「entry」ラベルに記述されるアクティビティは、その状態に遷移したタイミングで実行されるアクティビティです。他にも、その状態にいる間実行されるアクティビティを表す「do」ラベル、その状態から出るタイミングでアクティビティが実行される「exit」ラベルがあります。また、状態は入れ子にすることができ、内部に状態を含む状態を特別に「合成状態」と呼びます。

「遷移」は、特定のイベントによって発生する状態から状態への移り変わりを表現します。遷移時に行われるアクティビティを指定することもでき、書式は「イベント名[ガード条件]/アクティビティ名」です。ガード条件は、その遷移が発生するために必要な条件を表します。

遷移の途中に現れる（開始状態に似ている）黒丸は「ジャンクション」と呼ばれ、複数の遷移を連続させるためのものです。これを白丸や白抜きのひし形で記述すると、「選択」と呼ばれる要素になります。「ジャンクション」が、連続する遷移のガード条件を同時に評価するのに対し、「選択」は段階的に評価するという違いがあります。

「深い履歴擬似状態」とは、合成状態に遷移する際に、以前の内部状態を覚えていることを表します。図の例で説明すると、対象の出張申請が、「活動中」状態の中の「承認中」状態にあるとします。次に、「保留する」遷移が発生し、「活動保留中」状態に遷移したとします。そこで、「復帰する」遷移が発生すると、深い履歴擬似状態が指定されているので、（「未申請」状態から再開されるのではなく）「承認中」状態に復帰するという具合です。