GME

私がリサーチアシスタントとして参加している研究プロジェクトSASSY(Self-Architecting Software SYstems)では、GME(Generic Modeling Environment)というモデリングツールをベースに研究を進めています。
私は渡米してから初めてGMEを知りました。GMEを使ったことがある日本人は私だけかも？

GME = (EMF + GMF) / 2 ?
GMEはVisual C++で実装されているためWindowsのみで利用可能なスタンドアローンツールです。乱暴に一言で表現すると、GMEはEMFとGMFを足して2で割ったようなもの、という感じです。
GMEはMDAで言うところのM2レベルのモデル実装を提供していて(EMFで言うところのEcore)、それを用いてユーザがDomain Specificなメタモデルを定義することができます。GMEの大きな特徴は、いったんユーザがメタモデルを定義すると、ゼロコーディングかつコードを一切生成することなく、そのインスタンスモデルのグラフィカルなエディタを提供します。この点において、メタモデルからソースコードを生成するEMF/GMFとは大きく異なります。GMEは、強いて言えば、私が2007年に公開した「Reflective Ecore Model Diagram Editor」と同じコンセプトです。

たとえば、以下のようなメタモデルを定義し、インスタンス化可能なクラスに対してアイコンを指定します。
すると、以下のようなインスタンスのグラフィカルエディタを利用可能になります。
エディタ上の視覚効果を意識したM2モデル実装
GMEは（のちのちご紹介しようと思っていますが）独特なM2モデル実装を提供していて、純粋なEMOFの実装をしているEcoreとは全く異なります。EMF/GMFでは、ドメインを定義するモデルそのものとエディタ上での視覚効果を定義するモデルはそれぞれEMFおよびGMFに完全に分離されています。一方、GMEでは上記のように、メタモデルからグラフィカルエディタをコードの生成なしに提供するため、M2モデル実装が同エディタの視覚効果を意識せざるを得ない状況になっています。たとえば、クラス一つに対しても、GMEではFCO(First Class Object)、Model、Atomという3種類のクラスがM2レベルで定義されています。Modelは他のModelまたはAtomをコンポジションとして子供を持つことができ、Atomは子供を持つことができないクラスです。FCOはModelおよびAtomの両方を抽象化する親クラスです。ユーザはこの3種類のクラスを使い分けることにより、クラスの種類に応じてグラフィカルエディタの挙動をコントロールすることができます。一方、本来クラスとはクラスであって他の何者でもないはずなので、最初にGMEのM2モデルに触れるときはかなりの違和感を感じてしまいます。EMFに慣れ親しんできた私にとって、GMEはかなりとっつきにくいものでした。

GMEはEclipseに移行中
GEMS(Generic Eclipse Modeling System)というプロジェクトにおいてその土台をEclipse/EMFに移行しようとしています。現在のバージョンは3.0-rc3。GMEが提供している独特なモデリングコンセプトのほとんどが削ぎ落とされてしまっていて、まだまだ移行段階という印象です。GMEのモデルファイルをGEMSにインポート可能にすることを目標に掲げているようですが、まだ実現されていません。