前の投稿 次の投稿

2010/02/27

予約システムのユースケースモデル

前回、予約システムを必要とする人は以下の二つであると前回記した。

1. コミュニティ内での予約管理に使用したい（予約者と管理者が同一）
2. 予約管理を簡易にしたい（予約者と管理者が別）

これについて少し詳しく説明するため、ユースケースを作成してみた。

まず 1 について。設備管理者が、自前のパソコンで予約管理を行いたい場合なんかが専らとなるでしょう。

図1 - 予約者と管理者が同一の場合のユースケース図

表1 - 予約者と管理者が同一の場合のユースケース記述

ユースケース名	顧客の予約を管理する
概要	メールや電話など、本システムと関わらない場所から受け付けた予約を、顧客情報と共に管理を行う。
アクター	・管理者（オペレータ）
メインフロー	アクターは、（利用の申請をした）顧客がシステムに利用者として登録されているか問い合わせる。 システムは、該当する利用者がいた場合それを返す。該当しなかった場合は「ゲスト利用者」として返す。 アクターは、顧客が申請をした設備の利用予定時前後の予約状況を調べる。 システムは、設備の予約情報を表示する。 アクターは、設備が予約可能の場合、予約登録をする。既に予約が入っていた場合には、顧客にその旨を伝える。 システムは、予約情報を記録する。

こんなところでしょうか。「設備」というのは例えば分析機器であったり会議室であったりします。しかしながらこのシステムは時間的拘束を管理するということですので、サービス業の人員、例えば美容院における美容師、介護サービスの介護福祉士にも成り得ます。利用希望者は、基本的にシステムを使う事はありませんが、予約状況を確認するサービスも拡張可能ということにしてあります。

つづいて 2 について。利用者のためにWebで予約サービスを行う、といった利用法を想定しています。

図2 - 予約者と管理者が別の場合のユースケース図

表2 - 予約者と管理者が別の場合のユースケース記述

ユースケース名	顧客が設備の利用を申請し、管理者が承認を行う
概要	顧客は本システムへWebからアクセスし、設備の予約状況を確認・申請を行う。管理者はシステムを使い、その予約の承認を行う。
アクター	・利用希望者　・管理者
メインフロー	アクター（利用希望者）は、設備がいつ空いているか問い合わせる。 システムは、空き状況を返す。 アクター（利用希望者）は、予約の申請を行う。 システムは、予約可能である申請の場合、承った旨を伝える。 アクター（管理者）は、予約の申請があるか調べる。 システムは、現在の予約申請を返す。 アクター（管理者）は、予約の申請に問題が無い場合、そのまま承認を行う。

予約受け付け数が多い場合には、電話や対面での応対に意外と時間を費やす事となります。このシステムを導入する事で、設備への時間配分の煩わしさを解消することができます。Web上での公開を行うので、このユースケースの場合、インターネット接続が必須になります。1 のユースケースと同時利用する事も出来ます。

以上のように、当たり前な感じになりましたが、これぐらい抽象化されたユースケースに適う汎用性のあるシステムを基本とします。次はクラス図使ってデータも出るを設計してみます。

Ryusuke at 16:21 | コメント (0) | ユースケース 予約システム

コメント(0)

コメントを投稿

前の投稿 次の投稿

コメントの投稿 (Atom)