Metamodelo Independente de Plataforma

Foi conduzida uma revisão da literatura (BERARDINELLI; CORTELLESSA; PACE, 2011; BOONMA; SUZUKI, 2009; BUCKL et al., 2008; CARACAS; BERNAUER, 2011; DELICATO et al., 2009; FUENTES; GÁMEZ, 2010; “ISIS - Gratis”, 2015; LOSILLA et al., 2007; SHIMIZU et al., 2011) a partir da seleção de trabalhos acadêmicos com os temas "Linguagens Específicas de Domínio" e "metamodelos para RSASF" com o objetivo de entender como um PIM poderia descrever os requisitos funcionais e não funcionais de um grande número de aplicações para RSASF e ao mesmo tempo manter um nível de abstração adequado e sem incluir informação referente ao nível de plataforma. O objetivo de tal revisão foi criar um metamodelo que pudesse ajudar os especialistas de domínio a descrever os seus sistemas usando apenas conceitos de RSASF de alto nível de abstração.

O metamodelo independente de plataforma, ou metamodelo PIM, projetado utiliza modelos UML de Classes e Atividades como base para descrever todas as informações necessárias para definir uma aplicação. Tal metamodelo dispõe dos estereótipos UML, através de um perfil UML, necessários para incluir nos metaelementos dos modelos (classes, atividades, etc.) as principais informações referentes às características de RSASF que foram selecionadas durante a revisão da literatura. Um perfil UML é um mecanismo de extensão da UML que provê uma maneira de customizar modelos para um domínio específico. O objetivo é, através dos perfis UML projetados, permitir que desenvolvedores de aplicações para RSASF possam incluir informações sobre a organização física e comportamental da rede nos modelos.

Figura 24. Estereótipos da visão estrutural.

O metamodelo independente de plataforma foi desenvolvido considerando: (i) os diferentes pontos de vista entre os desenvolvedores de aplicações para RSASF (domínio e rede); (ii) os diferentes níveis de abstração (dependente ou independente de plataforma); e (iii) a necessidade de levar em conta requisitos funcionais e não funcionais durante o processo de desenvolvimento de uma aplicação. Dadas as características do PIM acima mencionadas, e usando a habilidade da UML de prover diferentes visões de seus diagramas, foi possível separar a modelagem de aplicações para RSASF em três diferentes visões: (i) Estrutural (Figura 24), (ii) Comportamental (Figura 27), e (iii) Configuração.

Para a visão estrutural um diagrama UML de Classes é estendido, a Tabela 4 descreve todos os estereótipos da visão estrutural. A Figura 25 mostra um exemplo do modelo da visão estrutural de uma aplicação. O Pacote Network (elemento pacote padrão de um diagrama UML de Classes) mais externo com o estereótipo «System» armazena todos os outros elementos UML que fazem parte do modelo da visão estrutural da aplicação. Os Pacotes internos Sensors e Sink que representam as «Regions» (Regiões). Dentro de cada região estão representados os «Nodegroups» (Grupos de Nós) contendo todos os nós responsáveis por realizar uma mesma tarefa. Por fim, aparece o «WirelessLink» interligando «Nodegroups», através de uma comunicação sem fio. Cada um dos «Nodegroups» existentes possui um comportamento específico que é modelado através da visão comportamental (Figura 26).

Tabela 4. Descrição dos estereótipos da visão estrutural.

Estereótipo Descrição Propriedade Definição System Define configuração da

aplicação modelada em termos de protocolos utilizados.

Topology † Topologia física da rede. routingProtocol † Protocolo de roteamento da rede. transportProtocol † Protocolo da camada de transporte. communicationProtocol † Protocolo de entrega de informações para

múltiplos destinatários. Region Local físico onde são

agrupados os dispositivos que estão fisicamente próximos.

Description Descrição textual da região.

Lat Propriedade latitute para localização da região.

Long Propriedade longitude para localização da região.

NodeDefinition Especificação de plataforma e dispositivo utilizado na aplicação.

OS † Sistema operacional ou plataforma sensor. Sensors † Sensores instalados no nó.

Battery † Fonte de energia do dispositivo. Actuators † Atuadores instalados no dispositivo. NodeGroup Nós responsáveis por

realizar uma mesma tarefa.

minNumNodes Mínima quantidade de nós no grupo. maxNumNodes Máxima quantidade de nós no grupo. Definition NodeDefinition especificando as

características de hardware do grupo. lifeTime Tempo de vida requerido para os

dispositivos deste grupo. WirelessLink Representa a comunicação

sem fio entre dois grupos de nós diferentes

Protocol † Protocolo de enlace da camada física e camada de acesso ao meio.

Antenna † Hardware da antena do dispositivo.

Figura 25. Modelo da visão estrutural de uma aplicação usando a DSL criada

Para a visão comportamental o diagrama de atividades UML foi escolhido como modelo base para definição do comportamento de cada um dos nós da rede e também estendido com um perfil para RSASF (verificar a Figura 27 e a Tabela 5 para mais detalhes sobre os estereótipos disponíveis) para incluir as características do domínio de RSASF que são necessárias para a correta definição de uma aplicação conforme as características levantadas durante a revisão da literatura.

Figura 26. Modelo da visão comportamental de uma aplicação.

A Figura 26 apresenta o comportamento de uma aplicação modelada utilizando a ArchWiSeN. Dentro do diagrama de atividades da Figura 26 existe uma swinmlane (ou raia de piscina, em português) que contem todos os elementos UML responsáveis pela definição do comportamento dos Nós (Node na figura). Dentro desta swinmlane estão alocados: (i) o pseudoestado inicial (símbolo representado por um círculo preto), (ii) as atividades a serem executadas (representadas pelos retângulos de cantos arredondados), e (iii) o sentido no qual as atividades devem ser executadas (representado pelas setas interligando as atividades). Dessa forma, o comportamento da aplicação deve ser modelado com os elementos UML, mas ainda é preciso definir os estereótipos usados em cada uma das atividades. Primeiro, após a inicialização do nó, foi definido um «Radio» para que a antena do nó esteja disponível para entrega e envio de dados na rede sem fio. Em seguida, foi definida uma «Function» para realizar o processo de calibragem dos sensores presentes nos nós. Com o fim dessa atividade, um «Timer» de 22 segundos foi especificado para que haja um intervalo de tempo entre a calibragem e a atividade realizada pelo «Actuator». Após o trabalho do atuador, um novo «Timer» (agora de 20 segundos) antecede o processo de coleta de dados dos sensores (« ReadSensor»). Com os dados obtidos, o nó realiza uma computação (definida pelo elemento «Aggregation») e envia («Send») as

informações processadas para o nó sorvedouro. A última atividade configura o último temporizador («Timer») para executar esta aplicação a cada 24 horas.

Figura 27. Estereótipos da visão comportamental.

Tabela 5. Descrição dos estereótipos da visão comportamental.

Estereótipo Descrição do Estereótipo

Propriedade Definição da Propriedade

SensorData Tipo de dado proveniente de um sensor.

type Tipo do sensor (luz, temperatura, etc).

Receive Recebimento de dados pela aplicação

- -

Application Definições da aplicação desenvolvida.

Description Descrição da aplicação em texto.

NodesQuantity Quantidade responsáveis pela execução da aplicação.

dataAccuracyRange Acurácia de dados exigida pelos requisitos da aplicação.

Port Interface de comunicação de hardware.

Type Tipo de porta de comunicação (USB, serial, etc)

Actuator Dispositivo de hardware atuador.

Type Tipo de atuador (Relê eletrônico).

FunctionalUnit Unidade funcional que representa uma atividade específica do

comportamento de uma RSSF que deve ser aplicado a uma atividade UML.

Description Descrição textual da Unidade Funcional.

Function Função específica de domínio usada na aplicação.

Specification Especificação literal da função. O código pode ser dicionado manualmente após a transformação M2T.

Radio Especificação do rádio da aplicação.

DutyCycle † Ciclo de trabalho do rádio. Período de tempo inativo onde a aplicação aguarda para o envio ou recebimento de dados. SendAction Especificação de uma

envio de requisição a um atuador.

Resource Actuator que receberá o chamado de execução de uma ação.

Timer Especificação de um temporizador.

Value Atributo numérico de indica o tempo em milissegundos.

ReadSensor Especificação de uma leitura de sensor.

Data SensorData que representa o dado a ser coletado.

A visão de configuração possibilita a inclusão, nos diagramas UML de Classes e Atividades, de características específicas, como protocolo de roteamento e topologia de rede, que afetam diretamente os requisitos não funcionais. Por exemplo, o estereótipo «System» configura propriedades da RSASF como protocolo de roteamento e topologia e o estereótipo «Radio» configura o duty-cycle (ou ciclo de trabalho) do nó. O símbolo † nas Tabela 4 e Tabela 5 marcam todas as propriedades que são da visão de configuração.

A Figura 28 representa uma visão completa de todos os estereótipos existentes no perfil para RSASF na implementação da ArchWiSeN. As setas pretas na Figura 28 representam extensões de metaclasses UML segundo a especificação UML (UML-DIAGRAMS.ORG, 2014) enquanto as setas brancas representam generalizações. A Figura 28 (A) apresenta os estereótipos responsáveis por estender o diagrama de classes UML que são usados na especificação da visão estrutural. A Figura 28 (B) apresenta os estereótipos responsáveis por estender o diagrama de atividades UML para tornar possível a modelagem da visão comportamental das aplicações para RSASF. Por fim, existem algumas propriedades em alguns estereótipos que pertencem à visão de configuração espalhados pela Figura 28. Por exemplo, a propriedades routingProtocol no estereótipo «System» e dutyCycle no estereótipo «Radio» pertencem à visão de configuração e são apresentadas na Figura 28 (A) e Figura 28 (B), respectivamente. O Apêndice A (Definição dos estereótipos presentes no metamodelo PIM)

agregação de dados. Uma agregação pode ocorrer após uma coleta ou recebimento de dados.

Samples Número de amostras obtidas até a realização da agregação

In Tipo de dado de entrada

Out Tipo de dado de saída

Led Especificação do controle de Leds.

Type Identificador do Led

Starts Quando a ação de Led será executada. Antes ou depois da ação onde o estereótipo Led foi aplicado.

State Novo status do Led (Ligado ou Desligado)

Send In SensorData de entrada.

pushModel Modelo de entrega de dados (Periódica, Dirigida a Eventos, etc).

sendMessageBy Meio onde o dado será enviado (Sem fio ou físico)

parameter Parâmetros textuais a serem enviados na mensagem.

descreve em detalhes os estereótipos definidos para a especificação das características independentes de plataforma a serem utilizadas pelos desenvolvedores e traz exemplos do uso de cada um dos estereótipos.

Figura 28. Todos os estereótipos disponíveis no perfil para RSASF. (A) Estereótipos da visão estrutural. (B) Estereótipos da visão comportamental.

Além dos estereótipos e propriedades apresentados na Figura 28, ainda é preciso definir as propriedades necessárias para definir requisitos não funcionais que poderão ser modelados pelo desenvolvedor através do metamodelo PIM disponível na ArchWiSeN para a definição de serviços de middleware necessários ao funcionamento da aplicação. Dentre os diversos serviços de middleware para RSASF apresentados na Seção 2.5, esta Tese limita-se ao escopo de quatro serviços básicos: comunicação assíncrona, descoberta de serviços (interna), segurança e agregação de dados. O objetivo de tais propriedades no nível do PIM é permitir

aos desenvolvedores especificar os requisitos não funcionais necessários para suas aplicações que serão atendidos pelos respectivos serviços do middleware.

Figura 29. Estereótipos com propriedades referentes à configuração dos serviços de

middleware.

Assim, as propriedades relacionadas a serviços de middleware para RSASF foram adicionadas no nível de PIM da infraestrutura MDA (Figura 29) para incorporar alguns dos requisitos exigidos e tornar possível a configuração de serviços para RSASF em um alto nível de abstração. Assim, para cada serviço disponível, as propriedades relacionadas à configuração desses serviços de

middleware para RSASF são:

S1. Serviço de Segurança: Propriedades booleanas Authentication do estereótipo «System» e Cryptography dentro do estereótipo «Send» do PIM;

S2. Serviço de Comunicação Assíncrona: Propriedade TopicName (conjunto de parâmetros do tipo texto) dentro dos estereótipos «Send» e «Receive» para denotar uma comunicação do tipo publish-

subscrible do serviço de comunicação do middleware.

S3. Serviço de Descoberta: Propriedade Discovery dentro do estereótipo «Radio» para que um nó possa anunciar suas propriedades e tópicos disponíveis para a rede representando o serviço de descoberta. A

propriedade discovery inclui uma lista das características que deverão ser anunciadas na descoberta, dentre elas: hardware, sensores e

EnergyLevel. Com relação a característica hardware, o nó deve anunciar na mensagem de descoberta o seu processador e memória RAM disponível, já na característica sensores o nó deve anunciar quais os tipos de dados ele está apto a coletar. Por fim, com a característica EnergyLevel o nó anuncia o seu nível de bateria atual. S4. Agregação: Como a infraestrutura MDA da ArchWiSeN já possui um

estereótipo para agregação de dados, nenhuma outra propriedade ou elemento precisou ser modificado para a disponibilização desse serviço.