Outline of the Thesis

(a) Montagem de componente.

(b) Montagem de aplica¸c˜ao.

Figura 3.7: Montagem na ´area de trabalho.

3.5

Considera¸c˜oes Finais

Neste cap´ıtulo vimos quais os requisitos necess´arios para o desenvolvimento do Bean- Watcher. Em seguida, mostramos como o PECOS foi utilizado para modelar os elemen- tos sensoriados num ambiente sem fio e detalhamos a arquitetura da nossa ferramenta. Por fim, descrevemos como ´e a utiliza¸c˜ao do BeanWatcher no desenvolvimento de uma aplica¸c˜ao.

Cap´ıtulo 4

Desenvolvimento de Aplica¸c˜oes

Utilizando o BeanWatcher

Neste cap´ıtulo falaremos sobre os requisitos e desenvolvimento de aplica¸c˜oes de mon- itora¸c˜ao e atua¸c˜ao atrav´es do BeanWatcher. Em seguida, discutiremos como uma aplica¸c˜ao ´e desenvolvida. Mostraremos como ´e a estrutura das aplica¸c˜oes geradas atrav´es do BeanWatcher. Por fim, descreveremos a utiliza¸c˜ao do BeanWatcher em um processo de desenvolvimento de software. Como utilizamos redes de sensores como estudo de caso, o presente cap´ıtulo ser´a direcionado para estas redes.

4.1

Requisitos das Aplica¸c˜oes de Monitora¸c˜ao e

Atua¸c˜ao em Redes de Sensores

Tradicionalmente, desenvolvimento de sistemas s˜ao organizados em arquitetura com diferentes camadas l´ogicas, onde o sistema ´e dividido em n´ıveis de abstra¸c˜ao que partem desde a camada f´ısica at´e a camada de aplica¸c˜ao, este modelo ´e usado de forma bottom-up. Por outro lado, redes de sensores s˜ao direcionadas `as aplica¸c˜oes, sendo mais adequada uma abordagem top-down, como sugerido por [31], pois uma vez que os requisitos de neg´ocios s˜ao conhecidos os de n´ıveis mais baixos se tornam mais claros.

Por´em, para desenvolver aplica¸c˜oes para redes de sensores os projetistas devem pensar nas seguintes quest˜oes:

• Finalidade da rede: Que tipo de dado est´a sendo sensoriado e qual o objetivo da rede? As aplica¸c˜oes dever˜ao ser capazes de mostrar qualquer dado sensoriado, por exemplo, se a rede coletar temperatura, a aplica¸c˜ao dever´a mostrar qual a temperatura no momento.

• Visualiza¸c˜ao dos dados: Qual a melhor forma de disponibilizar os dados ao usu´ario? Se a rede coletar informa¸c˜oes de temperatura, a aplica¸c˜ao poderia mostrar um termˆometro indicando a temperatura sensoriada.

• Informa¸c˜oes gerenciais: Quando e quais informa¸c˜oes gerenciais devem ser obtidas da rede? Por exemplo, a aplica¸c˜ao pode necessitar de informa¸c˜oes sobre o mapa de energia ou localiza¸c˜ao dos n´os.

4.2 Desenvolvendo Aplica¸c˜oes em Redes de

Sensores 28

• Mecanismos de processamento distribu´ıdo: Quais mecanismos est˜ao sendo utilizados pela rede para pr´e-processar o resultado do sensoriamento? Por ex- emplo, poder´ıamos ter mecanismos de compress˜ao, fus˜ao ou agrega¸c˜ao de dados, logo as aplica¸c˜oes devem suportar tais mecanismos.

• Atua¸c˜ao: Quais os parˆametros que devem ser passados para a rede no momento da atua¸c˜ao? Devemos nos preocupar em como devem ser passados os dados para a rede. Este fator est´a fortemente ligado ao prop´osito da rede.

As quest˜oes acima levantadas dizem respeito aos aspectos gerais das redes de sen- sores. Por´em existem outros pontos que dependem exclusivamente do objetivo da rede, por este motivo apenas no momento de desenvolver as aplica¸c˜oes ´e que podemos cobrir estes aspectos, como:

• Formato das mensagens da aplica¸c˜ao: Como os dados ser˜ao enviados dos sensores? Qual o formato das mensagens enviadas? Como prever o sensoriamento de diferentes tipos de dados? Qual o formato das mensagens que os sensores recebem, no caso de termos atua¸c˜ao por parte dos sorvedouros?

• Formato dos dados sensoriados: Como os dados devem ser sensoriados e enviados? Por exemplo, se tivermos uma rede que coleta dados sobre a temper- atura, podemos estar interessado em um intervalo ou em um simples valor da temperatura.

• Mecanismo para melhoria do funcionamento da rede: Como e quando s˜ao aplicados os mecanismo de melhoria do funcionamento da rede?

Claramente, as aplica¸c˜oes tendem a apresentar diferentes caracter´ısticas e restri¸c˜oes. Desta forma, n˜ao ´e f´acil oferecer uma ´unica API para suportar as necessidades de todas aplica¸c˜oes. Uma boa abordagem seria considerar cada elemento desta aplica¸c˜ao como um componente que pode ser utilizado por diferentes aplica¸c˜oes, como feito pelo BeanWatcher.

4.2

Desenvolvendo Aplica¸c˜oes em Redes de

Sensores

Nesta se¸c˜ao, mostraremos como uma aplica¸c˜ao em redes de sensores ´e desenvolvida sem a utiliza¸c˜ao de ferramentas para auxiliar e descreveremos como ´e o desenvolvimento da mesma aplica¸c˜ao atrav´es do BeanWatcher, apontando algumas vantagens da utiliza¸c˜ao desta ferramenta.

Baseado nos requisitos apresentados na se¸c˜ao anterior, podemos pensar em alguns cen´arios que mostram como estes requisitos s˜ao mapeados para o desenvolvimento de aplica¸c˜oes de monitora¸c˜ao.

Cen´ario 1 : Uma rede de sensores com a finalidade de visualizar a temperatura am- biente em uma planta¸c˜ao de uva.

• Sem o BeanWatcher: O desenvolvedor implementaria a visualiza¸c˜ao da temperatura e a comunica¸c˜ao.

4.2 Desenvolvendo Aplica¸c˜oes em Redes de

Sensores 29

• Com o BeanWatcher: Utilizar´ıamos o componente que representa uma rede de sensores para temperatura e o componente de comunica¸c˜ao, ambos dispon´ıveis na ferramenta, e montar´ıamos a aplica¸c˜ao com estes compo- nentes.

Cen´ario 2 : Agora a mesma aplica¸c˜ao, sendo que os dados precisam ser fundidos a cada 3 dados recebidos.

• Sem o BeanWatcher: O desenvolvedor reaproveitaria a aplica¸c˜ao do cen´ario 1. Por´em, implementaria o suporte `a fus˜ao de dados a cada 3 dados recebidos, caso seja necess´ario modificar para 5 dados recebidos ter´a que reimplementar.

• Com o BeanWatcher: Utilizar´ıamos o componente que representa uma rede de sensores para temperatura e o componente para fus˜ao de dados, em seguida configurar´ıamos a fus˜ao a cada 3 dados recebidos, ou se necess´ario a cada 5.

Cen´ario 3 : Agora, al´em da temperatura ambiente, a rede passa a monitorar a umi- dade relativa do ar, soa um alarme quando a temperatura est´a acima de um determinado valor e mecanismos de compress˜ao s˜ao aplicados.

• Sem o BeanWatcher: O desenvolvedor implementaria o comportamento da temperatura, da press˜ao, do alarme e o mecanismo de compress˜ao.

• Com o BeanWatcher: Utilizar´ıamos os componentes: temperatura, press˜ao, alarme e compress˜ao. Em seguida, configurar´ıamos as propriedades do alarme obedecendo as regras solicitadas pelo desenvolvedor e o mecanismo de compress˜ao para suportar um determinado algoritmo.

Cen´ario 4 : Por fim, ao disparar o alarme, o agricultor solicita a irriga¸c˜ao da planta¸c˜ao para diminuir a temperatura.

• Sem o BeanWatcher: O desenvolvedor teria que integrar a aplica¸c˜ao feita no cen´ario 4 `a solicita¸c˜ao de atua¸c˜ao nos sensores e para isso implementaria o mecanismo de atua¸c˜ao atrav´es de um bot˜ao.

• Com o BeanWatcher: Incluir´ıamos o componente para atua¸c˜ao que seria representado por um bot˜ao.

Al´em disso, para cada um dos cen´arios as aplica¸c˜oes poderiam ser executadas em um

desktop e um dispositivo port´atil. Neste caso, o desenvolvedor teria que reimplementar

as aplica¸c˜oes para as duas plataformas, mas atrav´es do BeanWatcher, como a ferra- menta suporta diferentes linguagens, bastaria gerar as aplica¸c˜oes para uma linguagem alvo diferente.

Note que, ao utilizar o BeanWatcher, o desenvolvedor n˜ao precisa conhecer como os componentes s˜ao implementados e nenhum c´odigo precisa ser implementado. Contudo, ´e permitido ao desenvolvedor alterar os componentes existentes com o objetivo de otimiz´a-los.