InfoBUS anyWhere - Aplicação móvel para consulta detransportes públicos
André Filipe Ramos Levita
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
JúriPresidente: Prof. Doutor José Manuel Nunes Salvador TriboletOrientador: Prof. Doutor Ricardo Jorge Feliciano Lopes PereiraCo-orientador: Doutor António Brandão LealVogais: Prof. Doutor Alexandre Paulo Lourenço Francisco
Novembro 2012
Agradecimentos
Quero agradecer ao meu orientador, Professor Ricardo Pereira, por toda a sua orientação, apoio
e disponibilidade prestados durante este último ano. Ao meu co-orientador da Tecmic, Professor
António Brandão Leal, e aos colaboradores da empresa Ricardo Ramos, Luís Pedro, Ricardo
Pedro e João Ribeiro pelo apoio prestado no enquadramento dos produtos da Tecmic e na
utilização de novas tecnologias.
Quero agradecer também à minha família pelo apoio emocional e financeiro prestado não só
durante o desenvolvimento da tese de mestrado mas também durante a realização do curso.
Por fim quero agradecer aos meus amigos que me acompanharam durante a realização da tese,
com um agradecimento em especial aos meus colegas Marta Santos e Diogo Morgado.
i
Abstract
InfoBUS anyWhere extends the Tecmic product XTraN Passenger designed for real-time monito-
ring of a public transportation fleet activity. InfoBUS anyWhere presents the information stored in
XTraN Passenger to a mobile environment. Users can access arrival time prediction of transports
or any kind of information regarding stations, schedules or transport lines. The developed sys-
tem also provides an automated process for planning a trip using only the public transportation
network. This process uses arrival time prediction of transports and some preferences specified
by the user for determine the most suitable plan. Users can then execute the trip plan in the
mobile application and be notified about the plans details and events.
Keywords: public transports, mobility, XTran Passenger, trip planning
iii
Resumo
O produto desenvolvido pela Tecmic, denominado por XTraN Passenger, é um sistema orientado
para a gestão inteligente de frotas, acompanhando em tempo real a atividade de uma frota de
transportes públicos. O XTraN Passenger agrega também informação relativa a paragens, linhas
de transporte, horários e previsões de chegada em tempo real dos autocarros às paragens. No
entanto, toda a informação gerida apenas é acessível através da Web, servindo pedidos sem
noção do contexto do utilizador.
O objetivo deste trabalho é disponibilizar toda a informação em ambiente móvel através do de-
senvolvimento de uma aplicação móvel nativa, que usufrua de funcionalidades do dispositivo mó-
vel, como a sua localização. O sistema desenvolvido, que dá pelo nome de InfoBUS anyWhere,
fará parte da plataforma XTraN Passenger, sendo integrado como um módulo adicional.
É também objetivo deste trabalho, automatizar o processo de planear uma viagem utilizando
a rede de transportes públicos e disponibilizar tal funcionalidade na aplicação móvel. O com-
ponente responsável pela determinação dos planos de viagem, denominado por Simulador de
Viagem, contemplará informação em tempo real, como os atrasos dos autocarros, e outras prefe-
rências do utilizador. Após a obtenção de um plano de viagem na aplicação móvel, esta permitirá
o acompanhamento em tempo real da execução do plano. Notificando o utilizador de diversos
eventos como a chegada do respetivo autocarro à paragem.
Keywords: transportes públicos, mobilidade, XTran Passenger, planeamento de viagem
v
Conteúdo
Agradecimentos i
Abstract iii
Resumo v
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Conceitos Fundamentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Tecmic - XTraN Passenger . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Trabalho Relacionado 7
2.1 Advanced Public Transportation Systems(APTS) . . . . . . . . . . . . . . . . . . . 7
2.2 Simuladores de viagem nos APTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Algoritmos e modelos de dados do simulador de viagem . . . . . . . . . . . . . . . 15
2.4 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Arquitetura 23
3.1 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
vii
3.2 XTraN Passenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Servidor de Estimativa de Tempos . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Componentes do Sistema InfoBUS anyWhere . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2 Servidor InfoBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.3 Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Implementação 35
4.1 XTraN Passenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1 PassengerDAL(Domain Access Layer) . . . . . . . . . . . . . . . . . . . . . 35
4.1.2 Servidor de Estimativa de Tempos . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Estrutura de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Camada de Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Camada Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4 Algoritmo dos Melhores Planos de Viagem . . . . . . . . . . . . . . . . . . 40
4.3 Servidor InfoBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.1 Camada de Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Camada Lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 Estrutura de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.2 Menus de Interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Avaliação 53
5.1 Algoritmo do Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1 Tempo de Inicialização e Análise dos Dados . . . . . . . . . . . . . . . . . 54
5.1.2 Pedidos ao Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . 54
viii
5.1.3 Planos de Viagem Detalhados . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.4 Conjugação de Resultados com o Servidor de Estimativa de Tempos . . . 57
5.2 Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.1 Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2 Duração Pedido-Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.3 Acompanhamento de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Conclusão 65
6.1 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Bibliography 69
Appendix 73
A Imagens da Aplicação Móvel 73
B Resultado dos Testes 83
ix
Lista de Tabelas
2.1 Sumário de sistemas Advanced Public Transportation Systems (APTS) com simu-
lador de viagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Sumário dos algoritmos para o simulador de viagem . . . . . . . . . . . . . . . . . 21
5.3 Construção das estruturas de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 55
xi
Lista de Figuras
2.1 MyBus - Estimativas de tempos[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 TAD - Interface da aplicação do dispositivo móvel [2] . . . . . . . . . . . . . . . . . 9
2.3 OneBusAway - Interface da aplicação do dispositivo móvel[3] . . . . . . . . . . . . 12
2.4 PATH2Go - Interface da aplicação do dispositivo móvel[4] . . . . . . . . . . . . . . 14
3.5 Casos de uso - Utilizador do aplicação móvel . . . . . . . . . . . . . . . . . . . . . 25
3.6 XTraN Passenger - Modelo de dados relacional . . . . . . . . . . . . . . . . . . . . 27
3.7 Arquitetura de alto nível . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Arquitetura de lado servidor: Servidor InfoBUS e Simulador de Viagem . . . . . . 30
3.9 Arquitetura da aplicação móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.10 Diagrama de sequência - Interação entre componentes . . . . . . . . . . . . . . . 33
4.11 Estrutura de Dados - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . 37
4.12 Controladores - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.13 Estrutura de Dados - Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . 47
4.14 Acompanhamento de Viagem - Máquina de estados . . . . . . . . . . . . . . . . . 52
5.15 Máquina de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.16 100 Pedidos ao Simulador de Viagem . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.17 Resultados dos Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.18 Resultados da Duração Pedido-Resposta . . . . . . . . . . . . . . . . . . . . . . . 61
5.19 Teste do acompanhamento de viagem . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.20 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.21 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
xiii
A.22 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.23 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.24 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
A.25 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.26 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.27 Imagens da Aplicação Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.28 Resultados detalhados do Simulador de Viagem (Dados de entrada e 1º plano) . . 84
B.29 Resultados detalhados do Simulador de Viagem (2º e 3º plano) . . . . . . . . . . . 85
xiv
Lista de Acrónimos
API Application Programming Interface
APTS Advanced Public Transportation Systems
ATIS Advanced Traveler Information Systems
AVL Automatic Vehicle Location
FIFO First In First Out
FMS Fleet Management Systems
GIS Geographic Information System
GPS Global Positioning System
GTFS General Transit Feed Specification
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
ORM Object-Relational Mapping
PDA Personal Digital Assistant
REST Representational State Transfer
SOAP Simple Object Access Protocol
SQL Structured Query Language
TAD Travel Assistent Device
URI Uniform Resource Identifier
WAP Wireless Application Protocol
WML Wireless Markup Language
WWW World Wide Web
xv
Capítulo 1
Introdução
1.1 Motivação
A utilização em massa dos transportes públicos em detrimento do transporte através do automó-
vel pessoal, permite uma redução em termos de congestionamento, consumo de combustível e
emissão de gases poluentes [5, 6]. Contudo, tais factos não superam a relutância de uma
parte da população em efetuar a transição em completo para o sistema de transportes públi-
cos, muito devido à complexidade do sistema ou à falta de informação necessária. Por outro
lado, utilizadores regulares dos transportes públicos são confrontados com determinados pro-
blemas provenientes da utilização do sistema. Algumas das agências responsáveis por gerir e
disponibilizar toda a informação do seu negócio, não conseguem abranger todas as paragens
ou lugares críticos de passagem com a informação necessária para qualquer utilizador. Além
disso, a disponibilização da informação em tempo real relativa a atrasos ou cancelamento de
carreiras, encontra-se apenas em sítios estratégicos e de grande tráfego. Esta é disponibilizado
através do uso de painéis eletrónicos, tornando-se assim, economicamente dispendiosa para
abranger todos as paragens e locais de negócio. Ao existir um incumprimento parcial dos horá-
rios definidos para os transportes públicos, surge a necessidade de alertar os seus utilizadores,
independentemente da paragem ou lugar em que se encontram. A utilização da informação em
tempo real poderá traduzir-se numa redução de tempos de espera ou na consideração de alter-
nativas mais rápidas.
Muitos utilizadores são confrontados com a necessidade de se deslocarem entre pontos geográ-
ficos com recurso aos transportes públicos. A tarefa de planear uma viagem deste tipo poderá
tornar-se complicada e demorada devido ao leque de opções existentes e da necessidade de
1
2 CAPÍTULO 1. INTRODUÇÃO
consultar toda a informação relevante. A complexidade do plano aumenta quando é necessá-
rio envolver o uso de mais do que uma linha de transporte. Assim, a consulta de informação
relativa a paragens, pontos de transbordo entre carreiras e horários para traçar um plano de
viagem, traduz-se num processo difícil e com a possibilidade dos resultados serem inadequados
ou pouco eficientes em termos de tempo ou custo total. Para mais, não é possível contemplar
os atrasos em tempo real dos transportes públicos incluídos no plano de viagem traçado.
1.2 Enquadramento
Nesta secção é apresentado o sistema atual de gestão e monitorização dos transportes públicos
desenvolvido pela Tecmic1, o XTraN Passenger. Para compreender este sistema é necessário
introduzir alguns conceitos fundamentais e as técnicas mais usadas nos sistemas de informação
de apoio à utilização de transportes públicos.
1.2.1 Conceitos Fundamentais
Para desenvolver um sistema de informação geográfica Geographic Information System (GIS)
que permita modelar todo o negócio de um sistema de transportes públicos, é necessário recor-
rer ao uso de tecnologias dos sistemas APTS[7, 8]. O principal propósito destas tecnologias é
providenciar aos utilizadores uma quantidade superior de informação, com maior facilidade de
acesso, relativa à rede de transportes públicos. Entre outras categorias dos sistemas APTS,
destacam-se duas:
• Advanced Traveler Information Systems (ATIS): Utilização de tecnologias de informação
para fornecer informações dos transportes públicos aos utilizadores em casa, no trabalho,
na beira da estrada, no próprio transporte, nas paragens, etc. Os utilizadores podem ace-
der em tempo real a horários e informações de congestionamento através de telefones,
painéis de mensagem variável, quiosques ou através da World Wide Web (WWW). O prin-
cipal objetivo é providenciar informação mais completa e de diversas formas para que os
utilizadores, habituais ou ocasionais, possam escolher de forma apoiada o seu transporte.
• Fleet Management Systems (FMS): Gestão e controlo da frota em tempo real recorrendo
ao uso de tecnologias de informação. A tecnologia mais usada para os transportes públicos
é o Automatic Vehicle Location (AVL). Este sistema é constituído por vários terminais a
bordo de cada veículo, que permitem a medição em tempo real da posição utilizado o
1http://www.tecmic.pt (Acedido em Agosto 2012)
1.2. ENQUADRAMENTO 3
sistema Global Positioning System (GPS). Posteriormente, essa informação é transmitida
para um sistema central.
Devido à grande evolução tecnológica que possibilitou o uso de dispositivos móveis como fer-
ramentas para o acesso à Internet e com capacidades de realizar tarefas com alguma carga
computacional, é agora possível aceder a estes sistemas de informação num contexto móvel.
A grande vantagem da utilização de dispositivos móveis, para além da sua mobilidade, advém
da utilização do GPS para identificar a posição do utilizador [9]. Desta forma, o contexto do
utilizador é transmitido para o sistema central facilitando a eliminação de informação irrelevante.
1.2.2 Tecmic - XTraN Passenger
A Tecmic é uma empresa Portuguesa fundada em 1988 que tem como principal objetivo o desen-
volvimento de soluções para a gestão inteligente de frotas. O XTraN Passenger é uma solução
completa e poderosa que permite acompanhar em tempo real toda a atividade da frota de trans-
porte públicos, comunicar por voz e dados com o tripulante, determinar e comunicar a previsão
de chegada dos próximos autocarros às paragens assim como informar o utilizador dos transpor-
tes públicos sobre tempos de espera através de diversos canais. O sistema XTraN Passenger
recorre ao uso de tecnologias FMS como o AVL para obter a localização da sua frota e também
a tecnologias ATIS para providenciar informação da sua frota aos utilizadores sobre diversos
canais.
O XTraN Passenger é constituído por uma plataforma modular da qual fazem parte os seguintes
módulos: Informer, uma plataforma multi-canal que fornece informação de previsões de che-
gada de forma precisa e em tempo real aos passageiros através de mensagens SMS, painéis
eletrónicos ou da WWW; Counter, um sistema inteligente de contagem de passageiros que
utiliza uma inovadora tecnologia de monitorização de movimentos; Eco-driver, que permite o
controlo de eficiência energética da condução tendo em vista a redução do consumo de com-
bustível e o aumento do conforto e segurança dos passageiros; e Infotainer, que providencia
informação dinâmica a bordo do transporte relativa ao serviço, fornecendo entretenimento e
publicidade baseada na localização.
4 CAPÍTULO 1. INTRODUÇÃO
1.3 Objetivos
É necessário um sistema que informe os utilizadores da rede de transportes públicos, em am-
biente móvel, de toda a informação gerida pela empresa Tecmic relativa a paragens, linhas de
transporte, transportes em movimento, horários, atrasos e previsões de chegada dos transpor-
tes às paragens. Para o âmbito deste projeto, apenas serão utilizados os dados colecionados
e geridos para zona do Chapecó, Santa Catarina - Brasil. No entanto deverá ser incorporada
a extensibilidade para outras agências colaboradores da Tecmic como a Carris - Transportes
Públicos de Lisboa1. Este sistema deverá ser incorporado no módulo XTraN Passenger.
Todo o processo para determinar um plano de viagem deverá ser automatizado, apresentando
ao utilizador em ambiente móvel, diversas alternativas para a sua deslocação entre um ponto de
origem e um ponto de destino. Deverão ser considerados dois tipos de deslocação, pedestre e
de autocarro, mas deverá ser incorporada a extensibilidade para outros tipos. Cada plano obtido,
deverá ser constituído por um conjunto de paragens e transportes a utilizar. Para o cálculo dos
planos de viagem, deverão ser considerados fatores como o tempo de viagem, o número de
transbordos e a distância pedestre realizada.
Após a obtenção de um plano de viagem, deverá ser possível um acompanhamento de viagem
em tempo real do mesmo. A aplicação notificará o utilizador, para cada instante, da ocorrência
de eventos como a sua chegada ou a de um autocarro à respetiva paragem pertencente ao plano
de viagem. Deverá também ser apresentada a informação da próxima carreira ou a paragem a
utilizar.
1.4 Solução
A solução apresentada contempla o desenvolvimento do Sistema InfoBUS anyWhere constituído
por três componentes:
• Simulador de Viagem: Responsável pela determinação de planos de viagem que per-
mitam a deslocação do utilizador entre dois pontos geográficos e sob um conjunto de
preferências e restrições.
• Servidor InfoBUS: Disponibiliza toda a informação referente ao XTraN Passenger e ao
Simulador de Viagem.
1http://www.carris.pt (Acedido em Agosto 2012)
1.5. ESTRUTURA DA DISSERTAÇÃO 5
• Aplicação móvel: Desenvolvida para o uso em dispositivos móveis. Permite a apresen-
tação gráfica de toda a informação gerida pela Tecmic em ambiente móvel. Responsável
pela funcionalidade do acompanhamento de viagem em tempo real.
1.5 Estrutura da Dissertação
Este documento contém a pesquisa, implementação e avaliação do sistema InfoBUS anyWhere
no âmbito da Dissertação de Mestrado. Este encontra-se estruturado da seguinte forma:
• Capítulo 2: apresenta o trabalho relacionado na área
• Capítulo 3: apresenta a análise de requisitos e o desenho da arquitetura
• Capítulo 4: apresenta as tecnologias e os detalhes de implementação para cada um dos
componentes desenvolvidos
• Capítulo 5: apresenta a avaliação ao sistema
• Capítulo 6: apresenta as conclusões e o trabalho futuro
Capítulo 2
Trabalho Relacionado
O trabalho relacionado encontra-se dividido em 3 secções. Na primeira secção serão apresenta-
dos alguns sistemas APTS seguindo uma abordagem cronológica. A segunda secção contempla
a introdução de simuladores de viagem nestes sistemas de informação. A abordagem do tra-
balho relacionado será assente numa perspetiva dos dispositivos móveis devido ao âmbito do
trabalho a realizar. Por fim, serão apresentados algoritmos de procura para a obtenção de pos-
síveis planos de viagem considerando fatores como o tempo ou a distância. As duas últimas
secções serão concluídas com uma tabela comparativa entre as diferentes soluções.
2.1 Advanced Public Transportation Systems(APTS)
O Busview [10] é o primeiro sistema universalmente disponível através da WWW que providen-
cia o acesso à localização geográfica de autocarros e a um conjunto de informação relativa aos
mesmos. Através desta aplicação, que pode ser transferida da WWW para ser executada lo-
calmente, os utilizadores podem visualizar a posição dos autocarros num mapa e seguir o seu
progresso com a opção de ser notificado da chegada do autocarro a uma determinada localiza-
ção. Adicionalmente, os utilizadores podem localizar o seu autocarro através da especificação
da linha de transporte ou das paragens abrangentes. Como complemento deste sistema e face
ao interesse em disponibilizar aos utilizadores tempos estimados para a partida ou chegada de
autocarros, foi desenvolvido a aplicação MyBus [1], essencialmente composta por uma interface
de acesso Web. Contudo, tal informação seria bastante mais usável se pudesse ser acedida por
um dispositivo móvel de forma a notificar um utilizador que se encontre, por exemplo, à espera
do seu autocarro.
7
8 CAPÍTULO 2. TRABALHO RELACIONADO
Para o desenvolvimento desta extensão do sistema, foi usado o protocolo Wireless Applica-
tion Protocol (WAP) e a linguagem Wireless Markup Language (WML) como mecanismos para
a entrega e apresentação de informação no dispositivo móvel. Esta extensão, vista como um
subsistema, é constituída pelo dispositivo móvel, pelo WAP Gateway e um servidor Web. O Ga-
teway comunica com o dispositivo móvel através de WAP e WML, traduzindo os seus pedidos
para o servidor Web usando Hypertext Transfer Protocol (HTTP). No dispositivo móvel, a inter-
face gráfica para o utilizador requer a introdução de identificadores únicos dos autocarros ou
paragens, para que seja processado o pedido com a informação desejada. O desconhecimento
do contexto do utilizador, isto é, a sua localização exata, torna este método desconfortável para
o utilizador pois requer a memorização destes identificadores. Para mais, estes não correspon-
dem normalmente a mapeamentos diretos com o nome da paragem ou do autocarro.
Figura 2.1: MyBus - Estimativas de tempos[1]
Apesar das limitações impostas pela rede de acesso e da tecnologia existente, especialmente
nos dispositivos móveis desta altura (2002), o MyBus disponibiliza funcionalidades ao utilizador
que permitem obter previsões de chegada da rede de autocarros (interface representada na Fi-
gura 2.1). Este sistema poderá ser considerado como um ponto de partida para todo o trabalho
desenvolvido nesta área.
Barbeau et al. e Patterson et al. apresentam sistemas com o intuito de ajudar a deslocação
de utilizadores com necessidades especiais na rede de transportes públicos [2, 11]. Estes uti-
lizadores, devido a deficiências físicas ou mentais, sofrem o risco de se perderem ao saírem
numa paragem errada ou de apanharem o autocarro errado durante um determinado percurso.
2.1. ADVANCED PUBLIC TRANSPORTATION SYSTEMS(APTS) 9
A solução para este problema, passa pela utilização de uma aplicação móvel presente no tele-
móvel de cada utilizador. Esta aplicação, através do conhecimento exato da posição do utilizador
e dos autocarros, consegue informar o utilizador se este se encontra no caminho correto. Adici-
onalmente, é possível avisar o utilizador da iminência da chegada a uma paragem que ele deva
utilizar. Esta notificação poderá ser complementada com a fotografia da respetiva paragem para
uma maior facilidade no seu reconhecimento. As restantes informações, como o aviso de atraso
ou chegada do respetivo autocarro, também serão apresentadas ao utilizador.
O sistema Travel Assistent Device (TAD) [2], apresentado por Barbeau et al., contempla três com-
ponentes essenciais: a aplicação presente no telemóvel do utilizador denominada precisamente
de TAD (representado na Figura 2.2), o servidor de informação relativa à rede de transportes
públicos e uma aplicação Web. Através da aplicação Web, é possível que um segundo utiliza-
dor possa controlar e monitorizar o trajeto efetuado pelo utilizador do TAD. Desta forma, não
existe a obrigação de acompanha-lo fisicamente no seu percurso. O TAD, apesar de ter sido
desenvolvido para utilizadores com necessidades especiais, poderá ser utilizado por qualquer
utilizador. Este sistema tem como base a utilização do contexto do utilizador como principal re-
curso para as suas funcionalidades, contudo, apenas é possível utilizar o TAD para efetuar rotas
pré-estabelecidas, limitando assim a sua utilização.
Figura 2.2: TAD - Interface da aplicação do dispositivo móvel [2]
Existem aplicações desenvolvidas com o intuito de proporcionar informação e serviços a todo o
tipo de utilizadores que frequenta a rede de transportes públicos. O sistema apresentado por
Joo-Yen et al. permite o acesso à informação da rede de autocarros em Seoul, Coreia do Sul[12].
Todos os serviços são acedidos através de uma interface gráfica simples e de fácil utilização. As
principais funcionalidades presentes no sistema são:
• Visualização da posição atual do utilizador e das paragens de autocarro que estão perto
10 CAPÍTULO 2. TRABALHO RELACIONADO
da sua posição.
• Pesquisa de linha de autocarro ou de paragens de autocarro através do nome ou identi-
ficador do mesmo. Sendo possível aceder posteriormente a um conjunto de informação
relacionada com paragem ou a linha do autocarro como por exemplo, hora do próximo
autocarro ou conjunto de paragens associadas a uma linha de autocarro.
• Visualização do mapa à volta da respetiva paragem possibilitando uma maior facilidade no
seu reconhecimento.
• Permitir guardar um estado do utilizador com as paragens ou linhas de autocarro preferidas
ou mais utilizadas.
O sistema é constituído pelo dispositivo móvel, correspondente neste caso a um Personal Digital
Assistant (PDA), um servidor que disponibiliza a aplicação e um servidor de base de dados.
A grande desvantagem deste sistema reflete-se no facto de ser necessário transferir todos os
dados do servidor de base de dados para o PDA para poderem ser efetuadas as funcionalidades
descritas. Tal facto poderá ser bastante preocupante tendo em consideração dois aspetos: a
memória disponível nos dispositivos móveis que na maior parte dos casos é bastante limitada;
tempo de transferência ou atualização dos dados entre os diferentes componentes. O sistema
torna-se assim pouco escalável.
2.2 Simuladores de viagem nos APTS
A motivação para a inclusão de simuladores de viagem advém das necessidades dos utilizado-
res em se deslocarem de forma rápida e eficiente de um ponto para outro. A tarefa de planear
uma viagem poderá tornar-se complicada e demorada devido ao leque de opções existentes e
da necessidade de consultar a informação necessária. De tal forma, a existência de um sistema
automatizado que resolva este problema permite ao utilizar achar planos de viagens num me-
nor espaço de tempo e com a informação correta. Normalmente, este tipo de simuladores são
associados à utilização do automóvel pessoal como meio de transporte. Nesta secção serão
apresentados simuladores de viagem dos sistemas APTS, ou seja, sistemas em que o meio de
deslocação associado são os transportes públicos.
O sistema OneBusAway [3] permite o acesso à informação da rede de transportes públicos
e disponibiliza um simulador de viagem de forma a ajudar o utilizador a deslocar-se para o seu
destino. Este sistema apresenta semelhanças ao XTraN Passenger desenvolvido pela Tecmic
2.2. SIMULADORES DE VIAGEM NOS APTS 11
em termos de serviços disponibilizados ao utilizador. No entanto, o seu desenho apresenta al-
gumas diferenças pois a informação respeitante aos transportes públicos não está localizada no
domínio do sistema. Assim, existe a necessidade de aceder a serviços externos como o General
Transit Feed Specification (GTFS)1 que disponibilizem a informação pretendida. As funcionali-
dades do OneBusAway são as seguintes:
• Visualização de mapas: mapas que contêm informação de paragens, linhas de transporte
e posições dos transporte.
• Acesso a informação da rede de transportes: informação em tempo real do cumpri-
mento de horários, permitindo a consulta dos respetivos atrasos. Desta forma, o utilizador
fica com uma perceção do tempo que tem de esperar, se ainda tem tempo para apanhar
o transporte ou se simplesmente o perdeu. Esta informação poderá ser acedida através
de três interfaces: chamada telefónica, mensagem de texto SMS ou interface Web. Todos
estes fatores contribuem para um aumento na satisfação do utilizador, reduzindo o tempo
de espera nas paragens pelo respetivo transporte [13].
• Serviço de alertas: informar o utilizador do acontecimento de incidentes temporários
como acidentes rodoviários, condições atmosféricas adversas, deterioramento de estra-
das ou alteração temporária de rotas, paragens e horários.
• Simulador de viagem: os utilizadores poderão utilizar um serviço que através de um
ponto de origem e um ponto de destino, são apresentadas as possíveis rotas que per-
mitem a deslocação entre esses pontos. Adicionalmente, o utilizador pode especificar
algumas preferências para a viagem como por exemplo, a distância máxima a percorrer,
número de transferências ou distância máxima percorrida a pé. O simulador de viagem
permite também uma alternativa para especificar o ponto de destino referindo por exemplo
a intenção de visitar um restaurante, parque ou biblioteca. O sistema calcula os possíveis
pontos de interesse apresentando o plano de viagem associado.
O OneBusAway pode ser acedido através das interfaces especificadas anteriormente e através
de aplicações móveis nativas como Nokia e iPhone (interface representada na Figura 2.3). Con-
tudo, o uso de um dispositivo móvel traz os maiores benefícios devido ao âmbito da utilização do
sistema. A informação relevante é obtida mais facilmente devido ao conhecimento do contexto
do utilizador, proporcionando uma melhoria nos serviços disponíveis.
1http://code.google.com (Acedido em Agosto 2012)
12 CAPÍTULO 2. TRABALHO RELACIONADO
(a) Localização de paragens e autocarros (b) Tempos de espera
Figura 2.3: OneBusAway - Interface da aplicação do dispositivo móvel[3]
O estudo realizado sobre a utilização do sistema OneBusAway [14, 15] na área de Seattle dos
Estados Unidos da América, demonstra que a informação em tempo real da chegada de trans-
portes e de outros serviços apresentados anteriormente, aumentam consideravelmente a usabi-
lidade do sistema de transportes públicos. Os utilizadores revelam que conseguem gerir melhor
o seu tempo considerando que as funcionalidades no sistema se adequam às suas necessida-
des. O estudo apresentado revela também comparações entre a utilização de aplicações que
usam o contexto do utilizador para determinar a sua posição, como é o caso das aplicações
nativas iPhone, e outras que usam métodos como a especificação da posição através do mapa.
Os resultados revelam que o uso do contexto do utilizador apresenta os melhores tempos de
resposta da aplicação. Destaca-se igualmente a elevada percentagem de utilizadores, cerca de
93%, que reportou passar menos tempo à espera do seu transporte e que, na maior parte dos
casos, considera mais vantajoso mudar para uma paragem alternativa com base na informação
do OneBusAway. Os resultados do estudo realizado apresentam vantagens da utilização de um
dispositivo móvel. No entanto, há que ter em consideração o reduzido número de utilizadores
em que o estudo foi realizado, cerca de 15.
O sistema ENOSIS [16] insere-se no mesmo âmbito que o OneBusAway, no entanto apresenta
algumas funcionalidades suplementares. Através de conclusões de estudos realizados, o sis-
tema integra a funcionalidade de acompanhar o utilizador ao longo dum plano de viagem obtido
pelo simulador, alertando-o de eventuais alterações inesperadas ou da previsão de tempos de
2.2. SIMULADORES DE VIAGEM NOS APTS 13
partida. Contudo, esta funcionalidade não tem conhecimento automático da posição exata do
utilizador nem se ele se encontra efetivamente a executar o plano, é necessário que o utilizador
providencie este tipo de informação. O simulador de viagens, para além de incorporar diversos
meios de transporte, possibilita o planeamento de viagens de longa distância. O ENOSIS pode
ser acedido pela WWW, e-mail e através do dispositivo móvel por mensagens de voz e SMS.
Contrariamente ao OneBusAway, não existe nenhuma aplicação nativa móvel levando assim ao
não aproveitamento do contexto do utilizador.
O PATH2Go [4] é um sistema de informação multi-modal dos transportes públicos com especial
foco no seu simulador de viagem. Através do acesso a dados de entidades externas, é possí-
vel integrar informação em tempo real relativa a diferentes meios de transporte como autocarro,
comboio ou metropolitano num único sistema. Para além destes meios de transporte, é con-
templada a opção do utilizador percorrer parte do percurso com o seu carro. Os três principais
módulos do PATH2Go são:
• Sistema de informação de trânsito: pesquisa de linhas de transporte, paragens ou infor-
mação em tempo real.
• Simulador de viagem multi-modal: usando informação em tempo real e dados geográfi-
cos, são calculados os planos de viagem adequados considerando um conjunto de prefe-
rências do utilizador. É possível também a comparação entre diferentes planos de viagem
em termos de tempos, emissões de poluentes, tempos de espera e tempos de viagem.
• Acompanhamento do plano de viagem: com base na localização do utilizador, ajudá-lo
ao longo do seu percurso.
O sistema está acessível através de uma interface Web e de uma aplicação móvel nativa iPhone
(interface representada na Figura 2.4). Para o acompanhamento do utilizador ao longo da sua
viagem, é necessário identificar qual a atividade que ele se encontra atualmente a realizar (es-
pera, deslocamento, etc.). Para tal, são aplicados algoritmos de correspondência de mapa tendo
em consideração o erro do GPS associado à localização do dispositivo móvel.
Nextbus1 e 5112 são outros sistemas que também disponibilizam simuladores de viagem restri-
tos a uma determinada área de execução. Podem ser acedidos através de interfaces Web e de
aplicações móveis. No entanto, contrariamente ao PATH2Go não incluem um simulador multi-
modal. Apenas é considerado um meio de transporte.
1http://www.nextbus.com (Acedido em Agosto 2012)2http://511.org (Acedido em Agosto 2012)
14 CAPÍTULO 2. TRABALHO RELACIONADO
Figura 2.4: PATH2Go - Interface da aplicação do dispositivo móvel[4]
A existência de outras plataformas como o Trimet1 e o Google Transit2, que apenas disponi-
bilizam o simulador de viagem através de uma interface Web também deverá ser mencionada.
O simulador de viagem Google Transit, desenvolvido pela Google, permite obter um plano de
viagem ótimo considerando os dados submetidos em ficheiros GTFS. Dependendo da região de
viagem, poderá existir mais do que um meio de transporte. Desta forma, caso reduza o tempo
total de viagem, os planos de viagem podem estar sujeitos a transições entre diferentes tipos de
transportes conjugados com distâncias que devem ser percorridas a pé.
Os dados utilizados pelo Google Transit são estáticos e não contemplam atrasos em tempo
real. Do ponto de vista da empresa, para representar a informação de um determinado meio
de transporte, é necessário submeter um conjunto de ficheiros que definem a informação crítica
do negócio, isto é, paragens, linhas, horários, calendários, tarifas, o nome da agência adminis-
trativa, etc. Cada ficheiro deverá respeitar a estrutura do GTFS para ser aceite e incorporado
no sistema. Desta forma, o Google Transit está ao alcance de todas os países e zonas com
transportes públicos, bastando para isso a submissão dos ficheiros GTFS que representam o
funcionamento de cada agência. Já o Trimet apenas disponibiliza serviços para área de Por-
tland, Estados Unidos da América. Contudo, ambos os sistemas incorporam vários meios de
transporte para a determinação dos planos de viagem.
1http://trimet.org (Acedido em Agosto 2012)2http://www.google.com/transit (Acedido em Agosto 2012)
2.3. ALGORITMOS E MODELOS DE DADOS DO SIMULADOR DE VIAGEM 15
Na Tabela 2.1 encontram-se resumidos os diferentes sistemas apresentados nesta secção. Es-
tes serão classificados de acordo com as interfaces de acesso, tipos de informação, funcionali-
dades, meios de transporte do simulador de viagem e âmbito de execução.
2.3 Algoritmos e modelos de dados do simulador de viagem
Qualquer simulador de viagem necessita de um algoritmo para calcular quais as possíveis rotas
que satisfaçam o pedido do utilizador. Para além dos algoritmos típicos de caminho mais curto,
existe a necessidade de introduzir outros fatores que devem influenciar o cálculo da rota. No
âmbito deste sistema, fará sentido ter em conta fatores como o custo total do percurso, o tempo
necessário para executar o percurso, o número de transições de transportes públicos durante
uma viagem ou a distância percorrida a pé. Como suporte ao algoritmo é necessário existir um
modelo de dados onde possa ser extraída a informação relevante para a sua execução.
Chao-Lin Liu et al. propõem um algoritmo com o objetivo de determinar possíveis rotas que per-
mitam a ligação entre dois pontos [17]. A motivação para o seu algoritmo, assenta no facto de os
utilizadores tipicamente preferirem planos de viagem que necessitam de menos transições entre
linhas de transporte, dado que o custo e o tempo aumentam com este tipo de transições. Assim,
o algoritmo de procura opera ao nível das linhas de transporte e não de pontos de paragens.
Os pontos de transição são representados por um conjunto de paragens que podem incorporar
vários modos de transporte. São considerados 3 algoritmos para solucionar o problema:
• Matrizes de adjacências[18]: utilização de matrizes quadradas para representar a conec-
tividade entre vários pontos. As linhas e colunas são indexadas pelo nome do ponto de
transição e o valor da posiçãoMi,j da matriz M é atribuído pelo número de caminhos dire-
tos entre i e j. Demonstrado por indução, a matriz M elevada a n denota a quantidade de
ligações entre os vários pontos considerando n transições. Desta forma, é possível achar
o percurso que permite a deslocação entre dois pontos considerando o menor número de
transições. No entanto, este algoritmo exige um poder computacional elevado, tornando-se
insuficiente para a resolução do problema.
• Matrizes de conectividade: com base no conceito das matrizes de adjacências, as ma-
trizes de conectividade permitem a representação da conectividade entre as linhas de
transporte. As linhas e as colunas são indexadas pela linha de transporte e o valor da
16 CAPÍTULO 2. TRABALHO RELACIONADO
Sistem
aInterfaces
deacesso
Tipode
informação
FuncionalidadesM
eiosde
transportedo
simulador
Âm
bitogeográ-
fico
OneB
usAw
ay[3]W
eb,S
MS
,A
plica-ções
iPhone
eA
n-droid
Dinâm
ica-
tempo
realS
imuladorde
viagem;M
apascom
loca-lização
detransportes;S
erviçode
aler-tas;P
revisõesem
tempo
real
Transportespúblicos,pe-
destreS
eattle,EU
A
EN
OS
IS[16]
Web,
E-m
ail,S
MS
echam
adastelefóni-
cas
Dinâm
ica-
tempo
realS
imulador
deviagem
comescala
mundialconsiderando
deslocaçõesem
aviãoou
barco;A
companham
entodo
planode
viagem
Transportespúblicos
Mundial
PATH2G
o[4]W
ebe
aplicaçãoiP
honeD
inâmica
-tem
poreal
Sim
uladordeviagem
;Mapas
comloca-
lizaçãode
transportes;Serviço
dealer-
tas;Previsões
emtem
poreal;A
compa-
nhamento
doplano
deviagem
Transportepessoal,
transportespúblicos,
pedestre
São
Francisco,E
UA
Nextbus
Web,
SM
S,
Aplica-
çõesiP
hone,Android
eB
lackberries
Dinâm
ica-
tempo
realM
apascom
localizaçãode
transpor-tes;
Serviço
dealertas;
Previsões
emtem
poreal
Transportespúblicos
Washington
DC
,S
ãoFrancisco,
Toronto,etc.511
Web,S
MS
Dinâm
ica-
tempo
realS
imulador
deviagem
;M
apascom
lo-calização
detransportes;P
revisõesem
tempo
real
Transportespúblicos
São
Francisco,E
UA
Trimet
Web,S
MS
Dinâm
ica-
tempo
realS
imuladorde
viagem;M
apascom
loca-lização
detransportes;S
erviçode
aler-tas;P
revisõesem
tempo
real
Transportespúblicos
Portland,EU
A
TransitW
ebE
státicaS
imulador
deviagem
comextensibili-
dadepara
ainclusão
deoutras
agên-cias
atravésde
GTFS
Transportepessoal,
transportespúblicos,
pedestre
Mundial
comtransporte
regio-nal
Tabela2.1:
Sum
áriode
sistemas
AP
TScom
simuladorde
viagem
2.3. ALGORITMOS E MODELOS DE DADOS DO SIMULADOR DE VIAGEM 17
posição Ti,j da matriz T é atribuído pelo número de paragens em comum entre i e j. Res-
peitando as propriedades das matrizes de adjacências, a matriz T elevada a n denota o
número de paragens em comum considerando n transições. Contudo, a informação repre-
sentada pelas matrizes revela resultados enganadores. Existem restrições que não são
representadas, como a direção da linha de transporte, apenas aplicando este algoritmo. É
necessário juntar algumas condicionantes de implementação para que sejam apresenta-
dos os resultados corretos.
• Algoritmo de planeamento: Com a ajuda das matrizes de conectividade e outras fun-
ções de conectividade de rotas, o algoritmo apresentado apenas considera no máximo
três transferências. Caso a origem e o destino sejam servidos pela mesma linha de trans-
porte, apenas existe a necessidade de verificar se a linha tem o sentido origem-destino.
Caso seja necessário recorrer a dois ou mais pontos de transição, obtido através da matriz
Tn, é necessário verificar a localização dos pontos de transição e se efetivamente existe a
possibilidade de realizar essas transições devido ao sentido da linha de transporte.
O algoritmo apresentado é completo e ótimo para o cálculo do rotas considerando o menor nú-
mero de transferências. No entanto, e apesar de ser referido como uma possível extensão ao
sistema, a aplicação não contempla no seu algoritmo outros fatores como o tempo ou o custo
para determinar os percursos. Por outro lado, como alternativa e adicionando um complemento
ao sistema, foi incorporada a utilização de pontos de transição especiais denominados de “pon-
tos de agregação”. Estes pontos representam uma forte concentração de linhas de transporte,
superior a quinze linhas, tipicamente representando estações multi-modais e são utilizados como
pontos preferenciais para ser efetuada uma transição. Considerando esta implementação, o al-
goritmo mantém-se completo mas não se revela ótimo.
Ao considerar o tempo real como principal fator para a obtenção de um plano de viagem, como
é o caso do algoritmo apresentado por Jeral Jariyasunant [19], surge outro tipo de problema.
Devido à necessidade de aceder à informação de tempos e rotas através de serviços externos,
não é sustentável obter todos os dados de uma só vez para cada pedido do utilizador. Nestas
condições, a duração entre pedido-resposta está sujeita a um grande atraso. A solução passa
por realizar uma pré-computação da informação necessária em duas fases. Na primeira fase
são obtidos os dados de rotas, paragens e localizações através dos ficheiros GTFS da Goo-
gle. Seguidamente é realizado um mapeamento entre as paragens e um serviço externo onde
seja possível obter informação em tempo real das linhas de transporte. Na segunda fase são
construídas três tabelas de procura: tabela de geolocalização onde é armazenada a latitude e a
18 CAPÍTULO 2. TRABALHO RELACIONADO
longitude de cada paragem; tabela de serviços que contempla os horários e períodos de funcio-
namento de todas as linhas de transporte; tabela de caminhos em que são consideradas todas
as paragens como possível origem e são calculadas todas as paragens destino com o máximo
de quatro transições efetuadas. Para os pontos de transição são consideradas paragens de
cruzamento de linhas de transporte e paragens com uma reduzida deslocação pedestre entre
elas. Com esta pré-computação realizada, qualquer pedido do utilizador é traduzido no seguinte
procedimento:
1. Determinar a paragem mais próxima do utilizador através da tabela de geolocalização .
2. Obter através da tabela de caminhos, todos os caminhos possíveis que possibilitem a
deslocação da paragem mais próxima para o destino.
3. Remover caminhos irrelevantes através da tabela de serviços.
4. Obter a informação de tempo real associada a cada paragem e apresentar os cinco resul-
tados com tempos inferiores.
A avaliação do algoritmo revelou resultados positivos com uma média de tempos inferior a três
segundos entre o pedido e a resposta do utilizador. A escalabilidade do sistema revela um au-
mento de ordem polinomial em termos de espaço para a tabela de procura de caminhos. O
algoritmo não é ótimo pois pode excluir paragens no passo 1 que corresponderiam a um cami-
nho mais curto.
Tendo em consideração os vários tipos de transporte existentes, Joel Booth et al. apresentam
um simulador de viagens assente num modelo de dados em grafo onde é possível especificar
os meios de transporte que o utilizador deseja utilizar [20]. Para além de serem considerados
diferentes meios de viagem (automóvel, pedestre, comboio ou metropolitano), existe ainda a
possibilidade de condicionar o plano de viagem através de restrições físicas como a exclusão de
rotas com pontes ou ruas específicas, restrições temporais como a duração máxima da viagem
e restrições que incluam certas instalações ou serviços como bancos e restaurantes na rota
traçada.
O modelo de dados é definido pelo tuplo U = (M,F,L,G) em que: M é o conjunto de meios de
transporte, F o conjunto de instalações ou serviços, L o conjunto de atributos e G um multi-grafo
rotulado e dirigido. Por sua vez, G = (V,E,Ψ) em que V representa os vértices, E os arcos
e Ψ uma função de mapeamento de atributos. Os vértices são pontos geográficos escolhidos
em conformidade com a proximidade de uma instalação, um serviço ou uma paragem de uma
linha de transporte. Os arcos correspondem a linhas dos vários meios de transporte entre os
2.3. ALGORITMOS E MODELOS DE DADOS DO SIMULADOR DE VIAGEM 19
diferentes vértices.
Baseado em linguagens espaço-temporais[21], a construção da base de dados em grafo é reali-
zada através da declaração de predicados descrevendo os vários componentes descritos ante-
riormente e as suas relações. Consequentemente, o sistema de interrogação à base de dados é
baseado na estrutura da linguagem SQL permitindo assim a obtenção dos planos de viagem de-
sejados. A interrogação a executar poderá conter várias restrições como o meio de transporte,
instalações a parar ou o tempo máximo para realizar a viagem acompanhado de um grau de
probabilidade. Caso o utilizador pretenda minimizar o tempo da viagem, é usada uma versão do
algoritmo de Dijkstra[22] adaptada a um multi-grafo para obter o caminho mais curto.
Zang e Cai propõem um algoritmo dinâmico de caminho mais curto com o objetivo primário
de minimizar o tempo de viagem e como segundo objetivo, minimizar o número de transferên-
cias entre linhas de transporte[23]. Devido ao aumento do ritmo de vida, a grande maioria das
pessoas considera o tempo como o fator principal para a obtenção de um plano de viagem apro-
priado.
O modelo de dados deste sistema é constituído por um grafo onde é representada a rede de
trânsito. De forma a simplificar a rede, paragens que se encontrem separadas por curtas dis-
tâncias são agregadas num único nó. Arcos entre os diferentes nós correspondem a secções
de estrada que permitem a sua ligação. Assim, cada arco poderá estar associado a diferentes
linhas de transporte. Para cada plano, o tempo total da viagem é dado por:
t = twalk + tv + ti + twait + tprice
Onde twalk corresponde ao tempo de deslocação pedestre da origem para a paragem e da pa-
ragem do destino para o destino, tv ao tempo de deslocação no transporte público, ti ao tempo
de transferência entre transportes ou tempo na deslocação pedestre entre paragens, twait ao
tempo de espera pelo transporte e tprice corresponde a uma transformação do preço total da
viagem em tempo. Cada um destes tempos é calculado tendo em consideração fatores que
influenciam diretamente o seu valor. O algoritmo apresentado é ótimo e baseia-se no algoritmo
de Dijkstra[22], no entanto, devido à consideração de tempos complementares como ti ou tprice,
apresenta resultados diferentes para os mesmos dados de entrada.
Li et al. apresentam um simulador de viagem incorporando igualmente vários meios de trans-
porte e informação em tempo real[24]. Para além dos tradicionais meios de transporte, é acres-
centada a possibilidade do utilizador deixar o seu carro num determinado parque de estacio-
namento e posteriormente seguir num transporte público. O desenho do simulador de viagem
20 CAPÍTULO 2. TRABALHO RELACIONADO
permite satisfazer as preferências de diferentes utilizadores apresentando sempre um conjunto
de planos como resposta. Tal necessidade deve-se ao facto de os utilizadores terem opiniões
diferentes sobre como preferem realizar o percurso da origem ao destino. Exemplificando, um
utilizador pode preferir deslocar-se um pouco mais a pé enquanto que outro pode preferir aguar-
dar na paragem.
Para calcular quais os possíveis planos de viagem, o problema é partido em três subproblemas
de caminho mais curto: da origem para paragens ou parques de estacionamento; do destino
para paragens mais próximas; e das paragens ou parques de estacionamento que estão mais
perto da origem para paragens que estão mais perto do destino. Para os dois primeiros, é con-
siderada a aplicação do algoritmo bi-direcional de Dijkstra[22]. Para o terceiro subproblema,
são adaptados os algoritmos GOR1[25] e o algoritmo de Jiminez e Marzal[26] para obter os
caminhos mais curtos considerando a minimização do tempo de viagem como fator principal.
O modelo de dados utilizado é caracterizado por uma rede de trânsito onde existem diferentes
tipos de nós (paragens, parques de estacionamento e pontos de transição) e arcos entre os nós
com atributos temporais que são atualizados periodicamente.
Na Tabela 2.2 encontram-se resumidos os diferentes algoritmos apresentados nesta secção.
Estes serão classificados de acordo com os algoritmos que usam no seu processo, fatores con-
siderados pela sua execução e o modelo de dados utilizado.
2.4 Conclusões
O PATH2Go e o OneBusAway apresentados na secção 2.2 revelam-se os sistemas mais com-
pletos e aproximados ao XTraN Passenger contemplando o uso de aplicações nativas para dis-
positivos móveis. As funcionalidades destas aplicações aproximam estes sistema ao propósito
da aplicação InfoBUS. Para mais, a aplicação móvel do PATH2Go permite o acompanhamento
do utilizador durante um plano de viagem.
Em relação aos algoritmos apresentados na secção 2.3, o proposto por Joel Booth et al.[20]
revela-se o mais abrangente podendo incorporar diversas preferências do utilizador na determi-
nação do plano. Contudo, o uso dos algoritmos baseados em Dijsktra, apresentados por Zang
e Cai[23] ou Li et al.[24], podem satisfazer o pedido da maioria dos utilizadores sem necessitar
de um sistema tão complexo. A ideia apresentada por Jeral Jariyasunant et al.[19] envolve uma
pré-computação dos dados para reduzir tempos de resposta e será utilizada no sistema InfoBUS
anyWhere.
2.4. CONCLUSÕES 21
Aut
ores
Alg
oritm
osFa
ctor
esem
cons
ider
ação
Mod
elos
deda
dos
Cha
o-Li
nLi
uet
al.[1
7]B
asea
doem
mat
rizes
deco
nect
ivid
ade[
18]
Núm
ero
detra
nsiç
ões
Não
espe
cific
ado
Jera
lJar
iyas
unan
teta
l.[19
]A
lgor
itmo
espe
cial
izad
oTe
mpo
devi
agem
enú
mer
ode
tran-
siçõ
esTa
bela
sde
proc
ura
espe
cial
izad
as
Joel
Boo
thet
al.[2
0]E
spaç
o-te
mpo
rais
[21]
eD
ijkst
ra[2
2]Te
mpo
devi
agem
,núm
ero
detra
n-si
ções
,cu
sto,
mei
ode
trans
port
e,po
ntos
dein
tere
sse
Red
ede
trâns
itoem
graf
o
Zang
eC
ai[2
3]B
asea
dono
Dijk
stra
[22]
Tem
pode
viag
em,n
úmer
ode
tran-
siçõ
ese
cust
o,R
ede
detrâ
nsito
emgr
afo
Liet
al.[2
4]D
ijkst
ra[2
2],
GO
R1[
25],
Jim
inez
eM
arza
l[26]
Dis
tânc
iae
tem
poR
ede
detrâ
nsito
emgr
afo
Tabe
la2.
2:S
umár
iodo
sal
gorit
mos
para
osi
mul
ador
devi
agem
Capítulo 3
Arquitetura
Neste capítulo é apresentada a arquitetura do sistema InfoBUS. São levantados os requisi-
tos inerentes ao sistema e são descritos os seus componentes. Por fim, é apresentada a
comunicação de alto nível entre os componentes.
3.1 Análise de Requisitos
Os requisitos funcionais estão fundamentalmente concentrados na aplicação móvel porque ape-
nas neste componente irá existir interação direta com o utilizador, já os requisitos não funcionais
estarão presentes um pouco por todo o sistema. Os requisitos para o sistema InfoBUS são:
• Localização e visualização no mapa de paragens. Possibilidade de consultar informação
detalhada acerca da mesma (nome, morada, linhas de transportes que passam na para-
gem, previsões de chegada dos próximos transportes).
• Localização e visualização no mapa de transportes com atualização em tempo real do seu
estado e informação.
• Acesso a informação relativa a uma determinada linha de transporte.
• Obtenção de horários, previsões de chegada e atrasos dos transportes públicos.
• Acesso a notícias e avisos relativos aos transportes públicos.
• Simulação de viagem através da especificação de:
– Ponto de origem e de destino.
23
24 CAPÍTULO 3. ARQUITETURA
– Data de partida.
– Preferências do utilizador: percurso mais rápido ou com menos transbordos com es-
pecificação do limite máximo à deslocação pedestre.
• Duração máxima de 3 segundos entre o pedido e a resposta relativamente à simulação de
viagem.
• Plano de viagem ótimo para horários pré-estabelecidos e tendo como critério o tempo de
viagem ou o número de transbordos.
• Plano de viagem atualizado com previsões de chegada dos autocarros às paragens
• Interoperabilidade com o módulo XTraN Passenger.
• Visualização e gestão de planos de viagem agendados.
• Acompanhamento em tempo real do plano de viagem obtido pelo simulador através da
localização de transportes e paragens incluídas no plano, informação do plano, posição do
utilizador e tempos de viagem. Exibição de notificações relativas a:
– Chegada de transporte.
– Paragens de entrada e de saída a utilizar.
– Percurso a realizar no transporte público ou a caminhar.
– Chegada ao destino.
Através dos requisitos definidos, o diagrama de casos de uso representado na Figura 3.5 ilustra
todas as ações que o utilizador tem sobre a aplicação móvel. O simulador de viagem calcula os
possíveis planos e permite que o utilizador possa agendar a sua execução imediata ou a prazo.
Os planos agendados são guardados de forma persistente e podem ser geridos pelo utilizador
de forma local.
3.2 XTraN Passenger
No módulo XTraN Passenger desenvolvido pela Tecmic estão presentes todos os dados neces-
sários ao funcionamento do sistema InfoBUS, uma camada de acesso aos dados denominada
de PassengerDAL e ainda o Servidor de Estimativa de Tempos. Através do seu modelo de
dados é possível representar toda a lógica de negócio subjacente a um sistema APTS. Para
simplificar a explicação do modelo de dados e visto que o sistema InfoBUS apenas necessita
3.2. XTRAN PASSENGER 25
Figura 3.5: Casos de uso - Utilizador do aplicação móvel
de aceder a um sub-conjuntos de dados, doravante apenas será explicado e representado uma
parte do modelo de dados do XTraN Passenger, excluindo assim, detalhes e alguma lógica de
negócio que não será necessária para o sistema InfoBUS.
3.2.1 Modelo de Dados
A Figura 3.6 representa o modelo de dados relacional do XTraN Passenger. Cada linha de trans-
porte é representada pela tabela CARREIRA, onde por sua vez poderão existir variações de
rota dessa mesma linha de transporte, representadas na tabela CARREIRAVARIANTE. Por fim,
a tabela CARREIRAVARIANTESENTIDO representa a direção pela qual essas variações são
realizadas. As linhas de transportes são compostas por múltiplos troços (tabela TROCO), cada
troço corresponde a um conjunto de paragens (tabela PTPARAGEM). Estes agrupamentos são
26 CAPÍTULO 3. ARQUITETURA
feitos de forma a representar uma linha de transporte com um nível de granularidade superior.
Cada troço contém um conjunto de ligações entre paragens (tabela Connection). Através de
cada item desta tabela, é possível obter dados importantes, como a distância entre paragens.
Como acontece frequentemente no dia a dia, existe a possibilidade de demorar mais tempo a
realizar um percurso a uma determinada hora de um dia útil do que noutro horário. Tal lógica
está representada na tabela ConnectionTime, em que cada item desta tabela, contém informa-
ção sobre a tempo estimado para efetuar uma determinada ligação. A duração está dependente
do dia (tabela DIA), época (tabela EPOCA) e ainda das horas a que ocorre (tabela VARIANTE).
Assim, a relação entre as tabelas Connection e ConnectionTime é de um para muitos.
Os horários de serviço de cada linha de transporte estão representados na tabela Schedule,
estes estão dependentes do tipo de serviço ao qual o transporte se designa e também ao tipo
de dia e de época. Os dias são representados como dia útil, Sábado, feriado ou Domingo e
feriado especial. As épocas como escolar e não escolar. Para fazer a associação entre este tipo
de informação, é necessário recorrer à tabela SERVICOCHAPA. A tabela ED_CALENDARIO
caracteriza cada dia do ano em relação ao seu tipo e época.
O modelo de dados representado contempla ainda dados sobre os veículos (tabela VEICULO),
o seu condutor (tabela CONDUTOR) e ainda a sua atual posição representada pela tabela PO-
SICAO_E. Por fim, todas as partidas são registadas na tabela Departure.
3.2.2 Servidor de Estimativa de Tempos
O Servidor de Estimativa de Tempos tem como objetivo calcular previsões de chegada dos trans-
portes às paragens. Para tal, existem dois casos a ter em consideração: o transporte já se en-
contra em viagem ou caso contrário, ainda não iniciou a viagem. No primeiro caso, a estimativa
é feita utilizando informação da última paragem realizada, a sua posição atual e o tempo pré-
calculado para realizar a ligação entre as paragens durante aquele horário. No segundo caso, a
estimativa é feita usando o histórico das últimas viagens realizadas respeitantes a linha de trans-
porte em questão. O Servidor de Estimativa de Tempos está acessível através de serviços Web
e é essencial para sistema InfoBUS pois permite a conjugação dos resultados obtidos através
de dados estáticos com informação em tempo real relativa aos transportes públicos.
3.3. COMPONENTES DO SISTEMA INFOBUS ANYWHERE 27
Figura 3.6: XTraN Passenger - Modelo de dados relacional
3.3 Componentes do Sistema InfoBUS anyWhere
A solução contempla uma arquitetura cliente-servidor representada na Figura 3.7. Os compo-
nentes desta arquitetura poderão ser separados logicamente pela sua funcionalidade e locali-
zação: lado servidor e lado cliente. No lado do servidor será desenvolvido um módulo InfoBUS
como extensão do sistema XTraN Passenger da Tecmic. Por sua vez, o módulo InfoBUS, será
composto pelo Servidor InfoBUS e pelo Simulador de Viagem. No lado cliente existirá uma
aplicação móvel que acederá, para além do Servidor InfoBUS, a serviços externos como o re-
positório de mapas de estrada. O GPS será usado para facilitar a utilização de algumas funcio-
nalidades por parte do utilizador da aplicação móvel, sendo mesmo indispensável em algumas
atividades.
Toda a informação apresentada pela aplicação móvel será obtida através do servidor InfoBUS.
28 CAPÍTULO 3. ARQUITETURA
Por sua vez, este servidor comunicará com a plataforma XTraN Passenger, para obter os da-
dos necessários. Devido a limitações computacionais do dispositivo móvel, a requisitos não
funcionais e também para limitar a transferência de dados entre componentes, a execução do
simulador de viagem estará igualmente integrada no lado do servidor.
Figura 3.7: Arquitetura de alto nível
3.3.1 Simulador de Viagem
O Simulador de Viagem, representado na Figura 3.8, determina planos de viagem com base
na informação fornecida pelo utilizador, i.e., origem, destino e preferências para a determinação
do plano (plano mais rápido ou com menos transbordos e limite à deslocação pedestre). O al-
goritmo para a obtenção dos melhores planos de viagem consiste na aplicação iterativa de um
algoritmo para determinar o caminho mais curto tendo como suporte uma rede de trânsito. Cada
iteração do algoritmo considera uma rede de transito com alterações parciais da rede anterior
permitindo assim obter diferentes caminhos. De notar que os melhores planos de viagem não
3.3. COMPONENTES DO SISTEMA INFOBUS ANYWHERE 29
correspondem ao caminhos mais curtos pois tal não se adequa ao âmbito dos transportes pú-
blicos. Considerando o seguinte exemplo: O caminho mais curto entre o ponto X e o ponto Y é
composto pelas paragens A, B, C e pela carreira 1 que realiza todas as paragens do percurso.
Existe ainda a carreira 2 que realiza unicamente as paragens B e C mas que não pertence ao
plano obtido. Ao considerar a aplicação de um algoritmo de K caminhos mais curtos, o resultado
na 2ª iteração seria o plano com a carreira 1 para realizar as paragens A e B e a carreira 2 para
realizar as paragens B e C. Tal plano não faz sentido para o utilizador visto que ele é forçado
a abandonar um autocarro que o levaria ao seu destino. Como tal, as iteração posteriores do
algoritmo irão usar redes de trânsito com a omissão de cada carreira pertencente ao plano ante-
rior. Desta forma é garantido que as alternativas para o utilizador são suficientemente diferentes,
o caso descrito neste exemplo não ocorrerá e que são obtidas as alternativas mais rápidas ao
considerar a carreira retirada.
O tempo ou número de transbordos são os critérios usados para a aplicação do algoritmo e a
rede de trânsito tem como suporte os dados fornecidos pelo XTraN Passenger. Após o cálculo
dos melhores planos de viagem, segundo as preferências especificadas e os horários estáticos,
é realizado um acesso ao Servidor de Estimativa de Tempos de forma a obter previsões de che-
gada dos transportes às paragens incluídas nestes planos de viagem. Assim, são garantidos os
melhores planos de viagem na primeira fase do algoritmo, conjugados posteriormente com infor-
mação em tempo real. Caso existam atrasos que alterem o tempo total das viagens simuladas,
é feita uma reordenação dos resultados. Em termos de arquitetura, o Simulador de Viagem está
estruturado em dois camadas:
• Camada de apresentação: desenvolvimento de uma interfaces de acesso aos serviços
disponibilizados pelo Simulador de Viagem através da Web.
• Camada lógica: pré-computação da rede de trânsito que será composta por paragens,
ligações entre paragens, linhas de transporte e pelos horários de serviço. Os dados utili-
zados para a construção da rede de trânsito estão presentes no servidor de base de dados
do XTraN Passenger. A camada lógica contempla ainda a implementação do algoritmo de
procura para obter os melhores planos de viagem e o acesso ao Servidor de Estimativa de
Tempos.
Para evitar constantes acessos ao servidor de base de dados do XTraN Passenger em cada pe-
dido ao Simulador de Viagem, a rede de trânsito é computada com a inicialização da aplicação,
mantida em memória primária de forma a diminuir tempos de acesso e apenas será atualizada
num determinado período T . A frequência de alteração ou inserção de novos dados relativos a
paragens, linhas de transporte ou horários deverá definir o período de atualização T , sendo este
30 CAPÍTULO 3. ARQUITETURA
valor configurável pelo administrador da aplicação. A camada de dados é omitida da arquitetura
visto que os dados usados são todos transferidos do XTraN Passenger.
Figura 3.8: Arquitetura de lado servidor: Servidor InfoBUS e Simulador de Viagem
3.3.2 Servidor InfoBUS
O Servidor InfoBUS, representado na Figura 3.8, tem como principal função servir todos os
pedidos provenientes da aplicação móvel, sem manter estado entre os mesmos. É o front end
de todo o sistema que engloba a parte do servidor e disponibiliza uma Application Programming
Interface (API) de acesso aos serviços fornecidos ora pelo módulo XTraN Passenger ora pelo
Simulador de Viagem, através da Web. Este é estruturado em duas camadas:
• Camada de apresentação: desenvolvimento de interfaces de acesso Web aos serviços
disponibilizados pelo sistema.
• Camada lógica: processamento da lógica de negócio, i.e., são decididos quais os servi-
ços a invocar dentro das infraestruturas da Tecmic. O pedido poderá requerer um acesso
ao Servidor de Estimativa de Tempos para a obter previsões de chegada dos transportes
públicos às paragens, ou poderá ser realizado um pedido ao Simulador de Viagem para
3.3. COMPONENTES DO SISTEMA INFOBUS ANYWHERE 31
determinar uma plano de viagem. Alternativamente, poderá ser efetuado um acesso ao
servidor de base de dados do XTraN Passenger através da camada de dados Passen-
gerDB para obter informações relativas a paragens, linhas de transporte, etc.
3.3.3 Aplicação Móvel
A aplicação móvel é o único componente onde existe interação direta com o utilizador, servindo
assim os propósitos finais de todo o sistema InfoBUS. Através desta aplicação, é possível ace-
der a todas as funcionalidades descritas na secção 3.1. São apresentados os resultados finais
ao utilizador num ambiente móvel relativamente a dados do XTraN Passenger ou do Simulador
de Viagem. Grande parte dos dados obtidos são conjugados com mapas geográficos obtidos
por fontes externas, levando a uma melhor compreensão da informação por parte do utilizador.
Outro serviço essencial para este componente, vulgarmente utilizado num ambiente móvel, é a
utilização do sistema GPS. A aplicação móvel utiliza o GPS de forma a facilitar algumas funcio-
nalidades, como por exemplo a localização de paragens nas imediações. O acompanhamento
de um plano de viagem, previamente obtido pelo Simulador de Viagem, necessita obrigato-
riamente do sistema GPS para comparar a posição atual do utilizador com a rota a realizar.
Adicionalmente, são também efetuados pedidos ao Servidor InfoBUS para obter a posição atual
dos transportes pertencentes ao plano escolhido. A aplicação móvel, representado na Figura
3.9, é constituída por três camadas:
Figura 3.9: Arquitetura da aplicação móvel
• Camada de apresentação: interface gráfica para que o utilizador possa interagir com o
sistema, acedendo às suas funcionalidades e notificando-o durante o acompanhamento
de viagem.
• Camada lógica: elaboração e transmissão dos pedidos para o servidor InfoBUS, obtenção
de mapas do respetivo repositório e acesso ao sistema GPS do dispositivo móvel. Acesso
32 CAPÍTULO 3. ARQUITETURA
à camada inferior de dados para obter informação dos planos de viagem agendados ou
em execução. Implementação do algoritmo de acompanhamento de viagem.
• Camada de dados: acesso aos dados referentes a planos de viagem. Cada plano, após
ter sido obtido indiretamente pelo Simulador de Viagem e escolhido pelo utilizador, será
armazenado de forma persistente numa base de dados relacional.
O algoritmo de acompanhamento de viagem traduz-se numa máquina de estados onde cada
estado é referente às condições do utilizador, i.e., em espera pelo transporte, a caminhar para
a paragem ou para o destino e no transporte. Sendo que o estado final será o de chegada
ao destino. As transições entre os diversos estados correspondem a eventos como chegada
à paragem, chegada do transporte ou chegada ao destino. O acompanhamento de viagem é
apenas informativo daquilo que o utilizador deverá realizar e é executado em background.
3.4 Comunicação
Como especificado em 3.3.2, o Servidor InfoBUS disponibiliza uma API para aceder aos seus
serviços através da Web. Todos os pedidos provenientes da aplicação móvel são independentes
e realizados através de serviços Representational State Transfer (REST). Cada pedido é feito
usando unicamente o protocolo HTTP e contém toda a informação necessária para ser proces-
sado através do URI. Esta solução foi adotada de forma a aumentar a flexibilidade e interope-
rabilidade de qualquer sistema remetente. O Servidor de Estimativa de Tempos, desenvolvido
pela Tecmic e utilizado pelo sistema InfoBUS, é acedido através da invocação de WebServices.
Como tal, e por coerência às soluções implementadas, o Simulador de Viagem é igualmente
acedido via WebServices. A figura 3.10 representa a interação entre os diversos componentes
e para simplificar a sua ilustração, foram agrupados todos os pedidos referentes a informação
presente no XTraN Passenger (invocação Obter info). Assim, existem 3 tipos de invocações que
geram interações diferentes entre os componentes do lado servidor. Na invocação Obter info, é
feito um acesso ao servidor de base de dados do XTraN Passenger, são geradas vistas para os
dados obtidos e por fim, estas são retornadas à aplicação móvel. Na invocação Obter previsões,
é realizado um acesso ao Servidor de Estimativa de Tempos. Na invocação Simular viagem,
os dados são reencaminhados para o Simulador de Viagem e por sua vez, este realizará um
acesso ao Servidor de Estimativa de Tempos.
3.4. COMUNICAÇÃO 33
Figura 3.10: Diagrama de sequência - Interação entre componentes
Capítulo 4
Implementação
Neste capítulo são descritos todos os aspetos relativos à implementação dos componentes
enumerados e arquitetados no último capitulo. São apresentadas todas as linguagens,
tecnologias e bibliotecas utilizadas assim como detalhes de implementação. A escolha das tec-
nologias foi fortemente baseada nas tecnologias já utilizadas pela Tecmic na construção dos
seus produtos, em tecnologias Open Source e na experiência obtida previamente no desenvol-
vimento de Software com determinadas linguagens ou arquiteturas.
4.1 XTraN Passenger
Nesta secção são apresentados os componentes do XTraN Passenger usados na implementa-
ção do sistema InfoBUS anyWhere.
4.1.1 PassengerDAL(Domain Access Layer)
Todos os dados estão armazenados numa base de dados relacional Structured Query Lan-
guage (SQL) com recurso à ferramenta Microsoft SQL Server 2008. A camada desenvolvida pela
Tecmic que permite o acesso aos dados, utiliza uma solução Object-Relational Mapping (ORM),
o NHibernate. Esta camada de abstração, denominada por PassengerDAL, será utilizada quer
pelo Simulador de Viagem quer pelo Servidor InfoBUS para aceder aos dados presentes na
base de dados do XTraN Passenger. O PassengerDAL disponibiliza interfaces de acesso para
todos os dados necessários pelo Sistema InfoBUS.
35
36 CAPÍTULO 4. IMPLEMENTAÇÃO
4.1.2 Servidor de Estimativa de Tempos
O Servidor de Estimativa de Tempos disponibiliza uma interface de acesso Web aos seus ser-
viços. A interface é constituída por vários serviços, dos quais apenas dois são utilizados pelo
Sistema InfoBUS:
• GetEstimationByStopPoint(int numberOfEstimations, System.TimeSpan timeSpan,
string stopPointCode): obtenção de numberOfEstimations estimativas para o próximo
intervalo de tempo representado por timeSpan. Filtrado para a paragem identificada por
stopPointCode.
• GetEstimationByRouteAndStopPoint(int numberOfEstimations, System.TimeSpan ti-
meSpan, string routeCode, string stopPointCode): obtenção de numberOfEstimations
estimativas para o próximo intervalo de tempo representado por timeSpan. Filtrado para a
paragem identificada por stopPointCode e pela linha de transporte routeCode.
4.2 Simulador de Viagem
O Simulador de Viagem foi implementado com recurso à linguagem C# e à plataforma da Mi-
crosoft .NET 4.0. A escolha destas tecnologias deve-se ao facto de todos os componentes
desenvolvidos pela Tecmic usarem estas tecnologias, da possibilidade de ser prestado apoio
por membros da Tecmic (em caso de problemas ou dúvidas) e também por experiência pessoal
adquirida previamente em projetos académicos. O ambiente de desenvolvimento escolhido foi
o Microsoft Visual Studio 2010 e o servidor aplicacional embutido Visual Studio Development
Server.
4.2.1 Estrutura de Dados
Os dados utilizados para o Simulador de Viagem são construídos através de informação pre-
sente no servidor de base de dados do XTraN Passenger. Esta informação é acedida pela
camada PassengerDAL. No Simulador de Viagem, todos os acessos a esta camada estão en-
capsulados na classe PassengerDB. A estrutura de dados é traduzida no diagrama de classes
representado na figura 4.11.
A rede de transito é implementada através de um grafo onde cada vértice, representado pela
classe Vertex, constitui uma paragem e as suas principais características como a localização e
4.2. SIMULADOR DE VIAGEM 37
Figura 4.11: Estrutura de Dados - Diagrama de Classes
a sua identificação única. Os arcos do grafo por sua vez, representam ligações entre as para-
gens (representado pela classe Edge). De forma a modelar o facto de cada ligação entre duas
paragens puder ser realizada por diferentes linhas de transporte e/ou por deslocação pedestre,
cada arco é também ele constituído por um subconjunto de conexões, representado pela classe
Connection. Assim, a classe Connection poderá corresponder a uma ligação do tipo pedestre
ou de autocarro. Se a ligação for de autocarro, existe sempre a associação ao identificador da
respetiva linha de transporte. A cada vértice estão ainda associados um conjunto ordenado de
horários (classe OrderedScheduleResumed). Através da utilização de tabelas de hash, cada
horário, representado pela classe ScheduleResumed, é agrupado pela linha de transporte e
também pela hora a que se realiza.
A aplicação do algoritmo para obter os melhores planos gera objetos do tipo DetailedPathResult
que por sua vez são constituídos por um conjunto de objetos do tipo Connection. Esta primeira
classe contém ainda detalhes da viagem completa, como é o caso do número de transbordos, a
distância total, a distância total pedestre, tempo total de viagem e o tempo total de espera. Cada
objeto do tipo Connection contém tipos primitivos que apenas são preenchidos pelo algoritmo e
que detalham a distância, o tempo ou os horários de cada ligação utilizado pelo plano.
38 CAPÍTULO 4. IMPLEMENTAÇÃO
4.2.2 Camada de Apresentação
Esta camada disponibiliza a interface de acesso Web aos serviços do Simulador de Viagem.
Esta interface foi implementada exclusivamente como um WebService da plataforma .NET, não
existindo nenhum requisito para qualquer outro tipo de acesso. Assim, os serviços são identifi-
cados por um URI, descritos e definidos usando XML e acedidos através do uso dos protocolos
HTTP e Simple Object Access Protocol (SOAP). O Simulador de Viagem apenas é constituído
por um único serviço:
• SimulateTrip(TripPlannerRequest request): em que os dados necessários para a exe-
cução do simulador são descritos no objeto request do tipo TripPlannerRequest com os
seguintes tipos primitivos:
– sourceLat : latitude da origem.
– sourceLon: longitude da origem.
– destinationLat : latitude do destino.
– destinationLon: longitude do destino.
– sourceName: morada da origem.
– destinationName: morada do destino.
– time: hora e data do início da viagem.
– preference: preferência de viagem (tempo ou transbordos).
– maxPedestrianDistance: distância máxima a caminhar.
O pedido é propagado para a camada inferior onde será executado o algoritmo. Os resultados
obtidos são retornados sob a forma de uma lista de objetos do tipo DetailedPathModel.
4.2.3 Camada Lógica
O ficheiro de configuração Web.config contém a atribuição às seguintes variáveis utilizadas na
construção do grafo e na execução do algoritmo:
• ConnectionMaxPedestrianDistance: distância pedestre máxima entre duas paragens
(em metros).
• GraphUpdatePeriod: período de atualização dos dados (em minutos).
• TimeEstimatorUse: limite máximo para incluir a consulta ao servidor de estimativa de
tempos no algoritmo do Simulador de Viagem (em minutos).
4.2. SIMULADOR DE VIAGEM 39
• MaxPaths: limite máximo de alternativas a calcular para cada pedido.
A classe Singleton TripPlanner é o componente base e controlador de todo o processo. É ins-
tanciada com a inicialização da aplicação, sendo desde logo construído o grafo correspondente
à rede de trânsito. Este processo consiste em obter toda a informação necessária do XTraN
Passenger para construir os vértices e os arcos do grafo. Para além das ligações de autocarro já
existentes no XtraN Passenger, são adicionadas ligações do tipo pedestre entre todos os vértices
cuja distância não exceda o limite definido por ConnectionMaxPedestrianDistance. Para calcular
a distância entre duas paragens, é aplicada a distância de Manhattan, também conhecida como
Taxicab geometry1. A distância retilínea entre dois pontos geográficos não representa, na mai-
oria das vezes, a distância necessária que uma pessoa precisa de percorrer para se deslocar
entre esses dois pontos no mundo real. A distância de Manhattan apresenta uma aproximação
suficientemente realista para a simulação pretendida. São também pré-calculados todos os ho-
rários de serviço das carreiras existentes. Estes horários são posteriormente associados a cada
vértice/paragem. Toda este informação é atualizada com uma periodicidade GraphUpdatePe-
riod, i.e., é feita a reconstrução do grafo e de toda a sua informação.
Toda esta pré-computação é realizada antes de qualquer pedido proveniente da Web visto que
se trata de uma estrutura de dados independente e que servirá como recurso para a execução
do algoritmo do Simulador de Viagem. Já no âmbito do processamento de cada pedido proveni-
ente da camada de apresentação, é instanciada uma Thread da classe BestPaths responsável
por aplicar o seguinte processo:
1. Criação de vértices provisórios correspondentes ao ponto de origem e destino.
2. Criação de arcos/ligações provisórias do tipo pedestre entre o vértice origem e destino e
todos os outros vértices pertencentes ao grafo excluindo ligações superiores à distância
máxima a caminhar (maxPedestrianDistance).
3. É aplicado o algoritmo dos melhores planos de viagem entre a origem e o destino (apre-
sentado na próxima secção).
4. Caso a diferença entre a data de início da viagem e a data a que o pedido foi processado
seja inferior a TimeEstimatorUse minutos, são aplicados os seguintes passos adicionais
para cada caminho obtido (acesso ao Servidor de Estimativas de Tempo):
• Para cada ligação realizada por autocarro e na qual a linha de transporte não seja
continuação da anterior, são obtidas previsões de chegada à respetiva paragem. Para1http://wikipedia.org/wiki/Taxicab_geometry (Acedido em Agosto 2012)
40 CAPÍTULO 4. IMPLEMENTAÇÃO
cada ligação realizada por autocarro e na qual a linha de transporte seja continuação
da anterior, é simulado o tempo de chegada à paragem com base na duração da
ligação, evitando assim outro acesso ao Servidor de Estimativa de Tempos.
• São atualizados os tempos de chegada e partida para cada vértice/paragem e é veri-
ficado se o plano de viagem se mantém exequível na existência de atrasos.
• Caso existam alterações ao tempo total de viagem, é feito um reordenamento dos
melhores planos de viagem.
5. São removidos os vértices e arcos/ligações provisórios.
6. Com base nos melhores planos de viagem obtidos, são geradas e retornadas as respetivas
vistas à camada de apresentação.
4.2.4 Algoritmo dos Melhores Planos de Viagem
Foi escolhido e adaptado o algoritmo de Dijkstra para ser aplicado durante a execução deste
algoritmo com base em diferentes redes de transito. Para a execução deste algoritmo existem
duas estruturas auxiliares: RT que armazena diferentes redes de transito em forma de fila First
In First Out (FIFO) e que inicialmente é preenchida com a rede de trânsito original; MPV que
armazena os caminhos obtidos em cada iteração do algoritmo de Dijkstra. O algoritmo dos
melhores planos de viagem é constituído por um ciclo principal que é executado enquanto RT
não está vazio e o tamanho de MPV seja menor ou igual ao limite máximo de MaxPaths. Cada
iteração é descrita pelo seguinte processo:
• Aplicação do algoritmo de Dijkstra tendo como rede de transito o primeiro elemento retirado
da fila RT .
• Caso a aplicação do algoritmo de Dijkstra tenha retornado um caminho válido p, este é
guardado na estrutura MPV e são construídas n redes de transito. Cada nova rede de
transito é um ajustamento da rede utilizada pelo caminho p. São removidas todas as co-
nexões (representadas pela estrutura Connection) correspondentes a uma linha de trans-
porte utilizada durante o caminho p, i.e., não será mais utilizada essa linha de transporte
na nova rede de transito. Cada rede de transito obtida por este tarefa é adicionada à fila
RT .
Por fim, é feito uma reordenação sobre a estrutura MPV tendo como critério de ordenação a
preferência especificada pelo utilizador.
4.2. SIMULADOR DE VIAGEM 41
Com este processo é garantido que nas diversas iteração do ciclo principal sejam obtidos ca-
minhos consideravelmente diferentes que no limite poderão ser compostos pelas mesmas para-
gens/vértices mas nunca pelas mesmas conexões. Assim sendo, n corresponde ao número de
linhas de transporte existentes no caminho obtido pelo algoritmo de Dijkstra. Esta solução foi
adotada visto que o propósito deste algoritmo é apresentar ao utilizador alternativas compostas
por uma ou mais linhas de transporte diferentes do plano anterior, sempre ordenadas pela pre-
ferência especificada (tempo ou número de transbordos). A remoção da conexões não significa
a remoção dos arcos entre quaisquer dois vértices e desta forma, a ligação continuará a ser
exequível se existir uma outra conexão.
Em cada iteração do ciclo principal é garantido o caminho mais curto com a respetiva rede de
transito mas não são garantidos os K caminhos mais curtos no final deste algoritmo pois a modi-
ficação da rede de transito é feita ao nível das linhas de transporte e não ao nível das paragens.
Contudo, os planos apresentados não deixam de ser aproximações bastante próximas aos ca-
minhos mais curtos e apresentam, dentro do âmbito dos transportes públicos, soluções bastante
lógicas para o utilizador. Contextualizando, um utilizador dos transportes públicos ao considerar
dois planos de viagem que permitem chegar ao seu destino, não vê sentido em considerar a
alternativa ao plano principal, a execução da mesma linha de transporte mas em que se verifi-
que o seu abandono numa paragem antecipada. I.e., uma determinada linha de transporte que
possibilite uma chegada em menor tempo ao destino não deverá ser interrompida de forma a
ser considerada em diferentes planos de viagem.
4.2.4.1 Algoritmo de Dijkstra
A escolha deste algoritmo é justificada pelo facto de se tratar de um algoritmo ótimo com com-
plexidade de O(|E| + |V |log|V |) caso seja utilizada uma fila de prioridades. Para mais, este
algoritmo é considerado como o mais rápido tendo em conta a sua aplicação num grafo dirigido
com pesos de arcos positivos e origem única. De forma concisa e sucinta, o algoritmo de Dijkstra
segue sempre o caminho cuja a distância acumulada até então, seja a mais reduzida. No âmbito
desta aplicação, os arcos utilizados pelo algoritmo serão pesados de acordo com o tempo total
da viagem ou o número de transbordos ocorridos, conforme a preferência do utilizador. O peso
dos arcos apenas pode ser atribuído em tempo de execução do algoritmo pois estes estão de-
pendentes da hora de chegada à respetiva paragem/vértice e/ou da linha de transporte utilizada
anteriormente. O pseudo-código do algoritmo de Dijkstra é dado por:
1 function Dijkstra(Graph, source):
2 for each vertex v in Graph:
42 CAPÍTULO 4. IMPLEMENTAÇÃO
3 dist[v] := infinity ;
4 previous[v] := undefined ;
5 connection[v] := undefined;
6 pedestrian[v] := 0;
7 dist[source] := 0 ;
8 Q := the set of all nodes in Graph ;
9 while Q is not empty:
10 u := vertex in Q with smallest distance in dist[] ;
11 if dist[u] = infinity:
12 break ;
13 remove u from Q ;
14 for each neighbor v of u:
15 conn := best_conn_between(u, v) ;
16 alt := dist[u] + conn.dist ;
17 if alt < dist[v]:
18 dist[v] := alt ;
19 previous[v] := u ;
20 connection[v] := conn;
21 if conn = pedestrian:
22 pedestrian[v] := pedestrian[u] + conn.dist;
23 else
24 pedestrian[v] := pedestrian[u];
25 decrease-key v in Q;
A distância, representada pelo vetor dist, é dada pelo tempo total de viagem ou pelo número
de transbordos, até ao vértice/paragem em questão. A estrutura previous permite guardar qual
o vértice/paragem utilizado anteriormente. Para além destas estruturas, imprescindíveis para a
execução do algoritmo, foram acrescentadas mais dois vetores: connections e pedestrian. O
primeiro permite guardar as conexões utilizadas anteriormente e a segundo permite guardar a
distância pedestre realizada até cada vértice/paragem de forma a controlar a distância realizada
a pé pelo utilizador. Para a atribuição do vértice u na linha 10, é mantido uma estrutura ordenada
pela distância implementada através de um SortedDictionary.
Com base no horário previsto de chegada ao vértice u, a função best_conn_between(u, v) deter-
mina qual a melhor conexão que possibilita a deslocação de u para o vértice v. Independente-
mente da preferência de viagem especificada pelo utilizador, é realizado o seguinte processo:
4.3. SERVIDOR INFOBUS 43
se for possível continuar na mesma linha de transporte do que a conexão anterior, é escolhida
a conexão entre u e v que tiver essa mesma linha de transporte, evitando assim um tempo de
espera desnecessário em u. Caso contrário, é escolhida a conexão, pedestre ou de autocarro,
que possibilite o menor horário previsto de chegada ao vértice v. Para tal, é necessário aceder à
informação dos horários de transporte armazenada nas estruturas OrderedScheduleResumed.
Este processo respeita sempre o filtro de horários de acordo com o tipo de dia e a respetiva
época. Por outro lado, a escolha de uma conexão pedestre terá sempre em consideração o
valor presente na estrutura pedestrian. Caso esta variável ultrapasse o valor definido pelo utili-
zador (maxPedestrianDistance), não serão mais utilizadas conexões pedestres.
Após este processo, se não for encontrado nenhum horário ou se não for possível realizar o
respetivo arco de forma pedestre, o peso atribuído ao arco será representado por infinity.
Caso contrário, ao peso do arco será atribuído o tempo de viagem associado a essa conexão
(tempo de deslocação entre paragens mais o tempo de espera) se a preferência for o caminho
mais rápido ou um número real pertencente ao intervalo [0, 1] se a preferência for o menor nú-
mero de transbordos. O valor 1 representa a ocorrência de um transbordo e o valor 0 o caso
oposto.
4.3 Servidor InfoBUS
O Servidor InfoBUS foi implementado com recurso à linguagem C# e à plataforma para o desen-
volvimento de aplicações Web, o ASP.NET. Para separar as tarefas da aplicação, foi utilizado o
padrão de arquitetura Model View Controller (MVC) implementado pelo ASP.NET MVC. Tal como
o Simulador de Viagem, a escolha destas tecnologias deve-se às mesmas razões anteriormente
referidas. Para mais, foi possível adaptar um projeto previamente desenvolvido pela Tecmic,
cujo propósito era bastante similar ao Servidor InfoBUS. Como ambiente de desenvolvimento foi
igualmente escolhido o Microsoft Visual Studio 2010 e o servidor aplicacional embutido Visual
Studio Development Server.
4.3.1 Camada de Apresentação
Com a utilização da tecnologia ASP.NET MVC, é possível disponibilizar uma API para o acesso
Web baseado numa arquitetura REST. Os serviços são identificados por um URI e acedidos atra-
vés do protocolo HTTP. Os dados retornados são unicamente estruturados em objetos JavaScript
Object Notation (JSON). Os serviços disponibilizados estão agrupados pelo tipo de dados a que
44 CAPÍTULO 4. IMPLEMENTAÇÃO
se referem. Estes agrupamentos correspondem às seguintes interfaces URI:
• http://ServerAddress/BusStop: informação de paragens.
• http://ServerAddress/BusStopRoute: informação de paragens de uma determinada li-
nha de transporte.
• http://ServerAddress/MobileActualState: informação de transportes em movimento.
• http://ServerAddress/Route: informação de rotas.
• http://ServerAddress/RouteVariantDirection: informação de variações de rotas com o
sentido definido.
• http://ServerAddress/TimeEstimation: previsões em tempo real da chegada dos auto-
carros às paragens.
• http://ServerAddress/TripPlanner: simulação de planos de viagem.
Consequentemente, a cada URI é acrescentado uma String que correspondente à definição de
cada pedido. Por exemplo, o URI http://ServerAddress/BusStop/GetByRVD?10, corresponde
à obtenção de paragens que estejam presentes na linha de transporte identificada pelo número
10. A String GetByRVD identifica a função, com ou sem argumentos, acedida dentro da camada
lógica. Todas as funções desenvolvidas serão listadas na próxima secção.
4.3.2 Camada Lógica
A cada agrupamento identificado está associado um controlador responsável pelo processa-
mento do pedido. Cada controlador é implementado por uma classe cujo nome é uma concate-
nação do nome da interface URI com a String Controller. O diagrama de classes representado
na figura 4.12 contém todos os controladores desenvolvidos assim como a listagens de funções
que podem ser acedidas dentro de cada controlador. Com a exceção dos controladores TimeEs-
timationController e TripPlannerController, a implementação de cada função de cada controlador
limita-se a utilizar a camada de acessos aos dados do XTraN Passenger, o PassengerDAL, para
processar o pedido. No caso dos controladores TimeEstimationController e TripPlannerControl-
ler, são invocados os WebServices na aplicação correspondente. Posteriormente, são construí-
das as vistas relativas aos dados obtidos e devolvidas à camada de apresentação. As vistas
são objetos constituídos unicamente por tipos primitivos que resumem ou filtram a informação
presente em cada objeto do domínio do XTraN Passenger.
4.4. APLICAÇÃO MÓVEL 45
Figura 4.12: Controladores - Diagrama de Classes
4.4 Aplicação Móvel
A Aplicação Móvel foi desenvolvida para o sistema operacional Android e consequentemente
escrita em Java. A escolha desta tecnologia é justificada pelo seu rápido crescimento no mer-
cado, pelo facto de ser Open Source e da experiência de desenvolvimento adquirida em projetos
académicos anteriores. O ambiente de desenvolvidamente utilizado foi o Eclipse com o plugin
AVD.
A camada de apresentação é representada por uma interface gráfica definida em ficheiros XML
correspondentes aos diversos ecrãs. A lógica de negócio foi implementada com recurso a ativi-
dades e serviços fornecidos pelo sistema Android. Por fim, os dados estão armazenados numa
base de dados relacional SQLite e acedidos através duma camada desenvolvida para esse pro-
pósito. De forma a facilitar a compreensão desta secção, após uma descrição da estrutura de
dados utilizada, a implementação deste componente será explicada da seguinte forma: para
cada menu principal de interação com o utilizador, serão apresentadas as atividades/serviços
desenvolvidas, os ficheiros XML usados, imagens da aplicação e outros detalhes de implemen-
tação. Os casos de uso foram associados a diferentes menus de acordo com o seu propósito.
46 CAPÍTULO 4. IMPLEMENTAÇÃO
4.4.1 Estrutura de Dados
Todos os dados utilizados pela aplicação são reconstruções dos objetos correspondentes às
vistas retornadas em formato JSON por parte do Servidor InfoBUS reaproveitando toda a sua
lógica de dados. Os dados são assim representados pelas classes ilustradas na figura 4.13. As
classes, BusStopRouteModel e BusStopModel, modelam informação das paragens com ou sem
linha de transporte associada, respetivamente. As classes, RouteModel e RouteVariantDirecti-
onModel, contêm informação de rotas e variações de rota com sentido definido, respetivamente.
A classe TimeEstimationModel traduz as previsões de chegada dos autocarros às paragens.
Para representar o estado de um determinado transporte em movimento é utilizado a classe
MobileActualStateModel. Já as classes, DetailedPathModel e ConnectionModel, encapsulam
dados referentes ao resultado do pedido de simulação de viagem e constituem as únicas enti-
dades persistidas localmente na aplicação móvel.
Foi desenvolvida uma camada de abstração denominada e implementada na classe InfoBUS-
DAL que permite o acesso aos dados persistidos na base de dados relacional SQLite. Foram
também criados métodos para a atualização, inserção ou remoção dos dados armazenados.
4.4.2 Menus de Interação
4.4.2.1 Inicialização - Menu Principal
Com a inicialização da aplicação é lançada a atividade MainMenuGridActivity à qual está as-
sociado o ficheiro XML main_menu_grid. Em termos de interface gráfica, são apresentadas as
4 principais funcionalidades disponibilizadas pela aplicação móvel: Informação/Localização de
Transportes, Avisos e Alertas, Simulador de Viagem e Gestão/Acompanhamento de Viagem.
Adicionalmente, é instanciada a classe RestAPIClient responsável por executar todos os pedi-
dos ao Servidor InfoBUS independentemente da atividade/serviço em execução. A configuração
dos URI acedidos pela aplicação móvel, do porto e do endereço do servidor é definido no ficheiro
config.properties. A interface do menu principal está representada na figura A.20(a).
4.4.2.2 Informação/Localização de Transportes
A atividade principal responsável por esta funcionalidade é TransportInformationActivity à
qual está associado o ficheiro XML transport_info_map. O ecrã desta atividade, representado
na figura A.20(b), é inteiramente ocupado pelo mapa de estradas disponibilizado pelo Google
Maps. As opções acessíveis pela tecla menu desta atividade são: determinar e apresentar a
4.4. APLICAÇÃO MÓVEL 47
Figura 4.13: Estrutura de Dados - Diagrama de Classes
48 CAPÍTULO 4. IMPLEMENTAÇÃO
posição atual do utilizador no mapa após uma consulta ao sistema GPS do dispositivo móvel;
determinar as paragens nas imediações, funcionalidade ilustrada na figura A.20(c). O procedi-
mento para esta segunda funcionalidade consiste em adquirir as coordenadas geográficas de
dois cantos opostos do mapa, formalizar e enviar o pedido através do objeto RestAPIClient.
Para evitar que a área do mapa seja demasiado grande, i.e., que faça retornar um número
excessivo de paragens, a área é limitada a um determinado nível de zoom. O URI acedido
é http://ServerAddress/BusStop/GetByGeoEnvelope com os respetivas coordenadas como
argumento. As paragens retornadas são utilizadas para serem desenhadas as paragens so-
brepostas ao mapa. Qualquer outro pedido feito ao Servidor InfoBUS é análogo e não será
novamente descrito.
Para qualquer paragem que se encontre desenhada no mapa, desta atividade ou de outra poste-
riormente apresentada, é possível consultar informação detalhada da mesma. Caso seja essa a
ação executada pelo utilizador, é lançada a atividade DetailedBusStopInfoActivity associado
ao ficheiro XML tabhost_info, onde é possível consultar informação generalizada da paragem
como a sua morada, linhas de transporte que passam na paragem e as próximas previsões de
chegada dos transportes. As figuras A.21(a), A.21(b), A.21(c) e A.22(a) ilustram estas funciona-
lidades.
Alternativamente, é possível realizar uma pesquisa avançada através da atividade SearchAc-
tivity à qual está associado o ficheiro XML search_form. O utilizador tem à sua disposição os
seguintes tipos de pesquisa (interface representada na figura A.22(b)):
• Pesquisa da linha de transporte: São obtidas todas as rotas existentes através do Ser-
vidor InfoBUS, dando ao utilizador a possibilidade de selecionar a que deseja e a sua res-
petiva variação. Consequentemente, será mostrado no mapa da atividade TransportInfor-
mationActivity todas as paragens pertencentes a essa rota assim como a posição atual
dos transportes que estão a realizar essa linha de transporte (figuras A.22(c) e A.23(a)). A
posição dos transportes é atualizada periodicamente caso o utilizador assim o deseje. Tal
como cada paragem, é possível consultar informação detalhada de cada transporte (figura
A.23(b)).
• Pesquisa do local: À medida que o utilizador for escrevendo o nome do local, são apre-
sentadas diversas opções para completar o local desejado. Esta funcionalidade foi imple-
mentada com recurso aos serviços do Google Places API com acesso análogo ao Servidor
InfoBUS, i.e., é feito um acesso ao URI correspondente, sendo retornado um objeto JSON
com as sugestões para os caracteres inseridos até ao momento. Após a escolha da opção
4.4. APLICAÇÃO MÓVEL 49
correta, o mapa é centrado na morada correspondente.
• Pesquisa pela paragem: Assim que o utilizador concluir a sua escrita, são obtidas e
apresentadas as hipóteses válidas para os caracteres introduzidos através dum pedido
ao Servidor InfoBUS. Após a escolha da opção correta, o mapa é centrado na paragem
correspondente.
4.4.2.3 Avisos e Alertas
Esta funcionalidade não foi implementada pois a Tecmic não possui de momento nenhum com-
ponente do XTraN Passenger que disponibilize esta informação para o âmbito do sistema Info-
BUS.
4.4.2.4 Simulador de Viagem
O objetivo desta funcionalidade é permitir ao utilizador introduzir todos os dados necessários
para que possam ser calculados e apresentados consequentemente os melhores planos de
viagem. Todos os ecrãs desta funcionalidade estão ilustrados nas figuras A.23(c), A.24, A.25,
A.26 e A.27. A atividade lançada inicialmente é a TripPlannerActivity associada ao ficheiro
XML trip_planner. Os campos obrigatórios e que necessitam de ser preenchidos pelo utilizador
são:
• Origem e Destino: O ponto de origem e do destino podem ser determinados de duas
formas: pela posição atual do dispositivo móvel (através do sistema GPS); e pela es-
pecificação de um ponto no mapa. Para a segunda, é lançada uma atividade auxiliar
(SelectPlaceActivity) permitindo ao utilizador escolher diretamente no mapa de estradas,
qual a origem/destino.
• Data de partida: O utilizador poderá escolher a data atual ou especificar uma nova data
superior à data atual.
• Preferência: percurso mais rápido ou percurso com menos transbordos.
Todos os campos são validados antes de ser formalizado o pedido para o Servidor InfoBUS.
Caso a resposta contenha pelo menos um plano de viagem, os resultados são apresenta-
dos resumidamente numa nova atividade (TripPlannerResultsActivity associada ao ficheiro
trip_planner_result). O utilizador poderá executar 3 ações sobre cada plano obtido:
50 CAPÍTULO 4. IMPLEMENTAÇÃO
1. Consulta do plano detalhado com especificação dos sub-trajetos a realizar pé e de au-
tocarro, das linhas de transporte a utilizar e de todos os tempos e distâncias em cada
sub-trajeto. Para tal é lançada a atividade TripPlannerDetailedRouteActivity.
2. Visualização do plano no mapa de viagem com identificação de todas as paragens incluí-
das no plano assim como a rota realizada durante o plano através da atividade TripPlan-
nerMapRouteActivity. O plano de viagem obtido apenas contém o conjunto de todas as
paragens ordenadas, não contendo as rotas que fazem a ligação entre as mesmas. De
forma a contornar esta limitação do sistema XTraN Passenger, a ligação entre as paragens
é representada pelo melhor trajeto que permita uni-las. Contudo, pode acontecer o caso
do percurso mostrado não corresponder exatamente ao real mas face ao âmbito para que
está a ser utilizado, tal não se revela um problema visto que a representação é apenas
para o utilizador ter uma ideia por onde os transportes vão passar. Este trajeto é dado pelo
serviço do Google Maps através da formalização de um URI que encapsule o pedido. O
retorno desta invocação é um objeto JSON que será processado pela aplicação móvel.
3. Agendamento do plano de viagem através do armazenamento de forma persistente do
plano de viagem selecionado podendo ser consultado ou executado mais tarde através do
menu Gestão/Acompanhamento de Viagem. Tal ação é realizada com recurso à camada
InfoBUSDAL.
4.4.2.5 Gestão/Acompanhamento de Viagem
Neste menu é possível visualizar e gerir todos os planos de viagem controlados pela aplicação.
A atividade inicial responsável por este menu é a TripManagerActivity. A cada plano de viagem
está associado um estado: agendado; em execução; expirado; e completo. Quando o plano é
agendado pelo utilizador através do Simulador de Viagem, é associado o estado agendado. So-
bre este plano, o utilizador poderá novamente consultar o plano detalhado ou a sua ilustração
no mapa tal como especificado na secção anterior. Adicionalmente, poderá apaga-lo de forma
permanente. Caso o plano se encontre no estado agendado ou em execução, é possível come-
çar ou continuar a tarefa do acompanhamento de viagem.
A funcionalidade do acompanhamento de viagem foi implementada com recurso a um serviço
e a uma atividade. Tal decisão deve-se à necessidade desta tarefa ser executada em segundo
plano, i.e., sem ser necessário a consulta da interface gráfica e da respetiva atividade por parte
do utilizador. Assim, caso o utilizador tenha como atividade topo a TripMonitoringActivity, to-
das as notificações serão demonstradas na interface gráfica dessa atividade. A comunicação
4.4. APLICAÇÃO MÓVEL 51
entre o serviço e a atividade é realizada através da declaração de um BroadcastReceiver na
atividade e do envio de Intent por parte do serviço com filtros apropriados. Caso contrário, ou
seja, caso o utilizar se encontre noutra atividade da aplicação ou mesmo fora do contexto da
aplicação, será notificado através do sistema Android e do seu serviço de notificações.
Em termos de implementação, ao lançar a atividade responsável pelo acompanhamento de
viagem (TripMonitoringActivity) é iniciado o serviço TripMonitoringService. Este por sua vez
lança uma Thread (MonitoringTrip) cuja função é acompanhar a deslocação do utilizador ao
longo do plano, detetando os diversos eventos. A lógica desta tarefa foi implementada através
duma máquina de estados representada na figura 4.14. Com o início da viagem existe uma
transição para o estado Caminhar. Através deste estado é possível chegar a um estado final
caso a ligação atual seja a última, i.e., que permita chegar ao destino. Caso contrário, a ligação
terá como destino uma paragem, levando a que seja atualizado o estado para Espera. Para de-
tetar a chegada ao destino ou à paragem, a Thread MonitoringTrip compara a posição atual do
dispositivo móvel com a posição da paragem ou do destino através duma manipulação das co-
ordenadas geográficas. A periodicidade desta comparação está dependente da receção duma
atualização de posição por parte do sistema GPS. Assim que a distância entre os dois pontos
seja inferior a um limite estipulado, existirá uma transição de estados. No estado Espera apenas
existe uma transição possível para o estado Transporte que representa a chegada do transporte
à paragem. Para detetar este evento, é lançada uma Thread auxiliar (BusLocationUpdater)
responsável por interrogar periodicamente o Servidor InfoBUS pela posição atual do respetivo
transporte. Já no estado Transporte existem 3 transições possíveis aquando da chegada a uma
paragem. Caso seja uma paragem de saída e a próxima ligação seja efetuada a caminhar, existe
uma transição para o estado Caminhar. Caso seja uma paragem de saída mas a próxima ligação
seja efetuada noutro transporte, existe uma passagem para o estado Espera. Caso contrário,
trata-se meramente de uma paragem realizada pelo transporte que não deverá ser utilizada pelo
utilizador. A comparação de posições entre os transportes, paragens e o dispositivo móvel é
análoga à descrita anteriormente.
Com a ocorrência de um evento, existe a necessidade de notificar o utilizador da estado atual da
sua viagem ou da transição ocorrida. Foram desenvolvidas as seguintes notificações para esse
propósito:
• Informação do próximo transporte
• Próxima paragem a utilizar
• Caminhar até à próxima paragem
52 CAPÍTULO 4. IMPLEMENTAÇÃO
Figura 4.14: Acompanhamento de Viagem - Máquina de estados
• Caminhar até ao destino
• Abandonar o transporte na próxima paragem
• Não abandonar o transporte na próxima paragem
• Chegada ao destino
• Chegada à paragem
• Apanhar o transporte
Qualquer ação não prevista do utilizador, como por exemplo a perca de um transporte, ou o
atraso significativo de um transporte que invalide a execução do plano de viagem, não é atu-
almente detetado pela aplicação móvel. Tais ações ou condicionantes não foram identificadas
como requisitos a implementar numa primeira fase do projeto. No entanto, a solução para estes
problemas passaria por detetar estes casos através de comparações de posição semelhantes
às descritas anteriormente ou por análise a atrasos registados. Seria acrescentando um estado
de erro na máquina de estados e assim que ocorresse uma transição para este novo estado,
seria requisitado um novo plano de viagem ao Servidor InfoBUS com um novo ponto de origem
e uma nova data de partida relativamente ao pedido inicial.
Capítulo 5
Avaliação
Durante o desenvolvimento do sistema foram realizados testes de unidade para garantir a
correta implementação de todos os requisitos e funcionalidades. A integridade e validade
da comunicação entre os diversos componentes foi verificada com testes de integração. Como
avaliação do sistema final foram tiradas métricas relativas a duração de tarefas e de memória
ocupada. Foram verificados todos os casos de uso exercidos pelo utilizador na Aplicação Móvel.
Os testes foram realizados num computador com as características descritas na figura 5.15 e os
dados utilizados do XTraN Passenger são referentes à zona geográfica do Chapecó, Brasil.
(a) Caracteristicas CPU (b) Caracteristicas Memória
Figura 5.15: Máquina de testes
53
54 CAPÍTULO 5. AVALIAÇÃO
5.1 Algoritmo do Simulador de Viagem
5.1.1 Tempo de Inicialização e Análise dos Dados
A aplicação do algoritmo para determinar os planos de viagem necessita de dados referentes à
rede de trânsito. Estes dados são pré-computados antes de qualquer pedido efetuado ao Simu-
lador de Viagem, ou seja, são pré-computados com a inicialização do algoritmo e atualizados
com período definido pelo administrador do sistema. Este processo foi avaliado através da du-
ração desta tarefa e das características do grafo resultante como a memória ou o número de
vértices. Foram realizadas 5 experiências nas quais houve uma variação crescente da quanti-
dade de carreiras como dados de entrada. A base de dados do XTraN Passenger possui no seu
total 350 carreiras. A tabela 5.3 agrega todos os resultados obtidos.
Existe um aumento linear entre o número de carreiras processadas como input e o número de
conexões no grafo resultante. O mesmo se aplica à relação entre número de carreiras e o me-
mória do grafo. Já o número de vértices e de arcos tem uma variação de crescimento menor à
medida que o número de carreiras aumenta. O tempo de construção também aumenta linear-
mente com o número de carreiras processadas como input e o seu valor de grandeza justifica-se
pelo facto de ser necessário aceder aos dados presentes na base de dados do XTraN Passen-
ger de forma a obter as paragens, ligações entre paragens, linhas de transporte e os respetivos
horários. Este processo engloba também o cálculo e adição de ligações pedestres entre as
paragens. A memória ocupada pelo conjunto de dados completo (350 Carreiras) é de 23 MB e
corresponde a um total de 591 vértices/paragens, 1202 arcos/ligações e 8726 conexões. Estes
dados são mantidos em memória principal durante todo o tempo de execução do Simulador de
Viagem.
5.1.2 Pedidos ao Simulador de Viagem
A duração da execução do algoritmo dos melhores planos de viagem é um fator crucial para
a avaliação do Simulador de Viagem. O sucesso deste componente assenta na capacidade
de serem apresentados os melhores planos de viagem, em tempo aceitável para o utilizador,
independentemente da diversidade no valores de entrada. O teste apresentado consiste na
formulação de pedidos ao Simulador de Viagem com dados de entrada gerados aleatoriamente:
ponto de origem e destino (dentro dos limites geográficos da zona do Chapecó, Brasil), data
5.1. ALGORITMO DO SIMULADOR DE VIAGEM 55
Carreiras Tempo (Seg) Vértices/Paragens Arcos Conexões Memória (MB)
70 11,70 383 653 1430 5
140 15,31 524 946 3327 10
210 23,24 543 1006 5330 15
280 31,83 578 1106 7374 19
350 36,18 591 1202 8726 23
Tabela 5.3: Construção das estruturas de dados
de partida (entre as 8 e as 23 horas do dia 21/08/2012) e distância máxima pedestre (valores
entre 500 e 1000). Este teste não contempla a segunda fase do algoritmo, i.e., a conjugação
dos resultados com a previsão de chegada dos autocarros às paragens dada pelo Servidor de
Estimativa de Tempos. Cada pedido foi duplicado para ser processado tendo como preferência
para a viagem o caminho mais rápido e no seu duplicado, o caminho com menos transbordos.
Foram realizados 100 experiências nestas condições. Os gráficos da figura 5.16 apresentam a
duração do algoritmo para cada um dos pedidos respetivamente. Os resultados obtidos revelam
uma média de 74 milissegundos para a execução do algoritmo tendo como heurística o tempo
mínimo e 93 milissegundos para a minimização de transbordos. Existem no entanto alguns
casos em que o tempo de execução atingiu valores máximos de 896 e 1107 milissegundos.
Tais casos podem ser justificados pela necessidade do algoritmo Dijkstra ter executado até ao
fim, i.e., ter processado todos os nós e todas as combinações possíveis de ligações entre os
mesmos e não ter encontrado qualquer plano exequível. O valor da distância pedestre máxima
pode não ter sido suficiente ou não existir efetivamente uma rota entre os pontos especificados.
5.1.3 Planos de Viagem Detalhados
Tão importante como o tempo de execução do algoritmo é o conteúdo dos resultados apresen-
tados. O segundo teste feito ao Simulador de Viagem tem como objetivo detalhar os resultados
obtidos após a execução do algoritmo, verificar as diferenças entre os planos obtidos com dife-
rentes preferências e valida-los manualmente. Os dados de entrada são gerados aleatoriamente
tal como no teste anterior. Existe ainda a variação da preferência para determinar os planos
de viagem: FASTEST - percurso mais rápido; MIN_TRANSHIPMENT - percurso com menos
56 CAPÍTULO 5. AVALIAÇÃO
(a) Resultados - Caminho mais rápido
(b) Resultados - Caminho com menos transbordos
Figura 5.16: 100 Pedidos ao Simulador de Viagem
transbordos. As figuras B.28 e B.29 sumarizam as experiências realizadas nestas condições,
detalhando os dados de entrada e as características dos 3 melhores planos obtidos segundo
o critério especificado. Para cada plano é apresentado o tempo total de viagem, o tempo total
de espera, a distância total, a distância total pedestre e o número de transbordos. No caso da
preferência ser o percurso mais rápido, os resultados são ordenados pelo tempo total. Caso con-
trário, os resultados são ordenados pelo número de transbordos, tornando possível que planos
secundários tenham efetivamente uma duração inferior ao plano principal. A existência dos 3
melhores planos com caraterísticas similares em relação às distâncias não é de estranhar visto
que existem diversas linhas de transporte que executam as mesmas ligações entre paragens.
Com este teste é possível concluir que os planos fazem sentido do ponto de vista do utilizador e
que as alternativas apresentadas são válidas.
5.1. ALGORITMO DO SIMULADOR DE VIAGEM 57
5.1.4 Conjugação de Resultados com o Servidor de Estimativa de Tempos
A conjugação de resultados com o Servidor de Estimativa de Tempos foi excluída dos testes
anteriores visto que é necessário uma atualização em tempo real da posição dos autocarros no
mundo real. Tal não acontece visto que os dados recolhido correspondem a um backup da base
de dados do XTraN Passenger. Logo todos os pedidos ao Servidor de Estimativa de Tempos são
inconsequentes no que diz respeito à atualização de tempos dos planos previamente obtidos.
As previsões retornadas coincidem com os tempos obtidos durante a primeira fase do algoritmo.
De forma a testar a execução do algoritmo completo, esta limitação é contornada pela interceção
de cada chamada ao Servidor de Estimativa de Tempos, retornando um resultado fictício que
provoque a alteração dos planos. Este teste foi realizado sobre os seguintes planos de viagem
obtidos na primeira fase do algoritmo:
1. Plano A: Trajeto constituído pelas ligações: Deslocação pedestre - Carreira 70 (3 para-
gens - Horário na 1ª paragem: 08:40:00) - Carreira 71 (1 paragem - Horário na paragem:
08:50:00) - Deslocação pedestre.
2. Plano B: Trajeto constituído pelas ligações: Deslocação pedestre - Carreira 100 (4 para-
gens - Horário na 1ª paragem: 08:50:00) - Deslocação pedestre.
3. Plano C: Trajeto constituído pelas ligações: Deslocação pedestre - Carreira 82 (4 paragens
- Horário na 1ª paragem: 09:00:00) - Deslocação pedestre.
A previsão de chegada das carreira 70, 100 à respetiva paragem foi atrasada em 15 minutos.
Como resultado desta ação, o plano A tornou-se inválido visto que o horário da carreira 71 não se
atrasou e era necessário a chegada do utilizador à paragem de entrada da carreira 71 até o seu
horário de passagem do autocarro (08:50:00). Já os restantes planos continuaram exequíveis
mas com uma alteração no tempo de viagem no plano B. No entanto, houve uma reordenação
da ordem dos planos, sendo apresentados como resultado final os planos C e B nesta precisa
ordem. De notar que as previsões disponibilizadas pelo servidor de estimativa de tempos são
sempre referente a todos os veículos duma determinada carreira, contemplando assim o facto
de que se existisse uma outra carreira 70 com horário de passagem na 1ª paragem às 08:41:00,
o plano A apenas sofreria uma alteração de tempo de viagem. Através deste teste foi possível
testar todos os casos que poderão acontecer na realidade sendo os resultados os expectáveis.
58 CAPÍTULO 5. AVALIAÇÃO
5.2 Aplicação Móvel
5.2.1 Testes de Usabilidade
Para avaliar a usabilidade da aplicação móvel, foi pedido a 10 utilizadores que nunca tiveram
contacto prévio com a aplicação, que desempenhassem um conjunto de tarefas que corresponde
à execução dos casos de uso definidos. Cada tarefa foi avaliada segundo as seguintes métricas:
tempo, erros cometidos e grau de satisfação (1-Muito Insatisfeito; 2-Insatisfeito; 3-Satisfeito; 4-
Bom; 5-Muito Bom). As tarefas são:
1. Realizar uma pesquisa avançada para ir para o local: Chapecó - Santa Catarina, Brazil.
Obter as paragens nas imediações da área apresentada. Visualizar para uma das para-
gens obtidas pelo processo anterior, a informação dos itinerários e das próximas previsões
de chegada à respetiva paragem.
2. Realizar uma pesquisa avançada para obter informação da linha de transporte: 02-Tomazelli,
Tomazelli. Direcção: Down. Mostrar as viaturas no itinerário e consultar informação para
uma das viaturas ilustradas.
3. Realizar uma simulação de viagem com os seguintes dados: ponto de origem e de des-
tino especificados através do mapa e dentro dos limites de Chapecó; selecionar a data
24/08/2012 às 09:00 horas; percurso mais rápido; e distância máxima a pé de 750 metros.
Obter resultados e consultar o plano detalhado para o primeiro plano de viagem obtido.
Os resultados dos testes é expresso através da figura 5.17. A 1ª tarefa teve uma média de:
duração - 78,2 segundos; erros - 0,6; satisfação - 4,2. A 2ª tarefa teve uma média de: duração
- 83,4 segundos; erros - 0,3; satisfação - 4,2. A 3ª tarefa teve uma média de: duração - 150,5
segundos; erros - 0,2; satisfação - 4,8. Na sua generalidade, os utilizadores conseguiram exe-
cutar as tarefas sem necessitar de qualquer ajuda, compreendendo intuitivamente o que realizar
na aplicação. Em alguns casos, estes cometeram erros que atrasaram a conclusão da tarefa.
Alguns destes erros foram: navegação para o menu errado ou seleção da funcionalidade errada
à primeira tentativa. No caso específico do 5º utilizador da 2ª tarefa, este não encontrou a fun-
cionalidade de mostrar as viaturas no itinerário. Todas as tarefas, na opinião dos utilizadores,
contribuíram para uma satisfação global bastante positiva. A 3ª tarefa, apesar de ser a mais
extensa, foi a menos propensa a erros e com uma média de satisfação mais elevada.
5.2. APLICAÇÃO MÓVEL 59
(a) Duração das tarefas
(b) Erros cometidos
(c) Grau de satisfação
Figura 5.17: Resultados dos Testes de Usabilidade
60 CAPÍTULO 5. AVALIAÇÃO
5.2.2 Duração Pedido-Resposta
A duração entre o pedido ao servidor e a sua resposta é um fator critico porque qualquer utili-
zador não deverá esperar um tempo excessivo pela informação que pretende. Caso contrário,
o utilizador fica aborrecido, perdendo o interesse em utilizar as funcionalidades do sistema. O
requisito inicial para esta duração foi estabelecido em 3 segundos e foi avaliada através da for-
malização de 10 pedidos para cada uma das seguintes tarefas disponíveis na aplicação móvel:
obtenção das paragens nas imediações; simulação de viagem. Foram escolhidas estas funcio-
nalidades pois ilustram casos opostos: um pedido simples e um pedido mais complexo, exigindo
uma computação superior no Servidor, inigualável por qualquer outro pedido. Cada pedido foi
duplicado e avaliado segundo dois ambientes de ligação diferente (rede Wifi e rede 3G). A rede
Wifi utilizada foi a do Instituto Superior Técnico, com velocidades máximas de 54 Mbps e a rede
3G da Vodafone com velocidades máximas de 4 Mbps. O Servidor InfoBUS e o Simulador de
Viagem foram colocados numa rede doméstica com velocidades aproximadas de download e
upload de 50 Mbps e 8 Mbps, respetivamente. Os dados de entrada para qualquer pedido foram
gerados aleatoriamente dentro dos limites estipulados.
Os resultados obtidos para a execução dos 10 pedidos referentes à obtenção de paragens nas
imediações, representados na figura 5.18, revelam uma média da duração de 93,3 milissegun-
dos para a rede Wifi e de 251,3 milissegundos para a rede 3G. Já para os 10 pedidos referentes
à simulação de viagem, a média foi de 273,5 milissegundos para a rede Wifi e de 573,6 milisse-
gundos para a rede 3G. Os valores máximos são de 491 milissegundos e de 1333 milissegundos
para cada um diferentes tipos de pedidos, referentes em ambos os casos, à rede 3G. Os resul-
tados obtidos são satisfatórios e cumprem claramente o limite máximo traçada como requisito
inicial - 3 segundos.
5.2.3 Acompanhamento de Viagem
Em ordem de ser testada a funcionalidade do acompanhamento de viagem é necessário a re-
correr a dois tipos de simulação: a posição geográfica do dispositivo móvel e dos transpor-
tes que fazem parte do plano de viagem. Para simular a posição do utilizador foi desenvol-
vido uma aplicação extra em JAVA, denominada por InfoBUSSimulator, com o único propósito
de estabelecer uma ligação Telnet para o emulador do Android, para que sejam enviadas as
coordenadas geográficas. O emulador por sua vez, simula a receção de um sinal GPS no
sistema Android com as coordenadas recebidas anteriormente. Para simular a posição dos
transportes é intercetada a chamada ao servidor que é responsável por esta funcionalidade
5.2. APLICAÇÃO MÓVEL 61
(a) Paragens nas imediações
(b) Simulação de viagem
Figura 5.18: Resultados da Duração Pedido-Resposta
(http://ServerAddress/MobileActualState?plate=”plateNumber”), alterando os dados retor-
nados de forma a que exista uma deslocação fictícia dos transportes. Como referido anterior-
mente, a posição dos transportes não é atualizada na base de dados do XTraN Passenger visto
que se trata de um backup sem atualizações em tempo real.
O plano de viagem utilizado neste teste foi reaproveitado de testes anteriores, i.e., o plano cons-
tituído pelas ligações: Deslocação pedestre - Carreira 70 (3 paragens - Horário na 1ª paragem:
08:40:00) - Carreira 71 (1 paragem - Horário na paragem: 08:50:00) - Deslocação pedestre. Este
plano é constituído por ligações pedestres e duas carreiras, possibilitando assim o teste dos dife-
rentes casos de alternação do tipo de transporte: pedestre -> autocarro; autocarro -> autocarro;
autocarro -> pedestre. A figura 5.19 é constituída por imagens da aplicação móvel durante a
62 CAPÍTULO 5. AVALIAÇÃO
execução do plano especificado. O início do plano corresponde à deslocação pedestre até à pri-
meira paragem. Nesta paragem, o utilizador aguarda a chegada da Carreira 70 sendo possível
consultar a sua posição atual no mapa. Após o embarque, a aplicação notifica o utilizador das
paragens que deve ignorar e a paragem que deve utilizar para sair do autocarro. O processo de
espera por um transporte repete-se, neste caso, pela carreira 71 (omitido na imagens). Por fim,
e após a realização de uma ligação a caminhar, o utilizador chega ao seu destino final.
5.2. APLICAÇÃO MÓVEL 63
(a) Caminhar para a paragem (b) Chegada à paragem (c) Em espera do autocarro
(d) Chegada do autocarro (e) Em deslocação pelo autocarro (f) Paragem a não utilizar
(g) Paragem a utilizar (h) Caminhar para o destino final (i) Chegada ao destino
Figura 5.19: Teste do acompanhamento de viagem
Capítulo 6
Conclusão
Neste documento foi apresentado o sistema InfoBUS anyWhere. Este permite disponibili-
zar em ambiente móvel, parte da informação gerida pela empresa Tecmic relativa à sua
gestão inteligente de frotas dos transportes públicos, o XTraN Passenger. Incluído igualmente
neste sistema está o Simulador de Viagem que permite que o utilizador se abstraía da tarefa,
por vezes complexa e demorada, de determinar manualmente um plano de deslocação usando
os transportes públicos.
Como trabalho de pesquisa e contextualização face ao propósito deste projeto, foram apresen-
tados vários sistemas de apoio à utilização de transportes públicos, denominados de APTS.
Foram abordadas as funcionalidades de cada sistema, algumas das tecnologias inerentes e as
suas aplicações móveis. Foram também cobertos os sistemas APTS que incluem simuladores
de viagem. Estes assentam em diferentes técnicas, estruturas de dados e algoritmos que per-
mitem a determinação de planos de viagem tendo em consideração fatores como o tempo, o
número de transferências de linha de transporte ou a distância.
O sistema InfoBUS anyWhere é constituído por 3 componentes. Localizado nas infraestrutu-
ras da Tecmic, encontra-se o Simulador de Viagem. Este é responsável pela determinação
dos planos de viagem com base na informação presente no XTraN Passenger. Os dados são
convertidos numa estrutura de dados própria do Simulador de Viagem: um grafo que modela
toda a rede de trânsito, onde cada vértice corresponde a uma paragens e cada arco a uma liga-
ção, pedestre ou de transporte, entre duas paragens. O algoritmo de procura para a obtenção
dos melhores planos de viagem é baseado na aplicação do algoritmo de Dijkstra. A pesagem
de cada arco corresponde ao tempo ou ao número de transbordos total da viagem até então.
Sendo este critério determinado pelo pedido do utilizador, assim como o limite à deslocação
65
66 CAPÍTULO 6. CONCLUSÃO
pedestre. Após a obtenção dos planos de viagem, com base em horários estáticos, é feito uma
conjugação com informação em tempo real relativa aos atrasos dos transportes incluídos no
plano, validando ou reordenando os resultados anteriores.
Também presente nas infraestruturas da Tecmic encontra-se o Servidor InfoBUS cujo princi-
pal propósito é disponibilizar uma API, através da Web e com recurso a serviços REST, para o
acesso a todos os dados do XTraN Passenger e do Simulador de Viagem. O 3º componente
desenvolvido foi uma Aplicação Móvel para Android. Esta é responsável por apresentar gra-
ficamente ao utilizador a informação pretendida por este. Para tal, é feita uma comunicação
com o Servidor InfoBUS, invocando um dos seus serviços (informação de paragens, linhas de
transporte, horários, previsões de chegada, simulação de viagem, localização de veículos, etc.).
A aplicação móvel dispõe igualmente da funcionalidade de ser efetuado um acompanhamento
em tempo real da execução do plano de viagem obtido, alertando o utilizador de eventos como a
chegada do transporte, paragem a utilizar ou simplesmente informando-o do próximo transporte.
Todos os testes realizados ao sistema desenvolvido tiveram resultados satisfatórios. Para o
Simulador de Viagem, foram quantificados os tempos de inicialização e construção de dados,
assim como o desempenho do seu algoritmo de procura para um conjunto diversificado de da-
dos de entrada. Já o protótipo da aplicação móvel, foi sujeita a testes de usabilidade por parte
de diferentes utilizadores. O requisito para a duração entre o pedido e a resposta ser inferior a 3
segundos foi validado para redes Wifi e 3G. A funcionalidade do acompanhamento de viagem foi
também ela validada com recurso a algumas simulações devido ao impedimento de ser testado
em condições reais.
Todos os objetivos foram alcançados com sucesso e todos os requisitos definidos foram im-
plementados e validados. Contudo, existem alguns aspetos que deverão ser reavaliados e que
podem ser melhorados. A distância a pé entre duas paragens é calculada usando a distância de
Manhattan, o que pode levar a resultados enganadores uma vez que poderão haver casos onde
existem vias ou rios que não podem ser atravessados e é necessário percorrer uma distância
bastante superior.
O algoritmo dos melhores planos de viagem não garante os K caminhos mais curtos pois con-
sidera a exclusão de linhas de transporte e não de paragens em cada aplicação do algoritmo
de Dijkstra. Apesar de evitar o retorno de alternativas que não fazem sentido do ponto de vista
do utilizador, poderão existir casos em que a melhor alternativa ao plano principal consiste efe-
tivamente no abandono antecipado de uma determinada linha de transporte, também incluída
no plano principal, para considerar uma percurso diferente e viável. A solução para este pro-
blema passará por considerar a exclusão de caminhos entre as diversas iterações do algoritmo
6.1. TRABALHO FUTURO 67
de Dijkstra ao nível das linhas de transporte e das paragens.
Existe uma limitação da aplicação do algoritmo de Dijkstra face ao limite para a deslocação pe-
destre. Caso este limite seja ultrapassado durante a execução do algoritmo, este não considera
a utilização de mais ligações pedestres. Tal facto pode levar a que não seja encontrado o ca-
minho mais curto. O comportamento exemplar seria tolerar a utilização numa primeira fase de
ligações mais demoradas (sem ser a pé) para mais tarde poder andar a pé.
6.1 Trabalho Futuro
A implementação do algoritmo dos melhores planos de viagem poderá incorporar algum parale-
lismo entre as diversas invocações ao algoritmo de Dijkstra. Podem ser incluídos outro tipo de
preferências para serem determinados os melhores planos de viagem, preferências como preço
das viagens ou restringir o uso de algum tipo de transportes. Podem inclusive ser considerados
outros algoritmos para a determinação do caminho mais curto.
A aplicação móvel encontra-se completamente funcional. No entanto, deverá ser melhorada
em termos de interface gráfica, proporcionando ao utilizador uma experiência mais satisfatória
e agradável em termos de visualização e interação com o dispositivo. Novas funcionalidades,
como a receção de avisos e alertas, também podem ser incluídas. O acompanhamento de vi-
agem poderá ser estendido de forma a incorporar a deteção de incumprimentos do plano de
viagem face a erros do utilizador ou a atrasos dos transportes públicos.
Bibliografia
[1] S. D. Maclean and D. J. Dailey. The use of wireless internet service to access real-time tran-
sit information. In Proceedings of the Nineth Annual World Congress on Intelligent Transport
Systems 2002, 2002.
[2] S.J. Barbeau, P.L. Winters, N.L. Georggi, M.A. Labrador, and R. Perez. Travel assistance
device: utilising global positioning system-enabled mobile phones to aid transit riders with
special needs. volume 4, pages 12–23. 2010.
[3] Brian Ferris, Kari Watkins, and Alan Borning. Onebusaway: A transit traveler information
system. In Mobile Computing, Applications, and Services - First International ICST Con-
ference, MobiCASE 2009, San Diego, CA, USA, October 26-29, 2009, Revised Selected
Papers, volume 35, pages 92–106. Springer, 2009.
[4] Liping Zhang, Jing-Quan Li, Kun Zhou, Somak Gupta, Meng Li, Wei-Bin Zhang, Mark Miller,
and James Misener. Traveler information tool with integrated real-time transit information
and multimodal trip planning. pages 1–10. 2011.
[5] American Public Transit Association. Public transportation facts at a glance. Technical
report, APTA, 2008.
[6] D. Schrank and T.Lomax. 2009 urban mobility report. Technical report, Texas Transportation
Institute, 2009.
[7] Jeffrey L Adler and Victor J Blue. Toward the design of intelligent traveler information sys-
tems. volume 6, pages 157–172. 1998.
[8] Research, Special Programs Administration, and Volpe National Transportation Systems
Center. Advanced public transportation systems : the state of the art : update 2000. Federal
Transit Administration, 2000.
[9] Bharat Rao and Louis Minakakis. Evolution of mobile location-based services. volume 46,
pages 61–65. ACM, New York, NY, USA, 2003.
69
70 BIBLIOGRAFIA
[10] S.D. Maclean and D.J. Dailey. Busview: a graphical transit information system. In Intelligent
Transportation Systems, 2001, pages 1073–1078. IEEE, 2001.
[11] Donald Patterson, Lin Liao, Krzysztof Gajos, Michael Collier, Nik Livic, Katherine Olson,
Shiaokai Wang, Dieter Fox, and Henry Kautz. Opportunity knocks: A system to provide
cognitive assistance with transportation services. In UbiComp 2004: Ubiquitous Computing.
Springer.
[12] Joo-Yen Choi, Ja-Hyun Jung, Sungmi Park, and Byeong-Mo Chang. A location-aware smart
bus guide application for seoul. In Convergence and Hybrid Information Technology, 2008.
ICCIT ’08. Third International Conference on, volume 1, pages 875–880, 2008.
[13] Katrin Dziekan and Karl Kottenhoff. Dynamic at-stop real-time information displays for public
transport: effects on customers. volume 41, pages 489–501. 2007.
[14] Brian Ferris, Kari Watkins, and Alan Borning. Onebusaway: Location-aware tools for impro-
ving public transit usability. 2010.
[15] Brian Ferris, Kari Watkins, and Alan Borning. Onebusaway: results from providing real-time
arrival information for public transit. In Proceedings of the 28th international conference
on Human factors in computing systems, pages 1807–1816, Atlanta, Georgia, USA, 2010.
ACM.
[16] K.G. Zografos, K.N. Androutsopoulos, and V. Spitadakis. Design and assessment of an
online passenger information system for integrated multimodal trip planning. volume 10,
pages 311–323. IEEE, 2009.
[17] Chao-Lin Liu, Tun-Wen Pai, Chun-Tien Chang, and Chang-Ming Hsieh. Path-planning algo-
rithms for public transportation systems. In Intelligent Transportation Systems, 2001, pages
1061–1066. IEEE, 2001.
[18] Ravindra K. Ahuja, Thomas L. Magnanti, and James B. Orlin. Network Flows: Theory,
Algorithms, and Applications. Prentice Hall, 1993.
[19] Jerald Jariyasunant and Eric Mai. Algorithm for finding optimal paths in a public transit
network with real-time data. In Transportation Research Board 90th Annual Meeting, 2010.
[20] Joel Booth, Prasad Sistla, Ouri Wolfson, and Isabel F. Cruz. A data model for trip planning
in multimodal transportation systems. In Proceedings of the 12th International Conference
on Extending Database Technology: Advances in Database Technology, pages 994–1005,
New York, NY, USA, 2009. ACM.
BIBLIOGRAFIA 71
[21] M. Erwig and M. Schneider. Spatio-temporal predicates. volume 14, pages 881–901. IEEE,
2002.
[22] Daniel Delling, Peter Sanders, Dominik Schultes, and Dorothea Wagner. Engineering route
planning algorithms. In Algorithmics of Large and Complex Networks. Lecture notes in
computer science. Springer, 2009.
[23] Zihui Zang and Wenxue Cai. A dynamic shortest path algorithm based on real-time traffic
information in the urban public transit network. In Service Operations and Logistics, and
Informatics, 2008. IEEE International Conference on, volume 2, pages 1500–1504. IEEE,
2008.
[24] L.P. Zhang W.-B. Zhang J.Q. Li, K.Zhou. A multimodal trip planning system incorporating the
park-and-ride mode and real-time traffic/transit information. In ITS World Congress, 2010.
[25] Boris Cherkassky, Andrew V. Goldberg, and Tomasz Radzik. Shortest paths algorithms:
Theory and experimental evaluation. volume 73, pages 129–174. 1993.
[26] Víctor Jiménez and Andrés Marzal. Computing the k shortest paths: A new algorithm and
an experimental comparison. In Jeffrey Vitter and Christos Zaroliagis, editors, Algorithm
Engineering, volume 1668, pages 15–29. Springer, Berlin, 1999.
Apêndice A
Imagens da Aplicação Móvel
73
74 APÊNDICE A. IMAGENS DA APLICAÇÃO MÓVEL
(a)M
enuprincipal
(b)Inform
ação/Localizaçãode
Transportes-O
pções(c)
Paragens
nasim
ediações
FiguraA
.20:Im
agensda
Aplicação
Móvel
75
(a)
Info
rmaç
ãopa
rage
m(b
)In
form
ação
gera
lda
para
gem
(c)
Info
rmaç
ãodo
siti
nerá
rios
que
pass
amna
para
gem
Figu
raA
.21:
Imag
ens
daA
plic
ação
Móv
el
76 APÊNDICE A. IMAGENS DA APLICAÇÃO MÓVEL
(a)Inform
açãodas
próximas
previsõesde
chegadaà
paragem(b)
Pesquisaavançada
(c)Linha
detransporte
seleccionada
FiguraA
.22:Im
agensda
Aplicação
Móvel
77
(a)
Mos
trarv
iatu
ras
noiti
nerá
rio(b
)In
form
ação
doau
toca
rro
(c)
Sim
ulad
orde
Via
gem
Figu
raA
.23:
Imag
ens
daA
plic
ação
Móv
el
78 APÊNDICE A. IMAGENS DA APLICAÇÃO MÓVEL
(a)H
ipótesesde
escolhapara
oponto
departida
(b)E
scolhado
pontode
partidaatravés
dom
apa(c)
Selecção
dadata
departida
FiguraA
.24:Im
agensda
Aplicação
Móvel
79
(a)
Sel
ecçã
oda
pref
erên
cia
devi
agem
eda
dist
ânci
am
áxim
ape
dest
re(b
)P
lano
sde
viag
emob
tidos
(c)
Açõ
esso
bre
opl
ano
devi
agem
Figu
raA
.25:
Imag
ens
daA
plic
ação
Móv
el
80 APÊNDICE A. IMAGENS DA APLICAÇÃO MÓVEL
(a)P
lanode
viagemdetalhado
(b)P
lanode
viagemno
mapa
(c)P
lanoagendado
FiguraA
.26:Im
agensda
Aplicação
Móvel
81
(a)
Ges
tão
dos
plan
osag
enda
dos
Figu
raA
.27:
Imag
ens
daA
plic
ação
Móv
el
Apêndice B
Resultado dos Testes
83
84 APÊNDICE B. RESULTADO DOS TESTES
FiguraB
.28:R
esultadosdetalhados
doS
imuladorde
Viagem
(Dados
deentrada
e1º
plano)
85
Figu
raB
.29:
Res
ulta
dos
deta
lhad
osdo
Sim
ulad
orde
Via
gem
(2º
e3º
plan
o)