Frage

Ich habe ein wenig weitergelesen Flussbasierte Programmierung in den letzten Tagen.Da ist ein Wiki die weitere Einzelheiten liefert.Und Wikipedia hat eine guter Überblick auch drauf.Mein erster Gedanke war: „Großartig, ein weiterer Befürworter der Lego-Land-Rollenprogrammierung“ – ein Konzept, das bis in die späten 80er Jahre zurückreicht.Aber je weiter ich lese, desto mehr muss ich zugeben, dass ich neugierig geworden bin.

  1. Haben Sie FBP für ein echtes Projekt verwendet?
  2. Was ist Ihre Meinung zu FBP?
  3. Hat FBP eine Zukunft?

In mancher Hinsicht scheint es der heilige Gral der Wiederverwendung zu sein, den unsere Branche seit dem Aufkommen prozeduraler Sprachen verfolgt.

War es hilfreich?

Lösung

Interessante Diskussion! Mir ist gestern eingefallen, dass ein Teil der Verwirrung darauf zurückzuführen ist, dass viele verschiedene Notationen gezielte Bögen verwenden, sie jedoch für verschiedene Dinge bedeuten. In FBP repräsentieren die Linien begrenzte Puffer, über die Travel -Streams von Datenpaketen. Da die Komponenten normalerweise langlebige Prozesse sind, können Streams eine große Anzahl von Paketen umfassen, und FBP ). Da ein Send an einen begrenzten Puffer ausnimmt, wenn der Puffer (vorübergehend) voll (oder vorübergehend leer) ist, können unbestimmte Datenmengen mithilfe endlicher Ressourcen verarbeitet werden.

Zum Vergleich: Das E in Grafcet stammt aus ETAPES, was "Schritte" bedeutet, was ein ziemlich anderes Konzept ist. In dieser Art von Modell (und es gibt eine Reihe von diesen da draußen) sind die zwischen den Schritten fließenden Daten entweder auf das beschränkt, was gleichzeitig im Hochgeschwindigkeitsspeicher gehalten werden kann, oder müssen auf der Festplatte gehalten werden. FBP unterstützt auch Schleifen im Netzwerk, was in stufenbasierten Systemen schwer zu tun ist - siehe zum Beispiel http://www.jpaulmorrison.com/cgi-bin/wiki.pl?brokerageApplication - Beachten Sie, dass diese Anwendung sowohl MQSeries als auch CORBA auf natürliche Weise verwendete. Darüber hinaus ist FBP nativ parallel und eignet sich daher für die Programmierung von Netznetzwerken, Multicore -Maschinen und eine Reihe von Richtungen des modernen Computers. Ein letzter Kommentar: In der Literatur habe ich viele verwandte Projekte gefunden, aber nur wenige haben alle Eigenschaften von FBP. Eine Liste, die ich im Laufe der Jahre angehäuft habe (einige von ihnen näher als Grafcet), kann in gefunden werden http://www.jpaulmorrison.com/cgi-bin/wiki.pl?flowlikeprojects .

Andere Tipps

1.Haben Sie FBP für ein echtes Projekt verwendet?

Wir haben einen DF-Server für unser Automatisierungsprojekt entworfen und implementiert (Dispatcher, Komponentenschnittstelle, eine Reihe von Komponenten, DF-Sprache, DF-Compiler, Benutzeroberfläche).Es ist in reinem C++ geschrieben und läuft auf mehreren Unix-ähnlichen Systemen (Linux x86, MIPS, avr32 usw., Mac OSX).Es fehlen einige Funktionen, z.B.ausgefeilte Flusskontrolle, komplexe Thread-Steuerung (es gibt nur eine nicht allzu fortgeschrittene Komponente dafür), es ist also nur ein Prototyp, auch wenn es funktioniert.Wir arbeiten jetzt an einem voll ausgestatteten Server.Wir haben bei der Implementierung und Nutzung des Prototyps viel gelernt.

Außerdem werden wir eines Tages einen visuellen Editor erstellen.

2.Was ist Ihre Meinung zu FBP?

2.1.Zuallererst ist es die Datenflussprogrammierung ultimativer Spaß

Als ich die Datenflussprogrammierung kennenlernte, fühlte ich mich wie vor 20 Jahren, als ich zum ersten Mal mit der Programmierung in Berührung kam.Obwohl sich die DF-Programmierung von der prozeduralen/OOP-Programmierung unterscheidet, handelt es sich lediglich um eine Art Programmierung.Es gibt viel zu entdecken, auch sooo einfache!Es ist sehr lustig, wenn Sie als erfahrener Programmierer auf ein DF-Problem gestoßen sind, das eine sehr, sehr grundlegende Sache ist, Ihnen aber vorher völlig unbekannt war.Wenn Sie also in die DF-Programmierung einsteigen, werden Sie sich wie ein Anfänger-Programmierer fühlen, der zum ersten Mal den „Zyklus“ oder die „Bedingung“ erfüllt hat.

2.2.Es kann nur für bestimmte Architekturen verwendet werden

Es ist nur ein Hammer, der zum Einschlagen von Nägeln dient.DF ist nicht für Benutzeroberflächen, Webserver usw. geeignet.

2.3.Die Datenflussarchitektur ist für einige Probleme optimal

Ein Datenfluss-Framework kann magische Dinge bewirken.Es kann Prozeduren parallelisieren, die ursprünglich nicht für die Parallelisierung konzipiert sind.Komponenten sind Single-Thread-Komponenten, aber wenn sie in einem DF-Diagramm organisiert werden, werden sie zu Multi-Thread-Komponenten.

Beispiel:Wussten Sie, dass machen ist ein DF-System?Versuchen mache -j (Siehe Mann, wofür -j verwendet wird).Wenn Sie einen Multi-Core-Rechner haben, kompilieren Sie Ihr Projekt mit und ohne -j und vergleichen Sie die Zeiten.

2.4.Optimale Aufteilung des Problems

Wenn Sie ein Programm schreiben, teilen Sie das Problem häufig in kleinere Unterprobleme auf.Es gibt übliche Aufteilungspunkte für bekannte Unterprobleme, die Sie nicht implementieren müssen. Verwenden Sie einfach die vorhandenen Lösungen, wie SQL für DB oder OpenGL für Grafiken/Animationen usw.

Die DF-Architektur teilt Ihr Problem auf sehr interessante Weise:

  • das Datenfluss-Framework, das die Architektur bereitstellt (verwenden Sie einfach eine vorhandene),
  • die Komponenten:der Programmierer erstellt Komponenten;die Komponenten sind einfache, gut getrennte Einheiten – die Herstellung von Komponenten ist einfach;
  • die Konfiguration:a.k.a.Datenflussprogrammierung:Der Konfigurator stellt den Datenflussgraphen (Programm) unter Verwendung der vom Programmierer bereitgestellten Komponenten zusammen.

Wenn Ihr Komponentensatz gut konzipiert ist, kann der Konfigurator ein System erstellen, von dem der Programmierer noch nie geträumt hat.Konfigurator kann Neues umsetzen Merkmale ohne den Programmierer zu stören.Die Kunden sind zufrieden, weil sie eine personalisierte Lösung haben.Auch der Softwarehersteller ist zufrieden, da er nicht mehrere kundenspezifische Zweige der Software pflegen muss, sondern nur kundenspezifische Konfigurationen.

2.5.Geschwindigkeit

Wenn das System auf nativen Komponenten basiert, ist das DF-Programm schnell.Der einzige Zeitverlust ist der Nachrichtenversand zwischen Komponenten im Vergleich zu einem einfachen OOP-Programm, er ist auch minimal.

3.Hat FBP eine Zukunft?

Ja sicher.

Der Hauptgrund dafür ist, dass es massive Multiprocessing-Probleme lösen kann, ohne völlig neue seltsame Softwarearchitekturen und seltsame Sprachen einzuführen.Die Datenflussprogrammierung ist einfach, und ich meine beides:Komponentenprogrammierung und Datenflusskonfigurationserstellung.(Selbst das Schreiben von Datenfluss-Frameworks ist kein Hexenwerk.)

Außerdem ist es sehr wirtschaftlich.Wenn Sie über einen guten Komponentensatz verfügen, müssen Sie nur noch die Legosteine ​​zusammensetzen.Ein DF-Programm ist einfach zu warten.Für die Erstellung der DF-Konfiguration ist kein erfahrener Programmierer erforderlich, sondern lediglich ein Systemintegrator.

Ich würde mich freuen, wenn sich native Systeme verbreiten würden und Türen für die Erstellung benutzerdefinierter Komponenten offen stünden.Außerdem sollte es eine Standard-DF-Sprache geben, was bedeutet, dass sie mit plattformunabhängigen visuellen Editoren und mehreren DF-Servern verwendet werden kann.

Ich muss mit dem Kommentar nicht zustimmen, dass FBP nur ein Mittel zur Implementierung von FSMs ist: Ich denke asynchron, kommunizieren durch Datenströme von Datenböcken, die über sogenannte begrenzte Puffer rennen. Ja, definitiv sind FSMs eine Möglichkeit, Komponentenprozesse zu bauen, und tatsächlich gibt es in meinem Buch über FBP ein ganzes Kapitel, das dieser Idee gewidmet ist, und das verwandte PDAs (PDAs ()1) - http://www.jpaulmorrison.com/fbp/compil.htm - Meiner Meinung nach wäre eine FSM, die ein nicht triviales FBP-Netzwerk implementiert, unglaublich komplex. Als Beispiel das gezeigte Diagramm inhttp://www.jpaulmorrison.com/fbp/image010.jpgist ungefähr 1/3 von a Single Batch -Job auf einem Mainframe. Jeder dieser Blöcke läuft asynchron mit allen anderen. Übrigens wäre ich sehr interessiert, mehr Antworten auf die Fragen im ersten Beitrag zu hören!

1: http://en.wikipedia.org/wiki/pushdown_automaton Push-Down-Automaten

Immer wenn ich den Begriff flow -basierte Programme höre, denke ich konzeptionell an LabView. IE -Komponentenprozesse, deren Planung hauptsächlich durch eine Änderung der Eingabedaten bestimmt wird. Dies ist wirklich LEGO -Programmierung in dem Sinne, dass die LabView -Plattform für die neueste Mindstorm -Produkte verwendet wurde. Ich bin jedoch nicht einverstanden, dass dies ein weniger nützliches Programmiermodell macht.

Für industrielle Systeme, die in der Regel Datenerfassung, -kontroll- und -automatisierung umfassen, passt sie sehr gut. Was ist ein Steuerungssystem, wenn nicht Daten in Transformation zu Daten ausgestattet sind? Dh welche Komponente in Ihrem Steuerungsschema würden Sie nicht lieber als schwarze Box in einem größeren Bild darstellen, wenn Sie dies tun könnten. Um dieses Maß an architektonischer Klarheit unter Verwendung anderer Methoden zu erreichen, müssen Sie möglicherweise ein Datendomänenklassendiagramm zeichnen, dann eine Problemklassenbeziehung der Domänen -Laufzeit, darüber hinaus ein Anwendungsfalldiagramm und wechseln Sie zwischen ihnen hin und her. Mit fließenden Systemen haben Sie den Luxus, viele dieser Informationen genau genug zusammenzubrechen, damit Sie ein System realistischerweise visuell entwerfen können, sobald die Komponenten erstellt und definiert sind.

Eine Frage, die ich bei der Betrachtung einer in LabView geschriebenen Anwendung nie stellen musste, lautet "Welches Stück Code setzen Sie diesen Wert?" versehentlich erstellen.

Wenn dies nur für den Code gilt, der typischerweise prozedural geschrieben wurde!

1) Ich baue ein kleines FBP -Rahmen für ein Anomalie -Erkennungsprojekt, und es stellt sich heraus, dass es eine großartige Idee war.

Sie können sich auch einige davon ansehen Knime -Videos, Das gibt eine gute Vorstellung davon, wie sich ein flowbasiertes Framework anfühlt, wenn das Framework von einem großartigen Team zusammengestellt wird. Zugegeben, es ist Chargenbasis und nicht für den kontinuierlichen Betrieb erstellt.

Das bei weitem beste Beispiel für fließbasierte Programmierung ist jedoch UNIX Pipes Das ist eines der ältesten und übersehenen FBP -Framework. Ich glaube nicht, dass ich die Kraft von Nix -Rohren näher erläutern muss ...

2) FBP ist ein sehr leistungsfähiges Werkzeug für eine Menge Probleme. Die intrinsische Parallelität ist ein großer Vorteil, und jedes FBP -Framework kann durch Adaptermodule vollständig transparent gemacht werden. Intelligente Frameworks sind auch absurd fehlertolerant und können bei Bedarf stürzte Module dynamisch neu laden. Die konzeptionelle Einfachheit ermöglicht auch eine sauberere Kommunikation mit allen, die an einem Projekt beteiligt sind, und viel saubererer Code.

3) Absolut! Rohre sind hier, um zu bleiben, und sind eines der mächtigsten Merkmale von UNIX. Die Macht, die einem FBP -Framework im Vergleich zu einem statischen Programm inhärent ist, sind viele und trivialisieren Veränderungen bis zu dem Punkt, an dem einige Frameworks neu konfiguriert werden können während dem Rennen ohne besondere Maßnahmen.

FBP FTW! ;-)

In der Automobilentwicklung verfügen sie über ein agnostisches Messaging -Protokoll der Sprache, das Teil der meisten Spezifikation (medienorientierter Systemtransport) ist, um zwischen Komponenten über ein Netzwerk oder innerhalb desselben Geräts zu kommunizieren. Systeme haben normalerweise sowohl einen realen als auch einen visualisierten Nachrichtenbus - daher haben Sie effektiv eine Form der fließbasierten Programmierung.

Das war es, was die Glühbirne vor einigen Jahren für mich weiterging und mich hierher gebracht hat. Es ist wirklich eine fantastische Art zu arbeiten und viel mehr Spaß als herkömmliche Programmierung. Der Nachrichtenkatalog bildet die zentrale Spezifikation und den Referenzpunkt. Es funktioniert sowohl für Entwickler als auch für das Management gut. Das IE -Management kann den Nachrichtenkatalog stöbern, anstatt sich die Quelle anzusehen.

Bei der integrierten Protokollierung bezieht sich auch auf den Katalog, um verständliche Analyse zu erzeugen, die Dinge wirklich produktiv werden können. Ich habe echte Erfahrung in der Entwicklung von kommerziellen Produkten auf diese Weise. Ich bin daran interessiert, die Dinge weiter zu bringen, insbesondere in Bezug auf Werkzeuge und IDES. Leider denke ich, dass viele Menschen im Automobilsektor den Punkt darüber verpasst haben, wie großartig dies ist, und es nicht geschafft haben, darauf aufzubauen. Sie werden jetzt von anderen Modeerscheinungen abgelenkt und haben nicht klar, dass es weit mehr gab die meisten Entwicklung als der physische Bus.

I've used Spring Web Flow extensively in Java Web applications to model (typically) application processes, which tend to be complex wizard-like affairs with lots of conditional logic as to which pages to display. Its incredibly powerful. A new product was added and I managed to recut the existing pieces into a completely new application process in an hour or two (with adding a couple of new views/states).

I also looked into using OS Workflow to model business processes but that project got canned for various reasons.

In the Microsoft world you have Windows Workflow Foundation ("WWF"), which is becoming more popular, particularly in conjunction with Sharepoint.

FBP is just a means of implementing a finite state machine. It's nothing new.

I realize that it is not exactly the same thing, but this model has been used for years in PLC programming. ISO calls it Sequential Flow Chart, but many people call it Grafcet after a popular implementation. It offers parallel processing and defines transitions between states.

It's being used in the Business Intelligence world these days to mashup and process data. Data processing steps like ETL, querying, joining , and producing reports can be done by the end-user. I'm a developer on an open system - ComposableAnalytics.com In CA, the flow-based apps can be shared and executed via the browser.

This is what MQ Series, MSMQ and JMS are for.

This is cornerstone of Web Services and Enterprise Service Bus implementations.

Products like TIBCO and Sun's JCAPS are basically flow-based without using this particular buzz-word.

Most of the work of the application is done with small modules that pass messages through a processing network.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top