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

前回、データ仕様のモデリングを行う際、ビジネスモデリングで作成したクラス図を参考にしながら、仕様のレベルまでを詳細化する「段階的詳細化」を行う必要があると説明しました。以下、詳細化の具体的な内容を説明します。

システムの範囲に応じて図を変更

ビジネスモデリングの段階ではシステム化の範囲や他システムとの境界が決まっていないため、クラス図にはシステム化の範囲外の概念や他システムが管理するデータも含まれています。そこで、仕様化の段階で、開発対象のシステムにおいて不要なクラスや属性を取り除きます。

例えば、図1のビジネスモデリングのクラス図には「荷物」「サイズ種別」などのクラス、「宅配」クラスの「受付日」「料金」などの属性、「宅配」クラスから「住所・電話番号」クラスへ参照している「ご依頼主」の関連があります。しかし、配達予約システムは配達予約に特化しているため、これらのクラス・属性・関連はシステムの範囲外となり、クラス図から取り除きます(図2)。

図1　ビジネスモデリングのクラス図

図2　データの仕様を定義したクラス図

画面やシステム間インタフェースの項目を反映

ビジネスモデリングのクラス図では業務の概念の理解を目的としているため、システムに必要な属性をすべて定義する必要はありません。したがって、仕様化の段階でクラスに必要なすべての属性を定義します。

この作業の最大のインプットは画面やシステム間インタフェースの項目です。この項目をシステムで管理するには、項目に該当する属性をクラスに定義する必要があるのは当然ですが、新しいクラスや関連が必要になることもあります。例えば、前回の図1の配達予定画面には「配達日時」「ステータス」などの項目がありますが、この項目をシステムで管理するには、クラス図(図2)に「配達計画」クラスと「配達日付・時間帯」「配達予約状態」属性を定義する必要があります。

ビジネスルールを反映

ビジネスルールもクラス図のインプットになります。ビジネスルールのほとんどは関連とその多重度に影響します。配達予約システムでは、宅配便の届け先の住所・氏名から配達事前連絡先を割り出します。このように、宅配便と配達事前連絡先の間には関連があることから、クラス図(図2)にも「宅配」クラスと「配達事前連絡先」クラスに関連を定義します。

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