Using MDA for Building Wireless Sensor Network Applications

Taniro C. Rodrigues, Priscilla V. Dantas, Flávia C. Delicato, Paulo F. Pires

DIMAp - Universidade Federal do Rio Grande do Norte {tanirocr, pridnt, fdelicato, paulo.f.pires}@gmail.com

Claudio Miceli, Luci Pirmez NCE/DCC-IM - Universidade Federal do Rio de Janeiro

{claudiofarias, luci}@nce.ufrj.br

Resumo — Propomos o desenvolvimento de aplicações de RSSF usado MDA, possibilitando contribuição direta do especialista de domínio no desenvolvimento da aplicação sem necessidade de conhecimento específico de RSSF. Além disso, MDA promove o reuso dos artefatos de nível de aplicação e de plataformas de sensores, permitindo que um modelo representando uma aplicação seja reusado em diferentes plataformas e que um modelo de plataforma seja reusado para diferentes aplicações.

Abstract — We propose a MDA approach to develop WSN applications, which allows domain experts to contribute in the development of applications without needing knowledge on WSN platforms and allows network experts to program nodes to met application requirements without specific knowledge on the domain. Our approach also promotes reuse, allowing an application model to be reused across different sensor platforms and a platform model to be reused for different applications.

Keywords: Wireless Sensor Network, MDA, DSL, MDE.

I. INTRODUÇÃO Rede de Sensores Sem Fio (RSSF) constituem um campo

de pesquisa promissor, integrando conhecimentos de diversas disciplinas como redes de computadores, sistemas distribuídos, sistemas embarcados e engenharia de software. A disponibilização de ambientes instrumentados por sensores interconectados a uma rede sem fio, provendo informações variadas em tempo real sobre o mundo físico, promete trazer drásticas mudanças na forma com que as pessoas interagem com o meio ambiente. RSSFs possuem potencial de aplicação em diferentes áreas, tais como militar, ambiental, industrial, entre outras [25]. No entanto, para se atingir plenamente o potencial de uso de RSSFs, o desenvolvimento de aplicações para tais redes precisa ser facilitado e tornar-se acessível para usuários das mais diversas áreas de conhecimento.

Uma RSSF é composta por um conjunto de nós sensores e um ou mais nós sorvedouros. Nós sensores são pequenos dispositivos espacialmente distribuídos, em geral movidos a bateria, e equipados com um rádio transceptor, unidades de sensoriamento e um micro-controlador. Sorvedouros são dispositivos mais poderosos computacionalmente e sem restrição de energia (em geral PCs), responsáveis por interagir com a aplicação, recebendo tarefas e consultas, e por reunir e entregar os dados gerados pelos sensores. RSSFs são capazes de monitorar o mundo físico, capturar dados úteis da área de sensoriamento, processar os dados coletados, tomar decisões, e

realizar operações concretas no meio monitorado [10]. RSSFs caracterizam-se por uma grande heterogeneidade considerando os requisitos da aplicação, as características dos nós sensores (hardware e sistema operacional), e os protocolos de rede utilizados. Há atualmente diversas plataformas que suportam o desenvolvimento e a implementação de aplicações de RSSF, cada uma possuindo seus próprios requisitos, ambientes de programação e execução e ferramentas de desenvolvimento.

A primeira geração de RSSFs adotava uma abordagem de projeto “especifico da aplicação” [9], e a maioria dos sistemas era concebida a partir do zero, como software monolítico construído para uma plataforma de destino, um sistema operacional (SO) específico, e endereçando requisitos de uma única aplicação alvo. Nesse contexto, os desenvolvedores de aplicações precisavam conhecer tanto as especificidades das redes, incluindo protocolos e configurações de baixo nível, quanto os requisitos de alto nível da aplicação alvo, e construíam programas utilizando as abstrações fornecidas pelo SO do sensor. O alto acoplamento entre a lógica da aplicação e da plataforma base do sensor, juntamente com a falta de uma metodologia de suporte ao ciclo de vida do desenvolvimento de aplicações resultava em projetos com código dependente da plataforma e difíceis de manter, modificar e reutilizar.

Considerando que uma mesma RSSF é potencialmente útil para uma ampla gama de aplicações e que a infra-estrutura física da rede é cara, há uma tendência em se projetar RSSFs em escala comercial para diferentes aplicações. Nesse cenário, vislumbra-se que uma grande infra-estrutura de sensores será desenvolvida incrementalmente por múltiplos fabricantes [11], atendendo a diferentes demandas de domínios distintos de aplicações. Subsistemas de diferentes fabricantes devem ser transparentemente integrados com o resto da infra-estrutura de TI e prover interfaces intuitivas para acesso por usuários remotos e leigos em redes. Os nós dessa infra-estrutura devem ser programados para cada aplicação, enquanto ao mesmo tempo decisões de nível de rede, como a escolha do protocolo de roteamento de dados, devem ser tomadas de modo a otimizar os recursos e prolongar o tempo de vida da infra-estrutura. Para tal cenário ser viável, um dos principais desafios a ser suplantado consiste em prover, por um lado, mecanismos de alto nível que abstraiam as características da infra-estrutura de sensores subjacente e permitam os especialistas em aplicações representar as características de seus domínios usando linguagens com as quais estão familiarizados, por outro lado mecanismos que permitam especialistas em rede

2010 Fourth Brazilian Symposium on Software Components, Architectures and Reuse

978-0-7695-4259-1/10 $26.00 © 2010 IEEE

DOI 10.1109/SBCARS.2010.21

110

configurar as características de baixo nível necessárias para obter a eficiência em energia requerida pelas RSSFs.

Argumentamos que a adoção de uma abordagem de Desenvolvimento Dirigido a Modelos (DDM), mais especificamente, da Model-Driven Architecture (MDA) [14], é uma solução promissora para atender aos requisitos das atuais e futuras RSSFs. Usando-se MDA é possível aumentar o nível de abstração do desenvolvimento de aplicações de RSSF e ao mesmo tempo promover uma separação clara e sinérgica entre a especificação de requisitos do nível da aplicação e a especificação de requisitos de uma dada plataforma de sensor. Com uma abordagem MDA, os sistemas de RSSF podem ser divididos em níveis de abstração dependente ou não da plataforma de sensores, e o design de cada nível pode ficar sob a responsabilidade dos seus respectivos especialistas.

Este trabalho apresenta uma infra-estrutura MDA, composta de diferentes artefatos de software, e um processo de desenvolvimento associado, para a construção de aplicações de RSSFs. O conhecimento do domínio da aplicação é representado no nível PIM usando uma Linguagem Específica de Domínio (do inglês Domain Specific Language, DSL). Tal DSL é definida pelo meta-modelo PIM, que descreve a semântica dos elementos necessários e suficientes para construir aplicações de RSSF, independentemente da plataforma de implementação. O conhecimento representando diferentes plataformas de sensor é especificado no nível PSM. Portanto, a infra-estrutura MDA proposta engloba diferentes meta-modelos PSM, um para cada plataforma de RSSF. No processo MDA proposto, os desenvolvedores de aplicação (aqui denominados especialistas do domínio) são basicamente responsáveis pela modelagem do PIM (e por fazer alguns aperfeiçoamentos adicionais no código final). A partir do PIM, um primeiro conjunto de transformações MDA toma como entrada esse modelo, juntamente com o meta-modelo PSM da plataforma de sensor escolhida, e gera uma instância PSM que representa a lógica da aplicação mapeada para a plataforma alvo. O especialista de redes tem a possibilidade de aperfeiçoar esse artefato de software gerado (a instância PSM), incluindo novos elementos ou acrescentando detalhes em elementos existentes de forma que o PSM final seja suficiente para descrever integralmente os requisitos das aplicações na plataforma alvo. É importante notar que tal refinamento engloba apenas as informações disponíveis no nível de abstração do especialista de rede, preservando assim a clara separação de conceitos, objetivo almejado no trabalho. No próximo passo, outras transformações MDA tomam como entrada o modelo PSM refinado e, utilizando templates de código para a respectiva plataforma do sensor, geram código-fonte, o qual após refinamento pode ser executado.

Neste artigo apresenta-se o desenvolvimento de uma aplicação inicial para RSSF usando a infra-estrutura e o processo descritos, seguido de uma série de cenários de mudança, nos quais são explorados os benefícios da proposta em termos de facilitar a construção das aplicações e reusar os artefatos gerados. O restante do trabalho está organizado como segue. As Seções II e III mostram o processo de desenvolvimento de aplicações proposto e a infra-estrutura MDA que suporta o processo. Uma prova de conceito da viabilidade da proposta é descrita na Seção IV. A Seção V

apresenta a avaliação da proposta, a Seção VI discute trabalhos relacionados e considerações finais são feitas na Seção VII.

II. PROCESSO DE DESENVOLVIMENTO DE APLICAÇÕES UTILIZANDO A ABORDAGEM MDA PROPOSTA

Esta Seção apresenta os passos necessários para desenvolver uma aplicação de RSSFs de acordo com a abordagem proposta, seguindo o processo de desenvolvimento e fazendo uso dos artefatos fornecidos pela infra-estrutura MDA criada (descrita na Seção III).

Aplicações de RSSF são desenvolvidas de acordo com dois pontos de vista. O primeiro é realizado pelo especialista no domínio de aplicação (biólogos, engenheiros, etc) e o segundo é realizado pelo especialista em redes, que possui conhecimento tanto dos protocolos de nível de rede quanto das plataformas de sensores. Construir aplicações de RSSF utilizando a abordagem MDA proposta promove a divisão de responsabilidades entre os desenvolvedores destes diferentes pontos de vista, permitindo-lhes utilizar os seus conhecimentos específicos e livrando-os da necessidade de lidar com as exigências que não pertencem ao seu campo de especialização.

Figura 1. Processo de desenvolvimento de aplicações RSSF com MDA.

O processo de desenvolvimento a ser seguido na abordagem proposta está sintetizado no diagrama de atividades UML da Figura 1. A primeira atividade no diagrama, "Análise de requisitos", é realizada por ambos os desenvolvedores, o especialista de domínio e o especialista em redes, e representa a etapa onde eles levantam todas as informações necessárias para a construção da aplicação. Esta é uma atividade tradicional de elicitação de requisitos realizada em qualquer processo de desenvolvimento de software[19]. Os artefatos de software produzidos como resultados dessa atividade (diagramas UML de Casos de Uso, documentos textuais, etc) representam os requisitos do sistema e constituem o CIM, que será utilizado nas fases posteriores pelos desenvolvedores (especialistas de domínio e especialistas de rede) envolvidos na construção da

111

aplicação de RSSF. O documento inclui requisitos funcionais (relacionados com a lógica da aplicação) e requisitos não-funcionais (relacionadas com a configuração da plataforma de RSSF). Este artigo não aborda a construção do CIM.

O CIM é utilizado pelo especialista de domínio na atividade "Modelar Aplicação com DSL", para especificar o modelo PIM. Este modelo é baseado no meta-modelo DSL anteriormente especificado (processo ilustrado na Figura 2), e que faz parte da infra-estrutura MDA provida. O CIM também é usado pelo especialista de rede na atividade "Escolher Plataforma”, onde o especialista vai avaliar as plataformas de sensores disponíveis e escolher aquela que melhor satisfaz os requisitos elicitados. Em seguida, a atividade "Aplicar transformação M2M" é realizada pela infra-estrutura MDA. Essa atividade tem como entrada o modelo PIM, com o seu meta-modelo associado, e o meta-modelo PSM da plataforma de RSSF escolhida pelo especialista de rede, e gera como saída uma instância do PSM que representa a concretização da aplicação nesta plataforma específica. Tal PSM é refinado pelo especialista de rede na atividade "Refinar Modelo", a fim de incrementar o modelo gerado automaticamente com informações referentes à especificidades relacionadas com a rede da plataforma alvo, ou escolher uma biblioteca de aplicativos que melhor se adapte a aplicação de requisitos não-funcionais relacionados, por exemplo, às características da área-alvo ou as políticas de economia de recursos da rede.

Finalmente, é realizada a atividade "Aplicar transformação M2T". Esta atividade tem duas entradas: o modelo PSM refinado pelo especialista de rede e o modelo de código da plataforma escolhida, e gera como saída o código fonte da aplicação a ser implantado nos nós sensores. O código gerado é então refinado por ambos os especialistas, de rede e domínio (cada um considerando seu conhecimento específico), na atividade "Refinar Código", a fim de adicionar melhorias como funções específicas da aplicação ou parâmetros de protocolos que não são automaticamente geradas pelo processo.

III. INFRA-ESTRUTURA MDA PROPOSTA Esta seção inicialmente descreve a infra-estrutura MDA

construída para apoiar o processo de desenvolvimento MDA proposto neste trabalho, sua construção e os artefatos nela contidos. Tal infra-estrutura engloba todos os artefatos MDA necessários para construir aplicações segundo a proposta. Além de apoiar o processo proposto, a infra-estrutura é extensível para acomodar a inclusão de novos meta-modelos e/ou transformações, sempre que necessário, por exemplo, quando surge uma nova tecnologia de sensores.

A. Processo de Construção da Infra-estrutura A infra-estrutura provida como parte do presente trabalho

fornece o suporte de software para o desenvolvimento das aplicações segundo o processo MDA proposto. Ela foi construída segundo uma série de atividades descritas a seguir.

A primeira atividade necessária ao processo de construção de infra-estrutura MDA (Figura 2), "Construir Meta-modelo PIM (DSL)" consiste na especificação do meta-modelo que define todos os artefatos necessários para desenvolver uma aplicação de RSSF, em um nível independente de plataforma. Em seguida, a atividade "Construir Meta-modelo PSM" tem

como objetivo gerar os meta-modelos para as plataformas de sensores existentes. Cada PSM descreve as características necessárias para o desenvolvimento de qualquer aplicação em uma plataforma de sensores específica. Tais PSMs devem ser concebidos de forma a cobrir a maioria dos detalhes necessários para representar qualquer aplicativo na plataforma alvo. Nesse artigo foram construídos PSMs para a plataforma TinyOS [24] e SunSPOT [22]. A implementação de tais atividades foi realizada na ferramenta Eclipse Modeling Framework (EMF) [5]. Todos os meta-modelos foram desenvolvidos usando Ecore [5].

Figura 2. Processo para construir a infra-estrutura MDA

A atividade “Construir programa de transformação M2M” visa criar transformações de modelo para modelo, para transformar um modelo de aplicação genérico, desenvolvido a partir do meta-modelo PIM, em uma aplicação para uma plataforma de sensores específica, tendo como base um meta-modelo PSM alvo. Na infra-estrutura proposta os programas de transformação foram construídos usando a linguagem de transformação de modelos QVTO da OMG [20] (QVT Operacional Language).

Finalmente, a atividade “Construir programa de transformação M2T” visa a geração de código fonte na infra-estrutura proposta. Nesta atividade, são desenvolvidos os templates de código, que funcionam como esqueletos para cada plataforma-alvo. O programa de transformação M2T, usando uma instância de um modelo específico de plataforma (PSM), é capaz de gerar código-fonte para tal plataforma, baseado nos templates desenvolvidos. Nesse trabalho, esses templates foram desenvolvidos usando o plugin do Eclipse Acceleo. Acceleo é uma implementação da linguagem de transformação de modelo para texto MOF (MOFM2T) [16], o padrão OMG atual.

As atividades descritas produzem todos os artefatos de software incluídos na infra-estrutura MDA. Com estes artefatos (meta-modelos DSL/PIM, meta-modelos PSM para plataformas RSSF, transformações M2M e M2T), é possível aplicar a abordagem MDA proposta para a construção de aplicações de RSSF seguindo os passos mostrados no diagrama de atividades UML da Figura 1. Processo de desenvolvimento de aplicações RSSF com MDA. descrito na Seção II. Por questões de espaço, o diagrama da Figura 2 foi simplificado, não representando a iteratividade existente nas três atividades finais

112

do processo, as quais devem ser executadas para cada nova plataforma de sensores.

B. Artefatos da Infra-estrutura MDA 1) Meta-modelo da DSL

Foi realizada uma revisão da literatura sobre DSLs para RSSFs em trabalhos recentes, com objetivo de encontrar uma DSL com poder de expressão suficiente para descrever uma aplicação para RSSF sem que houvesse a necessidade de conhecimentos específicos dos diversos domínios de RSSFs. A lista bibliográfica completa da revisão realizada pode ser encontrada no sítio1 deste trabalho. Escolheu-se a DSL descrita em [12] para uso no presente trabalho. As motivações para tal escolha são: (i) esta DSL preenche os requisitos funcionais de uma ampla gama de aplicações de RSSF, e (ii) possui um nível de abstração adequado, sem incluir decisões de programação. Tal DSL foi construída para ajudar especialistas do domínio a descrever os seus sistemas usando apenas conceitos de RSSF com os quais estão familiarizados. Para incorporar os elementos desta DSL [12] na infra-estrutura proposta, ela foi especificada por meio de um meta-modelo Ecore.

A DSL utilizada inclui tanto características estruturais quanto comportamentais da aplicação. Em aplicativos desenvolvidos usando esta DSL, todos os objetos modelados são incluídos em uma aplicação de RSSF (elemento WSNApplication), onde essa aplicação é estruturalmente descrita como um conjunto de Regions. Uma Region é caracterizada pela proximidade física dos nós dentro dela. Todos os nós responsáveis pela execução de uma mesma tarefa são agrupados em um NodeGroup e Nodegroups implantados próximos uns dos outros são agrupados em uma região. NodeGroups diferentes podem ser conectados através de um WirelessLink. O elemento NodeDefinition descreve o tipo de nós (por exemplo, mote Micaz[4]) para ser utilizado na implementação do sistema para cada NodeGroup. Nodegroups ainda guardam informações sobre quantos nós estão no grupo e qual a política de energia a ser utilizada. Tal política é representada por um atributo (“consumo de energia”) cujo valor é um tipo enumerado e permite o desenvolvedor configurar um importante requisito de QoS para sua aplicação, que é relativo ao tempo de vida da rede. Atualmente há dois valores possíveis para esse campo: “padrão” e “economia”. A política de economia é usada para aplicações que demandam um longo tempo de vida (portanto requerendo o máximo de economia de energia) da rede em detrimento de outros parâmetros de QoS (como atraso por exemplo). Behavior é o elemento que representa o comportamento dos nós de um grupo (simulando uma máquina de estado). O comportamento dos nós de um mesmo NodeGroup é definido em termos de FunctionalUnits que podem ser tanto de Comunicação (CommUnit) ou unidades de tempo (TimerUnit). A funcionalidade representada por um FunctionalUnit é definida através de uma enumeração chamada FunctionalUnitType. Assim, a cada FunctionalUnit é atribuída a um FunctionalUnitType que representa um comportamento específico. Por exemplo, o FunctionalUnitType RECEIVE_MSG_RADIO define o comportamento para esperar por uma mensagem de entrada (recebida via rádio), o

1 http://labdist.dimap.ufrn.br/twiki/bin/view/LabDistProjects/WSN

FunctionalUnitType TIMER define um timer em milissegundos que deve terminar antes do início da próxima FunctionalUnit, etc. Além de definir as funcionalidades a serem realizadas pelos nós, o controle de fluxo também deve ser definido para especificar completamente a lógica da aplicação. UnitLinks são elementos que ligam as FunctionalUnits definidas dentro de um NodeGroup, definindo a seqüência em que eles serão executados. Além disso, FunctionalUnits podem ser designadas para Resources através de um ResourceLink. ResourceLinks podem ser definidos como Sensor, Port, ConfigParam ou Actuator de acordo com a necessidade do desenvolvedor.

2) Meta-modelos PSM para TinyOS2 e J2ME Esta Sub-seção descreve os dois PSM meta-modelos

definidos no trabalho: o TinyOS2.x e J2ME. TinyOS é um sistema operacional de código aberto projetado para RSSFs. Tem uma arquitetura baseada em componentes que permite a implementação de aplicações utilizando componentes pré-existentes. As bibliotecas do TinyOS incluem protocolos de rede, serviços e drivers para diferentes famílias de sensores. Várias plataformas de hardware de sensores, como Mica e a família Telos usam TinyOS. A linguagem NesC (uma extensão da linguagem de programação C) é utilizada na implementação de aplicações TinyOS. Sun SPOT (Sun Small Programmable Object Technology) é uma plataforma de RSSF desenvolvida pela Sun Microsystems que usa a linguagem Java para criar aplicativos. Dispositivos Sun SPOT usam a Squawk VM (uma máquina virtual J2ME pequenas) que permite executar aplicações RSSF diretamente no sensor (sem OS) poupando de sobrecarga e melhorando o desempenho.

Os meta-modelos TinyOS e SunSpot são ilustrados na Figura 3 (A) e (B). O PSM do TinyOS foi especificado através de uma extensa revisão de trabalhos sobre desenvolvimento de RSSF usando essa plataforma. Ele inclui um conjunto de características de execução que a DSL não abrange (como criação de eventos ou comando), já que esses recursos de baixo nível estão em geral fora do escopo do especialista de domínio. O meta-modelo projetado define as características básicas de qualquer aplicação implementada em nesC [7] para ser executada na plataforma TinyOS 2.x. Na linguagem nesC, uma aplicação de RSSF é composta de um conjunto de componentes que podem ser Modules ou Configurations. A diferença entre eles é que o primeiro abrange todas as peças programáveis do aplicativo executável (o código em si), enquanto o segundo é responsável por montar os componentes de uma determinada aplicação. Configurations conectam declarações de diferentes componentes, enquanto os Modules definem funções e atribuem estados [10]. Componentes provêm e usam Interfaces, que contém Events e Commands. Events funcionam como gatilhos para ativar uma ação desejada. Commands são funções que podem ser invocadas para instanciar as variáveis ou atribuir estados para um Module. Por exemplo, uma chamada ao comando "led0On()" da interface Leds instrui para ligar o led 0 do sensor. Os Modules devem implementar todos os Commands das Interfaces que são providas (provides) e cada Event de Interfaces que usam (uses). Cada Interface tem um tipo que especifica suas características. Esse tipo é definido pelo elemento TypeInterface do PSM, que representa uma lista (uma enumeração criada para a tipagem de

113

dados) de todas as interfaces disponíveis para o desenvolvimento de aplicação TinyOS.

Figura 3. Meta-modelos (A) PSM TinyOS e (B) PSM J2ME desenvolvidos

com Ecore.

O diagrama da Figura 3 (B) descreve o meta-modelo PSM para a plataforma SunSPOT/J2ME. Neste PSM, cada aplicação é representada por um sistema e pode ser composta por muitos pacotes, que podem conter várias classes. Cada classe é composta de atributos e métodos. Um método pode ter vários parâmetros de entrada e um parâmetro de saída ou mesmo nenhum. Parâmetros e atributos são Elements. Enumerations representam tipos de dados (elementType), visibilidade de um componente (Visibility) e o tipo de uma classe (Kind).

3) Transformações Para cada plataforma de sensor adicionada na infra-

estrutura MDA proposta, é necessário definir as respectivas transformações modelo para modelo (M2M) e modelo para texto (M2T) (atividades "Construir programa de transformação M2M" e "Construir programa de transformação M2T"). A Seção IV.A.2) detalha como estas transformações são utilizadas no processo MDA proposto. As transformações M2M são responsáveis por mapear elementos de DSL em elementos de um dado PSM. A Figura 4 mostra um trecho do código da transformação M2M definindo que o elemento WSNApplication da DSL seja mapeado para o elemento TinyOS System. Cada elemento DSL NodeGroup de uma Region é mapeado para elementos Application do TinyOS. Os elementos Behaviour da DSL dentro de cada NodeGroup são mapeados para elementos Application do TinyOS.

Para construir um programa de transformação M2T, modelos de código para cada plataforma de aplicação-alvo devem ser definidos. Modelos de código para as linguagens nesC e J2ME estão disponíveis no sítio deste trabalho. É interessante notar que as transformações M2M e M2T são definidas apenas uma vez, sendo reutilizados em vários sistemas de RSSF que compartilham a mesma plataforma de destino (ou seja, o mesmo meta-modelo PSM).

Figura 4. Fragmento de código QVTo para mapear elementos da DSL aos

elementos do TinyOS.

IV. PROVA DE CONCEITO Esta seção ilustra o emprego da abordagem MDA proposta

no desenvolvimento de aplicações de RSSF para um cenário inicial e, a seguir, apresenta vários cenários de mudança que exploram os benefícios de nossa proposta. Além de demonstrar os principais passos necessários para aplicar a proposta apresentada, o estudo realizado também mostra a sua utilidade em fornecer o isolamento entre os dois desenvolvedores distintos envolvidos no projeto de aplicações de RSSF, bem como a reutilização dos artefatos de software produzidos. O cenário inicial foi extraído de um importante domínio de aplicação de RSSF: monitoração da saúde de estruturas civis (do inglês Structural Health Monitoring - SHM) [3].

A. Cenário Base: Monitoramento da saúde estrutural (SHM) com Plataforma Mica Motes O objetivo das aplicações de monitoramento da saúde

estrutural (SHM - Structural Health Monitoring) é detectar e localizar danos em estruturas civis, como prédios, pontes e outras. Todas as estruturas reagem a vibrações, forçadas ou causadas pelo ambiente (naturais). Vibrações naturais podem ser geradas por terremotos, ventos, veículos em movimento, ondas, entre outros, enquanto vibrações forçadas são geradas por shakers e outros dispositivos. Há várias propostas de algoritmos para realizar detecção e localização de danos em estruturas. O cenário implementado no presente trabalho foi baseado em [3], onde são apresentados dois algoritmos para SHM. O primeiro trata da localização e o segundo da detecção de danos. No estudo realizado, vamos analisar apenas o algoritmo de detecção de danos, cujo objetivo é detectar a presença de danos em um edifício usando (i) acelerômetros capazes de detectar variações no comportamento da estrutura, e (ii) um computador externo ao processo de detecção dados; e determinar a existência de danos estruturais. Para a execução com sucesso desse algoritmo, são necessários no mínimo trinta nós sensores, a serem dispostos em cada andar do edifício monitorado, para obter dados com a precisão necessária para detectar qualquer anormalidade. O algoritmo de detecção funciona da seguinte forma: inicialmente, os sensores coletam

114

a assinatura inicial da estrutura monitorada e enviam essa informação para o nó coletor (sorvedouro) conectado a um computador. Essa leitura inicial consiste na assinatura de uma estrutura "saudável" (não danificada) e é usada para fins de comparação com as medições posteriores dos sensores. Em uma segunda fase, o sorvedouro calcula um conjunto de funções (como detalhado em [3]) e armazena os resultados para cada assinatura da estrutura, centralizando as funções de que necessitam de um maior processamento em um computador e não em cada nó sensor. A assinatura de uma estrutura é obtida após ter sido efetuada a coleta dos sinais de aceleração pelos sensores e representa a resposta vibracional da estrutura a estímulos recebidos. Após a coleta, é aplicada uma Transformada Rápida de Fourier (FFT) no sinal de aceleração coletado. A seguir, usa-se um método para extração dos valores de freqüência dos picos do espectro de freqüência gerado pela FFT. Esses valores de freqüências dos picos são as freqüências respectivas aos modos de vibração da estrutura. Os valores de freqüências obtidas em cada sensor, considerando a taxa de amostragem utilizada, referem-se aos primeiros picos do espectro de freqüência retornado pela FFT, e vão compor a chamada assinatura da estrutura.

Vários tipos de hardware de sensor fornecem as funcionalidades necessárias para uma aplicação SHM. No estudo realizado esse fato será explorado, desenvolvendo a mesma aplicação em diferentes plataformas de sensores. Inicialmente, no cenário base, a aplicação foi desenvolvida para rodar em nós sensores da família Mica Motes, mais especificamente na plataforma MICAz [4], executando TinyOS 2.x. Posteriormente, como um dos cenários de mudança, a aplicação irá rodar em nós sensores Sun Spot executando J2ME [22]. Na primeira configuração (cenário base) tem-se nós sensores MICAz modelo MPR 2400, que são alimentados por baterias e operam com rádio IEEE 802.15.4, associados a placas de sensoriamento modelo MTS 310, que possuem acelerômetro de 2 eixos. Na segunda configuração (descrita na Seção B.1), tem-se nós Sun SPOT modelo MPR 2400, que também operam com rádio IEEE 802.15.4, associados a placas de sensoriamento com acelerômetro de 3 eixos. Para ambos os casos, o hardware do nó sorvedouro (ou estação base) é o mesmo dos nós sensores, embora esse nó esteja desconectado das placas de sensoriamento e conectado a um computador pessoal através de um cabo USB, usando um gateway MIB 520 no caso do nós MICAz ou porta USB padrão no caso do nó Sun SPOT. O computador pessoal receberá os dados coletados pelos sensores e aplicará o algoritmo de detecção de danos.

1) Modelagem da aplicação SHM com a DSL Segundo o processo proposto, os especialistas de rede e de

domínio iniciam a atividade "Análise de Requisitos", gerando como saída o CIM. Em seguida, o especialista de domínio inicia a atividade "Modelagem da aplicação com DSL", utilizando como base a DSL descrita na Subseção III.B.1), bem como o modelo CIM. Como atividade paralela, o especialista de rede analisa o CIM e escolhe qual é a plataforma de sensores, dentre as disponíveis, que melhor se adéqua aos requisitos da aplicação alvo.

Duas regiões (elemento Region da DSL) foram criadas para modelar o cenário referente a aplicação de SHM. A primeira Region (chamada downtier) representa a instalação

da RSSF em um dos andares do prédio (se houver mais andares o modelo seria basicamente o mesmo definido para a Region downtier, necessitando apenas incluir e ligar novos WirelessLinks). Dentro de uma Region downtier, um NodeGroup é definido como composto por 30 nós sensores com função de coletar dados (valores de aceleração) de um dos andares do edifício. Além desse requisito funcional básico definido para o grupo de nós, define-se um requisito de QoS (não funcional) que é a política de uso de energia. Aplicações de SHM requerem monitoramento periódico por um longo tempo. Portanto a aplicação requer um grande tempo de vida útil da rede; para tal o desenvolvedor escolhe a política de “economia”. A segunda Region (uptier) possui um NodeGroup (nomeado SinkNode, contendo apenas o nó sorvedouro) responsável por receber os dados enviados pelos nós sensores na Region de detecção (downtier) e com conexão com o computador externo responsável pela execução do cálculo da detecção de danos. As duas Regions se comunicam entre si através de um WirelessLink. É importante notar que esta configuração, sensor-sorvedouro, é a mais comumente usada em cenários de RSSF, onde um nó sorvedouro é responsável pela distribuição das tarefas de sensoriamento e de receber os dados coletados pelos sensores. O nó sorvedouro em geral está localizado em uma área geográfica distante do local onde os nós sensores são implantados.

O funcionamento da aplicação em questão é semelhante ao funcionamento de uma máquina de estado, que se inicia a partir de uma FunctionalUnit do tipo START_SENSING e usando UnitLinks para conectar todas as FunctionalUnit necessárias para operacionalizar o comportamento da aplicação. Usando essa abordagem, o funcionamento da aplicação consiste em um conjunto de chamadas de função, de acordo com o algoritmo adotado (representando a lógica da aplicação). Neste exemplo, as funções TimerUnits, FunctionalUnits e CommUnit foram utilizadas. A função dos TimerUnits é definir o tempo de acesso da aplicação aos dados sensoriados e mudar a taxa de envio de dados. Uma aplicação que requeria o envio de informações em tempos menores deve configurar uma taxa maior. As FunctionalUnits realizam tarefas como START_SENSING, para que os nós sensores iniciem o processo de sensoriamento; CONFIG_RADIO, para configurar o rádio; USER_DEFINED para criar uma função específica para esta aplicação, tal como calibrar a placa de sensoriamento; SEND_ACTION, para acionar atuadores e READ_SENSOR_DATA, para ler os dados do sensor. O CommUnit visa realizar o envio dos dados coletados pelos nos sensores para o nó sorvedouro através de um SEND_MSG_RADIO. Alguns ResourceLinks são usados para conectar FunctionalUnits a dispositivos externos, a fim de enviar (para a porta serial no computador) ou coletar (a partir das placas de sensoriamento) dados. Por exemplo, as FunctionalUnits com o tipo READ_SENSOR_DATA, chamadas getSamples, usa um inResource, o que significa que ele irá obter algumas informações do sensor.

Um timer de repetição foi inserido na aplicação modelada de forma que os procedimentos descritos pelo respectivo algoritmo possam ser repetidos a cada 24 horas. Na região uptier uma CommUnit foi adicionada para receber dados e um

115

ResourceLink foi adicionado para enviar eporta do computador para serem processados

Figura 5. Aplicação SHM modelada com

A Figura 5 mostra uma WSNApplicatioque engloba duas Regions (downtier eWirelessLink que representa a comunicação eDentro de cada região há um NodeGroup dispositivos que compartilham as mesmfísicas são alocados. Por exemplo, Damage_detection_1 tem 30 nós sensores usam a mesmo NodeDefinition (que inclueacelerômetro). A Figura 5(A) mostra o celemento getData usando um FuntionalUnirecursos (nós) por meio de um ResourceLinmostra as FunctionalUnits que modelam dentro do NodeGroup que atua como sorvefinalizada a modelagem da aplicação considerando que o especialista de redplataforma de sensores que melhor se adaptpresente aplicação, ambas as atividades aplicação com DSL" e "Escolher Plataformaconcluídas para a aplicação SHM.

2) Gerando o PSM e o código-fonte O PSM e o código-fonte são gerados pel

M2M e M2T disponíveis na infra-estrutuestudo mostrado serão usadas duas trans(DSL-TinyOS e DSL-Sun SPOT) e duas tra(TinyOS-nesC e Sun SPOT-Java). A desenvolvida com a DSL pode ser utilizamodelos PSM tanto do TinyOS quantalcançando a reutilização da especificaçãoPara gerar o modelo PSM e o código-fonte, do M2M e M2T são executadas dentro do ade acordo com as atividades mostradas na Fi

Um exemplo do caminho percorrido petransformação da DSL ao código é: FunctionalUnit READ_SENSOR_DATA M2M adiciona ao modelo do PSM as classerealizar o sensoriamento. Para tal, é analisadassociado a READ_SENSOR_DATA para de sensor que está sendo lido e assim adiciao modelo do PSM todos os requisitos, vaeventos e comandos necessários. A transforPSM para texto é mais simples compararealizando apenas a leitura do mode

sses dados a uma .

m o DSL.

on nomeada SHM e uptier) e um entre essas regiões.

em que todos os mas características

o NodeGroup e todos esses nós

em as placas com comportamento do it que faz uso dos nk. A Figura 5 (B) o comportamento

edouro. Depois de com a DSL, e e já escolheu a a às exigências da

"Modelagem da a” (Figura 1) estão

las transformações ura MDA. Para o sformações M2M nsformações M2T aplicação SHM

ada para gerar os to do SUNSpot, o das aplicações. as transformações

ambiente Eclipse e gura 1. elos programas de

ao detectar a a transformação

es necessárias para do o ResourceLink

determinar o tipo onar corretamente ariáveis, módulos, rmação do modelo ada com a M2M, elo do PSM e

transformando, seguindo o melemento do PSM em um elem

Figura 6. Fragmento de código geradSun SP

Nesse primeiro cenário, sãoTinyOS/nesC. Uma vez quexecutada, o especialista de rModelo", cujo objetivo é adiincluídos na DSL. Um exemprotocolo de comunicação queda rede, no caso, um protocolsaltos, como o CTP [26]. Paramodificar o PSM gerado da smodelo os componentes que recriar elementos de ligaçãocomponentes CTP aos componmodificar o elemento de confiligações (wirings) para os novnotar que essa tarefa exige cRSSF, bem como conhecimenque não são comumente especialistas de domínio. Apósum PSM refinado com as infocódigo fonte. Finalmente, a atiM2T" é realizada tendo como para a plataforma escolhida e transformação gera todos ocompilar a aplicação (configugerado pode também exigir apSHM, o especialista de domírelacionadas com o algoritmodetecção de danos (por exemp

modelo de código adotado, um ento de código-fonte.

do para a aplicação SHM. TinyOS (A), POT (B).

o usadas as transformações para ue a transformação M2M é rede inicia a atividade "Refinar cionar elementos ao PSM não

mplo típico é a escolha de um e melhor se adéqüe a topologia o de roteamento com múltiplos

a tal, o especialista da rede deve seguinte forma: (i) adicionar ao epresentam o protocolo CTP, (ii) o que conectem os novos nentes já incluídos no PSM, (iii) iguração existente, incluindo as vos componentes. É importante conhecimento de protocolos de nto das plataformas de sensores, parte das competências dos s concluir esta atividade, temos

ormações necessárias para gerar ividade "Aplicar Transformação entrada os templates de código o modelo PSM refinado. Essa

os arquivos necessários para uração e módulos). O código

perfeiçoamentos. Para o cenário ínio tem de incluir as funções o específico empregado para a lo, funções para calcular a FFT

116

e extrair os picos de freqüência de uma série temporal). A Figura 6(A) mostra um exemplo de código gerado pela transformação M2T para o estudo de caso apresentado, considerando o TinyOS como a plataforma-alvo.

B. Cenários de Mudança e Discussão 1) Mudança da plataforma No estudo realizado, parte-se do pressuposto que a primeira

escolha de uma plataforma de sensores para a aplicação SHM foi TinyOS. Porém, em um cenário típico do ambiente RSSF, uma mesma aplicação posteriormente necessita ser executada em outra plataforma. Neste caso, estamos considerando a SUN Spot como segunda plataforma. O objetivo é ilustrar como a proposta promove a reutilização da especificação da aplicação e, portanto, a reutilização de todo o conhecimento de domínio, independente de mudanças da plataforma alvo. Sem usar a abordagem proposta, o código completo da aplicação precisaria ser reescrito a partir do zero. Ao utilizar a abordagem proposta, uma vez que a infraestrutura construída já provê os metamodelos e transformações necessários, 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 da DSL para o PSM do SunSPOT a fim de gerar um modelo de aplicação para o SunSPOT, realizando qualquer refinamento exigido no modelo gerado e, em seguida, aplicar a transformação M2T correspondente (e refinar o código gerado). A Figura 6(B) ilustra o código-fonte gerado para SunSPOT para a mesma aplicação de SHM.

2) Mudança de protocolos de nível de rede Há vários protocolos especificamente projetados para RSSF

[10], 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. Com 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”. No caso da aplicação com plataforma alvo TinyOS, para mudar o protocolo faz-se necessária uma atualização no Modelo PSM que foi gerado automaticamente pelo processo MDA proposto. Esta atualização é composta de três fases: a primeira é a remoção dos componentes que estão declarados, mas que não serão mais utilizados; a segunda é a adição dos novos componentes que implementam o novo protocolo necessário; e a terceira, é refazer os wirings (ligações) dos componentes religando uma interface que está sendo usada com a nova implementação provida pelos componentes adicionados. É 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.

3) Mudança de 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 o especialista de domínio só precisa mudar o valor do atributo “consumo de energia” do NodeGroup (no caso, de “economia” para “padrão”). 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. Assim, a transformação M2M irá gerar o modelo PSM utilizando Configurações que condizem com a escolha do especialista. Outro caso típico é a aplicação passar a requerer agregação de dados antes de enviar para o sorvedouro. Nesse caso, o especialista de domínio terá que alterar o fluxo de atividades que ocorre dentro do Behaviour do NodeGroup. Por exemplo, adicionar uma FunctionalUnit do tipo STORE_DATA_RAM para guardar um valor no próprio sensor e realizar, através de um outro fluxo de FunctionalUnits, a agregação dos dados antes de enviar ao sorvedouro.

4) Nova aplicação Nesse cenário ilustra-se o reuso de artefatos ao nível de

plataforma, obtido ao se criar uma nova aplicação usando a abordagem proposta. Nesse caso, será necessário realizar todas as atividades mostradas na Figura 1, ou seja, fazer o levantamento de requisitos, em seguida modelar a aplicação com a DSL, e assim sucessivamente. Consideramos o novo domínio uma aplicação do monitoramento de atividade vulcânica [28]. O uso de RSSF para monitoramento de atividade vulcânica tem ganhado destaque devido à grande vantagem em relação a custo, tamanho e requisitos de energia se comparados aos instrumentos tradicionalmente usados nos estudos de vulcões. Em [28] é descrita uma aplicação para monitoramento vulcânico baseada no uso de 5 sensores do tipo Mica2. Resumidamente, os sensores são divididos em três grupos: no primeiro, com três sensores, os Motes possuem microfones infrasônicos acoplados e realizam a captação de dados e enviam para o sorvedouro; no segundo grupo um nó dotado de GPS é responsável por realizar a sincronização dos sensores com microfones repassando para estes mensagens com atualizações do tempo; o ultimo grupo é um nó sorvedouro que recebe as informações dos nós com microfones e as passa através de uma porta serial para um dispositivo de maior potência, que pode enviar o sinal para a estação de controle localizada a quilômetros do vulcão. Com a abordagem proposta, a aplicação pode ser modelada com uma Region contendo três NodeGroups, responsáveis pelas atividades dos três grupos de sensores descritos. Dentro de cada NodeGroup é adicionado um Behaviuor que irá descrever o comportamento de cada um dos nós. Com a aplicação modelada com a DSL, o especialista em redes iria “Escolher a Plataforma” e usar a infra-estrutura MDA para fazer a transformação M2M e gerar um modelo específico desta aplicação na plataforma escolhida (Mica-TinyOS). Por fim, seriam realizados os refinamentos tanto no modelo especifico de plataforma quanto no código gerado após a transformação M2T.

Assim, é possível perceber que com a abordagem proposta pode-se modelar outras aplicações, de diversos domínios, usando a mesma infra-estrutura e reusando-se todos os

117

artefatos MDA da infra-estrutura (DSL, PSMs, transformações M2M e transformações M2T) reutilizáveis.

V. AVALIAÇÃO A abordagem MDA proposta foi avaliada sob diferentes

perspectivas. Primeiramente, foram realizadas duas análises objetivas avaliando a capacidade do processo proposto de geração de código-fonte e a corretude do código gerado. Em seguida, conduzimos um experimento com dois grupos de programadores com o intuito de comparar o esforço de construir uma aplicação RSSF usando a abordagem tradicional com a nossa abordagem MDA. Por último, realizamos uma análise subjetiva baseada nos resultados do Estudo de Caso.

Para a aplicação SHM, a TABELA 1 mostra a quantidade de linhas de código (LOC, do inglês Line of Code) geradas automaticamente pela abordagem proposta. Como pode ser visto, a abordagem gera praticamente 100% do código-fonte necessário para compilar a aplicação, necessitando a adição de poucas linhas de código na plataforma TinyOS para a especificação de um Makefile. Resultados similares foram obtidos pela aplicação de monitoramento vulcânico. Isso demonstra a diminuição no esforço de programação obtida, benefício tradicionalmente ganho com abordagens MDA.

TABELA 1. LINHAS DE CÓDIGO GERADAS PARA A APLICAÇÃO SHM.

Plataforma LOC Gerada LOC Adicionada TinyOS 141 2

SunSPOT 191 0 Como forma de avaliar a corretude do código-fonte gerado

pela abordagem apresentada foram realizados Testes de Unidade. Os testes foram realizados para a aplicação SHM com o código-fonte gerado para TinyOS rodando dentro do ambiente de simulação do TinyOS, o TOSSIM [27], a partir da criação de um arquivo de descrição da rede e de inserções no código para a realização das verificações necessárias. Os casos de testes foram baseados nas entradas e sinais necessários para rodar a aplicação de modo a mesma executar todos os passos usando um critério de cobertura de caminho. Os testes de unidade têm como objetivo testar trechos do código (neste caso funções e o uso de eventos) com objetivo de encontrar falhas nestas partes. Os testes são feitos comparando os resultados dados pelo sistema com os resultados esperados pelo testador. Os resultados mostraram que o código gerado não apresentou erros em testes de unidade no código gerado, ou seja, o código gerado é correto e funcional. É importante ressaltar que o código utilizado para os testes não passou pela atividade “Refinar Código” do processo de desenvolvimento de aplicações RSSF com MDA proposto, por isso algumas funções apresentam apenas a sua assinatura descrita no código. Ainda seria necessário incluir nestas funções as linhas de código necessárias para que elas efetuem corretamente a tarefa a que lhes foi atribuída, porém essa é uma atividade manual.

Em uma segunda abordagem de avaliação foram realizados experimentos com alunos de Ciência da Computação da UFRN. Os alunos foram divididos em dois grupos: um grupo usando a abordagem proposta (1) e outro a programação tradicional para sensores (2). Além das aplicações descritas no presente artigo, outras três aplicações, retiradas do tutorial do TinyOS, foram usadas para os experimentos. Todas possuíam

complexidade similar, consistindo de tarefas de sensoriar e enviar dados. O experimento iniciou com a explicação dos requisitos das aplicações para ambos os times, seguida de uma explicação do processo MDA proposto. Os componentes do grupo responsável pelo desenvolvimento no modo tradicional possuíam conhecimento intermediário de programação para TinyOS/nesC e o outro grupo não possuía conhecimento prévio do processo de desenvolvimento (incluindo a DSL). A Tabela 2 mostra os resultados. A média de tempo de desenvolvimento de uma aplicação usando a abordagem tradicional foi de quatro horas enquanto a média do tempo usando a nossa abordagem foi de 30 minutos, demonstrando uma redução significativa no tempo de desenvolvimento da aplicação usando a abordagem.

TABELA 2. RESULTADOS DOS EXPERIMENTOS.

Aplicação Grupo 1 Grupo 2 SHM 45 min 9hs

Vulcão 45 min 9hsBlink leds 30 min 3hs

Basic dissemination 35 min 3hs Leds counter 25 min 2hs

Com relação a prova de conceito, ela demonstrou que a proposta atingiu de modo satisfatório seus objetivos. O processo MDA proposto promoveu uma separação clara da lógica de domínio da lógica de redes. O especialista do domínio em ambos os casos (SHM e vulcões) precisava apenas conhecer os elementos da DSL e o básico de programação (para a atividade Refinar Código). Por outro lado, o especialista em redes precisou apenas lidar com elementos relacionados a redes, tanto no PSM quanto em nível de código.

VI. TRABALHOS RELACIONADOS Apesar de ser uma preocupação recente, já existem trabalhos

que abordam metodologias sistemáticas para construir aplicações de RSSFs e mesmo alguns com desenvolvimento orientado a modelos (MDD). TinyCubus [14] é um framework que permite selecionar dinamicamente e interligar componentes do TinyOS predefinidos. TinyDB [13] define uma visão de banco de dados para o TinyOS, onde consultar predefinidas são distribuídas e executadas em diferentes nós de uma RSSF. Os dois trabalhos exigem um conhecimento profundo da plataforma-alvo e os projetos resultantes são difíceis de manter, modificar e reutilizar. Em [1] é apresentado Baobab, um framework de meta-modelagem para projetar aplicações de RSSF e gerar o código correspondente. Baobab permite aos usuários definir aspectos funcionais e não funcionais de um sistema separadamente, como modelos de software, validá-los e gerar o código automaticamente. Diferentemente da abordagem proposta neste trabalho, o Baobab gera código para uma única plataforma, o nesC. Além disso, todos os meta-modelos usados no Baobab estão muito mais próximos do nível de hardware/programação de baixo nível do que a DSL que estamos usando. Portanto, nenhum dos trabalhos citados permite o desenvolvimento de aplicações de RSSF sem exigir que o especialista de domínio necessite de conhecimentos específicos e de baixo nível dessas plataformas, diferentemente da nossa proposta.

Em [2] é proposta uma abordagem baseado em modelo utilizando DSLs e geradores de código para gerar um middleware específico para a aplicação e aumentar a

118

reutilização em sistemas de RSSFs. Uma abordagem baseada em componentes é adotada para a DSL e a aplicação de RSSF é interpretada como um conjunto de componentes que interagem através de um modelo baseado em eventos. A transformação do modelo em código executável e a geração de middleware são realizadas por um gerador de código baseado em modelo. Diferentemente desse trabalho, a proposta apresentada não adota uma solução baseada em componentes e foi projetada para ser estendida através de uma abordagem baseada em meta-modelos. Além disso, em [2] não é abordada a separação de responsabilidades entre os diferentes tipos de desenvolvedores envolvidos na criação de aplicações de RSSF.

Em [12] é apresentada uma abordagem MDE para o desenvolvimento de aplicações de RSSF. Três níveis de abstração são definidos que permitem aos desenvolvedores criar: (1) os modelos específicos de domínio, (2) descrições da arquitetura baseada em componentes, e (3) modelos específicos de cada plataforma. Transformações automatizadas de modelos entre esses três níveis de abstração foram concebidas e, para demonstrar a viabilidade da proposta, foi desenvolvido um aplicativo para controle de irrigação em RSSF. Embora esta proposta seja semelhante a nossa, no sentido de usar transformações entre modelos, ela não explora a geração de PSMs para diferentes plataformas, nem demonstra o comportamento da abordagem para diferentes domínios. Também não é explorado o fato de que a construção de sistemas de RSSFs envolve desenvolvedores com diferentes conhecimentos e habilidades. Outra diferença é que, enquanto o presente trabalho adota uma DSL textual, em [12] é fornecido um editor gráfico para modelagem do aplicativo, que pode ser mais conveniente para alguns usuários.

A referência [23] fornece uma solução MDE sofisticada que suporta o ciclo de vida completo de desenvolvimento de aplicações de uso geral. Esta solução oferece um plug-in NesC para modelagem gráfica e automatizada para a geração de código NesC [7]. Usando artefatos de uso geral "adaptados" para o domínio de RSSF, aplicações de RSSF podem ser modeladas em alto nível de abstração. Na presente proposta, ao invés de usar artefatos genéricos adaptados para RSSFs, foi desenvolvida uma solução específica adaptada a realidade dessas redes, levando em conta e explorando os diferentes conhecimentos dos desenvolvedores para tal ambiente.

VII. CONSIDERAÇÕES FINAIS Neste artigo foi mostrado como o uso de uma abordagem

dirigida a modelos pode facilitar o desenvolvimento de aplicações para RSSF aumentando o nível de abstração e possibilitando a geração de código-fonte de forma automática (ou semi) da maior parte do código fonte necessário. A construção de aplicações segundo a abordagem proposta possibilita a divisão de responsabilidades entre os desenvolvedores, permitindo que eles usem seus conhecimentos específicos e evitando a necessidade de especialistas terem que lidar com requisitos que não fazem parte de seu conhecimento. Outra importante contribuição da proposta é sua capacidade de lidar com a alta heterogeneidade e as constantes mudanças tecnológicas na área de RSSFs, já que no evento de uma mudança de plataforma toda a lógica de aplicações já desenvolvidas pode ser imediatamente reusada.

REFERÊNCIAS [1] B. Akbal-Delibas, P. Boonm and J. Suzuki, “Extensible and Precise

Modeling for Wireless Sensor Networks.”, UNISCON 2009, LNBIP 20, pp. 551–562, 2009.

[2] C. Buckl, S. Sommer,A. Scholz, A. Knoll and A. Kemper, “Generating a Tailored Middleware for Wireless Sensor Network Applications.”, IEEE SUTC 2008, pp. 162–169, 2008.

[3] K. Chintalapudi, et al, “Structural Damage Detection and Localization Using NetSHM”, IPSN 2006, pp. 475–482, 2006.

[4] Crossbow Tecnology products overview, available at: http://www.xbow.com/Products/wproductsoverview.aspx

[5] EMF available at: http://www.eclipse.org/modeling/emf [6] B. Forstner, et al, “Model-Based System Development for Embedded

Mobile Platforms”, MBD/MOMPES’06, pp. 43–52, 2006. [7] D. Gay, et al, “The nesC Language: A Holistic Approach to Networked

Embedded Systems”, ACM SIGPLAN, pp. 1–11, 2003. [8] T. He, B. M. Blum, J. A. Stankovic and T. Abdelzaher, “AIDA:

Adaptive Application Independent Data Aggregation in Wireless Sensor Networks”, ACM Transactions on Embedded Computing System, v. 3, n.2, pp. 426–457, May 2004.

[9] W. B. Heinzelman, A. P. Chandrakasan and H. Balakrishnan, “An Application-Specific Protocol Architecture for Wireless Microsensor Networks”. IEEE Transactions on Wireless Communications, v.1, n. 4, pp. 660-670, Oct 2002.

[10] P. Levis, “TinyOS Programming”, available in http://www.tinyos.net/tinyos-2.x/doc/pdf/tinyos-programming.pdf

[11] J. Liu and F. Zhao, "Towards Semantic Services for Sensor-Rich Information Systems", 2nd IEEE/CreateNet International Workshop on Broadband Advanced Sensor Networks, Boston, MA, Oct 2005.

[12] F. Losilla, C. Vicente-Chicote, B. Álvarez, A. Iborra and P. Sánchez, “Wireless Sensor Network Application Development: An Architecture-Centric MDE Approach”. ECSA 2007, LNCS 4758, pp. 179-194, 2007.

[13] S. R. Madden, M. J. Franklin, J. M. Hellerstein and W. Hong, “TinyDB: An Acqusitional Query Processing System for Sensor Networks”. ACM Transactions on Database Systems 30, pp. 122-173, 2005.

[14] P. Marrón, D. Minder, A. Lachenmann and K. Rothermel “TinyCubus: An Adaptive Cross-Layer Framework for Sensor Networks”. Information Technology: Vol. 47, Issue 2, pp. 87-97, 2005.

[15] Model Driven Architecture, available at http://www.omg.org/mda/ [16] Model To Text (M2T): Acceleo, available at:

http://www.eclipse.org/modeling/m2t/?project=acceleo [17] OMG, Object Management Group. Meta-model and UML Profile for

Java and EJB Specification. OMG Adopted Specification: formal/040202 (2004).

[18] PathfinderMDA, available at: http://www.pathfindermda.com/sorting-out_prt1.pdf

[19] R. Pressman. “Software Engineering: A Practitioner's Approach”, MacGraw Hill, 2004.

[20] QVTo - Operational QVT Language Documentation, available at: http://www.eclipse.org/m2m/qvto/doc/

[21] D. A. Sadilek, “Prototyping Domain-Specific Languages for Wireless Sensor Networks”. ATEM (2007). 2007.

[22] Sun SPOT World, available at: http://www.sunspotworld.com [23] The Cadena 2.0 Project: Kansas State University, USA, available at:

http://cadena.projects.cis.ksu.edu/ [24] TinyOS Community Forum, available at: http://www.TinyOS.net [25] M. Wang, J. Cao and J. Li, “Middleware for Wireless Sensor Networks:

A Survey”. JCST, pp. 305-326, May 2008. [26] The Collection Tree Protocol, available in: http://www.tinyos.net/tinyos-

2.x/doc/txt/tep123.txt [27] TOSSIM, availible at: http://docs.tinyos.net/index.php/TOSSIM [28] Monitoring Volcanic Eruptions with a Wireless Sensor Network,

availible at: http://www.eecs.harvard.edu/~werner/projects/volcano/.

119