ユースケース駆動開発実践_要件定義
前回ユースケース駆動開発の流れを掴めたので実際に開発を進めてみたいと思います。以下のECサイトの機能要求からドメインモデリングとユースケースを行いたいと思います。
要求定義
・ユーザはログイン画面でユーザ名、パスワードを入力してパスワード認証が行える。 ・ユーザはショッピングカートに商品を入れることができる。 ・ユーザはショッピングカートに入れた商品の品目を参照できる。 ・ユーザはショッピングカートに入れた商品の品目を更新できる。 ・ユーザはショッピングカートに入れた商品を購入できる。 ・ECサイト管理者は商品カタログの登録、更新が行える。 ・商品カタログ上の商品が購入対象になる。 ・商品の金額に変更があった場合、ショッピングカートの参照画面で変更前と後の金額を表示する。 ・商品の支払方法としてクレジットカードと銀行振込を選択できる。 ・ECサイト管理者は1回限り利用できるクーポンコードを発行できる。 ・ユーザは商品の購入手続き時にクーポンコードを入力できる。 ・クレジットカード支払いの場合、購入時に支払いが行われて配達予定日を表示する。 ・銀行振込の場合、購入後1週間が支払い期限になりそれがすぎるど購入キャンセルになる。振込が完了したら配達予定日が確認できる様になる。 ・支払い手続きが完了したら外部のシステムに連携して商品を発送予定にします。 ・ユーザは商品の配送状況を確認する。このとき配送状況は外部システムと連携して取得する。 ・購入画面で宛先を選択する。宛先は個人情報、または手入力で入力する。 ・商品の発送前であればキャンセルが行える。入金後のキャンセルでは外部システムと連携し払い戻しが行われる。 ・ユーザは購入履歴を確認できる。
機能要求の一覧はドメインクラスの豊富な情報源となる。ドメインモデルのクラスの抽出をするためにも機能要求の名詞を抽出します。
ユーザ ショッピングカート 商品 品目 ECサイト管理者 商品カタログ 支払方法 クレジットカード 銀行振込 クーポンコード 外部配送システム 配送状況 個人情報 購入履歴
このときドメインモデルのクラスとして扱うには小さそうなのは省きます。ユーザ名はユーザアカウントの属性として扱えそうなので省きます。
機能要求と合わせてアクターも抽出します。このシステムのアクターはユーザ ECサイト管理者 外部配送システム となります。このとき、アクターのユーザとドメインクラスのユーザは別であることに注意します。
ドメインモデリング
次に、機能要求から抽出した名詞の一覧の関係を図示化します。
ドメインモデリングでは凡化、集約の関係が明らかになる様にする。ドメインモデリングの対象はドメインなのでGUI固有の部品クラス等は含まない様にします。商品カタログと商品はとりあえず関連がない状態ですが、ecサイト上で出店ができる様になった場合出店者アカウント毎の商品カタログを用意する必要性が出てくるのでその場合は商品がどのカタログに関連づいているかの情報が必要になってくると思います。
ユースケースモデリング
次にアクター毎の操作のユースケース図を描きます。ユースケース図では、事前に必要な操作、とその操作を実施することで発生するものなどがわかる様に書きます。例えば商品の検索はログインしていなくてもできるけど、ショッピングカートへの品目追加はログインが必要ということがわかる様にします。
precedesは事前に必要な操作になります、ショッピングカートへの品目の追加は事前にログインが必要なのでprecedesになります。invokesはその操作により発生するものを指します。ここでは購入後の入金に発生する商品の発送がinvokesになります。
また、ユースケース図だけでなく実際の操作の流れを叙述的に文章に書き込みます。
例えばユーザはログイン画面でユーザ名、パスワードを入力してパスワード認証が行える。という操作は以下の様になります。
- ユーザはログイン画面でユーザ名パスワードを入力してログインボタンをクリックする
- ログインに成功したら商品の一覧画面を表示する
- ログインに失敗したらログイン画面にログイン失敗と表示する
要求レビュー
ドメインモデルのオブジェクト間の関係を説明する。ユースケースについては正常系とエラー系それぞれ叙述的に書かれていることを確認する。ユースケース記述にはGUI紙芝居や画面モックアップを使って説明する。
