59
CENTRO DE ENSINO SUPERIOR DE FOZ DO IGUA ¸ CU CURSO DE CI ˆ ENCIA DA COMPUTA¸ C ˜ AO TRABALHO DE CURSO MODELAGEM DE AMBIENTES DE COMPUTA¸ C ˜ AO UB ´ IQUA UTILIZANDO SIMULA ¸ C ˜ AO JURMIR CANAL NETO FOZ DO IGUA¸ CU - PR 2009

Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 2: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 3: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 4: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 5: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 6: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

WPAN Wireless Personal Area Network

WWAN Wireless Wide Area Network

Page 7: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 8: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 9: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 10: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 11: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 12: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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-

Page 13: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 14: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 15: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 16: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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;

Page 17: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 18: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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)

Page 19: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 20: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 21: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 22: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 23: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 24: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 25: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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,

Page 26: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 27: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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,

Page 28: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 29: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 30: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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;

Page 31: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 32: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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);

Page 33: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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-

Page 34: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 35: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 36: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 37: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 38: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulaçã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-

Page 39: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 40: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 41: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 42: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 43: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 44: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 45: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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:

Page 46: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 47: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 48: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 49: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 50: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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 ( ) ;

Page 51: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 52: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 53: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 54: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 55: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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

Page 56: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

55

Figura 5.4: Diferenca Entre a Taxa de Acerto das Hipoteses Para 50 Clientes

Page 57: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 58: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.

Page 59: Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação

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.