Eclipse Modeling Frameworkを使用したメタモデル開発（およびデータモデリングについて少し）

これは、モデル駆動型開発サイクルの2番目の記事です。 今日は、Ecoreメタメタモデルに基づいてメタモデルを作成します。 データモデリング、つまりアンカー、6NF、および概念モデリングについて簡単に触れます。

はじめに

OCLとメタモデリングに関する以前の記事をざっと読むことができますが、これは必須ではありません。 これらの論文だけで十分です：

1. 現実世界にはさまざまなオブジェクト（人、組織、イベント、建物、銀行口座、星、惑星、木、音楽など）があります。
2. 一部の情報システムでは、これらのオブジェクトに関するさまざまな情報を処理できます。
3. 情報はいくつかのモデルに対応しています。 モデルは多かれ少なかれ形式化、明示的または暗黙的であり、実世界のオブジェクトのさまざまな側面を記述することができ、それ自体が実世界のオブジェクトです。 たとえば、一部のUMLクラス図はモデルです。
4. モデルは、いくつかのメタモデル、モデリング言語（UMLなど）に従って構築されます。
5. メタモデルは、メタメタモデル（Ecore、MOFなど）に従って構築されます。

より抽象的には、これらの論文は、 モデル駆動型アーキテクチャのOMG（Object Management Group）コンソーシアムによって記述されました。



この記事を読んだ後、独自のメタモデル（モデリング言語）を作成する方法を学びます。

実装するメタモデルの選択

まず、実装するメタモデルを決定する必要があります。



例としてのみ作成された人工メタモデルは役に立たない。



エンティティ接続モデル、ペトリネットなど シンプルすぎて面白くない。



一部のPMMLは興味深いですが、複雑すぎます。



EMFを使用してチャリティを実装できます。 おそらく非常に興味深いでしょう（すべてが可換図を使用して記述されているプログラミング言語を想像してください）が、それは無意味です。



私の意見では、黄金の平均はアンカーです。 この言語の例を使用すると、すぐに1つの石で多くの鳥を捕まえることができます。

• メタモデルを作成する方法を学びます。
• エンティティ関係図に代わる方法の1つを理解しましょう。
• データの正規化に関するステレオタイプの一部は破られる可能性があります。
• 概念モデリングについて見ていきましょう。

他のデータモデリング言語が必要な理由についての余談

私が最後の仕事に就いたとき、インタビューで、前の仕事で行ったすばらしい店とキューブが何であるかを話しました。 そして、彼らは私に尋ねた：データスキームが変更された場合、このストレージとキューブはどうなりますか？ 結局のところ、ストレージ構造とキューブを変更すると、古いデータスキームに基づく過去の期間のレポートを受信できなくなります。 私は、データスキームを慎重に考え、それに大きな変更はない、何かが追加される、などのようなことを答えました。さらに深刻な変更がある場合、それについて何もすることはありませんでした。



しばらくして、データスキーマを簡単に変更するこのタスクは完全に簡単であることに気付きました。 正しいデータモデリング手法を選択するだけです。 3NF-5NFに基づいてストレージを構築する場合、実際、データスキームのわずかな変更でもすべてが壊れます。 データを6NFに正規化すると、変更はデータベースに既に保存されているデータに影響しません。



Data VaultとAnchorは、データを6NFに正規化するという考えにある程度基づいています。 このリトリートがあなたのアンカーに興味を引くのに十分であることを願っています。

ご注意



実際、これはデータモデリングの頂点ではありません。これらのアプローチでは考慮されていないものがいくつかあります。 しかし、それらは、例えば、私たちのモデリング手法で考慮されますが、あなたが私たちと仕事をするならば、あなたはこれについて知るでしょう;-)

データモデリングの歴史に関する余談

最後にアンカーに移る前に、少し歴史を書いてください（それについて批判的で皮肉なことをお願いします）。



1970年代には、データモデリングに関する多くの研究がありました。 それらの年に発明された悪くないアプローチの1つはオブジェクトロールモデリングです。 それはアルファとオメガのデータモデリングであり、実際にはピークであり、その後、この領域の劣化の歴史が始まりました。 このアプローチについては詳しく説明しません。 一言で言えば、そこにあるデータは事実の形で記述されていますが、RDFのような「subject-predicate-object」ではなく、任意の数のオブジェクトを持つタプルの形で記述されています。







残念ながら、当時の誰もがORモデリングの天才に気付いていなかったため、Peter Chenは1976年にエンティティ関係モデルについて説明した記事を公開しました。 ERモデルは、事実ではなく属性を持つという点でORモデルと異なります。 これは非常に大きな違いです。







英語版ウィキペディアの TheMattrixによる「 ER Diagram MMORPG 」。 Commonsを介してCC BY-SA 3.0の下でライセンスされています。



ORモデルでは、オブジェクトに関連する一連の事実は非常にarbitrary意的です。 たとえば、「従業員1-名前はイヴァン-従業員1--1990年生まれ」という事実を定式化できます。 またはさらに複雑：「従業員1位-学位取得-科学博士-2010年。」 しかし、これは、従業員に関する他の事実を定式化できないことを意味するわけではないため、従業員の名前と生年月日をこの順序で常に示す必要があるという意味ではありません。



ERモデルでは、ファクトから属性に移動すると、そのようなモデルの柔軟性/開放性が失われ、特定の方法で順序付けられた属性に配線されたファクトの固定セットを記述する固定構造のモデリングを開始します。



Peter Chenの表記のERモデルでは、接続は菱形で、属性は楕円で表されるという事実に注意してください。 さらに、通信はバイナリだけではありません。



1981年、産業用コンピューター化データモデリング （ICAM）をさらに劣化させるために提案された米国空軍プログラムの一環として、エンティティ内に属性が入り、菱形からの接続が単純に線になったIDEF1が開発されました。 さらに、 米軍の陰謀的な陰謀の結果として、多くの人々は、Peter ChenのERモデルではなくIDEF1にエンティティ関係モデルを関連付けます。







itl.nist.govによる 「 B 5 1 IDEF1Xダイアグラム 」- 情報モデリングの統合定義（IDEFIX）-93 12月21日 。 Commonsを介してPublic Domainでライセンスされています。



その後、UML、RDF、XSD、アンカー、あらゆる種類のNoSQLなど、データをモデル化できる多くの言語とメソッドが登場しました。 しかし、これらすべてに新しい革新的なものはありません。 ちなみに、これはファッショナブルなホイッスルを追跡する必要がないという事実の良い例であり、ほとんどのものは長い間発明されており、マーケターのための新しいラッパーに変わります。

アンカーリトリート

それで、 アンカーに着きました。 この言語は、通常のIDEF1XまたはUMLクラス図とは異なりますが、実際には、多くの人が忘れているかもしれないPeter Chenの古いERモデルからのトレーシングペーパーにすぎません。 主な違いをリストします。







LarsRönnbäckによる「 アンカーモデリングの例 」-http : //www.anchormodeling.com。 Commonsを介してMITでライセンスされています。



アンカーでは、エンティティの名前がアンカーに変更され、関係の名前が中括弧に変更されます（タイ-中括弧と呼ぶこともできますが、「中括弧」という言葉はこのモデルに魅力を加えます）、属性は変更されません。



ERモデルでは、属性に表現があります。 アンカーでは、これらはより親しみのあるデータ型と呼ばれます。



ERモデルでは、ビューは許容値の範囲をさらに制限できます。 アンカーでは、値の範囲を制限することもできますが、任意ではなく、有効な値をリストすることで制限できます。 アンカーのこのような列挙型は、ノットと呼ばれます。 今後は、この点でアンカーを少し開発します。



ERモデルとアンカーの間のこれらの違いが重要であると考えられる可能性は低いです。 これまでのところ、アンカーは40年前のブランド変更されたアイデアを連想させます。



おそらく最も重要な違いは、属性と履歴の保存との関係です（履歴属性と履歴タイ）。 ERモデルには存在しませんが、一般に、 根本的に新しいものはありません。



疑問が生じる可能性があります。アンカーが非常に二次的なものである場合、なぜそれが必要なのか、他のアプローチに対する利点は何ですか？



答えはとても簡単です。 アンカーを使用すると、データの正規化について少し異なる見方をすることができます。 以前は、通常の形式は主にデータの異常の観点から考慮されていました。 この場合、6NFは真空中のある種の球形の馬のように見えました。これはおそらく理論的な観点からは興味深いですが、実際には役に立ちません。 AnchorやData Vaultのようなアプローチの出現により、データの正規化は異常の排除だけでなく、データスキームの進化の観点からも重要であることが明らかになりました。 何も壊さずにこのようなスキームを変更する方が簡単です。

プロジェクト作成

このサイトには、アンカーモデルの素晴らしいエディターがあります。 Eclipse Modeling Frameworkに基づいて、同様のエディターを作成しようとします。

ご注意



より正確には、この記事では、単純化された（ツリーのような）エディターを作成します。 次の記事では、本格的なチャートエディタを作成します。 そして、次の記事から、なぜこれをすべて行っているのかが明らかになります。 もちろん、モデリング言語の作成方法を学ぶことだけではありません。

したがって、すべてを実際に試してみたい場合は、 Eclipse Modeling Toolsをダウンロードして解凍してください。



新しいEcore Modeling Projectを作成します。 「アンカー」という名前を付けます。 [ビューポイントの選択]タブで、[デザイン]を選択します。







メタモデルはecoreファイルに保存されます。 airdファイルには、メタモデルのチャートが保存されます。 前の記事を読んだ場合、モデルとモデル図は異なるものであることを理解する必要があります。 最後に、メタモデルからソースコードを生成するためのモデルがgenmodelファイルに保存されます。 特に、どのフォルダーにコードを追加するかなど、コードを生成するためのさまざまなルールを設定します。

ご注意



以下、メタモデルをモデルと呼ぶことがあります。 これに矛盾はなく、メタモデル自体がモデルです。 同様に、メタクラスはメタメタモデルに関するクラスです。

プロジェクトを作成するのが面倒な場合は、 準備を整えることができます。

基本的なメタクラスの作成

次に、メタクラス（アンカーモデルに含まれる可能性のあるエンティティの種類）を記述する必要があります。 グラフにクラスを追加し、Anchorという名前を付けます。 EStringデータ型の名前属性を追加します。 [下限]フィールドに1と入力します。



別のクラスを追加し、Attributeという名前を付けます。 name属性をコピーします。



アンカーモデルでは、アンカーと属性をリンクできます。 したがって、メタモデルでは、アンカーと属性の間に接続を作成する必要があります。 接続はコンポジションである必要があります。属性はそれ自体では存在できず、常にアンカーに属し、さらにアンカーに属しているためです。

ご注意



命名関係にはさまざまなアプローチがあります。 アンカーと属性のこの関係は、attribute、attributes、ownedAttribute、ownedAttributesと呼ばれます。 1対1の関係は、単数形で一意に識別される必要があります。 1対多の関係は、単数形で参照されることもあれば、複数形で参照されることもあります。 リレーションがコンポジションの場合、所有されているプレフィックスが名前に追加されることがあります。 これは、属性がアンカーに属することを意味します。



モデルが1つの命名スキームを使用することが重要です。 2番目を使用します。

モデルエディターの生成

そのため、メタモデルの概要は既に簡略化されています。 次に、このメタモデルに従ってモデルを作成します。 これを行うには、プラグインのソースコードを生成する必要があります。これをEclipseで実行し、モデルを操作できるようにします。



anchor.genmodelを開きます。 プロパティにはさまざまな設定があります。 それらを変更せずに残すことができますが、通常、生成されたコードのフォルダーはsrcからsrc-genに変更され、生成されたコードから手動で記述されたコードを分離します。 ところで、私たちのプロジェクトでは、手書きのコードはまったくありません。



コンテキストメニューで[モデルコードの生成]を選択すると、アンカーモデルを操作するためのJava APIがsrc（またはsrc-gen）フォルダーに表示されます。 この記事および以降の記事の目的のために、このコードを調べたり編集したりする必要はありません。







「編集コードの生成」および「エディターコードの生成」を実行します。 したがって、2つの追加プロジェクトを作成します。1）モデリング言語のオブジェクトモデルとエディターの間のレイヤー、2）ツリーのようなモデルエディター。



ヒープの前に、「テストコードの生成」コマンドを使用してテストプロジェクトを作成します。 単体テストは作成しませんが、このプロジェクトでは、メタモデル用に生成されたAPIの使用例を見ることができます。 また、このプロジェクトでは、テストモデルを作成します。



Javaパースペクティブに切り替えます（ウィンドウ->パースペクティブ->パースペクティブを開く）。



[実行]-> [構成の実行...]を選択します。[Eclipseアプリケーション]セクションで、新しい構成を作成して実行します。







anchor.testsプロジェクト（ファイル->インポート...->一般->既存のプロジェクトをワークスペースにインポート）を実行中のEclipseインスタンスにインポートします。 モデリングパースペクティブを開きます（ウィンドウ->パースペクティブ->パースペクティブを開く->モデリング）。 プロジェクトに新しいモデルフォルダーを作成します（ファイル->新規->フォルダー）。 フォルダーにアンカーモデルを作成します（ファイル->新規->その他...）。







最後のタブで、モデルウィザードはルートとして使用するオブジェクトを尋ねます（モデルオブジェクトフィールド）。 ルートオブジェクトはまだ作成されていないため、[アンカー]を選択します。



[プロパティ]タブで、アンカーの名前を指定し、属性を追加します。

モデルルートオブジェクトの作成

これまでのところ、エディターでは属性を持つアンカーを1つだけ記述することができます。 モデルに複数のアンカーを設定するには、次を実行します。



Eclipseの2番目のインスタンスを閉じ、最初のインスタンスで、モデリングパースペクティブを開きます。 anchor.ecoreファイルを開きます。 メタクラスモデルをメタモデルに追加します。







生成されたアンカーというメタクラスEReferenceを追加します。 [EType]フィールドで、[アンカー]を選択します。 下限は1に設定され、上限は-1（任意の量）に設定されます。 [包含]フィールドで、真の値を指定します（これは、アンカーがモデルに属することを意味します）。



次に、アンカーからモデルへのバックリンクを作成します。 これは必須ではありませんが、次の記事で必要になります。 これを行うには、モデル名のリンクを作成し、アンカーメタクラスでModelと入力します。 [EOpposite]フィールドで、アンカーバックリンクを選択します。 [下限]フィールドに1と入力します。

ご注意



メタモデルツリーエディターは、生成したばかりのエディターと非常に似ていることに気づいたでしょう。 アイコンのおかげで少しきれいに見えない限り。 デフォルトのアイコンは、アイコンフォルダーのanchor.editプロジェクトにあります。 他のアイコンはここから取得できます 。 それらはsvgから生成されるため、少し曲がっていますが、アイデアは得られます。

メタモデルを保存します。 anchor.airdでチャートを開きます。 モデルメタクラスを図に追加します（[既存の要素]セクションの右側のツールパレットで、[追加]を選択します）。 ツリーエディタで作成したアンカーメタクラスとの双方向の関係も図に追加されていることに注意してください。

プラグインの生成

メタモデルを変更した後、すべてのプロジェクトでソースコードを再生成することを忘れないでください。 これで、Eclipseの2番目のインスタンスを開始する代わりに、次の手順を実行します。 メニューから、[ファイル]-> [エクスポート...]-> [展開可能なプラグインとフラグメント]を選択します。







作成されたすべてのプロジェクト（少なくともanchor.testsを除くすべて）を確認します。 [ホストにインストール]を選択します。 リポジトリ プラグインをデプロイした後、Eclipseを再起動します。 アンカーモデルエディターは、Eclipseの2番目のインスタンスを起動せずに、このワークスペースで使用できるようになります。



プラグインをいくつかのフォルダーにエクスポートすることもできます。 その後、結果のjarファイルを$ ECLIPSE_HOME / dropinsフォルダーにコピーできます。 Eclipseを再起動すると、プラグインが利用可能になります。

メタモデルの完成

一般に、これがメタモデルを作成するためにEMFについて知る必要があるすべてです。 残っているのは、欠落しているメタクラスを追加することだけです。



他のメタクラスが必要かどうかを調べるには、単にアンカーモデルの例を見るか、M。Bergholtz、P。Johannesson、P。Wohedの記事「アンカーモデリング-進化するデータ環境でのアジャイル情報モデリング」を参照してください 。







このメタモデルを実装しようとすると、図に示されているものよりも最適な方法で実行できることがわかります。 次の2つの点を改善します。

1. 重複するプロパティとリレーションシップは別々のクラスに配置されます。
2. 型システムを少し改善します。

ご注意



名前付きインターフェイスは図に表示されません。これを使用すると、図が完全に判読できなくなるためです。



一部のプロパティでは、EDoubleだけでなくEDoubleObject型が使用されます。これらのプロパティはオプションであるためです。 EDoubleデータ型を設定すると、デフォルトで0に設定され、実際に0に設定されているのか、単に指定されていないのかを理解することはできません。

改善点を詳細に検討してください。

抽象クラスとインターフェースに関するアドオン

上記の元のクラス図は、履歴を保持しながらすべての属性とステープルについて、メタクラスTIME TYPEとの関係が定義されていることを示しています。 一部のメタクラスには、DATA TYPEメタクラスと同様の関係があります。 また、多くのメタクラスには名前属性がありますが、図には示されていません。



これらすべての同じプロパティおよび関係は、対応するメタクラスHistorized、Typed、Namedなどに移動できます。 アンカーモデルでは、これらのメタクラスのインスタンスは存在できないため、抽象として注意する必要があります。



Ecoreは多重継承を許可します。 また、たとえば、HistorizedAttributeは、Attribute、Typed、およびHistorizedメタクラスから十分に継承できます。 ただし、複数の継承を使用してEcoreメタモデル用に生成されたJava APIを見ると、ベースメタクラスの1つだけがJavaクラスとして実装され、残りはJavaインターフェイスとして実装されていることがわかります（Java多重継承をサポートしていません）。 したがって、一意性を保つために、一部のメタクラスをEcoreメタモデルのインターフェイスとしてすぐにマークすることが望ましいです。

データ型補遺

サイトのアンカーモデルの例を見ると、varchar（42）、moneyなどの形式のデータ型があります。 キーのデータ型がモデルで明示的に設定されていることを確認してください。 個人的に、私はこの物理学への執着に非常に驚きました。 当初、アンカーはかなり概念的なモデリング言語の印象を与えましたが、モデルは特定のDBMSに関連付けられていることが判明しました。



いくつかの抽象データ型を追加することでこの欠陥を解消します（上の図で見られます）。これは以降の記事で特定のDBMSのデータ型に変換されます。 さて、一般に、先を見据えて、次の記事でモデル変換の可能性を示すためにこのメタモデルを作成しました。 そして、アンカーWebサイトのコメントで、XSLTを使用してSQLクエリを生成することについての地獄まで読んでいます。これは悪いことです。

おわりに

この記事を読んだ後は、Eclipse Modeling Frameworkを使用してモデリング言語を作成できるはずです。 また、データモデリングの分野から何か面白いことを学んだかもしれません。



次の記事では、ツリーエディターだけでなく、 ダイアグラムエディターの作成方法について説明します。