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

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 Silva1 , Fabrício A. Silva1 , Linnyer B. Ruiz2 , Antonio A. F. Loureiro3
1
2
3
Campus Florestal – Universidade Federal de Viçosa (UFV)
35.690-000 – Florestal – MG – Brasil
Departamento de Informática – Universidade Estadual de Maringá (UEM)
87.020-900 – Maringá – PR – Brasil
Departamento de Ciência da Computação – Universidade Federal de Minas Gerais (UFMG)
31.270-010 – 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
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.
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].
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 conflictResolutionClass 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
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 detectCollectiveConflict, 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
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 ResolutionAlgorithm. 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
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).
4.1. 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 =" b r . ufmg . d c c . 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 =" b r . ufmg . d c c . c o l l e c t i v e c o n t e x t s . M e t h o d o l o g y . DynamicMethodology " / >
< a l g o r i t h m c l a s s =" b r . ufmg . d c c . 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 " >
< A v g E n e r g y C o n s u m p t i o n P r o c e s s i n g >200 </ A v g E n e r g y C o n s u m p t i o n P r o c e s s i n g >
<AvgCollectiveQoS >60.48 </ AvgCollectiveQoS >
<AvgIndividualQoS >60.80 </ AvgIndividualQoS >
<AvgNumberMessages > 1 . 0 < / AvgNumberMessages >
< AvgMessageSize > 1 0 0 . 0 < / AvgMessageSize >
</ a l g o r i t h m >
< a l g o r i t h m c l a s s = " . . . " name = " . . . " >
...
</ a l g o r i t h m >
</ 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 SiafuCReMe (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 site1 http://www.dcc.ufmg.br/∼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.
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 304–307, 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:96–103.
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). http://www.isi.edu/nsnam/ns/.
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:60–69.
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:461–467.
Siafu (2010). An Open Source Context Simulator. http://siafusimulator.sourceforge.net/.
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 1828–1833, 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):154–161.