Você está na página 1de 16

ANTARES: Um sistema Web de consulta de

rotas de nibus como servio pblico


Rodrigo Bastos1
Patrcia A. Jaques2

Resumo: Este artigo apresenta um sistema Web para busca de rotas de nibus como ferramenta de
auxlio a usurios de transporte pblico. A aplicao desenvolvida usa o algoritmo A*, conhecido
no campo de inteligncia artificial, como base para a gerao de rotas de nibus. A API do Google
Maps empregada para ilustrar os resultados visuais e descritivos de dada busca. Dois
experimentos foram realizados a fim de avaliar a usabilidade e corretude da ferramenta.
Palavras-chave: Sistemas de informao. Sistemas Web. Inteligncia artificial.

Abstract: This paper presents a Web system for bus trajectory search as a tool to help public
transport users. The developed application uses the A* algorithm, known on the Artificial
Intelligence field, as a base for the generation of bus routes. The Google Maps API is employed to
illustrate the descriptive and visual results of a given search. Two experiments were accomplished
in order to evaluate the system usability and correctness.
Keywords: Information systems. Web systems. Artificial intelligence.

Introduo

A Web tem se constitudo na mdia mais promissora desde a inveno da televiso. Enquanto a televiso
um meio de comunicao em que o emissor domina todo o processo e o receptor no pode responder em tempo
real, a Web oferece a oportunidade de interao, atravs de uma tecnologia naturalmente aberta e possibilita a
colaborao coletiva de novas ideias e obras [1].
A distncia geogrfica deixou de ser um entrave, mas a econmica (ricos e pobres), a cultural (acesso
efetivo pela educao continuada) e a tecnolgica (acesso e domnio ou no das tecnologias de comunicao)
ganharam fora. Contudo, com o constante crescimento do nmero de usurios da Web no mundo, ampliaram-se
as possibilidades em torno de suas aplicaes; assim, reas como educao, comrcio e entretenimento ganharam
seu espao na rede.
Alm dos sistemas educacionais, de entretenimento ou corporativos, um outro tipo de aplicao vem
ganhando espao na Web: os sistemas destinados prestao de servios, ou, como so conhecidos, software
como servio (do ingls software as a service). Um exemplo deste tipo de aplicao est relacionado pesquisa
de telefones e estabelecimentos a Telelista [2]. Nesta pgina Web so oferecidos telefones teis, possibilidade
de busca de telefones por atividades, servio, produto, marca, entre outros, alm de filtros adicionais por estado
ou cidade. Por sua vez, os servios oferecidos pelo site dos Correios [3] variam entre o monitoramento de uma
mercadoria, consulta de CEP ou endereo, clculos de prazos e preos, entre outros.

Programa Interdisciplinar de Ps-graduao em Cincia da Computao - UNISINOS


{rodrigobas@gmail.com}
2
Programa Interdisciplinar de Ps-graduao em Cincia da Computao - UNISINOS
{pjaques@unisinos.br}
doi: 10.5335/rbca.2010.005

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 41

A empresa Google [4] criou, recentemente, um servio de localizao por meio de imagens de satlites,
mapas, definio de rotas, etc chamado Google Maps [5], por meio do qual so disponibilizadas diversas opes
de consultas e visualizaes ao usurio, como, por exemplo, pesquisar um determinado endereo, encontrar
empresas ou negcios, visualizao por mapa, satlite ou terreno, entre outros, atravs de uma interface
amigvel. Alm disso, o Google Maps oferece a opo de integrar os diferentes tipos de mapas a qualquer site
particular atravs de uma Interface de Programao de Aplicativos, ou, em ingls, Application Programming
Interface (API), desenvolvida na linguagem JavaScript chamada Google Maps API [6].
Inspirado nas tecnologias e possibilidades do Google Maps, o presente trabalho prope um complemento
deste servio destinado a auxiliar usurios do transporte pblico. O sistema proposto, desenvolvido para a Web,
solicita ao usurio apenas a rua de origem e a rua de destino e fornece uma descrio completa de linhas de
nibus (e em que paradas) que ele deve utilizar para chegar ao seu destino. Alm disso, pela integrao com o
Google Maps API, o sistema oferece ao usurio um mapa de visualizao da trajetria prevista pelo sistema. O
nico sistema Web, do qual se tem conhecimento, que oferece informao semelhante no Brasil o da EPTC
[7]3. Entretanto, a EPTC oferece um servio simplificado neste sentido, visto que o site da empresa permite
apenas visualizar o itinerrio das linhas de nibus e os seus horrios. Assim, delega ao usurio todo o trabalho
braal de montar sua trajetria, pois s existe a informao de qual nibus ou lotao passa por uma determinada
rua.
Este artigo se encontra organizado como segue: na seo 2 apresentada uma introduo aos algoritmos
de busca inteligentes, com destaque ao algoritmo A*, que ser aplicado na definio de trajetrias neste trabalho;
a seo 3 descreve o Google Maps e como este servio, utilizado para visualizao de trajetrias no presente
trabalho, pode ser inserido em outros sistemas web; a seo 4 realiza uma comparao do trabalho proposto com
outros trabalhos relacionados; na seo 5 descrito o sistema proposto e, na seo 6, so apresentados os
resultados da avaliao com usurios; finalmente, na seo 7 so descritas algumas consideraes finais e
sugeridos trabalhos futuros a serem realizados para o aprimoramento do sistema.

Algoritmos de Busca da IA
O trabalho proposto utiliza-se de algoritmos de busca inteligente para definio das rotas de nibus.

Algoritmos de busca so uma das mais poderosas abordagens para a resoluo de problemas em
inteligncia artificial (IA) [8]. Trata-se de mecanismos de resoluo de problemas universais que
sistematicamente exploram alternativas e encontram uma sequncia para a soluo do problema proposto.
Encontrada a sequncia, h de se considerar se esta trata de uma soluo eficiente ou no. Outra questo
relevante refere-se aos recursos necessrios soluo, ou seja, tempo e memria necessrios para se chegar ao
resultado [8].
Um problema de busca pode ser idealizado por meio da definio dos seguintes elementos [8]:
- um ou mais estados iniciais. Exemplo: o primeiro lance no jogo de xadrez;
- um ou mais estados finais. Exemplo: o xeque-mate;
- um espao de estados, ou seja, todas as possveis posies intermedirias entre o estado inicial e o
estado final. So todos os lances possveis entre o estado inicial e o estado final, por qualquer sequncia
de aes;
- um conjunto de aes que permitem passar de um estado para outro. As aes iro determinar quais so
os estados sucessores de um determinado estado. Exemplo: as regras do jogo.
O problema de busca pode ser representado graficamente por meio de uma rvore de busca, definida
como um conjunto de ns que representam os estados explorados na busca da soluo. A rvore deve possuir um
n inicial (onde a busca inicia) e um n objetivo (onde a busca termina), os quais so conectados por ns
intermedirios. O objetivo da busca encontrar um caminho que ligue o n inicial ao n final. Como entrada
tem-se a descrio do n inicial, do objetivo e de um procedimento que conduza os ns aos seus sucessores;
como sada tem-se uma sequncia de ns que comea no n inicial e termina no n objetivo.
3

Para as cidades de So Paulo e Belo Horizonte, a Google oferece um servio semelhante, chamado de Google Transit.
Maiores detalhes na seo de Trabalhos Relacionados.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 42

Existem dois principais mtodos para a resoluo de problemas atravs de busca na IA: busca cega
(exaustiva) e busca heurstica (informada).
2.1

Busca Cega

A busca cega ou exaustiva no sabe qual o melhor n, entre as fronteiras4 possveis, que deve ser
expandido em busca do menor custo de caminho deste n at o n final (objetivo) [8]. Esses algoritmos se
baseiam na estrutura do espao de estados e determinam estratgias sistemticas para sua explorao, ou seja,
seguem uma estratgia fixa no momento de visitar os ns que representam os estados do problema. Trata-se
tambm de algoritmos exaustivos, de modo que podem acabar recorrendo a todos os ns do problema para achar
a soluo. O custo desses algoritmos pode ser proibitivo na maioria dos problemas reais; portanto, seu uso deve
se limitar a problemas pequenos. Existem, basicamente, duas estratgias de busca cega: em largura e em
profundidade, as quais possuem derivaes.
2.2

Busca Heurstica

A busca heurstica utiliza conhecimento especfico do problema na escolha do prximo n a ser


expandido atravs da aplicao de uma funo de avaliao a cada n na fronteira do espao de estados [8]. O
A* o algoritmo de busca heurstica que vem sendo mais empregado.
O algoritmo A* tenta minimizar o custo total da soluo usando uma funo de avaliao para escolher
um n vizinho do espao de estados de menor valor para ser expandido. Essa funo de avaliao visa prever a
distncia deste n at o objetivo. No A*, a funo de avaliao definida por f(n) = g(n) + h(n), onde g(n) a
distncia real entre o n origem e o n candidato expanso e h(n) (tambm chamada de funo heurstica) um
custo estimado do n candidato at o n destino. Caso se esteja desenvolvendo um sistema que defina a melhor
rota de carro entre duas cidades x e y, g(n) seria a distncia real entre x e w (uma cidade qualquer intermediria) e
h(n), uma distncia estimada entre w e y, por exemplo, a distncia euclidiana. Para que A* seja eficiente, h(n)
deve ser sempre admissvel, ou seja, nunca deve superestimar o custo real. No exemplo dado de rotas entre duas
cidades, a distncia euclidiana uma heurstica admissvel, visto que a distncia em linha reta entre duas cidades
nunca ser maior que a distncia real entre estas duas cidades.
2.3

A*: Algoritmo Aplicado no Trabalho

No sistema Web proposto, o algoritmo utilizado para definir as trajetrias foi o A*. Em razo do
propsito da aplicao, o algoritmo escolhido deve possuir uma soluo completa, pois deve apresentar sempre,
pelo menos, uma soluo quando existir. A soluo encontrada tambm deve ser tima (a estratgia sempre
encontra a melhor soluo quando existem diferentes solues), pois, caso contrrio, ir gerar um custo
desnecessrio de deslocamento ao usurio. Quanto maior a distncia, maior tempo de locomoo gasto e,
geralmente, maior nmero de linhas de nibus a tomar. Em relao a esses dois critrios, os algoritmos de busca
em largura, custo uniforme ou aprofundamento iterativo (que so algoritmos de busca cega) tambm poderiam
ser escolhidos, mas a definio pelo A* ocorreu tambm em funo de tempo e espao. Por se tratar de um
sistema web, este dever ter um tempo de resposta satisfatrio; neste ponto, o algoritmo que melhor gerencia os
recursos e oferece um bom desempenho o A*. Originalmente, o algoritmo A* definido conforme a Figura 1.
Por se tratar de um algoritmo de busca heurstica, necessrio que o algoritmo A* tenha algum
conhecimento especfico sobre o problema (heurstica) para poder estimar qual o melhor nodo da fronteira a ser
expandido. Neste caso, para garantir que os melhores caminhos possam ser expandidos na ordem correta, o
algoritmo faz uso de uma fila de prioridade (PriorityQueue) para armazenar os nodos que esto ordenados na fila
de acordo com o seu custo estimado (a sua distncia estimada) at o n objetivo, como pode ser visto na linha 2
da Figura 1. Na primeira chamada do mtodo, a fila de prioridade possui apenas o nodo inicial (origem) que foi
inserido na linha 3. Isso garante que a condio imposta na linha 4 seja verdadeira e, dessa maneira, o lao seja
executado. Na linha 5, um nodo removido da fila de prioridade (sempre o primeiro) para na linha 6 verificar se
aquele nodo o objetivo (destino) ou no. Se o estado do n for o objetivo desejado, o algoritmo retorna o
resultado; caso contrrio, continua a execuo na linha 7, inserindo na fila de prioridade todos os possveis
4

Fronteira o conjunto de ns sucessores que ainda no foi explorado (ainda no se testou se era o estado soluo).

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 43

sucessores (nodos que podem ser atingidos pelo nodo atual), de forma ordenada de acordo com a heurstica, e
volta para o lao da linha 4. Esse processo repetido at que o objetivo seja alcanado ou a fila de prioridade
esteja vazia. Neste ltimo caso, o problema no tem soluo, ou seja, no possvel definir um caminho possvel
dados o estado inicial e o objetivo.

Figura 1. Implementao genrica do algoritmo A* [8]

Google Maps

O Google Maps um servio de pesquisa e imagens de satlite da Terra gratuito na Web, fornecido pela
empresa Google. O servio do Google Maps oferece vrios tipos de mapas, desde os mais simples, com nomes
de ruas, rodovias, empresas, pontos tursticos, at complexos, animados ou no, com possibilidades de traar
rotas com origem e destino, informaes sobre quilometragem, entre outros. Este servio pode ser utilizado
diretamente no endereo http://maps.google.com.br.
Uma outra opo bastante til disponvel no Google Maps a possibilidade de consultar rotas informando
apenas a origem e o destino. A ferramenta oferece um detalhamento tanto visual quanto descritivo das ruas que o
usurio ter de percorrer para chegar ao destino. Para fazer uso desta opo basta utilizar o link Como chegar
disponvel na tela.
Atravs de uma API JavaScript criada pela Google possvel embutir esses mapas em pginas Web
particulares. Esta API, que oferece uma integrao com AJAX, toda documentada, possui diversos exemplos e
est disponvel em http://code.google.com/apis/maps/documentation.
Para realizar a insero dos mapas nas pginas Web, primeiramente deve ser realizada a importao da
biblioteca, que nada mais do que uma referncia ao endereo da API do Google. Neste momento tambm deve
ser informada uma chave individual que vinculada a uma conta do Google.
Cada elemento do mapa na API uma espcie de classe na orientao a objetos, onde podem ser
instanciados, modificados, habilitados ou desabilitados e assim por diante, por meio de construtores,
propriedades e mtodos. Pode-se, por exemplo, habilitar ou no o zoom nos mapas, habilitar ou no as opes de
visualizao dos mapas por satlite ou terreno, criar cones prprios em substituio aos cones padres, entre
outros.
No sistema proposto, foram utilizadas as opes de traar trajetrias que ficam em destaque no mapa,
caixas de texto que demarcam pontos importantes do percurso, opes de navegao no mapa e zoom, alm das
opes de visualizao por mapa, satlite ou hbrido.

Trabalhos Relacionados

O trabalho desenvolvido por Tarik Attar [9] apresenta basicamente uma comparao entre os algoritmos
A* e o Ant Colony Optimisation com os resultados gerados pela API do Google Maps para problemas
envolvendo roteamento. Para isso, foi desenvolvido um sistema que procura investigar algoritmos de rotas
dentro do contexto web.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 44

Para o desenvolvimento deste sistema Web foram utilizadas tecnologias como a Personal Home Page
(PHP), como linguagem de programao; o Mysql [10], como gerenciador de banco de dados, e a Geography
Markup Language (GML), como linguagem para apresentao de informao de objetos geogrficos bsicos.
Embora o trabalho de Attar e o trabalho proposto utilizem ferramentas e tecnologias semelhantes, os
objetivos propostos por ambos so diferentes. O presente trabalho faz uso do algoritmo A* para a construo de
um sistema Web, com o objetivo de indicar o menor nmero de nibus possvel a usurios de transporte pblico,
utilizando o Google Maps como ferramenta visual para exibio das trajetrias. Por outro lado, o trabalho
realizado por Tarik Attar utiliza o algoritmo A* em conjunto com o algoritmo Ant Colony Optimisation a fim de
comparar os resultados obtidos com o Google Maps na definio de rotas de carro. Alm disso, a modelagem
utilizada no presente trabalho apresenta-se mais complexa em razo da necessidade de considerar nibus, ruas,
paradas e direo dos nibus. Por fim, Tarik Attar considera como heurstica no algoritmo A* apenas a distncia
linear, ao passo que a presente proposta utiliza tambm a distncia manhattan para fins de comparao.
O Google Transit [11] o novo sistema Web criado pela empresa Google, que tem por finalidade
principal definir rotas atravs de transporte pblico. Alm disso, permite a localizao de paradas de nibus e a
consulta de informaes sobre estaes de trem e horrios. A cobertura do sistema ainda restrita a alguns
pases, como Estados Unidos, Canad, Japo, Taiwan, Austrlia, ustria, Frana, Itlia, Polnia, Rssia e Sua.
No Brasil, o servio encontra-se em funcionamento apenas para as cidades de So Paulo e Belo Horizonte.
Embora o Google Transit e o trabalho proposto possuam objetivos semelhantes, no foi possvel
comparar tecnicamente os dois trabalhos, pois no foram encontrados artigos que pudessem fornecer
informaes tcnicas do Google Transit. Em relao aos servios prestados, o Google Transit possui algumas
funcionalidades adicionais, tais como mostrar o valor total que deve ser pago para o trajeto, horrios dos
transportes, assim como vrias opes de trajetos. Um ponto diferencial do trabalho proposto disponibilizar um
mdulo administrador para cadastro e gerenciamento de dados.
O site Hotstop.com (http://hotspot.com) oferece um servio muito semelhante ao oferecido pelo Google
Transit. Atravs deste possvel informar um endereo de origem e um endereo de destino e solicitar ao
sistema que exiba a trajetria. O sistema fornece tambm a possibilidade de exibio da trajetria para ser
percorrida de nibus, de txi, a p ou com as trs opes ao mesmo tempo. A cobertura deste sistema, entretanto,
restrita a apenas algumas cidades dos Estados Unidos.
Da mesma forma que o Google Transit, no foram encontrados artigos que descrevessem tecnicamente o
HotSpot.

Sistema Desenvolvido

O sistema desenvolvido formado por dois principais mdulos: o de administrador e o de usurio. O


mdulo de administrador permite o cadastro e atualizao de toda informao necessria para gerenciamento do
sistema: ruas, paradas, usurios, controles de acesso e nibus. J o mdulo do usurio contm a principal
funcionalidade do sistema: o sistema de consulta de trajetria de nibus.
Para realizar a pesquisa de trajetrias necessrio informar o nome da rua de origem e o nome da rua de
destino, sendo o nmero (na rua) de origem e destino opcionais (Figura 2). O usurio deve tambm informar a
heurstica a ser utilizada para calcular a distncia entre as paradas, que pode ser distncia manhattan ou distncia
euclidiana, conforme ser explicado na seo 5.2.1.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 45

Figura 2. Tela de pesquisa de trajetrias.

Figura 3. Tela de resultado da pesquisa de trajetrias


O resultado da pesquisa pode ser visto na Figura 3 por meio de uma tabela com duas colunas: Trajetrias
e Mapa. A primeira coluna desta tabela, com o ttulo Trajetria, refere-se ao resultado descritivo gerado pelo
sistema atravs do algoritmo de busca A*. Neste caso so gerados sempre dois tpicos: a origem e o destino.
Tanto na origem quanto no destino so apresentadas informaes sobre a rua, nmero, parada e o nibus que o
usurio deve utilizar. Um tpico adicional pode ser gerado quando houver necessidade de o usurio efetuar uma
troca de nibus durante o percurso chamado Troca de nibus. Neste tpico tambm so apresentadas
informaes sobre a rua, nmero e parada na qual o usurio deve desembarcar de um nibus e embarcar em
outro.
A segunda coluna desta tabela, com o ttulo Mapa, refere-se ao resultado visual gerado pelo sistema
atravs da API do Google Maps. Este mapa contm o trajeto completo que o usurio deve percorrer para ir da
origem para o destino.
5.1

Modelagem da Base de Dados

O primeiro passo para desenvolver este sistema foi realizar a modelagem da base de dados. Nesta etapa a
preocupao foi com as informaes que seriam necessrias armazenar no banco de dados para que o algoritmo

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 46

de busca conseguisse definir as trajetrias corretamente. Assim, a modelagem da base de dados em seu estado
final pode ser vista na Figura 4.
A tabela Ruas tem apenas um ID (inteiro e sequencial) e um nome e faz um relacionamento de um (1)
para (N) com a tabela de Paradas, que, por sua vez, tambm tem um ID (inteiro e sequencial), coordenadas de
latitude e longitude, que definem o ponto exato onde a parada est localizada, e o campo numeroRuaParada, que
identifica em que altura (nmero) esta parada est localizada na rua. Esse relacionamento representa que numa
determinada rua podem existir diversas paradas, mas uma parada est localizada em apenas uma rua. A tabela
Onibus tem apenas um ID (inteiro e sequencial) e um nome, que utilizado para identificar o nome da linha, e
faz um relacionamento de (N) para (N) com a tabela Paradas. Para representar um relacionamento deste tipo, foi
necessrio criar a tabela Onibus_Paradas. Este relacionamento representa que um nibus pode percorrer diversas
paradas e, ao mesmo tempo, uma mesma parada pode ser percorrida por diferentes nibus.

Figura 4. Estado final da modelagem da base de dados

5.2

Modelagem do Sistema

O segundo passo para desenvolver este sistema foi definir a modelagem das entidades atravs do
diagrama de classes disponvel na Unified Modeling Language (UML). O diagrama de classes do ponto de vista
de especificao composto pelas principais classes e mtodos do sistema, pode ser visualizado na Figura 5.
A classe TrajetoriaAction, atravs do mtodo pesquisar(), inicia o processo de pesquisa de trajetrias no
sistema, recebendo todos os dados informados pelo usurio na tela de pesquisa (rua de origem, nmero de
origem, rua de destino, nmero de destino e o mtodo heurstico). Os campos da tela foram mapeados e inseridos
na classe TrajetoriaBean. A classe TrajetoriaBO atravs do mtodo pesquisar() responsvel por validar todas as
regras de negcio (rua de origem no cadastrada, rua de destino no cadastrada, rua de origem no possui parada,
rua de destino no possui parada) antes de instanciar a classe Busca, mtodo busca(). Este mtodo cria um objeto
do tipo fila de prioridade (PriorityQueue) contendo os dados do endereo de origem atravs da classe Node, que
contm informaes principalmente sobre o nibus e a parada em questo. Somente depois de definidas as
origens e o destino que o mtodo Aestrela() 5 inicia efetivamente a definio de trajetrias; para isso, faz uso
dos mtodos da classe Problema para definir, por exemplo, os estados sucessores de um determinado nodo. O
mtodo Aestrela() tem como retorno um objeto da classe Node com toda a soluo do problema. Acessando este
objeto atravs de recurso possvel gerar uma lista que contm todos os pontos que compem a trajetria.

Quando o autor se referenciar ao mtodo de busca implementado, utilizar como nomenclatura o Aestrela,
enquanto a referncia ao algoritmo original ser o A*.
Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 47

Figura 5. Diagrama de classes do sistema web

5.3

Definindo a Trajetria de nibus


Foi necessrio definir, inicialmente, os componentes do problema.
- Estado inicial: parada mais prxima na rua e numerao onde o usurio se encontra inicialmente (a
origem do trajeto);
- Estado final (objetivo): parada mais prxima na rua e numerao aproximada onde o usurio deseja
chegar (o destino do trajeto);
- Aes: se mover para parada prxima em uma linha de nibus;
- Heurstica: distncia linear (geometria euclidiana) e a distncia manhattan (geometria pombalina).

A busca utiliza tanto a distncia linear como a distncia manhattan como funo heurstica entre a parada
candidata e a parada destino, de acordo com a opo selecionada pelo usurio na interface do sistema. A
distncia linear foi escolhida no s por se tratar da menor distncia entre dois pontos como pela preocupao do
sistema em oferecer ao usurio o menor caminho e o menor nmero de linhas possveis. J a distncia manhattan
foi escolhida por motivos de comparao de resultados com a distncia linear, j que costuma oferecer a menor
distncia entre dois pontos quando se trata de uma malha urbana. Foram omitidos todos os demais aspectos do
mundo real, como trnsito, condies da estrada, tempo, entre outros.
Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 48

Definidos os componentes do sistema, foi necessrio adequar o algoritmo de busca A* para as condies
impostas pelo problema.
O algoritmo A*, na sua verso final, implementado neste trabalho pode ser visto na Figura 6 atravs do
mtodo Aestrela(). No texto usaremos Aestrela para se referir verso modificada para o trabalho do algoritmo
original A*.
Antes de invocar o mtodo Aestrela() necessrio criar uma fila de prioridade. A fila de prioridade na
verso modificada do A* definida para o trabalho no possui apenas um estado inicial como a definio genrica
do algoritmo A*. Ela possui a mesma quantidade de estados iniciais do que a quantidade de nibus que cruzam a
parada de origem. Isso ocorre porque os estados (nodos) neste caso representam a relao de um nibus com
uma parada, ou seja, quantos nibus diferentes cruzam aquela parada. A definio da primeira parada localizada
na rua de origem que ser utilizada na busca ocorre pela subtrao do nmero informado pelo usurio na
interface e do nmero de paradas existentes naquela rua. A parada que possuir a menor diferena em relao s
demais ser a parada escolhida. Neste momento inicial, os estados iniciais (nodos) so inseridos na fila de
prioridade, o que garante que o algoritmo no ir recomendar dois ou mais nibus quando poderia recomendar
apenas um, evitando, assim, trocas desnecessrias ao usurio.

Figura 6. Implementao do algoritmo A* para o trabalho


A definio da parada de destino (objetivo) ocorre da mesma forma que a parada de origem, pois ambas
so definidas pelo critrio de proximidade, isto , o sistema identifica a parada mais prxima na mesma rua que o
usurio informou na interface do sistema. Alm da fila de prioridade e do objetivo, o mtodo Aestrela() recebe a
informao sobre qual mtodo heurstico utilizar, de acordo com a seleo do usurio na interface do sistema.
Apesar da particularidade imposta pelo problema de possuir diversos estados iniciais, o mtodo Aestrela()
propriamente dito obedece definio genrica do algoritmo A*. Todavia, cabe definir detalhes sobre o mtodo
que obtm os sucessores (getSucessors()) de um determinado estado (Figura 7) (ver Figura 7). Este mtodo
responsvel por estabelecer quem so os estados possveis de serem alcanados atravs do estado atual. Para
isso, primeiramente devem ser pesquisados quais so os nibus que cruzam a parada atual. Para cada nibus
retornado, devem ser buscadas as prximas paradas a partir da parada atual. A prxima parada de um
determinado nibus pode ser obtida pela tabela onibusparadas, coluna ordemParada. A relao de cada nibus
com a sua prxima parada e as informaes sobre custo do caminho, profundidade e heurstica so armazenadas
numa lista (vetor), que representa, assim, os sucessores possveis do nodo atual. Da mesma forma que na

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 49

definio do algoritmo A*, o mtodo getSucessors() obtm os sucessores do estado atual para poder inserir na
fronteira. A Figura 7 ilustra a implementao deste mtodo no sistema.

Figura 7. Implementao do mtodo getSucessors()

Figura 8. Implementao da classe Node

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 50

Por ser completo, o algoritmo A* sempre acha uma soluo caso exista e, dessa forma, retorna ao final
um nodo (Figura 8), que possui toda a soluo do problema. Acessando este nodo atravs de recurso, criada
uma lista com todo o trajeto que o usurio ir percorrer, com informaes detalhadas das paradas e nibus, desde
a origem at o destino.
5.3.1

Frmulas Utilizadas na Funo Heurstica

O algoritmo realiza o clculo da distncia de forma automtica por meio das informaes de latitude e
longitude da parada candidata e a parada destino. Para isso, foram criadas duas funes no sistema que calculam
a distncia entre dois pontos na terra, uma de acordo com a distncia linear, ou tambm chamada euclidiana, e
outra de acordo com a distncia manhattan. Essas duas formas de clculo de distncias entre os dois pontos so
implementadas buscando comparar os resultados obtidos, j que em algumas situaes, como, por exemplo, em
problemas envolvendo rotas, podemos obter grandes distores de resultado de acordo com a heurstica
utilizada, que deve ser sempre admissvel, ou seja, nunca superestimar o custo real. Ambas as funes recebem
como parmetros duas latitudes e duas longitudes (das paradas) e retornam a distncia em quilmetros entre os
dois pontos. Os mtodos finais relativos ao clculo das distncias linear e manhattan podem ser vistos na Figura
9, respectivamente.

Figura 9. Distncia entre dois pontos conforme os dois mtodos considerados


O mtodo de clculo da distncia linear baseia-se na trigonometria esfrica [12] para definir a distncia
entre dois pontos na superfcie terrestre a partir de suas latitudes e longitudes. Para este clculo usa-se a frmula
da lei esfrica dos cossenos definida em (1), onde distance ser a distncia final em quilmetros (km) entre os
dois pontos, lat1 e long1 representam a latitude e longitude em radianos do 1 ponto, e lat2 e long2 representam
a latitude e longitude em radianos do 2 ponto. R corresponde ao raio da terra que equivale aproximadamente a
6.371 km e acos, sin e cos representam, respectivamente, as funes trigonomtricas arco-cosseno, seno e
cosseno.
distance = acos(sin(lat1).sin(lat2) + cos(lat1).cos(lat2).cos(long2long1)).R

(1)

O mtodo de clculo da distncia manhattan baseia-se na frmula matemtica visualizada em (2).


|x1-x2|+|y1-y2|

(2)

Para aplicar a frmula necessrio converter as latitudes e longitudes de graus para quilmetros [11]. As
latitudes so convertidas simplesmente multiplicando o seu valor em graus por 111.111 quilmetros (pois 1 grau
corresponde a 111.111 quilmetros). As longitudes so convertidas multiplicando-se o seu valor em graus
tambm por 111.111 quilmetros e, alm disso, multiplicando este resultado pelo cosseno da latitude (visto que
este valor pode sofrer uma variao de 1% para menos quanto mais prximo da linha do Equador, ou para mais
quanto mais prximo dos polos em razo do achatamento terrestre). Aps a obteno dos valores das latitudes e
longitudes dos pontos em quilmetros, basta aplicar a frmula em (2) para obtermos a distncia manhattan entre

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 51

os dois pontos em quilmetros, onde x1 e x2 correspondem s longitudes convertidas para km dos pontos e y1 e
y2 representam as suas latitudes convertidas.
5.4

Implementao do Sistema

O sistema Web utiliza o paradigma orientado a objetos atravs da linguagem de programao Java [13],
verso 1.5. Sendo este um sistema Web, utilizado a Java Server Pages (JSP) em conjunto com o framework
Model View Controller (MVC) Struts da Apache [14], verso 1.3.8. Para isso, o servidor de aplicao utilizado
o Tomcat, tambm da Apache, verso 5.0. O sistema gerenciador de banco de dados o Mysql na sua verso
para o sistema operacional Windows.

Avaliao do Sistema

Nesta seo so descritos os experimentos realizados com o objetivo de avaliar aspectos da usabilidade e
da corretude dos resultados apresentados pelo sistema Web. Para isso, duas metodologias foram aplicadas: testes
com usurios e testes unitrios.
Para realizao da avaliao utilizou-se uma base de dados sinttica com informaes reais de seis linhas
de nibus, 19 ruas e 68 paradas da cidade de So Leopoldo, no Rio Grande do Sul. Essas informaes foram
coletadas de maneira manual pelos prprios autores, ou seja, os percursos dos nibus foram percorridos de carro
para que as informaes fossem coletadas.
6.1

Testes com Usurios

A metodologia utilizada visa verificar a usabilidade do sistema. Usabilidade se refere capacidade de um


sistema ser compreendido, aprendido e atrativo ao utilizador [15].
Para a avaliao optou-se pela utilizao do sistema por uma amostra de usurios voluntrios,
constituindo-se desta maneira em uma amostra por convenincia. O perfil da amostra apresentado na seo
6.1.1.
Os testes com os usurios foram realizados em So Leopoldo (Rio Grande do Sul), nas dependncias da
Universidade do Vale do Rio dos Sinos, e em Canoas (Rio Grande do Sul), nas dependncias de uma empresa da
rea de transporte em Canoas entre 1 e 24 de outubro de 2008.
Para a realizao da avaliao, um e-mail foi enviado aos usurios contendo um documento com as
informaes sobre a avaliao, forma de acesso ao sistema e perguntas. Para participar da avaliao, o usurio
deveria ler as informaes no documento, acessar o sistema Web, responder s perguntas e enviar um e-mail
com o formulrio respondido para o endereo fornecido no documento.
6.1.1

Perfil da Amostra

A amostra utilizada nos testes com usurios constitui-se como no probabilstica e com um total de 17
indivduos. Dos usurios entrevistados 47% habitam So Leopoldo, 29% moram em Porto Alegre, 12% em
Canoas, 6% em Esteio e 6% em Montenegro (Figura 10). Os indivduos que no habitam a cidade de So
Leopoldo, a qual foi mapeada para essa avaliao, conhecem a cidade ou por estudar ou por trabalhar nela. Em
relao escolaridade, 41% dos indivduos possuem superior completo; a mesma proporo de indivduos est
cursando o ensino superior e o restante, 18%, possui ensino mdio completo. Ainda, 82% dos entrevistados so
do sexo masculino e 18% do sexo feminino.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 52

Figura 10. Perfil da amostra por cidade

6.1.2

Resultados
Os participantes da avaliao responderam s seguintes questes relativas ao sistema Web:

Q1) As telas do sistema so intuitivas para o preenchimento da informao necessria? (Sim/No) Voc
tem sugesto de melhorias?
Observou-se que um total de 17 participantes respondeu sim questo, ou seja, 100% dos usurios
consideram o sistema intuitivo.
Q2) As informaes de sada (mapa com trajeto, nome das ruas, linhas de nibus, etc.) apresentadas pelo
sistema so suficientes? (Sim/No) Contribua com suas sugestes.
Observou-se que um total de 14 participantes respondeu sim a esta questo, ou seja, 82,35% dos usurios
consideram que as informaes de sada so suficientes para localizao.
Q3) As alternativas de nibus apresentadas pelo sistema so aquelas que voc costuma utilizar?
(Sim/No) Caso afirmativo, elas so melhores ou piores? Contribua com suas sugestes (caso o sistema no
contemple o trajeto que voc costuma fazer, teste com o trajeto exemplo fornecido anteriormente).
Observou-se que cinco participantes responderam sim questo, ou seja, 29,41% dos usurios utilizam as
linhas que foram apresentadas pelo sistema.
Q4) Voc achou o sistema til e gostou de utiliz-lo? (Sim/No) Justifique.
Observou-se que um total de 16 participantes respondeu sim a esta questo, ou seja, 94,12% dos usurios
gostaram de utilizar o sistema.
Q5) Voc utilizaria o sistema se ele estivesse disponvel em um site web? (Sim/No) Justifique.
Observou-se que um total de 16 participantes respondeu sim a esta questo, ou seja, 94,12% dos usurios
utilizariam o sistema se estivesse disponvel na Web.
Considerando a opinio geral dos participantes desta avaliao, existem evidncias da aprovao do
sistema por parte dos usurios no que diz respeito usabilidade, utilidade e relevncia das informaes
apresentadas. Para a maioria dos usurios o sistema proposto seria utilizado. A Tabela 1 sintetiza o resultado
final da avaliao com os usurios.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 53

Tabela 1. Resultado final da avaliao com os usurios


Questes

Respostas
Sim %

No %

Total

Q1

100

100

Q2

82,35

17,65

100

Q3

29,41

70,59

100

Q4

94,12

5,88

100

Q5

94,12

5,88

100

A Tabela 2 ilustra alguns comentrios considerados relevantes realizados pelos usurios durante a
execuo da avaliao.
Levando em conta que a avaliao fora realizada com a participao de uma amostra selecionada de
usurios voluntrios e no probabilstica, cabe destacar que os resultados obtidos no podem ser generalizados,
ou seja, a leitura e interpretao devem ser focadas apenas na amostra.
Tabela 2. Comentrios relevantes dos usurios
No
Q1
Q2
Q3
Q4

Q5

6.2

Resp. Comentrios
Sim
"...tela de consulta bastante direta e intuitiva..."
Sim
"... as informaes so de timo aproveitamento..."
"...pontos marcados (A,B,C) no possuem legenda sendo difcil saber do que se trata. So paradas de
No
nibus?..."
Sim
"...uma das alternativas de nibus que utilizo para ir ao meu trabalho..."
No "...no utilizo nibus em So Leopoldo..."
"...maravilhoso. Pensando grande isto poderia ser de grande ajuda tanto a populao que utiliza nibus
Sim
diariamente quanto aqueles que desejam pegar um nibus em um lugar desconhecido."
No "...como no posso avaliar os resultados produzidos no posso afirmar de se usaria ou no..."
"... uma maneira muito fcil de conseguirmos informaes sobre lugares desconhecidos, agilizando a
Sim
locomoo..."
"...no momento atual no utilizaria pois tenho carro e 95% das vezes que saio de casa utilizo meu
No
veculo..."

Testes Unitrios

Os objetivos propostos com a utilizao desta metodologia visam verificar se o sistema apresenta
resultados adequados em funo das entradas fornecidas pelo usurio. Como o objetivo principal do sistema
traar rotas, o nico mdulo submetido aos testes unitrios foi o mdulo de pesquisa de trajetrias. Por meio
desses testes buscou-se tambm realizar a comparao dos dois critrios heursticos existentes no sistema: a
distncia linear e a distncia manhattan.
Para realizao dos testes optou-se por uma amostra pr-selecionada de oito ruas, que garantiram 14
diferentes entradas no sistema, de maneira que pelo menos um teste fosse realizado considerando os seguintes
cenrios: Rua de origem no cadastrada; Rua de destino no cadastrada; Rua de origem no possui parada; Rua
de destino no possui parada; Trajetria no pode ser definida, pois no h nibus cadastrados que faam o
percurso; Trajetria pode ser definida.
Esses cenrios procuraram verificar a consistncia do sistema. Observou-se que em todas as situaes o
sistema apresentou um comportamento correto, ou seja, notificava o usurio que no era possvel fornecer a
trajetria em virtude da informao insuficiente ou ele fornecia uma trajetria correspondente.
Para a validao do ltimo cenrio (Trajetria pode ser definida), oito pesquisas foram realizadas no
total, utilizando como heurstica a distncia linear e a distncia manhattan. No foram encontradas diferenas
significativas em relao s heursticas utilizadas. Observou-se que, em alguns poucos casos, a distncia
Manhatan leva a um pior desempenho do sistema, ao contrrio do que se esperava. Acredita-se que isso se deve
ao fato de a malha urbana de So Leopoldo no ter um formato predominantemente quadricular.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 54

Considerando os cenrios de teste identificados e tambm a amostra de ruas utilizada para a execuo
dos testes unitrios, existem evidncias do funcionamento adequado do sistema no que diz respeito ao mdulo de
pesquisa de trajetrias.
Levando em conta que os testes foram realizados com uma amostra de ruas selecionada por
convenincia, importante salientar que os resultados obtidos no podem ser generalizados, ou seja, a leitura e
interpretao devem ser focadas apenas na amostra.
Alm disso, o fato de os resultados apresentados entre a distncia linear e a distncia manhattan serem
os mesmos tambm no pode ser conclusivo ou generalizado. Outros experimentos se fazem necessrios quando
a base de dados for complementada, pois o nmero de ruas e paradas cadastradas mostrou-se pequeno para
chegar a uma concluso mais precisa.

Concluses e trabalhos futuros

Inspirado no crescimento dos sistemas destinados Web e tambm na prestao de servios, o presente
trabalho props um sistema Web que pudesse auxiliar efetivamente usurios de transporte coletivo atravs da
consulta e visualizao das trajetrias de nibus.
O sistema Web construdo representa a primeira implementao referente ao seu desenvolvimento. Para
que seja dado como um produto comercial, alguns aprimoramentos devem ser realizados e algumas limitaes
devem ser contornadas:
Trajetos percorridos a p: atualmente o sistema pesquisa trajetos apenas de nibus, isto , no esto
sendo contemplados pequenos deslocamentos a p por parte do usurio para ir de uma parada a outra para tomar
outro nibus. Nestas situaes o sistema retorna uma mensagem de erro informando que no foi possvel definir
uma rota.
Limitao de 25 pontos na GOOGLE MAPS API: a limitao de 25 pontos (paradas) imposta pela
Google Maps API praticamente inviabiliza a utilizao dos mapas para o propsito deste trabalho, pois isto faz
com a trajetria visual apresentada esteja limitada a 25 paradas, mesmo que o sistema esteja hoje preparado para
recomendar um nmero bem maior do que este. Uma opo para contornar este problema poderia ser pesquisar e
utilizar outra API semelhante, como, por exemplo, a Yahoo Maps API (http://developer.yahoo.com/maps/) ou o
Live Search Maps (http://dev.live.com/blogs/devlive/archive/2008/08/06/391.aspx) que porventura no tenham a
mesma limitao.
Pesquisa de ruas: a forma de pesquisa e exibio das ruas que esto cadastradas pode ser melhorada de
maneira que oferea ao usurio a possibilidade de saber o nome correto das ruas ou as ruas cadastradas para
realizao da pesquisa. Atualmente, o sistema acusa erro de rua no cadastrada caso o usurio no informe
exatamente o nome da rua.
Tempo de percurso: uma informao bastante til que poderia ser acrescentada, mas que hoje no existe,
o tempo total aproximado do percurso.
Horrios dos nibus: outra informao que poderia ser bastante til seria a informao sobre os horrios
dos nibus. Caso no seja possvel saber exatamente o horrio em que os nibus cruzam as paradas, pelo menos
a informao do horrio em que os nibus saem da garagem seria de grande utilidade.
Interface amigvel para dispositivos mveis: pretende-se desenvolver uma interface de acesso ao
sistema para dispositivos mveis que permita ao usurio acessar o sistema em qualquer lugar.
Estes e outros aprimoramentos sero desenvolvidos em uma dissertao de mestrado que estender o
sistema proposto.

Agradecimentos
Os autores agradecem ao professor Dr. Leonardo Chiwiacowsky pelo auxlio nos clculos baseados em
trigonometria esfrica.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 55

Referncias
[1] LEVY, P. Collective Intelligence: Mankinds Emerging World in Ciberspace (1st ed.). New York: Basic
Books, 1997.
[2] TELELISTAS. TeleListas.net: Lista Telefnica
<http://www.telelistas.net/>. Acesso em: 4 mar. 2008.

102

online

Brasil.

Disponvel

em:

[3] CORREIOS. Correios: encomendas, rastreamento, telegramas, cep, cartas, selos, agncias e mais. Disponvel
em: <http://www.correios.com.br/>. Acesso em: 4 mar. 2008.
[4] GOOGLE. Google. Disponvel em: <http://www.google.com>. Acesso em: 5 mar. 2008.
[5] GOOGLE MAPS. Google Maps. Disponvel em: <http://maps.google.com.br/>. Acesso em: 28 fev. 2008.
[6] GOOGLE
MAPS
API.
Google
Maps
API
<http://code.google.com/apis/maps/>. Acesso em: 1 jul. 2008.

Google

[7] EPTC.
EPTC:
Empresa
Pblica
de
Transporte
e
<http://www2.portoalegre.rs.gov.br/eptc/>. Acesso em: 28 fev 2008.

Code.

Disponvel

em:

Circulao.

Disponvel

em:

[8] RUSSEL, S. & NORVIG, P. Inteligncia artificial: uma abordagem moderna (3rd ed.). Campus, 2004.
[9] ATTAR, T. An investigation on routing algorithms web-based applications. Master, Napier University.
Disponvel em: <http://www.tarikattar.com/blog/wp-content/uploads/2008/05/tarikattardissertation.pdf>.
Acesso em: 7 mai. 2009.
[10] MYSQL. Mysql. Disponvel em: <http://dev.mysql.com/>. Acesso em: 7 jul. 2008.
[11]
GOOGLE.
TRANSIT.
Google
Transit.
Google
<http://www.google.com.br/transit>. Acesso em: 7 maio 2009.

Transit.

Disponvel

em:

[12] AYRES JNIOR, F. Trigonometria: plana e esfrica. So Paulo: McGraw-Hill, 1976.


[13] SUN. Sun Microsystems. Disponvel em: <http://www.sun.com>. Acesso em: 27 maio 2008.
[14] APACHE. Apache: Apache Software Foundation. Disponvel em: <http://www.apache.org/>. Acesso em:
27 mai. 2008.
[15] NIELSEN, J. Usability Engineering. San Francisco: Morgan Kaufmann, 1993.

Revista Brasileira de Computao Aplicada (ISSN 2176-6649), Passo Fundo, v.2, n. 1, p. 41-56, mar. 2010 56

Você também pode gostar