ユースケース駆動開発実践ガイドを読んでわかったこと

ユースケース駆動開発実践ガイド を読んでいます。現在、ロバストネス分析のところまで読み進めました。この本で目からウロコが落ちる体験をしています。以下、気付いた点です。

ユースケースってすごい

いままでユースケース記述というのは「アクターと丸をつないだものに、他の資料(機能仕様書など)から見つけ出した説明をつけたもの」で「あまり役に立たないもの」と考えていたのですが、違いました。ICONIXプロセスでは次のことをすることで、ユースケースを設計の基本となる極めて重要な資料に仕立て上げています。

  • 先に用語リスト(ドメインモデル)を作成し、そこに含まれる用語を使うことで曖昧さを排除する。
  • 宣言的(例:ユーザーは検索できる)ではなく叙述的(例:ユーザーは検索ボタンをクリックする)に書く。
  • 「事前条件」「アクター」「スコープ」「レベル」「成功時保障」などの項目を省略し、その分、モデリングに集中する。
  • 晴れ日の記述(基本コース)と雨の日の記述(代替コース)の2つで操作・動作を網羅する。

特に、叙述的に書くことで、ユースケースの操作・動作内容を、アクターとシステムとの対話として記述することができます。根底にケイのオブジェクト指向と同じもの*1が流れていることを感じました。

ロバストネス図では必ずしもコントローラからバウンダリに線を引かなくてよい

私はいままで画面に何かを表示したり(メッセージダイアログを含む)、表示を変更する場合、ロバストネス図バウンダリと、表示を担当するコントローラ(複数)とを矢印で結んでいました。この本に載っている例を見ると、あるバウンダリから呼び出された処理では、そのバウンダリに何かを表示するとき、単に「○○を表示する」というコントローラがあるだけで、バウンダリに線が引かれていない所がありました。いままで図中の矢印がごちゃごちゃに交錯していましたが、すっきりさせることができそうです。

まだまだ読み進めたいと思います。

*1:ケイのオブジェクト指向と同じもの=「Smalltalkの底を流れる設計思想」([id:umeaji:20060721:p1])です。id:umeaji さん、有用な記事をありがとうございます。