Cenários de mudança

Nesta subseção são discutidos quatro cenários de mudanças (denotados por

SC), os quais representam situações típicas em ambientes de RSASF, sendo

elas: (i) mudança do protocolo de comunicação adotado na rede; (ii) mudança dos requisitos da aplicação; (iii) desenvolvimento de uma nova aplicação para a

93

mesma plataforma de RSASF; e (iv) execução da aplicação em uma plataforma de RSASF diferente.

SC1. Mudança de protocolos de nível de rede. Há diversos protocolos

especificamente projetados para RSSF [LEVIS, 2006], cada um mais adequado para diferentes topologias e atendendo diferentes requisitos de QoS. Uma mudança de topologia da rede ou da densidade dos nós instalados pode demandar a escolha de um novo protocolo para executar nos sensores. Utilizando a presente proposta, caso haja a necessidade de alteração do protocolo de rede usado, o especialista de redes teria que realizar mudanças no modelo PSM da aplicação gerado, durante a atividade “Refinar Modelo”. Para mudar o protocolo faz-se necessária uma atualização no PSM que foi gerado automaticamente pelo processo MDA. Esta atualização é composta de três fases: a primeira é a remoção dos métodos, responsáveis pelo protocolo de rede, que estão declarados, mas que não serão mais utilizados; a segunda é a adição de novos métodos que implementam o novo protocolo necessário; e a terceira, é refazer o construtor da classe atualizando o fluxo do programa.

É importante observar que todos os aspectos relacionados ao domínio ficam totalmente transparentes ao especialista de redes no momento da troca de protocolo, fazendo com que todas as mudanças realizadas neste nível sejam claramente separadas da modelagem feita pelo especialista de domínio.

SC2. Mudança dos requisitos da aplicação. Em caso de mudanças nos

requisitos da aplicação, serão necessárias mudanças ao nível do modelo PIM, realizadas pelo especialista de domínio. Um caso típico de mudança consiste nos requisitos de QoS da aplicação. Supondo a aplicação de SHM, se ao longo do monitoramento e análise de dados for detectada uma situação de dano potencial em uma estrutura, passa a ser mais relevante ter uma resposta rápida da rede em vez de aumentar seu tempo de vida. Tal requisito pode ser traduzido para uma alteração na política de energia e na taxa de envio de dados. Para alterar a política de energia tudo que o especialista de domínio

94

precisa fazer é modificar o valor do ciclo de trabalho do elemento

RadioConfigUnit. Para mudar a taxa de envio de dados, o especialista de

domínio terá apenas que alterar o valor do temporizador TimerUnit que controla o tempo de espera antes de cada envio de dados. Desta, forma a transformação M2M irá gerar o modelo PSM utilizando as configurações que condizem com a escolha do especialista. Todas estas alterações podem ser efetuadas sem a participação do especialista de redes.

SC3. Nova aplicação. Este cenário ilustra o reuso obtidos dos artefatos em

nível de plataforma quando uma nova aplicação é modelada em uma plataforma que é especifica na infraestrutura MDA utilizada. Uma aplicação pertencente ao domínio de monitoramento de desastres ambientais, especificamente de detecção de queimadas é considerada neste cenário. Em [FARIAS, 2005] é descrita uma aplicação para monitorar queimadas baseada no uso de 50 sensores. Resumidamente, os sensores são divididos em dois grupos: no primeiro, com 49 sensores, os nós foram distribuídos pela floresta a fim de coletar os dados e enviá-los para o sorvedouro; no segundo grupo um nó, o sorvedouro, recebe os dados enviados pelos nós sensores e envia-os para um computador externo através de uma conexão USB. Para esta aplicação (Figura 5-2), foram criadas duas regiões representando a área sensoreada e a área ocupada pelo nó sink, respectivamente. Para a área sensoreada, região sensing, um grupo de nós (sensingForest) foi modelado, contendo um componente

Behaviour chamado collectData e que é responsável pela coleta de dados sobre a

temperatura local e o envio destes ao nó sink. Já na segunda região, sink, o grupo de nós antenna foi modelado, o qual é composto pelo componente

antennaBehaviour. Este componente tem como tarefa receber os dados

coletados pelos nós sensores e enviá-los para um computador externo a rede. Além disso, caso uma queimada seja detectada na floresta, ele disparará um alerta

Com a aplicação modelada com a DSL, o especialista em redes efetua a atividade “Escolher Plataforma” e usa a infraestrutura MDA para fazer a

95

transformação M2M e gerar um modelo específico desta aplicação na plataforma escolhida (Sun SPOT). Por último, seriam realizados os refinamentos tanto no modelo específico de plataforma quanto no código gerado após a transformação M2T.

Figura 5-2 Modelagem da aplicação Burning Forest com a DSL intermediária.

Desta forma é possível perceber que com o ciclo de desenvolvimento de sistemas para RSASF utilizado é possível modelar outras aplicações, de diversos domínios, usando a mesma infraestrutura e reusando todos os artefatos reutilizáveis da infraestrutura MDA (DSL, PSMs, transformações M2M e transformações M2T).

96

SC4. Mudança da plataforma de RSASF. Em um cenário típico do

ambiente RSASF, uma mesma aplicação posteriormente necessita ser executada em outra plataforma. Sem a utilização do ciclo de desenvolvimento e da infraestrutura propostos em [RODRIGUES, 2011], o código completo da aplicação precisaria ser reescrito a partir do zero. Ao utilizar tal ciclo de desenvolvimento exige-se, apenas, a construção das transformações M2M e M2T de acordo com a plataforma requerida. Após a realização destas atividades, as únicas etapas exigidas para se reusar a especificação da aplicação para essa nova plataforma são: selecionar a transformação M2M que transforma modelos da DSL para a plataforma desejada a fim de gerar um modelo de aplicação, realizando qualquer refinamento exigido no modelo gerado e, em seguida, aplicar a transformação M2T correspondente (e refinar o código gerado).

5.2. LWiSSy

Inicialmente, uma análise comparativa entre LWiSSy e as DSLs propostas por [LOSILLA, 2007] e por [SHIMIZU, 2011] foi efetuada a fim de determinar o poder de expressividade das três DSLs com relação à capacidade de otimização (refinamento), separação de interesses (diferentes perfis de desenvolvedor envolvidos), modelagem comportamental e estrutural do sistema, e programação da rede considerando diferentes níveis de granularidade. Logo após, um experimento controlado foi conduzido para analisar o impacto da utilização de LWiSSy com relação à eficácia da linguagem em facilitar a compreensão e manutenção de sistemas de RSASF.