EoDフレームワーク？

Written on Jun 5, 2005. Posted in Java

お風呂で考えたことを書いてみる。

最近，EoDについて考える機会があった。「Ease Of Development」，つまり「開発を簡単に」という言葉だ。とかく世の中では，EJB3.0や，J2SE5.0に搭載されたAuto-Boxingやannotation，JSFなどがEoDとして取り上げられているが，システム開発の工程で考えると，それらのEoDは「微々たるもの」と思えてならない。EoDは局所的なものではなく，工程全体で考える必要がある。

EoDは，整理すると，3段階のEoDがあると，最近思い始めている。

要求を整理するためのEoD* 整理の結果をソフトウェアに落とすためのEoD* コーディングのためのEoD

顧客の要求は，ほとんどの場合全く整理されていない。顧客自身も，自分が言っている要求が自分たちの業務として正しいかどうかも半信半疑だったりする。各要求がそれぞれ相反するものだったりして，とてもシステム化できない状況が当然だ。でも，納期は日々短縮される。

そこで，業務分析をできるだけ実装に近い形で行うことが必要になる。これは，「『では，どうすればいいんですか』では見つからない」で語られている。現状理解を行い，それに基づいて「軸」と「箱」を決め，その「軸」に基づいて要求や問題点を整理していく。「軸」のおかげで，設計者も顧客も共通な「箱」に仕様を落とし込むことができる。この「軸」と「箱」は，もちろんドメイン超依存だ。

「軸」や「箱」は，そのままソフトウェアの構造(システムアーキテクチャ)に割り当てられるようになっていれば，結果として整理された仕様を即実装に落とせる。各仕様の「軸」が共通なので，「箱」を多態的に扱うことができるようになるからだ。つまり，導き出された「箱」を，StrutsのアクションクラスやChain Of ResponsibilityパターンのCommandなどに落とし込みやすくなる。

これが第1段階のEoDと言えるものだ。ドメイン超依存の「軸」と「箱」を定義し，それに対応するドメイン超依存ソフトウェアアーキテクチャを準備し，仕様の整理がそのまま実装に対応するようにする。これがうまくいけば，これほど効果のあるEoDはない。「基本設計→詳細設計→実装」という複雑な過程を経ることがないからだ。

一旦「軸」と「箱」を導き出して，それをソフトウェアアーキテクチャに割り当てられれば，「箱」に相当するものを実装者に手書きさせなくても，自動生成してしまえば良い。「軸」で整理された仕様を各種「箱」に落とし，「箱」の種別に対応するソフトウェアコンポーネントを自動生成させる。それは，Strutsのアクションクラスだったり，DAO関連のコードだったりするわけだ。さらに「箱」と「箱」のつながりまで見えていれば，例えばStrutsのstruts-config.xmlも出力できるかもしれない。

この自動生成が，第2段階のEoDだ。この自動生成は，現時点ではEclipseのプラグインとして作成するのが良いだろう。この自動生成プラグインは，ドメイン超依存，逆に言うと，必要とされてないものまで機能を持たせる必要はない。最低限「箱」さえ用意できれば，それでいい。「ドメインに応じた開発環境を開発する」にも書かれている。

あとは，実装者の前に提供された各「箱」に対して，命を吹き込む。J2SE5.0の新機能などを実装者が使いながら，効率的なコーディングを行う。第1，第2段階のEoDで「箱」は整理された形でソフトウェアコンポーネント化されているので，実装者は「いかに合理的なコードを記述するか」に専念すればよい。第3段階のEoD，つまり最近言われているEoDのほとんどは，この段階になって初めて効果が出るものだ。

開発を効率的に，合理的に，そして簡単にするためには，「分業」を進める必要がある。第1段階と第2段階のEoDは，「整理された形で細かく分割し，単純化する」作業であり，その結果「分業」の準備が整う。ソフトウェアコンポーネントは，種別ごとにコードの内容や作り方が異なるために，第3段階のEoDとして何を適用すれば一番効果がでるかを「箱」ごとに選択する必要がある(annotationが効くかもしれないし，Web層に対してJSFの適用が効果を出すかもしれない)。

「実装を楽に」という「軸」でソフトウェア開発の工程全体を考えた結果，「第3段階のEoD」が効果をあげるには「第2段階のEoD」ができていないといけないし，「第2段階のEoD」を行うには「第1段階のEoD」が必要である。これって，システム開発に対するフレームワークみたいなものじゃないだろうか。しいて言えば，EoDフレームワークか？これを「体系化力」と呼ぶとしたら，まさにこれこそがEoDな気がする。

何かと技術的な面が目立つEoDだが，結局は業務分析から実装がいかに簡単になるかを考え，そして分業が可能な実装作業の単純化を図らなければならないということが，EoDなんだと思う。実装になってから「実装を簡単に」では遅いってことだろう。

・・・と長々と書いてみて気がついたことがある。これって，普通にJ2EEアーキテクチャで言われていることだよな，きっと。