Visão comportamental

Assim como ocorre com a visão estrutural, o subconjunto de componentes do metamodelo de LWiSSy que compõem a visão comportamental, descrita nesta

74

Seção (Figura 4-3), destina-se aos especialistas de domínio. Essa visão lida com a programação de grupos de nós e de nós individuais e é responsável pelo projeto do comportamento de cada uma das aplicações que integram o sistema de RSASF e, portanto, será necessário produzir um modelo comportamental para cada uma das aplicações presentes no sistema.

Figura 4-3 Modelo gráfico que representa a visão comportamental em LWiSSy.

Nesta visão, o especialista deve inicialmente definir um ponto de partida pelo qual a aplicação começará (componente InitialState). Feito isto, o especialista chega ao core do modelo, onde ele poderá definir o conjunto de todas as atividades que integram a aplicação (componente Activity). Para modelar a dependência entre as atividades e o fluxo da aplicação, o especialista pode encadear as atividades por meio do relacionamento link presente no componente Activity.

Cada uma das atividades executadas pela aplicação pode utilizar qualquer um dos recursos presentes no grupo de nós sobre o qual a aplicação será instalada. Para isto, basta que o especialista de domínio instancie o atributo

75

que ele deseja utilizar. Os tipos de atividades disponíveis em LWiSSy são: Join,

Fork, Choice e Action. O componente Fork efetua uma divisão no fluxo principal

da aplicação em dois fluxos paralelos. Este componente permite a execução de atividades concorrentes nos nós caso a plataforma suporte esta característica. Com a utilização do componente Join é possível unir os fluxos paralelos, gerados pelo fork, em apenas um único fluxo principal. O terceiro componente,

Choice, representa uma estrutura condicional. Com isso, ao utilizá-lo o

especialista de domínio deve definir uma guarda (atributo guard do componente

Choice), que nada mais é do que uma condição que deve ou não ser satisfeita

após o término da atividade anterior a esta, e cenários (atividades) de saída que serão executados de acordo com o resultado obtido durante a análise da guarda. A expressão “if Temp > 40” pode ser considerada um exemplo de guarda que analisará o resultado da coleta dos dados de temperatura para definir qual será a próxima atividade a ser executada pela aplicação. Neste caso, o atributo Temp é um recurso que foi definido durante a visão estrutural e que compõe o grupo de nós responsável pela execução desta aplicação.

O último e mais complexo dos componentes que representam uma atividade trata-se do componente Action. Todo elemento definido como uma Action deve ter um nome associado (atributo name) e, caso o especialista de domínio ache necessário, uma descrição (atributo description). Este componente deve ser utilizado para modelar funcionalidades específicas de RSASF durante a modelagem da aplicação. Ele é composto por cinco componentes: Timer,

Aggregation, LED, Send e Common.

O componente Timer deve ser utilizado pelo especialista caso seja necessário utilizar algum tipo de temporizador (timer) durante o fluxo da aplicação. Ele pode ser útil em aplicações onde a coleta ou o envio de dados seja periódico, sendo realizado em intervalos de tempo constantes e predefinidos, em contraste com aplicações dirigidas a eventos onde a coleta e o envio de dados dependem da ocorrência de um determinado evento e não consideram o fator tempo .

76

Durante a modelagem de um componente deste tipo, o especialista de domínio deve determinar um intervalo de tempo em milissegundos (atributo timer) e o tipo de timer a ser utilizado (atributo type), o qual pode ser contínuo (disparado a cada ciclo daquela aplicação) ou pontual (disparado apenas durante o primeiro ciclo de atividades da aplicação).

O segundo componente do tipo Action trata-se do componente Aggregation. Ele deve ser empregado em aplicações onde se desejam realizar operações de agregações de dados. Diversas aplicações de RSASF utilizam algum tipo de agregação antes de enviarem os dados coletados para os nós sink ou estações base. Isso se faz necessário pela grande quantidade de nós sensores presentes na rede, o que acaba gerando uma maior transmissão de dados e, por sua vez, o aumento de colisões e perda de pacotes, além do elevado consumo de energia por parte dos nós sensores, visto que a comunicação é a principal responsável pelo consumo de energia. Dessa forma, a agregação dos dados pode melhorar a precisão dos dados coletados, tornar a rede menos vulnerável a falhas e imprecisões de um único nó e diminuir o consumo de energia [NAKAMURA, 2007].

Em uma agregação é necessário definir a variável onde o resultado da agregação será armazenado (atributo variable) e a função de agregação que será utilizada (atributo function), a qual pode ser um dos valores predefinidos por LWiSSy (AVERAGE, COUNT, MIN e MAX), ou pode ser definida pelo especialista posteriormente (USER_DEFINED), visto que a agregação pode envolver técnicas mais complexas, como media móvel ponderada, inferências bayesianas, várias técnicas estatísticas ou probabilísticas, dentre outras. A agregação possui dois atributos de controle, sendo eles: o número de amostras que o sensor irá agregar (atributo numberOfSamples) e o intervalo de tempo n o qual o nó estará disponível para receber os dados coletados (atributo delay). Caso o intervalo de tempo (delay) seja atingido durante o processo de agregação e a quantidade de amostras não seja a esperada, a agregação será efetuada a fim de garantir o

77

bom funcionamento da aplicação, ou seja, o atributo delay é mandatório no processo de agregação.

O componente LED trata do gerenciamento dos LEDs que se encontram na placa do nó. Através dele é possível ligar e desligar os LEDs (atributo status), bem como escolher a cor que será utilizada pelos mesmos (atributo color) quando estiverem ligados. Os LEDs podem desempenhar o papel de atuadores por meio da emissão de sinais de alerta durante a ocorrência de algum evento inesperado, por exemplo.

A penúltima funcionalidade inerente a área de RSASF que LWiSSy trata é o envio de mensagens entre os nós da rede. Esta funcionalidade é suportada pelo componente Send. Por meio dele, o especialista de domínio pode definir o tipo de modelo de entrega de dados que será utilizado (atributo pushModel) pela aplicação e o meio pelo qual a mensagem será dissipada na rede (atributo

sendMessageBy). Além disso, o atributo parameter será utilizado de acordo com

o modelo de entrega de dados escolhido. Caso o tipo EVENT_DRIVEN seja configurado, o especialista deverá definir qual a condição (evento de interesse) que deve ser considerada para que os dados sejam enviados. No entanto, caso o tipo PERIODIC seja configurado, o especialista deverá determinar o intervalo de tempo, em milissegundos, no qual os dados devem ser enviados.

O último componente a ser descrito, Common, engloba várias funcionalidades da área de RSASF que, ao contrário das demais até agora citadas, não possuem tantas configurações e por isso foram armazenadas em um único componente. Para utilizá-lo o especialista de domínio precisa apenas definir o atributo type para dos tipos predefinidos em CommonType. Dentre as funcionalidades mapeadas para este componente aparecem: a configuração dos rádios dos nós, a leitura de dados provenientes de um sensor ou de uma porta, o recebimento por porta ou rádio de mensagens, o envio de uma ação por meio de um atuador à rede e a exibição dos dados recebidos por uma estação base. Convém destacar que a configuração dos rádios pode ser considerada uma

78

funcionalidade mais complexa, pois se faz necessária a definição do ciclo de trabalho (duty cycle) do mesmo. No entanto, tal característica é considerada de baixo nível de abstração para ser tratada pelo especialista de domínio e, por isso, será tratada diretamente pelo especialista de redes durante a modelagem da visão de refinamento.

Por fim, o especialista de domínio pode configurar um ou mais estados finais para a sua aplicação (componente FinalState). Em alguns casos este componente não é modelado, pois se trata de uma aplicação cíclica.

Ao término da descrição desta visão pode-se concluir que ela é uma instanciação do diagrama de atividades da UML com foco na área de RSASF. Tal diagrama foi escolhido como base por representar os estados de uma atividade e por ser orientado a fluxos de controle, características estas que são mais facilmente absorvidas e utilizadas por profissionais que não conhecem os diagramas da UML. Além disso, quando se considera um alto nível de abstração, todo o fluxo das aplicações pode facilmente ser modelado por meio deste tipo de diagrama.