Ruby on Rails によるシステム開発をモデリングで効率的に行う

• 概要編
• 分析・設計編（ユースケース図とユースケース記述）
• 分析・設計編（フィーチャモデリング）
• 分析・設計編（フィーチャと解決領域のマッチング）
• 分析・設計編（ER 図）
• 分析・設計編（ER 図の実践）
• 実装編（モデルを実装に落とし込む）
• まとめ

連載の概要

本連載では、一般的な題材としてブログを開発してみたいと思います。モデリングが主眼なので、凝ったものを作るつもりはありませんが、それなりにモデリングが必要になるように、複数ユーザを管理することができて、認証と認可を持ったブログを開発します。

モデリングプロセスは以下のような流れを想定しています。これまで直感に任せてきた部分を少し明示的に行うようになります。

本連載におけるプロセス

本プロセスは、以下の三点に留意して策定しています。

• 何を開発するのかを明らかにする
• 既存の資産（プラグイン）を活用しやすくする
• DB の設計をしっかりと行う

まず、「何を開発するのかを明らかにする」についてです。Rails は「何を作るのか決めてからがすごいフレームワーク」ですから、何を作るのか明示的に決めるために、代表的な手法であるユースケースモデリングを使用します。

次に、「既存の資産（プラグイン）を活用しやすくする」についてです。これは、フィーチャモデリングを行うことで対応します。おそらく、モデリングに詳しくない人にとってはフィーチャモデリングは聞きなれない言葉だと思います。ソフトウェアプロダクトラインという手法で使われています。

Rails の生産性を上げる特徴として、豊富なプラグインが挙げられます。認証もタギングも国際化もプラグインが存在します。しかし、そのアプリケーションでどのようなプラグインを要求しているのか認識する必要があります。本連載で詳しく紹介しますが、フィーチャモデリングは、そのアプリケーションがどのようなプラグインを要求するのか認識する場合に有効です。

最後に「DB の設計をしっかりと行う」についてです。これは、ER 図を作成することで対応します。DB スキーマさえ作ってしまえば、Rails の開発は試行錯誤をしながらも進めることができます。DB は必須ですから、もっとも重要な作業といえるかもしれません。

次回は、ユースケースモデリング（ユースケース図の作成とユースケース記述の作成）の解説を行います。それでは！