Loading article…
フレーム技術(FT) は、再利用可能で機械適応可能な構成要素 (フレームと呼ばれる) からカスタム ソフトウェア[ 1 ]を製造する言語中立(つまり、さまざまな言語を処理) システムです。FT は、大規模で複雑なソフトウェア システムの設計、構築、進化に伴う時間、労力、エラーを削減するために使用されます。FT の根本的な利点は、ソフトウェア エンジニアリングを悩ませてきた、類似しているが微妙に異なるコンポーネントの増殖[ 2 ]を阻止できることです。この問題に対して、プログラミング言語の構成要素 (サブルーチン、クラス、テンプレート/ジェネリック) やマクロ、ジェネレータなどのアドイン技術では、実用的で拡張可能な解決策を提供できませんでした。
FTの実装は数多く存在する。Netron Fusionはビジネスソフトウェアの構築に特化しており、独自開発である。ART（Adaptive Reuse Technology）は、汎用的なオープンソースのFT実装である。ポール・G・バセットは、変化する要件や状況に合わせて（生成されたプログラムや手書きのプログラムを）適応させる際に発生する、反復的でエラーが発生しやすい編集作業を自動化するために、最初のFTを発明した。
現在、FT がドメイン モデリング、要件収集、アーキテクチャと設計、構築、テスト、ドキュメント作成、微調整、進化など、ソフトウェア ライフサイクルのほとんどの側面をどのように促進できるかを説明する膨大な文献が存在します[ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ]。FT と他のアプローチとの独立した比較[ 11 ]は、複雑なシステムの構築と保守に必要な時間とリソースを大幅に削減できることを裏付けています。その理由の 1 つは、FT がプログラマをソフトウェア固有の冗長性から保護することです。FT は、同等の XVCLフレームライブラリからCOTSオブジェクト ライブラリを再現しており、サイズは 3分の 2 小さく、よりシンプルです。[ 2 ] [ 6 ]カスタム ビジネス アプリケーションは、アセンブルされたソース ファイルのサイズの 5% ～ 15% のNetron Fusion SPC フレームによって日常的に仕様化および保守されています。[ 7 ]
以下に、2つの非公式な説明と、それに続くより正確な定義と説明を示します。
正式には、フレームとは、フレームテキスト（通常の（プログラム）テキストの0行以上と、FTのフレームプロセッサがカスタムプログラムを生成する際に実行するフレームコマンド）から構成される手続き型マクロです。各フレームは、ネストされたサブアセンブリの階層における汎用コンポーネントであると同時に、自身をサブアセンブリフレームと統合するための手順でもあります（統合の競合を上位レベルのサブアセンブリを優先して解決する再帰的なプロセスです）。出力は、通常はコンパイル可能なソースモジュールであるカスタムドキュメントです。
プロセッサは、コマンドを通常のテキストに置き換えたり、通常のテキストをそのまま出力したりすることで、フレームテキストを変換します。例：呼び出しを、呼び出されたフレームの処理結果に置き換えます。代入を何も置き換えません。インスタンス化は、フレームパラメータに割り当てられた式（文字列、算術式、ネストされたフレームパラメータの連結など）を評価した結果として得られる通常のテキストになります。
Invoke はフレーム間のコンポーネント関係を設定します。たとえば、図 1 では、FはJのコンポーネントであり、 CはJのサブコンポーネントです。もちろん、IとJ がFを呼び出すように、多くのコンポーネントが同じサブコンポーネントを呼び出すことができ、それぞれが異なるテキストを構築します。コンポーネント全体の構造は、一般的な半束[ 12 ]を形成し、各フレームはサブアセンブリのルートとなります。したがって、Cはそれ自身のサブアセンブリであり、FとC はFサブアセンブリのコンポーネントであり、J、F、およびCはJサブアセンブリのコンポーネントです。[ 13 ]
コンテキストスコープは、FT を他のモデリングおよび構築システムと区別するものです。各フレームは、そのサブアセンブリを統合するコンテキストを構成します。ネストされたサブアセンブリでは、下位レベルは統合する情報が少ないため、コンテキストフリーになります。統合の競合は、最もコンテキストに依存するフレームがパラメータを割り当てたり挿入したりすることを優先して解決されます。そのフレームのサブアセンブリ内の他のすべてのフレームに対しては、そのフレームは読み取り専用になります。[ 14 ] 図 1 では、フレームFとC がパラメータpに異なる値を割り当てると競合します。したがって、 F がC をオーバーライドします。つまり、フレームプロセッサはCのpへの割り当てを無視し、FとCのpにFの値を使用します。同様に、J はFとC の両方をオーバーライドできます。
コンテキストスコープが重要なのは、任意の数の（サブ）コンポーネントを特定のコンテキストに適合させるために必要なすべての調整が、そのコンテキストに明示的かつ局所的に行われるためです。コンテキストスコープがない場合、そのような調整はほとんどが暗黙的で、コンポーネントのバリアント内に散在し、隠蔽されてしまいます。このようなバリアントは増殖しやすく、不必要な冗長性と複雑さを招くだけでなく、システムの進化も不必要に困難で、エラーが発生しやすくなります。
仕様フレーム（SPC）は、アセンブリ全体の最上位に位置する、したがって最もコンテキスト依存度の高いフレームです。プロセッサは、図1のLやMなどのSPCから処理を開始し、完全なプログラムまたはサブシステムを作成します。原理的にはSPCですべての詳細をカスタマイズできますが、実際には、ほとんどの例外（および例外に対する例外など）は既にさまざまなサブアセンブリフレームによって処理されているため、SPCはアセンブリ全体のごく一部に過ぎません。
フレームライブラリが与えられた場合、SPCは論理的に構築するプログラムを内包します。したがって、SPCは主要な制御点としてソースファイルに取って代わります。テンプレートを使用してプログラムを作成するSPCを作成し、その後SPCを使用してそれらのプログラムを無期限に管理および進化させるのが一般的な方法です。この方法により、アプリケーションプログラマが知っておくべき詳細の数と管理すべき事項が大幅に削減されます。また、ソーステキストを手作業でコピーおよび編集する際に発生する冗長性、複雑さ、およびエラーも回避できます。ほとんどのコンポーネントが再利用され、事前にテストされているため、デバッグ時間も短縮されます。SPCはテストが最も少ないため、エラーはSPCに集中する傾向があります。
テンプレートとは、カスタマイズ方法を説明するコメントが埋め込まれた、典型的なSPC（ソフトウェアプロセスコード）です。通常、プログラムの種類は少数であり、それぞれの種類はテンプレートによって特徴付けられます。プログラマーは、テンプレートをコピーして入力することで、必要なフレーム、コンポーネント間の関係、または通常カスタマイズが必要な詳細を覚えておく必要なく、SPCに変換できます。
FTベースのドメイン固有言語（FT-DSL）は、その意味論（プログラムコードで表現される）がフレームに組み込まれたドメイン固有言語です。一般的なFT-DSLエディタは、DSL式とフレームの間で変換を行い、フレーム化された意味論を適応させて、DSL式のプログラムコード相当表現を記述します。このサブアセンブリの上位にあるSPCは、ドメイン固有言語では表現できないカスタマイズをプログラムコードで指定できます。そのため、ユーザーが変更されたDSL式からプログラムコードを再生成しても、以前のカスタマイズは失われません。[ 15 ]
フレームエンジニアリングは、ソフトウェアエンジニアリングをフレーム技術環境に適用するものです。これには、ドメイン分析、設計、記述、テスト、およびフレームとそれらが構築するシステムの共進化が含まれます。[ 10 ]フレーム化は、ボトムアップとトップダウンの両方で行われます。ボトムアップでは、フレームエンジニアは通常、類似のプログラム要素のグループ（テキストスニペットからサブシステムまで、あらゆる粒度）を統合およびパラメータ化して汎用的な同等物にすることでフレームを作成します。トップダウンのアプローチは、ドメインの専門知識と反復的なプロトタイプの改良を組み合わせたもので、アプリケーションとアーキテクチャの要件、企業標準、および投資を大幅に上回るリターンが得られる再利用可能な資産のセットを進化させたいという要望によって制約されます。（再利用は、フレームライブラリの合計サイズを結果として得られる構築物の合計サイズで割ること、および/または個々のフレームの再利用をカウントすることによって測定されます。）
成熟したフレームライブラリは、ソフトウェアプロジェクトのステークホルダーがシステムの目新しさにのみ注意を集中させ、堅牢なコンポーネントとアーキテクチャの大部分を当然のこととして扱うことができるため、コスト効率を高めます。成熟したライブラリは静的ではありません。フレームエンジニアは、selectコマンドを使用して再利用可能なフレームを無期限に進化させ、フレームの以前のバージョンから作成されたプログラムに修正を加える必要なく、新しい要件を満たすことができます。[ 7 ]