DESENVOLVIMENTODEUMAPLICATIVOANDROIDPARA ...cristina/TCC_Nardi_Augustinho.pdf · 1 1 INTRODUÇÃO Elegante,modernaeorganizada,acidadedeCuritibaéa2a cidadebrasileiramais preparadapararecebervisitantes,perdendoapenasparaoRiodeJaneiro(EXAME,2016

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁDEPARTAMENTO ACADÊMICO DE INFORMÁTICA EDEPARTAMENTO ACADÊMICO DE ELETRÔNICACURSO DE ENGENHARIA DE COMPUTAÇÃO

EDUARDO AMADEO DE CARLI NARDIJOSÉ GUILHERME AUGUSTINHO

DESENVOLVIMENTO DE UM APLICATIVO ANDROID PARAGERAÇÃO DE ITINERÁRIO TURÍSTICO EM CURITIBA

TRABALHO DE CONCLUSÃO DE CURSO

CURITIBA2018

EDUARDO AMADEO DE CARLI NARDIJOSÉ GUILHERME AUGUSTINHO

DESENVOLVIMENTO DE UM APLICATIVO ANDROID PARAGERAÇÃO DE ITINERÁRIO TURÍSTICO EM CURITIBA

Trabalho de Conclusão de Curso apresentado ao Curso deEngenharia de Computação da Universidade TecnológicaFederal do Paraná, como requisito parcial para a obtençãodo título de Engenheiro de Computação.

Orientadora: Profa Dra Ana Cristina Kochem Vendra-min

Coorientadora: Profa Dra Anelise Munaretto Fonseca

CURITIBA2018

Ministério da EducaçãoUniversidade Tecnológica Federal do Paraná

Campus Curitiba

Departamento Acadêmico de EletrônicaDepartamento Acadêmico de Informática

Curso de Engenharia de Computação

TERMO DE APROVAÇÃO

DESENVOLVIMENTO DE UM APLICATIVO ANDROID PARA GERAÇÃO DEITINERÁRIO TURÍSTICO EM CURITIBA

por

EDUARDO AMADEO DE CARLI NARDI

JOSÉ GUILHERME AUGUSTINHO

Este trabalho de conclusão de curso foi apresentado em 25 de junho de 2018 como

requisito parcial para a obtenção do grau de Engenheiro em Computação. Os

candidatos foram arguidos pela Banca Examinadora composta pelos professores

abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho

aprovado.

__________________________________Profª. Drª. Ana Cristina B. Kochem Vendramin

Orientadora

___________________________________ Profª. Drª. Anelise Munaretto Fonseca

Coorientadora

_______________________________Profº. Drº. Thiago Henrique Silva

_______________________________Profª. Drª Nádia Puchalski Kozievitch

_______________________________Profª. Drª Leyza Elmeri Baldo Dorini

AGRADECIMENTOS

Primeiramente agradecemos tanto aos nosso familiares mais próximos, como pais eirmãos, como aos mais distantes, como tios e primos. Todos ele tiveram um papel motivacionalmuito importante para que conseguíssemos realizar o trabalho de maneira contínua e saudável.Outros que também nos motivaram, como amigos e colegas, também agradecemos.

Agradecemos às professoras Dra Ana Cristina Kochem Vendramin e Dra AneliseMunaretto Fonseca, orientadora e coorientadora, pela paciência e orientação em todo oprocesso.

Agradecemos a todos os demais professores que fizeram parte da nossa formação, poistodos contribuíram de alguma maneira para todo o conhecimento que acumulamos e todas asinformações que apresentamos neste trabalho.

Eu denomino meu campo de Gestão do Conhe-cimento, mas você não pode gerenciar conhe-cimento. Ninguém pode. O que pode fazer - oque a empresa pode fazer - é gerenciar o am-biente que otimize o conhecimento. (PRUSAK,Laurence, 1997).

RESUMO

NARDI, Eduardo; AUGUSTINHO, José. Desenvolvimento de um Aplicativo Android paraGeração de Itinerário Turístico em Curitiba. 2018. 54 f. Trabalho de Conclusão de Curso –Curso de Engenharia de Computação, Universidade Tecnológica Federal do Paraná. Curitiba,2018.

O turismo destaca-se por ser uma atividade econômica bastante relevante para o crescimentodas cidades. A capital do estado do Paraná, Curitiba, oferece diversas atrações ao público, comoparques, museus, praças e locais históricos. Entretanto, para organizar um bom itinerário paraum turista, torna-se necessário considerar fatores externos como tempo de deslocamento, meiosde transporte, horários de funcionamento de cada local desejado, seus valores de admissãoe, especialmente em Curitiba, a previsão do tempo para o período da visita. Inserido nessecontexto, este projeto objetiva o desenvolvimento de um aplicativo Android para planeja-mento de um itinerário que se adeque às realidades do usuário. A aplicação será construídautilizando-se o modelo em V, dividida em 7 etapas: análise de requisitos; planejamento de altonível; planejamento detalhado; implementação; teste individual; teste de integração e testede validação. Como resultado, espera-se um aplicativo que considerando as particularidadesde cada local, as condições climáticas diárias e as entradas do usuário, gere a este uma rotaagradável.

Palavras-chave: itinerário Curitiba, turismo Curitiba, dados Curitiba.

ABSTRACT

NARDI, Eduardo; AUGUSTINHO, José. Development of an Android application to built atouristic route in Curitiba. 2018. 54 f. Trabalho de Conclusão de Curso – Curso de Engenhariade Computação, Universidade Tecnológica Federal do Paraná. Curitiba, 2018.

The tourism stands out as a very relevant economic activity for the growth of the cities.The capital of the state of Paraná, Curitiba, offers a lot of attractions to people, like parks,museums, squares, and historical places. However, to organize a good itinerary for a tourist,it is necessary to consider external factors like time of displacement, means of transport, theworking hours of each place, its values of entering ,and, especially in Curitiba, the weatherforecast of the period of the visitation. In this context, this project has the objective to developan Android application to plan an itinerary fitted in the user’s reality. The application will bebuilt following the V model, divided in seven steps: requirements analysis; high-level planning;detailed planning; implementation; individual tests; integration tests and validation tests. As aresult, it is expected an application which, through the user entries, particularities from everyplace, and daily forecast, informs a nice route for him.

Keywords: Curitiba itinerary, Curitiba tourism, Curitiba data.

LISTA DE FIGURAS

Figura 1 – Gráfico de distribuição da plataforma Android . . . . . . . . . . . . . . . . . 8Figura 2 – Camadas da arquitetura do Android . . . . . . . . . . . . . . . . . . . . . . 9Figura 3 – Tela de roteiro Visit a City . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figura 4 – Tela de roteiro Nativoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figura 5 – Uma das telas da patente da Google . . . . . . . . . . . . . . . . . . . . . . 13Figura 6 – A não linearidade do processo de Design Thinking . . . . . . . . . . . . . . . 16Figura 7 – Exemplo de um item do banco de dados . . . . . . . . . . . . . . . . . . . . 22Figura 8 – Exemplo de uma resposta à requisição de distância da API do Google . . . . . 26Figura 9 – Tela inicial do aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 10 – Telas para criação de itinerário . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 11 – Alerta solicitando confirmação do usuário para definição do local de partida . . 31Figura 12 – Telas representando o itinerário para o segundo dia de passeio . . . . . . . . . 33Figura 13 – Telas representando o itinerário para o oitavo dia de passeio . . . . . . . . . . 34Figura 14 – Tela de detalhes de um local . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 15 – Tela representando a previsão meteorológica do dia . . . . . . . . . . . . . . . 36Figura 16 – Tela representando navegação para local desejado no aplicativo do Google Maps 37Figura 17 – Alerta solicitando confirmação do usuário para restaurar última rota salva . . . 38Figura 18 – Telas com locais para conhecer . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 19 – Diagrama de casos de uso do aplicativo. . . . . . . . . . . . . . . . . . . . . 49

LISTA DE QUADROS

Quadro 1 – Distribuição da plataforma Android. . . . . . . . . . . . . . . . . . . . . 7Quadro 2 – Locais cadastrados no banco de dados e suas informações. . . . . . . . . 23Quadro 3 – Primeiro risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Quadro 4 – Segundo risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Quadro 5 – Terceiro risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Quadro 6 – Quarto risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Quadro 7 – Especificação do caso de uso "Criar itinerário" . . . . . . . . . . . . . . . 50Quadro 8 – Especificação do caso de uso "Utilizar última rota salva" . . . . . . . . . 51Quadro 9 – Especificação do caso de uso "Locais para conhecer" . . . . . . . . . . . 52Quadro 10 – Especificação do caso de uso "Apresentar itinerário criado" . . . . . . . . 53

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

CDN Content Delivery Network

FCM Firebase Cloud Messaging

GCM Google Cloud Messaging

GPS Global Positioning System

HTTP Hypertext Transfer Protocol

IBGE Instituto Brasileiro de Geografia e Estatística

ID Identity Document

IDE Integrated Development Enviroment

IDH-M Índice de Desenvolvimento Humano Municipal

JSON JavaScript Object Notation

MON Museu Oscar Niemeyer

PIB Produto Interno Bruto

URL Uniform Resource Locator

UTC Coordinated Universal Time

UTFPR Universidade Tecnológica Federal do Paraná

XML Extensible Markup Language

SUMÁRIO

1 – INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 – FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . 42.1 A Cidade de Curitiba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Turismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Plataforma Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 –REVISÃO DE LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . . 103.1 Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Estudos Sobre Patentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Mapa digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Sistema de gestão turística . . . . . . . . . . . . . . . . . . . . . . 143.2.3 Considerações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 –METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.1 Método de definição da solução . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Método de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.1 Ambiente de programação . . . . . . . . . . . . . . . . . . . . . . . 174.3.2 Linguagem de programação . . . . . . . . . . . . . . . . . . . . . . 184.3.3 Controle de versionamento . . . . . . . . . . . . . . . . . . . . . . . 184.3.4 Testes de requisições para as APIs . . . . . . . . . . . . . . . . . . 184.3.5 Plataforma de software . . . . . . . . . . . . . . . . . . . . . . . . 184.3.6 Plataforma de hardware . . . . . . . . . . . . . . . . . . . . . . . . 19

5 –DESENVOLVIMENTO DO APLICATIVO . . . . . . . . . . . . . . . . . . 205.1 Plataforma Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1.1 Motivo para escolha do Firebase . . . . . . . . . . . . . . . . . . . 205.1.2 Características e ferramentas . . . . . . . . . . . . . . . . . . . . . 205.1.3 Uso no projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.1 Estrutura dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2.2 Dados armazenados . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3 APIs utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3.1 Distance Matrix API . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3.2 Google Play Services Location . . . . . . . . . . . . . . . . . . . . . 265.3.3 Dark Sky API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 –O APLICATIVO DESCUBRA CURITIBA . . . . . . . . . . . . . . . . . . 296.1 Tela inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Criar itinerário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3 Utilizar última rota salva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.4 Locais para conhecer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 –CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

APÊNDICE A–PROJETO DE DESENVOLVIMENTO DE SOFTWARE . . . 46A.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.3 Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.4 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

1

1 INTRODUÇÃO

Elegante, moderna e organizada, a cidade de Curitiba é a 2a cidade brasileira maispreparada para receber visitantes, perdendo apenas para o Rio de Janeiro (EXAME, 2016).Dados justificados, entre outros, pelo ótimo aeroporto da cidade, sistema de transporte público,sistema de transporte particular - por meio de táxi ou veículos de aplicativos - diversidade deeventos, atendimento ao visitante, rede de hospedagem e excelentes pontos turísticos.

De acordo com o prefeito da cidade de Curitiba, Rafael Greca, ”o turismo é a atividadeque gera mais empregos e renda no mundo e, apesar de ser do setor terciário, é uma verdadeiraindústria sem chaminés” (AGÊNCIA DE NOTÍCIAS DA PREFEITURA DE CURITIBA, 2017).Assim, seguindo essa linha, pode-se perceber o quanto a prática do turismo é importante parao desenvolvimento do município.

Curitiba possui uma vasta gama de locais interessantes para visita, compreendendoparques, bosques, praças, museus, shoppings e seu setor histórico. Entre as áreas verdes,destaca-se o Jardim Botânico, importante cartão postal da cidade, repleto de jardins, fontes euma estufa de vidro, a qual abriga diversas espécies de plantas. Entre os museus, o que maisatrai turistas é o MON - Museu Oscar Niemeyer - trazendo obras com foco na arquitetura,artes visuais e design. Sua aparência em formato de um olho também chama a atenção.

Segundo estudos realizados pela Infosys, 85% das pessoas no mundo pesquisam ebuscam informações sobre suas viagens em smartphones (JORNAL DE TURISMO, 2017).Portanto, pode-se afirmar que a grande maioria dos turistas já estão habituados a utilizar essesdispositivos quando o assunto é turismo. Além disso, para 43% dos brasileiros a melhor maneirade explorar lugares desconhecidos é com o auxílio de aplicativos, de acordo com um estudorealizado pela equipe do web site Momondo, um buscador de passagens aéreas e reservasde hotéis (ROCHA, 2016). Assim, pode-se afirmar que existe um público que tem uma altaprobabilidade de se tornar usuário de um aplicativo de itinerários turísticos.

Para aproveitar bem sua estadia na cidade, nem sempre os turistas possuem um planode visitas adequado. São diversas as abordagens para a geração de um bom itinerário, nãohavendo uma ideal. Alguns fatores a serem considerados são: rotas e tempo de deslocamento,tempo de visita em cada local, seus valores de admissão, horários de funcionamento e ascondições climáticas para o período. Neste contexto, uma aplicação para dispositivos móveisque auxiliasse o turista a organizar e visualizar todas essas variáveis seria de grande utilidade,trazendo benefícios para toda a cidade.

1.1 Objetivos

Nesta seção são descritos os objetivos gerais e específicos do projeto.

Capítulo 1. INTRODUÇÃO 2

1.1.1 Objetivo Geral

O objetivo geral do presente trabalho é desenvolver um aplicativo Android que calculeum itinerário turístico para a cidade de Curitiba considerando as entradas do usuário, ascaracterísticas de cada local e as condições climáticas do dia.

1.1.2 Objetivos Específicos

Os objetivos específicos do presente trabalho são:• Avaliar quais atrações não deveriam ser visitadas devido às condições climáticas desfavo-

ráveis e encontrar alternativas viáveis para essas;• Sugerir ao usuário um tempo de permanência proporcional à extensão e relevância do

local visitado;• Agrupar as atrações em conjuntos específicos, como locais históricos, parques, museus,

gastronômicos, entre outros;• Coletar dados corretos sobre os pontos turísticos mais relevantes da cidade.

1.2 Justificativa

Segundo o Instituto Municipal de Turismo de Curitiba, o número de turistas dobrounos últimos 14 anos na cidade. Em 2003 foram recebidos 2.409.569 visitantes. Já em 2017, estenúmero subiu para 4.533.705 (AGÊNCIA DE NOTÍCIAS DA PREFEITURA DE CURITIBA,2017). Assim, disponibilizar uma ferramenta para facilitar e guiar a visita de todas essas pessoasse torna algo muito atrativo e cada dia mais necessário.

Dada a enorme quantidade de locais e rotas turísticas que a cidade de Curitibaoferece, planejar um roteiro adequado pode não ser uma tarefa tão simples. Para conhecer asparticularidades de cada local é necessário empregar tempo e dedicação em sítios especializadossobre o assunto, sejam livros, revistas, panfletos, web sites ou por meio de indicação pessoal.Após reunir todas as informações necessárias, o turista deve seguir uma grande quantidade deetapas: selecionar quais locais possui interesse, determinar se os horários de funcionamento etaxas de entrada são compatíveis com seu período de visita/verba disponível, determinar operíodo adequado para a visita, traçar a melhor rota entre os pontos desejados, considerandoas distâncias e tempos de deslocamento e, por fim, caso o turista não faça alimentação nolocal, apontar ainda os estabelecimentos próximos que possam proporcionar essas refeições(almoço, janta ou lanche).

Portanto, uma ferramenta que pudesse auxiliar na tarefa de cálculo de um itinerárioturístico seria de extrema conveniência, principalmente para os visitantes externos da cidade. Oaplicativo proposto surge como uma solução para o problema. Nele são listados os principaislocais da cidade e suas principais informações, como nome, descrição e foto. Além disso, doisdados são extremamente importantes para a geração do itinerário: o tempo sugerido de visitae a relevância do local. Estas duas informações foram determinadas empiricamente pela equipe.

Capítulo 1. INTRODUÇÃO 3

O objetivo do aplicativo é gerar a rota com os lugares de maior relevância para o usuário,respeitando os tempos de visita.

Outro fator pertinente é o clima. Não é recomendado visitar locais abertos em diaschuvosos, como áreas verdes e monumentos, por exemplo, sob pena de dificultar o deslocamentoe prejudicar as paisagens. Nesse sentido, a aplicação desenvolvida também leva em consideraçãoo clima da cidade, fornecendo dados meteorológicos diários e considerando a probabilidade deprecipitação para escolha dos lugares.

1.3 Estrutura do Documento

O presente documento está estruturado da seguinte forma: o primeiro capítulo introduzo projeto, mostrando seus objetivos e qual a motivação para o seu desenvolvimento. O segundocapítulo aborda alguns aspectos fundamentais envolvendo o tema do projeto. O terceiro capítulofaz uma análise de aplicativos com propósitos semelhantes e realiza um estudo sobre patentes.O quarto capítulo explana a metodologia utilizada pela equipe durante o feitio do projeto. Oquinto capítulo aborda aspectos técnicos do aplicativo, como a plataforma de back-end utilizadae as APIs externas consultadas. O sexto capítulo explica detalhadamente o funcionamentodo aplicativo. O sétimo capítulo faz considerações sobre o resultado final do projeto e sugeretrabalhos futuros.

4

2 FUNDAMENTAÇÃO TEÓRICA

Nesta seção são expostas informações fundamentais relacionadas ao tema proposto.A Seção 2.1 aborda aspectos básicos referentes à cidade de Curitiba, como história, dadosdemográficos, geografia e cultura, além de informações sobre o turismo. A Seção 2.2 discorrea respeito da plataforma escolhida para o desenvolvimento do aplicativo, sua estrutura earquitetura.

2.1 A Cidade de Curitiba

A capital do estado do Paraná nasceu a partir de um pequeno povoado bandeirante quese instalou na região à procura de ouro. Permanecendo na cidade, culminaram no surgimentode diversas vilas, povoados e locais importantes que perduram até os dias atuais, como aPraça Tiradentes, o Centro Histórico e a Catedral Metropolitana (FERREIRA, 2006). Em 29de março de 1693, o capitão-povoador Matheus Martins Leme promoveu a primeira eleiçãopara a Câmara de Vereadores. Estava fundada a Vila de Nossa Senhora da Luz dos Pinhais,depois Curitiba1.

”O estudo etimológico da palavra Curitiba é complexo e varia de acordo com osmuitos autores” (FERREIRA, 2006). Contudo, para Antenor Nascentes, importante etimólogobrasileiro, trata-se de um termo de origem tupi-guarani: ”Ku’ri” que significa ”pinheiro” +”tüba”, um sufixo coletivo que tem como significado ”muito pinheiro, pinhal”. O nome fazreferência à grande quantidade de Araucaria angustifolia - popularmente conhecida comoaraucária - antigamente presente nas terras onde hoje está Curitiba.

Curitiba está localizada na região Sul do Brasil, na parte leste do estado, sobre aregião denominada Primeiro Planalto do Paraná. É a oitava capital mais populosa do país, com1.879.355 habitantes contabilizados pelo Instituto Brasileiro de Geografia e Estatística (IBGE),em 2010. Sua área total é de 435,036km2.

O Índice de Desenvolvimento Humano Municipal (IDH-M) da cidade é consideradomuito alto pelo Programa das Nações Unidas para o Desenvolvimento (PNUD), com o valorde 0,856. De 2000 a 2010, a proporção de pessoas com renda domiciliar per capita de atémeio salário mínimo reduziu em 65,3% e em 2010, 97,7% da população vivia acima dalinha de pobreza, 1,3% encontrava-se na linha da pobreza e 1,0% estava abaixo2. Possuium PIB de R$ 79.383.343 mil, o quinto maior do Brasil (INSTITUTO PARANAENSE DEDESENVOLVIMENTO ECONÔMICO E SOCIAL, 2003).

É notória a contribuição dos imigrantes na cidade para a formação de sua estrutura

1Disponível em: <http://www.curitiba.pr.gov.br/conteudo/historia-fundacao-e-nome-da-cidade/207>.Acesso em: 11 de dezembro de 2016

2Disponível em: <http://www.relatoriosdinamicos.com.br/portalodm/1-acabar-com-a-fome-e-a-miseria/BRA004041095/curitiba—pr>. Acesso em: 11 de junho de 2018

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 5

populacional, econômica, social e cultural, influenciando de forma marcante os hábitos ecostumes locais. "Com a emancipação política do Paraná (1854) e o incentivo governamental àcolonização na segunda metade do século 19, Curitiba foi transformada pela intensa imigraçãode europeus", segundo dados retirados do site da prefeitura, na sua coluna sobre imigração3.Neste sentido, destacam-se os alemães, franceses, suíços, poloneses, italianos, ucranianos ejaponeses, nos centros urbanos ou nos núcleos coloniais.

2.1.1 Turismo

A qualidade de vida oferecida pela capital paranaense, a grande quantidade de hotéis erestaurantes, a intensa agenda cultural e sua capacidade de mobilidade urbana, fazem da cidadeo destino de diversos turistas que fomentam seu crescimento econômico. Entre os atrativosque ela possui destacam-se os museus, parques, bosques, setores históricos e shoppings.

Com relação aos parques, desta-se o Jardim Botânico, ponto turístico que mais recebevisitantes na cidade. Cabe ressaltar também o Bosque do Papa, que abriga casas tipicamentepolonesas e foi construído para a visita do Papa João Paulo II em 1980; o Passeio Público,primeiro parque municipal criado em 1886; o Parque Barigui, criado em 1972 para proteger abacia do rio Barigui; o São Lourenço; o Tanguá e o Tingui. Entre os museus destacam-se oMuseu Paranaense (com dedicação às artes plásticas e à história), Museu Oscar Niemeyer (comdedicação às artes plásticas) e o Museu de História Natural (dedicado à biologia e botânica).

No centro de Curitiba está localizada a maior biblioteca pública do estado e da RegiãoSul do país, a Biblioteca Pública do Paraná, criada em 1857 e reformada em 1953 para ascomemorações do centenário do estado do Paraná4. A biblioteca serve a população com quase600 mil livros.

Outro ponto de destaque na capital é o Mercado Municipal, fundado em 2 de agostode 1958. É o principal e mais tradicional endereço para compras de Curitiba. O consumidorencontra produtos como: bebidas, queijos, vinhos, ervas medicinais, temperos e especiarias,iguarias, conservas, pescados, embutidos, carnes exóticas e com cortes especiais, além dosrestaurantes étnicos da praça da alimentação. Para os turistas interessados em compras, valetambém conhecer as ruas temáticas da cidade, como a Rua Riachuello e a Rua Teffé.

Curitiba também é conhecida pela sua grande quantidade de shoppings. Eles atraemdiversos moradores locais e turistas, interessados em realizar compras, consumir alimentosou simplesmente passear. A cidade conta com mais de 10 shoppings, sendo o maior deleso Shopping Palladium, ”diversas vezes apontado como o preferido dos paranaenses e doscuritibanos pelo Prêmio Impar/Ibope, e eleito em 2015 o Shopping Mais Querido do Brasilpela Associação Brasileira de Shopping Centers (Abrasce)” (PALLADIUM, 2016).

3Disponível em: <http://www.curitiba.pr.gov.br/conteudo/historia-imigracao/208>. Acesso em: 11 dedezembro de 2016.

4Disponível em: <http://www.bpp.pr.gov.br/modules/conteudo/conteudo.php?conteudo=3>. Acesso em:11 de dezembro de 2016.


Uma pesquisa referente ao quarto trimestre de 2017 entrevistou 14.085 passageirosem 15 aeroportos do país, avaliando sua satisfação em 38 quesitos, tais como atendimento,infraestrutura, serviços e acesso, entre outros. Os entrevistados atribuíram notas de 1 a 5 acada um deles. Entre todos os aeroportos, o de Curitiba Afonso Pena ficou em primeiro lugar,com a nota 4,77 (VEJA, 2018). A qualidade do aeroporto da cidade também contribui para oseu turismo bem sucedido.

Outra maneira de conhecer os principais pontos turísticos da cidade é embarcandona Linha Turismo, um ônibus de dois andares que além dos locais já citados anteriormente,também trafega por espaços culturais, centros históricos, regiões gastronômicas e memoriaisétnicos. A Linha Turismo circula a cada trinta minutos, percorrendo aproximadamente 45kmem cerca de três horas. Para embarcar é preciso adquirir uma cartela com cinco tíquetes novalor de R$45,00, permitindo um embarque e quatro reembarques.

No de dia 10 de maio de 2005, a Administração Municipal autorizou a criação doInstituto Municipal do Turismo em Curitiba, um órgão de personalidade jurídica autárquica.Seu objetivo fundamental5 é ”o desenvolvimento sustentável do setor turístico e o estímuloda atividade turística, com ações de fomento, promoção e divulgação do produto turísticoCuritiba”.

Durante o ano de 2017 foi realizada uma pesquisa para determinar o perfil dos usuáriosque utilizam a Linha Turismo. De um total de 578.433 embarques, o número amostrado foide 681. Constatou-se que 96,2% dos que fizeram o passeio foram turistas ou excursionistase 3,8% moradores de Curitiba e região metropolitana. Desses 96,2% de visitantes, a maioriavem de avião (66,9%), com a família (38,6%), e fica hospedada em hotel (70,4%). A principalmotivação para visitar a cidade é o lazer/descanso (60,2%) e a maioria (58,9%) estava visitandoa cidade pela primeira vez. O estado de origem dos visitantes que mais se destacou foi São Paulo(28,1%), Rio de Janeiro (12,1%), seguido de outras cidades do Paraná (8,1%) (INSTITUTOMUNICIPAL DE TURISMO, 2017).

2.2 Plataforma Android

O Android é um sistema operacional voltado principalmente para dispositivos móveiscom tela sensível ao toque, como smartphones e tablets, mas que também está presente emdiversos outros dispositivos, como TVs, veículos, relógios de pulso, consoles de videogames, etc.O sistema pertence à empresa Google e é baseado no Linux kernel, uma base para a criação desistemas operacionais.

São mais de 1,4 bilhões de aparelhos ativos que utilizam o Android como sistemaoperacional (CALLAHAM, 2015). Assim, pode-se perceber a importância dessa ferramenta nocenário de dispositivos móveis.

5Disponível em: <http://www.turismo.curitiba.pr.gov.br/conteudo/historico/5>. Acesso em: 11 de dezem-bro de 2016.


A história do Android começou em outubro de 2003, na cidade de Palo Alto naCalifórnia, quando Andy Rubin, Rich Miner, Nick Sears e Chris White fundaram a Android, Inc.Quase dois anos depois, a Google anunciou a compra da empresa - esse foi um de seus primeirospassos em direção ao mercado de softwares para dispositivos móveis (SUPERINTERESSANTE,2012). Após diversas versões de testes e não-oficiais, em 30 de abril de 2009 foi lançada aprimeira versão oficial do Android, a de número 1.5. Essa versão foi a primeira a recebero codinome de um doce, Cupcake, e as próximas versões também seguiriam esse padrão.Atualmente o sistema operacional da Google se encontra na de número 8.1 (Android Oreo).

Periodicamente o Google coleta dados estatísticos sobre seus usuários objetivandoidentificar seu perfil de uso, fornecendo um serviço personalizado para cada um. Por um períodode 7 dias (com término em 8 de janeiro de 2018), a empresa verificou a distribuição das versõesdo sistema Android no mundo todo, verificando os dispositivos que acessaram a versão maisrecente da Google Play Store. A loja oficial de aplicativos da Google é compatível com Android2.2 e posteriores. O Quadro 1 ilustra os resultados obtidos, representados graficamente pelaFigura 1.

Quadro 1 – Distribuição da plataforma Android.

Versão Codinome Distribuição2.3.3 - 2.3.7 Gingerbread 0.3%4.0.3 - 4.0.4 Ice Cream Sandwich 0.4%

4.1.x Jelly Bean 1.5%4.2.x Jelly Bean 2.2%4.3 Jelly Bean 0.6%4.4 KitKat 10.3%5.0 Lollipop 4.8%5.1 Lollipop 17.6%6.0 Marshmallow 25.5%7.0 Nougat 22.9%7.1 Nougat 8.2%8.0 Oreo 4.9%8.1 Oreo 0.8%

Fonte: (ANDROID DEVELOPERS, 2018)

O espaço de armazenamento do Android é divido em diversas partições, como a/system que abriga informações do sistema operacional e a /data para aplicações do usuário.Ao contrário das distribuições Linux para desktop, os administradores do sistema não possuemacesso irrestrito à plataforma. Para obter acesso root, é necessário explorar uma falha do sistema,prática que é comumente utilizada pela comunidade para expandir sua usabilidade. Dessa formaé possível alterar dados sensíveis do sistema operacional, instalar sistemas customizados, utilizarsensores do aparelho de maneira irrestrita, desinstalar aplicativos de sistema indesejados, etc.

Apesar do sistema Android ter sido produzido baseado no kernel Linux, alguns autoresdivergem se o mesmo é, ou não, de fato uma distribuição Linux. Para a Linux Foundation e


Figura 1 – Gráfico de distribuição da plataforma AndroidFonte: (ANDROID DEVELOPERS, 2018)

Chris DiBona, chefe da parte open source da Google (PROSCHOFSKY, 2011), sim. Outros,como o engenheiro da mesma empresa Patrick Brady, afirmam que o Android difere muito dastradicionais distribuições Linux, não incluindo a biblioteca GNU C, por exemplo (PAUL, 2009).

Com o objetivo de entender a arquitetura do Android deve-se observar a Figura 2.Pode-se perceber que a mesma é dividida em 4 camadas: Linux kernel, camada nativa, camadade estruturas para aplicação e camada de aplicações.

A camada mais inferior, linux kernel, fornece abstrações para configuração, gerencia-mento e manipulação de hardwares, como câmera, teclado, display, áudio, sensores, etc. Estacamada também é responsável por manipular informações de rede e todos os drivers disponíveisdo dispositivo.

Logo acima temos uma camada de abstração do hardware, ou seja, facilita a progra-mação das bibliotecas nativas do Android. Estas são a base de todo o desenvolvimento dosoftware do sistema operacional.

Já na camada de estruturas para aplicação, são preparadas ferramentas de gerência detodas as utilidades do aparelho, como o sistema GPS ou o sistema de controle de janelas. Porúltimo temos a camada de aplicação, que é o uso de todas as outras camadas com o objetivode oferecer um serviço ao usuário, como jogos e visualizador de imagens.

O presente capítulo apresentou uma fundamentação teórica para o projeto, com umaexplanação sobre a cidade de Curitiba e a plataforma Android. O próximo capítulo apresentauma revisão de literatura, discorrendo sobre as principais referências utilizadas para a idealizaçãodo projeto.


Figura 2 – Camadas da arquitetura do AndroidFonte: (SHARMA, 2013)

10

3 REVISÃO DE LITERATURA

Neste capítulo é realizada uma breve revisão bibliográfica de trabalhos anteriores. ASeção 3.1 detalha o funcionamento de dois aplicativos com caráter semelhante ao proposto e aSeção 3.2 realiza um estudos sobre patentes.

3.1 Estado da Arte

Pela alta difusão do uso de smartphones e a importância do turismo para a economiade diversos países, logo se viu a oportunidade da criação de aplicativos para auxílio de turistas.Estes aplicativos podem ser divididos em categorias, existindo, por exemplo, aqueles quepossibilitam a criação de um itinerário turístico. Porém existem outros que apresentam umsistema onde os usuários podem avaliar os pontos turísticos e procurar os melhores para sevisitar. Existem também aplicativos que oferecem guias por áudio. Nesta seção são comentadosos mais populares e interessantes do mercado dentro da categoria de aplicativos para criação eacompanhamento de roteiros ou itinerários.

O aplicativo Visit a City 1 oferece roteiros prontos ao usuário, ou seja, ele não defineum itinerário ao turista baseado em suas escolhas ou gostos. Assim, após escolher uma cidadede interesse, o aplicativo oferece roteiros prontos já divididos em categorias, como ”Atraçõesmais visitadas” ou ”Roteiro para conhecer e fazer compras”. Além dos roteiros grátis, em que ousuário faz o passeio sozinho e se move de um local ao outro de maneira autônoma, o aplicativooferece também opções pagas, em que o usuário será guiado ou terá serviços diferenciados.Um exemplo de roteiro pago na cidade de Roma é o "Viagem à Pompeia e ao Vesúvio em umdia partindo de Roma".

Na parte de roteiros gratuitos, o usuário deve escolher quantos dias ele deseja queo itinerário dure. Assim, ele é apresentado a uma tela de roteiro que pode ser observada naFigura 3.

Como a escolha feita no caso apresentado foi de 3 dias, pode-se perceber a divisãoem dias na parte superior da tela. Dentro do dia 1, existe uma lista dos locais do roteiros,com nome, foto, descrição, duração do passeio, se está aberto no momento e com botõesde comprar ingresso ou navegar para o local. Entre cada item da lista, existe um tempo delocomoção a pé, sendo possível trocar para outras formas de transporte. Existe também apossibilidade de editar os locais apresentados, podendo excluir um item, trocar um item dehorário com outro ou adicionar um novo local.

Por ser um aplicativo estrangeiro e com maior foco na Europa, o Visit a City nãoapresenta muitos detalhes na cidade de Curitiba, existindo somente alguns roteiros pagos, nãoexistindo nenhum gratuito.

1Disponível em: <https://www.visitacity.com/>. Acesso em: 28 de junho 2018.

Capítulo 3. REVISÃO DE LITERATURA 11

Figura 3 – Tela de roteiro Visit a CityFonte: Aplicativo Visit a City

Um outro aplicativo que apresenta itinerários turísticos é o Nativoo2. Este tambémapresenta roteiros prontos gratuitos e pagos, porém oferece a opção de criação de um novoitinerário. Ao selecionar esta opção, o usuário deve primeiro escolher quais dias deseja fazer asvisitas, adicionar, opcionalmente, o hotel em que está hospedado e adicionar locais que desejavisitar. Após, o usuário deve definir a categoria do itinerário, com opções como ”Romântico”,”Cultura”, ”Família”, entre outros. Existe também a escolha da intensidade da viagem, sendo”Normal”, ”Sem pressa” ou ”Muitos lugares”. Depois de todas essas definições, o roteiro écriado e apresentado como na Figura 4.

Como pode-se perceber, existe também uma divisão de dias na parte superior da tela.Contudo, o Nativoo apresenta um mapa com todos os pontos a serem visitados naquele dia.Após o mapa existe uma lista dos locais, porém, diferentemente do Visit a city, não apresentauma definição de horários para a visita, existindo somente uma divisão de manhã, tarde e noite.Outra diferença entre os aplicativos apresentados é que o Nativoo não oferece uma maneirafácil de iniciar a navegação para aquele local, focando mais na apresentação do mapa.

O Nativoo também apresenta a possibilidade de edição de itinerário, existindo aindaa possibilidade de adicionar mais dias, tornando a sua edição mais completa do que a do

2Diponível em: <https://nativoo.sbtur.com/>. Acesso em: 28 de junho de 2018.


Figura 4 – Tela de roteiro NativooFonte: Aplicativo Nativoo

aplicativo Visit a city. A cidade de Curitiba nesse aplicativo é tão completa quanto as outrascidades, além de também ser traduzido para o português.

O aplicativo apresentado neste documento procurou apresentar para os usuários ospontos fortes dos dois aplicativos que já estão no mercado, de modo que se encontre umsistema de itinerário turístico ideal. Dentre os pontos de inspiração estão a definição de horáriopara visita, como o apresentado pelo Visit a city, e a possibilidade de gerar um itinerário àpartir das escolhas pessoais do usuário, como acontece com o Nativoo. A principal diferençadeste para o sistema apresentado no presente documento é a consideração do clima para ageração do itinerário. Outra diferença que pode ser apontada é a escolha de locais pela suadefinição (parque, museu, etc) e não pela sua característica subjetiva (Romântico, cultura,etc).

3.2 Estudos Sobre Patentes

Nesta seção são expostas patentes que tenham alguma semelhança com partes oucom o conceito geral do projeto, podendo assim buscar a veracidade de que o projeto é umaideia legítima. A Subseção 3.2.1 aborda sobre a patente de um modelo de mapa digital. Já


na Subseção 3.2.2 é apresentada a patente de um sistema de gestão turística que usa umaconexão com a rede.

3.2.1 Mapa digital

A patente de mapa digital da Google (RASMUSSEN et al., 2011) apresenta todo osistema de mapa digital usado principalmente na ferramenta Google Maps. A patente apresentatodo o estilo das telas e gráficos apresentados ao usuário, assim como pode-se observar naFigura 5.

Figura 5 – Uma das telas da patente da GoogleFonte: (RASMUSSEN et al., 2011)

Além da parte de design, a patente também apresenta fluxogramas que explanam quala ideia do algoritmo que está sendo apresentado, tanto na parte de busca de endereço quantona parte do quanto do terreno se deve mostrar na tela.

Como neste trabalho optou-se por utilizar a API da Google, a equipe não terá que criarum software próprio de navegação em mapa digital. No entanto, se deverá operar dentro doslimites apresentados pela API, como requisições máximas de informações em um determinadotempo ou a impossibilidade de se obter algumas informações sem que o usuário tenha que entrardiretamente no aplicativo da Google, saindo assim do aplicativo que está sendo apresentadocomo objetivo neste projeto.


3.2.2 Sistema de gestão turística

Dentro do banco de patentes europeu encontra-se um sistema de gestão turística quese conecta à Internet (LEI, 2016). Dentre as ferramentas que o sistema oferece estão:

• Planejamento de rota;• Sistema de guia;• Sistema de compra de ingressos;• Sistema de emergência;• Sistema de previsão do clima.

Através dessas informações pode-se perceber que o sistema apresentado na patente temcerta semelhança com o projeto, pois existe um planejamento de rota que leva em consideraçãoo clima. Contudo, o sistema apresentado na patente não está especificado como sendo umaplicativo. Deve-se levar em consideração também que o algoritmo para o planejamento darota será desenvolvido inteiramente pela equipe, não devendo ter uma semelhança significativacom a apresentada na patente.

Além disso, o aplicativo deste projeto terá outras ferramentas que não são apresentadasna patente, como a apresentação dos locais divididos em grupos com diferentes perfis, assimcomo a possibilidade do usuário ter um perfil que também define algumas decisões no itinerário.

3.2.3 Considerações

Apesar das patentes terem certa semelhança com aquilo que é proposto neste projeto,elas não impedem o feitio deste pois são ideias claramente diferentes e com diferentes objetivos,fazendo com que o aplicativo proposto neste trabalho seja autêntico.

O presente capítulo apresentou os estudos realizados por terceiros, de modo a tê-loscomo referência. O próximo capítulo apresenta a metodologia empregada para o desenvolvimentodo projeto, assim como todas as tecnologias e ferramentas utilizadas.

15

4 METODOLOGIA

Neste capítulo é exposta toda a metodologia utilizada pela equipe para realizar oprojeto. A Seção 4.1 explana sobre o método usado para definir qual seria a solução técnicado projeto. Na Seção 4.2 é apresentado o método de desenvolvimento aplicado no feitio dotrabalho. Já na Seção 4.3 são expostas as tecnologias utilizadas para o desenvolvimento dosistema, como o ambiente e a linguagem de programação, a ferramenta de controle de versão,a ferramenta para testes de requisição das APIs e a plataforma de software.

4.1 Método de definição da solução

Usou-se o processo de Design Thinking para definir o problema existente e encontrara solução mais amigável para os usuários.

Design Thinking é uma metodologia de design que visa encontrar soluções para umproblema focando na experiência do usuário. Outro ponto importante dessa abordagem éfazê-la de maneira coletiva e colaborativa, ouvindo o maior número de opiniões possíveis.

Em 1969, o vencedor de um prêmio Nobel Herbert Simon definiu um dos primeirosmodelos para um processo de Design Thinking (SIMON, 1996). Este modelo consiste emsete estágios superiores, cada um havendo seus estágios e atividades, e foi uma referênciapara vários outros modelos. Um deles foi o proposto pelo Instituto de Design Hasso-Plattnerde Stanford (DAM, 2018), uma das mais importantes universidades em Design Thinking.Segundo o Instituto, existem 5 estágios no processo, sendo eles: Empatia, Definição, Ideação,Prototipação e Testes. Uma explicação de cada um pode ser vista a seguir:

1. Empatia - O primeiro passo do processo é tentar entender o problema de uma maneiraempática, ou seja, observar o ambiente da maneira que o usuário o vê. Para conseguirrealizar esse passo é possível obter informações com especialistas do ramo, pois estes jápossuem uma vasta experiência e farão colocações que somente eles conhecem. Outraação que pode ser realizada é estar fisicamente no local em que ocorre o problema,tentando extrair todos os detalhes sobre a situação.

2. Definição - Nesta fase, todas as informações coletadas na fase de Empatia serão usadaspara definir qual é o problema. Este deve ser o problema raiz, não uma visão sobre umaparte. Um exemplo é a diferença entre a visão "Nós precisamos aumentar a distribuiçãode comidas nutritivas para crianças em 5%", se comparada com a correta visão "Criançasprecisam comer comidas mais nutritivas para melhorar sua saúde e crescer".

3. Ideação - No terceiro estágio do processo, já existem todas as informações encontradasno estágio da Empatia e a definição do problema cerne, encontrada na fase de Definição.Assim, é preciso começar a pensar em possíveis soluções para o problema, baseando-seem soluções para problemas parecidos e na criatividade da equipe.

Capítulo 4. METODOLOGIA 16

4. Prototipação - É nessa fase em que serão, no caso de um aplicativo, criadas as telas,pensando no que cada uma deve conter e quais serão os fluxos entre elas. Deve-se levarmuito em conta a usabilidade da solução, pois além de resolver o problema, a ferramentadeve fazer isso da maneira mais amigável possível para os usuários.

5. Teste - Por fim, todos os protótipos e pensamentos gerados das etapas anteriores devemser testados e validados. Nessa fase devem ser realizados casos de uso simulados, ou seja,simular todos os possíveis fluxos de uso no sistema, com o objetivo de encontrar falhasou possíveis melhorias na ferramenta.

Apesar de existir uma lógica linear entre as fases do processo apresentado, existempontes entre as etapas que podem ocorrer dependendo do andamento do projeto. Umavisualização dos possíveis acontecimentos e a qual caminho ele leva pode ser observado naFigura 6.

Figura 6 – A não linearidade do processo de Design ThinkingFonte: (DAM, 2018)

4.2 Método de Desenvolvimento

O método que foi utilizado neste projeto é o modelo em V. Este método é chamadode modelo em V pois se vê todo o planejamento e especificação como a “descida” da parteesquerda da letra, enquanto os testes são a “subida” da parte direita da letra. A primeira partedo modelo é dividida em três etapas, sendo seguidas respectivamente em: análise de requisitos,planejamento de alto nível e planejamento detalhado. A segunda etapa também é dividida emtrês etapas, sendo feitas na seguinte ordem: teste individual, teste de integração e teste devalidação. Entre essas duas partes existe a implementação.

Diferente do modelo em cascata, em que as etapas são seguidas de maneira linear até ofim, no modelo em V são definidas possíveis voltas às etapas de planejamento de acordo com os


resultados das etapas de testes. De acordo com o método, quando descobre-se um erro na etapade teste individual, deve-se voltar à etapa de planejamento detalhado. Quando encontra-se umproblema na etapa de teste de integração, é preciso voltar à etapa de planejamento de altonível. Por último, quando descobre-se um erro na etapa de teste de validação, volta-se à etapade análise de requisitos.

Na etapa de levantamento de requisitos, deve-se fazer uma análise de todas asnecessidades que existem em cada parte do aplicativo, gerando-se uma lista de requisitosfuncionais e uma lista de requisitos não funcionais. Quanto mais detalhadas forem essas listas,mais rápidas e detalhadas serão as próximas etapas do método. Os requisitos e os riscoslevantados podem ser observados no Apêndice A.

Na etapa de planejamento de alto nível, são feitas algumas definições do software,como o diagrama de classes, além de quais serão as tabelas do banco de dados e, no caso doaplicativo, quantas e quais serão as diferentes páginas e menus. Já na etapa de planejamentodetalhado, devem ser feitos os outros diagramas mais detalhados, como o diagrama sequencial.É preciso também detalhar quais serão, exatamente, os dados que serão guardados no bancode dados, assim como definir os algoritmos que serão usados.

Nas etapas de testes, primeiro deve-se testar cada entidade ou classe individualmente,procurando-se por erros locais. Depois, testa-se o sistema como um todo, procurando por errosem todas as funcionalidades do projeto. Por último, deve-se testar o aplicativo com possíveisusuários, procurando por erros de concepção ou por possíveis melhorias, além de avaliar suausabilidade.

4.3 Tecnologias

Nesta seção são discutidas todas as tecnologias usadas para a realização do projeto,como o ambiente e a linguagem de programação, a ferramenta de controle de versão, aferramenta para testes de requisição das APIs, a plataforma de software e a plataforma dehardware.

4.3.1 Ambiente de programação

Pelo fato de o sistema operacional Android ser da Google, pode-se afirmar que amelhor plataforma para desenvolvimento nesse ambiente é o Android Studio (VARGAS, 2018),pois ele é o ambiente oficial disponibilizado pela empresa. Por ser o mais indicado e utilizado,o Android Studio detém também de muitos tutoriais a ajudas em fóruns e blogs.

Além de ser uma IDE, o Android Studio também oferece uma ferramenta de teste queemula um dispositivo Android, facilitando assim os testes em diversos dispositivos diferentes.Outro facilitador deste ambiente no projeto é o fato de existir uma extensão dentro do AndroidStudio para o banco de dados Firebase (Apresentação na Seção 5.1), permitindo uma rápidavisualização de tutoriais para o uso deste dentro do sistema.


4.3.2 Linguagem de programação

Na Google I/O de 2017, um evento realizado pelo Google que acontece todos os anoscom o objetivo de a empresa apresentar todas as suas novidades e expectativas, os engenheirosresponsáveis pelo Android anunciaram o Kotlin como a nova linguagem oficial de programaçãopara a plataforma (VIANA, 2017).

No entanto, pelo fato de essa mudança ter sido muito recente, não existe umaquantidade grande de conteúdos em fóruns se comparado com a linguagem Java (Antigalinguagem de programação oficial para Android). Outro ponto que fez com que a equipeutilizasse o Java como linguagem para o feitio do projeto é o fato de ambos já conheceremessa linguagem, eliminando a necessidade de aprender uma nova.

4.3.3 Controle de versionamento

Para que exista um melhor controle das versões do código e exista uma organizaçãode adições ao projeto por duas pessoas diferentes, é necessária a utilização de um sistemapara isso. Dentre o vários sistemas de controle de arquivos disponíveis, o mais utilizado é oGit. Porém, para utilizar esse sistema é preciso que exista um servidor para guardar todosos arquivos enviados por todos os desenvolvedores do código. Assim, fez-se necessário o usode uma ferramenta online que disponibiliza a criação de um repositório de maneira gratuita.A ferramenta escolhida foi o Github1, pois ele é muito robusto e oferece um aplicativo paramandar os arquivos para o repositório de maneira mais fácil e usual.

4.3.4 Testes de requisições para as APIs

Para testar as respostas de uma requisição para uma API sem o uso de uma ferramenta,no contexto de desenvolvimento de aplicações mobile, faz-se necessária a passagem por algunspassos no ambiente de teste, ou seja, é preciso passar pelas telas do aplicativo, colocar asinformações necessárias e depois visualizar em uma nova tela qual é a resposta.

Com o objetivo de simplificar o processo de testes das requisições, utilizou-se noprojeto uma ferramenta específica para isso, o Postman2. Com esta, definimos a URL darequisição, quaisquer informação que precisamos mandar no corpo dela e o header. Após isso,pode-se enviar a requisição, existindo um corpo de mensagem com a resposta recebida doservidor.

4.3.5 Plataforma de software

A plataforma escolhida pela equipe para desenvolver o aplicativo é o Android, pelofato de ser uma plataforma de desenvolvimento aberto. Mais informações sobre essa plataformasão explanadas na Seção 2.2.

1Disponível em: <https://github.com/>. Acesso em: 21 de junho de 2018.2Disponível em: <https://www.getpostman.com/>. Acesso em: 21 de junho de 2018.


Outras opções de desenvolvimento mobile são: o IOS, sistema operacional dos produtosApple, e as ferramentas de desenvolvimento híbrido, como o Ionic3. Para desenvolver para aplataforma IOS, é preciso ter uma conta de desenvolvedor Apple, o que geraria um custo a maispara a equipe. Outra ressalva sobre essa plataforma é o fato de ela necessitar a aprendizagem deuma linguagem de programação própria, o Swift4. As ferramentas de desenvolvimento híbridopermitem que um mesmo código seja usado tanto para Android quanto para IOS. Porém, essasferramentas não são recomendadas quando se presa pela experiência do usuário no campo dedesign, pois elas não seguem os padrões de cada um dos sistemas operacionais de maneiraindividual.

4.3.6 Plataforma de hardware

Como o projeto tem como objetivo desenvolver um aplicativo mobile, não é necessáriaa utilização de uma plataforma de hardware. Serão utilizados somente smartphones ou tablets.

O presente capítulo apresentou as duas metodologias que serviram de guia para o feitiodo trabalho, assim como as tecnologias e ferramentas que fizeram parte do desenvolvimento.O próximo capítulo apresenta pontos técnicos que compõe o sistema, assim como informaçõessobre cada um deles.

3Disponível em: <https://ionicframework.com/>. Acesso em: 21 de junho de 2018.4Disponível em: <https://developer.apple.com/swift/>. Acesso em: 21 de junho de 2018.

20

5 DESENVOLVIMENTO DO APLICATIVO

Neste capítulo são explanados alguns aspectos técnicos sobre os principais componentesque compõe o aplicativo, como a plataforma de back-end utilizada, as APIs externas consultadase as principais decisões de projeto.

5.1 Plataforma Firebase

Nesta seção é discutido sobre a plataforma utilizada como back-end da aplicação, ouseja, o sistema utilizado como banco de dados online do projeto. Na Subseção 5.1.2 é discutidosobre as características e ferramentas presentes no Firebase1. Logo após, na Subseção 5.1.3são apresentadas quais ferramentas foram utilizadas no projeto e a estrutura dos dados dentrodo banco de dados. Por fim, na Subseção 5.1.1 existe uma explicação do porquê utilizou-se oFirebase como sistema de banco de dados do projeto.

5.1.1 Motivo para escolha do Firebase

Para guardar todas as informações de todos os pontos turísticos necessários, é precisode um banco de dados. O desenvolvimento de um banco de dados e de um webservice para poderenviar e colher dados pela rede é complexo e exigiria muito tempo. Além disso, necessitaria omantimento de um servidor próprio para armazenar o banco e estar ligado à Internet a todomomento. Isso geraria mais custos para a equipe.

Com o objetivo de contornar a complicação desnecessária para o feitio do projeto eum maior custo, encontrou-se o Firebase, uma plataforma muito robusta, com um bom suportee grátis (dentro de alguns limites). Como o projeto está em ambiente acadêmico, o Firebase,em seu pacote grátis, supre todas as necessidades do sistema.

5.1.2 Características e ferramentas

O Firebase é uma plataforma do Google que oferece ferramentas e uma infraestruturaa desenvolvedores de aplicativos mobile e web. Ele possui planos pagos e gratuitos. Asfuncionalidades oferecidas são (AVRAM, 2016):

• AdMob - Integração com o Google AdMob;• AdWords - Integração com o Google AdWords;• Analytics - Um painel para monitorar o comportamento do usuários da aplicação,

segmentação demográfica e desempenho de campanha;• Autenticação - Suporte de autenticação de usuários via e-mail, Facebook, GitHub,

Google Sign-In e Twitter ;

1Disponível em: <https://firebase.google.com/>. Acesso em 02/07/2018

Capítulo 5. DESENVOLVIMENTO DO APLICATIVO 21

• Relatório de erros - Monitora os erros da aplicação em todos os dispositivos e éintegrado com o Analytics para analisar o comportamento dos usuários após falhas;

• Database - Um banco de dados NoSQL utilizado para armazenar dados JSON (JavaS-cript Object Notation - Notação de Objetos JavaScript);

• Dynamic Links - deep links para possibilitar que o usuário acesse páginas internas daaplicação;

• Hosting - uma CDN (Content Delivery Network) distribuída globalmente para serviraplicações web;

• Indexing - utilizado para indexar as aplicações na busca do Google (Google Search);• Invites - possibilita a troca de informações sobre uma aplicação entre usuários;• Messaging - o antigo Google Cloud Messaging (GCM) é o novo Firebase Cloud

Messaging (FCM);• Notifications - gerenciamento de notificações enviadas para o seu usuário;• Offline - possibilita o armazenamento de dados na memória cache local, permitindo

assim o funcionamento da aplicação em estado offline;• Real Time - os dados são armazenados em tempo real no banco de dados;• Storage - armazena as mídias do usuário, como áudio, imagens e vídeos;• Test Lab - teste da aplicação em dispositivos reais;• Remote Config - permite aos desenvolvedores modificar o comportamento e a aparênciada aplicação sem requerer que os usuários realizem o download de uma nova versão.Esta funcionalidade é utilizada para testes A/B, alterar o tema visual da aplicação ouaté mesmo se comunicar com usuários de regiões especificas, etc;

• Synchronization - quando os dados são alterados em um dispositivo eles são enviadospara o Firebase e então para todos os dispositivos conectados. Caso existam dispositivosoffline neste momento, eles serão atualizados com a última versão dos dados logo apósa conexão com internet;

5.1.3 Uso no projeto

Dentre todas as ferramentas presentes no Firebase, no projeto foram utilizadas oDatabase e o Storage. Neste estão presentes todas as fotos de cada um dos pontos turísticoscadastrados, enquanto naquele exsitem as informações dos pontos e dados de distância entreeles.

5.2 Banco de dados

Nesta seção existe a explicação sobre como os dados estão organizados, além deapresentar todas as informações coletadas.


5.2.1 Estrutura dos dados

A estrutura de dados utilizada no banco de dados é a definida pela ferramenta Firebase,o JSON (JavaScript Object Notation - Notação de Objetos JavaScript). Esta estrutura funcionade modo que existe uma hierarquia dos dados, ou seja, define-se campos e dentro deles podem-sedefinir novos campos. Para um melhor entendimento deve-se observar a Figura 7.

Figura 7 – Exemplo de um item do banco de dadosFonte: Autoria própria

Dentro da estrutura ”places” é possível ver o número 0. Este é o identificador de umlocal, ou seja, é o número que identifica aquele ponto turístico. Dentro deste ponto, existemtodas as informações sobre ele. Uma explicação sobre cada uma das características é explanadaa seguir:

• coordinates - São as coordenadas geográficas em que o ponto se encontra;• description - descrição sobre o ponto;• id - número de identificação do ponto;• image - nome do arquivo de imagem presente no storage do projeto;• name - nome do ponto;• placeGroup - todos os grupos em que o ponto está inserido.• relevance - relevância do ponto em comparação com todos os outros. Este númerovaria de 1 a 5, sendo 5 a maior relevância e 1 a menor;

• visitTime - o tempo médio em minutos que leva para visitar o ponto;• weatherDependent - valor que indica se a decisão de visitar o ponto depende ou não

do clima.


5.2.2 Dados armazenados

O Quadro 2 representa todos os locais cadastrados no banco de dados do Firebase esuas informações. Cada número na coluna ”Grupo(s)” representa um dos grupos cadastrados.O nome de cada grupo e o seu número de referência são:

• 0 - Parques bosques e praças.• 1 - Postos Turísticos.• 2 - Museus.• 3 - Locais de compra.• 4 - Gastronômicos.

Quadro 2 – Locais cadastrados no banco de dados e suas informações.

Nome Grupo(s) Relevância Tempo devisita (emminutos)

Dependedo clima

Jardim Botânico 0, 1 5 120 SimBosque do Alemão 0 3 90 SimParque Tanguá 0, 1 5 120 SimParque Barigui 0 4 150 Sim

Parque João Paulo II 0 3 90 SimParque Tingui 0 4 120 Sim

Parque São Lourenço 0 3 90 SimPraça do Japão 0 3 60 Sim

Zoológico Municipal 0 3 120 SimPraça da Espanha 0 2 60 Sim

Bosque Reinhard Maack 0 1 60 SimPasseio Público 0, 1 4 90 SimPraça Osório 0, 1 3 60 Sim

Praça Santos Andrade 0, 1 2 30 SimÓpera de Arame 1 3 60 SimLargo da Ordem 1 5 60 Sim

Estádio Joaquim AméricoGuimarães

1 2 60 Não

Estádio Major Antônio CoutoPereira

1 2 60 Não

Estádio Durival Britto e Silva 1 2 60 NãoCatedral Metropolitana de

Curitiba1 5 30 Não

Torre Panorâmica de Curitiba 1 3 60 NãoMemorial de Curitiba 1 2 30 Não

Mesquita Imam Ali ibn AbiTalib

1 1 30 Não

Praça Tirandentes 0, 1 5 30 SimPraça Rui Barbosa 0, 1 5 60 Sim


Museu Oscar Niemeyer 1, 2 5 120 NãoMuseu Egípcio e Rosacruz 2 1 90 Não

Museu Paranaense 2 2 90 NãoMuseu do Automóvel de

Curitiba2 1 90 Não

Museu Ferroviário 2 2 90 NãoMuseu do Expedicionário 2 2 90 Não

Museu de ArteContemporânea do Paraná

2 1 90 Não

Mercadoteca 4 2 120 NãoMercado Municipal de

Curitiba3, 4 4 90 Não

Rua XV de Novembro 1, 3 5 120 SimShopping Estação 3, 4 3 150 NãoShopping Curitiba 3, 4 3 150 NãoShopping Palladium 3, 4 3 150 NãoShopping Barigui 3, 4 3 150 NãoShopping Cidade 3, 4 1 90 NãoShopping Total 3, 4 2 90 NãoShopping Crystal 3, 4 2 90 NãoShopping Mueller 3, 4 3 150 Não

Shopping Pátio Batel 3, 4 3 150 NãoShopping Jardim das

Américas3, 4 1 90 Não

Fonte: Autoria própria

5.3 APIs utilizadas

Nesta seção são expostas as APIs usadas no projeto, tanto suas informações como deque maneira foram utilizadas. Na Subseção 5.3.1 são explanadas todas as informações sobre aDistance Matrix API2, que é uma das APIs do Google a qual retorna informações de distânciaentre o usuário e um local definido. Já na Subseção 5.3.2, apresenta-se a Google Play ServicesLocation, API utilizada para conseguir a localização atual do usuário.

5.3.1 Distance Matrix API

A Distance Matrix API permite a coleta de informações de distância entre dois pontosquaisquer do planeta. Para a sua utilização, é necessária a obtenção de uma chave de acesso,ação esta que pode ser feita gratuitamente. Essa chave será utilizada para validar a suarequisição de informações ao servidor do Google, pois, caso não houvesse essa validação, nãoexistiria uma maneira de o Google controlar quantas requisições cada usuário está realizando.Na versão gratuita, existe uma limitação de 1.000 requisições por dia.

2Disponível em: <https://developers.google.com/maps/documentation/distance-matrix/intro>. Acessoem 02/07/2018.


Para obter uma chave de acesso de qualquer API do Google é necessária a criação deum projeto no Google Cloud Platform. Após isso, é preciso pressionar o botão "Obter umachave", na plataforma de APIs do Google Maps3.

As requisições da API são feitas em HTTP (Hypertext Transfer Protocol). O formatoda requisição possui a forma básica https://maps.googleapis.com/maps/api/distancematrix/outputFormat?parameters. O campo outputFormat da URL pode ser qualquer um dos seguintesvalores:

• json - indica a saída em JSON ou• xml - indica a saída como XML (Extensible Markup Language).

O campo parameters se refere aos parâmetros de solicitação que darão as informaçõesnecessárias para obter a resposta desejada. Existem parâmetros obrigatórios e opcionais. Comoé padrão em URLs, todos os parâmetros são separados usando o caractere E comercial (&).Os parâmetros obrigatórios estão listados a seguir:

• origins - o ponto inicial do cálculo do tempo e da distância do percurso. É possívelfornecer um ou mais locais separados pelo caractere de barra reta (|), em forma deendereço, coordenadas de latitude/longitude ou ID de local;

• destinations - um ou mais locais para usar como o ponto final do cálculo do tempo eda distância do percurso. As opções para o parâmetro destinations são as mesmas doparâmetro origins, conforme descrito acima;

• key - a chave de API do aplicativo. Essa chave identifica o aplicativo para fins degerenciamento de cotas.

Para melhor especificar quais as informações desejadas na requisição, são possíveisadicionar os seguintes parâmetros opcionais:

• mode - especifica o modo de transporte a ser usado ao calcular a distância e o tempode percurso. O valor padrão é driving ;

• language - o idioma no qual retornar os resultados;• avoid - introduz restrições à rota, como evitar rodovias;• units - especifica o sistema de unidades a ser usado ao expressar a distância como texto;• arrival-time - especifica a hora desejada de chegada para solicitações de rota em

segundos a partir da meia-noite (UTC) do dia 1o de janeiro de 1970;• departure-time - a hora de saída desejada;• traffic-model - especifica as suposições a serem usadas ao calcular o tempo no trânsito,

como otimista ou pessimista;• transit-mode - especifica um ou mais modos de transporte preferenciais, como ônibus

ou trem;• transit-routing-preference - especifica preferências para solicitações de transporte

público.3Disponível em: <https://developers.google.com/maps/documentation/distance-matrix/intro>. Acesso

em 21 de maio de 2018.


Após enviar a requisição para a API entre o Cristo Redentor e o Estádio do Maracanãde carro, ambos presentes na cidade do Rio de Janeiro, obteve-se a resposta presente na Figura8.

Figura 8 – Exemplo de uma resposta à requisição de distância da API do GoogleFonte: Autoria própria

Como pode-se perceber, o servidor retorna o endereço de ambos os pontos, assimcomo a distância entre eles e o tempo estimado de locomoção. A distância está em metros e otempo em segundos. Este é utilizado no projeto para mostrar para o usuário quanto tempo elevai levar para se locomover ao próximo ponto do itinerário, podendo alternar entre a pé oude carro. Não é possível selecionar outras formas de deslocamento, tendo em vista o carátergratuito da licença utilizada. Já a distância é utilizada no algoritmo de cálculo do itinerário, nosentido de colocar locais mais próximos entre si em ordem.

Para implementar as requisições, no projeto utilizou-se uma classe de código abertochamada Retrofit. Esta permite que as requisições sejam criadas de maneira organizada etransparente, pois utiliza anotações (Uso do símbolo ”@” em Java) para gerar corretamente arequisição, sem a necessidade de gerá-la toda manualmente. Além disso, a descoberta de errosdurante a requisição se torna mais fácil com o Retrofit, porque ele já gera automaticamenteuma resposta de erro caso ele ocorra.

5.3.2 Google Play Services Location

Por meio da API Google Play Services Location4 é possível obter a localização emcoordenadas de um dispositivo. Esta informação é utilizada no sistema para definir qual deve

4Disponível em: <https://developers.google.com/android/guides/setup>. Acesso em: 02/07/2018.


ser o primeiro local do itinerário, pois o primeiro ponto deve ser o mais perto dentre todos osescolhidos.

Para ter acesso a essa informação, é necessário que o usuário permita que o aplicativotenha acesso ao dados de localização. Para que ocorra essa permissão durante o uso doaplicativo, é necessária uma mudança no manifest do projeto, pois é nele que são definidas aspossíveis permissões necessárias.

A API Google Play Services Location usa dois tipos diferentes de permissões: AC-CESS_COARSE_LOCATION e ACCESS_FINE_LOCATION. Este permite que a aplicaçãoacesse uma localização exata do aparelho, pois utiliza o GPS para a definição das coorde-nadas. Já a outra permissão oferece uma localização aproximada do aparelho, pois utilizasomente informações de redes de telefonia e Wi-fi. No projeto utilizou-se a permissão AC-CESS_FINE_LOCATION, pois a definição correta do primeiro ponto do itinerário faz com queele se torne muito mais satisfatório.

5.3.3 Dark Sky API

A Dark Sky API5 foi utilizada no projeto para consulta de dados meteorológicos. AAPI possui dois planos de utilização: gratuito e pago. Ambos permitem as mesmas formasde requisições e acesso às informações referentes ao clima, com a diferença que a primeiraversão permite apenas 1000 requisições por dia. Após excedido o limite a conta de usuário ébloqueada e liberada apenas no próximo dia.

Um importante diferencial do aplicativo Descubra Curitiba é o fato deste considerar aprevisão meteorológica para a construção do itinerário. Contando com o dia atual, o aplicativoavalia a probabilidade de precipitação para os próximos 8 dias. Caso essa seja superior a 60%(valor determinado empiricamente pela equipe), o itinerário não irá considerar locais descobertospara aquele dia como parques, bosques, praças e a maioria dos locais públicos. O aplicativousa esses dados para proporcionar uma melhor experiência de visita ao usuário, pois não éagradável visitar esses tipos de locais com condições climáticas inadequadas (principalmentechuva). A variável booleana que representa essa característica é a de nome WeatherDependent,representada na Figura 7.

Além de avaliar a probabilidade de precipitação, para cada dia são disponibilizadasinformações complementares referentes ao clima, as quais os usuários podem consultar paramelhor planejarem seu passeio. São elas: temperatura (média, máxima e mínima), probabilidadee intensidade de precipitação, horário do nascer e pôr do sol, nebulosidade (taxa percentualem que o céu está encoberto por nuvens), umidade relativa do ar, velocidade dos ventos epressão atmosférica. A API também disponibiliza outros dados aos clientes, mas que nãosão considerados significativos para o propósito da aplicação, como quantidade de ozônioatmosférico, ponto de condensação da água, fase da lua, direção do vento, etc

5Disponível em: <https://darksky.net/dev>. Acesso em: 21 de maio de 2018.


O presente capítulo apresentou todos componentes técnicos que estão presentes noaplicativo, como o sistema de banco de dados Firebase e as API’s. O próximo capítulo apresentaos fluxos e telas obtidos ao final do desenvolvimento, explicando claramente todos os possíveispassos no uso do aplicativos e seus resultados.

29

6 O APLICATIVO DESCUBRA CURITIBA

Neste capítulo estão presentes todos os fluxos e telas do aplicativo. Na Seção 6.1 éabordada a primeira tela do sistema. Na Seção 6.2 é exposto o principal fluxo do aplicativo:criar itinerário. Na Seção 6.3 é apresentada a funcionalidade "Última rota salva". Por fim, naSeção 6.4 são mostrados o fluxo e telas da funcionalidade "Locais para conhecer".

6.1 Tela inicial

A tela inicial da aplicação pode ser visualizada na Figura 9. Ela possui 3 opções: "criaritinerário", ”utilizar última rota salva” e "locais para conhecer". Os detalhes de cada uma sãoabordados nas próximas subseções.

Figura 9 – Tela inicial do aplicativoFonte: Autoria própria

6.2 Criar itinerário

A criação do itinerário representa a principal funcionalidade do aplicativo: permitirque a partir de diversas informações fornecidas pelo usuário (entradas), uma rota turística

Capítulo 6. O APLICATIVO DESCUBRA CURITIBA 30

adequada seja gerada (saída). Para tal, todas as informações requeridas devem ser preenchidas,não podendo nenhuma ficar vazia. A Figura 10 ilustra as telas para criação de itinerário.

Figura 10 – Telas para criação de itinerárioFonte: Autoria própria

O primeiro passo é a seleção do local de partida. Esse local tipicamente representao hotel ou hospedagem do turista. Será o ponto inicial do passeio para todos os dias. Parapreencher este campo o usuário possui duas opções: inserir manualmente o local ou selecionara opção ”UTILIZAR LOCALIZAÇÃO ATUAL” para que a aplicação faça uso do sensor GPSdo dispositivo para determinar sua localização. Quando o usuário deseja inserir os dadosmanualmente, a aplicação utiliza a classe Geocoder para encontrar as coordenadas do localinserido. Para realizar a busca podem ser utilizados nomes de ruas, avenidas, locais públicose diversos outros logradouros. Caso o local não possa ser encontrado ou não for o desejado,deve-se cancelar a operação e repetir o processo novamente, inserindo novos dados. Paraexemplificar o processo, deseja-se definir como local de partida a sede centro da UTFPRcampus Curitiba. Inserindo o texto ”utfpr” é solicitada a confirmação do usuário ilustradapela Figura 11. Como o endereço encontrado corresponde à da UTFPR campus Apucarana, ousuário deve selecionar a opção "TENTAR NOVAMENTE".

O local selecionado também deve pertencer a uma determinada área de abrangência.O espaço permitido engloba toda a cidade de Curitiba e região metropolitana. Caso seja


Figura 11 – Alerta solicitando confirmação do usuário para definição do local de partidaFonte: Autoria própria

selecionado um local fora dessa área, o aplicativo irá alertar o usuário.A próxima etapa é a seleção dos dias do passeio. Ele será composto por todos dias

compreendidos entre o primeiro e último dia (inclusive). Para essa seleção há as seguintesrestrições:

• Não é possível selecionar o dia atual como primeiro dia de passeio caso já tenha sepassado das 16:00 horas;

• Há um limite de 7 dias para seleção do primeiro dia de passeio, contando a partir dadata atual;

• Há um limite de 7 dias para seleção do último dia de passeio, contando a partir doprimeiro dia selecionado;

• Não é possível selecionar o último dia de passeio caso o primeiro ainda não esteja definido.

O próximo passo é a definição dos horários de início e término do itinerário. Esseshorários serão definidos para todos os dias. O horário de início representa o instante em que ousuário deseja iniciar o seu passeio diariamente (momento em que irá sair de sua hospedagempara ir ao primeiro local de visita). O horário de término representa o instante máximo para avisita naquele dia, ou seja, a permanência sugerida do usuário em uma atração não poderáultrapassá-lo. Para essa seleção há as seguintes restrições:

• O horário de início deve estar compreendido entre às 05:00 e 16:00 horas;• O horário de término deve vir após o horário de início e deve estar compreendido entre

às 08:00 e 20:00 horas;• O passeio deve ter uma duração de pelo menos 3 horas;• Não é possível selecionar o horário de início caso os dias de início e término do passeio

ainda não estejam definidos.• Não é possível selecionar o horário de término caso o horário de início ainda não esteja

definido.

A quarta etapa é a seleção dos locais de interesse. Esses estão divididos em 5 grupos:parques, bosques e praças, pontos turísticos, museus, locais de compras e gastronômicos. Ao


menos um deve ser escolhido para que o itinerário possa ser gerado. Ao todo são 45 lugarescadastrados no banco de dados do aplicativo e a maioria possui dois grupos associadas. Arelação completa dos lugares pode ser visualizada por meio Quadro 2. Caso hajam locaisinsuficientes para gerar um itinerário de acordo com as entradas do usuário, o aplicativo iráalertá-lo, reduzir o número de dias do passeio e alterar o horário de término do último dia. Issoirá ocorrer, por exemplo, se o usuário selecionar 7 dias de passeio, com duração diária de 10horas e optar apenas pelo grupo de locais "Gastronômicos". O resultado é um itinerário deapenas 3 dias.

Por fim o usuário deve escolher se deseja ou não considerar a previsão do tempopara os próximos 7 dias para a construção do itinerário. Em caso afirmativo, o aplicativoirá consultar a API Dark Sky (Subseção 5.3.3) para obter os dados meteorológicos. Se aprobabilidade de precipitação para um dado dia estiver acima de 60%, considera-se que iráchover. Portanto não serão escolhidos locais descobertos para a visita. Se esta opção fordesmarcada o clima será desconsiderado para a geração da rota. Como o aplicativo obtém aprevisão do tempo para apenas 7 dias, caso os dias de passeio excedam esse período o climatambém será desconsiderado.

Ao pressionar o botão ”FINALIZAR” o itinerário finalmente é gerado. Todos os locaissão obtidos do banco de dados do Firebase (Subseção 5.1) e filtrados de acordo com os gruposselecionados e sua dependência do clima. Eles são representados pela estrutura indicada pelaFigura 7. Seu mais importante atributo é a relevância, com valores discretos no intervalo de 1 a5. Quanto maior a relevância, maior é a representatividade daquele local para a cidade, ou seja,mais importante ele é. Pode-se considerar que os locais de relevância 5 são cartões-postais.

O conceito principal do algoritmo é maximizar a relevância diária dos locais visitadose, consequentemente, a de todo o itinerário. O segundo ponto a ser analisado são as distânciasentre os locais, as quais devem ser as menores possíveis. Elas são obtidas por intermédio daDistance Matrix API da Google (Subseção 5.3.1). É sempre considerado o caminho mais rápidofornecido, via carro. Assim sendo, todos os locais são ordenados por dois atributos a cadaiteração, primeiro em ordem decrescente de relevância e segundo em ordem crescente de tempode deslocamento. O tempo de permanência será sempre o tempo sugerido de visita, atributovisitTime presente na Figura 7, determinado empiricamente pela equipe.

A Figura 12 ilustra as telas de um itinerário gerado pelo aplicativo. Foram consideradoscomo local de partida a sede centro da UTFPR campus Curitiba, duração do passeio de 8dias (de 24/05/2018 à 31/05/2018), horário de início diário para às 09:00 horas, horário detérmino diário para às 19:00 horas, com todos os grupos de locais selecionados e considerandoa influência do clima. O dia ilustrado é o segundo dia (25/05/2018).

Para cada local do itinerário são exibidos os seguintes elementos: foto, nome, horáriode visita, descrição resumida e os botões ”Detalhes”, ”Clima” e ”Navegar”. Conforme indica aFigura 12, a recomendação é que o usuário visite primeiro o Parque Tanguá, com duração devisita de 2 horas. O instante de início da visita está indicado como às 09:26, apesar do horário


Figura 12 – Telas representando o itinerário para o segundo dia de passeioFonte: Autoria própria

de início ter sido definido para às 09:00, pois 26 minutos é o tempo de deslocamento de carrodo seu local de partida até o parque.

Após visitar o Parque Tanguá o usuário deve se dirigir ao próximo item do itinerário,o Parque Tingui. O tempo de deslocamento de um local para outro via carro é de 8 minutos.Se necessário é possível alterar o meio de locomoção de carro para a pé pressionando o botãosimbolizado por duas flechas ao lado do tempo de deslocamento. Nesse caso, é importanteressaltar que apenas os tempos de início e término de visita dos próximos locais daquele mesmodia serão atualizados. Como o tempo de deslocamento a pé na maioria dos casos é superior aotempo via carro, é possível que o horário de término do passeio seja ultrapassado. A Figura 13ilustra o oitavo dia do itinerário e evidencia a diferença entre os tempos de deslocamento. Aalteração é bastante significativa, passando de 9 para 44 minutos.

Ao pressionar o botão ”Detalhes” a tela ilustrada pela Figura 14 é exibida. Essa contémo nome, foto do local, sua descrição completa e demais informações complementares, como aque grupo(s) pertence, sua relevância, tempo sugerido para visita e se é ou não dependente doclima.

A opção ”Clima” pode ser acessada independentemente do usuário ter selecionadoou não a opção ”Considerar a previsão do tempo dos próximos 7 dias para a construção


Figura 13 – Telas representando o itinerário para o oitavo dia de passeioFonte: Autoria própria

do itinerário” na tela anterior. Os detalhes do clima são ilustrados pela Figura 15. Na partesuperior da tela é indicado o dia do passeio, a temperatura média e um ícone que exibe umresumo das condições climáticas. O resumo é obtido através da leitura da variável icon, aqual possui os seguintes valores: dia limpo, noite limpa, chuva, nublado, parcialmente nubladodurante o dia e parcialmente nublado durante a noite. No quadro abaixo são descritas demaisinformações complementares, como temperatura mínima e máxima, probabilidade e intensidadede precipitação, nebulosidade (taxa percentual em que o céu está encoberto por nuvens),umidade relativa do ar, velocidade dos ventos, pressão atmosférica e horário do nascer e pôrdo sol.

A terceira opção presente em cada local do itinerário, ”Navegar”, redireciona o usuáriopara o aplicativo Google Maps, definindo como ponto de partida sua localização atual (obtidapor meio do sensor GPS do dispositivo) e como destino o local selecionado. É possível entãoselecionar a rota desejada (a pé, carro, ônibus, bicicleta ou aplicativos de mobilidade urbana) eutilizar a navegação GPS do Google pressionando o botão ”Iniciar”. A Figura 16 ilustra a telano Google Maps.


Figura 14 – Tela de detalhes de um localFonte: Autoria própria

6.3 Utilizar última rota salva

Cada itinerário gerado pela aplicativo é salvo localmente no dispositivo e pode serrestaurado por meio da opção "UTILIZAR ÚLTIMA ROTA SALVA", presente na Figura 9.Apenas um único itinerário pode ser salvo, ou seja, se um novo for gerado, o anterior serásobrescrito. Ele será restaurado de maneira idêntica à qual foi salvo (como ilustrado pelaFigura 12 e Figura 13). Independente do clima ter sido considerado para a geração, ele não seráconsultado novamente. Deste modo, como as previsões são mais precisas conforme os dias seaproximam, um dia que foi considerado chuvoso anteriormente pode não ser mais consideradoe vice-versa.

Antes de efetuar a restauração o aplicativo irá confirmar a ação do usuário (Figura 17)e informar os dados da rota salva, como o dia de início, horário de início e duração do passeio.Ele também irá alertar o usuário que não será possível visualizar dados meteorológicos de diaspassados.


Figura 15 – Tela representando a previsão meteorológica do diaFonte: Autoria própria

6.4 Locais para conhecer

Esta opção permite a visualização de todos os 45 locais presentes no banco de dadosdo aplicativo. Os locais estão dispostos em um formato de lista vertical de fácil navegação.Representa uma opção, por exemplo, ao usuário que não deseja construir propriamente umitinerário. Através dessa opção é possível ter uma noção das principais atrações turísticas quea cidade de Curitiba oferece, conhecendo ainda seus detalhes e acessando rapidamente umarota para acesso. Essa tela pode ser visualizada por meio da Figura 18.

Se o botão ”DETALHES” for pressionado uma tela semelhante à indicada pelaFigura 14 será exibida, informando a descrição completa do local, tempo sugerido de passeio,grupo(s) a que pertence, relevância, dependência do clima e sua foto. O botão ”ROTA” tambémpossui a mesma função já descrita na Subseção 6.2. O usuário é redirecionado para o aplicativodo Google Maps e é possível selecionar uma rota (a pé, carro, ônibus, bicicleta ou aplicativosde mobilidade urbana) e utilizar a navegação GPS do Google (Figura 16).

O presente capítulo apresentou todos os resultados obtidos no desenvolvimento doaplicativo, tanto em telas quanto em funcionalidades. O próximo capítulo apresenta a conclusãodo documento, fazendo um estudo sobre tudo o que foi realizado, assim como explanando


Figura 16 – Tela representando navegação para local desejado no aplicativo do Google MapsFonte: Autoria própria

sobre possíveis trabalhos futuros a partir do que foi feito.


Figura 17 – Alerta solicitando confirmação do usuário para restaurar última rota salvaFonte: Autoria própria

Figura 18 – Telas com locais para conhecerFonte: Autoria própria

39

7 CONCLUSÃO

Apesar da Linha Turismo ser uma boa alternativa para alguns, ela possui alguns pontosa serem observados. Não representa uma boa opção para aqueles que desejam conhecer ouse deslocar pela cidade por diversos dias, uma vez que sua taxa de embarque não possui umvalor muito acessível. Outro fator é que ela não permite a seleção de categorias de locaispara visita, passando por todos os pontos oferecidos. Para mitigar esses e outros problemas,o aplicativo proposto oferece a possibilidade de escolha das categorias dos locais para visita,além de dividi-los na quantidade de dias desejados. Dessa maneira, é oferecido um itinerárioturístico ao usuário que adequa-se à sua realidade.

Outro fator que faz com que um aplicativo móvel seja um ótima opção para funcionarcomo um guia turístico é a facilidade no seu uso e sua ampla disponibilidade para a maioria dosturistas. Isto se deve ao fato de que smartphones são cada vez mais populares, principalmentese pensarmos na população que tem a oportunidade de realizar o turismo.

As duas metodologias utilizadas durante o projeto complementaram-se, de modo queambas foram cruciais para o desenvolvimento correto do aplicativo. O processo de DesignThinking foi aplicado principalmente para definir o problema que o projeto desejava mitigar, queé a dificuldade do visitante em criar um itinerário turístico na cidade de Curitiba. Esse processotambém fez com que a equipe conseguisse criar o design das telas de maneira que pôde servalidada por possíveis usuários do aplicativo. Enquanto ocorriam as etapas de prototipaçãoe teste do Design Thinking, começou-se o processo do Modelo em V, dando início à escritados requisitos do projeto e definição dos casos de uso (Os quais podem ser observados noApêndice A. Com o uso desta metodologia algumas mudanças no projeto ocorreram durante oseu desenvolvimento, de forma a refinar quais funcionalidades realmente agregam valor para osusuários do aplicativo.

Uma dificuldade encontrada durante o desenvolvimento do projeto foi a limitação derequisições da versão gratuita da Google Matrix API. No momento de criar um itinerário, énecessária a obtenção das distâncias entre todos os pontos. Assim, levando em conta que sãomais de 40 locais cadastrados, são necessários mais de 1.600 cálculos de distâncias, ultrapassandoos 1.000 cálculos diários permitidos na versão gratuita. Para contornar a necessidade de todasessas requisições, optou-se por previamente guardar os dados de distâncias no próprio bancode dados da aplicação. Ainda que o banco de dados não seja local, seu tempo de resposta émenor que o de requisição da API, culminando na geração mais rápida do itinerário.

O fato do usuário poder visualizar o seu último itinerário salvo no próprio dispositivofaz com que o aplicativo também possa ser usado sem conexão com a internet (modo offline).Pensando em turistas que não adquiriram um pacote de internet móvel, ou seja, aqueles queestão usando somente internet em redes Wi-fi, a possibilidade de acompanhar os locais doitinerário sem a necessidade de conexão se torna muito valioso e útil.

Capítulo 7. CONCLUSÃO 40

A possibilidade de levar em conta o clima na geração de um itinerário é uma dasprincipais funcionalidades que diferenciam o projeto de outros aplicativos já existentes. Estaferramenta, principalmente em uma cidade que chove com frequência como Curitiba, trazmuito valor para o aplicativo, pois muitos locais turísticos se tornam menos agradáveis ou atéimpossíveis de se visitar com chuva, como é o caso do Parque Barigui (planejado para alagarem períodos de chuva, impedindo enchentes e alagamentos na cidade (AZEVEDO, 2011)).

7.1 TRABALHOS FUTUROS

No que se refere a trabalhos futuros, há diversas possibilidades. O aplicativo propostopossui uma ampla capacidade de expansão. Algumas funcionalidades adicionais incluem:

• Adição de mais informações sobre cada local - isso incrementaria ainda mais arelevância da opção ”Locais para conhecer” (Subseção 6.4). Os usuários que não desejamgerar um itinerário por intermédio do aplicativo, podem fazer uso de informações maiscompletas para construir o seu próprio ou simplesmente ter uma visão ampla dos locaisda cidade. Poderiam ser disponibilizados dados como: história dos locais, horários defuncionamento (para dias de semana e finais de semana), valores de admissão, restaurantespróximos, se é acessível para pessoas com necessidades especiais, se é recomendado paracrianças, se possui wifi, entre outros.

• Monetização - há também a possibilidade de monetizar a aplicação divulgando o serviçode hotéis, restaurantes ou passeios pagos. Para implementar essa funcionalidade, serianecessária a criação de uma plataforma web para uso dos clientes, de forma que pudessemgerenciar as ofertas cadastradas.

• Integração com serviços da cidade - além de simplesmente disponibilizar informaçõesatualizadas sobre os eventos da cidade, eles também poderiam ser utilizados para aconstrução do itinerário. Outro serviço disponibilizado por Curitiba é a Linha Turismo. Oaplicativo poderia gerar um itinerário especial para os usuários que desejam utilizá-la,considerando suas particularidades, como horário de saída e chegada dos ônibus, o númerode embarques e desembarques permitidos e os locais em que passa.

As demais alterações podem ser realizadas principalmente em três frentes: algoritmopara cálculo de itinerário, implementação de ferramentas colaborativas e personalização de umitinerário já criado. Algumas sugestões para o algoritmo são:

• Maior sensibilidade às condições climáticas - ao invés de serem obtidos para cadadia, a previsão do tempo poderia ser obtida de hora em hora, fazendo com que o algoritmopudesse avaliar melhor a probabilidade de precipitação do momento. Outra possibilidadeé que os locais pudessem ser remanejados entre os dias. Isso possibilitaria que aquelesque não dependem do clima, como museus, fossem menos frequentados em dias limpos,ainda que tivessem alta relevância.

• Não permitir a seleção de locais de um mesmo grupo em sequência - por vezes,


o algoritmo fornece uma rota com locais muito semelhantes seguidos. Não é agradávelvisitar uma sequência de museus ou shoppings, por exemplo.

• Seleção de perfil do passeio - outros aplicativos com proposta semelhante permitemque o usuário possa selecionar o perfil do passeio, gerando rotas mais adequadas, porexemplo, para famílias, casais, turistas que desejam passear em um ritmo mais intenso,aventureiros, etc.

• Dias e horários flexíveis - permitir a possibilidade de seleção de dias espaçados, isto é,com intervalos entre si. Os horários de início e término também poderiam ser variáveispara os dias desejados, não um valor fixado para todos.

• Calcular o melhor caminho entre os pontos turísticos - atualmente o algoritmoescolhe os pontos turísticos de acordo com a relevância, utilizando a distância somentepara “desempatar” quando dois locais tem a mesma relevância. Porém, a distâncialevada em conta é aquela entre o usuário e os pontos turísticos, e não entre os próprioslocais, ou seja, não há uma garantia de que o próximo local do itinerário é o mais perto.Uma solução para esse problema pode ser a utilização de um mapa auto-organizávelde Kohonen (HAYKIN, 2007) com aprendizado de Winner takes all (RAUBER, 2005),conforme proposto por (ABREU, 2015) para o problema clássico do caixeiro viajante(LAPORTE, 1992).

Algo que aumentaria consideravelmente a complexidade do projeto seria a possibilidadede edição de um itinerário já criado. Atualmente não é possível fazer nenhuma modificação(caso deseje alterá-lo o usuário deve refazer todo processo, escolhendo parâmetros diferentesdos originais). Algumas possibilidades de edição incluem:

• Adição de pausas - úteis para representar o momento das refeições ou qualquer tipode intervalo.

• Alteração da ordem de locais - permitir que a ordem de locais para visita em umitinerário possa ser alterada, dentro de um mesmo dia ou em dias diferentes.

• Adição e remoção de locais - permitir que locais possam ser adicionados, de acordocom aqueles cadastrados no banco ou de novos locais, bem como sua remoção.

• Alteração no tempo de visita - o turista não ficaria mais limitado ao tempo sugeridode permanência nos locais. A alteração também deveria considerar os horários defuncionamento, alertando o usuário nos casos de alguma inadequação.

Cada vez mais presentes no cotidiano, as ferramentas colaborativas de softwarepermitiriam maior interação entre os turistas de cidade. Além de permitir o compartilhamentode informações em redes sociais, algumas sugestões são:

• Adição de novas fotos - da mesma forma que a aplicação Google Maps permite, oenvio de fotos auxiliaria os usuários a visualizarem fotos mais recentes dos locais, tambémem diferentes horários, estações do ano e condições climáticas distintas.

• Sistema de avaliação - alguns itinerários poderiam ser disponibilizados para toda a


comunidade e essa poderia avaliar sua popularidade, com comentários e uma nota. Ositinerários com melhor avaliação seriam mais frequentemente sugeridos aos usuários.

• Alteração de relevância e tempo sugerido - locais com maior número de visitas emelhor avaliados, tornariam-se mais relevantes. O tempo sugerido também poderia seradaptado de acordo com o tempo de permanência média em cada local. Pode-se fazeruso do sensor GPS do aparelho para estimar sua localização.

• Sistema de pontuação e níveis - Assim como ocorre em diversos jogos digitais eaplicações colaborativas, poderia ser desenvolvido um sistema de níveis no aplicativo.Novos usuários iniciariam com sua conta no nível 1, de forma que quanto maior suapontuação, maior seria o seu nível. Para conseguir mais pontos é necessário colaborarcom a comunidade (avaliando itinerários, enviando fotos, fazendo avaliações, registrandoopiniões, entre outros). Contas com um nível alto poderiam receber algum tipo de bônusou permissões maiores dentro do aplicativo.

43

Referências

ABREU, A. d. Uma resolução do problema do caixeiro-viajante por mapa auto-organizávelcom aprendizado winner takes all. Revista brasileira de computação aplicada, v. 16, n. 1,2015. ISSN 2176-6649. Citado na página 41.

AGÊNCIA DE NOTÍCIAS DA PREFEITURA DE CURITIBA. Em 14 anos, número devisitantes dobrou em Curitiba. 2017. Disponível em: <http://www.curitiba.pr.gov.br/noticias/em-14-anos-numero-de-visitantes-dobrou-em-curitiba/43559>. Acesso em: 14 demaio de 2018. Citado 2 vezes nas páginas 1 e 2.

ANDROID DEVELOPERS. Versões da plataforma. 2018. Disponível em: <https://developer.android.com/about/dashboards/>. Acesso em: 17 de maio de 2018. Citado 2 vezes nas páginas7 e 8.

AVRAM, A. Google Firebase: back-end completo para aplicações web e mobile. 2016.Disponível em: <https://www.infoq.com/br/news/2016/07/google-firebase>. Acesso em: 16de maio de 2018. Citado na página 20.

AZEVEDO, G. Parques já não suportam enchentes. 2011. Dis-ponível em: <https://www.gazetadopovo.com.br/vida-e-cidadania/parques-ja-nao-suportam-enchentes-dp70pbc5eh5tddniwqt2tifda>. Acesso em: 23 dejunho de 2018. Citado na página 40.

CALLAHAM, J. Google says there are now 1.4 billion active Androiddevices worldwide. 2015. Disponível em: <http://www.androidcentral.com/google-says-there-are-now-14-billion-active-android-devices-worldwide>. Acesso em: 2de junho de 2018. Citado na página 6.

DAM, R. 5 Stages in the Design Thinking Process. 2018. Disponível em: <https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process>. Acesso em:04 de junho de 2018. Citado 2 vezes nas páginas 15 e 16.

EXAME. Curitiba é a 2a cidade brasileira melhor preparada para rece-ber visitantes. 2016. Disponível em: <https://exame.abril.com.br/negocios/dino/curitiba-e-a-2a-cidade-brasileira-melhor-preparada-para-receber-visitantes-dino89080165131/>. Acesso em: 25 de maio de 2018. Citado na página 1.

FERREIRA, J. C. V. Municípios Paranaenses: Origens e significados de seusnomes. Curitiba: Secretaria de Estado da Cultura, 2006. 340 p. Disponível em:<http://www.itcg.pr.gov.br/arquivos/File/Produtos_DGEO/Divisas_Municipais/Origens_Significados_nomes_municipios_pr.pdf>. Acesso em: 2 de junho de 2018. Citado na página 4.

HAYKIN, S. Redes Neurais: Princípios e Prática. 2. ed. [S.l.]: Bookman Editora, 2007.Citado na página 41.

INSTITUTO MUNICIPAL DE TURISMO. Pesquisa Linha Turismo. 2017. Disponível em:<http://multimidia.turismo.curitiba.pr.gov.br/2018/4/pdf/00002421.pdf>. Acesso em: 30 demaio de 2018. Citado na página 6.

http://www.curitiba.pr.gov.br/noticias/em-14-anos-numero-de-visitantes-dobrou-em-curitiba/43559

http://www.curitiba.pr.gov.br/noticias/em-14-anos-numero-de-visitantes-dobrou-em-curitiba/43559

https://developer.android.com/about/dashboards/

https://developer.android.com/about/dashboards/

https://www.infoq.com/br/news/2016/07/google-firebase

https://www.gazetadopovo.com.br/vida-e-cidadania/parques-ja-nao-suportam-enchentes-dp70pbc5eh5tddniwqt2tifda

https://www.gazetadopovo.com.br/vida-e-cidadania/parques-ja-nao-suportam-enchentes-dp70pbc5eh5tddniwqt2tifda

http://www.androidcentral.com/google-says-there-are-now-14-billion-active-android-devices-worldwide

http://www.androidcentral.com/google-says-there-are-now-14-billion-active-android-devices-worldwide

https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process

https://www.interaction-design.org/literature/article/5-stages-in-the-design-thinking-process

https://exame.abril.com.br/negocios/dino/curitiba-e-a-2a-cidade-brasileira-melhor-preparada-para-receber-visitantes-dino89080165131/



http://www.itcg.pr.gov.br/arquivos/File/Produtos_DGEO/Divisas_Municipais/Origens_Significados_nomes_municipios_pr.pdf

http://www.itcg.pr.gov.br/arquivos/File/Produtos_DGEO/Divisas_Municipais/Origens_Significados_nomes_municipios_pr.pdf

http://multimidia.turismo.curitiba.pr.gov.br/2018/4/pdf/00002421.pdf

Referências 44

INSTITUTO PARANAENSE DE DESENVOLVIMENTO ECONÔMICO E SOCIAL. Índice deDesenvolvimento Humano Municipal - IDHM - 2000: Anotações sobre o desempenhodo Paraná. Curitiba, 2003. 340 p. Disponível em: <http://www.ipardes.gov.br/biblioteca/docs/idhm_2000.pdf>. Acesso em: 11 de junho de 2018. Citado na página 4.

JORNAL DE TURISMO. Smartphones são usados por 85% das pessoas quebuscam por viagens. 2017. Disponível em: <http://www.abeoc.org.br/2017/11/smartphones-sao-usados-por-85-das-pessoas-que-buscam-por-viagens/>. Acesso em: 14 demaio de 2018. Citado na página 1.

LAPORTE, G. The traveling salesman problem: An overview of exact an approximate algorithms.European Journal of Operational Research, v. 59, n. 2, 1992. Citado na página 41.

LEI, W. Tourism management system. 2016. Disponível em: <https://worldwide.espacenet.com/publicationDetails/biblio?CC=CN&NR=205028328U&KC=U&FT=D&ND=3&date=20160210&DB=&locale=en_EP>. Acesso em: 2 de junho de 2018. Citado na página 14.

PALLADIUM. Palladium Curitiba Comemora 9 anos e Celebra Bons Re-sultados. 2016. Disponível em: <http://www.palladiumcuritiba.com.br/agenda/palladium-curitiba-comemora-9-anos-e-celebra-bons-resultados?agenda=4>. Acessoem: 28 de maio de 2018. Citado na página 5.

PAUL, R. Dream (sheep++): A developer’s introduction to GoogleAndroid. 2009. Disponível em: <https://arstechnica.com/gadgets/2009/02/an-introduction-to-google-android-for-developers/>. Acesso em: 19 de maio de 2018.Citado na página 8.

PROSCHOFSKY, A. Google: "Android is the Linux desktop dreamcome true". 2011. Disponível em: <https://derstandard.at/1308186313932/Google-Android-is-the-Linux-desktop-dream-come-true>. Acesso em: 19 de maio de2018. Citado na página 8.

RASMUSSEN, J. et al. Digital mapping system. Google Patents, 2011. US Patent 7,894,984.Disponível em: <http://www.google.com/patents/US7894984>. Acesso em: 2 de junho de2018. Citado na página 13.

RAUBER, T. W. Redes neurais artificiais. Universidade Federal do Espírito Santo, 2005.Citado na página 41.

ROCHA, A. R. Cresce o uso de aplicativos em viagens. Veja pesquisa. 2016. Disponívelem: <http://blog.tribunadonorte.com.br/eturismo/83779>. Acesso em: 14 de maio de 2018.Citado na página 1.

SHARMA, N. The Beginner’s Guide to Android: Android Architecture. 2013. Disponívelem: <http://www.edureka.co/blog/beginners-guide-android-architecture/>. Acesso em: 2 dejunho de 2018. Citado na página 9.

SIMON, H. Sciences of the Artificial. 3. ed. Universidade Estadual de Campinas: MIT Press,1996. Citado na página 15.

SUPERINTERESSANTE. Conheça a história do Android, o sistema operacio-nal mobile da Google. 2012. Disponível em: <https://super.abril.com.br/galeria/conheca-a-historia-do-android-o-sistema-operacional-mobile-da-google/>. Acesso em: 17 demaio de 2018. Citado na página 7.

http://www.ipardes.gov.br/biblioteca/docs/idhm_2000.pdf

http://www.ipardes.gov.br/biblioteca/docs/idhm_2000.pdf

http://www.abeoc.org.br/2017/11/smartphones-sao-usados-por-85-das-pessoas-que-buscam-por-viagens/

http://www.abeoc.org.br/2017/11/smartphones-sao-usados-por-85-das-pessoas-que-buscam-por-viagens/

https://worldwide.espacenet.com/publicationDetails/biblio?CC=CN&NR=205028328U&KC=U&FT=D&ND=3&date=20160210&DB=&locale=en_EP



http://www.palladiumcuritiba.com.br/agenda/palladium-curitiba-comemora-9-anos-e-celebra-bons-resultados?agenda=4

http://www.palladiumcuritiba.com.br/agenda/palladium-curitiba-comemora-9-anos-e-celebra-bons-resultados?agenda=4

https://arstechnica.com/gadgets/2009/02/an-introduction-to-google-android-for-developers/

https://arstechnica.com/gadgets/2009/02/an-introduction-to-google-android-for-developers/

https://derstandard.at/1308186313932/Google-Android-is-the-Linux-desktop-dream-come-true

https://derstandard.at/1308186313932/Google-Android-is-the-Linux-desktop-dream-come-true

http://www.google.com/patents/US7894984

http://blog.tribunadonorte.com.br/eturismo/83779

http://www.edureka.co/blog/beginners-guide-android-architecture/

https://super.abril.com.br/galeria/conheca-a-historia-do-android-o-sistema-operacional-mobile-da-google/

https://super.abril.com.br/galeria/conheca-a-historia-do-android-o-sistema-operacional-mobile-da-google/

Referências 45

VARGAS, J. Conheça o Android Studio, a ferramenta oficial deApps para Android. 2018. Disponível em: <https://jeanvargas.com.br/conheca-o-android-studio-ferramenta-oficial-para-o-desenvolvimento-de-apps-para-android/>. Acesso em: 21 de junho de 2018. Citado na página 17.

VEJA. Aeroporto Internacional de Curitiba é o mais bem avali-ado do país. 2018. Disponível em: <https://veja.abril.com.br/blog/parana/aeroporto-internacional-de-curitiba-e-o-melhor-avaliado-do-brasil/>. Acesso em: 2 dejunho de 2018. Citado na página 6.

VIANA, D. Kotlin: A nova linguagem oficial para desenvolvimentoAndroid. 2017. Disponível em: <https://www.treinaweb.com.br/blog/kotlin-a-nova-linguagem-oficial-para-desenvolvimento-android/>. Acesso em: 22 demaio de 2018. Citado na página 18.

https://jeanvargas.com.br/conheca-o-android-studio-ferramenta-oficial-para-o-desenvolvimento-de-apps-para-android/



https://veja.abril.com.br/blog/parana/aeroporto-internacional-de-curitiba-e-o-melhor-avaliado-do-brasil/

https://veja.abril.com.br/blog/parana/aeroporto-internacional-de-curitiba-e-o-melhor-avaliado-do-brasil/

https://www.treinaweb.com.br/blog/kotlin-a-nova-linguagem-oficial-para-desenvolvimento-android/

https://www.treinaweb.com.br/blog/kotlin-a-nova-linguagem-oficial-para-desenvolvimento-android/

46

APÊNDICE A – PROJETO DE DESENVOLVIMENTO DE SOFTWARE

As etapas de planejamento para desenvolvimento do aplicativo são descritas nesteapêndice. Compreendem o levantamento de requisitos funcionais e não funcionais, definição deum cronograma, identificação de riscos e criação de diagramas de caso de uso.

A.1 Requisitos funcionais

RF1 O software deverá permitir a definição de uma nova rota, considerando os seguintesaspectos:

• Dia de início e término do passeio;• Horário de início e término do passeio (único para todos os dias);• Local de partida;• Tipos de lugares (parques, bosques e praças, museus, restaurantes, pontos turísticos,

locais de compras).

RF2 O software deverá determinar a melhor rota para o usuário, considerando as entradasfornecidas, o grau de relevância dos locais, tempo de deslocamento e tempo sugerido depermanência.RF3 O software deverá calcular a rota do usuário, considerando o deslocamento entre locaisde carro.RF4 O software deverá permitir a utilização da última rota salva.RF5 O software deverá salvar a rota do usuário assim que ela for gerada.RF6 O software deverá informar dados gerais e detalhados para a previsão do tempo em todosos dias do passeio.RF7 O software deverá apresentar detalhes sobre os pontos turísticos, como foto, descrição etempo de permanência sugerido.RF8 O software deverá redirecionar o usuário para o aplicativo do Google maps, com a rotapara o local desejado já calculada.RF9 O software deverá informar qual o tempo de deslocamento entre os locais do itinerário,tanto de carro quanto a pé.

A.2 Requisitos não funcionais

RNF1 Os dados da última rota do usuário serão salvos localmente no próprio dispositivo.RNF2 As fotos dos locais serão salvas em um servidor externo.RNF3 A versão mínima da API Android utilizada será a recomendada pelo Android Studio(4.4.2).RNF4 O idioma do aplicativo será o português (Brasil).

APÊNDICE A. PROJETO DE DESENVOLVIMENTO DE SOFTWARE 47

RNF5 A linguagem de programaçaõ será o Java.RNF6 O sistema operacional de desenvolvimento será o Android.

A.3 Riscos

Os riscos do projeto serão expostos e avaliados nos Quadros 3, 4, 5 e 6. Em cadaum são expostas as seguintes informações: denominação, descrição, impacto, probabilidade eestratégias e ações para mitigar o risco.

Quadro 3 – Primeiro risco.

1o ETAPA: IDENTIFICAÇÃO DO RISCODenominação do risco: Dificuldade na utilização da API do Google MapsDescrição do Risco: A equipe pretende utilizar a API para calcular a menor rota eexibi-la ao usuário, entretanto ela nunca foi utilizada por nenhum membro da equipe.2o ETAPA: AVALIAÇÃO DO RISCOImpacto: Alto (X) Médio/Alto

( )Médio ( ) Médio/Baixo

( )Baixo ( )

Explique: A utilização correta da API é vital para que o projeto seja bem-sucedido.Probabilidade: Alto ( ) Médio/Alto


(X)Baixo ( )

Explique: A API é utilizada por uma grande quantidade de aplicações no mercado epossui ampla comunidade de desenvolvedores. Sua documentação em seu site oficialtambém é bastante completa.3o ETAPA: RESPOSTA AO RISCOEstratégias e Ações: Mitigar. Procurar avaliar a API o quanto antes para compreenderseu funcionamento e buscar implementar simples exemplos de uso.



Quadro 4 – Segundo risco.

1o ETAPA: IDENTIFICAÇÃO DO RISCODenominação do risco: Criação de uma interface gráfica agradável e intuitiva aousuário.Descrição do Risco: A implementação da interface gráfica é uma parte muito importantedo projeto, pois a facilidade do uso do aplicativo é um dos pontos fortes de seu uso.2o ETAPA: AVALIAÇÃO DO RISCOImpacto: Alto (X) Médio/Alto


( )Baixo ( )

Explique: A facilidade do uso do aplicativo é vital para que ele seja usado de maneirarápida e intuitiva.Probabilidade: Alto ( ) Médio/Alto

( )Médio (X) Médio/Baixo

( )Baixo ( )

Explique: Apesar de a implementação de uma interface gráfica agradável ser uma tarefadifícil, existem muitos aplicativos no mercado como exemplos para se basear.3o ETAPA: RESPOSTA AO RISCOEstratégias e Ações: Conviver. Deve-se buscar opiniões sobre a interface do aplicativodurante a implementação, melhorando-se o design de acordo com as críticas.


Quadro 5 – Terceiro risco.

1o ETAPA: IDENTIFICAÇÃO DO RISCODenominação do risco: Dificuldade na utilização da base de dados do IPPUC.Descrição do Risco: A base de dados do IPPUC pode ser de difícil manipulação.2o ETAPA: AVALIAÇÃO DO RISCOImpacto: Alto ( ) Médio/Alto

( )Médio (X) Médio/Baixo

( )Baixo ( )

Explique: A não utilização do dados do IPPUC fará com que os pontos de ônibuspresentes no aplicativo não seja tão fidedigna á realidade.Probabilidade: Alto ( ) Médio/Alto


(X)Baixo ( )

Explique: Existe um grupo de alunos e professores que trabalham com essa base dedados, sendo possível a requisição de assistência a esse grupo.3o ETAPA: RESPOSTA AO RISCOEstratégias e Ações: Mitigar. Pode-se utilizar os dados de pontos de ônibus presentesna API do Google.



Quadro 6 – Quarto risco.

1o ETAPA: IDENTIFICAÇÃO DO RISCODenominação do risco: Dificuldade em encontrar locais próximos para alimentação.Descrição do Risco: A API do Google não menciona todos os locais para alimentação.2o ETAPA: AVALIAÇÃO DO RISCOImpacto: Alto ( ) Médio/Alto


( )Baixo (X)

Explique: Os locais presentes na API são suficientes para calcular o itinerário.Probabilidade: Alto ( ) Médio/Alto


( )Baixo (X)

Explique: Apesar de não haver todos os locais, os que existem na API são, provavelmente,suficientes.3o ETAPA: RESPOSTA AO RISCOEstratégias e Ações: Mitigar. Contatar pessoas que trabalham nos locais em que nãoexistem locais próximos na API e descobrir se realmente não existem locais próximospara alimentação.


A.4 Diagrama de casos de uso

O diagrama de casos de uso pode ser visto na Figura 19. Os detalhamentos de cadaum estão presentes nos Quadros 7, 8, 9 e 10.

Figura 19 – Diagrama de casos de uso do aplicativo.Fonte: Autoria própria


Quadro 7 – Especificação do caso de uso "Criar itinerário"

Nome Criar itinerárioAtores UsuárioDescrição Caso de uso executado quando o usuário

deseja criar um novo itinerário.Pré-condições O dispositivo que o usuário está utilizando

deve estar conectado à internet.Pós-condições Gera-se um itinerário e o mostra ao usuário.

Fluxo básicoAções do atores Ações do sistema1 - O usuário pressiona o botão “Criar itine-rário” na tela inicial do aplicativo.

2 - Apresenta uma interface em que existemtodos os campos necessários para a criaçãode um itinerário.

3 - O usuário preenche todos os campos(Local de partida, Primeiro dia de passeio,Último dia de passeio, Horário de início, Ho-rário de término, Locais de interesse e se querconsiderar o clima) e pressiona ”Finalizar”.

4 - Verifica as informações conforme as Re-gras de Negócio RN001 até a RN009. Casoalguma não seja atendida, vai para 4a.5 - Gera um itinerário baseado nas infor-mações apresentadas e inicia o caso de uso"Apresentar caso de uso criado".

Regras de negócio[RN001] Não é possível selecionar o dia atual como primeiro dia de passeio caso já tenhase passado das 16:00 horas.[RN002] Há um limite de 7 dias para seleção do primeiro dia de passeio, contando apartir da data atual.[RN003] Há um limite de 7 dias para seleção do último dia de passeio, contando a partirdo primeiro dia selecionado.[RN004] Não é possível selecionar o último dia de passeio caso o primeiro ainda nãoesteja definido.[RN005] O horário de início deve estar compreendido entre às 05:00 e 16:00 horas.[RN006] O horário de término deve vir após o horário de início e deve estar compreendidoentre às 08:00 e 20:00 horas.[RN007] O passeio deve ter uma duração de pelo menos 3 horas.[RN008] Não é possível selecionar o horário de início caso os dias de início e término dopasseio ainda não estejam definidos.[RN009] Não é possível selecionar o horário de término caso o horário de início ainda nãoesteja definido.


Fluxo alternativoAções do atores Ações do sistema1 - A qualquer momento o usuário selecionavoltar.

2 - Desconsidera informações digitadas e en-cerra o caso de uso.

Fluxo de exceçãoAções do atores Ações do sistema

4a - Caso alguma Regra de Negócio não sejaatendida, apresenta uma mensagem de alertae volta para o fluxo básico 2.


Quadro 8 – Especificação do caso de uso "Utilizar última rota salva"

Nome Utilizar última rota salvaAtores UsuárioDescrição Caso de uso executado quando o usuário

deseja recarregar o último roteiro usado.Pré-condições O dispositivo que o usuário está utilizando

deve estar conectado à internet.Pós-condições Recupera-se o último itinerário e o mostra

ao usuário.Fluxo básico

Ações do atores Ações do sistema1 - O usuário pressiona o botão “Utilizarúltima rota salva” na tela inicial do aplicativo.

2 - Mostra um alerta, questionando se o usuá-rio quer restaurar o último itinerário criado.

3 - O usuário responde positivamente a per-gunta. Caso responda negativamente, vaipara 3a.

4 - Recupera a rota salva e vai para o casode uso "Apresentar itinerário criado".

Regras de negócioNão há neste caso de uso.

Fluxo alternativoNão há neste caso de uso.


Fluxo de exceçãoAções do atores Ações do sistema

3a - Volta para a tela inicial do aplicativo.


Quadro 9 – Especificação do caso de uso "Locais para conhecer"

Nome Locais para conhecerAtores UsuárioDescrição Caso de uso executado quando o usuário

deseja visualizar todos os locais presentes noaplicativo.

Pré-condições O dispositivo que o usuário está utilizandodeve estar conectado à internet.

Pós-condições Mostra uma lista com todos os locais paraconhecer.

Fluxo básicoAções do atores Ações do sistema1 - O usuário pressiona o botão “Locais paraconhecer” na tela inicial do aplicativo.

2 - Apresenta uma lista com todos os locaispresentes no banco de dados. Cada item temum botão “Detalhes” e outro "Rota".

3 - O usuário pressiona o botão "Detalhes".4 - Apresenta um tela com todos os detalhesdo local escolhido.

5 - O usuário pressiona o botão "Rota".6 - Redireciona o usuário para o aplicativoGoogle Maps, com a rota do seu local atualpara o ponto escolhido.



2 - Volta para a tela inicial do aplicativo.Fluxo de exceção

Não há neste caso de uso.Fonte: Autoria própria


Quadro 10 – Especificação do caso de uso "Apresentar itinerário criado"

Nome Apresentar itinerário criadoAtores UsuárioDescrição Caso de uso executado após a criação de um

itinerário.Pré-condições O dispositivo que o usuário está utilizando

deve estar conectado à internet.Pós-condições Mostra o itinerário criado separado por dias.

Fluxo básicoAções do atores Ações do sistema

1 - Apresenta o itinerário criado em uma visãocom abas, onde cada aba é um dia distinto.Existe uma lista de locais em cada dia e emcada item existem três botões: “Detalhes”,“Clima” e “Navegar”. Entre dois itens existeum botão de troca de modo de transporte.

2 - O usuário pressiona o botão “Detalhes”de um dos itens.

3 - Apresenta uma interface com todos osdetalhes do local escolhido.

4 - O usuário pressiona o botão “Clima” deum dos itens.

5 - Apresenta um tela com as informaçõesclimáticas do local escolhido.

6 - O usuário pressiona o botão “Navegar”de um dos itens.

7 - Redireciona o usuário para o aplicativodo Google Maps, com a rota do ponto atualaté o local escolhido.

8 - O usuário pressiona o botão de trocar omodo de transporte.

9 - Muda o modo de transporte atual. Devealternar entre carro e a pé.




2 - Vai para o caso de uso Criar itinerário.Fluxo de exceção

Não há neste caso de uso.


Documents

DESENVOLVIMENTODEUMAPLICATIVOANDROIDPARA ...cristina/TCC_Nardi_Augustinho.pdf · 1 1 INTRODUÇÃO Elegante,modernaeorganizada,acidadedeCuritibaéa2a cidadebrasileiramais preparadapararecebervisitantes,perdendoapenasparaoRiodeJaneiro(EXAME,2016