UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
ROUTE: UM PROTÓTIPO PARA VISUALIZAÇÃO DE
INFORMAÇÕES DO TRÂNSITO EM TEMPO REAL
FELIPE NOGUEIRA DE SOUZA
BLUMENAU 2018
FELIPE NOGUEIRA DE SOUZA
ROUTE: UM PROTÓTIPO PARA VISUALIZAÇÃO DE
INFORMAÇÕES DO TRÂNSITO EM TEMPO REAL
Trabalho de Conclusão de Curso apresentado ao curso de graduação em Ciência da Computação do Centro de Ciências Exatas e Naturais da Universidade Regional de Blumenau como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação.
Prof. Aurélio Faustino Hoppe, Mestre – Orientador
BLUMENAU 2018
ROUTE: UM PROTÓTIPO PARA VISUALIZAÇÃO DE
INFORMAÇÕES DO TRÂNSITO EM TEMPO REAL
Por
FELIPE NOGUEIRA DE SOUZA
Trabalho de Conclusão de Curso aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II pela banca examinadora formada por:
______________________________________________________
Presidente: Prof. Aurélio Faustino Hoppe, Mestre – Orientador, FURB
______________________________________________________
Membro: Prof. Everaldo Artur Grahl, Mestre – FURB
______________________________________________________
Membro: Prof. Dalton Solano dos Reis, Mestre – FURB
Dedico este trabalho a todas as pessoas que de alguma maneira contribuíram para a realização deste trabalho, principalmente a minha família e namorada.
AGRADECIMENTOS
À minha família que sempre esteve e está do meu lado independentemente da situação, principalmente a minha mãe Rosana A. M. Nogueira de Souza, meu pai Celso Campos de Souza e minha irmã Júlia Nogueira de Souza.
Á minha namorada, Hana Beatriz Gieland, que sempre me apoia nas minhas escolhas. Aos meus amigos que direta ou indiretamente contribuíram para toda a formação e para o desenvolvimento deste trabalho.
Ao meu orientador, Aurélio Hoppe, que teve paciência e me incentivou apesar dos obstáculos.
O sucesso nasce do querer, da determinação e persistência em se chegar a um objetivo. Mesmo não atingindo o alvo, quem busca e vence obstáculos, no mínimo fará coisas admiráveis.
RESUMO
O tempo é um dos recursos mais preciosos na vida das pessoas, por isso cada ajuda possível para poupá-lo é de grande importância. Visando um trânsito cada vez mais inteligente e conectado, além do privilégio da maioria das pessoas possuírem um smartphone com GPS, este trabalho descreve a construção de um aplicativo Android colaborativo para coleta de informações do trânsito, verificando o menor trajeto entre dois pontos a partir de uma série histórica. O usuário poderá verificar os últimos trajetos percorridos além de consultar a situação das vias por dia da semana, período do mês e intervalo de horário. O aplicativo também mostrará ao usuário qual o melhor dia e horário para iniciar o percurso desejado. Para a construção do aplicativo foi utilizado o ambiente de desenvolvimento Android Studio, na linguagem Java. O servidor foi construído utilizando a linguagem de programação C#, com os recursos do .Net Core e Entity Framework. A hospedagem do banco de dados SQL Server e das APIs da aplicação foi feita na nuvem com o Microsoft Azure. Os resultados obtidos nos testes da aplicação com a colaboração dos usuários demonstram que o protótipo cumpriu seu objetivo, sendo capaz de mostrar com clareza as informações do trajeto desejado e também a melhor data para percorre-lo.
Palavras-chave: Trânsito. Trânsito inteligente. Geolocalização. .Net Core. Entity Framework. Azure.
ABSTRACT
Time is one of the most valuable resource in people's lives, so every possible help to save it is of great importance. Aiming at an increasingly intelligent and connected traffic, plus the privilege of most of the people own a smartphone with GPS, this paper describes the construction of a collaborative Android application for collecting traffic information, verifying the smallest path between two points from a historical series. The user will be able to check the last routes traveled besides to consult the situation of the routes by day of the week, period of the month and interval of time. The application will also show to the user the best day and time to start the desired route. For the construction of the application, it was used the Android Studio development environment, in the Java language. The server was built using the C# programming language, with the features of .Net Core and Entity Framework. Hosting the SQL Server database and application APIs was done in the cloud with Microsoft Azure. The results obtained in the tests of the application with the users' collaboration demonstrate that the prototype fulfilled its objective, being able to show clearly the information of the desired path and also the best date to go through it.
LISTA DE FIGURAS
Figura 1 - Pontes de Konigsberg ... 20
Figura 2 - Distância entre dois pontos ... 22
Figura 3 - Versão do Sistema para dispositivos móveis ... 24
Figura 4 - Hardware do sistema desenvolvido ... 25
Figura 5 - Resultado do cálculo da rota de menor custo ... 26
Figura 6 - Grafo gerado a partir dos pontos coletados ... 26
Figura 7 - Mapa do administrador ... 28
Figura 8 - Mapa do usuário... 29
Figura 9 - Diagrama de casos de uso ... 31
Figura 10 - Arquitetura da aplicação ... 32
Figura 11 - Diagrama de classes startup ... 34
Figura 12 - Diagrama de classes Entity Framework ... 35
Figura 13 - Diagrama de classes API de usuário ... 36
Figura 14 - Diagrama de classes da API de rotas ... 37
Figura 15 - Tela de login e tela de cadastro de usuário ... 39
Figura 16 - Tela principal ... 39
Figura 17 - Tela principal com os filtros disponíveis ... 40
Figura 18 - Tela principal com pesquisa e tela principal com melhor rota ... 41
Figura 19 - Tela das localizações, tela com o trajeto percorrido e tela de perfil do usuário .... 42
LISTA DE QUADROS
Quadro 1 - Método de inicialização ... 21
Quadro 2 - Método de relaxamento ... 21
Quadro 3 - Algoritmo de Dijkstra... 21
Quadro 4 - Requisitos Funcionais ... 30
Quadro 5 - Requisitos Não Funcionais ... 30
Quadro 6 - Inicialização do servidor ... 42
Quadro 7 - Configuração das tabelas do banco em C#... 43
Quadro 8 - Configuração da tabela Usuario ... 43
Quadro 9 - Adicionar informações da rota ... 45
Quadro 10 - Inicialização da malha viária ... 46
Quadro 11 - Algoritmo de Dijkstra... 48
Quadro 12 - Busca da melhor rota entre dois pontos ... 49
Quadro 13 – Atualização de melhor rota ... 50
Quadro 14 - Comparativo entre este trabalho e os trabalhos correlatos ... 54
Quadro 15 - JSON armazenado ... 63
Quadro 16 - Questionário de perfil do usuário ... 64
Quadro 17 - Questionário de atividades do usuário ... 65
LISTA DE TABELAS
Tabela 1 - Perfil dos usuários ... 51 Tabela 2 - Atividades do usuário ... 52 Tabela 3 - Usabilidade do aplicativo ... 53
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface EF - Entity Framework
GPS – Global Positioning System HTML – HyperText Markup Language HTTP – HyperText Transfer Protocol JSON – JavaScript Object Notation MER – Modelo Entidade Relacionamento MVC – Model View Controller
ORM - Object Relational Mapper REST – Representational State Transfer RF – Requisitos Funcionais
RNF – Requisitos Não Funcionais RTC – Real Time Clock
SaaS – Software as a Service
SUMÁRIO
1 INTRODUÇÃO ... 14 1.1 OBJETIVOS ... 15 1.2 ESTRUTURA ... 15 2 FUNDAMENTAÇÃO TEÓRICA ... 16 2.1 MONITORAMENTO DE TRÂNSITO ... 16 2.2 SISTEMAS COLABORATIVOS ... 182.3 GRAFOS E O ALGORITMO DE DIJKSTRA ... 19
2.4 GEOLOCALIZAÇÃO E GOOGLE MAPS API ... 22
2.5 TRABALHOS CORRELATOS ... 23
2.5.1 Bustracker: Sistema de rastreamento para transporte coletivo ... 23
2.5.2 Automação do tráfego de veículos: Sistema de busca de caminho de menor custo entre dois pontos ... 25
2.5.3 Cadêbusão: Aplicativo colaborativo para acompanhar a localização do ônibus ... 27
3 DESENVOLVIMENTO ... 30 3.1 REQUISITOS ... 30 3.2 ESPECIFICAÇÃO ... 31 3.2.1 Casos de Uso ... 31 3.2.2 Arquitetura ... 32 3.2.3 Diagramas de classes... 33 3.3 IMPLEMENTAÇÃO ... 37
3.3.1 Técnicas e ferramentas utilizadas... 37
3.3.2 Aplicativo móvel ... 38
3.3.3 Servidor ... 42
3.4 ANÁLISE DOS RESULTADOS ... 50
3.4.1 Análise de perfil do usuário ... 51
3.4.2 Análise de atividades do usuário ... 52
3.4.3 Análise de usabilidade do aplicativo ... 53
3.4.4 Comparação com trabalhos correlatos ... 53
4 CONCLUSÕES ... 56
4.1 EXTENSÕES ... 57
APÊNDICE A – MODELO ENTIDADE RELACIONAMENTO... 62 APÊNDICE B – QUESTIONÁRIO DE AVALIAÇÃO DE USABILIDADE E
14
1 INTRODUÇÃO
É essencial que a locomoção seja feita de forma mais inteligente, a partir de informações seguras e rotas otimizadas - que provêm da tecnologia de geolocalização, para evitar congestionamentos e atrasos (ODIARIO, 2017).
Geolocalização é a arte de descobrir aonde você está no mundo e (opcionalmente) compartilhar essa informação com as pessoas que você confia. Há mais de uma maneira de descobrir aonde você está — seu endereço IP, sua conexão de rede sem fio, com que torre de celular seu telefone está falando, ou hardware GPS dedicado que calcula latitude e longitude da informação enviada por satélites no céu. (PILGRIM, 2010, p. 1).
Conforme Ribeiro (2012), a geolocalização é um conceito relativamente novo, criado em 2009 e, que se tornou uma grande tendência com a popularização dos smartphones. Esse conceito possui aplicações tanto para o uso pessoal, quanto para o uso corporativo. Em geral, a geolocalização faz cada vez mais parte do cotidiano, coletando informações e rotas otimizadas. É possível compartilhar a posição atual com amigos, chamar um táxi ou até mesmo lembrar onde estacionou o carro (RIBEIRO, 2012).
O uso da geolocalização permite identificar horários de chegada e saída e o controle de rotas. Além disso, é possível verificar em tempo real paradas não autorizadas, desvios de trajetos e o tempo estimado de chegada em um local (VICARI, 2016).
As cidades brasileiras ainda usam pouco da tecnologia para melhoria da gestão de trânsito. De acordo com levantamento feito pela FGV Projetos em 31 prefeituras – 20 capitais e 11 municípios com mais de 200 mil habitantes – embora todos reconheçam a importância da tecnologia, menos de 20% a utilizam para controlar o trânsito (CZERWONKA, 2014, p. 1).
Com o crescimento desenfreado das cidades sem um planejamento adequado para a mobilidade urbana que atenda e priorize as pessoas, pensando no coletivo e em como oferecer opções melhores de transporte o problema do trânsito se agrava gradualmente (E-MOVING, 2017). Segundo Salatiel (2012), o trânsito se tornou uma das maiores dores de cabeça para a população. O acúmulo de veículos nas ruas causa prejuízos, estresse, acidentes e poluição, e tende a piorar nos próximos anos, caso não sejam adotadas políticas mais eficientes.
Milhões de pessoas saem cedo de casa todos os dias para mais uma manhã de trabalho. Com todas essas pessoas saindo ao mesmo tempo de carro ou usando o transporte público, o congestionamento, poluição e estresse do trânsito acabam atingindo a todos e casualmente já chegam ao local de trabalho com sinais de cansaço e irritação além de afetar a qualidade de vida (LOCAMERICA, 2017). Segundo Bittencourt e Lerípio (2017), os deslocamentos extensos e muitas vezes caóticos são responsáveis por restringir o tempo de lazer, exercícios
15
físicos, atividades criativas e convívio familiar, sendo que todas essas atividades contribuem de alguma forma para o bem-estar da população.
Diante deste cenário, este trabalho apresenta a construção de uma aplicação que coleta informações do trânsito, para estabelecer um mapa de incidência a partir de séries históricas. A coleta de informações será feita de forma colaborativa a partir da geolocalização dos usuários que utilizam a aplicação.
1.1 OBJETIVOS
O objetivo deste trabalho é criar uma aplicação para monitoramento de trânsito, coletando informações para estabelecer um mapa do fluxo de veículos em determinadas ruas / horários.
Os objetivos específicos são:
a) coletar estatísticas sobre as rotas a partir dos usuários da aplicação, afim de melhorar futuros percursos;
b) armazenar os dados coletados de acordo com sua classificação histórica, assim ajudando a definir a melhor data para percorrer um determinado trajeto;
c) calcular o caminho mínimo de uma rota dado ponto de origem e destino, utilizando as informações das ruas na modelagem de um grafo;
d) disponibilizar um mapa de incidência de carros por horário do dia. 1.2 ESTRUTURA
Este trabalho está estruturado em quatro capítulos. O primeiro capítulo aborda sobre a introdução do tema proposto. O segundo capítulo apresenta os principais assuntos relacionados a este trabalho com embasamento teórico e também apresenta os trabalhos correlatos. O terceiro capítulo contém informações sobre o desenvolvimento do trabalho, apresentando os requisitos, diagramas, especificação, implementação e análise de resultados. Por fim, o quarto capítulo apresenta as conclusões obtidas através da análise dos resultados e as possíveis extensões deste trabalho.
16
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo tem como objetivo descrever os principais assuntos que fundamentarão este trabalho. A seção 2.1 descreve sobre o problema do trânsito na sociedade e como a tecnologia auxilia na redução de trânsito. A seção 2.2 traz uma breve introdução de sistemas colaborativos. A seção 2.3 descreve o que é um grafo e o algoritmo de Dijkstra. Na seção 2.4 será apresentado sobre o Google Maps API e sua funcionalidade de mapa de calor.
2.1 MONITORAMENTO DE TRÂNSITO
Um dos maiores desafios das grandes cidades na atualidade é o trânsito. Somando o mau planejamento, falta de investimentos em infraestrutura e o crescimento das cidades, o problema do trânsito só se agrava com o passar do tempo (NETWORKING, 2013). Segundo SAP (2013, p. 1), “os espaços urbanos estão em constante mudança: as cidades crescem, a população aumenta e cada vez mais automóveis prejudicam a fluidez do tráfego nos grandes centros”.
No Brasil, com o incentivo do governo federal e a facilidade em obter linhas de crédito e financiamento, fez com que a quantidade de veículos aumentasse 119% nos últimos dez anos, indo muito além dos investimentos em infraestrutura urbana. E, que na cidade de São Paulo, por exemplo, uma pessoa passa diariamente em média duas horas e quarenta minutos no trânsito (LOPASSO, 2014).
Artero et al. (2014) apontam que em São Paulo, o monitoramento é feito utilizando-se aproximadamente 300 câmeras de vídeo e duas centrais de monitoramento, para um total de 15.546 km de vias. Já Junqueira (2016) observa que o trânsito, principalmente nas grandes cidades, afeta todos os cidadãos de diferentes maneiras e ressalta a necessidade de existirem mais controles sobre o que se trafega nas ruas e avenidas da cidade. Através destas câmeras e radares, é possível coletar diversos dados sobre o tráfego de veículos nos locais onde estão instaladas e com esses dados determinar o volume de veículos que passam em determinadas vias, se há muitos caminhões e ônibus transitando, entre várias outras estatísticas.
Boechat (2015) sugere como alternativa para reduzir o impacto do aumento da concentração de veículos no mundo o uso de novas tecnologias, citando como exemplo, a utilização de aplicativos móveis voltados para a melhoria de mobilidade urbana, que estão se tornando populares no Brasil através dos anos, principalmente pelo fato destes aplicativos já criarem conteúdos localizados para as cidades brasileiras. Já Artero et al. (2014) acreditam que a combinação do Global Positioning System (GPS) e conectividade com a internet, são fortes aliados para o fornecimento de informações relacionadas às condições do trânsito no
17
qual o usuário está inserido. Além disso, ressaltam que as aplicações para dispositivos móveis também estão sendo utilizadas em todas as áreas que requerem mobilidade e comunicação, pois não geram grandes custos e trazem excelentes vantagens para o usuário.
Segundo Freitas Júnior (2011), estes serviços podem fornecer informações geo-personalizadas ajudando as pessoas com itinerários e condições de trânsito, localizando postos de gasolina ou restaurantes, providenciando socorro em caso de emergência, gerenciamento de frotas, rastreamento de cargas e recuperação de veículos roubados, e vários outros serviços. Onde, uma simples aplicação colaborativa para dispositivos móveis é capaz de fornecer informações valiosas que podem ser aproveitadas pela própria aplicação e outras em prol da mobilidade urbana.
Segundo Rosa (2018), a cidade de Joinville receberá em breve semáforos inteligentes e câmeras térmicas que serão testadas nas áreas de tráfego da cidade. Isso permitirá a detecção precisa de pedestres, ciclistas e automóveis sem a interferência das condições climáticas. No Brasil, o termo semáforo inteligente é muitas vezes usado de forma incorreta, fazendo referência a semáforos modernizados, tendo LED, nobreak e comunicação via 3G e GPS, porém para ser realmente inteligente é preciso uma combinação de tecnologias como sensores, redes de comunicação de alta capacidade e um sistema que coordene tudo isso (ALECRIM, 2016).
Ratti e Biderman (2017) apontam que com o rápido avanço da tecnologia da informação, comunicação, robótica e inteligência artificial, os sistemas de mobilidade estão passando por grandes mudanças e estão prestes a remodelar radicalmente a paisagem urbana. Toda essa tecnologia formaria uma grande rede de comunicação em busca de um trânsito melhor, reduzindo severamente o número de acidentes, melhorando o aproveitamento do combustível e tornando o consumo menos agressivo ao meio ambiente (ALBERGE, 2012). Segundo Hamann (2015), as possibilidades que um trânsito inteligente disponibiliza para os usuários são muitas. Sensores poderiam contar a quantidade de carros que trafegam por uma via e cruzar os dados coletados para em poucos segundos, mudar o fluxo das vias evitando os engarrafamentos, rotas alternativas poderiam ser sugeridas aos motoristas para que o organismo inteiro funcionasse sem travamentos.
Como aponta Simões (2016), todas essas necessidades e soluções dão início ao conceito de smart city no quesito de trânsito, que tem o intuito de levar qualidade de vida aos usuários do trânsito, transformando informações em ações tangíveis. Uma smart city funciona baseada em três pilares, o de interoperabilidade que trata a parte de integração entre sistemas de transporte, o de sustentabilidade onde é preciso sustentar a integração comprovando seus
18
benefícios para o usuário e por fim o conhecimento tecnológico que identifica a deficiência e encontra uma solução viável.
Hamann (2015) relata que apesar das grandes metrópoles estarem constantemente necessitando de novas soluções para o trânsito, a aplicação de todos esses conceitos e soluções nas cidades, ainda pode demorar muito, pois dependem de recursos e adaptações de vários itens que compõe o trânsito.
2.2 SISTEMAS COLABORATIVOS
Os sistemas ou plataformas colaborativas são ferramentas de software utilizadas para facilitar a execução de tarefas em grupo, sendo que essas ferramentas devem ser bem especializadas para obedecer a seus usuários em várias formas de interação, facilitando a comunicação entre os membros do grupo tanto no mesmo local quanto em posições geograficamente diferentes (BAUM, 2018).
Segundo Ribeiro (2016), as características mais comuns de um sistema colaborativo são trabalhar com computação em nuvem, poder ser editado simultaneamente, acessível de forma remota, compatíveis com diversos dispositivos e oferecidos na forma de Software as a Service (SaaS). A computação em nuvem significa que o sistema não está em uma máquina específica e sim em uma máquina virtual, sendo possível o acesso de todos os participantes. A edição simultânea significa que todos os participantes podem fazer edições ao mesmo tempo, trazendo informações com muito mais velocidade. Ser acessível remotamente permite a visualização das informações de qualquer lugar que esteja mediante a um login com usuário e senha. Compatibilidade com vários dispositivos significa que desde o smartphone até o desktop estão preparados para o uso da aplicação. O SaaS traz o conceito de uso do software em nuvem, mediante a login por usuário e senha, podendo ser pago ou não (RIBEIRO, 2016).
Segundo Antunes (2015), as vantagens de utilizar um sistema que coloca em prática a colaboração são quase as mesmas vantagens de se trabalhar em equipe, sendo que várias cabeças pensando em um problema tendem a chegar a uma solução mais rápida e melhor e uma equipe que colabora entre si efetivamente costuma ser mais engajada e comunicativa. Antunes (2015) ainda cita como desvantagens os fatos de que um sistema colaborativo necessita de coordenação, em alguns casos o uso de um sistema colaborativo pode ser caro e a colaboração pode burocratizar os processos e torna-los lentos.
De acordo com Joyce (2015, p. 1), “as ferramentas de colaboração (sistemas colaborativos) são classificadas de acordo com o lugar das interações (presenciais ou à distância) e o tempo (síncronas ou assíncronas).”. Joyce (2015) ainda explica que as
19
ferramentas síncronas são as que requerem tempo de resposta imediato enquanto as assíncronas não necessitam do tempo de resposta imediato.
De acordo com o modelo 3C, que analisa a colaboração em três dimensões, para ser considerado colaborativo o sistema deve: implementar o conceito de coordenação permitindo que haja alguma coordenação nas áreas de cooperação; implementar o conceito de comunicação permitindo que o software forneça em algum ponto uma ferramenta de comunicação através de envios de mensagens ou chats; implementar o conceito de cooperação permitindo em algum ponto do sistema que seus usuários possam colaborar uns com os outros (ANTUNES, 2015).
Os sistemas colaborativos estão sendo cada vez mais utilizados nas empresas para integrar equipes, gerir projetos e troca de informações entre os membros da equipe sendo uma ferramenta que usa todas as suas vantagens para fomentar o trabalho em equipe e aumentar a produtividade (SAFETEC, 2017). Baum (2018) afirma que se bem aplicado com um fluxo de trabalho e uma equipe bem treinada, as tarefas podem ser realizadas com eficiência e obter resultados incríveis.
2.3 GRAFOS E O ALGORITMO DE DIJKSTRA
Segundo Pereira e Câmara (2008), a teoria dos grafos teve sua origem no confronto de problema práticos, diferentemente da maioria dos problemas matemáticos. Pereira e Câmara (2008, p. 1) ainda ressaltam que “o primeiro problema cuja solução envolveu conceitos do que veio a ser a teoria dos grafos (séc. XVII) foi resolvido por Euler e não passava de uma especulação matemática.”.
Acredita-se que um dos primeiros problemas envolvendo a teoria dos grafos, aconteceu na cidade de Konigsberg na Alemanha, onde um rio que passava pela cidade a dividia em quatro, com 7 pontes interligando as partes de modo que deveria passar apena uma vez em cada ponte (ROCHA, 2016). A Figura 1 ilustra as pontes da cidade de Konigsberg.
20
Figura 1 - Pontes de Konigsberg
Fonte: Rocha (2016).
Conforme relata Silva (2009), grafos são usados para resolver problemas em diversas áreas, como na representação de qualquer malha viária de transportes ou rotas de distribuição de serviços, independente do problema a teoria dos grafos é uma fonte de um grande número de problemas atraentes, complexos e de simples enunciados.
Um grafo G = (V,E) é um conjunto não-vazio V, cujos elementos são chamados vértices, e um conjunto E de arestas. Uma aresta é um par não-ordenado (vi,vj), onde vi e vj são elementos de V. Normalmente, utiliza-se uma representação gráfica de um grafo (GAGNON e BORBA, 2010, p. 1).
Um dos algoritmos mais famosos utilizados na teoria dos grafos é o algoritmo de Dijkstra. Este algoritmo é usado para encontrar o menor caminho entre dois pontos (vértices) do grafo, isso quando os pesos das arestas são não-negativos (CASTRO, 2014). Conforme detalha Castro (2014, p. 1), “o algoritmo de Dijkstra utiliza um procedimento iterativo, determinando, na iteração 1, o vértice mais próximo de 1, na segunda iteração, o segundo vértice mais próximo do vértice 1, e assim sucessivamente”.
Santos (2006) explica que a inicialização dos atributos de estimativa de caminho mais curto é realizada da seguinte forma: para cada vértice v pertencente a V, mantêm-se um atributo d[v], que é um limite superior sobre o peso de um caminho mais curto desde a origem s até v. O Quadro 1 demonstra o método de inicialização.
21
Quadro 1 - Método de inicialização
1 2 3 4 5 6 7 initializeSingleSource(G, s) início para todo v ∈ V[G] d[v] = ∞ π[v] = -1 d[s] ← 0 fim
Fonte: adaptado de Santos (2006).
O algoritmo de Dijkstra utiliza a técnica de relaxamento que consiste em verificar se é possível melhorar o caminho mais curto até v obtido até o momento pela passagem de u
(NUNES, 2009?). O Quadro 2 apresenta a técnica de relaxamento utilizada no algoritmo de Dijkstra.
Quadro 2 - Método de relaxamento
1 2 3 4 5 6 relax(u,v,w) início
se d[v] > d[u] + w(u,v) então d[v] = d[u] + w(u,v) antecessor[v] = u fim
Fonte: adaptado de Santos (2006).
Segundo Santos (2006), o algoritmo de Dijkstra é considerado simples com um bom tempo de execução, sendo baseado no algoritmo de busca em largura, selecionando um vértice como raiz da busca e calculando o custo mínimo deste vértice aos demais vértices. O algoritmo de Dijkstra é apresentado através do Quadro 3.
Quadro 3 - Algoritmo de Dijkstra
1 2 3 4 5 6 7 8 9 10 Dijkstra (G, w, s) início initializeSingleSource(G, s) S = 0 Q = V[G] enquanto Q <> 0 u = extrair-mín(Q)
para cada v adjacente a u relax(u, v, w)
fim
Fonte: adaptado de Santos (2006).
A explicação do algoritmo por Santos (2006) é apresentada da seguinte maneira: a linha 3 executa a inicialização habitual dos valores de d e π, e a linha 4 inicializa o conjunto S
como o conjunto vazio. O algoritmo mantém o invariante de que Q = V - S no início de cada iteração da estrutura de repetição das linhas 6 a 9. A linha 5 inicializa a fila de prioridade mínima Q para conter todos os vértices em V; tendo em vista que s = ø nesse momento, o invariante é verdadeiro após a linha 5. Em cada passagem pelo “laço while” das linhas 6 a 9, um vértice u é extraído de Q = V - S e inserido no conjunto S, mantendo assim o invariante. Então, o vértice u tem a menor estimativa de caminhos mais curtos em comparação a qualquer
22
vértice em V-S. Em seguida, as linhas 8 e 9 relaxam cada aresta (u, v) que saem de u, atualizando assim a estimativa d[v] e o predecessor π[v] se o caminho mais curto até v pode ser melhorado mediante a passagem por u.
2.4 GEOLOCALIZAÇÃO E GOOGLE MAPS API
A geolocalização é a localização de um objeto ou usuário em um sistema determinado de coordenadas. O processo de determinar geolocalização pode ser feito por uma série de tecnologias e, geralmente, quando se fala de geolocalização de um usuário, refere-se ao smartphone ou tablet que ele está usando (RIBEIRO, 2012, p. 1).
Segundo Cesani e Dranka (2013), a geolocalização conta com uma base de dados completa e mostram com precisão o posicionamento do veículo, pontos de referência e rotas alternativas. Já Campos (2015) afirma que várias empresas compartilham e disponibilizam tais serviços de forma gratuita, indicando às pessoas sobre sua posição em tempo real, detalhando ruas, pontos turísticos entre outras informações. Campos (2015) também aponta que as informações de geolocalização podem ser utilizadas em forma de Application Programming Interface (API) para favorecer a utilização de localização em sites confiáveis ou a sua própria localização.
Campos (2015) relata que a API mais conhecida é a da Google, que em 2005, lançou sua ferramenta de geolocalização e disponibilizou gratuitamente o Google Maps aos usuários da Internet. Através dela é possível ter acesso a mapas de países, estados, cidades, avenidas e ruas. Tudo isso é apresentado através de um site simples, porém capaz de realizar buscas precisas e com um ótimo desempenho. A Figura 2 mostra a utilização da API do Google Maps onde é possível calcular a distância de um ponto para outro, mostrando a distância em km e qual o tempo de deslocamento entre os pontos.
Figura 2 - Distância entre dois pontos
23
Para Fernandes (2009), esta API permite a criação de mapas com locais definidos, controle de zoom, tipos de mapa, geração de rotas e pesquisa por estabelecimentos. Ao lançar a API, o Google deslocou o foco do site de uma maneira sutil, mas revolucionária. Passou a se parecer mais com uma tela onde os programadores poderiam pintar suas próprias imagens e assim aplicações são criadas mostrando onde é possível abastecer, em quais lugares a polícia possui radares e todos os tipos de informações que ajudam os motoristas em seu caminho (DAVIS, 2010).
Segundo Google (2016), uma das várias funcionalidades do Google Maps API é o mapa de calor. Através desse tipo de mapa, é possível visualizar com facilidade a distribuição e a intensidade relativa de pontos de dados em um mapa. Ao utilizar a camada de mapa de calor, é feita uma sobreposição colorida sobre o mapa. Onde, as áreas de maior intensidade são coloridas de vermelho e as de menor intensidade em verde.
Dias e Felipe (2015) destacam que para ter acesso aos recursos da API do Google Maps é necessária uma chave de acesso, assim validando o uso da API. A partir dela é possível monitorar o uso do aplicativo e se necessário, expandir o limite de uso da API. 2.5 TRABALHOS CORRELATOS
Neste capítulo são apresentados três trabalhos correlatos que possuem características semelhantes a proposta deste trabalho. A seção 2.1 apresenta um sistema de monitoramento do transporte coletivo em tempo real desenvolvido por Vicenzi (2015). A seção 2.2 descreve um protótipo de sistema de busca de rotas de menor custo em uma malha viária (SCHROEDER, 2012). Por fim, a seção 2.3 descreve um trabalho acadêmico onde foi desenvolvido um aplicativo para acompanhamento da localização do ônibus (SILVEIRA, 2017).
2.5.1 Bustracker: Sistema de rastreamento para transporte coletivo
Vicenzi (2015) descreve o Bustracker como um sistema de monitoramento de transporte coletivo em tempo real com o uso da tecnologia GPS e o microcontrolador ESP8266. Para o funcionamento do sistema, informações são coletadas e disponibilizadas em um sistema Web através de um painel com o tempo de chegada e saída de cada ônibus até o terminal, ou por meio do mapa do Google Maps incorporado no sistema.
Vicenzi (2015) explica que o trabalho foi dividido em três partes: a primeira parte é responsável por captar as informações a partir de um microcontrolador ESP8266. A segunda parte é responsável por receber as informações, essa parte foi desenvolvida em Python e
24
utiliza o MongoDB como banco de dados. A terceira parte é responsável por disponibilizar as informações ao usuário, sendo desenvolvida em Django e MongoDB. O trabalho foi desenvolvido no formato cliente-servidor, onde a camada cliente é dividida em duas partes, uma responsável por informar a localização do veículo ao servidor via Wi-Fi e outra pela interface com o usuário. A camada de servidor é responsável pelo processamento e armazenamento das informações. Na Figura 3, é apresentada a versão para dispositivos móveis.
Figura 3 - Versão do Sistema para dispositivos móveis
Fonte: Vicenzi (2015).
Vicenzi (2015) também desenvolveu um hardware para o sistema, conforme mostra a Figura 4. Esse hardware pode ser dividido em três partes principais: um microcontrolador ESP12, que é uma das versões mais populares e flexíveis do ESP8266, responsável por executar o código Lua; módulo GPS; e módulo Real Time Clock (RTC). Além desses itens, o dispositivo conta com um circuito para controlar quando ativar o recebimento dos dados GPS e LEDs para indicarem status.
25
Figura 4 - Hardware do sistema desenvolvido
Fonte: Vicenzi (2015).
Vicenzi (2015) relata que foram feitos testes com um veículo com e sem conexão para validar as duas condições. As duas maneiras testadas, apresentaram resultados diferentes, pois enquanto no modo com conexão o sistema é capaz de informar a localização do veículo com uma precisão de 100-250 metros. No modo sem conexão não é possível obter a posição do veículo em tempo real. Todavia, não é possível informar ao usuário o local atual e o tempo de chegada até o terminal. A partir disso, o autor conclui que o modo ideal para o melhor funcionamento do trabalho é o modo com conexão.
2.5.2 Automação do tráfego de veículos: Sistema de busca de caminho de menor custo entre dois pontos
Schroeder (2012) desenvolveu um protótipo para busca de rotas de menor custo em uma malha viária baseando-se nas condições reais de tráfego para determinar a rota que levará menos tempo para ser percorrida. A coleta de dados para o sistema foi feita a partir de dispositivos celular com sistema operacional Android. A estruturação dos dados foi feita utilizando grafos, sendo que o cálculo de menor custo foi estabelecido através do algoritmo de Dijkstra. O algoritmo de Dijkstra é o mais famoso entre os algoritmos para resolver problemas de caminho com origem e destino.
De acordo com o percurso feito pelos usuários da aplicação, o servidor constrói uma malha viária e armazena estatísticas das condições de tráfego baseado na velocidade média em que o dispositivo se desloca pela via. Ao solicitar uma rota, informando um ponto de origem e destino, o servidor retorna a rota de menor custo, baseando-se nas condições de tráfego. A Figura 5 apresenta o resultado de uma consulta realizada no aplicativo.
26
Figura 5 - Resultado do cálculo da rota de menor custo
Fonte: Schroeder (2012).
Para o desenvolvimento do servidor desse protótipo, foi escolhido a linguagem C# e o banco de dados SQL Server. Esta escolha permitiu utilizar várias bibliotecas da linguagem que facilitam a programação.
Os testes foram feitos utilizando o dispositivo Samsung Galaxy S II com sistema Android versão 4.0.4, e este dispositivo demonstrou grande precisão nas coordenadas obtidas. Segundo Schroeder (2012), o sistema operacional Android dispôs de informações importantes para a administração da coleta de coordenadas geográficas sem assim ter a necessidade de implementar controles externos. Na Figura 6, é possível visualizar pontos que foram coletados em um teste e também o grafo gerado a partir destes pontos.
Figura 6 - Grafo gerado a partir dos pontos coletados
27
Por fim, Schroeder (2012) conclui que mesmo cidades pequenas podem ter informações de tráfego consideradas, e que a partir do seu trabalho, futuros usuários de sistemas baseados nesse trabalho podem se beneficiar das informações para deslocar-se de maneira mais eficiente.
2.5.3 Cadêbusão: Aplicativo colaborativo para acompanhar a localização do ônibus
Silveira (2017) desenvolveu um sistema colaborativo para dispositivos móveis Android e iOS que realiza o monitoramento da posição dos ônibus. Duas aplicações foram construídas, uma para os administradores realizarem os cadastros necessários e outra para os usuários acompanharem o ônibus.
O monitoramento dos ônibus é realizado com dispositivos Beacons, que possuem reconhecimento automático através do Bluetooth. A partir deste dispositivo, as informações são carregadas no banco de dados pela aplicação do usuário e um serviço web consome as informações e calcula a sua média, definindo assim a localização do ônibus.
No desenvolvimento do trabalho Silveira (2017) utilizou para as aplicações o framework Ionic versão 2.2.1, através das linguagens HTML5, SCSS e Typescript. As aplicações foram portadas para Android, porém o Ionic permite compila-las para iOS, Windows e para Web. Já o serviço foi construído em PHP armazenando os dados no banco de dados MySQL hospedado em nuvem no DreamHost e se comunica com a aplicação móvel através do protocolo HTTP, no formato JSON. O desenvolvimento dos mapas foi feito utilizando o Google Maps API em conjunto com o plugin de geolocalização do Cordova para detectar a posição dos dispositivos.
Através da aplicação para os administradores é possível cadastrar um ônibus, um ponto de ônibus, um terminal, rotas e itinerários. Além disso, o administrador pode visualizar o mapa com todos os itens cadastrados e os ônibus em circulação que são atualizados a cada dez segundos. Este mapa foi construído a partir do Google Maps API. A Figura 7 apresenta o mapa que os administradores podem visualizar.
28
Figura 7 - Mapa do administrador
Fonte: Silveira (2017).
Segundo Silveira (2017), a aplicação construída para os usuários inicia com duas funcionalidades paralelas. A primeira funcionalidade ocorre em segundo plano, se tratando da procura de Beacons que estejam ao alcance do smartphone e quando localizados, seu endereço físico e a posição GPS do aparelho são armazenadas em uma lista. A segunda funcionalidade se trata da visualização de rotas, onde o usuário pode verificar através do mapa os ônibus que estão em circulação para o trajeto definido. Também é possível clicar nos pontos de ônibus para visualizar informações como estimativa de tempo e distância para cada veículo em circulação. A Figura 8 apresenta o mapa do usuário e as informações exibidas ao clicar no ponto de ônibus.
29
Figura 8 - Mapa do usuário
Fonte: Silveira (2017).
Por fim, Silveira (2017) conclui que o objetivo principal do trabalho, o qual era desenvolver uma aplicação híbrida colaborativa utilizando Beacons para auxiliar no monitoramento de ônibus, foi alcançado. Silveira (2017) ainda destaca que comparando seu trabalho a outros trabalhos semelhantes, o custo de investimento é menor, e que houve uma certa imprecisão na localização do GPS dos outros trabalhos chegando a 100 metros, enquanto o CADEBUSÃO necessitava de poucos segundos para pegar de maneira precisa a posição do usuário no mapa, garantindo uma melhor localização dos ônibus.
30
3 DESENVOLVIMENTO
Este capítulo demonstra as etapas de desenvolvimento deste trabalho. A seção 3.1 descreve os requisitos da aplicação. Na seção 3.2 é dedicada a especificação da aplicação, demonstrando os casos de uso, arquitetura e diagramas de classe. A seção 3.3 apresenta a implementação da aplicação com o detalhamento das principais funcionalidades do sistema. Por fim, na seção 3.4 são apresentados os resultados obtidos através de testes e análise destes resultados.
3.1 REQUISITOS
Nesta seção são demonstrados os Requisitos Funcionais (RF) e os Requisitos Não Funcionais (RNF) da aplicação, apresentados no Quadro 4 e Quadro 5 respectivamente. Eles estão relacionados com os casos de uso apresentados na Figura 9.
Quadro 4 - Requisitos Funcionais
Requisitos Funcionais (RF) Casos de uso (UC)
RF 01: permitir que o usuário se cadastre. UC01
RF 02: permitir que o usuário cadastrado possa realizar login. UC02 RF 03: permitir que o usuário consulte uma rua de origem e uma rua de destino. UC03 RF 04: permitir que o usuário visualize a situação do trânsito em um determinado
dia/horário da semana.
UC04 RF 05: permitir que o usuário solicite o melhor dia e horário para transitar entre
dois pontos.
UC05 RF 06: permitir que o usuário consulte suas ultimas 10 viagens. UC06 RF 07: permitir que o usuário visualize no mapa a rota percorrida na sua viagem. UC07 RF 08: coletar informações do trânsito através do deslocamento de veículos que
estejam utilizando o aplicativo.
UC08
RF 09: autenticar o usuário UC09
RF 10: gerar um grafo a partir das rotas coletadas. UC10 RF 11: buscar o menor caminho através do algoritmo Dijkstra. UC11
Fonte: elaborado pelo autor.
Quadro 5 - Requisitos Não Funcionais
Requisitos Não Funcionais (RNF)
RNF 01: rodar na plataforma Android.
RNF 02: utilizar o ambiente de desenvolvimento Android Studio na linguagem Java para desenvolver a aplicação móvel.
RNF 03: utilizar o ambiente de desenvolvimento Visual Studio na linguagem C# para desenvolver o servidor.
RNF 04: se comunicar com o servidor através de requisições REST.
RNF 05: possuir APIs que disponibilizem as informações em formato JSON. RNF 06: utilizar o banco de dados SQL Server para armazenamento de dados. RNF 07: realizar a persistência de dados através do Entity Framework. RNF 08: utilizar o Azure para hospedar o banco de dados na nuvem. RNF 09: utilizar o Azure para publicar as APIs na nuvem.
RNF 10: utilizar API do Google Maps para geolocalização e desenvolvimento de mapas.
31
3.2 ESPECIFICAÇÃO
Esta seção apresenta a especificação da solução. A seção 3.2.1 apresenta o diagrama de casos de uso da aplicação. A seção 3.2.2 apresenta a arquitetura da aplicação. Na seção 3.2.3 são demonstrados os diagramas de classe da aplicação, com foco no servidor.
3.2.1 Casos de Uso
Nesta seção é apresentado o diagrama de casos de uso, demonstrado pela Figura 9. Neste diagrama são apresentadas as funcionalidades para o ator Usuário, sendo este o ator que interage com a aplicação.
Figura 9 - Diagrama de casos de uso
Fonte: elaborado pelo autor.
Ao acessar a aplicação, o Usuário precisará criar uma conta, conforme o caso de uso
UC01 – Realizar cadastro. O caso de uso UC02 – Realizar login, permite ao Usuário
se autenticar caso já tenha uma conta cadastrada. Após realizar a operação de criar conta ou login no aplicativo, será enviada uma requisição ao servidor para validar as informações do usuário, como é demonstrado no caso de uso UC09 – Autenticar o usuário.
Estando autenticado no aplicativo, o Usuário poderá consultar uma rua de origem e destino conforme o UC03 – Consultar rota. A rota será mostrada para o dia da semana e horário que está sendo feita a pesquisa. O caso de uso UC04 – Consultar rota por dia/hora, permitirá definir outro dia da semana e/ou horário para visualizar a melhor rota, conforme as condições de trânsito daquele momento. Enquanto o aplicativo estiver aberto e rodando, serão coletadas algumas informações do trânsito, como a rua onde está, latitude e
32
longitude, e o tempo de deslocamento entre ruas a partir do UC08 – Coletar informações do trânsito, sendo armazenadas no banco de dados ao detectar uma nova rua conforme o
UC12 – Armazenar dados do trânsito. O caso de uso UC06 – Consultar ultimas viagens permite ao usuário visualizar uma lista com as suas 10 ultimas viagens, exibindo informações sobre elas. No caso de uso UC07 – Visualizar rota percorrida de uma viagem, o usuário poderá visualizar todo o trajeto que percorreu no mapa, sendo mostrado as condições de trânsito daquele trajeto.
As consultas de trajeto geram um grafo no servidor, conforme o caso de uso UC10 – Gerar grafo. Esse grafo representa a malha viária com as ruas coletadas pela aplicação. Quando o usuário solicita a menor rota entre dois pontos, será aplicado o algoritmo de Dijkstra para verificar qual a melhor rota que a aplicação deverá apresentar como retorno, conforme o caso de uso UC11 – Aplicar Dijkstra.
3.2.2 Arquitetura
Na Figura 10 é apresentado o desenho da arquitetura da aplicação, onde são utilizadas principalmente as ferramentas Azure, .Net Core, Entity Framework para trabalhar com o servidor e Google Maps API e Android para tralhar com o aplicativo móvel.
Figura 10 - Arquitetura da aplicação
Fonte: elaborado pelo autor.
Aplicativo
33
O servidor é totalmente implementado utilizando .Net Core, utilizando os recursos que esta tecnologia oferece. As requisições para o servidor são feitas através de APIs REST utilizando o protocolo HyperText Transfer Protocol (HTTP), que retornam respostas em formato Java Script Object Notation (JSON). A aplicação móvel envia dados do trânsito utilizando o Google Maps API para recolher informações da rota, tais como nome da rua e coordenadas a cada 200 metros percorridos para uma API de coleta de informações, onde o servidor processa os dados e os armazena, classificando-os por ruas e data. O armazenamento é feito em um banco de dados SQL Server, hospedado em uma máquina virtual na nuvem através do Microsoft Azure. Este armazenamento é controlado utilizando o Entity Framework (EF) que trabalha com Object Relational Mapper (ORM) que é uma técnica de mapeamento objeto relacional onde existem classes que representam as tabelas do banco de dados em memória e também utiliza transações controladas pelo contexto da requisição, onde os dados são enviados para o banco de dados somente ao comitar a transação. A cada consulta de uma rota, o servidor manipula os dados salvos construindo uma malha viária (grafo) com os pontos de interesse e aplica o algoritmo Dijkstra para encontrar a menor rota entre os dois pontos pesquisados.
Por fim, a aplicação móvel para plataforma Android recebe um JSON com as informações requisitadas sobre o trânsito e os transforma em objetos manipuláveis Java, aplicando este retorno a um mapa do Google Maps e exibindo a rota graficamente.
3.2.3 Diagramas de Classes
O modelo de arquitetura do servidor representado nos diagramas de classes foi separado em 4 partes para melhor entendimento. Na sequência são apresentadas as classes de inicialização da aplicação, inicialização do Entity Framework e a modelagem do banco de dados para classes em C#, API de usuário/login e API de rotas.
A Figura 11 apresenta o diagrama de inicialização do servidor. A classe Program é a primeira a ser chamada no servidor. Esta classe tem a finalidade de subir a aplicação e configura-la em um WebHost removendo a necessidade de utilizar o IIS para publicar o servidor. A classe Startup é a segunda a ser chamada na pilha de execução, tendo como finalidade configurar os serviços da aplicação, repositórios e também o padrão de arquitetura Model View Controller (MVC). Nesta classe são realizadas as injeções de dependências dos serviços e repositórios, diminuindo o acoplamento entre objetos do sistema, utilizando interfaces para instanciar as classes. Além disso, a classe Startup também configura a conexão com o banco de dados através de uma string de conexão.
34
Figura 11 - Diagrama de classes startup
Fonte: elaborado pelo autor.
A Figura 12 representa as classes que compõe a modelagem do banco de dados utilizando o Entity Framework. A classe Context é encarregada de iniciar e aplicar as configurações das tabelas através das classes de configurações, ela também cria um DbSet que irá fazer referência direta as tabelas presentes no banco de dados. As classes
BestRouteEntityConfiguration, ResearchedRouteEntityConfiguration,
RouteEntityConfiguration, StreetEntityConfiguration, UserEntityConfiguration e
UserRouteEntityConfiguration, modelam as tabelas MelhorRota, RotaPesquisada,
Rota, Rua, Usuario e UsuarioRota respectivamente. Essas classes de configuração mapeiam o nome da tabela, o nome de cada campo, seu tipo, tamanho, chave primária, chave estrangeira e obrigatoriedade. As classes BestRouteEntity, ResearchedRouteEntity,
RouteEntity, StreetEntity, UserEntity, UserRouteEntity são os objetos modelados que são utilizados pela aplicação para interagir com o banco, cada propriedade dessas classes faz referência a uma coluna da tabela do banco de dados. Todas as tabelas estão presentes no banco de dados SQL Server hospedado no Microsoft Azure
35
Figura 12 - Diagrama de classes Entity Framework
Fonte: elaborado pelo autor.
A Figura 13 representa o diagrama de classes da API de usuário e da API de login. A classe UserController é responsável por buscar, criar, alterar e deletar um usuário. As requisições de criação e alteração de usuário esperam um objeto do tipo UserRequest, onde estão os dados do usuário que será manipulado. Todos os outros métodos, exceto o de deletar, retornam um objeto do tipo UserResponse que é semelhante a classe UserRequest, alterando apenas o tipo de um de seus atributos. A classe LoginConctroller tem como única finalidade realizar a autenticação do usuário.
36
Figura 13 - Diagrama de classes API de usuário
Fonte: elaborado pelo autor.
A Figura 14 apresenta a API de rotas. A classe RouteController retorna as rotas do usuário, a melhor rota entre dois pontos e adiciona e altera informações das rotas além de interagir com grande parte dos models existentes. A principal parte da aplicação inicia a partir das requisições para essa classe. Dentro do pacote Models estão as classes que interagem com o aplicativo móvel, tanto para enviar informações quanto para receber os objetos das requisições. A classe UserRoute contém as informações da rota de um usuário. A classe
RouteSearchResponse envia informações de uma rota pesquisada para o aplicativo móvel. A classe RouteSearchRequest recebe informações vindas da requisição para adicionar e alterar uma rota pesquisada. A classe RouteRequest recebe as informações de deslocamento do usuário para que seja possível armazenar a malha viária e posteriormente montar o grafo. A classe RouteInformation contém uma lista de objetos da classe RouteInformationMetada, onde essas duas classes têm como objetivo armazenar em formato JSON as informações da rota pesquisada para futuras consultas. A classe BestRouteDateResponse retorna para o aplicativo móvel as informações da melhor rota entre dois pontos, além de uma lista de pontos para que o aplicativo desenhe a rota graficamente.
37
Figura 14 - Diagrama de classes da API de rotas
Fonte: elaborado pelo autor.
3.3 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da implementação. A seção 3.3.1 exibe informações sobre as técnicas e ferramentas utilizadas no desenvolvimento da aplicação. Na seção 3.3.2 são apresentadas as funcionalidades do aplicativo móvel. Na seção 3.3.3 demonstra os detalhes da implementação do servidor da aplicação. A base de dados construída no SQL Server foi representada por um Modelo Entidade Relacionamento (MER), disponível no APÊNDICE A.
3.3.1 Técnicas e ferramentas utilizadas
O servidor foi totalmente escrito na linguagem C#, utilizando a Integrated Development Environment (IDE) Visual Studio 2017. Para a comunicação da API com o dispositivo móvel foi utilizado o framework ASP.NET Core, dessa maneira dispensa a
38
necessidade de utilizar o Internet Information Services (IIS), pois o ASP.NET Core possui um WebHost próprio. A arquitetura do servidor está levemente baseada no modelo Service-Oriented Architecture (SOA), onde serviços são disponibilizados para o consumo das APIs. Para evitar um alto acoplamento entre classes, foi utilizado o padrão de desenvolvimento Depedency Injection (DI), assim a dependência entre as classes não é implícita programaticamente e sim controlada pela configuração de infraestrutura da aplicação. A manipulação dos dados é feita utilizando o Entity Framework (EF), que modela as tabelas do banco de dados em objetos e sendo possível realizar operações do banco em memória.
O aplicativo móvel foi construído utilizando a IDE Android Studio 3.0.1 na linguagem Java para a regra de negócio e o XML para o desenvolvimento da interface visual. Para a comunicação HTTP com o servidor foram utilizadas, principalmente, as bibliotecas
com.squareup.retrofit2:retrofit:2.1.0 e com.squareup.retrofit2:converter-gson:2.0.0-beta4 abstraindo a conexão com o servidor para uma única classe e controlando as requisições através de interfaces.
3.3.2 Aplicativo móvel
Ao acessar o aplicativo é apresentada a tela de autenticação. Nesta tela o usuário terá a possibilidade de se registrar, caso ainda não tenha feito ou poderá utilizar o seu cadastro para efetuar o login no aplicativo. Caso a ação selecionada seja a de registro, apertando no botão
Registrar será redirecionado para a tela de registro, e nesta tela é necessário informar um nome, um usuário, uma senha, um e-mail e uma data de nascimento para cadastrar o usuário no aplicativo. A foto na etapa de cadastro é um item opcional, caso uma foto não seja escolhida, o aplicativo mantém a imagem padrão de usuário. Após o preenchimento de todos os campos obrigatórios, é necessário apertar no botão Confirmar para que o cadastro do usuário esteja completo. A Figura 15 mostra a tela de autenticação e a tela de cadastro de usuário.
39
Figura 15 - Tela de login e tela de cadastro de usuário
Fonte: elaborado pelo autor.
Após o usuário se cadastrar ou realizar o login no aplicativo é apresentada a tela principal, onde a maioria das ações do aplicativo acontecem. A tela possui um mapa do Google Maps iniciando sempre na posição atual onde o usuário está localizado, sendo possível navegar por esse mapa e utilizar as funções de zoom e rotação normalmente. Também é exibida uma caixa de pesquisa. Após selecionar uma rua de origem, é exibida uma segunda caixa de seleção, desta vez para selecionar a rua de destino onde a aplicação irá procurar a rota entre esses dois pontos. Tanto para a rua de origem, quanto para a rua de destino, ao serem selecionadas é adicionado um marcador no mapa indicando visualmente os dois pontos escolhidos. A Figura 16 mostra a tela principal ao iniciar e suas variantes para selecionar uma rua de origem e destino.
Figura 16 - Tela principal
40
Na parte inferior da tela principal encontram-se os botões de filtro e os botões de ações, sendo esse último grupo o que irá efetivamente enviar a requisição para realizar a busca de uma rota entre os dois pontos escolhidos e respeitando os filtros informados. Existem dois botões de filtro disponíveis. O primeiro botão, o de Calendário, filtra uma rota por um ou mais dias da semana ou por um período de um mês. Ao optar pelo filtro de Dias da semana, o usuário tem a possibilidade de escolher um ou mais dias da semana, assim ao realizar a pesquisa de rota será levado em consideração apenas os percursos que foram feitos nestes dias. Ao optar pelo filtro de Período do mês, o usuário tem a possibilidade de escolher a primeira ou segunda metade de um mês. Dessa maneira, ao realizar a pesquisa de rota será levado em consideração apenas os percursos que foram feitos no mês escolhido e do dia 01 até o dia 15 para a primeira metade ou do dia 16 até o último dia do mês para a segunda metade. O segundo botão, o de Hora, filtra uma rota por um intervalo de horas. Selecionando uma hora de início e uma hora de fim. Ao realizar a pesquisa de rota, leva-se em consideração apenas os percursos que foram feitos entre os dois horários selecionados.
O terceiro botão, o botão de Pesquisa, realiza a busca entre os dois pontos escolhidos respeitando todos os filtros configurados anteriormente. Este botão só terá uma ação caso a rua de origem e a rua de destino estejam preenchidas. O quarto botão, o de Melhor rota, realiza a busca entre os dois pontos selecionados, retornando a melhor rota disponível independentemente dos filtros informados. Este botão também só terá ação caso a rua de origem e a rua de destino estejam preenchidas. A Figura 17 apresenta os filtros de data e os filtros de horas.
Figura 17 - Tela principal com os filtros disponíveis
41
Após a configuração dos parâmetros de pesquisa e a realização da busca de uma rota, é exibido graficamente no mapa a rota. A linha tracejada no mapa indicando a rota entre os dois pontos pode ser da cor verde para um trânsito rápido, amarela para um trânsito moderado e vermelha para um trânsito intenso. Cada rua pode ter a linha de uma cor, pois é levada em consideração a situação de rua por rua. A exibição visual ao clicar nos botões Pesquisar e
Melhor rota é bastante semelhante, apenas mudando a rota de acordo com os dados do aplicativo e no caso da melhor rota, é exibida uma caixa indicando qual o melhor dia e melhor horário para percorrer o trajeto. A Figura 18 apresenta o resultado visual da busca de uma rota entre dois pontos.
Figura 18 - Tela principal com pesquisa e tela principal com melhor rota
Fonte: elaborado pelo autor.
Através do menu lateral do aplicativo é possível acessar os itens de Minhas localizações, Editar Perfil e Sair, sendo este último para se desconectar do aplicativo. A tela de minhas localizações exibe as 10 últimas rotas coletadas do usuário que está logado no aplicativo, exibindo a rua de início e a rua de fim além do dia em que o trajeto foi feito. É possível selecionar uma dessas 10 rotas para que seja exibido no mapa o trajeto total percorrido sem buscar a melhor rota entre a rua de início e a rua de fim. A linha de exibição do trajeto ficará na cor azul. Na tela de perfil, é possível editar os campos do usuário e também alterar a foto e ao clicar no botão Confirmar os dados são alterados. A Figura 19 apresenta o menu lateral para navegação entre as telas do aplicativo, a tela dos últimos trajetos percorridos pelo usuário e a tela de perfil do usuário.
42
Figura 19 - Tela das localizações, tela com o trajeto percorrido e tela de perfil do usuário
Fonte: elaborado pelo autor.
3.3.3 Servidor
Ao inicializar o servidor a classe Startup executa o método ConfigureServices, onde é feita a configuração dos serviços que compõe a aplicação. Nestes serviços estão a regra de negócio e são chamados pelos controllers para buscar ou guardar informações vindas do request. O Quadro 6 apresenta o método ConfigureServices responsável pelo início das configurações.
Quadro 6 - Inicialização do servidor
1 2 3 4 5 6 7 8 9 10 11 12 13 14
public void ConfigureServices(IServiceCollection services) { services.AddDbContext<Context>(options =>options.UseSqlServer( Configuration.GetConnectionString("BaseRouteAzure"))); services.AddMvc(); services.AddScoped(typeof(IRepository<>), typeof(BaseRepository<>)); //Services services.AddScoped<UserAppService>(); services.AddScoped<RouteAppService>(); services.AddScoped<GraphAppService>(); services.AddScoped<StreetAppService>(); }
Fonte: elaborado pelo autor.
Na linha 3 é indicada qual a string de conexão a aplicação fará uso para se comunicar com o banco de dados. Na linha 7 é realizada a injeção de dependência dos repositórios. Nas linhas 10 a 13 são registrados os serviços na aplicação onde há a regra de negócio.
A configuração do ORM do banco de dados pelo Entity Framework é feito no método
43
modelar o banco de dados para classes em C#. O Quadro 7 demonstra o método de configuração.
Quadro 7 - Configuração das tabelas do banco em C#
1 2 3 4 5 6 7 8 9
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.ApplyConfiguration(new UserConfiguration()); modelBuilder.ApplyConfiguration(new UserRouteEntityConfiguration()); modelBuilder.ApplyConfiguration(new RouteEntityConfiguration()); modelBuilder.ApplyConfiguration(new StreetEntityConfiguration()); modelBuilder.ApplyConfiguration(new ResearchedRouteEntityConfiguration()); modelBuilder.ApplyConfiguration(new BestRouteEntityConfiguration()); }
Fonte: elaborado pelo autor.
Nas linhas 3 a 8 são registradas as classes que contem as configurações de modelagem das tabelas do bando de dados.
Para modelar a tabela do banco de dados para uma classe em C# foi utilizado o fluent mapping, estratégia do Entity Framework. Através dele é possível indicar qual coluna do banco será representada por uma propriedade da classe C#, qual o tamanho tipo de dado aceito no banco, se o campo é obrigatório, se é uma chave primária ou chave estrangeira, entre outras particularidades. No Quadro 8 é demonstrado através do mapeamento da tabela
Usuario, como funciona a configuração de uma tabela. O método Configure é o responsável por essa configuração.
Quadro 8 - Configuração da tabela Usuario 1 2 3 4 5 6 7 8 9 10 11
public void Configure(EntityTypeBuilder<UserEntity> builder) { builder.ToTable("Usuario"); builder.Property(x =>x.Id).HasColumnName("Id").HasColumnType("int") .IsRequired().ValueGeneratedOnAdd(); builder.Property(x => x.Name).HasColumnName("Nome").HasColumnType("varchar(200)") .IsRequired().ValueGeneratedNever().HasMaxLength(200); builder.Property(x => x.Username).HasColumnName("Usuario").HasColumnType("varchar(100)") .IsRequired().ValueGeneratedNever().HasMaxLength(100); builder.Property(x => x.Password).HasColumnName("Senha").HasColumnType("varchar(100)") .IsRequired().ValueGeneratedNever().HasMaxLength(100); builder.Property(x => x.Email).HasColumnName("Email").HasColumnType("varchar(200)") .IsRequired().ValueGeneratedNever().HasMaxLength(200); builder.Property(x => x.BirthDate).HasColumnName("DataNascimento").HasColumnType("date") .IsRequired().ValueGeneratedNever(); builder.HasKey(x => x.Id); }
44
A linha 3 indica qual a tabela que será mapeada nesta classe. Nas linhas 4 a 9 são realizados os mapeamentos de cada campo da tabela Usuario. A linha 10 indica qual a chave primária da tabela.
Os dados coletados pelo aplicativo móvel são enviados a cada 200 metros percorridos pelo veículo, caso a rua de origem e destino sejam diferentes. Esses dados formam a base de informações colaborativas a qual este trabalho tem como objetivo montar. Após coletados os dados são adicionados ao banco através do método AddRoute, onde são enviadas as informações das ruas de origem e destino, como o nome, latitude e longitude. Ainda neste método é realizada uma verificação de segurança se a rua de origem coletada anteriormente é igual a rua de destino atual ou se a rua de destino anterior é igual a rua de origem atual, dessa maneira evita que ocorra um ciclo de coleta de informações desnecessárias. O Quadro 9 apresenta o método responsável por adicionar a informação da rota coletada pelo usuário.
45
Quadro 9 - Adicionar informações da rota
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
public RouteRequest AddRoute(RouteRequest route) {
if (!route.UserRouteId.HasValue || route.UserRouteId == 0) {
var userRouteEntity = AddUserRoute(route.UserId); route.UserRouteId = userRouteEntity.Id;
}
var originStreet = streetAppService.GetStreet(route.OriginStreet); var destinationStreet =
streetAppService.GetStreet(route.DestinationStreet); var totalSeconds = 0;
var lastRoute = routeRepository.GetAll().OrderByDescending(r => r.Id).FirstOrDefault(r => r.UserRouteId == route.UserRouteId); if (lastRoute != null)
{
if (lastRoute.OriginStreetId == destinationStreet.Id && lastRoute.DestinationStreetId == originStreet.Id) { routeRepository.Delete(lastRoute.Id); routeRepository.SaveChanges(); return null; } totalSeconds = (int)HrBrasilia().Subtract(lastRoute.Date).TotalSeconds; } else { totalSeconds = (int)HrBrasilia().Subtract(route.Date).TotalSeconds; }
var routeEntity = new RouteEntity { OriginStreetId = originStreet.Id, DestinationStreetId = destinationStreet.Id, OriginLatitude = route.OriginLatitude, OriginLongitude = route.OriginLongitude, DestinationLatitude = route.DestinationLatitude, DestinationLongitude = route.DestinationLongitude, Date = HrBrasilia(), UserRouteId = route.UserRouteId ?? 0, TotalSeconds = totalSeconds }; routeRepository.Add(routeEntity); routeRepository.SaveChanges(); route.TotalSeconds = routeEntity.TotalSeconds; return route; }
Fonte: elaborado pelo autor.
A linha 3 verifica se já existe uma rota sendo percorrida pelo usuário para que seja salva uma nova rota, caso o usuário tenha acabado de iniciar o aplicativo. Na linha 14 é obtida as informações da última rota coletada pelo usuário e salva no banco de dados para que seja
