Apesar de ser uma área emergente, já existem diversos trabalhos acerca da utilização de DSLs para o desenvolvimento de aplicações para RSASF [AKBAL- DELIBAS, 2009], [LOSILLA, 2007], [SHIMIZU, 2011], [BOONMA, 2011]. No entanto, nos trabalhos reportados atualmente na literatura, ou os autores propõem a utilização de apenas um modelo gráfico ([AKBAL-DELIBAS, 2009], [LOSILLA, 2007]), razão esta que acaba dificultando a modelagem dos sistemas, ou, mesmo desenvolvendo mais de uma DSL, não propõem a divisão entre modelos estruturais e comportamentais ([SHIMIZU, 2011]), não havendo uma separação clara entre estes dois aspectos. Com isso, as linguagens propostas acabam tornando-se ou extensas demais (e, portanto muito genéricas), a fim de englobar todas as características possíveis, tanto da rede, quanto dos sistemas, dessa forma, dificultando a programação dos sistemas tanto quanto se fosse utilizada uma linguagem de programação, ou simplistas demais, mantendo fixas algumas características importantes para os sistemas, e, portanto especializando-se em demasia ao ponto de não contemplarem características básicas da área de RSASF e, assim, inviabilizando a programação eficiente dos sistemas.
Estabelecer um equilíbrio entre a generalidade e a especificidade é um desafio ao se projetar uma DSL. Neste trabalho buscamos encontrar uma solução de compromisso nesse sentido. Buscamos também oferecer uma solução que promova uma clara separação de interesses entre os especialistas envolvidos no desenvolvimento de sistemas para RSASF, visto que tal separação promove uma melhora na modularidade dos sistemas e, por sua vez, ocasiona a diminuição dos custos tanto de tempo quanto de capital envolvidos durante a fase de desenvolvimento.
Em [AKBAL-DELIBAS, 2009], é apresentado o framework Baobab. Trata-se de um framework MDD para o desenvolvimento de sistemas para RSSF. Na
57
proposta do Baobab é descrito um metamodelo que inclui os componentes e comportamentos mais comuns da área de RSSF. Além disso, a DSL que compõe o framework pode ser estendida pelos próprios desenvolvedores para englobar novos domínios de aplicações e plataformas para RSSF. O metamodelo engloba ainda a modelagem de requisitos não-funcionais, como a formação de clusters na rede, e funcionais. Adicionalmente, a DSL suporta a inclusão de restrições OCL (Object Constraint Language), característica esta que garante que todos os modelos gerados pela DSL serão válidos. Por se tratar de um framework MDD, também é possível gerar o código fonte das aplicações modeladas.
A DSL descrita em [AKBAL-DELIBAS, 2009] difere da linguagem LWiSSy pelo fato de agregar muitas informações de baixo nível de abstração em seu metamodelo (definição de algoritmos de cluster, gerenciamento do ciclo de trabalho considerando informações de cluster, dentre outros), o que dificulta a modelagem de sistemas pelo especialista de domínio. Adicionalmente, o metamodelo deve ser especificado por meio de apenas um modelo gráfico, o que causa uma dependência entre os especialistas de domínio e de redes, os quais terão que efetuar a modelagem em conjunto. Além disso, o fato do metamodelo proposto ser muito extenso e ainda existir a possibilidade de extensão do mesmo pelos próprios desenvolvedores, a modelagem dos sistemas de RSSF pode se tornar tão complexa quanto à programação em baixo nível.
Moppet, um framework de desenvolvimento dirigido a modelos para RSSF, é proposto em [BOONMA, 2011] com o objetivo de auxiliar na construção de aplicações para RSSF, bem como estimar a performance destas. O framework é capaz de prever o consumo de energia e o ciclo de vida dos nós da rede sem que para isto seja necessário efetuar a geração de código-fonte. Além disso, é possível gerar o código-fonte das aplicações na linguagem nesC e, portanto, implantá-lo em nós que suportam a plataforma TinyOS. Assim como a DSL proposta em [AKBAL-DELIBAS, 2009], a DSL definida no framework Moppet engloba algumas características com baixo nível de abstração (protocolos de roteamento e hardware dos nós utilizados) e, dessa maneira, o desenvolvimento
58
de aplicações com esta DSL, em geral, tem que considerar o trabalho em conjunto dos especialistas envolvidos no desenvolvimento (especialistas de domínio e de redes). Adicionalmente, até mesmo para o especialista de redes, esta DSL não é de fácil usabilidade, uma vez que alguns conceitos de RSSF que são utilizados por toda aplicação da área não são facilmente modelados, como por exemplo, a comunicação entre os nós, a qual não é considerada.
Em [LOSILLA, 2007] é apresentada uma abordagem MDE para o desenvolvimento de sistemas de RSSF. Nesta abordagem é proposta uma linguagem que tem como objetivo ajudar especialistas de domínio a incluir toda a informação necessária ao sistema por meio de modelos. Este trabalho também efetua a geração automática do código fonte do sistema para RSSF. Apesar de LWiSSy ter sido desenvolvida com base no metamodelo proposto em [LOSILLA, 2007], eles diferem em alguns aspectos. Em [LOSILLA, 2007] apenas um modelo gráfico é gerado, o que acaba dificultando a separação de interesses (especialistas de domínio e de redes) e de características estruturais e comportamentais durante a modelagem dos sistemas. Além disso, o metamodelo possui um alto nível de abstração e, por sua vez, não abrange características importantes da área de RSASF, como: suporte a agregação de dados, definição da topologia da rede, inserção de componentes de decisão durante a modelagem comportamental do sistema, dentre outras.
O trabalho descrito em [SHIMIZU, 2011] propõe a divisão do processo de desenvolvimento de sistemas para RSASF em três modelos distintos. Tal divisão foi proposta porque, segundo o autor, a programação de sistemas para RSASF pode ser efetuada considerando três enfoques diferentes, os quais possuem características distintas. Além disso, ainda é possível solucionar o tradeoff existente entre o custo de prototipagem e a capacidade de otimização de desempenho das aplicações presentes no sistema.
Os enfoques observados, ou níveis de granulosidade, são os seguintes: nível de rede, nível de grupos de nós sensores e nível de nó. Os modelos do nível de
59
rede devem focar em abstrações da rede e descrever o processamento de dados considerando a rede como um todo. Neste modelo é possível definir os pontos de agregação, de fusão e os nós sink da rede. Já os modelos de nível de grupos de nós dependem do modelo de nível de rede e descrevem características relacionadas à comunicação e tratam um grupo de nós como uma entidade única. Por fim, o modelo de nível de nó também depende do modelo de nível de rede e descreve o comportamento de cada um dos nós considerando características de hardware.
Ainda em [SHIMIZU, 2011], a construção da aplicação é dividida em duas fases: prototipagem e otimização. Na fase de prototipagem o desenvolvedor determina apenas o modelo de nível de rede, enquanto que os modelos de nível de grupos de nós e de nível de nó são gerados automaticamente a partir do modelo de rede (apesar do modelo em nível de nó depender diretamente apenas do modelo de rede, a geração deste modelo ocorre somente após a geração automática do modelo de grupos de nós) e por fim um modelo executável é gerados automaticamente com base nos modelos anteriores.
Na fase de otimização, que pode ser vista como um ciclo, o desenvolvedor executa o modelo executável gerado, monitora seu desempenho, refina o modelo (rede, grupo ou nó), que julgar necessário, a fim de otimizá-lo e efetua a geração automática dos demais modelos (da mesma maneira que ocorre durante a fase de prototipagem) para gerar um modelo executável e reiniciar a fase de otimização.
Nota-se que no trabalho de Shimizu ([SHIMIZU, 2011]) os modelos, diferentemente dos modelos utilizados em LWiSSy, podem ser vistos como “programas”, uma vez que tratam-se de modelos executáveis, representados por diagramas de classe UML.
Apesar de propor a construção de várias DSLs, o trabalho descrito em [SHIMIZU, 2011] limita-se a modelagem de aspectos estáticos de sistemas de sensoriamento, não contemplando a parte comportamental do sistema,
60
característica esta que é crucial para a modelagem das aplicações de RSASF que compõem o sistema. Além disso, o trabalho não efetua consideração sobre a participação de desenvolvedores com diferentes conhecimentos e habilidades, ou seja, o especialista de domínio e o especialista de rede. Dessa forma, estes especialistas continuam dependentes entre si durante a modelagem do sistema. Adicionalmente, os metamodelos propostos não tratam algumas características de “baixo nível” que são primordiais durante a modelagem das aplicações. Alguns exemplos disto são a ausência de protocolos de comunicação, protocolos de controle de topologia da rede e de dispositivos presentes na rede (atuadores, portas que efetuam a comunicação entre os nós sink e as estações base).
Além das diferenças já citadas acima com relação aos metamodelos propostos em [AKBAL-DELIBAS, 2009], [BOONMA, 2011] e [LOSILLA, 2007], ao contrário destes, LWiSSy efetua a divisão, através do uso de modelos gráficos distintos, da modelagem de sistemas de RSASF em três níveis, os quais serão descritos na Seção 4.2. A utilização de apenas um metamodelo nas DSLs anteriores dificultava a modelagem das aplicações e não possibilitava o suporte ao tratamento do tradeoff entre o custo de prototipagem e a capacidade de otimização de desempenho (refinamento). Outro fator que merece destaque é o tratamento da rede considerando diferentes níveis de granulosidade, assim como ocorre em [SHIMIZU, 2011], uma vez que RSASF podem ser analisadas tanto considerando o nível da rede como um todo, ou os grupos de nós específicos que compõem a rede e, até mesmo, considerando individualmente cada um dos nós que integram a rede e que podem ter características distintas seja em relação a plataforma utilizada, quanto com relação ao processamento dos dados.
LWiSSy permite ainda que os especialistas de domínio e de redes modelem seus respectivos modelos de maneira independente, restringindo assim o trabalho em grupo destes especialistas ao nível de análise dos requisitos, característica esta que diminui a dependência entre os diferentes perfis de desenvolvedor envolvidos no desenvolvimento de sistemas para RSASF. Tal
61
dependência poderia causar atrasos durante o ciclo de desenvolvimento dos sistemas. Além disso, LWiSSy incorpora ainda um modelo comportamental, no qual é possível definir todo o fluxo de cada uma das aplicações inseridas nos nós sensores. Outra característica importante consiste na inserção de protocolos para RSASF, os quais não existiam nas DSLs anteriores e, por sua vez, as soluções geradas (código fonte) sempre exigiam uma atividade de refinamento de código muito extensa, uma vez que todo sistema de RSASF considera diversos protocolos durante o seu desenvolvimento.
Uma característica importante e que não é tratada em nenhum dos trabalhos relacionados consiste na capacidade de modelagem de diversas aplicações em um mesmo sistema. Esta capacidade, a qual só está presente em LWiSSy, torna-a adequada para os cenários emergentes de redes de sensores e atuadores compartilhadas. Além disso, nenhum dos trabalhos relacionados efetuou algum tipo de avaliação qualitativa dos metamodelos gerados, sendo esta uma característica importante para garantir que o metamodelo proposto pode, de fato, ser utilizado durante o processo de desenvolvimento de sistemas para RSASF.
Para concluir este Capítulo, a Tabela 3-1 apresenta uma comparação sumarizada entre as características presentes em todos os trabalhos que foram discutidos e LWiSSy.
LWiSSy Baobab Moppet Losilla Shimizu
Separação de interesses √ - - -
Suporte a modelagem estrutural e comportamental
√ √ √ √ √
Definição de vários modelos
gráficos √ - - - √ Divisão de características estruturais e comportamentais em modelos diferentes √ - - - - Suporte a parâmetros de refinamento √ - - - √ Suporte a modelagem de √ - - - -
62
Redes de Sensores Compartilhadas Validação de modelos com
OCL - √ √ √ -
Modelos executáveis - - - - √
Geração automática de
código-fonte √ √ √ √ √
Previsão do tempo de vida e
performance do sistema - - √ - -
63