メタモデルは、モデル駆動型ソフトウェア開発の最も重要な側面の 1 つです。以下の MDSD の課題に対処するには、メタモデリングの知識が必要です。
- ドメイン固有モデリング言語 (DSL) を構築します。メタモデルは、この言語の抽象構文を記述します。
- モデルの検証: モデルはメタモデルで定義された制約の下で有効です。
- モデル間変換: この変換が定義されている 2 つのメタモデル間のマッピング原則。
- コード生成: テンプレート参照 DSL メタモデルを生成します。
- ツールの統合: メタモデルに基づいて、モデリング ツールをそれぞれのドメインに適合させることができます。
1. メタモデルの定義
メタモデルは、宣言型モデリング用のモデルです。より正確には、メタモデルはモデルの可能な構造を記述します。メタモデルは、モデリング言語のコンポーネントとその関係、制約やモデリング ルールを抽象的な方法で定義しますが、言語の具象文法は記述しません。メタモデルはモデリング言語の抽象的で静的な構文を定義すると言います。逆も同様で、すべての形式言語には Java や UML などのメタモデルがあります。
メタモデルとモデルの間にはクラスとインスタンスの関係があります。各モデルはメタモデルのインスタンスであるため、メタモデルの定義にはメタモデリング言語が必要であり、言語はメタメタモデルによって記述されます。理論的には、この抽象化の「カスケード」は無限に拡張できますが、実際には他の手段が取られます。
MDSD のコンテキストでは、ドメインの DSL はメタモデルによって定義されます。
現実、モデル、メタモデルの関係
原則として、モデルは任意のモデリング言語で記述できます。言語の選択は、説明するドメインに対する言語の適合性に基づいて行う必要があります。実際には、この決定は、モデリング言語で利用できる実用的なツールがあるかどうかによって決まります。これは、UML が多くの状況でモデリングに使用できることを意味します。したがって、UML のコンテキストでモデリングを検討することは非常に重要です。
メタ関係は通常、モデル相対です。
OMGのクアッドレイヤー
UML メタモデルの構築クラスは、メタ要素 MOF 分類子のインスタンスになりました。MOF クラスは M3 レベルで定義されます。Meta Object Facility MOF は、OMG のメタメタモデルです。MOF は、UML などのモデリング言語を M2 レベルで定義するために使用されます。その背後にある考え方は、UML が唯一のモデリング言語ではなく、追加のドメイン固有の、場合によっては標準化されたモデリング言語が MOF に基づいて定義されるということです。MOF は、非オブジェクト指向モデリング言語も定義できます。
OMG モデルでは、MOF の上にメタ層はありません。基本的に、MOF 自体が定義されます。
MOFでの傍受の一部
MOF という名前が示すように、オブジェクト指向パラダイムに基づいたメタメタ言語です。この目的を達成するために、MOF は同じ概念と具体的な構文を使用して、UML からクラスのカーネルを借用します。
2. メタ層と抽象化層の比較
モデル間にはさまざまな関係がある場合があります。メタ関係。モデルの作成に使用されるメタモデルによって定義された概念を示します。
一方、モデルは同じメタ レベルにある場合でも、異なる抽象化レベルにある可能性があります。通常、変換は上位モデル層のモデルを下位抽象化層のモデルにマッピングするために使用され、各モデルはメタモデルのインスタンスになります。つまり、2 つのモデルは異なりますが、モデルとメタモデルは同じメタ レイヤー上に存在します。
3. MOF と UML
UML は MOF (アプリケーション) のインスタンスです。さまざまな詳細を考慮する必要があります。
まず、UML は MOF よりも前から存在していました。UML はもともと形式的に定義されました。つまり、UML の知識は純粋に口頭で定義されました。その後定義される MOF は、UML が形式的に MOF に基づいていることを指定します。UML 定義の後のバージョンでは、この順序によって引き起こされる問題が克服されているため、UML は真の MOF 言語になることができます。
MOF モデルの表記法は UML の具体的な構文であるため、場合によっては混乱が生じます。形式的には、これはモデル要素の名前空間/パッケージの仕様によって解決できますが、依然として混乱が生じる可能性があります。
MOF には、UML にも存在する多くのモデル要素が含まれています。たとえば、どちらの言語にも Class という名前の要素があります。要素が同じ名前を持ち、同じ特性を大まかに説明している場合でも、異なるメタレベルにある限り、それらは同一ではありません。
メタと抽象
4.UMLの拡張
ソフトウェア開発では、通常、MOF に基づいてまったく新しい M2 言語を定義することから始めるのではなく、UML メタモデルから始めて、必要に応じてそれを拡張します。
- UMLに基づく正式なモデル拡張
- クラステンプレート/プロファイルによる拡張 (UML1.x)
- クラステンプレート/設定ファイルで拡張(UML1.2)
1. メタモデル拡張に基づく
このタイプの拡張は、UML のメタモデルを拡張します。このために、モデリングでよく行われるように、より高レベルのメタレベル言語 (この場合は MOF) が適用されます。このような拡張は、そのようなツールが明確に表現され、公開されている MOF ベースのメタモデルを備えている場合にのみ実現できます。
M2層内の継承
2. UML1.xカテゴリテンプレートで拡張
クラス テンプレートを使用した拡張機能は、構成ファイル メカニズムの一部として定義された UML 固有の機能です。
3. UML2.0設定ファイルで拡張
UML 2.0 の定義拡張クラス テンプレート メカニズムを使用し、それをより理解しやすい構成ファイル メカニズムのコンテキストに配置します。ここではスケーリングの概念が重要です。拡張機能は、新しい表記法と新しい UML 言語構造です。これは塗りつぶされた継承矢印として表されます。
UML 2.0 と UML 1.x のもう 1 つの違いは、モデル要素が同時に複数のカテゴリ テンプレートを持つことができることです。これには、クラス テンプレートのすべての属性がタグ付きの値として含まれます。
5、UML設定ファイル
プロファイルは、専門的または技術的領域に合わせた UML の適応と拡張をサポートします。UML は言語ではなく言語ファミリーであるとも言えます。この場合、UML プロファイルはストロークの要素、つまり具体的な言語です。目標は、UML ツールとジェネレーターがプラグインのように構成ファイルを処理できるようにすることです。この目的のために、OMG は UML の構成ファイル メカニズムを定義しました。
UML では、構成ファイルを UML で表現し、アプリケーション モデルでの使用に注釈を付けるための言語オプションが提供されるようになりました。
構成ファイルは自己完結型ではありません。代わりに、常に参照メタモデルに依存して使用します。これは、UML メタモデルまたは既存の構成ファイルにすることができます。
6. メタモデリングとOCL
OCL は、Object Constraint Language の頭字語です。これは、欠点のない便利な宣言型言語であり、MOF モデリング言語に基づいてモデリング ルールなどの制約を定義するために使用されます。制約は、モデル インスタンスの有効性に関する追加情報でモデルを強化します。制約は M1 層と M2 層のアプリケーションに適用されます。
7. メタモデリング: 例 1
説明のために、UML に依存しない独自のメタモデル、つまり UML メタモデルを拡張しないメタモデルを構築してみましょう。たとえば、FODA アプローチで生成プログラミングと特徴モデルを使用します。
8. メタモデリング: 例 2
メタモデルのもう 1 つの例は、小型デバイスや組み込みシステムで利用できる、非常に簡素化されたコンポーネント インフラストラクチャです。このインフラストラクチャに基づくアプリケーションの中心的な要素は、明らかに、コンポーネントです。アーキテクチャを定義するプロセスでは、コンポーネントのコンテンツを定義することが合理的です。そのため、最初にこのインフラストラクチャのコンポーネントのメタモデルを定義する必要があります。
また、コンポーネントには多くの構成パラメータがあります。問題を単純化するために、これらのパラメーターは、システムの起動時に構成ファイルから読み取られるため、String 型のコンポーネント クラスのプロパティである必要があります。
9. ツールによるモデル検証のサポート
メタモデリングをサポートするさまざまなツールがあります。次の選択肢を区別することができます。
- サポートしません
- 別のツール
- 統合モデリングツール
最も一般的な使用法は、UML ツールと別個のジェネレーター/ベリファイアーを組み合わせることです。残念なことに、統合されたメタモデリング ツールは依然として市場からほとんど無視されています。
ジェネレーターはすべてのモデルを入力データとして受け取ります。パーサーはこれらを分析し、メタモデル インスタンシエーターは、構成されたメタモデルを使用して結果の解析ツリーをインスタンス化します。ジェネレーターではさまざまなアナライザーを使用できるため、入力の形式は交換可能です。
10. メタモデリングと動作
メタモデリングのコンテキストにおける動作は、2 つの点で興味深いものです。一方では、動作をメタモデルの意味の中に隠すことができ、他方では、メタモデリングを使用して、たとえばアクティビティ図や状態図の形式で動作モデリングに明示的にアクセスできます。
11. より複雑な例
アルマ望遠鏡について。データ構造は UML で定義され、そこから他のさまざまなアーティファクトが生成されます。
- XM Lモード
- さまざまな言語 (C++、Java、Python) で実装された XML および (逆) コンパイラーのラッパー クラス。
- 独自のデータ形式用のコンバーター
- データモデルのHTMLドキュメント
1. 基本
まず、エンティティと依存オブジェクトを区別する必要があります。エンティティには独自の ID があり、いくつかの属性に基づいて検索できます。エンティティは、さらにいくつかの部分、つまり依存オブジェクトに分割できます。これらの依存オブジェクトは、それ自体の ID を持たないため、検索できません。オブジェクトを保持しているエンティティのみがオブジェクトを認識し、取得できます。セクションにはさらに多くのセクションを含めることができます。
2. 値の型
データ モデル内のデータには他にも違いがあります。空における星の位置などの特定の情報は、オブジェクトやその基礎となる種類には依存しません。この目的のために、値の型が導入されます。値の型自体にはアイデンティティはなく、数値のみで構成されます。同じ値を持つ 2 つの値型インスタンスは同一とみなされます。通常、エンティティまたは依存オブジェクトを定義するプロパティは、プリミティブ型または値型のみにすることができます。これらの値はシステム内で繰り返されるためです。
3. 物理量
ALMA は物理計測ツールであるため、扱うデータには多くの物理量が含まれるため、メタモデルのように物理量を明確に示すことが合理的です。物理量には値と単位があります。さまざまな物理量には、特定の定義された単位と値の範囲があります。
12. メタモデリングの欠陥
このセクションでは、いくつかのヒントとテクニックを提供し、特に UML に関連するメタモデリングのいくつかの落とし穴を明らかにします。
- メタモデリングでは、どの表記法を使用する必要があるかがもはや明らかではないという問題がよく発生します。
- 間違ったメタレイヤーにいることに気づきました。
一般に、プログラミング言語でメタモデルを実装する方法という重要な質問をすることが役立つことが証明されています。逆に、どのシンボルが正しいかを示唆することもできます。
1. インターフェース
問題: メタクラス エンティティの強度には特定のインターフェイスを実装する必要があるという事実を表現したい。
正しい解決策: エンティティの実装されたインターフェイスのセットには、インターフェイス スタックが含まれている必要があります。これは、OCL 制約によって、または単語のメタ関連のサブセットを構築することによって表現できます。
2. 依存関係
問題: コンポーネントはインターフェイス上で操作を呼び出すため、コンポーネントがインターフェイスに依存できるという事実を表現します。
正しい解決策: コンポーネントとインターフェイス間の関連付けを定義し、それを使用法と呼びます。
コンポーネントは多くのインターフェイスを使用でき、インターフェイスは多くのコンポーネントで使用できます。
3.ID
問題: エンティティには、属性またはベース キーの識別を表す ID と呼ばれる String プロパティが 1 つだけ必要です。
正しい解決策: OCL 制約が使用され、エンティティの属性に ID という名前の文字列属性が存在する必要があると規定されています。
4. 基本キー
問題: エンティティのすべてのインスタンスは、その属性の中にエンティティ PK タイプの属性を 1 つだけ持つ必要があります。ここで、エンティティ PK は特別なメタクラス属性です。
正しい解決策:
正しいメタモデル
5. メタレイヤーとインスタンス
このセクションでは、UML を例として使用して、複雑なモデリング言語を使用する際の落とし穴を説明します。
UML クラス図と UML オブジェクト図が示されています。オブジェクトは、クラス図で定義されたクラスのインスタンスです。これまでのところ、オブジェクトとクラスの間の関係は明らかにインスタンスの関係であり、これは同じクラスの複数のオブジェクトが存在できることをさらに証明しています。これはリンクとアソシエーションの関係でもあります。
この明らかな矛盾は、2 つの instanceof が同じ言語構造ではないことを観察することで簡単に解決できます。