ロバストネス駆動開発？
過去に「 ロバストネス図113枚!!」でも取り上げたが，最近ロバストネス分析を設計の入り口にすることが多くなった。バウンダリ，コントローラ，エンティティという３つのステレオタイプは，今日のWebアプリケーションのアーキテクチャにかなりしっくりとくる。統一プロセスでも，ユースケースからクラスの発見をするために，ロバストネス分析をすることが推奨されている。 ロバストネス分析の結果のロバストネス図は，かなり直感的にシステムの構造と流れを示してくれるので，あまり実装に詳しくない人でも理解可能なようだ。システムの構造や設計に興味を持っているお客さんであれば，十分使用に堪えるシンプルさがあると思う（興味を持っていれば，が重要）。 僕が設計書と実装をできるだけ近づけるために，自動生成が効果的だと思っていることは，このエントリを読んでいる方々はご存知のことと思う。クラスを見つけるためのロバストネス分析が基本だが，策定したアーキテクチャに基づいて分解された実装の単位ごとに設計書を定義している状態なら，ロバストネス分析をすることによって，設計書についても導き出すことができるようになる。
今日のシステムは，細かなモジュールが相互に連携しあいながら処理が流れていくという構造になる。つまり，従来と違って，設計書も１冊の物語的なものではなく，個々の細かなモジュールと対に作成されることが普通だ。各設計書は，自分が担当する責務を全うするために必要な他のモジュールを参照する。細かく細分化された設計書の参照を追っていけば，モジュールの関連や，ある機能に必要な設計書一式を導き出すことが出来るだろう。しかし，規模が大きくなればなるほど，設計書の量は膨大になり，追うことは非現実的になってしまう。さらに，実装から関連を導き出すことは，XML地獄に自ら溺れることになるため，これもまた非現実的だろう。
設計書と設計書の関係，実装モジュールと実装モジュールの関係，そして設計書と実装モジュールの関係，これらをすべて表しているものこそが，ロバストネス分析の結果得られた，ロバストネス図だ。
多くの場合，ロバストネス図はただの途中成果物という説明がなされる。しかし，僕にはとてもそうは思えない。目の前にある業務と基本設計の成果物を頼りに，さまざまな発見とそれらの関連を見事に表している分析結果を，途中の成果物という一過性のものと捉えてしまうことに，抵抗感を感じてしまう。上記のやり方に従って一緒に仕事をしてくれた設計者や開発者も，ロバストネス図の必要性を強烈に感じてくれている。
もうこれは，ロバストネス駆動開発と言っても良いんじゃないかと思う。「ロバストネス駆動開発」でググってもヒット件数ゼロになってしまったことにちょっと驚きだ。
過去の「
クラス図は何も語らない」のエントリでも書いたが，ロバストネス分析の結果導き出されるクラスを図示することも大事だけど，正しいアーキテクチャが目の前にあれば，クラスの分割基準は決まりきった状態になっている。設計書を結局書かなかった，とか，クラスの粒度やテスト基準がバラバラで保守不能，という結果にならないためにも，書くべき設計書を見つけた根拠，そして作成すべきクラスを見つけた根拠として，ロバストネス図を一過性のものとせず，プロジェクトの大事な成果物の一つとして重要な位置付けにすべきではないだろうか。
