プロジェクトジェネレーター

この記事では、大規模なソフトウェアおよび情報システムの開発用に設計された特定のソフトウェア製品に焦点を当てます。 この製品は「Project Generator」と呼ばれ、ソフトウェアシステムの開発プロセスが自動化の対象と見なされる場合、プログラミングへの手段的アプローチに基づいています。 このトピックは、前世紀の70〜80年代のどこかでかなり流行していましたが、私たちの意見では、このアプローチは今日では時代遅れではありません。 少なくとも、私たちのクリエイティブチームは、長年にわたって、独自のツールを使用してさまざまな目的で産業用自動システムを開発することができました。



記事の以下のセクションでは、この問題に対する私たち自身の見解の歴史的発展を考慮に入れて、大規模なソフトウェアおよび情報システムの開発に対する手段サポートへのアプローチのいくつかの技術的側面を検討します。 私たちの「自己掘り起こし」が過度に勤勉だと感じる視聴者の部分については、「現在の状況」セクションに直接行くことを提案します。

開発者の動機を理解するための歴史的な遠足

プロジェクトジェネレーターは、よく知られた理由により、航空設計局でプロジェクトの作業を完了し、他の分野で獲得した経験の応用を模索し始めるように開発チームが強制された四半世紀以上前に敷設されました。



銀行セクターのいくつかのプロジェクトに取り組んでいると、パラメーターの構成のみが異なる多くの類似した要素で構成されるいくつかのシステムを作成する必要がありました。 開発中のシステムは、ワークステーション-サーバー-データベースという2レベルのクライアントサーバーという当時の新しい技術に基づいて構築されました。 一般に、クライアントワークステーションのシステムの各要素は、特定のアクションを実行し、場合によっては別の画面に切り替えるために、データ入力フォーム、複数のテーブル、複数のボタンまたはメニュー項目を備えた画面を実装しました。 クライアント/サーバープロトコルでは、対応するデータの送信とサーバー応答の受信をプログラムする必要がありました。 サーバーは、クエリパラメータの取得、分析、データベースへの必要なクエリの実行、結果をクライアントのリクエストへの応答の形式で送信する手順を提供しました。



したがって、作業は2次元のように実行されました。 それらの1つは、新しいフラグメントの開発であり、これをプロシージャと呼びます。 開発中および問題の改良中に新しい手順が登場しました。 古い手順が変更されました。



ここで、「手順」という言葉は、たとえばパスカルの意味では使用されません。 サブルーチン、関数などのようなものです。むしろ、一種のプログラムコードテンプレートです。



2番目の次元は、手順を実装するための技術そのものです。 プロトコルが変更され、さまざまなセキュリティサブシステムが接続されたため、クライアントプログラムとサーバープログラムの両方で、以前に実装されたすべての手順のプログラムコードを一度に変更する必要が生じました。



さらに、多数の手順を使用して、クライアントとサーバーのプログラムが相互作用のプロトコルに準拠しているという点でプロジェクトの整合性を維持することが問題になりました。 たとえば、新しいパラメータが何らかのリクエストで追加された場合、対応する編集は、クライアントとサーバーの2つの異なるプログラムで一貫して実行する必要があります。



上記に関連して、このプロセスを自動化するアイデアが生まれました。 その頃までには、複雑な言語の構文解析プログラム（代数モデル、分析式の計算、その他の無関係なタスクの階層的記述を含むFakir概念プログラミングシステム）の実装の経験がありました。



その結果、さまざまなプロジェクトパラメータと一連の手順記述を含む見出しで構成されるプロジェクト記述言語が開発されました。 各プロシージャには、一意の名前、入力パラメータのリスト、入力パラメータと出力パラメータの指定を含むサーバーへのリクエストのリスト、および応答のタイプ（表または1セット）、およびこのプロシージャのコンテキストで実行できる提供されたアクションのリストがありました。



プロシージャで使用される名前付きデータ型は、その説明でプロジェクトの一部として指定されました。 説明は、構成のさまざまなコンポーネントとタイプの対応について自然に制御されていました。



このような記述は、プロジェクトジェネレーターの入力に送信され、プロジェクトジェネレーターはメモリ内にプロジェクトモデルを構築し、整合性の分析を行いました。 さらに、モデルに基づいて、クライアントおよびサーバープログラムモジュールを実装するプログラムのテキストが生成されました。



最も単純な場合のクライアントプログラムは完成した形式で生成されましたが、特殊な場合には、説明した単純なプロジェクトモデルで提供されていない特別なアクションを実行する手動ソフトウェア挿入を注文することができました。



プロジェクトプログラム自体はC言語で実装されました。 当時のサーバーはVAX VMSプラットフォーム上にあり、MS DOSを実行しているIBM PC上のクライアントプログラムでした（VAX VMSでも提供されていました）。 サーバー要求はC上のプリプロセッサで書き込まれ、Cプログラムのテキストに埋め込まれたSQLクエリを理解しました。



プロジェクトの説明には、説明したタイプに関するデータベーステーブルの説明も含まれていました。 これにより、特定のデータベーススキーマに準拠するための完全な解析を使用して、SQL言語のサブセットのプロジェクトの説明でデータベースへの単純化されたクエリを作成できました。 より複雑なクエリは、プリプロセッサツールを使用してサーバープログラムに実装されました。



説明された技術が根付いており、10年間にわたって時の試練に耐えてきました。 その助けにより、さまざまな分野でかなりの数のプロジェクトが行われました。



プロジェクトモデルが改善され、複雑になりました。 ソフトウェアおよびハードウェアプラットフォームは変化していました。 クライアントおよびサーバーは、MS WindowsおよびLinuxで機能し始めました。



上記の2次元の開発により、アナリストの仕事とシステムプログラマの仕事を分離することができました。 アナリストは適用されたタスクに焦点を合わせ、オペレーティングシステム、プロトコル、言語などのシステムプログラマーに焦点を当てました。



このテクノロジーの主な利点は、システム開発者が作成したコードが大幅に削減されることです。 1つの手順の記述には数十行かかる場合があり、通常、生成されるCプログラムコードは1桁大きくなります。 システムソフトウェアを変更しても、アプリケーション開発者のコ​​ードには影響しません。そのような変更は、ジェネレータの新しいバージョンで考慮されます。



プロジェクトジェネレーターを使用すると、最小限の開発者（多くの場合1人）で複雑なボリュームプロジェクトを実装できました。これは、プログラミングの複雑さに精通していなかったが、システム開発の数学的トレーニングと経験がある人々によって行われました。 つまり プログラマーではなく、アナリストが独立して複雑なプロジェクトを作成し、システムプログラマーを関与させることなく作業状態にすることができました。



開発の利便性を確保するために、プロジェクトを設計するためのさまざまな補助機能がジェネレータで絶えず改善されました。 プログラムテキストに加えて、さまざまなプラットフォームのすべてのプログラムコンポーネントの翻訳とアセンブリを実行するために、多数のバッチファイルが生成されました。 生成されたデータベース作成および変更ユーティリティ。 顧客に転送するためのインストールパッケージを作成する手順は自動化されました。



わずかな用語の混乱に注意してください。 上記のプロジェクト記述言語は、C、Pascalなどのようにプログラム演算子が存在しないという意味で、非手続き型言語として指定されることがよくありました。プロジェクト言語で言及されている手順は、まったく異なる概念です。

非手続き型プロジェクトモデルからユニバーサルプログラミング言語への移行

2000年代初頭の食中に食欲が増すにつれて、プロジェクトをさらに発展させるために使用される技術を改善する必要があるという理解がありました。



まず、プロジェクトモデル自体のフレームワークが、一連の型、データベース、一連のクエリプロシージャとして、タイトになりました。



第二に、サーバープログラムで、時にはクライアントプログラムでC言語を使用するのは面倒になりました。 アナリストのレベルが低すぎると、パラメーター、ポインター、ゼロバイトなどを渡すことの詳細と微妙さを掘り下げることです。



一方、銀行会計のニーズのためにデータベースへの単純なクエリではなく、複雑なデータ構造を持つ膨大なプログラムを書く必要があるプロジェクトが登場しました。 このようなプロジェクトでは、多くの手動コードを作成する必要があるため、プログラムテキストの自動生成の効果が低下しました。



ウィンドウインターフェイスへの移行に伴い、機会が生まれました。その結果、クライアントプログラムで、テキストと数字を含むテーブルだけでなく、写真、図面などのあらゆる種類のコンテンツも表示する必要がありました。



この点で、クライアント/サーバー相互作用プロトコルを複雑にする必要がありました。 これはすべて、まったく新しいプロジェクトジェネレーターを開発するインセンティブになりました。



新しい開発は、構造文書の概念に基づいていました。 プロジェクトジェネレーターのコンテキストでのドキュメントは、中心概念の1つを占めます。 会話レベルでは、ドキュメントはプログラムメモリ内のネットワーク構造のデータベースです。



文書（データベース）のネットワーク構造は、1対多の関係が確立されている行の間で、テーブルがその中に格納されていることを前提としています。 これは、長年の設計で使用してきたネットワーク構造データベースの古い、忘れられた概念です。



主なアイデアは、クライアントプログラムが複数のタプルやテーブルの形式ではなく、このリクエスト構造用に修正された任意のドキュメントの形式でサーバーから情報を受信することでした。 また、対称的に、クライアントはリクエストを処理し、一般的な形式でドキュメントを送信します。



したがって、サーバーはプロトコルから入力ドキュメントを読み取り、その構造をメモリに復元できる必要があります。 さらに、受信したドキュメントに基づいて、現在はビジネスロジックと呼ばれる特定のプログラムを実行します。このプログラムでは、データベース（メモリ内ではなく、実際の）との対話が想定されます。 その結果、プログラムは、プロトコルに従ってクライアントプログラムに送信するための出力ドキュメントを生成する必要があります。



クライアントプログラムは、受信したデータに基づいてアプリケーションウィンドウのコンテンツを生成するプログラムを提供する必要があります。



初期プロジェクトでは、以前のバージョンのジェネレーターと同様に、サーバー要求の本文を記述するためのC言語の使用、およびアプリケーションウィンドウのコンテンツを作成するためのプログラムを想定していました。 実験ツールとして、比較的簡単なプログラミング言語が開発され、C言語を置き換えるために単純なケースで設計されました。 この言語は、プロジェクト全体の記述言語の一部であり、ジェネレーターのベース言語の従来の名前を受け取りました。



基本言語の基本概念を以下にリストします。



名前付きデータ型の説明は、所定の固定長の文字列、異なる桁数、列挙型、マスク型（名前付きコンポーネントを含むビットマスク）、構造、そして最後に上記のドキュメントです。



文書を含む、指定されたタイプのパラメーターを持つ手順（Cの関数の類似体）。



主な標準演算子は、代入、条件演算子、forループ、whileループ、プロシージャコール、式です。 すべてが通常の標準言語に非常に似ています。 ドキュメントタイプの場合、そのコンポーネントを操作する手順が自動的に使用可能になります。



結果は圧倒的でした-現在のプロジェクトでしばらくしてから、Cプログラムのシェアは急速に減少して重要でないサイズになりました。 どういうわけか、プロジェクト開発者は、プロジェクトモデルだけでなく、クライアントとサーバーの両方のすべてのプログラムもこの言語のみで記述し始めたことが判明しました。



この予期しないプロセスの神格化は、ジェネレーター自体を基本言語で記述したことです。

開発のさまざまな段階でのプロジェクトジェネレーターアーキテクチャ

最初は、入力時にプロジェクトの説明、C言語の手動プログラムのテキストのセット、およびC用のデータベースプリプロセッサをジェネレーター構造が想定していました。 出力は、翻訳、アセンブル、配布、およびその他の有用なアクションのための一連のCプログラムとスクリプトです。



開発のこの段階でのジェネレーター構造は、次の図のような形式でした。









基本言語の出現により、ジェネレーターの構造は次のようになりました。 ジェネレーターでは、プロジェクトモデルのCコードジェネレーターとベース言語のテキストのCコードジェネレーターの2つのコンポーネントが区別されました。



プロジェクトモデルには、サーバー、アプリケーション、サーバーポート、セキュリティサブシステム、アプリケーションウィンドウの種類、ダイアログ、その他多くの有用なものなどの高レベルのエンティティが含まれています。 プロジェクトを生成するプロセスのこれらすべてのモデルエンティティは、Cプログラムを生成します。



開発者は、特定のルールに従って、プロジェクトのCプログラムの結果セットに含まれるCプログラムを作成します。



マニュアルCプログラムの一部は、ベース言語の同等のプログラムに置き換えることが可能になりました。これは、プロジェクトモデルとより簡単に統合できます。



したがって、基本言語の出現により、ジェネレーターの構造は次の図に示す形式になりました。









基本的な言語を開発する過程で、その上での入力テキストの量が増加し、Cでは減少しました。 また、モデル記述言語が開発されると、ベース言語のコード量も減少し、モデルエンティティの短い記述と長い記述に置き換えられます。



プロジェクト記述のモデルコンポーネントが複雑であるため、モデルからCコードではなくベース言語のコードを生成するというアイデアが生まれました。 これにより、モデルエンティティの実装のためにCの複雑なアドレス指定を監視する必要がなくなったため、ジェネレーター自体が簡素化されました。 Cのベース言語の翻訳者は、これらすべてを監視します。



その結果、発電機の構造は次のようになりました。

ジェネレーターのベース言語の基本概念

ベース言語は、汎用プログラミング言語を実装するプロジェクト記述ジェネレーター言語の一部です。 プロジェクトジェネレータを使用する開発者は、プロジェクトの一部として、この言語で通常のプログラムを作成できます。



Cとは異なり、ベース言語で個別のプログラムを作成してブロードキャストする方法はありません。 プログラムが数十のオペレータで構成されている場合でも、プログラムが唯一のコンポーネントとなるプロジェクトをユーティリティタイプのパッケージ（コンソールアプリケーション）として記述する必要があります。



より複雑な場合、ベース言語のプログラムはいくつかのパッケージで構成されます。



パッケージは、ジェネレーター（およびベース）言語の基本概念の1つです。 パッケージはプロジェクト内で一意の名前を持ち、何らかのタイプのパッケージとして宣言され、原則として、パッケージプログラムテキストを含む別のファイルとして提示されます。



プロジェクト記述は、ヘッダーとパッケージの順序付きリストを含むプロジェクト記述ファイルです。



ジェネレーターには、ジェネレーターの開発者によって作成され、プロジェクトのモデルエンティティを介して明示的または暗黙的に使用できる、さまざまなタイプのいわゆるシステムパッケージの大規模なセットが含まれています。 開発者パッケージは、システムパッケージの名前と一致する必要はありません。



「Hello world」のような単純なプロジェクトの例を次に示します。 ここでは、プロジェクトのディレクトリ構造は考慮しません。 この場合、2つのファイルを作成する必要があります。プロジェクトの説明と、プロジェクトの一部としてのユーティリティの説明で、それらの名前を作成します。



プロジェクト名をこんにちは、プロジェクト内のユーティリティの名前はworldです。 次に、hello.genとworld.utilityの2つのテキストファイルを作成する必要があります。



Hello.genファイル：





World.utilityファイル：





このようなプロジェクトの生成およびアセンブリの結果、実行可能モジュールworld.exe（MS Windowの場合）またはworld（Unixの場合）が取得されます。 起動時に、プログラムはコンソールに文字列「Hello world！」を出力します。



より複雑な例を考えてみましょう。この例では、ユーティリティパッケージに加えて、タイプパッケージの単純なパッケージが使用されます。



Pkgexample.genファイル：





Mypkg.packageファイル：





Myutl.utilityファイル：





この場合、プロジェクトの一部として、mypkgソフトウェアパッケージとmyutlユーティリティの2つのパッケージがあります。



mypkgパッケージでは、外部仕様のセクション（implementationキーワードの前）で、t_myint型の説明は基本型int（32ビット整数）から派生し、2つの入力パラメーターa、bとt_myint型の2つの入力パラメーターと1つの出力パラメーターを持つsumプロシージャの仕様同じタイプ。



implementaionキーワードの後に​​記述されたものはすべて、パッケージ内でのみ使用可能です。



localsumプロシージャには、外部のsumプロシージャと同様の見出しがありますが、fprocキーワードで始まります。これは、ローカルオブジェクトであることを意味します。 ヘッダーの後に、セミコロンの代わりに、中括弧で囲まれたステートメントのブロックがあります。これは、Cのステートメントとよく似ています。 ブロック内には、1つの代入演算子があります。 下品な平等とは異なり、ここでの割り当ては「：=」という文字で与えられます。



基本的な数学教育を受けた発電機の開発者にとって、a = a + 1のようなC言語のような構造を見るのは苦痛でした。 そのような演算子では藻類パスカル表記を使用することが決定されました。



ローカルlocalsumプロシージャの後、仕様セクションで宣言された合計外部プロシージャの本体が検索されます。 以前に指定されたプロシージャの説明は、ローカルプロシージャの説明に似ていますが、キーワードfprocdeclとパラメータの正確なコピーがあります。 次は、ローカルプロシージャコールlocalsumが配置されているプロシージャの本体ブロックです。



myutlパッケージには、中括弧で囲まれたステートメントブロックを含む単一のメインセクションがまだあります。 ユーティリティのメインセクションは、パッケージの最後にある1つのインスタンスにある必要があります。 これは、Cのメイン関数の類似物です。 このブロックのステートメントは、ユーティリティの起動時に実行されます。



ブロックには3つの演算子があります。 最初の演算子は3つの変数p、q、rの説明であり、最初の2つは定数式で初期化されます。 変数タイプは、パッケージ名の後にドットが続き、このパッケージで定義されたタイプ名が続く形式で指定されます。



2番目のステートメントは、タイプなどのポイント式で指定されたmypkgパッケージからのsumプロシージャの呼び出しです。



3番目のオペレーターは、コンソールへのデバッグ印刷です。



2つの整数定数の合計を計算するためのこのような手の込んだプログラミングは、公開されるテキストの最小サイズで可能な限り多くのベース言語の可能性を示す目的でのみ行われました。



より複雑な例は、ドキュメントタイプの操作を示しています。



docexample.genファイル：





Doc.packageファイル：





Doctest.utilityファイル：





docexampleプロジェクトには、doc.packageとdoctest.utilityの2つのパッケージが含まれています。



docパッケージは、指定された長さのUTF-8エンコーディングで文字型t_orgname、t_addr、t_phone、t_empnameを記述します。



type orgs-document（dqueueキーワード）。 組織orgとempの2種類のレコード-組織と従業員について説明します。 括弧内には、示されたタイプのレコードのコンポーネントがリストされています。 本質的に、これは、2つのテーブルとその中の指定された列でデータベースを記述することに似ています。



ネットワーク構造は、1対多のレコード間の関係によって定義されます。 このような関係はセットとして導入されます。 したがって、org_empセットは組織と従業員の関係を導入し、多くの従業員が組織で働くことができますが、各従業員は1つの組織でしか働いていません。 ownerキーワードは、セットのレコード所有者タイプを設定します。 キーワードメンバー（セットメンバー）は、セットのメンバーレコードのタイプを指定します。



所有者のないコレクション（この例ではorgs_org）は単数形と呼ばれ、ドキュメント内の単一のコピーに存在します（その所有者は条件付きでドキュメント/データベース全体です）。



ドキュメントタイプ宣言は、そのようなドキュメントのレコードタイプを、レコードの名前と一致する名前で自動的に宣言します。 その際、パッケージ内の型名の一意性に留意してください。



さらに、各レコードおよび各セットに対して、これらのオブジェクトを操作する手順が自動的に生成され、利用可能になります。



そのため、組織レコードの場合、ドキュメントへのリンク、作成されたレコードインスタンスへのリンクを取得するためのレコードタイプの出力変数という2つのパラメーターでorg_creプロシージャが作成されます。



org_emp_insプロシージャは、3つのパラメーターを持つorg_empセットに対して作成されます：org型のインスタンスへの参照-セットの所有者レコード、emp型のインスタンスへの参照-セットメンバーのレコード、整数-セット内の位置（負の数-セットの末尾からの番号付け）。



org_emp_memプロシージャは、3つのパラメーターを持つorg_empセットに対しても作成されます：org型のインスタンスへの参照—セットの所有者レコード、整数—セット内の位置、および出力パラメーター— emp型のインスタンスへの参照—メンバーのレコード。



org_empセットの場合、1つのemp型パラメーター（入力および出力）を使用してorg_emp_nextプロシージャーが作成され、セットの次の要素に移動します。



多機能式isnull（...）およびisnotnull（...）は、ドキュメントレコードなどの変数に適用されます。



このプロジェクトでは、randおよびrand_testシステムパッケージを使用して、ランダムなテストデータを生成します。



解析の力を示すために、別のサンプルプロジェクトを検討してください。



Calc.genファイル：





Calc.utilityファイル：





計算ユーティリティの開発が表示され、その入力で式が提供され、出力で式の計算値が提供されます。



tlex解析システムパッケージを使用すると、このパッケージの幅広い組み込み機能を使用して、非常にシンプルで最小限のコードで式を解析するタスクを解決できます。 この例は、解析の問題を解決することがいかに簡単でコンパクトであるかを示しています。



プロジェクトにはtlexシステムパッケージが含まれます-文字列の字句解析。 解析は、再帰降下法を使用して行われます。 各非終端文法シンボルは、解析プログラムの手順に対応しています。



文法は、どの終端記号が読み取り位置にあるかを見つけた結果に基づいて、構文解析に使用する文法規則を決定できるように縮小する必要があります。 これをこの形式にすることは、ほとんどの既存の言語にとって難しいことではありません。 これを行うには、初期文法の観点から誤ったテキストを許可するサブ言語を定義するだけで十分です。 将来的には、構築された構文解析ツリー（何らかの形式で）に基づいて、正確性を確認できます。



実際、実際のプログラムは文脈自由文法で記述されていないため、これは常に実際の翻訳者で行われます。 KSの文法では、さまざまなオブジェクト（型、プロシージャ、変数）の使用が禁止されている言語を記述することはほとんどできません。 したがって、この種のチェックはとにかく行われます。



この場合、分析は、コンソールのプログラム呼び出しの入力パラメーター文字列に対してcalcユーティリティで実行されます。 パラメーターを1つだけ指定しないと、エラーメッセージが表示されます。 パラメータが設定されている場合、結果の計算で解析されます。 分析が成功すると、計算結果がコンソールに出力されます。 エラーが発生した場合、エラーが検出されたテキストの位置を示す情報を含む診断メッセージが発行されます。



言葉の文法。 加算式は、演算記号+または-で区切られた乗算式のシーケンスです。 乗算式は、演算記号*または/で区切られた一連の因子です。 乗数は、カッコ内の加算式または数値です。



加算式はsyn_addプロシージャに対応し、乗算式はsyn_mulに対応し、乗数はsyn_factに対応します。



構文手順のパラメーター：buf-分析するテキスト、xlex-字句解析コンテキスト（読み取り位置を含む）、dval-出力パラメーター-計算値。



tlexパッケージの字句解析手順を使用しました。



関数tlex.sample-現在の位置で、パラメーターに提示されたサンプルの存在を確認します。 パターンが文字で始まる場合、認識されるテキストはパターン全体と一致する必要があり、サブストリングとしてパターンを含まない必要があります。 つまり procサンプルの可用性を確認すると、読み取り位置のprocdeclテキストは肯定的な結果になりません。 トークンを認識すると、すべてのスペース文字、行末、タブなどがスキップされ、CおよびC ++のスタイルのコメントもスキップされます。



Tlex.sample_errプロシージャ-tlex.sampleプロシージャでサンプルの有無を確認し、存在しない場合は、分析された文字列の読み取り位置に関する情報を含むメッセージテキストで致命的なエラーを開始します。



このような関数/プロシージャのペアは、多くの種類のトークンのtlexパッケージに存在します。 この関数を使用すると、トークンの存在を確認でき、プロシージャがチェックし、不在の場合はエラーを開始します。



tlex.doubleプロシージャー-現在の位置で、123.456形式の10進数の存在を確認します。 NOSIGNパラメーターは、語彙レベルで+-記号を禁止し、これらの文字を文法レベルで認識します。 NOFRACパラメーターは、小数点付きまたは小数点なしの数値を有効にします。

小計

前のセクションでは、コア言語機能の一部を示すサンプルプロジェクトを提供します。 これはガイドではなく、言語のガイドではなく、トレーニングの例のセットでもないことに注意してください。 これは単なる紹介文です。



読者がこの場所にたどり着くと、非常に論理的な質問があります-この基本言語には他の言語にはないものがあり、その実装にエネルギーとお金を費やす必要があるのはなぜですか？



まず、ベース言語は、プロジェクトを記述するための完全なジェネレーター言語の一部です。 データベース、SQLクエリ、サーバー、サーバーポート、アプリケーション、アプリケーション画面レイアウト、ダイアログ、構成ファイル、任意のデータ型のJSON変換、関連テーブルの抽象セットなどのモデルエンティティを記述するためのジェネレーター言語には、さまざまな構造があります。さまざまな環境（dom-model、gtk、qt）などのマッピング。このリストは絶えず更新され、古いエンティティは消滅し、新しいエンティティが表示されます。 そして、これらの構造はすべて、主に基本言語で実装されています。 ジェネレーター開発の初期段階では、モデル設計はCで直接実装されました。 ベース言語を使用すると、モデルと言語の統合が容易になりました。



第二に、ジェネレーターは、プログラムコードの量が数十万行で測定される場合に、大規模プロジェクトの実装を目的としています（その場合のみ、大きな利点をもたらします）。 大きなプロジェクトでの作業は、最大数千行の小さなプログラムの開発とは根本的に異なります。 小さなプログラムでは、開発者はその構造に関するすべての情報を頭の中に保持できます。 大規模なプログラムでは、これは不可能です。 そのようなプログラムを変更する過程で、余分な未使用コードが必然的に増加します。 このプロセスに対抗するために、ジェネレーターは多数の手段とコードチェックを行います。



プロシージャの見出しでは、仮パラメータは入力、入力および出力、出力のみとして指定されます。 プロシージャ本体の変換中に、この仕様の正確性がチェックされます。 たとえば、特定のパラメータが出力として宣言されており、プロシージャの本文に、値が割り当てられる前に変数が読み取られるために使用されるパスが演算子ツリーにある場合、この状況はエラー診断につながります。 これは、このプロシージャで呼び出される他のプロシージャの入力と出力に関する情報を使用します。 変数が構造のタイプを持っている場合、そのような分析は、任意のレベルでそのコンポーネントごとに実行されます。



構造ドキュメントの場合、すべてのレコードとセットに対して提供されるすべての操作の完全なセットを注文できます。 これにより、コードが大幅に冗長になります。 各レコードおよびセットに必要なすべての操作のリストを明示的に設定することができます（そして必要です）。 この場合、プロジェクトで使用されなかった操作が特定され、適切な診断が発行されます。 さらに、たとえば、レコード作成操作が使用されない場合、これもエラーとして扱われます。 または、セットの場合、セットに含まれて使用されなくなった操作があるため、エラーも生成されます。



このテキストを書いている時点では、プロジェクトモデルの古いエンティティを削除するプロセスがありました（古いサーバーとアプリケーションは新しいものに置き換えられます）。 古いオブジェクトと新しいオブジェクトが同時に存在したときのジェネレーターコードでプロジェクトモデルを表すドキュメントには、約250種類のレコードと800種類以上のセットがありました。 古いエンティティを削除すると、レコード数は190に減少し、580に設定されます。非常に多くのオブジェクトとそれらの操作の使用を手動で追跡することは非常に難しいことは明らかです。



実例として、金融活動の分野での1つの実際の、既に完了したプロジェクトのデータを示します。 ジェネレーターのプロジェクトには、合計203829行の1294ファイルが含まれていました。 結果のCコードには、2608812行のファイルが4605個ありました。 プロジェクトには23種類のサーバー、リクエストを受信する29のポート、11のアプリケーション、27のユーティリティ（コンソールプログラム）があり、これは1つだけですが、システム全体で最大のプロジェクトです。 このシステムには、個々のパッケージのエクスポートとインポートによって相互接続された7つのプロジェクトが含まれていました。 システムを7つの異なる発電機プロジェクトに分割し、発電量を削減しました。 偏執的な整合性チェッカーなしでこのような経済を管理することは非常に問題です。

現在の状況

プロジェクトジェネレーターは、開発作業の全期間を通じて、開発チームの内部プロジェクトとして開発されました。 適用されたプロジェクトで作業する過程で、お客様は場合によっては、プロジェクトに関連する何らかの方法でジェネレーターを使用して自分の開発に使用する機会がありました（そして、制御するのが難しいだけではありません）。 プロジェクトの作業中に、タスクのステートメントが明確になり、ツールの新しいニーズが発生しました。これは、ジェネレータの次のバージョンで実装されました。 冒頭で述べたように、それは応用と手段の2つの次元での開発でした。 つまり ジェネレーターは次の（次の）プロジェクトと共に開発されました。 定期的に、ジェネレータ自体を一般向けのソフトウェア製品にすることについての話がありました。 このテキストは、ある意味では、このシステムを非常に一般に公開する試みです。



現在、ジェネレータには、さまざまなバージョンのデータベース管理システムOracle、Postgres、MySql、MS Sql、Sqliteを操作するためのツールがあります。 データベースの操作には、ジェネレータツールを使用したデータベーススキーマの記述、データベーススキーマ内のクエリテキストの完全な構文およびセマンティック制御を使用した特別な言語（SQLのかなり代表的なサブセットが使用されます）でのSQLクエリの記述が含まれます。 さまざまなタイプのデータベースの代替を指定するツールがあります。 また、いわゆる動的クエリを記述できます。これは、制御なしでデータベースに転送されます。



サーバーは最新のネットワークツール-UnixのEpollおよびMS WindowsのI / O完了に転送されます。



最近まで、アプリケーションは単一のインターフェイスモデル（いわゆるウィンドウレイアウト）を使用して開発され、Microsoft WIN32 GUIとUnix用GTK-3の2つの実装がありました。これら2つのシステムの1つのモデルを維持することは、WIN32 GUIの開発ツールが未発達であるため、ますます困難になっています。そのため、GTK-3とQt-5の2つの異なるアプローチが現在開発されています。モデルは異なりますが、非常に似ています。それらを分離するか、異なる実装で個々の例外と組み合わせようとする決定が下されるまで。



WEB開発で使用するJava Scriptパッケージのエクスポートを積極的に開発しています。ブラウザーでは、サーバーからjson形式のデータを受信し、プロジェクトで記述されたタイプを操作するための関数を使用できます。たとえば、Java Script用に生成された構造ドキュメントを使用できます。



WEB開発では、HTMLのかなり代表的なサブセットが、基本言語での挿入を使用して実装されます（PHPと同様）。同時に、HTMLマークアップは、ネストタグの正確性について監視されます。そしてもちろん、ベース言語での挿入は、ジェネレーター全体で通例であるように、完全に制御されます。



主にモバイルプラットフォーム（Android）でコンポーネントシステムを開発するために、Java言語へのパッケージのエクスポートを実装しました。