最終更新日: 2004 年 6 月 29 日
このチュートリアルは、『EMF モデルの生成』 (簡単な library モデルの生成について説明) の続編です。『EMF モデルの生成』チュートリアルでは、Rose モデルまたは Java インターフェース・ファイルのセットから EMF モデルを簡単に生成する方法を 紹介しました。このチュートリアルでは、既存のモデルを拡張する EMF モデルを生成する方法について説明します。
まず、以下の図で library モデルを再度確認してください。
本チュートリアルでは、schoollibrary という新規パッケージを作成することによって、 この library モデルを拡張します。このパッケージには 3 つのクラスが含まれ、 そのうちの 2 つは以下のように library モデルのクラスを拡張します。
このチュートリアルでは、すでに作成済みの library モデルを使用して、 この schoollibrary パッケージの EMF モデルを生成する方法について段階的に説明します。 『EMF モデルの生成』チュートリアルで示したように、Rose モデルおよび Java インターフェースのセット からこの新規モデルを作成する方法を紹介します。
スクリーン・ショットは、Eclipse SDK のバージョン 3.0 および EMF の バージョン 2.0 を使用したものです。
ステップ 1: | Rose からのモデルのインポート または 注釈付き Java を使用したモデルの定義 |
ステップ 2: | EMF モデルおよびエディター・コードの生成 |
ステップ 3: | 生成されたエディターの実行 |
ステップ 4: | エディターの変更 |
付録: | モデルを生成するための代替手段 |
この library モデルおよびエディターは、前の『EMF モデルの生成』チュートリアルで生成したものです。
これらのパッケージがリストされていない場合は、前のチュートリアルの操作を完了するか、 『付録』を参照して両方のモデルを一度に作成する方法を調べる必要があります。
Rose モデル・ファイル schoollibrary.mdl をご使用のワークステーションの任意のロケーションに保管してください。このファイルには、library パッケージと schoollibrary パッケージの両方が含まれています。
各種モデル間でパッケージを共有する場合、各パッケージはそれ自身の .cat ファイルに配置し、
それらを .mdl ファイルで参照するにとどめることを強く推奨します。ただし、
このチュートリアルに関しては、単一のモデル・ファイルで library
パッケージを単に複製して拡張します。パッケージが、単一の .mdl ファイル内に含まれている場合でも、外部の
.cat ファイルで参照される場合でも、生成プログラムは全く同じ振る舞いをします。
以下の操作を行い、ワークスペースに新規 EMF プロジェクトを作成します。
schoollibrary パッケージの注釈付き Java インターフェースを以下に示します。Rose ファイルからではなく、 これらのインターフェース・ファイルから生成プログラム・モデルを生成することができます。
SchoolLibrary.java
package org.eclipse.example.schoollibrary; import org.eclipse.example.library.Library; /** * @model */ public interface SchoolLibrary extends Library { /** * @model */ String getLocation(); }
Asset.java
package org.eclipse.example.schoollibrary; /** * @model */ public interface Asset { /** * @model */ float getValue(); }
SchoolBook.java
package org.eclipse.example.schoollibrary; import org.eclipse.example.library.Book; /** * @model */ public interface SchoolBook extends Book, Asset{ }
ワークスペースに新規 Java プロジェクトを作成します。
前のチュートリアルで示したようにインターフェースを用いて作成および入力することも可能ですが、 ここではその代わりに ZIP ファイル schoollibrary.zip からこれらをインポートする方法を紹介します。このファイルを ご使用のワークステーションの任意のロケーションに保管してください。
以下の操作を行って、EMF モデルを作成します。
生成プログラム・モデル genmodel は、モデルの全体を表すルート・オブジェクトを表示します。 このモデル・オブジェクトの子は、モデル内のパッケージを表します。
このコードは、生成される際に自動的にコンパイルされ、 変更が行われると再コンパイルされます。ワークベンチ設定で自動ビルドを使用不可にした場合は、 コードを変更する際に必ず再ビルドすることを忘れないでください。
新規プラグインをテストするには、Eclipse の 2 つ目のインスタンス (ランタイム・ワークベンチと呼ばれます) を起動する必要があります。プラグインはこのワークベンチで実行されます。
ここで、「Schoollibrary モデル (Schoollibrary Model)」ウィザードを使用して、モデルの新規インスタンスを作成することができます。
このエディターのルート・オブジェクトは、「My.schoollibrary」リソースに対応します。 このリソースの下にあるオブジェクトが school library であるという点に、ご注目ください。
ランタイム・ワークベンチを終了し、元の開発ワークベンチに戻ります。
このセクションでは、生成されるコードを変更する方法を説明します。生成されたエディターでラベル の変更を行うだけですが、いくつかの異なる実例を示すような方法でやってみましょう。
まず、生成プログラム・モデルで変更を行います。 これにより、生成されるコードが影響を受けます。
生成されたファイルのタイム・スタンプを調べて、実際に SchoolLibraryItemProvider.java だけが再生成されたことを確認できます。
以下の表に、さまざまなオブジェクトのコンテキスト依存メニューにある 「モデル・コードの生成」、「編集コードの生成」、および「エディター・コードの生成」 メニュー項目によって生成されるファイルの要約を示します。「すべて生成」メニュー項目は、 これら 3 つのメニュー項目をすべて選択した場合と同じ働きをします。
モデル・コードの生成 | 編集コードの生成 | エディター・コードの生成 | |
モデル <M> |
plugin.xml <M>Plugin.java * ...および、各パッケージ用のファイル |
plugin.xml plugin.properties <M>EditPlugin.java ...および、各パッケージ用のファイル |
plugin.xml plugin.properties <M>EditorPlugin.java ...および、各パッケージ用のファイル |
パッケージ <P> |
<P>Package.java <P>PackageImpl.java <P>Factory.java <P>FactoryImpl.java <P>Switch.java <P>AdaptorFactory.java <P>ResourceImpl.java * <P>ResourceFactoryImpl.java * <P>Validator.java * ...および、各クラスおよび enum 用のファイル |
<P>ItemProviderAdaptorFactory.java ...および、各クラス用のファイル |
<P>Editor.java <P>ModelWizard.java <P>ActionBarContributor.java |
クラス <C> |
<C>.java <C>Impl.java |
<C>ItemProvider.java | |
Enum <E> | <E>.java |
* これらのファイルは、デフォルトでは生成されません。
これで、変更個所のテストを行う準備が整いました。
ここで、ラベル内の接頭部「School Library」が気に入らないので、それを取り除きたいものとしましょう。 これを行う唯一の方法はコードを編集することですが、この変更は簡単に行うことができます。
『EMF.Edit フレームワークの概説』で説明したとおり、EMF.Edit が項目プロバイダーを使用して行うことはさまざまありますが、ことに、特定タイプのオブジェクト用にどのラベルを表示するか の決定を行います。具体的には、この処理を行うのは getText() メソッドです。 ここでは、そのことを変更する必要があります。
先ほど、getText() の実装を、生成されたときの元の状態から変更しました。 これにより、生成プログラム・モデル内の SchoolLibrary クラスのラベル・フィーチャー・プロパティーが、 生成されたコードに影響を及ぼすことがなくなりました。これは、@generated Javadoc タグを除去したことにより、 コードの生成中にこのメソッドが上書きされることがなくなったためです。
ここで、エディターがロケーション属性または名前属性の値のどちらかを 表示するかをまだ決めていないとします。代わりに、後ほど生成プログラム・モデルを介して この値を変更できるようにしたいとします。ただし、「School Library」接頭部は 表示させないようにします。基本的な意図としては、生成された実装を、すべての戻りからこの接頭部を除去する 手書きのメソッドによって、使用可能に保ちたいものとします。新規メソッドの名前は「getText()」 にする必要があるため、生成されるメソッドの名前を変更する必要があります。
幸いなことに、EMF コード生成プログラムでは便利な機能がサポートされており、 生成するメソッドが、@generated タグを持たないメソッドと競合する場合に、 コード生成プログラムは同じ名前に「Gen」という接尾部が追加されたメソッドを検索します。そのメソッドが 存在し、しかも「@generated」タグを持つ場合、代わりにこのメソッドに実装が生成されます。
生成プログラム・モデルに戻り、ラベル・フィーチャー・プロパティーを変更し、 コードを再生成して、生成されたコードに実際に影響が及ぶことを確認できます。
自身のエディターによって別のプロジェクトに生成した基本 library モデルがまだない場合は、library モデルおよび schoollibrary モデル の両方を、単一のステップで同一のプロジェクト・セットに生成することができます。これは、Rose モデルから行うことも、注釈付き Java インターフェースのセットから行うこともできます。
Rose モデルを用いて処理を開始した場合は、上記と同じ操作を行います。 ただし、この場合はコードを生成するために両方のパッケージが選択されます。
注釈付き Java インターフェースを用いて処理を開始した場合は、 両方のパッケージが単一の Java プロジェクトにインポートされてから コード生成が実行されます。
ランタイム・ワークスペースを起動して新規エディターをテストすると、library モデルを schoollibrary モデルとは 別に生成した場合と比較して、library モデルに関してエディターで 1 つ小さな違いが 生ずることに気付きます。
前のチュートリアルでは、使用できる子は 2 タイプだけでしたが、 使用可能な子が 3 タイプになっていることに、注目してください。 特に、schoollibrary パッケージから「School Book」が組み込まれました。前のチュートリアルでは、 コード生成プログラムは Library の項目プロバイダーの生成時に「School Book」を 認識することができませんでした。今度は、2 つのパッケージが共に生成されたため、 基本パッケージは、自身を拡張するパッケージに関するすべての情報を認識します。