メタモデルの動的解釈

メタプログラミングに関する一連の記事を続けて、彼は情報システムの抽象化のレベルを上げるというかなり広範な仕事から絞り込みを準備しました。 Habrは確かに実用的なソリューションを愛していますが 、 私はまだそれらを持っていますが、多くの資料があり、それをいくつかの記事に分割する必要があります。 また、アプローチの有効性を示すために、多くのライブプロジェクトでの実装により、開発効率が数十倍に向上したと言えます。たとえば、週に数百のテーブルの構造を持つデータベースアプリケーションを作成し、数時間でプラットフォーム間でソリューションを移植します。 この記事は本質的に理論的であり、特定の用語で満たされていますが、残念ながらそれははるかに広範囲に及ぶでしょう。

「これは、私が制作作品で意味するもの、または前回私が言ったように、「オペラ・オペランズ」です。」 哲学では、「自然な自然」と「自然な自然」という「自然な自然」と「自然な自然」が区別されます。 類推により、「cultura culturata」と「cultura culturans」を形成できます。 たとえば、「失われた時を求めて」という小説は、作品としてではなく、「カルチュラカルチュラン」または「オペラオペラ」として作られています。 これはギリシャ人がロゴと呼んだものです。

// Merab Mamardashvili「古代哲学に関する講義」

問題の声明

情報システムの開発に対する古典的なアプローチは、明らかに、データ構造とプログラムコードを使用してドメインモデルを構築することです。 データ構造には、RAMおよび転送プロトコル、ディスク上のファイル、データベースの構造が含まれます。プログラムコードは、シミュレートされたデータで解決される問題のアクティブな（命令型、イベント型、または機能型）モデルです。



モデルが静的である多くのアプローチと技術​​があります 。 長期間（ソフトウェアの1つのバージョンの寿命）修正されました。 このような静的技術では、プログラムコード内の永続ストレージのデータ構造とオブジェクトの構造を同期する1つまたは別の手段が使用されます。 しかし、タスクのクラスがあり、そのような技術は受け入れ可能なソリューションではないため、ますます重要になっています。 開発者の介入とドメインモデルの変更を伴うシステムの新しいバージョンのリリースが必要であり 、最終的には情報システムのすべてのコンポーネントの再アセンブリが必要です 。 このような変更では、これらのコンポーネントをユーザーのワークステーションおよびサーバーに再展開する必要があります。Webアプリケーションの場合、このプロセスはよりソフトです。 展開はサーバーにのみ適用されます。 ただし、いずれにしても、モデルの変更は次の必要なアクションに関連付けられます。

• 展開中の特定の時間におけるシステムの通常の操作の中断（ユーザーセッションの中断、サービスの一時的な利用不能）、
• 永続ストレージのデータを古い形式から新しい形式に変換し、
• プログラムコードに変更を加える（開発、デバッグ、テストのための時間の割り当てを含む）
• 他のサブシステムとのすべての通信の改訂（データレベルとプログラム呼び出しレベルの両方）。

基本的に異なるアプローチを必要とするタスクのクラスを制限します。

• モデルの構造とパラメーターの変更が通常の通常の動作モードである、 動的サブジェクトエリアを持つタスク
• 疎結合データまたは変数構造、パラメーター、または処理ロジックを持つデータを処理するタスク、
• 処理されたオブジェクトのクラスの数がインスタンスの数に匹敵するタスク、またはインスタンスの数が1桁または2桁だけ大きいタスク
• ビジネスモデルの成功が、更新されたモデルと他のサブシステムとの統合の速度に依存するタスク（理想的には、リアルタイムまたはリアルタイムに近い統合が必要）
• 企業間データ交換、システム間統合（異種分散アプリケーションの統合を含む）、
• 大量ユーザーに関連しないアプリケーションタスク 。

タスククラスには、電子メール、ドキュメント管理、CRMシステム、インスタントメッセージングシステム、ソーシャルネットワーク、ニュースまたは情報Webリソースなど、長寿命のソフトウェアを作成できる一般的なコミュニケーションまたは情報タスクは含まれないことを強調します。 .d。 そのような技術の範囲は、次の産業に限定されます 。

• 企業アプリケーション情報システム、
• データベースアプリケーション
• 分析システム、報告システム、意思決定システム、
• パートナー企業間の統合システム。

そのようなタスクは伝統的に弱く自動化されているか、または限定的に自動化されていると考えられています 。 しかし、それらを解決する方法を探している場合、ソフトウェアソリューションの抽象化レベルを上げると、パラメーターと構造が変更された関連タスクを含む、より広範なタスクがカバーされると考えるのが自然です。 このようなモデルを一般的なタスクよりもメタモデルと呼び、それをサブジェクト領域に動的にマッピング（投影）する方法を提案します。この方法では、システムに供給されるメタデータに応じて1つのメタモデルから複数のドメインモデルを動的に取得できます。 このようなメタデータは、メタモデルを補完および指定する必要があります（構造とパラメーターを記述するため）。



ソフトウェアコンポーネントとデータ構造の抽象化を増やすことの難しさは何ですか：

1.プログラムコード内の有線識別子によるリンク。 データ構造およびプログラムインターフェイスへのアピールは、論理識別子を使用して実行されます。論理識別子は、最終的に呼び出しアドレス、メインメモリ内の相対アドレス、およびネットワーク呼び出しに変換されます。 また、静的（初期）バインディングと動的（後期）バインディングでは、システムコンポーネントのプログラムコードで識別子が保護され、さらにコード全体に識別子が散在しています。 また、抽象化を高めるために、コードにはドメインモデルを指す識別子を含めるのではなく、メタモデルを指す識別子のみを含める必要があります。

2.変数の静的型付けの使用 。 動的なサブジェクト領域を持つタスクの場合、変数の型（オブジェクト、クラス、式、定数、関数）が事前にわからないだけでなく、この型はコンパイル時にもわからない場合があります。 少なくとも、このような問題を解決するのに適したプログラミング言語は、型、クラス、および新しく作成された型の変数のイントロスペクションと動的作成をサポートする必要があります。

3.ドメインモデルのいくつかのクラスを混合し、システムの問題を解決します。 たとえば、「car」クラスは、画面に表示するビジュアルコントロール、ライブラリ、タグ、シリアル化の必要性、および構文構造、ディスクまたはデータベースへの格納方法、送信方法を知る必要はありません。ネットワーク、プロトコルやデータ形式、RAMに展開する形式など。

上記のプログラミング手法が行われないと主張することはありません。それらは、対象領域の静的モデルに関する問題を解決するために非常に適用可能で不可欠です。 静的および動的リンクは、動的ドメインを持つソフトウェアの体系的な側面を開発するのに適していますが、上記の手法は、ドメインのモデルまたはメタモデルの処理に関連付けられるべきではありません。

動的なメタモデルの解釈

動的解釈の原理を説明する前に、使用する用語の意味を明確にします。



メタモデルは、特定のドメインモデルよりも高い抽象化レベルの情報モデルです。 メタモデルでは、個別のタスクの機能については説明しませんが、広範なタスクについて説明し、これらのタスクで共通の抽象化、データ処理ルール、ビジネスプロセス管理を強調しています。 メタモデルは、実行時に既に必要な特異性と特異性に適応し、メタデータを動的コードに変換し、起動環境（仮想マシン、オペレーティングシステム、クラウドインフラストラクチャ）との動的リンクを保証します。



メタデータ -情報システムに入るデータの構造とパラメーターを記述するデータ。 メタモデルを解釈して、メタモデルは、着信データをすでに解釈するドメインモデルを動的に構築します。 メタデータには、宣言型および命令型の構造を含めることができます。たとえば、タイプ、処理ルール、スクリプト、正規表現などです。 メタデータがないと、受信データは完全ではなく、メタモデルはそれらがなければ解決される問題の動的モデルを形成できません。つまり、メタデータはデータの説明を補完し、受信データを解釈するメタモデルの手段を補完します



アプリケーション仮想マシンは、オペレーティングシステム、仮想マシン、またはクラウドインフラストラクチャと通信する動的な解釈環境です。 仮想マシンとは異なり、適用された仮想マシンはシステムタスクを提供しませんが、アプリケーションタスクは、動的リンクを使用してメタモデル、メタデータ、およびデータからモデルを作成するだけでなく、それらにすばやくアクセスするためにモデルの拡張フラグメントをRAMにキャッシュします。



動的解釈を備えたIPコンポーネントの図。 スキームの略語：MS-ステートマシン、K-コンポーネント構成、PX-永続ストレージ、L-ロジック。 コンポーネントからの呼び出しは下のコンポーネントに行き、リクエストは上から行きます（答えは反対方向に行きます）。



そのため、メタモデルはIPの各コンポーネントにあり（図を参照）、幅広いクラスのタスクのための抽象的な機能を含んでいます。 コンポーネントが起動すると、メタモデルはアプリケーション仮想マシンにデプロイされますが、その動的な解釈、つまり ドメインモデルまたは解決する問題に変換するには、永続ストレージシステム、ステートマシン、または情報システムの別のコンポーネントからデータとメタデータを取得する必要があります。 メタモデルの動的な解釈は、メタモデル、メタデータ、およびデータからドメインモデルを作成するプロセスです。 動的解釈は、実行時にクライアントとサーバーの両方で発生します。 動的解釈では、ドメインモデルはメモリに完全には組み込まれませんが、着信データが処理されるときに断片的に解釈され、アプリケーション仮想マシンにキャッシュして、複数の解釈の計算リソースのコストを回避できます。



メタモデルには、動的解釈に必要なメタデータの仕様が含まれています。 これがコンポーネントの最初のセッションであり、アクセス可能な永続ストレージおよびステートマシンにまだメタデータがない場合、識別子（アドレス）またはユーザーが入力した要求、またはシステムの別のコンポーネントから送信された要求を使用して取得できます（ただし、コンポーネントに配線されていません） 。 このプロセスは、アプリケーション仮想マシンのセッションコンポーネントによって制御されます。 将来的には、メタデータをキャッシュし、データをキャッシュして要求を最小限に抑え、ソース（ストレージシステムまたはリモートコンポーネント）のバージョンまたはチェックサムが変更されたとき、またはソースからイベントを受信したときにのみ更新できます。 変更されたメタデータを受信すると、RAMのメモリ内のドメインモデルが再構築されます。 ほとんどの場合、リストラを完了するのではなく、「怠lazな」（あなたが行くように）する方が最適です。



この方法でシステムコンポーネントに受信されたメタデータは、宣言的なパラメーターと命令型スクリプトでメタモデルを補完し、ドメインクラスを動的に構築し、受信したデータをそれらに入力し、動的に構築されたビジネスロジックを使用して処理できるようにします。 その結果、コンポーネントの機能と他のコンポーネントとの対話インターフェースは、システムを再コンパイルすることなく幅広いタスクで変更でき、新しいメタデータパラメーターを設定するだけで（スクリプトを変更しなくても）多くの変更が可能です。



動的に構築されたアプリケーションデータ構造とアプリケーションスクリプト（イベント、データ処理メソッド）は、動的モデルが実行されているアプリケーション仮想マシンのAPI呼び出しに依存します。 そのようなAPIは、起動環境のAPI（たとえば、オペレーティングシステム、モバイルオペレーティングシステム、仮想マシン、クラウドインフラストラクチャAPIなどのAPI）に「置かれ」ます。 モデルの動的な構築は、IPのサーバーコンポーネントとクライアント（ユーザー）コンポーネントの両方で行われます。 ユーザーインターフェイスは動的に構築され、APIの役割は、使用される視覚化ライブラリ（GUIコンポーネント）またはレンダラーレンダリング環境（HTML5、Flash、SilverLight、Adobe AIRなど）によって実行されます。 ネットワークインターフェイスも動的に構築できますが、送信プロトコルとデータ交換フォーマットは、もちろん固定（コンポーネントにコンパイル）するか、プラットフォームで利用可能なアクセス可能なセット（JSON、XML、YAML、CLEAR、CSV、HTMLなど）から選択する必要がありますなど）。



ユーザーはGUIでイベントをトリガーし、その結果ローカルデータ処理またはネットワークコールが発生します。 ネットワークインタラクションでの動的解釈の意味は、呼び出されたリモートプロシージャの識別子、それらのパラメーター、および返されたデータの構造が呼び出し側コンポーネントに事前に接続されておらず、メタモデルの動的解釈中にメタデータから取得されることです。 リモート側にも固定インターフェース（ネットワーク呼び出しを介して利用可能なコンパイル済みコンポーネントメソッドに事前接続）がなく、代わりにメタプロトコル（データ転送形式、処理がサポートされているパラメータータイプ）と構造を動的に読み取ることができるイントロスペクションメカニズムのみが事前に知られていますリモートネットワークインターフェイス。 たとえば、このようなメタプロトコルは、HTTP、JSONP、SSE、WebSocket、およびイントロスペクションインターフェイスと組み合わせることにより、宣言構造から作成できます。



動的解釈におけるステートマシンの役割は、ネットワークコール間でクライアントとサーバーの両方に必要なデータセットを持つセッションを保存することです。 これは、ユーザーアクションがモデルを特定の状態にし、後続の各ネットワーク呼び出しがトランザクション内の前の呼び出しに依存する、シーケンシャルまたはインタラクティブなヒューマンマシンデータ処理を提供するために必要です。 さらに、ステートマシンは、メタデータ、データ、さらに動的に構築されたモデルをRAMにキャッシュすることにより、トラフィックとコンピューティングリソースのコストを大幅に削減できます。 ステートマシンは、メインメモリ（プログラミング言語用）、ローカルストレージ（HTML5アプリケーション用の「ローカルストレージ」）、またはmemcachedサーバー（主にサーバーコンポーネント用）の構造を使用して実装できます。



DBMSでは、動的な解釈を備えた情報システムでの永続的なデータストレージが可能です。データスキームへのパラメトリックアプローチを使用したリレーショナルデータベース、またはストレージスキームメタデータのイントロスペクション 、キー値データベース、または「スキーマレス」 。 サーキットフリーのストレージ（MongoDBなど）は、動的解釈を備えたシステムにとってより自然であることに注意してください。 動的型付けと構造の柔軟な管理を提供します（型付けが弱いプログラミング言語に似ています）。 リレーショナルDBMSの場合、次のアプローチが使用されます：ドメインモデルを格納するメインテーブルに加えて、メタデータを格納するために追加のテーブルがデータベースに格納され、これらのテーブルにはメインテーブルの構造に関する追加情報が含まれます（高度なデータ型、処理パラメーター、関係の拡張分類および命令スクリプト） 。

結論

したがって、 メタモデルの動的な解釈を伴うIPコンポーネントの多層構造は、自己記述型リポジトリ（メタモデルの抽象化レベルによって制限されます）の下部で閉じ、データだけでなくメタデータも変更できる上部のユーザーに閉じます。これは、アプローチの柔軟性とシステムの変更の簡素化、構造と機能を変更する際に必要なユーザースキルのレベルの低下です。 ソフトウェアソリューションのアーキテクトとプログラマーが高レベルの抽象化、すなわち メタモデルの実装（もちろん、より難しいエンジニアリングタスク）。 しかし、最終的に、このアプローチは、抽象度の高いコードの再利用を増やし、コンポーネントバインディングの多くのタスクを自動化し、システムの変更と統合におけるヒューマンファクターの影響を減らし、ソフトウェアシステムのコンポーネント間の統合を簡素化することで利益をもたらします。

追加資料

1. メタプログラミング

2.いくつかの抽象的な層を持つデータベースの設計におけるメタモデルの使用：

パート1とパート2

3. 情報システムの統合