フローベースプログラミング
私はここ数日、 フローベースプログラミング について少し読んでいます。詳細を提供する wiki があります。そしてウィキペディアには 概要 もあります。私が最初に考えたのは、「レゴランドのふりプログラミングのもう1つの支持者」でした。これは、80年代後半を思い起こさせる概念です。しかし、私がもっと読むにつれて、私は興味をそそられたことを認めなければなりません。
- 実際のプロジェクトでFBPを使用しましたか？
- FBPについてどう思いますか？
- FBPには未来がありますか？
ある意味では、手続き型言語の登場以来、私たちの業界が追求してきた再利用の聖杯のように思えます。
興味深い議論！昨日、混乱の一部は、多くの異なる表記法が有向アークを使用しているという事実が原因である可能性があることに気付きましたが、それらを異なる意味で使用しています。 FBPでは、線は境界バッファを表し、データパケットのストリームを通過します。コンポーネントは通常、長時間実行されるプロセスであるため、ストリームには膨大な数のパケットが含まれる可能性があり、FBPアプリケーションは非常に長期間、おそらく「永続的に」実行される可能性があります（Eonと呼ばれるプロジェクトに関する2007年の論文を参照してください。 ）。制限付きバッファーへの送信は、バッファーが（一時的に）いっぱいになると（または一時的に空になると）中断されるため、有限のリソースを使用して無制限の量のデータを処理できます。
比較すると、GrafcetのEは、「ステップ」を意味するEtapesに由来します。これは、かなり異なる概念です。この種のモデル（およびこれらのモデルは多数あります）では、ステップ間を流れるデータは、一度に高速メモリに保持できるものに制限されるか、ディスクに保持する必要があります。 FBPは、ネットワーク内のループもサポートします。これは、ステップベースのシステムでは実行が困難です。たとえば、 http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication -noticeを参照してください。このアプリケーションがMQSeriesとCORBAの両方を自然な方法で使用したこと。さらに、FBPはネイティブに並列であるため、グリッドネットワーク、マルチコアマシン、および最新のコンピューティングのさまざまな方向性のプログラミングに役立ちます。最後のコメント：文献で私は多くの関連プロジェクトを見つけましたが、それらのいくつかはFBPのすべての特徴を持っています。私が何年にもわたって集めてきたリスト（Grafcetよりも近いものの数）は http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects にあります。
1。実際のプロジェクトにFBPを使用しましたか？
自動化プロジェクト用にDFサーバーを設計および実装しました（ディスパッチャー、コンポーネントiterface、一連のコンポーネント、DF言語、DFコンパイラ、UI）。ベア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。問題の最適な分割
プログラムを作成している場合は、問題を小さなサブ問題に分割することがよくあります。よく知られているサブ問題には通常、実装する必要のない分割点があります。SQLforDBやOpenGLforグラフィックス/アニメーションなどの既存のソリューションを使用するだけです。
DFアーキテクチャは、問題を非常に興味深い方法で分割します。
- アーキテクチャを提供するデータフローフレームワーク（既存のものを使用するだけ）、
- コンポーネント：プログラマーがコンポーネントを作成します。コンポーネントはシンプルで十分に分離されたユニットです。コンポーネントの作成は簡単です。
- 構成：別名データフロープログラミング：構成者は、プログラマーが提供するコンポーネントを使用して、データフローグラフ（プログラム）をまとめます。
コンポーネントセットが適切に設計されている場合、コンフィギュレーターは、プログラマーが夢にも思わなかったようなシステムを構築できます。 Configuratorは、プログラマーの邪魔をすることなく、新しい機能を実装できます。パーソナライズされたソリューションを提供しているため、顧客は満足しています。ソフトウェアメーカーも満足しています。なぜなら、ソフトウェアの顧客固有のブランチをいくつか維持する必要はなく、顧客固有の構成だけを維持する必要があるからです。
2.5。速度
システムがネイティブコンポーネント上に構築されている場合、DFプログラムは高速です。唯一の時間損失は、単純なOOPプログラムと比較して、コンポーネント間でメッセージをディスパッチすることです。それも最小限です。
3。 FBPには未来がありますか？
はい、確かに。
主な理由は、まったく新しい奇妙なソフトウェアアーキテクチャ、奇妙な言語を導入することなく、大規模なマルチプロセッシングの問題を解決できることです。データフロープログラミングは簡単です。つまり、コンポーネントプログラミングとデータフロー構成の構築の両方を意味します。 （データフローフレームワークの記述でさえ、ロケット科学ではありません。）
また、それは非常に経済的です。優れたコンポーネントのセットがある場合は、レゴブロックを組み合わせるだけで済みます。 DFプログラムは保守が簡単です。DF構成の構築には、経験豊富なプログラマーは必要ありません。システムインテグレーターだけが必要です。
ネイティブシステムが普及し、カスタムコンポーネントを作成するための扉が開かれていれば幸いです。また、標準のDF言語が必要です。これは、プラットフォームに依存しないビジュアルエディターといくつかのDFサーバーで使用できることを意味します。
FBPがFSMを実装するための単なる手段であるというコメントに反対する必要があります。FSMは適切であり、アプリケーションの構築において明確な役割を果たしていると思いますが、FBPのコアコンセプトは複数のコンポーネントプロセスを実行することです非同期、現在は制限付きバッファーと呼ばれているものにまたがるデータチャンクのストリームを使用して通信します。はい、確かにFSMはコンポーネントプロセスを構築する1つの方法であり、実際、このアイデアに専念するFBPに関する私の本には、PDAの関連する章があります（ 1 ）--- http://www.jpaulmorrison.com/fbp/compil.htm -しかし、私の意見では、重要なFBPネットワークを実装するFSMは非常に複雑です。例として、 
メインフレームで実行されているsingleバッチジョブの約1/3です。これらのブロックはすべて、他のすべてのブロックと非同期で実行されています。ちなみに、最初の投稿の質問に対する回答をもっと聞いてみたいと思います！
1 ： http://en.wikipedia.org/wiki/Pushdown_automaton プッシュダウンオートマトン
フローベースプログラミングという用語を聞くときはいつでも、概念的にはLabViewについて考えます。つまり、スケジューリングを行うコンポーネントプロセスは、主に入力データの変更によって駆動されます。これは、labviewプラットフォームが最新のマインドストーム製品に使用されたという意味で、実際にはISレゴプログラミングです。しかし、これがあまり有用でないプログラミングモデルになることに同意しません。
通常、データの収集、制御、および自動化を伴う産業用システムの場合、これは非常に適しています。データ入力がデータ出力に変換されない場合、どのような制御システムがありますか？つまり、制御スキームのどのコンポーネントを、可能であれば、全体像のブラックボックスとして表現したくないと思いますか。他の方法論を使用してそのレベルのアーキテクチャの明確さを達成するには、データドメインクラス図を描画し、次に問題のドメインランタイムクラス関係を描画し、その上にユースケース図を描画し、それらの間を行ったり来たりする必要があります。フロー駆動型システムを使用すると、コンポーネントが構築および定義された後、システムを視覚的に現実的に設計できるように、この情報の多くを正確にまとめることができるという贅沢があります。
Labviewで書かれたアプリケーションを見たときに私が尋ねる必要がなかった質問の1つは、「どのコードがこの値を設定したのか」です。これは、データから逆方向にたどることが本質的で簡単であり、複数の意図しないライターのような間違いも不可能だったためです。誤って作成します。
より一般的な手順で記述されたコードにそれが当てはまる場合に限ります。
1）異常検出プロジェクト用の小さなFBPフレームワークを構築しましたが、それは素晴らしいアイデアであることがわかりました。
KNIMEビデオ のいくつかを見ることができます。これは、フレームワークが優れたチームによってまとめられたときに、フローベースのフレームワークがどのように感じられるかについての良いアイデアを提供します。確かに、それはバッチベースであり、継続的な操作のために作成されていません。
ただし、フローベースプログラミングの最も良い例は、UNIXパイプです。これは、最も古く、最も見過ごされているFBPフレームワークの1つです。ニックスパイプの力について詳しく説明する必要はないと思います...
2）FBPは、多数の問題に対して非常に強力なツールです。固有の並列処理は大きな利点であり、アダプタモジュールを使用することで、どのFBPフレームワークも完全にネットワーク透過にすることができます。スマートフレームワークはまた、ばかげたフォールトトレラントであり、必要に応じてクラッシュしたモジュールを動的にリロードすることができます。概念が単純なため、プロジェクトに関係するすべての人とのコミュニケーションがよりクリーンになり、コードがよりクリーンになります。
3）絶対に！パイプはここにとどまり、unixの最も強力な機能の1つです。静的プログラムと比較してFBPフレームワークに固有の能力は多く、変更は簡単で、一部のフレームワークを特別な手段なしで再構成できるようになります実行中。
FBP FTW！ ;-）
自動車開発では、MOST仕様（Media Oriented Systems Transport）の一部である言語に依存しないメッセージングプロトコルがあります。これは、ネットワークを介して、または同じデバイス内でコンポーネント間で通信するように設計されています。システムには通常、実際のメッセージバスと視覚化されたメッセージバスの両方があります。したがって、フローベースプログラミングの形式を効果的に使用できます。
それが数年前に電球を点灯させ、私をここに連れてきた理由です。これは本当に素晴らしい作業方法であり、従来のプログラミングよりもはるかに楽しいものです。メッセージカタログは、中心的な仕様と参照ポイントを形成します。開発者と管理者の両方に適しています。つまり、管理者はソースを見る代わりにメッセージカタログを閲覧できます。
統合されたロギングを使用すると、カタログを参照してわかりやすい分析を生成することで、物事を本当に生産的にすることができます。私はこのように商用製品を開発した経験があります。特にツールとIDEに関して、物事をさらに進めることに興味があります。残念ながら、自動車セクター内の多くの人々は、これがどれほど素晴らしいかについてのポイントを見逃し、それに基づいて構築することができなかったと思います。彼らは現在、他の流行に気を取られており、物理バスよりもほとんどの開発がはるかに多いことに気づいていませんでした。
私は Spring Web Flow を広範囲に使用しましたJava Webアプリケーションは（通常）アプリケーションプロセスをモデル化します。これは、多くの条件付きロジックを備えた複雑なウィザードのような問題になる傾向があります。どのページを表示するかについて。その信じられないほど強力です。新製品が追加され、既存の部分を1、2時間で完全に新しいアプリケーションプロセスに再カットすることができました（いくつかの新しいビュー/状態を追加しました）。
OSワークフロー を使用してビジネスプロセスをモデル化することも検討しましたが、そのプロジェクトはさまざまな理由で缶詰になりました。
Microsoftの世界では、 Windows Workflow Foundation （ "WWF"）があります。これは、特に Sharepoint と組み合わせて人気が高まっています。
FBPは、 有限状態マシン を実装するための単なる手段です。それは新しいことではありません。
まったく同じではないことは承知していますが、このモデルはPLCプログラミングで長年使用されてきました。 ISOはそれをシーケンシャルフローチャートと呼んでいますが、多くの人々はそれを人気のある実装の後にGrafcetと呼んでいます。並列処理を提供し、状態間の遷移を定義します。
最近のビジネスインテリジェンスの世界では、データをマッシュアップして処理するために使用されています。 ETL、クエリ、結合、レポートの作成などのデータ処理ステップは、エンドユーザーが実行できます。私はオープンシステムの開発者です- ComposableAnalytics.com CAでは、フローベースのアプリをブラウザ経由で共有して実行できます。