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

ユースケース駆動開発実践ガイドを読んで気付いたことのメモです（そんなの当たり前だよ！」というようなこともあるかもしれませんが、ご容赦ください）。前回（d:id:paz3:20090613）の続きです。

シーケンス図のメッセージとロバストネス図のコントローラは1対1対応しなくてもよい

最初、ロバストネス図のすべてのコントローラをシーケンス図のメッセージに置き換えようとしました。たとえば「数量が足りていれば○○する」というような判断をするコントローラも、とあるオブジェクトの自分宛のメッセージとして記述しました。その結果、メッセージ（メソッド）の数が膨れ上がり、わけがわからなくなってしまいました。

書籍を読み直してみたところ、次のように書いてありました。

コントローラと操作の間に1対1の対応を取る必要はありません
シーケンス図上にフローチャートを描こうとしてはいけません

そこで、シーケンス図からこれらの（自分宛の）メッセージを削除したところ、非常に短くなり、見通しがよくなりました。

またシーケンス図上で同じ処理を何度も記述している場所が目立つようになるため、共通処理を発見しやすくなった気がします。

シーケンス図ってすごい

ICONIXプロセスを知る前は、ユースケース（のようなもの）を元にガシガシとコードを書いていました。その結果、完成してからデザインやオブジェクトの責務がおかしいと感じることが多々ありました。シーケンス図を描くことでオブジェクトの責務について十分吟味することができるようになりました。また、実際のコードを書く前に修正ができるので、別の設計に変更することも簡単にできるようになりました。

ロバストネス図を書き捨てなくてよい

一般的な（？）ロバストネス分析では、ロバストネス図は一時的なもので、次のステップに行くときに捨てるものらしいです。これは「もったいない」と思っていました。ICONIXプロセスでは、後のステップからのフィードバックでロバストネス図を修正します。つまり書き捨てにはなりません。

コードと対応する図が存在していることになるため、将来のシステム改修でも現在のシステムを分析する手間が省けます。システム改修の際は、ユースケースの修正からスタートします。コードのみを修正することができないというのは不利な点にも聞こえますが、コードに手を入れる前にどのようにやるかの十分な検討ができ、システムの品質の向上が期待できます。これはジョエル・スポルスキーが「やさしい機能仕様」で言っていることと同じだと思います。