図1　ビジネスモデリングのステートマシン図

前回から、架空の宅配便会社「まいにち宅配便」が開発を進めている「配達予約システム」を例にとり、UMLを用いてシステムの仕様をモデリングする方法について説明しています。今回は、システム仕様の中で重要な要素の1つである「状態」の仕様をモデリングする方法について解説します。

状態の検討も、ビジネスモデリングから仕様化まで一貫して行います。状態を表すステートマシン図もクラス図と同様に、ビジネスモデリングで作成した図を仕様のレベルにまで詳細化する必要があります。その際、次の5点を意識するとよいでしょう。

(1)システムの範囲に応じて不要なデータを除去

ビジネスモデリングで作成したステートマシン図にはシステム化の範囲外の状態や他システムが管理する状態も含まれているため、これらを取り除く必要があります。例えば、図1のビジネスモデリングのステートマシン図には「輸送中」状態がありますが、配達予約システムでは輸送中の状態を管理する必要がありません(図2)。

図2　状態の仕様を定義したステートマシン図

(2)エンドユーザーのための状態を定義

システムに必要な状態は主に3種類あります。1つ目はエンドユーザーのための状態です。第14回の図1の配達予定画面にある「配達予約なし」ステータスは、エンドユーザーがどの宅配を配達予約したらよいかを見分けられるように配慮して定義されたものです。図2のステートマシン図では、「待機中」状態をコンポジット状態(注1)にし、このサブ状態として「配達予約なし」状態を定義しています。

注1:複数の状態を統合した状態。複数の状態からの遷移先が同じ状態の場合に使う。

(3)他システムのための状態を定義

2つ目のシステムに必要な状態は他システムのための状態です。今回の例にはありませんが、他システムにデータの状態を提供しなければいけない場合がこれに当たります。

(4)ビジネスルールのための状態・遷移を定義

システムに必要な状態の3つ目がビジネスルールを実現するために必要になる状態、言い換えれば自システムのために必要な状態です。例えば、配達予定画面には届け済みの宅配は表示しません(予約する必要がないためです)。このビジネスルールを実現するには、宅配の状態として「届け済み」状態を管理する必要があります(図2)。

また、ビジネスルールは遷移にも影響を及ぼします。例えば、届け先が不在だった場合、配達予約ができるようになります。そのため、届け先不在の場合には「届け中」状態から「待機中」状態へ遷移する必要があります。

(5)遷移のトリガーの具体化

ビジネスモデリングで作成したステートマシン図は、業務の観点から状態遷移のトリガー(きっかけ)を定義しています。しかし、ユースケースやビジネスルールが明らかになっている仕様化の段階であれば、よりシステムの仕様を正しく反映したトリガーに定義し直すことが必要です。例えば、ビジネスモデリングのステートマシン図(図1)では、「ドライバーが配達に出発した」ら「届け中」になると定義しています。これに対し、仕様を反映したステートマシン図(図2)では、「配達開始時刻が来た」ら「届け中」になると定義しています。

『出典:システム開発ジャーナル Vol.4(2008年5月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。