モデリングとTDD

PHPのUMLモデリング用ツールでラウンドトリップ対応しているものはあまり見かけないのですが、これはたぶん、PHPの記法的に対応しにくい書き方が許されてしまうからではなかろうかと。そのため、PHPな現場でのモデリングツールの使い方としては、ウォーターフォールな開発フローの時は使えても、更新や変更の多い現場には向かないです。
新しいことや面白いことを開発していくときのモデリングは、マインドマップ図のように発案をサポートする機能としてモデリングツールを使いますが、ビジネスとしてのシステム開発では、ビジネス上のワークモデルをデッサンすることが基本になります。大きな構図から始めつつ詳細な素描を行い、そこにある無駄と無駄のある理由を解析して、同じ結果を生み効率の良い別なフローを提案します。
ここで発揮される力は、個人の卓越したコーディング能力とは別の何かが必要であるように思います。
最近感じているのは、モデリングツールで詳細設計を書きすぎない方がいいんじゃないかと。UMLモデルでも詳細レベルの設計を行うことはできるのですが、詳細設計というのは、多分にコードと密着している部分が多いので、モデリングを行う人物がシステムの詳細設計レベルへの適応を持っている必要が出てきます。通常は、設計と実装であれば、設計に従って実装するのが基本なはずですが、詳細レベルでは実装上の適合性はプログラム側で発見しやすいので、設計にフィードバックしないといけないという事情もあります。ここにワークフローの逆流を作るのはもったいない話です。詳細設計レベルのモデリングはコーディングそのものなので、そこまでモデラーがやるなら、いっそモデラーがコードを書いた方が早いように思います。ようするに、ある粒度に来たら、モデル図からコードに権限を委譲すべきです。「誰が」というのは関係なく。
逆に、TDDで大きな枠組みでの結合テストを書いていくと、テストケースが多すぎてテストが読みズラくなるとかそういうケースが見受けられるように思います。これは詳細設計がうまければ発生しない問題とはいえ結合テストの弱点であることは事実だろうと。
設計の粒度としてベーシックな部分はUMLモデルで、そこから先の詳細設計はテストケースで表現していったほうがいいんではないか。TDDがもたらしている効率のいいところと、モデリングのもたらす効率のおいしいところを組み合わせるのが上手い手ではないかと。
そこで、「結合テストなんていらない」とか、「詳細モデリングなんていらない」とか、言ってみようかと。
参考)「結合テストはでたらめだ」- J.B.Rainsberger氏による連載の紹介