caracterização e modelagem do comportamento de … · sistemas de mapa web, ou sigs web, são...

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

VINÍCIUS GONÇALVES BRAGA

Caracterização e Modelagem doComportamento de Usuários de Mapas

Web para Reprodução de Carga deTrabalho e Avaliação de Desempenho de

Sistemas Baseados em Tiles

Goiânia2015

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO

EM FORMATO ELETRÔNICO

Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Infor-mática da Universidade Federal de Goiás – UFG a reproduzir, inclusive em outro formatoou mídia e através de armazenamento permanente ou temporário, bem como a publicar narede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-seos termos “reproduzir” e “publicar” conforme definições dos incisos VI e I, respectiva-mente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixo especificada, sem queme seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publi-cação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgaçãoda produção acadêmica gerada pela Universidade, a partir desta data.

Título: Caracterização e Modelagem do Comportamento de Usuários de Mapas Web paraReprodução de Carga de Trabalho e Avaliação de Desempenho de Sistemas Baseados emTiles

Autor(a): Vinícius Gonçalves Braga

Goiânia, 16 de Setembro de 2015.

Vinícius Gonçalves Braga – Autor

Dr. Kleber Vieira Cardoso – Orientador





Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emCiência da Computação.

Área de concentração: Ciência da Computação.

Orientador: Prof. Dr. Kleber Vieira Cardoso

Goiânia2015





Dissertação defendida no Programa de Pós–Graduação do Instituto deInformática da Universidade Federal de Goiás como requisito parcialpara obtenção do título de Mestre em Ciência da Computação, aprovadaem 16 de Setembro de 2015, pela Banca Examinadora constituída pelosprofessores:

Prof. Dr. Kleber Vieira CardosoInstituto de Informática – UFG

Presidente da Banca

Profa. Dra. Jussara Marques de AlmeidaDepartamento de Ciência da Computação – UFMG

Prof. Dr. Ricardo Couto Antunes da RochaInstituto de Informática – UFG

Prof. Dr. Vagner José do Sacramento RodriguesInstituto de Informática – UFG

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Vinícius Gonçalves Braga

Bacharel em Engenharia de Software pela Universidade Federal de Goiás(2013). Participou de dois projetos P&D durante a graduação, trabalhandocom desenvolvimento de interfaces gráficas e monitoramento de sistemascomputacionais. É fundador do GDG Goiânia (Grupo de DesenvolvedoresGoogle de Goiânia) e participou da organização de diversos eventos detecnologia.

Dedico esta dissertação a Deus, aos meus pais, a minha namorada, ao meu

irmão, a todo o restante da minha família e aos meus amigos, por todo apoio, carinho e

compreensão.

Agradecimentos

Agradeço a Deus, pela graça da vida, pela saúde, pelas oportunidades e pela força nashoras difíceis.Aos meus pais, José e Cleusimar, por todo seu amor, carinho, compreensão, apoio,orientação e paciência ao longo dos anos e durante o período do mestrado. Agradeçopelas vezes que, mesmo cansados, viajaram para vir me visitar e me ajudaram em tudoque precisei.Ao meu irmão, Bruno, por todo seu amor, carinho e apoio.A Romilda, minha namorada, por todo seu amor, carinho, compreensão e apoio. Agradeçotambém pelos conselhos, pela paciência e pelos momentos de descontração e alegria.Ao Prof. Kleber Vieira Cardoso, por sua orientação, amizade, paciência e confiança.Ao Prof. Vagner José do Sacramento Rodrigues, por sua orientação, contribuição e confi-ança.Aos Profs. Ricardo e Jussara, por aceitarem o convite, pela presença na banca e pelascontribuições à dissertação.Aos meus amigos: Micael, Igor, Marquete, Allan, Inael, Jackeline, Geovane, Cássio,Diego, Danillo, Cleber, Bruno e todos os demais; pela amizade, apoio e momentos dedescontração. Em especial ao Micael, pela ajuda na revisão do texto.Aos colegas e amigos do grupo de pesquisa Lupa e da goGeo: Alex, Anderson, Eric,Everton, Fernando, Marcelo, Roberto, Sávio, Welder, Wisley e todos os demais; pelascontribuições, pela amizade e pelo apoio.À equipe da secretaria: Mirian, Patrícia, Berenice e todos os demais; pela atenção, paci-ência e suporte operacional.Ao INF/UFG, pelas instalações e equipamentos utilizados.A goGeo, pelas instalações e equipamentos utilizados.Agradeço à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES),pelo suporte financeiro.

“Libertando-se a mente de todo trabalho desnecessário, uma boa notaçãoa deixa livre para concentrar-se em problemas mais avançados e, com efeito,aumenta o poder mental da raça.”

Alfred North Whitehead (1861 - 1947),citado em “An Introduction to Mathematics” de Alfred North Whitehead.

Resumo

Braga, Vinícius Gonçalves. Caracterização e Modelagem do Comportamentode Usuários de Mapas Web para Reprodução de Carga de Trabalho eAvaliação de Desempenho de Sistemas Baseados em Tiles. Goiânia, 2015.113p. Dissertação de Mestrado. Instituto de Informática, Universidade Federalde Goiás.

Sistemas de mapa Web, ou SIGs Web, são ferramentas importantes para orientaçãogeográfica e análise de dados espaciais. Nos últimos anos, o uso desse tipo de sistematem aumentado, bem como o desafio para garantir o desempenho frente ao aumento donúmero de usuários e do volume de dados. A avaliação de desempenho é uma importanteatividade para investigar e mitigar problemas de desempenho em sistemas. O ponto inicialda avaliação de desempenho é a carga de trabalho, responsável por enviar requisições aosistema sob avaliação. A confiabilidade dos resultados da avaliação depende de uma cargaadequada. Apesar da importância dos sistemas de mapa Web, existem poucos esforçosna literatura para modelar a carga de trabalho desse tipo de sistema. Nesta dissertação,apresentamos uma metodologia para coleta e análise de dados, visando a criação deum modelo do comportamento dos usuários de SIGs Web e sua instanciação em umgerador de cargas de trabalho. Propomos também um modelo genérico, chamado MUSe-GM (Maps User Session Generative Model), e apresentamos uma caracterização docomportamento dos usuários utilizando dados de acesso a um sistema de mapas popular,coletados a partir de uma extensão desenvolvida para o navegador Google Chrome. Osresultados da caracterização foram utilizados para a criação de uma instância do modelode comportamento e na implementação de um gerador de cargas. A instância foi avaliadaatravés de testes em um sistema de mapas real, utilizando o gerador de cargas, e por meiode simulações. Os resultados foram comparados aos de outros dois modelos da literatura.O modelo proposto nesta dissertação se mostrou significativamente diferente em váriosaspectos em relação aos outros dois, apresentando um comportamento mais próximo docomportamento de usuários reais.

Palavras–chave

Avaliação de Desempenho, Sistemas de Informação Geográfica, Sistemas deMapa Web, Web Map Tile Service

Abstract

Braga, Vinícius Gonçalves. Characterization and Modeling of the Web Map-ping System Users’ Behavior to Reproduce the Workload and to do Perfor-mance Evaluation of Based Tiles Systems. Goiânia, 2015. 113p. MSc. Disser-tation. Instituto de Informática, Universidade Federal de Goiás.

Web mapping systems, or Web GIS, are important tools for geographic orientation andspatial data analysis. In recent years, the use of these systems has increased, as well as thechallenge to ensure performance while the number of users and the data volume continueto grow. The performance evaluation is an important activity to investigate and mitigatesystems performance issues. The workload is the starting point of the performanceevaluation and is responsible for sending resquests to the system under evaluation. Thereliability of the evaluation results is related to an appropriate load. Despite the importanceof web map systems, the literature as presented little efforts to model the workload of thesesystems. In this dissertation, we present a methodology to collect and analyze data in orderto create a model of Web GIS users’ behavior and to instantiate the model in a workloadgenerator. We also propose a generic model, named MUSe-GM (Maps User SessionGenerative Model), and present a characterization of the users’ behavior using data ofthe access to a popular mapping application, collected by an extension developed for theGoogle Chrome browser. The characterization results were used to develop an instance ofthe behavior model and to implement a workload generator. The instance was evaluated bytesting in a real Web map system, using the workload generator, and through simulations.The results were compared with two other models from literature. The proposed modelin this dissertation was significantly different in several aspects compared to the other,presenting a behavior closer to the real users’ behavior.

Keywords

Performance Evaluation, Geographic Information Systems, Web Mapping Sys-tems, Web Map Tile Service.

Sumário

Lista de Figuras 12

Lista de Tabelas 17

Lista de Algoritmos 19

1 Introdução 201.1 Objetivos 221.2 Organização da dissertação 23

2 Fundamentos e Trabalhos Relacionados 242.1 Sistemas de mapa Web 242.2 Modelagem de cargas de trabalho 282.3 Técnicas estatísticas 292.4 Trabalhos relacionados 342.5 Conclusão 38

3 Metodologia para criação do modelo e proposta de um modelo de comportamento 393.1 Metodologia para criação do modelo 39

3.1.1 Definição das características necessárias para a modelagem do comporta-

mento dos usuários 393.1.2 Coleta dos dados 413.1.3 Análise dos dados coletados 423.1.4 Construção da carga sintética 43

3.2 MUSe-GM (Maps User Session Generative Model) 443.2.1 Camada de sessão 44

Duração e tamanho das sessões de navegação 45Intervalo entre ações 45Operação de arraste 45Operação de zoom 46Operação de pesquisa 46Operação de roteirização 47Frequência das operações e sequência de passos 47Popularidade dos tiles 47

3.2.2 Camada de transferência de tiles 48Resolução da tela vs. número de tiles 48Volume de dados transferidos 48

3.3 Conclusão 49

4 Caracterização dos dados coletados e instância do modelo 504.1 Descrição do conjunto de dados coletados 504.2 Caracterização do comportamento dos usuários 51

4.2.1 Duração e tamanho das sessões de navegação 514.2.2 Intervalo entre ações 524.2.3 Operação de arraste 544.2.4 Operação de zoom 594.2.5 Frequência das operações e sequência de passsos 614.2.6 Popularidade dos tiles 65

4.3 Camada de transferência de tiles 674.3.1 Resolução da tela vs. número de tiles 674.3.2 Volume de dados transferidos 69

4.4 Instância do modelo de comportamento 724.5 Conclusão 74

5 Avaliação do Modelo 755.1 Considerações iniciais 75

5.1.1 Modelo de tiles aleatórios 755.1.2 Modelo HELP 76

5.2 Simulações 775.2.1 Validação da instância do modelo 775.2.2 Comparação entre os modelos 79

Duração e tamanho das sessões de navegação 80Operação de arraste 81Operação de zoom 81Popularidade dos tiles 82Transferência de tiles 83

5.3 Estudo de caso: goGeo 855.4 Configuração do ambiente e metodologia de testes 865.5 Resultados obtidos 875.6 Conclusão 90

6 Conclusão e Trabalhos Futuros 916.1 Produção científica 926.2 Perspectivas para trabalhos futuros 93

Referências Bibliográficas 94

A Metodologia de coleta e análise dos dados 99A.1 Google Maps 99A.2 Metodologia de coleta 101

A.2.1 Comportamento dos clientes 101A.2.2 Tamanho dos tiles 103

A.3 Metodologia de análise dos dados 103A.3.1 Duração da sessão de navegação e intervalo entre ações 104A.3.2 Traço das ações 104A.3.3 Operação de arraste 105A.3.4 Operação de zoom 107

A.3.5 Operações de pesquisa e roteirização 107A.3.6 Regiões populares – lista de tiles 107

B Matriz de Transição do Modelo da Figura 4.15 110

Lista de Figuras

2.1 Pirâmide de tiles com os níveis de zoom de 0 a 2. 262.2 Exemplo da matriz de pixels para tiles fictícios de resolução 5x5 px. 262.3 Gráfico de densidade dos dados Artificiais. 312.4 Comparação gráfica da adequação dos dados Artificiais com a distribui-

ção Lognormal com parâmetros µ = 3,99 e σ = 0,51. 32(a) Comparação da PDF empírica dos dados Artificiais com a PDF da

distribuição Lognormal. 32(b) Comparação da CDF empírica dados Artificiais com a CDF da

distribuição Lognormal. 322.5 Gráfico Q-Q entre os dados Artificiais e a distribuição Lognormal com

parâmetros µ = 3,99 e σ = 0,51. 33

3.1 Modelo alto nível do comportamento de um cliente de aplicação de mapaWeb durante uma sessão de navegação. 44

4.1 Ajuste da distribuição Lognormal aos dados da duração das sessões e daWeibull ao número de ações por sessão. 52(a) CDF empírica da duração das sessões em segundos vs. Lognormal

com µ = 4,472433 e σ = 1,77819. 52(b) CDF empírica do número de ações por sessão vs. Weibull com

β = 0,92590195 e α = 17,83891039. 524.2 Ajuste da Lognormal-GPD (com θ = 1,107957, µ = 0,6682218, σ =

0,5779033, τ = 2,166933 e ξ = 0,8950732) aos dados dos intervalosentre as ações dos usuários. 54

4.3 Análise do tamanho dos arrastes. 55(a) PDF do tamanho dos arrastes em pixels. 55(b) Média do tamanho dos arrastes, em pixels, por nível de zoom. 55

4.4 Correlação entre o tamanho dos arrastes e o nível de zoom. 56(a) Correlação entre o tamanho dos arrastes no eixo x e o nível de zoom.

y = 4,38x+107,28, R2 = 0,4018. 56(b) Correlação entre o tamanho dos arrastes no eixo y e o nível de zoom.

y = 6,589x+87,787, R2 = 0,7056. 564.5 Regressão linear nas estimativas dos parâmetros da Geométrica ajustada

à distribuição empírica do tamanho dos arrastes por nível de zoom. 57(a) Estimativa do parâmetro p da distribuição Geométrica por nível

de zoom para os arrastes no eixo x utilizando regressão linear.y =−0,0001376x+0,0079955. 57

(b) Estimativa do parâmetro p da distribuição Geométrica por nívelde zoom para os arrastes no eixo y utilizando regressão linear.y =−0,0002038x+0,0085857. 57

4.6 Adequação da distribuição Geométrica, com parâmetros estimados apartir da função y=−0,0002038x+0,0085857, ao tamanho dos arrastesno eixo y. 57

4.7 Modelagem da direção e sentido dos arrastes. Algumas transições foramocultadas na figura por motivos estéticos. Todos os estados estão interli-gados segundo as probabilidades apresentadas na Tabela 4.5. 58

4.8 Exemplo de saída do modelo de direções e sentido do arraste. 594.9 PDF do uso do mapa por nível de zoom. 594.10 Tamanho dos saltos na operação de zoom. 604.11 Tamanho dos saltos na operação de zoom. 614.12 Adequação da distribuição Geométrica aos dados do tamanho dos movi-

mentos da operação de zoom. 62(a) Tamanho dos movimentos da operação de zoom, em relação ao eixo

x, vs. Distribuição Geométrica com p = 0,0138865319. 62(b) Tamanho dos movimentos da operação de zoom, em relação ao eixo

y, vs. Distribuição Geométrica com p = 0,0086910695. 624.13 Frequência relativa das operações. 634.14 Comparação das distribuições propostas por Guan et al. [21], utilizando

(a) parâmetros que se ajustam aos dados coletados e (b) os parâmetrossugeridos pelos autores. 64(a) Frequência relativa das operações de Arraste, Zoom in e Zoom out

por nível de zoom, utilizando às funções propostas por Guan et al.[21] com os valores dos parâmetros sugeridos pelos autores: λ = 3e ω = 0,9. 64

(b) Frequência relativa das operações de Arraste, Zoom in e Zoom outpor nível de zoom. As linhas tracejadas representam a adequaçãoàs funções propostas por Guan et al. [21] com parâmetros λ =0,5 e ω = 0,4 e as linhas contínuas representam as distribuiçõesempíricas geradas a partir dos dados coletados. 64

4.15 Modelo de estados da sequência de passos. 654.16 Popularidade dos tiles (a) e ajuste da distribuição Zipf à distribuição de

frequência de popularidade(b). 66(a) Popularidade dos tiles. O eixo x contém o número de acessos a um

tile e o eixo y a quantidade de tiles que tiveram aquele número derequisições. 66

(b) Ajuste à distribuição Zipf com α = 1,565501. O eixo x contém oíndice de popularidade dos tiles e o eixo y a frequência acessos aostiles com índice x. A reta vermelha representa o ajuste. 66

4.17 Mapa de calor a nível mundial. 664.18 Mapa de calor a nível estadual, com foco em Goiânia e Brasília. 674.19 10 resoluções mais frequentes (em pixels). 684.20 Distribuição do número de tiles requisitados por operação de arraste. 684.21 Distribuição do número de tiles requisitados por operação de zoom. 694.22 CDFs da quantidade de dados transferidas por operação de arraste e zoom. 69

(a) CDF da quantidade de dados do conjunto de tiles requisitado poroperação de arraste. 69

(b) CDF da quantidade de dados do conjunto de tiles requisitado poroperação de zoom. 69

4.23 CDF da quantidade média de dados transferidos por operação. 704.24 Avaliação da quantidade de dados transferidas por sessão e da taxa

média de transferência de dados. 71(a) CDF da quantidade de dados transferidos por sessão, considerando

todas as requisições (TR) e considerando apenas as requisições atiles (Tiles). 71

(b) CDF da taxa média de transferência de dados durante as sessões denavegação. 71

4.25 Exemplo de saída de simulação da instância do modelo. 74

5.1 Lista de tiles dos EUA no nível de zoom 5. A imagem de fundo foi obtidado MapTiler [28]. 76

5.2 Comparação da duração e do número de ações nas sessões do MUSe-GM com os dados coletados das sessões de usuários reais. 78(a) CDF do número de ações em uma sessão simulada baseada no

MUSe-GM. 78(b) CDF do número de ações em uma sessão simulada baseada no

MUSe-GM. 785.3 Comparação do tamanho dos arrastes nas sessões do MUSe-GM com os

dados coletados das sessões de usuários reais. 79(a) Distribuições do tamanho dos arrastes no eixo x dos dados coleta-

dos e dos dados simulados. 79(b) Distribuições do tamanho dos arrastes no eixo y dos dados coleta-

dos e dos dados simulados. 795.4 Distribuição do tamanho dos saltos na operação de zoom das sessões

simuladas pelo MUSe-GM. 795.5 Comparação da duração e do número de ações nas sessões do MUSe-

GM e do HELP. 80(a) CDFs da duração de sessões de navegação do MUSe-GM e do HELP. 80(b) CDFs do número de ações de sessões de navegação do MUSe-GM

e do HELP. 805.6 Tamanho dos arrastes nos modelos MUSe-GM e HELP. 81

(a) Gráfico de densidade do tamanho dos arrastes no MUSe-GM. 81(b) Frequência de tamanho dos arrastes no HELP. 81

5.7 Frequências de uso dos níveis de zoom nos modelos MUSe-GM e HELP. 82(a) Frequência de uso dos níveis de zoom dos usuários simulados

baseados no MUSe-GM. 82(b) Frequência de uso dos níveis de zoom dos usuários simulados

baseados no HELP. 825.8 Frequências de uso dos níveis de zoom nos modelos MUSe-GM e HELP. 83

(a) Mapa de calor dos tiles requisitados pelo MA. 83(b) Mapa de calor dos tiles requisitados pelo HELP. 83(c) Mapa de calor dos tiles requisitados pelo MUSe-GM. 83

5.9 Distribuição do número de tiles requisitados por operação de arraste noMUSe-GM e no HELP. 84(a) Distribuição do número de tiles requisitados por operação de arraste

no MUSe-GM – valores acima de 21 foram omitidos por serempouco representativos. 84

(b) Distribuição do número de tiles requisitados por operação de arrasteno HELP. 84

5.10 Distribuição do número de tiles requisitados por operação de zoom noMUSe-GM e no HELP. 84(a) Distribuição do número de tiles requisitados por operação de zoom

no MUSe-GM. 84(b) Distribuição do número de tiles requisitados por operação de zoom

no HELP. 845.11 CDFs do número de tiles requisitados por sessão de navegação no

MUSe-GM e no HELP. 85(a) CDF do número de tiles requisitados por sessão de navegação no

MUSe-GM. 85(b) CDF do número de tiles requisitados por sessão de navegação no

HELP. 855.12 Configuração do ambiente de testes. 865.13 Comparação dos três modelos em relação ao número médio de requisi-

ções por segundo e tempo médio de resposta das requisições. 88(a) Comparação dos três modelos em relação ao número de médio de

requisições por segundo. 88(b) Comparação dos três modelos em relação ao tempo médio de

resposta as requisições. 885.14 Tempo de médio de resposta do sistema quando executado com 90

clientes do MA. Ênfase ao momento do colapso, com aumento súbito novalor medido. 88

5.15 Comparação entre as médias de conexões por segundo dos três modelos. 895.16 Comparação entre o número de ações e de tiles requisitados no HELP e

o MUSe-GM em sessões de 10 minutos. 90(a) Comparação entre as CDFs do número de ações em sessões de 10

minutos do HELP e do MUSe-GM. 90(b) Comparação entre as CDFs do número de tiles requisitados em

sessões de 10 minutos do HELP e do MUSe-GM. 90

A.1 Inicialmente, o mapa estava no nível de zoom 15 (a) e após uma operaçãode zoom in passou para o nível 16 (b). 100(a) Nível de zoom 15. 100(b) Nível de zoom 16. 100

A.2 Diagrama de sequência do fluxo de coleta da extensão. 102A.3 Diagrama ER dos dados coletados pela extensão. 103A.4 Coleta das estampas de tempo para cálculo do intervalo entre ações e

para o cálculo da duração das sessões de navegação. 104A.5 Exemplo do cálculo do tamanho de um arraste. As imagens de fundo são

do Google Maps. 106

A.6 Identificação dos tiles visualizados na tela. A imagem de fundo é doGoogle Maps. 109

Lista de Tabelas

2.1 Notações e siglas adotadas. 302.2 Distribuições estatísticas utilizadas no modelo de carga de trabalho Web

de Barford e Crovella [2]. 342.3 Exemplos de cenários apresentados por Ray et al. [36]. 36

3.1 Informações necessárias para se modelar cada característica do compor-tamento dos usuários e o volume de dados transferidos. 41

4.1 Resumo quantitativo dos dados coletados. 514.2 Informações sobre os grupos de usuários, obtidos através do uso do k-

means. 514.3 Estimativas dos parâmetros da Lognormal-GPD ajustada à distribuição

empírica dos intervalos entre ações dos usuários. 544.4 Coeficientes da correlação entre a média do tamanho dos arrastes e o

nível de zoom. 554.5 Matriz de transição do modelo da Figura 4.7. 584.6 Matriz de transição do modelo da direção/sentido da operação de zoom. 624.7 Média e principais percentis da quantidade de dados transferidos por

operação de arraste e de zoom, levando em consideração apenas ostamanhos das imagens dos tiles. 70

4.8 Média e principais percentis da quantidade média de dados transferidospor operação. 70

4.9 Média e principais percentis das quantidades de dados transferidos porsessão de navegação, considerando todas as requisições e considerandoapenas as requisições a tiles. 71

4.10 Média e principais percentis da taxa média de transferência de dados porsessão de navegação. 71

5.1 Variáveis do HELP e suas respectivas distribuições e valores. 775.2 Estatísticas descritivas da duração das sessões de navegação do MUSe-

GM e do HELP. 805.3 Estatísticas descritivas do número de ações do MUSe-GM e do HELP. 81

B.1 Matriz de transição do modelo de estados que representa a sequência depassos dos usuários - parte 1. 110



Lista de Algoritmos

4.1 Algoritmo da instância do MUSe-GM – Simula uma sessão de navegação. 73A.1 Identificação da operação realizada pelo usuário. 105A.2 Identificação do conjunto de tiles dispostos na tela. 108

CAPÍTULO 1Introdução

Sistemas de mapa Web, como o Google Maps [20] e o Bing Maps [30], setornaram ferramentas importantes para visualização de mapas e orientação geográfica.Esses sistemas são exemplos do que se pode construir com a tecnologia conhecida comoSistemas de Informação Geográfica (SIG). Por isso, são também chamados de Sistemasde Informação Geográfica Web, ou simplesmente SIG Web. Os SIGs Web podem permitir,dentre outras operações, a busca por locais específicos por meio de nome ou endereço, abusca por locais genéricos através de uma palavra-chave, a criação de rotas entre dois oumais pontos e a visualização da situação do trânsito.

Embora sejam menos populares, há diversos serviços de mapa Web que oferecemfuncionalidades mais específicas e permitem a inserção de dados geolocalizados e avisualização desses dados em mapas, como a plataforma goGeo [16], o Google MapsEngine [27] e o CartoDB [8]. Esses serviços são cada vez mais procurados por empresas,as quais têm interesse em visualizar seus dados geolocalizados a fim de definir melhoresestratégias de mercado, logística e investimentos. Os governos também utilizam essetipo de serviço para melhorar as ações na saúde e segurança pública [9, 19], para criarestratégias de prevenção e mitigação de tragédias [18], dentre outros propósitos.

Um problema crítico no desenvolvimento de qualquer aplicação Web, é garantiro desempenho a medida que o número de usuários e o volume de dados aumentam. Asaplicações de mapas possuem algumas peculiaridades que tendem a adicionar comple-xidade a esse problema. Nos últimos anos, houve um grande aumento na quantidade dedados espaciais, principalmente devido a proliferação de tecnologias de posicionamento,como os dispositivos móveis com GPS [1]. Além do aumento no volume de dados, o au-mento do número de usuários tem contribuído para a queda no desempenho dos serviçosde mapa [21].

Os principais fatores que afetam o desempenho de um sistema são o projeto,a implementação e a carga de trabalho a qual o sistema é submetido [11]. Os doisprimeiros fatores são bem conhecidos pelos desenvolvedores. Todavia, poucas iniciativasforam apresentadas, até o momento, para tratar o terceiro fator de maneira adequadapara aplicações de mapa Web. Os SIGs Web oferecem uma interação mais dinâmica

21

do que a maioria dos outros sistemas Web, contendo operações de navegação em mapa– como arraste, aproximação (zoom in) e afastamento (zoom out) – que possuem seuspróprios padrões. Esses padrões diferem do padrão comum de navegar clicando emlinks das aplicações Web tradicionais [46]. Essa diferença faz com que uma avaliação dedesempenho baseada em benchmarks para serviços Web tradicionais, não seja adequadapara os SIGs Web.

Usualmente, o desempenho de serviços de mapa Web é avaliado utilizandoreprodução de logs ou benchmarks de estresse [26, 32], com requisições a um conjuntoestático de tiles ou requisições a tiles aleatórios [21]. Esses benchmarks são apropriadospara comparação de determinados aspectos de diferentes sistemas e para detecção degargalos. No entanto, a carga gerada por eles tende a ser muito diferente da observadano sistema em produção. A reprodução de logs, embora fácil de utilizar, não ofereceuma alternativa simples para se ajustar a carga de trabalho a fim de simular condiçõesfuturas e variação de demanda [2]. Além disso, os logs não estão disponíveis parasistemas em desenvolvimento [21], os quais necessitam de outra alternativa para avaliarseu desempenho com uma carga de trabalho mais próxima da carga real.

Sem o conhecimento das características da carga real, não é possível identificaras operações que irão impactar o desempenho do sistema em produção. Essa informaçãoé importante para priorizar as atividades de desenvolvimento, com o intuito de melhoraras operações que são mais utilizadas pelos usuários. Um dos resultados deste trabalhomostra que as operações de arraste e zoom correspondem a cerca de 80% das operaçõesrealizadas no mapa. Isso sugere que melhorar o desempenho da renderização e da cache

das imagens do mapa pode afetar um percentual significativo das atividades dos usuários.Apesar da importância de se conhecer e modelar as cargas de trabalho de usuários

de aplicações SIG Web, a literatura apresenta poucos trabalhos sobre o assunto. Algunstrabalhos tentam simular a carga real de aplicações SIG e seus efeitos em bancos dedados geográficos [36, 41]. No entanto, a carga de trabalho foi projetada a partir daexperiência dos autores na indústria de SIG, sendo composta por bases de dados econsultas comumente utilizadas pelos sistemas nos quais eles trabalharam.

Romoser et al. [37] têm uma motivação similar a do nosso trabalho, masbuscaram caracterizar a carga de trabalho do USGS EROS, um sistema que permite aosusuários navegar e obter imagens da Terra tiradas por satélites da NASA. O trabalho seconcentrou em aspectos específicos do sistema USGS EROS, como o padrão de download

das imagens, os quais não podem ser generalizados para aplicações de mapa Web de usogeral, como o Google Maps.

Recentemente, Guan et al. [21] desenvolveram um trabalho com objetivos seme-lhantes aos nossos. Esse trabalho apresentou uma modelagem teórica que aborda caracte-rísticas do comportamento dos usuários de SIGs Web. Os autores se basearam na literatura

1.1 Objetivos 22

existente sobre cargas de trabalho para sistemas Web em geral e em seu conhecimento em-pírico sobre a navegação em SIGs Web para criar o modelo. Por outro lado, nosso trabalhofoi baseado em dados de acesso a uma aplicação de mapa real, o que também nos permitiurealizar uma investigação mais detalhada sobre o comportamento dos usuários.

Neste trabalho, definimos aspectos relevantes do comportamento dos usuáriosde aplicações de mapa Web e propomos um modelo desse comportamento durante umasessão de navegação. O modelo, chamado de MUSe-GM (Maps User Session Generative

Model), abrange aspectos como o intervalo de tempo entre as ações dos usuários, aduração das sessões, a sequência de passos dos usuários, dentre outros. Este trabalhotambém apresenta uma discussão detalhada sobre as operações de navegação (arraste ezoom), uma vez que, além de serem as operações mais utilizadas, são comuns a todosistema de mapa.

Apresentamos também a metodologia empregada para a construção e utilizaçãodo modelo proposto na implementação de um gerador de cargas. A metodologia contéma definição de aspectos relevantes do comportamento dos usuários de aplicações de mapaWeb e uma listagem das informações necessárias para se investigar esses aspectos.

Na fase de coleta de dados, devido a ausência de logs de SIGs Web disponíveispublicamente, desenvolvemos uma extensão para o navegador Google Chrome e coleta-mos, de maneira anônima, dados de acesso ao Google Maps. Com os dados coletados,realizamos diversas análises que nos permitiram construir uma instância do modelo pro-posto e utilizá-la como base para a criação de um gerador de cargas. O gerador de cargasfoi utilizado na avaliação de desempenho de um sistema de mapas real, a plataforma go-Geo. A goGeo foi avaliada com outras duas cargas, sendo uma baseada em um benchmark

de estresse [26] e a outra implementada a partir do modelo HELP, proposto por Guan et

al. [21]. Os resultados das avaliações confirmaram as diferenças entre o nosso modelo eos outros dois utilizados na comparação.

A seguir, apresentamos os principais objetivos deste trabalho e, por fim, como otexto está organizado nos demais capítulos.

1.1 Objetivos

O objetivo geral deste trabalho é propor um modelo estatístico do comporta-mento padrão de usuários de sistemas de mapa Web, o qual possa ser instanciado emum gerador de carga de trabalho para a avaliação de desempenho desse tipo de sistema.O modelo proposto deve contemplar as principais características do comportamento dosusuários e abranger as operações mais comuns em sistemas de mapa de uso geral: arraste,zoom in/out, pesquisa e roteirização. Para atingir esse objetivo geral, algumas atividadesintermediárias foram definidas:

1.2 Organização da dissertação 23

• Identificar o conjunto de características importantes para modelar o comportamentodos usuários de sistemas de mapa Web.• Coletar dados e extrair as informações que permitam parametrizar o modelo esta-

tisticamente.• Desenvolver uma instância do modelo e um gerador de cargas a partir dessa

instância.• Comparar o efeito produzido pelo gerador de cargas em um sistema de mapa Web

real com o efeito produzido por outras cargas de trabalho da literatura.

1.2 Organização da dissertação

O restante do texto está organizado em mais cinco capítulos, conforme apresen-tado a seguir. No Capítulo 2, introduzimos alguns conceitos fundamentais sobre aplica-ções de mapa Web e avaliação de desempenho. Esse capítulo também descreve alguns tra-balhos relacionados a esta pesquisa. No Capítulo 3, propomos uma metodologia, na qualdefinimos aspectos importantes para a modelagem do comportamento típico de usuáriosde um SIG Web. Além disso, descrevemos como coletar e analisar dados a fim de atingiresse objetivo e, ainda, como utilizar o modelo para a criação de um gerador de cargas. NoCapítulo 3, apresentamos também a proposta de um modelo de duas camadas. A primeiracamada trata do comportamento dos usuários em uma sessão de navegação e a segundaaborda a relação entre a sessão de navegação e a transferência de tiles e de dados na rede.

No Capítulo 4, apresentamos uma caracterização do comportamento típico dosusuários, baseada nos dados coletados. Comentamos também o potencial impacto douso dessas aplicações na rede, em termos do número de tiles e do volume de dadostransferidos. Apresentamos, ainda, uma instância do modelo proposto, contemplando asequência de ações dos usuários e o uso das operações de arraste e zoom.

No Capítulo 5, apresentamos os resultados da avaliação do modelo, realizadaatravés de simulações implementadas no Software R [35] e de testes em um sistema demapas Web real. Nos testes, comparamos o comportamento do sistema quando submetidoa uma carga implementada a partir do nosso modelo e quando submetido a outras duascargas. Por fim, o Capítulo 6 sintetiza as contribuições do trabalho e discute perspectivaspara os trabalhos futuros.

CAPÍTULO 2Fundamentos e Trabalhos Relacionados

Neste capítulo, apresentaremos alguns conceitos importantes relacionados aesta pesquisa. Na Seção 2.1, introduzimos algumas noções básicas sobre sistemas demapa Web. Na Seção 2.2, mostramos conceitos sobre modelagem de carga de trabalhoe abordamos, na Seção 2.3, algumas das técnicas estatísticas utilizadas neste trabalho.Por fim, discutimos, na Seção 2.4, sobre alguns trabalhos importantes que tratam demodelagem de cargas e sobre o comportamento de usuários de sistemas de mapa Web.

2.1 Sistemas de mapa Web

Um Sistema de Informações Geográfica (SIG) é um tipo de ferramenta com-putacional capaz de extrair informações baseadas em localização e construir relatórios emodelos visuais representando essas informações. Esses modelos são conhecidos comomapas geográficos. Nos últimos anos, o uso da tecnologia SIG tem se tornado mais aces-sível através de aplicações de mapa Web, ou SIGs Web.

Os SIGs Web podem oferecer diferentes tipos de serviços. As aplicações maispopularmente conhecidas são os sistemas como o Google Maps e o Microsoft BingMaps, os quais oferecem serviços de pesquisa e de criação de rotas e são voltados para opúblico geral. No entanto, existem aplicações mais específicas direcionadas para o públicoempresarial, acadêmico ou mesmo governos, que oferecem serviços que permitem a essasinstituições analisarem as relações espaciais de seus dados. Como exemplo, podemos citaro Visualizador da INDE [22] (Infraestrutura Nacional de Dados Espaciais), o qual oferecea possibilidade de cruzamento de diversas informações georreferenciadas do Brasil, alémde serviços de medição de área e de distâncias. Existem também plataformas como agoGeo [16], o CartoDB [8] e o Google Maps Engine Pro [27] que oferecem serviçosde criação de mapas customizados, os quais possibilitam aos usuários inserir e cruzardiferentes camadas de dados a fim de extrair relações entre eles.

As primeiras aplicações de mapa Web foram criadas na segunda metade dosanos 1990 e tinham uma série de limitações. A renderização e o download das imagenseram lentos, porque a parte do mapa apresentada na tela era representada por uma

2.1 Sistemas de mapa Web 25

única imagem. A cada movimento realizado pelo usuário, a imagem inteira precisavaser renderizada, mesmo que apenas uma parte dela fosse nova [39]. Desde então, algunspadrões surgiram para promover disponibilidade e reuso nas aplicações de mapa.

O Consórcio Geoespacial Aberto (Open Geospatial Consortium - OGC) publi-cou em 2006 o padrão Web Map Service (WMS) [3] que especificava uma maneira flexí-vel de se obter mapas digitais através do protocolo HTTP. Esse padrão foi desenvolvidovisando a renderização de mapas customizados. Através de parâmetros bem definidos,passados na URL, o usuário pode requisitar mapas com a informação, estilo, local noplaneta Terra, sistema de coordenada de referência e tamanho da imagem desejados. Eleainda permite que dois ou mais mapas possam ser sobrepostos de maneira acurada paraformar um novo mapa [3]. Apesar de toda a flexibilidade, o WMS possui uma limitaçãoquanto ao uso de cache. Como pelo menos dois de seus parâmetros são contínuos (localno planeta Terra e o tamanho da imagem), a probabilidade de que dois ou mais usuáriossolicitem imagens com os mesmos parâmetros é bem pequena [14].

Em 2010, o OGC especificou o padrão Web Map Tile Service (WMTS) [29],o qual resolve alguns dos problemas encontrados no WMS. No WMTS, o mapa édividido em um conjunto discreto e finito de imagens, chamadas de tiles. Por limitaro conjunto de imagens que os usuários podem requisitar, o padrão de tiles permiteque elas sejam colocadas em cache. Com essa abordagem, também é possível gerar asimagens previamente, melhorando de forma significativa a Qualidade de Serviço (Quality

of Service - QoS) entregue aos usuários. Outra vantagem de se dividir o mapa em imagensmenores, é que quando o usuário arrasta o mapa, apenas as imagens referentes a parte novado mapa são requisitadas, diminuindo o tráfego de rede. Atualmente, o modelo de tiles éextensamente utilizado, sendo empregado em sistemas como Google Maps, Bing Maps eOpenStreetMap1.

No padrão de tiles, podem ser utilizadas diferentes projeções para o esquema dedivisão do mapa, mas a projeção mais comum e utilizada pelos grandes serviços de mapacomo o Google Maps é a projeção de Mercator [39]. O esquema de tiles nessa projeçãorepresenta a Terra em duas dimensões de tamanhos iguais (um quadrado). Nesse caso, aquantidade de tiles é igual em ambos os eixos e cresce exponencialmente a medida queo nível de zoom aumenta, seguindo a regra 4zoom. Os vários níveis de zoom formam umapirâmide de tiles, como ilustrado na Figura 2.1, a qual mostra a divisão do mapa em tiles

até o nível de zoom 2. Nos níveis de zoom 0, 1 e 2, a quantidade de tiles é igual a 40, 41 e42, respectivamente.

A resolução de todos os tiles (Rt) em um sistema são iguais e, usualmente,utiliza-se a resolução de 256x256 px. Da mesma forma que a quantidade de tiles segue a

1OpenStreetMap: http://www.openstreetmap.org/


Figura 2.1: Pirâmide de tiles com os níveis de zoom de 0 a 2.

regra 4zoom, a resolução da imagem do mapa segue a regra 4zoom×Rt. A imagem do mapaem cada nível, além de possuir sua própria matriz de tiles, possui também uma matriz depixels, como mostrado na Figura 2.2. A Figura 2.2 apresenta a matriz de tiles do nívelde zoom 2 e parte da matriz de pixels da imagem. A resolução de tiles 5x5 px é fictícia eutilizada apenas para simplificar a figura. Como ilustrado, é possível identificar cada tile

e cada pixel de uma imagem de forma única. Para identificar um tile é suficiente utilizar oconjunto (Z,xt ,yt), onde Z é o nível de zoom e (xt ,yt) é o par ordenado do tile na matrizde tiles. O procedimento para a identificação dos pixels é o mesmo.

Figura 2.2: Exemplo da matriz de pixels para tiles fictícios deresolução 5x5 px.

Para identificar a qual tile pertence um determinado pixel (xp,yp) de um nível dezoom Z, a seguinte expressão pode ser utilizada:

(xt ,yt) =⌊( xp

T S,

yp

T S

)⌋, (2-1)


onde T S é o tamanho do lado do tile em pixels. Como exemplo, na resolução de 256x256px, o valor de T S é 256.

Os SIGs Web fazem um mapeamento entre o sistema de coordenadas geográficase as imagens do mapa. Dessa forma, a partir do nível de zoom e das coordenadas geográ-ficas (latitude e longitude), pode-se identificar o tile referente a essas coordenadas. Naprojeção de Mercator, é possível transformar as coordenadas geográficas em coordenadasde tiles utilizando a seguinte expressão:

(xt ,yt) = b(xc,yc)c , (2-2)

onde os valores de xc e yc são obtidos através das equações:

xc =lon+180

360×2zoom, (2-3)

yc =

1−ln(

tan(lat ∗ π

180

)+ 1

cos(lat∗ π180)

)π

×2zoom−1, (2-4)

sendo que lon é a longitude e lat é a latitude.A transformação de coordenadas geográficas para coordenadas de pixel pode ser

feita pela expressão:

(xp,yp) = b(xc×T S,yc×T S)c . (2-5)

Por fim, o processo inverso para recuperar as coordenadas geográficas, dados onível de zoom e as coordenadas de tiles, (xt ,yt), pode ser realizado através das equaçõesa seguir:

lon =xt

2zoom ×360−180, (2-6)

lat = arctan(

sinh(

π− yt

2zoom ×2π))× 180

π. (2-7)

As aplicações de mapa requisitam os tiles necessários para se preencher todo oespaço dedicado ao mapa na tela. Esse espaço é chamado de caixa delimitadora (Bounding

Box). Durante o texto, adotaremos o termo Bounding Box, por ser o mais comumenteutilizado na área de SIG.

As operações mais comuns nos sistemas de mapa Web voltados ao público geralsão as de arraste, zoom in/out, de pesquisa e de roteirização (ou rota). O arraste e o zoom

são as operações mais básicas e essenciais. Eles permitem a navegação no mapa e são

2.2 Modelagem de cargas de trabalho 28

necessários para que o usuário possa direcionar o mapa para uma região de interessee regular o nível de detalhes apresentado. A pesquisa, geralmente, oferece serviços degeocodificação e geocodificação reversa, os quais permitem aos usuários encontrar umponto no mapa através do endereço ou encontrar um endereço de um ponto no mapa,respectivamente. A roteirização permite aos usuários criarem rotas entre dois ou maispontos, utilizando diferentes meios de transporte como carro, avião, transporte público oumesmo a pé.

Neste trabalho, consideramos como SIG Web os sistemas de mapa que entregamseu serviço via navegador Web e que utilizam o padrão de tiles. Como apresentado, essetipo de sistema pode disponibilizar vários tipos de operações. No entanto, trabalharemosapenas com as quatro operações citadas acima, por serem as mais comuns e disseminadas.Elas estão presentes tanto em sistemas de uso geral, como o Google Maps e o Bing Maps,quanto em sistemas de público mais específico como o Google Maps Engine Pro.

2.2 Modelagem de cargas de trabalho

A avaliação de desempenho é uma atividade importante no desenvolvimento desistemas computacionais. Ela é usada para comparar alternativas de arquitetura e projeto,comparar a capacidade de diferentes sistemas, verificar a capacidade máxima de umsistema e para planejamento de capacidade [10, 11]. Uma avaliação de desempenhoadequada ajuda a entender melhor o sistema avaliado e suas capacidades, a tomarmelhores decisões de projeto e fazer um melhor uso dos recursos computacionais. Aprincipal ferramenta de uma avaliação de desempenho é a carga de trabalho. Ela exercitao sistema sob avaliação e o comportamento dele é influenciado pelas característicasda carga. Exercitar um sistema com uma carga de trabalho inadequada, pode produzirresultados que levem a uma avaliação e a um planejamento de capacidade errados [2, 11].

Apesar da importância de se ter acesso à carga real de um sistema para analisarseu desempenho, nem sempre a carga é conhecida. Portanto, é necessário utilizar cargasde trabalho sintéticas com características o mais próximo possível da carga real [11]. Ascargas sintéticas são obtidas através de modelos estatísticos, gerados a partir de mediçõesda carga real, geralmente armazenadas como logs ou traces de um sistema [2].

Modelos de carga de trabalho podem ser divididos em duas classes: modelosdescritivos e modelos generativos [11]. Os modelos descritivos procuram identificar eimitar as características mais importantes observadas na carga de trabalho imposta aosistema. A abordagem mais comum é a criação de um sumário estatístico da carga, o qualé empregado para gerar a carga sintética [11]. Em um sistema Web, pode-se, por exemplo,monitorar as requisições e modelar o processo de chegada através de uma distribuição

2.3 Técnicas estatísticas 29

de probabilidade. Essa distribuição é então utilizada no procedimento de criação dasrequisições sintéticas.

Os modelos generativos, por outro lado, procuram emular o processo que geroua carga de trabalho [11]. No caso do sistema Web, em vez de se modelar o processo dechegada das requisições, procura-se modelar o comportamento dos clientes que geramessas requisições. Ao emular os clientes, a carga de trabalho gerada terá as mesmas carac-terísticas da carga real, contudo, no modelo generativo, o controle sobre a carga sintéticaé maior, uma vez que, é possível configurar a quantidade de clientes. Dessa forma, omodelo generativo permite não apenas reproduzir a carga gerada, como também permitemanipulá-la, possibilitando investigar o comportamento do sistema quando submetido aum número variado de usuários.

A influência da carga de trabalho no desempenho de um sistema depende tantoda sua intensidade quanto de sua natureza [25]. Em sistemas de mapa Web, por exemplo,existem locais, chamados de hotspots, que são mais acessados do que outros [12, 21].Conhecer essa característica (natureza) da carga é vantajoso para que se possa pré-processar e manter os tiles mais acessados em cache, melhorando assim a qualidade doserviço entregue ao cliente [14, 15].

Barford e Crovella (1998) mostraram como os benchmarks utilizados na épocaproduziam resultados equivocados por não levarem em consideração características im-portantes da carga real de sistemas Web [2]. De forma semelhante, os benchmarks uti-lizados atualmente para avaliar o desempenho de sistemas de mapa Web desconsideramdiversas características particulares desse tipo de sistema.

2.3 Técnicas estatísticas

A modelagem da carga de trabalho de sistemas recorre a técnicas da estatísticapara compreender as características e padrões presentes no acesso aos sistemas. Nestaseção, iremos apresentar algumas das técnicas utilizadas neste trabalho. A fim de tornarmais clara a explicação, utilizaremos um conjunto de dados fictícios, chamados Artificiais,para exemplificar as técnicas de modelagem estatística. Durante o texto, utilizaremos asnotações e siglas apresentadas na Tabela 2.1.

Cada característica de um modelo é tratada como uma variável aleatória e ainvestigação do comportamento dessa variável, inicialmente, recorre a análises gráficas. Ohistograma da variável ou um gráfico de densidade permite observar como os dados estãodistribuídos e evidencia a presença ou não de padrões. Isso permite a identificação dosmodelos probabilísticos que podem ser mais adequados para modelá-la. Esses modelossão definidos como funções massa de probabilidade para variáveis discretas ou comofunções densidade de probabilidade para variáveis contínuas. As pdfs/pmfs de algumas


Notações/ DescriçãoSiglasx1,x2,xi realizações da variável aleatória XProb(.) probabilidade de um evento aleatóriof (x) função densidade de probabilidade (Probability Density Function - pdf)p(x) função massa de probabilidade (Probability Mass Function - pmf)µ média aritmética de uma distribuiçãoσ desvio padrão de uma distribuiçãoa estimador de um parâmetro aI{.} função indicadora de um conjuntoPDF Função Distribuição de Probabilidade (Probability Distribution Function)CDF Função Cumulativa de Probabilidade (Cumulative Distribution Function)

Tabela 2.1: Notações e siglas adotadas.

das distribuições mais comuns na literatura [2, 45] e utilizadas ou citadas neste trabalhosão apresentadas a seguir:

• Geométrica:

p(x; p) = p(1− p)x. (2-8)

• Binomial Negativa:

p(x;r, p) =Γ(x+ r)Γ(r)x!

pr(1− p)x. (2-9)

• Zipf:

p(i;C,α) =Ciα. (2-10)

• Lognormal:

f (x;µ,σ) =e−

(lnx−µ)2

2σ2

xσ√

2π. (2-11)

• Weibull:

f (x;α,β) =βxβ−1

αβe(x/α)β . (2-12)

• Pareto:

f (x;k,α) = αkαx−(α+1). (2-13)

• Exponencial:


f (x;λ) = λeλx. (2-14)

A Figura 2.3 mostra o gráfico de densidade dos dados Artificiais. Através dessegráfico é possível observar a distribuição dos dados Artificiais e selecionar os modelosque melhor se ajustem a eles. O formato da curva sugere que uma distribuição Lognormalpode ser um modelo adequado.

0 50 100 200 300

0.00

00.

005

0.01

00.

015

Valores

Pro

babi

lidad

e

Figura 2.3: Gráfico de densidade dos dados Artificiais.

Para verificar a adequação dos dados Artificiais à Lognormal, primeiramente,deve-se encontrar estimativas adequadas para os parâmetros µ e σ. Os estimadores dessesparâmetros são dados pelas seguintes equações:

µ =1n

n

∑i=1

lnxi, (2-15)

σ =

√1

n−1

n

∑i=1

(lnxi− µ)2. (2-16)

Uma das maneiras mais utilizadas para se encontrar os estimadores é o método deestimação por máxima verossimilhança (Maximum Likelihood Estimation - MLE). Sendoθ um parâmetro que define uma distribuição, o MLE é uma função que busca encontrar ovalor de θ que maximiza L(θ|x1, . . . ,xn), ou seja:

L(θ|x1, . . . ,xn) = f (x1,x2, ...,xn|θ) =n

∏i=1

f (xi|θ). (2-17)


Retornando ao exemplo, após estimar os parâmetros deve-se verificar se os da-dos realmente se ajustam à distribuição. Isso pode ser feito com métodos gráficos ouutilizando testes estatísticos mais rigorosos. No primeiro caso, pode-se gerar um gráficode densidade com a PDF empírica dos dados e com a PDF da Lognormal, como apresen-tado na Figura 2.4(a). Outra maneira é fazer a comparação entre suas CDFs, como mostraa Figura 2.4(b). Observando esses gráficos, a Lognormal se apresenta relativamente ade-quada para modelar os dados, no entanto, existem métodos mais rigorosos, apresentadosa seguir.

0 50 100 200 300

0.00

00.

005

0.01

00.

015

Valores

Pro

babi

lidad

e

ArtificiaisLognormal

(a) Comparação da PDF empírica dos dados Arti-ficiais com a PDF da distribuição Lognormal.

10 20 50 100 200

0.0

0.2

0.4

0.6

0.8

1.0

Valores

Pro

b(V

alor

es ≤

x)

ArtificiaisLognormal

(b) Comparação da CDF empírica dados Artificiaiscom a CDF da distribuição Lognormal.

Figura 2.4: Comparação gráfica da adequação dos dados Artifi-ciais com a distribuição Lognormal com parâmetrosµ = 3,99 e σ = 0,51.

Outro gráfico também bastante utilizado é o gráfico Quantil-Quantil ou gráficoQ-Q. O objetivo do Q-Q é encontrar os percentis de duas distribuições e gerar o gráficode um conjunto de percentis em função do outro. Para que as distribuições sejamcompatíveis, os pontos devem formar uma linha reta com coeficiente angular igual a1. A Figura 2.5 mostra o gráfico Q-Q dos dados Artificiais em relação a distribuiçãoLognormal. Como podemos perceber, os pontos se aproximam de uma linha reta comcoeficiente angular igual a 1, o que reforça a qualidade do ajuste à Lognormal.

Existem vários testes estatísticos utilizados para verificação de ajuste de distri-buições a dados. Um dos mais utilizados é o Kolmogorov-Smirnov (KS) que calcula adistância máxima entre as CDFs da distribuição teórica e da distribuição empírica dos da-dos. Executando o KS nos dados Artificiais e comparando com a Lognormal, obtemos umvalor-p = 0,9142. Utilizando um nível de significância igual a 0,05, temos que o valor-

p não dá indícios para que rejeitemos o ajuste da distribuição à Lognormal, tornando a


0 50 100 150 200 250 300

050

100

200

300

Valores

Logn

orm

al

Figura 2.5: Gráfico Q-Q entre os dados Artificiais e a distribuiçãoLognormal com parâmetros µ = 3,99 e σ = 0,51.

confiança no modelo ainda maior. Dessa forma, podemos utilizar a Lognormal como ummodelo aceitável para descrever a distribuição dos dados Artificiais.

Um outro teste estatístico bastante utilizado e recomentado por ser acurado aodetectar desvios nas caudas é o Anderson-Darling (A2) [33, 11]. Ele é uma variação doKS e computa a média ponderada das diferenças entre duas CDFs, em vez da diferençamáxima. Nesta dissertação, trabalhamos com ambos os testes para avaliar os dadoscoletados.

Apesar da importância de realizar os testes estatísticos, nem sempre se consegueuma distribuição teórica que passe nos testes para um determinado conjunto de dados[2, 11]. Isso se deve ao fato desses testes serem formulados para um número moderadode amostras, de dezenas até no máximo 1000 [11]. Contudo, a quantidade de amostas decarga de trabalho de computadores é, geralmente, da ordem de milhares ou milhões [11].Dessa forma, muitos trabalhos na literatura optam pela distribuição que gere os melhoresresultados (tanto graficamente, quanto nos testes), mesmo que o ajuste não seja perfeito[2, 11, 17].

Na próxima seção, são apresentados alguns trabalhos sobre modelagem de cargade trabalho e sobre o estudo do comportamento de usuários de aplicações de mapa Web.Apresentamos também trabalhos que propõem estratégias de caching e de prefetching detiles em sistemas de mapa Web e discutimos como os resultados deste trabalho podemcontribuir para uma melhor avaliação dessas estratégias.

2.4 Trabalhos relacionados 34

2.4 Trabalhos relacionados

A modelagem de cargas de trabalho é uma atividade bastante importante paraa avaliação de desempenho de sistemas. Na literatura, existem trabalhos apresentandomodelos para diferentes tipos de sistemas [13, 42, 17, 48, 2], alguns deles descritos aseguir. Esses trabalhos, em geral, utilizam técnicas estatísticas para realizar a modelagem,adequando diferentes modelos de probabilidade às características das cargas.

Barford e Crovella [2], por exemplo, criaram um modelo de carga de trabalhoWeb para avaliação de desempenho de redes e de servidores. Eles identificaram asseguintes características mais relevantes para representar a carga de trabalho: tamanhodos arquivos, tamanho das requisições, popularidade de arquivos, localidade temporaldas requisições, intervalos do navegador entre requisições para uma mesma ação dousuário (Active OFF time), intervalos entre as ações dos usuários (Inactive OFF time)e referências incorporadas nos arquivos.

Após definir as características, os autores utilizaram dados empíricos para en-contrar o melhor modelo de probabilidade estatística para cada uma delas. A Tabela 2.2apresenta um resumo das distribuições utilizadas e seus respectivos parâmetros. Barford eCrovella mostraram que essas características faziam com que a carga exercitasse o sistemade forma significativamente diferente das cargas utilizadas na época.

Característica Modelo pdf ParâmetrosTamanho dos arquivos - Corpo Lognormal Equação 2-11 µ = 9,357

σ = 1,138Tamanho dos arquivos - Cauda Pareto Equação 2-13 k = 133K

α = 1,1Popularidade dos arquivos Zipf Equação 2-10 -Localidade temporal Lognormal Equação 2-11 µ = 1,5

σ = 0,8Tamanho das requisições Pareto Equação 2-13 k = 1000

α = 1,0Active OFF time Weibull Equação 2-12 α = 1,46

β = 0,382Inactive OFF time Pareto Equação 2-13 k = 1

α = 1,5Referências Incorporadas Pareto Equação 2-13 k = 1

α = 2,43

Tabela 2.2: Distribuições estatísticas utilizadas no modelo decarga de trabalho Web de Barford e Crovella [2].

Seguindo a mesma linha de Barford e Crovella [2], Gonçalves et al. [17] mo-delaram a carga de trabalho de um sistema de armazenamento de arquivos na nuvem. Oobjetivo era prover insumos para a geração de cargas sintéticas que sirvam como substrato


para o desenvolvimento de novas soluções de armazenamento na nuvem. Assim como ou-tros trabalhos da literatura, eles definiram as características consideradas importantes parasimular a carga desse tipo de sistema e as modelaram estatisticamente. A modelagem foirealizada utilizando a técnica de melhor ajuste, levando em consideração as distribuiçõesNormal, Lognormal, Exponencial, Gamma, Logística, Beta, Uniforme, Weibull e Paretopara variáveis contínuas; Poisson, Binomial, Binomial Negativa, Geométrica e Hipergeo-métrica para variáveis discretas.

Apesar da popularização dos sistemas de mapas Web, há uma ausência detrabalhos na literatura que buscam caracterizar e modelar uma carga de trabalho realpara esse tipo de sistema. Os trabalhos, em sua maioria, procuram modelar cargas parabenchmarks em bancos de dados espaciais [10, 36, 41], sem a preocupação de analisarcaracterísticas do comportamento de usuários reais.

Ray et al. [36], por exemplo, criaram uma ferramenta de benchmark de bancosde dados espaciais chamada Jackpine, para possibilitar a comparação do desempenho dediferentes bancos de dados espaciais. Os autores modelaram diversas operações básicas(chamadas de micro benchmarks), comuns a esses bancos de dados, como cálculo deárea, intersecção entre objetos geográficos, sobreposição de objetos geográficos, dentreoutras. A partir dessas operações, construíram cenários de acesso a aplicações SIG,com o intuito de gerar uma carga de trabalho real. No entanto, os cenários foramconstruídos sem uma análise estatística do uso de uma aplicação real. Alguns dos cenáriossão apresentados na Tabela 2.3. Cada cenário executa um conjunto de consultas pré-determinadas, desconsiderando aspectos de uso real, como os intervalos entre ações deusuários, por exemplo.

Em um trabalho posterior [41], a ferramenta Jackpine foi modificada para pro-duzir diversos acessos concorrentes. O objetivo desse trabalho era classificar os diferentesmicro benchmarks, por eles definidos, em relação ao uso de CPU e de Entrada/Saída nodisco. Todavia, os benchmarks utilizados apresentam deficiências similares as do trabalhoanterior.

Ciferri R. [10], em sua dissertação de mestrado, fez um vasto estudo sobre o usodas aplicações SIG nas empresas e órgãos públicos brasileiros. Ele propôs um benchmark

para bancos de dados espaciais, criando um modelo de subtarefas. Nesse modelo, eleidentificou e descreveu um grande conjunto de transações primitivas em SIGs, as quaispodem ser utilizadas para a formação de transações mais complexas. No entanto, obenchmark proposto sofre do mesmo problema do benchmark da ferramenta Jackpine:não leva em consideração aspectos de navegação de usuários reais.

Diferentemente dos trabalhos citados anteriormente, Romoser et al. [37] avalia-


Descrição Consulta Macro Cenário

Cidade mais próximaEncontre a cidade mais próxima deuma dada latitude e longitude

GeocodificaçãoReversa

Rua mais próximaEncontre o nome da rua mais pró-xima a uma dada latitude e longi-tude

GeocodificaçãoReversa

Protegida por barragensEncontre as áreas de risco de inun-dação protegidas por uma ou maisbarragens

Análise de Riscode Inundação

Categorias de áreas de riscoDetermine a área total de risco deinundação em acres, agrupadospor categoria de área de risco


Seguro de inundaçãonecessário

Quais proprietários de imóveisresidenciais são obrigados a terseguro contra inundações


Alto risco industrialQuais complexos industriaisestão em áreas de alto risco deinundação.


Tabela 2.3: Exemplos de cenários apresentados por Ray et al.[36].

ram a carga de um sistema real. Os autores analisaram os logs do USGS EROS2, visandoestudar a carga de trabalho imposta a esse sistema. Eles investigaram os acessos ao sistemae os caracterizaram por usuários, por imagens e por requisições. Descobriram que a maiorparte das requisições vem de um pequeno conjunto de usuários, bem como são feitas aum pequeno conjunto de cenas (locais no mapa) mais populares. Os autores encontraramtambém padrões de acesso a imagens em datas de grandes desastres, como terremotose o acidente nuclear em Chernobyl. Esses padrões foram utilizados para a melhoria dastécnicas de caching e prefetching, com o intuito de aperfeiçoar o desempenho do sistema.Romoser et al., contudo, modelaram apenas características específicas do sistema USGSEROS, sendo que os resultados não podem ser utilizados para avaliar os sistemas de mapaWeb em geral.

Os trabalhos apresentados até aqui, apesar da preocupação em modelar cargasde trabalho para SIGs, estavam mais voltados para aspectos dos banco de dados espaciais[36, 41, 10] ou se focaram em características muito específicas de um sistema [37]. Umtrabalho desenvolvido por Guan et al. [21], concomitantemente ao nosso, se atentou parao mesmo problema que encontramos: a falta de modelos na literatura que descrevam acarga de SIGs Web baseada na carga real gerada pelos usuários.

Guan et al. [21] criaram uma carga de trabalho teórica, baseada no comporta-

2USGS EROS é um sistema que permite aos usuários navegarem e baixarem imagens da Terracapturadas pela NASA.


mento dos usuários, chamada de HELP. A informação sobre os usuários foi extraída detrabalhos da literatura sobre cargas de trabalho Web gerais e os autores complementaramo modelo com seu conhecimento empírico sobre o uso de SIGs Web. Assim como nós,eles propuseram distribuições para o tamanho das sessões, para o intervalo entre açõesdos usuários e para as principais operações de navegação (zoom in/out e arraste). Os au-tores também mostraram uma técnica para encontrar os pontos mais acessados do mapa(hotspots) a fim de se escolher o ponto inicial da navegação.

O nosso trabalho apresenta o estudo de características não analisadas por Guanet al. [21], criando um modelo mais completo. Nesta dissertação, além dos aspectosabordados em Guan et al., fazemos uma análise aprofundada das operações de zoom earraste. Aqui, modelamos o tamanho dos arrastes e o tamanho dos saltos nas operaçõesde zoom, além da direção e sentido dos movimentos gerados por essas operações.Ademais, mostramos a distribuição da quantidade de tiles requisitadas por cada umadessas operações e sua relação com as resoluções das telas. Outra particularidade de nossotrabalho, é que ele foi baseado na análise de dados de acesso reais a um SIG Web.

O modelo proposto nesta dissertação pode ser utilizado por outras pesquisas naárea de SIG, principalmente aquelas que desenvolvem estratégias para melhorar o desem-penho, como algoritmos de caching e de prefetching de tiles. A seguir, descreveremosalguns trabalhos com esse foco, mostrando como eles podem se beneficiar do modeloproposto neste texto.

Quinn et al. [34] criaram um modelo preditivo para requisição de tiles. Elesmostram como é possível prever os tiles que são acessados com maior frequênciautilizando informações como regiões mais habitadas, estradas principais, litorais e outrospontos de maior interesse. Na discussão de seu trabalho, os autores reconheceram aimportância de se identificar os padrões de navegação dos usuários para a construçãodos modelos preditivos mais apurados. O modelo proposto nesta dissertação aborda ospadrões de navegação dos usuários e pode, portanto, auxiliar na construção de modelospreditivos de tiles.

Vieira, M. et al. [46] apresentam um arcabouço de cache espacial para operaçõesde navegação (arraste e zoom) em mapa. Eles criam cargas de trabalho para emular anavegação de um usuário em um mapa para fazer seus testes. Contudo, assim como outrostrabalhos, essas cargas são definidas apenas utilizando o bom senso, sem um estudo decomo a navegação é realizada por usuários reais. Por exemplo, uma de suas cargas criauma movimentação aleatória no mapa, sorteando um local de início e movimentando omapa com a mesma probabilidade para qualquer direção. Esse tipo de movimentação nãorepresenta os movimentos de usuários reais, os quais não navegam de maneira uniforme,como mostraremos no Capítulo 4. Os resultados apresentados nesta dissertação poderiamser utilizados para criar cargas mais realistas e avaliar de maneira mais confiável o

2.5 Conclusão 38

arcabouço proposto por Vieira, M. et al. (2012).Diversos outros trabalhos seguem uma abordagem semelhante de criação de

estratégias para caching e prefetching [47, 23, 24, 14] e também podem aproveitar osresultados deste trabalho para melhor avaliar suas estratégias.

2.5 Conclusão

Neste capítulo, foram apresentados alguns fundamentos teóricos importantespara o entendimento desta dissertação. Inicialmente, descrevemos o que são os sistemasde mapa Web e os principais padrões utilizados por esses sistemas. Também, apresenta-mos os tipos de operações que foram consideradas no modelo proposto nesta dissertação,justificando o motivo da restrição. Posteriormente, abordamos os conceitos mais impor-tantes da modelagem de cargas de trabalho e as técnicas utilizadas neste trabalho. Aofinal, apresentamos alguns trabalhos relacionados ao tema desta pesquisa.

No próximo capítulo, apresentamos uma metodologia para coleta e análise dedados, a fim de se criar um modelo do comportamento de usuários de SIGs Web, epropomos um modelo genérico desse comportamento.

CAPÍTULO 3Metodologia para criação do modelo e propostade um modelo de comportamento

Neste capítulo, propomos uma metodologia para a coleta e análise dos dadosnecessários para modelar o comportamento dos usuário de um SIG Web. Adicionalmente,a metodologia retrata como utilizar o resultado da modelagem para a implementaçãode um gerador de cargas. Por fim, propomos o MUSe-GM: um modelo genérico docomportamento do usuário em uma sessão de navegação de aplicações de mapa.

3.1 Metodologia para criação do modelo

A metodologia foi dividida em quatro etapas: (1) definição das de característicasimportantes para se investigar o comportamento dos usuários, além do conjunto de dadosnecessários para analisá-las; (2) coleta de dados; (3) análise dos dados coletados parainvestigação de padrões nessas características e criação de um modelo e; (4) uso domodelo para implementação de uma carga sintética.

3.1.1 Definição das características necessárias para a modelagem docomportamento dos usuários

Para modelar e simular o comportamento de um usuário de um sistema de mapaWeb, deve-se levar em consideração as características da interação dos usuários com asoperações oferecidas pelo sistema. Conforme descrito anteriormente, iremos considerarapenas as operações de arraste, zoom, pesquisa e roteirização. Além da caracterizaçãoda interação com as operações, é importante identificar como essas interações estãodistribuídas no tempo.

A distribuição das interações em relação ao tempo deve ser modelada levando-seem consideração: (1) o intervalo entre as ações dos usuários dentro de uma mesma sessãode navegação e (2) o tempo de duração da sessão de navegação. O intervalo entre as ações

3.1 Metodologia para criação do modelo 40

é importante para simular de maneira fidedigna a frequência com que os usuários enviamrequisições.

Em relação aos arrastes, é necessário identificar o seu tamanho, pois isso afetana quantidade de tiles requisitadas aos servidores. Um arraste de tamanho grande poderequisitar uma quantidade de novos tiles necessária para preencher toda a tela, ao passoque, um arraste pequeno pode nem exigir a requisição de novos tiles. É importantetambém identificar a direção e o sentido dos arrastes.

Quanto à operação de zoom, é preciso saber se ela é de aproximação (zoom in)ou de afastamento (zoom out), além do nível de zoom anterior à operação e o tamanho dosalto realizado. Definimos como tamanho do salto o módulo da diferença entre o valor dozoom inicial e o valor do zoom final. Por exemplo, um usuário pode passar do nível dezoom 10 para o 15, realizando, então, um salto de tamanho 5. Outro aspecto importanteobservado nessa operação é que o zoom pode ser direcionado pelo ponteiro do mouse.Esse direcionamento faz com que o mapa seja centralizado em uma coordenada diferenteapós a operação.

Para cada uma das operações, deve-se identificar a quantidade de tiles requisita-dos. Outro aspecto importante para se modelar são as regiões mais populares, visto quea navegação dos usuários tende a se concentrar em regiões de maior interesse, como ci-dades [12, 34]. No mapa, as regiões mais populares podem ser vistas como os tiles maispopulares, podendo-se então conhecê-las através da identificação dos tiles mais acessadospelos usuários.

Para estudo da operação de pesquisa é importante se coletar o texto pesquisadopelo usuário, além da posição da parte do mapa visualizada no Bounding Box (BB) ante-rior e posteriormente à execução da operação. A investigação da operação de roteirizaçãorequer a coleta dos pontos das rotas, do meio de transporte escolhido, além da posiçãoinicial e final do mapa.

Além de se obter informações sobre as operações individualmente, é interes-sante identificar como o usuário interage com o sistema como um todo. Dessa forma, éimportante coletar a sequência das operações de forma a determinar o caminho seguidopelo usuário. Assim, é possível investigar, por exemplo, se os usuários costumam realizarpesquisas antes de fazer um arraste ou um zoom e identificar outros padrões de compor-tamento.

A Tabela 3.1 resume o conjunto de informações necessárias para se modelar cadauma das características definidas.


Característica Dados necessáriosDuração da sessão Tempo de duração da sessão de navegação

Intervalo de tempo entre açõesIntervalo de tempo entre cada ação realizada pelousuário

ArrasteTamanho do arraste em pixels, direção, sentido enúmero de tiles requisitados

ZoomTipo da operação (in ou out), nível de zoomanterior, tamanho do salto, mudança do centrodo mapa e número de tiles requisitados

PesquisaPosição da parte do mapa visualizada no BBanterior e posteriormente à operação e textopesquisado

RoteirizaçãoPosição da parte do mapa visualizada no BBanterior e posteriormente à operação, pontos darota e meio de transporte escolhido

Regiões populares Tiles visualizados na sessão de navegaçãoTraço das ações Sequência das ações realizadas em uma sessão

Tamanho das respostas às requisiçõesTamanho das respostas às requisiçõesfeitas aos servidores

Tabela 3.1: Informações necessárias para se modelar cada carac-terística do comportamento dos usuários e o volumede dados transferidos.

3.1.2 Coleta dos dados

Os dados podem ser coletados nos servidores [2] ou nos clientes [17]. No se-gundo caso, é possível obter informações com maior granularidade a respeito do com-portamento dos clientes. Neste trabalho, optamos por coletar os dados no lado do cliente,através de uma extensão desenvolvida para o navegador mais utilizado na atualidade [44],o Google Chrome1. No Apêndice A, apresentamos os detalhes da extensão desenvolvidae o processo de coleta e análise dos dados.

Nem sempre é possível coletar todas as informações necessárias diretamente.Contudo, pode-se coletar outros dados mais genéricos e analisá-los a fim de extrairas informações. A título de exemplo, em nosso caso, não foi possível coletar os tiles

acessados pelos clientes. Coletamos então as coordenadas geográficas do ponto centraldo mapa visualizado no BB e a resolução do BB e, a partir desses dados, identificamos ostiles acessados.

1Google Chrome: https://www.google.com/chrome/browser/desktop/index.html.


3.1.3 Análise dos dados coletados

Para analisar os dados, recorremos a ferramentas estatísticas a fim de encontrarpadrões que possam ser modelados. Para dados numéricos como duração da sessão,intervalo entre ações, tamanho dos arrastes e tamanho dos saltos na operação de zoom,o primeiro passo é gerar um histograma ou um gráfico de densidade. Através dessesgráficos, é possível ver o formato da distribuição dos dados e selecionar os modelosestatísticos que melhor se ajustem aos dados. Após a escolha dos modelos, deve-sebuscar estimar os parâmetros e testar a adequação via comparação de gráficos e/ou testesestatísticos mais sofisticados como o KS e o A2.

A sequência das ações, assim como a direção e o sentido dos arrastes e domovimento do mapa na operação de zoom podem ser modeladas através de modelos deestados. No caso da sequência das ações, cada ação considerada pode ser modelada comoum estado e as probabilidades de executar cada ação podem ser extraídas dos dados eutilizadas para formar a matriz de transição. O mesmo raciocínio pode ser aplicado emrelação a direção e sentido dos arrastes e zooms, considerando cada direção/sentido comoum estado. Esse tipo de modelo captura, por exemplo, a probabilidade de se manter oumudar a direção em arrastes sequenciais.

Para se encontrar as regiões mais visualizadas, pode-se fazer uma contagem dosacessos a cada tile e, então, gerar um mapa de calor para evidenciar as regiões maisacessadas [12]. A distribuição dos acessos aos tiles pode ser utilizada para gerar ospontos de início [21] das sessões de navegação. Alguns trabalhos sugerem que os locaismais acessados são regiões metropolitanas, grandes rodovias e outros pontos de interesse[12, 21]. No entanto, isso pode depender do objetivo do sistema. Por exemplo, um sistemautilizado para se estudar florestas, provavelmente terá as matas e florestas como regiõesmais populares.

Neste trabalho, não foi possível coletar dados suficientes para se encontrar pa-drões nas operações de pesquisa e roteirização. Contudo, apresentamos algumas sugestõesde como analisar as informações coletadas dessas operações.

Através dos textos pesquisados, é possível identificar padrões sobre a operaçãode pesquisa. Os textos podem ser utilizados para criar uma categorização dos termose/ou locais mais pesquisados, identificar a proporção de pesquisas por endereços, porcoordenadas geográficas, por nomes de locais ou por termos genéricos (como restauranteou farmácia). A informação da posição da parte do mapa mostrada no BB pode serutilizada para verificar se o usuário faz pesquisas por locais próximos ao visualizadoou por locais distantes. Essa informação pode ser empregada também para investigar adistribuição espacial das pesquisas, identificando as regiões em que o uso dessa operaçãoé mais frequente.

Dos dados coletados da operação de roteirização, pode-se investigar a distribui-


ção da distância entre os pontos da rota, identificando as frequências de criação de rotasdentro de uma mesma cidade ou entre cidades, estados e países diferentes. É possíveltambém avaliar a distribuição da quantidade de pontos em uma rota em sistemas que per-mitem adicionar mais de dois pontos. Outra possibilidade é encontrar a distribuição douso de cada meio de transporte na geração das rotas. Por fim, assim como na pesquisa,pode-se investigar as regiões em que o uso dessa operação é mais frequente.

Através da informação dos tiles requisitados, pode-se modelar a distribuiçãodo número de tiles requisitados ao servidor, por operação ou por sessão. Com essamodelagem, ainda existe a possibilidade de se estimar a carga gerada em termos de dadostransferidos, uma vez que se tenha o tamanho dos tiles em bytes. Essa estimativa tambémpode ser obtida pela análise direta do tamanho das respostas às requisições.

3.1.4 Construção da carga sintética

Um gerador de cargas sintéticas para um SIG Web deve ter dois módulosdiferentes: (1) simulador do comportamento dos usuários e (2) emulador da aplicaçãocliente do SIG Web.

O módulo (1) é responsável por simular os usuários, gerando a lista de açõesrealizadas durante uma sessão de navegação. As ações são geradas pela implementaçãodo modelo de comportamento. Essa implementação é feita com o uso de geradores denúmeros pseudoaleatórios, que tornam possíveis a criação de instâncias aleatórias dosusuários modelados [38]. As ações de cada usuário são repassadas para o módulo (2).

O módulo (2) deve emular a reação de uma aplicação cliente de mapa diantedas ações dos usuários. Ao receber uma ação, ele deve interpretá-la e a traduzi-la emrequisições para o servidor de mapas. Para isso, ele precisa abstrair o espaço retangularda página onde fica o mapa e emular características de um navegador Web, como o limitede conexões abertas por servidor. É no módulo (2) que devem ser inseridos tambémalgoritmos de caching e prefetching de tiles, caso seja desejável avaliar o impacto dessasabordagens. O módulo (2) deve, por exemplo, ser capaz de receber informações deuma operação de arraste, processá-las e requisitar os tiles necessários para preencher aabstração da página.

O gerador de cargas deve possibilitar a configuração do número de usuários edos parâmetros do modelo de comportamento. Os usuários emulados devem executar suasações de forma paralela.

3.2 MUSe-GM (Maps User Session Generative Model) 44

3.2 MUSe-GM (Maps User Session Generative Model)

Nesta seção, descrevemos a proposta de um modelo genérico para representar ocomportamento de usuários de SIGs Web durante uma sessão de navegação. O modelo foibatizado de MUSe-GM, sendo um acrônimo para Maps User Session Generative Model

(em português: Modelo Generativo de Sessões de Usuários de Mapas). O MUSe-GMconsidera as quatro operações mais comuns (zoom, arraste, roteirização e pesquisa) eabrange outros aspectos considerados importantes para caracterizar uma carga de trabalhode um SIG Web. Dentre eles, a duração e tamanho das sessões, o tamanho dos saltos naoperação de zoom e a popularidade dos tiles.

O modelo, como mostrado na Figura 3.1, foi dividido em duas camadas: (1)camada de sessão, que modela características da sessão e as ações dos usuários e (2)camada de transferência de tiles, que trata do impacto das ações em termos de requisiçõesde tiles e volume de dados transferidos. A camada 2 pode ser vista como a aplicaçãocliente do sistema de mapas, uma vez que ela é a responsável pela tradução das ações emrequisições a tiles.

Figura 3.1: Modelo alto nível do comportamento de um clientede aplicação de mapa Web durante uma sessão denavegação.

3.2.1 Camada de sessão

Uma sessão representa a navegação de um usuário na aplicação de mapa e teminício com a abertura da página da aplicação. Durante a sessão, o usuário realiza diferentesações na aplicação, a fim de buscar algo de seu interesse (por exemplo, encontrar umdeterminado endereço no mapa). Após atingir seu objetivo, o usuário fecha a página,encerrando a sessão de navegação.

A camada de sessão retrata o comportamento dos clientes durante o período denavegação. Ela contém as características que descrevem o comportamento dos clientesem relação ao tempo, como a duração das sessões e os intervalos entre ações. Além disso,


apresenta características que descrevem o uso das operações do mapa, a sequência deações dos usuários e a popularidade dos tiles.

A seguir, apresentamos as características consideradas neste trabalho para des-crever e modelar o comportamento dos usuários.

Duração e tamanho das sessões de navegação

A duração de uma sessão representa o intervalo de tempo transcorrido do inícioao fim da sessão, como pode ser visto na Figura 3.1. Uma sessão de navegação pode durarpor um tempo arbitrário e diferente a cada sessão. Sessões com longa duração nem sempreindicam maior carga de trabalho, pois o usuário pode deixar a página aberta enquanto fazoutras atividades não relacionadas à aplicação de mapa. Por esse motivo, é necessáriotambém considerar no modelo a quantidade de ações realizadas por um usuário dentro deuma sessão.

Intervalo entre ações

Durante uma sessão de navegação, um usuário alterna entre realizar ações eesperar/interpretar os resultados, como mostrado na Figura 3.1. O intervalo de tempoentre esses dois estados é chamado de intervalo para pensar (think time). Essa é umaimportante característica para o modelo, pois permite entender e simular um aspecto docomportamento humano: o tempo necessário para uma pessoa observar o mapa e decidirsua próxima ação.

Operação de arraste

A operação de arraste permite ao usuário direcionar o mapa para a região de seuinteresse. Nas aplicações de mapa atuais, essa operação é realizada, usualmente, atravésdo movimento de arrastar e soltar do mouse. É possível também realizá-la através doscontroles de direção (setas) do teclado, mas é uma opção pouco popular. Por ser realizada,na maioria das vezes através do mouse, o tamanho e a direção dos arrastes variam de umpara outro.

A tela do computador pode ser organizada como um plano cartesiano, com oseixos x e y medidos em pixels. A origem do plano é o ponto mais acima e à esquerda. Oeixo x cresce para a direta, ao passo que, o eixo y cresce para baixo. As interfaces gráficasutilizam esse padrão para posicionar os objetos na tela. Dessa forma, o tamanho de ummovimento de arraste pode ser medido em termos da variação, em pixels, da posição domapa.

A direção e o sentido de arrastes sequenciais, geralmente, percorrem algumcaminho lógico. Isso faz com que as probabilidades de se seguir para as diferentes


direções e sentidos sejam diferentes. A modelagem dessas probabilidades possibilita aemulação de arrastes com sequências de direções fiéis as de usuários reais.

Operação de zoom

Como explicado no Capítulo 2, os SIGs Web organizam o mapa em um númerodiscreto e finito de resoluções, chamadas de níveis de zoom. A operação de zoom consisteem navegar entre os diferentes níveis de zoom. Quando o nível de zoom inicial é menordo que o final, a operação é chamada de zoom in, e quando o zoom inicial é maior do queo final, a operação é chamada de zoom out. As aplicações atuais permitem aos usuáriosnavegar entre os níveis de zoom utilizando a roda do mouse, clique duplo no mapa, atravésdos botões de + (para zoom in) e - (para zoom out) do teclado ou de controles específicosna interface da aplicação.

Alguns níveis de zoom são mais utilizados do que outros por possuírem melhornavegabilidade ou maior nível de detalhes [14]. Esse fato deve ser levado em consideraçãopara a escolha do ponto inicial de navegação ou para priorização no armazenamento dosníveis mais acessados em cache.

Embora, teoricamente, os usuários naveguem sequencialmente entre os níveis dezoom, na prática, isso nem sempre acontece. Um usuário pode utilizar os controles dezoom (como a roda do mouse, por exemplo) de maneira rápida, de forma que pule níveisde zoom intermediários. De fato, o usuário não salta os níveis de zoom intermediários,mas passa rapidamente por eles, de forma que os tiles desses níveis não precisam serrequisitados.

Outro aspecto observado na operação de zoom é que, durante sua execução, omapa é direcionado pelo ponteiro do mouse, quando o mouse é utilizado. Isso faz comque o zoom gere também uma variabilidade na direção e sentido do mapa. A operação dezoom é, então, modelada considerando seu tipo (in/out), a variabilidade do tamanho dossaltos e da direção e sentido do mapa.

Operação de pesquisa

A operação de pesquisa permite aos usuários buscarem de maneira mais rápidapor locais de interesse. As pesquisas podem ser por pontos genéricos, utilizando palavras-chave como “farmácia”, “restaurante” ou mais específicas, utilizando nomes de estabe-lecimentos, endereços e até coordenadas geográficas. Existem também opções de pes-quisas mais sofisticadas, utilizando expressões como “perto de” para buscar pontos queficam próximos a outros. Por exemplo, a expressão “farmácia perto de aeroporto santagenoveva” busca as farmácias próximas ao Aeroporto Santa Genoveva. Outros tipos de


pesquisas são possíveis utilizando a tecnologia SIG, como na aplicação do TwitterMap2

da goGeo, na qual é possível pesquisar por termos nos twittes geolocalizados e aindafiltrá-los por data de publicação.

A natureza da operação de pesquisa depende da aplicação e do tipo de base dedados utilizada. Em geral, existem regiões de maior interesse para os usuários [12, 21]e a maioria das pesquisas buscam por pontos nessas regiões. A informação a respeitodesses pontos é importante para se modelar o uso da operação de pesquisa. Além disso,é interessante ter uma classificação dos termos mais procurados de forma a utilizá-los nomodelo e na criação de uma carga sintética.

Operação de roteirização

A operação de roteirização (ou rota) permite ao usuário criar uma rota entre doisou mais pontos. Um sistema pode oferecer diferentes opções de meio de locomoção emuma rota, como a pé, de carro, transporte público, avião ou bicicleta. A modelagem daroteirização deve incluir a regularidade dos pontos e dos meios de transporte utilizados.Adicionalmente, é importante modelar o tamanho das rotas, observando-se a frequênciade rotas intermunicipais ou entre estados e países diferentes. O modelo deve tambémrepresentar a frequência do número de pontos utilizados nas rotas.

Frequência das operações e sequência de passos

As operações são utilizadas com regularidades diferentes. O modelo deve incluiruma análise da frequência do uso de cada operação. Ademais, sabe-se que um usuáriorealiza uma sequência de passos a fim de alcançar um objetivo. Ações sequenciais acon-tecem com probabilidades diferentes, influenciadas pelos resultados de ações anteriores.Logo, é importante modelar a maneira como os usuários realizam a sequência de passos.

Popularidade dos tiles

As regiões mais acessadas dependem do objetivo e da base de dados do sistema,mas na grande maioria dos casos, os pontos de interesse estão nos grandes centros,grandes rodovias, litorais e pontos turísticos [12, 14, 21, 34]. Obviamente, os tiles maisacessados nos sistemas de mapa são aqueles relacionados aos pontos de maior interesse.O conhecimento desses tiles pode ser utilizado para priorizar seu armazenamento emcache ou para gerá-los previamente, melhorando assim a qualidade do serviço [14, 34].A frequência de acesso aos tiles pode ser empregada também para modelar a escolha doponto inicial de navegação em uma carga sintética.

2TwitterMap: http://twittermap.gogeo.io/app/#/dashboard.


3.2.2 Camada de transferência de tiles

Durante uma sessão, as diferentes ações realizadas pelo usuário resultam na re-quisição de tiles e outras informações aos servidores, como scripts e ícones, por exemplo.O número de tiles requisitados está relacionado à operação realizada, à resolução da telae também à implementação da aplicação cliente do SIG Web. As aplicações clientes po-dem implementar diferentes abordagens de caching e/ou prefetching de tiles, as quaisinfluenciam no número de tiles requisitados. Além disso, as aplicações podem utilizar oespaço da página de maneiras diferentes. Por exemplo, uma aplicação pode utilizar todoo espaço da página para o mapa, ao passo que outra pode deixar algum espaço reservadopara barras de informações ou de pesquisas. Essas abordagens distintas fazem com que osBounding Boxes das duas aplicações sejam diferentes em uma mesma resolução de tela.

Dessa forma, a camada de transferência de tiles deve ser analisada do ponto devista da relação entre as operações, a resolução da tela e o número de tiles requisitados.Além disso, as informações do tamanho dos tiles podem ser utilizadas para estimar ovolume de dados transferidos por operação e por sessão de navegação. Por fim, o volumede dados também pode ser avaliado, considerando a informação de tamanho das respostasa todas as requisições, incluindo dados além dos tiles.

Resolução da tela vs. número de tiles

O número de tiles requisitados aos servidores está diretamente relacionadoà resolução da tela do computador. As aplicações solicitam os tiles necessários parapreencher o espaço do mapa na tela3. Por exemplo, em uma operação de zoom, se o espaçodo mapa na tela tiver capacidade para mostrar 20 tiles, a aplicação irá solicitar 20 novostiles. A resolução interfere também na quantidade de tiles requisitadas nas operações dearraste e até mesmo no comportamento do usuário quanto ao uso dessa operação.

Volume de dados transferidos

Utilizando a informação dos tiles requisitados por operação e o tamanho, embytes, de cada tile é possível estimar o volume de dados transferidos por operação, levandoem consideração apenas as imagens. Sabendo quais tiles foram requisitados em umasessão, é possível também verificar o volume de dados transferidos nas sessões.

A informação do tamanho das respostas às requisições permite avaliar o volumetotal de dados transferidos em uma sessão, considerando outros elementos da aplicação,

3Exceto quando há implementação de prefetching ou quando algum tile está armazenado na cache donavegador. No caso do prefetching, a aplicação cliente pode solicitar tiles a mais a fim de melhorar aqualidade de serviço entregue ao usuário.

3.3 Conclusão 49

além dos tiles. Contudo, devido à natureza assíncrona das aplicações de mapa Web, é difí-cil utilizar essa informação para avaliar com precisão o volume de dados transferidos poroperação. Isso acontece porque as aplicações permitem que os usuários realizem novasações no mapa, sem que todas as requisições da ação anterior tenham sido completadas,tornando difícil o mapeamento entre ações e requisições.

3.3 Conclusão

Neste capítulo, descrevemos uma metodologia para definição, coleta e análise dedados, a fim de modelar o comportamento de usuários de um SIG Web e caracterizaraspectos importantes da carga gerada. Apresentamos também, como os resultados daanálise dos dados podem ser utilizados para a criação de um gerador de cargas de trabalho.Por fim, propusemos um modelo genérico do comportamento dos usuários, abordando osaspectos mais importantes para a caracterização e simulação desse comportamento.

No próximo capítulo, apresentaremos uma caracterização detalhada do compor-tamento dos usuários, baseada nos dados coletados neste trabalho, e definiremos umainstância para o MUSe-GM.

CAPÍTULO 4Caracterização dos dados coletados e instânciado modelo

Neste capítulo, apresentamos uma descrição do conjunto de dados coletados eapresentamos uma caracterização do comportamento do usuário de mapa Web com basena análise desses dados. Mostramos as distribuições e modelos estatísticos utilizados paramodelar cada aspecto do comportamento do usuário e analisamos a quantidade de tiles

e o volume de dados transferidos. Por fim, apresentamos uma instância do MUSe-GM,levando em consideração as informações obtidas com a caracterização.

4.1 Descrição do conjunto de dados coletados

Os dados analisados neste capítulo foram coletados de sessões de navegação deum dos sistemas de mapa mais populares do mundo, o Google Maps [20]. Como dito an-teriormente, a coleta foi realizada por meio de uma extensão desenvolvida para o GoogleChrome, cujos detalhes sobre a implementação e o tratamento dos dados são apresentadosno Apêndice A. A extensão foi divulgada por e-mail aos alunos do Instituto de Informá-tica da Universidade Federal de Goiás e por meio da rede social Facebook1. Além decoletar os dados, a extensão oferecia a funcionalidade de visualização dos horários deônibus da cidade de Goiânia. A funcionalidade adicional era independente da coleta, nãoinfluenciando no uso do Google Maps. Ela foi implementada a fim de incentivar os usuá-rios a instalarem a extensão e em sua descrição o usuário era informado da coleta anônimade dados. Devido ao método de divulgação e à funcionalidade oferecida, a maioria dosusuários da extensão era da região metropolitana de Goiânia.

A extensão teve um total de 169 usuários e coletou dados de 2.404 sessões denavegação, somando um total de 120.114 URLs. Como explicado no Apêndice A, foipossível identificar o comportamento dos usuários apenas no mapa de arruamento. Por

1Facebook: http://www.facebook.com

4.2 Caracterização do comportamento dos usuários 51

esse motivo, as sessões que navegaram no Street View2 e/ou no mapa com imagens desatélite foram descartadas. Excluindo-se essas sessões, restaram um total de 1.538 sessõesde navegação, realizadas por 146 usuários, e totalizando 36.860 URLs, as quais foramutilizadas nas análises deste capítulo. A Tabela 4.1 contém um resumo das informaçõesapresentadas.

Número de usuários Número de sessões Número de URLsTodas as sessões 169 2.404 120.114Sessões analisadas 149 1.538 36.860

Tabela 4.1: Resumo quantitativo dos dados coletados.

Aplicamos o algoritmo k-means para dividir os usuários em grupos diferentes,dependendo da quantidade de sessões criadas por cada usuário. Escolhemos o númerok de clusters utilizando a técnica de otimização da largura média de silhueta, obtendo ovalor k = 2. Dividimos então os usuários em usuários Casuais e usuários Regulares e asinformações dos grupos são apresentadas na Tabela 4.2.

Grupo No de usuários Mínimo-Máximo Média Desvio padrãoCasuais 121 1-17 4,43 4,18Regulares 25 19-106 40,08 22,57

Tabela 4.2: Informações sobre os grupos de usuários, obtidos atra-vés do uso do k-means.

4.2 Caracterização do comportamento dos usuários

Nesta seção, analisamos os dados coletados neste trabalho e descrevemos esta-tisticamente cada uma das características levantadas no Capítulo 3.

4.2.1 Duração e tamanho das sessões de navegação

A maioria das sessões tem duração na ordem de segundos ou minutos, sendoo 3o quartil equivalente a aproximadamente 4 minutos. No entanto, em alguns casos, osusuários deixam a aba do navegador aberta por dias, embora sem realizar nenhuma ação.Esses casos são, provavelmente, usuários de notebooks que têm o costume de colocar ocomputador em modo suspenso e, portanto, deixam os programas abertos por vários dias.Todavia, as situações em que a sessão dura mais de 24 horas se apresentaram raras emnossos dados (menos de 0,25%) e, além disso, não geram carga aos servidores. Dessa

2https://www.google.com/maps/streetview/


forma, retiramos essas ocorrências antes de modelar a duração das sessões de navegação.A distribuição Lognormal com µ = 4,472433 e σ = 1,77819 foi ajustada à distribuiçãoempírica da duração das sessões e a comparação de suas CDFs é apresentadas na Figura4.1(a). Utilizando o teste KS, obtivemos o valor valor-p= 0,388955, o que reforça aqualidade do ajuste.

1 100 10000

0.0

0.2

0.4

0.6

0.8

1.0

Duração (s)

Pro

b(D

uraç

ão d

a se

ssão

≤ x

)

ObservadoLognormal

(a) CDF empírica da duração das sessões em se-gundos vs. Lognormal com µ = 4,472433 e σ =1,77819.

0 50 100 150 200 250

0.0

0.2

0.4

0.6

0.8

1.0

Nº de ações

Pro

b(N

º de

açõ

es ≤

x)

ObservadoWeibull

(b) CDF empírica do número de ações por ses-são vs. Weibull com β = 0,92590195 e α =17,83891039.

Figura 4.1: Ajuste da distribuição Lognormal aos dados da dura-ção das sessões e da Weibull ao número de ações porsessão.

No trabalho de Guan et at. [21], os autores modelaram o tamanho das sessõesconsiderando o número de ações realizadas durante as sessões. Eles modelaram essacaracterística utilizando a distribuição Weibull. Embora não tenha passado nos testesKS e A2, visualmente, o ajuste se mostrou adequado a Weibull com β = 0,92590195 eα = 17,83891039, como ilustrado na Figura 4.1(b). Os valores-p resultantes nos testesKS e A2 foram 0,000076 e 0,00034, respectivamente.

4.2.2 Intervalo entre ações

Alguns intervalos muito pequenos foram coletados em virtude de URLs geradasautomaticamente pelo Google Maps ou devido a imprecisões na coleta em alguns nave-gadores. Uma vez que não temos como identificar esses intervalos, optamos por utilizarum limiar mínimo e descartamos os valores inferiores.

Em alguns trabalhos da literatura [2, 21], o tempo mínimo considerado como in-tervalo gerado por humanos em sistemas Web é de 1 segundo. No entanto, empiricamente,percebemos que em sistemas de mapa, esse tempo é menor. Pela natureza das operações,


o usuário pode realizar movimentos rápidos a fim de chegar a um determinado pontodo mapa. Durante o trajeto, nem sempre é necessário o usuário parar para interpretar omapa em cada um dos movimentos. Segundo o Human Benchmark [5], o tempo médiode reação do ser humano é de 215 milissegundos. Todavia, por se tratar de um teste develocidade de reação, consideramos que esse tempo é pequeno para representar interva-los entre ações em sistemas de mapa. Decidimos então utilizar como limiar mínimo umvalor intermediário. Optamos por uma abordagem utilizada em outros trabalhos [11], queconsiste em excluir o primeiro percentil dos dados a fim de retirar os dados discrepantes.O valor encontrado foi arredondado, e obtivemos o tempo de 400 milissegundos, o qualfoi eleito para ser o limiar inferior.

Os intervalos entre ações são, geralmente, modelados com a distribuição Pareto[2, 21], conhecida pela propriedade de cauda pesada. Contudo, não obtivemos um ajusteadequado apenas com a Pareto. Empregamos então uma mistura das distribuições Log-normal e Pareto Generalizada (Generalized Pareto Distribution - GPD). A distribuiçãoLognormal truncada a direita foi utilizada para modelar o corpo da distribuição, até umlimiar θ, e a GPD foi utilizada para modelar a cauda, a partir do limiar θ. Sendo Φ(.) afunção da distribuição Normal Padrão, a pdf da Lognormal-GPD é dada pela expressão[4]:

f (x) = r f1(x;µ,σ,θ)+(1− r) f2(x;ξ,τ,θ), (4-1)

onde f1 é a densidade da Lognormal truncada:

f1(x;µ,σ,θ) =1

Φ(

log(θ)−µσ

) 1xσ√

2πe−

12

(log(x)−µ

σ

)2

I{0<x≤θ} (4-2)

e f2 é a densidade da GPD com parâmetros ξ, τ e θ:

f2(x;ξ,τ,θ) =1τ

(1+ξ

x−θτ

)−( 1ξ+1

)I{θ<x}. (4-3)

Para que a densidade seja contínua, é necessário satisfazer a condição:

r(µ,σ,ξ,θ) =√

2πξ−1σΦ(θ∗)e12 (θ∗)2

√2πξ−1σΦ(θ∗)e

12 (θ∗)2

+ τξ−1. (4-4)

O limiar e os parâmetros das distribuições foram estimados utilizando a funçãoflognormgpdcon do pacote evmix [40] do Software R [35], a qual mantém a continuidadeno limiar. A Tabela 4.3 mostra os valores encontrados, sendo que entre parênteses está onome dado ao parâmetro no pacote evmix. O teste KS retornou um valor-p= 0,0159051, o


qual é um valor baixo, mas esperado devido a grande quantidade de elementos da amostra,como explicado no Capítulo 2.

µ (lnmean) σ (lnsd) θ (u) τ (sigmau) ξ (xi)0,6682218 0,5779033 1,107957 2,166933 0,8950732

Tabela 4.3: Estimativas dos parâmetros da Lognormal-GPD ajus-tada à distribuição empírica dos intervalos entre açõesdos usuários.

Apesar do resultado do KS, o ajuste visual se mostrou adequado, como podeser visto na Figura 4.2. A distribuição Lognormal pode gerar valores abaixo de 400milissegundos e a GPD pode gerar valores extremamente altos. Utilizamos então o valorde 0,4 segundos como limiar inferior e o valor de 4 horas, equivalente ao percentil 99 daduração das sessões, como limite superior em nosso modelo.

1 10 100 1000

0.0

0.2

0.4

0.6

0.8

1.0

Intervalo (s)

P(I

nter

valo

≤ x

)

ObservadoLognormal−GPD

Figura 4.2: Ajuste da Lognormal-GPD (com θ = 1,107957, µ =0,6682218, σ = 0,5779033, τ = 2,166933 e ξ =0,8950732) aos dados dos intervalos entre as açõesdos usuários.

4.2.3 Operação de arraste

A Figura 4.3(a) apresenta a distribuição do tamanho dos arrastes, em pixels,realizados pelos usuários. Os valores à esquerda do 0 representam movimentos paraa esquerda e para cima nos eixos x e y, respectivamente, e os valores à direita do 0representam movimentos para a direita (eixo x) e para baixo (eixo y). A maior parte dosarrastes são pequenos e, em geral, os arrastes no eixo y são maiores. Isso pode ser devidoao formato widescreen das telas, que apresenta menos informações no eixo y e resulta na


necessidade de movimentos maiores na direção vertical. Como o formato widescreen é omais utilizado atualmente [43], a maioria dos usuários movimenta o mapa dessa maneira.

Tamanho do arraste (px)

Den

sida

de

1500 500 0 500 1500

0.00

00.

001

0.00

20.

003

0.00

4

Esquerda

Para cima

Direita

Para Baixo

XY

(a) PDF do tamanho dos arrastes em pixels.

5 10 15 20

050

100

200

300

Nível de zoomTa

man

ho m

édio

dos

arr

aste

s (p

x) XY

(b) Média do tamanho dos arrastes, em pixels, pornível de zoom.

Figura 4.3: Análise do tamanho dos arrastes.

A Figura 4.3(b) mostra a média do tamanho dos arrastes por nível de zoom emostra uma tendência de aumento no tamanho dos arrastes a medida que o nível de zoom

cresce. Isso se deve ao fato de que em níveis maiores a distância relativa dos movimentosem relação ao planeta é menor. Por exemplo, um movimento de 100 px no nível dezoom 4 corresponde ao movimento de quilômetros em relação ao solo terrestre. O mesmomovimento de 100 px no zoom 21, representa uma movimentação de poucos metros.

Ao analisar com mais detalhes o tamanho dos arrastes por nível de zoom,confirmamos a existência de uma correlação positiva entre a média do tamanho dosarrastes e o nível de zoom, como pode ser visto nas Figuras 4.4(a) e 4.4(b). Calculamos oscoeficientes de correlação de Pearson, Spearman e Kendall, mostrados na Tabela 4.4, paraverificar a existência da correlação. Consideramos apenas os níveis de zoom superiores a5 para a análise da correlação, devido a falta de representatividade dos dados coletadosnos níveis de zoom menores.

Eixo Spearman Kendall Pearsonx 0,6642157 0,5441176 0,6626922y 0,8970588 0,7352941 0,8508549

Tabela 4.4: Coeficientes da correlação entre a média do tamanhodos arrastes e o nível de zoom.

Devido à existência da correlação apresentada, modelamos a distribuição dotamanho dos arrastes em função do nível de zoom. Utilizamos os valores absolutos


5 10 15 20

050

100

200

300

Nível de zoom

Méd

ia d

o ta

man

ho d

os a

rras

tes

(px)

(a) Correlação entre o tamanho dos arrastes noeixo x e o nível de zoom. y = 4,38x+ 107,28,R2 = 0,4018.

5 10 15 20

050

100

200

300

Nível de zoom

Méd

ia d

o ta

man

ho d

os a

rras

tes

(px)

(b) Correlação entre o tamanho dos arrastes noeixo y e o nível de zoom. y = 6,589x+ 87,787,R2 = 0,7056.

Figura 4.4: Correlação entre o tamanho dos arrastes e o nível dezoom.

do tamanho dos arrastes, uma vez que a distribuição é simétrica em relação ao 0,conforme apresentado na Figura 4.3(a). Existe a possibilidade de que um arraste tenha otamanho equivalente a 0 px em um dos eixos, resultando em movimentos exclusivamentehorizontais ou verticais. Isso, geralmente, ocorre quando o usuário utiliza as setas doteclado para movimentar o mapa.

A distribuição Geométrica foi ajustada aos dados empíricos do tamanho absolutodos arrastes, em pixels. Utilizamos o Método de Máxima Verossimilhança para estimaro parâmetro p. As estimativas são mostradas nas Figuras 4.5(a) e 4.5(b). Uma vez queos valores de p apresentam uma tendência de decaimento à medida que o nível dezoom aumenta, realizamos uma regressão linear, obtendo as funções y =−0,0001376x+

0,0079955 e y = −0,0002038x + 0,0085857 para os eixos x e y, respectivamente. AFigura 4.6 mostra, para alguns níveis de zoom, a adequação da distribuição empírica àdistribuição Geométrica, utilizando os parâmetros estimados a partir da função obtida naregressão linear.

Além de avaliar o tamanho, verificamos também padrões em relação a direçãoe sentido dos arrastes. Consideramos os dois eixos simultaneamente, resultando em8 possibilidades de movimentação: Esquerda/Para Cima (E/PC), Esquerda/Para Baixo(E/PB), Esquerda/0 px (E/0 px), Direita/Para Cima (D/PC), Direita/Para Baixo (D/PB),Direita/0 px (D/0 px), 0 px/Para Cima (0 px/PC) e 0 px/Para Baixo (E/0 px). Cadauma dessas possibilidades foi modelada como um estado, como pode ser visto na Figura4.7. As setas representam as transições entre os estados e cada transição acontece com


5 10 15 20

0.00

400.

0050

0.00

600.

0070

Nível de zoom

Est

imat

iva

de p

(a) Estimativa do parâmetro p da distribuição Ge-ométrica por nível de zoom para os arras-tes no eixo x utilizando regressão linear. y =−0,0001376x+0,0079955.

5 10 15 20

0.00

40.

005

0.00

60.

007

Nível de zoom

Est

imat

iva

de p

(b) Estimativa do parâmetro p da distribuição Ge-ométrica por nível de zoom para os arras-tes no eixo y utilizando regressão linear. y =−0,0002038x+0,0085857.

Figura 4.5: Regressão linear nas estimativas dos parâmetros daGeométrica ajustada à distribuição empírica do tama-nho dos arrastes por nível de zoom.

0 500 1500 2500

0.0

0.2

0.4

0.6

0.8

1.0

Zoom 15

Tam. do arraste (px)

Pro

b(Ta

m. d

o ar

rast

e <

x)

0 500 1500 2500

0.0

0.2

0.4

0.6

0.8

1.0

Zoom 16


Pro

b(Ta

m. d

o ar

rast

e <

x)

0 500 1500 2500

0.0

0.2

0.4

0.6

0.8

1.0

Zoom 17


Pro

b(Ta

m. d

o ar

rast

e <

x)

0 500 1500 2500

0.0

0.2

0.4

0.6

0.8

1.0

Zoom 18


Pro

b(Ta

m. d

o ar

rast

e <

x)

Figura 4.6: Adequação da distribuição Geométrica, com parâme-tros estimados a partir da função y =−0,0002038x+0,0085857, ao tamanho dos arrastes no eixo y.


uma probabilidade própria. Devido à grande quantidade de transições, não foi possívelapresentar todas na figura. A matriz de transição do modelo, cujas probabilidades foramextraídas dos dados coletados, é apresentada na Tabela 4.5.

Figura 4.7: Modelagem da direção e sentido dos arrastes. Algu-mas transições foram ocultadas na figura por motivosestéticos. Todos os estados estão interligados segundoas probabilidades apresentadas na Tabela 4.5.

0/PB 0/PC D/0 D/PB D/PC E/0 E/PB E/PC0/PB 0.2029 0.1014 0.0290 0.1014 0.0580 0.0145 0.1159 0.10140/PC 0.1528 0.1528 0.0000 0.0694 0.0972 0.0139 0.1250 0.1806

D/0 0.0741 0.0370 0.0370 0.1111 0.1481 0.0000 0.1111 0.1111D/PB 0.0044 0.0019 0.0013 0.3256 0.1073 0.0031 0.1374 0.1706D/PC 0.0026 0.0073 0.0040 0.1127 0.3388 0.0013 0.1648 0.1292

E/0 0.0714 0.0714 0.0714 0.0714 0.0714 0.1071 0.1071 0.1786E/PB 0.0056 0.0051 0.0023 0.1326 0.1462 0.0017 0.3521 0.1151E/PC 0.0018 0.0073 0.0012 0.1525 0.1123 0.0037 0.1251 0.3307Início 0.0096 0.0096 0.0048 0.2410 0.2230 0.0042 0.2698 0.2380

Tabela 4.5: Matriz de transição do modelo da Figura 4.7.

Uma simulação do processo estocástico do modelo de direções e sentidos retornasequências como a da Figura 4.8.


Figura 4.8: Exemplo de saída do modelo de direções e sentido doarraste.

4.2.4 Operação de zoom

A análise dos dados revelou que a frequência de acesso a cada nível de zoom édiferente, como pode ser visto na Figura 4.9. Um comportamento similar foi reportadopor Garcia et al. [14] ao analisar traces de servidores de mapas da Espanha. Os níveis dezoom entre 13 e 17 são os mais utilizados por permitirem uma navegabilidade confortávela nível de cidade e com um bom nível de detalhes. A queda na frequência de uso dosníveis de zoom superiores ao 17 é explicada pela proximidade em relação a superfíciedo planeta. Isso faz com que a região mostrada na tela seja pequena e torna a navegaçãomenos confortável, exigindo arrastes maiores para movimentar o mapa.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Nível de zoom

Fre

quên

cia

0.00

0.05

0.10

0.15

0.20

Figura 4.9: PDF do uso do mapa por nível de zoom.

Os níveis de zoom menores do que 13 apresentam um nível de detalhes pequeno,o que explica a queda gradual na frequência de uso deles. A maior frequência de uso donível de zoom 4, em relação a seus vizinhos, acontece por ele ter sido o nível de zoom

padrão para o início da navegação no maps.google.com durante a maior parte do períodode coleta.

Outra propriedade que analisamos na operação de zoom foi o tamanho dos saltos.A Figura 4.10 mostra a distribuição dos saltos, cujos valores à esquerda representam zoom


out e à direita representam zoom in. A maior parte dos saltos são pequenos e saltos muitograndes (maiores que 8) são raros. O terceiro quartil em ambos os lados é 2 e o percentil99 é 7.

Tamanho do salto

Fre

quên

cia

Zoom OutZoom In

15 10 5 1 1 5 10 15

1e−

41e

−3

1e−

21e

−1

Figura 4.10: Tamanho dos saltos na operação de zoom.

Os saltos variam de acordo com o nível de zoom, como exibido na Figura4.11. Nos níveis de zoom menores, a probabilidade de saltos de aproximação é maiore em níveis de zoom maiores, acontece o oposto. Dessa forma, é necessário modelar adistribuição de saltos em função do nível de zoom. Neste trabalho, modelamos os saltos demaneira indireta ao considerar os níveis de zoom como estados no modelo de sequênciade passos proposto na Seção 4.2.5. As probabilidades de transições entre os níveis dezoom no modelo criam um padrão de saltos semelhante aos dos dados coletados, comomostraremos no Capítulo 5.

A direção da mudança do ponto central na operação de zoom foi modeladautilizando um modelo de estados semelhante ao da operação de arraste, adicionando oestado 0 px/0 px. Diferentemente da operação de arraste, na operação de zoom é possívelter um movimento de tamanho 0 px nos dois eixos. Nesse caso, o zoom acontece semque haja alteração no ponto central do mapa, o que ocorre, geralmente, quando o usuárioutiliza os controles + e - da aplicação ou do teclado. A Tabela 4.6 apresenta a matrizde transição entre as diferentes direções que o mapa pode ser movimentado. Os estadosque contêm 0 px em apenas um eixo são raros, pois o ponteiro do mouse deve estarprecisamente no meio do mapa em um dos eixos. Por fim, assim como na operação dearraste, há uma maior tendência de que operações de zoom sequenciais tenham a mesmadireção e sentido.


Figura 4.11: Tamanho dos saltos na operação de zoom.

O tamanho da mudança do ponto central da operação de zoom foi medido emodelado em pixels. Para isso, transformamos as coordenadas geográficas dos pontoscentrais do mapa nos níveis de zoom inicial (z0) e final (z f ) em coordenadas de pixel

do zoom min(z0, z f ). A diferença entre as coordenadas de pixel representa o tamanho damudança. A escolha pelo nível de zoom menor é para padronizar o cálculo e obter valoresmenores e, consequentemente, mais simples de operar.

A distribuição Geométrica foi utilizada para modelar o tamanho da mudança doponto central. Utilizamos o Método de Máxima Verossimilhança para estimar o parâmetrop da Geométrica, obtendo os valores p= 0,0138865319 para o eixo x e p= 0,0086910695para o eixo y. As Figuras 4.12(a) e 4.12(b) mostram as CDFs do ajuste dos dados.

4.2.5 Frequência das operações e sequência de passsos

A Figura 4.13 mostra que as operações de zoom e arraste representam 80% dototal das operações realizadas no mapa. A operação de roteirização (Rota) aparece comuma frequência maior do que a operação de pesquisa. Isso ocorre porque a operaçãode roteirização é realizada em mais de um passo e cada um dos passos é contadoseparadamente, fazendo com que o número aumente.

Guan et al. [21] definiram as funções de distribuição 4-5, 4-6 e 4-7 que relaci-onam a tendência da frequência de uso das operações de zoom in e zoom out e arraste,respectivamente, em função do nível de zoom. A Figura 4.14(a) mostra o gráfico dessasdistribuições utilizando os valores λ = 3 e ω = 0,9, sugeridos pelos autores.


0/0 0/PB 0/PC D/0 D/PB D/PC E/0 E/PB E/PC0/0 0.855 0.000 0.000 0.000 0.034 0.034 0.000 0.026 0.051

0/PB 0.000 0.000 0.000 0.000 0.000 0.000 0.000 1.000 0.0000/PC 0.000 0.000 0.000 0.000 0.000 0.000 0.000 1.000 0.000

D/0 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000D/PB 0.015 0.000 0.000 0.000 0.418 0.088 0.000 0.086 0.394D/PC 0.008 0.000 0.000 0.000 0.076 0.481 0.000 0.339 0.095

E/0 0.000 0.000 0.000 0.000 0.200 0.400 0.200 0.200 0.000E/PB 0.027 0.000 0.000 0.000 0.080 0.335 0.002 0.436 0.119E/PC 0.008 0.000 0.000 0.000 0.260 0.113 0.002 0.094 0.525Início 0.058 0.001 0.001 0.001 0.207 0.233 0.002 0.249 0.248

Tabela 4.6: Matriz de transição do modelo da direção/sentido daoperação de zoom.

0 200 400 600

0.0

0.2

0.4

0.6

0.8

1.0

Tamanho do movimento (px)

Pro

b(Ta

man

ho d

o m

ovim

ento

≤ x

)

ObservadoGeométrica

(a) Tamanho dos movimentos da operação de zoom,em relação ao eixo x, vs. Distribuição Geomé-trica com p = 0,0138865319.

0 200 400 600

0.0

0.2

0.4

0.6

0.8

1.0

Tamanho do movimento (px)

Pro

b(Ta

man

ho d

o m

ovim

ento

≤ x

)

ObservadoGeométrica

(b) Tamanho dos movimentos da operação de zoom,em relação ao eixo y, vs. Distribuição Geomé-trica com p = 0,0086910695.

Figura 4.12: Adequação da distribuição Geométrica aos dados dotamanho dos movimentos da operação de zoom.

Zoom in:

f (l;λ) = 1−(

llmax

)λ, onde lmax é o nível de zoom máximo. (4-5)

Zoom out:

f (l;ω,λ) = ω(

llmax



Arraste Zoom Rota Pesquisa

Operação

% d

o to

tal

0.0

0.1

0.2

0.3

0.4

0.5

0.42 0.38 0.13 0.07

Figura 4.13: Frequência relativa das operações.

Arraste:

f (l;ω,λ) = (1−ω)(

llmax


Fizemos uma análise dos dados coletados a fim de investigar a tendência mos-trada por Guan et al. [21]. O resultado da análise pode ser visto na Figura 4.14(b). Emnossa avaliação, confirmamos a presença da tendência encontrada pelos autores. Con-tudo, os valores dos parâmetros que melhor se ajustaram aos nossos dados foram λ = 0,5e ω = 0,4.

Adicionalmente, modelamos a sequência de passos dos usuários através deum modelo de estados (Modelo de Estados de Sequência de Passos - MESP), cujosestados são os níveis de zoom e as operações realizadas no mapa, com exceção dasoperações de arraste e zoom. Essas duas operações são as mais elementares de um SIGWeb, portanto, resolvemos representá-las de uma maneira diferente das demais. Elassão representadas como transições, sendo transições entre níveis de zoom diferentesconsideradas operações de zoom e transições entre um mesmo nível de zoom consideradasarrastes. Essa abordagem, além de destacar as operações de arraste e zoom das demais,simplifica o modelo ao diminuir a quantidade de estados e transições necessárias pararepresentar todas as operações.

A Figura 4.15 mostra o diagrama do MESP. Com o intuito de melhorar avisualização do diagrama, as transições entre os estados, com exceção das transiçõesque representam operações de arraste e zoom, foram colocadas como setas de duas


5 10 15 20

0.0

0.2

0.4

0.6

0.8

1.0

Nível de zoom

Fre

quên

cia

ArrasteZoom inZoom out

(a) Frequência relativa das operações de Arraste,Zoom in e Zoom out por nível de zoom, utili-zando às funções propostas por Guan et al. [21]com os valores dos parâmetros sugeridos pelosautores: λ = 3 e ω = 0,9.

0 5 10 15 20

0.0

0.2

0.4

0.6

0.8

1.0

Nível de zoom

Fre

quên

cia

ArrasteZoom inZoom out

(b) Frequência relativa das operações de Arraste,Zoom in e Zoom out por nível de zoom. As linhastracejadas representam a adequação às funçõespropostas por Guan et al. [21] com parâmetrosλ= 0,5 e ω= 0,4 e as linhas contínuas represen-tam as distribuições empíricas geradas a partirdos dados coletados.

Figura 4.14: Comparação das distribuições propostas por Guan etal. [21], utilizando (a) parâmetros que se ajustam aosdados coletados e (b) os parâmetros sugeridos pelosautores.

pontas. Outra simplificação foi a representação de apenas dois níveis de zoom. No modelocompleto, há estados representando cada um dos níveis de zoom.

O início e o fim da sessão de navegação também são representados como umestado (I/F) e suas transições são ligadas aos estados de zoom para representar que anavegação pode iniciar e ser encerrada em qualquer nível de zoom. Há transições entreo estado I/F e os estados das operações de pesquisa (Pq) e Rota (R), representando oscasos em que o primeiro acesso é feito através de URLs que direcionam o SIG Web

diretamente para os resultados dessas operações3. Nesses casos, a transição é feita doI/F para a operação e, posteriormente, para um estado que representa um nível de zoom.

Como também pode ser observado na Figura 4.15, uma transição de um nível dezoom X para o mesmo nível de zoom X representa um arraste; uma transição entre o nívelde zoom X para o nível de zoom Y , sendo Y > X , representa um zoom in; e uma transiçãoentre o nível de zoom X para um nível de zoom W , sendo W < X , representa um zoom

out. Os valores do tipo P(S1→ S2) indicam a probabilidade de mudança do estado S1 parao estado S2. Calculamos essas probabilidades nos dados coletados e obtivemos a matriz

3Isso pode acontecer, por exemplo, quando o acesso ao mapa é direcionado a partir do resultado de umapesquisa em um sistema de busca.


Figura 4.15: Modelo de estados da sequência de passos.

de transição, apresentada nas Tabelas B.1, B.2, B.3 e B.4, dispostas no Apêndice B porquestões de espaço.

4.2.6 Popularidade dos tiles

Para avaliar a popularidade dos tiles, contamos a quantidade de vezes que cadatile foi requisitado pelos usuários e os ordenamos em ordem crescente de quantidadede requisições. Encontramos resultados semelhantes aos de outros trabalhos [12, 21],confirmando que a popularidade dos tiles segue a Lei de Zipf. Essa lei afirma que, se ostiles forem ordenados em ordem crescente de popularidade, então o número de referênciasao tile i tende a ser inversamente proporcional a iα, seguindo a Equação 2-10. O valor C daEquação 2-10 é uma constante positiva e α é o expoente de decaimento. Valores maioresde α implicam em uma maior concentração de requisições a um pequeno conjunto de tiles

populares [2, 21].A Figura 4.16(a) mostra um gráfico com o número de acessos no eixo x vs.

a quantidade de tiles que tiveram x acessos. Conforme esperado, determinados tiles

são bastante requisitados, enquanto outros, raramente são. A Figura 4.16(b) mostra adistribuição de popularidade dos tiles e o ajuste da distribuição Zipf. Utilizando o métodoMLE, o valor estimado para o parâmetro α da Zipf foi de 1,565501.

Com o intuito de ilustrar a distribuição dos acessos aos tiles, geramos um mapa


1 5 50 500

110

100

1000

Nº de acessos

Qtd

. tile

s co

m x

ace

ssos

(a) Popularidade dos tiles. O eixo x contém o nú-mero de acessos a um tile e o eixo y a quan-tidade de tiles que tiveram aquele número derequisições.

1 2 5 20 50 200

1e−

051e

−03

1e−

01

Índice

Fre

quên

cia

(b) Ajuste à distribuição Zipf com α = 1,565501.O eixo x contém o índice de popularidade dostiles e o eixo y a frequência acessos aos tilescom índice x. A reta vermelha representa oajuste.

Figura 4.16: Popularidade dos tiles (a) e ajuste da distribuiçãoZipf à distribuição de frequência de popularidade(b).

de calor com as regiões acessadas. Para isso, utilizamos o Leaflet.heat4 e os pontosinseridos no mapa foram as coordenadas geográficas coletadas. O resultado pode servisto nas Figuras 4.17 e 4.18. Como esperado, as regiões mais acessadas são cidades,sendo Goiânia a região mais acessada, visto que a maioria dos usuários que instalarama extensão residem nessa cidade. Esse resultado reforça outros encontrados na literatura[12, 14, 21].

Figura 4.17: Mapa de calor a nível mundial.

4Leaflet.heat: https://github.com/Leaflet/Leaflet.heat.

4.3 Camada de transferência de tiles 67

Figura 4.18: Mapa de calor a nível estadual, com foco em Goiâniae Brasília.

4.3 Camada de transferência de tiles

Nesta seção, avaliamos a influência da resolução da tela no número de tiles

requisitados por operação de zoom e arraste. Além disso, utilizamos essa informação e oconhecimento do tamanho, em bytes, dos tiles para estimar o volume de dados transferidospor operação e por sessão. Por fim, analisamos o volume de dados transferidos com baseno tamanho das respostas a todas as requisições.

4.3.1 Resolução da tela vs. número de tiles

Na versão do Google Maps utilizada na coleta de dados, o mapa ocupa toda apágina e sua resolução, geralmente, utiliza todo o espaço horizontal (eixo x) e perde algumespaço vertical (eixo y) devido à área ocupada pelas barras do navegador e do sistemaoperacional. A Figura 4.19 apresenta a distribuição das 10 resoluções de mapa maisfrequentes nos dados coletados. Em outras aplicações, o mapa pode não preencher todaa página e, nesses casos, as resoluções serão diferentes das apresentadas na Figura 4.19.Contudo, independente do espaço ocupado na página, a resolução do mapa é diretamenteproporcional à resolução da tela.

Uma vez que não foi possível coletar diretamente as informações de quais tiles

foram requisitados, avaliamos a quantidade de tiles requisitados considerando todos ostiles necessários para preencher o espaço da tela. Dessa forma, desconsideramos fatorescomo caching e prefetching de tiles.

A Figura 4.20 mostra a distribuição do número de tiles requisitados na operaçãode arraste. Na maioria dos casos, o número de tiles é zero devido ao grande número dearrastes pequenos, os quais apenas mostram partes de tiles que já haviam sido trazidosdo servidor, mas não apareciam na tela. A figura mostra uma tendência de redução dasprobabilidades à medida que os valores no eixo x aumentam. Isso ocorre porque os valores


Frequência

1280x899

1279x678

1311x657

1440x799

1366x677

1920x947

1440x785

1366x667

1920x955

1366x643

0 0.05 0.15 0.25

Figura 4.19: 10 resoluções mais frequentes (em pixels).

maiores estão relacionados a arrastes maiores, os quais ocorrem com menor frequência,como mostrado na Seção 4.2.3.

Número de tiles

0 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 40 42 45 48 66

Fre

quên

cia

1e−4

1e−3

1e−2

1e−1

5e−1

Figura 4.20: Distribuição do número de tiles requisitados por ope-ração de arraste.

A Figura 4.21 mostra a distribuição do número de tiles requisitados na operaçãode zoom. As quantidades de tiles mais requisitadas são 18, 24 e 28, devido às resoluçõesde tamanho próximas a 1366x768 px, a qual é a resolução de tela mais utilizada nomundo [43]. Dependendo de como os tiles estiverem organizados, essa resolução podesuportar 6 ou 7 tiles no eixo x e 3 ou 4 tiles no eixo y. A multiplicação desses valoresresulta nos valores 18, 24, 28 e 21, sendo que o 21 também é um das mais recorrentes.As quantidades 40 e 45 também estão entre as mais frequentes e estão relacionadas àresolução de tela 1920x1080 px, que é a segunda mais comum [43]. Nessa resolução, umzoom pode requisitar 32, 36, 40 ou 45 tiles, dependendo de como eles estão organizadosna tela.


Número de tiles

4 9 12 15 16 18 20 21 24 25 28 30 32 35 36 40 42 45 55 60 66

Fre

quên

cia

1e−4

1e−3

1e−2

1e−1

5e−1

Figura 4.21: Distribuição do número de tiles requisitados por ope-ração de zoom.

4.3.2 Volume de dados transferidos

O volume de dados transferido foi analisado de duas maneiras: (1) levando emconsideração apenas o tamanho dos tiles transferidos e (2) levando em consideração otamanho de todas as respostas às requisições feitas na sessão de navegação.

As Figuras 4.22(a) e 4.22(b) mostram as CDFs da quantidade de dados transferi-dos nas operações de arraste e zoom, respectivamente, levando em consideração apenas ostiles carregados durante cada operação. A Tabela 4.7 contém a média e alguns percentisrelacionados às CDFs. 99% dos arrastes exigem a transferência de menos de 344,71 KBde imagens de tiles e 99% dos zooms exigem menos de 883,71 KB.

0 200 400 600 800

0.0

0.2

0.4

0.6

0.8

1.0

Tamanho (KB)

P(T

aman

ho ≤

x)

(a) CDF da quantidade de dados do conjunto detiles requisitado por operação de arraste.

0 500 1000 1500

0.0

0.2

0.4

0.6

0.8

1.0

Tamanho (KB)

P(T

aman

ho ≤

x)

(b) CDF da quantidade de dados do conjunto detiles requisitado por operação de zoom.

Figura 4.22: CDFs da quantidade de dados transferidas por ope-ração de arraste e zoom.


Operação Média 25o 50o 75o 99o PercentilArraste 69,52 KB 0,00 KB 51,05 KB 106,60 KB 344,71 KBZoom 360,10 KB 213,70 KB 345,80 KB 482,80 KB 883,71 KB

Tabela 4.7: Média e principais percentis da quantidade de dadostransferidos por operação de arraste e de zoom, le-vando em consideração apenas os tamanhos das ima-gens dos tiles.

A Figura 4.23 mostra a CDF da quantidade média de dados transferidas por ope-ração, utilizando para isso a informação do tamanho de todas as respostas às requisições.A Tabela 4.8 contém a média e alguns percentis importantes dessa CDF. Em 99% dasocasiões, as operações geram a transferência de até aproximadamente 2,59 MB.

0 1000 2000 3000 4000

0.0

0.2

0.4

0.6

0.8

1.0

Quantidade média de KB

P(Q

uant

idad

e m

édia

de

KB

≤ x

)

Figura 4.23: CDF da quantidade média de dados transferidos poroperação.

Média 25o 50o 75o 99o Percentil547,80 KB 193,40 KB 327,20 KB 650,50 KB 2,59 MB

Tabela 4.8: Média e principais percentis da quantidade média dedados transferidos por operação.

A Figura 4.24(a) compara as CDFs do volume de dados transferidos, por sessão,considerando apenas o tamanho dos tiles (Tiles) e considerando o tamanho das respostasa todas às requisições (TR). A Tabela 4.9 apresenta um resumo com algumas estatísticasdescritivas das distribuições. As imagens dos tiles representam uma parte relevante dototal de dados transferidos, mas, em geral, representam menos da metade do volume total.


500 2000 5000 20000

0.0

0.2

0.4

0.6

0.8

1.0

Tamanho (KB)

P(T

aman

ho ≤

x)

TRTiles

(a) CDF da quantidade de dados transferidos porsessão, considerando todas as requisições (TR)e considerando apenas as requisições a tiles(Tiles).

0 1000 3000 5000

0.0

0.2

0.4

0.6

0.8

1.0

Kbps

P(K

bps

≤ x

)

(b) CDF da taxa média de transferência de dadosdurante as sessões de navegação.

Figura 4.24: Avaliação da quantidade de dados transferidas porsessão e da taxa média de transferência de dados.

Tipo Média 25o 50o 75o 99o PercentilTiles 1,97 MB 0,76 MB 1,48 MB 2,64 MB 8,43 MBTodas as Requisições (TR) 4,40 MB 2,04 MB 3,12 MB 5,38 MB 22,26 MB

Tabela 4.9: Média e principais percentis das quantidades de dadostransferidos por sessão de navegação, considerandotodas as requisições e considerando apenas as requi-sições a tiles.

Na Figura 4.24(b), ilustramos a CDF da quantidade média de dados transferidospor segundo, durante as sessões de navegação. Na Tabela 4.10, mostramos a médiae os principais percentis dessa distribuição. Em nossos dados, o volume médio deinformações transferidas por segundo não chega a ser um fator limitante, levando emconsideração a velocidade das conexões banda larga atuais. Contudo, esses valores podemser significativamente maiores em aplicações que enviem grande quantidade de dados paraserem renderizados.

Média 25o 50o 75o 99o Percentil483,00 Kbps 69,85 Kbps 233,20 Kbps 576,90 Kbps 3,26 Mbps

Tabela 4.10: Média e principais percentis da taxa média de trans-ferência de dados por sessão de navegação.

4.4 Instância do modelo de comportamento 72

4.4 Instância do modelo de comportamento

Algumas das características descritas anteriormente foram combinadas paraformar uma instância do MUSe-GM, apresentado na Seção 3.2. Certas característicasnão fazem parte da instância, pois são obtidas indiretamente. Por exemplo, o modelo deestados da sequência de passos (MESP), descrito na Seção 4.2.5, é responsável por criaras ações dos usuários até atingir o estado Início/Fim. Dessa forma, não há necessidadede utilizar a distribuição de número de ações por sessão de navegação, pois o MESP,indiretamente, gera o número de ações de cada sessão.

Abaixo segue a lista das características utilizadas como componentes da instân-cia do modelo:

• o MESP, descrito na Seção 4.2.5;• o modelo de caracterização da operação de arraste, proposto na Seção 4.2.3;• o modelo de caracterização da operação de zoom, proposto na Seção 4.2.4;• a distribuição dos intervalos entre ações, apresentada na Seção 4.2.2 e;• o conceito de pontos de interesse abordados na literatura [12, 14, 21] e discutido na

Seção 4.2.6

Além desses componentes, utilizamos a distribuição das resoluções de monitoresmais utilizadas no mundo, com base nos dados do StatCounter Global Stats [43] paragerar os tamanhos da telas dos usuários simulados. Por simplicidade, consideraremos queo mapa ocupa toda a tela.

Uma vez que não obtivemos um conjunto relevante de dados sobre as operaçõesde pesquisa e roteirização, a instância do modelo aqui apresentada irá considerar apenasas operações de arraste e zoom. Para isso, é necessário remover os estados de Pesquisa eRota da matriz de transição do MESP, apresentada no Apêndice B.

O Algoritmo 4.1 mostra como os componentes operam em conjunto para formara instância do modelo e simular uma sessão de navegação. Na linha 1, o ponto inicialde navegação é selecionado. Na linha 2, a resolução da tela é escolhida. Na linha 3,o intervalo entre a abertura da página inicial e a próxima ação é selecionado, atravésda distribuição de intervalos. O nível de zoom inicial é extraído, na linha 4, a partir doMESP, considerando as probabilidades de saída a partir do estado Início/Fim. Na linha 5,a operação para abertura da página inicial é criada, utilizando os dados gerados nas linhasanteriores.

Da linha 8 à linha 27, as operações são geradas e configuradas de acordo comseu tipo, até que o estado Início/Fim seja atingido. Quando esse estado é atingido, umaoperação final é criada (linha 29), indicando o encerramento da sessão de navegação.

O ponto inicial de navegação – sorteado pela função pontoInicial na linha 1– pode ser escolhido a partir das informações coletadas a respeito da distribuição de

4.4 Instância do modelo de comportamento 73

Algoritmo 4.1: Algoritmo da instância do MUSe-GM – Simula uma sessão denavegação.

Saída: CO - Conjunto de operações da sessão de navegação.PONTO_INICIAL← pontoInicial()1

RESOLUCAO← resolucao()2

INT ERVALO← intervalo()3

/* Seleciona o primeiro nível de zoom, a partir dasprobabilidades de saída do estado Início/Fim */

ZOOM_INICIAL← nivelDeZoomInicial()4

PAGINA_INICIAL← novaAcaoInicial(PONTO_INICIAL,5

ZOOM_INICIAL, INT ERVALO)6

CO.adiciona(PAGINA_INICIAL)7

/* Seleciona o próxima operação, a partir das probabilidades desaída do estado equivalente ao nível zoom corrente */

ACAO← proximaAcao()8

enquanto ACAO.Tipo 6= Inicio/Fim faça9


se ACAO.Tipo = Arraste então11

TAMANHO_ARRAST E← tamanhoDoArraste(ACAO.ZoomAtual)12

ARRAST E← novoArraste(TAMANHO_ARRAST E, INT ERVALO)13

CO.adiciona(ARRAST E)14

senão se ACAO.Tipo = Zoom In então15

TAMANHO_MUDANCA← mudancaDoCentro(ACAO.ZoomAtual)16

ZOOM← novoZoom(ACAO.ZoomAtual, ACAO.ZoomFinal,17

TAMANHO_MUDANCA, INT ERVALO)18

CO.adiciona(ZOOM)19

senão20

TAMANHO_MUDANCA← mudancaDoCentro(ACAO.ZoomFinal)21

ZOOM← novoZoom(ACAO.ZoomAtual, ACAO.ZoomFinal,22

TAMANHO_MUDANCA, INT ERVALO)23

CO.adiciona(ZOOM)24

fim25

ACAO← proximaAcao()26

fim27


ACAO_FINAL← novaAcaoFinal(INT ERVALO)29

CO.adiciona(ACAO_FINAL)30

popularidade dos tiles. No entanto, quando não há informações suficientes coletadas,pode-se recorrer a uma base de pontos de interesse, como apresentado por Guan et al.

[21].A função tamanhoDoArraste utiliza os modelos de direção e de tamanho dos

movimentos do arraste para sortear os valores do tamanho do arraste. Por outro lado,a função mudancaDoCentro utiliza os modelos propostos na Seção 4.2.4 para sortear o

4.5 Conclusão 74

valor da mudança no ponto central da operação de zoom. Quando a operação é do tipozoom in, o cálculo das novas coordenadas centrais é feito em relação ao nível de zoom

corrente (linha 16). Quando é do tipo zoom out, é realizado em relação ao nível de zoom

final (linha 21).A Figura 4.25 ilustra uma sequência de saída criada pela instância do modelo.

Inicialmente, é realizada a configuração da resolução da tela. Após essa configuraçãopreliminar, a página inicial é carregada e a execução das ações tem início. Na operaçãode zoom, o parâmetro z0 é o nível de zoom inicial e o parâmetro z f é o nível de zoom

final. Os parâmetros x e y representam o tamanho do movimento do mapa nos eixos x e y,respectivamente. Os círculos vermelhos, representam os intervalos entre as ações.

Figura 4.25: Exemplo de saída de simulação da instância do mo-delo.

4.5 Conclusão

Neste capítulo, apresentamos uma caracterização detalhada do comportamentopadrão de usuários de um SIG Web e seu impacto em termos de requisições de tiles.Avaliamos também o volume de dados transferidos por operação e por sessão de navega-ção. Por fim, descrevemos uma instância do MUSe-GM, utilizando alguns resultados dacaracterização como componentes dessa instância.

No próximo capítulo, iremos apresentar uma avaliação da instância do MUSe-GM e traçaremos também um comparativo entre o MUSe-GM e outros dois modelosexistentes.

CAPÍTULO 5Avaliação do Modelo

Este capítulo apresenta uma avaliação do MUSe-GM, especificamente, da instân-cia apresentada no Capítulo 4. A avaliação é feita através de simulações, implementadasno Software R [35], e de testes de desempenho executados na plataforma de mapas Web

goGeo. Implementamos também um modelo de requisição de tiles aleatórios (MA)1 e omodelo HELP, proposto por Guan et al. [21], a fim de investigar as diferenças deles emrelação ao MUSe-GM.

5.1 Considerações iniciais

Para realizar as simulações e os testes de desempenho deste capítulo, considera-mos acessos aos tiles do território dos Estados Unidos da América (EUA). Com o propó-sito de simular a popularidade dos tiles nessa região, utilizamos uma base de dados quecontém as coordenadas e a população estimada de cidades e outras regiões dos EUA noano 20002. Essa mesma abordagem foi utilizada tanto no MUSe-GM, quanto no HELP. Aseguir, detalhamos a implementação do MA e apresentamos algumas considerações sobreo HELP.

5.1.1 Modelo de tiles aleatórios

O MA realiza chamadas a tiles de maneira aleatória, sem levar em consideração aproximidade entre tiles em chamadas subsequentes. Cada cliente requisita apenas um tile

simultaneamente e não há intervalo entre as requisições. Os tiles são ordenados de acordocom suas coordenadas de tile, utilizando como primeiro fator de ordenação o nível dezoom, seguido pela coordenada x e pela coordenada y, nessa ordem. A escolha do tile

é realizada utilizando uma distribuição uniforme, no intervalo [1, NUM_TILES), sendoNUM_TILES, o número total de tiles considerados.

1Modelos de requisições de tiles aleatórios são, usualmente, utilizados para testes de estresse [21, 26]em sistemas baseados em tiles.

2Esri ArcGIS Sample Data - http://www.baruch.cuny.edu/geoportal/data/esri/esri_usa.htm.

5.1 Considerações iniciais 76

Uma vez que os testes podem se restringir a alguma região específica, o MAfoi desenvolvido de forma a acessar apenas tiles predeterminados. Para tanto, o modelorecebe uma lista de tiles em um mesmo nível de zoom e a partir dessa lista identificaos tiles equivalentes nos outros níveis de zoom. Dessa forma, é possível fornecer comoentrada uma lista de tiles em um nível de zoom menor, que, por exemplo, corresponda aoterritório de algum país, e o MA identifica todos os tiles equivalentes nos outros níveisde zoom. Em nossos testes, a lista de tiles fornecida como entrada para o MA engloba oterritório dos EUA, conforme descrito previamente, e é apresentada na Figura 5.1.

Figura 5.1: Lista de tiles dos EUA no nível de zoom 5. A imagemde fundo foi obtida do MapTiler [28].

5.1.2 Modelo HELP

O modelo HELP foi implementado a partir de sua descrição apresentada notrabalho de Guan et al. [21]. No entanto, a indisponibilidade de algumas informaçõesexigiu que alguns parâmetros fossem estimados ou assumidos, conforme descrito a seguir.A resolução foi estimada a partir de uma figura apresentada no artigo, a qual sugere o usode 3 tiles em cada direção. Portanto, assumimos uma resolução fixa de 768x768 px, a qualsuporta 3x3 tiles. No artigo, não há citação sobre modelagem do tamanho dos arrastes,mas a unidade elementar utilizada em todo o modelo é o tile. Portanto, assumimos umtamanho de arraste fixo equivalente ao tamanho de um tile. Assumimos também o uso dadistribuição uniforme para modelar o tamanho dos saltos e a direção e sentido dos arrastes.O conjunto de todas as variáveis utilizadas para modelar o HELP com suas respectivasdistribuições e valores são apresentados na Tabela 5.1.

5.2 Simulações 77

Variável Distribuição/Valor ParâmetrosHotspots Bases de pontos de interesse Esri ArcGIS Sample DataTamanho das sessões Weibull β = 0,311; α = 0,2912Intervalo entre ações Pareto k = 1; α = 1,5Caminho das operações Zoom in: Equação 4-5,

Zoom out: Equação 4-6, ω = 0,9; λ = 3Arraste: Equação 4-7

Direção/sentido do Uniforme a = 0; b = 3, sendoarraste 0 - Para cima

1 - Para Baixo2 - Direita3 - Esquerda

Tamanho dos arrastes 1 tile = 256 px -Resolução da tela 3x3 tiles = 768x768 px -Tamanho dos saltos Uniforme a = 1;

Zoom In:b = abs(Zatual−Zmax)

ouZoom Out: b = Zatual ,onde Zatual é o nível de zo-om atual e Zmax é o nívelde zoom máximo

Tabela 5.1: Variáveis do HELP e suas respectivas distribuições evalores.

5.2 Simulações

Nesta seção, avaliamos, através de simulações, a adequação da instância doMUSe-GM às características não utilizadas diretamente em sua construção. Essa análiseserá apresentada na Seção 5.2.1. Realizamos também simulações com os modelos MA eHELP, com o objetivo de comparar as três soluções. Os resultados dessa comparação sãodiscutidos na Seção 5.2.2.

5.2.1 Validação da instância do modelo

Conforme descrito no Capítulo 4, alguns aspectos da caracterização não foramutilizados para compor a instância do modelo, pois podem ser obtidos indiretamente poroutras características consideradas. A seguir, avaliamos a adequação do comportamentodas características obtidas de forma indireta em relação ao comportamento verificado nosdados coletados.

O número de ações em uma sessão é gerado indiretamente pelo MESP, comomostrado no capítulo anterior. A Figura 5.2(a) apresenta a comparação entre a distri-buição de número de ações geradas pelo MESP com a distribuição empírica dos dados

5.2 Simulações 78

coletados. Embora a distribuição empírica apresente uma maior assimetria à direita, elassão semelhantes no corpo da distribuição.

0 50 100 150 200 250

0.0

0.2

0.4

0.6

0.8

1.0

Número de ações

P(N

úmer

o de

açõ

es≤

x)

DadosMUSe−GM

(a) CDF do número de ações em uma sessão simu-lada baseada no MUSe-GM.

1e+00 1e+02 1e+04 1e+06

0.0

0.2

0.4

0.6

0.8

1.0

Duração (s)P

(Dur

ação

da

sess

ão≤

x)

DadosMUSe−GM

(b) CDF do número de ações em uma sessão simu-lada baseada no MUSe-GM.

Figura 5.2: Comparação da duração e do número de ações nassessões do MUSe-GM com os dados coletados dassessões de usuários reais.

A duração das sessões também não é utilizada diretamente na instância doMUSe-GM e depende do número de ações geradas pelo MESP e dos intervalos gerados apartir da distribuição de intervalos. A Figura 5.2(b) ilustra a comparação da distribuiçãode duração das sessões geradas pelas simulações e a distribuição empírica. A distribuiçãoempírica apresenta uma cauda maior, contudo elas são semelhantes na maior parte dacurva.

Os arrastes são gerados utilizando dois tipos de informações: a distribuição dotamanho dos movimentos e o modelo de direções. A combinação desses dois componentesresultou nas distribuições apresentadas nas Figuras 5.3(a) e 5.3(b), relacionadas aos eixosx e y, respectivamente. O ajuste das distribuições de tamanho dos arrastes simulados emrelação aos dados coletados foi melhor no eixo y do que no eixo x. Essa diferença eraesperada, devido a simplificação adotada ao utilizar um modelo linear para calcular osparâmetros das distribuições. Apesar disso, o modelo de estados utilizado para modelar asdireções se mostrou adequado, visto que, assim como nos dados coletados, a distribuiçãode tamanho dos arrastes se mostrou simétrica em relação ao valor 0.

O MESP é responsável por escolher os níveis de zoom que devem ser acessadosem cada ação. Dessa forma, as distribuições de frequência de uso dos níveis de zoom ede tamanho dos saltos, observadas nos dados, não foram utilizadas na instância. Todavia,

5.2 Simulações 79


Den

sida

de

1500 500 0 500 1500

0.00

00.

002

0.00

40.

006

Esquerda Direita

DadosMUSe−GM

(a) Distribuições do tamanho dos arrastes no eixo xdos dados coletados e dos dados simulados.


Den

sida

de

1500 500 0 500 1500

0.00

00.

002

0.00

40.

006

Para cima Para Baixo

DadosMUSe−GM

(b) Distribuições do tamanho dos arrastes no eixo ydos dados coletados e dos dados simulados.

Figura 5.3: Comparação do tamanho dos arrastes nas sessões doMUSe-GM com os dados coletados das sessões deusuários reais.

como ilustrado nas Figuras 5.7(a) e 5.4, o uso do MESP resultou em distribuições comum padrão semelhante às encontradas nos dados coletados.

Tamanho do salto

Fre

quên

cia

Zoom OutZoom In

15 10 5 1 1 5 10 15

1e−

031e

−02

1e−

01

Figura 5.4: Distribuição do tamanho dos saltos na operação dezoom das sessões simuladas pelo MUSe-GM.

5.2.2 Comparação entre os modelos

Comparamos os modelos quanto às distribuições de frequência de uso dos níveisde zoom, de popularidade dos tiles acessados, do número de ações dos usuários simulados,

5.2 Simulações 80

da duração das sessões e quanto ao número de tiles requisitados por operação e por sessãode navegação. Naturalmente, o MA não foi avaliado com relação a sessão e operações,uma vez que não implementa esses conceitos.

Duração e tamanho das sessões de navegação

A Figura 5.5(a) mostra as CDFs empíricas das durações das sessões resultantesdas simulações do MUSe-GM e do HELP. Na tabela 5.2, destacamos algumas métricasdescritivas dessas distribuições. As sessões do MUSe-GM duram, em média, mais tempodo que as do HELP. O principal motivo para isso é que o número de ações por sessão doMUSe-GM e os intervalos entre ações são maiores, em média.

Modelo Mínimo 1o Quartil 2o Quartil Média 3o Quartil MáximoMUSe-GM 1,032 25,69 70,92 207,7 174,2 9976HELP 2,014 2,98 4,42 11,71 8,58 397,5

Tabela 5.2: Estatísticas descritivas da duração das sessões de na-vegação do MUSe-GM e do HELP.

1e+00 1e+02 1e+04 1e+06

0.0

0.2

0.4

0.6

0.8

1.0

Duração (s)

P(D

uraç

ão d

a se

ssão

≤ x

)

MUSe−GMHELP

(a) CDFs da duração de sessões de navegação doMUSe-GM e do HELP.

0 50 150 250 350

0.0

0.2

0.4

0.6

0.8

1.0

Número de ações

P(N

úmer

o de

açõ

es≤

x)

MUSe−GMHELP

(b) CDFs do número de ações de sessões de nave-gação do MUSe-GM e do HELP.

Figura 5.5: Comparação da duração e do número de ações nassessões do MUSe-GM e do HELP.

A Figura 5.5(b) apresenta a comparação das CDFs do número de ações porsessão dos dois modelos. Na Tabela 5.3, apresentamos algumas das principais métricasdescritivas das distribuições resultantes das simulações. O número de ações do MUSe-GM tende a ser maior do que do HELP. A distribuição proposta pelo HELP é provinda deestudos de número de ações em em sites tradicionais, sem a interatividade de um mapa

5.2 Simulações 81

Web. Em vista disso, acreditamos que o número de ações geradas pelo MUSe-GM é maisadequado no contexto dos SIGs Web.

Modelo Mínimo 1o Quartil 2o Quartil Média 3o Quartil MáximoMUSe-GM 1 6 12 16,76 23 181HELP 1 1 1 4,068 1 338

Tabela 5.3: Estatísticas descritivas do número de ações do MUSe-GM e do HELP.

Operação de arraste

A operação de arraste possui um comportamento significativamente diferenteentre os dois modelos. No MUSe-GM existe uma variação no tamanho dos arrastes e emrelação à direção deles, a qual não é levada em consideração no HELP. No HELP, comoilustrado na Figura 5.6(b), o tamanho dos arrastes é fixo e realizado apenas em 4 sentidos– esquerda, direita, para cima e para baixo. Essa simplificação torna o comportamento dosusuários sintéticos mais distante da realidade.


Den

sida

de

1000 500 0 500 1000

0.00

000.

0010

0.00

200.

0030

Esquerda

Para cima

Direita

Para Baixo

XY

(a) Gráfico de densidade do tamanho dos arrastesno MUSe-GM.

256 0 256Tamanho do arraste (px)

Fre

quên

cia

0.0

0.1

0.2

0.3

0.4

0.5

0.6

Esquerda

Para cim

a

Direita

Para B

aixo

XY

(b) Frequência de tamanho dos arrastes no HELP.

Figura 5.6: Tamanho dos arrastes nos modelos MUSe-GM eHELP.

Operação de zoom

Nas simulações do HELP, utilizamos o nível de zoom 6 como inicial – assimcomo nos testes do trabalho original – e o 21 como nível máximo3. Como ilustrado na

3No HELP o nível de zoom máximo é configurável.

5.2 Simulações 82

Figura 5.7(b), a distribuição de frequência gerada pelo HELP é diferente da gerada peloMUSe-GM. Ela se apresenta crescente em relação aos níveis de zoom, o que difere docomportamento exposto na caracterização do Capítulo 4 e dos resultados do trabalho deGarcía et al. [14].

Nível de zoom

Fre

quên

cia

0.00

0.05

0.10

0.15

0.20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

(a) Frequência de uso dos níveis de zoom dos usuá-rios simulados baseados no MUSe-GM.

Nível de zoom

Fre

quên

cia

0.00

0.05

0.10

0.15

0.20

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

(b) Frequência de uso dos níveis de zoom dos usuá-rios simulados baseados no HELP.

Figura 5.7: Frequências de uso dos níveis de zoom nos modelosMUSe-GM e HELP.

Popularidade dos tiles

O modelo MA acessa os tiles com a mesma probabilidade, ou seja, há umadistribuição uniforme de acesso aos tiles e seu mapa de calor possui a mesma intensidadeem todas as regiões, como pode ser visto na Figura 5.8(a). Esse tipo de comportamento,como abordado anteriormente, não é adequado para representar o comportamento deusuários reais.

O HELP e o MUSe-GM revolvem o problema da popularidade dos tiles damesma maneira, utilizando informações sobre pontos de interesse para a escolha do pontoinicial. Como é possível ver nas Figuras 5.8(b) e 5.8(c), o mapa de calor dos dois modelosé semelhante e determinadas regiões são mais acessadas do que outras. Essas regiõessão tiles pertencentes às grandes cidades, mostrando que o comportamento de ambos osmodelos são adequados em relação aos estudos de popularidade de tiles presentes naliteratura [12, 14, 34].

Apesar de semelhantes, o mapa de calor do MUSe-GM abrange um númeromaior de localidades do que o HELP. Isso ocorre porque o MUSe-GM considera amudança do ponto central do mapa na operação de zoom. As operações de zoom in/out

que acessam níveis de zoom menores podem centralizar o mapa em pontos distantes,

5.2 Simulações 83

(a) Mapa de calor dos tiles requi-sitados pelo MA.

(b) Mapa de calor dos tiles requi-sitados pelo HELP.

(c) Mapa de calor dos tiles requi-sitados pelo MUSe-GM.

Figura 5.8: Frequências de uso dos níveis de zoom nos modelosMUSe-GM e HELP.

gerando acesso a esses pontos. Outro fator que influencia é que, no MUSe-GM, a operaçãode arraste pode gerar arrastes maiores do que no HELP e, ainda, arrastes sequenciaistem uma maior probabilidade de seguir em uma mesma direção do que no HELP. Essecomportamento do MUSe-GM pode, então, fazer com que pontos mais distantes do pontoinicial sejam acessados com maior probabilidade do que no HELP. Por fim, o MUSe-GMtambém considera resoluções de tela maiores e que suportam mais tiles, o que tambémcolabora para a requisição de tiles em pontos mais distantes do ponto inicial.

Transferência de tiles

Por considerar mais características dos usuários reais, o MUSe-GM possuidistribuições de número de tiles por operação e por sessão que são significativamentediferentes das distribuições do HELP. A seguir, apresentamos uma comparação entre essasdistribuições.

As Figuras 5.9(a) e 5.9(b) ilustram como o MUSe-GM gera uma maior varia-bilidade no número de tiles requisitados por arraste. Essa variabilidade ocorre devido àsdiferentes resoluções de tela consideradas e às variações no tamanho dos arrastes e mostrao quanto esses aspectos influenciam no padrão de requisições geradas para os servidores.

Uma maior variabilidade é encontrada também no número de tiles requisitadosna operação de zoom. Esse padrão está diretamente relacionado à distribuição de resolu-ções de tela, conforme descrito na Seção 4.3.1. Assim como no arraste, considerar essepadrão é importante para avaliar os padrões de requisições geradas para os servidores.

As Figuras 5.11(a) e 5.11(b) mostram as CDFs do número de tiles requisitadospor sessão de navegação. A média de tiles requisitados por sessão é maior no MUSe-

5.2 Simulações 84

Número de tiles

Fre

quên

cia

0 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

1e−

031e

−02

1e−

011.

0

(a) Distribuição do número de tiles requisitados poroperação de arraste no MUSe-GM – valoresacima de 21 foram omitidos por serem poucorepresentativos.

Número de tiles

Fre

quên

cia

3 4 6 8

1e−

041e

−02

1.0

(b) Distribuição do número de tiles requisitadospor operação de arraste no HELP.

Figura 5.9: Distribuição do número de tiles requisitados por ope-ração de arraste no MUSe-GM e no HELP.

Número de tiles

Fre

quên

cia

6 12 15 16 18 20 21 24 25 28 30 32 35 40 42 45 48 54

1e−

041e

−02

1.0

(a) Distribuição do número de tiles requisitados poroperação de zoom no MUSe-GM.

Número de tiles

Fre

quên

cia

9 12 16

1e−

021e

−01

1.0

(b) Distribuição do número de tiles requisitadospor operação de zoom no HELP.

Figura 5.10: Distribuição do número de tiles requisitados por ope-ração de zoom no MUSe-GM e no HELP.

GM. Isso ocorre devido aos padrões de navegação considerados nesse modelo e devido àdiferença nas distribuições do número de ações por sessão de navegação.

5.3 Estudo de caso: goGeo 85

0 500 1000 1500

0.0

0.2

0.4

0.6

0.8

1.0

Número de tiles

P(N

úmer

o de

tile

s≤

x)

(a) CDF do número de tiles requisitados por sessãode navegação no MUSe-GM.

0 200 400 600 800

0.0

0.2

0.4

0.6

0.8

1.0

Número de tiles

P(N

úmer

o de

tile

s≤

x)

(b) CDF do número de tiles requisitados por sessãode navegação no HELP.

Figura 5.11: CDFs do número de tiles requisitados por sessão denavegação no MUSe-GM e no HELP.

5.3 Estudo de caso: goGeo

A goGeo é uma plataforma de mapas Web de alto desempenho que ofereceuma API4 e uma infraestrutura escalável para o desenvolvimento de aplicações de mapaWeb e Serviços Baseados em Localização. A solução da goGeo foi projetada paraarmazenar e processar grandes volumes de dados espaciais de forma distribuída. Oliveira,S. [31] apresenta a arquitetura base da plataforma utilizada para fazer o processamentodistribuído. Antes do início deste trabalho, a avaliação de desempenho da plataforma erarealizada através de benchmarks de estresse [26, 32], como o MA. No entanto, surgiu anecessidade de se entender melhor o comportamento da solução com acessos promovidospor usuários reais. Entender esse comportamento é importante tanto para planejamentodos recursos computacionais quanto para definição do modelo de precificação para usoda plataforma.

Na Seção 5.4, mostramos a configuração do ambiente utilizado para os testese detalhamos a metodologia utilizada na sua condução e execução. Implementamos trêsgeradores de cargas a partir dos modelos descritos anteriormente e os utilizamos paraavaliar o desempenho do sistema. Os resultados são apresentados na Seção 5.5.

4https://api-docs.gogeo.io/map.

5.4 Configuração do ambiente e metodologia de testes 86

5.4 Configuração do ambiente e metodologia de testes

Os testes foram realizados em laboratório, com uma rede Gigabit Ethernet ecinco computadores com processador Intel i7 3.4 Ghz com 4 núcleos físicos e tecnologiaHyper-Threading, totalizando 8 núcleos, 16 GB de memória RAM e disco rígido SATA7200 rpm de 1 TB. A Figura 5.12 ilustra o ambiente de testes utilizado. Em quatrocomputadores foram instalados módulos do servidor de tiles, os quais são responsáveispelo armazenamento das bases de dados espaciais e pela renderização das imagens. Noquinto computador, foi instalado o servidor Web que funciona como um despachante parao sistema. Todas as requisições são enviadas para esse equipamento, o qual repassa paraos servidores de tile, aguarda a resposta e devolve ao cliente. Um sexto computador, coma mesma configuração dos anteriores, foi utilizado para gerar as cargas sintéticas.

Figura 5.12: Configuração do ambiente de testes.

Utilizamos uma base de dados de pontos nos EUA com 4 milhões de registrose com o tamanho de 660,26 MB. A cache dos servidores de tiles foi desativada paranão interferir nos resultados, fazendo com que todas as requisições exigissem uma novarenderização de tile. Assim como no trabalho de Guan et al. [21], cada teste foi executadopor um período de 10 minutos e com um tempo de 20 segundos para iniciar todos osusuários sintéticos.

O MUSe-GM e o HELP possuem um número de ações variáveis por sessão, oque poderia fazer com que os usuários sintéticos encerrassem suas sessões antes do teste

5.5 Resultados obtidos 87

ser concluído. Dessa forma, modificamos os modelos para que o número de ações fossesuficiente para criar sessões com duração maior ou igual a 10 minutos.

Os testes foram implementados utilizando o arcabouço de testes de desempenhoGatling5, o qual é capaz de emular características de navegadores Web. Por exemplo,ele, automaticamente, limita a quantidade de conexões a um mesmo servidor, utilizandoo mesmo limite dos navegadores Web (geralmente 6). Ele também possui uma cache

própria, simulando a de um navegador. Essa característica faz com que a carga dosusuários simulados se apresente mais próxima da real, visto que os usuários reais aquimodelados acessam os sistemas via navegador Web.

Em nossa implementação, todas as ações dos usuários são geradas antes doinício das sessões sintéticas. A criação dessas ações necessita da geração de diversosvalores aleatórios, os quais fazem uso intenso do processador. Criá-las sob demanda podeimpactar no desempenho e nos resultados do teste, pois o processo responsável por enviarrequisições pode sofrer atrasos.

5.5 Resultados obtidos

Analisamos os modelos em relação ao número de requisições por segundo,tempo de resposta das requisições e em relação ao número de conexões abertas. Cadaum dos modelos foi executado com um mínimo de 10 e um máximo específico suportadopelos servidores. O limite máximo suportado foi de 90 usuários para o MA, 100 usuáriospara o HELP e 130 usuários para o MUSe-GM.

A Figura 5.13(a) ilustra o número médio de requisições por segundo em funçãodo número de usuários. O MUSe-GM apresenta o menor número de requisições porsegundo, seguido pelo HELP e pelo MA. O MUSe-GM e o HELP apresentam valoresmais realistas, uma vez que implementam o conceito de intervalos entre ações. Consideraro padrão de requisições do MA pode levar a uma subestimação do número de usuáriosque um sistema pode atender.

Com 40 clientes, o MA possivelmente encontrou um gargalo do sistema, o queexplica o aumento no tempo médio de resposta, a partir dessa quantidade de clientes,mesmo que o número médio de requisições por segundo não sofra um aumento significa-tivo. Ao chegar a 90 usuários, o número de requisições por segundo do MA cai drastica-mente, possivelmente devido a um colapso que causa um aumento repentino no tempo deresposta. Uma vez que, os clientes esperam a resposta do sistema para enviar a requisiçãoseguinte, eles ficam parte do tempo bloqueados e, assim, o número de requisições dimi-nui. A Figura 5.14 mostra o momento do teste em que ocorreu o colapso. Observe que o

5Gatling (versão 2.1.7) - http://gatling.io/.


10

25

50

100

200

10 30 50 70 90 110 130Número de clientes

Req

uisi

ções

por

seg

undo

HELP

MA

MUSe−GM

(a) Comparação dos três modelos em relação aonúmero de médio de requisições por segundo.

50

100

200


Tem

po d

e re

spos

ta (

ms)

HELP

MA

MUSe−GM

(b) Comparação dos três modelos em relação aotempo médio de resposta as requisições.

Figura 5.13: Comparação dos três modelos em relação ao númeromédio de requisições por segundo e tempo médio deresposta das requisições.

tempo de resposta aumentou subitamente pouco antes dos 400 segundos de execução doteste.

200

1000

5000

2000

0

Tempo (s)

Tem

po m

édio

de

resp

osta

(m

s)

350 375 400 425 450

Figura 5.14: Tempo de médio de resposta do sistema quando exe-cutado com 90 clientes do MA. Ênfase ao momentodo colapso, com aumento súbito no valor medido.

O número médio de requisições por segundo do MA é maior independente da


quantidade de clientes. No entanto, com menos de 30 usuários, o tempo médio de respostado sistema é menor do que o do HELP e com menos de 20 é menor do que o do MUSe-GMtambém. A razão para esse comportamento é explicada pela concorrência das requisições.No MA, as requisições de um mesmo cliente acontecem de maneira sequencial, visto queapenas um tile é requisitado simultaneamente. Por outro lado, no HELP e no MUSe-GM,diversos tiles podem ser requisitados simultaneamente6, gerando rajadas de requisições e,consequentemente, o aumento no tempo de resposta.

Outro aspecto investigado foi o número de conexões abertas. Na Figura 5.15,é possível ver que o número de conexões do MA é menor do que dos outros modelos,mesmo que o número médio de requisições por segundo seja maior. Isso acontece, devidoao fato dos clientes enviarem suas requisições de forma sequencial e, consequentemente,utilizarem apenas uma conexão. O HELP utiliza mais conexões do que o MUSe-GM,devido à diferença média nos intervalos.

0

200

400


Núm

ero

de c

onex

ões

HELP

MA

MUSe−GM

Figura 5.15: Comparação entre as médias de conexões por se-gundo dos três modelos.

A influência da diferença entre as distribuições dos intervalos pode ser vistade maneira mais clara na Figura 5.16(a), a qual apresenta as CDFs do número deações do MUSe-GM e do HELP em sessões 10 minutos. O HELP gera, em média, umnúmero maior de ações e, consequentemente, requisita mais tiles, em média, quando sãocomparadas sessões com a mesma duração.

6Em nossa implementação, cada cliente pode requisitar até 6 tiles simultaneamente, devido a emulaçãoda limitação de conexões imposta pelos navegadores Web.

5.6 Conclusão 90

0 50 100 150 200 250

0.0

0.2

0.4

0.6

0.8

1.0

Número de ações

P(N

úmer

o de

açõ

es≤

x)

MUSe−GMHELP

(a) Comparação entre as CDFs do número de açõesem sessões de 10 minutos do HELP e do MUSe-GM.

0 500 1000 2000

0.0

0.2

0.4

0.6

0.8

1.0

Número de tiles

P(N

úmer

o de

tile

s≤

x)

MUSe−GMHELP

(b) Comparação entre as CDFs do número de tilesrequisitados em sessões de 10 minutos do HELPe do MUSe-GM.

Figura 5.16: Comparação entre o número de ações e de tiles re-quisitados no HELP e o MUSe-GM em sessões de 10minutos.

5.6 Conclusão

Neste capítulo, fornecemos uma avaliação do MUSe-GM através de simulaçõese de testes na plataforma de mapas Web goGeo. Por meio das simulações, avaliamos aadequação dos resultados do MUSe-GM em comparação aos da caracterização, apresen-tada no capítulo anterior, e os comparamos também em relação a outros dois modelos daliteratura. Percebemos que há diferenças importantes entre o MUSe-GM e o HELP comrelação ao número de ações por sessão de navegação, tempo de duração das sessões, nú-mero de tiles requisitados por operação e por sessão, distribuição de frequência de acessoaos níveis de zoom e distribuição do tamanho dos arrastes.

Dos testes na goGeo, verificamos diferenças significativas no comportamentodo sistema quando submetido a uma carga de trabalho baseada no MUSe-GM e quandosubmetido a cargas de trabalho baseadas no MA. Constatamos também distinções emrelação ao modelo HELP, tendo sua carga se mostrado mais intensa que a do MUSe-GM. Observamos que o principal motivo desse comportamento é a diferença entre asdistribuições de intervalo entre ações.

No próximo capítulo, apresentaremos as considerações finais sobre o trabalho ediscutimos perspectivas para trabalhos futuros. Além disso, listamos os produtos geradosa partir desta pesquisa.

CAPÍTULO 6Conclusão e Trabalhos Futuros

Os sistemas de mapa Web se tornaram uma importante ferramenta nos dias atuais,tendo um número expressivo de usuários. No entanto, há uma carência de modelos estatís-ticos que descrevam o comportamento desses usuários. A ausência de modelos adequadostorna difícil a realização de avaliações de desempenho acuradas. Como consequência, vá-rias atividades são afetadas, como o projeto de novos sistemas, a evolução de sistemas emoperação e a estimativa de recursos computacionais para atendimento da demanda.

Nesta dissertação, propusemos uma metologia de coleta e análise de dadospara a modelagem do comportamento de usuários de SIGs Web e desenvolvimento deum gerador de carga de trabalho. Apresentamos também uma proposta de um modelogenérico, chamado de MUSe-GM, que contempla as características mais importantespara descrever esse comportamento. Abordamos nesse modelo quatro operações comunsnos sistemas de mapa Web de amplo uso, sendo elas o arraste, o zoom, a pesquisa e aroteirização.

Seguindo a metologia descrita, desenvolvemos um trabalho de coleta e análisede dados, culminando com a criação de uma caracterização detalhada do comportamentodos usuários e na construção de uma instância do MUSe-GM. A instância do modelofoi construída a partir dos resultados da caracterização e contempla todos os passos paraa criação de uma sessão de navegação, sendo eles: (1) seleção da resolução da tela, (2)escolha do ponto inicial de navegação e (3) o conjunto de operações realizadas.

Avaliamos o MUSe-GM a partir de simulações, verificando sua adequaçãoà características dos usuários não utilizadas diretamente na construção da instância.Comparamos também o comportamento do modelo em relação a outros dois: (1) ummodelo de requisições aleatórias (MA), geralmente utilizado em testes de estresse, e (2) omodelo HELP, proposto por Guan et al. [21]. Constatamos diferenças significativas entreeles nas operações de arraste e zoom, na quantidade de operações por sessão, na duraçãodas sessões, além de diferenças no padrão de requisição aos tiles.

Por fim, executamos testes de desempenho na plataforma de mapas Web goGeo ecomparamos o comportamento do sistema quando estimulado com cargas implementadasa partir de cada um dos modelos. Verificamos diferenças importantes nas características

6.1 Produção científica 92

das cargas e na reação do sistema. O MA gera um número significativamente maiorde requisições por segundo, porém as requisições de um mesmo cliente acontecem demaneira síncrona. O MUSe-GM e o HELP geram um menor número de requisições porsegundo, no entanto, um mesmo cliente pode enviar requisições em paralelo. Esse padrãode requisições, juntamente com os intervalos aleatórios, pode criar rajadas de requisições,as quais não são geradas pelo MA. O MUSe-GM, em geral, possui uma carga menosintensa que a do HELP, devido à diferença nos intervalos entre ações.

O conjunto de operações existentes nos SIGs Web é amplo, contudo, as operaçõesaqui investigadas estão presentes em grande parte dos sistemas de mapa Web. Além disso,é possível adicionar novas operações ao MUSe-GM sem afetar as operações consideradas,uma vez que seus componentes são independentes. O MESP, proposto na instância domodelo, também foi desenvolvido de maneira a possibilitar sua expansão e permiteadicionar novas operações como estados, sem prejudicar as demais. Por fim, destacamosque o MUSe-GM gera uma carga, teoricamente, mais próxima da realidade do que asoutras abordagens existentes e, assim, pode permitir avaliações de desempenho maisacuradas.

6.1 Produção científica

Além do texto desta dissertação, a pesquisa desenvolvida neste trabalho, resultouno desenvolvimento dos seguintes produtos:

• Artigo: Descriptive Modeling of the Web Mapping Systems Users’ Behavior [7].Evento: XV Brazilian Symposium on Geoinformatics (GeoInfo 2014) - Campos doJordão, São Paulo, Brasil. Novembro de 2014.Modalidade: Evento internacional. Apresentação de artigo completo.Situação: Publicado e apresentado.• Artigo: Understanding and Modeling the Behavior of Web Map Users. [6]

Periódico: JIDM - Journal of Information and Data Management.Ano: 2015.Situação: Publicado.• Software: Simulador do MUSe-GM.

Informações: Gera o conjunto de ações do usuário em uma sessão de navegação.Linguagem: R [35].Disponível em: http://vgbresearch.appspot.com.• Software: Interpretador do MUSe-GM.

Informações: Interpreta a saída do Simulador do MUSe-GM e identifica os tiles

necessários para atender cada ação dos usuários sintéticos.

6.2 Perspectivas para trabalhos futuros 93

Linguagem: Scala.Disponível em: http://vgbresearch.appspot.com.• Software: Gerador de cargas do MUSe-GM.

Informações: Gera cargas de trabalho, baseadas no MUSe-GM, para avaliação dedesempenho de servidores de tiles.Linguagem: Scala.Arcabouço utilizado: Gatling (versão 2.1.7).Disponível em: http://vgbresearch.appspot.com.

6.2 Perspectivas para trabalhos futuros

Ao longo da pesquisa, identificamos algumas oportunidades de investigação quenão foram exploradas neste trabalho. A seguir, apresentamos uma breve discussão sobreessas oportunidades para trabalhos futuros.

• Investigação detalhada das operações de pesquisa e rota e de outras operações deSIGs Web, como clique em itens do mapa, geocodificação reversa, inserção dedados, cruzamento de camadas, medição de distâncias, restrição de bounding box,dentre outras.• Estudo do comportamento dos usuários de aplicativos de mapas em dispositi-

vos móveis. Esses aparelhos diferem dos microcomputadores em vários aspectos,como: tamanhos e resoluções de tela, métodos de interação com a interface e velo-cidade da conexão com a Internet. Essas diferenças podem resultar em padrões decomportamento distintos dos observados neste trabalho e é importante investigá-lostambém, uma vez que os dispositivos móveis são cada vez mais populares.• Os trabalhos existentes na literatura sobre algoritmos de caching e prefetching de

tiles avaliam suas propostas com cargas de trabalho inadequadas [34, 46]. O MUSe-GM pode ser utilizado para avaliar essas propostas e oferecer insumos para evoluiros algoritmos.• O MUSe-GM possui um modelo de estados (o MESP) que permite inferir a próxima

ação do usuário, baseado no estado atual. Esse modelo pode ser utilizado paraprever as ações dos usuários e, consequentemente, pode ser empregado comoestratégia de prefetching de tiles.

Referências Bibliográficas

[1] AJI, A.; WANG, F.; VO, H.; LEE, R.; LIU, Q.; ZHANG, X.; SALTZ, J. Hadoop

gis: a high performance spatial data warehousing system over mapreduce.

Proceedings of the VLDB Endowment, 2013.

[2] BARFORD, P.; CROVELLA, M. Generating representative web workloads for

network and server performance evaluation. In: ACM SIGMETRICS Performance

Evaluation Review, 1998.

[3] BEAUJARDIERE, J. D. L. OpenGIS R© Web Map Server Implementation Specifica-

tion. Open Geospatial Consortium Inc. http://www.opengeospatial.org/sta

ndards/wms, 2006. [Versão 1.3; Último acesso: 29-Agosto-2014].

[4] BEE, M. Statistical analysis of the lognormal-pareto distribution using probabi-

lity weighted moments and maximum likelihood. Technical report, Department of

Economics, University of Trento, Italy, 2012.

[5] BENCHMARK, H. Human benchmark - reaction time test. http://www.humanben

chmark.com/tests/reactiontime, 2015. [Último acesso: 08-Julho-2015].

[6] BRAGA, V. G.; DE OLIVEIRA, W. B.; RODRIGUES, V. J. S.; CARDOSO, K. V. Unders-

tanding and modeling the behavior of web map users. Journal of Information and

Data Management, 2015.

[7] BRAGA, V. G.; OLIVEIRA, W.; SACRAMENTO, V.; CARDOSO, K. V. Descriptive Mo-

deling of the Web Mapping Systems Users’ Behavior. In: XV Brazilian Symposium

on Geoinformatics (GeoInfo 2014), 2014.

[8] CARTODB. CartoDB. http://www.cartodb.com, 2014. [Último acesso: 16-Julho-

2014].

[9] CENTRO DE OPERAÇÕES DO RIO DE JANEIRO. Centro de operações do rio de

janeiro. http://www.centrodeoperacoes.rio.gov.br/, 2014. [Último acesso:

08-Outubro-2014].


[10] CIFERRI, R. R. Um benchmark voltado a análise de desempenho de sistemas de

informações geográficas. Tese de Mestrado, Universidade Estadual de Campinas

- Unicamp, 1995.

[11] FEITELSON, D. G. Workload Modeling for Computer Systems Performance

Evaluation. Cambridge University Press, 2014.

[12] FISHER, D. How We Watch the City: Popularity and Online Maps. In: Workshop

on Imaging the City, ACM CHI 2007 Conference, 2007.

[13] GANAPATHI, A.; CHEN, Y.; FOX, A.; KATZ, R.; PATTERSON, D. Statistics-driven

workload modeling for the cloud. In: Data Engineering Workshops (ICDEW), 2010

IEEE 26th International Conference on, 2010.

[14] GARCÍA, R.; DE CASTRO, J. P.; VERDÚ, E.; VERDÚ, M. J.; REGUERAS, L. M. Web

map tile services for spatial data infrastructures: Management and optimiza-

tion. In: Cartography - A Tool for Spatial Analysis. InTech, 2012.

[15] GARCÍA, R.; DE CASTRO, J. P.; VERDÚ, M. J.; VERDÚ, E.; REGUERAS, L. M.;

LÓPEZ, P. A Descriptive Model for Predicting Popular Areas in a Web Map. In:

Proceedings of the 10th WSEAS - International Conference on Artificial Intelligence,

Knowledge Engineering and Data Bases, 2011.

[16] GOGEO. goGeo - High Performance Maps Platform. https://www.gogeo.io,

2014. [Último acesso: 16-Julho-2014].

[17] GONÇALVES, G.; DRAGO, I.; DA SILVA, A. P. C.; DE ALMEIDA, J. M.; VIEIRA, A. B.

Caracterizaçao e modelagem da carga de trabalho do dropbox. Anais do 32o

Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC,

2014.

[18] GOOGLE. Joint task force - homeland defense. http://services.google.co

m/fh/files/misc/jtfhd_case_study_google_earth_enterprise.pdf, 2014.

[Último acesso: 08-Outubro-2014].

[19] GOOGLE. Patrolling with google maps. http://services.google.com/fh/fi

les/misc/case-study-stadtpolizei-zuerich-en.pdf, 2014. [Último acesso:

08-Outubro-2014].

[20] GOOGLE. Google Maps. http://www.maps.google.com, 2015. [Último acesso:

16-Julho-2015].

[21] GUAN, X.; CHENG, B.; SONG, A.; WU, H. Modeling Users’ Behavior for Testing

the Performance of a Web Map Tile Service. Transactions in GIS, 2014.


[22] INFRAESTRUTURA NACIONAL DE DADOS ESPACIAIS - INDE. Visualizador da INDE.

http://visualizador.inde.gov.br/, 2014. [Último acesso: 16-Julho-2014].

[23] KANG, Y.-K.; KIM, K.-C.; KIM, Y.-S. Probability-based tile pre-fetching and

cache replacement algorithms for web geographical information systems. In:

Proceedings of the 5th East European Conference on Advances in Databases and

Information Systems, 2001.

[24] KEFALOUKOS, P. K.; VAZ SALLES, M.; ZACHARIASEN, M. Tileheat: A framework

for tile selection. In: Proceedings of the 20th International Conference on Advances

in Geographic Information Systems, 2012.

[25] LE BOUDEC, J.-Y. Performance Evaluation of Computer and Communication

Systems. EPFL Press, Lausanne, Switzerland, 2010.

[26] MAPLARGE. Map server performance. http://maplarge.com/mapserverper

formance, 2014. [Último acesso: 16-Julho-2014].

[27] MAPS, G. Google Maps For Work. http://www.google.com/intx/pt-BR/ente

rprise/mapsearth/, 2014. [Último acesso: 16-Julho-2014].

[28] MAPTILER. Tiles à la Google Maps: Coordinates, Tile Bounds and Projec-

tion. http://www.maptiler.org/google-maps-coordinates-tile-bounds-p

rojection, 2015. [Último acesso: 1-Outubro-2015].

[29] MASÓ, J.; POMAKIS, K.; JULIÀ, N. OpenGIS Web Map Tile Service Implementa-

tion Standard. http://www.opengeospatial.org/standards/wmts, 2010.

[30] MICROSOFT. Bing Mapas. http://www.bing.com/maps/, 2014. [Último acesso:

16-Julho-2014].

[31] OLIVEIRA, S. S. T. DistJoin: Plataforma de Processamento Distribuído de

Operações de Junção Espacial com Bases de Dados Dinâmicas. Tese de

Mestrado, Universidade Federal de Goiás, 2013.

[32] OSGEO WIKI. Benchmarking 2011. http://wiki.osgeo.org/wiki/Benchmark

ing_2011, 2011. [Último acesso: 31-Julho-2014].

[33] PAXSON, V.; FLOYD, S. Wide Area Traffic: the Failure of Poisson Modeling.

IEEE/ACM Transactions on Networking (ToN), 1995.

[34] QUINN, S.; GAHEGAN, M. A predictive model for frequently viewed tiles in a web

map. Transactions in GIS.


[35] R DEVELOPMENT CORE TEAM. R: A Language and Environment for Statistical

Computing. R Foundation for Statistical Computing, Vienna, Austria, 2008. ISBN

3-900051-07-0.

[36] RAY, S.; SIMION, B.; BROWN, A. D. Jackpine: A benchmark to evaluate spatial

database performance. In: Data Engineering (ICDE), 2011 IEEE 27th International

Conference on, 2011.

[37] ROMOSER, B.; FARES, R.; JANOVICS, P.; RUAN, X.; QIN, X.; ZONG, Z. Global

workload characterization of a large scale satellite image distribution system.

In: Performance Computing and Communications Conference (IPCCC), 2012 IEEE

31st International, 2012.

[38] ROSS, S. M. Simulation. Academic Press, 2012.

[39] SAMPLE, J.; IOUP, E. Tile-Based Geospatial Information Systems: Principles and

Practices. Springer, 2010.

[40] SCARROTT, C. J.; HU, Y. evmix: Extreme value mixture modelling, threshold

estimation and boundary corrected kernel density estimation, 2015. Available

on CRAN.

[41] SIMION, B.; RAY, S.; BROWN, A. D. Surveying the landscape: An in-depth

analysis of spatial database workloads. In: Proceedings of the 20th International

Conference on Advances in Geographic Information Systems, 2012.

[42] SONG, B.; ERNEMANN, C.; YAHYAPOUR, R. Parallel computer workload modeling

with markov chains. In: Job Scheduling Strategies for Parallel Processing, 2005.

[43] STATS, S. G. Top 10 desktop screen resolutions from july to aug 2015 |

statcounter global stats. http://gs.statcounter.com/#desktop-resolutio

n-ww-monthly-201507-201508-bar, 2015. [Último acesso: 28-Agosto-2015].

[44] STATS, S. G. Top 5 desktop browsers from july to aug 2015 | statcounter global

stats. http://gs.statcounter.com/#desktop-browser-ww-monthly-201507

-201508, 2015. [Último acesso: 28-Agosto-2015].

[45] TRIVEDI, K. S. Probability and Statistics with Reliability, Queueing and Compu-

ter Science Applications. Wiley-Interscience, 2001.

[46] VIEIRA, M.; BAKALOV, P.; HOEL, E.; TSOTRAS, V. A spatial caching framework for

map operations in geographical information systems. In: Mobile Data Manage-

ment (MDM), 2012 IEEE 13th International Conference on, 2012.


[47] YESILMURAT, S.; ISLER, V. Retrospective adaptive prefetching for interactive

web gis applications. GeoInformatica, 2012.

[48] ZHANG, Q.; CHERKASOVA, L.; MATHEWS, G.; GREENE, W.; SMIRNI, E. R-capriccio:

A capacity planning and anomaly detection tool for enterprise services with live

workloads. In: Proceedings of the ACM/IFIP/USENIX 2007 International Conference

on Middleware, 2007.

APÊNDICE AMetodologia de coleta e análise dos dados

Neste apêndice, apresentamos as técnicas utilizadas para coletar e analisar osdados utilizados nesta pesquisa. Mostramos como foi possível coletar dados de acessoao Google Maps, utilizando uma extensão desenvolvida para o Google Chrome. Descre-vemos também, como coletamos as informações de tamanho, em bytes, dos tiles e asutilizamos para estimar o volume de dados transferidos por sessão de navegação e poroperação de arraste e zoom no mapa.

A seguir, na Seção A.1, discorremos sobre o Google Maps e uma característicadesse sistema que possibilitou a coleta de dados através da extensão desenvolvida parao Google Chrome. Na Seção A.2, apresentamos detalhes da implementação da extensãoe da condução da coleta de dados. Mostramos também, os procedimentos para coletardados sobre o tamanho dos tiles do Google Maps. Por fim, na Seção A.3, descrevemos astécnicas utilizadas para analisar e extrair informações dos dados coletados.

A.1 Google Maps

O Google Maps é uma aplicação de mapas popular desenvolvida pelo Googlee possui versões para Web e dispositivos móveis. Este trabalho utiliza apenas a versãoWeb, pois apenas nela foi possível coletar os dados. Atualmente, o Google Maps permitevisualizar imagens de satélite, informações de trânsito, do transporte público, de terreno,do arruamento e de outros pontos de interesse. Além disso, permite a definição de rotas ea visualização das ruas e de outros locais do ponto de vista de um pedestre, com imagensem 360 graus. A aplicação é desenvolvida em JavaScript, CSS e HTML e, por isso, nãoexige a instalação de nenhum software especial para renderizar os mapas.

A URL do Google Maps é atualizada ao fim de cada ação realizada pelo usuárioe contém informações que permitem a identificação das ações do usuário, em uma sessãode navegação, a partir do conjunto de URLs dessa sessão. Como exemplo, observe aFigura A.1. Ao se realizar uma operação de zoom in (aproximação) no mapa, a URL foiautomaticamente atualizada – o nível do zoom passou de 15 para 16 – refletindo essaação. Quando o mapa é visualizado com imagens de satélite, as URLs não contêm o

Apêndice A 100

nível de zoom. Dessa forma, utilizamos apenas as sessões de navegação que utilizaramexclusivamente o mapa de arruamento para fazer nossas análises. A seguir, apresentamosos principais padrões encontrados nas URLs que permitiram extrair informações docomportamento dos usuários.

(a) Nível de zoom 15. (b) Nível de zoom 16.

Figura A.1: Inicialmente, o mapa estava no nível de zoom 15 (a)e após uma operação de zoom in passou para o nível16 (b).

As duas informações mais básicas contidas na URL são as coordenadas doponto central e o nível de zoom do mapa visualizado. Abaixo segue um exemplo deuma URL com essas informações destacadas em negrito. Elas sempre aparecem após umcaractere arroba (@). O primeiro número antes da vírgula representa a latitude, o segundoa longitude e o terceiro, com a letra “z” ao final, é o nível de zoom, que varia de 0 a 21.

• https://www.google.com/maps/@37.3075744,-95.4133961,4z

Quando o usuário realiza uma pesquisa, a URL é alterada para incluir as infor-mações dessa pesquisa. A nova URL passa a incluir a string “/search/” seguida da string

inserida na caixa de pesquisa. Dessa forma, se o usuário pesquisar por shopping, a URLficará com o seguinte padrão:

• https://www.google.com.br/maps/search/shopping/@-15.9471832,-49.5790...

Quando o usuário cria uma rota entre dois ou mais pontos, a nova URL passaa incluir a string “/dir/” seguida das strings dos pontos da rota, sendo que cada ponto éseparado por uma barra “/”. Dessa forma, se o usuário criar uma rota entre a Wall Street

e o Museu de Arte Metropolitano de Nova York, a URL ficará com o padrão a seguir.Primeiramente vem o “/dir/”, que indica que é uma rota, depois a string indicando oprimeiro ponto da rota, a Wall Street, e em seguida a string indicando o segundo ponto darota, o Museu de Arte Metropolitano de Nova York.

Apêndice A 101

• .../dir/Wall+St,+New+York,+NY/The+Metropolitan+Mus eum+of+Art/...

Se um ponto específico do mapa for destacado, a URL passa a conter a string

“/place/” seguida da string relacionada ao ponto selecionado. Como exemplo, observe aURL abaixo, que é formada quando a Wall Street está em destaque no mapa. Esse padrãoacontece quando o usuário clica em um local específico ou quando uma pesquisa retornaum único resultado.

• .../place/Wall+St,+New+York,+NY/...

Além das informações citadas é possível saber se o usuário está visualizandoo mapa de trânsito, de terreno, fotos de monumentos e locais, além de informaçõessobre o uso do Street View. Todas essas informações podem ser facilmente extraídas comexpressões regulares, sendo possível detectar as ações realizadas pelos usuários. A seguir,apresentamos as metodologias de coleta e de análise dos dados deste trabalho.

A.2 Metodologia de coleta

Para desenvolver a caracterização e a modelagem do comportamento dos usuá-rios, apresentada no Capítulo 4, coletamos, de maneira anônima, informações de acessoao Google Maps. A partir dos dados coletados, foi possível identificar os tiles carrega-dos na tela dos usuários. Essa informação, foi utilizada na investigação, descrita na Seção4.3.2, do volume de dados transferidos por sessão e por operação de arraste e zoom.

A seguir, descrevemos as técnicas desenvolvidas para coletar os dados utilizadosnesta pesquisa. Na Seção A.2.1, abordamos a coleta das informações utilizadas parainvestigar o comportamento dos usuários e na Seção A.2.2, discutimos sobre a coletado tamanho dos tiles.

A.2.1 Comportamento dos clientes

Desenvolvemos uma extensão do Google Chrome para coletar, de maneiraanônima, as informações utilizadas na caracterização e modelagem do comportamentodos usuários de aplicações de mapa Web. A Figura A.2 ilustra o diagrama de sequênciascom fluxo de coleta da extensão. Ela coleta os dados durante uma sessão de navegação noGoogle Maps, que tem início quando o usuário acessa a página do Google Maps e terminaquando ele encerra sua atividade – fechando a aba/janela ou acessando outro endereço namesma aba.

Durante uma sessão de navegação no Google Maps, o usuário realiza váriasações a fim de encontrar um local de seu interesse. A cada ação, o Google Maps atualiza a

Apêndice A 102

URL. Um evento do Google Chrome informa à extensão sobre essa alteração e a extensãoarmazena a URL e outros dados coletados no banco de dados do navegador. Quando ousuário encerra a sessão de navegação, a extensão agrupa todos os dados coletados e osenvia para um servidor.

Figura A.2: Diagrama de sequência do fluxo de coleta da exten-são.

A Figura A.3 mostra o diagrama Entidade-Relacionamento (ER) dos dadoscoletados. A extensão coleta as URLs de acesso ao Google Maps juntamente com aestampa de tempo em que a URL foi gerada. Associada à URL também está a resoluçãoda página, que é coletada a cada ação do usuário, uma vez que, a página pode serredimensionada durante o acesso. Como o mapa ocupa toda a página, a resoluçãodela equivale à resolução do Bounding Box. Além disso, a extensão também coletainformações sobre as requisições realizadas pela página do Google Maps. Cada requisiçãocontém informações sobre o tamanho da resposta em bytes, um tipo binário (boolean)indicando se o dado estava em cache e a estampa de tempo de quando a requisiçãofoi completada. A extensão foi publicada na Chrome Web Store e os detalhes sobre a

Apêndice A 103

divulgação, quantidade de usuários e outras informações quantitativas dos dados coletadosforam apresentadas na Seção 4.1.

Figura A.3: Diagrama ER dos dados coletados pela extensão.

A.2.2 Tamanho dos tiles

Por meio do Algoritmo A.2 foi possível encontrar, a partir das URLs, quaistiles foram carregados na tela dos usuários. Criamos então uma lista com todos os tiles

carregados e coletamos o tamanho, em bytes, de cada tile, enviando requisições HEADpara o servidor de tiles do Google e coletando o valor do cabeçalho Content-Length doprotocolo HTTP, enviado como resposta. Um exemplo do formato da URL do servidor detiles acessado é mostrado a seguir.

• http://mt1.google.com/vt/z=16&x=19307&y=24642, onde z é o nível de zoom e xe y representam as coordenadas (x, y) na matriz de tiles do nível de zoom z.

A.3 Metodologia de análise dos dados

O tamanho das respostas às requisições foi coletado diretamente pela extensão.Contudo, as outras informações necessárias para a modelagem, listadas na Tabela 3.1,foram extraídas de maneira indireta. A seguir apresentamos as técnicas utilizadas paraextrair cada uma das informações a partir dos dados coletados pela extensão.

Apêndice A 104

A.3.1 Duração da sessão de navegação e intervalo entre ações

A duração da sessão de navegação foi obtida calculando a diferença entre ostempos de início (S0) e fim da sessão (SF ). De forma semelhante, o intervalo entre duasações realizadas em sequência foi calculado a partir da diferença entre suas estampasde tempo. Na Figura A.4, ilustramos os instantes de coleta das estampas, bem como aduração da sessão e os intervalos.

Figura A.4: Coleta das estampas de tempo para cálculo do inter-valo entre ações e para o cálculo da duração das ses-sões de navegação.

A.3.2 Traço das ações

Para identificar as ações realizadas pelos usuários, foi necessário analisar asURLs das sessões de navegação duas a duas, em sequência. Para isso, desenvolvemoso Algoritmo A.1, o qual verifica a diferença entre duas URLs sequenciais e identifica qualoperação foi realizada. Para ilustrar o processo realizado pelo algoritmo, apresentaremosalguns exemplos a seguir.

Exemplo 1: sejam as URLs 1 e 2 geradas a partir de dois acessos sequenciais deum mesmo usuário. Houve uma alteração no nível do zoom, passando de 4z para 5z. Essamodificação é verificada na linha 8 do algoritmo e a operação é identificada como umaoperação de zoom.

1. www.google.com/maps/@37.0625,-95.677068,4z2. www.google.com/maps/@37.0625,-95.677068,5z

Há casos em que acontecem modificações em diferentes partes da URL aomesmo tempo. Contudo, as diferentes alterações acontecem como resultado de uma únicaação. A ordem das estruturas condicionais do algoritmo A.1 é determinante para a corretaidentificação da operação nesses casos, como mostrado no exemplo a seguir.

Exemplo 2: sejam as URLs 3 e 4 geradas a partir de dois acessos sequenciais deum mesmo usuário. Como está destacado, a URL sofreu alterações tanto no nível de zoom,quanto na coordenada central. Isso ocorre porque quando a operação de zoom é realizada

Apêndice A 105

através de eventos do mouse, o ponto central do mapa é alterado de acordo com a posiçãodo ponteiro do mouse. Essa alteração deve, então, ser identificada como uma operação dezoom e, por esse motivo, a avaliação da mudança no zoom (linha 7) precede a avaliaçãoda mudança das coordenadas do ponto central (linha 9). Durante operações de pesquisae roteirização a coordenada central e o nível de zoom também podem ser alterados. Poresse motivo, o Algoritmo A.1 avalia as mudanças na rota e na pesquisa primeiro.

3. www.google.com/maps/@37.0625,-95.677068,4z4. www.google.com/maps/@38.2971386,-65.7063659,5z

Algoritmo A.1: Identificação da operação realizada pelo usuário.Entrada: URLi e URLi+1Saída: OP - A operação realizada pelo usuáriose URLi = NULL então1

OP← INICIO2

senão se haAlteracoesNaPesquisa(URLi,URLi+1) então3

OP← PESQUISA4

senão se haAlteracoesNaRota(URLi,URLi+1) então5

OP← ROT EIRIZACAO6

senão se haAlteracoesNoZoom(URLi,URLi+1) então7

OP← ZOOM8

senão se haAlteracoesNasCoordenadas(URLi,URLi+1) então9

OP← ARRAST E10

senão11

OP← OUT RA12

fim13

A.3.3 Operação de arraste

Utilizamos as informações das coordenadas do ponto central do mapa e do nívelde zoom, presentes nas URLs, para calcular o tamanho dos arrastes. A cada operação dearraste identificada, a posição do pixel da coordenada central da URLi (xi, yi) é calculadae subtraída do valor da posição do pixel da coordenada central da URLi+1 (xi+1, yi+1),obtendo assim o tamanho (x, y) do movimento do mapa em pixels. A Figura A.5 ilustracomo esse cálculo é realizado. Na URLi, o pixel central era o (1000, 1000), passando para(900, 1070) na URLi+1. Nesse caso, o mapa se movimentou 100px no eixo X e -70pxno eixo Y. O sinal é usado para detectar o sentido do movimento. No eixo X, um valornegativo representa um movimento para a esquerda e um valor positivo, um movimentopara a direita. No eixo Y, quando negativo, o movimento é para cima e quando positivo,para baixo.

Apêndice A 106

Figura A.5: Exemplo do cálculo do tamanho de um arraste. Asimagens de fundo são do Google Maps.

É possível identificar a lista de tiles dispostos na tela por URL. Dessa forma, ostiles necessários para preencher a tela em uma operação de arraste podem ser encontradosatravés dos seguintes passos:

1. Identificar o conjunto de tiles relacionados a URLi (CT1);2. Identificar o conjunto de tiles relacionados a URLi+1 (CTi+1);3. Subtrair o CTi+1 de CTi.

O conjunto de tiles carregados é equivalente ao resultado da subtração dos

Apêndice A 107

conjuntos.

A.3.4 Operação de zoom

O tamanho dos saltos na operação de zoom foi calculado através da subtraçãodo nível de zoom de dois acessos em sequência. Valores positivos de salto representamuma operação de zoom in e valores negativos, uma operação de zoom out. A estratégiapara verificar a alteração do ponto central do mapa foi a mesma utilizada para identificaro tamanho dos arrastes. Utilizamos o tamanho do movimento relativo ao menor nívelde zoom da operação, seja ele o nível inicial ou o final, a fim de manter os valores dostamanhos padronizados. A lista de tiles carregados foi obtida aplicando o procedimentoapresentado na Seção A.3.6 no nível final da operação de zoom.

A.3.5 Operações de pesquisa e roteirização

A posição do mapa anterior e posteriormente às operações de pes-quisa e roteirização são extraídas das coordenadas geográficas do ponto cen-tral e do nível de zoom das URLs relacionadas a cada operação. O textoda pesquisa também é encontrado nas URLs, utilizando a expressão regular((&|\?)q=[^&]+|/search/[^/]+/|/search/.*). Para extrair os pontos das rotas, pode-seutilizar a expressão (/dir/.*/)|((&|\?)saddr=.+|daddr=.+|dirflg.+).

A.3.6 Regiões populares – lista de tiles

Implementamos o algoritmo A.2 para identificar os tiles visualizados na telaatravés das URLs. Utilizando a informação das coordenadas centrais e do nível de zoom,é possível encontrar, através da Equação 2-5, a coordenada do pixel central. Uma vezque temos o tamanho da página em pixels, usamos essa informação para encontrar ascoordenadas do Bounding Box e os tiles dispostos nessa área.

O Algoritmo A.2 recebe como entrada a coordenada geográfica central, o nívelde zoom, a largura e a altura da página em pixels. Inicialmente, o algoritmo utiliza acoordenada geográfica central e o nível de zoom para calcular a coordenada do pixel

central (linha 1). A seguir, o algoritmo utiliza o PIXEL_CENT RAL e a resolução dapágina para calcular as coordenadas do Bounding Box (linhas 2-11). Se a largura ou alturaforem números pares, a coordenada do pixel central é [(largura / 2)+1], para o eixo X,e [(altura / 2)+1], para o eixo Y.

Após a identificação das coordenadas do BB, o Algoritmo A.2 itera na matriz depixels a partir das posições extremas EsquerdaX e TopoY , incrementando as variáveis

Apêndice A 108

Algoritmo A.2: Identificação do conjunto de tiles dispostos na tela.Entrada: LAT – latitude; LON – longitude; ZOOM – nível de zoom; LARGURA –

largura da página; ALTURA – altura da página.Saída: CT - Conjunto de tiles dispostos na tela.PIXEL_CENT RAL← coordenadaDePixel(LAT,LON,ZOOM)1

// BB é o Bounding BoxBB.EsquerdaX ← PIXEL_CENT RAL.X + bLARGURA/2c2

BB.TopoY ← PIXEL_CENT RAL.Y + bALTURA/2c3

BB.DireitaX ← PIXEL_CENT RAL.X + bLARGURA/2c4

BB.In f eriorY ← PIXEL_CENT RAL.Y + bALTURA/2c5

se ePar(LARGURA) então6

BB.DireitaX ← PIXEL_CENT RAL+ bLARGURA/2c+17

fim8

se ePar(ALTURA) então9

BB.In f eriorY ← PIXEL_CENT RAL+ bALTURA/2c+110

fim11

x← BB.EsquerdaX12

enquanto x <= BB.DireitaX ou bx/T Sc= bBB.DireitaX/T Sc faça13

y← BB.TopoY14

enquanto y <= BB.In f eriorY ou by/T Sc= bBB.In f eriorX/T Sc faça15

T ILE.X ← bx/T Sc16

T ILE.Y ← by/T Sc17

T ILE.Z← ZOOM18

se T ILE.X < 0 ou T ILE.X > 2ZOOM−1 então19

T ILE.X ← restoDaDivisao(T ILE.X , 2ZOOM)20

se T ILE.X < 0 então21

T ILE.X ← T ILE.X +2ZOOM22

fim23

fim24

se T ILE.Y < 0 ou T ILE.Y > 2ZOOM−1 então25

T ILE.Y ← restoDaDivisao(T ILE.Y, 2ZOOM)26

se T ILE.Y < 0 então27

T ILE.Y ← T ILE.Y +2ZOOM28

fim29

fim30

CT.adicionaTile(T ILE)31

y← y+T S32

fim33

x← x+T S34

fim35

x e y com um valor equivalente ao tamanho dos tiles (T S) (linhas 12-35)1. A iteração

1A resolução dos tiles no caso do Google Maps é 256x256 e por isso o valor do tamanho dos tiles (T S)utilizado no Algoritmo A.2 foi 256.

Apêndice A 109

acontece enquanto uma de duas condições forem satisfeitas. A primeira condição verificase os valores de x e y são menores ou iguais às posições extremas a direita (DireitaX)e abaixo (In f eriorY ), respectivamente. A segunda analisa se a coordenada de tile davariável incrementada no laço, x ou y, é igual a coordenada de tile da posição extremado BB, DireitaX (para o x) ou In f eriorY (para o y).

A Figura A.6 apresenta um exemplo da aplicação do Algoritmo A.2. Note que,apenas uma pequena parte do tile T R aparece na tela. O último valor de x ≤ DireitaX

corresponde a um pixel do penúltimo tile (posição A). Somente a primeira condição fariacom que o último tile (T R) não fosse identificado, pois na iteração seguinte, x seriaigual a XC. Dessa forma, a segunda condição é necessária. No exemplo da Figura A.6,o algoritmo calcula a coordenada de tile da posição extrema DireitaX e verifica se é amesma coordenada de tile do valor de x. Como a coordenada de tile de DireitaX (XB) é amesma de XC, o tile T R é adicionado a lista de tiles dispostos na tela.

Figura A.6: Identificação dos tiles visualizados na tela. A imagemde fundo é do Google Maps.

APÊNDICE BMatriz de Transição do Modelo da Figura 4.15

Neste apêndice, mostramos a matriz de transição do modelo de estados querepresenta a sequência de passos dos usuários (o MESP), discutido na Seção 4.2.5. Devidoao amplo espaço ocupado pela matriz, ela foi dividida em 4 tabelas, as quais são dispostasa seguir.

Zoom 01 Zoom 02 Zoom 03 Zoom 04 Zoom 05 Zoom 06Zoom 01 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 02 0.000000 0.200000 0.500000 0.200000 0.000000 0.000000Zoom 03 0.000000 0.027778 0.694444 0.111111 0.055556 0.041667Zoom 04 0.000000 0.020000 0.030000 0.360000 0.250000 0.070000Zoom 05 0.000000 0.005780 0.040462 0.121387 0.427746 0.156069Zoom 06 0.000000 0.000000 0.003968 0.023810 0.130952 0.440476Zoom 07 0.000000 0.000000 0.000000 0.009174 0.020642 0.098624Zoom 08 0.000000 0.000000 0.001852 0.001852 0.003704 0.027778Zoom 09 0.000000 0.000000 0.000000 0.000000 0.000000 0.009506Zoom 10 0.000000 0.000000 0.001603 0.000000 0.001603 0.001603Zoom 11 0.000000 0.000000 0.000000 0.001418 0.001418 0.000000Zoom 12 0.000000 0.000000 0.000000 0.000000 0.001046 0.002092Zoom 13 0.000000 0.000000 0.000000 0.000681 0.000000 0.000000Zoom 14 0.000461 0.000000 0.000000 0.000461 0.000000 0.000000Zoom 15 0.000000 0.000000 0.000351 0.000000 0.000000 0.000000Zoom 16 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 17 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 18 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 19 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 20 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 21 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000

Rota 0.000000 0.000296 0.000296 0.001775 0.003550 0.008284Pesquisa 0.000000 0.000756 0.000756 0.002268 0.003779 0.003779

Início/Fim 0.000000 0.000867 0.000867 0.008666 0.005199 0.004333

Tabela B.1: Matriz de transição do modelo de estados que repre-senta a sequência de passos dos usuários - parte 1.

Apêndice B 111


Rota 0.013314 0.018935 0.013905 0.013314 0.014201 0.045562Pesquisa 0.002268 0.008314 0.008314 0.018896 0.033258 0.060469

Início/Fim 0.008666 0.007799 0.008666 0.010399 0.017331 0.024263


Apêndice B 112


Rota 0.086982 0.091124 0.058580 0.044970 0.044675 0.004734Pesquisa 0.037793 0.046863 0.095238 0.083900 0.231293 0.020408

Início/Fim 0.022530 0.026863 0.044194 0.023397 0.036395 0.006066


Apêndice B 113

Zoom 19 Zoom 20 Zoom 21 Rota Pesquisa Início/FimZoom 01 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000Zoom 02 0.000000 0.000000 0.000000 0.100000 0.000000 0.000000Zoom 03 0.000000 0.000000 0.000000 0.013889 0.000000 0.041667Zoom 04 0.000000 0.000000 0.000000 0.050000 0.040000 0.070000Zoom 05 0.000000 0.000000 0.000000 0.057803 0.017341 0.104046Zoom 06 0.000000 0.000000 0.000000 0.055556 0.011905 0.063492Zoom 07 0.000000 0.000000 0.000000 0.073394 0.020642 0.055046Zoom 08 0.000000 0.000000 0.000000 0.085185 0.012963 0.061111Zoom 09 0.000000 0.001901 0.000000 0.066540 0.007605 0.030418Zoom 10 0.000000 0.000000 0.000000 0.075321 0.017628 0.043269Zoom 11 0.000000 0.000000 0.000000 0.063830 0.019858 0.046809Zoom 12 0.000000 0.000000 0.000000 0.131799 0.026151 0.031381Zoom 13 0.000000 0.000000 0.000000 0.144414 0.018392 0.053815Zoom 14 0.000921 0.000000 0.000000 0.105021 0.018885 0.046983Zoom 15 0.000702 0.000351 0.000702 0.075140 0.019312 0.043890Zoom 16 0.004124 0.000000 0.000000 0.079115 0.014998 0.050994Zoom 17 0.012771 0.001161 0.001548 0.089396 0.027477 0.058437Zoom 18 0.127811 0.010651 0.002367 0.041420 0.009467 0.072189Zoom 19 0.566239 0.057692 0.051282 0.023504 0.012821 0.070513Zoom 20 0.252525 0.414141 0.111111 0.040404 0.000000 0.070707Zoom 21 0.140845 0.154930 0.394366 0.056338 0.042254 0.154930

Rota 0.000592 0.000888 0.000000 0.471302 0.002367 0.060355Pesquisa 0.006047 0.001512 0.000000 0.097506 0.207861 0.028723

Início/Fim 0.001733 0.000867 0.000000 0.126516 0.614385 0.000000


caracterização e modelagem do comportamento de … · sistemas de mapa web, ou sigs web, são...

Documents