ユースケース駆動ではなくロバストネス駆動開発？

「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。

【参考1】
天使やカイザーと呼ばれて ≫ ロバストネス駆動開発？

天使やカイザーと呼ばれて ≫ ロバストネス図113枚!!

OOAD講座：第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking

ロバストネス図の使い道: プログラマの思索

ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。
この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。
確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。

ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。
単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バッチ処理があったりすると、ラフな設計がいるのだろう。

【参考2】
ソフトウェア開発の匠（1）：「ITエンジニアは職人気質を取り戻すべき」 (2/3) - ＠IT

ソフトウェア開発の匠（1）：「ITエンジニアは職人気質を取り戻すべき」 (3/3) - ＠IT

ユースケースの疑問: プログラマの思索

UML再考: プログラマの思索

ユースケースの善し悪し: プログラマの思索

でも、萩本さんの記事によれば、「ロバストネス分析に多大な工数をかけたが成果が出ない」という問題もある。

(引用開始)
ロバストネス分析から、シーケンス図などを使って動作検証を図り、分析モデルを作り上げる作業までには多くの工数を要した。
しかし、その結果作成された分析モデルは設計モデルにつながりにくく、何のためにシーケンス図などを使って検証したのか、作成したエンジニアたちにも分からなかった。

（1）ユーザーも開発者も理解しづらい産物を作りかねない
（2）分析モデルを作るまでに多くの工数を要する
(引用終了)

オブジェクト指向分析(OOA)の弱点は、分析モデルと実装モデルの乖離があるために、実装モデルに辿り着くまでの工数が大きくかかることだろう。
分析麻痺症候群に陥りやすい弱点があるのではないか。

概念モデル→論理モデル→物理モデルみたいな流れだと、中間成果物がやたらと増える。
しかもその成果物の保守も大変。

ロバストネス図がユースケースとクラス図の間を結ぶミッシングリンクであることは分かるが、仕様変更やソース修正と同じタイミングでロバストネス図も保守していくのは結構大変だ。
つまり、ロバストネス図も設計書やソースと同じく、構成管理の配下に置くべきである。
しかし、構成管理と連動したモデリングツールは結構使いづらい。

但し、astahは個人的には設計のスケッチツールとして使いやすいし、Subversionと連携して構成管理も可能だ。

【3】ロバストネス駆動開発は、個人的には結構イケているのではないか、と思ったりする。
簡単に書けるし、書いていくうちに、処理の粒度に気づいたり、他の人とのコミュニケーションにすぐに使えるからだ。

もう少し考えてみる。