Upload
jurmir-canal-neto
View
1.914
Download
2
Embed Size (px)
DESCRIPTION
Citation preview
CENTRO DE ENSINO SUPERIOR DE FOZ DO IGUACU
CURSO DE CIENCIA DA COMPUTACAO
TRABALHO DE CURSO
MODELAGEM DE AMBIENTES DE COMPUTACAO UBIQUA
UTILIZANDO SIMULACAO
JURMIR CANAL NETO
FOZ DO IGUACU - PR
2009
JURMIR CANAL NETO
MODELAGEM DE AMBIENTES DE COMPUTACAO UBIQUA
UTILIZANDO SIMULACAO
Trabalho de Conclusao de Curso submetidoao Centro de Ensino Superior de Foz doIguacu como parte dos requisitos para a ob-tencao do grau de bacharel em Ciencia daComputacao.
Orientador: Gildomiro Bairros
FOZ DO IGUACU - PR
2009
Resumo
Vista como a “Terceira-onda” da computacao, a Computacao Ubıqua visa criar sis-temas e ambientes que sejam capazes de auxiliar os seus usuarios a realizar suas tarefasde uma forma nao intrusiva e respeitando as caracterısticas e costumes de cada um. Si-mular os sistemas de tais ambientes e uma parte imprescindıvel do projeto, pois, alem desimplificar a complexidade da visualizacao do sistema, esta ainda pode adiantar diversosproblemas que seriam encontrados apenas na fase final, onde correcoes seriam caras etrabalhosas ou por vezes ate mesmo impossıveis.
Abstract
Seen as the third wave of computing, Ubiquitous Computing aims to create systemsand environments that are able to help its users to perform their tasks in a non-intrusiveway, respecting the characteristics and customs of each one. Simulate the systems of suchenvironments is a essential part of the project, because it can simplify the complexity ofthe system’s visualization, this can predict various issues that would be found only in thefinal stages, where corrections would be costly and difficult or sometimes even impossible.
Lista de Abreviaturas e Siglas
AmI Ambientes Inteligentes
CDMA Code Division Multiple Access
CSV Comma Separated Values
DAO Data Access Object
DESMO-J Discrete-Event Simulation and Modelling in Java
EPL Eclipse Public License
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
HSDPA High-Speed Downlink Packet Access
IDE Integrated Development Environment
LMDS Local Multipoint Distribution Service
LTE Long Time Evolution
MER Modelo Entidade-Relacionamento
MMDS Multichannel Multipoint Distribution Service
MN Mobile Nodes
P2P Peer-to-Peer
PC Personal Computer
PDA Personal Digital Assistants
RMI Remote Method Invocation
RPC Remote Procedure Call
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query Language
UML Unified Modeling Language
UWB Ultra Wide Band
WiMax Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
WMAN Wireless Metropolitan Area Network
WPAN Wireless Personal Area Network
WWAN Wireless Wide Area Network
Lista de Figuras
2.1 Relacao entre AmI e outras areas da computacao . . . . . . . . . . . . . . 20
2.2 Classificacao das tecnologias de redes sem fio . . . . . . . . . . . . . . . . . 23
2.3 Relacao entre Computacao Ubıqua, Pervasiva e Movel . . . . . . . . . . . . 26
2.4 Demonstracao do contexto e suas entidades . . . . . . . . . . . . . . . . . . 27
2.5 Ciclo de vida de um estudo simulado . . . . . . . . . . . . . . . . . . . . . 32
2.6 Exemplo de componentes de uma simulacao em computacao ubıqua . . . . 33
4.1 Representacao da Aquitetura Proposta na Implementacao do Sistema . . . 40
4.2 Modelo Entidade Relacional do Banco de Dados Utilizado . . . . . . . . . 42
4.3 Deteccao do Sensor com raio de 3 quadros . . . . . . . . . . . . . . . . . . 43
4.4 Classes do Pacote Localezation . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Classes do Pacote Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Classes do Pacote Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Taxa de Acerto Para 35 Clientes . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Taxa de Acerto Para 10 de Raio . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Taxa de Acerto Para 50 Clientes . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Diferenca Entre a Taxa de Acerto das Hipoteses Para 50 Clientes . . . . . 55
Lista de Listagens
4.1 Classe Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Metodo doInitialSchedules da Classe Modelo . . . . . . . . . . . . . . . . . 48
4.3 Diferenciacao das Deteccoes na Classe Sensor . . . . . . . . . . . . . . . . 49
4.4 Metodo lifeCycle da Classe SimProcessCliente . . . . . . . . . . . . . . . . 49
Sumario
1 Introducao 11
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.2 Objetivos Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Referencial Teorico 14
2.1 Sistemas Distribuıdos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3 Tipos de Sistemas Distribuıdos . . . . . . . . . . . . . . . . . . . . 16
2.1.3.1 Sistemas de Computacao Distribuıdos . . . . . . . . . . . 16
2.1.3.2 Sistemas de Informacao Distribuıdos . . . . . . . . . . . . 17
2.1.3.3 Sistemas Distribuıdos Pervasivos . . . . . . . . . . . . . . 17
2.1.4 Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4.1 Centralizadas . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.4.2 Nao-centralizadas ou Descentralizadas . . . . . . . . . . . 18
2.1.4.3 Hıbridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Ambientes Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Interdisciplinaridade . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Computacao Movel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1 Redes de Comunicacao Sem Fio . . . . . . . . . . . . . . . . . . . . 22
2.3.2 Limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Redes Ad Hoc Moveis . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Computacao Ubıqua ou Pervasiva . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1 Princıpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Consciencia de Contexto . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.3 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.4 Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Modelagem e Simulacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.1 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.3 Passos de Um Estudo Simulado . . . . . . . . . . . . . . . . . . . . 31
2.6 Utilizacao de Simulacao na Computacao Ubıqua . . . . . . . . . . . . . . . 32
2.6.1 Componentes de Uma Simulacao de Computacao Ubıqua . . . . . . 33
2.6.2 Estudos Similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Descricao do Ambiente Experimental 36
3.1 Tecnologias Envolvidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Estrutura Fısica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Configuracoes de Hardware . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Estrutura Logica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Sistema Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Aplicativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2.2 MySQL Workbench . . . . . . . . . . . . . . . . . . . . . 37
3.3.2.3 Netbeans . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 Bibliotecas e Frameworks . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3.1 DESMO-J . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3.2 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4 Implementacao 40
4.1 Especificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Codificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Pacote Localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Pacote Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Pacote Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6 Pacote Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7 Pacote Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7.2 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7.3 SimProcessCliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8 Execucao e Saıdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Resultados 51
6 Consideracoes Finais e Trabalhos Futuros 56
6.1 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Referencias Bibliograficas 57
11
1 Introducao
Integrar a computacao aos atos do dia-a-dia sem alterar habitos e costumes, levando
em consideracao a pessoalidade de cada um, e o objetivo da Computacao Ubıqua. Weiser
(1991), criador do termo “Computacao Ubıqua” (Ubiquitous Computing), prega que a
tecnologia deve fazer parte da vida das pessoas de uma forma nao intrusiva, ou seja, o
usuario nao deve adequar seus habitos a computacao, mas sim, a computacao deve estar
preparada para moldar-se as necessidades de cada um dos usuarios. Neste contexto, ambi-
entes inteligentes, saturados de computadores e preparados para lidar com a computacao
ubıqua, tanto fornecem informacoes e servicos ao usuario, quanto coletam informacoes
dele e reagem a suas acoes. Projetar esses ambientes de forma que seus servicos estejam
otimizados e imprescindıvel tanto para o bom aproveitamento das solucoes quanto para
evitar a frustracao do usuario.
A computacao ubıqua e considerada a “terceira-onda” da computacao (JANSEN et
al., 2005), sendo assim e um desafio para quase todas as suas areas. Sistemas distribuıdos
e computacao movel sao as principais afetadas, outro grande desafio e o desenvolvimento
de aplicacoes para esse tipo de ambiente. Entretanto questoes como: redes sem fio, redes
de alta disponibilidade e seguranca da informacao sao tambem muito importantes.
De acordo com este contexto, esse trabalho implementa a simulacao de um ambiente
voltado a computacao ubıqua. Essa simulacao se faz necessaria para a validacao de um de-
terminado ambiente, portanto como verificar a validade do uso de simulacoes em projetos
de ambientes inteligentes voltados a computacao ubıqua?
Como possıvel solucao propoe-se a criacao de um modelo na forma de matriz bidimen-
sional para determinar o posicionamento dos elementos no ambiente. Modelar o ambiente
e os seus elementos na forma de objetos, de forma que seja possıvel implementar uma
simulacao utilizando a linguagem de programacao Java. Coletar os dados provenientes da
execucao e entao verificar a eficiencia da simulacao no referido ambiente.
O ambiente simulado proposto e um ambiente de super-mercado onde as pessoas cir-
12
culam e fazem suas compras, deseja-se detectar qual produto determinado cliente retirou
de uma prateleira. A simulacao e utilizada para a verificacao de cada retirada de acordo
com tres hipoteses de disposicao dos sensores: afixados nos clientes, nos porta-produto
(carrinho ou cestinha) ou em ambos.
1.1 Objetivos
1.1.1 Objetivo Geral
Desenvolver um simulador para avaliar a possibilidade de uso de simulacoes em pro-
jetos de computacao ubıqua.
1.1.2 Objetivos Especıficos
• Apresentar conceitos de Sistemas Distribuıdos, Computacao Movel, Computacao
Ubıqua, Ambientes Inteligentes e Simulacao;
• Modelar um ambiente voltado a Computacao Ubıqua;
• Elaborar um prototipo simulado para a avaliacao do ambiente;
• Implementar o prototipo simulado usando Java;
• Realizar a simulacao do ambiente;
• Avaliar os resultados da simulacao.
1.2 Justificativa
Com o avanco das tecnologias de comunicacao e a miniaturizacao dos componentes, a
humanidade se torna a cada dia mais imersa em um mundo de computadores minusculos
e onipresentes. Neste contexto, a criacao de ambientes inteligentes capazes de fornecerem
servicos e informacoes atraves de tais equipamentos e importante e cada vez mais comum.
A capacidade de prever o comportamento de tal ambiente antes de sua criacao e funda-
mental para evitar a frustracao na utilizacao dos servicos e tambem os custos adicionais
de correcao do projeto fracassado.
13
Este projeto justifica-se por desenvolver uma forma de testar a validade do uso de
simulacoes em projetos de ambientes de computacao ubıqua antes de sua implantacao,
evitando assim os problemas ja relacionados.
Em se tratando de uma area de estudo relativamente nova, este trabalho se propoe a
explorar as caracterısticas basicas de um ambiente inteligente em um cenario de compu-
tacao ubıqua, auxiliando na obtencao de informacoes pela comunidade.
1.3 Metodologia
Trata-se de uma pesquisa aplicada, pois caracteriza-se por seu interesse pratico, isto e,
os resultados devem ser aplicados ou utilizados, imediatamente, na solucao de problemas
que ocorrem na realidade (LAKATOS; MARCONI, 2000).
Esta pesquisa classifica-se como pesquisa exploratoria, pois possui o objetivo de pro-
porcionar maior familiaridade com o problema, com vistas de torna-lo mais explıcito ou a
construir hipoteses. Este tipo de pesquisa tem como objetivo principal o aprimoramento
de ideias ou a descoberta de intuicoes (GIL, 2002).
Quanto aos procedimentos delimita-se como um estudo de caso, consistindo no es-
tudo profundo de poucos elementos, afim de descrever a situacao do contexto e formular
hipoteses ou teorias sobre a resolucao do problema (GIL, 2002).
Quanto as tecnicas e procedimentos de investigacao utilizada classifica-se como pes-
quisa indireta, ou bibliografica, ja que utiliza como base material ja elaborado (GIL,
2002), buscando embasamento em livros, artigos cientıficos, publicacoes periodicas e sites
da internet.
14
2 Referencial Teorico
2.1 Sistemas Distribuıdos
Segundo Tanenbaum e Steen (2007) sistemas distribuıdos sao uma colecao de com-
putadores que se apresenta ao usuario como apenas um sistema computacional. Ainda
segundo eles essa definicao abrange os dois aspectos mais importantes dos sistemas com-
putacionais distribuıdos, o hardware que e autonomo e o software que para a visao do
cliente, roda em um unico computador.
Ja Coulouris, Dollimore e Kindberg (2005) definem um sistema distribuıdo como sendo
um sistema no qual os computadores de uma rede se comunicam e coordenam suas ati-
vidades apenas pela troca de mensagens. Essa definicao engloba as caracterısticas de:
concorrencia entre componentes, ausencia de clock global e falhas independentes de com-
ponentes.
2.1.1 Propriedades
Para Coulouris, Dollimore e Kindberg (2005) as principais propriedades de um sistema
distribuıdos sao:
• Concorrencia: Em uma rede de computadores os programas devem ser executados
de forma concorrente. Dois processos podem realizar seus trabalhos em maquinas
separadas compartilhando recursos quando necessario;
• Ausencia de Clock Global: Quando programas precisam cooperar eles coorde-
nam suas acoes apenas por troca de mensagens. Esta coordenacao depende da ideia
distribuıda do tempo em que a acao deve ocorrer;
• Falhas Independentes: Todo sistema computacional pode falhar e e responsa-
bilidade dos engenheiros do sistema prever essa falha e suas consequencias. Um
15
sistema distribuıdo falha de forma diferente dos convencionais, uma falha provoca o
isolamento do seu causador, sem provocar danos ao resto do sistema.
Alem destas Tanenbaum e Steen (2007) ainda citam a forma de o usuario enxergar
o sistema como sendo unico, nao percebendo que os recursos utilizados podem estar es-
palhados em varias maquinas diferentes, como sendo uma das principais propriedades de
um sistema distribuıdo.
2.1.2 Caracterısticas
De acordo com Tanenbaum e Steen (2007) e Coulouris, Dollimore e Kindberg (2005)
existem varias caracterısticas importantes inerentes aos sistemas distribuıdos, entre elas
cita-se:
• Abertura: Deve ser possıvel a reimplementacao de funcoes do sistema sem que as ja
existentes sejam afetadas. Novos recursos ou modificacoes em recursos ja existentes
devem aderir ao sistema sem atrapalhar a parte que ja esta em funcionamento;
• Confiabilidade: Um sistema distribuıdo deve ser mais confiavel que um sistema
convencional. Se uma maquina falhar outra assumira seu lugar com o mınimo de
prejuızo possıvel;
• Escalabilidade: Um sistema deve ser capaz de suportar o aumento no numero de
recursos mantendo um desempenho satisfatorio. Se um sistema for projetado para
suportar X maquinas ao ser adicionado a ele mais Y maquinas ele deve aumentar o
seu desempenho de forma proporcional, apresentando o mınimo de perca possıvel;
• Flexibilidade: Deve ser possıvel adicionar novos recursos ao sistema sem causar
problemas a parte ja existente. A adicao de novas maquinas por exemplo deve ser
absorvida pelo sistema sem que ele necessite de grandes modificacoes;
• Transparencia: Os usuarios nao devem perceber que o sistema e distribuıdo. Ao
acessar o sistema ele devera ter a impressao de que todo ele esta em uma unica
maquina;
• Heterogeneidade: Um sistema distribuıdo pode apresentar diferentes tipos de
hardware, redes de comunicacao, equipamentos de redes, linguagens de programacao
entre outros;
16
• Performance: Rodar uma aplicacao em um sistema distribuıdo deve apresentar,
no mınimo, a mesma performance que ao roda-la em um sistema convencional;
• Seguranca: Boa parte das informacoes que transitam em um sistema distribuıdo
possui grande valor aos seus usuarios, portanto deve-se garantir a confidencialidade,
a integridade e a disponibilidade de tais dados;
• Tratamento de Falhas: Falhas ocorrem em todos os sistemas computacionais, em
um sistema distribuıdo ela deve ser detectada, mascarada ou escondida do usuario,
de forma que ele nao perceba a ocorrencia e ainda, se possıvel, realizar a recuperacao
do sistema para o estado anterior a falha.
2.1.3 Tipos de Sistemas Distribuıdos
Existem basicamente tres tipos de sistemas distribuıdos distintos: os Sistemas de Com-
putacao Distribuıdos, os Sistemas de Informacao Distribuıdos e os Sistemas Distribuıdos
Pervasivos (TANENBAUM; STEEN, 2007).
2.1.3.1 Sistemas de Computacao Distribuıdos
Esta e um das principais divisoes dos sistemas distribuıdos pois e a classe utilizada
nas tarefas de computacao de grande desempenho. Nesse modelo o intuito e de se dividir
o trabalho (processamento) em pequenas partes e delega-las aos nos componentes para
que estas sejam processadas, acelerando o trabalho de processamento (TANENBAUM;
STEEN, 2007). Este modelo ainda pode ser subdividido em:
• Sistema de Computacao em Cluster : Onde o hardware e software (sistema
operacional) de todas as maquinas componentes do sistema sao iguais, e estes estao
ligados a mesma rede;
• Sistema de Computacao em Grade: Neste modelo nao se adota qualquer pre-
missa quanto a hardware ou mesmo software, podendo variar em cada uma das
maquinas. Tambem nao e nescessario que todas as maquinas estejam na mesma
rede.
17
2.1.3.2 Sistemas de Informacao Distribuıdos
Neste modelo o foco esta em distribuir as solucoes de software. E normalmente en-
contrado em empresas que tiveram problemas de integracao ou interoperabilidade en-
tre seus sistemas, necessitando assim a distribuicao dos mesmos. Possuem dois tipos:
(TANENBAUM; STEEN, 2007)
• Sistemas de Processamento de Transacoes: Este sistema e primordialmente
utilizado em bancos de dados e outros sistemas onde e necessario garantir que uma
operacao sera realizada com sucesso, apresenta controle de suas atividades de forma
a garantir a atomicidade, consistencia, isolamento e durabilidade de uma operacao.
• Sistemas de Integracao de Aplicacoes Empresariais: A comunicacao direta
entre aplicacoes e o problema resolvido por esse tipo de sistema, onde cria-se inter-
mediadores (Middlewares) para realizar a integracao entre sistemas diferentes sem
necessitar a reimplementacao das aplicacoes ja existentes. Remote Procedure Call
(RPC) e Remote Method Invocation (RMI) sao exemplos de middlewares utilizados
nesse sistema.
2.1.3.3 Sistemas Distribuıdos Pervasivos
Diferentemente dos sistemas anteriores, onde a estabilidade e imprescindıvel, nos sis-
temas distribuıdos pervasivos ocorre justamente o contrario, sendo a instabilidade um
comportamento esperado. Principalmente devido a sua utilizacao ser feita por dispositi-
vos moveis ou embutidos, sua comunicacao e efetuada primordialmente atraves de redes
sem-fio (na maioria das vezes instaveis) usando composicoes Ad Hoc, o que causa a des-
centralizacao e a impossibilidade de se manter um modelo de topologia por muito tempo
o que contribui ainda mais para o cenario de instabilidade. Neste sistema os dispositivos
sao caracterizados por seu pequeno tamanho, pela alimentacao por baterias, mobilidade
e hardware de conexao sem fio (TANENBAUM; STEEN, 2007).
2.1.4 Arquiteturas
Um modelo arquitetural define a forma com a qual um componente do sistema interage
com outro componente e como essa interacao e mapeada em relacao a rede de computado-
res (COULOURIS; DOLLIMORE; KINDBERG, 2005). Para Tanenbaum e Steen (2007)
18
existem tres organizacoes basicas para as arquiteturas: centralizadas, descentralizadas e
hıbridas.
2.1.4.1 Centralizadas
Na arquitetura centralizada os servicos ficam centralizados em um servidor de onde os
clientes requisitam dados e aguardam resposta, o servidor por sua vez, aceita as requisicoes
apropriadas, processa-as e retorna os dados requisitados aos clientes. Sendo um “servidor”
um processo que disponibiliza um recurso especıfico, e um “cliente” um processo que
requisita tal recurso.
2.1.4.2 Nao-centralizadas ou Descentralizadas
As arquiteturas nao-centralizadas ou descentralizadas sao divididas em dois tipos, as
de distribuicao vertical onde os elementos logicos que sao diferentes ficam em maquinas
diferentes. E as de distribuicao horizontal, tambem conhecida como Peer-to-Peer (P2P),
onde cada maquina se subdivide em partes logicas que se equivalem, mantendo assim uma
relacao de equilıbrio entre as porcoes de dados manipuladas.
2.1.4.3 Hıbridas
Muitos sistemas distribuıdos combinam aspectos arquitetonicos dos modelos anteri-
ormente citados, sendo assim considerada uma distribuicao “hıbrida”. Um exemplo dessa
distribuicao sao os servidores de borda, que faz a ligacao entre uma rede distribuıda e uma
rede cliente-servidor, pode-se citar os provedores de acesso a internet como um servidor
de borda, ja que o usuario se conecta a ele (cliente-servidor) para efetuar acesso a internet
(descentralizada) por exemplo.
2.2 Ambientes Inteligentes
Um dos principais desafios do desenvolvimento de sistemas para a computacao ubıqua
e a criacao de Ambientes Inteligentes (AmI) capazes de suportar o tipo de interacao
necessaria. Remagnino, Foresti e Ellis (2005) caracterizam AmI como um paradigma que
oferece suporte a nova geracao de sistemas inteligentes e introduz novos significados a
comunicacao entre homem, maquinas e o ambiente. Computadores “desaparecem” em
19
segundo plano enquanto os usuarios transitam em primeiro plano no total controle do
ambiente em sua volta.
Para Emiliani e Stephanidis (2005) o conceito de AmI prove a visao de uma socie-
dade da informacao onde a enfase esta na simplicidade de uso, suporte mais eficiente aos
servicos, maior poder ao usuario e suporte as interacoes humanas. As pessoas se cercarao
de interfaces inteligentes e intuitivas que estarao inseridas em todos os objetos e em um
ambiente que seja capaz de reconhecer e responder a presenca de diferentes indivıduos de
uma maneira integrada, nao obstrutiva e praticamente invisıvel.
2.2.1 Interdisciplinaridade
Segundo Augusto e McCullagh (2007) a utilizacao de AmI cresce rapido como um
topico de interesse multi-disciplinar que permite a muitas areas de pesquisa ter uma
influencia significativa e benefica na nossa sociedade, conforme a Figura 2.1.
20
Figura 2.1: Relacao entre AmI e outras areas da computacao
Augusto e McCullagh (2007, Adaptada)
Redes, Sensores, Interfaces Homem-Maquina, Computacao Ubıqua e Inteligencia Ar-
tificial, todas essas areas sao relevantes e interrelacionadas, mas nenhuma delas cobre
totalmente o escopo de AmI. Os AmI unem os recursos dessas tecnologias para prover
servicos flexıveis e inteligentes aos usuarios agindo eu seu interior.
Ainda segundo Augusto e McCullagh (2007) a ideia basica de um Ambiente inteligente
e que enriquecendo um ambiente com tecnologias (Redes, Sensores, Interfaces Homem-
Maquina e etc) um sistema pode ser construıdo para tomar decisoes que beneficiem o seu
usuario, baseado em informacoes de tempo real e/ou historicas acumuladas.
21
2.2.2 Requisitos
Segundo Emiliani e Stephanidis (2005) ainda nao esta claro como um AmI deve ser
concebido e implementado, entretanto e possıvel delimitar alguns pontos importantes que
sao comuns nesse tipo de projeto:
• Em um AmI os servicos sao dinamicos e podem se reconfigurar e recombinar em
tempo de execucao para acomodar as necessidades de diferentes usuarios, em dife-
rentes contextos e ambientes;
• Nao ha diferenca entre comunicacao inter-pessoal e acesso a informacao. Compo-
nentes diferentes, usando variados tipos de mıdias (vıdeo, som, texto, figuras e etc)
estao interconectados para permitir a livre combinacao de suas funcoes;
• Os servicos sao altamente interativos e as interacoes sao complexas em termos das
funcionalidades oferecidas, entradas requeridas, saıdas providas, estrutura de comu-
nicacao e capacidade de configuracao;
• Muitos servicos utilizam recursos de multimıdia, provendo informacoes em diferentes
tipos de mıdia (vıdeo, som, texto, figuras e etc) simultaneamente e de maneira
integrada;
• As interacoes ocorrem de muitas maneiras, usando diferentes habilidades sensoriais
e motoras de forma concorrente e baseada nas formas mais simples de dialogo;
• A comunicacao e acesso a informacao sao usadas de forma concorrente para resolver
problemas comuns de forma combinada. E ainda, a cooperacao tem seu lugar entre
as pessoas ou seus representantes (avatares ou agentes), para a atribuicao de nıveis
variaveis de confianca;
• E fato que a computacao esta progressivamente mais social. Acesso a comunicacao
ou informacao nao e mais problema de apenas um indivıduo e do contato entre duas
pessoas, mas sim esta estendida em comunidades de usuarios que tem seus proprios
espacos (muitas vezes virtuais) onde podem interagir.
2.3 Computacao Movel
Computacao Movel e o estudo de tecnicas e dispositivos computacionais aplicados
fora de ambientes fixos. Seu aplicacao basica baseia-se na capacidade dos dispositivos
22
moveis de se comunicarem, atraves de redes sem-fio (wireless), com a parte fixa da rede
e possivelmente com outros dispositivos moveis, independentemente da sua localizacao.
Segundo Ahmad (2005) no entanto uma rede sem-fio nao e sinonimo de mobilidade, ja
que existem redes sem-fio com ambas as “pontas” fixas.
2.3.1 Redes de Comunicacao Sem Fio
Segundo Sanches (2007) redes de telecomunicacao sao conjuntos organizados de equi-
pamentos que possuem a funcao de transmissao, comutacao, multiplexacao ou qualquer
outra relevante a area. Para classificar as redes de computacao movel utiliza-se a dife-
renciacao entre tecnologias, area de alcance e taxa de transferencia, conforme Figura 2.2.
Podendo classifica-las da seguinte forma:
• Wireless Personal Area Network (WPAN) - Redes Pessoais Sem Fio: Redes de
curtıssimo alcance (dezenas de metros), com velocidades normalmente entre 250
Kbps e 480 Mbps. Muito utilizado para comunicacoes P2P ou Device-to-device
entre dispositivos 802.15 (Bluetooth), Ultra Wide Band (UWB) e Zigbee;
• Wireless Local Area Network (WLAN) - Redes Locais Sem Fio: Rede de curto-
medio alcance, taxa de transferencia entre 11 Mbps e 54 Mbps. Utilizado para
muitos fins, pois apresenta boa relacao entre, area de cobertura, velocidade e custo
de implementacao. Seus equipamentos implementam os padroes 802.11A, 802.11B,
802.11G e 802.11E;
• Wireless Metropolitan Area Network (WMAN) - Redes Metropolitanas Sem Fio:
Medio-longo alcance, velocidades entre 11 Mbps e 100Mbps. Redes como 802.16
(WiMax), 802.11 MMDS e 802.11 LMDS fazem parte desse grupo;
• Wireless Wide Area Network (WWAN) - Redes Geograficamente Distribuıdas Sem
Fio: Redes de longo alcance, tendo velocidades variando de 10 Kbps a 2.5 Gbps.
Abrange as redes GSM, GPRS, CDMA, HSDPA e tambem 2.5G, 3G, 3.5G e
4G/LTE.
23
Figura 2.2: Classificacao das tecnologias de redes sem fio
WIDE Project School of Internet (2009, Adaptada)
2.3.2 Limitacoes
Para Nicopolitidis et al. (2003) a computacao movel apresenta diversos problemas que
podem ser considerados como fatores limitantes na sua utilizacao. Para a Computacao
Ubıqua e imprescindıvel que tais limitacoes sejam estudadas e transpostas com solucoes
efetivas.
Talvez o pior problema da adocao de redes sem-fio seja a seguranca na transmissao de
dados, comprometida pelo fato dos pacotes trafegarem em um meio nao-restrito e assim
estao sujeitos a acao de softwares de captura de dados conhecidos como Sniffers.
Outro ponto limitante e o consumo de energia dos dispositivos, ja que por serem moveis
estes estarao desacoplados de fontes de energia, dependendo apenas de alimentacao por
baterias, como o hardware desses dispositivos esta cada vez mais potente, e imprescindıvel
o desenvolvimento de baterias duraveis, com tamanho e peso compatıvel, e de hardware
24
mais economico em questao da energia consumida.
Entretanto um dos piores problemas para as redes sem-fio continua sendo as interfe-
rencias sofridas por elementos externos. Condicoes climaticas, tipo de terreno, presenca
de paredes, entre outros tantos obstaculos podem atrapalhar ou ate mesmo interromper
a transmissao de dados em uma rede sem-fio.
A incerteza quanto aos possıveis danos a saude causados pelo campo magnetico e as
ondas celulares emitidas por dispositivos moveis e a deficiencia das interfaces de usuario,
que sao em geral improdutivas e insuficientes, sao outros pontos menores que dificultam
a utilizacao de dispositivos de computacao movel.
2.3.3 Redes Ad Hoc Moveis
Ad Hoc (do latim, “Sem cabeca” ou “Com este objetivo”) e o termo utilizado para des-
crever uma rede onde nao existe um no principal para onde todas as conexoes convergem,
nao apresenta uma topologia definida e um controle centralizado. Em uma rede Ad Hoc
todos os nos trabalham como roteadores em um modelo comunitario onde encaminham
as comunicacoes oriundas de seus vizinhos (BROCH et al., 1998).
Uma Rede Ad Hoc Movel ou Manet, e uma rede Ad Hoc (nao infra-estruturada) onde
os nos se movimentam modificando suas posicoes fısicas e consequentemente a distribuicao
da rede. Em uma rede Ad Hoc Movel existe o conceito de Mobile Nodes (MN) onde um
grupo de MNs formam redes autonomas. Como os nos sao moveis e impossıvel determinar
uma topologia, ja que esta pode mudar a qualquer momento.
Para Johnson (1994) as redes Ad Hoc podem ser classificadas como simetricas nas
quais todos os nos tem responsabilidades similares, distribuıdas igualmente entre eles,
sendo usado onde os MNs possuem caracterısticas similares, e como assimetricas, onde
dependendo de caracterısticas de cada nos, como raio de transmissao, capacidade de
processamento entre outros, este recebe tarefas proporcionais.
2.4 Computacao Ubıqua ou Pervasiva
A computacao conheceu duas grandes eras, primeiro a era do mainframe, onde havia
um computador para muitos usuarios que utilizavam-se de “terminais burros” para ter
acesso aos recursos, logo surgiu a atual era da computacao pessoal, que tirou a exclu-
sividade da computacao de dentro das empresas e universidades e levou as residencias,
25
fazendo uso dos Personal Computers (PCs) e criando a relacao de um computador para
cada um usuario (MUHLHAUSER; GUREVYCH, 2008). A computacao ubıqua e con-
siderada a terceira era da computacao (JANSEN et al., 2005) pois novamente altera a
forma de se utilizar os computadores, mudando a relacao para varias maquinas e um
so usuario, sendo que esses computadores podem ser tanto desktops e notebooks como
celulares, PDAs e dispositivos embarcados.
Nao e somente a quantidade de dispositivos que e alterada com a computacao ubı-
qua, segundo Weiser (1991) a ideia atual de computadores pessoais esta completamente
equivocada e nao aproveita o potencial da informatica, sendo que desktops, notebooks e
outros dispositivos nao conseguem tornar a computacao algo integral e invisıvel na vida
das pessoas. Ele prega que a computacao deve estar integrada a vida de forma que auxilie
a realizacao das tarefas levando em consideracao as particularidades de cada usuario e
do contexto em que ele esta inserido, ou seja, o sistema deve moldar-se as caracterısticas
do usuario e nao o usuario as caracterısticas do sistema, tirando o foco de uma “caixa”
(computador) e colocando-o diretamente na tarefa a ser realizada.
O principal objetivo da Computacao Ubıqua e integrar a computacao aos atos do dia-
a-dia sem alterar habitos e costumes, levando em consideracao a pessoalidade de cada um
e deixando a tarefa a ser realizada em primeiro plano, ao inves do processo de realiza-la
como e com a computacao convencional (WEISER, 1991).
Segundo Campiolo, Cremer e Sobral (2007) a computacao ubıqua prove a perspectiva
de se acessar informacoes a qualquer momento e em qualquer lugar atraves da criacao
de ambientes impregnados de computadores e dispositivos de comunicacao para interacao
direta com o seres humanos.
Diferente dos anteriores Lyytinen e Yoo (apud ARAUJO, 2003) pregam que por serem
areas emergentes e comum observar o uso dos termos computacao ubıqua, computacao
pervasiva e computacao movel como sinonimos, entretanto existem diferencas conceituais
entre elas e cada uma possui diferentes ideias de organizacao. Eles ainda salientam que a
computacao ubıqua pode ser considerada a uniao da computacao movel com a computacao
pervasiva conforme a Figura 2.3.
26
Figura 2.3: Relacao entre Computacao Ubıqua, Pervasiva e Movel
Araujo (2003, Adaptada)
2.4.1 Princıpios
De acordo com Weiser (1991) os princıpios ideologicos da Computacao Ubıqua podem
ser definidos como:
• Finalidade: A finalidade de um computador e ajudar na realizacao de tarefas, sem
se tornar o foco do problema;
• Imperceptibilidade: O melhor computador e um servo quieto e invisıvel;
• Extensao das capacidades humanas: O computador deve estender a intuicao
humana;
• Nao-Obstrucao: A tecnologia deve informar sem demandar o foco ou a atencao.
ja Hansmann, Nicklous e Stober (2001) delimitam os princıpios funcionais da compu-
tacao ubıqua como sendo:
• Diversidade: Existem muitos tipos de dispositivos cada um com suas vantagens,
desvantagens, limitacoes e caracterısticas especıficas;
• Descentralizacao: como se trata de um sistema altamente distribuıdo as respon-
sabilidades ficam descentralizadas de forma que a uniao dos elementos e que forma
a “inteligencia” do ambiente e do sistema.
• Conectividade: seguindo a definicao da palavra “ubıqua” (universal, onipresente)
os nıveis de conexao buscados sao de cobertura total em questao de tempo e espaco,
27
criando uma “malha sem costuras” de redes heterogeneas capazes de prover tais
servicos.
2.4.2 Consciencia de Contexto
Contexto, segundo Anagnostopoulos, Tsounis e Hadjiefthymiades (2007), e qualquer
informacao que pode ser utilizada para caracterizar uma situacao ou entidade. Uma
entidade e qualquer pessoa, ambiente ou objeto que seja considerado relevante para a
integracao entre o usuario e a aplicacao. Uma “Entidade Contextual” atua no sistema,
enquanto a entidade “visıvel”, e uma entidade que apenas fornece informacoes ou servicos.
A juncao de tais entidades forma o contexto, conforme a Figura 2.4.
Figura 2.4: Demonstracao do contexto e suas entidades
Anagnostopoulos, Tsounis e Hadjiefthymiades (2007, Adaptada)
2.4.3 Dispositivos
Para Jansen et al. (2005) um ambiente de computacao pervasiva consiste em uma
colecao de dispositivos e dos que os gerenciam e comandam. Existem dispositivos que
“sentem”o ambiente, que colhem dados e recebem entradas, chamados de sensores, podem
ser comparados com os dispositivos de entrada de dados em um sistema comum. E os
que alteram o ambiente, os atuadores, que trabalham como dispositivos de saıda. Eles
interagem de forma a auxiliar o usuario na resolucao de suas tarefas.
28
Em um sistema computacional comum, o usuario sempre tem de dizer ao sistema
o que ele deve fazer, qual e o proximo passo, ja no sistema pervasivo essa interacao e
mais fluente, tenta-se antecipar as preferencias do usuario de forma que com base nelas
possa-se agir antecipadamente. Essa antecipacao e conseguida principalmente com base
nos sensores, que recebem e repassam as informacoes para o processamento, e posterior
saıda pelos atuadores.
Para Grimm et al. (apud TANENBAUM; STEEN, 2007) um dispositivo na compu-
tacao ubıqua deve reconhecer de forma automatica o ambiente e se adaptar a ele. Sendo
essa adaptacao realizada com base em tres questoes: Adocao de mudancas contextuais,
incentivo as composicoes Ad Hoc e a adocao do compartilhando de recursos como padrao.
2.4.4 Projetos
Desde o primeiro projeto de computacao ubıqua, desenvolvido no Xerox PARC, su-
giram muitos outros que realizam pesquisas e desenvolvem solucoes com bases nos seus
experimentos, entre eles pode-se citar:
• Authoring on the Fly da Universidade de Freiburg, visando integrar servicos de
gravacao de vıdeo, ensino a distancia e criacao em tempo real de material multimıdia
em um unico sistema para serem utilizados em ambientes escolares, universitarios e
tambem em apresentacoes e eventos;
• Classroom 2000 do Georgia Institute of Technology, que visava levantar qual seria o
impacto da computacao ubıqua se aplica em ambientes educacionais, criando meios
para ampliar as capacidades de estudantes e professores atraves do uso de recur-
sos tecnologicos como mıdias digitais, ”arquivamento”das aulas em audio e v entre
outros;
• EasyLiving da Microsoft Research, consistia em criar uma arquitetura capaz de
suportar a agregacao dinamica de hardware e dispositivos, afim de permitir a criacao
de ambientes inteligentes;
• Gator Tech Smart House da Universidade de Florida, e um laboratorio utilizado na
pesquisa de novas tecnicas de computacao ubıqua, sendo principalmente focado na
criacao de ambientes conscientes de contexto.
• HP CoolTown, era um projeto que visava a criacao de interfaces e outros meios para
que os usuarios de dispositivos moveis pudessem interagir com o ambiente em sua
29
volta e com a Web.
• Igrocer, visa ser um “assistente de compras”, servindo tando para a criacao de listas
de compras como listas de produtos disponıveis, afim de automatizar o processo de
compra tanto para o cliente quanto para o comerciante, sendo tambem capaz de
manter um perfil nutricional do usuario.
• Medical Automation Research Center Smart House da Universidade de Virginia,
busca, principalmente, criar ambientes onde idosos podem habitar tendo sua saude
monitorada o tempo todo, utilizando diversos tipos de tecnologias inerentes a com-
putacao ubıqua.
2.5 Modelagem e Simulacao
Banks (1998) define simulacao como a imitacao da operacao de um processo do mundo
real, envolvendo a geracao de uma “historia artificial” do sistema e a observacao das
alteracoes causadas pelas inferencias relativas as caracterısticas do sistema real que esta
sendo representado. Simulacoes sao utilizadas para descrever e analisar o comportamento
do sistema, ajudando no desenvolvimento de sistemas reais. Tanto sistemas ja existentes
como conceituais podem ser modelados com simulacao, o que a torna uma ferramenta
valiosa na solucao de muitos problemas do mundo real.
2.5.1 Caracterısticas
Para Banks (1998) uma simulacao pode ser dividida primordialmente em nove partes
Law e Kelton (apud BANKS, 1998) e Carson (apud BANKS, 1998) definem cada uma
dessas partes como sendo:
• Modelo: E a representacao atual do sistema, deve-se ter a preocupacao com os
limites ou fronteiras do modelo que supostamente representa o sistema real. O
modelo deve ser complexo o bastante para responder as perguntas levantadas, mas
nao complexo demais para criar novas;
• Eventos: Sao as ocorrencias que alteram o estado do sistema. Existem tanto even-
tos internos (endogenos) que pode ser a interacao entre os elementos da simulacao,
quanto eventos externos (exogenos) como por exemplo a “chegada” de um novo
elemento;
30
• Variaveis de Estado do Sistema: Sao a colecao de toda a informacao necessaria
para definir o que aconteceu no interior do sistema para se atingir determinado
estado em determinado tempo;
• Entidades: E a representacao do objetos que necessitam definicao explıcita dentro
do sistema. Uma entidade pode ser dinamica, que atua no sistema ou estatica que
apenas serve as outras entidades;
• Atributos: Sao as representacoes das caracterısticas de uma entidade, esses atri-
butos devem ser considerados como variaveis locais para cada entidade;
• Recursos: Sao as entidades que proveem servicos as outras entidades, podendo
servir uma ou mais entidade ao mesmo tempo, dependendo das restricoes do sistema,
assim como uma entidade dinamica pode requerer um ou mais recurso ao mesmo
tempo;
• Processamento de Lista E uma tarefa resultante da existencia dos recursos, pois
estes apenas trabalharam dentro do seu limite, e as outras requisicoes serao colocadas
em listas (filas ou pilhas, dependendo do comportamento requerido do sistema).
Podem ser usadas listas exclusivas para cada recurso (por exemplo, fila de uma
bilheteria) ou uma lista unica para varios recursos (exemplo, fila de banco);
• Atividade: E um perıodo de tempo com duracao conhecida antes do inıcio da acao.
Ou seja, quando uma atividade comeca e possıvel agendar o final dela;
• Delay : E um perıodo de tempo indefinido, causado pela combinacao de condicoes
do sistema. Primordialmente e o tempo em que uma entidade fica “parada” no
sistema, aguardando a liberacao de um recurso;
2.5.2 Modelagem
Para Simon (apud PRITSKER, 1998) a Modelagem e a principal ferramenta no estudo
do comportamento de sistemas muito complexos.
Modelos sao a descricao do sistema, a sua utilidade e demonstrada por descreve-lo,
desenha-lo e analisa-lo. A modelagem e um processo muito complexo e que, muitas vezes,
envolve tanto a analise indutiva quanto a dedutiva. Se um modelo e a representacao de
um sistema ele pode ser considerado uma abstracao do sistema. Para desenvolver um abs-
tracao o modelista deve decidir quais os elementos do sistema real sao interessantes a essa
31
abstracao. Para chegar a tal conclusao e necessario que uma“finalidade”seja determinada,
um objetivo para a confeccao do modelo, portanto um modelo e a representacao de um
sistema voltado a uma determinada finalidade e modelagem e o processo de desenvolver
tais modelos (PRITSKER, 1998).
2.5.3 Passos de Um Estudo Simulado
De acordo com Pegden, Shannon e Sadowski (apud BANKS, 1998) e Law e Kelton
(apud BANKS, 1998) os passos necessarios para um projeto de estudo utilizando simula-
cao, conforme a Figura 2.5 sao:
• Formulacao do problema;
• Determinacao do objetivo e plano geral de projeto;
• Criacao do Modelo Conceitual;
• Levantamento de dados historicos ou estatısticos a serem utilizados como entrada,
na falta deles confeccao dos dados randomicos;
• Traducao do modelo (transformacao do Modelo Conceitual em computacional, im-
plementacao);
• Verificacao (testa se o modelo gera resultados corretos);
• Validacao (testa se o modelo gera dados proximos ao do fenomeno real);
• Design Experimental (Definicao das variaveis do sistema, por exemplo: tempo de
execucao, numero de repeticoes, maneira de inicializacao entre outros);
• Execucao do sistema e Analise das saıdas;
• Novas Execucoes (Se os resultados dos testes nao forem satisfatorios);
• Documentacao e Relato dos testes e resultados;
• Implementacao (Utilizacao dos resultados da simulacao no sistema real);
32
Figura 2.5: Ciclo de vida de um estudo simulado
Banks (1998, Adaptada)
2.6 Utilizacao de Simulacao na Computacao Ubıqua
Muito ja foi feito para a Computacao Ubıqua utilizando Simulacao, ja que, o uso desta
e de particular importancia para desenvolvedores e pesquisadores dessa area. Grande
parte dos requisitos de hardware estao atingindo a maturidade agora ja que muitas apli-
cacoes sao desenvolvidas pensando em um cenario futuro e contam com hardware que
sera construıdo posteriormente. Ainda atraves da simulacao e possıvel para os pesqui-
33
sadores avaliarem cenarios, aplicacoes e protocolos por exemplo, sem as dificuldades de
se trabalhar diretamente com os dispositivos de hardware reais (REYNOLDS; CAHILL;
SENART, 2006).
Construir modelos reais e uma tarefa complexa e muitas vezes impossıvel. O uso de
modelagem e simulacao para entender e avaliar ambientes de computacao ubıqua e uma
alternativa interessante e aplicavel (CAMPIOLO; CREMER; SOBRAL, 2007).
2.6.1 Componentes de Uma Simulacao de Computacao Ubıqua
Quatro abstracoes podem ser levantadas como componentes basicos desse tipo de
simulacao: Ambientes, Sensores, Atuadores e Aplicacoes (REYNOLDS; CAHILL; SE-
NART, 2006), conforme a Figura 2.6.
Figura 2.6: Exemplo de componentes de uma simulacao em computacao ubıqua
Levando em consideracao que os pontos chave em relacao a um ambiente e a locali-
zacao e o espaco fısico, este pode ser facilmente representado utilizando um modelo em
34
“grade”, uma matriz bidimensional por exemplo. A informacao relevante a determinado
espaco fısico e representada utilizando o conceito de camadas, onde uma camada pode
representar, por exemplo, o nıvel de luminosidade ou a temperatura de um determinado
espaco daquele ambiente (REYNOLDS; CAHILL; SENART, 2006).
Sensores sao elementos que proveem informacoes, capturando-as ou recebendo-as
de algum outro elemento do sistema, as caracterısticas mais comuns aos sensores sao
(CAMPIOLO; CREMER; SOBRAL, 2007):
• Se e ativo ou passivo;
• Se captura dados externa ou internamente;
• Se as suas ocorrencias (ativacoes) sao periodicas ou esporadicas.
Um sensor ativo investiga o ambiente em busca da informacao que ele necessita, por
exemplo pode-se citar o termometro, que “pega” a temperatura do ambiente onde ele esta.
Ja um sensor passivo “recebe” a informacao ao inves de busca-la no ambiente, como um
leitor de codigo de barras, por exemplo.
Na captura externa de dados o sensor “le” ou recebe a informacao de algum outro ele-
mento da simulacao, enquanto que na captura interna a informacao e inerente ao elemento,
sendo portanto “interno” a ele, como por exemplo a sua localizacao no ambiente.
Ocorrencias ou ativacoes sao conceitos ligados muito mais a parte logica da simulacao,
pois e atraves deles que criam-se as listas e filas de eventos. Ocorrencias periodicas sao
“agendadas” no sistema, ocorrem com determinada regularidade e podem ser prevista.
Ocorrencias esporadicas sao normalmente fruto de algum evento ou arbitrariedade, sendo
portanto, virtualmente imprevisıveis (CAMPIOLO; CREMER; SOBRAL, 2007).
Atuadores sao as entidades que“atuam”no sistema, ou seja que modificando variaveis,
alteram ou criam eventos inerentes a simulacao. Compartilham parte das caracterısticas
dos sensores, pois podem agir tanto interna como externamente, periodica ou esporadica-
mente (CAMPIOLO; CREMER; SOBRAL, 2007).
As aplicacoes sao o codigo logico desenvolvido em alguma linguagem de programacao,
o ideal e que se utilize o mesmo codigo para a simulacao e para o sistema real, mas
na grande maioria das vezes isso nao e possıvel devido, principalmente, a limitacao dos
simuladores em si (REYNOLDS; CAHILL; SENART, 2006).
35
2.6.2 Estudos Similares
E possıvel encontrar diversos exemplos como Contri et al. (2008) e Campiolo, Cremer e
Sobral (2007) que exploram a simulacao de ambientes de computacao ubıqua, por exemplo,
para a modelagem de prototipos de simuladores genericos ou entao outros como Huebscher
e McCann (2004) para comprovacao de modelos de aplicacoes e ainda estudos focados no
levantamento de requisitos para o proprio uso de simulacoes em projetos de computacao
Ubıqua como Reynolds, Cahill e Senart (2006).
36
3 Descricao do AmbienteExperimental
O ambiente experimental utilizado se baseia primordialmente em ferramentas libe-
radas como software livre e que sanam as necessidades do trabalho. No processo de
modelagem foi utilizado o plugin UML versao 1.4 da IDE Netbeans versao 6.7.1 para a
criacao dos modelos UML do sistema, e a ferramenta MySQL Workbench versao 5.1.18
para a modelagem do banco de dados. No processo de construcao foi utilizada a linguagem
de programacao Java em sua versao 1.6 e o banco de dados MySQL na versao 5.0.75.
3.1 Tecnologias Envolvidas
3.1.1 Java
A linguagem de programacao Java sera utilizada por suportar o desenvolvimento de
aplicacoes desktop (Aplicacoes que rodem localmente na maquina) e por prover uma forma
simples e flexıvel para o desenvolvimento de sistemas.
Uma das principais caracterısticas do Java e o suporte ao paradigma de programacao
da orientacao a objetos, sendo este imprescindıvel para o desenvolvimento deste trabalho.
3.1.2 MySQL
MySQL e um Sistema Gerenciador de Banco de Dados (SGBD), desenvolvido primei-
ramente pela empresa MySQL AB, sendo que esta foi adiquirida pela Sun Microsystems
e a Sun adiquirida pela Oracle Corporation. O MySQL suporta a Structured Query Lan-
guage (SQL) e se comunica com a linguagem Java atraves de driver desenvolvido pela
propira Sun Microsystems.
A principal caracterıstica do Mysql e a simplicidade na configuracao e utilizacao, o
37
fato de se comunicar com a linguagem Java e de ser suportado pelo framework Hibernate
foram pontos determinantes da escolha deste para ser utilizado nesse trabalho.
3.2 Estrutura Fısica
3.2.1 Configuracoes de Hardware
Somente uma maquina foi utilizada para a implementacao e execucao do sistema
sendo esta um notebook da marca Acer modelo Aspire 5715z contendo um processador
Intel Pentium Dual-Core T270 1.73GHz e 2 Gb de memoria RAM.
3.3 Estrutura Logica
3.3.1 Sistema Operacional
Sera utilizada apenas uma maquina com o sistema operacional GNU/Linux atraves
da distribuicao Ubuntu 9.10 Karmic Koala, com o Kernel versao 2.6.28-15-generic e todas
as devidas atualizacoes instaladas.
3.3.2 Aplicativos
3.3.2.1 Eclipse
Eclipse e um Integrated Development Environment (IDE) liberada como software li-
vre atraves da Eclipse Public License (EPL) criada por uma subsidiaria da IBM, que
pretendia diminuir a incompatibilidade entre os ambientes de desenvolvimento utilizados
na empresa. Em 2001 foi criado um consorcio de empresas chamado Eclipse Consortium
com a intencao de realizar o desenvolvimento da ferramenta em codigo aberto. Em 2004 e
lancada a primeira versao livre e fundada a Eclipse Foundation, quem gerencia o projeto
ate os dias de hoje.
A versao utilizada foi a 3.5 Galileo por ser a ultima versao estavel da ferramenta.
3.3.2.2 MySQL Workbench
MySQL Workbench e uma ferramenta visual de modelagem de banco de dados. De-
senvolvida pela Sun Microsystems, pode ser utilizada para a modelagem, criacao e ma-
38
nutencao de banco de dados MySQL.Neste trabalho ela sera utilizada para a criacao do
Modelo Entidade-Relacionamento (MER) do sistema.
A versao utilizada foi a 5.1.18 da ferramenta.
3.3.2.3 Netbeans
Netbeans e uma IDE produzida pela Sun Microsystems, e liberada como software livre
e gratuıto. Esta possui seu foco na integracao com a plataforma Java (tambem produzida
pela Sun) entretanto tambem suporta programacao em outras linguagens como C, C++,
Python entre outros. Porem sera utilizado apenas o plugin UML, para a geracao dos
diagramas necessarios a especificacao do sistema.
A versao utilizada foi a 6.7.1 do Netbeans e a versao 1.4 do plugin UML.
3.3.3 Bibliotecas e Frameworks
3.3.3.1 DESMO-J
Discrete-Event Simulation and Modelling in Java (DESMO-J) e um framework focado
no desenvolvimento de modelos simulados usando a linguagem de programacao Java e o
paradigma da programacao orientada a objetos. Foi criado e e mantido pelo Departamento
de Ciencia da Computacao da Universidade de Hamburgo na Alemanha, estando liberado
sob a Apache License, portanto e considerado Software Livre.
Foi utilizado este framework por ele abstrair as funcoes basicas necessarias para o de-
senvolvimento da simulacao, deixando o programador livre para a implementacao apenas
das entidades envolvidas e dos seus relacionamentos.
Neste projeto foi utilizada a versao 2.1.4b do DESMO-J por se tratar da ultima versao
estavel do framework.
3.3.3.2 Hibernate
O Hibernate e um framework criado por desenvolvedores Java liderados por Gavin
King, sendo que posteriormente esses desenvolvedores forma contratados pela JBoss Inc,
empresa esta que foi comprada posteriormente pela Red Hat Inc.
O framework e focado na realizacao do ”Mapeamento Objeto-Relacional”, apresen-
tando tambem funcionalidades para abstrair a comunicacao com o banco de dados. Por
39
contar com essas duas caracterısticas, este foi utilizado nesse trabalho. Foi utilizado tam-
bem o modulo Hibernate Annotations, pois esse dispensa o uso de XML na configuracao
do framework.
A versao do framework Hibernate que foi utilizada e a 3.3.2.GA e a versao 3.4.0.GA
do modulo Hibernate Annotations. Por serem as ultimas versoes estaveis de ambos.
40
4 Implementacao
Esta parte do trabalho visa exlorar os detalhes da especificacao e codificacao da si-
mulacao criada de acordo com o proposto nos capitulos anteriores.
A arquitetura e utilizada na implementacao conforme descrito na Figura 4.1. A classe
SimProcessClient representa os Atuadores do sistema, pois esta interage e altera o res-
tante sistema. A camada Ambientes e representada pelas informacoes contıdas na classe
Ambiente e pela classe Modelo da implementacao, pois estas contem informacoes ineren-
tes ao contexto da aplicacao. Ja a classe Sensor representa sozinha a camada Sensores
pois e a unica que faz a leitura de informacoes oriundas de outras classes. A camada de
Aplicacoes e composta por todas as outras classes auxiliares utilizadas no sistema.
Figura 4.1: Representacao da Aquitetura Proposta na Implementacao do Sistema
41
4.1 Especificacao
Em um ambiente de super-mercado onde as pessoas circulam e fazem suas compras,
deseja-se detectar, em tempo real, qual produto determinado cliente retirou de uma prate-
leira. Os propositos dessa necessidade sao diversos e estao fora do escopo desse trabalho.
Tendo em vista a necessidade levantada, defini-se que tres hipoteses serao testadas de
forma a definir a que possui a melhor taxa de acerto.
As hipoteses sao:
• Dispor os sensores apenas nos carrinhos;
• Dispor os sensores apenas nos clientes;
• Dispor os sensores nos clientes e carrinhos;
Cada uma das hipoteses tem suas vantagens e desvantagens o que nao e relevante para
o sistema.
Leva-se em consideracao que o ambiente sabe detectar qual produto foi retirado de
qual prateleira, deixando essa parte fora do escopo desse trabalho.
Ao simulador cabe apenas definir qual foi o cliente que retirou o produto da prateleira.
Entretanto para a realizacao dessa tarefa e necessaria a implementacao de diversas outras
classes auxiliares.
4.2 Codificacao
A implementacao foi realizada possuindo apenas um unico projeto, sendo subdividido
em pacotes e nomeado de MercadoUbiquo.
Foi tambem criado um banco de dados chamado mercadoUbiquo no qual ficara arma-
zenado as informacoes iniciais da simulacao, estas nao sofreram qualquer alteracao durante
a execucao. Toda a estrutura do banco de dados foi gerada automaticamente pelo fra-
mework Hibernate com base nas classes definidas no projeto, sendo que o resultado final
pode ser visto na Figura 4.2.
42
Figura 4.2: Modelo Entidade Relacional do Banco de Dados Utilizado
A logica basica da simulacao esta em movimentar os “X” clientes de forma que estes
vao ate as prateleiras e retiram os produtos, quando um produto e retirado da prateleira
o Sensor entra em acao e “escaneia” um raio de “Y” quadrados tendo como centro o local
onde foi detectado a saıda do produto, o primeiro cliente detectado e considerado como
responsavel pela retirada. Na Figura 4.3 demonstra-se como funciona a deteccao para
um raio de 3 quadros, nesse exemplo ocorre a deteccao errada do cliente que retirou o
produto.
43
Figura 4.3: Deteccao do Sensor com raio de 3 quadros
4.3 Pacote Localization
Um dos requisitos necessarios para o sucesso dessa simulacao e o posicionamento dos
clientes. Para tal, o pacote localization conta com as classe Point e MovePlanner conforme
a figura 4.4.
44
Figura 4.4: Classes do Pacote Localezation
A classe Point e utilizada para representar as unidades de localizacao, levando em
consideracao que se trata um sistema de duas dimensoes, este e o responsavel pelas infor-
macoes referentes as cordenadas (X,Y).
A outra classe pertencente a essa pacote e a classe abstrata MovePlanner esta somente
possui metodos estaticos e visa trabalhar como um tratador de todas as movimentacoes
necessarias aos clientes. Apessar de nao realizar realmente a movimentacao do cliente, esta
classe e a responsavel por calcular o caminho que o cliente devera fazer ate seu destino.
Para tal calculo e utiliza um ”algoritmo de melhor caminho”simples, com base no proximo
passo apenas.
4.4 Pacote Model
O pacote Model do projeto contem as classes utilizadas na criacao dos objetos atua-
dores do sistema simulado, conforme Figura 4.5:
45
Figura 4.5: Classes do Pacote Model
E tambem atraves das classes presentes no pacote Model que o framework Hibernate
faz o mapeamento objeto-relacional do sistema, como dito no capıtulo 3 foi utilizado o
modulo Annotations do Hibernate, que possibilita o mapeamento dos objetos utilizando
apenas anotacoes java, conforme demonstrado em parte da classe Cliente na listagem 4.1:
Listagem 4.1: Classe Cliente. . .
46
@Entity
@Table (name = " C l i e n t e " )
5 p u b l i c c l a s s Cl i en t e {@Id
@GeneratedValue ( s t r a t egy = GenerationType .AUTO)
p r i v a t e i n t id ;
10 p r i v a t e St r ing nome ;
@Transient
p r i v a t e PortaProduto portaProduto ;
15 @ManyToMany
@JoinTable (name = " L i s t a C o m p r a s " , joinColumns = { @JoinColumn (name=" c l i e n t e _ i d " ) } ,
inverseJoinColumns = {@JoinColumn (name=" p r o d u t o _ i d " ) })
@LazyCol lect ion ( LazyCol lect ionOption .FALSE)
p r i v a t e List<TipoProduto> l i s taCompras ;
20 . . .
A classe Cliente possui um atributo do tipo PortaProduto sendo este tipo uma In-
terface, ela e implementada pela classe abstrata PortaProdutoImpl que trata os metodos
comuns a todos os seus herdeiros e e extendida pelas classes Carrinho e Cestinha, sendo
essas as duas opcoes possıveis para o preenchimendo do atributo. A definicao de qual tipo
o cliente usara e feita com base no numero de produtos que ele possui em sua lista de
compras, se este possuir mais cinco produtos em sua lista, este ficara com um carrinho,
se nao, pegara uma cestinha.
Na classe Prateleira existem dois atributos do tipo Point um referencia a posicao real
do objeto e o outro marca o ponto a frente dele, por onde o cliente podera ter acesso a
seus produtos.
4.5 Pacote Persistence
O pacote Persistence e o responsavel por fazer toda a interacao com o banco de dados,
e tambem onde e feita a configuracao e o uso do framework Hibernate.
E composto pela classe HibernateUtils que abstrai a parte de conexao com o banco de
dados, e o Sub-pacote DAO, onde se encontram as classes Data Access Object (DAO) do
sistema, estas sao responsaveis por separar as regras de persistencia de dados das regras
de negocio.
4.6 Pacote Statistics
Ja o pacote Statistics contem a classe DataContainer, que visa armazenar os dados
estatısticos de cada hipotese e a classe StatisticsData que possui um DataContainer para
47
cada uma das hipoteses testadas, e tambem guarda outras informacoes estatısticas do
sistema e que e utilizada para o calculo dos resultados da simulacao.
4.7 Pacote Simulation
Este e o pacote onde toda a operacao da simulacao e realizada, ele possui tres sub-
pacotes: environment, composto pelas classes Ambiente e Modelo, o sub-pacote sensor,
que e composto pela classe Sensor e o pacote actuator, composto pela classe SimProces-
sCliente. A Figura 4.6 demonstra as interacoes entre essas classes.
Figura 4.6: Classes do Pacote Simulation
4.7.1 Environment
No pacote Environment ficam armazenadas as classes Modelo e Ambiente, ambas
responsaveis por trabalharem com informacoes inerentes ao ambiente da simulacao.
A classe Modelo extende a classe Model do framework DESMO-J que e a responsa-
vel pela configuracao e inicializacao da simulacao, possui dois metodos basicos: init e
doInitialSchedules.
O metodo init e utilizado para inicializar os geradores de valores pseudo-aleatorios
48
(tempo de passo e tempo de chegada), que serao utilizados na configuracao dos SimPro-
cessCliente, como distribuicoes uniformes.
Ja o metodo doInitialSchedules carrega do banco de dados, atraves das classes DAO,
toda a listagem e Clientes e Prateleiras, nesse ponto o framework Hibernate busca no
banco e popula a lista de compra de cada cliente e a lista de produtos de cada prateleira.
A lista de prateleiras e utilizada para popular a lista“PontosFixos”da classe abstrata Am-
biente, afim de garantir que os clientes nao atravessem esses pontos ocupados. Finalmente
a lista de clientes e utilizada para a criacao dos SimProcessClient, que sao os atuadores do
sistema, cada instancia recebendo um tempo de passo e um tempo de ativacao conforme
as bases pseudo-aleatorias geradas no metodo init, alem de um objeto do tipo Cliente que
possui as informacoes uteis a camada de aplicacao. Todo o fluxo da classe Modelo no
metodo doInitialSchedules pode ser observado na Listagem 4.2.
Listagem 4.2: Metodo doInitialSchedules da Classe Modelo@Override
p u b l i c v o i d do In i t i a l S ch edu l e s ( ) {d o u b l e aux tempo = 0 ;
ClienteDAOImpl clienteDAO = new ClienteDAOImpl ( ) ;
5 PrateleiraDAOImpl prateleiraDAO = new PrateleiraDAOImpl ( ) ;
p r a t e l e i r a s L i s t a = new Vector<Pra t e l e i r a >() ;
L ist<Pra t e l e i r a > auxPra t e l e i r a s = prateleiraDAO . g e tL i s t ( ) ;
f o r ( P r a t e l e i r a pt : auxPra t e l e i r a s ) {Ambiente . pontosFixos . add ( pt . getPos icao ( ) ) ;
10 i f ( pt . getTipoProduto ( ) . get Id ( ) != 99) {p r a t e l e i r a s L i s t a . add ( pt ) ;
}}List<Cl iente> l sC l i e n t e = clienteDAO . g e tL i s t ( ) ;
15 S t a t i s t i c sDa t a . t o t a l = l sC l i e n t e . s i z e ( ) ;
f o r ( C l i en t e c l I t : l sC l i e n t e ) {SimProcessCl iente c l i e n t e = new SimProcessCl iente ( t h i s , c l I t
. getNome ( ) , t r u e , c l I t , new SimTime( getClienteTempoPasso ( ) ) ) ;
c l i e n t e . a c t i v a t e ( new SimTime( aux tempo ) ) ;
20 aux tempo = aux tempo + getClienteTempoChegada ( ) ;
l i s t a C l i e n t e s . add ( c l i e n t e ) ;
}
}
A classe Ambiente e utilizada para a reprensentacao das informacoes inerentes a ca-
mada de Ambiente proposta nos capitulos anteriores. Esta contem, por exemplo, as
cordenadas X e Y maximas do sistema, os pontos que estao ocupados por prateleiras e
consequentemente nao estao acessıveis aos clientes, os pontos por onde os clientes entram
e saem do sistema e onde eles devem pegar os carrinhos, entre outros.
4.7.2 Sensor
No pacote Sensor encontra-se unicamente a classe Sensor sendo esta a responsavel
por verificar as retiradas de produtos e detectar qual o cliente que a realizou.
49
Quando um produto e retirado de uma prateleira, a instancia de Sensor contida em
Modelo e chamado, este registra a ocorrencia de uma saıda (na classe StatisticsData) e
escaneia uma area de “N” quadros com o centro no ponto onde o produto foi retirado. E
nesse ponto que ocorre a diferenciacao das tres hipoteses levantas anteriormente, como
demonstrado na listagem 4.3.
Listagem 4.3: Diferenciacao das Deteccoes na Classe Sensorp u b l i c b o o l e a n v e r i f i c a rR e t i r a d a ( P r a t e l e i r a pr ,
S imProcessCl iente s imProcessCl i ente , i n t t ipoSensor ) {
Point ptBase = pr . getPontoFrente ( ) ;
5
List<Point> ptL i s t = ptBase . c a l cu l a rAd jac en t e s ( r a i o ) ;
s w i t c h ( t ipoSensor ) {c a s e S t a t i s t i c sDa t a .CLIENTE COM SENSOR: {
10 r e t u r n v e r i f i c a rR e t i r a d aC l i e n t e ( pr , s imProcessCl i ente , p tL i s t ) ;
}c a s e S t a t i s t i c sDa t a .PORTA PRODUTO COM SENSOR: {
r e t u r n ve r i f i c a rRet i r adaPor taProduto ( pr , s imProcessCl i ente , p tL i s t ) ;
}15 c a s e S t a t i s t i c sDa t a .AMBOS COM SENSOR: {
i f ( ! v e r i f i c a rR e t i r a d aC l i e n t e ( pr , s imProcessCl i ente , p tL i s t ) ) {r e t u r n ve r i f i c a rRet i r adaPor taProduto ( pr , s imProcessCl i ente ,
p tL i s t ) ;
}20 r e t u r n t r u e ;
}}r e t u r n f a l s e ;
}
4.7.3 SimProcessCliente
A classe SimProcessCliente extende a classe SimProcess do DESMO-J e representa
a entidade cliente dentro da simulacao, as outras entidades (Prateleira, Produto e Porta-
Produto) nao necessitam ser representadas pois apenas sao afetadas pelas acoes da classe
Cliente e nao realizam acoes sozinhas. Esta possui um metodo lifeCycle que e onde se
desenvolve todo o “ciclo de vida” do cliente dentro do sistema, este comeca com o cliente
entrando no sistema e termina com a saıda do mesmo apos realizar suas compras e se
encaminhar para o ponto de saıda, conforme representado na Listagem 4.4.
Listagem 4.4: Metodo lifeCycle da Classe SimProcessClientep u b l i c v o i d l i f e C y c l e ( ) {
setarPortaProduto ( ) ;
5 i n i c i a r L i s t a P r a t e l e i r a s ( ) ;
rea l izarCompras ( ) ;
sa irDoSistema ( ) ;
10
meuModelo . g e t S t a t sCo l l e c t o r ( ) . s a i uC l i e n t e ( ) ;
50
i f (meuModelo . g e t S t a t sCo l l e c t o r ( ) . getProcessados ( ) == meuModelo
. g e t S t a t sCo l l e c t o r ( ) . g e tTota lC l i en t e s ( ) ) {15 meuModelo . getExperiment ( ) . stop ( ) ;
}}
4.8 Execucao e Saıdas
O sistema e executado pela classe App. Este instancia e interconecta as classes Modelo
e Experiment e entao “repassa o comando da aplicacao” para a classe Experiment do
framework DESMO-J que e responsavel pelas operacoes de controle inerentes ao proprio
framework, bem como a inicializacao da classe Modelo.
A execucao ocorre “N” vezes sendo “N” o resultado da multiplicacao entre o maior
numero de clientes possıveis e o maior valor possıvel para o raio do sensor. Os dados sao
coletados para as tres hipoteses simultaneamente em cada uma das execucoes.
As saıda e montada em um arquivo no formato Comma Separated Values (CSV) e
gerada no mesmo diretorio do sistema. Para cada uma das execucoes e registrado no CSV
as seguintes informacoes:
• Tipo do Teste (Hipotese);
• Numero de Clientes;
• Raio do sensor;
• Numero de retiradas;
• Acertos;
• Erros;
• Taxa de Acerto.
51
5 Resultados
Com o objetivo de validar a simulacao desenvolvida, foram realizados testes alterando
a principais variaveis do sistema. Foram escolhidas para o teste a variavel Quantidade de
Clientes que se refere a quantidade de clientes que participam da simulacao e a variavel
Raio que se refere a area de escaneamento do sensor. Os dados sao capturados para as
tres hipoteses levantadas anteriormente.
Atraves das variacoes propostas, e possıvel tracar o comportamento da simulacao. Os
dados colhidos em formato CSV foram tabulados e a partir destes foram analisados.
A variacao escolhida foi de 1 ate 50 para o numero de clientes e de 0 a 10 para o raio
do sensor, sendo portanto realizado 550 testes para cada uma das hipoteses e totalizando
1650 testes para todo o sistema. Com essa amplitude, a quantidade de informacao colhida
e suficiente para a realizacao de inumeraveis analises.
Pode-se analisar por exemplo, que para 35 clientes somente nos testes com raio igual
ou maior que 7, utilizar os sensores apenas no clientes ou em ambos, clientes e porta
produto, produz resultados diferentes, conforme pode ser analisado na figura 5.1.
52
Figura 5.1: Taxa de Acerto Para 35 Clientes
A diferenca detectada e apenas nas casas decimais, e esta tendencia se mantem em
testes com o numero de clientes superior ou igual a 35 e com raio superior ou igual a
7, entretanto a maior diferenca detectada e justamente nos testes com 35 clientes e raio
entre 7 e 10, sendo ela de 0,44%. Na figura 5.2 tambem e possıvel verificar a diferenca
entre essas duas hipoteses para uma amostra de 50 clientes.
53
Figura 5.2: Taxa de Acerto Para 10 de Raio
Foi possıvel tambem avaliar que utilizando o sensor somente no porta produto, a
taxa de acerto sempre e igual ou inferior as outras duas hipoteses,a figura 5.2 para uma
quantidade variavel de clientes e um valor fixo de raio 10, e a figura 5.3 demonstra essa
tendencia para uma amostra de fixa 50 clientes e um raio variavel.
54
Figura 5.3: Taxa de Acerto Para 50 Clientes
Para o teste com 50 clientes, a comparacao entre a taxa de acerto das hipoteses
varia conforme o grafico 5.4, sendo no maximo 6,62% entre “Ambos” e “Porta Produto” e
tambem entre “Cliente” e “Porta Produto” e no mınimo 0% em diversos momentos. Pode-
se visualizar tambem que a diferenca entre “Ambos” e “Cliente” manten-se em 0% ate o
teste com raio 6 e a partir do teste com raio 7 esta se mantem em 0,33%.
55
Figura 5.4: Diferenca Entre a Taxa de Acerto das Hipoteses Para 50 Clientes
56
6 Consideracoes Finais eTrabalhos Futuros
6.1 Consideracoes Finais
Tendo em vista a multi-disciplinariedade da computacao ubıqua, desenvolver sistemas
voltados a essa area, pode ser uma pratica relativamente complexa. Como se trata tambem
de uma area nova e pouco explorada os metodos e tecnicas relevantes durante o projeto
de uma solucao nao estao claramente explorados.
Este trabalho utilizou uma simulacao para testar tres possiveis hipoteses afim de
determinar a diferenca entre taxas de acerto de cada uma delas. Para que, dessa forma,
pudesse consider o uso de simulacoes como uma ferramenta util no projeto de sistemas e
ambientes voltados a computacao ubıqua.
Os resultados obtidos comprovam a viabilidade de utilizacao simulacoes em projetos
de computacao ubıqua, tendo em vista que foi possıvel determinar a diferenca entre as
hipoteses, esses dados poderiam ser utilizados para auxiliar a tomada de decisao de um
projetista sobre qual dos metodos utilizar.
6.2 Trabalhos Futuros
Como trabalho futuro propoe-se a re-execucao da simulacao utilizando dados nao-
aleatorios. Sendo esses dados coletados atraves de pesquisas e metodos estatısticos, a
veracidade dos resultados da simulacao seria maior.
Propoe-se tambem o desenvolvimento de um simulador generico para sistemas de
computacao ubıqua, onde a construcao do ambiente fosse realizada de forma grafica e a
logica necessaria para as entidades da simulacao fosse programada de uma forma simples
e natural.
57
Referencias Bibliograficas
AHMAD, A. Wireless and mobile data networks. New Jersey: Wiley-Interscience, 2005.
ANAGNOSTOPOULOS, C.; TSOUNIS, A.; HADJIEFTHYMIADES, S. Contextawareness in mobile computing environments. Wireless Personal CommunicationsJournal, v. 42, n. 3, Ago. 2007.
ARAUJO, R. B. Computacao ubıqua: princıpios, tecnologias e desafios. XXI SimposioBrasileiro de Redes de Computadores, Natal, 2003.
AUGUSTO, J. C.; MCCULLAGH, P. Ambient intelligence: concepts and applications.Computer Science and Information Systems Journal, ComSIS Consortium, v. 4, n. 1,Jun. 2007.
BANKS, J. (Ed.). Handbook of simulation - principles, metholdoly, advances, applicationsand pratice. 4. ed. New Jersey: Wiley-Interscience, 1998.
BROCH, J. et al. A performance comparison of multi-hop wireless ad hoc networkrouting protocols. In: Proceedings of the 4th annual ACM/IEEE international conferenceon Mobile computing and networking. New York: ACM, 1998. p. 85–97.
CAMPIOLO, R.; CREMER, V.; SOBRAL, J. B. M. On modeling for pervasivecomputing environments. In: . New York: ACM, 2007. p. 240–243.
CONTRI, E. et al. Modelando um ambiente ubıquo atraves de simulacao. 7thInternational Information and Telecommunication Technologies Symposium, Foz doIguacu, 2008.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems: ConceptsAnd Design. 4. ed. New York: Addison-Wesley, 2005.
EMILIANI, P. L.; STEPHANIDIS, C. Universal access to ambient intelligenceenvironments: opportunities and challenges for people with disabilities. Fev. 2005.Disponıvel em: <www.research.ibm.com/journal/sj/443/emiliani.pdf>. Acesso em:21/03/2009.
GIL, A. C. Como elaborar projetos de pesquisa. 4. ed. Sao Paulo: Atlas, 2002.
HANSMANN, U.; NICKLOUS, M. S.; STOBER, T. Pervasive computing handbook. NewYork: Springer-Verlag, 2001.
HUEBSCHER, M. C.; MCCANN, J. A. Simulation model for self-adaptive applicationsin pervasive computing. Proceedings of the Database and Expert Systems Applications,2004.
58
JANSEN, E. et al. A programming model for pervasive spaces. International Conferenceon Service-Oriented Computing, Amsterdam, 2005.
JOHNSON, D. B. Routing in ad hoc networks of mobile hosts. In: In Proceedings of theIEEE Workshop on Mobile Computing Systems and Applications. Washington: IEEEComputer Society, 1994. p. 158–163.
LAKATOS, E. M.; MARCONI, M. de A. Metodologia Cientıfica. 3. ed. Sao Paulo: Atlas,2000.
MUHLHAUSER, M.; GUREVYCH, I. Handbook of research on ubiquitous computingtechnology for real time enterprises. Hershey: Information Science Reference, 2008.
NICOPOLITIDIS, P. et al. Wireless Networks. New Jersey: Wiley-Interscience, 2003.
PRITSKER, A. A. B. Principles of simulation modeling. In: BANKS, J. (Ed.). Handbookof simulation - principles, metholdoly, advances, applications and pratice. New York:Wiley-Interscience, 1998.
REMAGNINO, P.; FORESTI, G. L.; ELLIS, T. Ambient intelligence a novel approach.4. ed. Berlin: Springer, 2005.
REYNOLDS, V.; CAHILL, V.; SENART, A. Requirements for an ubiquitous computingsimulation and emulation environment. In: InterSense ’06: Proceedings of the firstinternational conference on Integrated internet ad hoc and sensor networks. New York:ACM, 2006. p. 1.
SANCHES, C. A. Projetando redes wlan: conceitos e praticas. 2. ed. Sao Paulo: Erica,2007.
TANENBAUM, A. S.; STEEN, M. V. Sistemas distribuıdos: princıpios e paradigmas.Traducao de: Arlete Simille Marques. Revisao Tecnica de: Wagner Zucchi. 2. ed. SaoPaulo: Pearson Prentice Hall, 2007.
WEISER, M. The Computer of The Twenty-One Century. Fev. 1991. Disponıvel em:<http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html>. Acesso em: 17/03/2009.
WIDE PROJECT SCHOOL OF INTERNET. WAN,MAN,LAN,PAN. 2009. Disponıvelem: <http://www.soi.wide.ad.jp/class/20070044/slides/04/index 24.html>. Acesso em:25/04/2009.