Programación Basada en Flujo

https://stackoverflow.com/questions/405627

03-07-2019
|

Pregunta

He estado leyendo un poco sobre Programación basada en flujo en los últimos días. Hay un wiki que proporciona más detalles. Y wikipedia tiene una buena descripción general también. Mi primer pensamiento fue: "Gran otro defensor de la programación simulada de lego-land". - Un concepto que se remonta a finales de los 80. Pero, a medida que leo más, debo admitir que me intrigó.

¿Has utilizado FBP para un proyecto real?
¿Cuál es su opinión sobre FBP?
¿FBP tiene futuro?

En algunos sentidos, parece ser el santo grial de la reutilización que nuestra industria ha perseguido desde la llegada de los lenguajes de procedimiento.

Solución

¡Interesante discusión! Ayer se me ocurrió que parte de la confusión puede deberse al hecho de que muchas anotaciones diferentes usan arcos dirigidos, pero los usan para significar cosas diferentes. En FBP, las líneas representan memorias intermedias limitadas, a través de las cuales viajan flujos de paquetes de datos. Dado que los componentes suelen ser procesos de larga duración, las secuencias pueden comprender una gran cantidad de paquetes, y las aplicaciones FBP pueden ejecutarse durante períodos muy largos, tal vez incluso "perpetuamente". (vea un documento de 2007 sobre un proyecto llamado Eon, principalmente por personas de UMass Amherst). Dado que un envío a un búfer acotado se suspende cuando el búfer está (temporalmente) lleno (o temporalmente vacío), se pueden procesar cantidades indefinidas de datos utilizando recursos finitos.

En comparación, la E en Grafcet proviene de Etapes, que significa "pasos", que es un concepto bastante diferente. En este tipo de modelo (y hay varios de estos por ahí), los datos que fluyen entre los pasos se limitan a lo que puede guardarse en la memoria de alta velocidad al mismo tiempo, o deben guardarse en el disco. FBP también admite bucles en la red, lo cual es difícil de hacer en sistemas basados ??en pasos; consulte, por ejemplo, http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication : tenga en cuenta que esta aplicación utiliza MQSeries y CORBA de forma natural. Además, FBP es nativamente paralelo, por lo que se presta a la programación de redes de red, máquinas multinúcleo y una serie de direcciones de la informática moderna. Un último comentario: en la literatura he encontrado muchos proyectos relacionados, pero pocos de ellos tienen todas las características de FBP. En http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects .

Otros consejos

1. ¿Has utilizado FBP para un proyecto real?

Hemos diseñado e implementado un servidor DF para nuestro proyecto de automatización (despachador, iterface de componentes, un grupo de componentes, lenguaje DF, compilador DF, UI). Está escrito en C ++ simple y se ejecuta en varios sistemas tipo Unix (Linux x86, MIPS, avr32, etc., Mac OSX). Carece de varias características, p. control de flujo sofisticado, control de subproceso complejo (solo hay un componente no demasiado avanzado para él), por lo que es solo un prototipo, incluso funciona. Ahora estamos trabajando en un servidor con todas las funciones. Hemos aprendido mucho durante la implementación y el uso del prototipo.

Además, haremos un editor visual algún día.

2. ¿Cuál es su opinión sobre FBP?

2.1. En primer lugar, la programación del flujo de datos es diversión máxima

Cuando conocí la programación de flujo de datos, me sentí como hace 20 años, cuando conocí la programación por primera vez. Aunque la programación DF difiere de la programación procedimental / OOP, es solo un tipo de programación. ¡Hay muchas cosas por descubrir, incluso las más simples! Es muy divertido cuando, como programador experimentado, te encontraste con un problema de DF, que es algo muy básico, pero que antes era completamente desconocido para ti. Entonces, si saltas a la programación DF, te sentirás como un programador novato, que conoció por primera vez el "ciclo". o "condición".

2.2. Solo se puede usar para arquitecturas específicas

Es solo un martillo, que son para martillar clavos. DF no es adecuado para UI, servidores web, etc.

2.3. La arquitectura de flujo de datos es óptima para algunos problemas

Un marco de flujo de datos puede hacer cosas mágicas. Puede paralelizar procedimientos, que no están diseñados originalmente para la paralelización. Los componentes son de un solo subproceso, pero cuando se organizan en un gráfico DF, se vuelven multiproceso.

Ejemplo: ¿sabías que make es un sistema DF? Pruebe make -j (vea man, para qué se usa -j). Si tiene una máquina multinúcleo, compile su proyecto con y sin -j, y compare los tiempos.

2.4. División óptima del problema

Si está escribiendo un programa, a menudo divide el problema por subproblemas más pequeños. Hay puntos de división habituales para subproblemas conocidos, que no necesita implementar, solo use las soluciones existentes, como SQL para DB, o OpenGL para gráficos / animación, etc.

La arquitectura DF divide su problema de una manera muy interesante:

el marco de flujo de datos, que proporciona la arquitectura (solo use una existente),
los componentes: el programador crea componentes; los componentes son unidades simples y bien separadas; es fácil hacer componentes;
la configuración: a.k.a. programación de flujo de datos: el configurador reúne el gráfico de flujo de datos (programa) usando componentes proporcionados por el programador.

Si su conjunto de componentes está bien diseñado, el configurador puede construir dicho sistema, que el programador nunca había soñado. El configurador puede implementar nuevas funciones sin molestar al programador. Los clientes están contentos porque tienen una solución personalizada. El fabricante de software también está contento, porque no necesita mantener varias ramas específicas del cliente del software, solo configuraciones específicas del cliente.

2.5. Velocidad

Si el sistema se basa en componentes nativos, el programa DF es rápido. La única pérdida de tiempo es el envío de mensajes entre componentes en comparación con un simple programa OOP, también es mínimo.

3. ¿FBP tiene futuro?

Sí, claro.

La razón principal es que puede resolver problemas de multiprocesamiento masivos sin introducir nuevas arquitecturas de software extrañas, lenguajes extraños. La programación de flujo de datos es fácil, y me refiero a ambos: programación de componentes y construcción de configuración de flujo de datos. (Incluso la escritura del marco de flujo de datos no es una ciencia espacial).

Además, es muy económico. Si tiene un buen conjunto de componentes, solo necesita juntar los ladrillos de lego. Un programa de DF es fácil de mantener. El edificio de configuración de DF no requiere un programador experimentado, solo un integrador de sistemas.

Sería feliz, si los sistemas nativos se extendieran, con las puertas abiertas para la creación de componentes personalizados. También debe haber un lenguaje DF estándar, lo que significa que se puede usar con editores visuales independientes de la plataforma y varios servidores DF.

Tengo que estar en desacuerdo con el comentario acerca de que FBP es solo un medio de implementar FSM: creo que los FSM son geniales, y creo que tienen un papel definido en la creación de aplicaciones, pero el concepto central de FBP es de procesos de componentes múltiples ejecutando asincrónicamente , comunicándose por medio de secuencias de fragmentos de datos que se ejecutan en lo que ahora se llaman memorias intermedias limitadas. Sí, definitivamente los FSM son una forma de construir procesos de componentes, y de hecho hay un capítulo completo en mi libro sobre FBP dedicado a esta idea, y el relacionado de PDA ( 1 ) - http://www.jpaulmorrison.com/fbp/compil.htm , pero en mi opinión, un FSM que implemente una red FBP no trivial sería increíblemente complejo. Como ejemplo, el diagrama que se muestra en es aproximadamente 1/3 de un trabajo por lotes single que se ejecuta en un mainframe. Cada uno de esos bloques se ejecuta de forma asincrónica con todos los demás. Por cierto, ¡estaría muy interesado en escuchar más respuestas a las preguntas en la primera publicación!

1 : http://en.wikipedia.org/wiki/Pushdown_automaton Autómatas push-down

Cada vez que escucho el término programación basada en flujo pienso en LabView, conceptualmente. Es decir, el componente procesa quién está programado principalmente por un cambio en sus datos de entrada. Esto realmente ES programación de lego en el sentido de que la plataforma labview se utilizó para la última cosecha de productos de tormenta de ideas. Sin embargo, no estoy de acuerdo con que esto lo convierta en un modelo de programación menos útil.

Para sistemas industriales que típicamente involucran recolección de datos, control y automatización, encaja muy bien. ¿Qué es cualquier sistema de control si no se transforman los datos en datos? Es decir, qué componente de su esquema de control no preferiría representar como un cuadro negro en una imagen más grande, si pudiera hacerlo. Para lograr ese nivel de claridad arquitectónica utilizando otras metodologías, es posible que tenga que dibujar un diagrama de clase de dominio de datos, luego una relación de clase de tiempo de ejecución del dominio problemático, luego, un diagrama de caso de uso y alternar entre ellos. Con los sistemas impulsados ??por flujo, tiene el lujo de poder colapsar gran parte de esta información con la suficiente precisión como para poder diseñar de manera realista un sistema visual una vez que los componentes se construyen y definen.

Una pregunta que nunca tuve que hacer al mirar una aplicación escrita en labview es "¿Qué código establece este valor?", ya que era inherente y fácil de rastrear hacia atrás desde los datos, y también errores como múltiples los escritores involuntarios fueron imposibles de crear por error.

¡Si solo eso fuera cierto para el código escrito de una manera más típicamente procesal!

1) Construyo un pequeño marco FBP para un proyecto de detección de anomalías, y resultó ser una gran idea.

También puede ver algunos de los videos KNIME , que dan una buena idea de qué El framework basado en flujo se siente como cuando un gran equipo arma el framework. Es cierto que está basado en lotes y no está creado para una operación continua.

Sin embargo, con mucho, el mejor ejemplo de programación basada en flujo es canalizaciones UNIX , que es uno de los marcos de FBP más antiguos y olvidados. No creo que tenga que dar más detalles sobre el poder de las tuberías de nix ...

2) FBP es una herramienta muy poderosa para un gran conjunto de problemas. El paralelismo intrínseco es una gran ventaja, y cualquier marco FBP puede hacerse completamente transparente en la red mediante el uso de módulos adaptadores. Los marcos inteligentes también son absurdamente tolerantes a fallas y pueden recargar dinámicamente módulos bloqueados cuando es necesario. La simplicidad conceptual también permite una comunicación más limpia con todos los involucrados en un proyecto y un código mucho más limpio.

3) ¡Absolutamente! Las tuberías llegaron para quedarse, y son una de las características más poderosas de Unix. El poder inherente en un marco FBP en comparación con un programa estático son muchos, y trivializa el cambio, hasta el punto en que algunos marcos pueden reconfigurarse mientras se ejecuta sin medidas especiales.

FBP FTW! ;-)

En el desarrollo automotriz, tienen un protocolo de mensajería independiente del lenguaje que forma parte de la especificación MOST (Transporte de sistemas orientados a medios), diseñado para comunicarse entre componentes a través de una red o dentro del mismo dispositivo. Los sistemas generalmente tienen un bus de mensajes visual y real, por lo tanto, efectivamente tiene una forma de programación basada en el flujo.

Eso fue lo que hizo que la bombilla se encendiera hace varios años y me trajo aquí. Realmente es una forma fantástica de trabajar y mucho más divertida que la programación convencional. El catálogo de mensajes forma la especificación central y el punto de referencia. Funciona bien tanto para desarrolladores como para la administración. es decir, la Administración puede navegar por el catálogo de mensajes en lugar de mirar la fuente.

Con el registro integrado también se hace referencia al catálogo para producir análisis inteligibles, las cosas pueden ser realmente productivas. Tengo experiencia en el mundo real de desarrollar productos comerciales de esta manera. Estoy interesado en llevar las cosas más allá, particularmente en lo que respecta a herramientas e IDE. Desafortunadamente, creo que muchas personas dentro del sector automotriz han perdido el punto acerca de cuán grandioso es esto y no han podido construir sobre él. Ahora están distraídos por otras modas y no se dieron cuenta de que había mucho más en la mayoría de desarrollos que el bus físico.

He usado Spring Web Flow ampliamente en aplicaciones web Java para modelar (típicamente) procesos de aplicación, que tienden a ser asuntos complejos tipo asistente con mucha lógica condicional en cuanto a qué páginas mostrar. Es increíblemente poderoso. Se agregó un nuevo producto y logré recortar las piezas existentes en un proceso de aplicación completamente nuevo en una o dos horas (con la adición de un par de nuevas vistas / estados).

También estudié el uso de Flujo de trabajo del sistema operativo para modelar los procesos comerciales, pero ese proyecto se enlazó para varios razones.

En el mundo de Microsoft tiene Windows Workflow Foundation (" WWF "), que es cada vez más popular, especialmente en conjunto con Sharepoint .

FBP es solo un medio de implementar una máquina de estados finitos . No es nada nuevo.

Me doy cuenta de que no es exactamente lo mismo, pero este modelo se ha utilizado durante años en la programación de PLC. ISO lo llama diagrama de flujo secuencial, pero muchas personas lo llaman Grafcet después de una implementación popular. Ofrece procesamiento paralelo y define transiciones entre estados.

Se está utilizando en el mundo de Business Intelligence en estos días para combinar y procesar datos. El usuario final puede realizar pasos de procesamiento de datos como ETL, consultar, unir y producir informes. Soy desarrollador en un sistema abierto: ComposableAnalytics.com en CA, las aplicaciones basadas en flujo se pueden compartir y ejecutar a través de el navegador.

Para eso están las series MQ, MSMQ y JMS.

Esta es la piedra angular de las implementaciones de Web Services y Enterprise Service Bus.

Los productos como TIBCO y JCAPS de Sun están básicamente basados ??en el flujo sin usar esta palabra de moda en particular.

La mayor parte del trabajo de la aplicación se realiza con pequeños módulos que pasan mensajes a través de una red de procesamiento.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow