開発者こそモデリングすべきだよなぁって唐突に思いました。スキーマの設計方法は教えてくれません。どんなソフトウェアを作ればいいのか教えてくれるわけでもありません。「何を作るか決めてからがすごいフレームワーク」なのです。分析工程は開発者自身が自分のやり方で実施しないといけないのです。何を作るのかを導き出すのはモデリングが得意です。アプリを記述するには重すぎる気がします。(少なくとも私はそう考えています。)往々にして、図解言語というものは、概要をとらえるには適していますが、詳細に書くと途端に見難くなります。実装レベルのシーケンス図などは、見るだけでも吐き気がします。向けにシンプルな分析工程を考えてみます。図)私が考える必須モデリングはこれだけです。一つ一つ見ていきましょう。要求モデルを作成する(ユースケース図もしくはフィーチャモデル)何を作るのか、ユーザサイドから見た場合、ユースケースはわかりやすいです。ユースケースの例をあげると、「ブログ記事を投稿する」とかそんな感じですかね。図だけではなく、ユースケース記述もしっかりと書くようにしたいところです。フィーチャも認識しましょう。コード生成はフィーチャ単位で行われることが多い」からです。フィーチャとは、機能を再利用の観点からまとめたものです。act_as_authenticated(認証機能のコードジェネレータ)などで生成されるコードの単位に近いです。使いやすい粒度にまとめるのがいいでしょう。認証、コメント、タギングなどさまざまなフィーチャを認識できると、既存の資産(プラグインなど)の再利用がスムーズに行えます。アプリケーション開発に再利用可能なさまざまなフィーチャを提供してくれているという言い方ができるかもしれません。図)ユースケース記述などを書くと、ある程度データモデルを記述できるはずです。クラス図は仕様が複雑で難しすぎます。クラス図は関連、関連端の誤記・誤読が多く、使いこなすにはそれなりのスキルが要求されます。図は、仕様が単純です。図を書きたい場合は、オブジェクトの広場のこの記事で触れられている「現場を助けるモデリング」の発表資料を参照してください。図のテストの仕方を紹介しています。試行錯誤可能なフレームワークであること」です。どこかの工程を完璧に完了することよりも、ある程度で進めて、早めにレールに乗ってください。レールに乗って試行錯誤することが、実は最短になるのです。開発対象範囲内において、要求ならユースケースやフィーチャの漏れがないこと、データモデルはテーブルの漏れがないことあたりが目安です。来月あたり、このエントリに関係する内容を八角さんのサイトで執筆するつもりです。