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

https://stackoverflow.com/questions/405627

03-07-2019
|

質問

私は少し読んでいますフローベースのプログラミングここ数日間。がありますウィキさらに詳しく説明します。そしてウィキペディアには、良い概要それも。私の最初の考えは、「レゴランドごっこプログラミングの素晴らしいもう一人の提唱者」でした。これは 80 年代後半を思い起こさせるコンセプトです。しかし、読んでいくうちに、興味をそそられたことを認めざるを得ません。

実際のプロジェクトでFBPを使用したことがありますか?
FBPについてどう思いますか？
FBPに未来はあるのか？

ある意味、これは手続き型言語の出現以来、私たちの業界が追求してきた再利用の聖杯のように思えます。

解決

興味深いディスカッション！昨日、混乱の一部は、多くの異なる表記が有向アークを使用しているが、異なる意味を意味するために使用しているという事実に起因する可能性があることを思いつきました。 FBPでは、線は、データパケットのストリームを通過する境界付きバッファを表します。通常、コンポーネントは長時間実行されるプロセスであるため、ストリームは膨大な数のパケットで構成されている可能性があり、FBPアプリケーションは非常に長期間（おそらく「永久に」）実行される可能性があります。（Eonと呼ばれるプロジェクトに関する2007年の論文を参照してください。ほとんどはUMass Amherstの人々によるものです）。バッファーが（一時的に）いっぱいになった（または一時的に空になった）場合、境界付きバッファーへの送信が中断されるため、有限のリソースを使用して無制限の量のデータを処理できます。

比較すると、GrafcetのEはEtapesに由来し、「ステップ」を意味しますが、これはかなり異なる概念です。この種のモデル（およびこれらのモデルは多数あります）では、ステップ間を流れるデータは、高速メモリに一度に保持できるものに制限されるか、ディスクに保持する必要があります。 FBPはネットワーク内のループもサポートしますが、これはステップベースのシステムでは実行が困難です-たとえば http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication -このアプリケーションは自然にMQSeriesとCORBAの両方を使用していることに注意してください。さらに、FBPはネイティブに並列であるため、グリッドネットワーク、マルチコアマシン、および最新のコンピューティングの多くの方向性のプログラミングに役立ちます。最後のコメント：文献では多くの関連プロジェクトを見つけましたが、FBPのすべての特性を備えたプロジェクトはほとんどありません。私が長年にわたって蓄積してきたリスト（それらの多くはGrafcetよりも近い）は http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects 。

他のヒント

1。実際のプロジェクトにFBPを使用しましたか？

オートメーションプロジェクト（ディスパッチャー、コンポーネントインターフェース、多数のコンポーネント、DF言語、DFコンパイラ、UI）のDFサーバーを設計および実装しました。それは裸のC ++で書かれており、いくつかのUnixライクなシステム（Linux x86、MIPS、avr32など、Mac OSX）で動作します。いくつかの機能が欠けています。洗練されたフロー制御、複雑なスレッド制御（高度なコンポーネントではないため）は、単なるプロトタイプであり、機能します。現在、フル機能のサーバーに取り組んでいます。プロトタイプの実装および使用中に多くのことを学びました。

また、いつかビジュアルエディタを作成します。

2。 FBPについてどう思いますか？

2.1。まず、データフロープログラミングは 究極の楽しみ

です

データフロープログラミングに出会ったとき、最初にプログラミングに出会った20年前のように感じました。 DFプログラミングは手続き型/ OOPプログラミングとは異なりますが、一種のプログラミングです。発見すべきことがたくさんあります。すっごく単純なものも！経験豊富なプログラマーとして、非常に基本的なことであるDFの問題に遭遇したとき、それは非常に面白いです。したがって、DFプログラミングに飛び込むと、「サイクル」に最初に出会った新人プログラマーのように感じるでしょう。または＆quot; condition＆quot;。

2.2。特定のアーキテクチャでのみ使用できます

これはただのハンマーで、釘を打つためのものです。 DFはUI、Webサーバーなどには適していません。

2.3。データフローアーキテクチャはいくつかの問題に最適です

データフローフレームワークは、魔法のようなものを作成できます。もともと並列化用に設計されていないプロシージャを並列化できます。コンポーネントはシングルスレッドですが、DFグラフに編成されると、マルチスレッドになります。

例： make はDFシステムであることをご存知ですか？ make -j を試してください（man、-jの用途を参照）。マルチコアマシンを使用している場合は、-jを使用して、または使用せずにプロジェクトをコンパイルし、時間を比較します。

2.4。問題の最適な分割

プログラムを作成している場合、多くの場合、小さな副問題のために問題を分割します。よく知られているサブ問題には通常の分割点があります。実装する必要はありません。SQLfor DBやOpenGL for graphics / animationなどの既存のソリューションを使用するだけです。

DFアーキテクチャは、問題を非常に興味深い方法で分割します。

アーキテクチャを提供するデータフローフレームワーク（既存のものを使用する）、
コンポーネント：プログラマーはコンポーネントを作成します。コンポーネントはシンプルで十分に分離されたユニットです-コンポーネントを作成するのは簡単です。
構成：a.k.a.データフロープログラミング：コンフィギュレーターは、プログラマーが提供するコンポーネントを使用して、データフローグラフ（プログラム）をまとめます。

コンポーネントセットが適切に設計されている場合、コンフィギュレータはそのようなシステムを構築できますが、プログラマは夢にも思いませんでした。 Configuratorは、プログラマに影響を与えることなく、新しい機能を実装できます。顧客は、パーソナライズされたソリューションを持っているため、満足しています。また、ソフトウェアの製造者は、ソフトウェアの顧客固有のブランチを維持する必要がなく、顧客固有の構成だけを維持する必要があるため、満足しています。

2.5。速度

システムがネイティブコンポーネント上に構築されている場合、DFプログラムは高速です。唯一の時間損失は、単純なOOPプログラムと比較して、コンポーネント間でメッセージがディスパッチされることです。これも最小限です。

3。 FBPには未来がありますか？

はい、確かです。

主な理由は、まったく新しい奇妙なソフトウェアアーキテクチャ、奇妙な言語を導入することなく、大規模なマルチプロセッシングの問題を解決できるからです。データフロープログラミングは簡単です。つまり、b

私はFBPがFSMを実装するための単なる手段であるというコメントに異議を唱えなければなりません。FSMはきちんとしていると思います。 非同期に実行し、現在バウンドバッファと呼ばれているものを横切るデータチャンクのストリームによって通信します。はい、間違いなくFSMはコンポーネントプロセスを構築する1つの方法であり、実際、このアイデアに焦点を当てたFBPに関する私の本には章全体があり、PDAの関連する章（ 1 ）- http://www.jpaulmorrison.com/fbp/compil.htm -しかし、私の意見では、自明ではないFBPネットワークを実装するFSMは非常に複雑です。例として、図に示す図メインフレームで実行される単一バッチジョブの約1/3です。これらのブロックはすべて、他のすべてのブロックと非同期で実行されています。ところで、最初の投稿の質問に対する回答をもっと聞きたいと思います！

1 ： http://en.wikipedia.org/wiki/Pushdown_automaton プッシュダウンオートマトン

フローベースのプログラミングという言葉を聞くたびに、概念的にLabViewを思い浮かべます。すなわち、スケジューリングの対象となるコンポーネントプロセスは、主に入力データの変更によって駆動されます。これは、labviewプラットフォームが最新のマインドストーム製品に使用されたという意味で、レゴプログラミングです。ただし、これによりプログラミングモデルの有用性が低下することに同意しません。

通常、データの収集、制御、および自動化を伴う産業用システムには、非常に適しています。データがデータアウトに変換されない場合の制御システムは何ですか？つまり、制御スキームのどのコンポーネントを、可能であれば、大きな絵の中でブラックボックスとして表すことを好まないでしょうか。他の方法論を使用してそのレベルのアーキテクチャを明確にするには、データドメインクラス図を作成し、次に問題ドメインランタイムクラス関係を作成し、さらにその上にユースケース図を作成し、それらの間で前後に切り替える必要があります。フロー駆動システムでは、コンポーネントを構築して定義した後、視覚的に現実的にシステムを設計できるように、この情報の多くを十分に正確に折りたたむことができます。

labviewで記述されたアプリケーションを見るときに私が尋ねる必要のなかった1つの質問は、「どのコードがこの値を設定しましたか？」です。意図しない作家は、誤って作成することは不可能でした。

より一般的な手続き型の方法で記述されたコードに当てはまる場合のみ！

1) 異常検出プロジェクト用に小さな FBP フレームワークを構築しましたが、それが素晴らしいアイデアであることがわかりました。

一部をご覧いただくこともできますナイフビデオ, 、フローベースのフレームワークが優れたチームによって組み立てられたときにどのような感じになるかをよく理解できます。確かに、これはバッチベースであり、継続的な操作を目的として作成されたものではありません。

ただし、フローベースのプログラミングの最も良い例は次のとおりです。 UNIXパイプ これは、最も古いものの、最も見落とされている FBP フレームワークの 1 つです。nix パイプの威力について詳しく説明する必要はないと思います...

2) FBP は、大規模な問題に対して非常に強力なツールです。固有の並列処理は大きな利点であり、アダプターモジュールを使用することで、FBP フレームワークを完全にネットワーク透過にすることができます。スマートフレームワークは異常な耐障害性も備えており、クラッシュしたモジュールを必要に応じて動的に再ロードできます。また、概念的なシンプルさにより、プロジェクトに関わる全員とのコミュニケーションがよりわかりやすくなり、コードがよりクリーンになります。

3) 絶対に！パイプは今後も存続し、UNIX の最も強力な機能の 1 つです。静的プログラムと比較して、FBP フレームワークに固有の機能は非常に多く、一部のフレームワークを再構成できるほど変更が簡単になります。 走っている間 特別な対策もせずに。

FBP FTW!;-)

自動車開発では、MOST仕様（Media Oriented Systems Transport）の一部である言語に依存しないメッセージングプロトコルがあります。これは、ネットワークまたは同じデバイス内のコンポーネント間で通信するように設計されています。システムには通常、実際のメッセージバスと視覚化されたメッセージバスの両方があります。したがって、事実上、フローベースのプログラミングの形式があります。

それが数年前に電球を点灯させ、ここに連れてきた理由です。これは本当に素晴らしい働き方であり、従来のプログラミングよりもずっと楽しいものです。メッセージカタログは、中心的な仕様と参照点を形成します。開発者と管理者の両方に適しています。つまり、管理者はソースを見る代わりにメッセージカタログを閲覧できます。

統合ロギングを使用すると、カタログを参照してわかりやすい分析を生成することで、生産性を大幅に高めることができます。私はこの方法で商用製品を開発した実世界の経験を持っています。特にツールとIDEに関して、さらに物事を進めることに興味があります。残念ながら、自動車業界の多くの人々は、これがいかに素晴らしいかという点を逃し、それを基に構築できなかったと思います。彼らは現在、他の流行に気を取られており、物理バスよりも most 開発がはるかに多いことに気づきませんでした。

Spring Web Flowを使用しました Java Webアプリケーションで広範囲に（通常）アプリケーションプロセスをモデリングします。これは、どのページを表示するかに関する多くの条件付きロジックを伴う複雑なウィザードのような傾向があります。その信じられないほど強力です。新しい製品が追加され、1〜2時間で既存のピースをまったく新しいアプリケーションプロセスに再カットすることができました（新しいビュー/状態をいくつか追加しました）。

OSワークフローを使用してビジネスプロセスをモデル化することも検討しましたが、そのプロジェクトはさまざまな目的で使用できます理由。

Microsoftの世界では、 Windows Workflow Foundation （＆quot; WWF＆quot;）があります。特に Sharepoint と組み合わせて、より人気が高まっています。

FBPは、有限状態マシンを実装する手段にすぎません。目新しいものではありません。

まったく同じものではないことは承知していますが、このモデルは長年PLCプログラミングで使用されてきました。 ISOはこれをシーケンシャルフローチャートと呼びますが、多くの人は一般的な実装の後にGrafcetと呼びます。並列処理を提供し、状態間の遷移を定義します。

最近、ビジネスインテリジェンスの世界でデータのマッシュアップと処理に使用されています。 ETL、クエリ、結合、レポートの作成などのデータ処理手順は、エンドユーザーが実行できます。私はオープンシステムの開発者です- ComposableAnalytics.com CAでは、フローベースのアプリを共有して実行できますブラウザ。

これは、MQシリーズ、MSMQ、およびJMSの目的です。

これは、WebサービスとEnterprise Service Busの実装の基盤です。

TIBCOやSunのJCAPSなどの製品は、基本的にこの特定の流行語を使用しないフローベースです。

アプリケーションのほとんどの作業は、処理ネットワークを介してメッセージを渡す小さなモジュールで行われます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow