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

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

どうも、あかさたです。前回は「これまでの分析設計を確実に Rails での開発につなぐこと」をテーマに、ER 図の作成方法を紹介しました。今回も同様の視点から作成したモデルを実装に変換する手順について紹介します。

前回までのおさらい

前回までで、要求ドキュメントなどから以下のフィーチャモデルと ER 図を作成しました。

フィーチャモデル

ER 図

また、4 回目の記事でフィーチャモデルを検討した際に、「acts_as_authenticated」プラグインを利用することと、記事の CRUD を効率よく実装するために、「Rails のジェネレータ」を使って、scaffold を生成することを決定しています。

モデルを実装に落とし込む作業の流れ

モデルを実装に落とし込むということは、レールに乗って作り込みを開始できる状態にするということです。手順については以下の図を参照してください。

まずは、フィーチャモデルを検討した際に選択したプラグインなどの既存資産を適用します。（本記事では、「acts_as_authenticated」プラグインを適用することを決めています。本プラグインはジェネレータを内蔵しており、新しくモデルが作成されます。）

次に、ER 図をソースコード（モデルと DB）に変換します。ER 図を実装に落とし込む詳しい手順については後述します。ER 図からモデルと DB を作成したら、必要に応じて scaffold の生成などを行い、その後は、レールに乗ってユースケースや画面設計で決めた内容の作り込みを開始します。

ER 図を実装に落とし込む

以下の手順で ER 図を実装に落とし込みます。（本記事の内容は、Rails 1.2.6 に対応しています。）

1. モデルを作成する
2. マイグレーションファイルを作成する
3. モデルに関連を定義する

まずは、モデル名を決めます。モデル名は、そのまま英語化して「ブログ記事 -> Article」「認証ユーザー -> User」でいいでしょう。決めたモデル名に従って、Rails のジェネレータでそれぞれのモデルを自動生成してください。

次に、ER 図で定義した Attribute をこのマイグレーションファイルに反映させます。ここでは、Article モデルを検討します。Rails のジェネレータで「Article」モデルを生成すると、「001_create_articles.rb」というマイグレーションファイルが作成されるので、このファイルに ER 図で定義した Attribute を DB のカラムとして反映させます。

ER 図の内容と Rails の命名規約に従って、Attribute 名を決めてください。モデル名と同様英語化して、「ID -> id」「タイトル -> title」「記事内容 -> content」「投稿日 -> posted_at」「ライターID -> user_id」「公開状態 -> status」というように定義することができます。（「user_id」は外部キーで、「Article」と「User」の間の Relationship を実現するために必要です。）カラム名を検討した時に、それぞれの型も決定してください。

決めた属性名をマイグレーションファイルに反映します。これで、DB スキーマの定義は完了なので、マイグレーションを実行してください。

class CreateArticles < ActiveRecord::Migration
  def self.up
    create_table :articles do |t|
      t.column "title",         :string,     :default => "", :null => false
      t.column "content",       :text,       :default => "", :null => false
      t.column "posted_at",     :datetime,                   :null => false
      t.column "user_id",       :integer,    :default => 0,  :null => false
      t.column "status",        :integer,    :default => 0,  :null => false
    end
  end

  def self.down
    drop_table :articles
  end
end

最後にモデルに関連を定義します。ER 図では、「Article」と「User」の間の多重度は「多：1」となっています。「Article」から見ると、「User」は 1 ですから、「belongs_to」を使って、関連を定義します。（多なら、has_many を使用します。）

class Article < ActiveRecord::Base
  belongs_to :user
end

以上で、モデルを実装に落とし込む作業が完了します。ここから先は完全にレールに乗って作り込みを開始することができます。

まとめ

今回は、「Rails 上で作り込みを開始するための最後の作業」として、モデルを実装に落とし込む手順を紹介しました。記事の都合上、流れ作業的に記述しましたが、実際にはそれぞれの作業を行ったり来たりしながら進めます。

例を挙げると、フィーチャモデルの検討で scaffold を使用すると決めた場合、モデルがないと scaffold の生成はできませんから、ER 図をソースに反映させてから、フィーチャモデルの検討結果をコードに反映することになります。
逆に、フィーチャモデルを検討した結果使用することになったプラグインがモデルを生成することもあり、ER 図の作業に影響を与える場合があります。
このように、フィーチャモデルを実装に反映してから ER 図を反映というような奇麗な流れにならないことに注意してください。

また、モデルからコードへの変換作業は、機械的な作業なので、悩むところはあまりないと思いますが、Rails の規約を把握していないとスムーズに進めることはできませんので、注意してください。

次回で本連載は終了の予定です。次回は、Rails とモデリングを総括します。それでは！