UML 2.1の本を読み、アジャイル開発を得意とするWebフレームワークとUMLでの開発の住み分けおよび適合度が気になった。特にRuby on Rails。なので、検索結果のメモ。
八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（1） - 概要編
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（2） - 分析・設計編（ユースケース図とユースケース記述）
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（3） - 分析・設計編（フィーチャモデリング）
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（4） - 分析・設計編（フィーチャと解決領域のマッチング）
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（5） - 分析・設計編（ER 図）
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（6） - 分析・設計編（ER 図の実践）
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（7） - 実装編（モデルを実装に落とし込む）
- 八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（8） - まとめ
何を作るのかを考える場合、モデリングはよい道具になります。しかし、一般的な UML 本などに載っている開発プロセスなどは、重厚すぎて Rails を対象とするような小さな開発を行う際に、コストの面で不安があります。本連載では Ruby on Rails 用に使用する図や手順を絞り込んだ実用的なモデリング手法を、実際に Rails アプリケーションを作成しながら紹介します。
（八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（1） - 概要編より）
Ruby on Rails を使った開発に限った話ではありませんが、素晴らしい生産性を発揮する人がいます。優秀なフレームワークを使っていても、そこそこの生産性しか発揮できない人もいます。プログラミング能力や設計能力（内部・外部問わず）の差かもしれません。しかし、私はその差は次の二つの理由も外せないと考えています。
一つは、「何を作るのかイメージできない」ことです。この問題に対しては、前回の記事にて、ユースケースモデリングを通して対処する方法を説明しました。もう一つの理由は、「どうすれば少ないコストで作れるか検討するステップがない」ことです。
（八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（3） - 分析・設計編（フィーチャモデリング）より）
Rails には Convention over Configuration（設定より規約）という考え方があるためです。規約に沿った開発をすることで本来必要なはずのさまざまな設定を省略することができます。このため、ER 図にとっては、やや不適切な命名となってしまう場合があります。
（八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（6） - 分析・設計編（ER 図の実践）より）
また、本連載で紹介したモデリングプロセスは一般的なウェブアプリケーションを開発する際には有効でしょうが、Ajax、AIR、Silverlight などを駆使した複雑な UI を持ったアプリケーションの開発時にはあまり助けにならないでしょう。本モデリングプロセスはサーバーサイドによりすぎていることに注意してください。
言うまでもなく、大規模な案件はカバーしていません。RUP のような重厚なプロセス（RUP もやり方によっては軽量に運用できますが）を採用する方がいいでしょう。Rails がそれに適しているかどうかはわかりませんが。
django、Merb などの他の軽量なフレームワークであれば、本モデリングプロセスを使用することができるかもしれません。検討する価値はあるでしょう。
（八角研究所：Ruby on Rails によるシステム開発をモデリングで効率的に行う（8） - まとめより）
- マルチパラダイムデザイン - 序論 - ：第3回で紹介されていた。
- @IT：次世代開発基盤技術“Software Factories”詳解：第3回 長期的な要求を定義するフィーチャ・モデル：第4回で紹介されていたフィーチャーモデルの作り方。
- @ITデータベースエンジニアへの道：第2回 30分間データモデリング 〜ER図を描こう！〜：第5回で紹介されていた。
