Siafu-CReMe: Simulando o Tratamento de Conflitos em Aplicações Cientes de Contexto Coletivas

Transcrição

1 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 923 Siafu-CReMe: Simulando o Tratamento de Conflitos em Aplicações Cientes de Contexto Coletivas Thais R. M. Braga Silva 1, Fabrício A. Silva 1, Linnyer B. Ruiz 2, Antonio A. F. Loureiro 3 1 Campus Florestal Universidade Federal de Viçosa (UFV) Florestal MG Brasil 2 Departamento de Informática Universidade Estadual de Maringá (UEM) Maringá PR Brasil 3 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Belo Horizonte MG Brasil {thaisrb,loureiro}@dcc.ufmg.br, {fabricio.asilva}@ufv.br,{linnyer}@gmail.com Abstract. Context-aware computing is an active research area that deals with systems capable of adapting services according to the current needs of their users. A related research aspect that lately has received increasing attention from the scientific community is the resolution of conflicts of interests that may occur when context-aware systems are shared by a group of users. This paper presents a tool, called Siafu-CReMe, to the simulation of conflicts treatment solutions for collective context-aware applications. Siafu-CReMe is based on an adaptable and extensible architecture that allows users to determine how to detect conflicts for their collective applications, as well as the resolution algorithms to be used. Resumo. A computação ciente de contexto é uma área ativa de pesquisa que trata de sistemas capazes de adaptar serviços de acordo com as necessidades correntes de seus usuários. Um aspecto de pesquisa relacionado que tem recebido crescente atenção da comunidade científica é o tratamento de conflitos de interesses que podem ocorrer em sistemas cientes de contexto compartilhados por um grupo de usuários. Esse trabalho apresenta uma ferramenta, chamada Siafu-CReMe, para a simulação de soluções para o tratamento de conflitos em aplicações cientes de contexto coletivas. A Siafu-CReMe está baseada em uma arquitetura adaptável e extensível, a qual permite que cada usuário determine como detectar conflitos para sua aplicação coletiva, bem como os algoritmos de resolução a serem utilizados. 1. Introdução Aplicações computacionais cientes de contexto podem ser definidas como aquelas que utilizam informações sobre entidades de interesse (objetos, pessoas ou ambientes) para adaptarem seus serviços com o objetivo de aumentar a satisfação dos usuários [Abowd et al. 1999]. A informação considerada por esse tipo de aplicação é chamada de contexto e pode representar dados do ambiente físico (e.g., temperatura e luminosidade), bem como características pessoais (e.g., sentimentos e localização). Em muitos casos, as aplicações cientes de contexto são coletivas, ou seja, utilizadas simultaneamente por um grupo de usuários. Apesar dos usuários nesses cenários possuírem

2 924 Anais objetivos comuns, eles podem divergir sobre as adaptações desejadas para os serviços oferecidos pela aplicação, devido às diferenças em seus perfis individuais e/ou à escassez de recursos no ambiente. Dessa forma, conflitos de interesse podem ser detectados e devem ser resolvidos considerando os interesses coletivos e individuais [Silva et al. 2010]. Uma aplicação ciente de contexto coletiva é composta por um conjunto de tarefas (individuais e coletivas) e um conjunto de usuários. As tarefas são os serviços providos pela aplicação, sendo coletivas aquelas executadas simultaneamente por dois ou mais usuários. Um conflito coletivo pode ser definido como um estado inconsistente alcançado por uma aplicação coletiva após avaliar contextos ambientais e pessoais. A aplicação se torna incapaz de realizar adaptações de maneira a satisfazer interesses individuais e coletivos ao mesmo tempo. A resolução de conflitos coletivos é a adoção de um algoritmo ou técnica para resolver impasses identificados durante a execução de uma aplicação coletiva. O trabalho desenvolvido por [Silva et al. 2010] aborda o tratamento de conflitos em aplicações cientes de contexto coletivas, apresentando uma metodologia, chamada CReMe (Conflict Resolution Methodology), que tem como objetivo organizar as atividades de detecção e resolução de conflitos. O objetivo deste trabalho é propor uma ferramenta que permita a simulação de diferentes soluções para a identificação e o tratamento de conflitos em aplicações cientes de contexto coletiva. Essa ferramenta está baseada nas definições propostas pela metodologia CReMe, a qual já aborda as características principais do problema da resolução de conflitos coletivos. Adaptabilidade e extensibilidade são duas importantes características da ferramenta proposta, visto que a mesma deve atender ao maior número de pesquisadores possível, os quais desejam adotar diferentes técnicas para detectar e resolver conflitos, e simular diferentes aplicações coletivas. Atualmente, a maioria das ferramentas de simulação para aplicações cientes de contexto disponíveis na literatura não são multiusuários e não permitem a configuração de diferentes características para as aplicações. Além disso, aquelas que possuem esses atributos não apresentam uma solução para tratamento de conflitos. A ferramenta proposta, chamada Siafu-CReMe, é uma extensão de um ambiente para simulação, chamado Siafu [Martin and Nurmi 2006], o qual já possui disponíveis e validadas as funcionalidades ligadas a geração de aplicações cientes de contexto coletivas. 2. CReMe: Conflict Resolution Methodology A metodologia CReMe (Conflict Resolution Methodology) define modelos para a elaboração de soluções para diferentes aplicações coletivas e cientes de contexto. Os modelos que compõem a metodologia CReMe foram descritos em detalhes em [Silva et al. 2010]. Três modelos principais foram definidos, sendo eles o modelo de aplicação, o modelo de arquitetura e o arcabouço estrutural, chamado Conflict Engine, responsável por organizar os módulos que compõem a metodologia, bem como o fluxo de chamada e as interfaces entre os mesmos. O modelo de aplicação define que os sistemas atendidos pela CReMe funcionam em rodadas. Uma rodada é caracterizada por um instante de tempo da aplicação no qual os participantes da mesma indicam quais tarefas, dentre aquelas disponibilizadas pelo sistema, desejam executar. O modelo de arquitetura escolhido pela metodologia é cliente-servidor, com rodízio de servidores. O servidor é o elemento responsável por executar os módulos da Conflict Engine a cada rodada.

3 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 925 Basicamente, a Conflict Engine é composta por dois módulos principais: Módulo Detecção de Conflitos e Módulo Conciliação. O Módulo Detecção de Conflitos é responsável por identificar impasses de adaptação sobre as tarefas da aplicação indicadas pelos participantes e notificá-los ao Módulo Conciliação. Ele executa uma análise tridimensional considerando os perfis dos usuários, os contextos dos ambientes compartilhados e as tarefas da aplicação. Cada aplicação coletiva deverá utilizar uma implementação particular para esse módulo, de acordo com os tipos de conflitos coletivos enfrentados. O objetivo do Módulo Conciliação é adaptar as tarefas da aplicação de acordo com os interesses individuais e coletivos, considerando ainda os recursos disponíveis no ambiente, sempre que conflitos coletivos forem detectados. Para resolver conflitos, o módulo executa um algoritmo ou técnica de resolução, escolhida de acordo com as características da aplicação ciente de contexto coletiva considerada. De acordo com a metodologia CReMe, este módulo deverá utilizar um repositório de algoritmos para conciliação de conflitos. Sempre que conflitos tiverem que ser resolvidos, o módulo deverá selecionar um desses algoritmos para solucioná-lo. Os módulos propostos para a metodologia CReMe necessitam de informações que devem ser providas pelo projetista de cada aplicação. A CReMe recebe essas informações por meio de um arquivo XML (extensible Markup Language), chamado Nível de Atuação. 3. O Ambiente Siafu As soluções para tratamento de conflitos coletivos desenvolvidas com a metodologia CReMe podem ser implementada tanto em ambientes reais como também em ferramentas de simulação. Para o desenvolvimento dos módulos da Conflict Engine, conforme propostos pela metodologia CReMe, em um ambiente de simulação, é preciso também que se tenha as funcionalidades de simulação de uma aplicação ciente de contexto coletiva. Uma vez que já existem ferramentas com esse propósito disponíveis na literatura, uma delas pode ser escolhida para ser estendida e utilizada para simulação do tratamento de conflitos coletivos. Essa ferramenta deve atender, basicamente, aos seguintes requisitos: permitir simulações de aplicações cientes de contexto, conforme o modelo de aplicação proposto pela metodologia CReMe; permitir simulações de aplicações coletivas; permitir o uso de diferentes tipos de contextos; possuir código aberto e livre. Dentre as ferramentas encontradas na literatura e avaliadas, o Siafu [Martin and Nurmi 2006] foi selecionado por apresentar melhor aderência aos requisitos necessários. O Siafu é um simulador de aplicações cientes de contexto desenvolvido na linguagem de programação Java. É uma ferramenta de código aberto com licença GPL (GNU Public License). Com o Siafu já é possível simular aplicações cientes de contexto, inclusive considerando múltiplos usuários. O Siafu oferece grande liberdade aos usuários na determinação de diversas características da aplicação, tais como ambiente físico, número e perfil dos usuários, tipos de contextos pessoais e ambientais, padrão de movimentação, dentre outros aspectos. Os autores da ferramenta disponibilizaram uma página Web por meio da qual é possível obter o simulador e seu código, bem como as instruções completas para sua utilização e modificação [Siafu 2010].

4 926 Anais Além do Siafu, outras ferramentas de simulação foram encontradas na literatura. Porém, nenhuma delas atendeu tão bem aos requisitos quanto o Siafu. O Network Simulator [NS2 2001] e o GloMoSim [Zeng et al. 1998] são simuladores de rede com bastante reconhecimento na comunidade científica. No entanto, eles não oferecem suporte a aplicações cientes do contexto. O DiaSim [Jouve et al. 2009] possui maior foco em simulação de aplicações pervasivas, sem oferecer suporte ao uso de contextos. CASS [Park et al. 2007], ISS [Van Nguyen et al. 2009] e CAST [Kim et al. 2006] são simuladores propostos apenas para aplicações de Smart Home, e não possuem o código aberto. TATUS [O Neill et al. 2005] é um simulador com foco em testes de software para aplicações cientes de contexto que não permite comunicação em rede entre os elementos. Apesar de possibilitar a simulação de aplicações coletivas, o Siafu não contém qualquer implementação para o tratamento de conflitos coletivos. Portanto, a proposta deste trabalho é estender o Siafu, incluindo a funcionalidade de tratamento de conflito proposta pela metodologia CReMe (seção 2). Essa extensão recebe o nome de Siafu-CReMe. Os usuários dessa ferramenta serão os projetistas de aplicações cientes de contexto coletivas, interessados em avaliar uma ou mais soluções para tratamento dos conflitos coletivos. 4. A Ferramenta Siafu-CReMe Os principais requisitos para a implementação da Siafu-CReMe são adaptabilidade e extensibilidade. Esses requisitos foram considerados devido a duas importantes necessidades dos potenciais usuários da ferramenta. Em primeiro lugar, diferentes usuários provavelmente simularão diferentes aplicações. Assim, a ferramenta deve ser adaptável para simular diferentes aplicações cientes de contexto com características variadas, necessitando de um mínimo de esforço do usuário. Em segundo lugar, cada usuário pode desejar incorporar algum novo comportamento à sua solução para tratamento de conflitos, dependendo das necessidades de sua aplicação. A própria metodologia CReMe oferece a possibilidade de adequação da solução para cada aplicação em particular. Portanto, a ferramenta Siafu-CReMe permite que seus usuários desenvolvam outras metodologias para conciliação de conflitos utilizando os modelos propostos pela CReMe. O Siafu já possibilita que diferentes aplicações coletivas sejam configuradas e simuladas. Dessa forma, foi necessário criar uma arquitetura de extensão desse ambiente, a qual considera apenas os aspectos de tratamento de conflitos coletivos. A arquitetura da ferramenta Siafu-CReMe foi preparada de maneira a permitir a detecção de diferentes tipos de conflitos coletivos (i.e., conflitos ocorridos por diversos motivos) e a utilização de várias opções de algoritmos para o tratamento dos mesmos. As classes desenvolvidas para a ferramenta utilizam conceitos da programação orientada a objetos e também padrões de projetos consolidados na literatura para facilitar o desenvolvimento de novas funcionalidades, sempre que necessário. Além disso, foi implementado um esquema XML para determinar o formato dos arquivos de Nível de Atuação. Cada aplicação deve possuir um arquivo XML formatado de acordo com o esquema proposto, contendo um elemento conflictdetectionclass, um elemento conflict- ResolutionClass e um ou mais elementos algorithm. Esses elementos são utilizados pelas classes implementadas para a ferramenta, conforme será explicado a seguir. A figura 1 apresenta o diagrama de classes criado para a implementação da Siafu-CReMe. As principais classes desenvolvidas para os módulos de detecção e conciliação são apresentadas

5 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 927 juntamente com a explicação sobre como utilizá-las para construir e configurar a solução de tratamento de conflitos coletivos para um determinada aplicação. Figura 1. Diagrama de Classes - Siafu-CReMe A classe ServerPlace representa o papel de servidor. Ela repassa as informações recebidas ao arcabouço estrutural Conflict Engine. A cada rodada o papel de servidor (i.e., o objeto ServerPlace) estará vinculado a um dos dispositivos da aplicação simulada. Módulo Detecção de Conflitos: o módulo para detecção de conflitos é composto principalmente pela classe abstrata ConflictDetection. Essa classe possui os atributos e métodos comuns a todos os modelos de detecção de conflitos e o método abstrato detectcollective- Conflict, que deve ser implementado pelas suas subclasses para detectar conflitos de uma maneira específica. Para indicar qual o modelo de detecção a ser utilizado para a sua aplicação específica, o usuário deve configurar a aplicação utilizando o arquivo de Nível de Atuação. Essa configuração é feita utilizando o elemento conflictdetectionclass que contém o atributo name com o valor da classe que deve ser instanciada para identificar conflitos. O padrão de projeto Factory [Gamma et al. 1995], que utiliza os métodos de reflexão em Java, foi implementado para instanciar a classe utilizando apenas o nome da mesma. Esse padrão é implementado pela classe ConflictDetectionFactory. Dois modelos de detecção de conflitos já estão disponíveis na ferramenta: por tarefas e por demanda. O primeiro identifica conflitos quando usuários desejam realizar tarefas diferentes ao mesmo tempo, quando apenas uma pode ser escolhida. O segundo tipo identifica conflitos quando mais de um usuário deseja realizar uma tarefa, mas a mesma não tem capacidade para atender a todos simultaneamente. Caso o usuário queira utilizar um outro modelo de detecção de conflito, basta criar uma classe própria estendendo a classe abstrata ConflictDetection e configurar o nome da classe no arquivo XML. Dessa forma, o módulo descrito é facilmente adaptável apenas pelo valor de um parâmetro do arquivo XML, e extensível pois basta criar uma classe que estende a classe abstrata já existente, sem a necessidade de alterações do código do arcabouço. Módulo Conciliação: seguindo a proposta da metodologia CReMe, a Siafu-CReMe permite a adoção de vários algoritmos para a resolução de conflitos. Esses algoritmos

6 928 Anais são mantidos em um repositório, juntamente com meta-dados relacionados. Para escolher qual algoritmo será utilizado, o módulo de conciliação possui uma classe chamada Methodology, a qual contém uma instância do algoritmo a ser utilizado e o método solvecollectiveconflict que executa esse algoritmo. Essa classe não é abstrata pois a execução do método de resolução simplesmente executa o algoritmo selecionado. Porém, ela pode ser estendida para que possua o comportamento desejado pela aplicação. A configuração de qual classe será utilizada é feita pelo elemento conflictresolutionclass do arquivo XML. Assim como no módulo de detecção de conflitos, o padrão de projeto Factory [Gamma et al. 1995] e os métodos de reflexão Java foram adotados para permitir a instanciação da classe escolhida apenas pelo seu nome. A ferramenta atualmente possui a implementação de três metodologias para resolução de conflitos. Uma dessas metodologias escolhe o algoritmo que consome menos recurso, outra escolhe aquele que trará maior satisfação aos usuários e a última realiza um balanceamento entre o consumo de recursos e a satisfação dos usuários. Em relação aos algoritmos disponibilizados pelo repositório, a ferramenta já possui cinco implementações disponíveis. Porém, o usuário pode incrementar o repositório com novos algoritmos, bastando criar uma classe que estenda a classe abstrata Resolution- Algorithm. Essa classe abstrata possui os campos que representam os meta-dados de cada algoritmo e o método abstrato run, que contém a implementação dos passos do algoritmo. Para utilizar um algoritmo, é preciso informar ao simulador, por meio do arquivo XML, que o mesmo deverá ser adotado, bem como os valores para seus meta-dados. O arquivo XML permite que sejam configurados vários algoritmos para participarem do repositório da aplicação. Cada algoritmo é indicado pelo elemento algorithm, que contém os atributos class, para indicar qual classe representa o algoritmo, e name contendo o nome do algoritmo. Cada elemento algorithm possui ainda sub-elementos que configuram os valores dos seus respectivos meta-dados, sendo: AvgEnergyConsumptionProcessing: valor médio esperado para o consumo de energia do algoritmo com processamento; AvgCollectiveQoS: valor médio esperado para qualidade de serviço do algoritmo; AvgIndividualQoS: valor médio esperado para o coeficiente de variação da qualidade de serviço; AvgNumberMessages: número esperado de mensagens trocadas pelos dispositivos da aplicação para o algoritmo; AvgMessageSize: tamanho médio das mensagens do algoritmo. Novamente o padrão de projeto Factory [Gamma et al. 1995] foi utilizado para que a lista de algoritmos seja instanciada e configurada de acordo com os meta-dados dos parâmetros indicados. Dessa forma, o módulo de conciliação de conflitos é adaptável pela configuração de qual classe utilizar para selecionar o algoritmo e também quais algoritmos devem ser considerados e com quais valores para seus meta-dados. Outras Classes: a classe GenericReturn é utilizada para retornar os resultados obtidos pelo algoritmo escolhido pela metodologia utilizada. Ela é necessária visto ser impossível saber antecipadamente quais serão os dados retornados por cada implementação. A classe DefaultMobileDevice simula os dispositivos computacionais utilizados pelos participantes das aplicações. Ela possui a representação de uma fonte de energia (classe

7 XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 929 Battery), bem como métodos que correspondem ao envio e recepção de mensagens. Heranças podem ser criadas para que a classe reflita as características de um dispositivo (e.g., classe NexusOneBasedDevice) Exemplo de Utilização: Guia Turístico Computacional Coletivo Para demonstrar o uso da ferramenta, uma aplicação de guia turístico coletivo computacional foi implementada. Todos os turistas desejam realizar tarefas da aplicação em conjunto. Porém, em determinados momentos, eles podem apresentar diferentes interesses, gerando conflitos que devem ser resolvidos. < configuration > < c o n f l i c t D e t e c t i o n C l a s s name=" br. ufmg. dcc. c o l l e c t i v e c o n t e x t s. T a s k C o n f l i c t D e t e c t i o n "/ > < c o n f l i c t R e s o l u t i o n C l a s s name=" br. ufmg. dcc. c o l l e c t i v e c o n t e x t s. Methodology. DynamicMethodology "/ > < a l g o r i t h m c l a s s =" br. ufmg. dcc. c o l l e c t i v e c o n t e x t s. a l g o r i t h m s. M a j o r i t y T a s k A l g o r i t h m " name=" M a j o r i t y "> <AvgEnergyConsumptionProcessing >200 </ AvgEnergyConsumptionProcessing > <AvgCollectiveQoS >60.48 </ AvgCollectiveQoS > <AvgIndividualQoS >60.80 </ AvgIndividualQoS > <AvgNumberMessages >1.0 </ AvgNumberMessages> <AvgMessageSize >100.0 </ AvgMessageSize > </ algorithm > < a l g o r i t h m c l a s s = "... " name = "... " >... </ algorithm > </ c o n f i g u r a t i o n > Parte do arquivo XML gerado para a aplicação está apresentado acima. Alguns detalhes foram omitidos para facilitar a visualização e compreensão. Com relação à detecção de conflitos, foi preciso simplesmente indicar qual o nome da classe a ser utilizada. Nesse caso, foi utilizada a detecção por tarefas já disponibilizada pela ferramenta Siafu- CReMe (classe TaskConflictDetection). Para a conciliação, foi utilizada a versão proposta pela metodologia CReMe (classe DynamicMethodology) que também já está implementada na Siafu-CReMe. Três algoritmos já existentes no repositório foram selecionados e seus valores de meta-dados configurados. Em resumo, para uma aplicação de guia turístico coletivo, somente com as opções fornecidas pela Siafu-CReMe já foi possível configurar e executar a simulação. No entanto, caso uma aplicação não seja atendida pelas opções disponíveis, basta estender as classes existentes com as características desejadas e configurar normalmente a simulação. 5. Considerações Finais Este trabalho apresentou a ferramenta Siafu-CReMe para simulação de tratamento de conflitos em aplicações cientes de contexto coletivas. A ferramenta foi baseada na metodologia CReMe para tratamento de conflitos coletivos e implementada como uma extensão do simulador Siafu. Para atender a diferentes pesquisadores da área, a Siafu-CReMe possui duas principais características: adaptabilidade: um usuário pode facilmente configurar os detalhes de detecção e resolução de conflitos alterando apenas um arquivo de configuração XML; extensibilidade: foram definidas interfaces básicas para os módulos e essas interfaces podem ser facilmente estendidas para atender a diferentes aplicações. A ferramenta e a documentação contendo detalhes sobre como utilizá-la podem ser encontrados no site 1 thaisrb/sbrc2011. O plano para a demonstração no simpósio é: 1 Atenção ao copiar o link diretamente para o navegador pois o caractere pode ser corrompido.

8 930 Anais apresentação inicial dos objetivos da ferramenta; apresentação inicial da ferramenta de simulação Siafu; explicação das principais classes da Siafu-CReMe; configuração e execução da aplicação de guia turístico; explicação sobre como implementar um novo modelo de detecção de conflitos; explicação sobre como implementar um novo algoritmo de resolução de conflitos; explicação sobre como implementar uma nova metodologia. Referências Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith, M., and Steggles, P. (1999). Towards a better understanding of context and context-awareness. In HUC 99: Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing, pages , London, UK. Springer-Verlag. Gamma, E., Helm, R., Johnson, R. E., and Vlissides, J. (1995). Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley. Jouve, W., Bruneau, J., and Consel, C. (2009). Diasim: A parameterized simulator for pervasive computing applications. In PERCOM 09: Proceedings of the 2009 IEEE International Conference on Pervasive Computing and Communications, pages 1 3, Washington, DC, USA. IEEE Computer Society. Kim, I., Park, H., Noh, B., Lee, Y., Lee, S., and Lee, H. (2006). Design and implementation of context-awareness simulation toolkit for context learning. Sensor Networks, Ubiquitous, and Trustworthy Computing, International Conference on, 2: Martin, M. and Nurmi, P. (2006). A generic large scale simulator for ubiquitous computing. Mobile and Ubiquitous Systems, Annual International Conference on, 0:1 3. NS2 (2001). The Network Simulator ns-2 (v2.1b8a). O Neill, E., Klepal, M., Lewis, D., O Donnell, T., O Sullivan, D., and Pesch, D. (2005). A testbed for evaluating human interaction with ubiquitous computing environments. Testbeds and Research Infrastructures for the Development of Networks & Communities, International Conference on, 0: Park, J., Moon, M., Hwang, S., and Yeom, K. (2007). Cass: A context-aware simulation system for smart home. Software Engineering Research, Management and Applications, ACIS International Conference on, 0: Siafu (2010). An Open Source Context Simulator. Silva, T. R. M. B., Ruiz, L. B., and Loureiro, A. A. (2010). Tratamento de Conflitos Coletivos em Sistemas Ubíquos Cientes de Contexto. PhD thesis, Departamento de Ciência da Computação Universidade Federal de Minas Gerais. Van Nguyen, T., Kim, J. G., and Choi, D. (2009). Iss: the interactive smart home simulator. In ICACT 09: Proceedings of the 11th international conference on Advanced Communication Technology, pages , Piscataway, NJ, USA. IEEE Press. Zeng, X., Bagrodia, R., and Gerla, M. (1998). Glomosim: a library for parallel simulation of large-scale wireless networks. SIGSIM Simul. Dig., 28(1):