ドメイン分析をしてみる。
よくある例として、図書館を取り上げてみます。
次のようなユースケースがざっと考えられます。
- 図書を登録する（司書のみ）
- 図書の場所を調べる
- 図書の在庫を調べる
- 図書の貸し出しをする（司書のみ）
- 図書の返却をする（司書のみ）
- 図書の場所を登録する（司書のみ）
粒度は、「ユーザーマニュアルの章」になるようにしました。
（ICONIXプロセスに基づいています。）
さて、ここで私がいつもやっている感じでDBレイアウトを考えてみました。
書籍DB
- 書籍id
- 書籍名
- 著者
- 出版社
- ISBN
- 場所id
在庫DB
- 書籍id
- 在庫数
場所DB
- 場所id
- 棚名
- 分類
司書DB
- id
- pass
書籍DB：在庫DB＝1:1
書籍DB：場所DB＝1:1
という感じです。
さて、全てのユースケースについて分析してたらお試しにはならないので、
1.図書を登録する（司書のみ）
について分析してみます。
まずはユースケース記述を書きます。
基本処理
司書はログイン画面でidとpassを入力し、OKボタンをクリックする。
システムはidとpassが正しいことを確認する。
システムは場所を全て取得し、書籍登録画面を表示する。
司書は書籍名、著者、出版社、IDBN、在庫数、棚名、分類を入力する。
司書は場所リストから場所を選択する。登録したい場所が無い場合は、場所を登録してから選択する。
司書は在庫数を入力する。
司書は登録ボタンをクリックする。
システムは入力漏れが無いことを確認する。
システムは在庫数がゼロでないことを確認する。
システムは書籍を登録する。
代替処理
システムはidとpassが正しくなかった場合、メッセージボックスで警告する。
システムは入力漏れがあった場合、メッセージボックスで警告し、その項目をハイライトし、
在庫数がゼロの場合、メッセージボックスで警告し、在庫数テキストをハイライトする。
基本処理と代替処理しか書かないのは、ICONIXプロセスに基づいているからです。
これらについて、ロバストネス図を書くと、このようになりました。
あ、今みると
- システムは入力漏れが無いことを確認する。
- システムは在庫数がゼロでないことを確認する。
- 代替手順
を書き忘れた・・・。けど、まぁこんな感じでしょう。
うん、すんなりとここまでこれました。
図の作成にはフリーのツールjudeを使いました。作った図を簡単にjpg、pngで保存できるので使いやすいですね。
