ビジネスモデルからシステムを見いだす：実践！ UMLビジネスモデリング（6）（2/3 ページ）

To beビジネスモデルの定義が完了したら、これを基にビジネスモデルのシステム化を検討する。その際、具体的にどのようにしてシステムの機能や範囲を決定すればよいのか？ 前回までと同様、具体的なシナリオを用いて解説する。

[内田功志，システムビューロ]

ビジネスユースケース「洋菓子を販売する」のシステム化

　さらに今度は、いままで例に挙げなかった「洋菓子を販売する」という新しいビジネスユースケースを取り上げ、「計画を立てる」「洋菓子を作成する」と同じようにシステム化の検討を行ってみましょう。まず、システム化を検討する前のビジネス分析シーケンス図は以下のようになります。

図9　ビジネス分析シーケンス図： 洋菓子を販売する

　このビジネス分析シーケンス図に対して、販売状況を計画管理システムに登録するように洗練したのが、以下のビジネス設計シーケンス図です。

図10　ビジネス設計シーケンス図： 洋菓子を販売する

　図10では計画管理システムが加えられ、店員から「［可能ならば］販売状況を登録する()」というメッセージを受信しています。

　販売状況の登録は、販売のたびに必須というわけではなく、可能ならば、ということにしています。販売の都度、またはある一定の間隔、どちらのタイミングでも販売状況データを更新できるようなシナリオにしています。

　もちろん、計画を立てる際に販売結果を一括で登録することはできますが、販売の都度更新することも視野に入れています。これは、システムがビジネスの制約とならないようにという配慮であり、ビジネスモデルに自由度を与えています。

　このビジネス設計シーケンス図を基に、ビジネス分析クラス図を洗練してビジネス設計クラス図を作成します。

　以下が、システム化を検討する前のビジネス分析クラス図です。

図11　ビジネス分析クラス図： 洋菓子を販売する

　シーケンス図の場合と同様、これに計画管理システムを導入したのが、以下のビジネス設計クラス図です。

図12　ビジネス設計クラス図： 洋菓子を販売する

　このように、To beへと洗練したビジネス分析モデルの中にシステムをどう適用していくのかを検討して、ビジネス設計モデルへと洗練していきます。

　なお、前回取り上げたビジネス分析クラス図のビジネスアクターやビジネスワーカーの多重度は省略しています。実際、これらの多重度は、ビジネスエンティティ間の多重度に比べてそれほど重要ではないことが多いのです。