Flowbaseret programmering - Flow-based programming

Programmeringsparadigmer
Handling Agentorienteret Array-orienteret Automatisk-baseret Samtidig computing Relativistisk programmering Datadrevet Deklarativ (kontrast: Imperativ ) Funktionel Funktionel logik Rent funktionelt Logik Abduktiv logik Svar sæt Samtidig logik Funktionel logik Induktiv logik Begrænsning Begrænsningslogik Samtidig begrænsningslogik Dataflow Flowbaseret Reaktiv Funktionel reaktiv Ontologi Differentierbar Dynamisk/scripting Hændelsesdrevet Funktionsniveau (kontrast: Værdiniveau ) Punktfri stil Sammenhængende Generisk Imperativ (kontrast: Deklarativ ) Proceduremæssig Objektorienteret Polymorf Forsætlig Sprogorienteret Domænespecifik Læse Natursproget programmering Metaprogrammering Automatisk Induktiv programmering Reflekterende Attribut-orienteret Makro Skabelon Ikke-struktureret (kontrast: Struktureret ) Array Ikke -bestemmende Parallel computing Procesorienteret Sandsynlighed Quantum Set-teoretisk Stack-baseret Struktureret (kontrast: Ikke-struktureret ) Blokstruktureret Struktureret samtidighed Objektorienteret Skuespillerbaseret Klassebaseret Samtidig Prototype-baseret Ved adskillelse af bekymringer : Aspektorienteret Rolleorienteret Fagorienteret Rekursiv Symbolsk Værdiniveau (kontrast: funktionsniveau )
v t e

I computerprogrammering , flow-baseret programmering ( FBP ) er en programmeringsparadigme at definerer anvendelser som netværk af "black box" fremgangsmåder , som udveksle data på tværs foruddefinerede forbindelser ved besked passerer , hvor tilslutningerne er specificeret eksternt til processerne. Disse black box -processer kan forbindes uendeligt igen for at danne forskellige applikationer uden at skulle ændres internt. FBP er således naturligt komponentorienteret .

FBP er en særlig form for dataflow -programmering baseret på afgrænsede buffere, informationspakker med definerede levetider, navngivne porte og separat definition af forbindelser.

Introduktion

Flowbaseret programmering definerer applikationer ved hjælp af metaforen fra en "datafabrik". Den ser en applikation ikke som en enkelt, sekventiel proces, der starter på et tidspunkt, og derefter gør en ting ad gangen, indtil den er færdig, men som et netværk af asynkrone processer, der kommunikerer ved hjælp af strømme af strukturerede datastumper, kaldet "informationspakker" (IP'er). I denne opfattelse er fokus på applikationsdataene og de transformationer, der er anvendt på det for at producere de ønskede output. Netværket er defineret eksternt i processerne som en liste over forbindelser, der tolkes af et stykke software, normalt kaldet "planlæggeren".

Processerne kommunikerer ved hjælp af forbindelser med fast kapacitet. En forbindelse er knyttet til en proces ved hjælp af en port , som har et navn, der er aftalt mellem proceskoden og netværksdefinitionen. Mere end én proces kan udføre det samme stykke kode. På et hvilket som helst tidspunkt kan en given IP kun "ejes" af en enkelt proces eller være i transit mellem to processer. Porte kan enten være simple eller array-type, som de bruges f.eks. Til inputporten til Collate-komponenten beskrevet nedenfor. Det er kombinationen af ​​porte med asynkrone processer, der gør det muligt at understøtte mange langvarige primitive funktioner i databehandling, såsom Sort, Merge, Summarize osv., I form af software sorte bokse .

Fordi FBP -processer kan fortsætte med at eksekvere, så længe de har data at arbejde med og et sted at sætte deres output, kører FBP -applikationer generelt på mindre forløbet tid end konventionelle programmer og udnytter alle processorer på en maskine optimalt uden særlig programmering for at opnå dette.

Netværksdefinitionen er normalt diagrammatisk og konverteres til en forbindelsesliste i et sprog eller notation på et lavere niveau. FBP er ofte et visuelt programmeringssprog på dette niveau. Mere komplekse netværksdefinitioner har en hierarkisk struktur, der bygges op fra undernet med "klæbrige" forbindelser. Mange andre flowbaserede sprog/runtimes er bygget op omkring mere traditionelle programmeringssprog, det mest bemærkelsesværdige eksempel er RaftLib, der bruger C ++ iostream-lignende operatører til at specificere flowgrafen.

FBP har meget tilfælles med Linda- sproget, idet det i Gelernter og Carrieros terminologi er et "koordineringssprog": det er i det væsentlige sproguafhængigt. I betragtning af en planlægger, der er skrevet på et tilstrækkeligt lavt niveau, kan komponenter, der er skrevet på forskellige sprog, kædes sammen i et enkelt netværk. FBP egner sig således til begrebet domænespecifikke sprog eller "minisprog".

FBP udviser "datakobling", beskrevet i artiklen om kobling som den løseste type kobling mellem komponenter. Begrebet løs kobling er igen relateret til begrebet serviceorienterede arkitekturer , og FBP passer til en række af kriterierne for en sådan arkitektur, omend på et mere finkornet niveau end de fleste eksempler på denne arkitektur.

FBP fremmer højt niveau, funktionel stil af specifikationer, der forenkler ræsonnement om systemadfærd. Et eksempel på dette er den distribuerede dataflowmodel til konstruktiv specificering og analyse af semantikken i distribuerede flerpartsprotokoller.

Historie

Flow-Based Programming blev opfundet af J. Paul Morrison i begyndelsen af ​​1970'erne og blev oprindeligt implementeret i software til en canadisk bank. FBP blev ved starten stærkt påvirket af nogle IBM -simuleringssprog i perioden, især GPSS , men dens rødder går helt tilbage til Conways sædvanlige papir om det, han kaldte coroutines .

FBP har gennemgået en række navneændringer gennem årene: den oprindelige implementering blev kaldt AMPS (Advanced Modular Processing System). Én stor applikation i Canada blev lanceret i 1975, og har fra 2013 været i kontinuerlig produktionsbrug, der kører dagligt i næsten 40 år. Fordi IBM anså ideerne bag FBP "for meget som en naturlov" for at være patenterbare, satte de i stedet FBP's grundlæggende begreber i det offentlige område ved hjælp af en Technical Disclosure Bulletin , "Data Responsive Modular, Interleaved Task Programming System" , i 1971. En artikel, der beskriver dets begreber og erfaring med at bruge den, blev offentliggjort i 1978 i IBM Research IBM Systems Journal under navnet DSLM. En anden implementering blev udført som et fælles projekt mellem IBM Canada og IBM Japan under navnet "Data Flow Development Manager" (DFDM), og blev kortvarigt markedsført i Japan i slutningen af ​​80'erne under navnet "Data Flow Programming Manager".

Generelt blev begreberne i IBM omtalt som "Data Flow", men dette udtryk føltes at være for generelt, og til sidst blev navnet "Flow-Based Programming" vedtaget.

Fra begyndelsen af ​​80'erne til 1993 forfinede og promoverede J. Paul Morrison og IBM -arkitekten Wayne Stevens koncepterne bag FBP. Stevens skrev flere artikler, der beskriver og understøtter FBP -konceptet, og inkluderede materiale om det i flere af hans bøger. I 1994 udgav Morrison en bog, der beskriver FBP, og leverede empirisk bevis for, at FBP førte til reducerede udviklingstider.

Begreber

Det følgende diagram viser de vigtigste enheder i et FBP -diagram (bortset fra informationspakkerne). Et sådant diagram kan konverteres direkte til en liste over forbindelser, som derefter kan udføres af en passende motor (software eller hardware).

A, B og C er processer, der udfører kodekomponenter. O1, O2 og de to IN'er er porte, der forbinder forbindelserne M og N med deres respektive processer. Det er tilladt for processer B og C at udføre den samme kode, så hver proces skal have sit eget sæt arbejdslager, kontrolblokke osv. Uanset om de deler kode eller ej, kan B og C frit bruge den samme port navne, da portnavne kun har betydning inden for de komponenter, der refererer til dem (og selvfølgelig på netværksniveau).

M og N er det, der ofte omtales som " afgrænsede buffere ", og har en fast kapacitet med hensyn til antallet af IP'er, som de kan holde til enhver tid.

Begrebet porte er det, der gør det muligt at bruge den samme komponent mere end ét sted i netværket. I kombination med en parametreringsevne, kaldet Initial Information Packets (IIP'er), giver havne FBP mulighed for genanvendelse af komponenter, hvilket gør FBP til en komponentbaseret arkitektur. FBP viser således, hvad Raoul de Campo og Nate Edwards fra IBM Research har betegnet konfigurerbar modularitet .

Informationspakker eller IP'er tildeles i det, der kan kaldes "IP -rum" (ligesom Lindas tupler er tildelt i "dobbeltrum"), og har en veldefineret levetid, indtil de bortskaffes, og deres plads er genvundet - i FBP dette skal være en eksplicit handling fra en ejende proces. IP'er, der rejser på tværs af en given forbindelse (faktisk er det deres "håndtag", der rejser) udgør en "strøm", som genereres og forbruges asynkront - dette begreb har således ligheder med konceptet med dovne ulemper beskrevet i 1976 -artiklen af ​​Friedman og Wise.

IP'er er normalt strukturerede data - nogle IP'er indeholder dog muligvis ikke reelle data, men bruges simpelthen som signaler. Et eksempel på dette er "bracket IP'er", som kan bruges til at gruppere data -IP'er i sekventielle mønstre i en strøm, kaldet "substreams". Understrømme kan igen være indlejret. IP'er kan også kædes sammen til "IP -træer", som bevæger sig gennem netværket som enkeltobjekter.

Systemet med forbindelser og processer beskrevet ovenfor kan "ramificeres" til enhver størrelse. Under udviklingen af ​​en applikation kan overvågningsprocesser tilføjes mellem par af processer, processer kan "eksploderes" til undernet, eller simuleringer af processer kan erstattes af den virkelige proceslogik. FBP egner sig derfor til hurtig prototyping .

Dette er virkelig et samlebåndsbillede af databehandling: IP'erne, der rejser gennem et netværk af processer, kan opfattes som widgets, der rejser fra station til station i en samlebånd. "Maskiner" kan let tilsluttes igen, tages off -line til reparation, udskiftes og så videre. Mærkeligt nok ligner dette billede meget det af enhedsregistreringsudstyr, der blev brugt til at behandle data før computernes dage, bortset fra at kortstationer skulle håndbøres fra en maskine til en anden.

Implementeringer af FBP kan være ikke-præventive eller præventive-de tidligere implementeringer havde en tendens til at være ikke-præemptive (mainframe og C-sprog), hvorimod den seneste Java-implementering (se nedenfor) bruger Java Thread-klasse og er præventiv.

Eksempler

"Telegram -problem"

FBP -komponenter danner ofte komplementære par. Dette eksempel bruger to sådanne par. Det beskrevne problem virker meget enkelt som beskrevet i ord, men er faktisk overraskende svært at opnå ved hjælp af konventionel procedurelogik. Opgaven, kaldet "Telegram Problem", oprindeligt beskrevet af Peter Naur , er at skrive et program, der accepterer tekstlinjer og genererer outputlinjer, der indeholder så mange ord som muligt, hvor antallet af tegn i hver linje ikke overstiger et bestemt længde. Ordene må ikke deles, og vi antager, at intet ord er længere end outputlinjernes størrelse. Dette er analogt med ordindpakningsproblemet i tekstredigeringsprogrammer.

I konventionel logik opdager programmøren hurtigt, at hverken input- eller outputstrukturer kan bruges til at drive opkaldshierarkiet for kontrolflow . I FBP på den anden side foreslår selve problembeskrivelsen en løsning:

• "ord" nævnes eksplicit i beskrivelsen af ​​problemet, så det er rimeligt for designeren at behandle ord som informationspakker (IP'er)
• i FBP er der ikke et enkelt opkaldshierarki, så programmøren fristes ikke til at tvinge et delmønster af løsningen til at være det øverste niveau.

Her er den mest naturlige løsning i FBP (der er ikke en enkelt "korrekt" løsning i FBP, men dette virker som en naturlig pasform):

hvor DC og RC står for henholdsvis "DeCompose" og "ReCompose".

Som nævnt ovenfor kan Initial Information Packets (IIP'er) bruges til at specificere parametriske oplysninger, f.eks. Den ønskede outputpostlængde (krævet af de to yderste komponenter til højre) eller filnavne. IIP'er er datastumper, der er knyttet til en port i netværksdefinitionen, som bliver "normale" IP'er, når der udstedes en "modtagelse" for den relevante port.

Batchopdatering

Denne type program involverer at sende en fil med "detaljer" (ændringer, tilføjelser og sletninger) mod en "masterfil" og producere (mindst) en opdateret masterfil og en eller flere rapporter. Opdateringsprogrammer er generelt ret svære at kode ved hjælp af synkron, procedurekode, da to (nogle gange flere) inputstrømme skal holdes synkroniseret, selvom der kan være masters uden tilsvarende detaljer eller omvendt.

I FBP gør en genanvendelig komponent (Collate), der er baseret på enhedspostidéen om en Collator, det meget lettere at skrive denne type applikationer, da Collate fusionerer de to streams og indsætter bracket -IP'er for at angive grupperingsniveauer, hvilket forenkler nedstrøms logikken betydeligt. Antag, at en strøm ("mestre" i dette tilfælde) består af IP'er med nøgleværdier på 1, 2 og 3, og den anden strøm -IP'er ("detaljer") har nøgleværdier på 11, 12, 21, 31, 32, 33 og 41, hvor det første ciffer svarer til masternøgleværdierne. Ved at bruge parentestegn til at repræsentere "bracket" IP'er vil den samlede outputstrøm være som følger:

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

Da der ikke var nogen master med værdien 4, består den sidste gruppe af en enkelt detalje (plus parenteser).

Strukturen af ​​den ovennævnte strøm kan beskrives kortfattet ved hjælp af en BNF -lignende notation som f.eks

{ ( [m] d* ) }*

Collate er en genanvendelig sort boks, der kun behøver at vide, hvor kontrolfelterne er i sine indgående IP'er (selv dette er ikke strengt nødvendigt, da transformerprocesser kan indsættes opstrøms for at placere kontrolfelterne på standardplaceringer), og kan faktisk generaliseres til et hvilket som helst antal inputstrømme og en hvilken som helst dybde af beslag. Collate bruger en array-type port til input, hvilket tillader et variabelt antal inputstrømme.

Multiplexeringsprocesser

Flowbaseret programmering understøtter procesmultiplexering på en meget naturlig måde. Da komponenter er skrivebeskyttede, kan et vilkårligt antal forekomster af en given komponent ("processer") køre asynkront med hinanden.

Når computere normalt havde en enkelt processor, var dette nyttigt, når der foregik meget I/O; nu hvor maskiner normalt har flere processorer, begynder dette at blive nyttigt, når processer også er CPU-intensive. Diagrammet i dette afsnit viser en enkelt "Load Balancer" -proces, der distribuerer data mellem tre processer, mærket henholdsvis S1, S2 og S3, som er forekomster af en enkelt komponent, som igen føder til en enkelt proces ved et "først til mølle" , først til mølle ".

Simpelt interaktivt netværk

I denne generelle skematik kommer anmodninger (transaktioner), der kommer fra brugere, ind i diagrammet øverst til venstre, og svarene returneres nederst til venstre. "Bagenden" (på højre side) kommunikerer med systemer på andre steder, f.eks. Ved hjælp af CORBA , MQSeries osv. Krydsforbindelserne repræsenterer anmodninger, der ikke behøver at gå til bagenden, eller anmodninger, der skal cykle igennem netværket mere end én gang, før det returneres til brugeren.

Da forskellige anmodninger kan bruge forskellige back-end og kan kræve forskellige tid for back-enderne (hvis de bruges) til at behandle dem, skal der tages hensyn til at relatere returnerede data til de relevante anmodende transaktioner, f.eks. Hashtabeller eller caches.

Ovenstående diagram er skematisk i den forstand, at den endelige applikation kan indeholde mange flere processer: processer kan indsættes mellem andre processer for at styre caches, vise forbindelsestrafik, overvåge gennemløb osv. Også blokkene i diagrammet kan repræsentere "undernet" - små netværk med en eller flere åbne forbindelser.

Sammenligning med andre paradigmer og metoder

Jackson Structured Programming (JSP) og Jackson System Development (JSD)

Denne metode forudsætter, at et program skal struktureres som et enkelt proceduremæssigt hierarki af underrutiner. Dens udgangspunkt er at beskrive applikationen som et sæt "hovedlinjer", baseret på input- og outputdatastrukturer. En af disse "hovedlinjer" vælges derefter til at drive hele programmet, og de andre skal "vendes" for at gøre dem til underrutiner (deraf navnet "Jackson inversion"). Dette resulterer nogle gange i det, der kaldes et "sammenstød", hvilket kræver, at programmet opdeles i flere programmer eller koroutiner. Ved brug af FBP er denne inversionsproces ikke påkrævet, da hver FBP -komponent kan betragtes som en separat "hovedlinje".

FBP og JSP deler konceptet med at behandle et program (eller nogle komponenter) som en parser af en inputstrøm.

I Jacksons senere arbejde, Jackson System Development (JSD), blev ideerne udviklet yderligere.

I JSD opretholdes designet som et netværksdesign indtil det sidste implementeringsstadium. Modellen transformeres derefter til et sæt sekventielle processer til antallet af tilgængelige processorer. Jackson diskuterer muligheden for direkte at udføre den netværksmodel, der eksisterer forud for dette trin, i afsnit 1.3 i sin bog (kursiv tilføjet):

Specifikationen produceret ved afslutningen af ​​systemtimingstrinnet er i princippet i stand til direkte udførelse. Det nødvendige miljø vil indeholde en processor til hver proces, en enhed svarende til en ubegrænset buffer for hver datastrøm og nogle input- og outputenheder, hvor systemet er forbundet til den virkelige verden. Et sådant miljø kunne naturligvis leveres af passende software, der kører på en tilstrækkelig kraftfuld maskine. Nogle gange vil en sådan direkte udførelse af specifikationen være mulig og kan endda være et rimeligt valg.

FBP blev anerkendt af MA Jackson som en tilgang, der følger hans metode til "Programnedbrydning i sekventielle processer, der kommunikerer ved en coroutine-lignende mekanisme"

Applikativ programmering

WB Ackerman definerer et applikationssprog som et sprog, der udfører hele dets behandling ved hjælp af operatorer, der anvendes på værdier. Det tidligste kendte anvendelige sprog var LISP.

En FBP -komponent kan betragtes som en funktion, der omdanner sine inputstrømme til sin outputstrøm. Disse funktioner kombineres derefter for at foretage mere komplekse transformationer, som vist her:

Hvis vi mærker vandløb som vist med små bogstaver, kan diagrammet ovenfor gengives kortfattet som følger:

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

Ligesom i funktionel notation kan F bruges to gange, fordi den kun fungerer med værdier og derfor ikke har bivirkninger, i FBP kan to forekomster af en given komponent køre samtidigt med hinanden, og derfor må FBP-komponenter ikke have bivirkninger enten. Funktionel notation kunne klart bruges til at repræsentere mindst en del af et FBP -netværk.

Spørgsmålet opstår derefter, om FBP -komponenter selv kan udtrykkes ved hjælp af funktionel notation. WH Burge viste, hvordan strømudtryk kan udvikles ved hjælp af en rekursiv, anvendelig programmeringsstil, men dette arbejde var i form af (strømme af) atomværdier. I FBP er det nødvendigt at kunne beskrive og behandle strukturerede datastumper (FBP IP'er).

Desuden antager de fleste applikationssystemer, at alle data er tilgængelige i hukommelsen på samme tid, mens FBP-applikationer skal være i stand til at behandle langvarige datastrømme, mens de stadig bruger endelige ressourcer. Friedman og Wise foreslog en måde at gøre dette på ved at tilføje begrebet "dovne ulemper" til Burges arbejde. Dette fjernede kravet om, at begge argumenter for "ulemper" skulle være tilgængelige på samme tid. "Dovne ulemper" bygger faktisk ikke en strøm, før begge dens argumenter er realiseret - før det registrerer det simpelthen et "løfte" om at gøre dette. Dette gør det muligt at realisere en strøm dynamisk forfra, men med en urealiseret bagende. Slutningen af ​​strømmen forbliver urealiseret indtil slutningen af ​​processen, mens begyndelsen er en stadigt længere række af elementer.

Linda

Mange af begreberne i FBP ser ud til at være blevet opdaget uafhængigt i forskellige systemer gennem årene. Linda, der er nævnt ovenfor, er en sådan. Forskellen mellem de to teknikker illustreres af Linda "school of piranhas" belastningsbalanceringsteknik - i FBP kræver dette en ekstra "load balancer" -komponent, der leder anmodninger til komponenten i en liste, der har det mindste antal IP'er, der venter på blive behandlet. Det er klart, at FBP og Linda er nært beslægtede, og den ene kan let bruges til at simulere den anden.

Objektorienteret programmering

Et objekt i OOP kan beskrives som en semi-autonom enhed, der omfatter både information og adfærd. Objekter kommunikerer ved hjælp af "metodeopkald", som i det væsentlige er subrutineopkald, udført indirekte via den klasse, som det modtagende objekt tilhører. Objektets interne data kan kun tilgås ved hjælp af metodeopkald, så dette er en form for information, der gemmer sig eller "indkapsling". Indkapsling går imidlertid forud for OOP - David Parnas skrev en af ​​de skelsættende artikler om det i begyndelsen af ​​70'erne - og er et grundlæggende koncept inden for computing. Indkapsling er selve essensen af ​​en FBP -komponent, der kan betragtes som en sort boks , der udfører en vis konvertering af sine inputdata til sine outputdata. I FBP er en del af specifikationen af ​​en komponent de dataformater og strømstrukturer, den kan acceptere, og dem, den vil generere. Dette udgør en form for design efter kontrakt . Derudover kan dataene i en IP kun tilgås direkte af den proces, der i øjeblikket ejer. Indkapsling kan også implementeres på netværksniveau ved at have ydre processer til at beskytte de indre.

Et papir af C. Ellis og S. Gibbs skelner mellem aktive objekter og passive objekter. Passive objekter omfatter information og adfærd som beskrevet ovenfor, men de kan ikke bestemme tidspunktet for denne adfærd. Aktive objekter på den anden side kan gøre dette. I deres artikel siger Ellis og Gibbs, at aktive objekter har meget mere potentiale for udvikling af vedligeholdelige systemer end passive objekter. En FBP -applikation kan ses som en kombination af disse to typer objekter, hvor FBP -processer svarer til aktive objekter, mens IP'er svarer til passive objekter.

Skuespiller model

FBP betragter Carl Hewitt 's Actor som en asynkron proces med 2 porte: en til inputmeddelelser og en for kontrolsignaler. Et kontrolsignal udsendes af skuespilleren selv efter hver udførelsesrunde. Formålet med dette signal er at undgå parallel udførelse af skuespillerens krop og således at give adgang til aktørobjektets felter uden synkronisering.

Se også

• Aktive objekter
• Skuespiller model
• Apache NiFi
• BMDFM
• Kommunikation af sekventielle processer (CSP)
• Samtidig computing
• Dataflow
• Dataflowdiagram
• Dataflow programmering
• FBD - Funktionsblokdiagrammer (et programmeringssprog i IEC 61131 -standarden)
• Funktionel reaktiv programmering
• Linda (koordineringssprog)
• Lav-kode udviklingsplatforme
• MapReduce
• Node-RØD
• Pipeline programmering
• VRL Studio [1]
• Wayne Stevens
• XProc
• Yahoo rør

Referencer

eksterne links

• Razdow, Allen (december 1997). "Opbygning af virksomhedsdataraffinaderier" . DMReview . Hentet 2006-07-15 .
• Mayer, Anthony; McGough, Stephen; Gulamali, Murtaza; Young, Laurie; Stanton, Jim; Newhouse, Steven; Darlington, John (2002). "Betydning og adfærd i netorienterede komponenter" (PDF) . London e-Science Center, Imperial College of Science, Technology and Medicine. Arkiveret fra originalen (PDF) den 2012-02-04.
• Black, Andrew P .; Huang, Jie; Koster, Rainer; Walpole, Jonathan; Pu, Calton (2002). "Infopipes: En abstraktion til multimediastreaming" (PDF) . Multimediesystemer . Springer-Verlag. 8 (5): 406–419. doi : 10.1007/s005300200062 . S2CID  5700383 . Hentet 2006-08-10 .
• Kra, David (oktober 2004). "zSeries og iSeries -servere i gitterdomænet" . IBM DeveloperWorks . Hentet 2006-07-13 .
• Ludäscher, Bertram; Altintas, Ilkay; Berkley, Tchad; et al. (September 2004). "Videnskabelig arbejdsgangsstyring og Kepler -systemet" (PDF) . San Diego Supercomputer Center . Hentet 2006-07-14 .
• Bickle, Jerry; Richardson, Kevin; Smith, Jeff (2005). "OMG Software Radio Specification Overview for Robotics" (PDF) . Object Management Group - Software -Based Communications. Arkiveret fra originalen (PDF) den 2006-07-14 . Hentet 2006-07-15 .
• Blažević, Mario (2006). "Streaming Component Combinators" . Procedurer for ekstreme markeringssprog . Arkiveret fra originalen 2007-09-18 . Hentet 2006-11-09 .
• Kauler, Barry (1999). Flowdesign til integrerede systemer, 2. udgave . R&D Books/Miller Freeman. ISBN 978-0-87930-555-0.
• US patent 5204965 , Guthery, Scott B .; Barth, Paul S. & Barstow, David R., "Databehandlingssystem ved hjælp af strømlagre", udstedt 1993-04-20, tildelt Schlumberger Technology Corporation 
• Morrison, J. Paul (marts 2013). "Flowbaseret programmering" . Application Developers 'News (1) . Hentet 2014-05-25 .
• Staplin, George Peter (2006). "Tcl Flow -Based Programming - TFP" . Hentet 2010-10-07 .
• Johnston, Wesley M .; Hanna, JR Paul; Millar, Richard J. (marts 2004). "Fremskridt i dataflow -programmeringssprog". 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 (april 2003). "Trådgennemsigtighed i informationsflow -middleware" . Software: Øvelse og erfaring . 33 (4): 321–349. CiteSeerX  10.1.1.15.3933 . doi : 10.1002/spe.510 . S2CID  37356020 . Hentet 2006-12-05 .
• Stevenson, Tony (februar 1995). "Gennemgang af" Flow-Based Programming " " . PC Update, magasinet i Melbourne PC User Group, Australien. Arkiveret fra originalen 2006-09-25 . Hentet 2006-12-06 .
• Lea, Doug (maj 2001). "Komponere envejsbeskeder" . Hentet 2006-12-06 .
• Bowers, Shawn; Ludäscher, B .; Ngu, AHH; Critchlow, T. "Aktivering af videnskabelig genbrug af arbejdsgange gennem struktureret sammensætning af dataflow og kontrol-flow" (PDF) . SciFlow '06. Arkiveret fra originalen (PDF) 2007-02-05 . Hentet 2006-12-06 .
• Sorber, Jacob; Kostadinov, Alexander; Garber, Matthew; Brennan, Matthew; Hjørne, Mark D .; Berger, Emery D. (2007). "Eon". Eon: et sprog- og runtime -system til evige systemer . Forhandlinger fra den 5. internationale konference om integrerede netværkssensorsystemer - Session: Strømstyring. s. s. 161. doi : 10.1145/1322263.1322279 . ISBN 9781595937636. S2CID  12851752 .
• Fiedler, Lars; Dasey, Timothy (2014). "Systemer og metoder til Composable Analytics" . National teknisk informationstjeneste . Hentet 2014-04-01 .
• Matt, Carkci (2014). Dataflow og reaktive programmeringssystemer: En praktisk vejledning . CreateSpace Independent Publishing Platform. ISBN 978-1497422445.
• Lampa, Samuel; Dahlö, Martin; Alvarsson, Jonathan; Spjuth, Ola (2018). "SciPipe - Et workflow -bibliotek til smidig udvikling af komplekse og dynamiske bioinformatik -rørledninger" . bioRxiv : 380808. doi : 10.1101/380808 . Hentet 2018-08-02 .