En Fonction De La Programmation

Question

J'ai été faire un peu de lecture sur le Flux en Fonction de la Programmation au cours de la dernière quelques jours. Il y a un wiki qui présente plus de détails. Et wikipédia a une bonne vue d'ensemble sur elle aussi. Ma première pensée a été "un autre Grand promoteur de lego-land semblant de programmation" - un concept remontant à la fin des années 80. Mais, comme je l'ai lu en plus, je dois admettre que j'ai été intrigué.

1. Avez-vous utilisé FBP pour un projet réel?
2. Quelle est votre opinion de FBP?
3. Ne FBP ont-ils un avenir?

Dans un certain sens, il semble que le saint-graal de réutilisation que notre industrie a poursuivi depuis l'avènement des langages procéduraux.

Answer 1

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

Nous avons conçu et mis en œuvre un DF serveur pour notre projet d'automatisation (répartiteur, composant iterface, un tas de composants, DF langue, DF compilateur, de l'INTERFACE utilisateur). Il est écrit dans nu C++, et fonctionne sur plusieurs systèmes de type Unix (Linux x86, MIPS, avr32, etc., Mac OSX). Il lui manque plusieurs fonctions, par exemple sophistiqués de contrôle de flux, complexe thread de contrôle (il n'y qu'un pas trop avancé composant), c'est juste un prototype, même s'il fonctionne. Nous travaillons actuellement sur un serveur complet. Nous avons appris beaucoup au cours de la mise en œuvre et l'utilisation du prototype.

Aussi, nous allons faire un éditeur visuel de quelques jours.

2. Quelle est votre opinion de FBP?

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

Quand j'ai rencontré programmation par flux de données, j'ai été sentir comme il y a 20 ans, quand j'ai rencontré la programmation de la première. Bien, DF programmation diffère de la procédure ou de la programmation orientée objet de la programmation, c'est juste un genre de programmation. Il y a beaucoup de choses à découvrir, même tellement plus simple! C'est très drôle, quand, comme un programmeur expérimenté, vous avez rencontré un DF problème, qui est très-très simple, mais il a été completelly inconnu pour vous, avant de. Donc, si vous sautez dans DF programmation, vous vous sentirez comme un débutant programmeur, qui a d'abord rencontré le "cycle" ou "condition".

2.2. Il peut être utilisé uniquement pour des architectures

C'est juste un coup de marteau, qui sont pour marteler les clous. DF n'est pas adapté pour de l'Isu, serveur web, et ainsi de suite.

2.3. Des flux de données, l'architecture est optimale pour certains problèmes

Un flux de données à un cadre peut faire de la magie des choses. Il peut paralellize procédures, qui ne sont pas à l'origine conçu pour paralellization. Les composants sont mono-thread, mais quand ils sont organisés en une DF graphique, ils sont devenus multi-thread.

Exemple: saviez-vous, que faire est un DF système? Essayez de faire -j (voir l'homme, qu'est-ce-j est utilisé pour). Si vous avez des multi-core de la machine, de compiler votre projet avec et sans -j, et de comparer les temps.

2.4. Partage Optimal du problème

Si vous écrivez un programme, vous avez souvent diviser le problème pour les petits sous-problèmes. Il y a d'habitude split points pour le bien-connu des sous-problèmes, que vous n'avez pas besoin de mettre en œuvre, il suffit d'utiliser les solutions existantes, comme SQL pour la DB, ou OpenGL pour les graphismes et l'animation, etc.

DF architecture divise votre problème d'une manière très intéressante:

• le flux de données-cadre, qui prévoit l'architecture (il suffit d'utiliser une existante),
• les composants: le programmeur crée les composants; les composants sont simples, bien séparés des unités, il est facile de faire des composants;
• la configuration: un.k.un. programmation par flux de données: le configurateur met le graphe de flux de données (programme) ensemble à l'aide de composants fournis par le programmeur.

Si votre jeu de composants est bien conçu, le configurateur peut construire un tel système, qui le programmeur n'a même jamais rêvé. Configurateur peut mettre en œuvre de nouvelles fonctionnalités sans perturber le programmeur. Les clients sont heureux, parce qu'ils ont personnalisé la solution. Fabricant du logiciel est également heureux, parce qu'il/elle n'a pas besoin de maintenir un certain nombre de client-branches spécifiques du logiciel, juste la configuration spécifique du client.

2.5. Vitesse

Si le système est construit sur des éléments natifs, le DF programme est rapide. La seule perte de temps est le message disaptching entre les composants par rapport à un simple OOP programme, il est également minime.

3. Ne FBP ont-ils un avenir?

Oui, bien sûr.

La raison principale est qu'il permet de résoudre massive de multitraitement questions sans introduire de nouvelle marque étranges architectures logicielles, bizarre langues. Programmation par flux de données est facile, et je veux dire à la fois: composant de programmation et des flux de données de configuration de bâtiment. (Même flux de données dans le cadre de l'écriture n'est pas la science de fusée.)

Aussi, il est très économique. Si vous avez un bon jeu de composants, il vous suffit de mettre l'ensemble des briques de lego. Un DF programme est facile à entretenir. Le DF config bâtiment nécessite pas de programmeur expérimenté, juste un intégrateur système.

Je serais heureux, si native des systèmes répartis, avec les portes ouvertes pour composant personnalisé de la création. Aussi, il doit être un standard DF langue, ce qui signifie qu'il peut être utilisé avec plate-forme indépendante des éditeurs visuels et plusieurs DF serveurs.

Answer 2

Discussion intéressante! Il m'est apparu hier qu'une partie de la confusion peut être dû au fait que beaucoup de différentes notations utilisez dirigé arcs, mais de les utiliser pour signifier des choses différentes. Dans FBP, les lignes représentent délimitée tampons, à travers laquelle le voyage de flux de paquets de données. Puisque les composants sont généralement de longue durée d'exécution des processus, des flux peut comporter un grand nombre de paquets, et FBP les applications peuvent s'exécuter sur des périodes très longues, peut - être même "perpétuellement" (voir une étude de 2007 de papier sur un projet appelé Eon, surtout par des gens de chez UMass Amherst). Depuis un envoyer à un délimitée tampon suspend lorsque la mémoire tampon est (temporairement) complet (ou temporairement vide), pour une durée indéterminée quantités de données peuvent être traitées à l'aide de ressources limitées.

Par comparaison, le E dans le Grafcet vient d'Etapes, ce qui signifie "étapes", qui est plutôt une notion différente. Dans ce type de modèle (et il y a un certain nombre de ces là-bas), les données qui circulent entre les étapes est soit limitée à ce qui peut être tenu dans la mémoire à haute vitesse à un moment ou a lieu sur le disque. FBP prend également en charge les boucles dans le réseau, ce qui est difficile à faire dans l'étape systèmes à base de - voir, par exemple, http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication - notez que cette application, utilisée à la fois MQSeries et CORBA de façon naturelle. En outre, le FBP est nativement en parallèle, de sorte qu'il se prête à la programmation de la grille des réseaux, des machines multicœurs, et un certain nombre de directions de l'informatique moderne. Un dernier commentaire: dans la littérature, j'ai trouvé beaucoup de projets, mais peu d'entre eux ont toutes les caractéristiques de FBP. Une liste que j'ai accumulé au fil des années (un certain nombre d'entre eux de plus près que Grafcet) peut être trouvé dans http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects .

Answer 3

Je ne pas d'accord avec le commentaire à propos de FBP être juste un moyen de mettre en œuvre Smqs: je pense que Smqs sont soignés, et je crois qu'ils ont un rôle précis à jouer dans la construction d'applications, mais le concept de base de FBP est de composants multiples processus en cours d'exécution en mode asynchrone, la communication par le biais de flux de blocs de données qui courent à travers ce qu'on appelle les délimitée tampons. Oui, certainement Smqs sont un moyen de renforcer les processus de composant, et en fait il y a tout un chapitre dans mon livre sur le FBP consacrée à cette idée, et l'un des Pda (1) - http://www.jpaulmorrison.com/fbp/compil.htm - mais à mon avis, un FSM mise en œuvre d'un non-trivial FBP réseau serait incroyablement complexe. Un exemple: le diagramme présenté à la est d'environ 1/3 d'un seul lot de travail en cours d'exécution sur un ordinateur central. Chacun de ces blocs est en cours d'exécution asynchrone avec tous les autres. En passant, je serais très intéressé d'entendre plus de réponses aux questions posées dans le premier post!

1: http://en.wikipedia.org/wiki/Pushdown_automaton Push-down automates

Answer 4

Dans le développement automobile, ils ont une langue agnostique protocole de messagerie qui fait partie de la PLUPART des spécifications (Media Oriented Systems Transport), cet a été conçu pour communiquer entre les composants sur un réseau ou dans le même appareil. Les systèmes ont généralement à la fois un réel et de visualiser les bus de message, donc vous avez effectivement une forme de flux en fonction de la programmation.

Qu'est ce qui a fait de l'ampoule aller sur pour moi, il y a plusieurs années et m'a amené ici. C'est vraiment un moyen fantastique de travailler et donc beaucoup plus de plaisir que la programmation classique. Le catalogue de messages au centre de spécification et de point de référence. Il fonctionne bien pour les deux développeurs et de gestion. c'est à dire de Gestion sont en mesure de parcourir le catalogue de messages au lieu de chercher à la source.

Intégré avec la coupe de référencement sur le catalogue pour produire de l'intelligible, de l'analyse de choses peuvent être vraiment productif. J'ai une expérience du monde réel de développement commercial de produits de cette façon. Je suis intéressé à prendre les choses encore plus loin, en particulier en ce qui concerne les outils et les IDEs. Malheureusement, je pense que beaucoup de gens dans le secteur de l'automobile ont manqué le point que c'est et n'ont pas réussi à se construire. Maintenant, ils sont distraits par d'autres modes et a échoué à réaliser qu'il y avait beaucoup plus à la la plupart le développement de la physique en bus.