自動化されたプログラミングがドキュメンテーションの作成とプログラム全体のロジックの開発（プリミティブから複雑な例まで）の問題を解決するのにどのように役立つかについて既に話しました 。 今日は、この目的のために使用できる他の概念とツール、および自動化されたプログラミングがそれらの中でどのような位置を占めるかについて説明します。
アンドリュー・ブチッタ / Flickr / CC
UMLが離陸しなかった理由
ほとんどの場合、ソフトウェアを開発するときに、システムに修正が必要な場合、プログラマは単純にコードを取得してエラーを修正し、顧客に結果を示します。
「今日、プログラミングは工学科学ではなく、数学を応用したものです。 同時に、プログラマーはすぐにコードを書くことを学びます」と、ITMO大学プログラミングテクノロジー学部長のアナトリーシャリトは言います。
ほとんどの場合、ソリューションアーキテクチャは言葉で、または単純なブロック図を使用して説明されます。 Boochメソッド、Jim Rumbachメソッド（OMT）、Aivar Jacobsonメソッド（OOSE）などのいくつかの以前の標準に基づくユニバーサルモデリング言語（UML）は、この問題に役立つはずです。 そして彼にはある希望がありました。
UMLが一種の「銀の弾丸」になることを期待して、人々はUMLを使用しようとしましたが、広く普及しませんでした。 研究者は、アルゴリズムと複雑なプログラムの動作を記述する一般的に受け入れられている手段として、状態図の大規模な拡散を妨げる3つの主な障害を特定します。
最初に、状態図に加えて、他のタイプの図を使用して動作を説明することが提案されましたが、それらの相互作用を管理する規則は規制されていませんでした。
「多くの人がこの言語は長すぎると考えています」 と研究者で起業家のジョルディ・キャボットは言います。 「これは、UMLで利用可能な多数のダイアグラムによるものです。」
第二に、プログラムの構造と動作を説明する図を共有するためのアプローチは提案されていません。 第3に、動作を説明する図は主に開発者が相互に通信するために使用されましたが、UMLの目的は仕様をプログラムコードでの後続の実装でコンパイルすることです。
同様の運命が他の多くの決定を待っていましたが、UMLに代わる本格的な選択肢ではありません。 ビジネスプロセス（ BPMN ）、エンティティ関係モデル（ ERM ）、データフロー図（ DFD ）、状態図などをモデル化するための規則のシステムについて話している。クリス・ファーマンが述べているように 、これはすべてコミュニケーションツール。
機械への移行
ただし、プロジェクト仕様は、設計プロセスの結果をキャプチャし 、開発者の心を他の問題を解決するために解放し、実装段階での入力としても使用されるため、必要です。
複雑な動作をするソフトウェアシステムの開発段階
自動プログラミングは、仕様を生成するプロセスを促進できるアプローチです。 動作中に、外部または他の入力の影響下で状態間の遷移が実行され、出力「パルス」が形成されるグラフが作成されます。 このために、顧客が目的のソリューションの詳細な作業を規定する技術タスクのテキストバージョンが最初に形成されます。
この後、入力および出力アクションの規則、情報のソースおよびレシーバーが発表され、図が描かれます。 遷移グラフにより、顧客はプログラマーが何をするかをよりよく理解できます。
正式な変換を使用して接続図と遷移図を作成すると、プログラミング言語でオートマトンを実装するコードを構築できます。 この後、仕様はシステム設計ドキュメントの一部になります。 プロジェクトのドキュメントは自然言語でコンパイルされ、通常、問題の説明、システムの構造と動作の説明、およびその使用例が含まれています。
OOPの自動記述
オートマトンアプローチの原則は、オブジェクト指向プログラミングでも使用されます。 これは、「クラスとしてのマシンと制御オブジェクト」の概念のおかげで可能です。 このようなモデルは、たとえばUniMod自動プログラミングツールで採用されています。 この原則に従って構築された複雑な動作を備えたシステムのアーキテクチャを下の図に示します。
個別のクラスを各コントロールオブジェクトと比較すると、開発段階でモデリング段階でこれらのオブジェクトを区別する努力が実装段階で消えないという事実につながります。 さらに、各リクエストまたはコマンドは、計算状態の厳密に定義された部分にのみアクセスできます。
一般に、複雑な動作を持つシステムを設計するプロセスは、次のように説明できます。
- システムが多くの独立した相互作用するエンティティに分割されているときにオブジェクトの分解を実行します。
- エンティティをクラスと一致させ、クラスインターフェイスと関係を定義します。
- 複雑な動作を持つエンティティを強調表示します-自動化されたアプローチが使用されるのは、まさにその説明のためです。
- 各エンティティの制御状態のセットを定義します。 要求とコマンドは、制御マシンの入力変数と出力変数、およびそのイベントへのインターフェイスのコンポーネントにマップされます。 それらに基づいて、制御オートマトン自体が構築されます。
- 選択されたオブジェクト指向言語での人間のクラスの実装。 コード生成は、自動または手動で実行できます。
このアルゴリズムは、開発プロセスのモデル（ウォーターフォール、反復、クラスターなど）の選択においてプログラマーを制限するものではなく、マルチイテレーションに簡単に変更できます。 さらに、既存のオブジェクト指向システムに変更を加えることができ、「ゼロから」開発する必要がありません。