ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んでいます。現在、ロバストネス分析のところまで読み進めました。この本で目からウロコが落ちる体験をしています。以下、気付いた点です。 ユースケースってすごい いままでユースケース記述というのは「アクターと丸をつないだものに、他の資料（機能仕様書など）から見つけ出した説明をつけたもの」で「あまり役に立たないもの」と考えていたのですが、違いました。ICONIXプロセスでは次のことをすることで、ユースケースを設計の基本となる極めて重要な資料に仕立て上げています。 先に用語リスト（ドメインモデル）を作成し、そこに含まれる用語を使うことで曖昧さを排除する。 宣言的（例：ユーザーは検索できる）ではなく叙述的（例：ユーザーは検索ボタンをクリックする）に書く。 「事前条件」「アクター」「スコープ」「レベル」「成功時保障」などの項目を省略し、その分、モデリングに集中する。
ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んで気付いたことのメモです（そんなの当たり前だよ！」というようなこともあるかもしれませんが、ご容赦ください）。前回（d:id:paz3:20090613）の続きです。 シーケンス図のメッセージとロバストネス図のコントローラは1対1対応しなくてもよい 最初、ロバストネス図のすべてのコントローラをシーケンス図のメッセージに置き換えようとしました。たとえば「数量が足りていれば○○する」というような判断をするコントローラも、とあるオブジェクトの自分宛のメッセージとして記述しました。その結果、メッセージ（メソッド）の数が膨れ上がり、わけがわからなくなってしまいました。 書籍を読み直してみたところ、次のように書いてありました。 コントローラと操作の間に1対1の対応を取る必要はありません シーケンス図上にフローチャートを描こうとしてはいけません そこで、シーケンス図か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
