Programação baseada em fluxo

Question

Eu tenho lendo um pouco de Programação baseada em fluxo nos últimos dias. Existe um Wiki que fornece mais detalhes. E a Wikipedia tem um boa visão geral nele também. Meu primeiro pensamento foi: "Outro grande defensor da LEGO -Land fingle Programming" - um conceito que remonta ao final dos anos 80. Mas, ao ler mais, devo admitir que fiquei intrigado.

1. Você já usou o FBP para um projeto real?
2. Qual é a sua opinião sobre o FBP?
3. O FBP tem um futuro?

Em alguns sentidos, parece que o Santo Graal da reutilização que nossa indústria perseguia desde o advento das línguas processuais.

Answer 1

Discussão interessante! Ocorreu -me ontem que parte da confusão pode ser devido ao fato de que muitas anotações diferentes usam arcos direcionados, mas usá -los para significar coisas diferentes. No FBP, as linhas representam buffers limitados, através dos quais fluxos de viagem de pacotes de dados. Como os componentes são tipicamente processos de longa duração, os fluxos podem compreender um grande número de pacotes, e os aplicativos do FBP podem ser executados por períodos muito longos - talvez até "perpetuamente" (veja um artigo de 2007 em um projeto chamado EON, principalmente por pessoas da UMass Amherst ). Como um envio para um buffer limitado suspende quando o buffer está (temporariamente) cheio (ou temporariamente vazio), quantidades indefinidas de dados podem ser processadas usando recursos finitos.

Em comparação, o E em Grafcet vem de Etapes, que significa "etapas", que é um conceito bastante diferente. Nesse tipo de modelo (e há vários deles por aí), os dados que fluem entre as etapas são limitados ao que pode ser mantido em memória de alta velocidade ao mesmo tempo ou deve ser mantida no disco. O FBP também suporta loops na rede, o que é difícil de fazer em sistemas baseados em etapas - veja por exemplo http://www.jpaulmorrison.com/cgi-bin/wiki.pl?brokerageApplication - Observe que este aplicativo usou MQSeries e Corba de maneira natural. Além disso, o FBP é nativamente paralelo, por isso se presta à programação de redes de grade, máquinas multicore e várias direções da computação moderna. Um último comentário: na literatura, encontrei muitos projetos relacionados, mas poucos deles têm todas as características do FBP. Uma lista que acumiquei ao longo dos anos (vários deles mais próximos que o Grafcet) pode ser encontrada em http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLea-Projects .

Answer 2

1. Você já usou o FBP para um projeto real?

Projetamos e implementamos um servidor DF para o nosso projeto de automação (Dispatcher, Component Iterface, um monte de componentes, DF Language, DF Compiler, UI). Está escrito em C ++ nu e é executado em vários sistemas do tipo UNIX (Linux x86, MIPS, AVR32 etc., Mac OSX). Falta vários recursos, por exemplo, controle de fluxo sofisticado, controle complexo de roscas (existe apenas um componente não muito avançado para ele), por isso é apenas um protótipo, mesmo que funcione. Agora estamos trabalhando em um servidor completo. Aprendemos muito durante a implementação e o uso do protótipo.

Além disso, faremos um editor visual algum dia.

2. Qual é a sua opinião sobre o FBP?

2.1. Primeiro de tudo, a programação de fluxo de dados é diversão final

Quando conheci a programação do DataFlow, me senti há 20 anos, quando conheci a programação primeiro. Ao todo, a programação DF difere da programação processual/OOP, é apenas um tipo de programação. Há muitas coisas para descobrir, mesmo que tãem simples! É muito engraçado, quando, como um programador experiente, você conheceu um problema de DF, que é uma coisa muito básica, mas era completamente desconhecido para você antes. Portanto, se você pular para a programação do DF, se sentirá como um programador novato, que conheceu o "ciclo" ou "condição".

2.2. Pode ser usado apenas para arquiteturas específicas

É apenas um martelo, que é para martelar as unhas. O DF não é adequado para UIs, servidor da web e assim por diante.

2.3. A arquitetura de fluxo de dados é ideal para alguns problemas

Uma estrutura de fluxo de dados pode fazer coisas mágicas. Ele pode paralelizar procedimentos, que não são originalmente projetados para paralelização. Os componentes são threads únicos, mas quando são organizados em um gráfico de DF, eles se tornaram multi-thread.

Exemplo: você sabia que faço é um sistema DF? Tentar faça -j (Veja cara, para que serve). Se você possui uma máquina com vários núcleos, compila seu projeto com e sem -j e compare tempos.

2.4. Divisão ideal do problema

Se você está escrevendo um programa, geralmente divide o problema para subproblemas menores. Existem pontos de divisão usuais para subproblemas conhecidos, que você não precisa implementar, basta usar as soluções existentes, como o SQL para DB, ou OpenGL para gráficos/animação, etc.

A arquitetura DF divide seu problema de uma maneira muito interessante:

• A estrutura de fluxo de dados, que fornece a arquitetura (basta usar uma existente),
• Os componentes: o programador cria componentes; Os componentes são unidades simples e bem separadas - é fácil fazer componentes;
• A configuração: AKA DataFlow Programming: O configurador coloca o gráfico de fluxo de dados (programa) usando componentes fornecidos pelo programador.

Se o seu conjunto de componentes estiver bem projetado, o configurador poderá construir esse sistema, com o qual o programador nunca sonhou. Configurador pode implementar novo recursos sem perturbar o programador. Os clientes estão felizes, porque têm solução personalizada. O fabricante de software também está feliz, porque não precisa manter várias filiais específicas do cliente do software, apenas configurações específicas do cliente.

2.5. Velocidade

Se o sistema for construído com componentes nativos, o programa DF será rápido. A única perda de tempo é a expedição de mensagens entre os componentes em comparação com um programa OOP simples, também é mínimo.

3. O FBP tem um futuro?

Sim, claro.

A principal razão é que ele pode resolver problemas de multiprocessamento maciços sem introduzir arquiteturas de software estranhas novas, idiomas estranhos. A programação de fluxo de dados é fácil e quero dizer ambos: programação de componentes e construção de configuração de fluxo de dados. (Mesmo a escrita da estrutura de fluxo de dados não é uma ciência de foguetes.)

Além disso, é muito econômico. Se você tem um bom conjunto de componentes, só precisa montar os tijolos LEGO. Um programa DF é fácil de manter. A construção de configuração do DF não requer programador experiente, apenas um integrador de sistema.

Eu ficaria feliz, se os sistemas nativos se espalhassem, com as portas abertas para a criação de componentes personalizados. Também deve haver um idioma DF padrão, o que significa que ele pode ser usado com editores visuais independentes da plataforma e vários servidores DF.

Answer 3

Eu tenho que discordar do comentário sobre o FBP ser apenas um meio de implementar o FSMS: acho que os FSMs são legais e acredito que eles têm um papel definitivo na construção de aplicações, mas o conceito central de FBP é de vários processos de componentes em execução assíncrono, comunicando -se por meio de fluxos de pedaços de dados que passam pelo que agora são chamados de buffers limitados. Sim, definitivamente o FSMS é uma maneira de criar processos de componentes e, de fato, há um capítulo inteiro no meu livro sobre o FBP dedicado a essa idéia, e o relacionado de PDAs (1) - http://www.jpaulmorrison.com/fbp/compil.htm - Mas, na minha opinião, um FSM implementando uma rede FBP não trivial seria impossivelmente complexa. Como exemplo, o diagrama mostrado emé cerca de 1/3 de um solteiro Trabalho em lote em execução em um mainframe. Cada um desses blocos está executando de forma assíncrona com todos os outros. A propósito, eu ficaria muito interessado em ouvir mais respostas para as perguntas no primeiro post!

1: http://en.wikipedia.org/wiki/pushdown_automaton Automatos de empurrar

Answer 4

Sempre que ouço o termo programação baseada em fluxo, penso em Labview, conceitualmente. IE Processos de componentes cuja programação é impulsionada principalmente por uma alteração em seus dados de entrada. Isso realmente é a programação da LEGO no sentido de que a plataforma Labview foi usada para a última colheita de produtos MindStorm. No entanto, discordo que isso o torna um modelo de programação menos útil.

Para sistemas industriais que normalmente envolvem coleta, controle e automação de dados, ele se encaixa muito bem. O que é algum sistema de controle, se não os dados transformados em dados? Ou seja, qual componente em seu esquema de controle você não preferiria representar como uma caixa preta em uma imagem maior, se pudesse fazê -lo. Para atingir esse nível de clareza arquitetônica usando outras metodologias, talvez seja necessário desenhar um diagrama de classe de domínio de dados, depois um relacionamento de clínica de tempo de execução do domínio, além disso, um diagrama de casos de uso e vire para frente e para trás entre eles. Com os sistemas acionados por fluxo, você tem o luxo de poder colapsar muitas dessas informações juntas com precisão o suficiente para que você possa projetar realisticamente um sistema visualmente assim que os componentes forem construídos e definidos.

Uma pergunta que nunca tive que fazer ao olhar para um aplicativo escrito em Labview é "que pedaço de código definiu esse valor?", Pois era inerente e fácil de rastrear para trás com os dados, e também erros como vários escritores não intencionais eram impossíveis de criar por engano.

Se isso fosse verdade para o código escrito de uma maneira mais tipicamente processual!

Answer 5

1) Construo uma pequena estrutura FBP para um projeto de detecção de anomalia e acaba sendo uma ótima idéia.

Você também pode dar uma olhada em alguns dos Vídeos Knime, que dão uma boa idéia de como é uma estrutura baseada em fluxo quando a estrutura é montada por uma grande equipe. É certo que é baseado em lote e não é criado para operação contínua.

De longe o melhor exemplo de programação baseada em fluxo, no entanto, é Pipes Unix que é uma das mais antigas e mais esquecidas FBP Framework. Acho que não tenho que elaborar o poder dos tubos de nix ...

2) O FBP é uma ferramenta muito poderosa para um grande conjunto de problemas. O paralelismo intrínseco é uma grande vantagem, e qualquer estrutura do FBP pode ser feita completamente transparente em rede usando módulos adaptadores. As estruturas inteligentes também são tolerantes a falhas absurdamente e são capazes de recarregar os módulos travados dinamicamente quando necessário. A simplicidade conceitual também permite uma comunicação mais limpa com todos os envolvidos em um projeto e um código muito mais limpo.

3) Absolutamente! Os tubos estão aqui para ficar e são uma das características mais poderosas do Unix. O poder inerente a uma estrutura do FBP em comparação com um programa estático é muitos e trivializa a mudança, até o ponto em que algumas estruturas podem ser reconfiguradas enquanto correndo sem medidas especiais.

FBP FTW! ;-)

Answer 6

No desenvolvimento automotivo, eles têm um protocolo de mensagens agnósticas de idiomas que faz parte da maior especificação (transporte de sistemas orientados a mídia), foi projetado para se comunicar entre componentes em uma rede ou dentro do mesmo dispositivo. Os sistemas geralmente possuem um barramento de mensagens reais e visualizados - portanto, você efetivamente tem uma forma de programação baseada em fluxo.

Foi isso que fez a lâmpada continuar para mim há vários anos e me trouxe aqui. É realmente uma maneira fantástica de trabalhar e muito mais divertida do que a programação convencional. O catálogo de mensagens forma a especificação central e o ponto de referência. Funciona bem para desenvolvedores e gerenciamento. O gerenciamento do IE pode navegar no catálogo de mensagens em vez de olhar para a fonte.

Com o registro integrado também referenciar o catálogo para produzir análises inteligíveis, coisas podem ser realmente produtivas. Tenho experiência do mundo real de desenvolver produtos comerciais dessa maneira. Estou interessado em levar as coisas adiante, principalmente no que diz respeito a ferramentas e IDEs. Infelizmente, acho que muitas pessoas do setor automotivo perderam o ponto sobre o quão bom isso é e não conseguiu desenvolvê -lo. Eles agora estão distraídos por outros modismos e não perceberam que havia muito mais a maioria desenvolvimento do que o ônibus físico.

Answer 7

Eu usei Spring Web Flow extensivamente em aplicativos da Web Java para modelos (normalmente) processos de aplicativos, que tendem a ser assuntos complexos semelhantes a assistentes com muita lógica condicional sobre quais páginas exibirem. É incrivelmente poderoso. Um novo produto foi adicionado e eu consegui recrutar as peças existentes em um processo de aplicação completamente novo em uma ou duas horas (com a adição de algumas novas visualizações/estados).

Eu também procurei usar Fluxo de trabalho do sistema operacional Para modelar processos de negócios, mas esse projeto foi enlatado por vários motivos.

No mundo da Microsoft, você tem Windows Workflow Foundation ("WWF"), que está se tornando mais popular, principalmente em conjunto com SharePoint.

O FBP é apenas um meio de implementar um máquina de estados finitos. Não é nada de novo.

Answer 8

Percebo que não é exatamente a mesma coisa, mas esse modelo foi usado há anos na programação do PLC. A ISO o chama de fluxograma seqüencial, mas muitas pessoas o chamam de grafcet após uma implementação popular. Oferece processamento paralelo e define transições entre os estados.

Answer 9

Atualmente, ele está sendo usado no mundo da Business Intelligence para mashup e processar dados. Etapas de processamento de dados como ETL, consulta, união e produção de relatórios podem ser feitos pelo usuário final. Eu sou um desenvolvedor em um sistema aberto - Composableanalytics.com Na CA, os aplicativos baseados em fluxo podem ser compartilhados e executados através do navegador.

Answer 10

É para isso que servem a série MQ, MSMQ e JMS.

Esta é a pedra angular dos Serviços da Web e implementações de barramento de serviços corporativos.

Produtos como Tibco e JCAPs da Sun são basicamente baseados em fluxo, sem usar essa palavra em particular.

A maior parte do trabalho do aplicativo é feita com pequenos módulos que passam mensagens por uma rede de processamento.