Programmation basée sur le flux

Question

J'ai lu un peu de programmation basée sur les flux au cours des derniers jours. Il existe un wiki qui fournit des détails supplémentaires. Et wikipedia a également un bonne vue . Ma première pensée a été: "Un autre grand partisan de la programmation prétendue lego-land" - un concept qui remonte à la fin des années 80. Mais, au fil de ma lecture, je dois admettre que je suis intriguée.

1. Avez-vous utilisé FBP pour un projet réel?
2. Quelle est votre opinion sur la FBP?
3. La FBP a-t-elle un avenir?

À certains égards, cela ressemble au Saint Graal de la réutilisation que notre industrie poursuit depuis l’avènement des langages procéduraux.

Answer 1

Discussion intéressante! Hier, je me suis rendu compte qu'une partie de la confusion peut être due au fait que de nombreuses notations différentes utilisent des arcs dirigés, mais les utilisent pour signifier différentes choses. Dans FBP, les lignes représentent des tampons liés, traversés par des flux de paquets de données. Etant donné que les composants sont généralement des processus longs, les flux peuvent comprendre un grand nombre de paquets et les applications FBP peuvent s'exécuter pendant de très longues périodes - peut-être même "de manière perpétuelle". (Voir un article de 2007 sur un projet appelé Eon, principalement par des personnes de l’UMass Amherst). Étant donné qu'un envoi vers un tampon limité est suspendu lorsque le tampon est (temporairement) plein (ou temporairement vide), des quantités indéfinies de données peuvent être traitées à l'aide de ressources finies.

Par comparaison, le E de Grafcet provient de Etapes, ce qui signifie "étapes", ce qui est un concept assez différent. Dans ce type de modèle (et il en existe un certain nombre), le flux de données entre les étapes est soit limité à ce qui peut être stocké simultanément dans la mémoire haute vitesse, soit doit être stocké sur un disque. FBP prend également en charge les boucles sur le réseau, ce qui est difficile à faire dans les systèmes basés sur des étapes - voir par exemple http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication - notez que cette application a utilisé MQSeries et CORBA de manière naturelle. De plus, FBP étant nativement parallèle, il se prête donc à la programmation de réseaux en grille, de machines multicœurs et d’un certain nombre de directions de l’informatique moderne. Un dernier commentaire: dans la littérature, j'ai trouvé de nombreux projets connexes, mais peu d'entre eux possèdent toutes les caractéristiques de la FBP. Une liste que j'ai amassée au fil des ans (un certain nombre d'entre eux plus proche que Grafcet) se trouve dans http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects .

Answer 2

  

1. Avez-vous utilisé FBP pour un projet réel?

Nous avons conçu et mis en place un serveur DF pour notre projet d’automatisation (répartiteur, iterface de composant, ensemble de composants, langage DF, compilateur DF, interface utilisateur). Il est écrit en C ++ nu et fonctionne sur plusieurs systèmes de type Unix (Linux x86, MIPS, avr32, etc., Mac OSX). Il manque plusieurs fonctionnalités, par exemple contrôle de flux sophistiqué, contrôle de thread complexe (il n'y a qu'un composant pas trop avancé pour cela), donc ce n'est qu'un prototype, même si cela fonctionne. Nous travaillons maintenant sur un serveur complet. Nous avons beaucoup appris lors de la mise en oeuvre et de l'utilisation du prototype.

Nous allons également créer un éditeur visuel un jour.

  

2. Quelle est votre opinion sur la FBP?

2.1. Tout d’abord, la programmation de flux de données est le plaisir ultime

Quand j’ai rencontré la programmation par flux de données, j’avais l’impression d’être il ya 20 ans, quand j’ai rencontré la programmation pour la première fois. Malgré tout, la programmation DF diffère de la programmation procédurale / OOP, c’est juste une sorte de programmation. Il y a beaucoup de choses à découvrir, même tellement simples! C'est très amusant quand, en tant que programmeur expérimenté, vous avez rencontré un problème de DF, ce qui est très fondamental, mais il vous était totalement inconnu auparavant. Donc, si vous vous lancez dans la programmation DF, vous vous sentirez comme un programmeur débutant, qui a d’abord rencontré le "cycle". ou "condition".

2.2. Il ne peut être utilisé que pour des architectures spécifiques

C’est juste un marteau, qui sert à enfoncer des clous. DF ne convient pas aux interfaces utilisateur, aux serveurs Web, etc.

.

2.3. L’architecture de flux de données est optimale pour certains problèmes

Un framework de flux de données peut faire des choses magiques. Il peut paralelliser des procédures, qui ne sont pas conçues à l'origine pour la paralellisation. Les composants sont mono-threadés, mais lorsqu'ils sont organisés en un graphique DF, ils deviennent multi-threadés.

Exemple: saviez-vous que make est un système DF? Essayez make -j (voir man, pour quoi -j est utilisé). Si vous avez une machine multi-core, compilez votre projet avec et sans -j et comparez les temps.

2.4. Scission optimale du problème

Si vous écrivez un programme, vous divisez souvent le problème en sous-problèmes plus petits. Il existe généralement des points de partage pour les sous-problèmes connus, que vous n'avez pas besoin de mettre en œuvre. Utilisez simplement les solutions existantes, telles que SQL pour DB, ou OpenGL pour les graphiques / animations, etc.

.

L’architecture DF divise votre problème de manière très intéressante:

• le framework de flux de données, qui fournit l'architecture (utilisez simplement une architecture existante),
• les composants: le programmeur crée des composants; les composants sont simples et bien séparés - il est facile de fabriquer des composants;
• la configuration: a.k.a. programmation par flux de données: le configurateur assemble le graphe de flux de données (programme) à l’aide de composants fournis par le programmeur.

Si votre jeu de composants est bien conçu, le configurateur peut construire ce système, ce à quoi le programmeur n'a jamais rêvé. Le configurateur peut implémenter de nouvelles fonctionnalités sans déranger le programmeur. Les clients sont contents car ils ont une solution personnalisée. Le fabricant de logiciels est également satisfait, car il / elle n’a pas besoin de gérer plusieurs branches du logiciel spécifiques au client, mais uniquement des configurations spécifiques.

2.5. Vitesse

Si le système est construit sur des composants natifs, le programme DF est rapide. La seule perte de temps est la répartition des messages entre les composants par rapport à un simple programme POO, elle est également minime.

  

3. La FBP a-t-elle un avenir?

Oui, bien sûr.

La raison principale est qu’il peut résoudre d’énormes problèmes de multitraitement sans introduire de nouvelles architectures logicielles étranges, des langages étranges. La programmation de flux de données est facile, et je parle de la programmation de composants et de la configuration de flux de données. (Même l’écriture dans un cadre de flux de données n’est pas une fusée.)

Aussi, c'est très économique. Si vous avez un bon ensemble de composants, il vous suffit de réunir les briques lego. Un programme DF est facile à maintenir. La construction de la configuration DF ne nécessite aucun programmeur expérimenté, juste un intégrateur de système.

Je serais heureux si les systèmes natifs se propagent, avec des portes ouvertes pour la création de composants personnalisés. Un langage DF standard devrait également être disponible, ce qui signifie qu'il peut être utilisé avec des éditeurs visuels indépendants de la plate-forme et plusieurs serveurs DF.

Answer 3

Je ne suis pas du tout d'accord avec le commentaire selon lequel la FBP n'est qu'un moyen de mettre en œuvre des FSM: je pense que les FSM sont soignés et qu'ils ont un rôle bien défini dans la création d'applications, mais le concept de base de la FBP est constitué de processus à plusieurs composants. exécuter de manière asynchrone , en communiquant au moyen de flux de fragments de données qui traversent ce que l’on appelle maintenant des tampons liés. Oui, bien sûr, les FSM sont un moyen de créer des processus de composants. En fait, mon livre sur les FBP contient un chapitre entier consacré à cette idée et à celle des PDA ( 1 ) - http://www.jpaulmorrison.com/fbp/compil.htm - mais à mon avis, un FSM mettant en œuvre un réseau FBP non trivial serait incroyablement complexe. À titre d’exemple, le diagramme présenté dans correspond à environ 1/3 d’un travail par lots unique exécuté sur un ordinateur central. Chacun de ces blocs s'exécute de manière asynchrone avec tous les autres. En passant, je serais très intéressé d’entendre plus de réponses aux questions du premier post!

1 : http://fr.wikipedia.org/wiki/Pushdown_automaton Automates à déploiement rapide

Answer 4

Chaque fois que j'entends le terme programmation basée sur les flux, je pense à LabView, conceptuellement. Par exemple, les processus de composant dont la planification est principalement motivée par une modification de ses données d'entrée. C’est vraiment une programmation lego en ce sens que la plate-forme labview a été utilisée pour les derniers produits Mindstorm. Cependant, je ne suis pas d'accord pour dire que cela en fait un modèle de programmation moins utile.

Cela convient très bien aux systèmes industriels qui impliquent généralement la collecte, le contrôle et l’automatisation des données. Qu'est-ce qu'un système de contrôle si les données ne sont pas transformées en données sortantes? Par exemple, quel composant de votre schéma de contrôle ne préféreriez-vous pas représenter sous forme de boîte noire dans une image plus grande, si vous le pouviez? Pour atteindre ce niveau de clarté architecturale à l'aide d'autres méthodologies, vous devrez peut-être dessiner un diagramme de classes de domaine de données, puis une relation de classes d'exécution de problèmes, puis un diagramme de cas d'utilisation et basculer entre eux. Avec les systèmes pilotés par le flux, vous avez le luxe de pouvoir rassembler une grande partie de ces informations avec suffisamment de précision pour que vous puissiez concevoir visuellement un système de manière réaliste une fois que les composants sont construits et définis.

Une question que je n’ai jamais eu à poser lorsque je regarde une application écrite dans labview est "Quel morceau de code a défini cette valeur?", car il était inhérent et facile de remonter à partir des données, les écrivains involontaires étaient impossibles à créer par erreur.

Si seulement c'était vrai du code écrit d'une manière plus procédurale!

Answer 5

1) J'ai construit un petit cadre FBP pour un projet de détection d'anomalie, et il s'est avéré que c'était une excellente idée.

Vous pouvez également consulter certaines des vidéos KNIME , qui donnent une bonne idée de ce que Le framework basé sur les flux se sent comme lorsque le framework est mis en place par une grande équipe. Certes, il est basé sur des lots et n'est pas créé pour un fonctionnement continu.

Cependant, le meilleur exemple de programmation à base de flux est les tuyaux UNIX , qui constituent l’un des cadres FBP les plus anciens et les plus négligés. Je ne pense pas avoir à élaborer sur le pouvoir des nix pipes ...

2) FBP est un outil très puissant pour un grand nombre de problèmes. Le parallélisme intrinsèque est un grand avantage et tout framework FBP peut être rendu complètement transparent au réseau en utilisant des modules d’adaptateur. Les frameworks intelligents sont également absurdement tolérants aux pannes et capables de recharger dynamiquement les modules plantés lorsque cela est nécessaire. La simplicité conceptuelle permet également une communication plus claire avec toutes les personnes impliquées dans un projet et un code beaucoup plus propre.

3) Absolument! Les pipes sont là pour rester et sont l’une des fonctionnalités les plus puissantes d’Unix. Les possibilités inhérentes à un framework FBP par rapport à un programme statique sont nombreuses et modifient légèrement le changement, au point que certains frameworks peuvent être reconfigurés tout en exécutant sans mesures spéciales.

FBP FTW! ; -)

Answer 6

Dans le développement automobile, ils utilisent un protocole de messagerie indépendant du langage qui fait partie de la spécification MOST (Media Oriented Systems Transport), conçu pour la communication entre les composants sur un réseau ou au sein du même appareil. Les systèmes ont généralement à la fois un bus de messages réel et un bus de messages visualisé - vous avez donc une forme de programmation basée sur le flux.

C’est ce qui a motivé l’allumage de l’ampoule il ya plusieurs années et m’a amené ici. C'est vraiment une façon fantastique de travailler et tellement plus amusante que la programmation conventionnelle. Le catalogue de messages constitue la spécification centrale et le point de référence. Cela fonctionne bien pour les développeurs et la gestion. En d'autres termes, la direction peut parcourir le catalogue de messages au lieu de regarder la source.

Avec la journalisation intégrée, le référencement du catalogue permet également de produire des analyses intelligibles, ce qui permet d'obtenir des résultats réellement productifs. J'ai une expérience concrète du développement de produits commerciaux de cette manière. Je suis intéressé à aller plus loin, en particulier en ce qui concerne les outils et les IDE. Malheureusement, je pense que de nombreuses personnes du secteur de l'automobile ont manqué de comprendre à quel point c'est formidable et n'ont pas réussi à en tirer parti. Ils sont maintenant distraits par d’autres modes et ne réalisent pas qu’il y avait bien plus à plus développement que le bus physique.

Answer 7

J'ai utilisé Flux Web de printemps dans les applications Web Java pour modéliser (généralement) les processus d'application, qui sont généralement des opérations complexes ressemblant à des assistants avec beaucoup de logique conditionnelle quant aux pages à afficher. C'est incroyablement puissant. Un nouveau produit a été ajouté et j'ai réussi à recouper les éléments existants dans un tout nouveau processus de demande en une heure ou deux (en ajoutant quelques nouveaux états / vues).

J'ai également envisagé d'utiliser flux de travail du système d'exploitation pour modéliser les processus métier, mais ce projet a été mis en attente pour différents projets. raisons.

Dans le monde Microsoft, vous avez Windows Workflow Foundation (& WWF "), qui est de plus en plus populaire, notamment avec Sharepoint .

La FBP n’est qu’un moyen de mettre en œuvre une machine à états finis . Ce n'est pas nouveau.

Answer 8

Je réalise que ce n’est pas exactement la même chose, mais ce modèle est utilisé depuis des années dans la programmation automate. L'ISO appelle cela l'organigramme séquentiel, mais beaucoup de gens l'appellent Grafcet après une implémentation répandue. Il offre un traitement parallèle et définit les transitions entre les états.

Answer 9

Il est utilisé de nos jours dans le monde de la Business Intelligence pour le mashup et le traitement des données. Les étapes de traitement des données telles qu'ETL, interrogation, jonction et production de rapports peuvent être effectuées par l'utilisateur final. Je suis développeur sur un système ouvert - ComposableAnalytics.com Dans CA, les applications basées sur le flux peuvent être partagées et exécutées via le navigateur.

Answer 10

C’est à quoi servent MQ Series, MSMQ et JMS.

C’est la pierre angulaire des implémentations de Web Services et Enterprise Service Bus.

Des produits tels que TIBCO et le système JCAPS de Sun reposent essentiellement sur le flux sans utiliser ce mot à la mode.

La majeure partie du travail de l'application est effectuée avec de petits modules qui transmettent des messages via un réseau de traitement.