Cenário 1: Monitoramento de Temperatura para Smart Homes

Este cenário considera o desenvolvimento de uma aplicação para o domínio de Smart Homes que consistem em monitorar a temperatura de uma casa instrumentada por uma rede de sensores sem fio. Tal aplicação foi projetada através dos artefatos MDA da ArchWiSeN usando o processo de engenharia de aplicação apresentado na Seção 3.2, a partir de um nível independente de plataforma até a obtenção do código fonte. São apresentadas ainda dois cenários de mudanças para ilustrar a separação de interesses entre os desenvolvedores. O objetivo desta aplicação é:

Coletar dados de temperatura de um ambiente, processar esses dados através de uma função de agregação para que apenas a maior dentre 10 amostras seja considerada e, por fim, enviar apenas essa amostra para o nó sorvedouro.

Seguindo o diagrama de atividades que descreve o processo de engenharia de aplicação (Figura 43 do Capítulo 3), a primeira atividade a ser executada por ambos os desenvolvedores é a "Análise de Requisitos". Como essa atividade pode ser realizada a partir de qualquer técnica de engenharia de requisitos, conforme explicado na Seção 3.2, e está fora do escopo desta Tese, ela não será detalhada neste documento.

A atividade seguinte, "Modelar PIM", é realizada pelo especialista de domínio. Tal atividade é concluída a partir da execução dos seguintes passos:

i. Criação dos diagramas UML de Classes e Atividades; ii. Aplicação do perfil para RSASFs em ambos os modelos; iii. Modelagem da visão estrutural da aplicação;

iv. Modelagem da visão comportamental da aplicação. Figura 44. Modelo da visão estrutural.

A Figura 44 apresenta o modelo criado pelo especialista de domínio para representar a visão estrutural da aplicação. Neste modelo é possível perceber a existência de duas «regions», contendo em cada uma delas um «nodegroup» e um «nodedefinition». O «nodegroup» da «region» ServerRoom possui o nome Sala e um «nodedefinition» MyNodes. Em MyNodes é possível perceber que estão conectados aos dispositivos dois sensores: temperatura e luz. Já na «region»

SinkRoom, o «nodegroup» Controleutiliza a «nodedefinition» SinkNode.

A Figura 45 apresenta o modelo que representa a visão comportamental da aplicação também modelada pelo especialista de domínio. Nesta figura é possível notar a presença de duas swimlanes Sala e Controle. A primeira swimlane, Sala, modela o comportamento do «nodegroup» Sala, enquanto a segunda swimlane,

Controle, modela o comportamento do «nodegroup» Controle. O comportamento do «nodegroup» Sala é bastante simples. Os nós devem inicializar seus respectivos rádios, iniciar um temporizador de 20 segundos, realizar 10 coletas de dados de temperatura, selecionar apenas o maior dado obtido e enviar através do radio tal

dado. O comportamento do «nodegroup» Controle resume-se a obtenção dos dados através do rádio do dispositivo.

Figura 45. Modelo da visão comportamental.

Ambos os modelos apresentados (Figura 44 e Figura 45) foram desenvolvidos durante a atividade "Modelar PIM" utilizando diagramas UML de classes e atividades e o perfil para RSASF fornecido pela ArchWiSeN.

Seguindo o processo de engenharia de aplicação, o especialista de redes deve realizar a atividade "Escolher Plataforma" para selecionar a plataforma alvo da aplicação. A partir daí, o especialista de domínio pode realizar a atividade "Aplicar Marcas de Configuração" para incluir as propriedades de configuração nos modelos, como, por exemplo, a propriedade OS do estereótipo «nodedefinition» para TinyOS2x (Figura 44) e a propriedade DutyCicle do estereótipo «radio» do comportamento do nodegroup Sala (Figura 45).

Após a conclusão da modelagem da aplicação, ambos os desenvolvedores realizam a atividade "Verificação". Nessa atividade os desenvolvedores devem verificar se os modelos projetados atingem os requisitos elucidados. Um exemplo completo da atividade "Verificação" realizada com auxilio do Analisador de

Figura 46. PSM da aplicação.

As últimas etapas do processo correspondem a execução das transformações providas pela infraestrutura MDA para gerar o código executável da plataforma alvo. A Figura 46 representa o modelo PSM gerado automaticamente (Diagrama de Estados) através da atividade "Aplicar transformação M2M". Enquanto a Figura 47 apresenta um código da plataforma TinyOS gerado para o módulo dessa mesma aplicação. O código fonte completo dessa aplicação pode ser encontrado no Apêndice D.

Figura 47. Trecho de código fonte gerado para o módulo. 1 #include "datacentercontrol.h"

2

3 module DatacenterControlC {

4 uses interface Read<uint16_t> as GetSamples; 5 uses interface Boot as InitialNode1;

6 uses interface AMSend as SendMyData; 7 uses interface Packet;

8 uses interface AMPacket;

9 uses interface SplitControl as ConfigureRadio; 10 uses interface Timer<TMilli> as LittleTimer; 11

12 } implementation { 13 (...)

14}

Cenário de Mudança 1: Alterando os Protocolos de Nível de Rede. A mudança na topologia lógica de rede ou na densidade nós implantados (por

exemplo a necessidade de implantação de uma rede mais ou menos densa) pode exigir a seleção de um novo protocolo para executar nos nós sensores. Ao utilizar a abordagem proposta para atender esta necessidade, o especialista de redes deve realizar alterações no PSM gerado. Este processo é realizado durante a atividade "Refinar Modelo". Considerado TinyOS como plataforma alvo, para modificar o protocolo utilizado pelo modelo que representa a Configuration, a qual foi gerada automaticamente pela infraestrutura MDA, são necessárias três etapas: (i) remoção dos Components que são declarados, mas que não serão mais usados, (ii) adição de novos Components que implementam o novo protocolo, e (iii) realizar o wirings entre os Components e as Interfaces que estão sendo utilizadas. Este cenário mostra que, sempre que a mudança necessária ocorre no nível de rede, todos os aspectos de domínio relacionados permanecem inalterados e são transparentes para o especialista em rede. Além disso, essas mudanças são realizadas sem a participação do especialista de domínio.

Cenário de Mudança 2: Mudança nos Requisitos Específicos da Aplicação. Tais mudanças devem ser tratadas pelo especialista de domínio e devem ocorrer no nível PIM. Um caso típico é a mudança de parâmetros de QoS da aplicação. Este requisito pode ser traduzido como uma alteração da política de energia adotada e também no valor da taxa de transmissão de dados. Para alterar a política de energia o especialista de domínio modifica o valor do elemento da DSL RadioConfigUnit que denota o ciclo de trabalho (DutyCicle) para os nós. Para alterar a taxa de transmissão de dados, o especialista de domínio simplesmente altera o valor do temporizador que controla o tempo de espera antes de cada transmissão de dados. Desta forma, a transformação M2M vai gerar o modelo PSM usando as configurações que correspondem à escolha feita pelo especialista de domínio. Todas essas mudanças podem ser feitas sem a necessidade de participação do especialista de redes.

Dessa forma, com Cenário 1 da prova de conceito foi possível demonstrar através de uma aplicação simples o uso da ArchWiSeN para a geração de todo o código fonte necessário para aplicação e preservar a com a separação de interesses entre os desenvolvedores no surgimento de cenários de mudança.