Programmazione basata sul flusso

https://stackoverflow.com/questions/405627

03-07-2019
|

Domanda

Negli ultimi giorni ho fatto una piccola lettura su Programmazione basata sul flusso . Esiste un wiki che fornisce ulteriori dettagli. E Wikipedia ha anche una una buona panoramica . Il mio primo pensiero fu, "grande un altro sostenitore della lego-land fingere di programmare" - un concetto che risale alla fine degli anni '80. Ma, mentre leggo di più, devo ammettere di essermi incuriosito.

Hai usato FBP per un vero progetto?
Qual è la tua opinione su FBP?
L'FBP ha un futuro?

In alcuni sensi, sembra il santo graal di riutilizzo che la nostra industria ha perseguito fin dall'avvento dei linguaggi procedurali.

Soluzione

Discussione interessante! Mi è venuto in mente ieri che parte della confusione potrebbe essere dovuta al fatto che molte notazioni diverse usano archi diretti, ma li usano per significare cose diverse. In FBP, le linee rappresentano buffer limitati, attraverso i quali viaggiano flussi di pacchetti di dati. Dato che i componenti sono in genere processi di lunga durata, i flussi possono comprendere un numero enorme di pacchetti e le applicazioni FBP possono essere eseguite per periodi molto lunghi, forse persino "perpetuamente". (vedi un articolo del 2007 su un progetto chiamato Eon, per lo più da parte di UMass Amherst). Poiché un invio a un buffer limitato viene sospeso quando il buffer è (temporaneamente) pieno (o temporaneamente vuoto), è possibile elaborare quantità indefinite di dati utilizzando risorse limitate.

In confronto, la E in Grafcet deriva da Etapes, che significa "passi", che è un concetto piuttosto diverso. In questo tipo di modello (e ce ne sono alcuni là fuori), i dati che scorrono tra i passaggi sono limitati a ciò che può essere conservato nella memoria ad alta velocità in una sola volta o devono essere conservati su disco. FBP supporta anche i loop nella rete, cosa difficile da eseguire nei sistemi basati su step - vedere ad esempio http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication - nota che questa applicazione ha usato sia MQSeries che CORBA in modo naturale. Inoltre, FBP è nativamente parallelo, quindi si presta alla programmazione di reti a griglia, macchine multicore e un certo numero di direzioni dell'informatica moderna. Un ultimo commento: in letteratura ho trovato molti progetti correlati, ma pochi di essi hanno tutte le caratteristiche di FBP. Un elenco che ho accumulato nel corso degli anni (alcuni dei quali più vicini a Grafcet) è disponibile in http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects .

Altri suggerimenti

1. Hai usato FBP per un vero progetto?

Abbiamo progettato e implementato un server DF per il nostro progetto di automazione (dispatcher, iterface dei componenti, un gruppo di componenti, linguaggio DF, compilatore DF, UI). È scritto in C ++ e funziona su diversi sistemi simili a Unix (Linux x86, MIPS, avr32 ecc., Mac OSX). Manca diverse funzionalità, ad es. controllo di flusso sofisticato, controllo di thread complesso (esiste solo un componente non troppo avanzato), quindi è solo un prototipo, anche se funziona. Ora stiamo lavorando su un server completo. Abbiamo imparato molto durante l'implementazione e l'utilizzo del prototipo.

Inoltre, un giorno realizzeremo un editor visivo.

2. Qual è la tua opinione su FBP?

2.1. Innanzitutto, la programmazione del flusso di dati è divertimento estremo

Quando ho incontrato la programmazione del flusso di dati, mi sentivo 20 anni fa, quando ho incontrato per la prima volta la programmazione. Tuttavia, la programmazione DF differisce dalla programmazione procedurale / OOP, è solo un tipo di programmazione. Ci sono molte cose da scoprire, anche così semplici! È molto divertente quando, in qualità di programmatore esperto, hai riscontrato un problema DF, che è una cosa molto basilare, ma prima non ti era completamente sconosciuto. Quindi, se salti nella programmazione di DF, ti sentirai come un programmatore principiante, che per primo ha incontrato il "ciclo". o " condition " ;.

2.2. Può essere utilizzato solo per architetture specifiche

È solo un martello, che serve per martellare i chiodi. DF non è adatto per interfacce utente, server Web e così via.

2.3. L'architettura del flusso di dati è ottimale per alcuni problemi

Un framework di flusso di dati può fare cose magiche. Può paralizzare le procedure, che inizialmente non sono progettate per la paralellizzazione. I componenti sono a thread singolo, ma quando sono organizzati in un grafico DF, diventano multi-thread.

Esempio: lo sapevi che crea è un sistema DF? Prova make -j (vedi man, a cosa serve -j). Se hai una macchina multi-core, compila il tuo progetto con e senza -j e confronta i tempi.

2.4. Divisione ottimale del problema

Se stai scrivendo un programma, spesso dividi il problema per piccoli problemi secondari. Esistono soliti punti di divisione per noti sotto-problemi, che non è necessario implementare, basta usare le soluzioni esistenti, come SQL per DB o OpenGL per grafica / animazione, ecc.

L'architettura DF divide il tuo problema in un modo molto interessante:

il framework del flusso di dati, che fornisce l'architettura (basta usarne una esistente),
i componenti: il programmatore crea componenti; i componenti sono unità semplici e ben separate: è facile creare componenti;
la configurazione: a.k.a. programmazione del flusso di dati: il configuratore mette insieme il grafico del flusso di dati (programma) usando i componenti forniti dal programmatore.

Se il tuo set di componenti è ben progettato, il configuratore può costruire tale sistema, che il programmatore non ha nemmeno mai sognato. Configurator può implementare nuove funzionalità senza disturbare il programmatore. I clienti sono felici, perché hanno una soluzione personalizzata. Anche il produttore del software è felice, perché non ha bisogno di mantenere diversi rami del software specifici del cliente, solo configurazioni specifiche del cliente.

2.5. Velocità

Se il sistema è basato su componenti nativi, il programma DF è veloce. L'unica perdita di tempo è l'invio di messaggi tra i componenti rispetto a un semplice programma OOP, è anche minimo.

3. L'FBP ha un futuro?

Sì, certo.

Il motivo principale è che può risolvere enormi problemi di multiprocessing senza introdurre nuove strane architetture software, linguaggi strani. La programmazione del flusso di dati è semplice e intendo sia la programmazione dei componenti che la costruzione della configurazione del flusso di dati. (Anche la scrittura del framework del flusso di dati non è una scienza missilistica.)

Inoltre, è molto economico. Se hai un buon set di componenti, devi solo unire i mattoncini Lego. Un programma DF è facile da mantenere. La configurazione di DF DF non richiede programmatori esperti, ma solo un integratore di sistemi.

Sarei felice, se i sistemi nativi si diffondessero, con le porte aperte per la creazione di componenti personalizzati. Inoltre, dovrebbe esistere un linguaggio DF standard, il che significa che può essere utilizzato con editor visivi indipendenti dalla piattaforma e diversi server DF.

Non sono d'accordo con il commento sull'FBP che è solo un mezzo per implementare gli FSM: penso che gli FSM siano ordinati e credo che abbiano un ruolo definito nella costruzione di applicazioni, ma il concetto chiave di FBP è di processi a più componenti in esecuzione in modo asincrono , comunicando per mezzo di flussi di blocchi di dati che attraversano quelli che ora vengono chiamati buffer limitati. Sì, sicuramente gli FSM sono un modo per costruire processi componenti, e in effetti c'è un intero capitolo nel mio libro su FBP dedicato a questa idea, e quello relativo dei PDA ( 1 ) - http://www.jpaulmorrison.com/fbp/compil.htm - ma a mio avviso un FSM che implementa una rete FBP non banale sarebbe incredibilmente complesso. Ad esempio il diagramma mostrato in è circa 1/3 di un processo batch singolo in esecuzione su un mainframe. Ognuno di questi blocchi funziona in modo asincrono con tutti gli altri. A proposito, sarei molto interessato a ricevere più risposte alle domande nel primo post!

1 : http://en.wikipedia.org/wiki/Pushdown_automaton Automi push-down

Ogni volta che sento il termine programmazione basata sul flusso, penso a LabView, concettualmente. Vale a dire processi componente che la pianificazione è guidata principalmente da una modifica ai suoi dati di input. Questa è davvero una programmazione lego, nel senso che la piattaforma labview è stata utilizzata per l'ultimo raccolto di prodotti di brainstorming. Tuttavia non sono d'accordo sul fatto che ciò lo renda un modello di programmazione meno utile.

Per i sistemi industriali che in genere prevedono la raccolta, il controllo e l'automazione dei dati, si adatta molto bene. Che cos'è un sistema di controllo se non i dati in trasformati in dati in uscita? Vale a dire quale componente nel tuo schema di controllo non preferiresti rappresentare come una scatola nera in un quadro più ampio, se potessi farlo. Per raggiungere quel livello di chiarezza architettonica usando altre metodologie potrebbe essere necessario disegnare un diagramma di classe del dominio di dati, quindi un rapporto di classe di tempo di esecuzione del dominio problematico, quindi sopra un diagramma di caso d'uso e scorrere avanti e indietro tra di loro. Con i sistemi basati sul flusso hai il lusso di riuscire a comprimere molte di queste informazioni in modo sufficientemente accurato da poter progettare realisticamente un sistema visivamente una volta che i componenti sono stati creati e definiti.

Una domanda che non ho mai dovuto porre quando guardavo un'applicazione scritta in labview è " Quale pezzo di codice imposta questo valore? " ;, poiché era inerente e facile da rintracciare indietro dai dati, e anche errori come multipli scrittori non intenzionali erano impossibili da creare per errore.

Se solo fosse vero per il codice scritto in un modo più tipicamente procedurale!

1) Costruisco un piccolo framework FBP per un progetto di rilevamento di anomalie, e si è rivelato un'ottima idea.

Puoi anche dare un'occhiata ad alcuni dei video KNIME , che danno una buona idea di cosa il framework basato sul flusso è come quando il framework è messo insieme da una grande squadra. Certo, è basato su batch e non creato per il funzionamento continuo.

Il migliore esempio di programmazione basata sul flusso, tuttavia, è pipe UNIX che è uno dei framework FBP più vecchi e trascurati. Non credo di dover elaborare la potenza delle nix pipe ...

2) FBP è uno strumento molto potente per una vasta gamma di problemi. Il parallelismo intrinseco è un grande vantaggio e qualsiasi framework FBP può essere reso completamente trasparente in rete utilizzando i moduli adattatore. I framework intelligenti sono anche assurdamente tolleranti ai guasti e in grado di ricaricare dinamicamente i moduli danneggiati quando necessario. La semplicità concettuale consente inoltre una comunicazione più pulita con tutti i soggetti coinvolti in un progetto e un codice molto più pulito.

3) Assolutamente! I tubi sono qui per restare e sono una delle funzionalità più potenti di unix. Le potenzialità insite in un framework FBP rispetto a un programma statico sono molte e banalizzano il cambiamento, al punto che alcuni framework possono essere riconfigurati durante l'esecuzione senza misure speciali.

FBP FTW! ; -)

Nello sviluppo automobilistico, hanno un protocollo di messaggistica indipendente dal linguaggio che fa parte della specifica MOST (Media Oriented Systems Transport), progettato per comunicare tra i componenti su una rete o all'interno dello stesso dispositivo. I sistemi di solito hanno sia un bus di messaggi reale che visualizzato, quindi hai effettivamente una forma di programmazione basata sul flusso.

Questo è stato ciò che ha fatto accendere la lampadina per me diversi anni fa e mi ha portato qui. È davvero un modo fantastico di lavorare e molto più divertente della programmazione convenzionale. Il catalogo dei messaggi costituisce la specifica centrale e il punto di riferimento. Funziona bene sia per gli sviluppatori che per la gestione. vale a dire, i dirigenti sono in grado di sfogliare il catalogo dei messaggi anziché guardare l'origine.

Con la registrazione integrata anche facendo riferimento al catalogo per produrre analisi intelligibili, le cose possono diventare veramente produttive. Ho un'esperienza nel mondo reale nello sviluppo di prodotti commerciali in questo modo. Sono interessato ad andare oltre, in particolare per quanto riguarda strumenti e IDE. Sfortunatamente penso che molte persone nel settore automobilistico abbiano perso il punto su quanto sia grandioso e non sono riuscite a costruirlo. Ora sono distratti da altre mode e non riescono a rendersi conto che c'era molto di più nello sviluppo più del bus fisico.

Ho usato Spring Web Flow ampiamente nelle applicazioni Web Java per modellare (tipicamente) i processi delle applicazioni, che tendono ad essere complesse come procedure guidate con molta logica condizionale su quali pagine visualizzare. È incredibilmente potente. È stato aggiunto un nuovo prodotto e sono riuscito a ricostruire i pezzi esistenti in un processo di applicazione completamente nuovo in un'ora o due (con l'aggiunta di un paio di nuove viste / stati).

Ho anche cercato di utilizzare OS Workflow per modellare i processi aziendali ma quel progetto è stato scelto per vari ragioni.

Nel mondo Microsoft hai Windows Workflow Foundation (" WWF "), che è diventando più popolare, in particolare in combinazione con Sharepoint .

FBP è solo un mezzo per implementare una macchina a stati finiti . Non è una novità.

Mi rendo conto che non è esattamente la stessa cosa, ma questo modello è stato usato per anni nella programmazione di PLC. ISO lo chiama Diagramma di flusso sequenziale, ma molte persone lo chiamano Grafcet dopo un'implementazione popolare. Offre elaborazione parallela e definisce le transizioni tra stati.

Attualmente viene utilizzato nel mondo della Business Intelligence per eseguire il mashup e l'elaborazione dei dati. L'utente finale può eseguire operazioni di elaborazione dei dati come ETL, interrogazione, unione e produzione di report. Sono uno sviluppatore su un sistema aperto - ComposableAnalytics.com In CA, le app basate sul flusso possono essere condivise ed eseguite tramite il browser.

Ecco a cosa servono le serie MQ, MSMQ e JMS.

Questa è la pietra angolare delle implementazioni di servizi Web ed Enterprise Service Bus.

Prodotti come TIBCO e JCAPS di Sun sono fondamentalmente basati sul flusso senza usare questa particolare parola d'ordine.

La maggior parte del lavoro dell'applicazione viene eseguita con piccoli moduli che passano i messaggi attraverso una rete di elaborazione.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow