フローベースプログラミング

コンピュータプログラミングにおけるフローベースプログラミング( FBP ) は、アプリケーションをブラックボックスプロセスのネットワークとして定義するプログラミングパラダイムです。ブラックボックスプロセスは、メッセージの受け渡しによって定義済みの接続を介してデータを交換し、接続はプロセスの外部で指定されます。これらのブラックボックスプロセスは、内部を変更することなく、無限に再接続してさまざまなアプリケーションを形成できます。したがって、 FBP は本質的にコンポーネント指向です。

FBP は、境界付きバッファ、定義された有効期間を持つ情報パケット、名前付きポート、および接続の個別の定義に基づく、 データフロー プログラミングの特定の形式です。

フローベースのプログラミングでは、「データ ファクトリ」のメタファーを使用してアプリケーションを定義します。アプリケーションは、ある時点で開始され、完了するまで 1 つずつ処理を実行する単一の連続プロセスではなく、 「情報パケット」(IP) と呼ばれる構造化されたデータ チャンクのストリームを介して通信する非同期プロセスのネットワークとして見なされます。このビューでは、アプリケーション データと、目的の出力を生成するためにアプリケーション データに適用される変換に焦点が当てられます。ネットワークは、通常「スケジューラ」と呼ばれるソフトウェアによって解釈される接続のリストとして、プロセスの外部で定義されます。

プロセスは、固定容量の接続によって通信します。接続は、プロセス コードとネットワーク定義の間で合意された名前を持つポートによってプロセスに接続されます。複数のプロセスが同じコードを実行できます。任意の時点で、特定の IP は、1 つのプロセスによってのみ「所有」されるか、2 つのプロセス間で転送されます。ポートは、以下で説明する Collat​​e コンポーネントの入力ポートなどに使用されるように、単純なものまたは配列型のいずれかです。ポートと非同期プロセスの組み合わせにより、並べ替え、マージ、要約などのデータ処理の長時間実行される基本機能をソフトウェアブラック ボックスの形式でサポートできます。

FBPプロセスは、処理するデータと出力を格納する場所がある限り実行を継続できるため、FBPアプリケーションは、通常、従来のプログラムよりも短い経過時間で実行され、特別なプログラミングを必要とせずに、マシン上のすべてのプロセッサを最適に使用します。^[1]

ネットワーク定義は通常は図式的であり、低レベルの言語または表記法で接続リストに変換されます。FBP は、このレベルではビジュアル プログラミング言語であることが多いです。より複雑なネットワーク定義は階層構造を持ち、「スティッキー」接続を持つサブネットから構築されます。他の多くのフローベースの言語/ランタイムは、より伝統的なプログラミング言語に基づいて構築されています。最も注目すべき^{[引用が必要]}例は、フロー グラフを指定するために C++ iostream のような演算子を使用するRaftLibです。

FBP は、 Gelernterと Carriero の用語で言う「調整言語」である点でLinda ^[2]言語と多くの共通点があります。 ^[3]本質的に言語に依存しません。実際、十分に低レベルの言語で記述されたスケジューラがあれば、異なる言語で記述されたコンポーネントを単一のネットワークにリンクできます。したがって、FBP はドメイン固有言語または「ミニ言語」の概念に適しています。

FBP は「データ結合」を示します。これは、結合に関する記事でコンポーネント間の最も緩い結合として説明されています。緩い結合の概念は、サービス指向アーキテクチャの概念と関連しており、FBP は、このアーキテクチャのほとんどの例よりも細かいレベルではありますが、そのようなアーキテクチャの多くの基準に適合しています。

FBP は、システムの動作に関する推論を簡素化する、高レベルかつ機能的なスタイルの仕様を推進します。その一例は、分散型マルチパーティ プロトコルのセマンティクスを建設的に指定および分析するための分散型データ フローモデルです。

フローベースプログラミングは、 1970年代初頭にJ.ポール・モリソンによって発明され、当初はカナダの銀行のソフトウェアに実装されました。^{[4] FBPは当初、当時のIBMのシミュレーション言語、特に}GPSSの影響を強く受けていましたが、そのルーツはコンウェイがコルーチンと呼んだ独創的な論文にまで遡ります。^[5]

FBP は、長年にわたって何度も名前が変更されてきました。最初の実装は AMPS (Advanced Modular Processing System) と呼ばれていました。カナダの 1 つの大規模なアプリケーションは 1975 年に稼働し、2013 年の時点で、ほぼ 40 年間、毎日稼働し、継続的に実稼働しています。IBM は、FBP の背後にあるアイデアが「自然法則に似すぎている」ため特許を取得できないと判断したため、代わりに1971 年に技術開示速報「データ レスポンシブ モジュラー インターリーブ タスク プログラミング システム」 [6 ^{]によって FBP の基本概念をパブリック ドメインにしました。 [4]}その概念と使用経験を説明した記事は、1978 年にIBM Research IBM Systems Journal に DSLM という名前で掲載されました。^[7] 2 番目の実装は、IBM Canada と IBM Japan の共同プロジェクトとして「Data Flow Development Manager」(DFDM) という名前で行われ、1980 年代後半に「Data Flow Programming Manager」という名前で日本で短期間販売されました。

一般的に、IBM 内ではこれらの概念は「データ フロー」と呼ばれていましたが、この用語は一般的すぎると感じられたため、最終的に「フロー ベース プログラミング」という名前が採用されました。

1980年代初頭から1993年にかけて、J.ポール・モリソンとIBMのアーキテクトであるウェイン・スティーブンスは、FBPの背後にある概念を洗練し、推進しました。スティーブンスは、FBPの概念を説明し、それを支持する記事をいくつか執筆し、彼の著書のいくつかにそれに関する資料を含めました。^{[8] [9] [非一次資料が必要] [10] [非一次資料が必要]}。1994年にモリソンはFBPを説明し、FBPが開発時間の短縮につながるという実証的な証拠を示した本を出版しました。^[11]

次の図は、FBP 図の主要なエンティティ (情報パケットを除く) を示しています。このような図は、接続のリストに直接変換でき、適切なエンジン (ソフトウェアまたはハードウェア) によって実行できます。

A、B、C は、コード コンポーネントを実行するプロセスです。O1、O2、および 2 つの IN は、接続 M と N をそれぞれのプロセスに接続するポートです。プロセス B と C が同じコードを実行することは許可されているため、各プロセスには独自の作業用ストレージ、制御ブロックなどのセットが必要です。コードを共有するかどうかに関係なく、B と C は同じポート名を自由に使用できます。ポート名は、それらを参照するコンポーネント内 (およびネットワーク レベル) でのみ意味を持つためです。

M と N は、しばしば「制限付きバッファ」と呼ばれるもので、任意の時点で保持できる IP の数に関して固定容量を持ちます。

ポートの概念により、同じコンポーネントをネットワーク内の複数の場所で使用できるようになります。ポートは、初期情報パケット (IIP) と呼ばれるパラメータ化機能と組み合わせることで、FBP にコンポーネントの再利用機能を提供し、FBP をコンポーネントベースのアーキテクチャにします。したがって、FBP は、 IBM ResearchのRaoul de Campo とNate Edwards が「構成可能なモジュール性」と呼んでいるものを示しています。

情報パケットまたは IP は、いわゆる「IP 空間」に割り当てられます (Linda のタプルが「タプル空間」に割り当てられるのと同様)。IP は破棄されて空間が再利用されるまで、明確に定義された有効期間を持ちます。FBP では、これは所有プロセス側による明示的なアクションでなければなりません。特定の接続を移動する IP (実際には「ハンドル」が移動する) は「ストリーム」を構成し、非同期的に生成および消費されます。この概念は、1976 年の Friedman と Wise の論文で説明されているlazy cons の概念と類似しています。 ^[12]

IP は通常、構造化されたデータの塊です。ただし、一部の IP には実際のデータが含まれず、単に信号として使用されることがあります。この例としては、「ブラケット IP」があります。これは、ストリーム内の連続パターン (「サブストリーム」と呼ばれる) にデータ IP をグループ化するために使用できます。サブストリームはネストされることがあります。また、IP を連結して「IP ツリー」を形成することもできます。IP ツリーは、単一のオブジェクトとしてネットワーク内を移動します。

上で説明した接続とプロセスのシステムは、任意のサイズに「分岐」できます。アプリケーションの開発中に、プロセスのペア間に監視プロセスを追加したり、プロセスをサブネットに「展開」したり、プロセスのシミュレーションを実際のプロセス ロジックに置き換えたりすることができます。したがって、FBP はラピッド プロトタイピングに適しています。

これはまさにデータ処理の組立ラインのイメージです。プロセスのネットワークを移動する IP は、組立ラインのステーションからステーションへと移動する部品と考えることができます。「マシン」は簡単に再接続したり、修理のためにオフラインにしたり、交換したりできます。奇妙なことに、このイメージは、コンピューターの時代以前にデータ処理に使用されていたユニット レコード機器のイメージと非常に似ています。ただし、カードのデッキを 1 台のマシンから別のマシンに手で運ぶ必要があった点が異なります。

FBP の実装は非プリエンプティブまたはプリエンプティブです。以前の実装は非プリエンプティブである傾向がありました (メインフレームと C 言語)。一方、最新の Java 実装 (以下を参照) は Java Thread クラスを使用し、プリエンプティブです。

FBP コンポーネントは、しばしば相補的なペアを形成します。この例では、そのようなペアを 2 つ使用します。ここで説明する問題は、言葉で説明すると非常に単純に見えますが、実際には従来の手続き型ロジックを使用して達成するのは驚くほど困難です。「電報問題」と呼ばれるこのタスクは、ピーター・ナウアによって最初に説明され、テキスト行を受け取り、各行の文字数が特定の長さを超えない、できるだけ多くの単語を含む出力行を生成するプログラムを作成することです。単語は分割されず、どの単語も出力行のサイズを超えないと想定されます。これは、テキスト エディターのワード ラッピング問題に似ています。^[13]

従来のロジックでは、プログラマーは、入力構造も出力構造も制御フローの呼び出し階層を駆動するために使用できないことをすぐに発見します。一方、FBP では、問題の説明自体が解決策を示唆します。

• 問題の説明では「単語」が明示的に言及されているため、設計者が単語を情報パケット（IP）として扱うのは合理的です。
• FBP には単一の呼び出し階層がないため、プログラマーはソリューションのサブパターンを強制的に最上位レベルにしようとはしません。

FBP で最も自然な解決策は次のとおりです (FBP には単一の「正しい」解決策はありませんが、これは自然に適合しているように見えます)。

DC と RC はそれぞれ「DeCompose」と「ReCompose」を表します。

前述のように、初期情報パケット (IIP) は、必要な出力レコード長 (右端の 2 つのコンポーネントで必要) やファイル名などのパラメータ情報を指定するために使用できます。IIP は、ネットワーク定義内のポートに関連付けられたデータ チャンクであり、関連するポートに対して「受信」が発行されると「通常の」IP になります。

このタイプのプログラムでは、「マスター ファイル」に対して「詳細」(変更、追加、削除) のファイルを渡し、(少なくとも) 更新されたマスター ファイルと 1 つ以上のレポートを作成します。更新プログラムは、通常、同期の手続き型コードを使用してコーディングするのが非常に困難です。これは、対応する詳細のないマスターが存在する場合やその逆の場合であっても、2 つ (場合によってはそれ以上) の入力ストリームを同期させておく必要があるためです。

FBP では、Collat​​or のユニット レコードの考え方に基づく再利用可能なコンポーネント (Collat​​e) によって、このタイプのアプリケーションの作成がはるかに簡単になります。Collat​​e は 2 つのストリームを結合し、グループ化レベルを示す括弧 IP を挿入して、ダウンストリーム ロジックを大幅に簡素化します。1 つのストリーム (この場合は「マスター」) がキー値 1、2、3 の IP で構成され、2 番目のストリーム IP (「詳細」) がキー値 11、12、21、31、32、33、41 を持ち、最初の数字がマスター キー値に対応するとします。括弧文字を使用して「括弧」IP を表すと、照合された出力ストリームは次のようになります。

( m1 d11 d12 ) ( m2 d21 ) ( m3 d31 d32 d33 ) (d41)

値が 4 のマスターがなかったため、最後のグループは単一の詳細 (および括弧) で構成されます。

上記のストリームの構造は、BNFのような表記法 を使用して簡潔に記述することができます。

{ ( [m] 日* ) }*

Collat​​e は再利用可能なブラック ボックスであり、受信 IP 内の制御フィールドの場所のみを知る必要があります (トランスフォーマー プロセスを上流に挿入して制御フィールドを標準の場所に配置できるため、これは厳密には必要ではありません)。また、実際には任意の数の入力ストリームと任意の深さの括弧のネストの汎用化が可能です。Collat​​e は入力に配列型ポートを使用し、可変数の入力ストリームを許可します。

フローベースのプログラミングは、非常に自然な方法でプロセスの多重化をサポートします。コンポーネントは読み取り専用であるため、特定のコンポーネントの任意の数のインスタンス (「プロセス」) が互いに非同期で実行できます。

コンピュータに通常 1 つのプロセッサが搭載されていた頃は、大量の I/O が発生する場合にこの機能が役立ちました。現在では、マシンには通常複数のプロセッサが搭載されているため、プロセスが CPU を集中的に使用する場合にもこの機能が役立ち始めています。このセクションの図は、1 つの「ロード バランサ」プロセスが、それぞれ S1、S2、S3 というラベルの付いた 3 つのプロセスにデータを分散している様子を示しています。これらのプロセスは、1 つのコンポーネントのインスタンスであり、先着順で 1 つのプロセスにデータが送られます。

この一般的な図では、ユーザーからのリクエスト (トランザクション) が図の左上から入力され、応答が左下から返されます。「バックエンド」(右側) は、CORBA、MQSeriesなどを使用して、他のサイトのシステムと通信します。クロス接続は、バックエンドに送信する必要のないリクエスト、またはユーザーに返される前にネットワークを複数回循環する必要があるリクエストを表します。

異なるリクエストでは異なるバックエンドが使用される可能性があり、バックエンド (使用されている場合) がリクエストを処理するのに異なる時間が必要になる可能性があるため、返されたデータを適切なリクエスト トランザクション (ハッシュ テーブルやキャッシュなど) に関連付けるための準備を行う必要があります。

上記の図は、最終的なアプリケーションにさらに多くのプロセスが含まれる可能性があるという意味で概略的です。プロセスは、キャッシュの管理、接続トラフィックの表示、スループットの監視などのために他のプロセスの間に挿入される場合があります。また、図のブロックは「サブネット」、つまり 1 つ以上のオープン接続を持つ小さなネットワークを表す場合もあります。

この方法論では、プログラムはサブルーチンの単一の手続き階層として構造化される必要があると想定しています。その出発点は、入力および出力データ構造に基づいて、アプリケーションを一連の「メイン ライン」として記述することです。次に、これらの「メイン ライン」の 1 つを選択してプログラム全体を駆動し、他のメイン ラインを「反転」してサブルーチンに変換する必要があります (これが「ジャクソン反転」と呼ばれる理由です)。これにより、いわゆる「衝突」が発生し、プログラムを複数のプログラムまたはコルーチンに分割する必要が生じることがあります。FBP を使用する場合、この反転プロセスは必要ありません。すべての FBP コンポーネントを個別の「メイン ライン」と見なすことができます。

FBP と JSP は、プログラム (または一部のコンポーネント)を入力ストリームの パーサーとして扱うという概念を共有しています。

ジャクソンの後の著作であるジャクソンシステム開発（JSD）では、このアイデアがさらに発展しました。^{[14] [15]}

JSD では、設計は最終的な実装段階までネットワーク設計として維持されます。その後、モデルは利用可能なプロセッサの数に応じて一連の連続プロセスに変換されます。ジャクソンは、このステップの前に存在するネットワーク モデルを直接実行する可能性について、著書のセクション 1.3 で説明しています (太字は筆者による)。

システムタイミングステップの最後に作成された仕様は、原則として直接実行可能です。必要な環境には、各プロセス用のプロセッサ、各データストリーム用の無制限バッファに相当するデバイス、およびシステムが現実世界に接続されるいくつかの入力および出力デバイスが含まれます。もちろん、このような環境は、十分に強力なマシンで実行される適切なソフトウェアによって提供できます。場合によっては、仕様を直接実行することが可能であり、合理的な選択である場合もあります。^[15]

FBPは、MAジャクソンによって「コルーチンのようなメカニズムで通信する順次プロセスへのプログラムの分解」という彼の方法に従うアプローチとして認識されました^[16]

WBアッカーマンは、応用言語を、値に適用される演算子によってすべての処理を実行する言語と定義しています。^[17]最も古い応用言語はLISPでした。

FBP コンポーネントは、入力ストリームを出力ストリームに変換する関数と見なすことができます。これらの関数は、次に示すように、より複雑な変換を行うために結合されます。

図のようにストリームに小文字のラベルを付けると、上の図は次のように簡潔に表すことができます。

c = G(F(a),F(b));

関数表記法では F は値のみを扱うため副作用がないため 2 回使用できますが、FBP では特定のコンポーネントの 2 つのインスタンスが同時に実行される可能性があるため、FBP コンポーネントにも副作用があってはなりません。関数表記法は明らかに FBP ネットワークの少なくとも一部を表すために使用できます。

すると、FBPコンポーネント自体を関数記法で表現できるかどうかという疑問が生じます。WH Burgeは、ストリーム式を再帰的かつ応用的なプログラミングスタイルで開発する方法を示しましたが、この研究は原子値（のストリーム）の観点からのものでした。^[18] FBPでは、構造化データチャンク（FBP IP）を記述して処理できることが必要です。

さらに、ほとんどのアプリケーション システムでは、すべてのデータが同時にメモリ内で利用可能であると想定していますが、FBP アプリケーションでは、有限のリソースを使用しながら、長時間実行されるデータ ストリームを処理できる必要があります。Friedman と Wise は、 Burge の研究に「lazy cons」の概念を追加することで、これを実現する方法を提案しました。これにより、「cons」の両方の引数が同時に利用可能であるという要件がなくなりました。「lazy cons」は、両方の引数が実現されるまで、実際にはストリームを構築しません。その前に、これを行うための「約束」を記録するだけです。これにより、ストリームをフロントから動的に実現できますが、バックエンドは実現されません。ストリームの最後は、プロセスの最後まで実現されませんが、先頭はアイテムの連続がどんどん長くなります。

FBP の概念の多くは、長年にわたってさまざまなシステムで独立して発見されたようです。前述の Linda もその 1 つです。2 つの手法の違いは、Linda の「ピラニアの学校」負荷分散手法によって示されます。FBP では、処理待ちの IP の数が最も少ないリスト内のコンポーネントにリクエストをルーティングする追加の「負荷分散」コンポーネントが必要です。明らかに、FBP と Linda は密接に関連しており、一方を使用して他方を簡単にシミュレートできます。

OOPのオブジェクトは、情報と動作の両方を含む半自律的なユニットとして説明できます。オブジェクトは「メソッド呼び出し」によって通信します。これは基本的にサブルーチン呼び出しであり、受信オブジェクトが属するクラスを介して間接的に行われます。オブジェクトの内部データにはメソッド呼び出しによってのみアクセスできるため、これは情報隠蔽または「カプセル化」の一形態です。ただし、カプセル化は OOP より古く、David Parnas が70 年代初頭にこれに関する重要な記事の 1 つを執筆しました^[19]。これはコンピューティングの基本概念です。カプセル化は FBP コンポーネントの本質であり、ブラック ボックスとして考えることができ、入力データを出力データに変換する処理を実行します。FBP では、コンポーネントの仕様の一部は、受け入れることができるデータ形式とストリーム構造、および生成するデータ形式とストリーム構造です。これは、契約による設計の一形態を構成します。さらに、IP 内のデータには、現在所有しているプロセスによってのみ直接アクセスできます。カプセル化は、外部のプロセスが内部のプロセスを保護できるようにすることで、ネットワーク レベルでも実装できます。

C. エリスと S. ギブスの論文では、アクティブ オブジェクトとパッシブ オブジェクトを区別しています。^[20]パッシブ オブジェクトは、前述のように情報と動作から構成されますが、この動作のタイミングを決定することはできません。一方、アクティブ オブジェクトはこれを実行できます。論文の中で、エリスとギブスは、アクティブ オブジェクトはパッシブ オブジェクトよりも保守可能なシステムの開発においてはるかに高い可能性を秘めていると述べています。FBP アプリケーションは、これら 2 種類のオブジェクトの組み合わせと見なすことができます。FBP プロセスはアクティブ オブジェクトに対応し、IP はパッシブ オブジェクトに対応します。

FBP は、Carl Hewittのアクターを、入力メッセージ用と制御信号用の 2 つのポートを持つ非同期プロセスと見なします。制御信号は、実行の各ラウンドの後にアクター自体によって発行されます。この信号の目的は、アクター本体の並列実行を回避し、同期なしでアクター オブジェクトのフィールドにアクセスできるようにすることです。

• アクティブオブジェクト
• 俳優モデル
• アパッチニフィ
• ビーエムディーエム
• 通信シーケンシャルプロセス (CSP)
• 同時実行コンピューティング
• データフロー
• データフロー図
• データフロープログラミング
• FBD - 機能ブロック図（IEC 61131 規格のプログラミング言語）
• 関数型リアクティブプログラミング
• リンダ（調整言語）
• ローコード開発プラットフォーム
• マップリデュース
• ノードレッド
• パイプラインプログラミング
• ウェイン・スティーブンス
• XProc
• ヤフーパイプ
• スモウコード

• Razdow, Allen (1997 年 12 月)。「エンタープライズ データ精製所の構築」。DMReview。2005年 3 月 15 日のオリジナルからアーカイブ。2006年 7 月 15 日に取得。
• Mayer, Anthony; McGough, Stephen; Gulamali, Murtaza; Young, Laurie; Stanton, Jim; Newhouse, Steven; Darlington, John (2002)。「グリッド指向コンポーネントの意味と動作」(PDF)。ロンドン e-Science センター、インペリアル カレッジ オブ サイエンス、テクノロジー、医学。2012 年 2 月 4 日のオリジナル(PDF)からアーカイブ。
• Black, Andrew P.; Huang, Jie; Koster, Rainer; Walpole, Jonathan; Pu, Calton (2002). 「Infopipes: マルチメディア ストリーミングの抽象化」(PDF) .マルチメディア システム. 8 (5). Springer-Verlag: 406–419. doi :10.1007/s005300200062. S2CID  5700383 . 2006-08-10に取得。
• Kra, David (2004 年 10 月)。「グリッド ドメインの zSeries および iSeries サーバー」。IBM DeveloperWorks。2006年 7 月 13 日閲覧。
• Ludäscher, Bertram、Altintas, Ilkay、Berkley, Chad、他 (2004 年 9 月)。「科学的ワークフロー管理と Kepler システム」(PDF)。サンディエゴ スーパーコンピュータ センター。2006年 7 月 14 日に取得。
• Bickle, Jerry、Richardson, Kevin、Smith, Jeff (2005)。「OMG ソフトウェア無線仕様の概要 (ロボット用)」(PDF) 。Object Management Group - ソフトウェアベースの通信。2006年 7 月 14 日にオリジナル(PDF)からアーカイブ。2006年 7 月 15 日に取得。
• Blažević, Mario (2006)。「Streaming Component Combinators」。Extreme Markup Languages の議事録。2007 年 9 月 18 日にオリジナルからアーカイブ。2006年 11 月 9 日に取得。
• Kauler, Barry (1999)。『組み込みシステム向けフロー設計、第 2 版』。R&D Books/Miller Freeman。ISBN 978-0-87930-555-0。
• 米国特許 5204965、Guthery, Scott B.、Barth, Paul S.、Barstow, David R.、「ストリーム ストアを使用したデータ処理システム」、1993 年 4 月 20 日発行、Schlumberger Technology Corporation に譲渡 
• Morrison, J. Paul (2013 年 3 月)。「フローベース プログラミング」。アプリケーション開発者ニュース(1)。2014 年 8 月 8 日時点のオリジナルよりアーカイブ。2014年 5 月 25 日閲覧。
• Staplin, George Peter (2006)。「Tcl フローベース プログラミング - TFP」。2010 年 10 月 7 日閲覧。
• Johnston, Wesley M.; Hanna , JR Paul; Millar, Richard J. (2004 年 3 月)。「データフロー プログラミング言語の進歩」。ACMコンピューティング調査。36 (1): 1–34。doi : 10.1145 /1013208.1013209。S2CID  5257722。
• Koster, Rainer; Black, Andrew P.; Huang, Jie; Walpole, Jonathan; Pu, Calton (2003 年 4 月)。「情報フロー ミドルウェアのスレッドの透明性」。ソフトウェア: 実践と経験。33 (4): 321–349。CiteSeerX 10.1.1.15.3933。doi : 10.1002 /spe.510。S2CID 37356020。2006年 12 月 5 日に取得。 
• Stevenson, Tony (1995 年 2 月)。「「フローベース プログラミング」のレビュー」。PC Update、オーストラリアのメルボルン PC ユーザー グループの雑誌。2006 年 9 月 25 日のオリジナルからアーカイブ。2006年 12 月 6 日に取得。
• Lea, Doug (2001 年 5 月)。「一方向メッセージの作成」。2006 年 9 月 7 日にオリジナルからアーカイブ。2006年 12 月 6 日に取得。
• Bowers, Shawn; Ludäscher, B.; Ngu, AHH ; Critchlow, T. 「データフローと制御フローの構造化構成による科学的ワークフローの再利用の実現」(PDF) 。SciFlow '06 。2007-02-05 にオリジナル(PDF)からアーカイブ。2006-12-06に取得。
• Sorber, Jacob; Kostadinov, Alexander; Garber, Matthew; Brennan, Matthew; Corner, Mark D.; Berger, Emery D. (2007)。「Eon」。Eon : 永続システム用の言語およびランタイム システム。組み込みネットワーク センサー システムに関する第 5 回国際会議の議事録 - セッション: 電力管理。p. 161。doi : 10.1145 / 1322263.1322279。ISBN 9781595937636. S2CID  12851752。
• Fiedler, Lars; Dasey, Timothy (2014)。「コンポーザブル分析のためのシステムと方法」。国立技術情報サービス。2014 年 8 月 26 日にオリジナルからアーカイブ。2014年 4 月 1 日に取得。
• Matt, Carkci (2014)。データフローとリアクティブプログラミングシステム：実践ガイド。CreateSpace Independent Publishing Platform。ISBN 978-1497422445。
• Lampa, Samuel; Dahlö, Martin; Alvarsson, Jonathan; Spjuth, Ola (2018). 「 SciPipe - 複雑で動的なバイオインフォマティクスパイプラインのアジャイル開発のためのワークフローライブラリ」。bioRxiv : 380808. doi : 10.1101/380808 。 2018年8月2日閲覧。