MPS プロジェクト構造

モジュールメタ情報

ものをモジュールにまとめるとき、より良い善のためにモジュールを一緒に組み合わせる方法が必要です。モジュール間の関係は、それらが保持するメタ情報を通して記述されます。モジュール間の可能な関係は、いくつかのグループに分類できます。

• 依存関係 -1 つのモジュールが別のモジュールに依存している場合、前者の内部のモデルは後者からモデルをインポートできます。依存関係の reexport プロパティは、依存関係が推移的であるかどうかを示します。モジュール A が reexport プロパティが true に設定されたモジュール B に依存している場合、A で依存関係を宣言する他のすべてのモジュールも自動的に B に依存します。

• 拡張された言語依存性 - 言語 L が言語 M を拡張する場合、M からのすべての概念は、ロールまたは拡張概念のターゲットとして L 内で使用できます。また、言語 M のすべての側面は、言語 L の対応する側面で使用および拡張が可能です。

• 生成ターゲット依存関係 - 2 つの言語（L2 と L1）の間の関係。L2 の生成プログラムが L1 に生成するように指定する必要があるため、L1 の実行時依存関係が必要です。

• 使用言語 - モジュール A が言語 L を使用している場合、A 内のモデルは言語 L を使用できます。

• 使用されている devkit - モジュール A が devkit D を使用している場合、A 内のモデルは devkit D を使用できます。

• ジェネレーター出力パス - ジェネレーターの出力パスは、新しく生成されたすべてのファイルが配置されるフォルダーです。これは MPS が生成するものを探すことができる場所です。

• ファセット - ファセットは、モジュールで使用できる追加のテクノロジーまたは設定を指定します。モジュールに関連付けられたファセットは、モジュール記述子ファイル内に記録されます。これは、ファセット構成情報の最終的なソースです。テストおよび Java を含むすべてのファセットは、完全にオプションです。

  生成されたコードは、通常のコードに使用 source_gen 位置の代わり test_gen という名前のディレクトリに置かれることテストファセットを確実にします。

  言語モジュールのプロパティで Java モジュールファセットのチェックを外すと、言語がクラスローディングメカニズムから除外され、まったく異なるエクスペリエンスが発生することに注意してください。

それでは、MPS にあるさまざまな種類のモジュールについて見ていきます。

ソリューション

解決策は、MPS で可能な最も単純な種類のモジュールです。コードを保持し、共通の名前で統一されたモデルのセットにすぎません。ソリューションには 4 つのタイプがあります。

• 通常の解決策 - これらのソリューションはエンドユーザーコードを保持します。通常、IDE はオンデマンドでコードを生成し、生成された Java コードをコンパイルします。コンパイルされたコードは IDE にはロードされませんが、別の Java プロセスでオンデマンドで実行できます。

• サンドボックスソリューション - これらのソリューションは主に、言語設計のプロセス中に言語設計者によって、言語を対話的に進化させるためにコードを操作するために使用されます。通常、IDE はコードを生成しますが、生成されたコードをコンパイルしようとはしません。

• ランタイムソリューション - これらのソリューションには、他のモジュール (ソリューション、言語、ジェネレーター) が依存するコードが含まれています。コードは、MPS モデルだけでなく、Java クラス、ソース、jar ファイルでも構成できます。IDE は、クラスが外部でコンパイルまたは変更されるたびに、コードを生成およびコンパイルし、クラスを再ロードします。

• プラグインソリューション - これらのソリューションは、何らかの方法で IDE の機能を拡張します。新しいメニューエントリを提供したり、サイドツールパネルウィンドウを追加したり、プロジェクト設定ダイアログからカスタム設定画面を定義したりできます。ここでも、MPS はコードを生成してコンパイルし、クラスが変更されるたびにクラスを再ロードし続けます。さらに、IDE 機能もそれに応じて更新されます。

言語

言語は、ソリューションよりも複雑で、再利用可能な言語を表すモジュールです。これはいくつかのモデルで構成され、それぞれが言語の特定の側面を定義します: 構造、エディター、アクション、typesyste など。

言語は他の言語を拡張できます。拡張言語は、拡張言語からすべての概念を使用できます。独自の概念を導出し、継承された概念を参照のターゲットとして使用し、継承された概念を独自の概念内の子として直接配置することもできます。

言語は、サードパーティのライブラリまたはソリューションに実行時の依存関係があることがよくあります。たとえば、Hibernate や Swt などの Java ライブラリをラップする言語を作成できます。そうすれば、あなたの言語は、これらのライブラリに付属している標準の JavaAPI に代わるより優れたスムーズな代替手段をユーザーに提供します。

あなたの言語が機能するためには、あなたの言語にラップされたライブラリを含める必要があります。これは、ランタイムクラスパスまたはランタイムソリューションのいずれかを介して行います。ランタイムクラスパスは、Java で記述されたライブラリなどの一般的なシナリオに適していますが、ランタイムソリューションは、より複雑なシナリオに適しています。

• ランタイムクラスパス - ライブラリクラスをスタブ言語ジェネレーターとして利用できるようにします

• ランタイムソリューション - これらのモデルはジェネレーター内部のすべてのモデルから見える

ジェネレーター

ジェネレーターは、ある言語から他の言語、通常は別の言語への変換を定義します。ジェネレーターは他のジェネレーターに依存するかもしれません。ジェネレーターにコードを適用する順序は重要であるため、ジェネレーターに順序付け制約を設定できます。対応するセクションで生成についてさらに読むことができます。

DevKits

DevKits は、あなたの生活を楽にするために作成されました。相互接続された言語の大規模なグループがある場合は、単一のユニットとして扱う方法を確かに高く評価します。例: 個々の言語をすべてリストせずにインポートすることもできます。DevKits はこれを可能にします。DevKit を構築するときは、含める言語をリストします。

予想どおり、DevKits は他の DevKits を拡張できます。拡張された DevKit は、継承されたすべての言語を、それ自体の言語であるかのように実行します。

Java コンパイル

MPS は Java から生まれ、Java 環境でよく使われます。MPS モデルは java ファイルに生成されることが多いため、プログラムを実行する前に java をコンパイルする方法が必要です。一般的に 2 つの選択肢があります。

• MPS でコンパイルする (推奨)

• IntelliJ IDEA でコンパイルする (IntelliJ IDEA が必要です)

MPS でクラスをコンパイルするときは、モジュールのソースパスを設定する必要があります。ソースファイルは、モジュールが生成されるたびに、または make または rebuild アクションによって手動でコンパイルを呼び出すたびにコンパイルされます。