En programación informática , la programación basada en flujo ( FBP ) es un paradigma de programación 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 las conexiones se especifican externamente a los procesos. Estos procesos de caja negra se pueden volver a conectar infinitamente para formar diferentes aplicaciones sin tener que cambiarlos internamente. Por tanto, FBP está naturalmente orientado 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 una definición separada de conexiones.
Introducción
La programación basada en flujo define aplicaciones utilizando la metáfora de una "fábrica de datos". Considera una aplicación no como un proceso secuencial único, que comienza en un momento determinado y luego hace una cosa a la vez hasta que finaliza, sino como una red de procesos asincrónicos que se comunican mediante flujos de fragmentos de datos estructurados. llamados "paquetes de información" (IP). En esta vista, la atención 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 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 código. En cualquier momento, una IP determinada solo puede ser "propiedad" de un único proceso, o estar en tránsito entre dos procesos. Los puertos pueden ser simples o de tipo arreglo, como se usa, por ejemplo, para el puerto de entrada del componente Collate que se describe a continuación. Es la combinación de puertos con procesos asíncronos lo que permite que muchas funciones primitivas de procesamiento de datos de larga ejecución, como Ordenar, Combinar, Resumir, etc., sean compatibles en forma de cajas negras de software .
Debido a que los procesos FBP pueden continuar ejecutándose mientras tengan datos en los que trabajar y en algún lugar para poner su salida, las aplicaciones FBP generalmente se ejecutan en menos tiempo que los programas convencionales y hacen un uso óptimo de todos los procesadores en una máquina, sin necesidad de programación especial. lograr esto. [1]
La definición de red suele ser esquemática y se convierte en una lista de conexiones en algún lenguaje o notación de nivel inferior. FBP es a menudo un lenguaje de programación visual en este nivel. Las definiciones de red más complejas tienen una estructura jerárquica, y se construyen a partir de subredes con conexiones "pegajosas". Muchos otros lenguajes / tiempos de ejecución basados en flujo se construyen alrededor de lenguajes de programación más tradicionales, el ejemplo más notable [ cita requerida ] es RaftLib, que usa operadores C ++ tipo iostream para especificar el gráfico de flujo.
FBP tiene mucho en común con el lenguaje Linda [2] en que es, en la terminología de Gelernter y Carriero, 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 enlazarse en una sola red. Por lo tanto, FBP se presta al concepto de lenguajes específicos de dominio o "mini-lenguajes".
FBP exhibe "acoplamiento de datos", descrito en el artículo sobre acoplamiento como el tipo de acoplamiento más flexible entre componentes. El concepto de acoplamiento flexible está a su vez relacionado con el de las arquitecturas orientadas a servicios , y FBP se ajusta a varios de los criterios para dicha arquitectura, aunque a un nivel más detallado que la mayoría de los ejemplos de esta arquitectura.
FBP promueve un estilo funcional de alto nivel de especificaciones que simplifican el razonamiento sobre el comportamiento del sistema. Un ejemplo de esto es el modelo de flujo de datos distribuidos para especificar y analizar de manera constructiva la semántica de protocolos multipartitos distribuidos.
Historia
La programación basada en flujo fue inventada por J. Paul Morrison a principios de la década de 1970 e inicialmente se implementó en software para un banco canadiense. [4] FBP en sus inicios estuvo fuertemente influenciado por algunos lenguajes de simulación de IBM de la época, en particular GPSS , pero sus raíces se remontan al artículo seminal de Conway sobre lo que él llamó corutinas . [5]
FBP ha sufrido una serie de cambios de nombre a lo largo de los años: la implementación original se llamó AMPS (Sistema de procesamiento modular avanzado). Una gran aplicación en Canadá se puso en marcha en 1975 y, a partir de 2013, ha estado en uso continuo de producción, funcionando a diario, durante casi 40 años. Debido a que IBM consideró que las ideas detrás de FBP "se parecían demasiado a una ley de la naturaleza" para ser patentables, en su lugar pusieron los conceptos básicos de FBP en el dominio público, por medio de un Technical Disclosure Bulletin , "Data Responsive Modular, Interleaved Task Programming System". , [6] en 1971. [4] Un artículo que describe sus conceptos y experiencia al usarlo fue publicado en 1978 en IBM Research IBM Systems Journal bajo el nombre DSLM. [7] Se realizó una segunda implementación 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 años 80 con el nombre "Data Flow Programming Gerente".
Por lo general, los conceptos se denominaban en IBM "Flujo de datos", pero se consideró que este término era demasiado general y, finalmente, se adoptó el nombre "Programación basada en flujo".
Desde principios de los 80 hasta 1993, J. Paul Morrison y el arquitecto de IBM Wayne Stevens refinaron y promovieron los conceptos detrás de FBP. Stevens escribió varios artículos describiendo y apoyando el concepto de FBP e incluyó material al respecto en varios de sus libros. [8] [9] [se necesita fuente no primaria ] [10] [se necesita fuente no primaria ] . En 1994, Morrison publicó un libro que describe FBP y proporciona evidencia empírica de que FBP condujo a tiempos de desarrollo reducidos. [11]
Conceptos
El siguiente diagrama muestra las entidades principales de un diagrama FBP (además de los paquetes de información). Dicho diagrama se puede convertir directamente en una lista de conexiones, que luego se puede ejecutar mediante un motor apropiado (software o hardware).
A, B y C son procesos que ejecutan componentes de código. O1, O2 y las dos IN 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. Ya sea que compartan código o no, B y C son libres de usar el mismo puerto. nombres, ya que los nombres de los puertos solo tienen significado dentro de los componentes que hacen referencia a ellos (y a nivel de red, por supuesto).
M y N son lo que a menudo se denominan " búferes limitados " y tienen una capacidad fija en términos de la cantidad de IP que pueden contener en cualquier momento.
El concepto de puertos es lo que permite utilizar el mismo componente en más de un lugar de la red. En combinación con una capacidad de parametrización, denominada Paquetes de información inicial (IIP), los puertos proporcionan a FBP una capacidad de reutilización de componentes, lo que convierte a FBP en una arquitectura basada en componentes . Así, 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 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 FBP esto debe ser una acción explícita por parte de un proceso de propiedad. Las direcciones 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 asincrónica; este concepto tiene similitudes con el concepto de contras vagos descrito en el artículo de 1976 de Friedman y Wise. [12]
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 son las "IP entre paréntesis", que se pueden utilizar para agrupar las IP de datos en patrones secuenciales dentro de una secuencia, denominados "subflujos". Los subflujos, a su vez, pueden estar anidados. 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 se puede "ramificar" a cualquier tamaño. Durante el desarrollo de una aplicación, los procesos de monitoreo pueden agregarse entre pares de procesos, los procesos pueden "expandirse" a subredes, o las simulaciones de procesos pueden ser reemplazadas por la lógica del proceso real. Por lo tanto, FBP se presta a la creación rápida de prototipos .
Esta es realmente una imagen de línea de montaje del procesamiento de datos: las IP que viajan a través de una red de procesos pueden considerarse como dispositivos que viajan de una estación a otra en una línea de montaje. Las "máquinas" pueden reconectarse fácilmente, desconectarse para su reparación, reemplazarse, etc. Curiosamente, esta imagen es muy similar a la del equipo de grabación de unidades que se usaba para procesar datos antes de los días de las computadoras, excepto que los mazos de cartas tenían que llevarse a mano de una máquina a otra.
Las implementaciones de FBP pueden ser no preventivas o preventivas: las implementaciones anteriores tendían a no ser preventivas (mainframe y lenguaje C), mientras que la última implementación de Java (ver más abajo) usa la clase Java Thread y es preventiva.
Ejemplos de
"Problema de Telegram"
Los componentes de FBP a menudo forman pares complementarios. Este ejemplo utiliza dos de esos pares. El problema descrito parece muy simple como se describe en palabras, pero de hecho es sorprendentemente difícil de lograr usando la lógica de procedimiento convencional. La tarea, denominada "Problema de Telegram", originalmente descrita por Peter Naur , es escribir un programa que acepte líneas de texto y genere líneas de salida que contengan tantas palabras como sea posible, donde el número de caracteres en cada línea no exceda un cierto largo. Las palabras no se pueden dividir 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 palabras en los editores de texto. [13]
En la lógica convencional, el programador descubre rápidamente que ni las estructuras de entrada ni de salida pueden utilizarse para impulsar la jerarquía de llamadas del flujo de control . En FBP, por otro lado, la descripción del problema en sí 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 (IP).
- en FBP no hay una jerarquía de llamadas única, por lo que el programador no se ve tentado a forzar un subpatrón de la solución para que sea el nivel superior.
Aquí está la solución más natural en FBP (no existe una única solución "correcta" en FBP, pero esto parece un ajuste natural):
donde DC y RC significan "DeCompose" y "ReCompose", respectivamente.
Como se mencionó anteriormente, los paquetes de información inicial (IIP) se pueden usar para especificar información paramétrica, como la longitud de registro de salida deseada (requerida por los dos componentes más a la derecha) o nombres de archivo. Los IIP son fragmentos de datos asociados con un puerto en la definición de red que se convierten en IP "normales" cuando se emite una "recepción" para el puerto correspondiente.
Actualización por lotes
Este tipo de programa implica pasar un archivo de "detalles" (cambios, adiciones y eliminaciones) contra un "archivo maestro" y producir (al menos) un archivo maestro actualizado y uno o más informes. Los programas de actualización son generalmente bastante difíciles de codificar usando código de procedimiento síncrono, ya que dos (a veces más) flujos de entrada deben mantenerse sincronizados, aunque puede haber maestros sin los detalles correspondientes, o viceversa.
En FBP, un componente reutilizable (Collate), basado en la idea de registro de unidad de un Collator, hace que escribir este tipo de aplicación sea mucho más fácil ya que Collate fusiona los dos flujos e inserta IPs de corchetes para indicar niveles de agrupación, simplificando significativamente la lógica descendente. Supongamos que una secuencia ("maestros" en este caso) consta de IP con valores clave de 1, 2 y 3, y que las direcciones IP de la segunda secuencia ("detalles") tienen valores clave de 11, 12, 21, 31, 32, 33 y 41, donde el primer dígito corresponde a los valores de la clave maestra. Usando caracteres de corchetes para representar IPs "corchetes", la secuencia de salida clasificada será la 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 de la secuencia anterior se puede describir sucintamente usando una notación similar a BNF como
{([m] d *)} *
Collate es una caja negra reutilizable que solo necesita saber dónde están los campos de control en sus IP entrantes (incluso esto no es estrictamente necesario, ya que los procesos del transformador se pueden insertar en sentido ascendente para colocar los campos de control en ubicaciones estándar) y, de hecho, se puede generalizar. a cualquier número de flujos de entrada y cualquier profundidad 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 flujo admite la multiplexación de procesos de una manera muy natural. Dado que los componentes son de solo lectura, cualquier número de instancias de un componente determinado ("procesos") puede ejecutarse de forma asincrónica entre sí.
Cuando las computadoras generalmente tenían un solo procesador, esto resultaba útil cuando se realizaba una gran cantidad de E / S; Ahora que las máquinas suelen tener varios procesadores, esto comienza a ser útil cuando los procesos también requieren un uso intensivo de la CPU. El diagrama de esta sección muestra un solo proceso "Load Balancer" que distribuye datos entre 3 procesos, etiquetados como S1, S2 y S3, respectivamente, que son instancias de un solo componente, que a su vez se alimentan en un solo proceso en un "orden de llegada , primero servido "base.
Red interactiva simple
En este esquema general, las solicitudes (transacciones) que provienen de los usuarios ingresan al diagrama en la parte superior izquierda y las respuestas se devuelven en la parte inferior izquierda. Los "backends" (en el lado derecho) se comunican con sistemas en otros sitios, por ejemplo, utilizando CORBA , MQSeries , etc. Las conexiones cruzadas representan solicitudes que no necesitan ir a los backends, o solicitudes que tienen que pasar por la red más de una vez antes de ser devuelta al usuario.
Como diferentes solicitudes pueden usar diferentes back-end y pueden requerir diferentes cantidades de tiempo para que los back-end (si se usan) los procesen, se deben tomar las disposiciones necesarias para relacionar los datos devueltos con las transacciones de solicitud apropiadas, por ejemplo, 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: los procesos se pueden insertar entre otros procesos para administrar cachés, mostrar el tráfico de conexión, monitorear el rendimiento, etc. También los bloques en el diagrama pueden representar "subredes" - pequeñas redes con una o más conexiones abiertas.
Comparación con otros paradigmas y metodologías
Programación estructurada Jackson (JSP) y desarrollo de sistemas Jackson (JSD)
Esta metodología asume 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. Luego se elige una de estas "líneas principales" para manejar todo el programa, y se requiere que las otras se "inviertan" para convertirlas en subrutinas (de ahí el nombre "Inversión de Jackson"). Esto a veces resulta en lo que se llama un "choque", que requiere que el programa se divida en múltiples programas o corrutinas. Cuando se usa FBP, este proceso de inversión no es necesario, ya que cada componente de FBP puede considerarse una "línea principal" separada.
FBP y JSP comparten el concepto de tratar un programa (o algunos componentes) como un analizador 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 final de implementación. Luego, el modelo se transforma 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 que existe antes de este paso, en la sección 1.3 de su libro (cursiva agregada):
- La especificación producida al final del paso de sincronización del sistema es, en principio, capaz 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 está conectado al mundo real. Por supuesto, un entorno de este tipo podría proporcionarse mediante un software adecuado que se ejecute en una máquina suficientemente potente. A veces, dicha ejecución directa de la especificación será posible e incluso puede 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. Luego, estas funciones se combinan para realizar transformaciones más complejas, como se muestra aquí:
Si etiquetamos los flujos, como se muestra, con letras minúsculas, entonces el diagrama anterior se puede representar sucintamente de la siguiente manera:
c = G (F (a), F (b));
Al igual que en la notación funcional F se puede usar dos veces porque solo funciona con valores y, por lo tanto, no tiene efectos secundarios, en FBP dos instancias de un componente dado pueden ejecutarse simultáneamente entre sí y, por lo tanto, los componentes de FBP no deben tener efectos secundarios. ya sea. La notación funcional claramente podría usarse para representar al menos una parte de una red FBP.
Entonces surge la pregunta de si los componentes FBP pueden expresarse ellos mismos usando notación funcional. WH Burge mostró cómo se pueden desarrollar expresiones de flujo usando un estilo de programación recursivo y aplicativo, pero este trabajo fue en términos de (flujos de) valores atómicos. [18] En FBP, es necesario poder describir y procesar fragmentos de datos estructurados (FBP IP).
Además, la mayoría de los sistemas aplicativos asumen que todos los datos están disponibles en la memoria al mismo tiempo, mientras que las aplicaciones FBP deben poder procesar flujos de datos de larga duración mientras siguen utilizando recursos finitos. Friedman y Wise sugirieron una forma de hacer esto agregando el concepto de "contras vagos" al trabajo de Burge. Esto eliminó el requisito de que ambos argumentos de "contras" estén disponibles al mismo tiempo. Los "contras perezosos" en realidad no construyen un flujo hasta que se realizan sus dos argumentos; antes de eso, simplemente registra una "promesa" para hacer esto. Esto permite que una secuencia se realice dinámicamente desde el frente, pero con un back-end no realizado. El final de la secuencia permanece sin darse cuenta hasta el final del proceso, mientras que el comienzo es una secuencia de elementos cada vez más larga.
linda
Muchos de los conceptos de FBP parecen haberse descubierto de forma independiente en diferentes sistemas a lo largo de los años. Linda, mencionada anteriormente, es una de ellas. La diferencia entre las dos técnicas se ilustra con la técnica de equilibrio de carga de la "escuela de pirañas" de Linda: en FBP, esto requiere un componente "equilibrador de carga" adicional que enruta las solicitudes al componente en una lista que tiene la menor cantidad de direcciones IP en espera estar procesado. Claramente, FBP y Linda están estrechamente relacionados, y uno podría usarse fácilmente para simular al otro.
Programación orientada a objetos
Un objeto en OOP 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. Solo se puede acceder a los datos internos del objeto mediante llamadas a métodos, por lo que esta es una forma de ocultación o "encapsulación" de información. La encapsulación, sin embargo, es anterior a la programación orientada a objetos ( David Parnas escribió uno de los artículos fundamentales sobre ella 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 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, solo el proceso de propiedad actual puede acceder directamente a los datos de una IP. La encapsulación también se puede implementar a nivel de red, haciendo que los procesos externos protejan los internos.
Un artículo de C. Ellis y S. Gibbs distingue entre objetos activos y objetos pasivos. [20] Los objetos pasivos comprenden información y comportamiento, como se indicó anteriormente, pero no pueden determinar el momento de este comportamiento. Los objetos activos, por otro lado, pueden hacer esto. 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 verse como una combinación de estos dos tipos de objeto, donde los procesos FBP corresponderían a objetos activos, mientras que las IP corresponderían a objetos pasivos.
Modelo de actor
FBP considera al Actor de Carl Hewitt como un proceso asíncrono con 2 puertos: uno para mensajes de entrada y otro para señales de control. El propio actor emite una señal de control después de cada ronda de ejecución. El propósito de esta señal es evitar la ejecución paralela del cuerpo del actor y así permitir el acceso a los campos del objeto actor sin sincronización.
Ver también
- Objetos activos
- Modelo de actor
- Apache NiFi
- BMDFM
- Comunicación de procesos secuenciales (CSP)
- Computación concurrente
- Flujo de datos
- Diagrama de flujo de datos
- Programación de flujo de datos
- FUP - Diagramas de bloques de funciones (un lenguaje de programación en el estándar IEC 61131)
- Programación funcional reactiva
- Linda (lenguaje de coordinación)
- Plataformas de desarrollo de bajo código
- Mapa reducido
- Nodo-RED
- Programación de canalizaciones
- Estudio VRL [1]
- Wayne Stevens
- XProc
- Yahoo Pipes
Referencias
- ^ "Programación basada en flujo" .
- ^ Carriero, Nicolás; Gelernter, David (1989). "Linda en contexto". Comunicaciones de la ACM . 32 (4): 444–458. doi : 10.1145 / 63334.63337 .
- ^ Gelernter, David; Carriero, Nicolás (1992). "Idiomas de coordinación y su significado". Comunicaciones de la ACM . 35 (2): 97–107. doi : 10.1145 / 129630.129635 .
- ^ a b 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 todas partes" . Consultado el 24 de enero de 2016 .
- ^ Conway, Melvin E. (1963). "Diseño de un compilador de diagrama de transición separable". Comunicaciones de la ACM . 6 (7): 396–408. doi : 10.1145 / 366663.366704 .
- ^ J. Paul Morrison, Sistema de programación de tareas intercaladas, modular sensible a datos, Boletín de divulgación técnica de IBM, vol. 13, No. 8, 2425-2426, enero de 1971
- ^ Morrison, JP (1978). "Mecanismo de enlace de flujo de datos". Revista de sistemas de IBM . 17 (4): 383–408. doi : 10.1147 / sj.174.0383 .
- ^ Stevens, WP (1982). "Cómo el flujo de datos puede mejorar la productividad del desarrollo de aplicaciones". Revista de sistemas de IBM . 21 (2): 162-178. doi : 10.1147 / sj.212.0162 .
- ^ WP Stevens, Uso de flujo de datos para el desarrollo de aplicaciones , Byte, junio de 1985
- ^ WP Stevens, Diseño de software - Conceptos y métodos , Serie práctica de ingeniería de software, Ed. Allen Macro, Prentice Hall, 1990, ISBN 0-13-820242-7
- ^ Johnston, Wesley M .; Hanna, JR Paul; Millar, Richard J. (2004). "Avances en lenguajes de programación de flujo de datos". Encuestas de computación ACM . 36 (1): 1–34. CiteSeerX 10.1.1.99.7265 . doi : 10.1145 / 1013208.1013209 .
- ^ DP Friedman y DS Wise, CONS no debería evaluar sus argumentos, Autómatas, lenguajes y programación, Edinburgh University Press, Edimburgo, 1976
- ^ "Copia archivada" . Archivado desde el original el 6 de septiembre de 2014 . Consultado el 6 de septiembre de 2014 .Mantenimiento de CS1: copia archivada como título ( enlace )
- ^ " Programación " por MA Jackson, publicado en Proceedings of Workshop on Software in High-Energy Physics, páginas 1-12 , CERN, Ginebra, 4-6 de octubre de 1982
- ^ a b " Un método de desarrollo de sistemas Archivado el 6 de febrero de 2012 en la Wayback Machine " por MA Jackson, publicado en Herramientas y nociones para la construcción de programas: un curso avanzado , Cambridge University Press, 1982
- ^ " JSP en perspectiva " Michael Jackson; JSP en perspectiva; en Software Pioneers: Contribuciones a la Ingeniería de Software; Manfred Broy, Ernst Denert eds; Springer, 2002
- ^ WB Ackerman, Lenguajes de flujo de datos , Actas de la Conferencia Nacional de Computación, págs. 1087-1095, 1979
- ^ WH Burge, Técnicas de programación recursiva , Addison-Wesley, Reading, MA, 1975
- ^ Parnas, DL (1972). "Sobre los criterios a utilizar en la descomposición de sistemas en módulos". Comunicaciones de la ACM . 15 (12): 1053-1058. doi : 10.1145 / 361598.361623 .
- ^ C. Ellis y S. Gibbs, Objetos activos: realidades y posibilidades , en Conceptos, bases de datos y aplicaciones orientados a objetos , eds. W. Kim y FH Lochovsky, ACM Press, Addison-Wesley, 1989
enlaces externos
- Razdow, Allen (diciembre de 1997). "Construcción de refinerías de datos empresariales" . DMReview . Consultado 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) . London e-Science Centre, Imperial College of Science, Technology and Medicine. Archivado desde el 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) . Sistemas multimedia . Springer-Verlag. 8 (5): 406–419. doi : 10.1007 / s005300200062 . Consultado el 10 de agosto de 2006 .
- Kra, David (octubre de 2004). "Servidores zSeries e iSeries en el dominio grid" . IBM DeveloperWorks . Consultado 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 . Consultado el 14 de julio de 2006 .
- Bickle, Jerry; Richardson, Kevin; Smith, Jeff (2005). "Descripción general de la especificación de radio del software OMG para robótica" (PDF) . Grupo de gestión de objetos: comunicaciones basadas en software. Archivado desde el original (PDF) el 14 de julio de 2006 . Consultado el 15 de julio de 2006 .
- Blažević, Mario (2006). "Combinadores de componentes de transmisión" . Actas de Extreme Markup Languages . Archivado desde el original el 18 de septiembre de 2007 . Consultado el 9 de noviembre de 2006 .
- Kauler, Barry (1999). Diseño de flujo para sistemas integrados, 2da edición . Libros de I + D / Miller Freeman. ISBN 978-0-87930-555-0.
- Patente de EE.UU. 5204965 , Guthery, Scott B .; Barth, Paul S. & Barstow, David R., "Sistema de procesamiento de datos que usa almacenes de flujo", emitido el 20 de abril de 1993, asignado a Schlumberger Technology Corporation
- Morrison, J. Paul (marzo de 2013). "Programación basada en flujo" . Noticias de desarrolladores de aplicaciones (1) . Consultado el 25 de mayo de 2014 .
- Staplin, George Peter (2006). "Programación basada en flujo de Tcl - TFP" . Consultado 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". Encuestas de computación ACM . 36 (1): 1–34. doi : 10.1145 / 1013208.1013209 .
- Koster, Rainer; Black, Andrew P .; Huang, Jie; Walpole, Jonathan; Pu, Calton (abril de 2003). "Transparencia de hilo en middleware de flujo de información" . Software: práctica y experiencia . 33 (4): 321–349. CiteSeerX 10.1.1.15.3933 . doi : 10.1002 / spe.510 . Consultado el 5 de diciembre de 2006 .
- Stevenson, Tony (febrero de 1995). "Revisión de la" Programación basada en flujo " " . PC Update, la revista de Melbourne PC User Group, Australia. Archivado desde el original el 25 de septiembre de 2006 . Consultado el 6 de diciembre de 2006 .
- Lea, Doug (mayo de 2001). "Redacción de mensajes unidireccionales" . Consultado el 6 de diciembre de 2006 .
- Bowers, Shawn; Ludäscher, B .; Ngu, AHH; Critchlow, T. "Habilitación de la reutilización del flujo de trabajo científico a través de la composición estructurada del flujo de datos y el flujo de control" (PDF) . SciFlow '06. Archivado desde el original (PDF) el 2007-02-05 . Consultado el 6 de diciembre de 2006 .
- Sorber, Jacob; Kostadinov, Alexander; Garber, Matthew; Brennan, Matthew; Esquina, Mark D .; Berger, Emery D. (2007). "Eón". Eon: un sistema de lenguaje y tiempo de ejecución para sistemas perpetuos . Actas de la 5ª conferencia internacional sobre sistemas de sensores integrados en red - Sesión: Gestión de energía. pag. 161. doi : 10.1145 / 1322263.1322279 . ISBN 9781595937636.
- Fiedler, Lars; Dasey, Timothy (2014). "Sistemas y métodos de analítica componible" . Servicio Nacional de Información Técnica . Consultado el 1 de abril de 2014 .
- Matt, Carkci (2014). Flujo de datos y sistemas de programación reactiva: una guía práctica . Plataforma de publicación independiente CreateSpace. ISBN 978-1497422445.
- Lampa, Samuel; Dahlö, Martin; Alvarsson, Jonathan; Spjuth, Ola (2018). "SciPipe - Una biblioteca de flujo de trabajo para el desarrollo ágil de pipelines bioinformáticos complejos y dinámicos" . bioRxiv : 380808. doi : 10.1101 / 380808 . Consultado el 2 de agosto de 2018 .