1. CENTRO DE ENSINO SUPERIOR DE FOZ DO IGUACU
¸
ˆ ¸˜
CURSO DE CIENCIA DA COMPUTACAO
TRABALHO DE CURSO
MODELAGEM DE AMBIENTES DE COMPUTACAO UB´
¸˜ IQUA
¸˜
UTILIZANDO SIMULACAO
JURMIR CANAL NETO
FOZ DO IGUACU - PR
¸
2009

2. JURMIR CANAL NETO
MODELAGEM DE AMBIENTES DE COMPUTACAO UB´
¸˜ IQUA
¸˜
UTILIZANDO SIMULACAO
Trabalho de Conclus˜o de Curso submetido
a
ao Centro de Ensino Superior de Foz do
Igua¸u como parte dos requisitos para a ob-
c
ten¸ao do grau de bacharel em Ciˆncia da
c˜ e
Computa¸˜o.
ca
Orientador: Gildomiro Bairros
FOZ DO IGUACU - PR
¸
2009

3. Resumo
Vista como a “Terceira-onda” da computa¸˜o, a Computa¸˜o Ub´
ca ca ıqua visa criar sis-
temas e ambientes que sejam capazes de auxiliar os seus usu´rios a realizar suas tarefas
a
de uma forma n˜o intrusiva e respeitando as caracter´
a ısticas e costumes de cada um. Si-
mular os sistemas de tais ambientes ´ uma parte imprescind´ do projeto, pois, al´m de
e ıvel e
simplificar a complexidade da visualiza¸˜o do sistema, esta ainda pode adiantar diversos
ca
problemas que seriam encontrados apenas na fase final, onde corre¸oes seriam caras e
c˜
trabalhosas ou por vezes at´ mesmo imposs´
e ıveis.

4. Abstract
Seen as the third wave of computing, Ubiquitous Computing aims to create systems
and environments that are able to help its users to perform their tasks in a non-intrusive
way, respecting the characteristics and customs of each one. Simulate the systems of such
environments is a essential part of the project, because it can simplify the complexity of
the system’s visualization, this can predict various issues that would be found only in the
final stages, where corrections would be costly and difficult or sometimes even impossible.

5. 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

6. WPAN Wireless Personal Area Network
WWAN Wireless Wide Area Network

7. Lista de Figuras
2.1 Rela¸ao entre AmI e outras ´reas da computa¸ao . . . . . . . . . . . . . . 20
c˜ a c˜
2.2 Classifica¸ao das tecnologias de redes sem fio . . . . . . . . . . . . . . . . . 23
c˜
2.3 Rela¸ao entre Computa¸˜o Ub´
c˜ ca ıqua, Pervasiva e M´vel . . . . . . . . . . . . 26
o
2.4 Demonstra¸ao do contexto e suas entidades . . . . . . . . . . . . . . . . . . 27
c˜
2.5 Ciclo de vida de um estudo simulado . . . . . . . . . . . . . . . . . . . . . 32
2.6 Exemplo de componentes de uma simula¸ao em computa¸ao ub´
c˜ c˜ ıqua . . . . 33
4.1 Representa¸˜o da Aquitetura Proposta na Implementa¸ao do Sistema . . . 40
ca c˜
4.2 Modelo Entidade Relacional do Banco de Dados Utilizado . . . . . . . . . 42
4.3 Detec¸ao do Sensor com raio de 3 quadros . . . . . . . . . . . . . . . . . . 43
c˜
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 Diferen¸a Entre a Taxa de Acerto das Hip´teses Para 50 Clientes . . . . . 55
c o

8. Lista de Listagens
4.1 Classe Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 M´todo doInitialSchedules da Classe Modelo . . . . . . . . . . . . . . . . . 48
e
4.3 Diferencia¸ao das Detec¸oes na Classe Sensor
c˜ c˜ . . . . . . . . . . . . . . . . 49
4.4 M´todo lifeCycle da Classe SimProcessCliente . . . . . . . . . . . . . . . . 49
e

9. Sum´rio
a
1 Introdu¸˜o
ca 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 Te´rico
o 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 Computa¸ao Distribu´
c˜ ıdos . . . . . . . . . . . 16
2.1.3.2 Sistemas de Informa¸˜o Distribu´
ca ı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 N˜o-centralizadas ou Descentralizadas . . . . . . . . . . . 18
a
2.1.4.3 H´
ıbridas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Ambientes Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Interdisciplinaridade . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

10. 2.3 Computa¸ao M´vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
c˜ o
2.3.1 Redes de Comunica¸˜o Sem Fio . . . . . . . . . . . . . . . . . . . . 22
ca
2.3.2 Limita¸˜es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
co
2.3.3 Redes Ad Hoc M´veis
o . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Computa¸ao Ub´
c˜ ıqua ou Pervasiva . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1 Princ´
ıpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.2 Consciˆncia de Contexto . . . . . . . . . . . . . . . . . . . . . . . . 27
e
2.4.3 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.4 Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Modelagem e Simula¸ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
c˜
2.5.1 Caracter´
ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.3 Passos de Um Estudo Simulado . . . . . . . . . . . . . . . . . . . . 31
2.6 Utiliza¸˜o de Simula¸˜o na Computa¸˜o Ub´
ca ca ca ıqua . . . . . . . . . . . . . . . 32
2.6.1 Componentes de Uma Simula¸˜o de Computa¸ao Ub´
ca c˜ ıqua . . . . . . 33
2.6.2 Estudos Similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Descri¸˜o do Ambiente Experimental
ca 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 Configura¸oes de Hardware
c˜ . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Estrutura L´gica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
o
3.3.1 Sistema Operacional . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Aplicativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

11. 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 Implementa¸˜o
ca 40
4.1 Especifica¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
ca
4.2 Codifica¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
ca
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 Execu¸ao e Sa´
c˜ ıdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Resultados 51
6 Considera¸˜es Finais e Trabalhos Futuros
co 56
6.1 Considera¸˜es Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
co
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Referˆncias Bibliogr´ficas
e a 57

12. 11
1 Introdu¸˜o
ca
Integrar a computa¸ao aos atos do dia-a-dia sem alterar h´bitos e costumes, levando
c˜ a
em considera¸ao a pessoalidade de cada um, ´ o objetivo da Computa¸ao Ub´
c˜ e c˜ ıqua. Weiser
(1991), criador do termo “Computa¸˜o Ub´
ca ıqua” (Ubiquitous Computing), prega que a
tecnologia deve fazer parte da vida das pessoas de uma forma n˜o intrusiva, ou seja, o
a
usu´rio n˜o deve adequar seus h´bitos a computa¸ao, mas sim, a computa¸ao deve estar
a a a ` c˜ c˜
preparada para moldar-se as necessidades de cada um dos usu´rios. Neste contexto, ambi-
a
entes inteligentes, saturados de computadores e preparados para lidar com a computa¸˜o
ca
ub´
ıqua, tanto fornecem informa¸˜es e servi¸os ao usu´rio, quanto coletam informa¸oes
co c a c˜
dele e reagem a suas a¸oes. Projetar esses ambientes de forma que seus servi¸os estejam
c˜ c
otimizados ´ imprescind´ tanto para o bom aproveitamento das solu¸˜es quanto para
e ıvel co
evitar a frustra¸˜o do usu´rio.
ca a
A computa¸ao ub´
c˜ ıqua ´ considerada a “terceira-onda” da computa¸ao (JANSEN et
e c˜
al., 2005), sendo assim ´ um desafio para quase todas as suas ´reas. Sistemas distribu´
e a ıdos
e computa¸ao m´vel s˜o as principais afetadas, outro grande desafio ´ o desenvolvimento
c˜ o a e
de aplica¸oes para esse tipo de ambiente. Entretanto quest˜es como: redes sem fio, redes
c˜ o
de alta disponibilidade e seguran¸a da informa¸˜o s˜o tamb´m muito importantes.
c ca a e
De acordo com este contexto, esse trabalho implementa a simula¸˜o de um ambiente
ca
voltado ` computa¸ao ub´
a c˜ ıqua. Essa simula¸ao se faz necess´ria para a valida¸ao de um de-
c˜ a c˜
terminado ambiente, portanto como verificar a validade do uso de simula¸oes em projetos
c˜
de ambientes inteligentes voltados a computa¸ao ub´
c˜ ıqua?
Como poss´ solu¸ao prop˜e-se a cria¸ao de um modelo na forma de matriz bidimen-
ıvel c˜ o c˜
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
simula¸ao utilizando a linguagem de programa¸˜o Java. Coletar os dados provenientes da
c˜ ca
execu¸˜o e ent˜o verificar a eficiˆncia da simula¸˜o no referido ambiente.
ca a e ca
O ambiente simulado proposto ´ um ambiente de super-mercado onde as pessoas cir-
e

13. 12
culam e fazem suas compras, deseja-se detectar qual produto determinado cliente retirou
de uma prateleira. A simula¸ao ´ utilizada para a verifica¸ao de cada retirada de acordo
c˜ e c˜
com trˆs hip´teses de disposi¸ao dos sensores: afixados nos clientes, nos porta-produto
e o c˜
(carrinho ou cestinha) ou em ambos.
1.1 Objetivos
1.1.1 Objetivo Geral
Desenvolver um simulador para avaliar a possibilidade de uso de simula¸˜es em pro-
co
jetos de computa¸˜o ub´
ca ıqua.
1.1.2 Objetivos Espec´
ıficos
• Apresentar conceitos de Sistemas Distribu´
ıdos, Computa¸˜o M´vel, Computa¸ao
ca o c˜
Ub´
ıqua, Ambientes Inteligentes e Simula¸ao;
c˜
• Modelar um ambiente voltado ` Computa¸˜o Ub´
a ca ıqua;
• Elaborar um prot´tipo simulado para a avalia¸˜o do ambiente;
o ca
• Implementar o prot´tipo simulado usando Java;
o
• Realizar a simula¸˜o do ambiente;
ca
• Avaliar os resultados da simula¸ao.
c˜
1.2 Justificativa
Com o avan¸o das tecnologias de comunica¸ao e a miniaturiza¸˜o dos componentes, a
c c˜ ca
humanidade se torna a cada dia mais imersa em um mundo de computadores min´sculos
u
e onipresentes. Neste contexto, a cria¸ao de ambientes inteligentes capazes de fornecerem
c˜
servi¸os e informa¸˜es atrav´s de tais equipamentos ´ importante e cada vez mais comum.
c co e e
A capacidade de prever o comportamento de tal ambiente antes de sua cria¸ao ´ funda-
c˜ e
mental para evitar a frustra¸˜o na utiliza¸˜o dos servi¸os e tamb´m os custos adicionais
ca ca c e
de corre¸ao do projeto fracassado.
c˜

14. 13
Este projeto justifica-se por desenvolver uma forma de testar a validade do uso de
simula¸oes em projetos de ambientes de computa¸ao ub´
c˜ c˜ ıqua antes de sua implanta¸ao,
c˜
evitando assim os problemas j´ relacionados.
a
Em se tratando de uma area de estudo relativamente nova, este trabalho se prop˜e a
´ o
explorar as caracter´
ısticas b´sicas de um ambiente inteligente em um cen´rio de compu-
a a
ta¸˜o ub´
ca ıqua, auxiliando na obten¸ao de informa¸˜es pela comunidade.
c˜ co
1.3 Metodologia
Trata-se de uma pesquisa aplicada, pois caracteriza-se por seu interesse pr´tico, isto ´,
a e
os resultados devem ser aplicados ou utilizados, imediatamente, na solu¸˜o de problemas
ca
que ocorrem na realidade (LAKATOS; MARCONI, 2000).
Esta pesquisa classifica-se como pesquisa explorat´ria, pois possui o objetivo de pro-
o
porcionar maior familiaridade com o problema, com vistas de torn´-lo mais expl´
a ıcito ou a
construir hip´teses. Este tipo de pesquisa tˆm como objetivo principal o aprimoramento
o e
de id´ias ou a descoberta de intui¸oes (GIL, 2002).
e c˜
Quanto aos procedimentos delimita-se como um estudo de caso, consistindo no es-
tudo profundo de poucos elementos, afim de descrever a situa¸ao do contexto e formular
c˜
hip´teses ou teorias sobre a resolu¸ao do problema (GIL, 2002).
o c˜
Quanto as t´cnicas e procedimentos de investiga¸ao utilizada classifica-se como pes-
` e c˜
quisa indireta, ou bibliogr´fica, j´ que utiliza como base material j´ elaborado (GIL,
a a a
2002), buscando embasamento em livros, artigos cient´
ıficos, publica¸˜es peri´dicas e sites
co o
da internet.

15. 14
2 Referencial Te´rico
o
2.1 Sistemas Distribu´
ıdos
Segundo Tanenbaum e Steen (2007) sistemas distribu´
ıdos s˜o uma cole¸ao de com-
a c˜
putadores que se apresenta ao usu´rio como apenas um sistema computacional. Ainda
a
segundo eles essa defini¸˜o abrange os dois aspectos mais importantes dos sistemas com-
ca
putacionais distribu´
ıdos, o hardware que ´ autˆnomo e o software que para a vis˜o do
e o a
cliente, roda em um unico computador.
´
J´ Coulouris, Dollimore e Kindberg (2005) definem um sistema distribu´ como sendo
a ıdo
um sistema no qual os computadores de uma rede se comunicam e coordenam suas ati-
vidades apenas pela troca de mensagens. Essa defini¸ao engloba as caracter´
c˜ ısticas de:
concorrˆncia entre componentes, ausˆncia de clock global e falhas independentes de com-
e e
ponentes.
2.1.1 Propriedades
Para Coulouris, Dollimore e Kindberg (2005) as principais propriedades de um sistema
distribu´
ıdos s˜o:
a
• Concorrˆncia: Em uma rede de computadores os programas devem ser executados
e
de forma concorrente. Dois processos podem realizar seus trabalhos em m´quinas
a
separadas compartilhando recursos quando necess´rio;
a
• Ausˆncia de Clock Global: Quando programas precisam cooperar eles coorde-
e
nam suas a¸oes apenas por troca de mensagens. Esta coordena¸˜o depende da id´ia
c˜ ca e
distribu´ do tempo em que a a¸ao deve ocorrer;
ıda c˜
• Falhas Independentes: Todo sistema computacional pode falhar e ´ responsa-
e
bilidade dos engenheiros do sistema prever essa falha e suas conseq¨ˆncias. Um
ue

16. 15
sistema distribu´ falha de forma diferente dos convencionais, uma falha provoca o
ıdo
isolamento do seu causador, sem provocar danos ao resto do sistema.
Al´m destas Tanenbaum e Steen (2007) ainda citam a forma de o usu´rio enxergar
e a
o sistema como sendo unico, n˜o percebendo que os recursos utilizados podem estar es-
´ a
palhados em v´rias m´quinas diferentes, como sendo uma das principais propriedades de
a a
um sistema distribu´
ıdo.
2.1.2 Caracter´
ısticas
De acordo com Tanenbaum e Steen (2007) e Coulouris, Dollimore e Kindberg (2005)
existem v´rias caracter´
a ısticas importantes inerentes aos sistemas distribu´
ıdos, entre elas
cita-se:
• Abertura: Deve ser poss´ a reimplementa¸ao de fun¸˜es do sistema sem que as j´
ıvel c˜ co a
existentes sejam afetadas. Novos recursos ou modifica¸˜es em recursos j´ existentes
co a
devem aderir ao sistema sem atrapalhar a parte que j´ est´ em funcionamento;
a a
• Confiabilidade: Um sistema distribu´ deve ser mais confi´vel que um sistema
ıdo a
convencional. Se uma m´quina falhar outra assumir´ seu lugar com o m´
a a ınimo de
preju´ poss´
ızo ıvel;
• Escalabilidade: Um sistema deve ser capaz de suportar o aumento no n´mero de
u
recursos mantendo um desempenho satisfat´rio. Se um sistema for projetado para
o
suportar X m´quinas ao ser adicionado a ele mais Y m´quinas ele deve aumentar o
a a
seu desempenho de forma proporcional, apresentando o m´
ınimo de perca poss´
ıvel;
• Flexibilidade: Deve ser poss´ adicionar novos recursos ao sistema sem causar
ıvel
problemas a parte j´ existente. A adi¸ao de novas m´quinas por exemplo deve ser
a c˜ a
absorvida pelo sistema sem que ele necessite de grandes modifica¸˜es;
co
• Transparˆncia: Os usu´rios n˜o devem perceber que o sistema ´ distribu´
e a a e ıdo. Ao
acessar o sistema ele dever´ ter a impress˜o de que todo ele est´ em uma unica
a a a ´
m´quina;
a
• Heterogeneidade: Um sistema distribu´ pode apresentar diferentes tipos de
ıdo
hardware, redes de comunica¸ao, equipamentos de redes, linguagens de programa¸ao
c˜ c˜
entre outros;

17. 16
• Performance: Rodar uma aplica¸ao em um sistema distribu´ deve apresentar,
c˜ ıdo
no m´
ınimo, a mesma performance que ao rod´-la em um sistema convencional;
a
• Seguran¸a: Boa parte das informa¸oes que transitam em um sistema distribu´
c c˜ ıdo
possui grande valor aos seus usu´rios, portanto deve-se garantir a confidencialidade,
a
a integridade e a disponibilidade de tais dados;
• Tratamento de Falhas: Falhas ocorrem em todos os sistemas computacionais, em
um sistema distribu´ ela deve ser detectada, mascarada ou escondida do usu´rio,
ıdo a
de forma que ele n˜o perceba a ocorrˆncia e ainda, se poss´
a e ıvel, realizar a recupera¸ao
c˜
do sistema para o estado anterior a falha.
2.1.3 Tipos de Sistemas Distribu´
ıdos
Existem basicamente trˆs tipos de sistemas distribu´
e ıdos distintos: os Sistemas de Com-
puta¸˜o Distribu´
ca ıdos, os Sistemas de Informa¸˜o Distribu´
ca ıdos e os Sistemas Distribu´
ıdos
Pervasivos (TANENBAUM; STEEN, 2007).
2.1.3.1 Sistemas de Computa¸˜o Distribu´
ca ıdos
Esta ´ um das principais divis˜es dos sistemas distribu´
e o ıdos pois ´ a classe utilizada
e
nas tarefas de computa¸ao de grande desempenho. Nesse modelo o intuito ´ de se dividir
c˜ e
o trabalho (processamento) em pequenas partes e delega-las aos n´s componentes para
o
que estas sejam processadas, acelerando o trabalho de processamento (TANENBAUM;
STEEN, 2007). Este modelo ainda pode ser subdividido em:
• Sistema de Computa¸˜o em Cluster : Onde o hardware e software (sistema
ca
operacional) de todas as m´quinas componentes do sistema s˜o iguais, e estes est˜o
a a a
ligados a mesma rede;
• Sistema de Computa¸˜o em Grade: Neste modelo n˜o se adota qualquer pre-
ca a
missa quanto a hardware ou mesmo software, podendo variar em cada uma das
m´quinas. Tamb´m n˜o ´ nescess´rio que todas as m´quinas estejam na mesma
a e a e a a
rede.

18. 17
2.1.3.2 Sistemas de Informa¸˜o Distribu´
ca ıdos
a co ´
Neste modelo o foco est´ em distribuir as solu¸˜es de software. E normalmente en-
contrado em empresas que tiveram problemas de integra¸˜o ou interoperabilidade en-
ca
tre seus sistemas, necessitando assim a distribui¸˜o dos mesmos. Possuem dois tipos:
ca
(TANENBAUM; STEEN, 2007)
• Sistemas de Processamento de Transa¸˜es: Este sistema ´ primordialmente
co e
utilizado em bancos de dados e outros sistemas onde ´ necess´rio garantir que uma
e a
opera¸˜o ser´ realizada com sucesso, apresenta controle de suas atividades de forma
ca a
a garantir a atomicidade, consistˆncia, isolamento e durabilidade de uma opera¸˜o.
e ca
• Sistemas de Integra¸˜o de Aplica¸˜es Empresariais: A comunica¸˜o direta
ca co ca
entre aplica¸˜es ´ o problema resolvido por esse tipo de sistema, onde cria-se inter-
co e
mediadores (Middlewares) para realizar a integra¸˜o entre sistemas diferentes sem
ca
necessitar a reimplementa¸˜o das aplica¸oes j´ existentes. Remote Procedure Call
ca c˜ a
(RPC) e Remote Method Invocation (RMI) s˜o exemplos de middlewares utilizados
a
nesse sistema.
2.1.3.3 Sistemas Distribu´
ıdos Pervasivos
Diferentemente dos sistemas anteriores, onde a estabilidade ´ imprescind´
e ıvel, nos sis-
temas distribu´
ıdos pervasivos ocorre justamente o contr´rio, sendo a instabilidade um
a
comportamento esperado. Principalmente devido a sua utiliza¸˜o ser feita por dispositi-
ca
vos m´veis ou embutidos, sua comunica¸ao ´ efetuada primordialmente atrav´s de redes
o c˜ e e
sem-fio (na maioria das vezes inst´veis) usando composi¸oes Ad Hoc, o que causa a des-
a c˜
centraliza¸˜o e a impossibilidade de se manter um modelo de topologia por muito tempo
ca
o que contribui ainda mais para o cen´rio de instabilidade. Neste sistema os dispositivos
a
s˜o caracterizados por seu pequeno tamanho, pela alimenta¸˜o por baterias, mobilidade
a ca
e hardware de conex˜o sem fio (TANENBAUM; STEEN, 2007).
a
2.1.4 Arquiteturas
Um modelo arquitetural define a forma com a qual um componente do sistema interage
com outro componente e como essa intera¸˜o ´ mapeada em rela¸˜o a rede de computado-
ca e ca
res (COULOURIS; DOLLIMORE; KINDBERG, 2005). Para Tanenbaum e Steen (2007)

19. 18
existem trˆs organiza¸˜es b´sicas para as arquiteturas: centralizadas, descentralizadas e
e co a
h´
ıbridas.
2.1.4.1 Centralizadas
Na arquitetura centralizada os servi¸os ficam centralizados em um servidor de onde os
c
clientes requisitam dados e aguardam resposta, o servidor por sua vez, aceita as requisi¸oes
c˜
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 N˜o-centralizadas ou Descentralizadas
a
As arquiteturas n˜o-centralizadas ou descentralizadas s˜o divididas em dois tipos, as
a a
de distribui¸ao vertical onde os elementos l´gicos que s˜o diferentes ficam em m´quinas
c˜ o a a
diferentes. E as de distribui¸ao horizontal, tamb´m conhecida como Peer-to-Peer (P2P),
c˜ e
onde cada m´quina se subdivide em partes l´gicas que se equivalem, mantendo assim uma
a o
rela¸ao de equil´
c˜ ıbrio entre as por¸˜es de dados manipuladas.
co
2.1.4.3 H´
ıbridas
Muitos sistemas distribu´
ıdos combinam aspectos arquitetˆnicos dos modelos anteri-
o
ormente citados, sendo assim considerada uma distribui¸ao “h´
c˜ ıbrida”. Um exemplo dessa
distribui¸ao s˜o os servidores de borda, que faz a liga¸ao entre uma rede distribu´ e uma
c˜ a c˜ ıda
rede cliente-servidor, pode-se citar os provedores de acesso a internet como um servidor
de borda, j´ que o usu´rio se conecta a ele (cliente-servidor) para efetuar acesso a internet
a a
(descentralizada) por exemplo.
2.2 Ambientes Inteligentes
Um dos principais desafios do desenvolvimento de sistemas para a computa¸ao ub´
c˜ ıqua
´ a cria¸ao de Ambientes Inteligentes (AmI) capazes de suportar o tipo de intera¸ao
e c˜ c˜
necess´ria. Remagnino, Foresti e Ellis (2005) caracterizam AmI como um paradigma que
a
oferece suporte ` nova gera¸ao de sistemas inteligentes e introduz novos significados a
a c˜ `
comunica¸ao entre homem, m´quinas e o ambiente. Computadores “desaparecem” em
c˜ a

20. 19
segundo plano enquanto os usu´rios transitam em primeiro plano no total controle do
a
ambiente em sua volta.
Para Emiliani e Stephanidis (2005) o conceito de AmI provˆ a vis˜o de uma socie-
e a
dade da informa¸˜o onde a ˆnfase est´ na simplicidade de uso, suporte mais eficiente aos
ca e a
servi¸os, maior poder ao usu´rio e suporte as intera¸oes humanas. As pessoas se cercar˜o
c a c˜ a
de interfaces inteligentes e intuitivas que estar˜o inseridas em todos os objetos e em um
a
ambiente que seja capaz de reconhecer e responder a presen¸a de diferentes indiv´
` c ıduos de
uma maneira integrada, n˜o obstrutiva e praticamente invis´
a ıvel.
2.2.1 Interdisciplinaridade
Segundo Augusto e McCullagh (2007) a utiliza¸˜o de AmI cresce r´pido como um
ca a
t´pico de interesse multi-disciplinar que permite a muitas areas de pesquisa ter uma
o ´
influˆncia significativa e ben´fica na nossa sociedade, conforme a Figura 2.1.
e e

21. 20
Figura 2.1: Rela¸ao entre AmI e outras areas da computa¸˜o
c˜ ´ ca
Augusto e McCullagh (2007, Adaptada)
Redes, Sensores, Interfaces Homem-M´quina, Computa¸ao Ub´
a c˜ ıqua e Inteligˆncia Ar-
e
tificial, todas essas areas s˜o relevantes e interrelacionadas, mas nenhuma delas cobre
´ a
totalmente o escopo de AmI. Os AmI unem os recursos dessas tecnologias para prover
servi¸os flex´
c ıveis e inteligentes aos usu´rios agindo eu seu interior.
a
Ainda segundo Augusto e McCullagh (2007) a id´ia b´sica de um Ambiente inteligente
e a
´ que enriquecendo um ambiente com tecnologias (Redes, Sensores, Interfaces Homem-
e
M´quina e etc) um sistema pode ser constru´ para tomar decis˜es que beneficiem o seu
a ıdo o
usu´rio, baseado em informa¸oes de tempo real e/ou hist´ricas acumuladas.
a c˜ o

22. 21
2.2.2 Requisitos
Segundo Emiliani e Stephanidis (2005) ainda n˜o est´ claro como um AmI deve ser
a a
concebido e implementado, entretanto ´ poss´ delimitar alguns pontos importantes que
e ıvel
s˜o comuns nesse tipo de projeto:
a
• Em um AmI os servi¸os s˜o dinˆmicos e podem se reconfigurar e recombinar em
c a a
tempo de execu¸ao para acomodar as necessidades de diferentes usu´rios, em dife-
c˜ a
rentes contextos e ambientes;
• N˜o h´ diferen¸a entre comunica¸ao inter-pessoal e acesso a informa¸ao. Compo-
a a c c˜ c˜
nentes diferentes, usando variados tipos de m´
ıdias (v´
ıdeo, som, texto, figuras e etc)
est˜o interconectados para permitir a livre combina¸ao de suas fun¸˜es;
a c˜ co
• Os servi¸os s˜o altamente interativos e as intera¸oes s˜o complexas em termos das
c a c˜ a
funcionalidades oferecidas, entradas requeridas, sa´
ıdas providas, estrutura de comu-
nica¸ao e capacidade de configura¸ao;
c˜ c˜
• Muitos servi¸os utilizam recursos de multim´
c ıdia, provendo informa¸oes em diferentes
c˜
tipos de m´
ıdia (v´
ıdeo, som, texto, figuras e etc) simultaneamente e de maneira
integrada;
• As intera¸oes ocorrem de muitas maneiras, usando diferentes habilidades sensoriais
c˜
e motoras de forma concorrente e baseada nas formas mais simples de di´logo;
a
• A comunica¸ao e acesso a informa¸˜o s˜o usadas de forma concorrente para resolver
c˜ ca a
problemas comuns de forma combinada. E ainda, a coopera¸˜o tem seu lugar entre
ca
as pessoas ou seus representantes (avatares ou agentes), para a atribui¸˜o de n´
ca ıveis
vari´veis de confian¸a;
a c
´
• E fato que a computa¸ao est´ progressivamente mais social. Acesso a comunica¸ao
c˜ a c˜
ou informa¸˜o n˜o ´ mais problema de apenas um indiv´
ca a e ıduo e do contato entre duas
pessoas, mas sim est´ estendida em comunidades de usu´rios que tem seus pr´prios
a a o
espa¸os (muitas vezes virtuais) onde podem interagir.
c
2.3 Computa¸˜o M´vel
ca o
Computa¸˜o M´vel ´ o estudo de t´cnicas e dispositivos computacionais aplicados
ca o e e
fora de ambientes fixos. Seu aplica¸˜o b´sica baseia-se na capacidade dos dispositivos
ca a

23. 22
m´veis de se comunicarem, atrav´s de redes sem-fio (wireless), com a parte fixa da rede
o e
e possivelmente com outros dispositivos m´veis, independentemente da sua localiza¸˜o.
o ca
Segundo Ahmad (2005) no entanto uma rede sem-fio n˜o ´ sinˆnimo de mobilidade, j´
a e o a
que existem redes sem-fio com ambas as “pontas” fixas.
2.3.1 Redes de Comunica¸˜o Sem Fio
ca
Segundo Sanches (2007) redes de telecomunica¸˜o s˜o conjuntos organizados de equi-
ca a
pamentos que possuem a fun¸ao de transmiss˜o, comuta¸˜o, multiplexa¸ao ou qualquer
c˜ a ca c˜
outra relevante ` ´rea. Para classificar as redes de computa¸ao m´vel utiliza-se a dife-
aa c˜ o
rencia¸ao entre tecnologias, ´rea de alcance e taxa de transferˆncia, conforme Figura 2.2.
c˜ a e
Podendo classific´-las da seguinte forma:
a
• 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 comunica¸oes P2P ou Device-to-device
c˜
entre dispositivos 802.15 (Bluetooth), Ultra Wide Band (UWB) e Zigbee;
• Wireless Local Area Network (WLAN) - Redes Locais Sem Fio: Rede de curto-
m´dio alcance, taxa de transferˆncia entre 11 Mbps e 54 Mbps. Utilizado para
e e
muitos fins, pois apresenta boa rela¸ao entre, area de cobertura, velocidade e custo
c˜ ´
de implementa¸ao. Seus equipamentos implementam os padr˜es 802.11A, 802.11B,
c˜ o
802.11G e 802.11E;
• Wireless Metropolitan Area Network (WMAN) - Redes Metropolitanas Sem Fio:
M´dio-longo alcance, velocidades entre 11 Mbps e 100Mbps. Redes como 802.16
e
(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 tamb´m 2.5G, 3G, 3.5G e
e
4G/LTE.

24. 23
Figura 2.2: Classifica¸˜o das tecnologias de redes sem fio
ca
WIDE Project School of Internet (2009, Adaptada)
2.3.2 Limita¸oes
c˜
Para Nicopolitidis et al. (2003) a computa¸ao m´vel apresenta diversos problemas que
c˜ o
podem ser considerados como fatores limitantes na sua utiliza¸˜o. Para a Computa¸ao
ca c˜
Ub´
ıqua ´ imprescind´ que tais limita¸˜es sejam estudadas e transpostas com solu¸˜es
e ıvel co co
efetivas.
Talvez o pior problema da ado¸ao de redes sem-fio seja a seguran¸a na transmiss˜o de
c˜ c a
dados, comprometida pelo fato dos pacotes trafegarem em um meio n˜o-restrito e assim
a
est˜o sujeitos a a¸˜o de softwares de captura de dados conhecidos como Sniffers.
a ca
Outro ponto limitante ´ o consumo de energia dos dispositivos, j´ que por serem m´veis
e a o
estes estar˜o desacoplados de fontes de energia, dependendo apenas de alimenta¸ao por
a c˜
baterias, como o hardware desses dispositivos est´ cada vez mais potente, ´ imprescind´
a e ıvel
o desenvolvimento de baterias dur´veis, com tamanho e peso compat´
a ıvel, e de hardware

25. 24
mais econˆmico em quest˜o da energia consumida.
o a
Entretanto um dos piores problemas para as redes sem-fio continua sendo as interfe-
rˆncias sofridas por elementos externos. Condi¸˜es clim´ticas, tipo de terreno, presen¸a
e co a c
de paredes, entre outros tantos obst´culos podem atrapalhar ou at´ mesmo interromper
a e
a transmiss˜o de dados em uma rede sem-fio.
a
A incerteza quanto aos poss´
ıveis danos a sa´de causados pelo campo magn´tico e as
` u e
ondas celulares emitidas por dispositivos m´veis e a deficiˆncia das interfaces de usu´rio,
o e a
que s˜o em geral improdutivas e insuficientes, s˜o outros pontos menores que dificultam
a a
a utiliza¸˜o de dispositivos de computa¸ao m´vel.
ca c˜ o
2.3.3 Redes Ad Hoc M´veis
o
Ad Hoc (do latim, “Sem cabe¸a” ou “Com este objetivo”) ´ o termo utilizado para des-
c e
crever uma rede onde n˜o existe um n´ principal para onde todas as conex˜es convergem,
a o o
n˜o apresenta uma topologia definida e um controle centralizado. Em uma rede Ad Hoc
a
todos os n´s trabalham como roteadores em um modelo comunit´rio onde encaminham
o a
as comunica¸˜es oriundas de seus vizinhos (BROCH et al., 1998).
co
Uma Rede Ad Hoc M´vel ou Manet, ´ uma rede Ad Hoc (n˜o infra-estruturada) onde
o e a
os n´s se movimentam modificando suas posi¸˜es f´
o co ısicas e conseq¨entemente a distribui¸ao
u c˜
da rede. Em uma rede Ad Hoc M´vel existe o conceito de Mobile Nodes (MN) onde um
o
grupo de MNs formam redes autˆnomas. Como os n´s s˜o m´veis ´ imposs´ determinar
o o a o e ıvel
uma topologia, j´ que est´ pode mudar a qualquer momento.
a a
Para Johnson (1994) as redes Ad Hoc podem ser classificadas como sim´tricas nas
e
quais todos os n´s tem responsabilidades similares, distribu´
o ıdas igualmente entre eles,
sendo usado onde os MNs possuem caracter´
ısticas similares, e como assim´tricas, onde
e
dependendo de caracter´
ısticas de cada n´s, como raio de transmiss˜o, capacidade de
o a
processamento entre outros, este recebe tarefas proporcionais.
2.4 Computa¸˜o Ub´
ca ıqua ou Pervasiva
A computa¸ao conheceu duas grandes eras, primeiro a era do mainframe, onde havia
c˜
um computador para muitos usu´rios que utilizavam-se de “terminais burros” para ter
a
acesso aos recursos, logo surgiu a atual era da computa¸ao pessoal, que tirou a exclu-
c˜
sividade da computa¸ao de dentro das empresas e universidades e levou `s residˆncias,
c˜ a e

26. 25
fazendo uso dos Personal Computer s (PCs) e criando a rela¸˜o de um computador para
ca
cada um usu´rio (MUHLHAUSER; GUREVYCH, 2008). A computa¸ao ub´
a c˜ ıqua ´ con-
e
siderada a terceira era da computa¸ao (JANSEN et al., 2005) pois novamente altera a
c˜
forma de se utilizar os computadores, mudando a rela¸ao para v´rias m´quinas e um
c˜ a a
s´ usu´rio, sendo que esses computadores podem ser tanto desktops e notebooks como
o a
celulares, PDAs e dispositivos embarcados.
N˜o ´ somente a quantidade de dispositivos que ´ alterada com a computa¸˜o ub´
a e e ca ı-
qua, segundo Weiser (1991) a id´ia atual de computadores pessoais est´ completamente
e a
equivocada e n˜o aproveita o potencial da inform´tica, sendo que desktops, notebooks e
a a
outros dispositivos n˜o conseguem tornar a computa¸ao algo integral e invis´ na vida
a c˜ ıvel
das pessoas. Ele prega que a computa¸ao deve estar integrada a vida de forma que auxilie
c˜
a realiza¸˜o das tarefas levando em considera¸˜o as particularidades de cada usu´rio e
ca ca a
do contexto em que ele est´ inserido, ou seja, o sistema deve moldar-se as caracter´
a ` ısticas
do usu´rio e n˜o o usu´rio as caracter´
a a a ` ısticas do sistema, tirando o foco de uma “caixa”
(computador) e colocando-o diretamente na tarefa a ser realizada.
O principal objetivo da Computa¸ao Ub´
c˜ ıqua ´ integrar a computa¸˜o aos atos do dia-
e ca
a-dia sem alterar h´bitos e costumes, levando em considera¸˜o a pessoalidade de cada um
a ca
e deixando a tarefa a ser realizada em primeiro plano, ao inv´s do processo de realiz´-la
e a
como ´ com a computa¸ao convencional (WEISER, 1991).
e c˜
Segundo Campiolo, Cremer e Sobral (2007) a computa¸ao ub´
c˜ ıqua prove a perspectiva
de se acessar informa¸oes a qualquer momento e em qualquer lugar atrav´s da cria¸ao
c˜ e c˜
de ambientes impregnados de computadores e dispositivos de comunica¸˜o para intera¸˜o
ca ca
direta com o seres humanos.
Diferente dos anteriores Lyytinen e Yoo (apud ARAUJO, 2003) pregam que por serem
areas emergentes ´ comum observar o uso dos termos computa¸˜o ub´
´ e ca ıqua, computa¸˜o
ca
pervasiva e computa¸ao m´vel como sinˆnimos, entretanto existem diferen¸as conceituais
c˜ o o c
entre elas e cada uma possui diferentes id´ias de organiza¸ao. Eles ainda salientam que a
e c˜
computa¸˜o ub´
ca ıqua pode ser considerada a uni˜o da computa¸˜o m´vel com a computa¸ao
a ca o c˜
pervasiva conforme a Figura 2.3.

27. 26
Figura 2.3: Rela¸ao entre Computa¸˜o Ub´
c˜ ca ıqua, Pervasiva e M´vel
o
Araujo (2003, Adaptada)
2.4.1 Princ´
ıpios
De acordo com Weiser (1991) os princ´
ıpios ideol´gicos da Computa¸ao Ub´
o c˜ ıqua podem
ser definidos como:
• Finalidade: A finalidade de um computador ´ ajudar na realiza¸˜o de tarefas, sem
e ca
se tornar o foco do problema;
• Imperceptibilidade: O melhor computador ´ um servo quieto e invis´
e ıvel;
• Extens˜o das capacidades humanas: O computador deve estender a intui¸ao
a c˜
humana;
• N˜o-Obstru¸˜o: A tecnologia deve informar sem demandar o foco ou a aten¸ao.
a ca c˜
j´ Hansmann, Nicklous e Stober (2001) delimitam os princ´
a ıpios funcionais da compu-
ta¸˜o ub´
ca ıqua como sendo:
• Diversidade: Existem muitos tipos de dispositivos cada um com suas vantagens,
desvantagens, limita¸oes e caracter´
c˜ ısticas espec´
ıficas;
• Descentraliza¸˜o: como se trata de um sistema altamente distribu´ as respon-
ca ıdo
sabilidades ficam descentralizadas de forma que a uni˜o dos elementos ´ que forma
a e
a “inteligencia” do ambiente e do sistema.
• Conectividade: seguindo a defini¸˜o da palavra “ub´
ca ıqua” (universal, onipresente)
os n´
ıveis de conex˜o buscados s˜o de cobertura total em quest˜o de tempo e espa¸o,
a a a c

28. 27
criando uma “malha sem costuras” de redes heterogˆneas capazes de prover tais
e
servi¸os.
c
2.4.2 Consciˆncia de Contexto
e
Contexto, segundo Anagnostopoulos, Tsounis e Hadjiefthymiades (2007), ´ qualquer
e
informa¸˜o que pode ser utilizada para caracterizar uma situa¸ao ou entidade. Uma
ca c˜
entidade ´ qualquer pessoa, ambiente ou objeto que seja considerado relevante para a
e
integra¸ao entre o usu´rio e a aplica¸ao. Uma “Entidade Contextual” atua no sistema,
c˜ a c˜
enquanto a entidade “vis´
ıvel”, ´ uma entidade que apenas fornece informa¸˜es ou servi¸os.
e co c
A jun¸˜o de tais entidades forma o contexto, conforme a Figura 2.4.
ca
Figura 2.4: Demonstra¸˜o do contexto e suas entidades
ca
Anagnostopoulos, Tsounis e Hadjiefthymiades (2007, Adaptada)
2.4.3 Dispositivos
Para Jansen et al. (2005) um ambiente de computa¸ao pervasiva consiste em uma
c˜
cole¸ao de dispositivos e dos que os gerenciam e comandam. Existem dispositivos que
c˜
“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 usu´rio na resolu¸ao de suas tarefas.
a c˜

29. 28
Em um sistema computacional comum, o usu´rio sempre tem de dizer ao sistema
a
o que ele deve fazer, qual ´ o pr´ximo passo, j´ no sistema pervasivo essa intera¸˜o ´
e o a ca e
mais fluente, tenta-se antecipar as preferˆncias do usu´rio de forma que com base nelas
e a
possa-se agir antecipadamente. Essa antecipa¸˜o ´ conseguida principalmente com base
ca e
nos sensores, que recebem e repassam as informa¸˜es para o processamento, e posterior
co
sa´ pelos atuadores.
ıda
Para Grimm et al. (apud TANENBAUM; STEEN, 2007) um dispositivo na compu-
ta¸˜o ub´
ca ıqua deve reconhecer de forma autom´tica o ambiente e se adaptar a ele. Sendo
a
essa adapta¸ao realizada com base em trˆs quest˜es: Ado¸ao de mudan¸as contextuais,
c˜ e o c˜ c
incentivo `s composi¸˜es Ad Hoc e a ado¸ao do compartilhando de recursos como padr˜o.
a co c˜ a
2.4.4 Projetos
Desde o primeiro projeto de computa¸˜o ub´
ca ıqua, desenvolvido no Xerox PARC, su-
giram muitos outros que realizam pesquisas e desenvolvem solu¸˜es com bases nos seus
co
experimentos, entre eles pode-se citar:
• Authoring on the Fly da Universidade de Freiburg, visando integrar servi¸os de
c
grava¸˜o de v´
ca ıdeo, ensino a distˆncia e cria¸ao em tempo real de material multim´
a c˜ ıdia
em um unico sistema para serem utilizados em ambientes escolares, universit´rios e
´ a
tamb´m em apresenta¸oes e eventos;
e c˜
• Classroom 2000 do Georgia Institute of Technology, que visava levantar qual seria o
impacto da computa¸ao ub´
c˜ ıqua se aplica em ambientes educacionais, criando meios
para ampliar as capacidades de estudantes e professores atrav´s do uso de recur-
e
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 agrega¸ao dinˆmica de hardware e dispositivos, afim de permitir a cria¸ao
c˜ a c˜
de ambientes inteligentes;
• Gator Tech Smart House da Universidade de Florida, ´ um laborat´rio utilizado na
e o
pesquisa de novas t´cnicas de computa¸˜o ub´
e ca ıqua, sendo principalmente focado na
cria¸ao de ambientes conscientes de contexto.
c˜
• HP CoolTown, era um projeto que visava a cria¸˜o de interfaces e outros meios para
ca
que os usu´rios de dispositivos m´veis pudessem interagir com o ambiente em sua
a o

30. 29
volta e com a Web.
• Igrocer, visa ser um “assistente de compras”, servindo tando para a cria¸˜o de listas
ca
de compras como listas de produtos dispon´
ıveis, afim de automatizar o processo de
compra tanto para o cliente quanto para o comerciante, sendo tamb´m capaz de
e
manter um perfil nutricional do usu´rio.
a
• Medical Automation Research Center Smart House da Universidade de Virginia,
busca, principalmente, criar ambientes onde idosos podem habitar tendo sua sa´de
u
monitorada o tempo todo, utilizando diversos tipos de tecnologias inerentes a com-
puta¸˜o ub´
ca ıqua.
2.5 Modelagem e Simula¸˜o
ca
Banks (1998) define simula¸ao como a imita¸˜o da opera¸ao de um processo do mundo
c˜ ca c˜
real, envolvendo a gera¸˜o de uma “hist´ria artificial” do sistema e a observa¸ao das
ca o c˜
altera¸oes causadas pelas inferˆncias relativas as caracter´
c˜ e ısticas do sistema real que est´
a
sendo representado. Simula¸˜es s˜o utilizadas para descrever e analisar o comportamento
co a
do sistema, ajudando no desenvolvimento de sistemas reais. Tanto sistemas j´ existentes
a
como conceituais podem ser modelados com simula¸ao, o que a torna uma ferramenta
c˜
valiosa na solu¸˜o de muitos problemas do mundo real.
ca
2.5.1 Caracter´
ısticas
Para Banks (1998) uma simula¸˜o pode ser dividida primordialmente em nove partes
ca
Law e Kelton (apud BANKS, 1998) e Carson (apud BANKS, 1998) definem cada uma
dessas partes como sendo:
´
• Modelo: E a representa¸ao atual do sistema, deve-se ter a preocupa¸ao com os
c˜ c˜
limites ou fronteiras do modelo que supostamente representa o sistema real. O
modelo deve ser complexo o bastante para responder as perguntas levantadas, mas
n˜o complexo demais para criar novas;
a
• Eventos: S˜o as ocorrˆncias que alteram o estado do sistema. Existem tanto even-
a e
tos internos (end´genos) que pode ser a intera¸ao entre os elementos da simula¸˜o,
o c˜ ca
quanto eventos externos (ex´genos) como por exemplo a “chegada” de um novo
o
elemento;

31. 30
• Vari´veis de Estado do Sistema: S˜o a cole¸ao de toda a informa¸˜o necess´ria
a a c˜ ca a
para definir o que aconteceu no interior do sistema para se atingir determinado
estado em determinado tempo;
´
• Entidades: E a representa¸˜o do objetos que necessitam defini¸ao expl´
ca c˜ ıcita dentro
do sistema. Uma entidade pode ser dinˆmica, que atua no sistema ou est´tica que
a a
apenas serve as outras entidades;
• Atributos: S˜o as representa¸˜es das caracter´
a co ısticas de uma entidade, esses atri-
butos devem ser considerados como vari´veis locais para cada entidade;
a
• Recursos: S˜o as entidades que provˆem servi¸os as outras entidades, podendo
a e c
servir uma ou mais entidade ao mesmo tempo, dependendo das restri¸˜es do sistema,
co
assim como uma entidade dinˆmica pode requerer um ou mais recurso ao mesmo
a
tempo;
´
• Processamento de Lista E uma tarefa resultante da existˆncia dos recursos, pois
e
estes apenas trabalharam dentro do seu limite, e as outras requisi¸˜es ser˜o colocadas
co a
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 v´rios recursos (exemplo, fila de banco);
´ a
´
• Atividade: E um per´
ıodo de tempo com dura¸ao conhecida antes do in´ da a¸ao.
c˜ ıcio c˜
Ou seja, quando uma atividade come¸a ´ poss´ agendar o final dela;
c e ıvel
´
• Delay : E um per´
ıodo de tempo indefinido, causado pela combina¸˜o de condi¸˜es
ca co
do sistema. Primordialmente ´ o tempo em que uma entidade fica “parada” no
e
sistema, aguardando a libera¸˜o de um recurso;
ca
2.5.2 Modelagem
Para Simon (apud PRITSKER, 1998) a Modelagem ´ a principal ferramenta no estudo
e
do comportamento de sistemas muito complexos.
Modelos s˜o a descri¸ao do sistema, a sua utilidade ´ demonstrada por descrevˆ-lo,
a c˜ e e
desenha-lo e analis´-lo. A modelagem ´ um processo muito complexo e que, muitas vezes,
a e
envolve tanto a an´lise indutiva quanto a dedutiva. Se um modelo ´ a representa¸ao de
a e c˜
um sistema ele pode ser considerado uma abstra¸ao do sistema. Para desenvolver um abs-
c˜
tra¸˜o o modelista deve decidir quais os elementos do sistema real s˜o interessantes a essa
ca a

32. 31
abstra¸ao. Para chegar a tal conclus˜o ´ necess´rio que uma “finalidade” seja determinada,
c˜ a e a
um objetivo para a confec¸ao do modelo, portanto um modelo ´ a representa¸ao de um
c˜ e c˜
sistema voltado a uma determinada finalidade e modelagem ´ o processo de desenvolver
e
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 necess´rios para um projeto de estudo utilizando simula-
a
¸ao, conforme a Figura 2.5 s˜o:
c˜ a
• Formula¸ao do problema;
c˜
• Determina¸˜o do objetivo e plano geral de projeto;
ca
• Cria¸ao do Modelo Conceitual;
c˜
• Levantamento de dados hist´ricos ou estat´
o ısticos a serem utilizados como entrada,
na falta deles confec¸ao dos dados randˆmicos;
c˜ o
• Tradu¸ao do modelo (transforma¸ao do Modelo Conceitual em computacional, im-
c˜ c˜
plementa¸ao);
c˜
• Verifica¸ao (testa se o modelo gera resultados corretos);
c˜
• Valida¸˜o (testa se o modelo gera dados pr´ximos ao do fenˆmeno real);
ca o o
• Design Experimental (Defini¸ao das vari´veis do sistema, por exemplo: tempo de
c˜ a
execu¸˜o, n´mero de repeti¸oes, maneira de inicializa¸˜o entre outros);
ca u c˜ ca
• Execu¸˜o do sistema e An´lise das sa´
ca a ıdas;
• Novas Execu¸oes (Se os resultados dos testes n˜o forem satisfat´rios);
c˜ a o
• Documenta¸˜o e Relato dos testes e resultados;
ca
• Implementa¸ao (Utiliza¸ao dos resultados da simula¸ao no sistema real);
c˜ c˜ c˜

33. 32
Figura 2.5: Ciclo de vida de um estudo simulado
Banks (1998, Adaptada)
2.6 Utiliza¸˜o de Simula¸˜o na Computa¸˜o Ub´
ca ca ca ıqua
Muito j´ foi feito para a Computa¸˜o Ub´
a ca ıqua utilizando Simula¸˜o, j´ que, o uso desta
ca a
´ de particular importˆncia para desenvolvedores e pesquisadores dessa area. Grande
e a ´
parte dos requisitos de hardware est˜o atingindo a maturidade agora j´ que muitas apli-
a a
ca¸oes s˜o desenvolvidas pensando em um cen´rio futuro e contam com hardware que
c˜ a a
ser´ constru´ posteriormente. Ainda atrav´s da simula¸ao ´ poss´ para os pesqui-
a ıdo e c˜ e ıvel

34. 33
sadores avaliarem cen´rios, aplica¸˜es e protocolos por exemplo, sem as dificuldades de
a co
se trabalhar diretamente com os dispositivos de hardware reais (REYNOLDS; CAHILL;
SENART, 2006).
Construir modelos reais ´ uma tarefa complexa e muitas vezes imposs´
e ıvel. O uso de
modelagem e simula¸ao para entender e avaliar ambientes de computa¸˜o ub´
c˜ ca ıqua ´ uma
e
alternativa interessante e aplic´vel (CAMPIOLO; CREMER; SOBRAL, 2007).
a
2.6.1 Componentes de Uma Simula¸˜o de Computa¸˜o Ub´
ca ca ıqua
Quatro abstra¸˜es podem ser levantadas como componentes b´sicos desse tipo de
co a
simula¸ao: Ambientes, Sensores, Atuadores e Aplica¸˜es (REYNOLDS; CAHILL; SE-
c˜ co
NART, 2006), conforme a Figura 2.6.
Figura 2.6: Exemplo de componentes de uma simula¸ao em computa¸˜o ub´
c˜ ca ıqua
Levando em considera¸ao que os pontos chave em rela¸ao a um ambiente ´ a locali-
c˜ c˜ e
za¸ao e o espa¸o f´
c˜ c ısico, este pode ser facilmente representado utilizando um modelo em

35. 34
“grade”, uma matriz bidimensional por exemplo. A informa¸˜o relevante a determinado
ca
espa¸o f´
c ısico ´ representada utilizando o conceito de camadas, onde uma camada pode
e
representar, por exemplo, o n´ de luminosidade ou a temperatura de um determinado
ıvel
espa¸o daquele ambiente (REYNOLDS; CAHILL; SENART, 2006).
c
Sensores s˜o elementos que provˆem informa¸˜es, capturando-as ou recebendo-as
a e co
de algum outro elemento do sistema, as caracter´
ısticas mais comuns aos sensores s˜o
a
(CAMPIOLO; CREMER; SOBRAL, 2007):
• Se ´ ativo ou passivo;
e
• Se captura dados externa ou internamente;
• Se as suas ocorrˆncias (ativa¸oes) s˜o peri´dicas ou espor´dicas.
e c˜ a o a
Um sensor ativo investiga o ambiente em busca da informa¸˜o que ele necessita, por
ca
exemplo pode-se citar o termˆmetro, que “pega” a temperatura do ambiente onde ele est´.
o a
J´ um sensor passivo “recebe” a informa¸˜o ao inv´s de busc´-la no ambiente, como um
a ca e a
leitor de c´digo de barras, por exemplo.
o
Na captura externa de dados o sensor “lˆ” ou recebe a informa¸˜o de algum outro ele-
e ca
mento da simula¸˜o, enquanto que na captura interna a informa¸ao ´ inerente ao elemento,
ca c˜ e
sendo portanto “interno” a ele, como por exemplo a sua localiza¸˜o no ambiente.
ca
Ocorrˆncias ou ativa¸oes s˜o conceitos ligados muito mais a parte l´gica da simula¸ao,
e c˜ a o c˜
pois ´ atrav´s deles que criam-se as listas e filas de eventos. Ocorrˆncias peri´dicas s˜o
e e e o a
“agendadas” no sistema, ocorrem com determinada regularidade e podem ser prevista.
Ocorrˆncias espor´dicas s˜o normalmente fruto de algum evento ou arbitrariedade, sendo
e a a
portanto, virtualmente imprevis´
ıveis (CAMPIOLO; CREMER; SOBRAL, 2007).
Atuadores s˜o as entidades que “atuam” no sistema, ou seja que modificando vari´veis,
a a
alteram ou criam eventos inerentes a simula¸˜o. Compartilham parte das caracter´
` ca ısticas
dos sensores, pois podem agir tanto interna como externamente, peri´dica ou esporadica-
o
mente (CAMPIOLO; CREMER; SOBRAL, 2007).
As aplica¸oes s˜o o c´digo l´gico desenvolvido em alguma linguagem de programa¸ao,
c˜ a o o c˜
o ideal ´ que se utilize o mesmo c´digo para a simula¸ao e para o sistema real, mas
e o c˜
na grande maioria das vezes isso n˜o ´ poss´ devido, principalmente, a limita¸ao dos
a e ıvel c˜
simuladores em si (REYNOLDS; CAHILL; SENART, 2006).

36. 35
2.6.2 Estudos Similares
´
E poss´ encontrar diversos exemplos como Contri et al. (2008) e Campiolo, Cremer e
ıvel
Sobral (2007) que exploram a simula¸˜o de ambientes de computa¸˜o ub´
ca ca ıqua, por exemplo,
para a modelagem de prot´tipos de simuladores gen´ricos ou ent˜o outros como Huebscher
o e a
e McCann (2004) para comprova¸ao de modelos de aplica¸˜es e ainda estudos focados no
c˜ co
levantamento de requisitos para o pr´prio uso de simula¸oes em projetos de computa¸˜o
o c˜ ca
Ub´
ıqua como Reynolds, Cahill e Senart (2006).

37. 36
3 Descri¸˜o do Ambiente
ca
Experimental
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 vers˜o 1.4 da IDE Netbeans vers˜o 6.7.1 para a
a a
cria¸ao dos modelos UML do sistema, e a ferramenta MySQL Workbench vers˜o 5.1.18
c˜ a
para a modelagem do banco de dados. No processo de constru¸˜o foi utilizada a linguagem
ca
de programa¸˜o Java em sua vers˜o 1.6 e o banco de dados MySQL na vers˜o 5.0.75.
ca a a
3.1 Tecnologias Envolvidas
3.1.1 Java
A linguagem de programa¸˜o Java ser´ utilizada por suportar o desenvolvimento de
ca a
aplica¸˜es desktop (Aplica¸oes que rodem localmente na m´quina) e por prover uma forma
co c˜ a
simples e flex´ para o desenvolvimento de sistemas.
ıvel
Uma das principais caracter´
ısticas do Java ´ o suporte ao paradigma de programa¸ao
e c˜
da orienta¸˜o a objetos, sendo este imprescind´ para o desenvolvimento deste trabalho.
ca ıvel
3.1.2 MySQL
MySQL ´ um Sistema Gerenciador de Banco de Dados (SGBD), desenvolvido primei-
e
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 atrav´s de driver desenvolvido pela
e
pr´pira Sun Microsystems.
o
A principal caracter´
ıstica do Mysql ´ a simplicidade na configura¸ao e utiliza¸˜o, o
e c˜ ca

38. 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 Configura¸oes de Hardware
c˜
Somente uma m´quina foi utilizada para a implementa¸ao e execu¸˜o do sistema
a c˜ ca
sendo esta um notebook da marca Acer modelo Aspire 5715z contendo um processador
Intel Pentium Dual-Core T270 1.73GHz e 2 Gb de mem´ria RAM.
o
3.3 Estrutura L´gica
o
3.3.1 Sistema Operacional
Ser´ utilizada apenas uma m´quina com o sistema operacional GNU/Linux atrav´s
a a e
da distribui¸ao Ubuntu 9.10 Karmic Koala, com o Kernel vers˜o 2.6.28-15-generic e todas
c˜ a
as devidas atualiza¸˜es instaladas.
co
3.3.2 Aplicativos
3.3.2.1 Eclipse
Eclipse ´ um Integrated Development Environment (IDE) liberada como software li-
e
vre atrav´s da Eclipse Public License (EPL) criada por uma subsidiaria da IBM, que
e
pretendia diminuir a incompatibilidade entre os ambientes de desenvolvimento utilizados
na empresa. Em 2001 foi criado um cons´rcio de empresas chamado Eclipse Consortium
o
com a inten¸˜o de realizar o desenvolvimento da ferramenta em c´digo aberto. Em 2004 ´
ca o e
lan¸ada a primeira vers˜o livre e fundada a Eclipse Foundation, quem gerencia o projeto
c a
at´ os dias de hoje.
e
A vers˜o utilizada foi a 3.5 Galileo por ser a ultima vers˜o est´vel da ferramenta.
a ´ a a
3.3.2.2 MySQL Workbench
MySQL Workbench ´ uma ferramenta visual de modelagem de banco de dados. De-
e
senvolvida pela Sun Microsystems, pode ser utilizada para a modelagem, cria¸ao e ma-
c˜

39. 38
nuten¸ao de banco de dados MySQL.Neste trabalho ela ser´ utilizada para a cria¸ao do
c˜ a c˜
Modelo Entidade-Relacionamento (MER) do sistema.
A vers˜o utilizada foi a 5.1.18 da ferramenta.
a
3.3.2.3 Netbeans
Netbeans ´ uma IDE produzida pela Sun Microsystems, e liberada como software livre
e
e gratu´ Esta possui seu foco na integra¸ao com a plataforma Java (tamb´m produzida
ıto. c˜ e
pela Sun) entretanto tamb´m suporta programa¸ao em outras linguagens como C, C++,
e c˜
Python entre outros. Por´m ser´ utilizado apenas o plugin UML, para a gera¸˜o dos
e a ca
diagramas necess´rios a especifica¸˜o do sistema.
a ` ca
A vers˜o utilizada foi a 6.7.1 do Netbeans e a vers˜o 1.4 do plugin UML.
a a
3.3.3 Bibliotecas e Frameworks
3.3.3.1 DESMO-J
Discrete-Event Simulation and Modelling in Java (DESMO-J) ´ um framework focado
e
no desenvolvimento de modelos simulados usando a linguagem de programa¸ao Java e o
c˜
paradigma da programa¸˜o orientada a objetos. Foi criado e ´ mantido pelo Departamento
ca e
de Ciˆncia da Computa¸ao da Universidade de Hamburgo na Alemanha, estando liberado
e c˜
sob a Apache License, portanto ´ considerado Software Livre.
e
Foi utilizado este framework por ele abstrair as fun¸oes b´sicas necess´rias para o de-
c˜ a a
senvolvimento da simula¸ao, deixando o programador livre para a implementa¸˜o apenas
c˜ ca
das entidades envolvidas e dos seus relacionamentos.
Neste projeto foi utilizada a vers˜o 2.1.4b do DESMO-J por se tratar da ultima vers˜o
a ´ a
est´vel do framework.
a
3.3.3.2 Hibernate
O Hibernate ´ um framework criado por desenvolvedores Java liderados por Gavin
e
King, sendo que posteriormente esses desenvolvedores forma contratados pela JBoss Inc,
empresa esta que foi comprada posteriormente pela Red Hat Inc.
O framework ´ focado na realiza¸˜o do ”Mapeamento Objeto-Relacional”, apresen-
e ca
tando tamb´m funcionalidades para abstrair a comunica¸ao com o banco de dados. Por
e c˜

40. 39
contar com essas duas caracter´
ısticas, este foi utilizado nesse trabalho. Foi utilizado tam-
b´m o m´dulo Hibernate Annotations, pois esse dispensa o uso de XML na configura¸˜o
e o ca
do framework.
A vers˜o do framework Hibernate que foi utilizada ´ a 3.3.2.GA e a vers˜o 3.4.0.GA
a e a
do m´dulo Hibernate Annotations. Por serem as ultimas vers˜es est´veis de ambos.
o ´ o a

41. 40
4 Implementa¸˜o
ca
Esta parte do trabalho visa exlorar os detalhes da especifica¸˜o e codifica¸ao da si-
ca c˜
mula¸ao criada de acordo com o proposto nos c´pitulos anteriores.
c˜ a
A arquitetura ´ utilizada na implementa¸˜o conforme descrito na Figura 4.1. A classe
e ca
SimProcessClient representa os Atuadores do sistema, pois esta interage e altera o res-
tante sistema. A camada Ambientes ´ representada pelas informa¸˜es cont´
e co ıdas na classe
Ambiente e pela classe Modelo da implementa¸ao, pois estas cont´m informa¸oes ineren-
c˜ e c˜
tes ao contexto da aplica¸˜o. J´ a classe Sensor representa sozinha a camada Sensores
ca a
pois ´ a unica que faz a leitura de informa¸oes oriundas de outras classes. A camada de
e ´ c˜
Aplica¸oes ´ composta por todas as outras classes auxiliares utilizadas no sistema.
c˜ e
Figura 4.1: Representa¸ao da Aquitetura Proposta na Implementa¸˜o do Sistema
c˜ ca

42. 41
4.1 Especifica¸˜o
ca
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 prop´sitos dessa necessidade s˜o diversos e est˜o fora do escopo desse trabalho.
o a a
Tendo em vista a necessidade levantada, defini-se que trˆs hip´teses ser˜o testadas de
e o a
forma a definir a que possui a melhor taxa de acerto.
As hip´teses s˜o:
o a
• Dispor os sensores apenas nos carrinhos;
• Dispor os sensores apenas nos clientes;
• Dispor os sensores nos clientes e carrinhos;
Cada uma das hip´teses tem suas vantagens e desvantagens o que n˜o ´ relevante para
o a e
o sistema.
Leva-se em considera¸˜o que o ambiente sabe detectar qual produto foi retirado de
ca
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 realiza¸˜o dessa tarefa ´ necess´ria a implementa¸ao de diversas outras
ca e a c˜
classes auxiliares.
4.2 Codifica¸˜o
ca
A implementa¸ao foi realizada possuindo apenas um unico projeto, sendo subdividido
c˜ ´
em pacotes e nomeado de MercadoUbiquo.
Foi tamb´m criado um banco de dados chamado mercadoUbiquo no qual ficar´ arma-
e a
zenado as informa¸oes iniciais da simula¸ao, estas n˜o sofreram qualquer altera¸˜o durante
c˜ c˜ a ca
a execu¸ao. Toda a estrutura do banco de dados foi gerada autom´ticamente pelo fra-
c˜ a
mework Hibernate com base nas classes definidas no projeto, sendo que o resultado final
pode ser visto na Figura 4.2.

43. 42
Figura 4.2: Modelo Entidade Relacional do Banco de Dados Utilizado
A l´gica b´sica da simula¸ao est´ em movimentar os “X” clientes de forma que estes
o a c˜ a
v˜o at´ as prateleiras e retiram os produtos, quando um produto ´ retirado da prateleira
a e e
o Sensor entra em a¸˜o e “escaneia” um raio de “Y” quadrados tendo como centro o local
ca
onde foi detectado a sa´ do produto, o primeiro cliente detectado ´ considerado como
ıda e
respons´vel pela retirada. Na Figura 4.3 demonstra-se como funciona a detec¸˜o para
a ca
um raio de 3 quadros, nesse exemplo ocorre a detec¸ao errada do cliente que retirou o
c˜
produto.

44. 43
Figura 4.3: Detec¸˜o do Sensor com raio de 3 quadros
ca
4.3 Pacote Localization
Um dos requisitos necess´rios para o sucesso dessa simula¸ao ´ o posicionamento dos
a c˜ e
clientes. Para tal, o pacote localization conta com as classe Point e MovePlanner conforme
a figura 4.4.