EMFTextを使用したサブジェクト指向言語（DSL）の開発の概要

これは、モデル駆動型開発サイクルの5番目の記事です。 以前の記事では、すでにメタモデル 、 モデル検証 、 モデルのいくつかの表記法（ 図と表 ）を扱ってきました。 これはすべて、MOF モデリングスペースのフレームワーク内にありました。 今日は、EBNFモデリングスペースへの橋渡しを行います。MOFモデルのテキスト表記に精通します。

はじめに

一般に、汎用プログラミング言語とサブジェクト指向言語の開発のトピックに関する多くの情報があります。 確かにこれに興味がある人は誰でも、レクサー、パーサー、構文木などの一般的な考えを持っています。 しかし、反対側から少しアプローチします。 DSLの開発全般については考慮しません。モデル指向の開発の観点からのみ興味があります。

ご注意



正直なところ、導入は何らかのブレーンストーミングであることが判明しました。 主にモデル駆動型開発の専門家に焦点を当てています。 スクロールできます。

図では、赤、黄、紫、緑の色は、プログラミング言語の理論で通常考慮されるものを示しています。 EBNF（またはその他）の言語では、その言語の文法が開発されています。 その後、プログラマーは文法に従ってソースコードを記述します。 ソースコードはパーサーに渡され、パーサーはプログラムテキストを何らかの内部表現に変換します（抽象セマンティックグラフと呼びましょう）。 このグラフは、インタープリター、コンパイラー、エディター、またはコードジェネレーターによって使用されます。



これは、プログラミング言語の理論の非常に単純化された概略図です。 あまり詳しく調べません。



これと並行して、このシリーズの記事に専念するモデル指向開発という別の領域があります。



モデル指向の開発では、開発者の頭の中の思考からソースコード、単体テスト、またはドキュメントまで、すべてがモデルと見なされます（これが主要な主要エンティティです）。 また、開発プロセスは、一部のモデルを他のモデルに変換することです。

1. たとえば、最初に開発者の頭の中では、将来のプログラムの特定のイメージ（モデル）が発生します。
2. 次に、この精神的なイメージをUMLモデルに変換します。
3. UMLモデルに基づいて、ソースコード（モデル指向開発の観点からもモデル）を記述します。
4. ソースコードの単体テストを記述します（これはモデルです）。
5. ドキュメントを作成します（すべてがモデルです）。

これらの変換の中には、自動化が容易なものもあれば、短期的にはより複雑または不可能なものもあります。 しかし、これは本質を変えるものではありません-モデルとモデル変換のみがあります-他には何もありません（実際、変換もモデルですが、次の記事で詳しく説明します）。



一部のモデルは互いに非常に似ています。 たとえば、すべてのUMLモデルは、単一の表記法で特定のルールに従って構築されます（共通のメタモデル-UMLがあります）。 BPMNまたはERモデルは、UMLとはすでに異なっています。 しかし、それでも、ソースコードやプログラマの考えよりもUMLにはるかに近いものです。



これは、UML、BPMN、およびERが単一のMOFメタメタモデルに基づいて構築されたメタモデルであるという事実によるものです。 そして、プログラミング言語の文法（メタモデル）は別のメタメタモデル-EBNFに基づいています。 プログラマーの考えは、一部のメタモデルにも対応しています。これは、現在完全に形式化されていないメタメタモデルに対応しています。



各メタメタモデルは独自のモデリング空間を形成しますが、他のモデル空間とはまったく異なります。

ご注意



私が話していることを理解していない場合は、 OCLとメタモデルに関するシリーズの最初の記事を読むことができます。 スペースのモデリングに関する記事もあります 。

1つのモデリング空間（たとえば、MOF）内でモデルを変換する必要がある場合、これは基本です。 関連する仕様とツールがあり、次の記事で説明します。



ただし、a）ソースコードをUMLに変換するか、b）BPMNモデルから単体テストまたはドキュメントを生成する必要がある場合、これはすでにやや困難です。 これを行うには、2つのモデリングスペースの間にブリッジが必要です。 そして、ここでプログラミング言語の理論が助けになります。



この記事では、1つの非常に単純なサブジェクト指向言語（図の青いブロック）のメタモデルを検討し、その文法（図の緑のブロック）について説明します。 また、生成します（モデル指向開発では、パーサーとコードジェネレーターを使用してコードを手動で記述することは一般的にあまり習慣的ではありません-モデリングスペースMOFとEBNFの間のブリッジです。この言語用のエディターも生成します。



Eclipse Modeling Frameworkには、これに役立つツールがいくつかあります。

MOFモデルからテキスト変換言語（Acceleo）

これは、OMF仕様で説明されている MOFモデルからテキストを生成するためのテンプレート言語です。 AcceleoはOMG仕様の実装です。 仕様は2008年以降更新されていませんが、Acceleoは多くのプロジェクトで使用されています。 この言語は非常に単純であり、言語を更新する必要がない場合があります。 次のいずれかの記事で詳細に検討します。



この言語の利点は、モデルからテキストを簡単に作成できることです。 UMLまたはERモデルからSQLクエリをすばやく生成したり、CSV形式でモデルからアンロードしたりする必要がある場合は、この言語が最適です。



主な欠点は、このブリッジが一方通行であることです。 テキストを解析して、モデルに戻すことはできません。 また、結果のテキストが正しくフォーマットされるように、フォーマットテンプレート（スペース、ラインフィード）に多くの注意を払う必要があります。 同時に、テンプレート自体はあまり読みにくくなります。



ちなみに、Acceleoは実際にはOCLのテンプレートアドオンです。 この記事を読んだ場合、Acceleoを開発するには、さらにいくつかの設計を学ぶ必要があります。

EMFText

EMFTextはすでにAcceleoよりもはるかに興味深いものです。 メタモデルと言語構文を説明します。 その結果、MOFシミュレーションスペースとEBNFシミュレーションスペースの間に双方向のブリッジができます。 あなたのために、パーサー（テキストからモデルへ）、コードジェネレーター（モデルからテキストへ）、エディター（構文の強調表示とオートコンプリート）およびコンパイラー、インタープリター、言語デバッガーのブランクが自動的に生成されます。



EMFTextを使用して実装された言語の例があります。



この記事では、EMFTextを使用します。

Xtext

Xtextの機能はEMFTextに似ています。 より活発なコミュニティが特徴です。 また、Xtextのランタイムライブラリに依存するパーサーとコードジェネレーターを生成する方法。 EMFTextとは異なり、EMFTextは設計時にのみ必要であり、実行時には必要ありません。 このため、プロジェクトでは、XtextではなくEMFTextを使用します。

イプシロン生成言語

Epsilon用のAcceleoアナログ。

人間が使用できるテキスト表記

OMG HUTNも注目に値します。 これは、MOFモデルをシリアル化するためのテキスト構文です。 MOFモデルのJSONと考えることができます。 Epsilonの実装があります。 ただし、このことは私たちには適していません。中括弧だけでなく、任意の構文を記述する必要があるからです。

理論のビット

練習を始める前に、まだ少し理論が必要です。

ご注意



このセクションは、包括的または正確であることを意図していません。 次のセクションを理解できるようにするために、すべてを非常に単純化された概略的な方法で説明します。 プログラミング言語の理論に興味がある場合は、このトピック専用のソースを参照することをお勧めします。

EBNFとMOFモデリングスペースの間に橋を架けています。 ブリッジの片側にはソースコードがあり、もう片側にはプログラムの特定のモデルがあります（明確にするために、抽象セマンティックグラフと呼びます）。



通常、抽象的なセマンティックグラフはプログラマから隠されています。 どのように正確に機能するかは、コンパイラまたはインタープリターを実装することの問題です。 このグラフを使用するプログラマーは直接動作せず、ソースコードでのみ動作します。



一方、モデル指向の開発では、抽象的なセマンティックグラフが重要な役割を果たします。 これは、何らかの種類のパーサーの技術的な内部構造ではなく、プログラマーが使用するモデルです。 プログラマーにとって、このモデルがどの程度正確に設計され、どれほど便利であるかが重要です。

ご注意



もちろん、プログラマーが言語の反射機能を使用する場合、ソースコードではなくプログラムのモデルを使用します。 しかし、同時に、彼らは、おそらくそれを認識せずに、モデル指向開発の領域に分類されます。 彼らはプログラムをモデルとして見ています。

この図は、パーサーと言語コードジェネレーターの動作を概略的に示しています。

字句解析

最初に、ソースコードの字句解析が実行され、その結果、テキストが一連のトークンに分割されます。 通常、レクサーは、コンテキストに依存しない正規表現を使用してトークンを割り当てます。 このため、言語では

• レクサーがキーワードと識別子を区別できるように、識別子で使用できない予約語があります。
• テキストリテラルは引用符で囲まれているため、レクサーはそれらを予約語または識別子と区別できます。
• 識別子を開始したり、数字だけで構成したりすることはできません。そうしないと、レクサーがこの識別子または数値リテラルを理解することは困難です。

つまり 異なる種類のトークンの正規表現は、可能な限り重複しないようにしてください。 残念ながら、時々それらはまだ交差します。 時々これは問題ではありません。 また、これにより言語の文法が複雑になる場合があります。この状況は、SQLパーサーに関する次の記事で説明します。

解析

次に、トークンシーケンスの解析が実行されます。 パーサーは、言語の文法を調べて、トークンを特定の構文ツリーに編成します。 構造上、このツリーは言語のEBNF文法と同一です。

• 最初の非終端記号に対して、ツリーのルートノードが構築されます。
• 他の非終端記号については、ツリーの内部ノードが構築され、
• 終端記号（トークン、トークン）の場合、ツリーの葉ノードが構築されます。

特定の構文ツリーの簡素化

通常、特定の構文ツリーで作業することは非常に不便です。非常に単純な言語であっても、非常に深いことがわかります。



次の記事のいずれかで、算術式の言語を検討する可能性があります。 このような言語の特定の構文ツリーは、ピサの斜塔に似ていることがわかります。



単純な言語の場合は、タワーの余分な中間階を削除するだけです。 より複雑な言語では、より複雑な単純化が必要です。 その結果、抽象構文ツリーを取得します。



私たちのすべてのツリーノードは、特定のクラスのオブジェクトになります。 一般に、これは必要ではありませんが、たとえばXMLドキュメントとしてツリーを提示することにより、クラスとオブジェクトなしで実行できます。 しかし、オブジェクトの移動先のMOFのため、オブジェクトモデルが必要です。 MOF以外のモデリングスペースへのブリッジを構築する場合、プログラムオブジェクトモデルではなく、他のモデルが必要になります。

セマンティック分析

明らかに、比較的複雑な言語で書かれたプログラムはツリーとして表すことはできません。 たとえば、この言語で変数、クラス、型、関数を宣言し、それらを参照できる場合、そのようなテキストリンクを解決すると、抽象的なセマンティックグラフが取得されます。

コード生成

コード生成は、プログラムのテキスト表現がプログラムの何らかの抽象表現から形成される場合（たとえば、抽象セマンティックグラフとして）、解析の逆のプロセスです。



コード生成には、テンプレートとユニバーサルコードジェネレーターの2つのアプローチがあります。



テンプレートを使用する場合、将来のプログラムのおおよそのテキストが書き込まれます。 たとえば、このテキスト内のクラス、変数、関数の名前は、実際の名前が代わりに置き換えられる代わりに、特殊な文字シーケンスに置き換えられます。 明らかに、テンプレートを使用して任意のコードを生成することはできません。



ユニバーサルコードジェネレーターは、プログラムモデルを入力（たとえば、抽象セマンティックグラフ）として受け取り、対応するソースコードを出力します。 したがって、任意のコードを生成できます。 ただし、ユニバーサルコードジェネレーターを実装することは、テンプレートよりもはるかに複雑です。 結果のコードをフォーマットすることも難しい場合があります。 モデルには、スペース、改行などに関する情報を含む追加の注釈が必要です。 または、コードフォーマッタが必要です。コードフォーマッタは、どこかで記述または取得する必要があります。 テンプレート付きのバージョンでは、これは必要ありません。テンプレート内のすべてを必要に応じて直接フォーマットします。



幸いなことに、EMFTextは最も単純なコードフォーマット機能を備えたコードジェネレーターを自動的に生成します。

カスタマイズ

通常どおり、 Eclipse Modeling Toolsが必要になります 。 ここhttp://emftext.org/update_trunkからEMFTextの最新バージョンをインストールします。

プロジェクト作成

以前の記事とは異なり、完成したプロジェクトはありません。 はい、必要ありません。デフォルトで作成されたプロジェクトを使用します（ファイル->新規->その他...-> EMFTextプロジェクト）。







メタモデルフォルダーには、言語メタモデル（myDSL.ecore）とその文法（myDSL.cs）の空白が表示されます。 これらの2つのファイルは、言語を完全に記述しています。 他のほとんどすべてはそれらから生成されます。







この記事では、この単純なデモDSLに限定します。

言語メタモデル

メタモデルとは、言語のことです。 たとえば、Javaメタモデルには、クラス、メソッド、変数、式などのメタクラスが含まれます。 メタモデルにないものを言語で記述することはできません。 たとえば、Java 7メタモデルにはラムダ式はありません。 したがって、Java 7で作成されたコードでは使用できません。



次の図は、EMFTextが生成したドメイン固有言語のデモのメタモデルを示しています。

ご注意



図に示されている内容がわからない場合は、Eclipse Modeling Frameworkに関する記事を読むことができます。

サブジェクト指向言語を使用すると、エンティティモデル（EntityModel）を記述することができます。これは、エンティティ（Entity）とデータタイプ（DataType）の2つのタイプ（Type）で構成されます。 エンティティは抽象化できます。 エンティティには、機能（属性）、リンク（参照）、コンポーネントパーツ（包含）の3つのプロパティ（機能）があります。 プロパティは非常にシンプルで、複数のプロパティもありません。



理論的には、属性はデータ型のみを参照する必要があります。 また、リンクとコンポーネントはエンティティのみを参照する必要があります。 しかし、構造レベルのこのメタモデルでは、これは決して制限されません。 データ型を一部のエンティティの不可欠な部分にすることも、データ型の代わりにエンティティを属性型として指定することもできます。 これはおそらくあまり正しくありません。 これを修正する方法は2つあります。1）構造レベルで、または2）追加の制限を使用します。



最初のケースでは、プロパティのタイプごとに個別のメタクラスが作成されます（これがEcoreメタメタモデル自体の実装方法です）。 つまり FeatureKind列挙を削除し、型の関連付けを削除し、メタクラスFeatureを抽象化し、そこから3つのメタクラス、Attribute、Reference、およびContainmentを継承します。 最初に、DataTypeへのリンクを追加し、2番目と3番目-Entityに追加します。



2番目の方法は、OCLに関する記事で説明されています 。



この欠陥は修正しません。 さらに、リンク解決メカニズムの理解に役立ちます。

言語エディターの起動

そのため、EMFTextが生成したデモドメイン固有言語のメタモデルを多かれ少なかれ扱いました。 この言語の構文の説明に進む前に、ソースコードの例を見てみましょう。



これを行うには、Eclipseの2番目のインスタンスを作成して実行します（実行->構成の実行...）：







2番目のEclipseインスタンスで、新しいmyDSLプロジェクトを作成します（ファイル->新規->その他...-> EMFText myDSLプロジェクト）：







次の図に、myDSLで記述されたコードの例を示します。 ご覧のとおり、サブジェクト指向言語により、エンティティ、プロパティ、データ型を実際に記述することができます。



左下は、言語メタモデルに対応する構文ツリーです。 メタモデルに対応するツリーノードの1つの右下のプロパティ。 他の構文ツリーを取得する（新しいタイプのノード、新しいノードのプロパティを追加する）場合は、言語メタモデルを変更する必要があります。







エディターに構文の強調表示があることがわかります。 後で改善します。



また、Ctrl +スペースを介して、オートコンプリートが呼び出されますが、これはデフォルトでは希望どおりに機能しません。 属性は、エンティティではなくデータ型のみを提供する必要があります。 後で修正します。

特定の構文の説明

テストDSLのサンプルコードを見たので、myDSL.csファイルの構文の説明に戻りましょう。







1行目は、DSLで記述されたファイル拡張子を示しています。



2行目は、記述されたDSLのメタモデル名前空間を示しています。



3行目は、文法の最初の非終端記号を示し、同時に構文木のルートメタクラスを示します。



行6は、EMFTextパラメーターの1つを示しています。 このようなパラメーターは何百もあり、 マニュアルで個別に知ることができます 。



次は、言語の文法規則です。 ルール記述言語はEBNFに非常に似ていることがわかります。 ただし、ルールの左側の非終端文字の名前は、言語メタモデルの一部のメタクラスの名前と一致する必要があります。 また、ルールの右側の（非）終端文字の名前は、このメタクラスの一部のプロパティの名前と一致する必要があります。



ルールの右側にある文字の多様性は、メタモデルの対応するプロパティの多様性に対応する必要があります。



ルールをさらに詳しく分析しましょう。



10行目では、DSLのコードはキーワード「model」で始まり、その後にいくつかのタイプの説明が続くべきだと主張しています。 さらに、覚えておく必要があるように、メタモデルには、エンティティ（Entity）とデータ型（DataType）の2種類のタイプがあります。



行11は、エンティティの構文を説明しています。 エンティティの説明は、キーワード「abstract」で始まる場合があります。この場合、構文ツリー内の同じ名前のプロパティがtrueに設定されます。 次に、「エンティティ」というキーワードが続きます。



次に、エンティティの名前が続きます。これは、nameプロパティに格納されます。 名前のトークンのタイプは角括弧で示す必要があります。 この場合、指定されていないため、パーサーはデフォルトのトークン-TEXTを予期します。 少し後でトークンに戻ります。



次に、中括弧でエンティティの機能をリストする必要があります。 これは非終端記号です。プロパティの文法には独自のルールがあり（13行目）、メタモデルには別のメタクラスがあります。 したがって、角括弧はなく、トークンのタイプを指定する方法はありません。



行12は、データ型の構文を説明しています。 データ型の説明は、キーワード「datatype」で始まり、その後に型名とセミコロンが続く必要があります。



行13は、エンティティプロパティの構文を説明しています。 プロパティの説明は、3つのキープロパティ（「att」、「ref」、または「cont」）のいずれかで開始できます。 構文ツリーでは、指定されたキーワードに応じて、ノードのkindプロパティはFeatureKind列挙の値のいずれかを取ります。



この後に、プロパティのタイプ、プロパティの名前、セミコロンが続きます。 さらに、コード内のプロパティのタイプは文字列として示されますが、構文ツリーでは、名前によるリンクは対応するタイプへの物理リンクに変わります。 したがって、構文解析すると、ツリーではなくグラフが得られます。 後でリンク解決に戻ります。



一般に、解析時に正確に得られるものは、ささいな問題ではありません。 一方で、結果として生じる構造は、言語の文法をほぼ完全に複製し、具体的な構文ツリーのようです。 一方、EMFTextはシンボリックリンクを解決し、特定の構文ツリーを抽象的なセマンティックグラフに変換します。 また、ポストプロセッサをパーサーにねじ込むこともできます。これにより、モデルを簡素化できます。



言い換えれば、パーサーは特定の構文ツリーと抽象的なセマンティックグラフのある種のハイブリッドの出力を生成します。 このような単純な言語では、これはそれほど重要ではありません。 しかし、次の記事では、SQLのメタモデルを開発するときに、「どのようなメタモデルを実行しているのか、具体的または抽象的か？」という質問に再び戻る必要があります。

新しいタイプのトークンを追加する

次に、DSLを少し改善します。 myDSL.csでは、一部の端末文字（名前とタイプ）の後に空の角括弧が続きます。 そのような文字には、パターン付きのデフォルトのTEXTトークンが使用されます。



('A'..'Z'|'a'..'z'|'0'..'9'|'_'|'-')+







これは、エンティティ名が完全に10進数字で構成されているか、マイナス記号で始まることを意味しますが、これはおそらくあまり正しくありません。

ご注意



また、エンティティの名前に非ラテン文字を含めることはできません。おそらく、ユニコードのサポートによって言語が損なわれることはありません。



EMFTextは、Unicodeをサポートするが文字クラスをサポートしないANTLR正規表現を使用します。 したがって、有効な文字の範囲を明示的にリストする必要があります。 これについては気にしませんが。

したがって、タイプ名はラテンアルファベットの大文字でのみ開始し、他の文字で開始することはできません。 そしてプロパティ名-ラテンアルファベットの小文字のみ。



新しいタイプのトークンを説明するために、TOKENSセクションを作成します（9〜16行目）。







行10〜12は、トークンフラグメントを定義します。



14行目と15行目は、それぞれタイプ名とプロパティ名のトークンを定義しています。



角括弧内の行20〜22は、パーサーが予期するトークンを示しています。



ただし、問題があります。 新しいトークンの正規表現は、警告されているデフォルトのトークンTEXTと交差します（上の図を参照）。 これは何につながりますか？



たとえば、エンティティエンティティ「Car」はソースコードで定義されています。 このエンティティの名前は、TEXTとTYPE_NAMEの両方の正規表現と一致します。 レクサーが「車」がTYPE_NAMEであると判断した場合、すべて問題ありません。 しかし、彼がそれがTEXTであると判断した場合、ソースコードを解析する次の段階で、パーサーは次のようなエラーを生成します。「キーワードの後」エンティティ "

ご注意



前の段落の意味が理解できない場合は、上記の「理論の一部」セクションの図を見て、字句解析および構文解析のサブセクションを読んでください。

この不確実性を解決する方法はいくつかあります。

1. より具体的なトークンのEMFTextがデフォルトでより高い優先度を割り当てるという事実に依存しています。 つまり レクサーは最初にTYPE_NAMEとFEATURE_NAMEを検索し、次にTEXTを検索します。
2. トークンの優先度を手動で設定します。
3. 余分なトークンを削除します。
4. 文法を複雑にします。 たとえば、「name [TYPE_NAME]」の代わりに「name [TYPE_NAME] | 名前[TEXT]。 "

この場合、TEXTトークンは不要なので、削除するだけです。 これを行うには、7行目で、事前定義されたトークンTEXT、LINEBREAK、WHITESPACEを無効にします。 ただし、最後の2つのトークンが必要なので、18行目と19行目で明示的に定義します。







次に、左側のツリーでプロジェクトを右クリックし、表示されるコンテキストメニューで[すべて生成（EMFText）]を選択します。 ソースコードを再生成した後、Eclipseの2番目のインスタンスを実行します。



エンティティ名を小文字で記述すると、レクサーはそれをプロパティの名前（FEATURE_NAME）として解釈し、パーサーはTYPE_NAMEトークンが予期されていたというエラーを返します。



アンダースコア「_」で属性名を開始すると、レクサーはトークンが何であるかを理解しません。

構文の強調表示

デフォルトでは、EMFTextはすべてのキーワードを紫色に色付けします。 もう少し色を追加します。これを行うには、TOKENSTYLESセクションを作成します（22〜27行目）。







「すべて生成（EMFText）」ソースコードを再生成し、Eclipseの2番目のインスタンスを実行します。



それは気味が悪いように見えますが、あなたは考えを得る:)「車」がピンクではなく、青で塗られるという事実に注意を払ってください。 これは、レクサーがコンテキストに依存しない正規表現を使用してトークンを割り当てるためです。 彼は、プロパティ名ではなくエンティティ名が必要であることを知りません。

リンク解決

先ほど、エンティティのプロパティの定義における型名の自動補完がうまく機能しないという事実に注意を喚起しました。 属性（att）にはデータ型のみを提供し、リンク（ref）およびコンポーネントパーツ（cont）にはエンティティのみを提供する必要があります。



プロジェクトorg.emftext.language.myDSL.resource.myDSLで、自動補完とリンク解決を担当するFeatureTypeReferenceResolverクラスを見つけます。



resolveメソッドは、名前で一致するタイプを探す必要があります。 resolveFuzzyパラメーターの値がtrueの場合、メソッドは指定された文字列にほぼ適合するタイプを検索する必要があります（これは、タイプ名がオートコンプリートされるときに発生します）。 それ以外の場合、メソッドは指定された名前とまったく同じタイプを探す必要があります。



deResolveメソッドは、抽象セマンティックグラフでの参照のために、ソースコードでそのテキスト表現を返す必要があります。



型参照を解決する実装の1つを次に示します。

 package org.emftext.language.myDSL.resource.myDSL.analysis; import java.util.Map; import java.util.function.Consumer; import java.util.function.Predicate; import java.util.stream.Stream; import org.eclipse.emf.ecore.EReference; import org.eclipse.emf.ecore.util.EcoreUtil; import org.emftext.language.myDSL.DataType; import org.emftext.language.myDSL.Entity; import org.emftext.language.myDSL.EntityModel; import org.emftext.language.myDSL.Feature; import org.emftext.language.myDSL.FeatureKind; import org.emftext.language.myDSL.Type; import org.emftext.language.myDSL.resource.myDSL.IMyDSLReferenceResolveResult; import org.emftext.language.myDSL.resource.myDSL.IMyDSLReferenceResolver; public class FeatureTypeReferenceResolver implements IMyDSLReferenceResolver<Feature, Type> { //      ,    identifier public void resolve(String identifier, Feature container, EReference reference, int position, boolean resolveFuzzy, final IMyDSLReferenceResolveResult<Type> result) { //        . //    containment-      owner, //      container.getOwner().getOwner() EntityModel model = (EntityModel) EcoreUtil.getRootContainer(container); //       ,    , //    Predicate<Type> isRelevant = container.getKind() == FeatureKind.ATTRIBUTE ? type -> type instanceof DataType : type -> type instanceof Entity; Stream<Type> types = model.getTypes().stream().filter(isRelevant); //            Consumer<Type> addMapping = type -> result.addMapping(type.getName().toString(), type); //        ,   , //          if (resolveFuzzy) { types.filter(type -> type.getName().toUpperCase().startsWith(identifier.toUpperCase())) .forEach(addMapping); } //  (   ),         else { types.filter(type -> type.getName().equals(identifier)) .findFirst() .ifPresent(addMapping); } } //       ( ) public String deResolve(Type element, Feature container, EReference reference) { return element.getName(); } public void setOptions(Map<?, ?> options) { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コード生成

パーサーとエディターを使用して、最初の近似値を計算しました。 残るのはコード生成だけです。



左下隅の構文ツリーは表示専用です。 編集するには、ファイルをxmi形式で保存します（[ファイル]-> [名前を付けて保存...]）。



この場合、MyDSLEditorを使用してファイルを開くことができないというエラーが発生した場合、それを無視してxmi-fileを再度開きます。 同じ構文ツリーが表示されますが、編集できるようになりました。







エンティティの名前を「Car」から「Vehicle」に変更し、「Abstract」プロパティの真の値を設定します。



xmiファイルを拡張子myDSLで保存します。 閉じて再度開きます。







ご覧のとおり、構文ツリーの変更が考慮されています！ つまり モデルのテキストへの変換（コード生成）は機能します。



確かに、保存すると、改行と一部のスペースが消えました。



生成されたコードの通常のフォーマットを実現するには、次の3つの方法があります。

1. メタモデルwww.emftext.org/commons/layoutからのメタクラスLayoutInformationへのリンクを持つ各メタクラスを追加して、メタモデルを変更します。 私は個人的にこれをしませんでした。この場合、必要なスペースの数を数えたり、テキストのオフセットを計算したりする必要があると感じています。 -非常に複雑に見えます。
2. 別のコードフォーマッタを使用します。 これはおそらく、Javaコードなどを生成するときに最適なオプションであり、すでに準備が整っているフォーマッターがあります。
3. 言語の文法にいくつかの注釈を追加して、デフォルトのコードジェネレーターがコードのフォーマットを少し改善します。 これが最も簡単なオプションです。それをやってみましょう。

注釈「！0」、「！1」、および「＃1」が行30および31に追加されます。 これらの注釈はパーサーによって無視され、コードジェネレーターを対象としています。 注釈「#N」は、この時点でN個のスペースを挿入する必要があることをコードジェネレーターに伝えます。 また、注釈「！N」は、改行とN個のタブを表します。







「すべて生成（EMFText）」ソースコードを再生成し、Eclipseの2番目のインスタンスを再起動します。 モデルをテキスト形式で再度保存し、コードがより適切にフォーマットされていることを確認してください。

おわりに

この記事を読んだ後は、モデルのプリズムとモデル変換を通して、ソフトウェア開発を再確認する必要があります。



モデルはさまざまな表記法で表すことができます（ 図 、 表 、テキストの形式）。 モデル駆動型開発の観点から見ると、サブジェクト指向言語はメタモデルの表記法の1つにすぎません。



一方、サブジェクト指向言語の文法は、EBNF モデリング空間のメタモデルです。 そして、ソースコードはこのモデリング空間のモデルです。



パーサーとは、EBNFシミュレーションスペースからMOFシミュレーションスペースなどのモデルにモデルを変換することです。



コードジェネレーターは、セマンティック指向のモデリングスペース（MOFなど）からEBNFモデリングスペースへのモデルの逆変換です。



また、プログラミング言語を開発するためのツールの1つであるEMFTextにも出会いました。