制限のオブジェクト言語（およびメタモデルについて少し）

私たちの意見では、オブジェクト制約言語（OCL）は、モデリングに携わっているか、モデル指向の開発に興味があるすべての人に知られるべきです。 しかし、彼は不当にネットワーク全般に注意を奪われており、実際、ロシア語の情報セグメントは悲惨なものにすぎません。 それがどのような言語であり、なぜ必要なのかは、この記事で説明されています。 この記事は、基本的なもの、完全な範囲、定義の正確さなどを装うものではありません。 そのタスク：1）この言語を聞いたことがない人にOCLを紹介する簡単な例を通して、2）それを聞いたことがない人のために、それを使用する新しい方法を発見することが可能です。

構造的および追加の制限

例からすぐに始めましょう。 Jiraなどのプログラムを開発して、プロジェクトやタスクを考慮し、これらのタスクを従業員に分配するとします。 このようなプログラムのデータモデルは、このように非常に単純化されているように見えます。







このような図を描いた後、サブジェクトエリアに制限を課しました。従業員、タスク、およびプロジェクトのみがそこに存在し、それらがまさにそのような属性を持ち、そのような接続で正確に接続できることを修正しました。 たとえば、サブジェクトエリアでは、従業員には氏名と生年月日が必要です。 ただし、タスクまたはプロジェクトにそのような属性を含めることはできません。 または、タスクの実行者は従業員にしかなれませんが、別のタスクまたはプロジェクトは実行者にはなれません。 これらは明らかなことですが、そのようなモデルを作成するとき、制限を策定することを理解することが重要です。 このような制約は、構造的制約と呼ばれることもあります。



ただし、多くの場合、ドメインをモデル化するときの構造的な制限では不十分です。 たとえば、プロジェクトマネージャーが同時にプロジェクトの参加者になれないという制限が必要になる場合があります。 さて、この制限はこの図には従いません。 追加の（非構造的な）制限の他の例を（キャッチ;-)で）示します。

1. 研修生はプロジェクトを管理できません
2. プログラマーは1つのプロジェクトを管理できますが、他のプロジェクトに参加することはできません。
3. リードプログラマは、一度に2つまでのプロジェクトを管理できます
4. プロジェクトにはリーダーが1人しかいません
5. 完全な同名の人が1つのプロジェクトに参加することはできません
6. 閉じたプロジェクトに開いているタスクを含めることはできません（実際の実行時間がある場合、タスクは閉じられていると見なされます）
7. タスクにエグゼキューターを割り当てる前に、計画実行時間を決定する必要があります
8. 終了する前に、タスクのスケジュールされた実行時間を決定する必要があります。
9. 1つのプロジェクトの従業員は、開いているタスクを1つだけ持つことができ、すべてのプロジェクトに対して5つ以下のタスクしか持つことができません。
10. 従業員は法定年齢でなければなりません
11. 従業員の名前は、スペースで区切られた3つの部分（姓、名、および後援者）で構成する必要があります（スペースを2重、3重などにすることはできません）
12. リードプログラマーがSigmundに電話できない
13. タスクの実際の作業時間は、計画より2回を超えることはできません
14. タスクをそのサブタスクにすることはできません。
15. タスクを完了する予定時間は、サブタスクの予定時間以上でなければなりません。
16. ...自分でいくつかの制限を考え出す...

まとめ



さまざまなモデリング言語を使用して、サブジェクト領域に課される構造的制約を記述することができます。

• オブジェクトのタイプ：オブジェクトは対応するクラスのインスタンスにしかなれません（従業員はプロジェクトプロパティを持つことができず、タスクは従業員とともにテーブルに保存することはできません、など）。
• 許容されるプロパティと関連付け。
• タイプについて：プロパティは特定のタイプの値のみを取ることができます。
• 多重度：必要なプロパティ/関連付けの値を指定する必要があります。複数の「1」を持つプロパティ/関連付けについては、いくつかの値を指定できませんなど。

OCLなどの追加言語を使用して、追加の制限を説明できます。

Eclipseを構成する

これらすべてを実際に試してみたい場合は、Eclipseが必要です。 そうでない場合は、次のセクションに進みます。

1. Eclipse （できればEclipse Modeling Tools）をダウンロードして解凍します。 すでにRational Software Architect 9.0（Eclipseベース）を使用している場合は、それを使用できます。
2. 必要なライブラリをインストールします。
   
   
   • Eclipseの場合。 メニューから[ヘルプ]-> [モデリングコンポーネントのインストール]を選択します。 表示されるウィンドウで、「Graphical Modeling Framework Tooling」、「OCL Tools」、および「Ecore Tools」が干渉しないことを選択します。
   • RSA 9.0の場合。 org.eclipse.gmf.tooling.runtime _ *。Jarおよびorg.eclipse.ocl.examples.interpreter _ *。JarファイルをC：\ Program Files \ IBM \ SDP \ plugins \フォルダーにコピーします（インストール、フォルダーによって異なります）多分少し違う）。
3. テストメタモデルでpm * .jarプラグインをインストールします。
   
   
   • Eclipseの場合。 これらのファイルを「$ ECLIPSE_HOME / dropins」フォルダーにコピーします
   • RSA 9.0の場合。 これらのファイルをフォルダー「C：\ Program Files \ IBM \ SDP \ plugins \」にコピーします（インストールによって、フォルダーは若干異なる場合があります）。 いくつかのバグのため、dropinsフォルダーは推奨されません。
4. Eclipseを再起動します。 メニューから[ファイル]-> [新規]-> [その他]を選択し、検索バーに「pm」と入力します。 「Pm Model」と「Pm Diagram」が表示されます。
5. テストモデルを自分で作成するか、 完成したものを使用できます。
6. コンソールを開きます：ウィンドウ->ビューを表示->その他...リストで「コンソール」を見つけます。
7. コンソールウィンドウで、[コンソールを開く]ドロップダウンリストを開き、その中の[インタラクティブOCL]を選択します（下図を参照）。
8. ダイアグラム上の任意のオブジェクトを選択し、コンソールの下部に「self」と入力して、「Enter」を押します。 すべてが正しく構成されている場合、次のようなものが表示されます。

メタモデルを使用したプラグインが機能しない場合は、 ソースコードから自分でコンパイルできます。 RSA 9.0では、比較的古いバージョンのGMFを使用して動作します。

例1。タスクを実行する予定時間は、サブタスクの予定時間以上でなければなりません。

OCLについて最初に知っておくべきことは、制約が常にオブジェクトの特定のクラスに適用されることです。 OCLルールを記述する前に、このクラスを選択する必要があります。 時々、この選択はあまり明白ではありませんが、今ではすべてが単純です。ルールはタスクに適用されます。 self変数を使用して、タスクの特定のインスタンスにアクセスできます。 タスクのプロパティの値を取得する必要がある場合は、変数名の後にポイントを書き、このプロパティの名前を書きます。 同様に、関連付けの名前を指定できます。 Eclipseで試してみてください。

ご注意



不要な問題を回避するために、モデル内のすべてのクラス、プロパティなど。 ラテン文字を使用して名前が付けられます。 オートコンプリートを使用して、このプロパティまたはそのプロパティがどのように呼び出されるかを正確に調べることができます（Ctrl + Spaceを押して呼び出します）。

最終的な制御規則を図に示します。







OCLの初心者にとってそれほど重要なことは、文字「。」と「->」の違いです。

ポイントの後に来るものは、値またはオブジェクトのコレクション内の各要素を指します。

矢印が値またはオブジェクトのコレクション全体に適用された後に来るもの。

表は、ポイントと矢印の使用例をいくつか示しています。

OCL式	OCL式の解釈
self.plan_time	「Plan_time」プロパティの値を取得します
自己。サブタスク	多くのサブタスクを取得する
self。サブタスク。	セット内の各サブタスクについて、「Plan_time」プロパティの値を取得し、最終的に多くのそのような値を取得します
self。サブタスクTime_plan-> sum（）	値のセット全体の合計を計算する
self.time_plan-> sum（）	タスクはPlan_timeプロパティに対して最大で1つの値を持つことができるという事実にもかかわらず、この値は暗黙的に（単一の要素を持つ）セットに変換されます。 sum（）演算は、結果セットに適用されます。

ご注意



collect（）およびoclAsSet（）操作の説明については、OCL仕様を参照してください。

例2。プロジェクトマネージャーは、プロジェクトの参加者であってはなりません。

図は、このルールのいくつかの同等の定式化を示しています。プロジェクト参加者のリストを取得し、リーダーがいないことを確認します。







自己変数は省略できますが、暗黙的に暗示されます。 ただし、一部の操作（select、exists、forAll、...）は、追加の暗黙的な変数（イテレーター）を使用して新しいスコープを作成することに注意することが重要です。 同時に、プロパティチェーンがどの暗黙変数に属しているかを理解するのはかなり困難です。 そのような状況では、すべての変数（または1つを除くすべて）を明示的に指定することを強くお勧めします。

例3。リードプログラマーは、一度に2つまでのプロジェクトを管理できます。

このようなルールを記述する初心者は、通常、まず最初にOCL if-then-elseであるかどうかを尋ねます。 はい、ありますが、ほとんどのルールでは、代わりに含意を使用する方が適切です。







含意の前提が偽である場合、残りの条件をチェックすることさえしません。 そして、真である場合、従業員が管理するプロジェクトのリストを取得し、クローズされたプロジェクトをそれらから除外し、そのようなプロジェクトの数が2つ以下であれば、条件が満たされていると考えます。

例4。完全な同名の人は1つのプロジェクトに参加できません

これがおそらく最初の重要なルールです。 従業員とプロジェクトの両方から始めて、定式化を試みることができます。 正しいクラスで開始することが重要です:-) isUnique（）オペレーションの存在がわからない場合は、このようなタスクに最初に出会ったときのように、モノステロイド構造のフレーミングを開始できます。







明示的な反復子宣言をルール（「y」変数）から削除し、ルールの解釈を試みます。 個人的に、私は何が起こるかを正確に覚えていません。 どの名前がアドレス指定されているかを明確に判断することができないのは間違いかもしれません。 または、イテレータがselfよりも優先される場合があります。 仕様を確認する必要があります。 いずれの場合でも、そのような状況を回避し、変数を明示的に指定することをお勧めします。

ご注意



イテレータは複数にすることができます。 OCL仕様を見て、OCLコンソールで実験してください。 仕様が操作isUnique（）をどのように定義するかを参照してください。

例5。1つのプロジェクトの従業員は、1つの開いているタスクのみを持ち、すべてのプロジェクトに対して5つ以下のタスクを持つことができます。

このルールでは、最初に開いているタスクのリストで変数を宣言します。 次に、2つの条件を確認します。 実際の実行時間が示されていない場合、タスクは開いていると見なされます。







このルールを定義するのに最適なクラスは何だと思いますか？ 従業員またはタスクの場合？

例6。タスクはそのサブタスクにはできません

図に描かれているルールの本質をすぐに理解しなかった場合、これは非常に自然なことです。 一方では、オブジェクトのクラス「タスク」があり、他方では、タスクには親タスクを示す関連付け「タスク」があります。 さまざまな方法でクラスおよびプロパティ/関連付けに名前を付けることをお勧めします。これにより、モデルの品質が向上し、OCLルールの理解が容易になります。







「額」ルールを実装することから始めましょう。 特定のタスクの関連付け「問題」がタスク自体を示しているかどうかを確認しましょう：「self。Task <> self」。 図では、自己変数への明示的な参照を削除しました。 これは致命的ではないように思われますが、OCL式では、プロパティまたは関連付けだけでなく、クラスも参照できます。 たとえば、次の式を使用すると、すべてのタスクのリスト「Task.allInstances（）」を取得できます。 この例では、OCLインタープリターは、クラスではなく「タスク」アソシエーションであると判断する可能性が高くなります。 しかし、繰り返しますが、このようなあいまいさを避けることをお勧めします。



この規則の2番目の欠点は、サブタスクが独自のサブタスクを持つことができることを考慮していないことです。 タスクは、そのサブタスクのサブタスクであることが簡単にわかります。 そうでないことを確認するには、ループまたは再帰関数が必要になる場合があります。 しかし、OCLにはループはなく、関数を使用するとすべてが非常に単純になるわけではありません。 しかし、素晴らしいClosure（）操作があります。 この操作はコレクションに対して定義されているため、ドットではなく矢印を前に置く必要があります。 コレクションの各要素について、closure（）オペレーションは引数として指定された式を評価し、取得した値をコレクションに結合します。その各要素に対してこの式を再度評価し、取得した値を結果のコレクションに追加します。

self.->union(self..)->union(self...)->union(...)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

図は、それぞれ親タスクとサブタスクの再帰に基づいたルールの2つのバージョンを示しています。 最良の選択肢は何だと思いますか（トリックの質問）。

ご注意



確かに、遅かれ早かれサイクルが必要になります。 ほとんどの場合、代わりにコレクションに定義された操作（select、exists、...）を使用できます。



それでもループが必要な場合は、次のようなものを試すことができます。

 Sequence{1..10}->collect(...)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

iterate（）操作にも注意してください。

例No.7。従業員の名前は、スペースで区切られた3つの部分（姓、名、愛用者）で構成する必要があります（スペースを2重、3重などにすることはできません）

明らかに、このようなルールは正規表現を使用して実装するのが最も簡単です。 ただし、 OCL仕様にはそれらを操作する操作はありません。 図では、正規表現を使用しないこのようなルールの実装例を示しています。 幸いなことに、標準のOCLライブラリは拡張可能であり、一部の実装では、matches（）操作がまだ存在するか、自分で実装することができます。

OCLコンストラクト

確認したすべてのOCL式は、Basic OCL（Essential OCL）で記述されています。 （ところで、それらはどのように違うと思いますか？）私たちが使用した主な構造をリストします：

• 自己変数-式は常にオブジェクトの特定のクラスにバインドされます
• 名前によるプロパティ（および関連付け）へのアクセス：
  
  
  • self.Actor.Tasks.Project.Manager.Tasks ...
• 算術および論理演算
• 関数呼び出し：
  
  
  • Name.substring（1、5）
  • Name.size（）=文字列の長さ
• コレクションを操作する：
  
  
  • 名前->サイズ（）= 1 従業員には単一の名前が必要です
  • タスク-> forAll（タスク|タスク。Time_plan> 10）
• 変数宣言：
  
  
  • let s1：Integer = name.indexOf（ ''）in
• 条件付きステートメント（if-then-else）

完全なOCLには、詳細に検討しない追加の構造がいくつかありますが、仕様を読むことでそれらに慣れることができます。

• メッセージ、状態
• パッケージ、コンテキスト、式の目的（パッケージ、コンテキスト、inv、pre、post、body、init、deriv）

宿題

OCL仕様を参照してください。



プリミティブデータタイプ、コレクションのタイプ（多数、シーケンスなど）を理解します。 OCLで日付と時刻を操作するためのプリミティブ型がないのはなぜだと思いますか？ まだ必要な場合はどうしますか？



Basic OCL、Essential OCL、Complete OCLの違いを理解します。



他のOCLルールを自分で実装し、Eclipseでチェックします。



記事に記載されているすべてのOCL式は、trueまたはfalseの値のみを取ることができます。 （ところで、あなたはこの声明に同意しますか？）あなたの意見では、OCL式は値の数値範囲、戻り文字列、値のセットまたはオブジェクトを持つことができますか？ このような非ブールOCL式はどのように使用できますか？



あなたの意見では、OCL式の計算結果は別のOCL式になりますか？

ボーナス メタモデルについて少し

以前に行ったことは、モデルの制限を説明し、特定の従業員、タスク、およびプロジェクトに関するこれらの制限を確認することだけです。 たとえば、プロジェクトマネージャーが同時にプロジェクトの参加者になることはできないというルールを説明しました。 さらに、すべてのプロジェクトと従業員一般に対してこのルールを説明しました。 そして、彼らは特定のプロジェクトと従業員のためにそれをチェックしました。

例No. 1.メタモデル「Employee-Task-Group」

それでは、1つ上のレベルに進みましょう。 たとえば、タクシーの注文サービスのために、別のアプリケーションを開発します。 同様のデータモデルがあります。 従業員の代わりに、タスクの代わりにドライバー、注文、そしてプロジェクトの代わりに都市がいるようにします。 もちろんこれは非常に条件付きの例ですが、アイデアを実証するためにのみ必要です。 または、たとえば、医師に予約するためのアプリケーションを開発する必要があります。 医師、部門、レセプションがあります。



これらすべてのモデルを見て、それらの一般的なパターンを見ることができます。 プログラマー、ドライバー、医師は基本的に同じものであり、従業員です。 オーダー、レセプション-これは、要約すると、単なるタスクです。 さて、市、支部、プロジェクトを要約しましょう。 それらを単なるグループと呼びます。 従業員とタスク間の接続は実行と呼ばれます。 従業員とグループ間のつながりは参加と呼ばれます。







そのような絵を描いて、あなたと私は主題領域の新しいレベルの認識に達しました-私たちはメタモデルを開発しました、私たちはそのようなモデルを記述することができる言語です。



記事の最初の部分で作成したモデルが、対象領域のオブジェクトに関する情報に構造的および非構造的制限を課したことを思い出してください。



同様に、メタモデルは、このメタモデルに従って構築されたモデルに構造的および非構造的制約を課します。 たとえば、このメタモデルに対応するモデルでは、図で赤でマークされたメタクラスに基づいた要素のみが存在できます。 たとえば、クラス「Building」、「Road」、または従業員、タスクなどではない類似のものは、モデルに表示できません。

ご注意



ところで、メタモデルはメタメタモデル（MOF、Ecoreなど）に基づいて構築されます。 興味がある場合は、OMG MOF仕様をお読みください。 一般的なケースでは、シミュレーションレベルの数は任意ですが、通常は2〜3で十分です。



ところで、MOF自体が構築されたメタメタモデルに基づいてどう思いますか？



脳の脱臼を恐れない場合は、記事Dragan Djuric、DraganGaševic、およびVladanDevedžic「The Tao of Modeling Spaces」を読んでください（私は個人的に彼らの苗字から脳の脱臼があります）。 概して、ソフトウェアを開発するとき、すべてはモデルであり（開発者の心の中の精神的なイメージからソースコード、ドキュメント、テストスクリプトなど）、開発プロセスは一部のモデルを他のモデルに変換することです。 モデル変換のトピックについては、後続の記事で開示する予定です。

あなたの意見では、上の図に示されているモデル（緑の長方形、青い線）はメタモデル（赤い長方形）に対応していますか？



明らかに、構造的制約に加えて、メタモデルには非構造的制約が含まれる場合があります。 後者については、OCLで再び説明できます。 このようなルールの例を図に示します。

ご注意



実際、この写真はあまり正確ではありません。 本格的なメタモデルの代わりに、UMLプロファイルがここで使用されます。これは、厳密に言えば、UMLメタモデルに基づいて構築された通常のUMLモデルです（これは、MOFメタメタモデルに基づいて構築されます）。 ただし、実際には、メタモデルは多くの場合ゼロからではなく、UMLプロファイルの形式で構築されます。 たとえば、 ISO 20022標準では、メタモデルは2つの同等のバージョンで実装されています。1）Ecoreに基づく本格的なメタモデル、2）UMLプロファイル。 この記事の目的の観点から、これらのニュアンスはそれほど重要ではないため、UMLプロファイルを「メタモデル」と見なします。

例2。メタモデル「Entity-Attribute-Link」

上記のメタモデルは少し人工的で価値がないように見えます。 より適切なメタモデルを構築してみましょう。 リレーショナルデータベースのデータ構造を記述できる言語を開発する必要があるとします。 この場合、参加者、タスク、プロジェクトなどの違い。 それほど重要ではありません。 これらはすべて、属性を持つことができ、関係によって相互接続されるエンティティです。 この例では、1対多、多対多の2種類の関係があります。 このようなメタモデルのメタクラスは、図の赤い長方形で説明されています。 図に示されているモデル（緑色の長方形、青色の線）はメタモデルに対応すると思いますか？ このモデルの各要素は、メタクラスの1つに属することができますか？







さて、最後に練習に移りましょう。 このために、Rational Software Architectを使用します。適切なUMLエディターを使用できます。 無料でイデオロギー的に正しいパピルスの例ですべてを表示できますが、残念ながら、あまり便利ではありません。



そのため、UMLエディターで新しい空のプロジェクトを作成します。 以下のステレオタイプを使用してUMLプロファイルを作成します。

ご注意



Attributeステレオタイプのプロパティに注意してください。 これは、モデル内の任意の属性が持つことができるプロパティのリストです。

次に、次のUMLモデルを作成し、作成したばかりのプロファイルを適用し、必要なステレオタイプを適用します。 これをすべて作成するのが面倒な場合は、 完成したプロジェクトを取得できます。







大まかに言えば、「メタモデル」に従ってモデルを構築しました。 モデルの各要素は、「メタモデル」のメタクラスの「インスタンス」です。

ご注意



繰り返しますが、厳密に言えば、そうではありません。 そして、プロファイル、ステレオタイプ、モデル、およびモデルのすべての要素-作成したものはすべて、UMLメタモデルのメタクラスのインスタンスです。 つまり プロファイルとそれを使用するモデルの両方が同じレベルのモデリングにあります。 しかし、実用的な観点からは、このプロファイルを「メタモデル」と見なすことができ、それに従ってモデルが作成されました。 これが何であるかを理解し、メタモデルが何であるかを理解したら、もう1つのステップがあります-ダイアグラムの長方形と線が何であるかを理解し、モデリングの観点からxmiファイルが何であるかを理解します。 上記の記事はこれに役立ちます。

次に、OCLのメタモデルの追加の制限について説明します。 たとえば、属性はエンティティに属している必要があります。 プロファイルではなく、本格的なメタモデルの形でメタモデルを作成した場合、このルールは非常に単純になります。

 owner.oclIsKindOf(Entity)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、そのようなルールを記述する必要さえありません。 AttributeとEntityの間に所有者の関連付けを作成するだけで、原則として他のタイプの要素をバインドすることはできません。



ただし、メタモデルはUMLプロファイルとして作成されたため、ルールが必要であり、一見したところ、ささいなことではありません。

 base_Property.class.getAppliedStereotype('PMProfile::Entity') <> null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このルールは、UMLメタクラス「プロパティ」を拡張する属性ステレオタイプに適用されます。 これは、モデル内でAttrbiuteステレオタイプのインスタンスを何らかのプロパティ（UMLメタクラス「Property」のインスタンス）にバインドできることを意味します。 後者では、特定の値minLength、maxLength、およびpatternを設定できます。 上記で作成したOCLルールは、Attributeステレオタイプのこのインスタンスのみをチェックします。



base_Propertyプロパティを使用して、ステレオタイプのインスタンスからプロパティに移動します。 次に、クラスの関連付けを介して、プロパティが属するクラスに移動します。 そして最後に、ステレオタイプ「Entity」がこのクラスに適用されているかどうかを確認します。

ご注意



これが仕様にどの程度対応するかはわかりませんが、ステレオタイプのインスタンスとUMLメタクラス（この場合はbase_Property）のインスタンスとの関連付けを省略できる場合があります。これは暗黙的にselfとして暗示されます。

ご注意



質問がある場合、クラスの関連付けを使用する必要があることをどのように見つけましたか。2つの方法があります。1）Eclipseでのオートコンプリート（Ctrl +スペース）および2） OMG UML仕様 。

上記のルールでは、EclipseベースのUMLエディターに標準のトリックを使用しています。 ただし、getAppliedStereotype（）操作はOCLの非標準の拡張機能であり、他のツールではサポートされていない場合があります。 同じルールを次のように書くことができます。

 class.extension_Entity->notEmpty()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロパティが属するクラスに、Entityステレオタイプに基づく拡張機能との接続（extension_Entityアソシエーションを介して）があるかどうかを確認します。

ご注意



2番目のオプションは、理論的には標準とより整合性があります。 ただし、Eclipseの古いバージョンでは問題が発生する可能性があるため、最初のオプションを使用することをお勧めします。

ご注意



プロファイル内で、base_Property、extension_Entity、およびクラスの関連付けを見つけてください。

図は、さらに3つのルールを示しています。

1. 属性にはタイプが必要です。
2. 1対多の関係では、一方の端の多重度は1以下で、もう一方の端の多重度は1以下でなければなりません。
3. エンティティに属するすべてのプロパティは、通常の属性または関係ロールのいずれかでなければなりません。

モデルをUMLプロファイルとしてではなく、MOFに基づくメタモデルとして作成した場合、これらのルールを通常の構造上の制限に置き換えることは可能だと思いますか？



MOFとEcoreは互いに非常に似ています。 根本的に異なるメタメタモデルを想像できますか？

メタモデルの制約の例

以下は、作成した1つの実際のメタモデルからの最も単純で最も複雑なルールの例です。 一方で、これはもちろんひどいコードの例ですが、他方では、いくつかのOCL構成体のデモンストレーションです:-)



ADTコンポーネントの最大再現性は0より大きい必要があります。

 upper > 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

制約関係を通じて継承されるADTコンポーネントは、親タイプの対応するコンポーネントと同じ位置にある必要があります。

 datatype.generalization->exists( getAppliedStereotype('SomeProfile::restriction') <> null) implies ( let parent : DataType = datatype.general->any(true).oclAsType(DataType) in let props : OrderedSet(Property) = parent.ownedAttribute-> select(getAppliedStereotype('SomeProfile::Component') <> null) in let cur : Property = props->select(x|x.type=self.type)->any(true) in cur <> null implies ( let prevEnd : Integer = props->indexOf(cur) - 1 in prevEnd = 0 or ( let allPrev : OrderedSet(Property) = props->subOrderedSet(1, prevEnd) in let requiredPrev : OrderedSet(Property) = allPrev->select(lower > 0) in requiredPrev->isEmpty() or ( let prevStart : Integer = allPrev->indexOf(requiredPrev->last()) in let allowedPrev : OrderedSet(Property) = allPrev-> subOrderedSet(prevStart, allPrev->size()) in let index : Integer = datatype.ownedAttribute-> indexOf(self.oclAsType(Property)) in index > 1 and ( let selfAllPrev : OrderedSet(Property) = datatype.ownedAttribute-> subOrderedSet(1, index - 1)-> select(getAppliedStereotype('SomeProfile::Component') <> null) in selfAllPrev->isEmpty() or ( let prevType : Type = selfAllPrev->last().type in allowedPrev->exists(x|x.type=prevType)))))))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OCLが必要な理由

プロファイルまたはメタモデルの制御ルール-あなたはすでにこれに関するすべてを知っています。



モデル内の制御ルール-そしてそれも。



操作および計算されたプロパティの仕様-OCL仕様を読むことで、これを自分で知ることができます。



モデル変換（ QVT 、 MOF M2T ）-これについては、以下の記事で説明します。



存在の意味の認識-このために、最初の絵を黙想してください。 イエスをどこに引き寄せますか？ そしてマトリックス？