Hopp til innhold

Flytbasert programmering

Fra Wikipedia, den frie encyklopedi
Sideversjon per 10. mar. 2024 kl. 18:53 av Sauer202 (diskusjon | bidrag) (Skapt ved oversettelse av siden «Flow-based programming»)
(diff) ← Eldre sideversjon | Nåværende sideversjon (diff) | Nyere sideversjon → (diff)

Flytbasert programmering et programmeringsparadigme som definerer applikasjoner som nettverk av svartboks-prosesser som utveksler data på tvers av forhåndsdefinerte forbindelser (kanaler) ved meldingsoverføring, der forbindelsene spesifiseres eksternt for prosessene. Disse svartboks-prosessene kan kobles om i det uendelige for å danne forskjellige applikasjoner uten å måtte endres internt. Flytbasert programmering er derfor naturlig komponentorientert .

Flytbasert programmering er en spesiell form for dataflytprogrammering basert på avgrensede buffere, informasjonspakker med definerte levetider, navngitte porter og separat definisjon av tilkoblinger.

I flytbasert programmering ser man ikke på en applikasjon som en enkelt sekvensiell prosess som starter på et tidspunkt og deretter gjør én ting om gangen til den er ferdig, men i stedet som et nettverk av asynkrone prosesser som kommuniserer ved hjelp av strømmer av strukturerte informasjonspakker. Fokuset er på applikasjonsdataene og transformasjonene som gjøres for å produsere de ønskede resultatene. Nettverket er definert eksternt for prosessene som en liste over forbindelser som tolkes av en skedulerer.

Prosessene kommuniserer ved hjelp av tilkoblinger med fast kapasitet. En tilkobling er knyttet til en prosess ved hjelp av en port, som har et navn avtalt mellom prosesskoden og nettverksdefinisjonen. Mer enn én prosess kan kjøre samme kodebit. På et hvilket som helst tidspunkt kan en gitt IP bare "eies" av en enkelt prosess, eller være i transitt mellom to prosesser. Porter kan enten være enkle eller array-type, som f.eks. brukes for inngangsporten til Collate-komponenten beskrevet nedenfor. Det er kombinasjonen av porter med asynkrone prosesser som gjør det mulig å støtte mange langvarige primitive funksjoner for databehandling, som Sorter, Merge, Summarize, etc., i form av programvaresvarte bokser .


Nettverksdefinisjonen er vanligvis laget diagrammatisk ved hjelp av et visuelt programmeringsspråk, og konverteres til tekstkode på lavere nivå.

Flytbasert programmering kan sees på som koordinasjonsspråk,[1] og er i hovedsak språkuavhengig. Gitt en skedulerer på skrevet på lavnivåspråk kan faktisk komponenter skrevet i forskjellige språk kobles sammen i ett enkelt nettverk. Flytbasert programmering egner seg dermed bra til utvikling med domenespesifikke språk.

Flytbasert programmering har datakobling, som er den løseste formen for kobling mellom komponenter. Konseptet med løs kobling er i sin tur relatert til tjenesteorientert arkitekturer, og flytbasert programmering passer til en rekke av kriteriene for en slik arkitektur, om enn på et mer finkornet nivå enn de fleste eksempler på denne arkitekturen.

Flytbasert programmering fremmer funksjonelle spesifikasjoner på høyt nivå som forenkler resonnement om systematferd. Et eksempel på dette er den distribuerte dataflytmodellen for konstruktivt å spesifisere og analysere semantikken til distribuerte flerpartsprotokoller.



Følgende diagram viser hovedentitetene i et flytbasert diagram (bortsett fra informasjonspakkene). Et slikt diagram kan konverteres direkte til en liste over tilkoblinger, som deretter kan utføres av en passende motor (programvare eller maskinvare).

Enkelt FBP-diagram

A, B og C er prosesser som utfører kodekomponenter. O1, O2 og de to IN-ene er porter som kobler forbindelsene M og N til deres respektive prosesser. Det er tillatt for prosess B og C å kjøre samme kode, så hver prosess må ha eget arbeidslager, kontrollblokker, og så videre.

M og N er det som ofte refereres til som " avgrensede buffere ", og har en fast kapasitet når det gjelder antall informasjonspakker de kan holde til enhver tid.


















Se også

Referanser

  1. ^ Gelernter, David; Carriero, Nicholas (1992). «Coordination languages and their significance». Communications of the ACM. 35 (2): 97–107. doi:10.1145/129630.129635.