SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 5

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. Introdução
    2. OddFilter
    3. Numbers
    4. MaxNumberIIP
    5. Printer
    6. Dropper
    7. Filter GUI
  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

Componentes compostos

Introdução

Uma das características mais importantes de um sistema de desenvolvimento de software é a possibilidade de reutilização de código. Flow-Based Programming utiliza componentes compostos que abrigam uma rede interna de componentes. Esta rede interna é uma subnet, conceito de Flow-Based Programming que agrupa componentes conectados  que recebem entradas em portas externas  e enviam pacotes para portas externas. Estas portas externas de entrada e saída mapeam portas de componentes na subnet adaptando os nomes das portas na subnet para serem usados do exterior.

Subnet

subnet

O diagrama acima mostra uma subnet “My First Subnet” confinada por uma linha tracejada que delimita a fronteira da subnet. Na fronteira ficam as portas externas de entrada e de saída. A classe FBPSubnet, uma subclasse de FBPDriver que, por sua vez, descende de FBPNetwork, implementa a DSL (Domain Specific Language: técnica já usada em Method Wrapper in Pharo/Smalltalk III) para configuração e uso da subnet. As portas externas foram implementadas como componentes que adaptam o exterior ao interior da subnet mapeando os nomes das portas.

Vamos descrever sucintamente a subnet do diagrama acima que serviu de exemplo para guiar a implementação. No interior da subnet há dois componentes. Uma instância de FBPPipeline, componente que transfere os pacotes da entrada para a saída sem nenhum processamento, e uma instância de FBPDisplay, componente que exibe uma representação dos pacotes lidos da entrada numa janela e, se a porta opcional de saída estiver conectada, os despacha para a porta de saída. Se a porta de saída não estiver conectada os pacotes são descartados. A porta externa de entrada EIN (um componente) mapeia os pacotes recebidos em sua porta #EIN para a sua porta de saída #OUT, que por sua vez está conectada à porta #IN de um componente FBPPipeline no interior da subnet. A porta externa de saída EOUT recebe pacotes na sua porta #IN vindos da conexão com a porta #OUT de um componente FBPDisplay no interior da subnet. A porta externa EOUT repassa os pacotes recebidos do interior da subnet a sua porta #EOUT. Assim a subnet pode ser vista como um componente que possui porta de entrada #EIN, porta de saída #EOUT, e transmite os pacotes recebidos sem alteração mas exibindo uma representação dos mesmos em uma janela. Este é o efeito da combinação dos elementos internos da subnet em questão.

Externamente à subnet temos um componente FBPNumbers que gera uma quantidade de números inteiros e outro componente FBPDisplay. O primeiro componente está conectado à porta #EIN da subnet e o segundo à porta #EOUT da subnet. O efeito da execução do rede FBP está mostrado na imagem abaixo:

subnet-first-displays

A configuração e execução da rede é feita pelo código abaixo (no estilo DSL):

subnet-first-DSL-code

O estilo DSL da API para subnet torna clara a intenção do código que configura a subnet. A subnet possui um método #start que ativa todos os componentes internos e portas externas (que são componentes também). Graças ao polimorfismo duck typing a subnet se comporta, pelo menos para ser ativada, como um componente o qual responde ao método #start. “Se grasna, então é um pato.”

Vamos montar uma segunda subnet com mais portas conforme o diagrama abaixo:

subnet-second

A subnet acima tem quatro portas externas. FairMerge é um componente que “mistura com justiça” duas streams chegadas nas sua portas de entrada de tal forma que preserva a ordem de chegada dos pacotes na sua saída. OddFilter já é um velho conhecido nosso e foi introduzido na parte 3 desta série de posts.

O efeito da execução  está mostrado abaixo:

subnet-second-displays

O código segue abaixo:

subnet-second-code

Composição

composite

O resultado da execução do composite criado com a subnet anterior no seu interior é o mesmo de antes:

composite-displays

A rede raíz (root network) que usa o composite em lugar da subnet (que agora está instanciada em seu interior) é a seguinte:

network-with-composite

O composite usado na rede acima é uma instância da classe FBPCompositeExample que, por sua vez, é uma subclasse de FBPComposite. Veja abaixo a situação na hierarquia de herança:

composite-hierarchy

As subclasses de FBPComponent e FBPComposite devem implementar métodos abstratos. O método abstrato #portNamesAndTypes de FBPComponent deve ser implementado por todos os componentes para retornar um array com os nomes das portas e tipos. As instâncias de FBPComposite herdam também esta obrigação de implementar o método mas o implementa assim:

composite-portNamesAndTypes-method

O métodos #portNamesAndTypes é invocado durante a criação das portas em FBPComponent>>#createPorts durante a inicialização. Veja abaixo o FBPPipeline>>#portNamesAndTypes:

pipeline-portNamesAndTypes

Mas para composites o método não é usado por FBPComposite>>#createPorts porque as portas são obtidas das portas externas já criadas na subnet:

composite-createPorts

O método abstrato FBPComposite>>#subnet deve ser implementado nas subclasses para construir a instância da subnet de cada composite.

composite-subnet-override-abstract-method

Os métodos #closeAllInputPorts e #processSendEndOfDatasAndCloseOutputPorts de FBPComponent tiveram overrides em FBPComposite que nada executam para deixar a responsabilidade de fechar portas e enviar end of datas para a subnet.

Os códigos podem ser obtidos no repositório do projeto (Ver no final do primeiro post).

Agora está iniciada a temporada de caça para matrioska programming.

Anúncios

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

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

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

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

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

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

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

  7. Pingback: SmallFBP: a Smalltalk framework for Flow-Based Programming – Part 8 | 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