2009年7月8日水曜日

Reflective Ecore Model Diagram Editorの.ecoreサポートを実装

夏休みに入ってから開発を再開したReflective Ecore Model Diagram Editor (Dynamic GMF)。今日、ようやく.ecoreファイルへ対応することができました。

Ecoreファイル用新規作成ウィザード作成
このエントリに書いたように、従来の新規作成ウィザードを改造したことにより、XSDファイル以外のファイル形式に対応したウィザードを拡張ポイントを介して追加できるようになりました。そこでまず、Ecoreファイルをメタモデルとして指定可能な新規作成ウィザードを作成し、上記拡張ポイントに登録しました。以下のスクリーンショットは、新規作成ウィザードの1ページ目でウィザード選択ページです。XSDファイル形式だけでなくEcoreファイル形式も選択肢として表示されています。ユーザの選択に応じて、上記拡張ポイントに登録されたウィザードが次のページから表示されます。親クラスの指定が必要
GMFベースのグラフィカルエディタでは、ダイアグラムを描くキャンバスがモデルツリーの根オブジェクトに相当します。言い方を変えると、同エディタはモデルツリーの根オブジェクトを知る必要があります。上記新規作成ウィザードでは、指定されたXSDまたはEcoreファイルをメタモデルとして読み込み、根オブジェクトのクラスを特定した後、根オブジェクトを新規作成しダイアグラムエディタを起動します。

XMLスキーマの場合、同スキーマにvalidなXMLインスタンスは必ず一つだけルートエレメントが存在するようにスキーマが定義されているはずなので、エディタはスキーマを解析することで根オブジェクトのクラスを特定することができます。一方、Ecoreモデルの場合、メタモデルを解析しただけでは根オブジェクトのクラスを特定することができません。そこで、以下のようなルートクラス指定用ウィザードページを最後のページに用意しました。このアプローチは、EMFで自動生成できるツリーエディタの新規作成ウィザードとまったく同じです。その他実装を修正
あとはEMFが提供するモデルインポータを使って、.ecoreファイルをEcoreモデルに変換し、既存のグラフィカルエディタ実装に渡すだけです。XSDファイルであっても.ecoreファイルであってもEcoreモデルに変換した後は、直列化以外はまったく処理が同じです。

従来、変換されたEcoreモデルに関する情報をエディタ内部で参照する際には、MetaModelManagerという静的クラスを介して、あたかもグローバル変数のようにアクセスするという、ダサい実装になっていました。そこで、 上記MetaModelManagerの機能をEMFのアダプタとして実装しなおしました。これにより、Ecoreモデルに含まれる任意のメタオブジェクト(EClass、EReference等々)から上記アダプタを取得し、上記情報を参照できるようにしました。別の言い方をすると、拡張オブジェクトパターンを使ってサブクラス化することなく上記メタオブジェクトに機能を追加しました。

まだTODOあります
概ね問題なく動いているような気がしますが、少なくとも以下のTODOがあります。
  • 上記MetaModelManagerと同様、EcoreModelElementTypesというグローバル変数さながらの静的クラスがあります。(GMFによって自動生成されるグラフィカルエディタには全てこのようなXXElementTypesクラスが自動生成され利用されています。)ダサい実装を直したいところです。
  • この夏に初めて気がついた(!)のですが、GMFによって自動生成されるグラフィカルエディタには、モデルナビゲータなる機能を実装するコードも自動生成されます。本機能により、Project Explorer(Package Explorerではない)上にダイアグラムファイル(.xml_diagramや.xmi_diagram)が表示された場合、同ファイルに含まれるEMFオブジェクトをツリー上に表示させることができます。現状では、この機能がうまく動作していません。上記EcoreModelElementTypesと深い関連があり、同時に修正したいところです。
  • EMFに同梱されているReflective Ecore Model Editorと同様、.ecoreファイルを編集するエディタのコンテキストメニューから、Dynamic GMFを起動できるようにしたいです。
ひとまず、上記のうち3つ目を実装したら0.2.0としてリリースしつつ、他の二つをこなそうかな、と考えています。

0 件のコメント: