Arquitetura e Implementação

A arquitetura do IDEA4WSN (Figura 6.4) é composta pelos módulosDesenvolvimento, AplicaçãoeRede. Em todos os componentes foram utilizadas as mesmas tecnologias:

JSP (Corporation, 2014) para criar as telas de exibição; JQuery (jQuery Foundation., 2014) para melhorar a interação do usuário com o ambiente de desenvolvimento; Twitter Bootstrap (Twitter, 2014) para melhorar a aparência do ambiente; o Spring (GoPivotal, 2014) para tratar as requisições do usuário no servidor; e o JFreeChart (Limited, 2014) para gerar os gráficos (relatórios). As telas do editor podem ser vistas no Apêndice A.

Figura 6.4 Arquitetura do IDEA4WSN.

O móduloDesenvolvimentoé responsável por oferecer funcionalidades básicas para os outros módulos. Por exemplo, uma de suas funções é identificar o usuário logado, facilitar o acesso aos projetos independente de onde eles estejam armazenados, implementar a interface básica da IDEA4WSN, executar atividades que levam longo tempo para serem concluídas (e.g., avaliar do consumo de energia da aplicação e/ou da rede) em segundo plano e, por fim, configurar o ambiente.

Para facilitar o desenvolvimento das aplicações, foi desenvolvido o móduloAplicação.

Ele possui um pacote chamado Desenvolvedor responsável por destacar as palavras chaves (através de uma extensão do JQuery chamada ACE Editor (IDE, 2014)), validar o código e sugerir correções de erros. Essas características atendem aos requisitos do ED01 ao ED03. Além disso, esse módulo é responsável por avaliar uma aplicação ou parte dela (pacoteAvaliador), sugerir modificações (pacoteProponente de Sugestões) para diminuir o consumo de energia (veja a Seção 6.3.3) e mostrar os resultados da avaliação, atendendo aos requisitos do ED04 ao ED07. Esse módulo utiliza o gerenciador para

algumas atividades mencionadas anteriormente.

O móduloRedeé responsável pelo editor de rede e pelas funcionalidades a fim de avaliar o seu consumo de energia e a sua confiabilidade. Ele foi construído para atender aos requisitos do ED08 ao ED11 e consiste em três partes: o pacote Desenvolvedor, responsável pela representação visual do editor e sugestões de otimizações; o pacote Avaliador, responsável pela avaliação da energia e da confiabilidade e responsável por elaborar os relatórios após as avaliações; e o pacote Analisador de Sensibilidade é responsável por fazer análise de sensibilidade dos parâmetros escolhidos pelo usuário.

O módulo Avaliador é responsável por interagir com o gerenciador, enviando e recebendo informações sobre as avaliações.

Entre os pacotes implementados, as sugestões (do móduloAplicação) são as mais importantes por tornar o ambiente de desenvolvimento ciente de energia. Por este motivo, a próxima seção irá explicar quais foram as sugestões implementadas na aplicação.

6.3.3 Sugestões

As otimizações implementadas no editor da aplicação reduzem o consumo de energia da aplicação e não alteram a sua lógica. Individualmente, estas otimizações não representam um ganho significativo de energia (apenas microjoules). No entanto, se uma função otimizada for executada diversas vezes, esse ganho pode se tornar significativo. Além disso, essas sugestões são genéricas o suficiente para serem usadas em qualquer aplicação.

Ao todo, foram implementadas cinco otimizações, as quais são apresentadas a seguir.

Figura 6.5 Exemplo de código otimizado sem parêntese.

A primeira sugestão (OT01) é evitar o uso de parênteses em operações matemáticas para não forçar uma mudança de prioridade de execução. Para isso, é recomendado tratá-los em outro lugar, atribuindo o valor a uma variável (veja a Figura 6.5). Essa substituição, um parâmetro por uma atribuição, é recomendada pelo fato de a atribuição consumir menos energia do que os parênteses.

A segunda sugestão (OT02) está relacionada à estrutura de repetiçãofor. É reco-mendado evitar o uso dessa estrutura para iniciararraysde tamanho fixo. Em vez disso, é sugerido atribuir individualmente os valores dos elementos doarray. A Figura 6.6 ilustra

6.3. EDITOR

Figura 6.6 Exemplo de código otimizado semfor.

dois códigos, o original e a sua versão otimizada.

Figura 6.7 Exemplo de código reordenando os ramos de umif-then-else.

A terceira sugestão (OT03) está relacionada a outra estrutura muito utilizada, o if-then-else. Essa estrutura pode ser otimizada da seguinte forma: os ramos (if, else if else), que possuem maior probabilidades de serem executados, devem ser colocados primeiro. O usuário informa a probabilidade do ramo de ser executado através da expressão//valor(como foi mencionado na Seção 5.2.1). Por exemplo, na Figura 6.7 o código original (a) possui um if-then-else com 3 ramos: o primeiro com 10%, o segundo, 30% e o terceiro, 60% de ser executado. A versão otimizada (b) muda a ordem em que os ramos aparecem: o ramo com maior probabilidade vem primeiro.

Figura 6.8 Exemplo de código reduzindo o incremento do valor 1 à uma variável.

A quarta sugestão (OT04) está relacionada ao incremento de uma variável. A ex-pressão completa (var = var + 1) consome mais energia do que sua versão simplificada (var++), como é mostrado na Figura 6.8.

A última sugestão (OT05) está relacionada com a melhor forma de atribuir um valor a uma variável. É recomendado atribuir um valor fixo/constante a uma variável ao invés de outra variável. Caso seja utilizada uma variável e essa variável não mude de valor ao longo do tempo, é recomendado torná-la uma constante. Por exemplo, a Figura 6.9, em especial o código original (a), ilustra o cálculo do comprimento de um círculo, em que o valor deπ (variável PI) é sempre o mesmo. Então, é recomendável que a variável PI seja uma constante, como ilustra o código otimizado (b).

Figura 6.9 Exemplo de código transformando uma variável em constante.

6.4 Tradutor

O tradutor, por sua vez, chamado de Sensor2Model, é responsável por traduzir o código fonte da aplicação escrito em nesC em um Modelo de Aplicação; e a configuração da RSSF em um Modelo de Rede e um Modelo de Região. Ele também integra o Modelo de Aplicação com o Modelo de Rede, criando o Modelo de Nó Sensor. A arquitetura do Sensor2Model é ilustrada na Figura 6.10.

Figura 6.10 Visão geral da arquitetura do tradutor.

O Sensor2Model é divido em 4 módulos: Serviço, Aplicação, Redee Região. O móduloServiçorecebe os dados do gerenciador (por exemplo, código da aplicação e configuração da RSSF) e repassa-os para o módulo correspondente. A interface abaixo é implementada por este módulo:

1 public interface Tradutor {

2 public void modeloDeAplicacao( Informacao inf );

3 public void modeloDeRede ( Informacao inf );

3 public void modeloDeNoSensor ( Informacao inf );

4 public void modeloDeRegiao ( Informacao inf );

5 }

6.5. AVALIADOR

Esta interface possui quatro métodos, um para cada modelo; por exemplo, o método modeloDeAplicacaoirá repassar para o móduloAplicaçãopara criar o Modelo de Aplica-ção. Todos os métodos recebem o mesmo objeto, mas com informações diferentes. Por exemplo, omodeloDeAplicacaoirá receber informações relacionadas à aplicação escrita na linguagem nesC; enquanto omodeloDeRedeirá receber do editor sobre a RSSF.

Além disso, esta interface é responsável por intermediar as ações entre os módulos.

Por exemplo, para gerar o Modelo de Nó Sensor, o método modeloDeNoSensor implementado pelo móduloServiço, primeiro acessa o móduloAplicação, simplifica-o (usando o sub-móduloSimplificação) e, depois, integra-o com o móduloRede(através do móduloIntegração). Ou, então, após executar o Modelo de Rede, o consumo de energia avaliado é repassado para aRegiãopara simular a confiabilidade da RSSF.

Os outros três módulos (Aplicação, Redee Região) possuem comportamentos si-milares. Cada um irá converter um modelo (sub-módulo Tradutor). Por exemplo, o móduloAplicaçãoestá relacionado com o Modelo de Aplicação; o móduloRede, com o Modelo de Rede; e o móduloRegião, com o Modelo de Região. Em especial, os módulos AplicaçãoeRedepossuem os sub-módulosSimplificadoreIntegrador, respectivamente, para gerar o Modelo de Nó Sensor. Todos esses módulos irão utilizar o gerenciador para notificar que os modelos foram criados. Além disso, enquanto os Modelos de Operadores e de Protocolos irão fazer parte do Modelo de Aplicação e de Rede (respectivamente), os algoritmos de roteamento irão auxiliar na criação do Modelo de Região, como foi mencionado na Seção 5.4.

6.5 Avaliador

O avaliador, chamado de Vident (Vident is EDEN Evaluator), utiliza outros programas, e.g., CPN Tools e Mercury, para avaliar os modelos. Ele atua como ponte entre o tradutor e os programas que irão avaliar de fato os modelos.

A arquitetura do Vident possui apenas três módulos (veja a Figura 6.11). O módulo Serviçoé responsável por oferecer uma única interface para avaliar tanto o consumo de energia quanto a confiabilidade da RSSF. Essa interface é mostrada abaixo:

1 public interface Avaliador {

2 public void consumoDeEnergia( Informacao inf );

3 public void confiabilidade ( Informacao inf );

4 }

Ao receber uma requisição, oServiçorepassa a chamada para o módulo apropriado, o qual irá avaliar o consumo de energia (o módulo Consumo de Energia) ou a

confia-Figura 6.11 Visão geral da arquitetura do avaliador.

bilidade (o móduloConfiabilidade). O móduloConsumo de Energiaé responsável por interagir com o CPN Tools (Westergaard and Verbeek, 2014), utilizando o Access/CPN (Westergaard, 2011), para avaliar os modelos CPN criados pelo tradutor. Por fim, o móduloConfiabilidadeutiliza o Mercury (Silvaet al., 2013) para avaliar a confiabilidade usando os modelos RBDs criados pelo tradutor.

É importante perceber que os métodos não retornam nenhum dado, porque o processo de avaliação é assíncrono: quando a avaliação terminar, o avaliador notifica o gerenciador através do componenteResultado. Este componente está presente nos módulosConsumo de EnergiaeConfiabilidade.

6.6 Gerenciador

A arquitetura do gerenciador já foi apresentada na Figura 6.3 e, por este motivo, não será apresentada novamente nesta seção. Em vez disso, nós iremos complementar as informações ditas anteriormente. Cada módulo do gerenciador (Gerenciador de Avaliação eGerenciador de Ciclo de Vida) implementam uma interface para se comunicar com as demais ferramentas do EDEN. As duas interfaces implementadas são mostradas abaixo:

01 public interface Ferramenta { 02 public void addEditor ();

03 public void addTradutor ();

04 public void addAvaliador();

05 } 06

07 public interface Avaliacao {

6.7. CONSIDERAÇÕES FINAIS

08 public void edicaoConcluida ( Informacao inf );

09 public void traducaoConcluida ( Informacao inf );

10 public void avaliacaoConcluida( Informacao inf );

11 }

A interfaceFerramentaé implementada pelo móduloGerenciador de Ciclo de Vidae é utilizada para adicionar uma instância do editor (linha 2), tradutor (linha 3) ou avaliador (linha 4). Toda vez que uma ferramenta é instanciada, ela deve notificar o gerenciador através dessa interface. O gerenciador é responsável por identificar qual ferramenta se conectou a ele através dos métodos da interface. Por exemplo, o método addEditor significa que um editor acabou de se conectar ao gerenciador. Além disso, cria-se um canal bidirecional entre a ferramenta e o gerenciador. Essa característica permite que o gerenciador utilize a conexão já existente para enviar ou receber notificações do processo de avaliação. Por exemplo, quando o avaliador conclui uma avaliação, ele envia uma notificação por este canal já estabelecido, acionando a interfaceAvaliacao.

A interface Avaliacao é utilizada para gerenciar a avaliação e está implementada ao módulo Avaliação. Os métodos desta interface indicam qual etapa foi finalizada.

Quando um desses métodos é chamado, o gerenciador fica responsável por repassar para a próxima etapa. Por exemplo, quando o métodoedicaoConcluidaé chamado, o gerenciador repassa as informações recebidas para o tradutor criar os modelos. Quando os modelos são criados, o métodotraducaoConcluidaé executado, dando início à etapa de avaliação, e assim por diante. Adicionalmente, o móduloGerenciador de Avaliação utiliza as informações no móduloGerenciador de Ciclo de Vidapara repassar os dados entre as instâncias das ferramentas.

6.7 Considerações Finais

Este capítulo apresentou o EDEN (Evaluation and Development Environment for Wireless Sensor Network), o qual foi desenvolvido para ser executado em um ambiente de nuvem.

O EDEN é composto por quatro ferramentas: editor, tradutor, avaliador e gerenciador. O editor, chamado de IDEA4WSN (Integrated Environment for Developing Energy-Aware Applications for WSN), é responsável por facilitar o desenvolvimento da aplicação e da configuração da RSSF. Além disso, ele oferece um mecanismo que avalia o que está sendo feito e sugere melhorias no código fonte, buscando melhorar o consumo energético. Outra funcionalidade do editor é mostrar para o usuário quais são os parâmetros ideais para a RSSF logo após o usuário informar um conjunto de elementos (e.g., protocolo, tamanho da rede e entre outras coisas). O tradutor (chamado de Sensor2Model) é utilizado para

traduzir o código da aplicação e a configuração da RSSF para os modelos de energia e confiabilidade apresentados anteriormente. Por sua vez, o tradutor necessita do avaliador, chamado de Vident (Vident is EDEN Evaluator), para avaliar os modelos gerados. Para intermediar a comunicação entre essas três ferramentas, existe o gerenciador. Por fim, o editor mostra para o usuário relatórios dos modelos avaliados.