En la programación en computadora, la programación basada en flujo (PBF) es un paradigma de programación que define aplicaciones como redes de procesos de "caja negra", los cuales intercambian datos a través de conexiones predefinidas por pasos de mensajes, donde las conexiones están especificadas externamente a los procesos. Estos procesos de caja negra pueden ser reconectados un sinnúmero de veces para formar diferentes aplicaciones sin tener que ser cambiados internamente. PBF, por lo tanto, esta naturalmente orientado a componentes.
PBF es una forma particular de programación de flujo de datos basados en buffers acotados, paquetes de información con tiempos de vida definidos, puertos nombrados y definición separada de conexiones.
Introducción La programación basada en flujo define aplicaciones usando la metáfora de una “fábrica de datos”. Ve una aplicación no como un proceso único y secuencial, que comienza en un punto en el tiempo, y luego hace una cosa a la vez hasta que finaliza, sino como una red de procesos asincrónicos que se comunican por medio de flujo de fragmentos de datos, llamados “paquetes de información” (PI). En esta perspectiva, la atención está en los datos de la aplicación y las transformaciones aplicadas para producir los resultados deseados. La red es definida externamente por los procesos, como una lista de conexiones que son interpretadas por una pieza de software, usualmente llamado “programador”.
Los procesos se comunican mediante conexiones de capacidad fija. Una conexión se adjunta a un proceso por medio de un puerto, que tiene un nombre acordado entre el código del proceso y la definición de la red. Más de un proceso puede ejecutar el mismo trozo de código. En cualquier momento, una IP determinada solo puede ser “propiedad” para un solo proceso o estar en tránsito entre dos procesos. Los puertos pueden ser simples o de tipo matriz, como se usa por ejemplo para el puerto de entrada del componente intercalar que se describe a continuación. Es la combinación de puertos con procesos asincrónicos lo que permite que muchas funciones primitivas de procesamientos de datos de larga duración (tales como Ordenar, fusionar, Resumir, etc.) sean soportadas en la forma de cajas negras de software.
Debido a que los procesos PBF pueden continuar ejecutándose siempre que tengan datos para trabajar y en algún lugar colocar su salida, las aplicaciones PBF generalmente se ejecutan en menos lapsos de tiempo que los programas convencionales y hacen un uso óptimo de todos los procesadores en una máquina sin necesidad de programación especial para lograrlo.
La definición de red suele ser esquemática y es convertida en una lista de conexión en algún lenguaje o notación de bajo nivel. PBF es a menudo un lenguaje de programación visual en este nivel. Las definiciones de red más complejas tienen una estructura jerárquica que se constituye a partir de subredes con conexiones “fijas”. Muchos otros lenguajes/tiempos de ejecución basados en el flujo se constituyen alrededor de lenguajes de programación más tradicionales, el ejemplo más notable es RaftLib, que utiliza operadores similares a iostream de C++ para especificar el gráfico de flujo.
PBF tiene mucho en común con el lenguaje LindaN. Carriero and D. Gelernter, Linda in Context, Communications of the ACM, Vol. 32, No. 4, April 1989 en la terminología de Gelernter y Carriero, un “lenguaje de coordinación”: Es esencialmente un lenguaje independiente.N. Carriero and D. Gelernter, Coordination Languages and their Significance, Communications of the ACM, Vol. 35, No. 2, February 1992 De hecho, da un planificador escrito en un lenguaje de nivel suficientemente bajo, Componentes escritos en diferentes lenguajes pueden ser vinculados en una sola red. PBF se presta así al concepto de lenguajes específicos de dominio o “mini lenguajes”.
PBF exhibe “acoplamiento de datos”, descrito en el artículo sobre acoplamiento como el tipo más flojo de acoplamiento entre componentes. El concepto de acoplamiento bajo esta a su vez relacionado con las arquitecturas orientadas al servicio y PBF se ajusta a un número de criterios para dicha arquitectura, aunque en un nivel más detallado que la mayoría de los ejemplos de esta arquitectura.
PFB promueve un estilo funcional de alto nivel de especificaciones que simplifica el razonamiento sobre el comportamiento del sistema. Un ejemplo de esto es el modelo de flujo de datos distribuidos para especificar y analizar constructivamente la semántica de los protocolos distribuidos de múltiples partes.
Historia La programación basada en flujo fue inventada por Paul J. Morrison a comienzos de 1970, inicialmente implementó un software para un banco canadiense. PFB en sus inicios fue fuertemente influenciado por algunos lenguajes de simulación de IBM del momento, en particular GPSS, pero sus raíces se remontan al documento seminal de Conway sobre lo que el llamó Corrutinas.M.E. Conway, Design of a separable transition-diagram compiler, Communications of the ACM, Vol. 6, No. 7, July 1963
PBF ha sufrido varios cambios de nombre a lo largo de los años: La implementación original se llamaba SPMA (Sistemas de procesamientos modular avanzado). Una gran aplicación en Canadá entró en funcionamiento en 1975 y a partir del 2013, a estado en uso continuo de producción, funcionando diariamente, durante casi 40 años. Debido a que IBM consideraba que las ideas detrás de PBF “se parecían demasiado a una ley de la naturaleza” para ser patentable, en su lugar pusieron los conceptos básicos de PBF en el dominio público, mediante un boletín de divulgación técnica “Sistema de programación de tareas intercaladas, modulares y sensibles a los datos,J. Paul Morrison, Data Responsive Modular, Interleaved Task Programming System, IBM Technical Disclosure Bulletin, Vol. 13, No. 8, 2425-2426, January 1971 en 1971. Un artículo describiendo sus conceptos y experiencias de usuarios fue publicado en 1978 en el IBM Research IBM Systems Journal bajo el nombre DSLM.J. Paul Morrison, Data Stream Linkage Mechanism, IBM Systems Journal Vol. 17, No. 4, 1978 Una segunda implementación fue hecha como un proyecto conjunto de IBM Canadá e IBM Japón, bajo el nombre de “Administrador de desarrollo de flujo de datos” (ADFD) y fue comercializado brevemente en Japón a fines de los años 80 bajo el nombre de “Administrador de programación de flujo de datos”.
Generalmente, los conceptos se denominaron dentro de IBM como “flujo de datos”, pero este término fue considerado demasiado general y finalmente se adoptó el nombre de Programación basada en flujo.
Desde principios de los años 80 hasta 1993, Paul J. Morrison y el arquitecto de IBM Wayne Stevens refinaron y promovieron los conceptos detrás de PBF. Stevens escribió varios artículos describiendo y apoyando los conceptos de PBF e incluyó material en varios de sus libros. [Fuente no primaria necesitada] [fuente no primaria necesitada].W.P. Stevens, How Data Flow can Improve Application Development Productivity, IBM System Journal, Vol. 21, No. 2, 1982W.P. Stevens, Using Data Flow for Application Development, Byte, June 1985W.P. Stevens, Software Design - Concepts and Methods, Practical Software Engineering Series, Ed. Allen Macro, Prentice Hall, 1990, En 1994, Morrison publicó un libro describiendo PBF y proporcionando evidencia empírica de que PBF condujo a tiempos de desarrollo reducidos.
Conceptos El siguiente diagrama muestra las principales entidades de un diagrama PBF (aparte de los Paquetes de información). Dicho diagrama se puede convertir directamente en una lista de conexiones, que luego puede ejecutar un motor apropiado (software o hardware). centro|miniaturadeimagen|Esquema PBF sencillo A, B y C son procesos que ejecutan componentes de código. O1, O2 y las dos entradas son puertos que conectan las conexiones M y N a sus respectivos procesos. Está permitido que los procesos B y C ejecuten el mismo código, por lo que cada proceso debe tener su propio conjunto de almacenamiento de trabajo, bloques de control, etc. Tanto si comparten código como si no, B y C son libres de usar los mismos nombres de puerto, ya que los nombres de puerto solo tienen significado dentro de los componentes que los hacen referencia (y a nivel de red, por supuesto).
M y N son lo que a menudo se denominan "memorias intermedias limitadas" y tienen una capacidad fija en términos de la cantidad de IP que pueden tener en cualquier momento.
El concepto de puertos es lo que permite utilizar el mismo componente en más de un lugar en la red. En combinación con una capacidad de parametrización, llamada Paquetes de información inicial (IIP), los puertos proporcionan a PBF una capacidad de reutilización de componentes, lo que convierte a PBF en una arquitectura basada en componentes . PBF exhibe lo que Raoul de Campo y Nate Edwards de IBM Research han denominado modularidad configurable .
Los paquetes de información o IP se asignan en lo que podría llamarse "espacio de IP" (al igual que las tuplas de Linda se asignan en "espacio de tupla"), y tienen una vida útil bien definida hasta que se eliminan y se recupera su espacio, en PBF esto debe ser una acción explícita por parte de un proceso de propiedad. Las IP que viajan a través de una conexión dada (en realidad son sus "manijas" las que viajan) constituyen un "flujo", que se genera y se consume de forma asíncrona; este concepto tiene similitudes con el concepto de contra perezoso descrito en el artículo de 1976 por Friedman y Wise.D.P. Friedman and D.S. Wise, CONS should not evaluate its arguments, Automata, Languages and Programming, Edinburgh University Press, Edinburgh, 1976
Las IP suelen ser fragmentos estructurados de datos; sin embargo, algunas IP pueden no contener datos reales, sino que se utilizan simplemente como señales. Un ejemplo de esto es "IP de soporte", que se puede utilizar para agrupar IP de datos en patrones secuenciales dentro de una secuencia, llamados "subcorrientes". Las corrientes secundarias pueden a su vez estar anidadas. Las IP también se pueden encadenar para formar "árboles de IP", que viajan a través de la red como objetos individuales.
El sistema de conexiones y procesos descritos anteriormente puede "ramificarse" a cualquier tamaño. Durante el desarrollo de una aplicación, los procesos de monitoreo pueden agregarse entre pares de procesos, los procesos pueden "explotar" en subredes o las simulaciones de procesos pueden reemplazarse por la lógica del proceso real. PBF por lo tanto se presta a la creación rápida de prototipos .
Esta es realmente una imagen de la línea de ensamblaje del procesamiento de datos: las IP que viajan a través de una red de procesos pueden considerarse como widgets que viajan de una estación a otra en una línea de ensamblaje. Las "máquinas" se pueden volver a conectar fácilmente, desconectar para repararlas, reemplazarlas, etc. Por extraño que parezca, esta imagen es muy similar a la del equipo de grabación de la unidad que se usaba para procesar datos antes de los días de las computadoras, excepto que los mazos de tarjetas tenían que llevarse a mano de una máquina a otra.
Las implementaciones de PBF pueden ser no preventivas o preventivas: las implementaciones anteriores tendían a ser no preventivas (mainframe y lenguaje C), mientras que la última implementación de Java (ver a continuación) usa la clase Java Thread y es preventiva.
Ejemplos
"Problema del telegrama"