Estrutura de arquivos

A estrutura de arquivos do framework é apresentada da seguinte forma: na raiz, o arquivo nop.ex que possui as definições de módulo. Em seguida, dentro da pasta lib estão os arquivos application.ex e dummy.ex que apresentam, respectivamente, as

definições da aplicação e uma demonstração de utilização do framework para uso em TDD (Test Driven Development). A Figura 62 apresenta a estrutura de arquivos do

framework NOP Elixir.

Figura 62. Estrutura de arquivos do framework NOP Elixir

Fonte: Autoria própria

A seguir, as subpastas element e service separam os desenvolvimentos dos elementos do framework dos elementos auxiliares conforme definido na seção 4.2.1. Desta forma, os arquivos carregam as implementações dos módulos conforme Tabela 12.

Tabela 12. Organização dos módulos desenvolvidos por pasta e arquivo

Pasta Arquivo Módulo

service base.ex NOP.Service.ServiceBase

service condition.ex NOP.Service.Condition

service fbe.ex NOP.Service.FBE

service premixe.ex NOP.Service.Premise

element base.ex NOP.Element.ElementBase

element condition.ex NOP.Element.Condition

element fbe.ex NOP.Element.FBE

element logic_element.ex NOP.Element.LogicElement element premise.ex NOP.Element.Premise

element rule.ex NOP.Element.Rule

4.3.4 Elementos do paradigma PON

Os elementos do PON são encontrados na pasta element dentro da estrutura de arquivos do framework. Encontrado no arquivo base.ex, o primeiro módulo do qual derivam todos os demais módulos é o NOP.Element.ElementBase que implementa o elemento UML ElementBase.

Em seguida, o apresenta-se o módulo NOP.Element.FBE, que é encontrado no arquivo fbe.ex e implementa o elemento UML FBE. Este módulo e é uma especialização25 _{de NOP.Element.ElementBase juntamente com GenServer}26 (THOMAS, 2018, p. 229-242). O Código 2 apresenta um trecho do código deste módulo. Este exemplo é o processamento da mensagem set_attr, que corresponde à implementação do método set_attribute definido na modelagem UML para a classe

FBE.

25 _{Em Elixir, uma forma de se representar a especialização é através do comando use (THOMAS, 2018)} 26 _{O módulo GenServer implementa um servidor genérico de forma a incorporar comportamentos} padrões como, facilidade para tratamento de mensagens e rastreamento e relatório de erros.

Código 2. Implementação de trata mento da mensagem set_attribute em microator FBE na linguagem Elixir

Fonte: Autoria própria

Quando da declaração de um FBE, portanto, é necessário implementar a função

init_attributes() com a inicialização dos Attributes. Também é neste momento que são

implementados os demais métodos inerentes ao FBE. O Código 3 apresenta um exemplo de uma implementação de um FBE completo com a definição dos Attributes definida na função init_attributes(), bem como uma função change_value_to3() representando um Method específico do FBE.

Código 3. Exemplo de implementação de FBE como especialização do módulo

NOP.Element.FBE

Fonte: Autoria própria

Na sequência, o módulo NOP.Element.LogicElement é o módulo base que serve de ancestral comum de todos os elementos lógicos, a saber (Premise, Condition e

Rule). Também especializado de NOP.ElementBase está declarado no arquivo logic_element.ex e é responsável por implementar o elemento UML LogicElement.

O elemento UML Premise é implementado no framework pelo módulo

NOP.Element.Premise e encontra-se no arquivo premise.ex e é especializado de Genserver e PON.Element.LogicElement.

Conforme descrito na seção 4.2.1, os elementos PON Condition e Subcondition foram condensados em um único elemento UML Condition. Este, por sua vez, é implementado no módulo NOP.Element.Condition e se encontra no arquivo

condition.ex trazendo todos os comportamentos de ambos os elementos PON.

Finalizando a lista de especializações de NOP.Element.LogicElement está o módulo NOP.Element.Rule que implementa o elemento UML Rule e se encontra no arquivo rule.ex. O Código 4 apresenta um exemplo de implementação de uma Rule completa.

Código 4. Exemplo de implementação de Rule como especialização de NOP.Element.Rule

Fonte: Autoria própria

O elemento UML Instigation não necessitou da construção de um módulo próprio, pois todo o comportamento esperado pode ser aproveitado por meio de Tasks (THOMAS, 2018, p. 293).

4.3.5 Elementos complementares

Dos elementos complementares, o primeiro módulo que é apresentado é o módulo NOP.Application. Especializado de Application27 (THOMAS, 2018, p. 277-278) este módulo é responsável por supervisionar os demais módulos de serviço que serão apresentados a seguir. Este módulo também encapsula algumas funções de tratamento de conjunto de atores a fim de trazer mais simplicidade na utilização do

framework. Este módulo encontra-se no arquivo application.ex e é o único dos listados

nesta seção que não se encontra dentro da pasta service. O Código 5 apresenta o

27 _{O módulo Application permite o empacotamento de softwares desenvolvidos na plataforma Erlang.} Estes são semelhantes ao conceito de biblioteca, comuns em outras linguagens de programação, mas com características próprias desta plataforma. Neste módulo implementam-se funcionalidades como ciclo de vida da aplicação, que pode então ser carregada, iniciada e interrompida.

trecho de inicialização deste módulo. Nesta etapa os serviços complementares são, então, iniciados e ficam sob sua supervisão.

Código 5. Trecho de código de inicialização do módulo Application do framework

Fonte: Autoria própria

O próximo módulo é o módulo NOP.Service.ServiceBase. Este módulo encontra- se no arquivo base.ex dentro da subpasta service. Este módulo é responsável por implementar o elemento UML ServiceBase e traz as funcionalidades comuns a todos os serviços.

O módulo NOP.Service.FBE é encontrado no arquivo fbe.ex. Especializado de

NOP.Service.ServiceBase e GenServer é o primeiro singleton inicializado por NOP.Application. Além de trazer facilidades de programação simplificando chamadas

para os elementos do paradigma, este se comporta como um supervisor de todos os elementos NOP.Element.FBE criados durante uma execução do framework.

A seguir, o módulo NOP.Service.Premise, também singleton, responsável por supervisionar e trazer simplificações de chamadas aos elementos

NOP.Element.Premise. Localizado em premise.ex e especializado de NOP.Service.ServiceBase e GenServer, também é inicializado e supervisionado por NOP.Application na inicialização da aplicação.

Da mesma forma, o módulo NOP.Service.Condition é responsável por supervisionar e trazer simplificações de chamadas aos elementos

NOP.Element.Condition. Localizado em condition.ex e especializado de NOP.Service.ServiceBase e GenServer é o terceiro supervisor singleton inicializado

por NOP.Application.

Por fim, o último singleton inicializado por NOP.Application encontra-se no módulo NOP.Service.Rule. Este é codificado no arquivo rule.ex e também, como os demais supervisores, é especializado por NOP.Service.ServiceBase e GenServer. Desta forma, uma aplicação que utiliza o Framework NOP Elixir terá sempre, e no mínimo, seis processos supervisores iniciados para gerenciar os processos relacionados ao paradigma, são eles: NOP.Application, NOP.Supervisor,

NOP.Service.FBE, NOP.Service.Premise, NOP.Service.Condition e NOP.Service.Rule. A Figura 63 apresenta a aplicação sendo executada com o Framework NOP Elixir conforme hierarquia de supervisão. O primeiro nó (ID

<0.264.0>) é o processo raiz, criado pela VM para todo aplicativo Erlang; o segundo nó (ID <0.265.0>) corresponde ao módulo inicial da aplicação disponibilizada pelo

Framework NOP Elixir, ou seja, NOP.Application; em seguida, o processo Supervisor

e os processos de gerenciamento dos demais elementos PON.

Figura 63. Estrutura de aplicações supervisoras em uma aplicação NOP Elixir