Evolve:コンポーネントを使って、依存注入を改善

作者 Srini Penchikala , 翻訳者 編集部Ｎ 投稿日 2010年11月28日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

Modeling Tool ,

Java ,

Dependency Injection ,

デザインパターン ,

言語 ,

Architecture ,

モデリング ,

プログラミング ,

Agile ,

Object Oriented Design ,

UML ,

Patterns ,

設計

共有 |

原文(投稿日：2010/11/22)へのリンク

Evolve は、JavaBeansを作成、接続、実行できる軽量ツールであり、JavaBeansを完全なコンポーネントとして扱うことができる。開発者は、Evolveを使ってグラフィカルに JavaBeansを記述し、オプションでsetter や getterのJavaコードを生成できる。４つの主要な機能をサポートしている。 JavaBeansの作成あるいはインポート、これらをつないでもっと複雑なコンポーネントの作成、これらの再利用と進化、そしてこれらの実行である。 Evolveシステムは、以下のような部分からできている。

• コネクター付きのコンポーネント モデル: 階層的なコンポーネント モデルで、完璧なコネクターにより、簡単に、直感的に詳細な構造を表すことができる。
• Resemblance と Evolution: これら２つの構成要素がコンポーネントの再利用をサポートする。 Resemblanceは、コンポーネントの継承を実現するしくみである。 Evolutionは、この上にあり、既存のシステムの構造を元々の定義を破ることなく、再モデルできるようにしている。これらの機能により、システムの変形版を作成したり、テスト コンポーネントに切り替えたりできる。
• Backbone インタープリタ: Backbone は、コンポーネント言語であり、 Evolveで作成したプログラムを実行できる、実行環境でもある。それは、オープンソースのドメイン固有言語なので、JavaBeansは、コンポーネントとして動作し、コンポーネント モデルに従って、接続できる。インタープリターは、テキストファイルを読み込み、その命令を使って、Beansをインスタンス化し、繋ぐことができる。 JavaBeansは、 Backboneでも、Javaコードでも表現できる。しかしJavaBeansインスタンスを繋いでできた複合コンポーネントは、 Backboneでしか表現できない。
• UML2 接続エディター: これは、UML2のコンポーネント図とステート図を使って、コンポーネントを繋ぐのに使われるグラフィカルなエディタである。 JavaBeanコード ジェネレータは、オプションのコンポーネントであるが、 JavaBeansの setter/getterコードを定義し、生成するのに使われる。Evolve は、既存のBeansをインポートして、繋ぐのも簡単である。

Evolveは、モデルや構成の静的なエラーチェックができる。Evolveは、Evolution機能を使って、１つのシステムから様々な派生版を作ることができ、すべての置換えは、自動的にチェックされる。

Evolveバージョン1.0.2は、今週リリースされた。Evolveのランタイムは、Apacheライセンスに基づいて、オープンソース化されている。グラフィカルなツールは、商用版とコミュニティ バージョンがある。

InfoQは、Evolveフレームワークのクリエータである Andrew McVeigh氏に、製品のフィーチャと将来のロードマップについて聞いた。Evolveを開発した主な動機は、何かを尋ねると、氏は、いくつもの銀行用にカスタマイズする大きなコンポーネント ベースのエンタープライズ プロジェクトで働いていたときに、拡張できるように、ソフトウェアが必要とする方法を予測するのは、非常に難しかった。Evolveがその結論で、ソフトウェアの進化は、創造への平等な関係に基づいている。

InfoQ: Evolveは、これまでの依存性注入（DI）技術とどう違うのですか？従来のDIソリューションより、どのような有利な点があるのですか？

両方共、コンポーネントやbeansを繋げてシステムを作り、コンポーネントをテストするなどのために、コンポーネントを取り付けたり、はずしたりできます。同じように機能します。しかし、EvolveとDIには、大きな違いが2つあります。

一つ目は、Evolveは、コネクタ付きの完全なコンポーネント モデルを使っています。このために、システム内で コンポーネントが相互接続する 方法を記述するのが非常に容易で柔軟になりました。回路基板上でチップを繋いでいくのにちょっと似ています。DIでは、お互いに参照している２つのbeansを繋ぐのに問題があるとき、あるいはアーキテクチャで、動的な構造を表すのが難しいなどの場合に、適切なコンポーネント モデルが欠如していることに、益々悩みます。これがEvolveによる恩恵の１つですね。

2つ目の大きな差は、Evolveが2つの強力なコンポーネント要素を統合していることで、バージョン コントロール能力によって、アーキテクチャ レベルで効果的に設計ができることです。これらが高度な再利用と進化の機能を実現しているキーです。これらの機能を使って、基のコンポーネントを壊すことなくコンポーネントを進化させることができます。際立っているのは、Evolveを使って作ったソフトウェアは、常に拡張可能だ、ということです。拡張と生成が完全に一体になってます。

InfoQ: Evolveフレームワークを使って、典型的なアプリケーション開発プロセスを説明してくれませんか。Evolveを使わずに行うこれまでのアプリケーション開発プロセスと比べて、モデリング、設計、開発、テスト、そしてデプロイのようなフェーズが、どのように違って実行されるのか？という点ですね。

素晴らしい質問です。1つの試みとして、もしあなたの作った全てのシステムがアーキテクチャとコード間で完全なリンクを持ち、拡張できることが保証されていたなら、あなたの開発プロセスが、どう変わったかを想像してください。それが根本的に意味するところは、設計とコーディングが同じアクティビティの2つの面になり、そしてあなたは、いつでも拡張すなわち進化できることが分かっているので、アプリケーションの作成にもっとアジャイルなアプローチをとることができる、ということです。予め計画することがずっと少なくなりますし、開発をもっと自由なやり方でできるようになるわけです。

他に違う点は、コンポーネント モデルは階層的なので、非常に細かい粒度のコンポーネントを使うことができます。片やDIでは、アーキテクチャの中に管理するコンポーネントが多すぎるのは、問題でした。Evolveには、ズームインやズームアウトがあるので、いくつコンポーネントがあっても適切なレベルからシステムを見ることができます。

ええ、Evolveは、アプリケーションのどの部分にも、良く対応できます。このためにGWTタイプのものを作ったり、再利用したりするような細かい粒度のものにも、サービスを作るような粗い粒度のものにも対応できます。

InfoQ: Evolveのアプローチの制約は何ですか？

私は、単に、Evolveで開発するには考え方を変える必要があるのが、一番の問題と考えています。一般に認められた見識を持っている人は、アーキテクチャと実装は分離されている、とか拡張性は計画的に、作りこまれていなければならない、とか言うわけです。Evolveを使えばこのような問題が無い、ということを理解するのは本当に難しいです。

もっと明らかな制約としては、我々は、未だ我々のアプローチの上に、広範囲な統合フレームワークを階層化していないことです。一方、我々のアプローチの基盤は、非常に強力なので、何を作り上げることができるか、そしてそれが既存のツールキットとどのように違うかを理解することに、非常に興奮しています。

最後に、Evolveは、現在 setter注入を使用することが必要です。DIと違って、接続するときは、完全な柔軟性があります。そしてコンストラクタ注入は、明らかに一般的な場合には対処できません。たとえば、コンポーネントと他の複雑な構造間に、双方向のリンクがある時ですね。接続するときに特に複雑でない場合、あるいは制約のあるDI接続パターンになるときには、我々はこの制約を緩和しようと検討中です。

InfoQ: このプロジェクトの将来のロードマップを教えてください。

我々は、多くの開発者が一つのシステムにリアルタイムで協働できるようにする、チームバージョンは、終えました。Androidバージョンを開発して、モバイル用アプリケーションを作るのに、これら全ての機能を使えるようにします。最後にEvolveにおける進化と拡張性サポートは、プラグイン アーキテクチャを作るのに理想的なことが分かっています。我々は、重点的にこれを検討しています。