Desenvolvimeneto de API em JavaScript para geração de rota com OSRM no ambiente TourplanB
Descrição do Produto
UNIVERSIDADE VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO
LORRAN DE SOUZA PEGORETTI
DESENVOLVIMENTO DE API EM JAVASCRIPT PARA GERAÇÃO DE ROTA COM OSRM NO AMBIENTE TOURPLANB
VILA VELHA 2015
LORRAN DE SOUZA PEGORETTI
DESENVOLVIMENTO DE API EM JAVASCRIPT PARA GERAÇÃO DE ROTA COM OSRM NO AMBIENTE TOURPLANB Trabalho de Conclusão de Curso apresentado a Universidade Vila Velha como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. Orientador: Msc. SANDRO TONINI SILVA
VILA VELHA 2015
LORRAN DE SOUZA PEGORETTI
DESENVOLVIMENTO DE API EM JAVASCRIPT PARA GERAÇÃO DE ROTA COM OSRM NO AMBIENTE TOURPLANB
BANCA EXAMINADORA
Prof. Msc. SANDRO TONINI SILVA Universidade Vila Velha Orientador
Prof. Msc. VINICIUS ROSALEN DA SILVA Universidade Vila Velha
Prof. Msc. CRISTIANO BIANCARDI Universidade Vila Velha Trabalho de Conclusão de Curso aprovado em 08/06/2015.
Autorizo que a UVV, sem ônus, promova a publicação de minha monografia em página própria na Internet ou outro meio de divulgação de trabalho científico.
ASSINATURAS
Prof. Msc. SANDRO TONINI SILVA Universidade Vila Velha Orientador
LORRAN DE SOUZA PEGORETTI Universidade Vila Velha
08/06/2015
A minha família. Aos meus amigos. A todos que amo.
AGRADECIMENTOS Agradeço principalmente aos meus pais pela força que me deram durante o tempo deste trabalho e durante toda a duração do curso, mesmo quando eu quis simplesmente desistir de tudo. Agradeço a toda equipe da Dabeeo, por toda ajuda, apoio e suporte enquanto estive morando na Coréia do Sul. Agradeço a todos os professores com quem tive a oportunidade de aprender tudo que precisei para o desenvolvimento deste trabalho e tantos outros durante minha vida, agradeço em especial a ajuda e orientação do professor Sandro Tonini durante todo o tempo deste trabalho. Agradeço a todos meus amigos que sempre estavam lá quando precisei durante esta longa jornada. A todos, obrigado.
"소주 주세요." 세종대왕
LISTA DE TABELAS 1
Requisitos Funcionais. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
2
Caso de Uso: Criar Plano de Viagem . . . . . . . . . . . . . . . . . . . .
48
3
Caso de Uso: Adicionar Atração ao Plano de Viagem . . . . . . . . . .
48
4
Caso de Uso: Gerar Rota . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5
Caso de Uso: Selecionar Tipo de Atração . . . . . . . . . . . . . . . . .
50
6
Caso de Uso: Adicionar Acomodação . . . . . . . . . . . . . . . . . . .
50
7
Caso de Uso: Salvar Plano . . . . . . . . . . . . . . . . . . . . . . . . .
51
8
Marcadores e tipos de atrações. . . . . . . . . . . . . . . . . . . . . . .
75
LISTA DE FIGURAS 1
Website do planjeador de viagem online TourplanB. [Dabeeo 2015]
. .
18
2
Website do guia turístico Triposo. [Triposo 2015] . . . . . . . . . . . . .
19
3
Website do guia turístico TripAdvisor. [TripAdvisor 2015] . . . . . . . . .
19
4
Georreferenciamento de lotes na região de Bauxita, Outro Preto, Minas Gerais. [TerraLab 2010] . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
24
Rota entre a prefeitura de Seul e a estação de metrô City Hall Station. (Imagem gerada pelo primeiro protótipo) . . . . . . . . . . . . . . . . . .
25
6
Grafo com seis vértices e sete arestas. . . . . . . . . . . . . . . . . . .
26
7
Exemplo de Problema de Roteamento de Veículos representado por um grafo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Exemplo funcionamento do algoritmo de Dijkstra e criação de árvore de vértices visitados. [Sedgewick e Wayne 2011] . . . . . . . . . . . . . . .
9
29
Grafo com três vértices e duas arestas e custo 3 do vértice v ao vértice w, passando pelo vértice u. . . . . . . . . . . . . . . . . . . . . . . . . .
10
27
30
Grafo com atalho criado do vértice v ao vértice w pelo Algoritmo Contraction Hierarchies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
11
Grafo com dois vértices e uma aresta, encontrado pelo motor de busca.
31
12
Grafo com seis vértices e cinco aresta encontrado como menor caminho pelo motor de busca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
32
Pseudocódigo utilizado para a criação de atalhos entre vértices no algoritmo de Contraction Hierarchies. [Geisberger et al. 2008] . . . . . . .
32
14
Camada de Engenharia Software. [Pressman 2011] . . . . . . . . . . .
33
15
Sequência das fases de desenvolvimento no modelo em cascata. . . .
34
16
Rota gerada pelo OSRM entre Seul e Busan. (Imagem gerada pelo primeiro protótipo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Exemplo de requisição para geração de rota entre dois pontos utilizada no OSRM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
41
Mapa gerado pelo Mapnik da área central de Seul no estilo utilizado por este trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
40
42
Mapa gerado pelo Mapnik da área central de Seul no estilo utilizado pelo OpenStreetMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
20
Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . .
47
21
Diagrama de Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
22
Diagrama de Sequência.
. . . . . . . . . . . . . . . . . . . . . . . . . .
55
23
Arquitetura cliente-servidor em duas camadas. [Falbo 2011] . . . . . . .
57
24
Arquitetura cliente-servidor em três camadas. [Falbo 2011] . . . . . . .
58
25
Arquitetura da aplicação TourplanB. . . . . . . . . . . . . . . . . . . . .
59
26
Diagrama de Entidades e Relacionamentos do banco de dados utilizado pela aplicação TourplanB. . . . . . . . . . . . . . . . . . . . . . . . . . .
63
27
Diagrama de Implantação da aplicação TourplanB. . . . . . . . . . . . .
64
28
Diagrama de componentes referente à aplicação TourplanB. . . . . . .
66
29
Rota entre Torre Eiffel e Museu do Louvre plotada pelo primeiro protótipo. 70
30
Rota entre Lisboa e Moscou plotada pelo primeiro protótipo.
. . . . . .
71
31
Rota dentro de Seoul plotada pelo segundo protótipo. . . . . . . . . . .
73
32
Rota passando por Hanoi e Nha Trang, no Vietnã, Siem Reap, no Camboja e terminando em Phuket, na Tailândia plotada pelo segundo protótipo. 74
33
Página inicial da aplicação TourplanB. . . . . . . . . . . . . . . . . . . .
82
34
Pop-up de login da aplicação TourplanB. . . . . . . . . . . . . . . . . . .
83
35
Pop-up para seleção de cidade. . . . . . . . . . . . . . . . . . . . . . . .
84
36
Pop-up para seleção de data de início e fim de viagem. . . . . . . . . .
85
37
Inicio de criação de plano de viagem. . . . . . . . . . . . . . . . . . . .
85
38
Pop-up de atração mostrada quando mouse for passado sobre marcador. 86
39
Aba de mais informações de atração aberta. . . . . . . . . . . . . . . .
87
40
Atração adicionada ao plano de viagem. . . . . . . . . . . . . . . . . . .
87
41
Duas atrações adicionadas ao plano de viagem. . . . . . . . . . . . . .
88
42
Rota gerada entre duas atrações. . . . . . . . . . . . . . . . . . . . . . .
89
LISTA DE SIGLAS API
Aplication Programming Interface
DDoS
Distributed Denial-of-Service
DER
Diagrama Entidade-Relacionamento
GPS
Global Positioning System
HTTP
Hypertext Transfer Protocol
IPS
Intrusion Prevention Systems
JSON
JavaScript Object Notation
OSRM
Open Source Routing Machine
PDF
Portable Document Format
PNG
Portable Network Graphics
SGBD
Sistema de Gerenciamento de Banco de Dados
SSD
Solid State Drive
SVG
Scalable Vector Graphics
RAM
Random-access memory
UML
Unified Modeling Language
SUMÁRIO
RESUMO ABSTRACT 1 INTRODUÇÃO
17
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . .
20
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.4 Método de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.5 Descrição dos Capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2 FUNDAMENTAÇÃO TEÓRICA
23
2.1 Georreferenciamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.2 Grafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.3 Busca em grafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.3.1 Algoritmo de Dijkstra . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.3.2 Algoritmo de Contraction Hierarchies . . . . . . . . . . . . . . . .
29
2.4 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.4.1 Processo de Desenvolvimento . . . . . . . . . . . . . . . . . . .
33
3 TECNOLOGIAS
36
3.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2 jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.3 Servidor Web Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4 OpenStreetMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.5 Open Source Routing Machine . . . . . . . . . . . . . . . . . . . . . . .
39
3.6 Mapnik
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.7 API HotelsCombined . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4 ENGENHARIA DE REQUISITOS
44
4.1 Minimundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.2 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.3 Requisitos Não Funcionais . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.4 Descrição de Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.5 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.5.1 Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . .
46
4.5.2 Descrição de Casos de Uso . . . . . . . . . . . . . . . . . . . . .
47
5 ESPECIFICAÇÃO DE ANÁLISE
52
5.1 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
5.2 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6 PROJETO DE SOFTWARE
56
6.1 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.1.1 Tipos de Arquitetura de Software . . . . . . . . . . . . . . . . . .
56
6.1.2 Arquitetura da Aplicação TourplanB . . . . . . . . . . . . . . . .
58
6.2 Modelo de Dados da aplicação TourplanB . . . . . . . . . . . . . . . . .
62
6.3 Diagrama de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.4 Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.5 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.5.1 Segurança contra ataques DDoS . . . . . . . . . . . . . . . . . .
67
7 API EM JAVASCRIPT PARA GERAÇÃO DE ROTA COM OSRM NO AMBIENTE TOURPLANB
68
7.1 Primeiro Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
7.2 Segundo Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
7.2.1 Tipos de Atração . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
8 CONCLUSÃO
76
8.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
8.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
REFERÊNCIAS
78
Apêndice A -- Manual do Usuário
81
A.1 Utilizando o Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.1.1 Requisitos Mínimos . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.1.2 Acessando o Sistema . . . . . . . . . . . . . . . . . . . . . . . .
82
A.1.3 Criando um novo plano . . . . . . . . . . . . . . . . . . . . . . .
83
RESUMO Mesmo com maiores facilidades de viajar para outras regiões do planeta atualmente, por diversas vezes, é difícil encontrar informações prévias de qualidade, de serviços e atrações disponíveis no local desejado. Baseado nessa oportunidade, com foco no mercado asiático, especialmente a China, que possui diversas restrições e bloqueios sobre o uso da internet, um serviço de planejamento de viagem online foi criado, chamado Tourplanb. Este trabalho propõe a criação de uma solução em ambiente web a ser incluída neste serviço de planejamento de viagem online e utilizada para a definição de melhor rota a ser tomada entre as atrações definidas pelo usuário. Para alcançar o objetivo de geração de rota para o usuário, foi feito o estudo e uso de diversas técnicas, ferramentas e tecnologias voltadas para a geração de rota e desenvolvimento web, como por exemplo, o funcionamento de gerroferenciamento, o motor de geração de rotas Open Source Routing Machine e sua integração com a aplicação TourplanB. Ao final do trabalho, os objetivos propostos são alcançados, com a geração de um protótipo que valida a proposta inicial e é capaz de gerar rotas em todos os continentes do planeta, inclusive rotas transcontinentais, quando possível.
Palavras-Chave:
rota, Tourplanb, viagem.
ABSTRACT Even with bigger travelling facilities for other regions of the planet nowadays, for several times, it is hard to find prior quality information, of services and attractions available in the desired place. Based on this opportunity, focused in Asian market, especially China, where there are several restrictions and locks about internet usage, an online travel planning service have been created, called Tourplanb. This paper has a purpose of creating a web-based solution to be included within this online travel planning service and used to define the best route among attractions defined by the user. For reaching the objective of route generation for the user, was done a study and usage of several techniques, tools and technologies for route generation and we development, for example, georeferencing operation, the route generation engine Open Source Routing Machine and its integration within the TourplanB application. At the end of this paper, the proposed objectives were reached, with a development of a prototype that validates the initial purpose and is capable of generating routes in all the continents of the planet, inclusive transcontinental routes, when it is possible.
Keywords:
route, Tourplanb, travel.
17
1
INTRODUÇÃO
O setor de turismo de viagens tem crescido a números expressivos nas últimas décadas em todo o mundo. Segundo publicação da BBC, [BBC 2014] a indústria do turismo obteve um crescimento de aproximadamente 412 bilhões de dólares americanos entre o ano de 1995 a 2010 ao redor do mundo. De certa forma, tal situação reflete a facilidade e interesse dos turistas em realizar seus desejos, seja por aumento da disponibilidade financeira, maior conhecimento de diferentes áreas ao redor do globo por meio de programas de TV ou internet, e até mesmo maior facilidade de acesso a locais cada vez mais distantes proporcionados pelo desenvolvimento da tecnologia, que reduzem o tempo de viagem. Porém, por diversas vezes, é difícil encontrar informações prévias de qualidade, de serviços e atrações disponíveis nos locais desejados, de tal forma que torne mais seguro ao turista realizar o planejamento de sua viagem por conta própria. No mercado asiático, segundo [CNA/CK 2012], o ano de 2012 apresentou no primeiro semestre um crescimento de 8% no número de chegada de turistas, contra um crescimento de 5% mundial, sendo assim a área onde o mercado de turismo apresentou o maior crescimento mundial, possuindo agora 40% dos gastos mundiais com turismo. Percebendo o crescimento deste mercado, adicionado pela falta de um serviço que fosse capaz de prover informações sobre a região e a possibilidade de planejar a viagem nos mínimos detalhes, o serviço de planejamento de viagens online, Tourplanb1 , que possui informações sobre pontos turísticos, hotéis, restaurantes, shoppings centers e etc, além da possibilidade de criação de planos de viagem hora a hora, foi criado na Coréia do Sul para suprir esta necessidade. A título de ilustração deste serviço, a figura 1 mostra a construção de um plano de viagem para a cidade de Seoul no website do Tourplanb, um plano que começa dia 16 de Março, e as atrações podem ser adicionadas na ordem desejada ou no horário desejado. 1 Serviço
de planejamento de viagem online criado
18
Figura 1: Website do planjeador de viagem online TourplanB. [Dabeeo 2015] A figura 1, mostra a seleção de uma atração, o tradicional Mercado de Namdemun, traz suas informações básicas, como website, horário de funcionamento e sua página web, assim como sua localização no mapa. Então o mercado pode ser adicionado ao plano de viagem do usuário como a primeira atração a ser visitada. Contendo informações das mais diversas localidades do globo, o Tourplanb proporciona aos usuários informações prévias dos locais de destino e suas atrações, possibilitando fazer um planejamento melhor de sua viagem, dia a dia e até mesmo hora a hora. Como por exemplo, qual museu visitar primeiro, visto que um fecha mais cedo que outro às segundas-feiras. As outras soluções já existentes não se encaixam na definição de planejador de viagem, mas sim algo mais próximo a um guia turístico, onde é possível encontrar informações sobre os locais, porém não provê a possibilidade de criar um plano de viagem, decidindo o que visitar em qual dia, e em qual hora. Dentre estas soluções existe o Triposo, figura 2, e o TripAdvisor, figura 3, sendo o TripAdvisor mundialmente mais famoso que o Triposo, possuindo inclusive um selo de qualidade, chamado Travellers’ Choice, que é distribuído para hotéis, pontos turísticos e restaurantes ao redor do mundo que recebem boa nota em seu website.[TripAdvisor 2015].
19
Figura 2: Website do guia turístico Triposo. [Triposo 2015]
Figura 3: Website do guia turístico TripAdvisor. [TripAdvisor 2015]
20
1.1
Motivação
Buscando fornecer o serviço de planejamento de viagens, especialmente para o mercado asiático, como Coréia do Sul e China, focado principalmente no crescente turismo de chineses para a Coréia do Sul, [CNN 2012] o planejador de viagens online Tourplanb, foi criado em meados de 2013. Após sua criação, um sistema de informação deve estar em constante melhoria para que possa cativar novos usuários e manter usuários habituais, visto que na maioria das vezes surge um concorrente ou algum outro serviço que se propõem a prover a mesma, ou parecida, experiência para o usuário. Buscando melhorar a experiência do usuário, identificou-se a necessidade de prover além de informações sobre pontos turísticos, informações sobre rotas entre e para estes pontos turísticos dentre os serviços do Tourplanb. Para que assim o viajante além de ter o seu plano de viagem, possa ter também a melhor rota possível para o plano de viagem desejado.
1.2
Objetivos
1.2.1
Objetivo Geral
Desenvolver uma solução em ambiente web para a criação de rotas entre atrações turísticas utilizando técnicas de georreferenciada em mapas, de forma que seja mais fácil para o usuário decidir seu plano de viagem, tendo a sua disposição a rota a ser seguida.
1.2.2
Objetivos Específicos
• Levantar e especificar o ambiente de negócio de turismo planejado, apontando suas restrições e oportunidades; • Pesquisar heurísticas para criação de rotas entre pontos georreferenciados; • Utilizar práticas, técnicas e ferramentas de Engenharia de software para implementar a integração entre uma API JavaScript e mapas, possibilitando a comunicação entre os mesmos e tratando solicitações e respostas; • Desenvolver a API respeitando a delimitação definida;
21
• Documentar o desenvolvimento e resultados obtidos;
1.3
Justificativa
Para não depender de serviços de terceiros, se fez necessária a criação de uma solução própria para a geração de rota, ou por estes serviços de terceiros possuírem um alto valor, limite de acesso por dia, hora, ou segundo, ou mesmo para deter um maior controle sobre o sistema como um todo. Ademais, alguns países asiáticos possuem rígidas políticas sobre o controle da Internet, como é o caso da China, onde algumas das ferramentas mais conhecidas para geração de rota e busca, como o Google Maps, são bloqueadas. [Carsten 2014]. Sendo assim, um sistema para geração de rota em acordo com o governo chinês, e sem bloqueio, sanaria o problema, e criaria um incremento para o sistema de planejamento de viagens. Tendo este cenário como base, fez-se então necessário o desenvolvimento de uma solução independente de serviços de terceiros que fosse capaz de calcular a melhor rota entre pontos e exibi-las em um mapa para ser integrado ao sistema TourPlanB.
1.4
Método de Pesquisa
Segundo Mario Bunge, [Szczepanik 2011] uma investigação procede de acordo com um método científico que se cumpre, ou ao menos se propõe a cumprir, as seguintes etapas: descobrimento do problema, colocação precisa do problema, procura de conhecimentos ou instrumentos relevantes ao problema, tentativa de solução do problema com auxílio dos meios identificados, invenção de novas ideias (hipóteses, teorias ou técnicas) ou produção de novos dados empíricos que prometam resolver o problema, obtenção de uma solução, investigação das consequências da solução obtida, prova (comprovação) da solução, correção das hipóteses. Sendo assim, para alcançar os objetivos, o método de pesquisa deste trabalho é dividido em seis etapas. A primeira etapa deste trabalho foi baseada na determinação do tema, o problema, nesta fase foi verificada uma necessidade, detalhada no início das atividades.
22
A segunda etapa foi focada no levantamento da bibliografia sobre desenvolvimento web, georreferenciamento, utilização de grafos para representação de caminhos e rotas, assim como a busca em grafos e tecnologias e ferramentas para auxiliar no desenvolvimento do trabalho. A terceira etapa se baseou no entendimento dos possíveis cenários de uso da API a ser desenvolvida. Na quarta etapa foi feita a proposição da arquitetura lógica, as ideias foram estruturadas conforme as exigências racionais da sistematização própria do trabalho. A quinta etapa consistiu da fase prática, onde foi feito o desenvolvimento do protótipo com base na arquitetura proposta anteriormente. Finalmente na sexta etapa, foi feita a conclusão com base nos resultados obtidos, reflexão sobre a usabilidade e aplicabilidade do protótipo desenvolvido em outras soluções, assim como pontos para discussões de trabalhos futuros.
1.5
Descrição dos Capítulos
Descreve-se, nos capítulos seguintes, a fundamentação teórica (2) assim como as tecnologias (3) utilizadas para o desenvolvimento deste trabalho, a engenharia de requisitos (4), especificação da análise (5), o projeto de software (6), desenvolvimento no capitulo (7) e a conclusão (8) deste projeto.
23
2
FUNDAMENTAÇÃO TEÓRICA
Nas seções a seguir é descrita a fundamentação teórica necessária para o desenvolvimento deste trabalho. Descrições sobre georreferenciamento e as heurísticas utilizadas no trabalho.
2.1
Georreferenciamento
Este trabalho utiliza uma camada georreferenciada de mapas, ou seja uma camada sobre a qual é possível fazer o georreferenciamento baseado em localizações geográficas (latitude e longitude). Fazer o georreferenciamento é o ato de associar alguma coisa com localizações em espaço físico. Então é possível associar uma imagem de um mapa ou mesmo imagens que possuam a descrição vetorial de cada pixel, com localizações espaciais. Esta associação pode ser aplicada a qualquer tipo de objeto ou estrutura que possa ser relacionado a uma localização geográfica, como estradas, praças, pontes, construções e etc. [Hackeloeer et al. 2014]. A figura 4 mostra o georreferenciamento de lotes na região de Bauxita em Minas Gerais produzida pelo sistema SIGHabitar da Universidade Federal de Ouro Preto, onde é possível ver a divisão de cada lote e sua associação com a imagem do mapa.
24
Figura 4: Georreferenciamento de lotes na região de Bauxita, Outro Preto, Minas Gerais. [TerraLab 2010] Para este trabalho a camada georreferenciada é utilizada para que seja possível traçar a rota no mapa, visto que, é possível relacionar qualquer tipo de objeto, incluindo estradas, ruas e avenidas com a imagem. Sendo assim, a rota gerada pelo motor de geração de rota, será o elemento a ser relacionado com a imagem. A título de ilustração do georreferenciamento utilizado neste trabalho, a figura 5 mostra uma rota entre a prefeitura de Seul e a estação de metrô City Hall Station, onde para que seja possível desenhar a linha da rota, é necessário saber o georreferenciamento, ou seja, as posições geográficas, da prefeitura e da estação de metrô, além de saber a posição geográfica das duas ruas que são necessárias para chegar de um ponto a outro, para que assim seja possível desenhar a rota dentro dos limites desejados, sendo eles, os dois pontos escolhidos e os limites das duas ruas utilizadas.
25
Figura 5: Rota entre a prefeitura de Seul e a estação de metrô City Hall Station. (Imagem gerada pelo primeiro protótipo)
26
2.2
Grafos
Grafos são conjuntos de elementos, onde alguns pares de elementos são conectados por links. Os elementos conectados são chamados de vértices e os links que fazem a conexão entre os pares de vértices são chamados de arestas. [Trudeau 2001]. A figura 6 traz a representação de um grafo com seis vértices e sete arestas.
Figura 6: Grafo com seis vértices e sete arestas. De acordo com [Feofiloff, Kohayakawa e Wakabayashi 2001], grafos são uma excelente opção para representar mapas de estradas, onde por exemplo, cada vértice representa um ponto da cidade e as estradas são representadas pelas arestas. Um exemplo da aplicação de grafos como mapa de estradas, é o Problema de Roteamento de Veículos [Dantzig e Ramser 1959], que consiste no atendimento de um conjunto de consumidores por uma frota de veículos que partem de um determinado ponto, o depósito. Assim cada veículo tem sua capacidade definida e a demanda dos consumidores não pode ultrapassar a capacidade dos veículos. A figura 7, mostra o grafo que representa um exemplo do Problema de Roteamento de Veículos. Como este trabalho possui o objetivo de criar rotas entre pontos turísticos, é feito o uso de grafos, pois como dito anteriormente, os grafos são uma excelente opção para a representação de estradas, além de que com o uso de algoritmos específicos, é possível a realização da busca em grafos e a criação de rotas entre os pontos desejados.
27
Figura 7: Exemplo de Problema de Roteamento de Veículos representado por um grafo.
2.3
Busca em grafos
De acordo com [Cormen et al. 2001] existem diversos algoritmos para busca em grafos, como por exemplo o algoritmo A*, Busca em largura, Busca em profundidade, Dijkstra, Minimax entre outros.Dentre esta diversidade de algoritmos de busca em grafos, são mostrados neste trabalho o algoritmo de Dijkstra, pois o algoritmo de Dijkstra pode ser facilmente aplicado ao contexto deste trabalho, já que é usado quando não se tem conhecimento sobre o grafo a ser pesquisado e não é possível estimar inicialmente a distância do vértice inicial ao vértice final desejado, como é o caso de encontrar a melhor rota entre duas atrações turísticas, visto que além de tudo o ambiente físico, as ruas e avenidas, podem sofrer mudanças, além de o algoritmo de Dijkstra é um algoritmo clássico e estudado durante o curso. O outro algoritimo mostrado é o algoritmo utilizado pelo motor de geração de rota Open Source Route Machine, uma implementação do Contraction Hierarchies. [Luxen 2014].
28
2.3.1
Algoritmo de Dijkstra
O algoritmo de Dijkstra, foi concebido pelo cientista da computação holandês Edsger Dijkstra no ano de 1956 e publicado em 1959. Se trata de um algoritmo de busca em grafos que resolve o problema do menor caminho entre vértices, para grafos que não possuam arestas com valor de custo negativo, produzindo assim uma árvore de menor caminho entre os vértices requeridos. [Dijkstra 1959]. Um pe a usabilidade do algoritmo de Dijkstra, e exatamente o foco deste trabalho, a necessidade de uma pessoa se deslocar de um ponto turístico pra outro, e para isso estão disponíveis várias estradas ou ruas que passam por diversos bairros ou cidades, então é necessário decidir qual o menor trajeto.
2.3.1.1
Funcionamento
O algoritmo de Dijkstra mantém um vetor de distâncias tentadas de cada vértice. O algoritmo resolve (ou visita) os vértices da rede baseado na ordem da distância dos vértices para o vértice raiz s e mantem uma invariante do caminho tentado que seja o correto para os vértices visitados. Quando o vértice u é visitado, ocorre um relaxamento, para que seja feito a visita à todos os vértices v adjacentes ao vértice u. A distância tentada até v é marcada como o tamanho do caminho de s passando por u até v quando acontece uma melhora no tamanho do caminho. O algoritmo de Dijkstra pode ser parado quando o vértice destino é alcançado. [Dijkstra 1959]. A figura 8, mostra um exemplo de funcionamento do algoritmo de Dijkstra e a geração da árvore de vértices visitados, afim de encontrar o menor caminho. Como descrito anteriormente um relaxamento é feito para que seja feita a visita a outro vértice, como é mostrado na figura 8, a primeira árvore possui 25% dos vértices visitados pelo algoritmo, a segunda árvore possui 50% dos vértices visitados, a terceira árvore 75% dos vértices visitados e a quarta árvore possui 100% dos vértices necessários para formar a rota visitados.
29
Figura 8: Exemplo funcionamento do algoritmo de Dijkstra e criação de árvore de vértices visitados. [Sedgewick e Wayne 2011]
2.3.1.2
Complexidade
De acordo com [Fredman e Tarjan 1987], uma implementação do algoritmo de Dijkstra baseado em uma fila de prioridade mínima, pode ser obtido uma complexidade de O([m+n] log n). Onde m é o número de arestas e n é o número de vértices. Neste caso, a fila de propriedade mínima é implementada utilizando Fibonacci Heap, uma estrutura do tipo heap, que consiste de uma coleção de árvores. Esta estrutura foi desenvolvida por Michael Fredman e Robert Tarjan em 1984.[Fredman e Tarjan 1987].
2.3.2
Algoritmo de Contraction Hierarchies
Contraction Hierarchies é uma técnica para acelerar a criação do caminho mais curto, fazendo primeiro um pré-processamento para criar versões mais encolhidas do grafo de conexão. Pode ser usado para gerar rotas de caminho mais curto muito mais
30
eficientemente que o algoritmo de Dijkstra, por exemplo. [Geisberger et al. 2008]. Este tipo de algoritmo possui duas fases, o pré-processamento do grafo original, que pode levar muito tempo para ser finalizado, no caso específico deste trabalho tomou dois dias e meio com a informação do planeta inteiro disponibilizada pelo projeto Open Street Map, e a fase de query que demanda menos de um segundo. O algoritmo de Contraction Hierarchies é um caso extremo de abordagem de hierarquia, que gera um vértice multicamadas na fase de pré-processamento, sendo cada vértice do grafo representado com seu próprio nível de hierarquia. [Geisberger et al. 2008].
2.3.2.1
Funcionamento
Como dito anteriormente o algoritmo de Contraction Hierarchies é divido em duas fases, pré-processamento e query. Na fase de pré-processamento os níveis ou ordem dos vértices são arbitrários, o ponto principal é que alguns atalhos são introduzidos quando se faz necessário. Como mostrado na figura 9 para alcançar o vértice w partindo do vértice v é necessário passar pelo vértice u.
Figura 9: Grafo com três vértices e duas arestas e custo 3 do vértice v ao vértice w, passando pelo vértice u. Então o algoritmo de Contraction Hierarchies cria uma nova aresta para encurtar o caminho do vértice v ao vértice w como mostrado na figura 10, preservando o custo original do caminho, que é 3. No final do pré-processamento, é obtido um grafo composto do grafo original com ordenação de vértices e com atalhos introduzidos. [Geisberger et al. 2008]
31
Figura 10: Grafo com atalho criado do vértice v ao vértice w pelo Algoritmo Contraction Hierarchies. Desta forma o motor de busca Open Source Route Machine consegue fazer a busca pela ordenação dos vértices tornado a query muito mais rápida e sendo necessário apenas remontar o grafo original do menor caminho encontrado. [Luxen 2014]. Suponha, o menor caminho entre dois pontos encontrado pelo motor de busca representado pelo grafo da figura 11. A aresta encontrada é na verdade um atalho criado pelo pré-processamento.
Figura 11: Grafo com dois vértices e uma aresta, encontrado pelo motor de busca. Após a seleção do menor caminho, o grafo original que contém todos os vértices e arestas é recriado, como mostra a figura 12.
32
Figura 12: Grafo com seis vértices e cinco aresta encontrado como menor caminho pelo motor de busca. O grande diferencial do algoritmo de Contraction Hierarchies, se dá na fase de pré-processamento, onde são gerados os atalhos entre os vértices como mostrado na figura 10, a seguir na figura 13, o pseudocódigo utilizado nesta fase.
Figura 13: Pseudocódigo utilizado para a criação de atalhos entre vértices no algoritmo de Contraction Hierarchies. [Geisberger et al. 2008]
2.3.2.2
Complexidade
Segundo [Geisberger et al. 2008], a complexidade na fase de pré-processamento depende dos parâmetros escolhidos para o algoritmo. Um parâmetro definido é o número de vértices a serem utilizados na criação do atalho, como por exemplo na figura 10, onde o terceiro vértice foi encolhido. Para visitar o vértice afim de criar o atalho, é utilizado o algoritmo de Dijkstra, portanto o custo de contração, ou encolhimento, tem por base a complexidade do algoritmo de Dijkstra, podem ter uma complexidade maior ou igual dependendo do parâmetro definido. v De acordo com [Luxen e Vetter 2011], como o número de vértices a serem visita-
33
dos após a fase de pré-processamento é menor que o numero de vértices do grafo original, a implementação utilizada pelo motor de geração de rota tem uma complexidade logarítmica, O(log K), o que permite a definição de rotas em menos de um segundo.
2.4
Engenharia de Software
De acordo com [Pressman 2011], a engenharia de software é uma estrutura que abrange um processo, um conjunto de métodos e uma gama de ferramentas, que são utilizados para garantir a qualidade de um software e satisfazer às necessidades das pessoas que irão utilizá-lo, visto que o software de computador é como um outro produto qualquer. Segundo [Pressman 2011], a engenharia software pode ser representada em camadas, como é mostrado na figura 14, tendo como sustentação fundamental para a engenharia de software o foco na qualidade e sua base na camada de processo. Sendo o processo que possibilita o desenvolvimento de software ser feito de forma racional e dentro do prazo.
Figura 14: Camada de Engenharia Software. [Pressman 2011]
2.4.1
Processo de Desenvolvimento
O processo de software é formado por um conjunto de passos parcialmente ordenados, relacionados com conjuntos de artefatos, pessoas, recursos, estruturas organizacionais e restrições, tendo como objetivo produzir e manter os produtos de software requeridos [Loncham 1993]. Existem alguns modelos de processo de desenvolvimento, chamados modelos prescritivos, pois eles prescrevem a maneira como os elementos do processo se interrelacionam uns com os outros. [Pressman 2011].
34
Para o desenvolvimento deste trabalho, o modelo de processo de desenvolvimento adotado foi o modelo em cascata, pois este modelo é bem adaptado para o fato de o problema possuir os requisitos bem entendidos, o que é o caso deste trabalho, pois se trata de um aperfeiçoamento definido de um sistema já existente, como mencionado anteriormente.
2.4.1.1
Modelo de Desenvolvimento em Cascata
O modelo em cascata também é chamado de ciclo de vida clássico, assume que é possível detalhar todos os requisitos antes das demais fases de desenvolvimento [Bezerra 2006], e sugere uma abordagem sequencial e sistemática para o desenvolvimento do software, como mostrado na figura 15, após a fase de levantamento das necessidades do cliente, ou comunicação, passa pela fase de planejamento, modelagem, construção, implantação e finalmente o suporte contínuo do software concluído. [Pressman 2011].
Figura 15: Sequência das fases de desenvolvimento no modelo em cascata. Segundo [Pressman 2011], o modelo de desenvolvimento em cascata é bem adaptado para ocasiões em que os requisitos do problema são bem compreendidos, quando o trabalho flui da comunicação à implantação de um modo razoavelmente linear. O que
35
é algumas vezes encontrado quando se trata de alterações ou aperfeiçoamentos de um sistema já existente. Por este motivo, o desenvolvimento em cascata foi adotado para este trabalho, visto que se trata de um aperfeiçoamento do sistema de planejamento de viagem online já existente Tourplanb e possui os requisitos bem compreendidos. Além do método de desenvolvimento em cascata existem outros modelos de desenvolvimento, como por exemplo o modelo de prototipação e o modelo de desenvolvimento ágil, estes modelos não serão utilizados no desenvolvimento deste trabalho pois segundo [Sommerville 2003], o modelo de prototipação é utilizado quando apenas o conjunto de objetivos gerais do sistema são definidos, mas não é possível gerar requisitos definidos, de entrada, de processamento e de saída, para o sistema, o que não é o caso deste trabalho, por se tratar de um aperfeiçoamento de um sistema já existente, possuindo os requisitos amplamente conhecidos e bem definidos, sendo assim o modelo de desenvolvimento de prototipação não se encaixa nos objetivos deste trabalho. De acordo com [Sommerville 2003], os métodos ágeis, são métodos de desenvolvimento incremental em que são feitos vários incrementos pequenos afim de atingir o software resultante final proposto, o que não se adequa a este trabalho, visto que o desenvolvimento não será feito de forma incremental, portanto nenhum método ágil será utilizado para o desenvolvimento deste trabalho.
36
3
TECNOLOGIAS
Nas seções a seguir são descritas as tecnologias e artefatos utilizados no desenvolvimento deste trabalho, como a linguagem de programação JavaScript e sua biblioteca jQuery, descrição do servidor web utilizado, descrição do projeto OpenStreetMap, do qual são colhidas informações sobre o mapeamento de regiões, descrição do motor de geração de rota Open Source Routing Machine, do toolkit de renderização de mapas Mapnik e descrição da API para localização de acomodação provida pela empresa HotelsCombined.
3.1
JavaScript
A linguagem de programação JavaScript foi criada na Netscape nos dias iniciais da Web, e tecnicamente, “JavaScript” é uma marca registrada da Sun Microsystems (hoje Oracle) usada para descrever a implementação de linguagem do Netscape (hoje Mozilla). Segundo [Flanagan 2011], JavaScript é a linguagem de programação da web. A maioria dos websites modernos usam JavaScript, e todos navegadores – em computadores, tablets, e smartphones – incluem interpretadores de JavaScript, fazendo do JavaScript a linguagem de programação de maior onipresença da história. A linguagem de programação JavaScript, é uma linguagem de alto nível, dinâmica, com programação interpretada sem tipos, que é bem adequado ao estilo de programação orientada a objetos e de programação funcional. A linguagem de programação JavaScript deriva sua sintaxe da linguagem de programação Java, funções de primeira-classe da linguagem de programação Scheme, e suas funções de herança, da linguagem de programação Self. Apesar do nome, JavaScript é completamente diferente da linguagem de programação Java, exceto por sua semelhança superficial da sintaxe.
37
Foi a linguagem utilizada para a desenvolvimento deste trabalho por opção da empresa detentora da aplicação TourplanB, e para facilitar a integração com a aplicãção, visto que a mesma também faz uso do JavaScript.
3.2
jQuery
jQuery é uma biblioteca JavaScript cross-browser, ou seja, capaz de funcionar perfeitamente em praticamente todos navegadores modernos, assim como o JavaScript. A biblioteca jQuery foi desenvolvida para simplificar os scripts do lado do cliente que interagem com o HTML. jQuery, no seu núcleo, é uma biblioteca de manipulação de DOM. DOM é uma estrutura de árvore que representa todos os elementos de um website. O jQuery é responsável por tornar as tarefas de encontrar, selecionar e manipular esses elementos DOM, simples e conveniente. Além da seleção e manipulação básica de elementos DOM, a biblioteca jQuery provê um novo paradigma para manipulação de eventos em JavaScript. A biblioteca jQuery é composta de apenas um único arquivo contendo todos DOM comuns, eventos, efeitos e funções Ajax. Ela pode ser incluída à um website vinculandose uma cópia local, ou a uma das muitas copias disponíveis em servidores públicos [jQuery Foundation 2014].
3.3
Servidor Web Apache
Segundo [Tanenbaum 2003], servidor web é um programa responsável por aceitar pedidos HTTP de clientes, geralmente de navegadores, e servi-los com respostas HTTP, que incluem opcionalmente dados, que são geralmente páginas web com imagens embutidas. O servidor Web Apache é um software colaborativo robusto, de nível comercial e de código livre [Foundation 2014] e segundo [Netcraft 2015] o servidor web mais utilizado do mundo. O Apache é então o servidor web utilizado neste trabalho, responsável por receber as requisições do navegador do cliente e responde-las, além de realizar a comunicação com os outros servidores utilizados, como o servidor que contém o motor de geração de rotas, e o servidor da empresa HotelsCombined por meio de sua
38
API detalhada mais à frente. O servidor web Apache, é utilizado neste trabalho pois além de se tratar de uma opção da empresa, o Apache é o servidor web mais utilizado do mundo [Netcraft 2015], o que significa de certa forma que, se trata de um servidor confiável além de ser um software de código livre.[Foundation 2014].
3.4
OpenStreetMap
O OpenStreetMap é um projeto de mapeamento colaborativo para criar um mapa livre e editável do mundo, é desenvolvido por uma comunidade voluntária de mapeadores que contribuem e mantêm atualizados os dados sobre estradas, trilhos, cafés, estações ferroviárias e muito mais por todo o mundo. [OpenStreetMap Contributors 2014]. O OpenStreetMap foi criado por Steve Coast em 2004, no Reino Unido. O OpenStreetMap foi inspirado pelo sucesso da Wikipédia [Lardinois 2014] e a preponderância dos dados de mapas proprietários no Reino Unido e em outros lugares. [Ramm 2011] Desde então, o OpenStreetMap possui mais de 1,6 milhões de usuários registrados [Neis 2012], que podem coletar dados usando um levantamento manual, dispositivos de GPS, fotografias aéreas e outras fontes livres. Mais que o mapa gerado, os dados gerados pelo projeto OpenStreetMap são considerados seu output primário. Esses dados estão então disponíveis para uso em aplicações tradicionais, substituir mapas proprietários, e em papéis mais incomuns, como para substituir dados incluídos em receptores GPS. [OSM Fondation 2014] Os dados gerados pelo OpenStreetMap podem ser obtidos no website do projeto, podem ser obtidos por áreas como continentes ou países ou então do globo como um todo. A opção pelo uso dos dados providos pelo OpenStreetMap se dá pelo fato de este ser o maior projeto do tipo encontrado nas pesquisas realizadas junto da empresa, além de ser um projeto colaborativo e não fazer o uso de dados proprietários, o que poderia beneficiar algumas regiões em detrimento de outras. Este trabalho portanto, propõe o uso dos dados e conteúdo do OpenStreetMap para a geração de rota e renderização de mapas, sendo estes explicados nas próximas seções.
39
3.5
Open Source Routing Machine
O Open Source Routing Machine (OSRM), é o motor que será utilizado para a geração da rota entre os pontos selecionados, sua escolha se deve a sua alta velocidade de resposta, o que é um fator crucial ao projeto, além da possibilidade de ser executado em servidores da empresa Dabeeo, o que resolveria qualquer problema de bloqueio, caso exista, nos países mercado foco. O Open Source Routing Machine é a implementação de um motor de alta performance para geração do caminho mais curto em redes rodoviárias. Ele combina o algoritmo de Contraction Hierarchies com os dados de redes rodoviárias gerados pelo projeto OpenStreetMap. O OSRM pode computar e gerar o menor caminho, desde que exista, entre qualquer origem e qualquer destino, com pontos intermediários definidos ou não, em menos de alguns milissegundos. Além do mais, arquivos de dados do OpenStreetMap podem ser facilmente importados, visto que o OSRM é projetado para que seja compatível com o OpenStreetMap. [Luxen e Vetter 2011]. O servidor OSRM depois de preparado com o arquivo da área desejada, podendo ser inclusive o planeta inteiro, recebe requisições Ajax para a geração da rota entre os pontos desejados baseado em suas localizações geográficas (latitude e longitude). Após a geração da rota mais curta, o servidor OSRM retorna a rota criada com informações de quais ruas, avenidas ou rodovias devem ser tomadas para cumprir a rota, além de sua forma geométrica comprimida usando uma implementação do algoritmo de codificação de polilinha do Google. [Luxen 2014]. O algoritmo de polilinha do Google, armazena dois tipos de informações codificadas para qualquer conjunto de pontos fornecido, a latitude e a longitude desses pontos e os níveis de zoom máximos para exibir esses pontos. Uma polilinha codificada também armazena informações que especificam a precisão ao desenhar a polilinha. Com essas informações é possível que o mapa ignore os segmentos de desenho nos níveis de zoom onde essa precisão não é necessária. [Google 2014]. Na figura 16 pode ser visto um exemplo de rota entre a prefeitura de
40
Seul e a prefeitura de Busan, cidade localizada no sul da Coréia do Sul, gerada pelo OSRM utilizando o primeiro protótipo.
Figura 16: Rota gerada pelo OSRM entre Seul e Busan. (Imagem gerada pelo primeiro protótipo) O OSRM utiliza um servidor sem estado, para o qual é feita a requisição de geração de rota.
3.5.1
Servidor Sem Estado
Servidor sem estado é assim chamado por utilizar o protocolo sem estado, ou stateless protocol, para realizar a comunicação com o lado do cliente. Este protocolo considera cada requisição como uma transação independente, que não está relacionada a nenhuma requisição anterior, de que forma que a comunicação se dê em pares, composta de requisição e resposta. [Seebach 2008]. Como dito antes, o OSRM transmite informações por um servidor sem estado,
41
onde o lado cliente apenas faz a requisição via HTTP, passando como informação na URL as localizações geográficas de cada ponto turístico desejado para que possa ser processada pelo motor de busca e o mesmo retorne a informação da rota caso exista, caso não exista o retorno é uma resposta negativa. A figura 17 mostra um exemplo de uma URL enviada ao OSRM para que seja gerada a rota entre dois pontos, informando além dos pontos geográficos, o formato de resposta desejado, a não necessidade de uma rota alternativa e a necessidade de instruções para esta rota.
Figura 17: Exemplo de requisição para geração de rota entre dois pontos utilizada no OSRM. Após obtida a resposta, caso seja uma resposta positiva de que existe uma rota entre os pontos solicitados, esta resposta é interpretada pela API desenvolvida neste trabalho e desenhada sobre a camada georreferenciada do mapa.
3.6
Mapnik
O Mapnik é um Kit de ferramentas utilizada para o desenvolvimento de aplicações de mapeamento. Capaz de suportar uma grande variedade de formatos de dados geoespaciais e oferecer opções flexíveis de estilo para a concepção de variados tipos de mapas, como por exemplo, mapas meteorológicos, hidrográficos e mapas rodoviários, entre outros. [Pavlenko 2013]. O Mapnik, neste trabalho é utilizado para renderizar o mapa com dados de redes rodoviárias providos pelo projeto OpenStreetMap. Ele é capaz de gerar um formato gráfico (PNG, JPEG, SVG e PDF) da informação contida nos dados, para construir a visualização do mapa. Esta foi a ferramenta de renderização de mapa escolhida para ser utilizada por conta de seu bom funcionamento com os dados providos pelo projeto OpenStreetMap, além de já ser a solução utilizada no ambiente mobile para a aplicação TourplanB, o que provê um bom conhecimento da ferramenta por parte da empresa. Mapas são (principalmente), compostos por um número arbitrário de camadas. Cada camada tem sua fonte de dados que é responsável por prover a informação
42
de sua geometria, informação fornecida por uma leitura e análise dos dados. Para renderizar os dados, pode ser atribuído um ou vários estilos para cada camada. O estilo, define como os objetos em uma camada são renderizados. Um estilo contém uma ou mais regras que podem opcionalmente restringir a exibição de um subconjunto de objetos fornecidos pela fonte de dados, por exemplo, para exibir apenas objetos que possuem um conjunto de atributos específicos. [Pavlenko 2014]. Nas figuras 18 e 19 são mostrados dois mapas da área central de Seul, com estilos diferentes gerados pelo Mapnik. A figura 18 mostra um mapa no estilo padrão utilizado neste trabalho e a figura 19 traz o estilo padrão utilizado pelo OpenStreetMap. O Mapnik é então, a ferramenta utilizada para prover a renderização e exibição dos objetos contidos no mapa utilizado por este trabalho.
Figura 18: Mapa gerado pelo Mapnik da área central de Seul no estilo utilizado por este trabalho.
43
Figura 19: Mapa gerado pelo Mapnik da área central de Seul no estilo utilizado pelo OpenStreetMap.
3.7
API HotelsCombined
A HotelsCombined é uma empresa que provê um serviço de pesquisa e comparação de preços de acomodação para todas as áreas do planeta, possuindo uma vasta lista de sites e agências de viagem como colaboradores para realizar tal pesquisa. [Hotels Combined 2014]. A HotelsCombined, provê uma API para afiliados, que possibilita realizar requisições entre servidores de acordo com uma dada posição geográfica e um limite de área desejada ou pelo nome do hotel desejado. A API provê como resposta a estas requisições, informações sobre todos os hotéis existentes na área limite, ou informação sobre o hotel desejado, assim como preços e disponibilidade fornecidos pelos diferentes sites e agências de viagem colaboradores. [Hotels Combined 2014]. Desta forma a API do HotelsCombined é usada neste trabalho para exibir e extrair informações sobre atrações do tipo acomodação para o usuário e popular a base de dados com informação dos hotéis selecionados quando esta se faz necessária.
44
4
ENGENHARIA DE REQUISITOS
A seguir é descrita a engenharia de requisitos deste trabalho. Primeiramente é definido o minimundo onde a solução irá atuar, em seguida são definidos os requisitos funcionais e não funcionais do sistema, e detalhadas suas funções e restrições. Em seguida é apresentada a descrição dos atores que interagem com o sistema, e então é apresentada uma descrição e análise dos casos de uso especificados para o sistema. De acordo com [Pressman 2011], a engenharia de requisitos é uma ação de engenharia de software importante que se inicia durante a atividade de comunicação e continua na de modelagem, e deve ser adaptada às necessidades do processo, do projeto, do produto e das pessoas que estão realizando o trabalho. Neste capítulo são definidas as funcionalidades e restrições necessárias para implementação da solução de roteamento a ser adicionada ao Tourplanb, sendo assim, apenas requisitos funcionais, requisitos não funcionais e casos de uso pertinentes à solução de roteamento são descritas neste capítulo. As descrições de requisitos funcionais, não funcionais e casos de uso, assim como os diagramas a eles relacionados, e relacionados ao trabalho como um todo, são desenvolvidos de acordo com a Linguagem de Modelagem Unificada (UML). De acordo com [Bezerra 2006], a UML trata-se de uma linguagem-padrão cujo objetivo é visualizar, especificar, construir e documentar todas as informações necessárias para o desenvolvimento de modelos de sistemas complexos de software orientado a objetos.
4.1
Minimundo
Este projeto tem por objetivo aprimorar a experiência do usuário no cenário TourPlanB, descrito anteriormente, onde foi dedicado oito meses de trabalho junto a empresa que o mantém, por parte do autor do trabalho durante intercambio estudantil na Coréia do Sul.
45
Além de aprimorar o planejador de viagem TourplanB, o produto do trabalho poderá ser incorporado em outras soluções que necessitem de geração de rota, utilizando da API desenvolvida, para que não seja mais necessário a utilização de serviços de terceiros, ou pela impossibilidade por motivos de bloqueios governamentais como já citado anteriormente, ou por motivos financeiros. A solução será responsável por criar em camadas georreferenciadas, ou seja, mapas, a rota entre os pontos desejados de forma rápida e simples.
4.2
Requisitos Funcionais
Segundo [Pressman 2011], requisitos funcionais são funções de um sistema de software ou seu componente. Sendo função descrita como um conjunto de entradas, seu comportamento e sua saída. As funcionalidades propostas são descritas através dos requisitos funcionais na Tabela 1.
Requisito RF1 RF2
RF3
4.3
Tabela 1: Requisitos Funcionais. Descrição Os usuários deverão ser autenticados através de login e senha. Manter plano Usuário autenticado tem opção de criar, salvar, editar, deletar e publicar em redes sociais plano de viagem gerado. Manter atração Usuário autenticado tem a opção de adicionar, editar e deletar atrações do sistema. Nome Efetuar login
Requisitos Não Funcionais
De acordo com [Pressman 2011], os requisitos não funcionais são os requisitos relacionados ao uso da aplicação, relacionados a desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenabilidade e tecnologias envolvidas. As restrições do sistema são especificadas através dos requisitos não funcionais descritos abaixo:
46
• O tempo máximo de resposta de uma query para a seleção do melhor caminho deve ser de um segundo. • O sistema deverá rodar em qualquer navegador desktop. • O sistema deverá se comunicar com o MySQL.
4.4
Descrição de Atores
Na terminologia da UML, qualquer elemento externo que interage com o sistema é denominado ator [Bezerra 2006]. • Usuário: Possui a função de selecionar tipo de atração, adicionar atração ao plano, invocar geração de rota, e caso esteja autenticado, salvar plano criado, adicionar nova atração, que não seja do tipo acomodação, e manter atrações adicionadas por ele próprio. • Administrador: Realiza todas as funções do usuário, com a diferença de poder manter atrações adicionadas por qualquer usuário. • HotelsCombined API: Possui a função de fornecer dados de atrações do tipo acomodação baseado em dados retornados pela API do HotelsCombined. • OSRM: Possui a função de calcular rota entre atrações adicionadas ao plano.
4.5
Casos de Uso
De acordo com [Bezerra 2006], um caso de uso é uma especificação de uma sequência de interações entre um sistema e os agentes externos que utilizam esse sistema. Um caso de uso deve definir o uso de uma parte da funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos desse sistema.
4.5.1
Diagrama de Casos de Uso
Casos de uso envolvidos: efetuar login, gerar rota, manter plano de viagem, manter atrações e adicionar acomodações. A figura 20, apresenta o diagrama de casos de uso do sistema.
47
Atores do sistema: Usuário, Administrador, HostelsCombined API, OSRM.
Figura 20: Diagrama de Casos de Uso
4.5.2
Descrição de Casos de Uso
Nesta fase de implementação do sistema, os casos de uso pertinentes a geração de rota são aqueles ligados a criação e alteração do plano de viagem. A descrição destes, segue nas tabelas 2, 3, 4, 5, 6 e 7.
48
Tabela 2: Caso de Uso: Criar Plano de Viagem CSU1: Criar Plano de Viagem Esse caso de uso dá início a criação do plano de viagem. Atores: Usuário, Administrator Pré-Condição: Não existe pré-condição para esse caso de uso. Pós-condição: Um novo plano de viagem começa a ser criado, com um novo dia adicionado ao plano de viagem. Fluxo Principal: 1. Este caso se inicia quando o ator seleciona a opção de criar novo plano de viagem. 2. O ator determina qual a data de inicio e data de fim do plano de viagem. 3. Aciona caso de uso Adicionar Atração ao Plano de Viagem, para cada dia pertencente ao plano de viagem. 4. Este caso de uso utiliza o CSU2.
Tabela 3: Caso de Uso: Adicionar Atração ao Plano de Viagem CSU2: Adicionar Atração ao Plano de Viagem Esse caso de uso adiciona a atração a ser visitada e ao plano de viagem do ator. Atores: Usuário, Administrator Pré-Condição: Não existe pré-condição para esse caso de uso. Pós-condição: Atração selecionada é adicionada à lista de atrações para o plano de viagem. Fluxo Principal: 1. Este caso se inicia após CSU1, quando o ator seleciona uma atração para ser adicionada ao seu plano de viagem. 2. Pode acionar caso de uso Gerar Rota. 3. Pode adicionar caso de uso Selecionar Tipo de Atração. 4. Este caso de uso pode utilizar o CSU3 e CSU4. 5. Este caso de uso se encerra.
49
Tabela 4: Caso de Uso: Gerar Rota CSU3: Gerar Rota Esse caso de uso gera rota entre as atrações selecionadas pelo ator e adicionadas ao seu plano de viagem. Atores: OSRM Pré-Condição: Ao menos duas atrações adicionadas ao plano de viagem. Pós-condição: Exibição de rota otimizada, caso exista, entre as atrações adicionadas ao plano de viagem. Fluxo Principal: 1. Este caso se inicia após CSU1, quando o ator seleciona uma atração para ser adicionada ao seu plano de viagem. 2. Este caso é chamado automaticamente pelo CSU2, quando este possui ao menos duas atrações adicionadas ao plano de viagem do Usuário. 3. Faz chamada uma cross-domain ao servidor contendo o motor de roteamento. 4. Adicionar nova camada ao mapa contendo rota. 5. Este caso de uso se encerra. Fluxo de Exceção: 1. Este caso se inicia após CSU1, quando o ator seleciona uma atração para ser adicionada ao seu plano de viagem. 2. Este caso é chamado automaticamente pelo CSU2, quando este possui ao menos duas atrações adicionadas ao plano de viagem do Usuário. 3. Faz chamada uma cross-domain ao servidor contendo o motor de roteamento. 4. Mostra mensagem de que não existe uma rota entre os pontos desejados. 5. Este caso de uso se encerra.
50
Tabela 5: Caso de Uso: Selecionar Tipo de Atração CSU4: Selecionar Tipo de Atração Esse caso de uso diferencia atrações que estão sendo exibidas no mapa. Atores: OSRM Pré-Condição: Não existe pré-condição para esse caso de uso. Pós-condição: Exibe no mapa apenas os tipos de atrações selecionadas. Fluxo Principal: 1. Este caso é chamado quando o ator define qual tipo de atração deseja visualizar. 2. Remove marcação de todas atrações que não condizerem com o tipo selecionado pelo ator. 3. Se o tipo de atração selecionada for acomodação, este caso de uso aciona caso de uso Adicionar Acomodação. 4. Este caso de uso pode utilizar CSU5. 5. Este caso de uso se encerra.
Tabela 6: Caso de Uso: Adicionar Acomodação CSU5: Adicionar Acomodação Esse caso de uso adiciona atrações do tipo acomodação ao mapa e quando necessário ao banco de dados. Atores: Usuário, HotelsCombined API Pré-Condição: Não existe pré-condição para esse caso de uso. Pós-condição: Exibe no mapa apenas atrações do tipo acomodação, e a adiciona ao banco de dados caso selecionada. Fluxo Principal: 1. Este caso é chamado quando o ator escolhe exibir apenas atrações do tipo acomodação. 2. Faz uma chamada cross-domain à API do HotelsCombined. 3. Exibe no mapa marcadores contendo informação de todas as acomodações numa área de 20 milhas. 4. Cria um registro contendo os detalhes da acomodação selecionada no banco de dados, caso a mesma não exista. 5. Este caso de uso se encerra
51
Tabela 7: Caso de Uso: Salvar Plano CSU6: Salvar Plano Esse caso de uso armazena o plano de viagem definido pelo ator na base de dados. Atores: Usuário Pré-Condição: O ator deverá estar autenticado no sistema. Pós-condição: Cria-se na base de dados um registro contendo o plano de viagem do ator. Fluxo Principal: 1. Este caso de se inicia quando o ator solicita o salvamento de seu plano de viagem. 2. Cria um registro contendo os detalhes do plano de viagem do ator na base de dados. 3. Este caso de uso se encerra Fluxo de Exceção: 1. Este caso de se inicia quando o ator solicita o salvamento de seu plano de viagem. 2. Informa ao ator que não foi possível realizar a operação. 3. Este caso de uso se encerra
52
5
ESPECIFICAÇÃO DE ANÁLISE
Nas próximas seções são detalhados os componentes da especificação de análise, diagrama de classes e diagrama de sequência, como feito no capítulo anterior, a ênfase maior é voltada para a geração de rota. De acordo com [Pressman 2011], o intuito do modelo de análise é fornecer uma descrição dos domínios de informação, funcional e comportamental necessários para um sistema baseado em computadores
5.1
Diagrama de Classes
O diagrama de classes é um tipo de diagrama de estrutura estática que descreve a estrutura de um sistema representando suas classes de sistema, as relações entre as classes, seus atributos e seus métodos [Bezerra 2006]. A figura 21 apresenta o diagrama de classes desenvolvido para a solução proposta por este trabalho.
53
Figura 21: Diagrama de Classes.
54
5.2
Diagrama de Sequência
O diagrama de sequência é um diagrama de iteração utilizado para apresentar as interações entre objetos de um sistema em ordem cronológica, através de elementos gráficos [Bezerra 2006]. A figura 22, apresenta o diagrama de sequência do caso de uso adicionar atração ao plano de viagem
55
Figura 22: Diagrama de Sequência.
56
6
PROJETO DE SOFTWARE
Nas próximas seções serão detalhados os componentes pertinentes a implementação da API e a geração de rota que deve ser proporcionada pela API desenvolvida, assim como o detalhamento do fluxo de dados utilizado para realizar a geração da rota.
6.1
Arquitetura de Software
De acordo com [Falbo 2011], a arquitetura de um software consiste na definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares, além disso a arquitetura define os elementos de software (ou módulos) e envolve informações sobre como estes elementos se relacionam uns com os outros. Segundo [Falbo 2011], o tipo da arquitetura do sistema é definido de acordo com a classe de sistema a ser desenvolvido, no caso deste trabalho, o sistema se encaixa na classe de sistemas de informação web, ou uma aplicação web.
6.1.1
Tipos de Arquitetura de Software
[Falbo 2011] define a arquitetura cliente-servidor, como o estilo de arquitetural típico para sistemas de informação, sobretudo para sistemas de médio e grande porte. Nessa arquitetura, componentes assumem os papéis de clientes e servidores de serviços. Um servidor é um componente que fica em estado de espera, aguardando a solicitação de um serviço por um ou mais clientes. Os clientes, por sua vez, podem ser vistos como processos independentes, ou seja, a execução de seu processo não interfere em outros processos.
57
6.1.1.1
Arquitetura Cliente-servidor em Duas Camadas
De acordo com [Falbo 2011], um uso bastante comum de arquiteturas clienteservidor consiste em explorar o poder dos computadores pessoais para gerenciar interfaces gráficas com o usuário, mantendo os serviços e dados do negócio em servidores. Sua forma mais simples, envolve múltiplos clientes fazendo requisições para um único servidor, como na figura 23, o que caracteriza uma arquitetura em duas camadas.
Figura 23: Arquitetura cliente-servidor em duas camadas. [Falbo 2011]
6.1.1.2
Arquitetura Cliente-servidor em Três Camadas
A arquitetura utilizada por este projeto, é conhecida como arquitetura cliente-servidor em três camadas, onde máquinas-clientes estão conectadas via rede a um servidor de aplicação, que por sua vez, se comunica com um servidor de dados. [Falbo 2011] A figura 24, mostra uma ilustração de uma arquitetura cliente-servidor em três camadas.
58
Figura 24: Arquitetura cliente-servidor em três camadas. [Falbo 2011] Segundo [Falbo 2011], esta arquitetura pode ser, ainda, estendida para n camadas, com a introdução de outros servidores que serão responsáveis por fornecer outros serviços, enquanto algum servidor se comporta como cliente consumindo este serviço. Isto pode ser visto no projeto arquitetural deste trabalho.
6.1.2
Arquitetura da Aplicação TourplanB
A arquitetura utilizada na aplicação TourplanB, é a arquitetura cliente-servidor em três camadas estendida, onde alguns servidores se comportam como clientes consumindo serviços de outros servidores. A figura 25, traz a arquitetura geral da aplicação TourplanB, onde são identificados pelos números de 1 a 7 o cliente e os servidores utilizados, além do fluxo de dados, representado pela direção das setas: 1. Cliente. 2. Servidor Web Apache. 3. Servidor de banco de dados TourplanB. 4. Servidor Mapnik. 5. Servidor de banco de dados utilizado pelo Mapnik. 6. Servidor do motor de geração de rota OSRM. 7. Servidor pertencente à empresa HotelsCombined.
59
Figura 25: Arquitetura da aplicação TourplanB. 6.1.2.1
Cliente
O cliente é responsável por enviar as requisições para a aplicação TourplanB, o cliente pode ser qualquer navegador web para desktop, visto que a aplicação não fornece suporte para navegadores mobile.
6.1.2.2
Servidor Web Apache
O servidor web Apache é responsável por hospedar a aplicação TourplanB juntamente com a API desenvolvida por este trabalho. O servidor web Apache, é o servidor utilizado neste trabalho, pois além de se tratar de uma opção da empresa, o Apache é o servidor web mais utilizado do mundo [Netcraft 2015], o que significa de certa forma que, se trata de um servidor confiável além de ser um software de código livre. [Foundation 2014] A partir deste servidor é realizada a comunicação com o servidor de banco de dados da aplicação TourplanB, a comunicação com o servidor Mapnik, para a renderização de imagens dos mapas quando necessário, a comunicação com o servidor OSRM, para a geração de rotas quando requisitadas, geração de rotas requisita e interpretada por meio da API desenvolvida neste trabalho, e a comunicação com a API
60
fornecida por HotelsCombined, para obtenção de informação sobre hospedagens.
6.1.2.3
Servidor de Banco de Dados TourplanB
O servidor de banco de dados, é o servidor responsável por armazenar todos os dados da aplicação TourplanB em um SGBD MySQL, dados que incluem usuários, atrações, planos de viagem e etc. O uso do MySQL neste caso, se trata de uma escolha da empresa, e também pelo fato de o MySQL ser o banco de dados de código livre mais utilizado do mundo. [Oracle 2015] A comunicação com este servidor se dá somente por meio do servidor web Apache, sendo que nenhum outro servidor, ou cliente possui acesso direto a este servidor.
6.1.2.4
Servidor Mapnik
O servidor Mapnik, é o servidor onde estará o toolkit de renderização de mapas Mapnik, é requisitado pelo servidor web Apache quando se faz necessário gerar uma imagem em formato gráfico para determinada área para que seja possível construir a visualização completa do mapa. Para este trabalho foi utilizado um servidor rodando Linux Ubuntu Server 14.04 LTS. Este sistema operacional foi escolhido por conta de minha maior familiaridade com servidores rodando Linux, mas nada impede que o Mapnik seja executado em outras plataformas como Windows ou MAC OS, pois o Mapnik também possui suporte para estas plataformas. [OSM Fondation 2014] O Mapnik é mantido em um servidor separado por opção da empresa, para que possa ser utilizado em outros serviços além da aplicação TourplanB.
6.1.2.5
Servidor de Banco de Dados utilizado pelo Mapnik
O servidor de banco de dados utilizado pelo Mapnik, possui um SGBD PostgreSQL, onde é armazenado dados de todo o planeta fornecidos pelo projeto OpenStreetMap. [OSM Fondation 2014] Estes dados são utilizados somente pelo servidor Mapnik diretamente, quando se faz necessária a geração de imagem em formato gráfico para alguma área, onde o Mapnik requisita a este servidor apenas os dados ne-
61
cessários para renderizar imagens com o estilo e área definidos. O SGBD PostgreSQL, foi o SGBD escolhido para este servidor, pois segundo [Pavlenko 2013], o Mapnik possui um maior suporte a este SGBD e possui inclusive uma ferramenta própria para o carregamento da informação disponibilizada pelo OpenStreetMap, de forma preparada para ser utilizada pelo Mapnik. O uso do PostgreSQL em um servidor separado do Mapnik, se dá pelo fato de o montante de informação de todo o planeta chegar próximo de 250 gigabytes, de forma que afetaria a eficiência da geração de imagens caso o gerenciamento dos dados e a renderização da imagem fossem feitos em um mesmo servidor. Outra opção possível seria a comunicação direta com os servidores do projeto OpenStreetMap, porém não utilizada por opção da empresa.
6.1.2.6
Servidor do Motor de Geração de Rota OSRM
O servidor do motor de geração de rota OSRM, é o servidor responsável por hospedar a aplicação do motor de geração de rotas OSRM, responsável por gerar as rotas quando requisitado pela API desenvolvida neste trabalho. O OSRM utiliza os dados fornecidos pelo projeto OpenStreetMap para gerar rotas, assim como o toolkit de renderização de mapas Mapnik utiliza estes dados para realizar a renderização de mapas. A diferença é que para que o OSRM seja capaz de gerar rotas é necessário realizar o pré-processamento destes dados, pois segundo [Luxen e Vetter 2011], o OSRM utiliza o algoritmo de Contraction Hierarchies, salvando os dados gerados durante o pré-processamento no disco rígido do servidor. Para que seja possível alcançar a performance desejada, o OSRM assim que iniciado, carrega os dados necessários para a geração de rota (dados gerados durante o pré-processamento) em memória no servidor e os mantém desta forma, dispensando o uso de SGBDs para realizar o armazenamento dos dados. [Luxen 2014] No caso deste trabalho, o servidor utilizado contava com 128 gigabytes de memória RAM e 1 terabyte de disco rígido SSD para que fosse possível carregar os dados do planeta inteiro utilizando a combinação memória RAM e swap, utilizado para simular uma maior quantidade de memória RAM.
62
6.1.2.7
Servidor Pertencente à Empresa HotelsCombined
O servidor pertencente à empresa HotelsCombined é o sistema externo que será consultado por meio de API fornecida pela própria HotelsCombined, como detalhado na seção 5.7, a fim de obter informações sobre hospedagens em uma determinada área. A requisição é feita pelo servidor web Apache, que obtém uma resposta contendo os dados referentes as opções de hospedagem da área requisitada para que possam ser georreferenciadas no mapa pela aplicação TourplanB e mostradas para o usuário.
6.2
Modelo de Dados da aplicação TourplanB
O modelo de dados utilizado pela aplicação TourplanB nesta solução é representado pelo Diagrama Entidade-Relacionamento (DER) descrito na figura 26. Nenhuma modificação foi necessária em relação ao modelo utilizado pela aplicação TourplanB. Note que, o esquema de persistência da aplicação TourplanB não é definido neste trabalho, e sim pela empresa detentora da aplicação, visto que as rotas não são persistidas no banco de dados sendo apenas necessária a informação pertinente a geolocalização das atrações para que a rota seja gerada. As rotas geradas, não são persistidas no banco de dados pelos seguintes motivos: 1) o tempo de geração de rota é pequeno, de forma que não é necessário armazená-la no banco de dados, sendo melhor para a performance geral da aplicação gerar a rota sempre que o plano de viagem for aberto ou modificado. 2) a direção das ruas e avenidas podem mudar, algumas ruas ou avenidas podem ser destruídas e outras serem construídas e, por isso deve-se manter sempre a rota mais atualizada disponível para o usuário. Desta forma, é melhor sempre gerar a rota durante a visualização, edição ou produção do plano de viagem, visto que para ter sempre a rota atualizada basta apenas atualizar os dados utilizados pelo motor de geração de rotas não havendo qualquer modificação no banco de dados. Já a persistência realizada no servidor de banco de dados utilizado pelo Mapnik, não será descrita neste trabalho, pois trata-se de um padrão definido pelos desenvolvedores do Mapnik e a forma como é feita esta persistência não é pertinente a este projeto, visto que a aplicação apenas utiliza os serviços proporcionados pelo Mapnik como uma aplicação Cliente.
63
Figura 26: Diagrama de Entidades e Relacionamentos do banco de dados utilizado pela aplicação TourplanB.
64
6.3
Diagrama de Implantação
Segundo [Bezerra 2006], o diagrama de implantação é utilizado para representar a topologia física do sistema, ou seja, é o diagrama utilizado para apresentar o mapeamento entre os componentes de software e o hardware utilizado pelo sistema. A figura 27, mostra o diagrama de implantação que representa a modelagem da arquitetura física do sistema TourplanB, onde é possível identificar todos os servidores citados na seção 6.1.2.
Figura 27: Diagrama de Implantação da aplicação TourplanB.
65
6.4
Diagrama de Componentes
De acordo com [Bezerra 2006], o diagrama de componentes é utilizado para representar como os componentes estão ligados entre si. A figura 28, mostra o diagrama de componentes pertinentes a aplicação TourplanB.
66
Figura 28: Diagrama de componentes referente à aplicação TourplanB.
67
6.5
Segurança
Este trabalho não possui por finalidade discutir ou definir quais métodos de segurança devem ser aplicados aos servidores. Sendo assim, será apenas descrito o que está sendo feito atualmente pela empresa em questão quanto à segurança dos servidores. Todas as informações descritas a seguir foram passadas pelo chefe da equipe de pesquisa e desenvolvimento da empresa Dabeeo1 , Jaewook Ahn, em Abril de 2015. São utilizadas técnicas de segurança apenas no servidor Web Apache, onde está hospedada a aplicação TourplanB, pois os servidores OSRM e Mapnik não possuem informação de grande valor, visto que todos os dados utilizados por estes servidores estão disponíveis para qualquer pessoa na página do projeto OpenStreetMap. Sendo assim, a comunicação entre o servidor web Apache e estes servidores se dá via HTTP.
6.5.1
Segurança contra ataques DDoS
O ataque DDoS (distributed denial-of-service), ou ataque de negação de serviço, é um ataque que tem por fim tornar os recursos de um sistema indisponível para seus utilizadores. É feito uma sobrecarga no servidor em que a aplicação está hospedada, assim são consumidos todos seus recursos (memória, processamento por exemplo), de forma que o servidor não é mais capaz de fornecer seu serviço. [Tanenbaum 2003] Os servidores Web Apache e Servidor de Banco de dados TourplanB, estão hospedados com a empresa parceira Hanbiro2 , que possui um sistema de IPS (Intrusion Prevention Systems) para realizar a segurança contra ataques DDoS, e outros tipos de ataques. O sistema IPS que a Hanbiro oferece possui como principal função identificar atividades maliciosas, fazer o log destas atividades e realizar o bloqueio ou parar estas atividades, garantindo assim que os servidores continuem a fornecer seus serviços. [Hanbiro 2015] Os outros servidores estão hospedados dentro da própria Dabeeo, e por suas funcionalidades estarem ainda em fase de testes, não possuem nenhum tipo sistema de segurança como o aplicado pela Hanbiro, por exemplo.
1 Website
empresa Dabeeo. de empresa parceira responsável pela hospedagem da aplicação TourplanB. 2 Website
68
7
API EM JAVASCRIPT PARA GERAÇÃO DE ROTA COM OSRM NO AMBIENTE TOURPLANB
A API para geração de rota, foi desenvolvida usando apenas a linguagem JavaScript, com foco voltado exclusivamente para browsers desktop. Foi testado em sua maior parte no Google Chrome versão 41, Internet Explorer 11 e Safari versão 8. A interface com o usuário utilizada para o primeiro protótipo se trata de uma interface simples, que possui apenas o mapa gerado pelo Mapnik, mapa este com padrão definido pela empresa Dabeeo, dois campos de entrada de texto, para que seja digitado o nome dos locais desejados, um botão para realizar a chamada da função de roteamento e dois botões para utilização de zoom no mapa. Já para o segundo protótipo foi utilizado a própria interface da aplicação TourplanB, onde a função de geração de rota é chamada quando existem mais de duas atrações no dia do plano de viagem. O desenvolvimento do primeiro protótipo e do segundo protótipo, assim como as decisões de implementação são discutidos nas seções seguintes.
7.1
Primeiro Protótipo
O primeiro protótipo consiste em desenvolver a API, que será responsável pela comunicação com o servidor OSRM, a interpretação dos dados recebidos como resposta, e a plotagem da rota no mapa. Neste protótipo, o usuário é responsável por entrar com o nome de duas atrações, lugares ou cidades, para que seja gerada a rota entre os dois pontos selecionados, neste caso a posição geográfica destes dois pontos é fornecida pelo projeto OpenS-
69
treetMap. As posições geográficas são recebidas através de uma chamada à API disponibilizada pelo projeto OpenStreetMap. Esta chamada, acontece apenas no primeiro protótipo e é descartada para o segundo protótipo, pois no segundo protótipo são utilizados dados provenientes do banco de dados TourplanB. Após obter as posições geografias dos pontos desejados, é montada a URL, como mostrada na figura 17, que será utilizada para realizar a requisição de rota ao servidor OSRM. Após obter a resposta, em formato JSON, caso esta seja positiva e exista uma rota entre os pontos desejados, é necessário realizar a interpretação da informação recebida e plotar a rota encontrada pelo OSRM. As figuras 29 e 30 mostram uma ilustração da rota entre a Torre Eiffel e o Museu do Louvre, ambos em Paris, e uma rota entre Lisboa, em Portugal, e Moscou na Rússia, ambas as rotas plotadas no mapa pelo primeiro protótipo utilizando a API desenvolvida baseada nas técnicas e os passos descritos acima.
70
Figura 29: Rota entre Torre Eiffel e Museu do Louvre plotada pelo primeiro protótipo.
71
Figura 30: Rota entre Lisboa e Moscou plotada pelo primeiro protótipo.
72
7.2
Segundo Protótipo
Após o desenvolvimento do primeiro protótipo, o segundo protótipo tratou-se apenas da integração da API desenvolvida ao aplicativo TourplanB, pois a princípio o mesmo utiliza os serviços de mapa do Google, que deve deixar de ser utilizado por conta dos bloqueios em alguns mercados alvo. Durante a integração a maior dificuldade ficou por conta da modificação das funções que faziam uso de serviços de georreferenciamento do mapa do Google, que foram resolvidas com o uso da biblioteca jQuery e a biblioteca de mapa pertencente à Dabeeo. As figuras 31 e 32, mostram rotas geradas pelo segundo protótipo durante a criação de planos de viagem. A figura 31 traz um plano de viagem simples dentro de Seul, na Coréia do Sul, que tem seu início no parque Sejongno, parte do museu pertencente ao parque, faz uma segunda parada em frente aos portões do palácio que pertenceu ao rei Sejong, uma terceira parada em um fast-food coreano, Lotteria, e com chegada a uma guesthouse próximo ao Lotteria. Neste exemplo, diferentemente do primeiro protótipo, a rota possui quatro pontos e não apenas dois. A figura 32, ilustra uma rota em mais de um país, são eles Vietnã, Camboja e Tailândia. Um exemplo com quatro pontos e distâncias maiores, se comparado com o exemplo da figura 31. Ambos os protótipos geram rotas apenas para carro, pois para que seja possível gerar a rota para caminhada ou bicicleta, seria necessária a utilização de outro servidor OSRM, configurado para gerar o tipo de rota desejado. Assim a comunicação se daria com o servidor que gera a rota para o perfil desejado, seja um perfil de rotas para carro, caminhada, bicicleta, etc.
73
Figura 31: Rota dentro de Seoul plotada pelo segundo protótipo.
74
Figura 32: Rota passando por Hanoi e Nha Trang, no Vietnã, Siem Reap, no Camboja e terminando em Phuket, na Tailândia plotada pelo segundo protótipo.
75
7.2.1
Tipos de Atração
Nas figuras 31 e 32, existem diferentes tipos de marcadores no mapa. Estes marcadores são utilizados para especificar a posição geográfica e qual o tipo de atração existe naquele ponto. O tipo de atração e marcador utilizado no segundo protótipo são descritos na tabela 8. Tabela 8: Marcadores e tipos de atrações. Marcador
Tipo de atração Atrações do tipo shopping, podem ser lojas dos mais variados tipos ou centros comerciais. Atrações do tipo cultura, incluindo galerias, museus, teatros, shows, exibições, cultura populares, e entretenimento em geral. Atrações do tipo história, incluído vilas históricas, centros arquitetônicos, etc. Atrações do tipo natureza, estas atrações podem se tratar de parques, montanhas, praias, lagos, rio, entre outros. Atrações do tipo experiência, nesta categoria se enquadram festivais, eventos em geral, parques temáticos, camping e etc. Atrações do tipo restaurante, representa todo tipo de local onde é vendido comida como cafés, bares, restaurantes, fast-foods, e etc. Atrações do tipo hospedagem, pode ser qualquer tipo de hospedagem, hotel, resort, albergues, etc. Atrações do tipo outros, quando a atração não pode ser encaixada em nenhum dos grupos anteriores, é utilizado este marcador para representar o local.
76
8
CONCLUSÃO
8.1
Considerações Finais
Este projeto teve início durante a realização de estágio em um intercâmbio na Coréia do Sul. Teve por objetivo a proposta de melhoria ao sistema já existente da empresa na qual o estágio foi realizado, o sistema TourplanB da empresa Dabeeo, baseado na expectativa de introdução do produto em mercados com várias limitações políticas ou legais, como o mercado Chinês, o que acaba por ocasionar vários bloqueios a diversas empresas mundialmente conhecidas e dos serviços por elas fornecidos. A ideia de oferecer rota em planos de viagens, surgiu da intenção de unificar um guia turístico a um GPS em um planejador de viagens, onde o usuário fosse capaz de obter informações sobre o local desejado e ao mesmo tempo ter a possibilidade de obter uma rota otimizada para realizar todos os seus desejos de viagem, visitando todos os pontos incluídos em seu plano de viagem. Para tanto, foram realizadas várias pesquisas sobre geração de rota, georreferenciamento, geração de mapas e sobre o próprio ambiente TourplanB, na expectativa de atender todos os requisitos e ideais pregados pela empresa detentora do serviço. O projeto foi desenvolvido integralmente utilizando a linguagem JavaScript, pois além de ser uma exigência da empresa, se trata de uma linguagem amplamente utilizada no desenvolvimento de sistemas web, tendo com isso um amplo suporte e com isso uma maior facilidade de desenvolvimento.
77
A implementação deste projeto foi complicada, principalmente devido ao elevado número de servidores e serviços utilizados para que fosse possível a plotagem da rota sobre a camada georreferenciada de mapa, para a visualização do usuário final. Os objetivos gerais deste projeto foram alcançados, visto que já no primeiro protótipo já é possível gerar e plotar a rota no mapa entre dois pontos, baseado apenas em sua localização geográfica. E no segundo protótipo, já é possível utilizar os artefatos desenvolvidos durante o trabalho dentro do ambiente TourplanB, alcançando totalmente os objetivos propostos. Além de terem sido utilizados todos os conhecimentos adquiridos durante o curso de Ciência da Computação, durante o desenvolvimento deste projeto, que teve uma duração de aproximadamente 18 meses, foi adquirido um vasto conhecimento de trabalho em projetos internacionais com equipe de nacionalidades diversas, a equipe desenvolvedora do sistema TourplanB.
8.2
Trabalhos Futuros
Propostas futuras baseadas no desenvolvimento deste projeto devem seguir a ideia de geração de rotas entre pontos turísticos ou pontos de interesse, em países com bloqueios políticos ou legais, porém com uma maior quantidade de opções para o usuário, como por exemplo, rotas compostas por partes de carro e partes de caminhada ou bicicleta, além de levar a proposta para o âmbito mobile, levando em consideração além das limitações impostas pelo ambiente mobile, a possibilidade de execução das rotinas de geração de rota sem a conexão à internet, para facilitar o seu uso por parte dos viajantes, visto que nem sempre possuímos um plano de celular que possua internet em diversos países.
78
REFERÊNCIAS [BBC 2014]BBC. The growth of tourism - BBC. 2014. URL: http://www.bbc.co.uk/ schools/gcsebitesize/geography/tourism. Visitado em: 06/03/2015. [Bezerra 2006]BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 2. ed. [S.l.]: Elsevier Acadêmico, 2006. [Carsten 2014]CARSTEN, P. Glitch Allows Brief Access To Google In China — Now Its Blocked Again. 2014. URL: http://www.businessinsider.com/ r-after-short-revival-google-service-disruptions-in-china-return-2014-10. Visitado em: 08/12/2014. [CNA/CK 2012]CNA/CK. Asia Pacific region world’s fastest growing tourism market. 2012. URL: http://www.eturbonews.com/31732/ asia-pacific-region-worlds-fastest-growing-tourism-market. Visitado em: 06/03/2015. [CNN 2012]CNN. Chinese tourists now No. 1 in Korea. Not all are happy. 2012. URL: http://travel.cnn.com/seoul/visit/ chinese-tourists-now-no1-in-korea-124981. Visitado em: 06/03/2015. [Cormen et al. 2001]CORMEN, T. H. et al. Introduction to Algorithms. 2nd. ed. [S.l.]: McGraw-Hill Higher Education, 2001. ISBN 0070131511. [Dabeeo 2015]DABEEO. TourplanB Website. 2015. URL: www.tourplanb.com. Visitado em: 09/03/2015. [Dantzig e Ramser 1959]DANTZIG, G. B.; RAMSER, J. H. The truck dispatching problem. Management Science, v. 6, n. 1, p. 80–91, 1959. Disponível em: . [Dijkstra 1959]DIJKSTRA, E. W. A note on two problems in connexion with graphs. Numerische Mathematik, Springer-Verlag, v. 1, n. 1, p. 269–271, 1959. ISSN 0029599X. Disponível em: . [Falbo 2011]FALBO, R. de A. Projeto de Sistemas de Software - Notas de Aula. [S.l.]: UFES, 2011. URL: http://www.inf.ufes.br/~falbo/node/10. Visitado em: 23/04/2015. [Feofiloff, Kohayakawa e Wakabayashi 2001]FEOFILOFF, P.; KOHAYAKAWA, Y.; WAKABAYASHI, Y. Uma Introdução Sucinta à Teoria dos Grafos. [S.l.]: McGraw-Hill Higher Education, 2001. [Flanagan 2011]FLANAGAN, D. JavaScript: The Definitive Guide. 6. ed. Sebastopol, CA, USA: O’Reilly Media, 2011.
79
[Foundation 2014]FOUNDATION, T. A. S. Apache HTTP Server. 2014. URL: http: //httpd.apache.org/ABOUT_APACHE.html. Visitado em: 31/03/2015. [Fredman e Tarjan 1987]FREDMAN, M. L.; TARJAN, R. E. Fibonacci heaps and their uses in improved network optimization algorithms. J. ACM, ACM, New York, NY, USA, v. 34, p. 596–615, July 1987. ISSN 0004-5411. Disponível em: . [Geisberger et al. 2008]GEISBERGER, R. et al. Contraction hierarchies: Faster and simpler hierarchical routing in road networks. In: Proceedings of the 7th International Conference on Experimental Algorithms. Berlin, Heidelberg: Springer-Verlag, 2008. (WEA’08), p. 319–333. ISBN 3-540-68548-0, 978-3-540-68548-7. [Google 2014]Google. Formato do Algoritmo de polilinha codificada. 2014. URL: https://developers.google.com/maps/documentation/utilities/ polylinealgorithm. Visitado em: 09/11/2014. [Hackeloeer et al. 2014]HACKELOEER, A. et al. Georeferencing: a review of methods and applications. Annals of GIS, v. 20, n. 1, p. 61–69, 2014. [Hanbiro 2015]HANBIRO. 한비로 IPS 소개. 2015. URL: http://hanbiro.com/hosting/ ddos-outline.html. Visitado em: 17/04/2015. [Hotels Combined 2014]Hotels Combined. HotelsCombined. 2014. URL: http:// hotelscombined.com/AboutUs/AboutUs.aspx. Visitado em: 09/11/2014. [Hotels Combined 2014]Hotels Combined. HotelsCombined API Documentation. 2014. URL: http://www.evselectro.com/image/data/datasheet/a.pdf. Visitado em: 09/11/2014. [jQuery Foundation 2014]jQuery Foundation. jQuery: The Write Less, Do More, JavaScript Library. 2014. URL: http://jquery.com. Visitado em: 08/11/2014. [Lardinois 2014]LARDINOIS, F. For The Love Of Open Mapping Data. 2014. URL: http://techcrunch.com/2014/08/09/for-the-love-of-open-mapping-data/. Visitado em: 09/11/2014. [Loncham 1993]LONCHAM, J. A structured conceptual and terminological framework for software process engineering. In: Proc. of the 2nd Internationnal Conference on Software Process (ICSP 2). Berlin: IEEE Press, 1993. [Luxen 2014]LUXEN, D. Open Source Routing Machine (OSRM) Wiki. September 2014. URL: https://github.com/Project-OSRM/osrm-backend/wiki. Visitado em: 09/11/2014. [Luxen e Vetter 2011]LUXEN, D.; VETTER, C. Real-time routing with openstreetmap data. In: Proceedings of the 19th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems. New York, NY, USA: ACM, 2011. (GIS ’11, 4), p. 513–516. [Neis 2012]NEIS, P. Analyzing the contributor activity of a volunteered geographic information project — the case of openstreetmap. ISPRS International Journal of GeoInformation, v. 1, n. 2, p. 146–165, 2012.
80
[Netcraft 2015]NETCRAFT. March 2015 Web Server Survey. 2015. URL: http://news.netcraft.com/archives/category/web-server-survey/. Visitado em: 31/03/2015. [OpenStreetMap Contributors 2014]OpenStreetMap Contributors. OpenStreetMap. 2014. URL: https://www.openstreetmap.org/about. Visitado em: 08/11/2014. [Oracle 2015]ORACLE. MySQL - The world’s most popular Open Source Database. 2015. URL: http://www.oracle.com/us/products/mysql/overview/index.html. Visitado em: 23/04/2015. [OSM Fondation 2014]OSM Fondation. OSM Map On Garmin. 2014. URL: https:// wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin. Visitado em: 09/11/2014. [Pavlenko 2013]PAVLENKO, A. Mapnik. 2013. URL: http://wiki.openstreetmap. org/wiki/Mapnik. Visitado em: 09/11/2014. [Pavlenko 2014]PAVLENKO, A. Mapnik Wiki. 2014. URL: https://github.com/ mapnik/mapnik/wiki. Visitado em: 09/11/2014. [Pressman 2011]PRESSMAN, R. S. Engenharia de Software, Uma Abordagem Profissional. 7. ed. New York, NY, USA: Bookman, 2011. [Ramm 2011]RAMM, F. OpenStreetMap: Using and Enhancing the Free Map of the World. [S.l.]: UIT Cambridge, 2011. [Sedgewick e Wayne 2011]SEDGEWICK, R.; WAYNE, K. Algorithms, 4th Edition. [S.l.]: Addison-Wesley, 2011. ISBN 978-0-321-57351-3. [Seebach 2008]SEEBACH, P. The stateless state, Remembering what you were doing five minutes ago on the Web. 2008. URL: http://www.ibm.com/developerworks/ library/wa-state/wa-state-pdf.pdf. Visitado em: 09/03/2015. [Sommerville 2003]SOMMERVILLE, I. Engenharia de software. [S.l.]: Addison Wesley, 2003. ISBN 9788588639072. [Szczepanik 2011]SZCZEPANIK, G. A concepção de método cientifico para mario bunge. Revista de filosofia, Guairacá., Santa Catarina, 2011. [Tanenbaum 2003]TANENBAUM, A. S. Redes de computadores. [S.l.]: CAMPUS - RJ, 2003. ISBN 9788535211856. [TerraLab 2010]TerraLab. SIGHabitar – Cadastro Técnico Multifinalitário da Cidade Ouro Preto em Minas Gerais. 2010. URL: http://www.decom.ufop.br/terralab/sighabitar-cadastro-tecnico-multifinalitario-dacidade-ouro-preto-em-minas-gerais/. Visitado em: 10/02/2015. [TripAdvisor 2015]TRIPADVISOR. Website TripAdvisor. 2015. URL: http://www. tripadvisor.com.br/. Visitado em: 06/03/2015. [Triposo 2015]TRIPOSO. Triposo Website. 2015. URL: http://www.triposo.com/. Visitado em: 06/03/2015. [Trudeau 2001]TRUDEAU, R. J. Introduction to Graph Theory. [S.l.]: Dover Books, 2001.
81
APÊNDICE A -- Manual do Usuário
A.1
Utilizando o Sistema
Nas seções a seguir é descrito o acesso ao sistema, e a utilização das funcionalidades da aplicação TourplanB, contudo, algumas funcionalidades presentes na aplicação oficial, não estão disponíveis no segundo protótipo, visto que a ênfase dada ao segundo protótipo foi exclusivamente na geração de rota. Portanto, algumas das funcionalidades estão disponíveis apenas na aplicação TourplanB encontrada em seu website oficial. OBS.: A interface apresentada no segundo protótipo é a mesma utilizada na aplicação oficial, sendo assim, esta se apresenta apenas no idioma inglês e coreano, pois não foi feita a conversão da biblioteca para o idioma português por opção da empresa, já no caso das atrações, por conta de as informações serem obtidas do banco e dados da aplicação, estas se apresentam em sua grande maioria apenas nos idiomas coreano e mandarim (chinês).
A.1.1
Requisitos Mínimos
Para acessar a aplicação TourplanB, o usuário deve ter: •Conexão a Internet; •Web Browser – Safari, Google Chrome, Opera, Mozilla Firefox, Internet Explorer (mínimo versão 9);
82
A.1.2
Acessando o Sistema
Por opção da empresa, a geração de rota será integrada ao site oficial da aplicação TourplanB apenas após minha volta à Coréia do Sul, pois fui o responsável pelo desenvolvimento desta parte durante este trabalho. Portanto o segundo protótipo, não está hospedado no servidor oficial da aplicação, mas sim em um servidor de testes, localizado na Coréia do Sul, concedido pela empresa Dabeeo. O acesso pode ser feito por meio do seguinte endereço: http://planb.blinking.kr/lorran/ Após acessar o endereço, a tela principal da aplicação é exibida, como mostra a figura 33.
Figura 33: Página inicial da aplicação TourplanB. Na aplicação oficial, não é necessário estar logado no sistema para que seja possível começar um novo plano, porém, para o uso do segundo protótipo, o login se faz necessário. Neste caso, o usuário já está logado, sendo sempre “Lorran Pegoretti”, usuário este que foi utilizado durante a realização do desenvolvimento e todos os testes. Na aplicação oficial, para realizar o login basta clicar no link o pop-up de login seja aberto, como mostra a figura 34.
, para que
83
Figura 34: Pop-up de login da aplicação TourplanB.
Na página inicial, para começar um novo plano basta clicar no link ou clicar no link
A.1.3
em qualquer página da aplicação.
Criando um novo plano
Após clicar no link para realizar um novo plano, um pop-up é aberto para que seja selecionada a cidade onde se deseja criar o novo plano, como mostra a figura 35.
,
84
Figura 35: Pop-up para seleção de cidade. No segundo protótipo, indiferentemente da cidade selecionada pelo usuário, o mapa é sempre movido para a cidade de Seul para a criação do novo plano. Após a seleção da cidade, é aberto o pop-up para a definição das datas de início e fim da viagem, como mostra a figura 36.
85
Figura 36: Pop-up para seleção de data de início e fim de viagem. Após selecionadas as datas, é mostrado os marcadores no mapa referente a cada atração, e é então possível começar o novo plano, como mostra a figura 37.
Figura 37: Inicio de criação de plano de viagem.
86
A.1.3.1
Adicionando atração ao plano
Após a exibição dos marcadores das atrações no mapa, como mostrado na figura 37, é mostrado um pop-up sobre o marcador, quando o mouse for passado sobre o mesmo, como mostra a figura 38.
Figura 38: Pop-up de atração mostrada quando mouse for passado sobre marcador. Este pop-up, contém algumas informações adicionais sobre a atração, como seu nome, foto, quando disponível, número de curtidas, número de revisões, número de marcações como favorito e número de compartilhamentos. Quando existe foto disponível neste pop-up, é possível abrir a aba de mais informações sobre a atração ao clicá-la, quando não existe foto disponível, esta aba pode ser aberta ao clicar sobre o marcador da atração no mapa. A figura 39, mostra a aba de mais informações da atração. Nesta aba é possível escolher em qual idioma se deseja visualizar a descrição da atração, caso exista mais de um disponível, além de avaliar a atração, entre outras funções. Para adicionar a atração ao plano de viagem, basta clicar no link presente na aba de mais informações ou no pop-up aberto sobre o marcador. Assim a atração é adicionada ao plano, como mostra a figura 40.
87
Figura 39: Aba de mais informações de atração aberta.
Figura 40: Atração adicionada ao plano de viagem.
88
A.1.3.2
Gerando rotas
Após a adição de ao menos duas atrações ao plano de viagem, como mostrado na figura 41, a rota entre estas atrações é plotada no mapa, como mostra a figura 42. Sempre que as atrações pertencentes ao plano de viagem forem alteradas, a rota também é alterada, e a nova rota é plotada no mapa.
Figura 41: Duas atrações adicionadas ao plano de viagem.
89
Figura 42: Rota gerada entre duas atrações.
Lihat lebih banyak...
Comentários
