SmallFBP: a Smalltalk framework for Flow-Based Programming

filter

Ciência, arte e filosofia se vão fundindo tanto em mim que algum dia certamente vou parir um centauro – Nietzsche.

  1.  Introdução
  2. Flow-Base Programming
    1. Component
    2. Port
    3. Information Packet (IP)
    4. Connection
    5. Network
    6. Initial Information Packet (IIP)
  3. Exemplo: Filter  
    1. OddFilter
    2. Numbers
    3. MaxNumberIIP
    4. Printer
    5. Dropper
  4. Portas automáticas
    1. Introdução
    2. Exemplo: Writer e Reader
    3. Usando displays com portas automáticas
    4. Usando portas automáticas no exemplo Filter
  5. Componentes compostos
    1. Introdução
    2. Subnet
    3. Composição
  6. Flow-Based Programming IDE
    1. Introdução
    2. Arquitetura
    3. Protótipo
  7. Flow-Based Programming IDE II
    1. Introdução
    2. Odd filter
  8. Flow-Based Programming IDE – III
    1. Introdução
    2. Writer e Reader

Introdução

Panta rhei (Panta rhei) – Tudo flui.
Heráclito

A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.

Max Planck

Há algum tempo li que Javascript seria a linguagem do futuro. Recentemente fui investigar isto (por causa de uma prévia experimentação com o CouchDB que usa Javascript para programar as funções map e reduce) e comecei a ler e experimentar com o Javascript (aproveitei meus dias de “minguinho” quebrado). Antes ficava resistente por achar chato ter que ficar inserindo código numa página HTML para testá-lo. Lendo sobre o Node JS acabei me convencendo que a sua CLI seria uma boa opção para testar o Javascript sem ter também que lidar com a DOM do web browser. Lendo o livro Node In Action, no capítulo que aborda as dificuldades de sequenciar ou coordenar ações assíncronas no Node, ao ler sobre os vários frameworks que auxiliam nesta tarefa me deparei com o NoFlo JS.

Quando vi aquilo e li um pouco sobre Flow-Based Programming pensei “é agora que vou parir um centauro!”. Mantida a adequada distância do ilustre filósofo, agora sendo comemorado nos seus 170 anos, lembrei logo das minhas frustradas tentativas (por falta de tempo e motivação) de codificar algo em Smalltalk (minha plataforma preferida para prototipagem rápida e pesquisas em Engenharia de Software – como testemunham alguns posts neste blog) em relação à Hexagonal ou Onion Arquitecture. A idéia de programação com componentes reutilizáveis generalizados, promessa acalentada no advento das linguagens orientadas a objeto mas parcialmente cumprida, pareceu encontrar um caminho promissor – digo isto mas me lembrando que John Paul Morrison, da IBM do Canadá, criou o conceito há mais de 40 anos e usou com sucesso num banco (há um comentário dele relatando como a IBM não fez questão de patentear o conceito de alguma forma. Veja a citação abaixo.). CORBA, SOA e afins trilharam ou tentam trilhar ainda esta senda no meio de abissais complicações.

The idea was so obvious that IBM declined to patent the new approach, calling it “much more like a law of nature” than a new invention, according to Morrison. Instead, the company published FBP as a technical disclosure bulletin, effectively making it public domain. And yet, except for a few rare applications like the Canadian bank, it never really caught on.

How An Arcane Coding Method From 1970s Banking Software Could Save The Sanity Of Web Developers Everywhere

John Paul Morrison, em seu livro sobre Flow-Based Programming, comenta sobre sua visão a respeito das técnicas de prototipação. Como eu gosto de prototipação em Engenharia de Software (por isso gosto do Smalltalk) resolvi traduzir o trecho que coloco abaixo:

A prototipagem rápida e a idéia relacionada de desenvolvimento iterativo foram ( e ainda são) outro entusiasmo dos meus. A prototipagem rápida é um processo de redução das incertezas no processo de desenvolvimento , tentando coisas. Eu acredito que qualquer coisa sobre a qual você não tem certeza deveria ser um protótipo: algoritmos complexos, hardware não familiares,estruturas de bases de dados, interfaces humanas ( especialmente! ), e assim por diante. Eu acredito que esta técnica se tornará ainda mais importante em poucas décadas à medida que nos movemos para ambientes cada vez mais complexos. Aqui, novamente, teremos que modificar ou até mesmo abandonar as velhas metodologias. O livro de 1993 de Dave Olson, “Explorando Chaos: Lucrando com sobre a realidade do desenvolvimento de software” (Exploiting Chaos: Cashing in
on the Realities of Software Development
) , descreve uma série de abordagens para combinar desenvolvimento iterativo com marcos para obter o melhor dos dois mundos, além de algumas fascinante digressões em novos conceitos de caos e “atratores estranhos”. Há alguns atratores muito estranhos em nosso negócio! Eu também acreditava há algum tempo que a maioria dos protótipos não deve apenas ser jogado fora depois de terem servido o seu propósito . Um protótipo deve ser capaz de se tornar “adulto”, passo a passo, e um sistema completo. Uma vez que a importância de protótipos é que reduzem incerteza, reescrever aplicações em uma linguagem diferente é susceptível de trazer um monte [de incerteza] de volta!

Flow-Based Programming lembra fortemente o conceito de Lego Programming. E também o Actor Model – que foi no que se baseou a implementação inicial do Smalltalk onde os objetos eram ativos (processos ou threads para cada objeto) e não passivos como agora é usual. A linguagem Linda – piadas a parte sobre ser uma homenagem a Linda Lovelace, a primeira programadora e filha de Lord Byron, ou aquela do filme Deep Throat – é citada por Morrison como bem próxima, conceitualmente, do Flow-Based Programming. Programas de simulação em geral, e em particular o Modelica, também usam abordagem similar.

Não se influencie pela palavra programming no título deste post. O conceito de Flow-Based Programming é bem abrangente e, na verdade, pode ser mapeado perfeitamente nas linguagens usuais de descrição de processos de forma bidirecional, eu diria. Flow-Based Programming é um conceito arquitetural anti-Von Neumann que pode usar ambientes existentes onde o paralelismo de processos já é a tônica como os pipes dos sistemas UNIX (NextFlow) ou mesmo interpretar os diagramas de fluxo do BPM (Esta impressão fica bem nítida ao ver o vídeo Morphic BPM) como Flow-Based Programming embora com um drill-down limitado em relação às possibilidades do negócio chegar próximo ao “chão de fábrica”, digamos assim, atapetados, metaforicamente, de componentes atômicos. Flow-Based Programming é uma linguagem com que o pessoal de negócio, que já entende de processos, vai ter uma empatia imediata. John Paul Morrison propõe que os usuários vão projetar os sistemas com os blocos que os programadores vão construir conforme uma especificação dada a eles pelo pessoal de negócio. Cita claramente o sonho do Legoland Programming. A idéia de tornar a programação mais palatável para leigos já teve várias abordagens e uma delas que pode ser bem atrativa para crianças é o Scratch, desenvolvido para o Squeak (uma versão do Smalltalk originada na Apple e na Disney – por isso o colorido). O projeto de fluxogramas, abandonados pelos programadores que preferem ler textos, é bastante popular no negócio para a descrição de processos em detalhes envolvendo pontos de decisão, bifurcações etc.

Abaixo, a título de ilustração, coloco imagens de sistemas que já embutem programação visual de fluxos de dados de forma similar a Flow-Based Programming (e são fonte de inspiração para aqueles que estão redescobrindo o conceito, como ocorreu em relação ao Quartz Composer e o NoFlo). Mas o insight sobre usar isto como arcabouço para desenvolver software numa nova proposta de arquitetura, apesar de não ser inédito, ainda precisa “pegar”.

Lego Programming

Quartz Composer

Modelica

NoFlo

Uma coisa que Flow-Based Programming tem em comum com o Smalltalk é uma parcimônia de conceitos que servem de blocos de construção para sistemas complexos. Esta economia tem conseqüência direta na produtividade porque incentiva a experimentação e libera a criatividade. Combinar coisas simples e bem comportadas (previsíveis) é mais fácil que combinar coisas complexas. Em Smalltalk tudo é objeto. Objetos, obviamente, classes, mensagens, closures (blocks) são objetos. Smalltalk foi consequência da idéia de especificar uma linguagem de programação em uma única página. E não foi com letras miúdas.

The second bet had even more surprising results. I had expected that the new Smalltalk would be an iconic language and would take at least two years to invent, but fate intervened. One day, in a typical PARC hallway bullsession, Ted Kaeh;er, Dan Ingalls, and I were standing around talking about programming languages. The subject pf power came up and the two of them wondered how large a language one would have to make to get great power. With as much panache as I could muster, asserted that you could define the “most powerful language in the world” in “a page of code.” They said, “Put up or shut up.”

THE EARLY HISTORY OF SMALLTALK

A linguagem Smalltalk tem apenas seis palavras chaves: true, false, nil,self, super, e thisContextE os objetos só se comunicam por mensagens que acionam métodos. Em Flow-Based Programming o vocabulário também é limitado: Component, Connection, Packet (Information Packet – IP), e Port. A implementação usando object-oriented programming usa uma classe cujas instâncias das subclasses (os componentes) são objetos que executam um laço infinito e só se comunicam com exterior através de suas portas (Ports) de entrada e saída. As portas estão nas extremidades da conexões (Connections) interligando os componentes. Os  pacotes (Packets) circulam numa única direção (de uma porta de saída de um componente para uma porta de entrada de um componente distinto). Cada componente é uma thread (ou processo) que “acorda” quando há pacotes a processar nas portas de entrada e “dormem” em caso contrário. Em relação aos pacotes um componente só pode fazer três coisas: criar, destruir ou enviar os pacotes por uma porta de saída. E os componentes ou são atômicos ou compostos de outros componentes configurados em uma rede interna que os conecta. Um modelo simples assim é extremamente palatável aos usuários e encorajam o Lego Programming. O poder de uma tal abstração é tremendo e está gerando um frisson na Internet. Vamos ilustrar uma possibilidade a título de exercício. A figura abaixo é bastante conhecida no mundo dos analistas e projetistas de processo. Vou usá-la para ilustrar uma possibilidade de uso conceitual na implementação dos componentes.

Imagine o componente abaixo com quatro tipos de portas: três de entrada e uma saída.

idef0

As portas Inputs e outputs dispensam comentários. Mas o que são as outras duas? Podemos imaginar que constraints pode ser implementado como uma porta que vai ser usada para configurar o componente para atender restrições. As restrições podem ser “injetadas” nesta porta (ou conjunto de portas) em forma de um componente ou de uma especificação a ser instanciada no ambiente interno do componente. Infra structure representa o que o componente precisa para executar. Novamente, podem ser bibliotecas encapsuladas em um componente ou pacote a serem instanciadas no ambiente interno do componente.

Quando vi que a minha licença médica já estava terminando e o meu tempo livre prestes a escassear corri e comecei a codificar furiosamente no Pharo Smalltalk obtendo uma primeira versão funcional em poucos dias – graças à incrível produtividade auxiliada pelo IDE do Smalltalk, especificamente do Pharo 3 – nova versão que comecei a experimentar. Esta saga, recheada de entusiasmo, pretendo relatar aqui nesta série de posts. Farei isto em paralelo com a construção gradual do código em Smalltalk. Enquanto isto larguei um pouco o Javascript. Smalltalk is a drug!

Nota: No meu afã de implementar logo um protótipo não tive tempo de ler as discussões e polêmicas sobre a melhor forma de implementar cada conceito. Nos trabalhos futuros pretendo corrigir algumas coisas e implementar outras que foram omitidas.


Anúncios

7 Respostas para “SmallFBP: a Smalltalk framework for Flow-Based Programming

  1. Pingback: SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 2 | Crab Log

  2. Pingback: SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 3 | Crab Log

  3. Pingback: Mudança de paradigma no desenvolvimento de software | Crab Log

  4. Pingback: SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 4 | Crab Log

  5. Pingback: Shared Bounded Queue in Pharo Smalltalk | Crab Log

  6. Pingback: SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 5 | Crab Log

  7. Pingback: Introdução ao Pharo | Crab Log

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s