ここ数日、フローベースのプログラミングについて少し読んでいます。詳細を提供するwikiがあります。また、ウィキペディアにもその概要がよくまとめられています。私が最初に思ったのは、「レゴランドごっこプログラミングの偉大な支持者だ」というものでした。これは 80 年代後半にさかのぼるコンセプトです。しかし、読み進めるうちに、私は興味をそそられたことを認めなければなりません。
ある意味では、手続き型言語の出現以来、私たちの業界が追求してきた再利用の聖杯のように思えます。
1. 実際のプロジェクトで FBP を使用したことがありますか?
自動化プロジェクト (ディスパッチャー、コンポーネント iterface、一連のコンポーネント、DF 言語、DF コンパイラー、UI) 用に DF サーバーを設計および実装しました。ベア C++ で書かれており、いくつかの Unix ライクなシステム (Linux x86、MIPS、avr32 など、Mac OSX) で動作します。洗練されたフロー制御や複雑なスレッド制御などのいくつかの機能が欠けているため (それほど高度ではないコンポーネントしかありません)、機能するとしても単なるプロトタイプにすぎません。現在、フル機能のサーバーに取り組んでいます。プロトタイプの実装と使用中に多くのことを学びました。
また、いつかビジュアルエディタを作ります。
2. FBP についてどう思いますか?
2.1. まず第一に、データフロープログラミングは 究極の楽しみです
私がデータフロープログラミングに出会ったのは、プログラミングに初めて出会った20年前のような感覚でした。ただし、DF プログラミングは手続き型/OOP プログラミングとは異なりますが、プログラミングの一種に過ぎません。とてもシンプルなものでも、発見することがたくさんあります！経験豊富なプログラマーとして、非常に基本的な問題である DF 問題に遭遇したとき、それは非常に面白いことですが、それは以前はまったく知られていませんでした。そのため、DF プログラミングに飛び込むと、「サイクル」または「条件」に最初に出会った新人プログラマーのように感じることができます。
2.2. 特定のアーキテクチャにのみ使用できます
釘を打つためのハンマーです。DF は、UI、Web サーバーなどには適していません。
2.3. データフロー アーキテクチャは、一部の問題に最適です
データフロー フレームワークは魔法のようなものを作ることができます。本来は並列化用に設計されていないプロシージャーを並列化できます。コンポーネントはシングルスレッドですが、DF グラフに編成するとマルチスレッドになります。
例: makeが DF システムであることをご存知ですか? make -jを試してください(man の -j の用途を参照してください)。マルチコア マシンを使用している場合は、プロジェクトを -j を使用した場合と使用しない場合でコンパイルし、時間を比較します。
2.4. 問題の最適な分割
プログラムを作成している場合、問題を小さなサブ問題に分割することがよくあります。よく知られているサブ問題には通常分割ポイントがありますが、実装する必要はありません。DB 用の SQL やグラフィックス/アニメーション用の OpenGL などの既存のソリューションを使用するだけです。
DF アーキテクチャは、非常に興味深い方法で問題を分割します。
コンポーネント セットが適切に設計されていれば、コンフィギュレーターは、プログラマーが夢にも思わなかったようなシステムを構築できます。Configurator は、プログラマーの邪魔をすることなく、新しい機能を実装できます。パーソナライズされたソリューションがあるため、顧客は満足しています。ソフトウェアの製造元も満足しています。ソフトウェアの顧客固有のブランチをいくつか維持する必要がなく、顧客固有の構成だけを維持する必要があるからです。
2.5。スピード
システムがネイティブ コンポーネントで構築されている場合、DF プログラムは高速です。唯一の時間の損失は、単純な OOP プログラムと比較して、コンポーネント間のメッセージ ディスパッチです。これも最小限です。
3. FBP に未来はありますか?
はい、そうです。
主な理由は、まったく新しい奇妙なソフトウェア アーキテクチャや奇妙な言語を導入することなく、大規模なマルチプロセッシングの問題を解決できることです。データフロー プログラミングは簡単です。つまり、コンポーネント プログラミングとデータフロー構成の構築の両方を意味します。(データフロー フレームワークの記述でさえ、難しい科学ではありません。)
また、非常に経済的です。適切なコンポーネントのセットがあれば、レゴ ブロックを組み立てるだけで済みます。DF プログラムは保守が容易です。DF 構成の構築には、経験豊富なプログラマーは必要なく、システム インテグレーターだけが必要です。
ネイティブシステムが普及し、カスタムコンポーネント作成の扉が開かれると嬉しいです。また、標準の DF 言語が必要です。つまり、プラットフォームに依存しないビジュアル エディターや複数の DF サーバーで使用できます。
興味深い議論！昨日、混乱の一部は、多くの異なる表記法が有向アークを使用しているが、それらを異なる意味で使用しているという事実による可能性があることに気づきました。FBP では、線はデータ パケットのストリームが通過する境界のあるバッファーを表します。コンポーネントは通常、長時間実行されるプロセスであるため、ストリームは膨大な数のパケットで構成される可能性があり、FBP アプリケーションは非常に長い期間 (おそらく「永久に」) 実行できます (主に UMass Amherst の人々による、Eon と呼ばれるプロジェクトに関する 2007 年の論文を参照してください)。 ）。バウンド バッファへの送信は、バッファが (一時的に) 一杯になる (または一時的に空になる) と中断されるため、限られたリソースを使用して無限の量のデータを処理できます。
比較すると、Grafcet の E は「ステップ」を意味する Etapes に由来し、かなり異なる概念です。この種のモデル (およびこれらのモデルは多数あります) では、ステップ間を流れるデータは、一度に高速メモリに保持できるものに制限されるか、ディスクに保持する必要があります。FBP はネットワーク内のループもサポートしますが、これはステップベースのシステムでは困難です。たとえば、http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplicationを参照してください。- このアプリケーションは MQSeries と CORBA の両方を自然な方法で使用していることに注意してください。さらに、FBP はネイティブに並列であるため、グリッド ネットワーク、マルチコア マシン、および最新のコンピューティングのさまざまな方向のプログラミングに適しています。最後に 1 つコメントします。関連する多くのプロジェクトを文献で見つけましたが、FBP のすべての特徴を備えているプロジェクトはほとんどありません。私が何年にもわたって集めてきたリスト (その多くは Grafcet よりも近いものです) はhttp://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjectsにあります。
FBP が FSM を実装するための単なる手段であるというコメントには同意できません。FSM は優れていると思います。アプリケーションの構築において明確な役割があると思いますが、FBP の中心的な概念は、複数のコンポーネント プロセスが非同期で実行されることです。現在バウンド バッファと呼ばれるものを横切って実行されるデータ チャンクのストリームによって通信します。はい、間違いなくFSMはコンポーネントプロセスを構築する1つの方法であり、実際、FBPに関する私の本にはこのアイデアに専念する章全体があり、PDAの関連する章( 1 ) - http://www.jpaulmorrison.com/ fbp/compil.htm - しかし、私の意見では、自明ではない FBP ネットワークを実装する FSM は非常に複雑です。例として、 に示す図
は、メインフレームで実行される単一のバッチ ジョブ。これらのブロックはすべて、他のすべてのブロックと非同期で実行されています。ところで、最初の投稿の質問に対する回答をもっと聞きたいです!
1 : http://en.wikipedia.org/wiki/Pushdown_automatonプッシュダウン オートマトン
フローベースのプログラミングという用語を聞くたびに、概念的に LabView を思い浮かべます。つまり、スケジューリングを行うコンポーネント プロセスは、主にその入力データの変更によって駆動されます。これは、labview プラットフォームが最新のマインドストーム製品に使用されたという意味で、まさにレゴ プログラミングです。ただし、これによりプログラミング モデルの有用性が低下するという点には同意しません。
通常、データの収集、制御、および自動化を伴う産業用システムには、非常に適しています。データ入力からデータ出力に変換されていない場合、制御システムとは何ですか? つまり、制御スキーム内のどのコンポーネントをより大きな画像でブラック ボックスとして表現したくないか (可能であれば) です。他の方法論を使用してそのレベルのアーキテクチャーの明快さを実現するには、データ ドメイン クラス図を作成し、次に問題ドメインのランタイム クラス関係を作成し、その上にユース ケース図を作成し、それらの間を行ったり来たりする必要があります。フロー ドリブン システムを使用すると、この情報の多くを十分に正確にまとめることができるので、コンポーネントを構築して定義すると、システムを視覚的に現実的に設計できます。
labview で書かれたアプリケーションを見て、「どのコードがこの値を設定したのか?」という質問をする必要はありませんでした。これは、固有のものであり、データからさかのぼって追跡するのが簡単であり、複数の意図しないライターのような間違いも不可能だったからです。間違えて作成。
より典型的な手続き型の方法で書かれたコードにそれが当てはまるとしたら!
自動車開発では、MOST仕様（Media Oriented Systems Transport）の一部である言語に依存しないメッセージングプロトコルがあります。これは、ネットワーク経由または同じデバイス内のコンポーネント間で通信するように設計されています。システムには通常、実際のメッセージバスと視覚化されたメッセージバスの両方があります。したがって、フローベースプログラミングの形式を効果的に使用できます。
それが数年前に私のために電球を動かし、私をここに連れて来た理由でした。これは本当に素晴らしい作業方法であり、従来のプログラミングよりもはるかに楽しいものです。メッセージカタログは、中心的な仕様と参照ポイントを形成します。これは、開発者と管理者の両方にとってうまく機能します。つまり、管理者はソースを確認する代わりにメッセージカタログを参照できます。
統合されたロギングを使用すると、カタログを参照してわかりやすい分析を生成することで、物事を非常に生産的にすることができます。私はこのように商用製品を開発した実際の経験があります。特にツールとIDEに関して、物事をさらに進めることに興味があります。残念ながら、自動車セクター内の多くの人々は、これがどれほど素晴らしいかについてのポイントを見逃し、それに基づいて構築することができなかったと思います。彼らは現在、他の流行に気を取られており、ほとんどの開発には物理的なバスよりもはるかに多くのものがあることに気づいていませんでした。
1) 異常検出プロジェクト用に小さな FBP フレームワークを構築しましたが、それは素晴らしいアイデアであることがわかりました。
フレームワークが素晴らしいチームによってまとめられたときにフローベースのフレームワークがどのように感じられるかについての良いアイデアを提供するKNIME ビデオのいくつかを見ることもできます。確かに、これはバッチ ベースであり、連続操作用に作成されたものではありません。
ただし、フローベースのプログラミングの最も良い例は、最も古く、最も見過ごされている FBP フレームワークの 1 つであるUNIX パイプです。nixパイプの力について詳しく説明する必要はないと思います...
2) FBP は、さまざまな問題に対して非常に強力なツールです。本質的な並列処理は大きな利点であり、アダプター モジュールを使用することで、FBP フレームワークを完全にネットワーク透過にすることができます。また、スマート フレームワークは驚くほどフォールト トレラントであり、必要に応じてクラッシュしたモジュールを動的にリロードできます。概念が単純であるため、プロジェクトに関係するすべての人とのコミュニケーションがより明確になり、コードもより明確になります。
3) 絶対に！パイプは定着しており、UNIX の最も強力な機能の 1 つです。静的プログラムと比較して FBP フレームワークに固有の能力は非常に高く、特別な手段なしで実行中に一部のフレームワークを再構成できる点まで、変更を些細なものにします。
FBP FTW! ;-)
私は、 Spring Web Flowを Java Web アプリケーションで広範囲に使用して (通常は) アプリケーション プロセスをモデル化しました。アプリケーション プロセスは、どのページを表示するかに関する多くの条件付きロジックを伴う複雑なウィザードのような問題になる傾向があります。その信じられないほど強力です。新しい製品が追加され、既存の部分を 1 時間か 2 時間で完全に新しいアプリケーション プロセスに再構成することができました (いくつかの新しいビュー/状態を追加しました)。
また、 OS ワークフローを使用してビジネス プロセスをモデル化することも検討しましたが、そのプロジェクトはさまざまな理由で中止されました。
Microsoft の世界ではWindows Workflow Foundation ("WWF") があり、特にSharepointと組み合わせて人気が高まっています。
FBP は、有限状態マシンを実装する手段にすぎません。それは何も新しいことではありません。
まったく同じものではないことは承知していますが、このモデルは PLC プログラミングで長年使用されてきました。ISO では Sequential Flow Chart と呼んでいますが、多くの人は一般的な実装にちなんで Grafcet と呼んでいます。並列処理を提供し、状態間の遷移を定義します。
これがMQシリーズ、MSMQ、JMSの目的です。
これは、Webサービスとエンタープライズサービスバスの実装の基礎です。
TIBCOやSunのJCAPSなどの製品は、基本的にこの特定の流行語を使用せずにフローベースです。
アプリケーションの作業のほとんどは、処理ネットワークを介してメッセージを渡す小さなモジュールを使用して行われます。