１）専用のモデリングツールを一から作る

 
　yacc/lex などを使って独自のパーサ（構文解析）とコンパイラを作ることが出来る。以前はこの手法が取られることはあったが、これには多くの時間と深い知識が必要なので、この手段を取る企業はもうない。
 

２）フレームワークをベースにして専用のモデリングツールを実装する

 
　一から全てを作る代わりに、ILOG JViews や Eclipse GEF や EMFなどのフレームワークを用いる。アプリケーションをビルドすることに等しい。主な欠点は、適正なツールを構築するまでに数年規模の工数が掛かってしまうこと。例えば商用レベルのUMLツールを作るだけでも25人・年必要（OOP conference で報告）。大抵の企業はそのような投資には耐えられない。
 

３）メタモデルからモデリングツールのスケルトンをフレームワーク上に生成、コードを追加

 
　２）を少しだけ前進させたのが Microsoft の DSL ツールや Eclipse GMF。メタモデルをベースにしてツールの骨格となるスケルトンを生成することで。しかしながらツールの細部全てを開発・実装する必要があるので、やはり多くの工数が必要。（コピー＆ペーストが出来るモデルエディタ、アンドゥー機能、再利用、モデル間の関連付け、マルチユーザ対応など）
 
　さらに大きな欠点は、ツールのサポートが保証されそうに無いこと。例えば、Eclipse GMF で作ったメタモデルを変更したらEclipse のエディタは既存モデルを開くことが出来なくなる。当然、開発資産を失いたくない企業にはお勧めできない。
 

４）メタモデルからフレームワーク上に完全なモデリングツールを生成する

 
　このレベル４のツールは存在しないので、あくまでも理論上のアプローチ。Eclipse GMF の当初の狙いは、このレベルであった。
 

５）メタモデルから汎用モデリングツールのコンフィグレーションデータを出力

 
　実装が必要となる１）～４）の手法に比較して、５）と６）ではツールを構成可能な機能が供給される。用意されたツールを用いてメタモデルを構成する。Wordによるスタイルの操作に似ている。スタイルをモディファイできるが、エディタ自体が変わることはない。各スタイルごとに異なるエディタを作れない。このレベルでは採用される汎用モデリングツール（UML）の制約を受ける。（メタモデルの進化に既存モデルが自動アップデートできない、ジェネレータの制限、モデルの表記など）
 

６）メタモデリングとモデリング環境の統合

 
　Wordであれば同じエディタ上で自分のスタイルを使用しながら修正することも出来る。同様に、MetaEdit+ではモデリング環境を使用しながらでもメタモデルに手を加えて直ちに既存モデルへ反映させることが出来る。
 
　最良のツールは僅かな労力・工数で、モデリングツールとコードジェネレータを構築できる。カテゴリー６）に属するMetaEdit+は、数日から数週間で独自のモデリングエディタとジェネレータを構築できるし、その作業をイテレーティブに支援できる。良きツールに大事なことは進化を支援できること。メタモデルや言語を変更してもモデリングツールや既存モデルが自動的にアップデートされること。
 

ドメインスペシフィックモデリングにMetaEdit＋が選ばれる理由

 

完全な統合環境であり既存ツールチェインとも連携できる	MetaEdit+ は、モデリング・メタモデリング・ジェネレータ（コードなど）が完全に統合されたツール。 また MetaEdit+ API は、オープンな SOAP / Web Services / .NET を採用し、既存ツールと連携できる。
ドメイン・スペシフィック モデリング言語の進化をサポート	DSM環境への修正・拡張が容易で、既存モデルは自動的にアップデートされ、破壊されることがない。
マルチユーザ環境	異なるホストプラットフォーム、アクセス権限下でマルチユーザによるモデリングをサポート。
ベンダーに固定されない	あらゆるモデル・メタモデルをXML形式にて自在にインポート・エクスポートできる