最近、
八角研究所で技術記事を書いているのですが、そこで、Ruby on Rails の開発を潤滑に進めるために、モデリングを含めた開発プロセスを架空の事例に適用して紹介した連載記事を執筆しました。
この連載を書いた理由を簡潔に述べると、そろそろ Rails も平凡なエンジニアにとって使いやすくなるようにいろいろな道具立てをそろえていかないといけないと考えたからです。
最近、「Rails や Ruby 界隈の VB 化(別に Java 化でも Struts 化でも良いですが。)」というような話が語られています。入門時に敷居の高さを感じさせる Ruby ですが、Rails によってその敷居が低くなり、さまざまな人が Ruby/Rails に参入できるようになりました。私もまた参入した一人です。これを VB 化というとすれば、Ruby が世の中で重要なポジションを占めるようになってきた一つの証拠と言えます。
もし Rails や Ruby の世界が VB 化していくとすれば、平凡なエンジニアでも安定した品質でシステム開発ができるようになるさまざまな「仕掛け」が必要になります。その仕掛けの一つに分析・設計時のモデリングが挙げられます。しかし、Rails のようなアジャイルなフレームワークでは、重厚な開発を連想させるモデリングと組み合わせて語る人はあまりいません。
Rails は身軽に素早く開発できるのが魅力のフレームワークである以上、一般的な UML の本などに載っているモデリングを絡めた開発プロセスは重すぎます。Rails が対象としているような「小さなシステム」にもふさわしくありません。
そこで、Rails にふさわしい軽量で使い勝手のいいモデリングプロセスを考えてやり方を整理した連載を書くことにしました。
連載記事「Ruby on Rails によるシステム開発をモデリングで効率的に行う」
(1) - 概要編
(2) - 分析・設計編(ユースケース図とユースケース記述)
(3) - 分析・設計編(フィーチャモデリング)
(4) - 分析・設計編(フィーチャと解決領域のマッチング)
(5) - 分析・設計編(ER 図)
(6) - 分析・設計編(ER 図の実践)
(7) - 実装編(モデルを実装に落とし込む)
(8) - まとめ
本ブログ内の関連記事
Rails 開発者こそモデリングするべきだって思った
また、今回敢えて記事名に「効率的」という言葉を入れました。実は、Rails を導入するだけでは効率的な開発はできません。Rails には有用な機能がたくさんあり、有用なプラグインがたくさんあります。既存の資産を最大限活用することで、Rails は本当の意味で高速に開発できるフレームワークとして機能します。
本連載では、明示的に既存資産の再利用を検討する工程を含めることで、ある程度効率性を高めることを狙いました。
■ この記事がカバーできていないこと
ソフトウェア開発のコストの多くは、分析・設計工程(仕様の策定)とデバッグ・テストで消費されます。本連載では、分析・設計工程にフォーカスを当てているため、Rails の真価を発揮するには別にテスト技法を調査する必要があります。そうした連載もいずれ書いてみたいと考えていますが、Rails のテストについて私は詳しくないので、追って調査したいと思います。
また、クライアントに Ajax や Flash を用いて複雑な UI を構築するような場合に使えるモデリング技法もカバーしていません。これに関係する話題は、このブログでは以下の記事で触れていますが、十分ではありません。
ウェブアプリで画面に関するモデリングはあり得るのか考えてみた
複雑な GUI を持つアプリケーションの設計について(Web アプリ編)
それぞれのモデリング手法について掘り下げることもできませんでした。特にデータモデリング(ER 図)は少なくとも一冊専門の書籍を読むことを強くお勧めします。(ここを読んでいるような方は何かしら読んでいると思いますが。)
本記事の手法は別に Rails 固有というわけではなく(そのため実装との関係が薄くなっている面もある)、「小さなシステム」を対象とした Seasar2 でも django でも使えると思いますが、検証はしていません。
■ 蛇足
私が開発しているモデリングツール
Kodouguにて、「RoRModeling」というメタモデルを使用すると、本連載のモデリング手法をカバーしたモデリング言語を使用することができます。
■ 八角研究所で書いた記事
平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみた
ユースケース図の include、extend、汎化について書いてみた