TCC_2010_2_Fernando_Figueiredo_Torres

Pontif´ıcia Universidade Católica de Minas Gerais
Bacharelado em Sistemas de Informa¸cão
Trabalho de Conclusão de Curso
Carro Cheio: Um Aplicativo Para
Forma¸cão de Caronas em Redes Sociais
Como Forma de Favorecer a Mobilidade
Urbana em Belo Horizonte
Fernando de Figueiredo Torres
Belo Horizonte
Dezembro 2010

Fernando de Figueiredo Torres
Carro Cheio: Um Aplicativo Para
Forma¸cão de Caronas em Redes Sociais
Como Forma de Favorecer a Mobilidade
Urbana em Belo Horizonte
Trabalho apresentado ao Instituto de
Ciências Exatas e Informática da Pontif´ıcia
Universidade Católica de Minas Gerais como
requisito parcial a obten¸cão da gradua¸cão
em Bacharelado em Sistemas de Informa¸cão
Orientador:
Fabio Tirelo
Instituto de Ciências Exatas e Informática
Belo Horizonte
Dezembro 2010

Trabalho de Conclusão de Curso sob o t´ıtulo “Carro Cheio: Um Aplicativo Para Forma¸cão
de Caronas em Redes Sociais Como Forma de Favorecer a Mobilidade Urbana em Belo
Horizonte”, do Instituto de Ciências Exatas e Informática da Pontif´ıcia Universidade
Católica de Minas Gerais, Belo Horizonte, dezembro 2010.
Prof. Fabio Tirelo
Orientador
Prof. Paulo César do Amaral Pereira
Examinador
Prof. Zenilton Kleber Gon¸calves do Patroc´ınio
Júnior
Examinador

Acho que nossas chances não parecem boas hoje, mas a única forma de falhar, para
mim, é apenas não tentando.
Gary Kasparov

Agradecimentos
A realiza¸cão deste trabalho só foi poss´ıvel devido à ajuda que tive, direta e indireta-
mente, de várias pessoas, ao longo dessa jornada.
No in´ıcio, tudo come¸cou com uma idéia, enviei para o professor Fabio Tirelo, que
prontamente se interessou em orientar o meu trabalho, e ao qual agrade¸co pela orienta¸cão,
incentivo, e comprometimento demonstrado em nossas reuniões.
Durante as centenas de horas investidas nesta pesquisa, contei com a excepcional ajuda
do Google, que me ofereceu condi¸cões de encontrar todas as informa¸cões que precisei,
além de disponibilizar o uso de sua API do Google Maps, para toda a comunidade de
desenvolvedores ao redor do Mundo.
Muitos dos problemas que encontrei durante o aprendizado da API do Google Maps,
só foram solucionados gra¸cas à boa vontade de Mark Williams e Bill Chadwick, que um
dia disponibilizaram seus experimentos na Internet, servindo de ótimos tutoriais.
Agrade¸co também àqueles que, por vezes, me proporcionaram momentos de distra¸cão,
para a renova¸cão das idéias. Aos meus amigos, obrigado por me tirarem da frente do
computador em alguns (poucos, é verdade) sábados.

Resumo
A mobilidade urbana é uma importante área de estudos da administra¸cão pública
cujo papel é proporcionar o irrestrito deslocamento de pessoas e ve´ıculos no espa¸co da
cidade. A necessidade de pol´ıticas de mobilidade urbana aumenta à medida que aumenta,
também, a disputa pelo espa¸co urbano, decorrente do crescimento anual da frota de
ve´ıculos. Entretanto, é fundamental a iniciativa e o comprometimento da popula¸cão para o
sucesso desse processo. Diante disso, este trabalho estuda a prática do compartilhamento
do carro, ou as “caronas”, com o objetivo de contribuir para a diminui¸cão de ve´ıculos
circulando nas vias da cidade, bem como a diminui¸cão de pessoas utilizando o transporte
coletivo. A pesquisa realizada se concentrou em dados da cidade de Belo Horizonte,
Minas Gerais. Para atingir os objetivos deste trabalho, foi desenvolvido o “Carro Cheio”
– um aplicativo para a rede social Orkut – que possibilita aos seus usuários divulgarem
e encontrarem vagas de carona. Através do Carro Cheio, os usuários do Orkut podem
combinar caronas com pessoas com as quais já mantém contato, sendo uma op¸cão mais
segura em rela¸cão aos demais sites de carona. Ainda, o Carro Cheio busca rotas com
proximidade de coordenadas geográficas e utiliza informa¸cões sobre as linhas de ônibus
de Belo Horizonte em suas respostas.
Palavras-chave: Redes sociais. Mobilidade urbana. API Opensocial. API Google Maps.

Lista de Figuras
1 Composi¸cão da frota em BH, em dez. 2009 . . . . . . . . . . . . . . . . p. 12
2 Queda na velocidade do transporte público em BH, entre 2002 e 2006 . p. 13
3 Crescimento da frota em BH, entre 2002 e 2006 . . . . . . . . . . . . . p. 13
4 Presen¸ca de usuários brasileiros nas principais redes sociais (em milhões) p. 19
5 Modelo e fluxo de dados de um aplicativo social . . . . . . . . . . . . . p. 20
6 Arquitetura da aplica¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
7 Diagrama do modelo de dados do aplicativo . . . . . . . . . . . . . . . p. 24
8 Página da BHTRANS com a rela¸cão das linhas de ônibus de Belo Horizonte p. 25
9 Página de itinerários no site da BHTRANS . . . . . . . . . . . . . . . . p. 26
10 Trecho do XML de resposta do servi¸co de geocodifica¸cão do Google . . p. 26
11 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
12 Página de registro no Orkut sandbox . . . . . . . . . . . . . . . . . . . p. 28
13 Conteúdo inicial do descritor do aplicativo . . . . . . . . . . . . . . . . p. 28
14 Página de submissão do aplicativo . . . . . . . . . . . . . . . . . . . . . p. 29
15 Página de confirma¸cão dos dados . . . . . . . . . . . . . . . . . . . . . p. 29
16 Processo de desenvolvimento do aplicativo . . . . . . . . . . . . . . . . p. 29
17 Tela do aplicativo: oferecer carona . . . . . . . . . . . . . . . . . . . . . p. 30
18 Tela do aplicativo: desambigua¸cão de locais . . . . . . . . . . . . . . . p. 31
19 Tela do aplicativo: desenho da rota do motorista . . . . . . . . . . . . . p. 32
20 Transi¸cão de estados para a modifica¸cão da rota . . . . . . . . . . . . . p. 33
21 Tela do aplicativo: salvar uma nova rota . . . . . . . . . . . . . . . . . p. 33
22 Registros na tabela rota passos . . . . . . . . . . . . . . . . . . . . . p. 34

23 Representa¸cão gráfica dos dados de uma rota . . . . . . . . . . . . . . . p. 34
24 Tela do aplicativo: janela de busca de rotas . . . . . . . . . . . . . . . p. 35
25 Fluxo de dados durante a busca por rotas . . . . . . . . . . . . . . . . p. 35
26 Fun¸cão de cálculo da distância linear entre dois pontos na Terra . . . . p. 36
27 Heur´ıstica de busca: cenário hipotético . . . . . . . . . . . . . . . . . . p. 36
28 Heur´ıstica de busca: primeira itera¸cão . . . . . . . . . . . . . . . . . . p. 37
29 Heur´ıstica de busca: segunda itera¸cão . . . . . . . . . . . . . . . . . . . p. 37
30 Heur´ıstica de busca: busca por ônibus . . . . . . . . . . . . . . . . . . . p. 38
31 Heur´ıstica de busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
32 Tela do aplicativo: enviar pedido de carona . . . . . . . . . . . . . . . . p. 39
33 Tela do aplicativo: visualizar, aceitar e recusar pedidos . . . . . . . . . p. 39
34 Tela do aplicativo: avaliar usuário . . . . . . . . . . . . . . . . . . . . . p. 40
35 Rota utilizada nos testes testes . . . . . . . . . . . . . . . . . . . . . . p. 41
36 Tela do aplicativo: resultado do Teste 3 . . . . . . . . . . . . . . . . . . p. 42
37 Tela do aplicativo: resultado do Teste 4 . . . . . . . . . . . . . . . . . . p. 43

Lista de Tabelas
1 Descri¸cão das tabelas do modelo de dados . . . . . . . . . . . . . . . . p. 24
2 Visão geral dos casos de uso do aplicativo . . . . . . . . . . . . . . . . p. 27
3 Parâmetros de buscas por caronas . . . . . . . . . . . . . . . . . . . . . p. 41

Lista de Abreviaturas
AJAX Asynchronous Javascript + XML.
API Application Programming Interface.
CSS Cascading Style Sheet.
DENATRAN Departamento Nacional de Trˆansito.
FTP File Transfer Protocol.
HTML Hypertext Markup Language.
HTTP Hypertext Transfer Protocol.
IBGE Instituto Brasileiro de Geograﬁa e Estat´ıstica.
PIB Produto Interno Bruto.
XML Extensible Markup Language.

Sumário
1 Introdu¸cão p. 12
1.1 Motiva¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15
2 Revisão da Literatura p. 17
2.1 Mobilidade Urbana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
2.2 Redes Sociais On-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.3 API Opensocial 0.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2.4 JQuery 1.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
2.5 API Javascript Google Maps 2.0 . . . . . . . . . . . . . . . . . . . . . . p. 21
2.6 Plataforma LAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
3 Metodologia p. 23
3.1 Escolha das Tecnologias Apropriadas . . . . . . . . . . . . . . . . . . . p. 23
3.2 Desenho do Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . p. 24
3.3 Obten¸cão dos Itinerários das Linhas de Ônibus de BH . . . . . . . . . . p. 24
3.4 Implementa¸cão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3.4.1 Orkut sandbox . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3.4.2 Cadastrar rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.4.3 Buscar rotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.4.3.1 Fluxo de dados da busca por rotas . . . . . . . . . . . p. 35

3.4.3.2 Cálculo da distância linear entre dois pontos na Terra . p. 36
3.4.3.3 Heur´ıstica de busca por rotas . . . . . . . . . . . . . . p. 36
3.4.4 Demais Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . p. 38
4 Resultados p. 41
4.1 Prepara¸cão do Ambiente de Testes . . . . . . . . . . . . . . . . . . . . p. 41
4.2 Avalia¸cão dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
5 Conclusão p. 44
Referências p. 45

12
1 Introdu¸cão
A cidade de Belo Horizonte (BH), fundada em 1897, foi a primeira capital planejada
do pa´ıs, inicialmente projetada para 200 mil habitantes. Mais de um século após a sua
funda¸cão, a capital atingiu uma popula¸cão aproximada de 2,5 milhões de habitantes,
tendo o 4o. maior PIB do Brasil (IBGE, 2007).
Em rela¸cão ao trânsito, BH terminou o ano de 2009 com uma frota de 1,2 milhões de
ve´ıculos, composta principalmente por automóveis (82%) e motocicletas (13%), conforme
mostrado na Figura 1. Esse número revela uma propor¸cão aproximada de um ve´ıculo
para cada dois habitantes. Para se fazer uma compara¸cão, a cidade de São Paulo, cujos
problemas de trânsito são constantemente citados na m´ıdia, possui a mesma propor¸cão
(IBGE, 2007; DENATRAN, 2010).
Figura 1: Composi¸cão da frota em BH, em dez. 2009
Fonte: DENATRAN, 2010
Com a facilidade cada vez maior em se adquirir um ve´ıculo, mais pessoas têm trocado
o uso do transporte público pelo transporte particular. A princ´ıpio, podemos imaginar
que essa troca representa ganho na qualidade de vida desses cidadãos. Entretanto, uma
visão mais ampla mostra que essa taxa de aumento da frota, por ser muito mais alta
que a capacidade do Estado em criar infraestruturas que a suporte, traz consequências
negativas à qualidade da mobilidade urbana e ao meio ambiente.
Um estudo, feito pela Empresa de Transportes e Trânsito de Belo Horizonte (BH-

13
TRANS, 2008), analisou a velocidade média do transporte público nos horários de pico
da manhã e da tarde, em BH. Esse estudo mostra que entre 2002 e 2006 houve uma
queda da velocidade em 6% no pico da manhã, e em 4,9% no pico da tarde (Figura 2).
Considerando o mesmo per´ıodo, vê-se na Figura 3 o número acumulado de novos ve´ıculos
adicionados à frota na cidade por categoria. Uma análise das Figuras 2 e 3 produz fortes
ind´ıcios de que o crescimento da frota de automóveis tem grande responsabilidade na
degrada¸cão da qualidade do trânsito.
Figura 2: Queda na velocidade do transporte público em
BH, entre 2002 e 2006
Fonte: BHTRANS, 2008
Figura 3: Crescimento da frota em BH, entre 2002 e 2006
Fonte: DENATRAN, 2010
O aumento no consumo de automóveis não se dá apenas pela sua utilidade como meio
de transporte. Na atualidade, o automóvel é considerado objeto de desejo e status social.
Ainda que os servi¸cos de transporte público sejam melhorados, fica dif´ıcil desestimular o
consumo e o uso do automóvel. Passa a ser necessário, então, estimular o uso consciente
do automóvel particular, transformando-no em um agente em prol da mobilidade urbana
sustentável.
O uso consciente do automóvel consiste em certas medidas que, se tomadas podem
colaborar para uma melhoria na qualidade do transporte e do meio ambiente de forma
geral. Essas medidas vão desde a escolha por ve´ıculos com combust´ıveis menos poluentes
até a mudan¸ca da visão individualista no uso do automóvel para uma visão coletiva. Nesse
sentido, este trabalho foca a prática da carona solidária.
Os impactos da carona solidária na mobilidade urbana tendem a ser muito positivos.
Um motorista que leve pessoas a pontos compreendidos em seu trajeto, pode ajudar
a diminuir o número de usuários do transporte público naquele dia. De forma análoga,
proprietários de automóveis poderiam se revezar para irem juntos ao trabalho, diminuindo
o número de automóveis nas ruas.
Apesar de todo o benef´ıcio da carona solidária, questões culturais e de seguran¸ca são
barreiras a serem vencidas. Em nossa sociedade, há receios associados à prática da carona;

14
por exemplo, é comum ensinar a crian¸cas que não se deve aceitar caronas de estranhos.
Considerando-se todo o cenário descrito, este trabalho estudou uma poss´ıvel solu¸cão
para o problema de se formar grupos de caronas, levando-se em conta as barreiras sociais e
culturais encontradas nesse processo. Além disso, foram analisadas as formas já utilizadas
para o mesmo propósito e suas limita¸cões. A solu¸cão proposta deve ser abrangente de
forma a alcan¸car o maior número de pessoas em um ambiente virtual (on-line). Ainda,
deve oferecer boas alternativas para as limita¸cões encontradas em outros mecanismos.
Para tanto, estudou-se o ambiente das redes sociais como ponto central da solu¸cão.
1.1 Motiva¸cão
Existem muitos fatores que dificultam a tarefa de encontrar e oferecer caronas. Por
meio da comunica¸cão verbal direta geram-se muitos ru´ıdos, pois é necessário abordar
todos os indiv´ıduos do grupo e questioná-los sobre sua inten¸cão em oferecer ou utilizar
caronas. Além disso, são necessárias algumas intera¸cões repetitivas entre as partes para
verificar questões de trajeto, paradas e vagas dispon´ıveis.
De outra forma, o uso de quadros de avisos em áreas de circula¸cão também apresenta
problemas. Sabe-se que as pessoas nem sempre lêem quadros de avisos, e nem sempre os
anúncios disponibilizam todas as informa¸cões que seriam necessárias. Também, manter o
quadro atualizado é trabalhoso.
Quando se opta por listas de discussão on-line, também surgem alguns problemas.
Conversas iniciadas na lista podem acabar em conversas externas e os membros da lista
podem não saber do estado atual de cada membro com rela¸cão às suas caronas. As
pessoas geralmente não recorrem ao histórico de listas de discussão antes de enviar uma
mensagem. Isso gera muitas mensagens repetitivas e, com isso, muitos usuários tendem a
abandonar a lista devido ao grande tráfego de e-mails em suas caixas postais.
Uma alternativa às abordagens tradicionais consiste no uso de sites de redes de caro-
nas (BIGOO, 2010; CARONEIROS, 2010). Esses mecanismos se mostram mais eficientes
do que as formas citadas anteriormente, porém obrigam o usuário a se cadastrar e utilizar
mais um site para um fim espec´ıfico. Além disso, pode ser que amigos que já se relacionem
em uma rede social, optem por entrar em sites de caronas diferentes. Considerando-se as
funcionalidades das redes de caronas dispon´ıveis atualmente, as formas como as buscas
são realizadas também podem não ser tão eficientes, pois encontram caronas baseadas
nas localidades de origem e destino, sem considerar outras informa¸cões como as coor-

15
denadas geográficas ao longo de toda a rota do motorista e potencial passageiro. Além
disso, não usam informa¸cões de transporte coletivo para sugerir respostas que possam ser
satisfatórias aos seus usuários.
Os problemas aqui levantados nos levam a propor uma solu¸cão alternativa, que se
beneficie das redes sociais já populares e amplamente utilizadas, agregando-lhes uma nova
funcionalidade. Com essa abordagem, espera-se manter os usuários em um ambiente a que
já estejam familiarizados, sem obrigá-los a migrar para um novo ambiente e constru´ırem
uma nova rede social.
1.2 Objetivos
O objetivo geral deste trabalho é criar um meio eficiente para que indiv´ıduos possam
combinar caronas no ambiente de uma rede social, por meio do desenvolvimento de um
aplicativo integrado a esse ambiente. A rede social escolhida, nesse caso, foi o Orkut.
Espera-se que os usuários do Orkut adicionem o aplicativo aos seus perfis e, a partir
disso, possam interagir com outros usuários que também possuam o aplicativo. Dessa
maneira, será poss´ıvel cadastrar viagens detalhando seus trajetos e pontos de parada.
Será poss´ıvel, também encontrar caronas com base em coordenadas geográficas, além de
poderem solicitar, aceitar ou recusar pedidos de carona. No caso de caronas realizadas,
os usuários poderão se avaliar, atribuindo opiniões com rela¸cão às suas experiências.
Deseja-se ainda, combinar ofertas de caronas com informa¸cões do transporte público
de BH. Com isso, quando não houver rotas que passem próximas ao passageiro, será
poss´ıvel sugerir viagens compostas por caronas e ônibus.
1.3 Justificativa
Podemos associar a prática de caronas à solidariedade e confian¸ca, praticadas na
maioria das vezes entre pessoas com hábitos semelhantes, tais como ir à mesma faculdade
ou à mesma região da cidade. Portanto, caronas têm um potencial maior de ocorrer entre
pessoas de um mesmo grupo social.
Com base nesta idéia, escolhemos a rede social Orkut como ambiente para a im-
planta¸cão do aplicativo de caronas, uma vez que nessa rede já estão formados la¸cos de
afinidade e confian¸ca entre seus usuários. Além disso, 72% dos brasileiros que usam redes

16
sociais (26 milhões de usuários) estão no Orkut (ÉPOCA, 2010), o que o torna um dos
três sites mais populares da Internet brasileira (ALEXA, 2010).
Outra justificativa para a abordagem escolhida é que ela pode se apresentar como uma
mudan¸ca de paradigma com rela¸cão aos sites de caronas existentes. Enquanto nas outras
solu¸cões “o usuário deve ir até aonde o aplicativo está”, nesta abordagem “o aplicativo
vai aonde o usuário já está”. Isso permite que o usuário utilize um novo recurso em um
ambiente que lhe é familiar.

17
2 Revisão da Literatura
2.1 Mobilidade Urbana
Segundo a BHTRANS (2008), mobilidade urbana é o conjunto de deslocamentos de
pessoas e bens, com base nos desejos e necessidades de acesso ao espa¸co urbano, por
meio da utiliza¸cão dos diversos modos de transporte. O conceito de “gerenciamento da
mobilidade” também é tratado por Rocha et al. (2006), como a busca de um equil´ıbrio
mais estável entre a oferta de infraestrutura de transportes e o atendimento adequado
da demanda por viagens (deslocamentos). Esse campo de estudos surgiu nos Estados
Unidos com a crise de energia de 1973, para mitigar problemas decorrentes da escassez
de derivados de petróleo (ROCHA et al., 2006 p. 4 apud BLACK, 2001).
O aumento populacional e o aumento da frota nas cidades causam uma disputa maior
pelos espa¸cos urbanos, que não crescem na mesma propor¸cão. A perda de tempo, a falta
de lugar para estacionar e a irrita¸cão que os congestionamentos causam são reflexos ne-
gativos do aumento da frota. Ainda, a polui¸cão causada pelos ve´ıculos também aumenta,
causando danos tanto ao meio ambiente quanto a saúde da popula¸cão.
Várias cidades no mundo estudam pol´ıticas e a¸cões para melhorias na qualidade de
vida da popula¸cão por meio de uma mobilidade urbana sustentável. A palavra sustentável
aqui, extende o conceito de mobilidade urbana considerando “[...] a realiza¸cão desses des-
locamentos sem comprometimento do meio ambiente, das áreas e das atividades urbanas,
além do próprio transporte” (BHTRANS, 2008).
Pode-se citar Londres, uma das cidades com plano de gerenciamento de mobilidade
mais difundido e consolidado, possuindo as seguintes estratégias: campanhas de conscien-
tiza¸cão sobre viagens; ciclismo e caminhada; pedágio urbano; ônibus e tramway (ônibus
elétrico) grátis para menores de 16 anos; dirija de outra maneira (drive another way) e
zonas de baixa emissão. Para o objetivo deste trabalho, destaca-se o compartilhamento do
carro (car polling), que é uma das medidas compreendidas na estratégia “dirija de outra

18
maneira” (ROCHA et al., 2006). Tal medida permite que dois ou mais usuários usufruam
do conforto de um mesmo automóvel reduzindo o congestionamento e a polui¸cão.
Recentemente, em São Paulo, foram realizadas campanhas educativas para incentivar
a “carona solidária”. Nessas a¸cões, realizadas pela Secretaria do Meio Ambiente, moto-
ristas que viajavam sozinhos recebiam a “multa legal”, uma interven¸cão lúdica feita por
monitores, atores e voluntários. O objetivo era fixar a idéia da importância de se usar o
ve´ıculo de forma mais consciente (GOVERNO DE SÃO PAULO, 2008).
Em Belo Horizonte, a Prefeitura Municipal e a BHTRANS realizam o projeto PlanMob-
BH (Plano de Mobilidade Urbana de Belo Horizonte). O PlanMob-BH faz parte do pro-
cesso de planejamento da mobilidade urbana de Belo Horizonte para 2020. O objetivo
do projeto é promover melhor qualidade de vida e desenvolvimento da cidade, susten-
tado nos princ´ıpios de: acessbilidade, seguran¸ca, eficiência, qualidade de vida, dinamismo
econômico, a¸cão integrada e inclusão social. Dentre as diretrizes que o projeto visa aten-
der, pode-se destacar: considerar o modo a pé como prioritário; garantir o deslocamento
das pessoas em um transporte coletivo de qualidade; democratizar o uso do sistema viário,
inclusive com medidas de restri¸cão do uso do automóvel, quando necessário; construir
pol´ıticas de estacionamento e distribui¸cão de mercadorias; estimular o uso de transporte
não motorizado, especialmente bicicletas; e por fim, garantir a todos, idependentemente
da capacidade de pagamento ou locomo¸cão, o direito de se deslocar e usufrir da cidade
com autonomia e seguran¸ca (PLANMOB-BH, 2010).
2.2 Redes Sociais On-line
Redes sociais on-line podem ser definidas como um servi¸co Web que permite in-
div´ıduos constru´ırem um perfil público ou semi-público dentro desses sistemas, articulados
a uma lista de outros usuários com os quais compartilham o mesmo ambiente e algumas
conexões, percorrendo suas listas de conexões e outras feitas por novos usuários dentro do
sistema (BOYD; ELLISON, 2005).
Uma em cada sete pessoas no planeta frequenta pelo menos uma rede social na In-
ternet. As comunidades formadas por sites como Orkut, Facebook e Twitter já alcan¸cam
quase a soma de 1 bilhão de usuários. Nesses ambientes virtuais, seus “habitantes” se
relacionam discutindo opiniões, compartilhando fotos, publicando anúncios, jogando, e
até mesmo procurando novos amigos. A Figura 4 traz um panorama da distribui¸cão
dos usuários brasileiros entre as principais redes sociais da atualidade, onde o Orkut com

19
26%, Twitter com 9,8% e Facebook com 9,6% aparecem como as três redes mais utilizadas
(ÉPOCA, 2010).
Figura 4: Presen¸ca de usuários brasileiros nas principais redes sociais (em milhões)
Fonte: ÉPOCA, 2010
Vários têm sido os trabalhos publicados com foco no estudo de redes sociais. Pesqui-
sadores de diversas áreas do conhecimento têm se interessado por entender a dinâmica
das redes de pessoas, mostrando a importância desse mecanismo de rela¸cões interpessoais
na vida moderna (BUYUKOKTEN et al. 2003; KUMAR et al. 2006).
Para os propósitos deste trabalho, o aspecto mais importante é observar a capacidade
das redes sociais em disseminar e transformar o acesso a informa¸cão, colaborando para que
os subgrupos de indiv´ıduos contidos nelas possam aumentar seu capital social. Utiliza-se
o sentido de capital social observado por Costa (2005):
Essa no¸cão poderia ser entendida como: a capacidade de intera¸cão dos
indiv´ıduos, seu potencial para interagir com os que estão a sua volta,
com seus parentes, amigos, colegas de trabalho, [...]. Capital social sig-
nificaria aqui a capacidade de os indiv´ıduos produzirem suas próprias
redes, suas comunidades pessoais (COSTA, 2005 p. 239 apud BURT,
2005; LIN, 2005; NARAYAN, 1999; PORTES, 1998; GROOTAERT,
1997; FUKUYAMA, 1996; PUTMAN, 1993; COLEMAN, 1990).
Finalizando, no mesmo trabalho de Costa (2005),
[...] uma comunidade virtual, quando convenientemente organizada,
representa uma importante riqueza em termos de conhecimento dis-
tribu´ıdo, de capacidade de a¸cão e de potência cooperativa (COSTA,
2005, p. 246 apud LÉVY, 2002).
Todas essas pondera¸cões a respeito das redes sociais certificam que são uma preciosa
ferramenta de media¸cão de comunica¸cão entre pessoas.

20
2.3 API Opensocial 0.8
A especifica¸cão Opensocial define uma API comum para o desenvolvimento de apli-
cativos sociais que podem funcionar em diversos sites (OPENSOCIAL, 2010).
Figura 5: Modelo e fluxo de dados de um aplicativo social
Fonte: OPENSOCIAL, 2010
Na Figura 5, vê-se o modelo de um aplicativo social e seus três componentes principais:
cliente, container e o servidor do aplicativo. O cliente é a representa¸cão do usuário
navegando no aplicativo. O container, por sua vez, é a própria rede social, nesse caso,
o Orkut. O papel do container é guardar o descritor do aplicativo (um arquivo XML) e
fornecer a capacidade de manipular seus “dados sociais”1
. Por fim, o servidor do aplicativo
é um servidor Web, que contém todos os arquivos do aplicativo, como imagens, arquivos
CSS, Javascript e outros. Nesse servidor também estão as páginas responsáveis por ler e
gravar informa¸cões no banco de dados do aplicativo.
O ponto central para se desenvolver um aplicativo social é entender como ocorre o
fluxo de dados entre seus componentes. Utilizando como base, ainda a Figura 5, tem-se
a seguinte sequência de opera¸cões:
1. O cliente (usuário) solicita ao container a visualiza¸cão de um aplicativo. Nesse
momento é carregado o descritor do aplicativo.
2. Através de protocolo HTTP via AJAX, o container envia “dados sociais” ao servidor
do aplicativo, como o código do usuário seguido de alguma opera¸cão que ele tenha
realizado, por exemplo “ofereceu uma carona de A até B”.
3. O servidor do aplicativo recebe os dados sociais, além dos dados de opera¸cão e
armazena essas informa¸cões em seu banco de dados, retornando para o container,
dados em forma de HTML, XML ou qualquer outra estrutura em formato texto.
4. O container recebe esses dados e entrega ao descritor do aplicativo, que renderiza
as atualiza¸cões na tela do aplicativo e exibe o resultado para o usuário.
1
Dados sobre perfis de usuários, lista de amigos, fotos e álbuns, atualiza¸cão de atividades na rede, etc.

21
Até a conclusão deste trabalho, o Orkut era um container homologado para a versão
0.8 da API Javascript Opensocial.
2.4 JQuery 1.2.2
JQuery é uma biblioteca Javascript, de uso gratuito, que reúne uma cole¸cão de fun¸cões
que permitem aos desenvolvedores escreverem códigos Javascript de maneira rápida, efi-
ciente e compat´ıvel com os principais modelos de navegadores (JQUERY, 2010).
Nessa biblioteca, o desenvolvedor encontra fun¸cões para realizar anima¸cões em ele-
mentos de uma página HTML; trabalhar de forma simplificada em intera¸cões com AJAX ;
manipular eventos; e várias outras utilidades.
Outro benef´ıcio, além de agilizar o desenvolvimento de aplica¸cões Web, é a capacidade
de utilizar extensões escritas e disponibilizadas por outros desenvolvedores. Através dessas
extensões, é poss´ıvel reutilizar solu¸cões que resolvam problemas recorrentes em uma t´ıpica
aplica¸cão Web, como valida¸cão de formulários, exibi¸cão de dicas de preenchimento de
campos, e muitos outros.
2.5 API Javascript Google Maps 2.0
A API Javascript Google Maps é disponibilizada de forma gratuita pelo Google aos
desenvolvedores que desejam incorporar o Google Maps em suas páginas.
Dentre os principais recursos fornecidos pela API pode-se destacar:
• Geocodifica¸cão: um servi¸co de consulta, no qual se informa um endere¸co e se recebe
como resposta informa¸cões detalhadas sobre tal endere¸co, inclu´ındo suas coordena-
das geográficas;
• Caminhos: desenho de linhas sobre o mapa, informando o melhor caminho, a pé
ou de automóvel, entre dois ou mais pontos. Além disso, os caminhos contêm
diversas informa¸cões úteis, como ruas percorridas, dire¸cões a serem seguidas, tempo
de viagem e distância;
• Visualiza¸cão: permite arrastar, ampliar ou reduzir o detalhamento do mapa;
• Representa¸cão: permite posicionar marcadores de localidades, abrir janelas de in-
forma¸cões em marcadores.

22
Outro ponto caracter´ıstico da API Google Maps é seu funcionamento baseado em
intera¸cões via AJAX entre a aplica¸cão do usuário e os servidores do Google, onde está
hospedada a API.
2.6 Plataforma LAMP
LAMP é uma sigla formada pelas letras iniciais das tecnologias Linux (sistema ope-
racional), Apache (servidor Web), MySQL (sistema gerenciador de bancos de dados) e
PHP2
(linguagem de programa¸cão). Essa combina¸cão tecnologica provê uma completa
infraestrutura para o desenvolvimento de aplica¸cões Web. O fato de ser composta por
tecnologias gratuitas, faz dessa plataforma uma boa alternativa em rela¸cão a tecnologias
comerciais como .NET e JEE (executando sobre servidores de aplica¸cão comerciais, como
Websphere ou Weblogic).
Ainda, apesar do L, na sigla, se referir ao sistema operacional Linux, uma aplica¸cão
LAMP pode ser facilmente portada para Windows ou Mac OS, com pouco ou até mesmo
nenhum trabalho de alterar códigos na aplica¸cão.
2
O “P” pode, às vezes, se referir a Perl ou Python.

23
3 Metodologia
Para se alcan¸car os objetivos deste trabalho, foi desenvolvido o aplicativo “Carro
Cheio”, integrado ao Orkut. O problema pesquisado foi dividido em cinco fases: escolha
das tecnologias apropriadas; desenho do modelo de dados; obten¸cão dos itinerários das
linhas de ônibus de BH; implementa¸cão; e por fim, testes.
3.1 Escolha das Tecnologias Apropriadas
Para a escolha das tecnologias a serem usadas no trabalho, consideraram-se as se-
guintes restri¸cões: gratuidade, boa documenta¸cão, curva de aprendizado reduzido e com-
patibilidade com navegadores a partir das versões: Mozilla Firefox 3.2.0, Microsoft Inter-
net Explorer 7.0, Google Chrome 6.0 e Apple Safari 4.0.
Figura 6: Arquitetura da aplica¸cão
Através do desenho da arquitetura da aplica¸cão (Figura 6), vê-se as tecnologias ele-
gidas para desenvolvimento do aplicativo “Carro Cheio”. São elas: rede social Orkut,
API Javascript Opensocial, Plataforma LAMP, API Google Maps e biblioteca Javascript
JQuery. O uso de cada tecnologia será abordado no decorrer desse cap´ıtulo.

24
3.2 Desenho do Modelo de Dados
O modelo de dados do aplicativo é exposto na Figura 7, na qual são apresentadas as
entidades que o compõem, bem como seus relacionamentos.
Figura 7: Diagrama do modelo de dados do aplicativo
Cada uma das entidades é descrita, brevemente, na Tabela 1.
Tabela 1: Descri¸cão das tabelas do modelo de dados
Entidade Descri¸cão
usuario Armazena os usuários do aplicativo. Os registros são inseridos no
momento que os usuários adicionam o aplicativo em seu perfil.
rota Armazena as informa¸cões sobre rotas que os usuários criam através
do aplicativo.
rota passo Armazena as coordenadas (latitude, longitude) de cada passo da rota
do usuário, na sequência em que ocorrem.
carona Armazena os pedidos de carona feitos por um usuário. Essa entidade
cruza dois usuários, uma rota e o passo da rota que foi solicitado.
onibus Armazena o cadastro das linhas de ônibus, por exemplo: 1010, SC02,
80.
onibus
itinerarios
Armazena os itinerários de cada linha de ônibus.
onibus
itinerarios
paradas
Armazena as coordenadas (latitude, longitude) de cada ponto de pa-
rada do ônibus no itinerário, na sequência em que ocorrem.
3.3 Obten¸cão dos Itinerários das Linhas de Ônibus
de BH
No projeto conceitual do aplicativo foi denifido que, em algumas situa¸cões, quando um
usuário fizesse uma busca por caronas, os resultados sugeridos poderiam ser viagens mis-

25
tas, combinando trechos de ônibus e trechos de automóvel. Eis uma situa¸cão hipotética,
na qual viagens mistas podem ser sugeridas:
• Francisco procurou por uma carona. Ele sai da Pra¸ca da Liberdade, Savassi, Belo
Horizonte e deseja chegar ao campus da PUC, no bairro São Gabriel, em Belo
Horizonte.
• Alfredo ofereceu uma carona no aplicativo. Ele também vai para a PUC, no bairro
São Gabriel. Entretanto, Alfredo sai da Pra¸ca Sete, centro de Belo Horizonte.
• É uma distância razoável – cerca de 1,6 quilômetros – para Francisco ir se encontrar
com Alfredo, se for à pé.
• Nesse cenário hipotético, a busca deve ser capaz de sugerir a Francisco tomar o
ônibus 4034 (Novo Dom Bosco / Savassi) para se encontrar com Alfredo, na Pra¸ca
Sete, e irem juntos até o campus da PUC.
Para que essa funcionalidade seja poss´ıvel, é necessário possuir uma base de dados
contendo as linhas de ônibus de BH e seus itinerários completos. Esses dados foram
obtidos em endere¸cos dispon´ıveis no site da Empresa de Transportes e Trânsito de Belo
Horizonte – BHTRANS.
Primeiro, obteve-se o número de cada linha de ônibus através da página Quadro de
horários1
, ilustrada na Figura 8.
Figura 8: Página da BHTRANS com a rela¸cão das linhas de ônibus de Belo Horizonte
Em seguida, ainda no site da BHTRANS, foi consultado o itinerário de cada linha,
através da página Itinerário2
.
Na Figura 9, vê-se a página com o resultado para a consulta à linha de ônibus 101.
Nesse momento, cada endere¸co correspondente ao ponto de parada do ônibus foi copiado
e formatado manualmente no arquivo itinerarios.txt.
1
Dispon´ıvel em: http://servicosbhtrans.pbh.gov.br/bhtrans/servicos eletronicos/
transporte qh info.asp.
2
Dispon´ıvel em: http://servicosbhtrans.pbh.gov.br/bhtrans/servicos eletronicos/
transporte itinerario resultado.asp?linha=101.

26
Figura 9: Página de itinerários no site da BHTRANS
Após o arquivo itinerarios.txt ter sido preenchido com os itinerários de todas as
linhas de ônibus, este foi processado por um programa em PHP – popula onibus.php –
cuja tarefa era popular as tabelas onibus, onibus itinerarios e onibus itinerarios -
paradas. Entretanto, para cada ponto de parada, foi preciso gravar a sua coordenada
geográfica. Para isso, foi utilizado o servi¸co de geocodifica¸cão do Google. Tal servi¸co
é acessado através de uma requisi¸cão HTTP, fornecendo como parâmetro o endere¸co a
ser geocodificado. Por exemplo, para obter as coordenadas do primeiro ponto da linha
de ônibus 101 – Avenida Artur Bernardes 1580 – deve-se enviar a seguinte requisi¸cão ao
servi¸co de geocodifica¸cão:
http://maps.google.com/maps/geo?output=xml&sensor=false&key=abcdefg&q=
Avenida Artur Bernardes 1580, Belo Horizonte, MG, Brasil
Como resposta a essa requisi¸cão, o geocodificador retorna um arquivo em formato
XML, contendo várias informa¸cões a respeito do endere¸co solicitado. Para este tra-
balho, é útil apenas as coordenadas geográficas do endere¸co, presentes entre as marca¸cões
<coordinates></coordinates>. Para o endere¸co Avenida Artur Bernardes 1580, tem-
se longitude -43.9476279 e latitude -19.9512799, conforme ilustrado na Figura 10.
Figura 10: Trecho do XML de resposta do servi¸co de geocodifica¸cão do Google
Fonte: GOOGLE, 2010
Após processar todo o arquivo itinerarios.txt, o banco de dados foi populado com
os itinerários de todas as linhas de ônibus de BH. Além disso, os pontos de embarque e
desembarque de cada ônibus foram mapeados com suas coordenadas geográficas.

27
3.4 Implementa¸cão
O escopo do aplicativo é apresentado através de um diagrama de casos de uso, visto
na Figura 11.
Figura 11: Diagrama de casos de uso
Cada caso de uso mostrado na Figura 11 é descrito, brevemente, na Tabela 2, possi-
bilitando uma visão geral sobre as funcionalidades do aplicativo. Adiante, nas subse¸cões
3.4.2 e 3.4.3, os casos de uso cadastrar rotas e buscar rotas serão descritos em mais
detalhes. Os demais casos de uso serão ilustrados na subse¸cão 3.4.4, através das capturas
das telas desenvolvidas para cada um.
Tabela 2: Visão geral dos casos de uso do aplicativo
Caso de uso Descri¸cão
Cadastrar
rota
Permite a um usuário, que possua automóvel, cadastrar as suas rotas,
detalhando os percursos através de um mapa. Em seguida essas rotas
ficarão dispon´ıveis para serem encontradas nas buscas por caronas.
Buscar rota Usuários interessados em encontrar uma carona, informam seus locais
de sa´ıda e destino e o sistema encontra rotas úteis a ele.
Pedir carona Quando um usuário encontra uma rota que lhe interesse, ele pode
pedir ao motorista uma carona. O aplicativo então envia ao moto-
rista, um pedido vindo desse usuário com o ponto onde este deseja
embarcar.
Visualizar
pedidos
Permite ao usuário visualizar todos os seus pedidos. Os pedidos são
dividos entre pedidos enviados e pedidos recebidos.
Aceitar
pedido
Ao visualizar seus pedidos recebidos, um usuário pode aceitar um
pedido. Esta a¸cão equivale a aceitar um pedido de carona.
Recusar
pedido
Ao visualizar seus pedidos recebidos, um usuário pode recusar um
pedido.
Avaliar
usuário
Permite avaliar o usuário positivamente ou negativamente. Cada
usuário possui um contador de avalia¸cões positivas e negativas.
Antes de continuar a descri¸cão da implementa¸cão do aplicativo, é necessário introduzir
o ambiente de testes de aplicativos do Orkut, chamado sandbox.

28
3.4.1 Orkut sandbox
O sandbox é uma versão do Orkut na qual os desenvolvedores podem instalar seus
aplicativos sociais e testá-los até estarem prontos.
Figura 12: Página de registro no Orkut sandbox
Fonte: ORKUT, 2010
A Figura 12 mostra a página de registro no sandbox. O registro deve ser feito no
endere¸co http://sandbox.orkut.com/SandboxSignup.aspx. Após realizar o registro, é
poss´ıvel acessar o ambiente sandbox e realizar os testes no aplicativo.
O acesso ao ambiente sandbox é feito no endere¸co http://sandbox.orkut.com/. O
primeiro passo para implementa¸cão do aplicativo foi submeter seu descritor inicial, cha-
mado aplicativo.xml, contendo informa¸cões básicas sobre autoria do aplicativo e as
bibliotecas que este utilizaria. A Figura 13 lista o conteúdo do descritor do aplicativo.
Figura 13: Conteúdo inicial do descritor do aplicativo
Como pode-se ver na Figura 13, o descritor se divide em duas se¸cões principais:
<ModulePrefs /> e <Content />. Na se¸cão <ModulePrefs /> devem ser informados
os parâmetros de autoria e descri¸cão do aplicativo. Nesta se¸cão também informa-se ao
container quais bibliotecas de fun¸cões devem ser carregadas para o aplicativo. A se¸cão

29
<Content /> é destinada a receber todo o conteúdo do aplicativo. Nela devem ser colo-
cados todos os códigos HTML, Javascript e outros.
Para submeter o descritor ao sandbox, antes foi preciso enviá-lo para o servidor do
aplicativo, através de um programa de FTP. O processo de submeter o descritor do
aplicativo é mostrado nas Figuras 14 e 15.
Figura 14: Página de submissão do aplicativo
Fonte: ORKUT, 2010
Figura 15: Página de confirma¸cão dos dados
Fonte: ORKUT, 2010
Na Figura 14, vê-se a página de submissão de um novo aplicativo. No campo de texto é
informado o endere¸co público do descritor do aplicativo, no caso deste trabalho, o descritor
público se encontra no endere¸co http://www.carrocheio.com/aplicativo.xml3
. Após
clicar no botão add application, é carregada a página de confirma¸cão, ilustrada na
Figura 15. Nessa página são exibidas as configura¸cões informadas no descritor, como
nome e e-mail do autor, nome e descri¸cão do aplicativo, além das imagens de ´ıcone e de
captura de tela. Também é poss´ıvel definir se o aplicativo terá acesso a informa¸cões dos
álbuns de fotos e se suas atividades serão divulgadas aos amigos da rede social.
Após clicar no botão save e confirmar a instala¸cão do aplicativo, este tornou-se dis-
pon´ıvel na lista de aplicativos do desenvolvedor. A partir da instala¸cão, o aplicativo entra
em processo de desenvolvimento, descrito na Figura 16.
Figura 16: Processo de desenvolvimento do aplicativo
3
Foi feito o registro do dom´ınio carrocheio.com e a contrata¸cão da hospedagem, para viabilizar a
infraestrutura necessária ao desenvolvimento da pesquisa.

30
O processo de desenvolvimento consiste nas seguintes etapas: são feitas altera¸cões
no código fonte do aplicativo, na esta¸cão de trabalho do desenvolvedor. Os arquivos,
modificados e acrescentados ao projeto, são enviados para o servidor do aplicativo através
de um programa de FTP (1). No sandbox, o pesquisador recarrega4
o aplicativo para
visualizar as altera¸cões (2). O sandbox se comunica com o servidor do aplicativo para
obter a versão mais nova do descritor. Além disso, também faz a requisi¸cão de imagens,
arquivos Javascript, CSS e outros (3).
Após uma visão geral do processo de desenvolvimento no Orkut sandbox, serão des-
critos em mais detalhes os casos de uso cadastrar rotas e buscar rotas.
3.4.2 Cadastrar rotas
Cadastrar uma rota é o mesmo que oferecer uma carona. Quando um usuário cadastra
uma rota, ele está descrevendo um caminho que percorre de automóvel.
Para cadastrar uma rota, o usuário deve escolher a op¸cão oferecer carona, na barra
de menus do aplicativo. Em seguida, será apresentada ao usuário a tela ilustrada na
Figura 17.
Figura 17: Tela do aplicativo: oferecer carona
Na Figura 17, observa-se os seguintes elementos: campos local de partida e local
de chegada, botões tra¸car rota e salvar esta rota, e finalmente, um mapa para
4
Recarregar significa atualizar a tela do navegador com o aplicativo carregado na barra de endere¸cos.

31
exibir e ajustar a rota.
Os locais de partida e de chegada são de preenchimento obrigatório. O usuário, en-
tretanto, pode informá-los em diversos formatos, por exemplo: “Afonso Pena, 1000, Belo
Horizonte”, “Pra¸ca da Liberdade, Belo Horizonte”, “Estádio Mineirão, Belo Horizonte”.
A rota é desenhada no mapa com base nas coordenadas dos locais de partida e de che-
gada. Portanto, para obter tais coordenadas, é preciso submeter os locais informados
pelo usuário a um servi¸co de geocodifica¸cão. Como já visto na se¸cão 3.3, neste trabalho
utilizou-se o servi¸co de geocodifica¸cão do Google Maps.
Alguns locais podem gerar ambiguidade. Se informado “Cristiano Machado, Belo
Horizonte”, serão encontradas várias respostas para este local.
Figura 18: Tela do aplicativo: desambigua¸cão de locais
A Figura 18 ilustra esse caso. Nela, vê-se que ao clicar em tra¸car rota, foi encontrada
uma ocorrência para “Pra¸ca da Liberdade, Belo Horizonte”, informada como local de
chegada. Entretanto, observando a Figura, vê-se que o aplicativo solicita ao usuário que
escolha o local de partida, dentre as seis op¸cões retornadas pelo geocodificador. A rota
não é tra¸cada no mapa até que o usuário clique em uma das op¸cões apresentadas.
Supondo que o usuário escolha a quarta op¸cão – Ave Cristiano Machado, Cidade
Nova, Belo Horizonte – a rota é, então, tra¸cada no mapa (Figura 19).
Observando a Figura 19, vê-se que ao tra¸car uma rota no mapa, surgem três novos
elementos na tela do aplicativo:

32
Figura 19: Tela do aplicativo: desenho da rota do motorista
1. Barra de status: contém informa¸cões sobre a distância percorrida no caminho, além
do tempo que seria gasto para percorrê-la (considerando viagem de automóvel).
2. Polilinha: uma linha cont´ınua composta de vários segmentos. Cada in´ıcio e fim de
segmento possui uma coordenada geográfica associada.
3. Marcadores: são ´ıcones que determinam marcos em uma polilinha. No caso de rotas
recém criadas, marcam o in´ıcio e o fim do trajeto. Rotas modificadas pelo usuário
podem conter marcadores intermediários, determinando desvios.
O caminho desenhado no mapa é determinado pela API Google Maps, através do
método loadFromWaypoints(waypoints:Array), da classe GDirections. Este método
recebe como parâmetro uma matriz, contendo dois ou mais pares de coordenadas (waypoints),
e desenha a polilinha sobreposta ao mapa. A rota mostrada na Figura 19 é obtida com a
seguinte chamada de método:
var rota = new GDirections();
rota.loadFromWaypoints([[-19.88892,-43.92916], [-19.932207,-43.9380159]]);
Nem sempre a rota desenhada pela API Google Maps corresponde ao caminho que
o usuário percorre. Nesse caso, é preciso permitir ao usuário modificar a rota, movendo
pontos da polilinha para marcar os desvios necessários. A API 2.0 do Google Maps não

33
possui métodos nativos para arrastar e soltar vértices da polilinha. A Figura 20 é utilizada
para demonstrar como foi implementada a funcionalidade de modifica¸cão de rotas.
Figura 20: Transi¸cão de estados para a modifica¸cão da rota
Na Figura 20, observa-se um trecho do mapa em quatro estados diferentes. No estado
1, o mapa observa os movimentos do cursor do mouse sobre sua superf´ıcie. A cada desloca-
mento do cursor, é calculada sua distância5
em rela¸cão a polilinha. Se a distância calculada
estiver abaixo de um valor arbitrado, o mapa passa para o estado 2. No estado 2, é exibido
um marcador temporário sobre o vértice da polilinha mais próximo ao cursor. O estado 3
representa o marcador temporário sendo arrastado pela superf´ıcie do mapa. Ao ser solto, o
marcador inicia o estado 4. No estado 4, a coordenada do marcador temporário é inserida
na matriz de waypoints. Em seguida, o método loadFromWaypoints(waypoints:Array)
é chamado para redesenhar a rota.
Para salvar a rota, deve-se clicar no botão salvar esta rota. Em seguida, a janela
salvar uma nova rota será exibida para o usuário (Figura 21).
Figura 21: Tela do aplicativo: salvar uma nova rota
Nessa janela, o usuário deve informar um t´ıtulo para a rota, além dos dias e horários
em que repete o trajeto. Ao clicar no botão concluir, a rota é finalmente gravada no
banco de dados. Uma rota é gravada da seguinte maneira: é inserido um registro na tabela
rota, com o código do usuário, o t´ıtulo da rota e suas informa¸cões de dias e horários.
5
Esse cálculo é realizado pela biblioteca Javascript BdccGeo.js (CHADWICK, 2007).

34
Na tabela rota passo são inseridos registros relacionados à rota criada. Cada registro
armazena a coordenada referente a um vértice da polilinha (Figura 22).
Figura 22: Registros na tabela rota passos
A Figura 22 mostra os oito primeiros passos de uma rota. Na Figura, vê-se a coluna
id rota. A coluna id rota relaciona um passo a uma rota. Nesse caso, os passos são
relacionados à rota de número 26. As colunas lat e lon se referem à latitude e à longitude
do passo. Por fim, a coluna passo final recebe o valor 1 se for o último passo da rota.
A coluna passo final é útil para o método de busca de caronas, apresentada na se¸cão a
seguir.
3.4.3 Buscar rotas
Nesta se¸cão será apresentado o método utilizado para buscar rotas. Como visto, na
se¸cão 3.4.2, uma rota é uma sequência de passos, realizados para se cumprir um trajeto.
Também foi visto que os passos são armazenados no banco de dados com suas coordenadas
geográficas. A Figura 23 representa esse conceito graficamente.
Figura 23: Representa¸cão gráfica dos dados de uma rota

35
3.4.3.1 Fluxo de dados da busca por rotas
Para encontrar ofertas de caronas, o usuário deve acessar a op¸cão pedir carona, no
menu de op¸cões do aplicativo (Figura 24).
Figura 24: Tela do aplicativo: tela de janela de busca de rotas
Na janela de busca de rotas há três campos que devem ser informados pelo usuário:
local de sa´ıda; local de destino; e a distância máxima que se deseja caminhar até o
embarque e o destino. Ao acionar o botão buscar, ocorre o fluxo de dados ilustrado na
Figura 25.
Figura 25: Fluxo de dados durante busca por rotas
Observando a Figura 25, as setas numeradas de um a quatro indicam a seguinte
sequência de opera¸cões:
1. Os locais de sa´ıda e de chegada são enviados ao servi¸co de geocodifica¸cão do Google
Maps, via Javascript e HTTP.
2. O servi¸co de geocodifica¸cão do Google Maps retorna a geocodifica¸cão dos locais,
contendo suas coordenadas geográficas.
3. As coordenadas geográficas dos locais de sa´ıda e de chegada são enviadas como
parâmetros para a página de busca de rotas, no servidor do aplicativo. Esse processo
também ocorre via Javascript e HTTP.

36
4. A página de busca de rotas responde com um objeto em formato JSON, contendo as
rotas encontradas ou contendo uma rota vazia, no caso de não encontrar nenhuma
rota compat´ıvel.
3.4.3.2 Cálculo da distância linear entre dois pontos na Terra
Na busca por rotas, é necessário calcular a distância linear entre dois pontos na
Terra, dadas as suas latitudes e longitudes. Para esse propósito, utilizou-se a Fórmula de
Haversine6
, a qual foi mapeada em uma fun¸cão escrita em linguagem PHP mostrada na
Figura 26.
Figura 26: Fun¸cão de cálculo da distância linear entre dois pontos na Terra
3.4.3.3 Heur´ıstica de busca por rotas
A Figura 27 a seguir, mostra um cenário hipotético.
Figura 27: Heur´ıstica de busca: cenário hipotético
Nesse cenário, há quatro rotas cadastradas no banco de dados. Essas rotas são re-
presentadas na Figura 27 através dos segmentos A-A’, B-B’, C-C’, D-D’. O sentido de
6
A fórmula de Haversine é uma importante equa¸cão usada em navega¸cão, fornecendo distâncias entre
dois pontos de uma esfera a partir de suas latitudes e longitudes. (FÓRMULA DE HAVERSINE, 2010)

37
cada rota é denotado por uma letra (A), como ponto de origem; e uma letra seguida de
apóstrofo (A’), como ponto de chegada. A necessidade do usuário é representada pelos
pontos I, como local de partida, e F, como local de chegada. Por fim, os c´ırculos r in-
dicam a distância máxima que o usuário deseja andar até o embarque ou até o seu local
de chegada. A distância máxima será citada como d max, no decorrer da apresenta¸cão da
heur´ıstica.
Na primeira itera¸cão, a heur´ıstica procura por rotas que possuam algum passo a uma
distância menor que d max, em rela¸cão ao ponto de chegada do usuário (F). Para todas as
rotas encontradas, utiliza-se apenas o passo com a menor distância até F. Após a primeira
itera¸cão, são encontradas as rotas B-B’, C-C’ e D-D’, conforme ilustrado na Figura 28.
Figura 28: Heur´ıstica de busca: primeira itera¸cão
A segunda itera¸cão é feita entre as rotas encontradas na primeira itera¸cão. Nessa
itera¸cão, a heur´ıstica seleciona rotas que possuam um passo à uma distância máxima
de 2d max7
do ponto I8
. Além disso, o passo deve ser anterior ao passo encontrado na
primeira itera¸cão. Essa restri¸cão elimina a rota C-C’ das respostas (Figura 29).
Figura 29: Heur´ıstica de busca: segunda itera¸cão
7
A razão de se ampliar a distância máxima é encontrar rotas mais distantes, mas que possam ser
alcan¸cadas de ônibus.
8
Para simplificar a Heur´ıstica escolheu-se o ponto I.

38
Observando a Figura 29, percebe-se que a rota D-D’ atende a necessidade do usuário.
A heur´ıstica considera, então, a rota D-D’ como ótima. Entretanto, a rota B-B’ possui
um ponto de embarque a uma distância maior do que d max. Para essa rota, a heur´ıstica
consulta a base de dados de itinerários de ônibus e procura por alguma linha que passe
próximo ao ponto I, chegando próximo ao ponto B. Se a heur´ıstica não encontrar uma
linha de ônibus, a rota é descartada. Caso contrário, a rota é mantida no conjunto de
respotas e o ônibus encontrado é inclu´ıdo na resposta, gerando uma rota mista (Figura
30).
Figura 30: Heur´ıstica de busca: busca por ônibus
Na Figura 30, o segmento pontilhado O-O’, representa o trecho a ser cumprido em
uma viagem de ônibus, chegando próximo ao ponto de embarque, na rota B-B’.
A heur´ıstica pode ser expressa na forma de um diagrama, conforme a Figura 31.
Figura 31: Heur´ıstica de busca
3.4.4 Demais Casos de Uso
Nesta se¸cão são ilustradas as telas dos seguintes casos de uso: pedir carona, visualizar
pedidos, aprovar pedido, recusar pedido e avaliar usuário.

39
O caso de uso pedir carona é ilustrado através da Figura 32, na qual pode-se ver a
janela de pedido de carona. Essa janela se abre no momento em que o usuário escolhe a
op¸cão pedir carona, na tela de busca de caronas (Figura 36).
Figura 32: Tela do aplicativo: enviar pedido de carona
Na Figura 33 é ilustrada a tela correspondente aos seguintes casos de uso: visualizar
pedidos, aceitar pedidos e recusar pedidos. Vê-se, na tela, o agrupamento dos pedidos
entre pedidos enviados e pedidos recebidos (aba que aparece ativa). Ainda, na Fi-
gura 33, observa-se a indica¸cão do local no qual o passageiro deseja embarcar, e as op¸cões
aceitar e recusar pedido.
Figura 33: Tela do aplicativo: visualizar, aceitar e recusar pedidos
Na Figura 34 é apresentada a tela para o caso de uso avaliar usuário. Nota-
se a rela¸cão de todas as rotas cadastradas pelo motorista. Uma rota, em espec´ıfico,
aparece expandida, relacionando seus passageiros (nesse caso, Jack). Através dos ´ıcones
polegar para cima e polegar para baixo, o motorista pode classificar o passageiro
positivamente ou negativamente. O ´ıcone lupa, abre a janela com informa¸cões sobre o
usuário em questão, contendo quantas classifica¸cões positivas e negativas ele possui.
Do ponto de vista do passageiro, pode-se classificar os motoristas com os quais viaja

40
acessando a aba Como passageiro, na qual estarão dispon´ıveis as mesmas opera¸cões.
Figura 34: Tela do aplicativo: avaliar usuário

41
4 Resultados
Neste cap´ıtulo, são apresentados os resultados obtidos nos testes realizados no apli-
cativo Carro Cheio. Para a avalia¸cão a sua eficiência, seus resultados foram comparados
aos resultados dos mesmos testes, realizados em sistemas similares.
4.1 Prepara¸cão do Ambiente de Testes
Para se testar o Carro Cheio, adicionou-se o aplicativo a dois perfis de usuários no
Orkut. Considere, como exemplo os usuários de Jack e Beth. Jack oferece uma carona,
enquanto Beth, procura uma carona.
Através do perfil de Jack, cadastrou-se uma rota (R), sa´ındo da Avenida Afonso Pena,
5100 e chegando à Avenida Afonso Pena, 1. Trata-se de um percurso de aproximadamente
4 quilômetros, segundo o Google Maps (Figura 35).
Figura 35: Rota utilizada nos testes testes
Em seguida, foram realizadas quatro buscas por caronas, através do perfil de Beth.
Os parâmetros de entrada estão listados na Tabela 3.
Tabela 3: Parâmetros de buscas por caronas
# Local de sa´ıda Local de chegada
1 Rua Ramalhete, 100 Rua dos Tupinambás, 500
2 Rua dos Tupinambás, 500 Rua Ramalhete, 100
3 Av. Afonso Pena, 1500 Rua dos Tupinambás, 500
4 Av. Bandeirantes, 800 Rua Espirito Santo, 800
Fonte: Autor da pesquisa, 2010
Os mesmos testes foram realizados nos sites Bigoo (www.bigoo.com.br) e Caroneiros
(www.caroneiros.com.br). Nesses sites, foram criadas as contas para Jack e Beth, man-
tendo seus papéis de motorista e passageira, respectivamente. Para as buscas realizadas

42
no Carro Cheio e Caroneiros, foi definido um raio de abrangência de 500 metros. No
Bigoo esse parâmetro não estava dispon´ıvel.
Cada teste, numerado de 1 a 4, procurou avaliar uma caracter´ıstica diferente, nos
sitemas. As caracter´ısticas avaliadas foram as seguintes:
• Teste 1: avalia se o mecanismo utiliza coordenadas geográficas na busca, uma vez
que os locais de sa´ıda e de chegada de Beth são próximos aos de Jack, mas não
contém as mesmas palavras-chave.
• Teste 2: avalia se o mecanismo é capaz de considerar o sentido da rota do motorista.
• Teste 3: avalia se o mecanismo é capaz de considerar pontos intermediários na rota
do motorista.
• Teste 4: avalia como o mecanismo trata casos nos quais Beth está relativamente
longe do ponto mais próximo a Jack.
4.2 Avalia¸cão dos Resultados
Após a realiza¸cão dos testes, observou-se que o Carro Cheio retornou respostas corre-
tas para as quatro consultas realizadas. O site Bigoo retornou uma resposta incorreta para
o teste 2. A rota encontrada pelo Bigoo era percorrida no sentido inverso ao da consulta
realizada. Já o site Caroneiros não encontrou a rota de Jack na terceira consulta. Após
refazer a terceira consulta ampliando o raio para 2 quilômetros, a rota foi encontrada.
Isso leva a acreditar que o site Caroneiros armazena apenas as coordenadas de origem e
destino, na rota do motorista.
Dentre os três sistemas testados, o Carro Cheio é o único que indica ao passageiro os
locais nos quais ele deve embarcar e desembarcar (Figura 36).
Figura 36: Tela do aplicativo: resultado do Teste 3

43
Como se vê, na Figura 36, o Carro Cheio foi impreciso ao sugerir o local para em-
barque, no teste 3. Ainda que tenha encontrado corretamente a rota, a resposta diz a
Beth para embarcar a 173 metros, na Av. Afonso Pena, 1433. Sabe-se que Beth poderia
embarcar logo à frente de seu endere¸co de sa´ıda, a menos de 100 metros. Essa imprecisão
deve-se ao fato de que as rotas não são gravadas com todas as suas coordenadas. Como
citado na se¸cão 3.4.2, as rotas são gravadas apenas com as coordenadas de in´ıcio e fim de
cada segmento da Polilinha.
Através do teste 4, foi poss´ıvel validar a integra¸cão do Carro Cheio com o transporte
coletivo de Belo Horizonte. Nesse teste, o endere¸co de sa´ıda de Beth (Av. Bandeirantes,
800) está há mais de 1 quilômetro de distância do ponto mais próximo a Jack. Nesse caso,
o Carro Cheio foi capaz de sugerir o ônibus 9106 a Beth, para que ela se encontre com
Jack próximo à Av. Bandeirantes, 1944. A Figura 37 apresenta a resposta para o teste 4.
Figura 37: Tela do aplicativo: resultado do Teste 4
Na Figura 37, vê-se a janela de representa¸cão gráfica da carona sugerida. Na janela
é apontado o local de origem de Beth e seu caminho até Jack. Arrastando a tela do
mapa, seria poss´ıvel ver o restante do trajeto, além do ponto de desembarque de Beth.
Complementando, no teste 4, tanto o Bigoo quanto o Caroneiros não encontraram a rota
de Jack.

44
5 Conclusão
Neste trabalho foi realizada a pesquisa e desenvolvimento do aplicativo Carro Cheio.
Através do Carro Cheio, procurou-se alcan¸car o objetivo de se fornecer um sistema efi-
ciente para combinar caronas através do Orkut. Ainda, tentou-se suprir no Carro Cheio,
as deficiências encontradas em outros sistemas com o mesmo propósito. A avalia¸cão dos
resultados foi feita por meio de testes direcionados, realizados pelo autor da pesquisa.
Dessa forma, os resultados obtidos nos testes e comparativos realizados entre o Carro
Cheio, Bigoo e Caroneiros não foram suficientes para afirmar que o Carro Cheio surge
como o melhor sistema de caronas, dentre os três. Para afirmar isso, seria necessário sub-
meter os três sistemas a testes mais abrangentes, com uma massa significativa de usuários,
e avaliar suas impressões.
Por outro lado, através dos testes, foi poss´ıvel verificar caracter´ısticas onde o Carro
Cheio, de fato, conseguiu suprir deficiências dos outros sistemas. Ainda, segundo os
testes, o Carro Cheio atingiu os objetivos propostos neste trabalho: integrar-se a rede
social Orkut; permitir o cadastro de rotas detalhando seu trajeto; realizar buscas de rotas
através de coordenadas geográficas; e integrar resultados com informa¸cões do transporte
coletivo de Belo Horizonte.
Vale ressaltar, entretanto, alguns estudos que podem ser realizados futuramente, para
tornar o aplicativo mais eficiente. Uma avalia¸cão de usabilidade poderia apontar medidas
a serem tomadas para tornar o uso do aplicativo mais intuitivo. Além disso, o formulário
de cadastro de rotas pode ser ampliado com mais informa¸cões. Com rela¸cão a heur´ıstica
de busca, pode-se se estudar a integra¸cão dos resultados com o transporte ferroviário.
Além disso, pode-se melhorar a precisão das buscas através do uso de interpola¸cão dos
pontos das rotas. Por fim, o uso de agentes inteligentes em versões futuras, pode trazer
novas funcionalidades ao aplicativo.

45
Referências
ABREU, N. R. de; BALDANZA, R. F.; SETTE, R. de S. Comunidades virtuais como
ambiente potencializador de estratégias mercadológicas: Locus de informa¸cões e troca de
experiências. Perspectivas em Ciência da Informa¸cão, v. 13, n. 3, p. 116-136, set./dez.
2008.
AJAX. In: WIKIPÉDIA: a enciclopédia livre. Wikimedia, 2006. Dispon´ıvel em
http://pt.wikipedia.org/wiki/AJAX (programa¸c~ao). Acesso em: 01 maio de 2010.
AGÊNCIA MINAS. Projeto Melhorar incentiva a carona solidária em Minas. Minas
Gerais, 2009. Dispon´ıvel em http://www.agenciaminas.mg.gov.br/component/
controlemultimidia/noticiaid=26804. Acesso em 01 maio 2010.
ALEXA. Top Sites in Brazil. Dispon´ıvel em http://www.alexa.com/topsites/coun-
tries/BR. Acesso em 01 may 2010.
BARGH, J.; MCKENNA, K. The internet and social life. The Annual Review of
Psychology, v. 55, p. 573-590, feb. 2004.
BELO HORIZONTE. Estat´ısticas e Mapas / Demografia. Dispon´ıvel em
http://portalpbh.pbh.gov.br/pbh/ecp/comunidade.do?app=estatisticas.
Acesso em 01 maio 2010.
BHTRANS, Empresa de Transportes e Trânsito de Belo Horizonte. Apresenta¸cão
sobre mobilidade urbana e acessibilidade. Seminário de Consolida¸cão da Rede Cidades
Interativas: Mobilidade Urbana, Acessibilidade e Governo Eletrônico. Natal, RN, mar.
2008.
BIGOO. Bigoo. Dispon´ıvel em http://www.bigoo.com.br/. Acesso em 01 novembro
2010.
BOYD, D. M.; ELLISON, N. B. Social network sites: Definition, history, and scholarship.
Journal of Computer-Mediated Communication, v. 13, n. 1, article 11, 2005.
BRASIL. Desenvolvimento Sustentável – Responsabilidade e compromisso de todos.
Governo do Brasil. Dispon´ıvel em http://www.cop15brasil.gov.br/pt-BR/. Acesso
em 01 maio 2010.
BUYUKKOKTEN, O.; ADAMIC, L. A.; AIDAR, E. A social network caught in the
Web. First Monday, v. 8, n. 6, june 2003.
CARONEIROS. Caroneiros.com - Encontrei aqui sua carona!. Dispon´ıvel em
http://www.caroneiros.com/. Acesso em 01 novembro 2010.

46
COSTA, R. Por um novo conceito de comunidade: redes sociais, comunidades pessoais
e inteligência coletiva. Interface - Comunica¸cão, Saúde, Educa¸cão, v.9, n.17, p.235-248,
mar./ago. 2005.
CHADWICK, B. Bill Chadwick’s Google Maps Demos. Dispon´ıvel em
http://www.bdcc.co.uk/Gmaps/BdccGmapBits.htm. Acesso em 01 maio 2010.
DENATRAN, Departamento Nacional de Trânsito. Frota de ve´ıculos. Dispon´ıvel em
http://www.denatran.gov.br/frota.htm. Acesso em 01 maio 2010.
ELLISON, N. B.; STEINFIELD, C.; C.LAMPE. The benefits of facebook “friends”:
social capital and college students use of online social network sites. Journal of
Computer-Mediated Communication, v. 12, n. 4, article 1, 2007.
ÉPOCA. O poder e o risco das redes sociais. Globo, n. 628, p. 79-113, maio 2010.
FÓRMULA DE HAVERSINE. In: WIKIPÉDIA: a enciclopédia livre. Wikimedia, 2006.
Dispon´ıvel em pt.wikipedia.org/wiki/Fórmula de Haversine. Acesso em: 01 maio
de 2010.
GOOGLE. Referência da API do Google Maps. Dispon´ıvel em
http://code.google.com/intl/pt-BR/apis/maps/documentation/javascript/v2/
reference.html. Acesso em 01 de maio 2010.
GOVERNO DE SÃO PAULO. Mutirão da carona incentiva transporte solidário.
Dispon´ıvel em http://www.saopaulo.sp.gov.br/spnoticias/lenoticia.php?id=
95276. Acesso em 01 maio 2010.
IBGE, Instituto Brasileiro de Geografia e Estat´ıstica. Contagem da popula¸cão 2007.
Dispon´ıvel em http://www.ibge.com.br/home/estatistica/populacao/
contagem2007/. Acesso em 01 maio 2010.
INFO EXAME. Gadgets verdes. Abril, p. 32-48, ago. 2009.
JQUERY. The write less, do more, Javascript library Dispon´ıvel em
http://www.jquery.com. Acesso em: 01 maio de 2010.
JSON. In: WIKIPÉDIA: a enciclopédia livre. Wikimedia, 2006. Dispon´ıvel em
http://pt.wikipedia.org/wiki/JSON. Acesso em: 01 maio de 2010.
JUNGBLUT, A. L. A heterogenia do mundo on-line: Algumas reflexões sobre
virtualiza¸cão, comunica¸cão mediada por computador e ciberespa¸co. Horizontes
Antropológicos, Porto Alegre, RS, n. 21, p. 97-121, jan./jun. 2004.
KAVANAUGH, A. et al. Community networks: Where off-line communities meet on-line.
Journal of Computer-Mediated Communication, v. 10, n. 4, 2005.
KUMAR, R.; NOVAK, J.; TOMKIMS, A. Structure and evolution of online social
networks. 12th ACM SIGKDD International Conference on Knowledge Discovery and
Data Mining, Philadelphia, EUA, aug. 2006.
MARTELETO, R. M.; SILVA, A. B. de Oliveira e. Redes e capital social: o enfoque da
informa¸cão para o desenvolvimento local. Ciência da Informa¸cão, Bras´ılia, v. 33, n. 3,
set./dez. 2004.

47
NOBRE, C. A. Aquecimento global e o papel do Brasil. Ciência Hoje, Rio de Janeiro, v.
36, n. 211, p. 38-40, dez. 2004.
OPENSOCIAL. Opensocial JavaScript API Reference. Dispon´ıvel em
http://wiki.opensocial.org/index.php?title=JavaScript API Reference.
Acesso em 01 de maio 2010.
ORKUT. Orkut developer home. Developer’s Guide: JavaScript. Dispon´ıvel em
http://code.google.com/intl/en-US/apis/orkut/docs/orkutdevguide/orkutdev-
guide-0.8.html. Acesso em 01 de maio 2010.
PLANMOB-BH. Plano de Mobilidade Urbana de Belo Horizonte. Dispon´ıvel em
http://www.planmobbh.com.br/. Acesso em 01 maio 2010.
ROCHA, A. C. B. et al. Gerenciamento da mobilidade: Experiências em Bogotá, Londres
e alternativas pós-modernas. Pluris 2006 Congresso Luso Brasileiro para o planejamento
urbano, regional, integrado e sustentável, Portugal, 2006.
SOUDERS, S. Even Faster Web Sites. O’Reilly, ed. 1, june 2009.
WILLIAMS, M. Google Maps API Tutorial. Dispon´ıvel em
http://econym.org.uk/gmap/. Acesso em 01 maio 2010.

TCC_2010_2_Fernando_Figueiredo_Torres

Mais conteúdo relacionado

Destaque

Semelhante a TCC_2010_2_Fernando_Figueiredo_Torres

TCC_2010_2_Fernando_Figueiredo_Torres