Modelagem de Ambientes de Computação Ubíqua Utilizando Simulação
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 2,357 views

 

Statistics

Views

Total Views
2,357
Views on SlideShare
2,323
Embed Views
34

Actions

Likes
0
Downloads
55
Comments
0

2 Embeds 34

http://jcanalneto.wordpress.com 33
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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
  • 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
  • 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.
  • 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.
  • Lista de Abreviaturas e Siglas AmI Ambientes Inteligentes CDMA Code Division Multiple Access CSV Comma Separated Values DAO Data Access Object DESMO-J Discrete-Event Simulation and Modelling in Java EPL Eclipse Public License GPRS General Packet Radio Service GSM Global System for Mobile Communications HSDPA High-Speed Downlink Packet Access IDE Integrated Development Environment LMDS Local Multipoint Distribution Service LTE Long Time Evolution MER Modelo Entidade-Relacionamento MMDS Multichannel Multipoint Distribution Service MN Mobile Nodes P2P Peer-to-Peer PC Personal Computer PDA Personal Digital Assistants RMI Remote Method Invocation RPC Remote Procedure Call SGBD Sistema Gerenciador de Banco de Dados SQL Structured Query Language UML Unified Modeling Language UWB Ultra Wide Band WiMax Worldwide Interoperability for Microwave Access WLAN Wireless Local Area Network WMAN Wireless Metropolitan Area Network
  • WPAN Wireless Personal Area Network WWAN Wireless Wide Area Network
  • Lista de Figuras 2.1 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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˜
  • 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.
  • 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
  • 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;
  • 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.
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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.
  • 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
  • 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˜
  • 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
  • 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;
  • 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
  • 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˜
  • 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
  • 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
  • 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).
  • 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).
  • 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
  • 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˜
  • 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˜
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 44 Figura 4.4: Classes do Pacote Localezation A classe Point ´ utilizada para representar as unidades de localiza¸ao, levando em e c˜ considera¸ao que se trata um sistema de duas dimens˜es, este ´ o respons´vel pelas infor- c˜ o e a ma¸oes referentes as cordenadas (X,Y). c˜ A outra classe pertencente a essa pacote ´ a classe abstrata MovePlanner esta somente e possui m´todos est´ticos e visa trabalhar como um tratador de todas as movimenta¸oes e a c˜ necess´rias aos clientes. Apessar de n˜o realizar realmente a movimenta¸ao do cliente, esta a a c˜ classe ´ a respons´vel por calcular o caminho que o cliente dever´ fazer at´ seu destino. e a a e Para tal calculo ´ utiliza um ”algoritmo de melhor caminho”simples, com base no pr´ximo e o passo apenas. 4.4 Pacote Model O pacote Model do projeto cont´m as classes utilizadas na cria¸˜o dos objetos atua- e ca dores do sistema simulado, conforme Figura 4.5:
  • 45 Figura 4.5: Classes do Pacote Model ´ E tamb´m atrav´s das classes presentes no pacote Model que o framework Hibernate e e faz o mapeamento objeto-relacional do sistema, como dito no cap´ ıtulo 3 foi utilizado o m´dulo Annotations do Hibernate, que possibilita o mapeamento dos objetos utilizando o apenas anota¸oes java, conforme demonstrado em parte da classe Cliente na listagem 4.1: c˜ Listagem 4.1: Classe Cliente ...
  • 46 @Entity @Table ( name = " C l i e n t e " ) 5 public class Cliente { @Id @GeneratedValue ( s t r a t e g y = G e n e r a t i o n T y p e .AUTO) private int id ; 10 private S t r i n g nome ; @Transient private PortaProduto portaProduto ; 15 @ManyToMany @JoinTable ( name = " L i s t a C o m p r a s " , j o i n C o l u m n s = { @JoinColumn ( name=" c l i e n t e _ i d " ) } , i n v e r s e J o i n C o l u m n s = { @JoinColumn ( name=" p r o d u t o _ i d " ) } ) @ L a z y C o l l e c t i o n ( L a z y C o l l e c t i o n O p t i o n . FALSE) private L i s t <TipoProduto> l i s t a C o m p r a s ; 20 ... A classe Cliente possui um atributo do tipo PortaProduto sendo este tipo uma In- terface, ela ´ implementada pela classe abstrata PortaProdutoImpl que trata os m´todos e e comuns a todos os seus herdeiros e ´ extendida pelas classes Carrinho e Cestinha, sendo e essas as duas op¸oes poss´ c˜ ıveis para o preenchimendo do atributo. A defini¸ao de qual tipo c˜ o cliente usar´ ´ feita com base no n´mero de produtos que ele possui em sua lista de ae u compras, se este possuir mais cinco produtos em sua lista, este ficar´ com um carrinho, a se n˜o, pegar´ uma cestinha. a a Na classe Prateleira existem dois atributos do tipo Point um referencia a posi¸˜o real ca do objeto e o outro marca o ponto a frente dele, por onde o cliente poder´ ter acesso a ` a seus produtos. 4.5 Pacote Persistence O pacote Persistence ´ o respons´vel por fazer toda a intera¸ao com o banco de dados, e a c˜ ´ tamb´m onde ´ feita a configura¸ao e o uso do framework Hibernate. e e e c˜ ´ E composto pela classe HibernateUtils que abstrai a parte de conex˜o com o banco de a dados, e o Sub-pacote DAO, onde se encontram as classes Data Access Object (DAO) do sistema, estas s˜o respons´veis por separar as regras de persistˆncia de dados das regras a a e de neg´cio. o 4.6 Pacote Statistics J´ o pacote Statistics cont´m a classe DataContainer, que visa armazenar os dados a e estat´ ısticos de cada hip´tese e a classe StatisticsData que possui um DataContainer para o
  • 47 cada uma das hip´teses testadas, e tamb´m guarda outras informa¸˜es estat´ o e co ısticas do sistema e que ´ utilizada para o c´lculo dos resultados da simula¸ao. e a c˜ 4.7 Pacote Simulation Este ´ o pacote onde toda a opera¸ao da simula¸˜o ´ realizada, ele possui trˆs sub- e c˜ ca e e pacotes: environment, composto pelas classes Ambiente e Modelo, o sub-pacote sensor, que ´ composto pela classe Sensor e o pacote actuator, composto pela classe SimProces- e sCliente. A Figura 4.6 demonstra as intera¸oes entre essas classes. c˜ Figura 4.6: Classes do Pacote Simulation 4.7.1 Environment No pacote Environment ficam armazenadas as classes Modelo e Ambiente, ambas respons´veis por trabalharem com informa¸˜es inerentes ao ambiente da simula¸˜o. a co ca A classe Modelo extende a classe Model do framework DESMO-J que ´ a respons´- e a vel pela configura¸ao e inicializa¸˜o da simula¸˜o, possui dois m´todos b´sicos: init e c˜ ca ca e a doInitialSchedules. O m´todo init ´ utilizado para inicializar os geradores de valores pseudo-aleat´rios e e o
  • 48 (tempo de passo e tempo de chegada), que ser˜o utilizados na configura¸˜o dos SimPro- a ca cessCliente, como distribui¸˜es uniformes. co J´ o m´todo doInitialSchedules carrega do banco de dados, atrav´s das classes DAO, a e e 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 ´ utilizada para popular a lista “PontosFixos” da classe abstrata Am- e biente, afim de garantir que os clientes n˜o atravessem esses pontos ocupados. Finalmente a a lista de clientes ´ utilizada para a cria¸ao dos SimProcessClient, que s˜o os atuadores do e c˜ a sistema, cada instˆncia recebendo um tempo de passo e um tempo de ativa¸˜o conforme a ca as bases pseudo-aleat´rias geradas no m´todo init, al´m de um objeto do tipo Cliente que o e e possui as informa¸oes uteis a camada de aplica¸ao. Todo o fluxo da classe Modelo no c˜ c˜ m´todo doInitialSchedules pode ser observado na Listagem 4.2. e Listagem 4.2: M´todo doInitialSchedules da Classe Modelo e @O verride public void doInitialSchedules () { double aux tempo = 0 ; ClienteDAOImpl clienteDAO = new ClienteDAOImpl ( ) ; 5 P r a t e l e i r a D A O I m p l p r a t e l e i r a D A O = new P r a t e l e i r a D A O I m p l ( ) ; p r a t e l e i r a s L i s t a = new V e c t o r<P r a t e l e i r a >() ; L i s t <P r a t e l e i r a > a u x P r a t e l e i r a s = p r a t e l e i r a D A O . g e t L i s t ( ) ; for ( Prateleira pt : auxPrateleiras ) { Ambiente . p o n t o s F i x o s . add ( p t . g e t P o s i c a o ( ) ) ; 10 if ( p t . g e t T i p o P r o d u t o ( ) . g e t I d ( ) != 9 9 ) { p r a t e l e i r a s L i s t a . add ( p t ) ; } } L i s t <C l i e n t e > l s C l i e n t e = clienteDAO . g e t L i s t ( ) ; 15 StatisticsData . total = lsCliente . size () ; for ( Cliente clIt : lsCliente ) { SimProcessCliente c l i e n t e = new S i m P r o c e s s C l i e n t e ( t h i s , clIt . getNome ( ) , true , c l I t , new SimTime ( g e t C l i e n t e T e m p o P a s s o ( ) ) ) ; c l i e n t e . a c t i v a t e ( new SimTime ( aux tempo ) ) ; 20 aux tempo = aux tempo + g e t C l i e n t e T e m p o C h e g a d a ( ) ; l i s t a C l i e n t e s . add ( c l i e n t e ) ; } } A classe Ambiente ´ utilizada para a reprensenta¸ao das informa¸oes inerentes a ca- e c˜ c˜ mada de Ambiente proposta nos c´pitulos anteriores. Esta cont´m, por exemplo, as a e cordenadas X e Y m´ximas do sistema, os pontos que est˜o ocupados por prateleiras e a a consequentemente n˜o est˜o acess´ a a ı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 respons´vel a por verificar as retiradas de produtos e detectar qual o cliente que a realizou.
  • 49 Quando um produto ´ retirado de uma prateleira, a instˆncia de Sensor contida em e a Modelo ´ chamado, este registra a ocorrˆncia de uma sa´ (na classe StatisticsData) e e e ıda ´ escaneia uma area de “N” quadros com o centro no ponto onde o produto foi retirado. E ´ nesse ponto que ocorre a diferencia¸ao das trˆs hip´teses levantas anteriormente, como c˜ e o demonstrado na listagem 4.3. Listagem 4.3: Diferencia¸ao das Detec¸oes na Classe Sensor c˜ c˜ public boolean v e r i f i c a r R e t i r a d a ( P r a t e l e i r a pr , SimProcessCliente simProcessCliente , int tipoSensor ) { Point ptBase = pr . getPontoFrente ( ) ; 5 L i s t <P o i n t> p t L i s t = p t B a s e . c a l c u l a r A d j a c e n t e s ( r a i o ) ; switch ( tipoSensor ) { case S t a t i s t i c s D a t a . CLIENTE COM SENSOR : { 10 return v e r i f i c a r R e t i r a d a C l i e n t e ( pr , simProcessCliente , ptList ) ; } case S t a t i s t i c s D a t a . PORTA PRODUTO COM SENSOR : { return v e r i f i c a r R e t i r a d a P o r t a P r o d u t o ( pr , simProcessCliente , ptList ) ; } 15 case S t a t i s t i c s D a t a . AMBOS COM SENSOR : { if ( ! v e r i f i c a r R e t i r a d a C l i e n t e ( pr , simProcessCliente , ptList ) ) { return v e r i f i c a r R e t i r a d a P o r t a P r o d u t o ( pr , simProcessCliente , ptList ) ; } 20 return true ; } } return false ; } 4.7.3 SimProcessCliente A classe SimProcessCliente extende a classe SimProcess do DESMO-J e representa a entidade cliente dentro da simula¸ao, as outras entidades (Prateleira, Produto e Porta- c˜ Produto) n˜o necessitam ser representadas pois apenas s˜o afetadas pelas a¸oes da classe a a c˜ Cliente e n˜o realizam a¸˜es sozinhas. Esta possui um m´todo lifeCycle que ´ onde se a co e e desenvolve todo o “ciclo de vida” do cliente dentro do sistema, este come¸a com o cliente c entrando no sistema e termina com a sa´ do mesmo ap´s realizar suas compras e se ıda o encaminhar para o ponto de sa´ ıda, conforme representado na Listagem 4.4. Listagem 4.4: M´todo lifeCycle da Classe SimProcessCliente e public void lifeCycle () { setarPortaProduto () ; 5 iniciarListaPrateleiras () ; realizarCompras () ; sairDoSistema () ; 10 meuModelo . g e t S t a t s C o l l e c t o r ( ) . s a i u C l i e n t e ( ) ;
  • 50 if ( meuModelo . g e t S t a t s C o l l e c t o r ( ) . g e t P r o c e s s a d o s ( ) == meuModelo . getStatsCollector () . getTotalClientes () ) { 15 meuModelo . g e t E x p e r i m e n t ( ) . s t o p ( ) ; } } 4.8 Execu¸˜o e Sa´ ca ıdas O sistema ´ executado pela classe App. Este instˆncia e interconecta as classes Modelo e a e Experiment e ent˜o “repassa o comando da aplica¸ao” para a classe Experiment do a c˜ framework DESMO-J que ´ respons´vel pelas opera¸oes de controle inerentes ao pr´prio e a c˜ o framework, bem como a inicializa¸ao da classe Modelo. c˜ A execu¸ao ocorre “N” vezes sendo “N” o resultado da multiplica¸˜o entre o maior c˜ ca n´mero de clientes poss´ u ıveis e o maior valor poss´ para o raio do sensor. Os dados s˜o ıvel a coletados para as trˆs hip´teses simultaneamente em cada uma das execu¸oes. e o c˜ As sa´ ´ montada em um arquivo no formato Comma Separated Values (CSV) e ıda e gerada no mesmo diret´rio do sistema. Para cada uma das execu¸˜es ´ registrado no CSV o co e as seguintes informa¸˜es: co • Tipo do Teste (Hip´tese); o • N´mero de Clientes; u • Raio do sensor; • N´mero de retiradas; u • Acertos; • Erros; • Taxa de Acerto.
  • 51 5 Resultados Com o objetivo de validar a simula¸ao desenvolvida, foram realizados testes alterando c˜ a principais vari´veis do sistema. Foram escolhidas para o teste a vari´vel Quantidade de a a Clientes que se refere a quantidade de clientes que participam da simula¸˜o e a vari´vel ` ca a Raio que se refere ` area de escaneamento do sensor. Os dados s˜o capturados para as a´ a trˆs hip´teses levantadas anteriormente. e o Atrav´s das varia¸oes propostas, ´ poss´ tra¸ar o comportamento da simula¸ao. Os e c˜ e ıvel c c˜ dados colhidos em formato CSV foram tabulados e a partir destes foram analisados. A varia¸ao escolhida foi de 1 at´ 50 para o n´mero de clientes e de 0 a 10 para o raio c˜ e u do sensor, sendo portanto realizado 550 testes para cada uma das hip´teses e totalizando o 1650 testes para todo o sistema. Com essa amplitude, a quantidade de informa¸ao colhida c˜ ´ suficiente para a realiza¸ao de inumer´veis an´lises. e c˜ a a 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 an´lisado na figura 5.1. a
  • 52 Figura 5.1: Taxa de Acerto Para 35 Clientes A diferen¸a detectada ´ apenas nas casas decimais, e esta tendˆncia se mant´m em c e e e testes com o n´mero de clientes superior ou igual a 35 e com raio superior ou igual a u 7, entretanto a maior diferen¸a detectada ´ justamente nos testes com 35 clientes e raio c e entre 7 e 10, sendo ela de 0,44%. Na figura 5.2 tamb´m ´ poss´ verificar a diferen¸a e e ıvel c entre essas duas hip´teses para uma amostra de 50 clientes. o
  • 53 Figura 5.2: Taxa de Acerto Para 10 de Raio Foi poss´ ıvel tamb´m avaliar que utilizando o sensor somente no porta produto, a e taxa de acerto sempre ´ igual ou inferior as outras duas hip´teses,a figura 5.2 para uma e ` o quantidade vari´vel de clientes e um valor fixo de raio 10, e a figura 5.3 demonstra essa a tendˆncia para uma amostra de fixa 50 clientes e um raio vari´vel. e a
  • 54 Figura 5.3: Taxa de Acerto Para 50 Clientes Para o teste com 50 clientes, a compara¸˜o entre a taxa de acerto das hip´teses ca o varia conforme o gr´fico 5.4, sendo no m´ximo 6,62% entre “Ambos” e “Porta Produto” e a a tamb´m entre “Cliente” e “Porta Produto” e no m´ e ınimo 0% em diversos momentos. Pode- se visualizar tamb´m que a diferen¸a entre “Ambos” e “Cliente” mant´n-se em 0% at´ o e c e e teste com raio 6 e a partir do teste com raio 7 esta se mant´m em 0,33%. e
  • 55 Figura 5.4: Diferen¸a Entre a Taxa de Acerto das Hip´teses Para 50 Clientes c o
  • 56 6 Considera¸˜es Finais e co Trabalhos Futuros 6.1 Considera¸˜es Finais co Tendo em vista a multi-disciplinariedade da computa¸ao ub´ c˜ ıqua, desenvolver sistemas voltados a essa area, pode ser uma pratica relativamente complexa. Como se trata tamb´m ´ e de uma area nova e pouco explorada os m´todos e t´cnicas relevantes durante o projeto ´ e e de uma solu¸ao n˜o est˜o claramente explorados. c˜ a a Este trabalho utilizou uma simula¸ao para testar trˆs possiveis hip´teses afim de c˜ e o determinar a diferen¸a entre taxas de acerto de cada uma delas. Para que, dessa forma, c pudesse consider o uso de simula¸˜es como uma ferramenta util no projeto de sistemas e co ´ ambientes voltados a computa¸ao ub´ c˜ ıqua. Os resultados obtidos comprovam a viabilidade de utiliza¸ao simula¸oes em projetos c˜ c˜ de computa¸ao ub´ c˜ ıqua, tendo em vista que foi poss´ determinar a diferen¸a entre as ıvel c hip´teses, esses dados poderiam ser utilizados para auxiliar a tomada de decis˜o de um o a projetista sobre qual dos m´todos utilizar. e 6.2 Trabalhos Futuros Como trabalho futuro prop˜e-se a re-execu¸ao da simula¸ao utilizando dados n˜o- o c˜ c˜ a aleat´rios. Sendo esses dados coletados atrav´s de pesquisas e m´todos estat´ o e e ısticos, a veracidade dos resultados da simula¸˜o seria maior. ca Prop˜e-se tamb´m o desenvolvimento de um simulador gen´rico para sistemas de o e e computa¸˜o ub´ ca ıqua, onde a constru¸ao do ambiente fosse realizada de forma gr´fica e a c˜ a l´gica necess´ria para as entidades da simula¸˜o fosse programada de uma forma simples o a ca e natural.
  • 57 Referˆncias Bibliogr´ficas e a AHMAD, A. Wireless and mobile data networks. New Jersey: Wiley-Interscience, 2005. ANAGNOSTOPOULOS, C.; TSOUNIS, A.; HADJIEFTHYMIADES, S. Context awareness in mobile computing environments. Wireless Personal Communications Journal, v. 42, n. 3, Ago. 2007. ARAUJO, R. B. Computa¸ao ub´ c˜ ıqua: princ´ ıpios, tecnologias e desafios. XXI Simp´sio o Brasileiro 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, applications and pratice. 4. ed. New Jersey: Wiley-Interscience, 1998. BROCH, J. et al. A performance comparison of multi-hop wireless ad hoc network routing protocols. In: Proceedings of the 4th annual ACM/IEEE international conference on Mobile computing and networking. New York: ACM, 1998. p. 85–97. CAMPIOLO, R.; CREMER, V.; SOBRAL, J. B. M. On modeling for pervasive computing environments. In: . New York: ACM, 2007. p. 240–243. CONTRI, E. et al. Modelando um ambiente ub´ ıquo atrav´s de simula¸ao. 7th e c˜ International Information and Telecommunication Technologies Symposium, Foz do Igua¸u, 2008. c COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems: Concepts And Design. 4. ed. New York: Addison-Wesley, 2005. EMILIANI, P. L.; STEPHANIDIS, C. Universal access to ambient intelligence environments: opportunities and challenges for people with disabilities. Fev. 2005. Dispon´ em: <www.research.ibm.com/journal/sj/443/emiliani.pdf>. Acesso em: ıvel 21/03/2009. GIL, A. C. Como elaborar projetos de pesquisa. 4. ed. S˜o Paulo: Atlas, 2002. a HANSMANN, U.; NICKLOUS, M. S.; STOBER, T. Pervasive computing handbook. New York: Springer-Verlag, 2001. HUEBSCHER, M. C.; MCCANN, J. A. Simulation model for self-adaptive applications in pervasive computing. Proceedings of the Database and Expert Systems Applications, 2004.
  • 58 JANSEN, E. et al. A programming model for pervasive spaces. International Conference on Service-Oriented Computing, Amsterdam, 2005. JOHNSON, D. B. Routing in ad hoc networks of mobile hosts. In: In Proceedings of the IEEE Workshop on Mobile Computing Systems and Applications. Washington: IEEE Computer Society, 1994. p. 158–163. LAKATOS, E. M.; MARCONI, M. de A. Metodologia Cient´fica. 3. ed. S˜o Paulo: Atlas, ı a 2000. MUHLHAUSER, M.; GUREVYCH, I. Handbook of research on ubiquitous computing technology 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.). Handbook of 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 computing simulation and emulation environment. In: InterSense ’06: Proceedings of the first international conference on Integrated internet ad hoc and sensor networks. New York: ACM, 2006. p. 1. a a ´ SANCHES, C. A. Projetando redes wlan: conceitos e pr´ticas. 2. ed. S˜o Paulo: Erica, 2007. TANENBAUM, A. S.; STEEN, M. V. Sistemas distribu´dos: princ´pios e paradigmas. ı ı Tradu¸ao de: Arlete Simille Marques. Revis˜o T´cnica de: Wagner Zucchi. 2. ed. S˜o c˜ a e a Paulo: Pearson Prentice Hall, 2007. WEISER, M. The Computer of The Twenty-One Century. Fev. 1991. Dispon´ em: ıvel <http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html>. Acesso em: 17/03/2009. WIDE PROJECT SCHOOL OF INTERNET. WAN,MAN,LAN,PAN. 2009. Dispon´ ıvel em: <http://www.soi.wide.ad.jp/class/20070044/slides/04/index 24.html>. Acesso em: 25/04/2009.