ICONIXプロセスでは、入力データの妥当性検証を、ユースケースモデリングの「代替コース」として発見し、記述する。
記述例:
代替コース
電子メールアドレスの形式が間違っていた場合:
「メールアドレスの形式が正しくありません」メッセージを表示する。
この代替コースを、要求レビューを経て、ロバストネス分析で、ロバストネス図の「コントロール」として描き、テストモデルにテストケースとして追加し、詳細設計のシーケンス図でメソッドに割当る。
大きな流れは、こうなんだけど、e-mail アドレスの詳細な仕様は、どこに、いつ、どうやって記述するのだろう?
最初はユースケースに
・代替コースの名前
・ユーザに表示するメッセージ(の中核)
程度を記述する。(基本事項だけ記述)
「 e-mail アドレスの正しい形式 」は、詳細すぎて、ここには書けない。
メッセージの内容も、画面では、より親切なガイドや説明を出したいかもしれない。
ICONIXプロセスでは、このような詳細情報は、「ユースケース」に添付する参考資料「補足仕様」として扱う。 モデリングツールに Enterprise Architect を使っていれば、補足仕様はノートや添付ファイルとして追加する。
ICONIXプロセスは、参考資料(補足仕様)の例として、この他に
・画面のモックアップ(実物大の模型:画面項目は実物と同じ詳細さ)
・データモデル (テーブルのカラム定義)
をあげている。
初期のユースケース記述は、手書きの画面紙芝居から出発する。
・画面モックアップ
・補足仕様書
・データモデル
などを作りながら詳細仕様をユースケースモデルに追加していく。
ユースケースモデルに補足仕様を追加したら、その補足仕様で発見・確認できた属性をドメインモデルにも並行して追加する。
ユースケースモデルとドメインモデルの同期をいつも重視するのが ICONIX流。
記述例:
代替コース
電子メールアドレスの形式が間違っていた場合:
「メールアドレスの形式が正しくありません」メッセージを表示する。
この代替コースを、要求レビューを経て、ロバストネス分析で、ロバストネス図の「コントロール」として描き、テストモデルにテストケースとして追加し、詳細設計のシーケンス図でメソッドに割当る。
大きな流れは、こうなんだけど、e-mail アドレスの詳細な仕様は、どこに、いつ、どうやって記述するのだろう?
最初はユースケースに
・代替コースの名前
・ユーザに表示するメッセージ(の中核)
程度を記述する。(基本事項だけ記述)
「 e-mail アドレスの正しい形式 」は、詳細すぎて、ここには書けない。
メッセージの内容も、画面では、より親切なガイドや説明を出したいかもしれない。
ICONIXプロセスでは、このような詳細情報は、「ユースケース」に添付する参考資料「補足仕様」として扱う。 モデリングツールに Enterprise Architect を使っていれば、補足仕様はノートや添付ファイルとして追加する。
ICONIXプロセスは、参考資料(補足仕様)の例として、この他に
・画面のモックアップ(実物大の模型:画面項目は実物と同じ詳細さ)
・データモデル (テーブルのカラム定義)
をあげている。
初期のユースケース記述は、手書きの画面紙芝居から出発する。
・画面モックアップ
・補足仕様書
・データモデル
などを作りながら詳細仕様をユースケースモデルに追加していく。
ユースケースモデルに補足仕様を追加したら、その補足仕様で発見・確認できた属性をドメインモデルにも並行して追加する。
ユースケースモデルとドメインモデルの同期をいつも重視するのが ICONIX流。