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

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

どうも、あかさたです。前回は、効率的な開発を検討するための最初のステップとして、フィーチャモデルの作成方法を紹介しました。今回は、このフィーチャを解決領域の技術要素にマッチングする方法を紹介します。

前回のおさらい

前回は、「意識して効率的な開発を行う」ために、以下のように既存資産の活用を手順化し、(1) と (2) について説明しました。

1. 要求を「既存資産の再利用の検討」をしやすい形式にまとめる（フィーチャ・モデリング）
2. 既存資産・フレームワークの機能などを整理する（解決領域の分析）
3. 要求と既存資産のマッチングを行う

そして、「ブログ記事を投稿する」「ブログ記事を公開する」「ブログ記事を閲覧する」ユースケースからフィーチャモデルの作成を行いました。「記事管理（記事の CRUD）」、「認証」、「管理（Admin 画面）」が、「八角ブログ」が持つフィーチャとして抜き出されました。

今回は、「(3) 要求と既存資産のマッチングを行う」について説明します。

要求と既存資産のマッチング

解決領域の分析結果を受けて、それぞれの問題領域のフィーチャの解決方法を検討します。

「記事管理」フィーチャについては、「Rails のコードジェネレータ」を使って、記事の Model と Scaffold を生成することで、画面作り込み前の状態まで作成できます。「管理」は、対応するプラグインがないこともないのですが、定番といわれるようなものは存在していないので、一から開発することになるでしょう。「認証」ですが、「acts_as_authenticated」プラグインで対応できます。このプラグインは認証機能を自動生成するジェネレータを持ちます。

このように、Rails では一から開発するケースはそれほど多くないので、既存資産を賢く活用してください。また、今回は既存資産の再利用という観点からのみフィーチャを検討しましたが、非機能要求全般の観点から検討することもできます。以下のフィーチャモデルを参照してください。

「記事管理」に「一日のページビュー 100 万以上の処理能力」というような非機能要求がある場合です。「100 万 PV/日」をフィーチャとしてとらえてパフォーマンスの観点から分析します。ページビューなら、解決領域上の技術としては「Rails のキャッシュ」が候補になるでしょう。今回の記事では対象とはしませんが、フィーチャモデリングは非機能要求が複雑な場合にも便利なので、ぜひ活用してください。

まとめ

本記事の肝は、何が何でもフィーチャモデリングをするということではありません。既存資産の再利用や非機能要求の検討を行うステップを明示的に儲けることで、適切な品質のシステムを効率よく開発することを一番大切にしています。本記事では、比較的メジャーな手法であるフィーチャモデリングを切り口にしました。システムの重要度に応じて、もっと簡略もしくは詳細な手法を採用するようにしてください。

本記事では詳しくふれませんでしたが、フィーチャ・モデルの書き方を詳しく知りたい方は、こちらの記事（@IT）がお勧めです。

次回は、DB 設計のために ER モデリングを紹介します。それでは！