Loading article…
コンピュータ プログラミングにおいて、機能指向プログラミング( FOP ) または機能指向ソフトウェア開発( FOSD ) は、ソフトウェア製品ライン(SPL)でのプログラム生成およびプログラムの増分開発のための プログラミング パラダイムです。
歴史
FOSD は、1980 年代後半にネットワーク プロトコルと拡張可能なデータベース システムにおけるレイヤー ベースの設計と抽象化のレベルから生まれました。[1] プログラムはレイヤーのスタックでした。各レイヤーは、以前に構成されたレイヤーに機能を追加し、レイヤーの構成が異なると異なるプログラムが生成されました。当然のことながら、このような設計を表現するためのコンパクトな言語が必要でした。初等代数がその要件を満たしていました。各レイヤーは、既存のプログラムに新しいコードを追加して新しいプログラムを生成する関数 (プログラム変換) であり、プログラムの設計は式、つまり変換 (レイヤー) の構成によってモデル化されました。左の図は、レイヤー i、j、h のスタックを示しています (h が下、i が上)。代数表記 i(j(h))、i•j•h、i+j+h は、これらの設計を表現するために使用されています。
時間の経過とともに、レイヤーは機能と同等とみなされるようになり、機能とはプログラム機能の増分です。プログラム設計と生成のパラダイムは、リレーショナル クエリ最適化の派生であると認識され、クエリ評価プログラムはリレーショナル代数式として定義され、クエリ最適化は式最適化でした。[2]ソフトウェア製品ラインは、各プログラムが機能の独自の構成によって定義されるプログラム ファミリです。FOSD はその後、機能のモジュール性、ツール、分析、および機能ベースのプログラム生成をサポートするための設計手法の研究へと進化しました。
FOSD研究の第2世代は、電気通信分野に端を発する機能の相互作用に関するものでした。その後、機能指向プログラミングという用語が作られました。 [3]この研究は、レイヤー間の相互作用を明らかにしました。相互作用では、他の機能と組み合わせるときに機能を適応させる必要があります。
第 3 世代の研究では、すべてのプログラムが複数の表現 (ソース、メイクファイル、ドキュメントなど) を持ち、プログラムに機能を追加する場合はそれぞれの表現を詳細化してすべてが一貫しているようにする必要があるという事実に焦点が当てられました。さらに、表現の一部は他の表現から生成 (または派生) される可能性があります。以下のセクションでは、FOSD の最新 3 世代、つまり GenVoca、[1] AHEAD、[4] FOMDD [5] [6]の数学的説明と、FOSD ツールを使用して開発された製品ラインへのリンクを示します。また、FOSD のすべての世代に当てはまる 4 つの追加結果は、FOSD メタモデル、FOSD プログラム キューブ、および FOSD 機能の相互作用です。
ジェンヴォカ
GenVoca（GenesisとAvocaを組み合わせた造語）[ 1]は、製品ラインのプログラムを定義するための構成パラダイムです。基本プログラムは、値と呼ばれる0項関数または変換です。
f -- 機能 f を持つ基本プログラム h -- 機能 h を備えた基本プログラム
機能は、プログラムを詳細化 (変更、拡張、改良) する単項関数/変換です。
i + x -- プログラム x に機能 i を追加します j + x -- プログラム x に機能 j を追加します。
ここで、+ は関数合成を表します。プログラムの 設計は名前付き式です。例:
p 1 = j + f -- プログラム p 1には機能 j と f がある p 2 = j + h -- プログラム p 2には機能 j と h がある p 3 = i + j + h -- プログラム p 3には機能 i、j、h があります
ドメインまたはソフトウェア製品ラインのGenVoca モデルは、基本プログラムと機能のコレクションです (メタモデルとプログラム キューブを参照)。作成できるプログラム (式) によって製品ラインが定義されます。式の最適化はプログラム設計の最適化であり、式の評価はプログラムの生成です。
- 注: GenVoca は、プログラムの段階的な開発に基づいています。これは、プログラムの理解と自動プログラム構築の鍵となる、設計の単純さとわかりやすさを重視したプロセスです。上記のプログラム p 3を考えてみましょう。これはベース プログラム h から始まり、機能 j が追加され (つまり、機能 j の機能が h のコードベースに追加され)、最後に機能 i が追加されます (つまり、機能 i の機能が j•h のコードベースに追加されます)。
- 注: すべての特徴の組み合わせが意味を持つわけではありません。 特徴モデル（命題式に変換可能）は、特徴の正当な組み合わせを定義するグラフィカルな表現です。[7]
- 注: GenVoca の最近の定式化は対称的です。つまり、基本プログラムは 0 (空のプログラム) の 1 つだけで、すべての機能は単項関数です。これは、GenVoca が重ね合わせによってプログラム構造を構成するという解釈、つまり複雑な構造はより単純な構造を重ね合わせることで構成されるという考え方を示唆しています。[8] [9] GenVoca のさらに別の定式化はモノイドとしてです。GenVoca モデルは、構成操作 (•) を持つ機能の集合です。構成は結合的であり、単位元 (つまり 1、単位関数) があります。すべての構成が可能ですが、すべてが意味を持つわけではありません。これが機能モデルが存在する理由です。
GenVoca の機能は、もともと C プリプロセッサ ( #ifdef feature ... #endif) 技術を使用して実装されていました。ミックスイン レイヤーと呼ばれるより高度な技術により、機能とオブジェクト指向のコラボレーション ベースの設計とのつながりが示されました。
先に
Algebraic Hierarchical Equations for Application Design ( AHEAD ) [4] は、 2 つの方法で GenVoca を一般化しました。まず、 GenVoca 値の内部構造をタプルとして明らかにしました。すべてのプログラムには、ソース、ドキュメント、バイトコード、メイクファイルなどの複数の表現があります。 GenVoca 値はプログラム表現のタプルです。たとえば、パーサーの製品ラインでは、基本パーサー f は文法 g f、Java ソース s f、ドキュメント d fによって定義されます。パーサー f は、タプル f=[g f , s f , d f ] によってモデル化されます。各プログラム表現にはサブ表現がある場合があり、それらにも再帰的にサブ表現がある場合があります。一般に、 GenVoca 値は、特定のプログラムの表現の階層を定義するネストされたタプルのタプルです。
プログラム成果物間の階層関係
例。端末表現がファイルであると仮定します。AHEAD では、文法 g f は単一の BNF ファイルに対応し、ソース s f はJava ファイルのタプル [c 1 …c n ] に対応し、ドキュメント d fは HTML ファイルのタプル [h 1 …h k ] です。GenVoca 値 (ネストされたタプル) は有向グラフとして表すことができます。パーサー f のグラフを右の図に示します。矢印は投影、つまりタプルからそのコンポーネントの 1 つへのマッピングを示します。AHEAD はタプルをファイル ディレクトリとして実装するため、 f はファイル g fとサブディレクトリ s fおよび d f を含むディレクトリです。同様に、ディレクトリ s fにはファイル c 1 …c nが含まれ、ディレクトリ df にはファイル h 1 …h kが含まれます。
- 注: ファイルはさらに階層的に分解できます。各 Java クラスは、メンバーとその他のクラス宣言 (初期化ブロックなど) のタプルに分解できます。ここで重要な点は、AHEAD の計算が再帰的であるということです。
2 番目に、AHEAD は、デルタと呼ばれる単項関数のネストされたタプルとして機能を表現します。デルタは、プログラムの改良(意味を保持する変換)、拡張(意味を拡張する変換)、または相互作用(意味を変更する変換) です。FOSD でそれぞれ発生するため、これらすべての可能性を表すために中立的な用語「デルタ」を使用します。
たとえば、機能 j が文法を Δg jだけ拡張し(新しいルールとトークンが追加される)、ソース コードを Δs jだけ拡張し(新しいクラスとメンバーが追加され、既存のメソッドが変更される)、ドキュメントを Δd jだけ拡張するとします。機能 j のデルタのタプルは j=[Δg j、Δs j、Δd j ] でモデル化され、これをデルタ タプルと呼びます。デルタ タプルの要素自体がデルタ タプルになることもあります。例: Δs j は、機能 j によって s fの各クラスに加えられた変更を表します。つまり、 Δs j =[Δc 1 …Δc n ] です。プログラムの表現は、ネストされたベクトルの加算によって再帰的に計算されます。パーサー p 2 (GenVoca 式は j+f) の表現は次のとおりです。
p 2 = j + f -- GenVoca 式
= [Δg j , Δs j , Δd j ] + [g f , s f , d f ] -- 置換
= [Δg j +g f , Δs j +s f , Δd j +d f ] -- 要素ごとにタプルを構成する
つまり、p 2の文法は、その拡張 (Δg j +g f )で構成された基本文法であり、p 2のソースは、その拡張 (Δs j +s f )で構成された基本ソース、というようになります。デルタタプルの要素自体がデルタタプルになる可能性があるため、合成は再帰的になります。たとえば、Δs j +s f = [Δc 1 …Δc n ]+[c 1 …c n ]=[Δc 1 +c 1 …Δc n +c n ] です。まとめると、GenVoca の値はプログラム成果物のネストされたタプルであり、機能はネストされたデルタタプルであり、+ はベクトル加算によってそれらを再帰的に合成します。これが AHEAD の本質です。
上記で示したアイデアは、2 つの FOSD 原則を具体的に示しています。統一性の原則は、すべてのプログラム成果物が同じように扱われ、変更されることを示しています (これは、上記の異なる成果物タイプのデルタによって証明されています)。スケーラビリティの原則は、すべてのレベルの抽象化が統一的に扱われることを示しています (これにより、上記のタプルの階層的なネストが生まれます)。
AHEADのオリジナルの実装は、AHEADツールスイートとJak言語であり、均一性とスケーラビリティの原則の両方を備えています。次世代のツールには、CIDE [10] とFeatureHouse [11]があります。
FOMDD とは
機能指向モデル駆動設計( FOMDD ) [5] [6] は、 AHEAD の考え方とモデル駆動設計( MDD ) (別名モデル駆動アーキテクチャ( MDA )) を組み合わせたものです。AHEAD 関数は、プログラムに機能が追加されたときにプログラム成果物のロックステップ更新をキャプチャします。ただし、プログラム成果物間には派生を表現する他の機能関係があります。たとえば、文法 g fとそのパーサーソース s fの関係は、javacc などのコンパイラ コンパイラ ツールによって定義されます。同様に、Java ソース s fとそのバイトコード b fの関係は、javac コンパイラによって定義されます。交換図はこれらの関係を表現します。オブジェクトはプログラム表現、下向き矢印は派生、水平矢印はデルタです。右の図は、プログラム p 3 = i+j+h = [g 3 ,s 3 ,b 3 ] の交換図を示しています。
可換図の基本的な特性は、2 つのオブジェクト間のすべてのパスが同等であることです。たとえば、パーサー h (左上のオブジェクト) の文法 g hからパーサー p 3 (右の図の右下のオブジェクト) のバイトコード b 3を導出する 1 つの方法は、バイトコード b hを導出して b 3に精製することですが、もう 1 つの方法は、 g h をg 3に精製してから b 3 を導出することです。ここで、 + はデルタ合成を表し、() は関数またはツールの適用を表します。
パーサー h の文法 g hからパーサー p 3のバイトコード b 3を導出するパスは複数あります。各パスは、実行によって開始オブジェクト (g f ) からターゲット オブジェクト (b 3 ) が生成されるメタプログラムを表します。潜在的な最適化があります。つまり、可換図の各矢印をたどるにはコストがかかります。可換図の 2 つのオブジェクト間の最も安価な (つまり、最短の) パスは測地線で、これは特定のオブジェクトからターゲット オブジェクトを生成する最も効率的なメタプログラムを表します。
- 注: 「コスト メトリック」は金銭的な値である必要はありません。コストは、生産時間、ピークまたは合計メモリ要件、電力消費、または「説明の容易さ」などの非公式なメトリック、または上記の組み合わせ (例:多目的最適化) で測定できます。測地線の考え方は一般的なものであり、このより一般的なコンテキストから理解および評価する必要があります。
- 注: 測地線には m 個の開始オブジェクトと n 個の終了オブジェクトが存在する可能性があります。m = 1 かつ n > 1 の場合、これはNP 困難な有向シュタイナー木問題です。
交換ダイアグラムが重要な理由は少なくとも 2 つあります。(1) 成果物 (測地線など) の生成を最適化できる可能性があり、(2) 開始オブジェクトからターゲット オブジェクトを構築するさまざまな方法を指定しているためです。[5] [12]ダイアグラムのパスはツール チェーンに対応します。FOMDD モデルに一貫性を持たせるには、1 つのオブジェクトを別のオブジェクトにマッピングするすべてのツール チェーンが実際に同等の結果を生み出すことが証明 (またはテストによって実証) される必要があります。そうでない場合は、1 つ以上のツールにバグがあるか、FOMDD モデルが間違っています。
- 注：上記のアイデアはカテゴリー理論に触発されたものである。[5] [6]
アプリケーション
- ネットワークプロトコル
- 拡張可能なデータベース システム
- データ構造
- 分散型陸軍火力支援シミュレーター
- プロダクションシステムコンパイラ
- グラフ製品ライン
- 拡張可能な Java プリプロセッサ
- ウェブポートレット
- SVG アプリケーション
参照
- FOSD メタモデル– 製品ラインの製品ライン
- FOSD折り紙
- FOSD プログラム キューブ– 多次元製品ライン
- 非常に高水準なプログラミング言語
参考文献
- ^ abc 「再利用可能なコンポーネントを使用した階層型ソフトウェア システムの設計と実装」(PDF)。
- ^リレーショナルデータベースにおけるアクセスパスの選択。 1979年5月30日。pp. 23–34。doi :10.1145/582095.582099。ISBN 9780897910019. S2CID 8537523。
- ^ 「機能指向プログラミング: オブジェクトの新たな見方」。2003 年 8 月 3 日時点のオリジナルよりアーカイブ。2015年 12 月 16 日閲覧。
- ^ ab 「スケーリング段階的改良」（PDF）。
- ^ abcd 「機能指向のモデル駆動型開発: ポータルのケーススタディ」(PDF)。
- ^ abc Trujillo, Salvador; Azanza, Maider; Díaz, Óscar (2007 年 10 月)。「ジェネレーティブ メタプログラミング」。ジェネレーティブ プログラミングとコンポーネント エンジニアリングに関する第 6 回国際会議の議事録。pp . 105–114。doi : 10.1145 /1289971.1289990。ISBN 9781595938558. S2CID 236715。
- ^ 「特徴モデル、文法、命題式」（PDF）。
- ^ 「特徴と特徴構成のための代数」(PDF)。
- ^ 「スーパーインポジション: ソフトウェア構成に対する言語に依存しないアプローチ」(PDF)。
- ^ 「すべての製品ラインバリアントの構文の正確さを保証する: 言語に依存しないアプローチ」(PDF)。
- ^ 「FeatureHouse: 言語に依存しない自動ソフトウェア構成」(PDF)。
- ^ 「増分テスト生成を使用したソフトウェア製品ラインのテスト」(PDF)。