UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO TÓPICOS AVANÇADOS EM SISTEMAS INTEGRADOS E DISTRIBUÍDOS II

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE PÓS-GRADUAÇÃO EM SISTEMAS E COMPUTAÇÃO TÓPICOS AVANÇADOS EM SISTEMAS INTEGRADOS E DISTRIBUÍDOS II RELATÓRIO TÉCNICO ADORILSON BEZERRA DE ARAÚJO ANDRÉ GUSTAVO DUARTE DE ALMEIDA

2 Relatório técnico referente a implementação de projeto de sistema ciente do contexto com o Context Toolkit, sob a orientação da professora Dra. Taís Batista.

3 1. Introdução Computação ubíqua são sistemas computacionais que permitem que o acesso ás informações e a realização de tarefas estejam disponíveis em qualquer lugar. Além disso, devem ser invisíveis para o usuário, possibilitando um uso intuitivo [Poslad, 2009]. Entre as diversas propriedades destacada pela literatura, uma delas é a ciência do contexto. Existem várias definições de contexto, e muitas caracterizações. Uma delas é dada por [Dey and Abowd, 2000], que define contexto como qualquer informação que pode ser usada para caracterizar a situação de uma entidade (pessoa, local, objeto) que é considerado relevante para a interação entre o usuário e a aplicação. Em outras palavras, um contexto representa um estado ou uma situação que afeta o comportamento do sistema. Considerando a definição acima, percebemos a necessidade de meios para capturar essas informações da entidade e transmitir para o sistema. Além disso, em decorrência da desejada invisibilidade, essa captura não pode depender de interação com usuários. Dada essas características, o desenvolvimento de sistemas ubíquos não é tarefa simples. [Salber et al., 1999] introduziu o conceito de widgets de contexto, que mediam a interação entre o ambiente e a aplicação da mesma maneira que um widget gráfico media a interação entre usuário e aplicação. A partir desse conceito, foi apresentado uma biblioteca de widget desenvolvida para capturar a presença, identificação e atividades de pessoas e coisas: o Context Toolkit. O Context Toolkit objetiva facilitar o desenvolvimento de aplicações com ciência do contexto usando a linguagem de programação Java [Context Toolkit, 2012]. Algumas de suas características são: Widgets para abstração de contexto, sensores e atuadores Descoberta de recursos de componentes distribuídos Modelagem de inteligência baseada em regras através de Enactors Modelagem de aprendizado de máquina com WEKA e JAHMM (para modelo Hidden Markov) Explanação de comportamentos da aplicação através do Intelligibility Toolkit Facilidades de controle através do framework Enactor O presente relatório trata da implementação de uma aplicação ciente do contexto com o Context Toolkit. 2. Modelagem A aplicação é um aplicação de monitoramento ambiental. Ela fará a monitoração da temperatura, da presença de fogo e do nível de poluição do ar. Se há presença de fogo é dado um alarme e o bombeiro é acionado e o local é informado a ele. Se há poluição do ar, a Secretaria de Meio Ambiente é informada,com o respectivo local, para tomar atitudes em relação ao transito ou fabricas que tenham na redondeza do local afetado. Para detectar poluição determinarmos uma faixa de valores, medidos em relação ao monóxido de carbono(dados fictícios). As faixas de valores são mostrados na Tabela 01. Condição <=20ppm Nível de Poluição Lower

4 >20 and <=40 Medium >40 Higher Tabela 01 - Níveis de Poluição Na detectação de incêndio, fizemos a suposição que nosso sensor tinha os mecanismos necessários para identificar se estava ou não ocorrendo incêndio, que na nossa interface gráfica está representado por um checkbox. Para identificação do local, fizemos a suposição de que os sensores(temperatura, incêndio e poluição) tinha localizadores gps embutidos nos mesmos, para fornecer o local de onde foi realizada a respectiva medição. Para tal, foram modelados dois grupos de componentes. Um grupo responsável pelo monitoramento da temperatura e incêndio e outro grupo pelo nível de poluição.conforme figuras abaixo: Figura 01 - Componentes de monitoramento da temperatura e incêndio Figura 02 - Componentes de monitoramento do nível de poluição Observamos na figura a presença de todos os componentes do sistema ubíquo, com os widgets para captação das informações de contexto, as condições para notificação do sistemas, os widgets atuadores e os serviços responsáveis por realizarem as atuações. Para o nosso estudo de caso, conforme descrito com mais detalhes na seção 03, simulamos os sensores tanto de captação como de atuação como janelas de interface gráfica com campos para coleta e exibição dos resultados. As notificações aos órgãos competentes foram simuladas através do uso de cores em uma tela que centraliza as informações. Para ilustrar a arquitetura da solução, a figura 03 apresenta o diagrama de classes da solução implementada. Para efeitos de simplificaçã, algumas classes auxiliares foram retiradas do diagrama.

5 Figura 03 - Diagrama de Classes da Solução Implementada As classses com pós-fixo widget representam os widgets da minha aplicação, que são criados dinamicamente, apartir do descritores XML como veremos na seção, do mesmo jeito que os Enactors. Associado aos sensores de atuação, temos as classes TemperatureService e PollutionService que são responsáveis por receber a notificação dos enactors e acionarem os atuadores, com base nos dados dos widgets de saída. A classe EventHandler é responsável realizar a intermediação entre a resposta dos widgets de saíde para a classse FormControlCenter, que no nosso exemplo simula os atuadores. Por fim as classses FormSensorTemperature e FormSensorPollution simulam os sensores dos seus respectivos ambientes. 3. Implementação Com base no modelo especificado na seção 2 e na API e documentação técnica do ContextToolkit devemos implementar os seguintes elementos: Widgets Enactors Serviços associados aos widgets atuadores

6 Na nossa implementação os sensores tanto de detecção(incêndio, temperatura e poluição) como os de alarme(incêndio e poluição) foram representados por interfaces gráficas que simulam a aquisição desses dados. Cabe aqui o parêntesis em relação ao Context Toolkit, que tem como seu objetivo permitir a comunicação dos widgets com as aplicações interessadas nos dados de contexto e não na lógica necessária para realizar a comunicação de baixo nível que normalmente é necessária para capturar as informações disponibilizadas para os widgets. 3.1 Implementação Widgets Sensores Na versão atual do ContextToolkit o desenvolvedor é apresentado a duas opções para implementação dos Widgets, uma é utilizando o processo de herança da classe Widget e a outra é utilizando XML. No ContextToolkit os widgets nada mais são do que POJOS Java que recebem os dados dos sensores. Conforme visto na seção 2, a figura 4 apresenta a representação XML do widget PollutionWidget. Figura 04 Descrição XML do Widget PollutionWidget A declaração dos demais Widgets seguem a mesma regra. Uma vez declarado através do XML é necessário transforma a descrição XML é um objeto Java que atue efetivamente como o Widget. Através da classe WidgetXMLParser podemos criar um objeto widget com base na descrição XML do mesmo e automaticamente iniciá-lo para que o mesmo possa ser detectado pelo Discoverer e passar a fornecer informações que sejam de interesse da nossa aplicação. Como dito anteriormente, a entrada vinda dos sensores foi simulada através do uso de telas, com campos de entrada de dados referente aos dados constantes nos widgets. Na figura 5 apresentamos a tela implementado pela classe FormSensorPollution, que tem como entrada a localização do sensor e o valor medido da poluição.

7 Figura 05 Tela de Aquisição dos dados do PollutionWidget O outro widget implementado segue a mesma lógica do que foi apresentado nesta seção. Os sensores atuadores são melhor descritos na seção seguinte. 3.2 Implementação Enactores e Sensores Atuadores Dentro da arquitetura do Context Toolkit, como visto anteriormente, os Enactors são responsáveis por analisarem os widgets responsáveis pela captura/atuação dos sensores, implementando assim a lógica da aplicação ciente de contexto. Através dos enactors podemos determinar quando temos interesse em um específico evento/valor. Da mesma maneira que os widgets, a versão atual do Context Toolkit permite que o desenvolvedor escreva em XML o comportamento de uma enactor. Para que um Enactor possa funcionar ele recebe como entrada um Widget e altera o valor de um Widget de saída, que seria nossa atuador(notificador da secretaria de meio ambiente e os bombeiros). Uma das limitações da versão XML de um Enactor é que podemos modificar apenas um dos campos do widget que estará funcionando como atuador e como precisamos de mais de um informação na saída(ex: Local e se tem ou não incêndio), na nossa implementação construímos a saída para conter todas as informações necessárias para nossa aplicação atuar da maneira adequada, necessitando assim que o widget atuador tenha apenas um campo, chamado status, que receberá uma string contendo as informações necessárias. Para efeitos de simulação, apesar de terem a mesma estrutura, decidimos criar dois widgets atuadores, chamados alarmfire-widget e alarmpollution-widget. Considerando os eventos de interesse de nossa aplicação, descritos na seção 2, apresentamos na figura 06 a descrição XML associada ao Enactor que tratará dos eventos relacionados a detecção se há incêndio ou não em um determinado local monitorado.

8 Figura 06 Enactor para tratar eventos de detecção de incêndio Iniciamos a declaração do Enactor informando o nome do mesmo e quais são os widgets de entrada e saída, respectivamente temperature-widget e alarmfire-widget. Em seguida definimos o nome do atributo de saída que deve ter o mesmo nome do campo no widget atuador(saída). Para determinar quais eventos são de interesse da aplicação, precisamos escrever consultas a serem realizadas com base no widget de entrada, para avaliar o que efetivamente é de interesse da aplicação. No nosso caso estamos interessados em saber se ocorre ou não incêndio em um determinado local. Em caso positivo a mensagem de status contém a String On Fire para que o serviço de atuação(services) saibam que é necessário notificar o corpo de bombeiros, além de informar a temperatura medida e o local da medição. Na descrição do Enactor é necessário informar qual o serviço responsável pelo tratamento da requisição e desse serviço qual a função que deverá ser executada. No código acima o serviço responsável chama-se TemperatureService e a função firecontrol. Na seção seguinte detalharemos a implementação do TemperatureService. 3.3 Implementação Services Observamos na seção anterior que os Enactors são responsáveis por implementar a lógica da aplicação no que diz respeito ao processamento das informações de contexto. Uma vez processado a efetiva atuação é delegada a um serviço(service), implementada por uma classe Java que deverá necessariamente estender a classe Service do ContextToolkit. A classe precisa ter apenas dois

9 métodos, sendo um deles o construtor que cria o serviço e faz a ligação do mesmo com o respectivo widget(atuador) e o outro método o que irá efetivamente executar a ação necessária(atuação). O método execute é invocado de maneira assíncrona, ou seja, apenas quando existe alguma modificação de interesse da aplicação. Ao receber essa notificação, repassamos o tratamento da mesma para a classe EventHandler, que é responsável por manipular o modelos de dados usado para gerenciar nossa interface gráfica. Como na nossa aplicação simulada não trabalhamos com atuadores físicos, optamos por criar uma interface gráfica que congregue as informações coletadas e interpretadas do contexto, utilizando uma notação gráfica para identificar as situações mais importantes, como se existe ou não incêndio e o nível de temperatura. A figura 07 mostra a aplicação em execução que mostra as duas telas que representam os sensores de captação de informações e a tela principal que apresenta um quadro com as diversas situações medidas, demonstrando de maneira gráfica o resultado da execução. Figura 07 Aplicação em Execução 4. Conclusão

10 Este relatório técnico procurou teve como objetivo demonstrar o desenvolvimento de uma aplicação ciente de contexto, mais especificamente uma que monitorasse aspectos ambientais em diversos locais. Foi necessário conhecimento da ciência de contexto e um estudo detalhado da arquitetura do framework ContextToolkit, que atua como middleware entre as aplicações e os sensores(seja de detecção ou de atuação). Sobre o processo desenvolvimento, apesar de não fazer parte do escopo desse trabalho, utilizamos um repositório de código público, com controle de versão, permitindo que a equipe mesmo estando em locais distintos pudesse colaborar no desenvolvimento do mesmo. Utilizamos o Eclipse como Ide de desenvolvimento e as diversas bibliotecas necessárias para o funcionamento do Context Toolkit. Para ter acesso ao código, bibliotecas utilizadas e a aplicação, os interessados devem acessar Acreditamos foi bastante proveitoso o desenvolvimento desse pequeno exemplo para podermos conhecer melhor um aplicação ubíqua e ter contato com o referido framework. Porém acreditamos que seria necessário o trabalho com sensores de verdade, espalhados em redes diferentes para verificar o nível em termos de produção do mesmo, fato este não realizado neste trabalhado dado a necessidade de sensores especializados e o pouco tempo disponível. 6. Referências [Poslad, 2009] Poslad, Stefan Ubiquitous Computing Smart Devicess, Environments and Interactions. John Wiley & Sons [Dey and Abowd, 2000] COLOCAR REFERENCIA... [Salber et al., 1999] Daniel Salber, Anind K. Dey and Gregory D. Abowd. The Context Toolkit: Aiding the Development of Context-Enabled Applications. [Context Toolkit, 2012] Acesso em 9 de abril de 2012.