<< 複雑さと戦う : 手続きの置き場所 | main | 実践 ICONIXプロセス : ステップ3 要求レビュー >>

実践 ICONIXプロセス : 入力データの妥当性検証の発見と詳細定義

ICONIXプロセスでは、入力データの妥当性検証を、ユースケースモデリングの「代替コース」として発見し、記述する。

記述例:

代替コース
電子メールアドレスの形式が間違っていた場合:
「メールアドレスの形式が正しくありません」メッセージを表示する。

この代替コースを、要求レビューを経て、ロバストネス分析で、ロバストネス図の「コントロール」として描き、テストモデルにテストケースとして追加し、詳細設計のシーケンス図でメソッドに割当る。

大きな流れは、こうなんだけど、e-mail アドレスの詳細な仕様は、どこに、いつ、どうやって記述するのだろう?

最初はユースケースに
・代替コースの名前
・ユーザに表示するメッセージ(の中核)
程度を記述する。(基本事項だけ記述)

「 e-mail アドレスの正しい形式 」は、詳細すぎて、ここには書けない。
メッセージの内容も、画面では、より親切なガイドや説明を出したいかもしれない。

ICONIXプロセスでは、このような詳細情報は、「ユースケース」に添付する参考資料「補足仕様」として扱う。 モデリングツールに Enterprise Architect を使っていれば、補足仕様はノートや添付ファイルとして追加する。

ICONIXプロセスは、参考資料(補足仕様)の例として、この他に
・画面のモックアップ(実物大の模型:画面項目は実物と同じ詳細さ)
・データモデル (テーブルのカラム定義)
をあげている。

初期のユースケース記述は、手書きの画面紙芝居から出発する。

・画面モックアップ
・補足仕様書
・データモデル
などを作りながら詳細仕様をユースケースモデルに追加していく。

ユースケースモデルに補足仕様を追加したら、その補足仕様で発見・確認できた属性をドメインモデルにも並行して追加する。

ユースケースモデルとドメインモデルの同期をいつも重視するのが ICONIX流。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< September 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM