Hispanopedia Wiki
Articulo de referencia

Programación basada en flujo

En programación informática , la programación basada en flujo ( FBP , por sus siglas en inglés) es un paradigma que define las aplicaciones como redes de procesos de caja negra ...

Hispanopedia WikiContenido en espanolLectura gratuita

En programación informática , la programación basada en flujo ( FBP , por sus siglas en inglés) es un paradigma que define las aplicaciones como redes de procesos de caja negra que intercambian datos a través de conexiones predefinidas mediante el paso de mensajes , donde dichas conexiones se especifican externamente a los procesos. Estos procesos de caja negra pueden reconectarse indefinidamente para formar diferentes aplicaciones sin necesidad de modificarse internamente. Por lo tanto, la FBP es inherentemente orientada a componentes .

FBP es una forma particular de programación de flujo de datos basada en búferes limitados, paquetes de información con tiempos de vida definidos, puertos con nombre y definición separada de conexiones.

Introducción

La programación basada en flujo define las aplicaciones mediante la metáfora de una "fábrica de datos". Considera una aplicación no como un único proceso secuencial que comienza en un momento dado y realiza una tarea a la vez hasta finalizar, sino como una red de procesos asíncronos que se comunican mediante flujos de fragmentos de datos estructurados, denominados "paquetes de información" (PI). Desde esta perspectiva, el foco se centra en los datos de la aplicación y las transformaciones que se les aplican para producir los resultados deseados. La red se define externamente a los procesos, como una lista de conexiones que es interpretada por un software, generalmente llamado "planificador".

Los procesos se comunican mediante conexiones de capacidad fija. Una conexión se asocia a un proceso mediante un puerto , cuyo nombre se define entre el código del proceso y la definición de red. Varios procesos pueden ejecutar el mismo fragmento de código. En cualquier momento, una dirección IP determinada solo puede pertenecer a un único proceso o estar en tránsito entre dos. Los puertos pueden ser simples o de tipo matriz, como el puerto de entrada del componente Collate que se describe a continuación. La combinación de puertos con procesos asíncronos permite que muchas funciones primitivas de procesamiento de datos de larga duración, como Sort, Merge, Summarize, etc., se ejecuten como cajas negras de software .

Debido a que los procesos FBP pueden continuar ejecutándose mientras tengan datos con los que trabajar y un lugar donde almacenar su salida, las aplicaciones FBP generalmente se ejecutan en menos tiempo que los programas convencionales y hacen un uso óptimo de todos los procesadores de una máquina, sin necesidad de programación especial para lograrlo. [ 1 ]

La definición de red suele ser diagramática y se convierte en una lista de conexiones mediante un lenguaje o notación de bajo nivel. FBP suele ser un lenguaje de programación visual en este nivel. Las definiciones de red más complejas tienen una estructura jerárquica, construida a partir de subredes con conexiones persistentes. Muchos otros lenguajes/entornos de ejecución basados ​​en flujo se basan en 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 grafo de flujo.

FBP tiene mucho en común con el lenguaje Linda [ 2 ] en que, en la terminología de Gelernter y Carriero, es un "lenguaje de coordinación" [ 3 ] : es esencialmente independiente del lenguaje. De hecho, dado un planificador escrito en un lenguaje de nivel suficientemente bajo, los componentes escritos en diferentes lenguajes pueden vincularse en una sola red. Por lo tanto, FBP se presta al concepto de lenguajes específicos de dominio o "mini-lenguajes".

FBP presenta el "acoplamiento de datos", descrito en el artículo sobre acoplamiento como el tipo de acoplamiento más laxo entre componentes. El concepto de acoplamiento laxo, a su vez, está relacionado con el de las arquitecturas orientadas a servicios , y FBP cumple con varios de los criterios de este tipo de arquitectura, aunque a un nivel más detallado que la mayoría de los ejemplos.

FBP promueve un estilo de especificaciones funcional y de alto nivel que simplifica el razonamiento sobre el comportamiento del sistema. Un ejemplo de esto es el modelo de flujo de datos distribuido para especificar y analizar de forma constructiva la semántica de los protocolos distribuidos multipartitos.

Historia

La programación basada en flujo fue inventada por J. Paul Morrison a principios de la década de 1970 y se implementó inicialmente en software para un banco canadiense. [ 4 ] En sus inicios, la FBP estuvo fuertemente influenciada por algunos lenguajes de simulación de IBM de la época, en particular GPSS , pero sus raíces se remontan al artículo fundamental de Conway sobre lo que él denominó corrutinas . [ 5 ]

FBP ha sufrido varios cambios de nombre a lo largo de los años: la implementación original se llamaba AMPS (Advanced Modular Processing System). Una gran aplicación en Canadá se puso en marcha en 1975 y, a fecha de 2013, llevaba casi 40 años en uso continuo en producción, funcionando a diario. Dado que IBM consideraba que las ideas detrás de FBP eran "demasiado parecidas a una ley de la naturaleza" para ser patentables, en su lugar puso los conceptos básicos de FBP en el dominio público, mediante un Boletín de Divulgación Técnica , "Data Responsive Modular, Interleaved Task Programming System" [ 6 ] en 1971. [ 4 ] Un artículo que describía sus conceptos y la experiencia de uso se publicó en 1978 en el IBM Research IBM Systems Journal bajo el nombre DSLM. [ 7 ] Una segunda implementación se realizó como un proyecto conjunto de IBM Canadá e IBM Japón, bajo el nombre "Data Flow Development Manager" (DFDM), y se comercializó brevemente en Japón a finales de los 80 con el nombre "Data Flow Programming Manager".

En general, dentro de IBM estos conceptos se denominaban "flujo de datos", pero se consideró que este término era demasiado general y, finalmente, se adoptó el nombre de "programación basada en flujo".

Desde principios de los años 80 hasta 1993, J. Paul Morrison y el arquitecto de IBM Wayne Stevens perfeccionaron y promovieron los conceptos detrás de FBP. Stevens escribió varios artículos que describían y respaldaban el concepto de FBP, e incluyó material sobre él en varios de sus libros. [ 8 ] [ 9 ] [ 10 ] . En 1994, Morrison publicó un libro que describía FBP y proporcionaba evidencia empírica de que FBP conducía a tiempos de desarrollo reducidos. [ 11 ]

Conceptos

El siguiente diagrama muestra las entidades principales de un diagrama FBP (aparte de los paquetes de información). Dicho diagrama se puede convertir directamente en una lista de conexiones, que luego puede ser ejecutada por un motor apropiado (software o hardware).

Diagrama FBP simple

A, B y C son procesos que ejecutan componentes de código. O1, O2 y las dos entradas (IN) son puertos que conectan las conexiones M y N con sus respectivos procesos. Se permite que los procesos B y C ejecuten el mismo código, por lo que cada proceso debe tener su propio conjunto de memoria de trabajo, bloques de control, etc. Independientemente de si comparten código o no, B y C pueden usar los mismos nombres de puerto, ya que estos solo tienen significado dentro de los componentes que los referencian (y, por supuesto, a nivel de red).

M y N son lo que a menudo se denomina " búferes limitados " y tienen una capacidad fija en términos del número de direcciones IP que pueden contener en un momento dado.

El concepto de puertos permite que un mismo componente se utilice en más de un punto de la red. En combinación con la capacidad de parametrización, denominada Paquetes de Información Inicial (IIP), los puertos dotan a FBP de la capacidad de reutilizar componentes, convirtiéndola en una arquitectura basada en componentes . De este modo, FBP 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 IP" (al igual que las tuplas de Linda se asignan en el "espacio de tuplas"), y tienen una vida útil bien definida hasta que se eliminan y se recupera su espacio; en FBP, esto debe ser una acción explícita por parte del proceso propietario. Los IP que viajan a través de una conexión determinada (en realidad, son sus "identificadores" los que viajan) constituyen un "flujo", que se genera y consume de forma asíncrona; este concepto, por lo tanto, tiene similitudes con el concepto de cons perezoso descrito en el artículo de Friedman y Wise de 1976. [ 12 ]

Las direcciones IP suelen ser bloques de datos estructurados; sin embargo, algunas pueden no contener datos reales, sino que se utilizan simplemente como señales. Un ejemplo de esto son las "direcciones IP entre corchetes", que se utilizan para agrupar direcciones IP de datos en patrones secuenciales dentro de un flujo, denominados "subflujos". Los subflujos, a su vez, pueden estar anidados. Las direcciones IP también pueden encadenarse para formar "árboles IP", que viajan por la red como objetos individuales.

El sistema de conexiones y procesos descrito anteriormente puede ramificarse a cualquier tamaño. Durante el desarrollo de una aplicación, se pueden añadir procesos de monitorización entre pares de procesos, dividirlos en subredes o sustituir las simulaciones de procesos por la lógica real. Por lo tanto, FBP se presta a la creación rápida de prototipos .

Esta es, en realidad, una metáfora de la cadena de montaje aplicada al procesamiento de datos: las direcciones IP que circulan por una red de procesos pueden considerarse como piezas que se desplazan de una estación a otra en una cadena de montaje. Las "máquinas" pueden reconectarse fácilmente, desconectarse para su reparación, reemplazarse, etc. Curiosamente, esta imagen es muy similar a la de los equipos de registro de datos que se utilizaban antes de la llegada de los ordenadores, con la diferencia de que las barajas de cartas debían transportarse manualmente de una máquina a otra.

Las implementaciones de FBP pueden ser no preferentes o preferentes; las implementaciones anteriores tendían a ser no preferentes (mainframe y lenguaje C), mientras que la última implementación en Java (véase más abajo) utiliza la clase Java Thread y es preferente.

Ejemplos

El problema del telegrama

Los componentes FBP suelen formar pares complementarios. Este ejemplo utiliza dos de estos pares. El problema descrito parece muy sencillo en palabras, pero en realidad es sorprendentemente difícil de resolver utilizando la lógica procedimental convencional. La tarea, denominada "problema del telegrama", descrita originalmente por Peter Naur , consiste en escribir un programa que acepte líneas de texto y genere líneas de salida con la mayor cantidad de palabras posible, donde el número de caracteres en cada línea no supere una longitud determinada. Las palabras no pueden dividirse y asumimos que ninguna palabra es más larga que el tamaño de las líneas de salida. Esto es análogo al problema del ajuste de línea en los editores de texto. [ 13 ]

En la lógica convencional, el programador descubre rápidamente que ni las estructuras de entrada ni las de salida pueden utilizarse para controlar la jerarquía de llamadas del flujo de control . En FBP, en cambio, la propia descripción del problema sugiere una solución:

  • Las "palabras" se mencionan explícitamente en la descripción del problema, por lo que es razonable que el diseñador trate las palabras como paquetes de información (PI).
  • En FBP no existe una única jerarquía de llamadas, por lo que el programador no se ve tentado a forzar que un subpatrón de la solución sea el de nivel superior.

Aquí está la solución más natural en FBP (no hay una única solución "correcta" en FBP, pero esta parece encajar de forma natural):

El problema del telegrama de Peter Naur

donde DC y RC significan "Descomponer" y "Recomponer", respectivamente.

Como se mencionó anteriormente, los paquetes de información inicial (IIP) se pueden usar para especificar información paramétrica, como la longitud deseada del registro de salida (requerida por los dos componentes de la derecha) o los nombres de archivo. Los IIP son fragmentos de datos asociados a un puerto en la definición de red que se convierten en direcciones IP "normales" cuando se emite una señal de "recepción" para el puerto correspondiente.

Actualización por lotes

Este tipo de programa implica comparar un archivo de detalles (cambios, adiciones y eliminaciones) con un archivo maestro, y generar (al menos) un archivo maestro actualizado y uno o más informes. Los programas de actualización suelen ser bastante difíciles de programar utilizando código procedimental síncrono, ya que se deben mantener sincronizados dos (a veces más) flujos de entrada, incluso si existen archivos maestros sin detalles correspondientes, o viceversa.

Estructura canónica de "actualización por lotes"

En FBP, un componente reutilizable (Collate), basado en la idea de registro unitario de un Collator, facilita enormemente la escritura de este tipo de aplicaciones, ya que Collate fusiona los dos flujos e inserta IP entre corchetes para indicar los niveles de agrupación, simplificando significativamente la lógica posterior. Supongamos que un flujo ("masters" en este caso) consta de IP con valores clave 1, 2 y 3, y los IP del segundo flujo ("details") tienen valores clave 11, 12, 21, 31, 32, 33 y 41, donde el primer dígito corresponde a los valores clave maestros. Al usar caracteres entre corchetes para representar los IP entre corchetes, el flujo de salida cotejado será el siguiente:

( m1 d11 d12 ) ( m2 d21 ) ( m3 d31 d32 d33 ) (d41)

Como no había ningún maestro con un valor de 4, el último grupo consta de un solo detalle (más corchetes).

La estructura del flujo anterior se puede describir sucintamente utilizando una notación similar a BNF , como por ejemplo:

{ ( [m] d* ) }*

Collate es una caja negra reutilizable que solo necesita saber dónde se encuentran los campos de control en sus IP entrantes (aunque esto no es estrictamente necesario, ya que se pueden insertar procesos transformadores aguas arriba para colocar los campos de control en ubicaciones estándar). De hecho, se puede generalizar a cualquier número de flujos de entrada y a cualquier nivel de anidamiento de corchetes. Collate utiliza un puerto de tipo matriz para la entrada, lo que permite un número variable de flujos de entrada.

Procesos de multiplexación

La programación basada en flujos admite la multiplexación de procesos de forma muy natural. Dado que los componentes son de solo lectura, cualquier número de instancias de un componente determinado ("procesos") pueden ejecutarse de forma asíncrona entre sí.

Ejemplo de multiplexación

Cuando los ordenadores solían tener un solo procesador, esto resultaba útil cuando había mucha actividad de entrada/salida; ahora que las máquinas suelen tener varios procesadores, también empieza a ser útil cuando los procesos consumen muchos recursos de la CPU. El diagrama de esta sección muestra un único proceso de "balanceador de carga" que distribuye datos entre tres procesos, denominados S1, S2 y S3, respectivamente, que son instancias de un único componente, los cuales, a su vez, alimentan un único proceso según el principio de "primero en llegar, primero en ser atendido".

Red interactiva simple

Esquema de una aplicación interactiva general

En este esquema general, las solicitudes (transacciones) de los usuarios ingresan al diagrama por la parte superior izquierda, y las respuestas se reciben por la parte inferior izquierda. Los sistemas de back-end (a la derecha) se comunican con sistemas en otros sitios, por ejemplo, mediante CORBA , MQSeries , etc. Las interconexiones representan solicitudes que no necesitan pasar por los sistemas de back-end, o solicitudes que deben circular por la red más de una vez antes de ser devueltas al usuario.

Dado que las distintas solicitudes pueden utilizar distintos sistemas de almacenamiento y pueden requerir diferentes cantidades de tiempo para que dichos sistemas (si se utilizan) las procesen, se deben tomar medidas para relacionar los datos devueltos con las transacciones solicitantes correspondientes, por ejemplo, mediante tablas hash o cachés.

El diagrama anterior es esquemático en el sentido de que la aplicación final puede contener muchos más procesos: se pueden insertar procesos entre otros para administrar cachés, mostrar el tráfico de conexión, monitorear el rendimiento, etc. Además, los bloques del diagrama pueden representar "subredes", es decir, pequeñas redes con una o más conexiones abiertas.

Comparación con otros paradigmas y metodologías

Programación Estructurada de Jackson (JSP) y Desarrollo de Sistemas de Jackson (JSD)

Esta metodología presupone que un programa debe estar estructurado como una única jerarquía procedimental de subrutinas. Su punto de partida es describir la aplicación como un conjunto de "líneas principales", basadas en las estructuras de datos de entrada y salida. Una de estas "líneas principales" se elige para controlar todo el programa, y ​​las demás deben "invertirse" para convertirlas en subrutinas (de ahí el nombre de "inversión de Jackson"). Esto a veces produce lo que se denomina un "choque", lo que obliga a dividir el programa en varios programas o corrutinas. Al utilizar FBP, este proceso de inversión no es necesario, ya que cada componente de FBP puede considerarse una "línea principal" independiente.

FBP y JSP comparten el concepto de tratar un programa (o algunos componentes) como un analizador sintáctico de un flujo de entrada.

En el trabajo posterior de Jackson, Jackson System Development (JSD), las ideas se desarrollaron aún más. [ 14 ] [ 15 ]

En JSD, el diseño se mantiene como un diseño de red hasta la etapa de implementación final. El modelo se transforma entonces en un conjunto de procesos secuenciales según el número de procesadores disponibles. Jackson analiza la posibilidad de ejecutar directamente el modelo de red existente antes de este paso, en la sección 1.3 de su libro (cursiva añadida):

La especificación generada al final del paso de temporización del sistema es, en principio, susceptible de ejecución directa. El entorno necesario contendría un procesador para cada proceso, un dispositivo equivalente a un búfer ilimitado para cada flujo de datos y algunos dispositivos de entrada y salida donde el sistema se conecta al mundo real. Dicho entorno podría, por supuesto, ser proporcionado por un software adecuado que se ejecute en una máquina suficientemente potente. En ocasiones, esta ejecución directa de la especificación será posible e incluso podría ser una opción razonable. [ 15 ]

FBP fue reconocido por MA Jackson como un enfoque que sigue su método de "Descomposición del programa en procesos secuenciales que se comunican mediante un mecanismo similar a una corrutina" [ 16 ].

Programación aplicativa

WB Ackerman define un lenguaje aplicativo como aquel que realiza todo su procesamiento mediante operadores aplicados a valores. [ 17 ] El primer lenguaje aplicativo conocido fue LISP.

Un componente FBP puede considerarse como una función que transforma su(s) flujo(s) de entrada en su(s) flujo(s) de salida. Estas funciones se combinan posteriormente para realizar transformaciones más complejas, como se muestra aquí:

Dos funciones alimentan una

Si etiquetamos las secuencias, como se muestra, con letras minúsculas, entonces el diagrama anterior se puede representar de forma concisa como sigue:

c = G(F(a),F(b));

Así como en la notación funcional la letra F puede usarse dos veces porque solo trabaja con valores y, por lo tanto, no tiene efectos secundarios, en FBP dos instancias de un componente dado pueden ejecutarse simultáneamente, por lo que los componentes de FBP tampoco deben tener efectos secundarios. La notación funcional podría usarse claramente para representar al menos una parte de una red FBP.

Surge entonces la pregunta de si los componentes FBP pueden expresarse mediante notación funcional. WH Burge demostró cómo se pueden desarrollar expresiones de flujo utilizando un estilo de programación recursivo y aplicativo, pero este trabajo se basó en (flujos de) valores atómicos. [ 18 ] En FBP, es necesario poder describir y procesar bloques de datos estructurados (FBP IP).

Además, la mayoría de los sistemas de aplicaciones asumen que todos los datos están disponibles en memoria al mismo tiempo, mientras que las aplicaciones FBP necesitan poder procesar flujos de datos de larga duración utilizando recursos finitos. Friedman y Wise propusieron una forma de lograrlo añadiendo el concepto de "cons perezoso" al trabajo de Burge. Esto eliminó el requisito de que ambos argumentos de "cons" estuvieran disponibles en el mismo instante. "Cons perezoso" no construye un flujo hasta que ambos argumentos se hayan realizado; antes de eso, simplemente registra una "promesa" de hacerlo. Esto permite que un flujo se realice dinámicamente desde el principio, pero con un final no realizado. El final del flujo permanece no realizado hasta el final del proceso, mientras que el principio es una secuencia de elementos cada vez más larga.

Linda

Muchos de los conceptos de FBP parecen haber sido descubiertos de forma independiente en diferentes sistemas a lo largo de los años. Linda, mencionada anteriormente, es un ejemplo de ello. La diferencia entre ambas técnicas se ilustra con la técnica de balanceo de carga de Linda, conocida como la "escuela de pirañas" : en FBP, esto requiere un componente adicional de "balanceador de carga" que dirige las solicitudes al componente de una lista con el menor número de direcciones IP en espera de procesamiento. Es evidente que FBP y Linda están estrechamente relacionadas, y una podría utilizarse fácilmente para simular la otra.

Programación orientada a objetos

En la programación orientada a objetos (POO), un objeto puede describirse como una unidad semiautónoma que comprende tanto información como comportamiento. Los objetos se comunican mediante "llamadas a métodos", que son esencialmente llamadas a subrutinas, realizadas indirectamente a través de la clase a la que pertenece el objeto receptor. Los datos internos del objeto solo pueden ser accedidos mediante llamadas a métodos, por lo que esto constituye una forma de ocultamiento de información o "encapsulación". Sin embargo, la encapsulación es anterior a la POO —David Parnas escribió uno de los artículos fundamentales sobre el tema a principios de los años 70 [ 19 ] — y es un concepto básico en informática. La encapsulación es la esencia misma de un componente FBP, que puede considerarse como una caja negra que realiza alguna conversión de sus datos de entrada en sus datos de salida. En FBP, parte de la especificación de un componente son los formatos de datos y las estructuras de flujo que puede aceptar y los que generará. Esto constituye una forma de diseño por contrato . Además, los datos en una propiedad intelectual (IP) solo pueden ser accedidos directamente por el proceso propietario actual. La encapsulación también puede implementarse a nivel de red, haciendo que los procesos externos protejan a los internos.

Un artículo de C. Ellis y S. Gibbs distingue entre objetos activos y pasivos. [ 20 ] Los objetos pasivos comprenden información y comportamiento, como se indicó anteriormente, pero no pueden determinar el momento de dicho comportamiento. Los objetos activos, en cambio, sí pueden hacerlo. En su artículo, Ellis y Gibbs afirman que los objetos activos tienen mucho más potencial para el desarrollo de sistemas mantenibles que los objetos pasivos. Una aplicación FBP puede considerarse una combinación de estos dos tipos de objetos, donde los procesos FBP corresponderían a objetos activos, mientras que las IP corresponderían a objetos pasivos.

Actor y modelo

FBP considera al actor de Carl Hewitt como un proceso asíncrono con dos puertos: uno para mensajes de entrada y otro para señales de control. El propio actor emite una señal de control tras cada ciclo de ejecución. El propósito de esta señal es evitar la ejecución paralela del cuerpo del actor y, por lo tanto, permitir el acceso a los campos del objeto actor sin sincronización.

Véase también

Referencias

  1. ↑ "Programación basada en flujo" .
  2. ↑ Carriero, Nicholas; Gelernter, David (1989). "Linda en contexto" . Communications of the ACM . 32 (4): 444– 458. doi : 10.1145/63334.63337 . S2CID 5900105 . 
  3. ↑ Gelernter, David; Carriero, Nicholas (1992). "Lenguajes de coordinación y su significado". Communications of the ACM . 35 (2): 97– 107. doi : 10.1145/129630.129635 . S2CID 7748555 . 
  4. 1 2 Gabe Stein (agosto de 2013). "Cómo un método de codificación arcano del software bancario de la década de 1970 podría salvar la cordura de los desarrolladores web en todo el mundo" . Fast Company . Consultado el 24 de enero de 2016 .
  5. ↑ Conway, Melvin E. (1963). "Diseño de un compilador de diagramas de transición separable" . Communications of the ACM . 6 (7): 396– 408. doi : 10.1145/366663.366704 . S2CID 10559786 . 
  6. ↑ J. Paul Morrison, Sistema de programación de tareas modulares e intercaladas con respuesta a datos, Boletín de divulgación técnica de IBM, vol. 13, n.° 8, 2425-2426, enero de 1971
  7. ↑ Morrison, JP (1978). "Mecanismo de enlace de flujo de datos". IBM Systems Journal . 17 (4): 383– 408. doi : 10.1147/sj.174.0383 .
  8. ↑ Stevens, WP (1982). "Cómo el flujo de datos puede mejorar la productividad del desarrollo de aplicaciones". IBM Systems Journal . 21 (2): 162– 178. doi : 10.1147/sj.212.0162 .
  9. ↑ WP Stevens, Uso del flujo de datos para el desarrollo de aplicaciones , Byte, junio de 1985
  10. ↑ WP Stevens, Diseño de software: conceptos y métodos , Serie de ingeniería de software práctica, Ed. Allen Macro, Prentice Hall, 1990, ISBN 0-13-820242-7
  11. ↑ Johnston, Wesley M.; Hanna, JR Paul; Millar, Richard J. (2004). "Avances en lenguajes de programación de flujo de datos". ACM Computing Surveys . 36 (1): 1– 34. CiteSeerX 10.1.1.99.7265 . doi : 10.1145/1013208.1013209 . S2CID 5257722 .  
  12. ↑ DP Friedman y DS Wise, CONS no debería evaluar sus argumentos, Autómatas, lenguajes y programación, Edinburgh University Press, Edimburgo, 1976
  13. ↑ "El problema del telegrama de Peter Naur"" . Archivado del original el 06-09-2014 . Recuperado el 06-09-2014 .
  14. ↑ " Programación archivada el 5 de diciembre de 2021 en la Wayback Machine " por MA Jackson, publicado en Actas del Taller sobre Software en Física de Altas Energías, páginas 1-12 , CERN, Ginebra, 4-6 de octubre de 1982
  15. 1 2 " Un método de desarrollo de sistemas Archivado el 6 de febrero de 2012 en Wayback Machine " por MA Jackson, publicado en Herramientas y nociones para la construcción de programas: Un curso avanzado , Cambridge University Press, 1982
  16. ↑ " JSP en perspectiva" Archivado el 16/05/2017 en Wayback Machine " Michael Jackson; JSP en perspectiva; en Pioneros del software: Contribuciones a la ingeniería de software; Manfred Broy, Ernst Denert eds; Springer, 2002
  17. ↑ WB Ackerman, Lenguajes de flujo de datos , Actas de la Conferencia Nacional de Computación, págs. 1087-1095, 1979
  18. ↑ WH Burge, Técnicas de programación recursiva , Addison-Wesley, Reading, MA, 1975
  19. ↑ Parnas, DL (1972). "Sobre los criterios que deben utilizarse para descomponer sistemas en módulos" . Communications of the ACM . 15 (12): 1053– 1058. doi : 10.1145/361598.361623 . S2CID 53856438 . 
  20. ↑ C. Ellis y S. Gibbs, Objetos activos: realidades y posibilidades , en Conceptos, bases de datos y aplicaciones orientadas a objetos , eds. W. Kim y FH Lochovsky, ACM Press, Addison-Wesley, 1989
  • Razdow, Allen (diciembre de 1997). "Construyendo refinerías de datos empresariales" . DMReview . Archivado del original el 15 de marzo de 2005. Recuperado el 15 de julio de 2006 .
  • Mayer, Anthony; McGough, Stephen; Gulamali, Murtaza; Young, Laurie; Stanton, Jim; Newhouse, Steven; Darlington, John (2002). «Significado y comportamiento en componentes orientados a la cuadrícula» (PDF) . Centro de e-ciencia de Londres, Imperial College of Science, Technology and Medicine. Archivado del original (PDF) el 4 de febrero de 2012.
  • Black, Andrew P.; Huang, Jie; Koster, Rainer; Walpole, Jonathan; Pu, Calton (2002). "Infopipes: Una abstracción para la transmisión multimedia" (PDF) . Multimedia Systems . 8 (5). Springer-Verlag: 406– 419. doi : 10.1007/s005300200062 . S2CID 5700383. Recuperado el 10 de agosto de 2006 . 
  • Kra, David (octubre de 2004). "Servidores zSeries e iSeries en el dominio de la cuadrícula" . IBM DeveloperWorks . Recuperado el 13 de julio de 2006 .
  • Ludäscher, Bertram; Altintas, Ilkay; Berkley, Chad; et  al. (septiembre de 2004). "Gestión del flujo de trabajo científico y el sistema Kepler" (PDF) . Centro de supercomputación de San Diego . Recuperado el 14 de julio de 2006 .
  • Bickle, Jerry; Richardson, Kevin; Smith, Jeff (2005). "Descripción general de la especificación de radio por software OMG para robótica" (PDF) . Object Management Group - Comunicaciones basadas en software. Archivado del original (PDF) el 14 de julio de 2006. Recuperado el 15 de julio de 2006 .
  • Blažević, Mario (2006). "Streaming Component Combinators" . Actas de Extreme Markup Languages . Archivado del original el 18 de septiembre de 2007. Consultado el 9 de noviembre de 2006 .
  • Kauler, Barry (1999). Diseño de flujo para sistemas embebidos, 2.ª edición . R&D Books/Miller Freeman. ISBN 978-0-87930-555-0.
  • Patente estadounidense 5204965 , Guthery, Scott B.; Barth, Paul S. y Barstow, David R., "Sistema de procesamiento de datos mediante almacenamiento de flujo", emitida el 20 de abril de 1993, asignada a Schlumberger Technology Corporation. 
  • Morrison, J. Paul (marzo de 2013). "Programación basada en flujo" . Noticias para desarrolladores de aplicaciones (1). Archivado del original el 8 de agosto de 2014. Recuperado el 25 de mayo de 2014 .
  • Staplin, George Peter (2006). "Programación basada en flujo Tcl - TFP" . Recuperado el 7 de octubre de 2010 .
  • Johnston, Wesley M.; Hanna, JR Paul; Millar, Richard J. (marzo de 2004). "Avances en lenguajes de programación de flujo de datos". ACM Computing Surveys . 36 (1): 1– 34. doi : 10.1145/1013208.1013209 . S2CID 5257722 . 
  • Koster, Rainer; Black, Andrew P.; Huang, Jie; Walpole, Jonathan; Pu, Calton (abril de 2003). "Transparencia de hilos en middleware de flujo de información" . Software: Practice and Experience . 33 (4): 321– 349. CiteSeerX 10.1.1.15.3933 . doi : 10.1002/spe.510 . S2CID 37356020. Recuperado el 5 de diciembre de 2006 .  
  • Stevenson, Tony (febrero de 1995). "Reseña de "Programación basada en flujo"" . PC Update, la revista del Grupo de Usuarios de PC de Melbourne, Australia. Archivado del original el 25-09-2006 . Recuperado el 06-12-2006 .
  • Lea, Doug (mayo de 2001). "Componiendo mensajes unidireccionales" . Archivado del original el 7 de septiembre de 2006. Recuperado el 6 de diciembre de 2006 .
  • Bowers, Shawn; Ludäscher, B.; Ngu, AHH ; Critchlow, T. "Habilitación de la reutilización de flujos de trabajo científicos mediante la composición estructurada de flujos de datos y de control" (PDF) . SciFlow '06. Archivado del original (PDF) el 5 de febrero de 2007. Consultado el 6 de diciembre de 2006 .
  • Sorber, Jacob; Kostadinov, Alexander; Garber, Matthew; Brennan, Matthew; Corner, Mark D.; Berger, Emery D. (2007). "Eon". Eon: un lenguaje y sistema de ejecución para sistemas perpetuos . Actas de la 5.ª conferencia internacional sobre sistemas de sensores en red integrados - Sesión: Gestión de energía. pág.  161. doi : 10.1145/1322263.1322279 . ISBN 978-1-59593-763-6. S2CID 12851752 . 
  • Fiedler, Lars; Dasey, Timothy (2014). "Sistemas y métodos para análisis componibles" . Servicio Nacional de Información Técnica. Archivado del original el 26 de agosto de 2014. Recuperado el 1 de abril de 2014 .
  • Matt, Carkci (2014). Sistemas de flujo de datos y programación reactiva: una guía práctica . CreateSpace Independent Publishing Platform. ISBN 978-1-4974-2244-5.
  • Lampa, Samuel; Dahlö, Martin; Alvarsson, Jonathan; Spjuth, Ola (2019). "SciPipe: Una biblioteca de flujo de trabajo para el desarrollo ágil de pipelines bioinformáticos complejos y dinámicos" . GigaScience . 8 (5). bioRxiv 10.1101/380808 . doi : 10.1093/gigascience/giz044 . PMC 6486472 .