TCC_2010_2_Fernando_Figueiredo_Torres

Pontifıcia Universidade Catolica de Minas Gerais

Bacharelado em Sistemas de Informacao

Trabalho de Conclusao de Curso

Carro Cheio: Um Aplicativo Para

Formacao 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

Formacao de Caronas em Redes Sociais

Como Forma de Favorecer a Mobilidade

Urbana em Belo Horizonte

Trabalho apresentado ao Instituto deCiencias Exatas e Informatica da PontifıciaUniversidade Catolica de Minas Gerais comorequisito parcial a obtencao da graduacaoem Bacharelado em Sistemas de Informacao

Orientador:Fabio Tirelo

Pontifıcia Universidade Catolica de Minas GeraisInstituto de Ciencias Exatas e Informatica

Belo Horizonte

Dezembro 2010

Trabalho de Conclusao de Curso sob o tıtulo “Carro Cheio: Um Aplicativo Para Formacao

de Caronas em Redes Sociais Como Forma de Favorecer a Mobilidade Urbana em Belo

Horizonte”, do Instituto de Ciencias Exatas e Informatica da Pontifıcia Universidade

Catolica de Minas Gerais, Belo Horizonte, dezembro 2010.

Prof. Fabio TireloOrientador


Prof. Paulo Cesar do Amaral PereiraExaminador


Prof. Zenilton Kleber Goncalves do PatrocınioJunior

ExaminadorPontifıcia Universidade Catolica de Minas Gerais

Instituto de Ciencias Exatas e Informatica

Acho que nossas chances nao parecem boas hoje, mas a unica forma de falhar, para

mim, e apenas nao tentando.

Gary Kasparov

Agradecimentos

A realizacao deste trabalho so foi possıvel devido a ajuda que tive, direta e indireta-

mente, de varias pessoas, ao longo dessa jornada.

No inıcio, tudo comecou com uma ideia, enviei para o professor Fabio Tirelo, que

prontamente se interessou em orientar o meu trabalho, e ao qual agradeco pela orientacao,

incentivo, e comprometimento demonstrado em nossas reunioes.

Durante as centenas de horas investidas nesta pesquisa, contei com a excepcional ajuda

do Google, que me ofereceu condicoes de encontrar todas as informacoes que precisei,

alem 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,

so foram solucionados gracas a boa vontade de Mark Williams e Bill Chadwick, que um

dia disponibilizaram seus experimentos na Internet, servindo de otimos tutoriais.

Agradeco tambem aqueles que, por vezes, me proporcionaram momentos de distracao,

para a renovacao das ideias. Aos meus amigos, obrigado por me tirarem da frente do

computador em alguns (poucos, e verdade) sabados.

Resumo

A mobilidade urbana e uma importante area de estudos da administracao publicacujo papel e proporcionar o irrestrito deslocamento de pessoas e veıculos no espaco dacidade. A necessidade de polıticas de mobilidade urbana aumenta a medida que aumenta,tambem, a disputa pelo espaco urbano, decorrente do crescimento anual da frota deveıculos. Entretanto, e fundamental a iniciativa e o comprometimento da populacao para osucesso desse processo. Diante disso, este trabalho estuda a pratica do compartilhamentodo carro, ou as “caronas”, com o objetivo de contribuir para a diminuicao de veıculoscirculando nas vias da cidade, bem como a diminuicao de pessoas utilizando o transportecoletivo. 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 usuarios divulgareme encontrarem vagas de carona. Atraves do Carro Cheio, os usuarios do Orkut podemcombinar caronas com pessoas com as quais ja mantem contato, sendo uma opcao maissegura em relacao aos demais sites de carona. Ainda, o Carro Cheio busca rotas comproximidade de coordenadas geograficas e utiliza informacoes sobre as linhas de onibusde Belo Horizonte em suas respostas.

Palavras-chave: Redes sociais. Mobilidade urbana. API Opensocial. API Google Maps.

Lista de Figuras

1 Composicao da frota em BH, em dez. 2009 . . . . . . . . . . . . . . . . p. 12

2 Queda na velocidade do transporte publico em BH, entre 2002 e 2006 . p. 13

3 Crescimento da frota em BH, entre 2002 e 2006 . . . . . . . . . . . . . p. 13

4 Presenca de usuarios brasileiros nas principais redes sociais (em milhoes) p. 19

5 Modelo e fluxo de dados de um aplicativo social . . . . . . . . . . . . . p. 20

6 Arquitetura da aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

7 Diagrama do modelo de dados do aplicativo . . . . . . . . . . . . . . . p. 24

8 Pagina da BHTRANS com a relacao das linhas de onibus de Belo Horizonte p. 25

9 Pagina de itinerarios no site da BHTRANS . . . . . . . . . . . . . . . . p. 26

10 Trecho do XML de resposta do servico de geocodificacao do Google . . p. 26

11 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

12 Pagina de registro no Orkut sandbox . . . . . . . . . . . . . . . . . . . p. 28

13 Conteudo inicial do descritor do aplicativo . . . . . . . . . . . . . . . . p. 28

14 Pagina de submissao do aplicativo . . . . . . . . . . . . . . . . . . . . . p. 29

15 Pagina de confirmacao dos dados . . . . . . . . . . . . . . . . . . . . . p. 29

16 Processo de desenvolvimento do aplicativo . . . . . . . . . . . . . . . . p. 29

17 Tela do aplicativo: oferecer carona . . . . . . . . . . . . . . . . . . . . . p. 30

18 Tela do aplicativo: desambiguacao de locais . . . . . . . . . . . . . . . p. 31

19 Tela do aplicativo: desenho da rota do motorista . . . . . . . . . . . . . p. 32

20 Transicao de estados para a modificacao da rota . . . . . . . . . . . . . p. 33

21 Tela do aplicativo: salvar uma nova rota . . . . . . . . . . . . . . . . . p. 33

22 Registros na tabela rota passos . . . . . . . . . . . . . . . . . . . . . p. 34

23 Representacao grafica 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 Funcao de calculo da distancia linear entre dois pontos na Terra . . . . p. 36

27 Heurıstica de busca: cenario hipotetico . . . . . . . . . . . . . . . . . . p. 36

28 Heurıstica de busca: primeira iteracao . . . . . . . . . . . . . . . . . . p. 37

29 Heurıstica de busca: segunda iteracao . . . . . . . . . . . . . . . . . . . p. 37

30 Heurıstica de busca: busca por onibus . . . . . . . . . . . . . . . . . . . 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 usuario . . . . . . . . . . . . . . . . . . . . . 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 Descricao das tabelas do modelo de dados . . . . . . . . . . . . . . . . p. 24

2 Visao geral dos casos de uso do aplicativo . . . . . . . . . . . . . . . . p. 27

3 Parametros 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 Transito.

FTP File Transfer Protocol.

HTML Hypertext Markup Language.

HTTP Hypertext Transfer Protocol.

IBGE Instituto Brasileiro de Geografia e Estatıstica.

PIB Produto Interno Bruto.

XML Extensible Markup Language.

Sumario

1 Introducao p. 12

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

2 Revisao 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 Obtencao dos Itinerarios das Linhas de Onibus de BH . . . . . . . . . . p. 24

3.4 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Calculo da distancia 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 Preparacao do Ambiente de Testes . . . . . . . . . . . . . . . . . . . . p. 41

4.2 Avaliacao dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42

5 Conclusao p. 44

Referencias p. 45

12

1 Introducao

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 seculo apos a sua

fundacao, a capital atingiu uma populacao aproximada de 2,5 milhoes de habitantes,

tendo o 4o. maior PIB do Brasil (IBGE, 2007).

Em relacao ao transito, BH terminou o ano de 2009 com uma frota de 1,2 milhoes de

veıculos, composta principalmente por automoveis (82%) e motocicletas (13%), conforme

mostrado na Figura 1. Esse numero revela uma proporcao aproximada de um veıculo

para cada dois habitantes. Para se fazer uma comparacao, a cidade de Sao Paulo, cujos

problemas de transito sao constantemente citados na mıdia, possui a mesma proporcao

(IBGE, 2007; DENATRAN, 2010).

Figura 1: Composicao da frota em BH, em dez. 2009Fonte: DENATRAN, 2010

Com a facilidade cada vez maior em se adquirir um veıculo, mais pessoas tem trocado

o uso do transporte publico pelo transporte particular. A princıpio, podemos imaginar

que essa troca representa ganho na qualidade de vida desses cidadaos. Entretanto, uma

visao 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 consequencias

negativas a qualidade da mobilidade urbana e ao meio ambiente.

Um estudo, feito pela Empresa de Transportes e Transito de Belo Horizonte (BH-

13

TRANS, 2008), analisou a velocidade media do transporte publico nos horarios de pico

da manha e da tarde, em BH. Esse estudo mostra que entre 2002 e 2006 houve uma

queda da velocidade em 6% no pico da manha, e em 4,9% no pico da tarde (Figura 2).

Considerando o mesmo perıodo, ve-se na Figura 3 o numero acumulado de novos veıculos

adicionados a frota na cidade por categoria. Uma analise das Figuras 2 e 3 produz fortes

indıcios de que o crescimento da frota de automoveis tem grande responsabilidade na

degradacao da qualidade do transito.

Figura 2: Queda na velocidade do transporte publico emBH, entre 2002 e 2006

Fonte: BHTRANS, 2008Figura 3: Crescimento da frota em BH, entre 2002 e 2006

Fonte: DENATRAN, 2010

O aumento no consumo de automoveis nao se da apenas pela sua utilidade como meio

de transporte. Na atualidade, o automovel e considerado objeto de desejo e status social.

Ainda que os servicos de transporte publico sejam melhorados, fica difıcil desestimular o

consumo e o uso do automovel. Passa a ser necessario, entao, estimular o uso consciente

do automovel particular, transformando-no em um agente em prol da mobilidade urbana

sustentavel.

O uso consciente do automovel 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 vao desde a escolha por veıculos com combustıveis menos poluentes

ate a mudanca da visao individualista no uso do automovel para uma visao coletiva. Nesse

sentido, este trabalho foca a pratica da carona solidaria.

Os impactos da carona solidaria na mobilidade urbana tendem a ser muito positivos.

Um motorista que leve pessoas a pontos compreendidos em seu trajeto, pode ajudar

a diminuir o numero de usuarios do transporte publico naquele dia. De forma analoga,

proprietarios de automoveis poderiam se revezar para irem juntos ao trabalho, diminuindo

o numero de automoveis nas ruas.

Apesar de todo o benefıcio da carona solidaria, questoes culturais e de seguranca sao

barreiras a serem vencidas. Em nossa sociedade, ha receios associados a pratica da carona;

14

por exemplo, e comum ensinar a criancas que nao se deve aceitar caronas de estranhos.

Considerando-se todo o cenario descrito, este trabalho estudou uma possıvel solucao

para o problema de se formar grupos de caronas, levando-se em conta as barreiras sociais e

culturais encontradas nesse processo. Alem disso, foram analisadas as formas ja utilizadas

para o mesmo proposito e suas limitacoes. A solucao proposta deve ser abrangente de

forma a alcancar o maior numero de pessoas em um ambiente virtual (on-line). Ainda,

deve oferecer boas alternativas para as limitacoes encontradas em outros mecanismos.

Para tanto, estudou-se o ambiente das redes sociais como ponto central da solucao.

1.1 Motivacao

Existem muitos fatores que dificultam a tarefa de encontrar e oferecer caronas. Por

meio da comunicacao verbal direta geram-se muitos ruıdos, pois e necessario abordar

todos os indivıduos do grupo e questiona-los sobre sua intencao em oferecer ou utilizar

caronas. Alem disso, sao necessarias algumas interacoes repetitivas entre as partes para

verificar questoes de trajeto, paradas e vagas disponıveis.

De outra forma, o uso de quadros de avisos em areas de circulacao tambem apresenta

problemas. Sabe-se que as pessoas nem sempre leem quadros de avisos, e nem sempre os

anuncios disponibilizam todas as informacoes que seriam necessarias. Tambem, manter o

quadro atualizado e trabalhoso.

Quando se opta por listas de discussao on-line, tambem surgem alguns problemas.

Conversas iniciadas na lista podem acabar em conversas externas e os membros da lista

podem nao saber do estado atual de cada membro com relacao as suas caronas. As

pessoas geralmente nao recorrem ao historico de listas de discussao antes de enviar uma

mensagem. Isso gera muitas mensagens repetitivas e, com isso, muitos usuarios tendem a

abandonar a lista devido ao grande trafego de e-mails em suas caixas postais.

Uma alternativa as 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, porem obrigam o usuario a se cadastrar e utilizar

mais um site para um fim especıfico. Alem disso, pode ser que amigos que ja 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

sao realizadas tambem podem nao ser tao eficientes, pois encontram caronas baseadas

nas localidades de origem e destino, sem considerar outras informacoes como as coor-

15

denadas geograficas ao longo de toda a rota do motorista e potencial passageiro. Alem

disso, nao usam informacoes de transporte coletivo para sugerir respostas que possam ser

satisfatorias aos seus usuarios.

Os problemas aqui levantados nos levam a propor uma solucao alternativa, que se

beneficie das redes sociais ja populares e amplamente utilizadas, agregando-lhes uma nova

funcionalidade. Com essa abordagem, espera-se manter os usuarios em um ambiente a que

ja estejam familiarizados, sem obriga-los a migrar para um novo ambiente e construırem

uma nova rede social.

1.2 Objetivos

O objetivo geral deste trabalho e 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 usuarios do Orkut adicionem o aplicativo aos seus perfis e, a partir

disso, possam interagir com outros usuarios que tambem possuam o aplicativo. Dessa

maneira, sera possıvel cadastrar viagens detalhando seus trajetos e pontos de parada.

Sera possıvel, tambem encontrar caronas com base em coordenadas geograficas, alem de

poderem solicitar, aceitar ou recusar pedidos de carona. No caso de caronas realizadas,

os usuarios poderao se avaliar, atribuindo opinioes com relacao as suas experiencias.

Deseja-se ainda, combinar ofertas de caronas com informacoes do transporte publico

de BH. Com isso, quando nao houver rotas que passem proximas ao passageiro, sera

possıvel sugerir viagens compostas por caronas e onibus.

1.3 Justificativa

Podemos associar a pratica de caronas a solidariedade e confianca, praticadas na

maioria das vezes entre pessoas com habitos semelhantes, tais como ir a mesma faculdade

ou a mesma regiao da cidade. Portanto, caronas tem um potencial maior de ocorrer entre

pessoas de um mesmo grupo social.

Com base nesta ideia, escolhemos a rede social Orkut como ambiente para a im-

plantacao do aplicativo de caronas, uma vez que nessa rede ja estao formados lacos de

afinidade e confianca entre seus usuarios. Alem disso, 72% dos brasileiros que usam redes

16

sociais (26 milhoes de usuarios) estao no Orkut (EPOCA, 2010), o que o torna um dos

tres sites mais populares da Internet brasileira (ALEXA, 2010).

Outra justificativa para a abordagem escolhida e que ela pode se apresentar como uma

mudanca de paradigma com relacao aos sites de caronas existentes. Enquanto nas outras

solucoes “o usuario deve ir ate aonde o aplicativo esta”, nesta abordagem “o aplicativo

vai aonde o usuario ja esta”. Isso permite que o usuario utilize um novo recurso em um

ambiente que lhe e familiar.

17

2 Revisao da Literatura

2.1 Mobilidade Urbana

Segundo a BHTRANS (2008), mobilidade urbana e o conjunto de deslocamentos de

pessoas e bens, com base nos desejos e necessidades de acesso ao espaco urbano, por

meio da utilizacao dos diversos modos de transporte. O conceito de “gerenciamento da

mobilidade” tambem e tratado por Rocha et al. (2006), como a busca de um equilıbrio

mais estavel 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 petroleo (ROCHA et al., 2006 p. 4 apud BLACK, 2001).

O aumento populacional e o aumento da frota nas cidades causam uma disputa maior

pelos espacos urbanos, que nao crescem na mesma proporcao. A perda de tempo, a falta

de lugar para estacionar e a irritacao que os congestionamentos causam sao reflexos ne-

gativos do aumento da frota. Ainda, a poluicao causada pelos veıculos tambem aumenta,

causando danos tanto ao meio ambiente quanto a saude da populacao.

Varias cidades no mundo estudam polıticas e acoes para melhorias na qualidade de

vida da populacao por meio de uma mobilidade urbana sustentavel. A palavra sustentavel

aqui, extende o conceito de mobilidade urbana considerando “[...] a realizacao desses des-

locamentos sem comprometimento do meio ambiente, das areas e das atividades urbanas,

alem do proprio transporte” (BHTRANS, 2008).

Pode-se citar Londres, uma das cidades com plano de gerenciamento de mobilidade

mais difundido e consolidado, possuindo as seguintes estrategias: campanhas de conscien-

tizacao sobre viagens; ciclismo e caminhada; pedagio urbano; onibus e tramway (onibus

eletrico) gratis para menores de 16 anos; dirija de outra maneira (drive another way) e

zonas de baixa emissao. Para o objetivo deste trabalho, destaca-se o compartilhamento do

carro (car polling), que e uma das medidas compreendidas na estrategia “dirija de outra

18

maneira” (ROCHA et al., 2006). Tal medida permite que dois ou mais usuarios usufruam

do conforto de um mesmo automovel reduzindo o congestionamento e a poluicao.

Recentemente, em Sao Paulo, foram realizadas campanhas educativas para incentivar

a “carona solidaria”. Nessas acoes, realizadas pela Secretaria do Meio Ambiente, moto-

ristas que viajavam sozinhos recebiam a “multa legal”, uma intervencao ludica feita por

monitores, atores e voluntarios. O objetivo era fixar a ideia da importancia de se usar o

veıculo de forma mais consciente (GOVERNO DE SAO 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 e promover melhor qualidade de vida e desenvolvimento da cidade, susten-

tado nos princıpios de: acessbilidade, seguranca, eficiencia, qualidade de vida, dinamismo

economico, acao integrada e inclusao social. Dentre as diretrizes que o projeto visa aten-

der, pode-se destacar: considerar o modo a pe como prioritario; garantir o deslocamento

das pessoas em um transporte coletivo de qualidade; democratizar o uso do sistema viario,

inclusive com medidas de restricao do uso do automovel, quando necessario; construir

polıticas de estacionamento e distribuicao de mercadorias; estimular o uso de transporte

nao motorizado, especialmente bicicletas; e por fim, garantir a todos, idependentemente

da capacidade de pagamento ou locomocao, o direito de se deslocar e usufrir da cidade

com autonomia e seguranca (PLANMOB-BH, 2010).

2.2 Redes Sociais On-line

Redes sociais on-line podem ser definidas como um servico Web que permite in-

divıduos construırem um perfil publico ou semi-publico dentro desses sistemas, articulados

a uma lista de outros usuarios com os quais compartilham o mesmo ambiente e algumas

conexoes, percorrendo suas listas de conexoes e outras feitas por novos usuarios 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 ja alcancam

quase a soma de 1 bilhao de usuarios. Nesses ambientes virtuais, seus “habitantes” se

relacionam discutindo opinioes, compartilhando fotos, publicando anuncios, jogando, e

ate mesmo procurando novos amigos. A Figura 4 traz um panorama da distribuicao

dos usuarios 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 tres redes mais utilizadas

(EPOCA, 2010).

Figura 4: Presenca de usuarios brasileiros nas principais redes sociais (em milhoes)

Fonte: EPOCA, 2010

Varios tem sido os trabalhos publicados com foco no estudo de redes sociais. Pesqui-

sadores de diversas areas do conhecimento tem se interessado por entender a dinamica

das redes de pessoas, mostrando a importancia desse mecanismo de relacoes interpessoais

na vida moderna (BUYUKOKTEN et al. 2003; KUMAR et al. 2006).

Para os propositos deste trabalho, o aspecto mais importante e observar a capacidade

das redes sociais em disseminar e transformar o acesso a informacao, 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 nocao poderia ser entendida como: a capacidade de interacao dosindivıduos, seu potencial para interagir com os que estao a sua volta,com seus parentes, amigos, colegas de trabalho, [...]. Capital social sig-nificaria aqui a capacidade de os indivıduos produzirem suas propriasredes, 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 acao e de potencia cooperativa (COSTA,2005, p. 246 apud LEVY, 2002).

Todas essas ponderacoes a respeito das redes sociais certificam que sao uma preciosa

ferramenta de mediacao de comunicacao entre pessoas.

20

2.3 API Opensocial 0.8

A especificacao 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 socialFonte: OPENSOCIAL, 2010

Na Figura 5, ve-se o modelo de um aplicativo social e seus tres componentes principais:

cliente, container e o servidor do aplicativo. O cliente e a representacao do usuario

navegando no aplicativo. O container, por sua vez, e a propria rede social, nesse caso,

o Orkut. O papel do container e guardar o descritor do aplicativo (um arquivo XML) e

fornecer a capacidade de manipular seus “dados sociais”1. Por fim, o servidor do aplicativo

e um servidor Web, que contem todos os arquivos do aplicativo, como imagens, arquivos

CSS, Javascript e outros. Nesse servidor tambem estao as paginas responsaveis por ler e

gravar informacoes no banco de dados do aplicativo.

O ponto central para se desenvolver um aplicativo social e entender como ocorre o

fluxo de dados entre seus componentes. Utilizando como base, ainda a Figura 5, tem-se

a seguinte sequencia de operacoes:

1. O cliente (usuario) solicita ao container a visualizacao de um aplicativo. Nesse

momento e carregado o descritor do aplicativo.

2. Atraves de protocolo HTTP via AJAX, o container envia “dados sociais” ao servidor

do aplicativo, como o codigo do usuario seguido de alguma operacao que ele tenha

realizado, por exemplo “ofereceu uma carona de A ate B”.

3. O servidor do aplicativo recebe os dados sociais, alem dos dados de operacao e

armazena essas informacoes 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 atualizacoes na tela do aplicativo e exibe o resultado para o usuario.

1Dados sobre perfis de usuarios, lista de amigos, fotos e albuns, atualizacao de atividades na rede, etc.

21

Ate a conclusao deste trabalho, o Orkut era um container homologado para a versao

0.8 da API Javascript Opensocial.

2.4 JQuery 1.2.2

JQuery e uma biblioteca Javascript, de uso gratuito, que reune uma colecao de funcoes

que permitem aos desenvolvedores escreverem codigos Javascript de maneira rapida, efi-

ciente e compatıvel com os principais modelos de navegadores (JQUERY, 2010).

Nessa biblioteca, o desenvolvedor encontra funcoes para realizar animacoes em ele-

mentos de uma pagina HTML; trabalhar de forma simplificada em interacoes com AJAX ;

manipular eventos; e varias outras utilidades.

Outro benefıcio, alem de agilizar o desenvolvimento de aplicacoes Web, e a capacidade

de utilizar extensoes escritas e disponibilizadas por outros desenvolvedores. Atraves dessas

extensoes, e possıvel reutilizar solucoes que resolvam problemas recorrentes em uma tıpica

aplicacao Web, como validacao de formularios, exibicao de dicas de preenchimento de

campos, e muitos outros.

2.5 API Javascript Google Maps 2.0

A API Javascript Google Maps e disponibilizada de forma gratuita pelo Google aos

desenvolvedores que desejam incorporar o Google Maps em suas paginas.

Dentre os principais recursos fornecidos pela API pode-se destacar:

• Geocodificacao: um servico de consulta, no qual se informa um endereco e se recebe

como resposta informacoes detalhadas sobre tal endereco, incluındo suas coordena-

das geograficas;

• Caminhos: desenho de linhas sobre o mapa, informando o melhor caminho, a pe

ou de automovel, entre dois ou mais pontos. Alem disso, os caminhos contem

diversas informacoes uteis, como ruas percorridas, direcoes a serem seguidas, tempo

de viagem e distancia;

• Visualizacao: permite arrastar, ampliar ou reduzir o detalhamento do mapa;

• Representacao: permite posicionar marcadores de localidades, abrir janelas de in-

formacoes em marcadores.

22

Outro ponto caracterıstico da API Google Maps e seu funcionamento baseado em

interacoes via AJAX entre a aplicacao do usuario e os servidores do Google, onde esta

hospedada a API.

2.6 Plataforma LAMP

LAMP e 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 programacao). Essa combinacao tecnologica prove uma completa

infraestrutura para o desenvolvimento de aplicacoes Web. O fato de ser composta por

tecnologias gratuitas, faz dessa plataforma uma boa alternativa em relacao a tecnologias

comerciais como .NET e JEE (executando sobre servidores de aplicacao comerciais, como

Websphere ou Weblogic).

Ainda, apesar do L, na sigla, se referir ao sistema operacional Linux, uma aplicacao

LAMP pode ser facilmente portada para Windows ou Mac OS, com pouco ou ate mesmo

nenhum trabalho de alterar codigos na aplicacao.

2O “P” pode, as vezes, se referir a Perl ou Python.

23

3 Metodologia

Para se alcancar 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; obtencao dos itinerarios das

linhas de onibus de BH; implementacao; 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 restricoes: gratuidade, boa documentacao, curva de aprendizado reduzido e com-

patibilidade com navegadores a partir das versoes: Mozilla Firefox 3.2.0, Microsoft Inter-

net Explorer 7.0, Google Chrome 6.0 e Apple Safari 4.0.

Figura 6: Arquitetura da aplicacao

Atraves do desenho da arquitetura da aplicacao (Figura 6), ve-se as tecnologias ele-

gidas para desenvolvimento do aplicativo “Carro Cheio”. Sao elas: rede social Orkut,

API Javascript Opensocial, Plataforma LAMP, API Google Maps e biblioteca Javascript

JQuery. O uso de cada tecnologia sera abordado no decorrer desse capıtulo.

24

3.2 Desenho do Modelo de Dados

O modelo de dados do aplicativo e exposto na Figura 7, na qual sao apresentadas as

entidades que o compoem, bem como seus relacionamentos.

Figura 7: Diagrama do modelo de dados do aplicativo

Cada uma das entidades e descrita, brevemente, na Tabela 1.

Tabela 1: Descricao das tabelas do modelo de dados

Entidade Descricao

usuario Armazena os usuarios do aplicativo. Os registros sao inseridos nomomento que os usuarios adicionam o aplicativo em seu perfil.

rota Armazena as informacoes sobre rotas que os usuarios criam atravesdo aplicativo.

rota passo Armazena as coordenadas (latitude, longitude) de cada passo da rotado usuario, na sequencia em que ocorrem.

carona Armazena os pedidos de carona feitos por um usuario. Essa entidadecruza dois usuarios, uma rota e o passo da rota que foi solicitado.

onibus Armazena o cadastro das linhas de onibus, por exemplo: 1010, SC02,80.

onibus

itinerarios

Armazena os itinerarios de cada linha de onibus.

onibus

itinerarios

paradas

Armazena as coordenadas (latitude, longitude) de cada ponto de pa-rada do onibus no itinerario, na sequencia em que ocorrem.

3.3 Obtencao dos Itinerarios das Linhas de Onibus

de BH

No projeto conceitual do aplicativo foi denifido que, em algumas situacoes, quando um

usuario fizesse uma busca por caronas, os resultados sugeridos poderiam ser viagens mis-

25

tas, combinando trechos de onibus e trechos de automovel. Eis uma situacao hipotetica,

na qual viagens mistas podem ser sugeridas:

• Francisco procurou por uma carona. Ele sai da Praca da Liberdade, Savassi, Belo

Horizonte e deseja chegar ao campus da PUC, no bairro Sao Gabriel, em Belo

Horizonte.

• Alfredo ofereceu uma carona no aplicativo. Ele tambem vai para a PUC, no bairro

Sao Gabriel. Entretanto, Alfredo sai da Praca Sete, centro de Belo Horizonte.

• E uma distancia razoavel – cerca de 1,6 quilometros – para Francisco ir se encontrar

com Alfredo, se for a pe.

• Nesse cenario hipotetico, a busca deve ser capaz de sugerir a Francisco tomar o

onibus 4034 (Novo Dom Bosco / Savassi) para se encontrar com Alfredo, na Praca

Sete, e irem juntos ate o campus da PUC.

Para que essa funcionalidade seja possıvel, e necessario possuir uma base de dados

contendo as linhas de onibus de BH e seus itinerarios completos. Esses dados foram

obtidos em enderecos disponıveis no site da Empresa de Transportes e Transito de Belo

Horizonte – BHTRANS.

Primeiro, obteve-se o numero de cada linha de onibus atraves da pagina Quadro de

horarios1, ilustrada na Figura 8.

Figura 8: Pagina da BHTRANS com a relacao das linhas de onibus de Belo HorizonteFonte: BHTRANS, 2010

Em seguida, ainda no site da BHTRANS, foi consultado o itinerario de cada linha,

atraves da pagina Itinerario2.

Na Figura 9, ve-se a pagina com o resultado para a consulta a linha de onibus 101.

Nesse momento, cada endereco correspondente ao ponto de parada do onibus foi copiado

e formatado manualmente no arquivo itinerarios.txt.

1Disponıvel em: http://servicosbhtrans.pbh.gov.br/bhtrans/servicos eletronicos/

transporte qh info.asp.2Disponıvel em: http://servicosbhtrans.pbh.gov.br/bhtrans/servicos eletronicos/

transporte itinerario resultado.asp?linha=101.

26

Figura 9: Pagina de itinerarios no site da BHTRANSFonte: BHTRANS, 2010

Apos o arquivo itinerarios.txt ter sido preenchido com os itinerarios de todas as

linhas de onibus, 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

geografica. Para isso, foi utilizado o servico de geocodificacao do Google. Tal servico

e acessado atraves de uma requisicao HTTP, fornecendo como parametro o endereco a

ser geocodificado. Por exemplo, para obter as coordenadas do primeiro ponto da linha

de onibus 101 – Avenida Artur Bernardes 1580 – deve-se enviar a seguinte requisicao ao

servico de geocodificacao:

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 requisicao, o geocodificador retorna um arquivo em formato

XML, contendo varias informacoes a respeito do endereco solicitado. Para este tra-

balho, e util apenas as coordenadas geograficas do endereco, presentes entre as marcacoes

<coordinates></coordinates>. Para o endereco 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 servico de geocodificacao do GoogleFonte: GOOGLE, 2010

Apos processar todo o arquivo itinerarios.txt, o banco de dados foi populado com

os itinerarios de todas as linhas de onibus de BH. Alem disso, os pontos de embarque e

desembarque de cada onibus foram mapeados com suas coordenadas geograficas.

27

3.4 Implementacao

O escopo do aplicativo e apresentado atraves 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 e descrito, brevemente, na Tabela 2, possi-

bilitando uma visao geral sobre as funcionalidades do aplicativo. Adiante, nas subsecoes

3.4.2 e 3.4.3, os casos de uso cadastrar rotas e buscar rotas serao descritos em mais

detalhes. Os demais casos de uso serao ilustrados na subsecao 3.4.4, atraves das capturas

das telas desenvolvidas para cada um.

Tabela 2: Visao geral dos casos de uso do aplicativo

Caso de uso Descricao

Cadastrar

rota

Permite a um usuario, que possua automovel, cadastrar as suas rotas,detalhando os percursos atraves de um mapa. Em seguida essas rotasficarao disponıveis para serem encontradas nas buscas por caronas.

Buscar rota Usuarios interessados em encontrar uma carona, informam seus locaisde saıda e destino e o sistema encontra rotas uteis a ele.

Pedir carona Quando um usuario encontra uma rota que lhe interesse, ele podepedir ao motorista uma carona. O aplicativo entao envia ao moto-rista, um pedido vindo desse usuario com o ponto onde este desejaembarcar.

Visualizar

pedidos

Permite ao usuario visualizar todos os seus pedidos. Os pedidos saodividos entre pedidos enviados e pedidos recebidos.

Aceitar

pedido

Ao visualizar seus pedidos recebidos, um usuario pode aceitar umpedido. Esta acao equivale a aceitar um pedido de carona.

Recusar

pedido

Ao visualizar seus pedidos recebidos, um usuario pode recusar umpedido.

Avaliar

usuario

Permite avaliar o usuario positivamente ou negativamente. Cadausuario possui um contador de avaliacoes positivas e negativas.

Antes de continuar a descricao da implementacao do aplicativo, e necessario introduzir

o ambiente de testes de aplicativos do Orkut, chamado sandbox.

28

3.4.1 Orkut sandbox

O sandbox e uma versao do Orkut na qual os desenvolvedores podem instalar seus

aplicativos sociais e testa-los ate estarem prontos.

Figura 12: Pagina de registro no Orkut sandboxFonte: ORKUT, 2010

A Figura 12 mostra a pagina de registro no sandbox. O registro deve ser feito no

endereco http://sandbox.orkut.com/SandboxSignup.aspx. Apos realizar o registro, e

possıvel acessar o ambiente sandbox e realizar os testes no aplicativo.

O acesso ao ambiente sandbox e feito no endereco http://sandbox.orkut.com/. O

primeiro passo para implementacao do aplicativo foi submeter seu descritor inicial, cha-

mado aplicativo.xml, contendo informacoes basicas sobre autoria do aplicativo e as

bibliotecas que este utilizaria. A Figura 13 lista o conteudo do descritor do aplicativo.

Figura 13: Conteudo inicial do descritor do aplicativo

Como pode-se ver na Figura 13, o descritor se divide em duas secoes principais:

<ModulePrefs /> e <Content />. Na secao <ModulePrefs /> devem ser informados

os parametros de autoria e descricao do aplicativo. Nesta secao tambem informa-se ao

container quais bibliotecas de funcoes devem ser carregadas para o aplicativo. A secao

29

<Content /> e destinada a receber todo o conteudo do aplicativo. Nela devem ser colo-

cados todos os codigos HTML, Javascript e outros.

Para submeter o descritor ao sandbox, antes foi preciso envia-lo para o servidor do

aplicativo, atraves de um programa de FTP. O processo de submeter o descritor do

aplicativo e mostrado nas Figuras 14 e 15.

Figura 14: Pagina de submissao do aplicativoFonte: ORKUT, 2010

Figura 15: Pagina de confirmacao dos dadosFonte: ORKUT, 2010

Na Figura 14, ve-se a pagina de submissao de um novo aplicativo. No campo de texto e

informado o endereco publico do descritor do aplicativo, no caso deste trabalho, o descritor

publico se encontra no endereco http://www.carrocheio.com/aplicativo.xml3. Apos

clicar no botao add application, e carregada a pagina de confirmacao, ilustrada na

Figura 15. Nessa pagina sao exibidas as configuracoes informadas no descritor, como

nome e e-mail do autor, nome e descricao do aplicativo, alem das imagens de ıcone e de

captura de tela. Tambem e possıvel definir se o aplicativo tera acesso a informacoes dos

albuns de fotos e se suas atividades serao divulgadas aos amigos da rede social.

Apos clicar no botao save e confirmar a instalacao do aplicativo, este tornou-se dis-

ponıvel na lista de aplicativos do desenvolvedor. A partir da instalacao, o aplicativo entra

em processo de desenvolvimento, descrito na Figura 16.

Figura 16: Processo de desenvolvimento do aplicativo

3Foi feito o registro do domınio carrocheio.com e a contratacao da hospedagem, para viabilizar ainfraestrutura necessaria ao desenvolvimento da pesquisa.

30

O processo de desenvolvimento consiste nas seguintes etapas: sao feitas alteracoes

no codigo fonte do aplicativo, na estacao de trabalho do desenvolvedor. Os arquivos,

modificados e acrescentados ao projeto, sao enviados para o servidor do aplicativo atraves

de um programa de FTP (1). No sandbox, o pesquisador recarrega4 o aplicativo para

visualizar as alteracoes (2). O sandbox se comunica com o servidor do aplicativo para

obter a versao mais nova do descritor. Alem disso, tambem faz a requisicao de imagens,

arquivos Javascript, CSS e outros (3).

Apos uma visao geral do processo de desenvolvimento no Orkut sandbox, serao des-

critos em mais detalhes os casos de uso cadastrar rotas e buscar rotas.

3.4.2 Cadastrar rotas

Cadastrar uma rota e o mesmo que oferecer uma carona. Quando um usuario cadastra

uma rota, ele esta descrevendo um caminho que percorre de automovel.

Para cadastrar uma rota, o usuario deve escolher a opcao oferecer carona, na barra

de menus do aplicativo. Em seguida, sera apresentada ao usuario 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, botoes tracar rota e salvar esta rota, e finalmente, um mapa para

4Recarregar significa atualizar a tela do navegador com o aplicativo carregado na barra de enderecos.

31

exibir e ajustar a rota.

Os locais de partida e de chegada sao de preenchimento obrigatorio. O usuario, en-

tretanto, pode informa-los em diversos formatos, por exemplo: “Afonso Pena, 1000, Belo

Horizonte”, “Praca da Liberdade, Belo Horizonte”, “Estadio Mineirao, Belo Horizonte”.

A rota e desenhada no mapa com base nas coordenadas dos locais de partida e de che-

gada. Portanto, para obter tais coordenadas, e preciso submeter os locais informados

pelo usuario a um servico de geocodificacao. Como ja visto na secao 3.3, neste trabalho

utilizou-se o servico de geocodificacao do Google Maps.

Alguns locais podem gerar ambiguidade. Se informado “Cristiano Machado, Belo

Horizonte”, serao encontradas varias respostas para este local.

Figura 18: Tela do aplicativo: desambiguacao de locais

A Figura 18 ilustra esse caso. Nela, ve-se que ao clicar em tracar rota, foi encontrada

uma ocorrencia para “Praca da Liberdade, Belo Horizonte”, informada como local de

chegada. Entretanto, observando a Figura, ve-se que o aplicativo solicita ao usuario que

escolha o local de partida, dentre as seis opcoes retornadas pelo geocodificador. A rota

nao e tracada no mapa ate que o usuario clique em uma das opcoes apresentadas.

Supondo que o usuario escolha a quarta opcao – Ave Cristiano Machado, Cidade

Nova, Belo Horizonte – a rota e, entao, tracada no mapa (Figura 19).

Observando a Figura 19, ve-se que ao tracar uma rota no mapa, surgem tres novos

elementos na tela do aplicativo:

32

Figura 19: Tela do aplicativo: desenho da rota do motorista

1. Barra de status: contem informacoes sobre a distancia percorrida no caminho, alem

do tempo que seria gasto para percorre-la (considerando viagem de automovel).

2. Polilinha: uma linha contınua composta de varios segmentos. Cada inıcio e fim de

segmento possui uma coordenada geografica associada.

3. Marcadores: sao ıcones que determinam marcos em uma polilinha. No caso de rotas

recem criadas, marcam o inıcio e o fim do trajeto. Rotas modificadas pelo usuario

podem conter marcadores intermediarios, determinando desvios.

O caminho desenhado no mapa e determinado pela API Google Maps, atraves do

metodo loadFromWaypoints(waypoints:Array), da classe GDirections. Este metodo

recebe como parametro uma matriz, contendo dois ou mais pares de coordenadas (waypoints),

e desenha a polilinha sobreposta ao mapa. A rota mostrada na Figura 19 e obtida com a

seguinte chamada de metodo:

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 usuario percorre. Nesse caso, e preciso permitir ao usuario modificar a rota, movendo

pontos da polilinha para marcar os desvios necessarios. A API 2.0 do Google Maps nao

33

possui metodos nativos para arrastar e soltar vertices da polilinha. A Figura 20 e utilizada

para demonstrar como foi implementada a funcionalidade de modificacao de rotas.

Figura 20: Transicao de estados para a modificacao 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, e calculada sua distancia5 em relacao a polilinha. Se a distancia calculada

estiver abaixo de um valor arbitrado, o mapa passa para o estado 2. No estado 2, e exibido

um marcador temporario sobre o vertice da polilinha mais proximo ao cursor. O estado 3

representa o marcador temporario sendo arrastado pela superfıcie do mapa. Ao ser solto, o

marcador inicia o estado 4. No estado 4, a coordenada do marcador temporario e inserida

na matriz de waypoints. Em seguida, o metodo loadFromWaypoints(waypoints:Array)

e chamado para redesenhar a rota.

Para salvar a rota, deve-se clicar no botao salvar esta rota. Em seguida, a janela

salvar uma nova rota sera exibida para o usuario (Figura 21).

Figura 21: Tela do aplicativo: salvar uma nova rota

Nessa janela, o usuario deve informar um tıtulo para a rota, alem dos dias e horarios

em que repete o trajeto. Ao clicar no botao concluir, a rota e finalmente gravada no

banco de dados. Uma rota e gravada da seguinte maneira: e inserido um registro na tabela

rota, com o codigo do usuario, o tıtulo da rota e suas informacoes de dias e horarios.

5Esse calculo e realizado pela biblioteca Javascript BdccGeo.js (CHADWICK, 2007).

34

Na tabela rota passo sao inseridos registros relacionados a rota criada. Cada registro

armazena a coordenada referente a um vertice da polilinha (Figura 22).

Figura 22: Registros na tabela rota passos

A Figura 22 mostra os oito primeiros passos de uma rota. Na Figura, ve-se a coluna

id rota. A coluna id rota relaciona um passo a uma rota. Nesse caso, os passos sao

relacionados a rota de numero 26. As colunas lat e lon se referem a latitude e a longitude

do passo. Por fim, a coluna passo final recebe o valor 1 se for o ultimo passo da rota.

A coluna passo final e util para o metodo de busca de caronas, apresentada na secao a

seguir.

3.4.3 Buscar rotas

Nesta secao sera apresentado o metodo utilizado para buscar rotas. Como visto, na

secao 3.4.2, uma rota e uma sequencia de passos, realizados para se cumprir um trajeto.

Tambem foi visto que os passos sao armazenados no banco de dados com suas coordenadas

geograficas. A Figura 23 representa esse conceito graficamente.

Figura 23: Representacao grafica dos dados de uma rota

35

3.4.3.1 Fluxo de dados da busca por rotas

Para encontrar ofertas de caronas, o usuario deve acessar a opcao pedir carona, no

menu de opcoes do aplicativo (Figura 24).

Figura 24: Tela do aplicativo: tela de janela de busca de rotas

Na janela de busca de rotas ha tres campos que devem ser informados pelo usuario:

local de saıda; local de destino; e a distancia maxima que se deseja caminhar ate o

embarque e o destino. Ao acionar o botao 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

sequencia de operacoes:

1. Os locais de saıda e de chegada sao enviados ao servico de geocodificacao do Google

Maps, via Javascript e HTTP.

2. O servico de geocodificacao do Google Maps retorna a geocodificacao dos locais,

contendo suas coordenadas geograficas.

3. As coordenadas geograficas dos locais de saıda e de chegada sao enviadas como

parametros para a pagina de busca de rotas, no servidor do aplicativo. Esse processo

tambem ocorre via Javascript e HTTP.

36

4. A pagina de busca de rotas responde com um objeto em formato JSON, contendo as

rotas encontradas ou contendo uma rota vazia, no caso de nao encontrar nenhuma

rota compatıvel.

3.4.3.2 Calculo da distancia linear entre dois pontos na Terra

Na busca por rotas, e necessario calcular a distancia linear entre dois pontos na

Terra, dadas as suas latitudes e longitudes. Para esse proposito, utilizou-se a Formula de

Haversine6, a qual foi mapeada em uma funcao escrita em linguagem PHP mostrada na

Figura 26.

Figura 26: Funcao de calculo da distancia linear entre dois pontos na Terra

3.4.3.3 Heurıstica de busca por rotas

A Figura 27 a seguir, mostra um cenario hipotetico.

Figura 27: Heurıstica de busca: cenario hipotetico

Nesse cenario, ha quatro rotas cadastradas no banco de dados. Essas rotas sao re-

presentadas na Figura 27 atraves dos segmentos A-A’, B-B’, C-C’, D-D’. O sentido de

6A formula de Haversine e uma importante equacao usada em navegacao, fornecendo distancias entredois pontos de uma esfera a partir de suas latitudes e longitudes. (FORMULA DE HAVERSINE, 2010)

37

cada rota e denotado por uma letra (A), como ponto de origem; e uma letra seguida de

apostrofo (A’), como ponto de chegada. A necessidade do usuario e representada pelos

pontos I, como local de partida, e F, como local de chegada. Por fim, os cırculos r in-

dicam a distancia maxima que o usuario deseja andar ate o embarque ou ate o seu local

de chegada. A distancia maxima sera citada como d max, no decorrer da apresentacao da

heurıstica.

Na primeira iteracao, a heurıstica procura por rotas que possuam algum passo a uma

distancia menor que d max, em relacao ao ponto de chegada do usuario (F). Para todas as

rotas encontradas, utiliza-se apenas o passo com a menor distancia ate F. Apos a primeira

iteracao, sao encontradas as rotas B-B’, C-C’ e D-D’, conforme ilustrado na Figura 28.

Figura 28: Heurıstica de busca: primeira iteracao

A segunda iteracao e feita entre as rotas encontradas na primeira iteracao. Nessa

iteracao, a heurıstica seleciona rotas que possuam um passo a uma distancia maxima

de 2d max7 do ponto I8. Alem disso, o passo deve ser anterior ao passo encontrado na

primeira iteracao. Essa restricao elimina a rota C-C’ das respostas (Figura 29).

Figura 29: Heurıstica de busca: segunda iteracao

7A razao de se ampliar a distancia maxima e encontrar rotas mais distantes, mas que possam seralcancadas de onibus.

8Para 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 usuario.

A heurıstica considera, entao, a rota D-D’ como otima. Entretanto, a rota B-B’ possui

um ponto de embarque a uma distancia maior do que d max. Para essa rota, a heurıstica

consulta a base de dados de itinerarios de onibus e procura por alguma linha que passe

proximo ao ponto I, chegando proximo ao ponto B. Se a heurıstica nao encontrar uma

linha de onibus, a rota e descartada. Caso contrario, a rota e mantida no conjunto de

respotas e o onibus encontrado e incluıdo na resposta, gerando uma rota mista (Figura

30).

Figura 30: Heurıstica de busca: busca por onibus

Na Figura 30, o segmento pontilhado O-O’, representa o trecho a ser cumprido em

uma viagem de onibus, chegando proximo 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 secao sao ilustradas as telas dos seguintes casos de uso: pedir carona, visualizar

pedidos, aprovar pedido, recusar pedido e avaliar usuario.

39

O caso de uso pedir carona e ilustrado atraves da Figura 32, na qual pode-se ver a

janela de pedido de carona. Essa janela se abre no momento em que o usuario escolhe a

opcao pedir carona, na tela de busca de caronas (Figura 36).

Figura 32: Tela do aplicativo: enviar pedido de carona

Na Figura 33 e ilustrada a tela correspondente aos seguintes casos de uso: visualizar

pedidos, aceitar pedidos e recusar pedidos. Ve-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 indicacao do local no qual o passageiro deseja embarcar, e as opcoes

aceitar e recusar pedido.

Figura 33: Tela do aplicativo: visualizar, aceitar e recusar pedidos

Na Figura 34 e apresentada a tela para o caso de uso avaliar usuario. Nota-

se a relacao de todas as rotas cadastradas pelo motorista. Uma rota, em especıfico,

aparece expandida, relacionando seus passageiros (nesse caso, Jack). Atraves 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 informacoes sobre o

usuario em questao, contendo quantas classificacoes 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 estarao disponıveis as mesmas operacoes.

Figura 34: Tela do aplicativo: avaliar usuario

41

4 Resultados

Neste capıtulo, sao apresentados os resultados obtidos nos testes realizados no apli-

cativo Carro Cheio. Para a avaliacao a sua eficiencia, seus resultados foram comparados

aos resultados dos mesmos testes, realizados em sistemas similares.

4.1 Preparacao do Ambiente de Testes

Para se testar o Carro Cheio, adicionou-se o aplicativo a dois perfis de usuarios no

Orkut. Considere, como exemplo os usuarios de Jack e Beth. Jack oferece uma carona,

enquanto Beth, procura uma carona.

Atraves do perfil de Jack, cadastrou-se uma rota (R), saındo da Avenida Afonso Pena,

5100 e chegando a Avenida Afonso Pena, 1. Trata-se de um percurso de aproximadamente

4 quilometros, segundo o Google Maps (Figura 35).

Figura 35: Rota utilizada nos testes testes

Em seguida, foram realizadas quatro buscas por caronas, atraves do perfil de Beth.

Os parametros de entrada estao listados na Tabela 3.

Tabela 3: Parametros de buscas por caronas

# Local de saıda Local de chegada

1 Rua Ramalhete, 100 Rua dos Tupinambas, 5002 Rua dos Tupinambas, 500 Rua Ramalhete, 1003 Av. Afonso Pena, 1500 Rua dos Tupinambas, 5004 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 papeis de motorista e passageira, respectivamente. Para as buscas realizadas

42

no Carro Cheio e Caroneiros, foi definido um raio de abrangencia de 500 metros. No

Bigoo esse parametro nao 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 geograficas na busca, uma vez

que os locais de saıda e de chegada de Beth sao proximos aos de Jack, mas nao

contem as mesmas palavras-chave.

• Teste 2: avalia se o mecanismo e capaz de considerar o sentido da rota do motorista.

• Teste 3: avalia se o mecanismo e capaz de considerar pontos intermediarios na rota

do motorista.

• Teste 4: avalia como o mecanismo trata casos nos quais Beth esta relativamente

longe do ponto mais proximo a Jack.

4.2 Avaliacao dos Resultados

Apos a realizacao 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. Ja o site Caroneiros nao encontrou a rota de Jack na terceira consulta. Apos

refazer a terceira consulta ampliando o raio para 2 quilometros, 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 tres sistemas testados, o Carro Cheio e o unico 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 ve, 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 a frente de seu endereco de saıda, a menos de 100 metros. Essa imprecisao

deve-se ao fato de que as rotas nao sao gravadas com todas as suas coordenadas. Como

citado na secao 3.4.2, as rotas sao gravadas apenas com as coordenadas de inıcio e fim de

cada segmento da Polilinha.

Atraves do teste 4, foi possıvel validar a integracao do Carro Cheio com o transporte

coletivo de Belo Horizonte. Nesse teste, o endereco de saıda de Beth (Av. Bandeirantes,

800) esta ha mais de 1 quilometro de distancia do ponto mais proximo a Jack. Nesse caso,

o Carro Cheio foi capaz de sugerir o onibus 9106 a Beth, para que ela se encontre com

Jack proximo a 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, ve-se a janela de representacao grafica da carona sugerida. Na janela

e apontado o local de origem de Beth e seu caminho ate Jack. Arrastando a tela do

mapa, seria possıvel ver o restante do trajeto, alem do ponto de desembarque de Beth.

Complementando, no teste 4, tanto o Bigoo quanto o Caroneiros nao encontraram a rota

de Jack.

44

5 Conclusao

Neste trabalho foi realizada a pesquisa e desenvolvimento do aplicativo Carro Cheio.

Atraves do Carro Cheio, procurou-se alcancar o objetivo de se fornecer um sistema efi-

ciente para combinar caronas atraves do Orkut. Ainda, tentou-se suprir no Carro Cheio,

as deficiencias encontradas em outros sistemas com o mesmo proposito. A avaliacao 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 nao foram suficientes para afirmar que o Carro Cheio surge

como o melhor sistema de caronas, dentre os tres. Para afirmar isso, seria necessario sub-

meter os tres sistemas a testes mais abrangentes, com uma massa significativa de usuarios,

e avaliar suas impressoes.

Por outro lado, atraves dos testes, foi possıvel verificar caracterısticas onde o Carro

Cheio, de fato, conseguiu suprir deficiencias 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

atraves de coordenadas geograficas; e integrar resultados com informacoes do transporte

coletivo de Belo Horizonte.

Vale ressaltar, entretanto, alguns estudos que podem ser realizados futuramente, para

tornar o aplicativo mais eficiente. Uma avaliacao de usabilidade poderia apontar medidas

a serem tomadas para tornar o uso do aplicativo mais intuitivo. Alem disso, o formulario

de cadastro de rotas pode ser ampliado com mais informacoes. Com relacao a heurıstica

de busca, pode-se se estudar a integracao dos resultados com o transporte ferroviario.

Alem disso, pode-se melhorar a precisao das buscas atraves do uso de interpolacao dos

pontos das rotas. Por fim, o uso de agentes inteligentes em versoes futuras, pode trazer

novas funcionalidades ao aplicativo.

45

Referencias

ABREU, N. R. de; BALDANZA, R. F.; SETTE, R. de S. Comunidades virtuais comoambiente potencializador de estrategias mercadologicas: Locus de informacoes e troca deexperiencias. Perspectivas em Ciencia da Informacao, v. 13, n. 3, p. 116-136, set./dez.2008.

AJAX. In: WIKIPEDIA: a enciclopedia livre. Wikimedia, 2006. Disponıvel emhttp://pt.wikipedia.org/wiki/AJAX (programac~ao). Acesso em: 01 maio de 2010.

AGENCIA MINAS. Projeto Melhorar incentiva a carona solidaria em Minas. MinasGerais, 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 ofPsychology, v. 55, p. 573-590, feb. 2004.

BELO HORIZONTE. Estatısticas e Mapas / Demografia. Disponıvel emhttp://portalpbh.pbh.gov.br/pbh/ecp/comunidade.do?app=estatisticas.Acesso em 01 maio 2010.

BHTRANS, Empresa de Transportes e Transito de Belo Horizonte. Apresentacaosobre mobilidade urbana e acessibilidade. Seminario de Consolidacao da Rede CidadesInterativas: Mobilidade Urbana, Acessibilidade e Governo Eletronico. Natal, RN, mar.2008.

BIGOO. Bigoo. Disponıvel em http://www.bigoo.com.br/. Acesso em 01 novembro2010.

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 Sustentavel – Responsabilidade e compromisso de todos.Governo do Brasil. Disponıvel em http://www.cop15brasil.gov.br/pt-BR/. Acessoem 01 maio 2010.

BUYUKKOKTEN, O.; ADAMIC, L. A.; AIDAR, E. A social network caught in theWeb. First Monday, v. 8, n. 6, june 2003.

CARONEIROS. Caroneiros.com - Encontrei aqui sua carona!. Disponıvel emhttp://www.caroneiros.com/. Acesso em 01 novembro 2010.

46

COSTA, R. Por um novo conceito de comunidade: redes sociais, comunidades pessoaise inteligencia coletiva. Interface - Comunicacao, Saude, Educacao, v.9, n.17, p.235-248,mar./ago. 2005.

CHADWICK, B. Bill Chadwick’s Google Maps Demos. Disponıvel emhttp://www.bdcc.co.uk/Gmaps/BdccGmapBits.htm. Acesso em 01 maio 2010.

DENATRAN, Departamento Nacional de Transito. Frota de veıculos. Disponıvel emhttp://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 ofComputer-Mediated Communication, v. 12, n. 4, article 1, 2007.

EPOCA. O poder e o risco das redes sociais. Globo, n. 628, p. 79-113, maio 2010.

FORMULA DE HAVERSINE. In: WIKIPEDIA: a enciclopedia livre. Wikimedia, 2006.Disponıvel em pt.wikipedia.org/wiki/Formula de Haversine. Acesso em: 01 maiode 2010.

GOOGLE. Referencia da API do Google Maps. Disponıvel emhttp://code.google.com/intl/pt-BR/apis/maps/documentation/javascript/v2/

reference.html. Acesso em 01 de maio 2010.

GOVERNO DE SAO PAULO. Mutirao da carona incentiva transporte solidario.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 populacao 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 emhttp://www.jquery.com. Acesso em: 01 maio de 2010.

JSON. In: WIKIPEDIA: a enciclopedia livre. Wikimedia, 2006. Disponıvel emhttp://pt.wikipedia.org/wiki/JSON. Acesso em: 01 maio de 2010.

JUNGBLUT, A. L. A heterogenia do mundo on-line: Algumas reflexoes sobrevirtualizacao, comunicacao mediada por computador e ciberespaco. HorizontesAntropologicos, 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 socialnetworks. 12th ACM SIGKDD International Conference on Knowledge Discovery andData Mining, Philadelphia, EUA, aug. 2006.

MARTELETO, R. M.; SILVA, A. B. de Oliveira e. Redes e capital social: o enfoque dainformacao para o desenvolvimento local. Ciencia da Informacao, Brasılia, v. 33, n. 3,set./dez. 2004.

47

NOBRE, C. A. Aquecimento global e o papel do Brasil. Ciencia Hoje, Rio de Janeiro, v.36, n. 211, p. 38-40, dez. 2004.

OPENSOCIAL. Opensocial JavaScript API Reference. Disponıvel emhttp://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 emhttp://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 emhttp://www.planmobbh.com.br/. Acesso em 01 maio 2010.

ROCHA, A. C. B. et al. Gerenciamento da mobilidade: Experiencias em Bogota, Londrese alternativas pos-modernas. Pluris 2006 Congresso Luso Brasileiro para o planejamentourbano, regional, integrado e sustentavel, Portugal, 2006.

SOUDERS, S. Even Faster Web Sites. O’Reilly, ed. 1, june 2009.

WILLIAMS, M. Google Maps API Tutorial. Disponıvel emhttp://econym.org.uk/gmap/. Acesso em 01 maio 2010.

TCC_2010_2_Fernando_Figueiredo_Torres

Documents

Transcript of TCC_2010_2_Fernando_Figueiredo_Torres