カスタムメタモデルに基づくDSLがあり、それがEMF/Ecoreに基づいています。私はどの解決策を選ぶべきかを理解しようとしていますが、どこにもまともな比較を見つけることができません。
誰かが私がどちらかを選択する必要がある理由がありますか?
私がこれまでに知っていることは、AcceleoはOMG標準化された言語を使用しているということですが、Xpandよりも使いにくいようです。
まず第一に、なぜAcceleoはXpandよりも習得が難しいと考えるのでしょうか。どちらの言語にも違いがありますが(たとえば、ブロックと区切り文字)、構造は非常に似ています。両方の言語のすべての要素について詳しく説明することはしませんが、たとえば、次のようなものの間にそのような違いは見られません。
«FOREACHmyAttributesASa»«a.name»«ENDFOREACH»
と
[for(a:Attribute | myAttributes)] [a.name /] [/ for]
どちらもテンプレートベースの言語であるため、まったく同じ構造になっています。AcceleoとXpandの主な違いは、AcceleoがOMGとツールの標準MOFM2TとOCLに基づいているという事実にあります。
私はXpandツールにあまり精通していませんが、それらのwikiで詳細を見つけることができます。反対側のAcceleoには、構文の強調表示、コードの補完、エラー検出、リファクタリングなどを備えたエディターが含まれています。また、デバッガー、プロファイラー、AntおよびMavenのサポートも含まれています。ジェネレーターを他のユーザーのEclipseプラグインとして簡単にデプロイしたり、通常のJavaアプリケーションのEclipseからそれらを使用したりすることもできます。Acceleoの詳細については、こちらをご覧ください。オベオネットワークのAcceleoのほとんどの機能をビデオで見ることができます(登録が必要です)。
最後に、Acceleoが活発に開発されている間に1年前に発生したxPandの最新のアクティビティ。必要に応じて、 githubでAcceleoの開発をフォローすることもできます。
ステファン・ベゴードー
免責事項:私はAcceleo開発チームのメンバーの1人です。
私は専門家ではなく、ちょっとした人です。
私の印象では、テンプレート言語だけが必要な場合は、Xpandが最適です。それ以外の場合は、Acceleoを選択してください。ただし、おっしゃるように、学習曲線は非常に急です。
テンプレート言語以上のものが必要なのはいつですか?私にとって、出力の構造(内容ではない)が入力の複数の独立した部分に依存している場合、それらはガスを使い果たしているように見えます。Acceleoに参加したくないが、これらのケースの1つがある場合は、入力言語から出力言語への途中で、おそらくルックアップを回避するために多くの冗長性を備えた、自動生成された「シム」言語を発明することを検討してください。テンプレート生成時。
私は完全に呼び出されたプロジェクトで古い2.xAcceleoを使用しており、新しいプロジェクトでいくつかのテストを行いました。言語は非常に使いやすいですが、新しいバージョンでは、スクリプトの言語が十分でない場合、Javaコードをテンプレートにバインドするのが少し難しくなります。
私は2.xの大ファンでしたが、3.xでは、それを機能させるために多くの問題を追加しました。たとえば、Eclipseリソースを処理するJavaコードを作成する必要があります。私はjunoにアップデートするときに完全に諦めました、私のacceleoプロジェクトはもう機能しませんでした、そして私は2日でそれを修正することができませんでした。箱から出して使いやすくなることを願っています。
基本的に主な違いは、ACCELEOは、モデルからテキストへの変換を定義するためのOMG(Object Management Group)標準であるMOFモデルからテキストへの変換言語の実装であるということです。したがって、これは、一般にMOF、UML、SysML、およびMDAを設計したのと同じグループによって設計された標準言語です。XPAndは、標準の前に存在していたと思う言語ですが、現在はそれとは異なります。
ゼロから始める場合は、Acceleoから始めてください。
私の場合、カスタムステレオタイプとステレオタイププロパティを持つカスタムメタモデル(UML2から派生)を使用します。AcceleoとXpandの両方のテンプレート言語を試しました。確かに、それらは構造と機能の点でかなり似ています。
ただし、大きな違いが1つあります(このユースケースではXpandがはるかに優れています)。Xpandテンプレートでカスタムステレオタイプを使用できます。Xpandエンジンは、すべてのステレオタイプに対して「最適なテンプレート/ルール」を見事に選択します(ステレオタイプ間の継承も考慮に入れます)。さらに、ステレオタイプのプロパティを取得するのは非常に簡単です。これらの2つの「機能」により、テンプレートは非常にエレガントでコンパクトで読みやすくなります。例えば:
«DEFINE myTemplate FOR MyUmlProfile::MyStereoType»
MyValue: «this.myStereotypeProperty» or simply: «myStereotypeProperty»
«ENDDEFINE»
Acceleoでは、同じこと(ステートメントが長く、コードが多い)を実現するのが不器用で、テンプレートが長く複雑になってしまいました。ただし、Acceleoの良い点は、IBM RSA(RSA(emx)モデルに直接適用)から便利に機能することでした。コードの強調表示とオートコンプリートがうまく機能しています。
Xpandは、RSAモデルを「.uml」(〜XML)形式にエクスポートした場合にのみ機能しました。コードの強調表示やオートコンプリートは提供されません(または少なくとも方法がわかりませんでした)。
すべての長所と短所を考慮して、私はまだXpandに投票します(私のユースケースでは)。