UNIVERSIDADE DO SUL DE SANTA CATARINA
JONATHAN HENRIQUE DE SOUZA
LEONARDO AMORIM RAMOS
SOLUÇÃO PARA BUSCA E CHAMADAS DE TÁXIS UTILIZANDO A
PLATAFORMA ANDROID
Palhoça
2011
JONATHAN HENRIQUE DE SOUZA
LEONARDO AMORIM RAMOS
SOLUÇÃO PARA BUSCA E CHAMADAS DE TÁXIS UTILIZANDO A
PLATAFORMA ANDROID
Trabalho de Conclusão de Curso apresentado ao Curso
de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharel em Sistemas de
Informação.
Orientador: Prof. Saulo Popov Zambiasi, Msc.
Palhoça
2011
JONATHAN HENRIQUE DE SOUZA
LEONARDO AMORIM RAMOS
SOLUÇÃO PARA BUSCA E CHAMADAS DE TÁXIS UTILIZANDO A
PLATAFORMA ANDROID
Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina.
Palhoça, 23 de novembro de 2011.
______________________________________________________
Professor e orientador Saulo Popov Zambiasi, Msc.
Universidade do Sul de Santa Catarina
______________________________________________________
Profa. Vera Rejane Niedersberg Schuhmacher, MEng.
Universidade do Sul de Santa Catarina
______________________________________________________
Profa. Maria Inés Castiñeira, Dra.
Universidade do Sul de Santa Catarina
Dedicamos este trabalho a nossos pais que
sempre estiveram ao nosso lado, deram-nos
amor e compreensão em todos os momentos e
ajudaram a construir este projeto que muda
nossas vidas. Ao professor Saulo Popov
Zambiasi pela ajuda e atenção ao orientar
nosso trabalho.
AGRADECIMENTOS
Às nossas famílias, fonte inspiradora, na qual nos espelhamos e tomamos como
exemplo.
Ao professor Saulo Popov Zambiasi, nosso orientador, pelas contribuições,
estímulo, atenção e orientação essenciais para o sucesso deste trabalho.
A todos os professores que passaram ao longo da nossa caminhada acadêmica.
Aos amigos, pelos momentos de distração, alegria e ajuda.
Vocês foram essenciais!
“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.” (José de Alencar).
RESUMO
Requisitar um serviço de táxi pode ser uma tarefa trabalhosa se não houver informação
disponível no momento certo. Para turistas ou pessoas que viajam com regularidade, esta
atividade passou a ser mais difícil. A crescente evolução dos celulares nos últimos anos
possibilitou o surgimento de um novo mercado de aplicativos para dispositivos móveis, no
qual os próprios dispositivos passaram a auxiliar as atividades diárias de seu usuário, em
qualquer lugar. Neste contexto, este trabalho propõe um protótipo de sistema de informação
para dispositivos móveis, que utilizam a plataforma Android, capaz de tornar o processo de
requisição de serviço de táxi mais fácil e ágil. Por meio de um receptor de sinais GPS
instalado no celular, o usuário pode visualizar a sua localização em um mapa provido pelo
serviço de mapas da Google, o Google Maps. A localização dos pontos de táxis mais
próximos do usuário são plotados no mapa. Com poucos toques na tela, o usuário pode ter
acesso a diversas informações de um determinado ponto de táxi, podendo, também, realizar
chamadas telefônicas, para um ponto de táxi de seu interesse, ou requisitá-lo através de
mensagens de texto. Com o objetivo de provar a eficiência do sistema desenvolvido,
realizaram-se avaliações juntamente com usuários finais utilizando questionários. Os
resultados mostraram que o protótipo desenvolvido atingiu o seu objetivo de criar um serviço
via dispositivos móveis que forneça mais facilidades para os usuários de táxis.
Palavras-chave: Android. GPS. Google Maps. Sistema de Informação Geográfico.
ABSTRACT
Ordering a taxi service can be a laborious task if there is no information available at the right
time. For tourists or people who travel regularly, this activity has become more difficult. The
growing trend of mobile phones in recent years has enabled the emergence of a new market
for mobile applications, where devices have their own daily activities to assist its user,
anywhere. In this context, this paper aims to propose a prototype information system for
mobile devices that use the platform Android able to make the process of requesting taxi
service easier and faster. Through a GPS signal receiver installed on the phone, the user can
view your location on a map provided by Google Maps service, Google Maps. The locations
of taxi stands closer to the user are plotted on the map. With a few taps on the screen, the user
can access various information for a particular taxi stand, and can also make phone calls, or
through text messages to a taxi stand in your best interest. In order to prove the efficiency of
the system developed, evaluations were carried out with end users through questionnaires.
The results showed that the prototype achieved its goal of creating a service via mobile
devices to provide better facilities for users of taxis.
Keywords: Android. GPS. Google Maps. Geographic Information System.
LISTA DE ILUSTRAÇÕES
Figura 1 – Telas do sistema cab4me.........................................................................................22
Figura 2 – Tela do sistema Tarifa de Táxi................................................................................23
Figura 3 – Tela do sistema myTaxi. .........................................................................................24
Figura 4 – Tela do sistema Taxi Magic. ...................................................................................25
Figura 5 – Logotipo do Android...............................................................................................26
Figura 6 – T-Mobile G1. ..........................................................................................................27
Figura 7 – Arquitetura da plataforma Android.........................................................................28
Figura 8 – Exemplo de activity.................................................................................................32
Figura 9 – Ciclo de vida de uma Activity.................................................................................32
Figura 10 – Distribuição de satélites GPS. ...............................................................................36
Figura 11 – Segmento de controle do GPS...............................................................................37
Figura 12 – Exemplos de receptores GPS ................................................................................38
Figura 13 – Processo de trilateração entre satélites..................................................................40
Figura 14 – Tipos de projeções quando à sua superfície..........................................................45
Figura 15 – Latitude. ................................................................................................................46
Figura 16 – Longitude. .............................................................................................................47
Figura 17 – Fórmula matemática da escala. .............................................................................48
Figura 18 – Exemplos de escalas..............................................................................................48
Figura 19 – Interface do serviço Google Maps. .......................................................................50
Figura 20 – Funcionalidade vista da rua do Google Maps. ......................................................50
Figura 21 – Arquitetura da Solução..........................................................................................55
Figura 22 – Atores do sistema. .................................................................................................58
Figura 23 – Protótipo da tela principal. ....................................................................................68
Figura 24 – Protótipo da tela de listagem de pontos de táxis. ..................................................69
Figura 25 – Protótipo da tela de informações de um ponto de táxi..........................................70
Figura 26 – Protótipo da camada de administração..................................................................71
Figura 27 – Diagrama de caso de uso – Ator Usuário..............................................................72
Figura 28 – Diagrama de caso de uso - Ator Administrador....................................................73
Figura 29 – Diagrama de sequência para o CSU11..................................................................75
Figura 30 – Diagrama de classe – Classes de modelo..............................................................76
Figura 31 – Diagrama de classe – Controladores. ....................................................................76
Figura 32 – Diagrama de utilização..........................................................................................78
Figura 33 – Tecnologias e ferramentas utilizadas no sistema. .................................................80
Figura 34 – Módulo administrador – tela principal..................................................................87
Figura 35 – Módulo administrador – formulário de cadastro de ponto de táxi........................88
Figura 36 – Módulo cliente – tela principal. ............................................................................89
Figura 37 – Módulo cliente – tela de informações de um ponto de táxi. .................................90
Figura 38 – Módulo cliente – menu da tela de informações de um ponto de táxi....................91
Figura 39 – Módulo cliente – seleção de chamadas. ................................................................92
Figura 40 – Módulo cliente – chamada telefônica. ..................................................................93
Figura 41 - Módulo cliente – tela para enviar mensagem de texto...........................................94
Figura 42 – Módulo cliente – menu da tela principal...............................................................95
Figura 43 – Módulo cliente – tela de lista de favoritos. ...........................................................96
Figura 44 – Módulo cliente – tela de histórico de chamadas. ..................................................97
Figura 45 – Módulo cliente – cálculo de rota...........................................................................98
Figura 46 – Módulo cliente – tela de custos de uma corrida....................................................99
Figura 47 – Módulo cliente – tela de listagem de pontos de táxis mais próximos.................100
Figura 48 – Questionário – Resultados da pergunta 1............................................................102
Figura 49 – Questionário – Resultados da pergunta 2............................................................103
Figura 50 – Questionário – Resultados da pergunta 4............................................................103
Figura 51 – Questionário – Resultados da pergunta 5............................................................104
Figura 52 – Questionário – Resultados da pergunta 6............................................................105
Figura 53 – Questionário – Resultados da pergunta 7............................................................105
Figura 54 – Questionário – Resultados da pergunta 8............................................................106
Figura 55 – Questionário – Resultados da pergunta 9............................................................107
LISTA DE QUADROS
Quadro 1 - Definições do ator Usuário.....................................................................................58
Quadro 2 - Definições do ator Administrador. .........................................................................59
Quadro 3 - Requisitos funcionais. ............................................................................................61
Quadro 4 - Requisitos não-funcionais – Usabilidade. ..............................................................62
Quadro 5 - Requisitos não-funcionais – Desempenho. ............................................................63
Quadro 6 - Requisitos não-funcionais – Operacionais. ............................................................63
Quadro 7 - Requisitos não-funcionais – Implementação..........................................................63
Quadro 8 - Requisitos não-funcionais – Arquitetura................................................................64
Quadro 9 - Regras de negócio. .................................................................................................66
Quadro 10 - Caso de uso CSU01 – Abrir mapa. ......................................................................74
Quadro 11 - Perguntas do questionário. .................................................................................101
Quadro 12 - Caso de uso CSU02 - Visualizar posição atual no mapa. ..................................122
Quadro 13 - Caso de uso CSU03 - Visualizar pontos de táxis através do mapa....................123
Quadro 14 - Caso de uso CSU04 - Visualizar lista de pontos de táxis próximos. .................124
Quadro 15 - Caso de uso CSU05 - Visualizar informações de pontos de táxis. ....................124
Quadro 17 - Caso de uso CSU06 - Visualizar histórico de chamadas. ..................................125
Quadro 18 - Caso de uso CSU07 - Gerenciar favoritos. ........................................................125
Quadro 19 - Caso de uso CSU08 - Calcular estimativa de preço de corrida..........................126
Quadro 20 - Caso de uso CSU09 - Realizar chamada............................................................127
Quadro 21 - Caso de uso CSU10 - Realizar chamada por telefone........................................127
Quadro 22 - Caso de uso CSU11 - Realizar chamada por SMS. ...........................................128
Quadro 23 - Caso de uso CSU12 - Cadastrar ponto de táxi. ..................................................128
Quadro 24 - Caso de uso CSU13 - Cadastrar ponto de táxi. ..................................................129
Quadro 25 - Caso de uso CSU14 - Remover ponto de táxi....................................................130
SUMÁRIO
1 INTRODUÇÃO ............................................................................................................................. 15
1.1
PROBLEMÁTICA .......................................................................................................................16
1.2
OBJETIVOS .................................................................................................................................17
1.2.1
Objetivo geral...........................................................................................................................18
1.2.2
Objetivos Específicos ...............................................................................................................18
1.3
JUSTIFICATIVA .........................................................................................................................18
1.4
ESTRUTURA DA MONOGRAFIA ............................................................................................19
2 REVISÃO BIBLIOGRÁFICA..................................................................................................... 21
2.1
ESTADO DA ARTE ....................................................................................................................21
2.1.1
cab4me ......................................................................................................................................21
2.1.2
Tarifa de Táxi...........................................................................................................................22
2.1.3
myTaxi ......................................................................................................................................23
2.1.4
Taxi Magic ................................................................................................................................24
2.2
2.2.1
ANDROID ....................................................................................................................................25
Arquitetura...............................................................................................................................28
2.2.1.1 Kernel..................................................................................................................................... 29
2.2.1.2 Bibliotecas.............................................................................................................................. 30
2.2.1.3 Runtime .................................................................................................................................. 30
2.2.1.4 Framework de aplicativos ...................................................................................................... 31
2.3
2.3.1
GPS ...............................................................................................................................................34
Segmentos .................................................................................................................................35
2.3.1.1 Segmento Espacial ................................................................................................................. 35
2.3.1.2 Segmento de Controle ............................................................................................................ 36
2.3.1.3 Segmento de Usuário ............................................................................................................. 37
2.3.2
Funcionamento.........................................................................................................................38
2.3.2.1 Modos de Operação................................................................................................................ 40
2.4
SISTEMAS DE INFORMAÇÕES GEOGRÁFICOS ..................................................................41
2.4.1
Definição ...................................................................................................................................41
2.4.2
Funções .....................................................................................................................................42
2.4.3
Cartografia ...............................................................................................................................42
2.4.3.1 Mapas ..................................................................................................................................... 43
2.4.3.2 Projeções ................................................................................................................................ 43
2.4.3.3 Sistemas de Coordenadas ....................................................................................................... 45
2.4.3.3.1
Latitude ................................................................................................................................46
2.4.3.3.2
Longitude .............................................................................................................................47
2.4.3.4 Escalas.................................................................................................................................... 47
2.5
2.5.1
GOOGLE MAPS ..........................................................................................................................49
Google Maps API .....................................................................................................................51
2.5.1.1 Google Geocoding API .......................................................................................................... 52
2.5.1.2 Google Direction API............................................................................................................. 52
3 MÉTODO....................................................................................................................................... 53
3.1
CARACTERIZAÇÃO DO TIPO DE PESQUISA .......................................................................53
3.2
ETAPAS .......................................................................................................................................54
3.3
ARQUITETURA DA SOLUÇÃO PROPOSTA ..........................................................................55
3.4
DELIMITAÇÕES.........................................................................................................................56
4 MODELAGEM DO SISTEMA ................................................................................................... 57
4.1
LINGUAGEM DE MODELAGEM UNIFICADA (UML)..........................................................57
4.2
IDENTIFICAÇÃO DOS ATORES ..............................................................................................57
4.3
REQUISITOS ...............................................................................................................................59
4.3.1
Requisitos funcionais ...............................................................................................................60
4.3.2
Requisitos não-funcionais........................................................................................................62
4.4
REGRAS DE NEGÓCIO .............................................................................................................65
4.5
PROTOTIPAÇÃO DAS TELAS..................................................................................................67
4.6
CASOS DE USO ..........................................................................................................................71
4.6.1
Diagrama de caso de uso .........................................................................................................72
4.6.2
Descrição dos casos de uso ......................................................................................................73
4.6.3
Diagrama de Sequência ...........................................................................................................74
4.6.4
Diagrama de Classe..................................................................................................................75
4.6.5
Diagrama de Utilização ...........................................................................................................77
5 DESENVOLVIMENTO ............................................................................................................... 79
5.1
TECNOLOGIAS E FERRAMENTAS.........................................................................................79
5.2
HISTÓRICO DO DESENVOLVIMENTO..................................................................................85
5.3
APRESENTAÇÃO DO SISTEMA ..............................................................................................86
5.3.1
Módulo administrador.............................................................................................................86
5.3.1.1 Tela principal ......................................................................................................................... 86
5.3.1.2 Cadastro de ponto de táxi ....................................................................................................... 87
5.3.2
Módulo cliente ..........................................................................................................................88
5.3.2.1 Tela principal ......................................................................................................................... 89
5.3.2.2 Informações de um ponto de táxi ........................................................................................... 90
5.3.2.3 Chamada telefônica ................................................................................................................ 91
5.3.2.4 Enviar mensagem de texto ..................................................................................................... 93
5.3.2.5 Lista de favoritos.................................................................................................................... 94
5.3.2.6 Histórico de chamadas ........................................................................................................... 96
5.3.2.7 Cálculo de rota ....................................................................................................................... 97
5.3.2.8 Listagem de pontos de táxis próximos ................................................................................... 99
5.4
5.4.1
5.5
AVALIAÇÃO.............................................................................................................................100
Interpretação dos resultados.................................................................................................102
CONSIDERAÇÕES ...................................................................................................................107
6 CONCLUSÕES E TRABALHOS FUTUROS.......................................................................... 109
6.1
CONCLUSÕES ..........................................................................................................................109
6.2
TRABALHOS FUTUROS .........................................................................................................110
REFERÊNCIAS ................................................................................................................................ 112
APÊNDICES...................................................................................................................................... 120
APÊNDICE A – CRONOGRAMA.................................................................................................. 121
APÊNDICE B – DESCRIÇÃO DOS CASOS DE USO ................................................................. 122
APÊNDICE C – RESULTADOS DOS QUESTIONÁRIOS ......................................................... 132
15
1
INTRODUÇÃO
A mobilidade, em relação aos dispositivos eletrônicos, tornou-se fundamental na
sociedade contemporânea. É notável a crescente utilização dos telefones celulares e as
mudanças de como a sociedade se relaciona e compartilha dados entre si. De acordo com
Taurion (2002), esta transformação deve-se, principalmente, à constante busca de informação,
ocasionando a criação de novas tecnologias que visam estar disponíveis em locais fora dos
nossos lares ou salas de trabalho. Portanto, é possível reconhecer que a necessidade do acesso
à informação aumentou consideravelmente ao longo dos anos, e os celulares foram uns dos
primeiros dispositivos eletrônicos a agregarem novas tecnologias devido a sua popularidade, e
de, também, novas oportunidades.
As facilidades, vantagens e preços acessíveis resultaram em um grande
crescimento da procura por esta tecnologia. A Teleco (2011) divulgou que, em fevereiro de
2011, já haviam mais de 200 milhões de celulares no Brasil, ultrapassando a sua população
absoluta, 185.712.713 habitantes, segundo o IBGE (2010a). Este cenário favorável
impulsionou o mercado de aplicativos voltados para dispositivos móveis no país. Diversas
operações feitas nestes aparelhos atualmente, como consultar o saldo do banco ou organizar
uma agenda pessoal, já são realizadas facilmente por meio de celular. Uma grande quantidade
de aplicativos é criada todos os dias para atender às mais diversas necessidades.
A crescente evolução dos celulares nos últimos anos mudou drasticamente o
modo de como os usuários interagem com o aparelho. Hanson (2007) relata que a
comunicação sem-fio entre dispositivos eletrônicos permite que seus usuários trabalhem,
socializem-se e interajam com outros em qualquer lugar que estejam. Grandes investimentos
para aumentar o poder de processamento e a capacidade de armazenamento em memória dos
celulares tornaram possível agregar novas funcionalidades para atrair os desejos dos
consumidores. É perceptível esta evolução ser vista nos telefones celulares, já que, há alguns
anos, os mesmos estavam restritos a somente realizar ligações telefônicas, hoje já é possível
escutar músicas, assistir canais de televisão, ler livros, navegar pela Internet, visualizar emails, entre outras funcionalidades, tudo em um mesmo aparelho.
Os celulares acabaram, também, agregando a função de fornecer a localização
geográfica de seu usuário. A introdução desta tecnologia nos dispositivos móveis abriu portas
para a vinda de serviços baseados na localização para os dispositivos móveis, mais
16
conhecidos como LBS1. Os sistemas LBS, de acordo a GSMA2 (2011, p. 12, tradução nossa),
"são serviços [...] que fornecem aos seus usuários um conjunto de serviços ligados à
localização do cliente". Exemplos de sistemas LBS são: busca de restaurantes ou hospitais
mais próximos, rastreamento de veículos em tempo real, obter informações metrológicas do
local, entre outros. Este novo tipo de interação com o seu usuário final tornou mais prático e
simples a execução de tarefas rotineiras e custosas. O exemplo mais famoso de aplicação LBS
é o Foursquare3, uma rede social em que seus usuários compartilham os locais que visitaram,
podendo receber uma pontuação de acordo com a frequência em que utilizam o sistema.
Em decorrência do alto crescimento das aplicações LBS, surgem novas soluções
para problemas já existentes, como é o caso do transporte urbano. Silva e Mateus (2003)
afirmam que o transporte é um recurso indispensável para que qualquer país possa se
desenvolver. Porém, como comentam os autores, o crescimento desenfreado da frota de carros
nos grandes centros urbanos limita este recurso, tornando relevante a busca e a inovação de
novos meios de maximizar a facilidade de uso desta demanda que cresce cada dia mais. Entre
as soluções possíveis está o uso do serviço de táxi.
Como contribuição no sentido de fornecer informações às pessoas via seus
dispositivos móveis, e em concordância com o contexto apresentado no texto acima, este
trabalho busca modelar e desenvolver uma aplicação LBS para smartphones4 focada no
subsídio e na facilidade às buscas e ao uso dos serviços de táxis como estratégia para
melhorar a mobilidade urbana dos centros urbanos, utilizando tecnologias móveis como
ferramenta para auxiliar o uso deste tipo de serviço. A premissa específica desse trabalho está
baseada na sua facilidade de uso do sistema e no valor agregado oferecido aos seus usuários.
1.1
PROBLEMÁTICA
Muitas pessoas executam suas atividades diárias, seja para lazer ou trabalho, em
constante movimento. Seja para ir até ao local de trabalho ou para conhecer uma cidade,
1
Location Based Services – Serviços Baseados na Localização.
2
GSM Association – Associação de Operadoras de Comunicação móvel.
3
http://www.foursquare.com/
4
Celulares com funcionalidades avançadas (e-mail, chat, acesso à Internet, etc.).
17
quando o deslocamento dessas pessoas se torna logo o suficiente para que ela não possa
chegar a tempo no seu destino caminhando, surge a necessidade da utilização de algum meio
de transporte motorizado. Para as pessoas que desejam conforto, segurança e flexibilidade, o
uso do táxi, como meio de transporte, é uma boa opção. Contudo, apesar das facilidades
oferecidas por este tipo de serviço, há de se notar, também, alguns problemas comuns por
quem escolhe o táxi como opção de meio de transporte.
Em geral, nota-se que, dependendo muito da cidade, dos serviços de táxis
oferecidos e do horário da utilização, os seus usuários podem acabar tendo que esperar muito
tempo até a chegada do motorista. Quando o serviço é requisitado em horário de pico, dias
chuvosos, frios, o problema torna-se ainda maior. No ponto de vista dos motoristas, é difícil
encontrar os seus clientes em locais desconhecidos pelos mesmos, o que pode forçá-los a
conduzir os seus veículos sem passageiros (JIANXIN et al, 2009). A dificuldade ainda é
maior quando o usuário está em viagem e não consegue dar referências suficientes para um
taxista encontrá-lo.
Em tempo, para realizar uma chamada a um táxi, é necessário, obrigatoriamente,
conhecer o número do telefone de um ponto de táxi, uma informação quase sempre
indisponível para quem realmente deseja. Há também a necessidade de chamar aquele taxista
que se encontra mais próximo do cliente, a fim de realizar o embarque com maior rapidez.
Pode, também, haver a preferência do usuário por táxis com determinadas características,
como, por exemplo, ar-condicionado, televisão, adaptação para deficientes físicos, entre
outros. O valor aproximado da corrida é outra informação importante para o cliente poder
conhecer as melhores alternativas de serviços de táxis presentes no local.
1.2
OBJETIVOS
Os objetivos deste trabalho estão divididos em: objetivo geral e objetivos
específicos.
18
1.2.1 Objetivo geral
O objetivo deste trabalho é modelar e desenvolver um protótipo de um aplicativo
para smartphones com sistema operacional Android que permita ao usuário realizar buscas e
chamadas de táxis, baseando-se na sua localidade, com o objetivo de tornar a requisição deste
tipo de serviço mais rápido e eficiente.
1.2.2 Objetivos Específicos
São objetivos específicos do projeto:
 obter conhecimentos sobre o estado da arte atual sobre sistemas de localização e
buscas de serviços de transportes via Internet e smartphones;
 apresentar a modelagem do sistema utilizando a linguagem UML5;
 desenvolver um protótipo baseado na modelagem proposta;
 efetuar testes para avaliação do protótipo;
 apresentar os resultados alcançados.
1.3
JUSTIFICATIVA
É notável a participação dos celulares e de outros dispositivos móveis nas
atividades cotidianas da sociedade. De acordo com pesquisas da Gartner (2011), a venda de
smartphones pelo mundo cresceu 96% no terceiro semestre de 2009. Uma enorme quantidade
de aplicativos voltados a esta tecnologia são desenvolvidos para atender os mais variados
perfis e necessidades. A PR Newswire (2011) relatou que o mercado de aplicativos móveis é
estimado em 6,8 bilhões de dólares, no ano de 2010, com a previsão de crescer para 25
5
Unified Modeling Language – Linguagem de Modelagem Unificada
19
bilhões de dólares no ano de 2015. Este novo cenário possibilitou o surgimento de novas
maneiras de acesso à informação e de iteração com outras pessoas.
Todos os recursos oferecidos pelos celulares, aliados à sua popularidade e à
facilidade, possibilitam a oportunidade para a criação de novas tecnologias para solucionar
problemas comuns da sociedade. O sistema proposto por este trabalho visa a, principalmente,
contribuir na agilidade ao acesso às informações sobre a localização de táxis mais próximos
geograficamente de tal forma que possa ajudar na sua busca e solicitação deste serviço.
Construir um aplicativo para busca e chamadas de táxis que possa ser utilizado em
qualquer lugar é de grande utilidade para pessoas que utilizam os táxis para se locomover.
Para os próprios taxistas, também há grandes vantagens em divulgar suas informações no
sistema, estimulando, desta forma, os seus serviços para os usuários do software.
Espera-se que o resultado final desta pesquisa consiga trazer valor real para os
usuários dos sistemas de táxis, dando-lhes mais rapidez e facilidade no processo de busca e
chamada deste tipo de serviço, de modo que estimule o uso de táxis e diminua o número de
veículos nos grandes centros urbanos.
1.4
ESTRUTURA DA MONOGRAFIA
Este trabalho está dividido em seis capítulos que são descritos a seguir:
Os objetivos, as problemáticas e as justificativas são apresentados no Capítulo 1.
No Capítulo 2, tem-se a revisão bibliográfica. Nela, são abordados temas a
respeito do estado da arte da problemática apresentada nesta pesquisa, da plataforma Android,
sua arquitetura e vantagens de sua utilização, uma introdução à tecnologia GPS, noções
básicas de Sistemas de Informações Geográficos, assim como cartografia e, também, é
abordada a forma com que o Google Maps API facilita a localização de endereços.
Logo após, no Capítulo 3, são descritos o método de desenvolvimento do trabalho
e a arquitetura do sistema proposto.
Em seguida, no Capítulo 4, é apresentada a etapa de modelagem do sistema
proposto. Toda a arquitetura é apresentada neste capítulo utilizando a notação UML.
Em seguida, no Capítulo 5, é descrita a etapa de desenvolvimento e validação do
software, assim com a apresentação do resultado final do trabalho.
20
Por fim, no Capítulo 6, é apresentada a conclusão e possíveis melhorias futuras.
21
2
REVISÃO BIBLIOGRÁFICA
Este capítulo apresenta os assuntos teóricos utilizados pelo presente trabalho,
abordando o estado da arte sobre o serviço de busca e chamadas de táxis, os conceitos básicos
da plataforma Android, a tecnologia de rastreamento geográfico (GPS), os fundamentos de
um Sistema de Informação Geográfico (SIG) e, por fim, um estudo geral sobre o serviço de
mapas oferecido pela Google, o Google Maps.
2.1
ESTADO DA ARTE
Esta seção tem como objetivo apresentar as principais e mais importantes
soluções tecnológicas presentes no mercado (na data em que esta pesquisa foi elaborada) que
visam facilitar o uso de serviço de táxis, realizando comparações de funcionalidades entre elas
e indicar pontos que possam ser melhorados.
2.1.1 cab4me
Desenvolvido pela empresa alemã Skycoders, o aplicativo cab4me é o mais
conhecido software deste ramo. Possui versões tanto para Android quanto para iPhone. Este
aplicativo fornece informações completas de pontos de táxis, como: número de contato, site,
formas de pagamentos aceitos, serviços, número de táxis disponíveis, entre outros. Há,
também, uma lista de pontos de táxis favoritos criado pelo usuário e uma lista de histórico,
com as últimas chamadas realizadas pelo aplicativo. Sua área de cobertura é bastante ampla,
podendo, até, os próprios usuários indicarem pontos de táxis que não estão cadastrados
(SKYCODERS, 2011). A Figura 1 apresenta algumas telas deste aplicativo.
22
Figura 1 – Telas do sistema cab4me.
Fonte: SKYCODERS, 2011.
Sua interface é simples e intuitiva, porém, às vezes, a mesma pode confundir o
usuário por apresentar muitas informações na tela. Já o processo para chamar um táxi é um
pouco demorado: para chamar um táxi, é necessário, primeiramente, selecionar no mapa o
local de onde o usuário deseja realizar o embarque. Após isso, é plotado no mapa ícones
indicando locais que podem conter pontos de táxis. Clicando em um desses ícones, uma tela é
aberta listando todas as companhias de táxis do local escolhido. Selecionando um item desta
lista, é aberta uma segunda tela contendo as informações do ponto de táxi, onde o usuário
pode iniciar uma chamada.
De maneira geral, o aplicativo cab4me possui várias funcionalidades interessantes
para requisitar um ponto de táxi próximo ao seu usuário. O seu ponto forte é a riqueza de
informações fornecidas pelo aplicativo, o que ajuda muito uma pessoa que necessita de um
serviço de táxi para se locomover.
2.1.2 Tarifa de Táxi
Trata-se de um sistema simples, porém funcional. O Tarifa de Táxi é um sistema
disponível pela web que fornece informações sobre previsões de custo de rotas pelas
principais cidades do Brasil. Há versões tanto para dispositivos móveis quanto para desktop.
23
Com ele, é possível calcular o valor (aproximado) de uma corrida de táxi, baseando-se na
distância da rota e nos valores das bandeiras estipulados por cada cidade (TARIFA DE TÁXI,
2011). Segue a Figura 2 que demonstra tal funcionalidade.
Figura 2 – Tela do sistema Tarifa de Táxi.
Fonte: TARIFA DE TÁXI, 2011.
Apesar de fornecer custos de uma rota, o sistema não fornece número para contato
de pontos de táxis existentes na cidade, como ocorre no aplicativo cab4me.
2.1.3 myTaxi
Disponível apenas para a Alemanha, o aplicativo myTaxi permite o seu usuário
tenha acesso às informações de pontos de táxis espalhados em algumas cidades do país
alemão. Há versões somente para iPhone e Android. O sistema automaticamente fornece
acesso aos pontos de táxis mais próximos à localização do usuário, possibilitando que o
mesmo faça chamadas para pontos de táxis com muita facilidade (MYTAXI, 2011). Sua
interface é o seu maior ponto forte: simples e limpa. A Figura 3 mostra uma tela deste
aplicativo.
24
Figura 3 – Tela do sistema myTaxi.
Fonte: http://www.mytaxi.net/, 2011.
Para chamar um táxi é fácil e simples: basta clicar sobre um ícone de táxi no mapa
para aparecer uma janela no topo da tela. Selecionando a opção “Call”, será feita uma ligação
telefônica para o destino escolhido.
2.1.4 Taxi Magic
Mais um aplicativo para dispositivos móveis para busca de pontos de táxis. O
Taxi Magic é um sistema disponível para iPhone, Android, Blackberry e Palm que ajuda o seu
usuário a encontrar e requisitar um serviço táxi em algumas cidades dos Estados Unidos. Na
Figura 4, há uma tela deste sistema.
25
Figura 4 – Tela do sistema Taxi Magic.
Fonte: http://taximagic.com/, 2011.
Com ele, é possível chamar um táxi, rastrear a sua chegada, efetuar o pagamento e
receber um recibo eletrônico, tudo diretamente pelo celular. (TAXI MAGIC, 2011).
2.2
ANDROID
Com o objetivo de desenvolver o sistema proposto, é importante conhecer em
detalhes a tecnologia que é utilizada. É apresentado, a seguir, a plataforma Android, sua
composição, bibliotecas, componentes e os motivos da escolha desta tecnologia.
O Android é uma plataforma de código fonte aberto voltada para dispositivos
móveis (como smartphones e tablets). Nesta plataforma, é possível encontrar um sistema
operacional baseado em Linux6, diversos aplicativos, e um middleware7 que realiza a
6
Um sistema operacional “de código aberto, desenvolvido por programadores voluntários espalhados por toda
internet” (VIVA O LINUX, 2011).
26
comunicação entre o sistema operacional e os seus aplicativos (GOOGLE, 2011e). Seu futuro
e organização é de responsabilidade da Open Handset Alliance (OHA), um grupo de 80
empresas de comunicação, hardware8 e software9, que em conjunto definem rumo da
tecnologia (OHA, 2011). “Android foi construído com a intenção de permitir aos
desenvolvedores criar aplicações móveis que possam tirar total proveito do que um aparelho
portátil possa oferecer. Foi feito para ser verdadeiramente aberto.” (PEREIRA, SILVA, 2009,
p. 3).
O logotipo da plataforma pode ser visto na Figura 5.
Figura 5 – Logotipo do Android.
Fonte: Google, 2011k.
Em 2007, foi lançado oficialmente o T-Mobile G1, o primeiro smartphone com a
tecnologia Android (Figura 6). O seu lançamento causou uma grande surpresa no mercado.
Em poucos meses, mais de um milhão de pessoas realizaram o download do kit de
desenvolvimento da plataforma. (ROGERS et al, 2009, p. 3).
7
“Camadas de software que não constituem diretamente aplicações, mas que facilitam o uso de ambientes ricos
em tecnologia da informação. A camada de middleware concentra serviços como identificação, autenticação,
autorização, diretórios, certificados digitais e outras ferramentas para segurança.” (NRP, 2011).
8
Parte física de um dispositivo eletrônico.
9
Conjunto de comandos que permitem executar uma determinada tarefa.
27
Figura 6 – T-Mobile G1.
Fonte: Google, 2011g.
O seu lançamento foi amplamente aceito no mercado, e até hoje é possível
perceber o grande crescimento da utilização desta tecnologia. No ano de 2010, o Android
tornou-se a plataforma mais popular entre os consumidores, atingindo 32% entre as vendas de
smartphones nos Estados Unidos, de acordo com uma pesquisa da Nielsen (2011). No
segundo trimestre de 2011, 46.775.9 de smartphones utilizando o sistema operacional
Android foram vendidos em todo o mundo, o que representa 43,4% de todos os smartphones
vendidos no mundo, um crescimento de 29,2% em relação ao ano passado. (GARTNER,
2011). Estes números demonstram o crescimento desta plataforma em âmbito mundial e a
possibilidade de abrir novos mercados com esta tecnologia.
O código fonte do Android é licenciado utilizando da Apache Software License
2.0 (GOOGLE, 2011), o que garante que o software possa ser modificado e redistribuído sem
restrições e em qualquer outro tipo de licença, porém exige a inclusão de aviso de direitos
autorais. (APACHE, 2011a). Portanto, qualquer desenvolvedor pode contribuir ao projeto,
seja implementando novas funcionalidades, traduzindo textos ou encontrando e corrigindo
falhas, contribuindo, assim, com o crescimento da plataforma.
Os aplicativos Android são desenvolvidos utilizando a linguagem Java, uma
linguagem de programação de alto nível, orientada a objetos, robusta e portável. (ORACLE,
2011).
28
A sua arquitetura foi desenvolvida de modo a ser compatível independente do
hardware fabricado por diversas empresas. Isto permite que não seja necessário desenvolver
diversos aplicativos diferentes para atender às exigências de dispositivos específicos.
(FELKER, DOBBS, 2011).
2.2.1 Arquitetura
A sua arquitetura é dividida em: kernel, bibliotecas, runtime e framework de
aplicativos, como representada na Figura 7.
Figura 7 – Arquitetura da plataforma Android.
Fonte: Google, 2011e.
No nível mais baixo da arquitetura, encontram-se o kernel e drivers para os
diversos dispositivos presentes no smartphone. Logo a acima, há as bibliotecas nativas e o
runtime utilizados pela camada de framework de aplicativos. Esta camada fornece instruções
de alto nível para a criação de aplicativos customizados para o usuário, encontrados na última
camada do arquitetura.
29
Cada camada é brevemente apresentada nas seções a seguir.
2.2.1.1 Kernel
Com o objetivo de utilizar a plataforma Android em diversos tipos de hardwares
diferentes, é necessário o uso de um sistema operacional para o gerenciamento de recursos
computacionais. De acordo com Tanenbaum (2000, p. 17), um sistema operacional “controla
todos os recursos do computador e fornece a base sobre a qual os programas aplicativos
podem ser escritos”.
O sistema operacional desenvolvido para gerenciar os processos dos aplicativos,
memória e outros recursos de hardware é baseado no sistema operacional Linux versão 2.6,
servindo como uma camada de abstração entre os processos dos aplicativos e o hardware do
dispositivo móvel. (GOOGLE, 2011e).
No interior de cada sistema operacional, há um componente chamado de kernel.
Um kernel, segundo Alecrim (2011):
pode ser entendido com uma série de arquivos escritos em linguagem C e em
linguagem Assembly que constituem o núcleo do sistema operacional. É o kernel que
controla todo o hardware do computador. Ele pode ser visto como uma interface
entre os programas e todo o hardware. Cabe ao kernel as tarefas de permitir que
todos os processos sejam executados pela CPU e permitir que estes consigam
compartilhar a memória do computador.
Além disso, ele inclui os programas de gerenciamento de memória, as
configurações de segurança, o software de gerenciamento de energia e vários drivers de
hardware. (STRICKLAND, 2011). Ele também é responsável pelo driver da câmera digital,
enviando comandos para o hardware da câmera.
30
2.2.1.2 Bibliotecas
O Android fornece diversas bibliotecas nativas para os seus aplicativos. Algumas
dessas principais bibliotecas são, de acordo com Google (2011e):

Surface Manager: Gerencia a visualização de imagens e o acesso aos dispositivos de
saída visuais.

SQLite: Trata-se de um Sistema Gerenciador de Banco de Dados (SGBD)10 leve e
rápido.

FreeType: Responsável por renderizar fontes.

OpenGL ES: Uma API11 para desenvolvimento de formas em 3D.

Midia Libraries: Possibilita a reprodução de áudios e vídeos de diversos formatos.

WebKit: Rendizador de páginas web.
Para Strickland (2011), bibliotecas podem ser definidas como “um conjunto de
instruções que dizem ao dispositivo como lidar com diferentes tipos de dados”. As bibliotecas
mais comuns são as que dão suporte aos reprodutores de mídia. Outra biblioteca comum na
atualidade é a de aceleração tridimensional, responsável pelo “acelerômetro”, equipamento
responsável pela captação dos movimentos feitos no celular.
2.2.1.3 Runtime
No mesmo nível da camada de bibliotecas, é possível encontrar a camada de
runtime (ou camada de execução). De acordo com Pereira e Silva (2009, p. 8), “a pequena
camada de execução [...] é uma instância da máquina virtual Dalvik, criada para cada
aplicação executada no Android”. O Dalvik é uma máquina virtual criada por Dan Bornstein e
projetada especialmente para ser embarcada em dispositivos com recursos limitados.
10
Conjunto de softwares capazes de armazenar, modificar e extrair dados de um banco de dados. (PC
MAGAZINE, 2011b).
31
(BORNSTEIN, 2011). É nesta camada que os aplicativos do dispositivo são executados e
gerenciados pelo sistema operacional.
2.2.1.4 Framework de aplicativos
Segundo a DocForge (2011, tradução nossa), um framework pode ser definido
como “um conjunto de códigos ou bibliotecas que proveem uma funcionalidade comum para
toda uma classe de aplicações”. Sua finalidade é dar suporte ao desenvolvimento de
aplicações, de modo a torná-lo mais produtivo para a resolução de problemas já solucionados.
Para o suporte ao desenvolvimento de novos aplicativos, a plataforma Android
oferece um conjunto de componentes reutilizáveis na sua camada de frameworks. Para cada
componente, há uma responsabilidade única em um aplicativo. De acordo com Google
(2011h), os componentes são Activities, Services, Content Providers, Broadcast Receivers,
Intents e Intents Fitler.
Uma Activity (Atividade), de acordo com Pereira e Silva (2009), representam uma
única janela independente para o usuário. Elas são capazes de agrupar diversos tipos de
componentes que irão responder às ações para quem for utilizá-las. Uma aplicação deve
conter uma ou mais Activities, sendo que uma deve ser declarada a principal da aplicação, que
será executada quando o usuário iniciar o aplicativo pela primeira vez. Um exemplo de
activity pode ser visto na Figura 8.
11
Application Programming Interface – Interface de Programação de Aplicações.
32
Figura 8 – Exemplo de activity.
Fonte: http://developer.android.com/guide/topics/ui/layout-objects.html (2011).
Cada Activity possui o seu ciclo de vida, que é gerenciado pelo sistema
operacional. Na Figura 9, é representado graficamente esse ciclo, assim como as respectivas
funções que são executadas quando um estado é iniciado.
Figura 9 – Ciclo de vida de uma Activity
Fonte: Pereira e Silva (2009, p. 12)
33
Um Activity é capaz de iniciar outra Activity (por meio de Intents, que são
apresentados mais à frente), parando a Activity anterior (sem antes salvar os seus dados) e
colocando-a em uma pilha de Activities (chamada de “Back Stack”). Quando o usuário
pressionar a tecla de voltar ou finalizar o trabalho em uma Activity, a Activity no topo da pilha
retorna as suas atividades. (GOOGLE, 2011i).
As Services (Serviços) são “trechos de código que normalmente são executadas
em segundo plano pelo tempo de sua criação até o desligamento do dispositivo. Elas
geralmente não expõem uma interface ao usuário”. (ROGERS, 2009, p. 7, tradução nossa).
Um exemplo possível para uma Service é um aplicativo que reproduz músicas. Enquanto o
usuário interage com a interface, haverá uma Service responsável pela leitura e reprodução da
música sem que a mesma interrompa ou bloqueie as ações do usuário.
Content Providers (Provedores de Conteúdo) é “a forma de compartilhas dados
entre os aplicativos. Este permite que outras aplicações possam armazenar e recuperar dados
no mesmo repositório utilizado por aquela aplicação”. (PEREIRA, SILVA, 2009, p. 15). Os
Content Providers são ativados por meio de Content Resolvers (Resolvedores de Conteúdo).
De acordo com Google (2011h), um Broadcast Receiver (Receptor de
Transmissões) são componentes capazes de responder a estímulos do sistema operacional ou
de outros aplicativos. Por exemplo, um Broadcast Receiver é capaz de anunciar a um
aplicativo que a bateria está fraca. Os Broadcast Receivers não possuem interfaces de usuário.
Para que seja possível ativar os componentes anteriormente listados (com exceção
dos Content Providers), é necessário o uso de uma Intent (Intenção). Intents são “estrutura de
dados que contém uma descrição abstrata de uma operação para ser executada”. (GOOGLE,
2011j, tradução nossa). É possível determinar quais Intents um determinado componente pode
receber. Para isso, é necessário o uso de Intent Filters (Filtros de Intenções). Estes filtros são
registrados no arquivo AndroidManifest.xml de cada aplicativo. (PEREIRA, SILVA, 2009).
Cada aplicativo deve manter um arquivo contendo as configurações de
funcionamento do mesmo. Este arquivo é chamado de AndroidManifest.xml e está localizado
no diretório raiz do aplicativo. Nele, é registrada a descrição de todos os componentes, suas
classes envolvidas, dados que podem tratar e também permissões de acesso às
funcionalidades específicas (como câmera, GPS, telefone, etc.). (PEREIRA, SILVA, 2009). O
seu conteúdo é lido pelo sistema operacional no momento em que aplicação é iniciada.
34
2.3
GPS
Com o avanço tecnológico dos sistemas de navegação por satélites, o GPS
(Global Positioning System) deixou de ser exclusiva para militares, navegadores ou
agricultores para a obtenção do posicionamento global. De acordo com Sousa e Lima (1997,
p. 120), “o surgimento do GPS provocou grandes mudanças nos sistemas convencionais de
posicionamento e navegação”. A vinda dessa tecnologia para os dispositivos móveis
popularizou o seu uso, possibilitando que aplicativos se comportem de acordo com a posição
atual do seu usuário, trazendo uma nova maneira de interatividade para os seus usuários.
Segundo Koolhaas (2011, p. 1, tradução nossa), “o GPS é um sistema de satélite
usado na navegação que permite determinar a posição durante 24 horas por dia, em qualquer
lugar do planeta e em qualquer condição climática”. Para Monico (2000, p. 2):
[...] o GPS, ou NAVSTAR-GPS (NAVigation Satellite with Time And Ranging), é um
sistema de radionavegação desenvolvido pelo Departamento de Defesa dos Estados
Unidos da América - DoD (Department of Defense), com o intuito de ser o principal
sistema de navegação das forças armadas americanas.
De acordo com Lammertsma (2005), a história da navegação por satélite teve
início na Guerra Fria, durante a corrida espacial entre os Estados Unidos e a União Soviética.
Em 1974, é dado início ao projeto NAVSTAR12 pelas forças armadas americanas, como uma
ferramenta para auxiliar na criação de estratégias militares. No início do ano de 1995 e com
um orçamento de 10 bilhões de dólares, o sistema GPS, como é conhecido hoje, foi
oficialmente posto em operação. (KOOLHASS, 2003).
O GPS é amplamente utilizado para diversas finalidades. Além de servir como
uma ferramenta para navegação aérea, marítima e terrestre, é possível encontrar o uso deste
sistema na cartografia, topografia, georreferenciamento, agricultura, segurança, rastreamento
de cargas, entre outras funções. (MONICO, 2000).
Para Koolhass (2003), esse sistema possui várias vantagens em relação a outras
formas de navegação, como bússolas, mapas, altímetros, etc. Sua velocidade, precisão e
disponibilidade em condições climáticas adversas (chuva, céu nublado, etc.) são as suas
maiores características que o torna um sistema altamente confiável. Porém, em locais estreitos
12
Navigation Satellite with Time and Ranging – Navegação por Satélite com Tempo e Alcançe
35
ou fechados, os receptores GPS podem não conseguir realizar a comunicação entre os
satélites.
2.3.1 Segmentos
El-Rabbany (2002) define que o GPS é separado em três segmentos: o segmento
espacial, o segmento de controle e o segmento de usuário.
2.3.1.1 Segmento Espacial
O segmento espacial, segundo Monico (2000), consiste de 24 satélites distribuídos
em seis planos orbitais igualmente espaçados, com quatro satélites em cada plano, numa
altitude aproximada de 20.200 km. Essa configuração garante que, no mínimo, quatro satélites
GPS sejam visíveis em qualquer local da superfície terrestre, a qualquer hora. Na Figura 10, é
possível visualizar graficamente esta distribuição de satélites na órbita terrestre.
36
Figura 10 – Distribuição de satélites GPS.
Fonte: Monico, 2000.
Cada satélite é equipado com quatro relógios atômicos, sendo que dois destes
utilizam o elemento césio e os outros dois utilizam o elemento rubídio. Esta configuração
permite que os satélites tenham o horário exato para transmitir aos receptores, não podendo
atrasar mais de 10 nanosegundos. Estes horários são sincronizados a cada quatro horas pelo
segmento de controle. (PESTANA, 2011; LAMMERTSMA, 2005).
2.3.1.2 Segmento de Controle
Segundo Alouni (1996), esse segmento é controlado pelo Departamento de Defesa
Americano. A principal estação de controle situa-se na cidade de Colorado Springs, Colorado,
já as demais estações localizam-se no atol de Kwajalein (Ilhas Marshall, Oceano Pacífico),
Havaí (Oceano Pacífico) e nas ilhas de Ascensão (Oceano Atlântico) e Diego Garcia (Oceano
Índico). As estações de controles estão localizadas próximo à linha do Equador para evitar
37
grandes interferências da ionosfera. (LAMMERTSMA, 2005). A localização dessas estações
é mostrada na Figura 11:
Figura 11 – Segmento de controle do GPS.
Fonte: Monico, 2000.
A função destas estações, segundo Lammertsma (2005), é monitorar todo o
sistema GPS na procura de eventuais erros ou inconsistências nos dados emitidos pelos seus
satélites, além de corrigir periodicamente os relógios internos dos mesmos.
2.3.1.3 Segmento de Usuário
Neste segmento, de acordo com El-Rabbany (2002), incluem-se todos os
receptores utilizados por civis e militares. Para a captação dos sinais emitidos pelos satélites
em qualquer lugar do planeta, é necessário o uso de um receptor GPS que é um equipamento
eletrônico provido de uma antena, podendo ser interna ou externa. Segundo Koolhaas (2011),
há uma grande quantidade de receptores GPS no mercado, e cada ano aparecem novos
modelos com diferentes benefícios e características. A Figura 12 fornece dois exemplos de
receptores:
38
Figura 12 – Exemplos de receptores GPS
Fonte: Monico, 2000
Para Monico (2000), “há uma grande quantidade de receptores no mercado
civil, para as mais diversas aplicações, limitadas apenas pela imaginação dos usuários, o que
demonstra que o GPS realmente atingiu sua maturidade”.
2.3.2 Funcionamento
O princípio básico de navegação pelo GPS, segundo Monico (2000), consiste:
[...] na medida de distâncias entre o usuário e quatro satélites. Conhecendo as
coordenadas dos satélites num sistema de referência apropriado, é possível calcular
as coordenadas da antena do usuário no mesmo sistema de referência dos satélites.
Do ponto de vista geométrico, apenas três distâncias, desde que não pertencentes ao
mesmo plano, seriam suficientes. Nesse caso, o problema se reduziria à solução de
um sistema de três equações, a três icógnitas. A quarta medida é necessária em razão
do não sincronismo entre os relógios dos satélites e o do usuário, adicionando uma
icógnita ao problema.
Lammertsma (2005) descreve, em mais detalhes, os passos necessários para o
cálculo da posição geográfica:
39
1. O receptor recebe o sinal de um satélite GPS.
2. O mesmo determina a diferença entre o tempo atual e o tempo recebido pelo sinal do
satélite.
3. A partir desta diferença, é realizado o cálculo para determinar a distância entre o
receptor e o satélite, sabendo-se que o sinal foi enviado a uma velocidade próxima da
luz.
4. O receptor recebe um sinal de outros dois satélites, e novamente é calculada a
distância entre ambos.
5. Conhecendo a distância de três satélites GPS, o receptor determina a sua localização
utilizando o princípio matemático chamado trilateração. Esse processo é demonstrado
na Figura 13.
A trilateração corresponde a um cálculo matemático para conhecer os pontos de
intersecção entre três esferas. No caso do sistema GPS, o raio de cada uma dessas esferas é
equivalente à distância entre o satélite e a antena, que foi calculada pelo receptor. Fazendo a
intersecção dessas três esferas, é possível identificar dois pontos que são comuns às mesmas
(como pode ser visto na Figura 13, item c). Utilizando o planeta Terra como uma quarta
esfera, descarta-se um ponto e somente o outro ponto é comum entre as quatro esferas. Este
ponto é a posição exata do usuário. Para que os cálculos das distâncias sejam feitas
corretamente, é importante que os relógios internos dos satélites estejam precisos e
sincronizados, sendo estes constantemente atualizados pelos segmentos de controle do
sistema. (PESTANA, 2011).
40
Figura 13 – Processo de trilateração entre satélites
Fonte: Lammertsma, 2005
De acordo com El-Abbany (2002), somente três satélites são necessários para
determinar a posição de um alvo na superfície terrestre. Porém, na prática, há a necessidade
da participação de um quarto satélite para a sincronia de horários entre os satélites e o
receptor.
2.3.2.1 Modos de Operação
De acordo com Monico (2000), o sistema GPS possui dois padrões de operação:

Standard Positioning System (SPS): Disponível para todos os usuários civis. Possui
uma margem de erro entre 100 e 140 metros, com um nível de confiança de 95%.

Precise Positioning System (PPS): Restrito ao uso militar e de usuários autorizados.
Sua margem de erro é de 1 a 20 metros.
Segundo o autor, o sistema GPS pode ter precisão maior do que estes dois padrões
de operação. Porém, por se tratar de um sistema global, uma margem de erro menor pode por
em risco os aspectos de segurança.
41
2.4
SISTEMAS DE INFORMAÇÕES GEOGRÁFICOS
O capítulo apresentado a seguir abrange os conceitos e utilizações dos Sistemas de
Informações Geográficos, assim como noções básicas de cartografia para compreender, com
maiores detalhes, os tipos de dados que este sistema gerencia.
2.4.1 Definição
Há diversas definições aceitas para entender o conceito de Sistema de Informação
Geográfico (SIG ou GIS - Geographic Information System, traduzido para o inglês). Para
Câmara e outros (1996, p. 3), SIG “são sistemas de informação construídos especialmente
para armazenar, analisar e manipular dados geográficos”. Segundo Davis (2001, p. 13,
tradução nossa), um SIG pode ser definido como “tecnologias e metodologias para coletar,
gerenciar, analisar, modelar e apresentar dados geográficos para uma ampla gama de
aplicações”, já para Longsdon (1995, apud FRENCH, 1996, p. 187, tradução nossa) trata-se
de “um sistema composto por hardware, software e processos designados para suportar a
captura, gerenciamento, manipulação, análise e visualização de dados espaciais com a
finalidade de solucionar problemas complexos de gestão”.
Devido a estas definições, podemos perceber a importância de uso de um SIG
quando existir a necessidade de conhecer o local de um dado.
Pode-se dizer, de forma genérica, “Se onde é importante para seu negócio, então
Geoprocessamento é uma ferramenta de trabalho”. Sempre que o onde aparece,
dentre as questões e problemas que precisam ser resolvidos por um sistema
informatizado, haverá uma oportunidade para considerar a adoção de um SIG.
(CÂMARA; DAVIS, 2011, p. 1).
42
2.4.2 Funções
Uma vez entendidas as definições de um SIG, há de se conhecer, também, a
maneira de como estes sistemas operam. Um SIG exerce diversas funções para tornar possível
um gerenciamento de dados espaciais. Estas funções são descritas, a seguir, baseando-se nas
definições de Davis (2001, p. 15):

Coletar: obter dados geográficos a partir de diversas fontes, como, por exemplo,
imagens de satélites, mapas, Internet, textos, etc.

Armazenar e gerenciar: integrar os dados coletados em uma base de dados geográfica,
de maneira que possam ser recuperados de maneira eficiente.

Recuperar: selecionar os dados desejados para que possam ser utilizados por quem o
necessita.

Converter: transformar um dado de um determinado tipo para outro. Ex.: Converter a
projeção de um mapa.

Analisar: uso de técnicas para obter informações sobre os dados armazenados.

Modelar: tornar os dados mais simples de acordo com um contexto.

Visualizar: apresentar dados em vários formatos diferentes. Ex.: Mapas, gráficos,
imagens.
2.4.3 Cartografia
Por séculos o ser humano teve a curiosidade de conhecer o mundo que o cerca.
Este desejo o levou a representar graficamente o espaço em que vive por meio de imagens e
de técnicas de cartografia. A cartografia pode ser definida como uma ciência e arte voltada
para o desenho e construção de mapas (RAMESH; MISRA, 1969, p. 13).
A seguir, são descrito os principais elementos desta ciência que são essenciais no
desenvolvimento do projeto desta pesquisa:
43
2.4.3.1 Mapas
Os mapas são os principais objetos de pesquisa da Cartografia. É por meio delas
que é possível conhecer a localização de um ponto no espaço. Segundo o IBGE (2011b):
Mapa é a representação no plano, normalmente em escala pequena, dos aspectos
geográficos, naturais, culturais e artificiais de uma área tomada na superfície de uma
figura planetária, delimitada por elementos físicos, político-administrativos,
destinada aos mais variados usos, temáticos, culturais e ilustrativos.
Para a International Cartographic Association (2011, tradução nossa), um mapa é
“uma imagem simbolizada da realidade geográfica, representando os recursos selecionados,
ou características, resultantes do esforço criativo de seu autor”.
Cada mapa é construído visando fornecer alguma informação específica. Existem
mapas que contem informações físicas, naturais, políticas, econômicas e sociais de uma
região. Além disso, um mapa deve informar qual projeção cartográfica foi utilizada para
representar a área estudada, o sistema de coordenada usado para conhecer a posição de um
determinado ponto na Terra e a escala para realizar cálculo de distâncias e conhecer o nível de
detalhamento visualizado.
2.4.3.2 Projeções
Antes de iniciar o trabalho de confecção de um mapa, é necessário que seja
determinado qual projeção cartográfica é utilizada para representar a Terra em uma superfície
plana (IBGE, 2011b). Segundo Bernhardsen (2002, p. 118), dados geográficos somente
podem ser desenhados em um mapa se projetados em uma superfície plana, portanto, em
razão da superfície da Terra ser curva (elipsóide), é necessária a aplicação de técnicas de
projeção para torná-la plana. Entre as projeções mais conhecidas, destacam-se a Spherical
Mercator (utilizada pelo serviço Google Maps) e a UTM13.
13
Universal Transverse Mercator
44
Segundo Oliveira (1993 apud FLITZ, 2005), as projeções cartográficas podem ser
classificadas como:

quanto ao tipo de superfície da projeção:
o planas: quando a superfície for um plano;
o cônicas: quando a superfície for um cone;
o cilíndricas: quando a superfície for um cilindro;

quanto à posição da superfície da projeção:
o equatorial: quando o centro da superfície de projeção situa-se no
equador terrestre;
o polar: quando o centro do plano de projeção é um polo;
o oblíqua ou horizontal: quando está em qualquer outra posição;
A Figura 14 demonstra alguns tipos de projeções cartográficas quanto ao tipo de
superfície utilizada para planificar a superfície terrestre.
45
Figura 14 – Tipos de projeções quando à sua superfície.
Fonte: IBGE, 2011b.
Apesar das diferentes técnicas de projeção, nenhuma é capaz de representar
fielmente as áreas e distâncias do planeta Terra em sua totalidade, devido à sua forma
elipsoidal. Cada projeção cartográfica busca representar as melhores distâncias ou áreas de
uma região em específico, porém, sempre deformando as outras regiões próximas (FLITZ,
2005).
2.4.3.3 Sistemas de Coordenadas
Em razão da esfericidade da Terra, para que seja possível representá-la em uma
superfície não-plana, é necessário que seja utilizado um sistema de coordenadas para
46
determinar a maneira de como é distribuído de pontos sobre a superfície (IBGE, 2011b). Um
sistema de coordenada pode ser definido como “uma estrutura de referências utilizadas para
comparar os detalhes da Terra com um modelo (mapa)”. (RAMESH; MISRA, 1969, p. 79,
tradução nossa).
Entre os sistemas de coordenadas atualmente conhecidos, o mais utilizado para a
representação de mapas é o sistema de coordenada geográfico. Este sistema basea-se em um
par de coordenadas para determinar a localização sobre a superfície terrestre representada por
meio de um mapa. (RAMESH; MISRA, 1969). De acordo com Bernhardsen (2002), este
sistema de coordenada utiliza graus, minutos e segundos como unidade de medida.
O par de coordenadas utilizado pelo sistema de coordenada geográfica é chamado
de latitude e longitude, descritos a seguir.
2.4.3.3.1 Latitude
As latitudes (ou paralelos), segundo o IBGE (2011b), são “os arcos contados
sobre o meridiano do lugar e que vai do Equador até o lugar considerado”. A Figura 15
apresenta com maior detalhe a representação da latitude.
Figura 15 – Latitude.
Fonte: Branco, 2011.
47
A sua variação é de 0º até 90º N (norte) e de 0º até 90º S (sul). A latitude 0º é
conhecida como Linha do Equador. (IBGE, 2011b).
2.4.3.3.2 Longitude
Similares às latitudes, as longitudes (ou meridianos) são linhas imaginárias que
partem do polo sul até o polo norte (RAMESH; MISRA, 1969). Na Figura 16, há uma
representação ilustrada das longitudes.
Figura 16 – Longitude.
Fonte: Branco, 2011.
A longitude varia de 0º até 180º W (oeste) e de 0º até 180 E (leste). A longitude 0º
é conhecida como Meridiano de Greenwich, já a longitude 180º é comumente conhecida
como Antimeridiano de Greenwich.
2.4.3.4 Escalas
Não existe uma maneira eficaz de representar a superfície terrestre sem que haja
uma redução no nível de detalhamento de um mapa. Para isso, utiliza-se uma escala para
48
determinar qual a proporção com a Terra usada para a construção do mapa. Segundo
(CÂMARA et al., p. 6, 1996), a escala é “a relação entre as dimensões dos elementos
representados em um mapa e a grandeza correspondente, medida sobre a superfície da Terra”.
Portanto, é possível representar, matematicamente, a escala como:
Figura 17 – Fórmula matemática da escala.
Fonte: Elaboração dos autores, 2011.
As escalas são itens obrigatórios de um mapa, sendo geralmente representados
como na Figura 18.
Figura 18 – Exemplos de escalas.
Fonte: IBGE, 2011.
Quanto maior for uma escala, menor será o nível de detalhamento de um mapa.
Logo, para que seja conhecido em maior detalhe de uma determinada área da superfície
terrestre, é necessário que a escala seja diminuída. (RAMESH; MISRA, 1969).
49
2.5
GOOGLE MAPS
Segundo Google (2011b), o Google Maps é “um serviço do Google que oferece
uma poderosa e amigável tecnologia de mapas e informações sobre empresas locais, incluindo
endereços, informações de contato e rotas para as empresas”. Para Marimoto (2009), “ele é
também o mais fácil de usar e pode ser instalado em praticamente qualquer aparelho, com
versões nativas para o Symbian, Android, Windows Mobile e iPhone”.
Lançado no ano de 2005, o Google Maps revolucionou o modo de visualizar
mapas pela Internet. Com o uso da tecnologia AJAX14, é possível navegar em qualquer lugar
do planeta com poucos cliques, sem que seja necessário renderizar toda a página. Suas
funcionalidades e riquezas de informações fizeram os seus concorrentes ficarem obsoletos
(PETERSON, 2011).
Este serviço é muito utilizado pelas pessoas para localizar endereços e
informações de contato. Além disso, o serviço Google Maps disponibiliza a funcionalidade de
rotas detalhadas, ferramenta que auxilia o usuário a obter o melhor caminho para chegar a
determinado endereço. Aliado a estas funcionalidades, há também a possibilidade de
arrastamento dos mapas para melhor visualização, imagens de satélite, vista da rua desejada,
atalhos no teclado e zoom com botão de rolagem.
Para os locais que o usuário navega, há diversas informações disponíveis, como a
descrição de pontos turísticos, fotos, sugestões de bares e restaurantes, museus. A Figura 19
mostra a maneira de como estas informações são expostas na interface do usuário.
14
Asynchronous JavaScript and XML (JavaScript e XML Assíncronos) – Tecnologia para troca de dados entre
um servidor web sem a necessidade de recarregar a página. (W3SCHOOLS, 2011).
50
Figura 19 – Interface do serviço Google Maps.
Fonte: http://maps.google.com, 2011.
A Figura 20 fornece um exemplo da funcionalidade de vista da rua do Google
Maps, utilizando um celular:
Figura 20 – Funcionalidade vista da rua do Google Maps.
Fonte: Marimoto, 2009.
Sobre a limitação do Google Maps, segundo Marimoto (2009):
A grande limitação do Google Maps é que ele não oferece a opção de baixar os
mapas previamente, se limitando a transferi-los conforme você se desloca, usando
tráfego de dados. O volume de dados transmitidos é relativamente pequeno, de
forma que é perfeitamente possível usá-lo esporadicamente mesmo nos planos prépagos.
51
Entre os concorrentes diretos do Google Maps, destaca-se o serviço Bing Maps15
da Microsoft, Yahoo! Maps16 da Yahoo! e o OpenStreetMap17 da Fundação OpenStreeMap. O
Google Maps difere-se destes outros serviços por oferecer maior riqueza em seus dados e
interatividade com o seu usuário, tornando-o um dos principais serviços de mapas online da
Internet.
2.5.1 Google Maps API
Uma API pode ser definida como “um formato de mensagem e linguagem
utilizada por um programa, aplicativo para se comunicar com o sistema operacional ou algum
programa de controle”. (PC MAGAZINE, 2011a, tradução nossa). As API’s são utilizadas
para poupar esforços com desenvolvimento de uma nova funcionalidade para o sistema, com
isso o desenvolvimento de um novo software acaba se tornando mais rápido. Para Roos
(2011), “uma API se assemelha ao Software como Serviço (SaaS), no sentido de que os
criadores de software não têm tempo de começar do zero a cada vez que escrevem um
programa”.
Outras vantagens são visíveis na utilização de uma API na aplicação (software).
Abaixo, seguem algumas destas vantagens:
 as empresas não precisam pagar por softwares de terceiros para utilizar uma
funcionalidade nova.
 adaptação aos sistemas já existentes. Uma vez a especificação esteja
disponível, fica transparente para o desenvolvedor ajustar a mesma às suas
necessidades.
 comunidade colaborativa: desenvolvedores colaboram com tutoriais (dicas) de
como utilizar a API. As dúvidas frequentes também são levadas em
consideração.
Nas duas seções, a seguir, são descritas duas APIs oferecidas pelo serviço de
mapas da Google, a Google Geocoding API e a Google Direction API.
15
http://www.bing.com/maps/
16
http://maps.yahoo.com/
17
http://www.openstreetmap.org/
52
2.5.1.1 Google Geocoding API
Esta API é responsável pela conversão de endereços físicos em coordenadas
geográficas, com isto os dados do endereço ficam mais “legíveis” para o serviço Google
Maps. A operação inversa da operação também é possível com a utilização desta API.
Este serviço é disponibilizado pela Google e é voltado a desenvolvedores que
desejam obter localizações mais precisas a partir de coordenadas ou de endereços. Para
Google (2011d), o Google Geocoding API pode ser usada apenas em conjunto com um mapa
do Google; a geocodificação de resultados sem exibi-los em um mapa é proibida. Esta API em
conjunto com o Google Maps, fornece uma poderosa ferramenta de geolocalização,
fornecendo a localização precisa baseada em informações.
2.5.1.2 Google Direction API
O Google Directions API é um serviço que calcula rotas entre os locais usando
uma solicitação HTTP. As rotas podem informar origens, destinos e pontos de referência
(Google, 2011c). De acordo com Reckziegel (2010), esta API aceita tanto endereços do tipo
texto como também latitudes e longitude previamente formatadas de acordo com o padrão
estabelecido.
Este serviço, em conjunto com o Google Maps, é bastante eficiente e tem sido
muito utilizado pelas pessoas que desejam ir para um lugar desconhecido por elas, ou então
por um endereço que contenha muitas ruas, dependendo assim de um guia para mostrar qual o
melhor trajeto de onde ela está (ponto origem) até onde querem chegar (ponto destino). Para
o cálculo da rota, o usuário deve informar o endereço de origem em que se encontra e o
endereço de destino a que deseja chegar. O cálculo da melhor rota, distância e tempo é feito
pela API, que juntamente com o Google Maps, apresenta o resultado de forma interativa no
mapa.
53
3
MÉTODO
Por se tratar de uma pesquisa de cunho científico, é imprescindível a apresentação
dos métodos que são utilizados na realização deste trabalho. O conceito de método, segundo
Cervo e Bervian (2002, p. 23), “é a ordem que se deve impor aos diferentes processos
necessários para atingir um certo fim ou um resultado desejado”.
3.1
CARACTERIZAÇÃO DO TIPO DE PESQUISA
Definir o conceito de pesquisa é indispensável para conduzir com eficiência no
avanço de qualquer trabalho científico. De acordo com a definição de Kourganoff (1990, apud
MATTAR NETO, 2002, p. 94), “a pesquisa é o conjunto de investigações, operações e
trabalhos intelectuais ou práticos que tenham como objetivo a descoberta de novos
conhecimentos, a invenção de novas técnicas e a exploração ou a criação de novas
realidades”. Para Cervo e Bervian (2002, p. 63), “a pesquisa é uma atividade voltada para a
solução de problemas teóricos ou práticos com o emprego de processos científicos”. Já, para
Ruiz (1996), uma pesquisa científica é a prática de uma investigação realizada de acordo com
as regras aceitas pela ciência.
No que se refere à sua área de ciência, esta pesquisa é caracterizada como prática,
pois o seu principal objetivo é criar um protótipo a partir de um modelo proposto para atender
às necessidades dos usuários de táxis. O intuito das pesquisas práticas é resolver
problemáticas encontradas em determinadas situações, com objetivo de aumentar o
conhecimento dos envolvidos nela (pesquisadores e pesquisados). (PRESTES, 2003, p. 25).
Quanto ao seu objetivo, a utilização do tipo de pesquisa exploratória é a que
melhor se encaixa neste trabalho, pois o mesmo busca aprofundar os seus conhecimentos
teóricos por meio de uma pesquisa bibliográfica, seguido de uma proposta para o problema
definido. Os objetivos das pesquisas exploratórias, segundo Andrade (1998, p. 104), são:
“proporcionar maiores informações sobre determinado assunto; facilitar a delimitação de um
54
tema de trabalho; definir os objetivos ou formular as hipóteses de uma pesquisa ou descobrir
novo tipo de enfoque para o trabalho que se tem em mente”.
Já do ponto de vista da sua abordagem ao problema, trata-se de uma pesquisa
qualitativa, pois, segundo Mezzaroba e Monteiro (2005), a mesma não pretende interpretar os
seus dados dentro de seu contexto, e não de maneira descritiva, como ocorre nas pesquisas
quantitativas. É utilizando as ponderações das informações feitas durante o desenvolvimento
da pesquisa que trará valor ao trabalho realizado. Os resultados desejados por esta pesquisa
não poderão ser demonstrados numericamente, mas por meio de modelos e de protótipos.
O objeto de pesquisa proposto é o de pesquisa bibliográfica. Este foi escolhido
pela facilidade que o pesquisador tem de encontrar mais materiais do que se fizesse uma
pesquisa diretamente (GIL, 1991). O presente trabalho busca informações a partir de livros,
artigos e normas para fundamentar suas escolhas e declarações.
3.2
ETAPAS
As etapas para a elaboração da monografia são:
a.
levantamento teórico;
b.
estudo da plataforma Android;
c.
estudo da API do Google Maps;
d.
captação de requisitos;
e.
modelagem do sistema;
f.
prototipação;
g.
implementação do sistema;
h.
testes;
i.
avaliação;
j.
apresentação dos resultados.
Estas etapas foram distribuídas dentro do período da realização desta pesquisa
conforme o cronograma (ver Apêndice A).
55
3.3
ARQUITETURA DA SOLUÇÃO PROPOSTA
Levando em consideração os objetivos pretendidos e as tecnologias escolhidas,
uma proposta de solução para o problema foi desenvolvida, como mostra a Figura 21.
Figura 21 – Arquitetura da Solução.
Fonte: Elaboração dos Autores, 2011.
Trata-se de uma arquitetura composta por três camadas:
 Camada Cliente: São todos os dispositivos móveis que acessam às informações do
sistema utilizando um aplicativo desenvolvido especificamente para tal função.
 Camada Servidor: Possui a responsabilidade de armazenar e consultar os dados dos
pontos de táxis cadastrados, além de processar as requisições realizadas pelas outras
camadas. É composto por um servidor de aplicação e um banco de dados geográfico,
capaz de armazenar e processar dados geográficos.
 Camada Administração: Responsável pela manutenção dos dados fornecidos pela
camada Servidor. Nele, o administrador do sistema pode ter acesso aos dados dos
pontos de táxis cadastrados, podendo adicionar novos pontos de táxis no sistema, além
de atualizar ou remover os pontos da base de dados já existentes.
56
Externo, em relação ao sistema, há o uso da tecnologia GPS e do serviço de
mapas oferecido pela Google, necessários para que toda a aplicação opere da maneira
desejada. O sistema GPS, como visto na seção 2.3, é encarregado por fornecer as coordenadas
geográficas do dispositivo móvel da camada cliente. Este, de posse desta informação, pode
visualizar sua posição atual em um mapa utilizando o serviço de mapas provido pelo Google
Maps por meio de seu smartphone. Para as ações que o cliente deste serviço queira executar
sobre o sistema (como listar pontos de táxis mais próximos ou calcular custo de uma rota),
são enviadas mensagens para a camada Servidor realizar o processamento destas requisições.
3.4
DELIMITAÇÕES
A solução proposta está restrita somente à busca e a chamadas de pontos de táxis
em smartphones que suportem a tecnologia Android, assim como a realização do cálculo do
valor aproximado de uma rota por meio da API do Google Maps.
57
4
MODELAGEM DO SISTEMA
Neste capítulo, é abordada a etapa de planejamento de desenvolvimento do
sistema proposto por este trabalho, assim como a apresentação dos resultados do processo de
modelagem do mesmo. Modelagem, de acordo com Booch, Rumbaugh e Jacboson (2000, p.
89), é “uma simplificação da realidade para entender melhor o sistema de desenvolvimento”.
Para modelar um sistema, é necessário o uso de uma linguagem que permita representá-lo por
meio de diagramas para as suas diferentes perspectivas.
4.1
LINGUAGEM DE MODELAGEM UNIFICADA (UML)
De acordo com Booch, Rumbaugh e Jacobson (2000, p. 13), criadores desta
linguagem, a UML é:
[...] uma linguagem gráfica para visualização, especificação, construção e
documentação de artefatos de sistemas complexos de software. A UML proporciona
uma forma-padrão para a preparação de planos de arquitetura de projetos de
sistemas, incluindo aspectos conceituais tais como as classes escritas em
determinada linguagem de programação, esquemas de banco de dados e
componentes de software reutilizáveis.
Para modelar o sistema proposto, é utilizada a linguagem UML na sua versão 2.1
com base nos requisitos e regras de negócio captados nesta etapa de modelagem.
4.2
IDENTIFICAÇÃO DOS ATORES
De acordo com Bezerra (2002, p. 51), um ator é “qualquer elemento externo que
interage com o sistema”. Tipicamente, um ator representa o papel de um ser humano, porém,
também pode representar qualquer dispositivo eletrônico que possa realizar interações com o
sistema. Os atores são representados dentro da notação UML por bonecos.
58
No sistema proposto por este trabalho, há dois atores, o próprio usuário da
aplicação e o administrador do sistema, como demonstrado na Figura 22.
Figura 22 – Atores do sistema.
Fonte: Elaboração dos autores, 2011.
As definições do ator Usuário são mostradas no Quadro 1:
Usuário
Ator
O Usuário é a parte interessada em obter informações dos
pontos de táxis ao seu redor. Ele é capaz de requisitar
dados gerais sobre cada ponto de táxi de seu interesse,
Definição
assim como informações sobre custos de rotas para os
seus destinos desejados.
Frequência de uso
Conhecimento em informática
Grau de escolaridade
Diário.
Intermediário. Necessita ter conhecimentos para manusear
um smartphone.
Ensino médio a ensino superior.
Acesso a informações como: posição geográfica dos
Permissão de acesso
pontos de táxis, dados comerciais de cada ponto de táxi,
possibilidade de realizar cálculos de rotas e de avaliar
serviços.
Quadro 1 – Definições do ator Usuário.
Fonte: Elaboração dos autores, 2011.
Já as informações do ator Administrador encontram-se no Quadro 2:
59
Administrador
Ator
Responsável pela manutenção das informações que o
Definição
sistema disponibiliza aos atores Usuário.
Frequência de uso
Diário.
Conhecimento em informática
Intermediário.
Grau de escolaridade
Ensino médio a ensino superior.
Permissão de acesso
Permite cadastrar novos pontos de táxis, além de remover
ou atualizar pontos de táxis já cadastrados.
Quadro 2 – Definições do ator Administrador.
Fonte: Elaboração dos autores, 2011.
Uma vez identificado os atores do sistema, é possível captar os requisitos e casos
de uso do sistema de acordo com as necessidades de cada ator.
4.3
REQUISITOS
Os requisitos, segundo as definições de Larman (2000, p. 60), “são uma descrição
das necessidades ou dos desejos para um produto”. Requisitos também são “características,
propriedades ou comportamentos desejados de um sistema”. (BOOCH; RUMBAUGH;
JACBOSON, 2000, p. 450). É importante que os requisitos de software estejam claros e
concisos com as necessidades de seus usuários, a fim de desenvolver um produto que agregue
valor para quem o utiliza. Para Tayer e Doffman (1997, p. 250, apud PRESSMAN, 2002):
A engenharia de requisitos fornece um mecanismo adequado para entender o que o
cliente deseja, analisar as necessidades, avaliar a exequibilidade, negociar uma
solução razoável, especificar a solução de maneira não-ambígua, validar a
especificação e administrar os requisitos à medida que eles são transformados num
sistema em operação.
Os requisitos podem ser divididos em dois tipos: requisitos funcionais e requisitos
não-funcionais.
60
4.3.1 Requisitos funcionais
Rezende (2006, p. 123) afirma que “os requisitos funcionais podem ser definidos
como as funções ou atividades que o software ou o sistema faz (quando pronto) ou fará
(quando em desenvolvimento). Devem ser definidos claramente e relatados explicitamente”.
Para o sistema apresentado por esta pesquisa, os requisitos funcionais são listados
no Quadro 3.
61
Identificador
Nome
RF01
Apresentar mapa
RF02
Mostrar posição atual
RF03
Mostrar pontos de táxis
no mapa
Listar pontos de táxis
RF04
ordenados pela
proximidade
RF05
RF06
RF07
Requisitar serviço por
telefone
Requisitar serviço por
SMS
Calcular estimativa de
corrida
Descrição
O sistema deve ser capaz de apresentar um mapa
interativo ao Usuário.
No mapa, o sistema deverá indicar ao Usuário a sua
posição atual.
No mapa, o sistema deverá indicar ao Usuário os
pontos de táxi no mapa.
O sistema deverá apresentar uma lista de pontos de
táxis próximos ao Usuário.
O sistema deverá estar apto a requisitar um serviço de
táxi por chamada por telefone.
O sistema deverá estar apto a requisitar um serviço de
táxi por mensagem SMS.
O sistema deverá apresentar ao Usuário uma
estimativa do valor da corrida, baseando-se na
distância definida pelo Usuário.
Com o intuito de buscar um ponto de táxi com maior
RF08
Gerenciar favoritos
rapidez, o Usuário deverá ser capaz de adicionar ou
remover os pontos de táxi de sua preferência.
RF09
Mostrar informações de
um ponto de táxi
RF10
Visualizar histórico
RF11
Listar pontos de táxis
RF12
Cadastrar ponto de táxi
RF13
Remover ponto de táxi
As informações referentes ao ponto de táxi, os táxis
disponíveis, seus acessórios e suas formas de
pagamento deverão ser mostradas para o Usuário.
O Usuário pode visualizar um histórico de pontos de
táxis requisitados anteriormente.
O Administrador do sistema deve ter permissão para
listar os pontos de táxis cadastrados no sistema.
O Administrador do sistema deve ter permissão para
cadastrar novos pontos de táxis no sistema.
O Administrador do sistema deve ter permissão para
remover um ponto de táxi da base de dados.
O Administrador do sistema deve ter permissão para
RF14
Atualizar ponto de táxi
atualizar as informações um ponto de táxi já
cadastrado no sistema.
Quadro 3 – Requisitos funcionais.
Fonte: Elaboração dos autores, 2011.
62
Os requisitos funcionais listados descrevem os comportamentos possíveis que o
sistema pode realizar em resposta às ações dos usuários. Cada requisito captado é entregue
aos desenvolvedores desta pesquisa para que estes possam transformar a necessidade em
código de software para compor o sistema.
4.3.2 Requisitos não-funcionais
Para Bezerra (2002, p. 21), os “requisitos não-funcionais declaram as
características de qualidade que o sistema deve possuir e que estão relacionadas às suas
funcionalidades”.
Nos quadros, a seguir, são mostrados os requisitos não-funcionais do sistema
desta pesquisa, agrupados pela sua classificação.
No Quadro 4, há a descrição dos requisitos não-funcionais relacionados à
usabilidade do sistema. Todos eles são descritos de maneira a tratar o modo de como o
usuário interage com o sistema. Uma boa usabilidade garante uma boa satisfação por parte do
seu usuário final.
Identificador
Descrição
RNF01
A resolução mínima para utilizar o sistema é de 240 X 320.
RNF02
O sistema apresentará textos e frases na língua portuguesa.
RNF03
Os ícones apresentados no sistema deverão ser de fácil entendimento.
RNF04
Deverá ser possível utilizar o aplicativo com a tela na posição horizontal.
RNF05
RNF06
Para os processamentos de dados, deverá ser mostrada, na tela, uma janela a
mensagem: “Carregando”.
Com o intuito de tonar mais rápido o processo de cadastro de pontos de
táxis, no módulo administrador, não deve haver transições de páginas.
Quadro 4 – Requisitos não-funcionais – Usabilidade.
Fonte: Elaboração dos autores, 2011.
O Quadro 5 lista os requisitos não-funcionais pertencentes ao grupo de
desempenho do sistema. Estes requisitos tratam sobre a velocidade de resposta às ações do
usuário.
63
Identificador
Descrição
Os tempos de resposta para as consultas não devem ultrapassar 5 (cinco)
RNF07
segundos.
Quadro 5 – Requisitos não-funcionais – Desempenho.
Fonte: Elaboração dos autores, 2011.
O Quadro 6 fornece os requisitos não-funcionais que estão ligados às questões
operacionais do sistema. Neles, são descritos os tipos de software e de hardware necessários
para utilizar o sistema.
Identificador
Descrição
A camada cliente do sistema deverá ser operada na plataforma Android
RNF08
versão 2.2 ou superior.
É obrigatório o uso de uma conexão via Internet para utilizar o sistema.
RNF09
O smartphone pode, quando presente, utilizar os recursos de sua antena
GPS para fornecer, ao aplicativo, informações à respeito da posição
RNF10
geográfica do usuário.
Quadro 6 – Requisitos não-funcionais – Operacionais.
Fonte: Elaboração dos autores, 2011.
No Quadro 7, há os requisitos não-funcionais classificados no grupo
“Implementação”. Este grupo contém os requisitos que tratam das tecnologias utilizadas no
desenvolvimento do sistema.
Identificador
Descrição
RNF11
No módulo cliente, o sistema é implementada utilizando a linguagem Java.
RNF12
O módulo servidor é implementado utilizando a linguagem Java.
RNF13
No módulo servidor, é utilizado o framework Spring.
RNF14
No módulo servidor, é utilizada a ferramenta Maven para gerenciamento do
projeto do software.
Quadro 7 – Requisitos não-funcionais – Implementação.
Fonte: Elaboração dos autores, 2011.
64
E, por fim, no Quadro 8, há a listagem dos requisitos não-funcionais de
arquitetura. Estes requisitos definem a arquitetura geral do sistema, o modo de como o mesmo
responde às ações externas e também aos tipos de comunicações feitas entre as suas camadas.
Identificador
RNF15
RNF16
Descrição
A camada servidor deverá operar utilizando um sistema operacional Linux.
A camada de persistência deverá operar utilizando um sistema operacional
Linux.
RNF17
O servidor deverá possuir no mínimo 512 megabytes de memória RAM.
RNF18
O SGBD utilizado para gerenciar os dados do sistema é o MongoDB.
RNF19
RNF20
A comunicação entre a camada cliente e a camada servidor é feita
utilizando o padrão de comunicação REST18, utilizando o protocolo HTTP.
As mensagens trocadas entre as camadas seguirão o padrão do formato
JSON19.
Prevendo o crescimento do sistema, a sua arquitetura deverá ser escalável20
RNF21
para suportar um aumento de processamento e de armazenamento, quando
for necessário.
Quadro 8 – Requisitos não-funcionais – Arquitetura.
Fonte: Elaboração dos autores, 2011.
Os requisitos não-funcionais mostrados nesta seção são, para os desenvolvedores,
importantes para documentar os padrões e regras utilizadas para o desenvolvimento do
software proposto.
18
Representational State Transfer (Transferência de Estado Representacional) – Serviços oferecidos na web
utilizando o protocolo HTTP seguindo padrões de nomenclaturas (IBM, 2011).
19
JavaScript Object Notation (Notação de Objetos JavaScript) – “É uma formatação leve de troca de dados. [...]
JSON é em formato texto e completamente independente de linguagem” (JSON, 2011).
20
Escalabilidade – Capacidade de um software de aumentar o seu poder de processamento e armazenamento de
dados para atender ao crescimento de usuários. (PC MAGAZINE, 2011c).
65
4.4
REGRAS DE NEGÓCIO
Outra informação importante no processo de modelagem do sistema é a definição
das regras de negócio que o sistema deverá seguir. “Regras de negócio são políticas,
condições ou restrições que devem ser consideradas na execução dos processos existentes em
uma organização”. (GOTTESDIENER, 1999, p. 70-71 apud BEZERRA, 2002).
O Quadro 9 representa as regras de negócio do sistema.
66
Identificação
Nome
RN01
Informações dos pontos
de táxi
RN02
sendo que:
Cálculo de estimativa de
V = Estimativa do valor da corrida
corrida
L = Preço da largada
D = Distância
B = Valor da bandeira em vigor
RN03
Preço de largada
RN04
Referência no cálculo
de custo de rota
RN05
Bandeiras
RN06
Campos obrigatórios
RN07
Histórico
RN08
Listagem de pontos de
táxis próximos
RN09
Descrição
Para cada ponto de táxi, o sistema deverá fornecer ao
Usuário as seguintes informações:
1 – nome;
2 – número de telefone;
3 – número de celular;
4 – condições de pagamentos aceitos;
5 – valor da bandeira 1;
6 – valor da bandeira 2;
7 – serviços oferecidos;
8 – site.
A fórmula para calcular a estimativa de custo de uma
corrida é dada como:
V = L + (D × B)
Favoritos no mapa
Quadro 9 – Regras de negócio.
Fonte: Elaboração dos autores, 2011.
Não é considerado, neste valor, o custo de tempo parado.
Cada município determina o preço da largada dos pontos
de táxis.
Utiliza-se o ponto de táxi mais próximo ao usuário para
efetuar o cálculo do custo de rota.
Cada município determina os valores e os horários de
vigência de cada bandeira.
Para o cadastro e atualização de pontos de táxis no
sistema, os campos obrigatórios são: ‘nome’, ‘valor da
bandeira 1’, ‘valor da bandeira 2’ e ‘preço da largada’.
Para cada ligação telefônica efetuada, um registro
contendo as informações da chamada (nome do ponto de
táxi, número, data) deverá ser armazenada na base de
dados do aplicativo.
Somente os pontos de táxis próximos a um raio de 10 km
em relação ao Usuário são listados.
Deverá ser mostrada a distância de cada ponto de táxi em
relação ao Usuário.
A lista deverá ser ordenada por proximidade de forma
ascendente.
Deverá haver um destaque especial na interface do
módulo cliente para facilitar a identificação de pontos de
táxis inseridos dentro da lista de favoritos do Usuário.
67
Com base nas regras de negócio mostradas no acima, é possível conhecer as
condições e restrições que necessitam ser desenvolvidas no software. Tais regras devem ser
consideradas durante todo o processo de desenvolvimento.
4.5
PROTOTIPAÇÃO DAS TELAS
O processo de prototipagem é uma etapa fundamental para a validação da
interface visual do sistema juntamente com o seu usuário e para que desenvolvedores tenham
uma referência documentada para criar as interfaces de usuário. Trata-se de “uma técnica que
serve de complemento à análise de requisitos é a construção de protótipos. No contexto do
desenvolvimento de software, um protótipo é um esboço de alguma parte do sistema”.
(BEZERRA, 2002, p. 37). Protótipos são comumente utilizados para facilitar a análise dos
casos de uso de um sistema proposto e para também validar os requisitos definidos junto ao
seu cliente.
São apresentados, a seguir, os protótipos da tela principal, de listagem de pontos
de táxis e da visualização das informações de um ponto de táxi.
A Figura 23 mostra o protótipo da tela principal do sistema. Nela, é possível
visualizar a posição provável do usuário, indicado por um ícone azul. Ao redor deste ícone, há
outros ícones, representados por um táxi, indicando ao usuário a posição geográfica dos
pontos de táxis próximos a ele. O usuário pode clicar neste ícone para visualizar as
informações do ponto de táxi escolhido.
68
Figura 23 – Protótipo da tela principal.
Fonte: Elaboração dos autores, 2011.
Na Figura 24, é possível visualizar o protótipo da tela que lista os pontos de táxis.
Nela, são apresentados os pontos de táxis próximos em relação à posição atual do Usuário,
sendo que esta lista deve ser ordenada pela proximidade. Ao lado de cada ponto de táxi, há
informações como o nome do ponto de táxi, o seu número de telefone, a distância relativa ao
usuário e a informação de que este ponto está na lista de favoritos do usuário ou não
(representado por uma estrela).
69
Figura 24 – Protótipo da tela de listagem de pontos de táxis.
Fonte: Elaboração dos autores, 2011.
É possível visualizar, na Figura 25, a tela que apresenta as informações de um
ponto de táxi ao Usuário.
70
Figura 25 – Protótipo da tela de informações de um ponto de táxi.
Fonte: Elaboração dos autores, 2011.
Nesta tela, o usuário pode realizar chamadas telefônicas ou por mensagem de
texto (SMS21).
Por fim, na Figura 26, é representada a interface visual da camada de
administração do sistema.
21
Short Message Service – Serviço de Mensagens Curtas.
71
Figura 26 – Protótipo da camada de administração
Fonte: Elaboração dos autores, 2011
É nesta interface que o Administrador do sistema pode cadastrar, atualizar ou remover
os pontos de táxis disponíveis na base de dados do sistema.
4.6
CASOS DE USO
De acordo com Larman (2000, p. 32), “casos de uso são descrições narrativas
(textuais) dos processos em uma empresa ou sistema”. Os casos de usos definem o escopo do
sistema, demonstrando as possíveis ações que os seus usuários poderão realizar.
Nas duas seções, a seguir, são mostrados os casos de usos do sistema, assim como
as suas respectivas descrições.
72
4.6.1 Diagrama de caso de uso
Segundo Booch, Rumbaugh e Jacobson (2000), um diagrama de caso de uso
permite que seja feita uma visualização do sistema como um todo, tendo como foco os seus
usuários e as interações que o mesmo realiza como o sistema.
Na Figura 27, é apresentado o diagrama de caso de uso resultante do processo de
planejamento do projeto, na visão do ator Usuário.
Figura 27 – Diagrama de caso de uso – Ator Usuário.
Fonte: Elaboração dos autores, 2011.
Na Figura 28, encontram-se os casos de uso para o usuário Administrador.
73
Figura 28 – Diagrama de caso de uso - Ator Administrador.
Fonte: Elaboração dos autores, 2011.
Estes diagramas servirão como base para dar prosseguimento para as outras etapas
do processo de modelagem do sistema.
4.6.2 Descrição dos casos de uso
A seguir, é apresentada a documentação do caso de uso CSU01 – Abrir mapa.
74
Abrir mapa
Identificador
CSU01
Descrição
Para que algumas ações sejam feitas no sistema, o Usuário deverá
abrir a janela contendo um mapa interativo.
Ator primário
Usuário
Ator secundário
Google Maps
Pré-condições
--
Fluxo de tarefas
1 – Usuário abre o menu.
2 – Seleciona a opção “Mapa”.
Fluxos de exceção
2.a - Não sendo possível acessar o serviço de mapas do Google;
2.a.1 - É mostrada uma mensagem de erro ao usuário;
Pós-condições
- Um mapa é apresentado na tela do Usuário.
Quadro 10 – Caso de uso CSU01 – Abrir mapa.
Fonte: Elaborador pelos autores, 2011.
As descrições dos demais casos de uso encontram-se no Apêndice B.
4.6.3 Diagrama de Sequência
Para cada caso de uso identificado, é possível criar um diagrama de sequência que
descreve (em um nível maior de detalhamento) todas as interações do usuário com o sistema
para atingir o objetivo levantado pelo caso de uso. Um diagrama de sequência “mostra as
interações de um sistema com seus atores para realizar todo um caso de uso ou uma parte
dele”. (BLAHA; RUMBAUGH, 2006).
A Figura 29 demonstra um diagrama de sequência feito para o caso de uso CSU11
– Realizar chamada por telefone.
75
Figura 29 – Diagrama de sequência para o CSU11.
Fonte: Elaboração dos autores, 2011.
Os diagramas de sequência complementam as informações dos diagramas de caso
de uso, fornecendo maiores detalhes de como o caso de uso estudado deve se comportar para
atingir o seu objetivo e quais mensagens devem ser trocadas entre os diferentes componentes
do sistema.
4.6.4 Diagrama de Classe
Com o objetivo de planejar e documentar as estruturas de dados do sistema, faz-se
o uso de um digrama de classe. “Um diagrama de classe descreve os tipos de objetos no
sistema e os vários tipos de relacionamento estático que existem entre eles” (FOWLER;
SCOOT, 2000, p. 57).
Na Figura 30, há o diagrama de classe para as classes de modelo do sistema, cuja
função é representar as entidades do sistema.
76
Figura 30 – Diagrama de classe – Classes de modelo.
Fonte: Elaboração dos autores, 2011.
Para as classes controladoras (responsáveis por receber, interpretar e executar
processamentos de dados requisitados pelo usuário) foram modelados como demonstra a
Figura 31.
Figura 31 – Diagrama de classe – Controladores.
Fonte: Elaboração dos autores, 2011.
77
Estes diagramas permitem que analistas de sistemas e programadores tenham uma
perspectiva de como os dados são estruturados e processados dentro do domínio de negócio
do sistema.
4.6.5 Diagrama de Utilização
Um diagrama de utilização, segundo Fowler e Scott (2000, p. 131) “mostra as
relações físicas entre componentes de software e hardware no sistema implementado”. Nele,
é possível ter uma visão macro da instalação do sistema, de forma que seja possível conhecer
todos os seus componentes e as interações entre cada um.
Na Figura 32, é demonstrado o digrama de utilização proposto para o
desenvolvimento do sistema desta pesquisa.
78
Figura 32 – Diagrama de utilização.
Fonte: Elaboração dos autores, 2011.
Com este diagrama, é possível visualizar, com maiores detalhes, a arquitetura do
sistema, suas tecnologias envolvidas e as interações entre cada nodo. Além disso, estas
informações são úteis para a instalação do sistema em produção.
79
5
DESENVOLVIMENTO
Após o processo de análise e de modelagem, segue-se a etapa de desenvolvimento
do sistema, tendo como base a documentação realizada na etapa anterior. Este capítulo tem
como objetivo expor toda a etapa de desenvolvimento realizada para a construção do sistema
proposto, começando pelo resumo das tecnologias utilizadas, o histórico do desenvolvimento,
apresentações das telas do sistema, avaliação e considerações finais.
5.1
TECNOLOGIAS E FERRAMENTAS
Uma vez determinados os requisitos (funcionais e não-funcionais) e os casos de
uso do sistema, deve-se escolher as tecnologias e ferramentas apropriadas para atender ao que
foi determinado na etapa de análise e modelagem para apoiar o processo de desenvolvimento.
Há diversas ferramentas e tecnologias disponíveis, hoje no mercado, cada uma com suas
características próprias, vantagens e desvantagens.
Após pesquisas das tecnologias disponíveis, os autores selecionaram aquelas que
julgaram apropriadas para o desenvolvimento do sistema proposto por esta monografia. A
relação das tecnologias está ilustrada na Figura 33.
80
Figura 33 – Tecnologias e ferramentas utilizadas no sistema.
Fonte: Elaboração dos autores, 2011.
Nos itens, a seguir, é feita uma breve descrição das tecnologias e das ferramentas
utilizadas, assim como os motivos de escolha de cada uma.
 Android
Como ilustrado no capítulo 2.2, Android é um sistema operacional e também uma
plataforma de desenvolvimento de código fonte aberto e gratuito voltado para dispositivos
móveis. Sua biblioteca de componentes é bastante rica e possui uma ótima documentação.
Apesar de ser complexa para desenvolvedores iniciantes e exigir uma alta curva de
aprendizado, a plataforma Android permite criar aplicativos interativos com o usuário e
totalmente customizáveis.
 Java
Java foi escolhida pelo fato de a plataforma Android executar aplicativos escritos
nesta linguagem. Trata-se de uma linguagem de programação de alto nível e orientada a
81
objetos, o que permite criar trechos de códigos reaproveitáveis. Sua facilidade de aprendizado
e alta produtividade foram essenciais para o desenvolvimento do projeto.
 Eclipse
Trata-se de uma IDE que visa a facilitar o desenvolvimento de aplicativos.
Juntamente com o plugin ADT22 (Android Development Tools - Ferramentas de
Desenvolvimento Android), a ferramenta Eclipse ganha a capacidade de gerenciar projetos
para a plataforma Android, sendo possível realizar a compilação de projetos e de também
executá-los em um emulador para testes de aplicativos.
 JSON
JSON é um formato leve e de fácil leitura para representação e troca de dados
(JSON, 2011). Devido às limitações de processamento e de memória disponível dos
smartphones, há de se escolher um formato que não consuma muitos recursos computacionais
para preservar a energia contida nas baterias. Ao contrário do formato XML23, o formato
JSON exige pouco processamento para criar e ler dados por possuir uma sintaxe mais simples
e compacta.
 REST
Defendido por Roy Thomas Fielding em 2000 em sua tese de doutorado, a
arquitetura REST compreende um conjunto de técnicas de engenharia para sistemas
heterogêneos distribuídos na web. Baseia-se no princípio de que qualquer recurso deve
possuir um identificador único, sendo que o mesmo pode ser estar sujeito a manipulações
(buscar, criar, atualizar e remover) utilizando operações padronizadas, conhecidas como
verbos (que, para o protocolo HTTP, são, respectivamente: GET, POST, PUT e DELETE)
(FIELDING, 2011).
Trata-se de uma alternativa às tecnologias RPC24 e Web Services (SOAP25,
WSDL26, etc.), pois caracteriza-se por ser leve (utiliza apenas o protocolo HTTP), ser
22
http://developer.android.com/sdk/eclipse-adt.html
23
eXtensible Markup Language - Formato de dados de tipo texto utilizado para troca mensagens entre sistemas
pela web (W3C, 2011).
24
Remote Process Call - Chamada de Processo Remota.
25
Simple Object Access Protocol - Protocolo Simples de Acesso à Objetos.
26
Web Services Description Language - Linguagem de Descrição de Serviços Web.
82
independente de plataforma e de linguagem de programação. Sistemas que seguem a fundo
estes padrões são conhecidos como sistemas RESTful.
Baseando-se nos requisitos não-funcionais do sistema, desempenho é uma
qualidade importante para a boa aceitação do software por parte de seus usuários. Por este
motivo, foi escolhida a tecnologia REST para comunicação entre clientes, e o servidor pelo
fato de a mesma apresentar uma arquitetura simples, rápida e, também, escalável.
 MongoDB
MongoDB é um SGBD de código-fonte aberto, gratuito, desenvolvido com a
linguagem de programação C++, multiplataforma, não-relacional, sem esquemas, de alta
performance, orientado a documentos e escalável. (MONGODB, 2011a).
O MongoDB pertence à categoria de banco de dados NoSQL, que utiliza uma
nova abordagem para o armazenamento e consulta de dados. Diferentemente dos SGBDs
relacionais, o MongoDB não dispõe seus dados armazenados na estrutura de tabelas, linhas e
colunas. Ao invés disto, o MongoDB organiza os seus dados em collections (coleções),
similar às tabelas dos banco de dados relacionais. Cada coleção pode conter vários
documentos (referentes às linhas de uma tabela) e cada documento poderá conter vários
campos (ou colunas, usando a abordagem entidade-relacional). Esta nomenclatura diferente é
devido ao fato de o MongoDB não possuir esquema (padrão de formato de tabelas e colunas),
ou seja, qualquer dado pode ser inserido em qualquer coleção. Com isto, é possível criar
documentos auto-contidos, ou seja, documentos que possuem todas as informações
necessárias para representar uma entidade da vida real, sem depender de outros documentos
(no MongoDB, não há relacionamentos). A vantagem fica pelo fato de as consultas
retornarem todos os dados necessários para o funcionamento do sistema, sem realizar
operações lentas de junção (joins). Entretanto, a base de dados não fica normalizada, podendo
conter dados redundantes.
Outro fator decisivo na escolha deste banco de dados é a simplicidade dos dados
do sistema proposto. Como há a necessidade de armazenar somente informações referentes a
pontos de táxis, agrupar todas estas informações em uma única coleção aumenta o
desempenho nas consultas de dados realizadas pelos usuários.
Também há disponível um suporte para sharding, um método de replicação de
dados em ambientes distribuídos em que diversos nós possam compartilhar dados entre si. No
caso de um nó deixar de operar, outro nó assume o seu lugar. Importante no caso de a
83
aplicação necessitar aumentar a sua capacidade de armazenamento de dados. (MONGODB,
2011b).
Entre outras funcionalidades, destacam-se o suporte nativo a dados geográficos
bidimensionais, índices, autenticação, backups e ferramentas para métricas e monitoramento
de desempenho.
Visando o desempenho e escalabilidade do sistema, o MongoDB possui todas as
qualificações para gerenciar os dados do sistema com bastante rapidez e eficiência.
 Apache Tomcat
Servidor web de código-fonte aberto, desenvolvido em Java e mantido pela
fundação Apache. É capaz de receber, tratar e responder requisições do protocolo HTTP.
(APACHE, 2011b). O Apache Tomcat caracteriza-se por ser um servidor leve e bastante
rápido devido à sua arquitetura simples e estável.
 Spring Framework
Framework para aplicativos Java, o Spring Framework, oferece suporte ao
desenvolvimento de aplicações orientadas à objetos de uma maneira simples e fácil. Dentro
dos módulos utilizados, destacam-se os módulos Core (núcleo), responsável pelo
gerenciamento de objetos do sistema, e o módulo MVC (Model-View-Controller - ModeloVisão-Controlador), é capaz de tratar e responder requisições vindas de um servidor web.
(SPRING SOURCE, 2011).
 Google Maps
O Google Maps, como visto na seção 2.5, oferece um serviço de mapas e
ferramentas para cálculo de rotas e de geocoding (processo para associar coordenadas
geográficas a endereços, e vice-versa). O serviço de mapas do Google Maps é essencial para
apresentar dados geográficos para o usuário do sistema, porém, necessita que o usuário do
sistema tenha uma conexão com a Internet ativa.
 GeoTools
Biblioteca de código-fonte aberto e escrita utilizando a linguagem Java. Fornece métodos para
manipulação de dados geográficos, como renderização gráfica de mapas, cálculo de
84
distâncias, conversão de projeções, entre outros. (GEOTOOLS, 2011). Apresenta uma boa
documentação e seus componentes são fáceis de utilizar.
 Subversion
Subversion é uma ferramenta para versionamento de arquivos de projetos de
software. Permite que desenvolvedores compartilhem o mesmo código e mantenham os
registros de todas as alterações feitas, sendo possível revertê-las caso alguma modificação
prejudique o funcionamento do software. (APACHE, 2011c).
 Maven
De acordo com Apache (2011d), Maven é um software voltado ao gerenciamento
de projetos desenvolvidos em Java. Com ele, é possível ter o controle de várias operações, tais
como: compilação, testes, resolução de dependências com outras bibliotecas, relatórios,
documentação do projeto, entre outros. Para cada projeto, deverá haver um arquivo chamado
pom.xml em que todas as configurações devem ser declaradas para o Maven poder interpretálas.
 JUnit
JUnit é a biblioteca de testes unitários mais conhecida da linguagem Java. O
mesmo permite criar e executar testes unitários de classes do sistema e ver os seus resultados
em tempo real, sendo importante para verificar se o código escrito está de acordo com as
regras escritas como testes unitários.
 jQuery
jQuery é uma biblioteca de código-fonte aberto e gratuito para a linguagem
JavaScript
27
focada no desenvolvimento de aplicativos web dinâmicos. Possui diversos
plugins disponíveis gratuitamente na Internet que incrementam a sua capacidade de manipular
elementos de páginas HTML. Não exige conhecimentos avançados em JavaScript, e sua
documentação é completa e rica em detalhes.
27
Linguagem de programação client-side, interpretada e orientada à objetos que é executada por navegadores
web (comumente chamados de browsers).
85
5.2
HISTÓRICO DO DESENVOLVIMENTO
Os principais desafios enfrentados durante o processo de codificação do sistema
foram:
 Conhecer a plataforma Android: Ambos os autores nunca tiveram alguma experiência
anterior em desenvolvimento de aplicativos voltados a dispositivos móveis. Ao iniciar,
perceberam que o desenvolvimento deste tipo de software é totalmente diferente de
um aplicativo desktop ou web, utilizando conceitos e técnicas muito diferentes das já
conhecidas. Um período de estudo foi reservado para conhecer os detalhes desta
tecnologia.
 Desempenho: Esta foi uma das maiores preocupações durante o desenvolvimento. Já
era de conhecimento dos autores que os smartphones possuem limitações de memória
e de processamento, portanto, o desenvolvimento do sistema foi realizado de forma a
utilizar o mínimo possível de recursos do dispositivo. Na camada de servidor, optou-se
utilizar a arquitetura REST por se tratar de uma solução simples e leve. Já o banco de
dados MongoDB correspondeu bem às expectativas do autores por oferecer uma boa
eficiência na busca de dados devido aos dados não serem normalizados e pela ausência
de operações de junções nas consultas.
 Usabilidade: Construir uma aplicação que seja fácil e confortável de usar é um fator
decisivo para o seu sucesso. Com a falta de experiência na área de design voltada para
o usuário final, os autores deste trabalho recorreram à busca de feedbacks obtidos de
usuários que se ofereceram a utilizar o sistema em versão de testes. As sugestões
destes usuários foram de grande importância para melhorar a interface visual do
sistema.
 Manipular dados geográficos: A falta de conhecimento na manipulação de dados
geográficos foi uma das dificuldades iniciais do projeto. Com alguns dias de estudo
focados neste assunto, foi possível compreender, em maiores detalhes, algumas
técnicas para utilizar estas estruturas de dados.
Alheio às estas situações acima citadas, o processo de desenvolvimento do
sistema deste trabalho ocorreu conforme o planejado, sendo possível implementar todos os
casos de usos definidos.
86
5.3
APRESENTAÇÃO DO SISTEMA
O sistema proposto por este trabalho, que foi desenvolvido com base na
modelagem apresentada no capítulo 4 e implementado utilizando as ferramentas e tecnologias
citadas na seção 5.1, é apresentado a seguir. Para demonstrar o funcionamento do sistema, foi
criado um exemplo de como o mesmo pode ser utilizado por parte de seus usuários.
5.3.1 Módulo administrador
O módulo administrador é utilizado pelo Administrador do sistema. Nele, é
possível cadastrar, atualizar e remover pontos de táxis que são acessados pelos usuários finais
do sistema.
5.3.1.1 Tela principal
A tela principal do módulo administrador é demonstrada na Figura 34.
87
Figura 34 – Módulo administrador – tela principal.
Fonte: Elaboração dos autores, 2011.
No canto direito desta tela, o Administrador tem acesso às informações de todos
os pontos de táxis cadastrados, podendo removê-los ou editá-los clicando em um dos ícones
disponíveis em cada linha da tabela de ponto de táxis. Ao selecionar uma linha da tabela, um
ícone vermelho indicando a posição geográfica do ponto de táxi selecionado é plotado no
mapa, à esquerda.
5.3.1.2 Cadastro de ponto de táxi
Na tela principal, ao clicar na aba contendo o texto “Novo ponto de táxi”, é
possível visualizar um formulário de cadastro, conforme mostra a Figura 35.
88
Figura 35 – Módulo administrador – formulário de cadastro de ponto de táxi.
Fonte: Elaboração dos autores, 2011.
Nele, o Administrador pode informar os dados daquele ponto de táxi (nome,
telefone, formas de pagamento, valor da bandeira 1, valor da bandeira 2, preço de largada,
serviços e site), além de sua posição geográfica. Neste exemplo, foi cadastrado um ponto de
táxi chamado “Ponto de Táxi Praça 7 de Setembro” com algumas informações (apenas para
fins de exemplo; não foram utilizados dados reais) e a sua localização geográfica foi dada
como: latitude 27,64568 S e longitude 48,667156 W, indicada no mapa por um ícone
vermelho.
5.3.2 Módulo cliente
Para os usuários finais do sistema, deve ser utilizado um smartphone com
conexão para a Internet e possuir uma antena GPS. Segue, abaixo, um exemplo de como o
sistema pode ser utilizado pelo Usuário.
89
5.3.2.1 Tela principal
Ao iniciar o aplicativo “Hey, Táxi!” pelo seu smartphone, o Usuário terá acesso
ao mapa e pode visualizar a sua posição atual (informada pelo sistema GPS) e também os
pontos de táxis próximos à sua localização. Considerando que o Usuário esteja localizado na
posição geográfica: latitude 27,65386 S e longitude 48,67591 W, a sua tela principal será
semelhante à Figura 36.
Figura 36 – Módulo cliente – tela principal.
Fonte: Elaboração dos autores, 2011.
A posição do Usuário é representada por um círculo azul, enquanto os pontos de
táxis são representados por ícones vermelhos. O Usuário pode navegar por este mapa,
arrastando-o para qualquer direção e também sendo capaz de aumentar e diminuir o nível
zoom. Nota-se que, nesta tela, já é possível visualizar os pontos de táxis que estão mais
próximos ao Usuário.
90
5.3.2.2 Informações de um ponto de táxi
Ao clicar sobre um ícone de ponto de táxi, o aplicativo requisita as informações
do ponto de táxi selecionado para o servidor. No momento em que a resposta chegar ao
smartphone, uma tela é mostrada para o Usuário, como pode ser possível visualizar na Figura
37.
Figura 37 – Módulo cliente – tela de informações de um ponto de táxi.
Fonte: Elaboração dos autores, 2011.
Esta tela fornece ao Usuário todas as informações, que foram cadastradas no
módulo de administração, sobre um determinado ponto de táxi, como o seu nome, número
para contato, valores da bandeira 1 e 2, serviços prestados, formas de pagamentos aceitos e o
seu site. A estrela à esquerda do nome do ponto de táxi indica se o mesmo está incluso dentro
da lista de ponto de táxis favoritos. O Usuário é capaz de clicar sobre este ícone para
adicionar/remover este ponto de táxi desta lista.
91
5.3.2.3 Chamada telefônica
Na tela de informações de um ponto de táxi, pressionando o botão menu do
smartphone, o seguinte menu é apresentado na tela:
Figura 38 – Módulo cliente – menu da tela de informações de um ponto de táxi.
Fonte: Elaboração dos autores, 2011.
O Usuário que deseja iniciar uma ligação telefônica deverá selecionar a opção
“Chamada”. Uma janela aparecerá aguardando a escolha do usuário quanto ao número que
deseja iniciar a ligação (telefone ou celular, quando disponíveis). A Figura 39 demonstra esta
janela:
92
Figura 39 – Módulo cliente – seleção de chamadas.
Fonte: Elaboração dos autores, 2011.
Para qualquer escolha do Usuário, uma nova janela é aberta para dar início à
ligação telefônica para o número escolhido, como demonstra a Figura 40:
93
Figura 40 – Módulo cliente – chamada telefônica.
Fonte: Elaboração dos autores, 2011.
Após realizar estes passos, o Usuário pode requisitar o serviço de táxi via
chamada telefônica. No momento em que uma chamada é iniciada, um registro é adicionado
no histórico de chamadas para futuras consultas.
5.3.2.4 Enviar mensagem de texto
Caso seja de desejo do Usuário manter contato com um ponto de táxi via
mensagem de texto (SMS), o mesmo deverá selecionar o item “Chamada de texto” no menu.
A tela demonstrada na Figura 41 é aberta:
94
Figura 41 - Módulo cliente – tela para enviar mensagem de texto.
Fonte: Elaboração dos autores, 2011.
Nela, é possível informar o corpo da mensagem SMS. Após concluir o
preenchimento da mensagem e clicar no botão “Enviar”, a mensagem de texto é enviada para
o ponto de táxi escolhido.
5.3.2.5 Lista de favoritos
Na tela principal, ao clicar no botão de menu do smartphone, o seguinte menu de
opções é aberta ao Usuário:
95
Figura 42 – Módulo cliente – menu da tela principal.
Fonte: Elaboração dos autores, 2011.
Selecionando a opção “Favoritos”, ume tela, como representado pela Figura 43, é
aberta:
96
Figura 43 – Módulo cliente – tela de lista de favoritos.
Fonte: Elaboração dos autores, 2011.
Uma lista de pontos de táxis mantida pelo Usuário é listada nesta tela.
Selecionando um item desta lista, a tela de informações de um ponto de táxi (como
apresentada na seção 5.3.2.2) é aberta. Com esta funcionalidade, a busca por um determinado
ponto de táxi de interesse do Usuário tornar-se-á mais rápida.
5.3.2.6 Histórico de chamadas
Abrindo o menu principal, quando clicar na opção “Histórico”, é apresentada a
tela contendo o histórico de chamadas telefônicas realizadas pelo Usuário, como mostra a
Figura 44.
97
Figura 44 – Módulo cliente – tela de histórico de chamadas.
Fonte: Elaboração dos autores, 2011.
Para cada item da lista, é mostrado o nome do ponto de táxi, a data da chamada e
o número de telefone ou celular que foi acionado. Os itens desta lista são ordenados pela data
da chamada. Com esta tela, o Usuário poderá encontrar com maior rapidez um determinado
ponto de táxi que foi chamado anteriormente. Para os pontos de táxis que estão inclusos na
lista de favoritos, uma estrela é colocada ao lado do ícone do táxi. O usuário pode limpar esta
lista, selecionando a opção “Limpar histórico” no menu desta tela.
5.3.2.7 Cálculo de rota
No caso de o Usuário deste exemplo desejar ir até a UNISUL Campus Pedra
Branca (latitude: 27,62435 S; longitude: 48,68174 W), mas não possui informações sobre o
ponto de táxi mais próximo, seus números para contato e de quanto custará uma corrida até o
98
seu destino, o mesmo pode selecionar a opção “Calcular rota” do menu principal do
aplicativo. Será pedido que o Usuário plote no mapa um ícone informando aonde será o seu
destino (indicado por um ícone azul). Após isso, o aplicativo é instruído para encontrar a
melhor rota (utilizando a Direction API da Google, visto na seção 2.5.1.2) para este destino
para então mostrá-la no mapa, como demonstrado na Figura 45:
Figura 45 – Módulo cliente – cálculo de rota.
Fonte: Elaboração dos autores, 2011.
Após o cálculo da rota e a confirmação do Usuário para efetuar os cálculos, a
seguinte janela é aberta:
99
Figura 46 – Módulo cliente – tela de custos de uma corrida.
Fonte: Elaboração dos autores, 2011.
É possível visualizar, nesta janela, informações importantes para o Usuário que
requisitou este serviço: a distância da rota e os valores (aproximados) da corrida quando
utilizar a bandeira 1 e 2. Abaixo, é mostrado informações do ponto de táxi que foi utilizado
como referência para os cálculos dos custos da rota (sempre é utilizado o ponto de táxi mais
próximo ao Usuário). No menu desta tela, o Usuário pode iniciar uma ligação telefônica ou
enviar uma mensagem de texto para este ponto de táxi.
5.3.2.8 Listagem de pontos de táxis próximos
Ao selecionar a opção “Listar próximos” no menu principal, a seguinte tela é
mostrada ao Usuário:
100
Figura 47 – Módulo cliente – tela de listagem de pontos de táxis mais próximos.
Fonte: Elaboração dos autores, 2011.
Os pontos de táxis mais próximos da localização do Usuário, a um raio de 10 km
de distância, são listados nesta tela. Para cada item desta lista, o nome do ponto de táxi e a sua
distância relativa ao Usuário são informados. Os pontos de táxis cadastrados como favoritos
são diferenciados por uma estrela ao lado do ícone de táxi. Ao clicar sobre um item da lista, a
tela de informações do ponto de táxi selecionado é aberta (como foi mostrado na seção
5.3.2.2).
5.4
AVALIAÇÃO
Com o intuito de verificar as expectativas de prováveis usuários perante o sistema
proposto, a etapa de avaliação foi iniciada logo após o término da etapa de desenvolvimento.
Para coletar estas informações, foi elaborado um questionário para ser entregue aos
101
entrevistados. De acordo com Lakatos e Marconi (1991, p. 201), “questionário é um
instrumento de coleta de dados, constituído por uma série ordenada de perguntas, que devem
ser respondidas por escrito e sem a presença do entrevistador”. Optou-se por utilizar esta
técnica de coletada de dados por a mesma ser simples, rápida e atingir um número maior de
pessoas simultaneamente. O seu objetivo é prover dados para fundamentar a comprovação
dos objetivos desta pesquisa.
O questionário, criado pelos autores deste trabalho, contém perguntas de múltipla
escolha para conhecer a opinião dos usuários sobre alguns pontos importantes do sistema
como usabilidade, desempenho, satisfação, entre outros. Além disso, uma área aberta para
inserir comentários, críticas e sugestões foi adicionada para o usuário colocar sua avaliação
geral do sistema. Todas as perguntas são opcionais.
Os sete usuários entrevistados, a convite dos autores, ofereceram-se a testar os
dois módulos do sistema e responder ao questionário. Suas identidades não foram reveladas.
As questões contidas nos questionários respondidos pelos entrevistados são
mostradas no
Quadro 11:
Número
Pergunta
Pergunta 1
Você costuma utilizar o serviço de táxi?
Pergunta 2
Atualmente, você encontra dificuldades para encontrar um ponto de táxi?
Pergunta 3
O software utilizado atende a suas necessidades?
Pergunta 4
O tempo de resposta do software é satisfatório?
Pergunta 5
É fácil aprender a usar?
Pergunta 6
Possui navegabilidade intuitiva, simples e eficiente?
Pergunta 7
Apresenta suas informações com legibilidade, clareza e consistência?
Pergunta 8
O aplicativo é estável e não apresentou falhas?
Pergunta 9
Com o software, ficou mais fácil e eficiente buscar e chamar um táxi?
Pergunta 10 Comentários, críticas e/ou sugestões
Quadro 11 - Perguntas do questionário.
Fonte: Elaboração dos autores, 2011.
As perguntas 1 até 9 são fechadas, sendo que as possíveis alternativas são: “Sim”,
“Às vezes” e “Não”, enquanto que, a pergunta 10 é aberta, podendo o(a) entrevistado(a)
deixar a sua opinião geral sobre o sistema.
102
Os questionários respondidos encontram-se no Apêndice C. A interpretação dos
resultados obtidos é feita a seguir.
5.4.1 Interpretação dos resultados
De posse dos resultados dos questionários realizado nesta etapa, foi possível
representá-los em gráficos para que seja feita uma análise geral da opinião dos entrevistados
sobre o sistema desenvolvido. Nesta seção, são expostas as análises e interpretações acerca
dos resultados obtidos da etapa de avaliação.
Na primeira pergunta no questionário, foi questionado se o(a) entrevistado(a)
costuma utilizar o serviço de táxi de sua cidade. O resultado é mostrado na Figura 48.
Figura 48 – Questionário – Resultados da pergunta 1.
Fonte: Elaboração dos autores, 2011.
Percebe-se, no gráfico a cima, que poucos entrevistados utilizam o serviço de táxi
diariamente. Motivos para esta falta de uso neste tipo de serviço podem ser: preço,
ineficiência, preferência por outro meio de transporte, falta de disponibilidade e de
informação. O software proposto por este trabalho visa resgatar a confiança entre os usuários
e os motoristas de táxis, oferecendo serviços que estimulem o uso deste meio de transporte.
A segunda pergunta questiona a facilidade de encontrar os serviços de táxis, na
visão dos entrevistados. O resultado desta pergunta encontra-se na Figura 49.
103
Figura 49 – Questionário – Resultados da pergunta 2.
Fonte: Elaboração dos autores, 2011.
Com os resultados desta pergunta, percebe-se que mais da metade dos
entrevistados enfrentam dificuldades em encontrar um ponto de táxi, o que pode levá-los a
utilizar outro meio de transporte.
A terceira pergunta presente no questionário foi anulada por apresentar um
questionamento de dupla interpretação. Não foi possível obter nenhuma informação com os
resultados desta pergunta.
A quarta pergunta do questionário é: “O tempo de resposta do software é
satisfatório?”. O seu objetivo é verificar se a velocidade em que as informações são
apresentadas ao usuário, assim que foram requisitadas, encontra-se em um nível satisfatório.
A Figura 50 mostra o resultado desta pergunta.
Figura 50 – Questionário – Resultados da pergunta 4.
Fonte: Elaboração dos autores, 2011.
104
De acordo com o gráfico a cima, o tempo de resposta não atrapalhou o uso do
sistema e não impediu o uso de suas funcionalidades, de acordo com a opinião dos
entrevistados.
A próxima pergunta questionou aos entrevistados a facilidade de entender o fluxo
de trabalho exigido para realizar as tarefas no sistema. O resultado é demonstrado na figura a
seguir.
Figura 51 – Questionário – Resultados da pergunta 5.
Fonte: Elaboração dos autores, 2011.
Percebeu-se que ocorreram certas dificuldades por parte de alguns entrevistados
em realizar as operações no sistema. Na seção de comentários e sugestões de um dos
entrevistados, encontra-se a seguinte frase: “Instruir como calcular rota”, o que claramente
demonstra que esta funcionalidade precise ser revista para tornar mais claro ao usuário a
maneira correta de calcular o preço estimado de uma rota. Outra sugestão para auxiliar o
aprendizado de uso é criando uma seção de ajuda para usuário iniciantes.
A sexta pergunta também está relacionada à usabilidade, porém, ela enfatiza mais
a navegabilidade do sistema, questionando aos entrevistados se o sistema os conduziu de uma
maneira clara a realização de suas tarefas. O resultado desta pergunta é mostrado na Figura
52.
105
Figura 52 – Questionário – Resultados da pergunta 6.
Fonte: Elaboração dos autores, 2011.
Em geral, houve uma boa aceitação na forma em que o sistema conduz os seus
usuários. Porém, alguns detalhes levantados nesta etapa merecem destaque, como, por
exemplo, o seguinte comentário de um dos entrevistados: “Validar quando o usuário deseja
sair do sistema”. A falta desta funcionalidade fazia com que o usuário saísse do sistema sem a
intenção caso o mesmo pressione o botão “voltar” várias vezes. Uma correção para esta falha
foi implementada após a coleta e leitura dos questionários.
Na mesma categoria de perguntas relacionadas à interface, a oitava pergunta do
questionário procura conhecer a opinião dos entrevistados a respeito da legibilidade, clareza e
consistência das informações apresentadas no sistema. O resultado é mostrado na Figura 53.
Figura 53 – Questionário – Resultados da pergunta 7.
Fonte: Elaboração dos autores, 2011.
106
O gráfico mostrado na figura anterior demonstra que, segundo a opinião dos
entrevistados, o sistema foi consistente em apresentar as suas informações ao usuário e não
exibiu dados incorretos ou pouco legíveis.
A próxima pergunta questiona ao entrevistado se o mesmo encontrou alguma
falha no sistema. Na próxima figura, são exibidos os resultados obtidos desta pergunta.
Figura 54 – Questionário – Resultados da pergunta 8.
Fonte: Elaboração dos autores, 2011.
Algumas falhas (bugs) foram encontradas pelos entrevistados durante o processo
de avaliação, o que explica o fato de serem feitas repostas no item “Às vezes” nesta pergunta.
As mesmas foram corrigidas após o término desta etapa.
Por fim, na última pergunta, foi questionado aos entrevistados a sua opinião sobre
a eficiência do software perante a problemática apontada neste trabalho. O seu resultado é
demonstrado na Figura 55.
107
Figura 55 – Questionário – Resultados da pergunta 9.
Fonte: Elaboração dos autores, 2011.
Com base neste gráfico e nos comentários contidos nos questionários, é possível
afirmar que o software proposto atendeu aos requisitos de facilitar e automatizar a busca e
chamadas de táxis, na visão dos entrevistados deste questionário. Um comentário feito por um
dos entrevistados reforça esta afirmação: “[...] de modo geral o software apresenta um bom
resultado. Acredito que será muito útil.”.
Após a coleta e avaliação dos resultados, percebeu-se um nível de satisfação
considerada aceitável por parte dos entrevistados que responderam aos questionários.
Algumas falhas foram encontradas nesta etapa, que logo foram corrigidas. Também foram
feitas algumas sugestões de melhorias, sendo que as mais simples e rápidas de serem
implementadas foram realizadas no sistema, as outras, que se mostraram mais relevantes,
foram classificadas como sugestões de trabalhos futuros.
Conclui-se, nesta etapa, que o objetivo geral do aplicativo de tornar mais fácil e
eficiente a busca e chamada de táxis foi atingido, baseando-se nos questionários e feedbacks
recebidos durante o período de desenvolvimento e avaliação.
5.5
CONSIDERAÇÕES
Este capítulo apresentou, de uma maneira geral, todo o processo de
desenvolvimento do sistema proposto, iniciando pelo estudo das tecnologias, seguindo para a
implementação até chegar à apresentação do resultado final. Observou-se que o sistema
108
proposto atendeu aos requisitos levantados por esta pesquisa, servindo como uma boa opção
de ferramenta para busca e chamadas de táxis de uma maneira simples e rápida.
Com a avaliação do sistema, foi possível obter opiniões gerais sobre os módulos
desenvolvidos, simulando o papel de um usuário final. A avaliação dos resultados mostrou
que o sistema proposto atingiu as reais necessidades dos usuários que desejam requisitar um
táxi.
109
6
CONCLUSÕES E TRABALHOS FUTUROS
Este capítulo apresenta as conclusões finais desta pesquisa, baseados no sistema
desenvolvido proposto por este trabalho, assim como os resultados obtidos por meio das
avaliações de usuários. Também, neste capítulo, é feito algumas sugestões de trabalhos
futuros para outras pesquisas desta área.
6.1
CONCLUSÕES
Este trabalho apresentou um protótipo de solução para dispositivos móveis, que
utilizam a plataforma Android, a auxiliarem os seus usuários a buscar e chamar os serviços de
táxis mais próximos às suas localizações geográficas. Para tal, foram reunidos as tecnologias
GPS, Android, Google Maps, MongoDB e arquitetura REST para criar um aplicativo que
torne esta tarefa mais fácil e eficiente. No final da etapa de desenvolvimento, deu-se início ao
processo de avaliação do protótipo com a aplicação dos questionários, a partir dos quais
foram recolhidos opiniões e feedbacks de possíveis usuários do sistema.
Com base nos resultados da etapa de avaliação do protótipo, verificou-se que este
trabalho atingiu o seu objetivo em propor uma solução utilizando a Tecnologia da Informação
(TI) para auxiliar usuários dos serviços de táxis dos centros urbanos a buscarem e realizarem
chamadas aos pontos de táxis, de modo que este serviço prestado pelo sistema de informação
desenvolvido torne este processo mais ágil e eficiente aos seus usuários.
Conhecimentos teóricos e técnicos em GPS, SIG, cartografia e Google Maps
foram fundamentais para a compreensão do problema e também na formulação da solução.
Tanto a etapa de modelagem e captação de requisitos quanto à etapa de desenvolvido
possibilitaram uma grande oportunidade de aprendizado e aperfeiçoamento de técnicas
obtidas no decorrer do curso de graduação. As ferramentas e tecnologias selecionadas para o
desenvolvimento do sistema proposto corresponderam às expectativas dos autores,
fornecendo uma estrutura robusta e confiável para implementar as funcionalidades previstas
no planejamento da pesquisa. O aplicativo “Hey, Táxi!”, objeto resultante desta pesquisa,
atendeu às expectativas de seus autores e dos entrevistados da etapa de avaliação em criar
110
uma solução para dispositivos móveis que esteja aliada a uma necessidade comum para
pessoas dos grandes centros urbanos, e que, ao mesmo tempo, gere valor para seus usuários
oferecendo um serviço importante para quem necessita se deslocar para outros lugares
utilizando um táxi como meio de transporte.
6.2
TRABALHOS FUTUROS
O sistema proposto por este trabalho ainda pode possuir muitas funcionalidades,
que podem ser incorporadas em trabalhos futuros. Tais funcionalidades podem ser de grande
valor para o seu usuário final, aperfeiçoando as já existentes ou criando novos serviços para
auxiliar às buscas de pontos de táxis. Algumas delas são baseadas nos feedbacks recebidos
durante o período de desenvolvimento e de avaliação. Elas são descritas a seguir:
 possibilitar que um usuário avalie e faça comentários sobre o serviço prestado por um
ponto de táxi, criando um ranking de pontos de táxis mais bem avaliados;
 para a funcionalidade de cálculo de rota, aperfeiçoar o algoritmo que sugere o ponto
de táxi ao usuário para considerar, além da sua distância ao usuário, aquele ponto de
táxi que:
o oferecer o menor valor da bandeira utilizada no horário vigente;
o possuir a melhor avaliação dos usuários;
o atendeu uma chamada do usuário anteriormente;
o estiver presente na lista de favoritos do usuário;
o possuir táxis disponíveis para realizar uma corrida.
 permitir que os próprios usuários sugiram incluir informações de pontos de táxis que
não estão cadastrados no sistema, ou fazer correções das informações já existentes;
 visualizar informações dos últimos pontos de táxis sem a necessidade de possuir uma
conexão com a Internet ativa (modo offline);
 mostrar, ao usuário, informações como:
o capacidade do porta malas, quando disponível;
o capacidade de passageiros;
o número de pontos de táxis disponíveis em um ponto de táxi.
111
 busca de pontos de táxis que possuírem determinadas características de interesse ao
usuário (possui telefone ou celular, aceita determinadas formas de pagamentos, possui
ar-condicionado, há disponibilidade para transportar malas, etc.);
 aumentar o alcance do aplicativo proposto, desenvolvendo versões para outras
tecnologias voltadas à dispositivos móveis, como, por exemplo, iPhone, iPad, HTML
5, Blackberry, Windows Phone, entre outros;
 estudo de técnicas para proteger os serviços RESTful oferecidos pelo servidor do
sistema, de forma a disponibilizar determinados recursos somente a usuários
devidamente autenticados e autorizados no sistema;
 estudo de usabilidade e ergonomia voltado à aplicativos para dispositivos móveis;
 utilizar os mesmos conceitos e tecnologias para a criação de um aplicativo para busca
de
pontos
de
ônibus
de
uma
cidade,
seus
horários
e
itinerários.
REFERÊNCIAS
ALECRIM, Emerson. O kernel do Linux. Disponível em:
<http://www.infowester.com/linuxkernel.php>. Acesso em: 25 jun. 2011.
ALOUINI, Mohamed-Slim. GPS: An Overview. Tunisian Scientific Magazine, 1996.
ANDRADE, Maria Margarida de. Introdução à metodologia do trabalho científico:
elaboração de trabalhos na graduação. 3. ed. São Paulo: Atlas, 1998.
APACHE. Apache License: Version 2.0. Disponível em:
<http://www.apache.org/licenses/LICENSE-2.0>. Acesso em: 1 mai. 2011a.
______. Apache Tomcat. Disponível em: <http://tomcat.apache.org/>. Acesso em: 16 jul.
2011b.
______. Subversion. Disponível em: <http://subversion.apache.org/>. Acesso em: 16 jul.
2011c.
______. Apache Maven. Disponível em: <http://maven.apache.org/>. Acesso em: 16 jul.
2011d.
BEZERRA, Eduardo. Princípios de análise de sistemas com UML. Rio de Janeiro: Campus,
2002.
BLAHA, Michael; RUMBAUGH, James. Modelagem e Projetos Baseados em Objetos
com UML 2. 2. ed. rev. e atual. Rio de Janeira: Campus, 2006.
BOOCH, Graddy; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de
Janeiro: Campus, 2000.
BORNSTEIN, D. Dalvik Virtual Machine. Disponível em: <http://www.dalvikvm.com/>.
Acesso em: 2 mai. 2011.
BRANCO, Anselmo L. Latitude, Longitude e GPS. Disponível em:
<http://educacao.uol.com.br/geografia/ult1694u97.jhtm>. Acesso em: 22 abr. 2011.
CÂMARA, Gilberto et al. Anatomia de Sistemas de Informação Geográfica. 1996.
Disponível em: <http://www.dpi.inpe.br/gilberto/livro/anatomia.pdf>. Acesso em: 22 abr.
2011.
CÂMARA, Gilberto; DAVIS, Clodoveu. Introdução. In: CÂMARA, Gilberto et al.
Introdução à Ciência da Geoinformação. Disponível em:
<http://www.dpi.inpe.br/gilberto/livro/introd/>. Acesso em: 21 abr. 2011.
CERVO, Amado Luiz; BERVIAN, Pedro A. Metodologia Científica. 5. ed. São Paulo:
Pretince Hall, 2002.
DAVIS, Bruce Ellsworth. GIS: a visual approach. Cengage Learning, 2001.
DANA, Nourie. Getting Started With an Integrated Development Enviromment (IDE).
Disponível em: <http://java.sun.com/developer/technicalArticles/tools/intro.html>. Acesso
em: 22 mai. 2011.
DIAS, Kelvin Lopes; SADOK, Djamel Fauzi Hadj. Internet Móvel: Tecnologias, Aplicações
e QoS. 19º Simpósio Brasileiro de Redes de Computadores: 2001.
DOCFORGE. Framework. Disponível em: <http://docforge.com/wiki/Framework>. Acesso
em: 8 mai. 2011.
EL-RABBANY, Ahmed. Introduction to GPS: the Global Positioning System. Artech
House Publishers, 2002.
FELKER, Donn; DOBBS, Joshua. Android Application Development for Dummies. Wiley
Publishing, 2011.
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software
Architectures. Disponível em: <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>.
Acesso em: 16 jul. 2011.
FLITZ, Paulo Roberto. Cartografia básica. 2 ed., rev. e ampl. Canoas: Centro Universitário
La Salle, 2005.
FOWLER, Marting; SCOOT, Kendal. UML Essencial: Um breve guia para a linguagempadrão de modelagem de objetos. 2 ed. Porto Alegre: Bookman, 2000.
FRANCH, Gregory T. Understanding the GPS: an introduction to the Global Positioning
System. GeoResearch: 1996.
GARTNER. Gartner Says Worldwide Mobile Phone Sales Grew 35 Percent in Third
Quarter 2010; Smartphone Sales Increased 96 Percent. Disponível em:
<http://www.gartner.com/it/page.jsp?id=1466313>. Acesso em: 30 mai. 2011.
______. Gartner Says Sales of Mobile Devices in Second Quarter of 2011 Grew 16.5
Percent Year-on-Year; Smartphone Sales Grew 74 Percent. Disponível em:
<http://www.gartner.com/it/page.jsp?id=1764714>. Acesso em: 3 set. 2011.
GeoTools. About GeoTools. Disponível em: <http://geotools.org/about.html>. Acesso em: 19
out. 2011.
GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 3. ed. São Paulo: Atlas, 1996.
GOOGLE. Android. Disponível em: <http://www.android.com>. Acesso em: 26 mar. 2011a.
______. Ajuda do Mapas: Sobre o Google Maps. Disponível em:
<http://maps.google.com/support/bin/answer.py?hlrm=en&answer=7060>. Acesso em: 10
abr. 2011b.
______. Serviços da web da Google Maps API: The Google Directions API. Disponível em:
<http://code.google.com/intl/pt-BR/apis/maps/documentation/directions/#Introduction>.
Acesso em: 12 abr. 2011c.
______. Serviços da web da Google Maps API: Google Geocoding API. Disponível em:
<http://code.google.com/intl/pt-BR/apis/maps/documentation/geocoding/#Geocoding>.
Acesso em: 12 abr. 2011d.
______. What is Android?. Disponível em:
<http://developer.android.com/guide/basics/what-is-android.html>. Acesso em: 1 mai. 2011e.
______. Licenses. Disponível em: <http://source.android.com/source/licenses.html>. Acesso
em: 1 mai 2011f.
______. Introducing the T-Mobile G1. Disponível em:
<http://www.google.com/intl/en_us/mobile/android/hpp.html>. Acesso em: 1 mai. 2011g.
______. Application Fundamentals. Disponível em:
<http://developer.android.com/guide/topics/fundamentals.html>. Acesso em: 2 mai. 2011h.
______. Activities. Disponível em:
<http://developer.android.com/guide/topics/fundamentals/activities.html>. Acesso em: 7 mai.
2011i.
______. Intents and Intent Filters. Disponível em:
<http://developer.android.com/guide/topics/intents/intents-filters.html>. Acesso em: 7 mai.
2011j.
______. Press/media. Disponível em: <http://www.android.com/media/>. Acesso em: 7 mai.
2011k.
GSM ASSOSIATION. Location Based Services. Disponível em:
<http://www.gsmworld.com/documents/se23.pdf>. Acesso em: 23 abr. 2011.
HANSON, Jarice. 24/7: how cell phones and the Internet change the way we live, work, and
play. Greenwood Publishing Group: 2007
IBGE. Dados do Censo 2010 publicados no Diário Oficial da União do dia 04/11/2010.
Disponível em: <http://www.ibge.gov.br/censo2010/dados_divulgados/index.php>. Acesso
em: 26 mar. 2011a.
______. Noções Básicas de Cartografia. Disponível em:
<http://www.ibge.gov.br/home/geociencias/cartografia/manual_nocoes/representacao.html>.
Acesso em: 22 abr. 2011b.
______. Mapas Estaduais. Disponível em:
<http://www.ibge.gov.br/mapas_ibge/atlas_juv_estaduais.php>. Acesso em: 3 set. 2011c.
IBM. RESTful Web Services: The basics. Acessado em:
<https://www.ibm.com/developerworks/webservices/library/ws-restful/>. Acesso em: 19 jun.
2011.
INTERNATIONAL CARTOGRAPHIC ASSOCIATION. Mission. Disponível em:
<http://icaci.org/mission>. Acesso em: 22 abr. 2011.
IT WEB. Plataforma Android vira líder de mercado. Disponível em:
<http://www.itweb.com.br/noticias/index.asp?cod=76469>. Acessado em: 26 mar. 2011.
JIANXIN, Yu et al. Design and Implementation of Taxi Calling and Dispatching System
based on GPS Mobile Phone: A Research for LBS Application Teaching Case. In:
INTERNATIONAL CONFERENCE ON COMPUTER SCIENCE & EDUCATION, 4.,
2009, China. Anais… p. 1163-1169.
JSON. Introdução ao JSON. Disponível em: <http://www.json.org/json-pt.html>. Acesso
em: 19 jun. 2011.
KOOLHAAS, Michael. Elementos del sistema de posicionamiento global (GPS).
Disponível em: <http://www.fagro.edu.uy/~topografia/docs/Elem.del_GPS1.3.pdf>. Acesso
em: 22 abr. 2011.
LAKATOS, E. M.; MARCONI, M. A. Fundamentos de metodologia científica. 3. ed. rev. e
ampl. São Paulo : Atlas, 1991.
LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e ao projeto
orientado a objetos. Porto Alegre: Bookman, 2000.
MARIMOTO, Carlos Eduardo. Smartphones: Guia Prático. Disponível em:
<http://www.hardware.com.br/livros/smartphones/google-maps.html>. Acesso em: 10 abr.
2011.
MATTAR NETO, João Augusto. Metodologia Científica na Era da Informática. São
Paulo: Saraiva, 2002.
MEZZAROBA, O; MONTEIRO, C. Manual de Metodologia da Pesquisa no Direito. 2. ed.
rev. São Paulo: Saraiva, 2004.
MONGODB. MongoDB. Disponível em: <http://www.mongodb.org/>. Acesso em: 16 jul.
2011a.
______. Sharding Introduction. Disponível em:
<http://www.mongodb.org/display/DOCS/Sharding+Introduction>. Acesso em: 16 jul. 2011b.
MONICO, J. F. G. Posicionamento pelo NAVSTAR-GPS: Descrição, fundamentos e
aplicações. 1 ed. Presidente Prudente: Editora UNESP, 2000.
MONQUEIRO, Julio Cesar Bessa. 40% do uso do Google Maps é através de dispositivos
portáteis. Disponível em: <http://www.hardware.com.br/noticias/2011-03/googlemobile.html>. Acesso em: 17 mar. 2011.
MYTAXI. myTaxi. Disponível em: <http://www.mytaxi.net>. Acesso em: 23 out. 2011.
NIELSEN. Android Most Popular Operating System in U.S. Among Recent Smartphone
Buyers. Disponível em: <http://blog.nielsen.com/nielsenwire/online_mobile/android-mostpopular-operating-system-in-u-s-among-recent-smartphone-buyers/>. Acesso em: 1 mai.
2011.
PC MAGAZINE. Definition of: API. Disponível em:
<http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp>. Acesso em: 24
abr. 2011a.
______. Definition of: DBMS. Disponível em:
<http://www.pcmag.com/encyclopedia_term/0,2542,t=DBMS&i=40952,00.asp>. Acesso em:
29 mai. 2011b.
______. Definition of: Scalable. Disponível em: <
http://www.pcmag.com/encyclopedia_term/0,2542,t=scalable&i=50835,00.asp>. Acesso em:
10 out. 2011c.
PEREIRA, Lúcio Camilo; SILVA, Lourenço. Android para Desenvolvedores. Brasport,
2009.
PESTANA, António. Sistema de Posicionamento Global. Disponível em:
<http://navstar.idt.ipp.pt/Acetatos/navstar_2002.pdf>. Acesso em: 24 jun. 2011.
PETERSON, Michael P. A Critical Assessment of Maps and the Internet. Disponível em:
<http://www.rbc.ufrj.br/_pdf_60_2008/60_03_7.pdf>. Acesso em: 25 jun. 2011.
PRESSMAN, Roger. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002.
PRESTES, Maria Luci de Mesquita. A pesquisa e a construção do conhecimento científico:
do planejamento aos textos, da escola à academia. 2. ed. São Paulo: Rêspel, 2003.
PR NEWSWIRE. World Mobile Applications Market Worth US$25 Billion by 2015.
Disponível em: <http://www.prnewswire.com/news-releases/marketsandmarkets-worldmobile-applications-market-worth-us25-billion-by-2015-114087839.html>. Acesso em: 30
mai. 2011.
RAMESH, A.; MISRA, R. P. Fundamentals of Cartography: Revised and Enlarged.
Concept Publishing, 1969.
RECKZIEGEL, Maurício. Google Directions e Elevation API: Aperfeiçoando o cálculo de
autonomia de veículos. Disponível em:
<http://imasters.com.br/artigo/17349/tendencias/google_directions_e_elevation_api_aperfeico
ando_o_calculo_de_autonomia_de_veiculos/>. Acesso em: 12 abr. 2011.
REDE NACIONAL DE PESQUISA. O que é middleware. Disponível em:
<http://www.rnp.br/noticias/2006/not-060926.html>. Acesso em: 9 mai. 2011.
REZENDE, Denis Alcide. Engenharia de software e sistemas de informação. Brasport:
2006.
ROGERS, Rick et al. Android Application Development: Programming with the Google
SDK. O'Reilly, 2009
ROOS, Dave. HowStuffWorks: Como aproveitar melhor uma API para conferências
online. Disponível em: <http://informatica.hsw.uol.com.br/conferencia-api4.htm>. Acesso
em: 18 de mar. 2011.
RUIZ, João Álvaro. Metodologia Científica: guia para eficiência nos estudos. São Paulo:
Atlas, 1996.
SILVA, Aloizio; MATEUS, Geraldo. A Mobile Location-Based Vehicle Fleet
Management Service Application. In: IEEE INTELLIGENT VEHICLES SYMPOSIUM, 4.,
2003, Columbus. Anais... p. 25-30.
SOUSA, Giselle; LIMA, Zélia. Geoprocessamento a aplicação do GPS na navegação
marítima. SEPA: Seminário Estudantil de Produção Acadêmica, Salvador, 1997.
SKYCODERS. cab4me. Disponível em: <http://www.cab4me.com/>. Acesso em: 23 out.
2011.
SPRING SOURCE. About Spring. Disponível em: <http://www.springsource.org/about>.
Acesso em: 16 jul. 2011.
STRICKLAND, Jonathan. HowStuffWorks: Como funciona o Android (Google Phone).
Disponível em: < http://informatica.hsw.uol.com.br/google-phone2.htm>. Acesso em: 9 de
mai. 2011.
TANENBAUM, Andrew S; WOODHULL, Albert S. Sistemas operacionais: projeto e
implementação. 2a edição. Porto Alegre: Bookmn, 2000.
TARIFA DE TÁXI. Tarifa de Táxi. Disponível em: <http://www.tarifadetaxi.com/>. Acesso
em: 23 out. 2011.
TAURION, Cezar. Internet Móvel: Tecnologias, aplicações e modelos. Rio de Janeiro:
Campus, 2002.
TAXI MAGIC. Taxi Magic. Disponível em: <http://taximagic.com/>. Acesso em: 23 out.
2011.
TELECO. Estatísticas de Celulares no Brasil. Disponível em:
<http://www.teleco.com.br/ncel.asp>. Acesso em: 26 mar. 2011.
VIVA O LINUX. O que é GNU/Linux. Disponível em:
<http://www.vivaolinux.com.br/linux/>. Acesso em: 25 jun. 2011.
W3C. XML. Disponível em: <http://www.w3.org/XML/>. Acesso em: 7 Ago. 2011.
W3SCHOOLS. AJAX Introduction. Disponível em:
<http://www.w3schools.com/ajax/ajax_intro.asp>. Acesso em: 3 set. 2011.
120
APÊNDICES
121
APÊNDICE A – CRONOGRAMA
122
APÊNDICE B – DESCRIÇÃO DOS CASOS DE USO
Visualizar posição atual no mapa
Identificador
CSU02
Descrição
Neste caso de uso, estão descritos os procedimentos para o Usuário
localizar-se geograficamente no mapa.
Ator primário
Usuário
Ator secundário
GPS
Pré-condições
--
Fluxo de tarefas
1 – Realizar CSU01.
2 – É iniciado serviço de localização por GPS.
3 – A cada 1 (um) minuto, o sistema atualiza a posição do Usuário no
mapa.
Fluxos alternativos
--
Fluxos de exceção
2.a - Não sendo possível acessar o serviço de GPS.
2.a.1 – É mostrada uma mensagem de erro.
Pós-condições
- Um ícone é plotado no mapa, indicando ao Usuário a sua posição
geográfica.
Quadro 12 - Caso de uso CSU02 - Visualizar posição atual no mapa.
Fonte: Elaboração dos autores, 2011.
123
Visualizar pontos de táxis através do mapa
Identificador
CSU03
Descrição
Permite que o Usuário visualize as posições geográficas dos pontos de
táxis utilizando o mapa.
Ator primário
Usuário
Ator secundário
GPS, Google Maps
Pré-condições
--
Fluxo de tarefas
1 – Realizar CSU01.
2 – A aplicação requisitará as informações geográficas dos pontos de
táxis do local que seta sendo mostrado ao Usuário.
Fluxos alternativos
--
Fluxos de exceção
2.a - Não sendo possível comunicar-se com o servidor da aplicação.
4.a.1 - Uma mensagem de erro é mostrada ao Usuário.
2.b - No caso de encontrar pontos de táxis sem informações
geográficas.
4.b.1 - Não é mostrado no mapa.
Pós-condições
- Para cada ponto de táxi que foi encontrado, é plotado no mapa um
ícone indicando a sua posição.
Quadro 13 - Caso de uso CSU03 - Visualizar pontos de táxis através do mapa.
Fonte: Elaboração dos autores, 2011.
124
Visualizar lista de pontos de táxis próximos
Identificador
CSU04
Descrição
Com o objetivo de facilitar a busca de pontos de táxis, o sistema é
capaz de listar os pontos de táxis próximos à localização do Usuário.
Ator primário
Usuário
Ator secundário
GPS
Pré-condições
- A posição do Usuário deve ser conhecida.
Fluxo de tarefas
1 – Usuário abre o menu.
2 – Seleciona a opção “Lista”.
3 – A posição geográfica do Usuário é calculada pelo GPS.
4 – Uma nova janela é aberta.
Fluxos alternativos
--
Fluxos de exceção
3.a – Não sendo possível acessar o serviço do GPS.
3.a.1 – Uma mensagem de erro é mostrada.
3.a.2 – O sistema retornará à janela principal (mapa).
Pós-condições
- Lista com os pontos mais próximos à um raio de 10 km, ordenados
por proximidade, em relação ao Usuário.
Quadro 14 - Caso de uso CSU04 - Visualizar lista de pontos de táxis próximos.
Fonte: Elaboração dos autores, 2011.
Visualizar informações de pontos de táxis
Identificador
CSU05
Descrição
Permite que o Usuário visualize informações e características de um
ponto de táxi desejado.
Ator primário
Usuário
Ator secundário
--
Pré-condições
--
Fluxo de tarefas
1 – O Usuário abre o mapa ou listagem de pontos de táxis.
2 – O mesmo clica em um ícone de um ponto de táxi.
3 – É feita uma requisição ao servidor para buscar as informações do
táxi escolhido.
Fluxos alternativos
--
Fluxos de exceção
3.a - Não sendo possível comunicar-se com o servidor da aplicação.
3.a.1 - Uma mensagem de erro é mostrada ao Usuário.
3.a.2 - O sistema retornará à janela principal (mapa).
Pós-condições
- É apresentada uma tela contendo todas as informações do ponto de
táxi escolhido.
Quadro 15 - Caso de uso CSU05 - Visualizar informações de pontos de táxis.
Fonte: Elaboração dos autores, 2011.
125
Visualizar histórico de chamadas
Identificador
CSU06
Descrição
O Usuário pode recuperar informações de pontos de táxis que foram
chamados anteriormente.
Ator primário
Usuário
Ator secundário
--
Pré-condições
--
Fluxo de tarefas
1 – Usuário abre o menu.
2 – O mesmo clica no item “Histórico”.
3 – É feita uma busca das últimas chamadas realizadas pelo Usuário.
Fluxos alternativos
--
Fluxos de exceção
3.a - No caso de não encontrar nenhuma chamada.
3.a.1 - É apresentada uma lista vazia.
Pós-condições
- É apresentada uma lista contendo as últimas 10 chamadas para
pontos de táxi diferentes realizadas pelo Usuário.
Quadro 16 - Caso de uso CSU06 - Visualizar histórico de chamadas.
Fonte: Elaboração dos autores, 2011.
Gerenciar favoritos
Identificador
CSU07
Descrição
Neste caso de uso, estão descritos as ações que o Usuário pode
realizar para adicionar ou remover um ponto de táxi da sua lista de
favoritos.
Ator primário
Usuário
Ator secundário
--
Pré-condições
--
Fluxo de tarefas
1 – Usuário abre o menu.
2 – O mesmo clica no item “Favoritos”.
3 – É feita uma busca por pontos de táxis cadastrados como favorito
pelo Usuário.
Fluxos alternativos
--
Fluxos de exceção
3.a - No caso de não existir nenhum ponto de táxi como favorito.
3.a.1 - É apresentada uma lista vazia.
Pós-condições
- É aberta uma janela no qual o Usuário é capaz de ver todos os
pontos de táxis que foram marcados como favoritos.
Quadro 17 - Caso de uso CSU07 - Gerenciar favoritos.
Fonte: Elaboração dos autores, 2011.
126
Calcular estimativa de preço de corrida
Identificador
CSU08
Descrição
Permite que o Usuário realize um cálculo da estimativa do valor da
corrida, partindo da sua posição atual até um destino de sua escolha.
Ator primário
Usuário
Ator secundário
GPS, Google Maps
Pré-condições
- A posição do Usuário deve ser conhecida.
Fluxo de tarefas
1 – Usuário abre o menu.
2 – O mesmo clica no item “Cálculo corrida”.
3 – O Usuário seleciona o seu destino.
4 – As informações são enviadas ao servidor.
5 – O sistema encontra o ponto de táxi mais próximo.
6 – O sistema calcula a estimativa da corrida.
Fluxos alternativos
--
Fluxos de exceção
4.a - Não sendo possível comunicar-se com o servidor da aplicação.
4.a.1 - Uma mensagem de erro é mostrada ao Usuário.
5.a – Não sendo possível encontrar um ponto de táxi próximo.
5.a.1 – Uma mensagem de erro é mostrada ao Usuário.
6.a - Não sendo possível acessar serviço de mapas do Google.
6.a.1 - Uma mensagem de erro é mostrada ao Usuário.
Pós-condições
- É apresentado a distância e o custo estimado desta corrida.
- É apresentado o ponto de táxi utilizado como referência para o
cálculo da rota.
Quadro 18 - Caso de uso CSU08 - Calcular estimativa de preço de corrida.
Fonte: Elaboração dos autores, 2011.
127
Realizar chamada
Identificador
CSU09
Descrição
Permite que o Usuário visualize as opções de chamadas para um
ponto de táxi escolhido.
Ator primário
Usuário
Ator secundário
--
Pré-condições
--
Fluxo de tarefas
1 – O Usuário seleciona um ponto de táxi de seu interesse.
2 – O mesmo abre o menu.
3 – Clica no item “Chamar”.
Fluxos alternativos
--
Fluxos de exceção
--
Pós-condições
- Caso o ponto de táxi tenha pelo menos um número de telefone, é
mostrada a opção “Telefone”.
- Caso o ponto de táxi tenha pelo menos um número de celular, é
mostrada a opção “SMS”.
Quadro 19 - Caso de uso CSU09 - Realizar chamada.
Fonte: Elaboração dos autores, 2011.
Realizar chamada por telefone
Identificador
CSU10
Descrição
O Usuário é capaz de realizar uma chamada telefônica para um
determinado ponto de táxi.
Ator primário
Usuário
Ator secundário
Operadora de telefonia
Pré-condições
- O dispositivo do Usuário deve ter capacidade de realizar chamadas
telefônicas.
- O Usuário deve ter crédito para poder realizar chamadas telefônicas.
- O ponto de táxi escolhido deverá possuir um número de telefone.
Fluxo de tarefas
1 – Realizar CSU10.
2 – O Usuário seleciona a opção “Telefone”.
3 – É aberta uma janela para iniciar a ligação telefônica.
Fluxos alternativos
--
Fluxos de exceção
3.a - No caso de não ser possível realizar uma chamada telefônica.
3.a.1 - O sistema retornará à janela de informações do ponto de
táxi.
Pós-condições
- O sistema inicia uma chamada com o ponto de táxi.
Quadro 20 - Caso de uso CSU10 - Realizar chamada por telefone.
Fonte: Elaboração dos autores, 2011.
128
Realizar chamada por SMS
Identificador
CSU11
Descrição
Permite que o Usuário realize uma requisição de serviço de táxi por
uma mensagem SMS.
Ator primário
Usuário
Ator secundário
Operadora de telefonia
Pré-condições
- O dispositivo do Usuário deve ter capacidade de enviar mensagens
SMS.
- O Usuário deve ter créditos para poder enviar mensagens SMS.
- O ponto de táxi escolhido deve possuir um número de telefone
celular.
Fluxo de tarefas
1 – Realizar CSU10.
2 – O Usuário seleciona a opção “SMS”.
3 – Uma janela mostrando o conteúdo da mensagem é aberta ao
Usuário.
4 – Usuário clica no botão “Enviar”.
Fluxos alternativos
--
Fluxos de exceção
4.a - No caso de não ser possível realizar uma chamada telefônica.
4.a.1 - Uma mensagem de erro é apresentada ao Usuário.
4.b.1 - Voltar ao passo 3.
Pós-condições
- O celular enviará uma mensagem SMS para o ponto de táxi
escolhido, informando o endereço do emissor.
Quadro 21 - Caso de uso CSU11 - Realizar chamada por SMS.
Fonte: Elaboração dos autores, 2011.
Listar pontos de táxis
Identificador
CSU12
Descrição
Caso de uso que descreve a funcionalidade de listagem de pontos de
táxis no módulo administrador.
Ator primário
Administrador
Ator secundário
--
Pré-condições
--
Fluxo de tarefas
1 – Administrador abre o sistema de administração.
2 – Clica na aba “Pontos de táxis”.
Fluxos alternativos
--
Fluxos de exceção
--
Pós-condições
- Os pontos de táxis cadastrados são listados na tela.
Quadro 22 - Caso de uso CSU12 - Cadastrar ponto de táxi.
Fonte: Elaboração dos autores, 2011.
129
Cadastrar ponto de táxi
Identificador
CSU13
Descrição
Permite que o Administrador cadastre novos pontos de táxis para
estarem disponíveis aos usuários do sistema.
Ator primário
Administrador
Ator secundário
--
Pré-condições
--
Fluxo de tarefas
1 – Administrador abre o sistema de administração.
2 – Clica na aba “Novo ponto de táxi”.
3 – Preenche o formulário.
4 – Indica a posição geográfica do novo ponto de táxi no mapa.
5 – Clica no botão “Salvar”.
Fluxos alternativos
--
Fluxos de exceção
5.a – Não fornecendo as informações obrigatórias: ‘Nome’, ‘Bandeira
1’, ‘Bandeira 2’, ‘Preço de largada’ e a posição geográfica do ponto
de táxi.
5.a.1 – Uma mensagem de erro é apresentada na tela.
5.a.2 – Retornar ao passo 3.
Pós-condições
- Uma mensagem de sucesso da operação é apresentada na tela.
Quadro 23 - Caso de uso CSU13 - Cadastrar ponto de táxi.
Fonte: Elaboração dos autores, 2011.
130
Remover ponto de táxi
Identificador
CSU14
Descrição
Descreve os passos para que um Administrador possa remover um
ponto de táxi da base de dados do sistema.
Ator primário
Administrador
Ator secundário
--
Pré-condições
- O ponto de táxi deve estar cadastrado no sistema.
Fluxo de tarefas
1 – Realizar CSU13.
3 – Clica no ícone de remoção.
4 – Uma mensagem de confirmação é apresentada.
5 – O Administrador clica em ‘OK’.
Fluxos alternativos
5.a – Clicando em ‘Cancelar’
5.a.1 – Encerrar caso de uso.
Fluxos de exceção
--
Pós-condições
- Uma mensagem de sucesso da operação é apresentada na tela.
- O ponto de táxi é removido da listagem de pontos de táxis.
Quadro 24 - Caso de uso CSU14 - Remover ponto de táxi.
Fonte: Elaboração dos autores, 2011.
131
Atualizar ponto de táxi
Identificador
CSU15
Descrição
Descreve os passos para que um Administrador possa atualizar as
informações de um ponto de táxi.
Ator primário
Administrador
Ator secundário
--
Pré-condições
- O ponto de táxi deve estar cadastrado no sistema.
Fluxo de tarefas
1 – Realizar CSU13.
3 – Clica no ícone de atualização.
4 – Uma aba é aberta com os campos de cadastro do ponto de táxi já
preenchidos.
5 – O Administrador informa as novas informações do ponto de táxi.
6 – O Administrador clica em ‘Salvar’.
Fluxos alternativos
5.a – Clicando em ‘Cancelar’
5.a.1 – Encerrar caso de uso.
Fluxos de exceção
Pós-condições
- Uma mensagem de sucesso da operação é apresentada na tela.
- As novas informações do ponto de táxi fornecidas no formulário são
salvas na base de dados do sistema.
Quadro 25 - Caso de uso CSU15 - Atualizar ponto de táxi.
Fonte: Elaboração dos autores, 2011.
132
APÊNDICE C – RESULTADOS DOS QUESTIONÁRIOS
133
134
135
136
137
138