IST Shuttle
Sistema de gestão em tempo real do serviço de shuttle - front office
Ricardo Andrade Fernandes
Dissertação para a obtenção de grau de mestre em
Engenharia Informática e de Computadores
Orientadores: Prof. Ricardo Jorge Feliciano Lopes Pereira
Prof. Teresa Maria Sá Ferreira Vazão Vasques
Júri
Presidente: Prof. Nuno João Neves Mamede
Orientador: Prof. Ricardo Jorge Feliciano Lopes Pereira
Vogal: Prof. João Pedro Faria Mendonça Barreto
Novembro 2014
Agradecimentos
Em primeiro lugar gostava de agradecer aos meus orientadores, o Prof. Ricardo Lopes Pereira e a Profa
Teresa Maria Sá Ferreira Vazão Vasques, pelo apoio e orientação cientı́fica, assim como a disponibilidade e paciência que apresentaram durante o decorrer desta tese, para que este projecto e dissertação
fossem desenvolvidos da melhor maneira possı́vel.
Gostava igualmente de agradecer à minha famı́lia por todo o apoio e suporte que me deram durante
toda a minha vida pessoal e académica e pelas palavras de encorajamento, principalmente nesta fase
final.
Por último, mas não menos importante quero agradecer a todos os meus amigos e colegas que se
disponibilizaram para fazer os testes da aplicação e aos que me foram dando conselhos, sugestões e
orientações.
iii
iv
Abstract
This document presents a proposal for a system of reservations in the shuttle, a service provided by
Instituto Superior Técnico (IST) which allows the transportation of students between the two campi.
The solution will allow users to reserve a travel in the shuttle, taking into account the existing schedule,
thus avoiding moving to the stops when that is already packed. Similarly, it will avoid unnecessary
travel to stops when there are no passengers entering or leaving, in order to reduce costs and save the
environment. It also allows control the use of this service, achieving a real and correct record of the
use. So a possible solution will be presented that takes into account the priorities and objectives of IST,
the expectations of users and the expectable features of the application, considering other solutions to
similar problems. Existing systems will be presented, focusing on the problems they have and explaining
why they are not valid solutions for this problem. In addition this document will present and analyse
previous data of the using of this service in previous years in order to prove that the current system of
control of use is not the best, exposing the flaws of it. Finally, the goal will be show the steps taken in
order to develop the solution, why it is so important to the user and what IST will gain from it.
Keywords: Shuttle, Reserve Management, Control of Use, Web Interface, Mobile Devices
v
vi
Resumo
Este documento apresenta uma proposta para um sistema de reservas de lugares no shuttle, um serviço
disponibilizado pelo IST que permite o transporte de alunos entre os dois campi do mesmo. A solução
irá permitir que os utilizadores reservem viagens no shuttle, tendo em conta o horário já existente, evitando que assim se desloquem para as paragens quando aquele já estiver lotado. Do mesmo modo,
irá evitar deslocações desnecessárias às paragens quando não existirem passageiros que pretendam
entrar ou sair, de forma a diminuir custos e poupar o meio ambiente. Também será possı́vel controlar a
utilização deste serviço, conseguindo-se um registo real e correto da mesma. Assim será apresentada
uma possı́vel solução que tem em conta as prioridades e objetivos do IST, as expectativas dos utilizadores e as funcionalidades espetáveis da aplicação, considerando outras soluções para problemas
semelhantes. Serão apresentados os sistemas já existentes, focando os problemas que estes apresentam e explicando por que motivo não são soluções válidas. Serão também apresentados os dados
de utilização deste serviço nos anos anteriores, de modo a comprovar que o atual sistema de controlo
de utilização não será dos melhores, expondo-se as falhas do mesmo. Por fim, o objetivo é mostrar as
medidas tomadas para desenvolver a solução, porque é tão importante para os utilizadores e que irá o
IST ganhar com isso.
Palavras-chave:
Shuttle, Gestão de Reservas, Controlo de Utilização, Interface Web, Dis-
positivos Móveis
vii
viii
Conteúdo
Agradecimentos
iii
Abstract
v
Resumo
vii
Lista de Tabelas
xiv
Lista de Figuras
xv
Acrónimos
xvii
1 Introdução
1.1 Enquadramento
1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Objetivos e proposta de solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3 Contribuições esperadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Trabalho relacionado
2.1 Sistemas de contagem de passageiros
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2 Sistemas de reserva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1 Sistemas de reserva planeada . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2 Sistemas de reserva em tempo-real . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3 Sı́ntese e comparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3 Sistemas de validação de passageiros . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4 Tecnologias relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.1 Sistemas informáticos do IST - Fénix
. . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4.2 Dispositivos móveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3 Arquitetura
19
3.1 Levantamento de requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.1 Elaboração do inquérito e entrevistas . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1.2 Súmula dos resultados dos inquéritos e entrevistas . . . . . . . . . . . . . . . . .
25
ix
3.2 Requisitos do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3 Descrição geral do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.4 Descrição detalhada dos componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4.1 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4.2 Gestão de reservas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.4.3 Gestão de carreiras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.4 Gestão de estatı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.5 Interação com motorista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.4.6 Sı́ntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4 Implementação
35
4.1 Opções de implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.1.1 Nova solução versus solução existente . . . . . . . . . . . . . . . . . . . . . . . .
35
4.1.2 Aplicação nativa versus aplicação web . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.1.3 Base de dados relacional versus não relacional . . . . . . . . . . . . . . . . . . . .
37
4.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.1 Simplificações e alterações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.2 Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.2.3 Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.2.4 Aplicação final desenvolvida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5 Avaliação
49
5.1 Objetivo dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.2 Cenários de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.2.1 Testes de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.2.2 Testes de aceitação com utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.2.3 Testes de carga e performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.3 Resultados dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.3.1 Testes de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.3.2 Testes de aceitação com utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.3.3 Testes de carga e performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.3.4 Análise de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
6 Conclusão
70
6.1 Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.2 Conquistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6.3 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
x
A Aplicação desenvolvida
73
A.1 Diagrama de navegação detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
A.2 Interfaces da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Referências
86
xi
xii
Lista de Tabelas
1.1 Percursos do Shuttle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.1 Exemplo de uma página com Responsive Web Design (RWD). . . . . . . . . . . . . . . .
18
3.1 Interação entre as diferentes partes do sistema . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2 Análise das respostas tendo em conta a função desempenhada. . . . . . . . . . . . . . .
21
3.3 Análise das respostas tendo em conta o uso de dispositivos móveis e o acesso à internet
dos mesmo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.4 Análise das respostas tendo em conta a utilização do shuttle. . . . . . . . . . . . . . . . .
22
3.5 Análise das respostas tendo em conta a importância de um sistema de reservas e a
preferência de lotação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.6 Análise das respostas tendo em conta a disposição dos utilização do shuttle para reservarem bilhetes e o tipo de reserva que pretendem. . . . . . . . . . . . . . . . . . . . . . .
22
3.7 Importância das diferentes modalidades de reservas. . . . . . . . . . . . . . . . . . . . .
23
3.8 Análise das respostas tendo em conta a preferência das penalizações a adotar. . . . . .
23
3.9 Diagrama de blocos dos componentes do sistema . . . . . . . . . . . . . . . . . . . . . .
30
3.10 Fluxograma da autenticação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.11 Fluxograma do processo de efetuar nova reserva. . . . . . . . . . . . . . . . . . . . . . .
31
3.12 Fluxograma do processo de cancelar uma reserva. . . . . . . . . . . . . . . . . . . . . . .
31
3.13 Fluxograma dos processos criar nova carreira, percurso, motorista, veiculo, perı́odo e
atualizar utilizador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.14 Fluxograma dos processos eliminar nova carreira, percurso, motorista, veiculo e perı́odo.
33
3.15 Fluxograma da análise de estatı́sticas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.16 Fluxograma das funcionalidades de interação com o motorista. . . . . . . . . . . . . . . .
34
4.1 Modelo Entidade Relacionamento (ER) da base de dados. . . . . . . . . . . . . . . . . .
39
4.2 Caso de uso de um utilizador do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3 Caso de uso de um administrador de sistema. . . . . . . . . . . . . . . . . . . . . . . . .
45
4.4 Caso de uso da gestão de viagens.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.5 Diagrama de navegação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.6 Diagrama de navegação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.7 Diagrama de navegação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
xiii
5.1 Gráfico de dispersão da atividade 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.2 Gráfico de dispersão da atividade 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.3 Gráfico de dispersão da atividade 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.4 Gráfico de dispersão da atividade 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.5 Gráfico de dispersão da atividade 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.6 Gráfico de dispersão da atividade 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.7 Gráfico de dispersão da atividade 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.8 Gráfico de dispersão da atividade 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.9 Gráfico de dispersão da atividade 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.10 Gráfico de dispersão da atividade 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.11 Gráfico de dispersão da atividade 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.12 Gráfico de dispersão da atividade 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.13 Gráfico do teste de carga e performance sobre a homepage. . . . . . . . . . . . . . . . .
65
5.14 Gráfico do teste de carga e performance para consulta de horário. . . . . . . . . . . . . .
66
5.15 Gráfico do teste de carga e performance para consultar os percursos do shuttle. . . . . .
66
5.16 Gráfico do teste de carga e performance para fazer nova reserva. . . . . . . . . . . . . .
67
5.17 Gráfico do teste de carga e performance para cancelar uma reserva. . . . . . . . . . . . .
67
5.18 Gráfico do teste de carga e performance para consultar o estado das reservas. . . . . . .
68
5.19 Gráfico do teste de carga e performance para a página do regulamento. . . . . . . . . . .
68
5.20 Gráfico do teste de carga e performance para a página dos contactos. . . . . . . . . . . .
69
A.1 Diagrama de navegação detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.2 Interface da aplicação - consulta horário.
. . . . . . . . . . . . . . . . . . . . . . . . . . .
75
. . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.4 Interface da aplicação - criar nova reserva. . . . . . . . . . . . . . . . . . . . . . . . . . .
76
A.5 Interface da aplicação - eliminar reserva. . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
A.6 Interface da aplicação - consulta do estado das reservas. . . . . . . . . . . . . . . . . . .
77
A.7 Interface da aplicação - imprimir ficha de viagem. . . . . . . . . . . . . . . . . . . . . . . .
77
A.8 Interface da aplicação - atualizar dados de viagem. . . . . . . . . . . . . . . . . . . . . . .
78
A.9 Interface da aplicação - criar perı́odo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
A.10 Interface da aplicação - eliminar perı́odo. . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
A.11 Interface da aplicação - criar carreira. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
A.12 Interface da aplicação - eliminar carreira. . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
A.13 Interface da aplicação - criar motorista e veı́culo. . . . . . . . . . . . . . . . . . . . . . . .
80
A.14 Interface da aplicação - eliminar motorista ou veı́culo. . . . . . . . . . . . . . . . . . . . .
81
A.15 Interface da aplicação - atualizar a prioridade. . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.16 Interface da aplicação - analisar estatı́sticas. . . . . . . . . . . . . . . . . . . . . . . . . .
82
A.17 Interface da aplicação - regulamento.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
A.18 Interface da aplicação - contactos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
A.3 Interface da aplicação - consulta percurso.
xiv
Lista de Figuras
2.1 Sistemas de contagem de passageiros: sı́ntese final. . . . . . . . . . . . . . . . . . . . .
7
2.2 Sistemas de reserva planeada: sı́ntese final. . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3 Sistemas de reserva em tempo-real: sı́ntese final. . . . . . . . . . . . . . . . . . . . . . .
11
2.4 Comparação entre as arquiteturas das soluções estudadas. . . . . . . . . . . . . . . . . .
11
2.5 Comparação entre as funcionalidades básicas das soluções estudadas. . . . . . . . . . .
12
2.6 Comparação entre as funcionalidades adicionais das soluções estudadas. . . . . . . . .
13
2.7 Comparação entre programas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.8 Custos e benefı́cios de programar para cada sistema operativo. . . . . . . . . . . . . . . .
18
4.1 Sı́ntese de componentes essenciais de outros sistemas. . . . . . . . . . . . . . . . . . . .
36
4.2 Diferenças entre bases de dados relacionais e não relacionais. . . . . . . . . . . . . . . .
38
5.1 Bateria de testes para novas reservas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.2 Bateria de testes para atualizar dados de viagem, quando o utilizador está presente. . . .
52
5.3 Bateria de testes para atualizar dados de viagem, quando o utilizador não está presente.
52
5.4 Bateria de testes para criar percurso.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.5 Bateria de testes para atualizar dados de viagem, quando o utilizador não está presente.
54
xv
xvi
Lista de Acrónimos
ADT Android Developer Tools
API Application Programming Interface
BI Bilhete de Identidade
CSS Cascading Style Sheets
DAEMON Disk And Execution Monitor
ER Entidade Relacionamento
GPS Global Positioning System
HTML HyperText Markup Language
ILR Intelligent Lane Reservation
IST Instituto Superior Técnico
JS JavaScript
JSON JavaScript Object Notation
MMS Multimedia Messaging Service
OD Matrix Origin/Destination Matrix
PHP PHP: Hypertext Preprocessor
QR Code Quick Response Code
RAID Redundant Array of Inexpensive Disks
RAM Random-Access Memory
RSU RoadSide Unit
RWD Responsive Web Design
SDK Software Development Kit
SMS Short Message Service
VANET Vehicular Ad Hoc Networks
xvii
xviii
Capı́tulo 1
Introdução
Este capı́tulo serve para enquadrar o âmbito da tese e o trabalho desenvolvido na mesma. Não existindo
nenhuma solução para resolver o problema em causa, será apresentada uma descrição sumária do
problema, bem como os objetivos e proposta de solução. Por fim, será enunciada a estrutura global
deste documento.
1.1
Enquadramento
O IST iniciou a sua atividade em 1911, tendo esta sido integralmente desenvolvida em Lisboa até ao
ano 2000, quando entrou em funcionamento o pólo do Taguspark. Este pólo, sediado na confluência
dos Concelhos de Sintra e Oeiras, no maior parque de Ciência e Tecnologia português, situa-se a cerca
de 20Km do campus da Alameda, servindo uma população estudantil de cerca de 1800 alunos. A pouco
eficiente rede de transportes públicos que serve os utentes do parque tem levado a um crescente uso de
serviços privados de transportes pelas entidades que nele desenvolvem parte da sua atividade, como
seja o IST. Foi neste contexto que, em 2005 foi lançado um serviço de shuttle, destinado a melhorar a
acessibilidade ao campus do Taguspark.
Quando este serviço começou não tinha grande aceitação por parte da comunidade, porque a frota
era muito reduzida e os horários e percursos disponibilizados muito limitados. Em 2010 foi efetuado
um inquérito à população do IST sobre o serviço de shuttle, com especial incidência para os membros
que frequentavam o campus do Taguspark. Este revelou que, num universo de cerca de 330 inquiridos,
mais de 50% considerava o número de carreiras insuficiente, optando os inquiridos por se deslocar por
outro meio de transporte, nomeadamente viatura própria.
Contudo, com a evolução da utilização e do serviço, este melhorou substancialmente e hoje tem um
leque alargado de horários. Atualmente, o serviço de shuttle é constituı́do por um conjunto de carreiras
regulares que asseguram o transporte entre os dois campi e as estações de Cacém e de Oeiras, e um
conjunto de carreiras ocasionais, que decorrem da necessidade de transportes fora destes perı́odos
associadas à realização de testes e exames. A Figura 1.1 mostra os diferentes percursos e paragens
que o shuttle pode efetuar.
1
Figura 1.1: Percursos do Shuttle.
Na atual configuração do serviço, existe um autocarro permanentemente alocado ao IST, que é
reforçado no perı́odo da manhã, almoço e final da tarde, perı́odos de maior afluência. Para proceder ao
planeamento da capacidade e à definição de carreiras, existem registos diários da ocupação de cada
autocarro e das entradas/saı́das em cada paragem, que são recolhidas pelos motoristas. Todavia,
este tipo de mecanismo não permite gerir as variações de procura de forma eficiente, verificando-se a
ocorrência de situações em que o autocarro vai completamente lotado – por vezes não há lugar para
todos os utilizadores – e noutras em que contabiliza apenas um número muito reduzido de passageiros,
fazendo paragens desnecessárias.
Segundo estudos deste ano letivo, o valor máximo de ocupação média do shuttle registou-se em
setembro e foi cerca de 69%1 . Como tem sido tendência natural dos últimos anos, verificam-se taxas de
ocupação mais reduzidas ao longo do semestre. Contabilizando apenas os valores médios dos primeiros quatro meses do ano letivo (setembro a dezembro) o serviço transportou 1977 passageiros. Com
um nı́vel de utilização tão elevado, em muitas situações, os passageiros deparam-se com um autocarro
totalmente lotado, impossibilitando-os de se deslocarem entre os campi nos horários pretendidos.
Por forma a melhor o serviço de shuttle, tornando-o mais vantajoso para os utilizadores e, idealmente, menos dispendioso para o IST, o presente projeto descreve uma solução que irá permitir aos
utilizadores deste serviço fazer ou cancelar reservas de viagens entre as diferentes paragens do autocarro.
1.2
Objetivos e proposta de solução
O serviço de reserva de bilhetes para o shuttle tem por objetivo possibilitar a gestão eficiente do serviço
oferecido pelo IST, através da possibilidade dos utentes procederem à reserva prévia de viagens,
alteração e cancelamento, em tempo real, de viagens reservadas. O processo de reserva deve ser
flexı́vel, permitindo efetuar reservas planeadas, mas também reservas de última hora.
Adicionalmente, e uma vez que é expectável que os utentes se esqueçam de reservar lugares, pelo
menos na fase inicial de lançamento do serviço, as reservas deverão incidir sobre uma percentagem
(parametrizável) da capacidade do veı́culo. Deverão ainda ser consideradas situações prioritárias, em
que o transporte do utente em causa deva ser assegurado, e situações em que, por forma a incentivar
1 Taxe
de ocupação média diária em todas as carreiras do mês de setembro
2
a utilização responsável, e por o serviço ser gratuito, exista uma penalização.
Os utentes devem usar a sua identidade IST para aceder ao sistema, podendo realizar estas
operações através de um dispositivo móvel ou fixo. A gestão de reservas será centralizada num servidor que se encarrega de responder aos pedidos dos utentes, em função do estado de ocupação do
veı́culo e do perfil do utente. A lista de reservas de cada viagem deverá ser enviada para o veı́culo,
de forma a que possa ser validada no ato de entrada de passageiros. A validação pode ser realizada
automaticamente por um sistema existente no veı́culo, ou manualmente, pelo condutor do autocarro.
O sistema deverá ainda disponibilizar um conjunto de estatı́sticas que permitam ao IST gerir o
serviço de forma mais eficiente. Caso seja possı́vel utilizar um sistema embarcado no veı́culo, com capacidades de comunicação, as estatı́sticas devem fornecer informação sobre cada viagem, em temporeal.
1.3
Contribuições esperadas
Este sistema propõe resolver o problema das filas de espera para o shuttle.
A principal contribuição será o sistema de reservas, que permitirá aos utilizadores planearem as
suas viagens, garantindo que terão lugar no autocarro, sendo que também estarão disponı́veis as
funções de alteração e cancelamento de reservas. Do lado da administração, o sistema permitirá gerir
carreiras, horários e percursos.
O sistema do veı́culo - hardware que fará o registo de entradas e saı́das de passageiros - está fora
do âmbito da presente tese.
1.4
Estrutura do documento
Esta tese é composta por 6 capı́tulos e 1 anexo.
Depois desta breve introdução ao problema, segue-se o capı́tulo 2 sobre o estado da arte onde
serão analisados os sistemas de contagem de passageiros, os sistemas de reserva planeada e em
tempo real, com respetiva sı́ntese e comparação sobre estes, passando depois para as tecnologias
relacionadas, com especial incidência para o Fénix e para as plataformas de dispositivos móveis.
No capı́tulo 3 será feita uma apresentação da proposta de arquitetura da solução, visando a descrição
geral e propriedades do sistema e descrição detalhada dos componentes.
Nos capı́tulos seguintes, 4 e 5, serão descritas as implementações e as tecnologias escolhidas bem
como os testes realizados e respetivos resultados.
Por fim o capı́tulo 6 apresentará o resumo do trabalho efetuado e das conclusões retiradas do
trabalho realizado, face aos resultados obtidos.
3
4
Capı́tulo 2
Trabalho relacionado
Este capı́tulo tem por objetivo apresentar o resultado do estudo do trabalho relacionado. O estudo
reparte-se em duas secções, na primeira são apresentados sistemas de reserva, com especial ênfase
para os processos de entrada e saı́da de passageiros em transportes públicos e para os diferentes
tipos de reserva. Na segunda secção serão apresentadas tecnologias que terão um contributo importante no desenvolvimento deste projeto, como sejam os sistemas informáticos do IST que suportam a
comunidade académica (Fénix) e as diferentes plataformas para dispositivos móveis.
Em cada secção será feita uma sı́ntese final, de forma a facilitar a análise e identificação dos aspetos
mais relevantes, que poderão influenciar a solução final a criar.
2.1
Sistemas de contagem de passageiros
O registo e análise de entradas e saı́das de passageiros em transportes públicos é utilizado para justificar e aumentar a eficiência dos mesmos. Existem várias maneiras de fazer este registo, quer por
observação/registo humano, o que ao fim de algum tempo torna a informação obsoleta e imprecisa,
quer por sistemas informáticos atuais, com registos automáticos. Do leque de sistemas disponı́veis foram estudados os seguintes sistemas:Origin/Destination Matrix (OD Matrix), EZ-Link e Quick Response
Code (QR Code) Ticket. A escolha dos mesmos deve-se ao simples facto de serem os que melhor se
enquadram com a temática e com a solução pretendida para o problema inicial, isto porque quer-se um
sistema que registe de forma rápida e eficaz tanto as entradas como saı́das dos passageiros, podendo
ser feitas tanto com recurso a um cartão como a QR Code.
O sistema OD Matrix foi criado com o intuito de obter dados de fluxo de passageiros entre as diferentes paragens dos transportes públicos. Os autocarros estão equipados com um sistema que guarda
a informação relativa à entrada de passageiros através dos bilhetes, quer eletrónicos quer para viagens únicas. Esta informação é transferida para um servidor central cada vez que o autocarro retorna
à garagem. Assim sendo, o principal problema é conseguir obter os dados referentes às saı́das de
passageiros. Para isto, este tipo de sistema usa um ”scanner”de Bluetooth que é instalado no teto do
autocarro e regista a deteção de dispositivos com esta tecnologia e o momento em que estes deixam
5
de ser detetáveis, considerando assim entradas e saı́das do autocarro, respetivamente [1]. A limitação
deste sistema reside na impossibilidade de obter o número exato de passageiros com base nesta tecnologia, uma vez que nem toda a gente tem dispositivos portadores desta tecnologia, e muitas vezes ela
estar desligada e de não ser possı́vel a nenhum sistema ligá-la automaticamente, ou detetá-la quando
desligada.
O EZ-Link faz a contagem de passageiros através de um smart card, obrigando o viajante a autenticarse à entrada e à saı́da do transporte [2]. Tal como acontece com o Metro, por exemplo, se o cartão
contiver unicamente a informação de entrada, este não pode voltar a entrar; do mesmo modo, se não
tiver informação de entrada, também não poderá sair. Ou seja, fazendo uma analogia com o sistema
binário em que 1 significa que o cartão registou entrada no sistema e 0 que registou saı́da, caso o
cartão tenha 1 este só poderá sair, caso tenha 0 este só poderá entrar. Esta informação é representada
por bits guardados no smart card. Dado que os cartões têm um identificador único e que pertencem a
uma e uma só pessoa, pelo menos em teoria, é possı́vel saber o trajeto efetuado e o tempo que este
demorou. Estes dados, tanto de passageiros como de viagens, estão todos registados e guardados
num servidor central.
A grande maioria dos transportes públicos faz o pagamento das viagens no ato da entrada do passageiro, mas o sistema QR Code Ticket tem uma visão diferente sobre esta temática e recorre ao uso
de dispositivos móveis para efetuar a compra dos bilhetes e evitar as filas na autenticação dos bilhetes. O passageiro é obrigado a validar a entrada e a saı́da do veı́culo, mas em vez de o fazer com
recurso a um cartão, usa o dispositivo móvel. Basicamente o passageiro “lê” um QR Code presente na
paragem antes de entrar no veı́culo e assim terá acesso à aplicação para registar a entrada. Seguidamente, assim que entrar no autocarro, o passageiro efetua o check-in, desencadeando o processo
de contacto com o servidor central para fornecimento de informação necessária à emissão do bilhete.
Desta forma, é enviado o nome de utilizador, password e origem do pedido (informação conseguida
através da leitura prévia do QR Code da paragem), sendo retornado um bilhete que é guardado como
imagem no dispositivo, de modo a que possa ser mostrado quando o revisor o solicitar. No final, o
passageiro volta a usar o dispositivo móvel para validar a saı́da do transporte, tendo novamente de ler
outro QR Code para que, na comunicação com o servidor central, este saiba o ponto de destino da
viagem. Este dupla leitura de QR Code serve também para que o sistema calcule de forma precisa o
valor que o utilizador terá de pagar pela sua viagem [3]. Dado que os passageiros estão registados
e os QR Code fornecem a localização dos pontos de origem e destino, o servidor central guarda toda
a informação referente às entradas e saı́das de cada passageiro. O QR Code Ticket está igualmente
preparado para a verificação/validação de bilhetes com recurso a dispositivos móveis, funcionalidade
que só está disponı́vel para administradores do sistema, com username e password próprias. Para isso
basta que os administradores acedam com as suas credenciais e será mostrado um menu exclusivo
para a verificação dos bilhetes eletrónicos.
A Tabela 2.1 sintetiza as principais caracterı́sticas dos sistemas estudados.
6
Nome
Registo de
entradas
Registo de
saı́das
Armazena dados
Localmente
OD Matrix
EZ-Link
QR Code
Ticket
Sim
Sim
Sim
Via Bluetooth
Sim
Sim
Sim
Não
Não
Transfere dados
para servidor
central
Sim
Sim
Sim
Tabela 2.1: Sistemas de contagem de passageiros: sı́ntese final.
2.2
2.2.1
Sistemas de reserva
Sistemas de reserva planeada
Na rede de transportes públicos de uma cidade não existe a necessidade de se reservarem lugares,
primeiro, porque o tempo de espera entre transportes não é muito grande, e segundo, porque existe
uma frequência elevada entre entradas e saı́das, o que garante que raramente estes estejam completamente lotados. No caso de viagens maiores, com frequência de autocarros menor e que têm tendência
a lotar, existe a necessidade de se garantir previamente um bilhete. As escolhas dos sistemas estudados tiveram em conta caraterı́sticas pretendida para o sistema a desenvolver tais como o perı́odo
de antecedência de reserva, alteração de reservas, reembolso e acesso e validação via dispositivos
móveis.
Neste sentido há várias empresas, tanto a nı́vel nacional como internacional, que disponibilizam este
tipo de sistemas. Um delas é a Rede Expressos1 que permite aos seus utilizadores reservarem bilhetes
via internet, ou através de bilheteiras. Uma reserva pode ser efetuada até 30 dias de antecedência,
podendo esta ser revalidada, sem custos, sendo que esta revalidação só é válida caso o bilhete tenha
sido adquirido nas bilheteiras, portanto os tı́tulos de transportes adquiridos via Internet não podem ser
alterados ou revalidados nem são passı́veis de reembolso.
Existe também um serviço de shuttle em aeroportos, que permite reservar uma viagem entre o
aeroporto e um hotel, escritório ou casa. O SuperShuttle2 é um serviço de partilha de viagens entre
aeroportos e o destino pretendido dos utilizadores - este serviço irá sempre buscar os utilizadores ao
local e na hora escolhidos pelo mesmo. A reserva deste serviço pode ser feita via Internet, aplicação
móvel ou por telefone, estando as linhas disponı́veis 24 horas por dia, 7 dias por semana. Também aqui
é possı́vel cancelar a reserva e ser reembolsado, desde que esta ação seja feita até 2 horas antes da
hora escolhida. Decorrido este prazo, o utilizador não será reembolsado.
Já a OEBB 3 , uma empresa de comboios austrı́aca, disponibiliza um sistema de reservas de bilhetes
para lugares pessoais, cabines para grupos, espaço para dormir ou jantar. O sistema possibilita a
reserva via Internet e quem o fizer ainda terá direito a um desconto sobre o preço. Para além da
compra nas bilheteiras locais e das reservas via Internet, disponibiliza ainda um serviço mobile ticketing
onde os utilizadores de dispositivos móveis podem comprar/reservar um bilhete através deste. Quanto
1 http://www.rede-expressos.pt/default.aspx,
último acesso em janeiro de 2014
último acesso em dezembro de 2013
3 http://www.oebb.at/en, último acesso em dezembro de 2013
2 http://www.supershuttle.com/,
7
ao cancelamento e reembolso, para este serviço o cancelamento é possı́vel, mas o reembolso fica a
cargo de uma companhia de seguros. No ato de compra/reserva o passageiro tem ao seu dispor um
seguro para si e para todos os pacotes e serviços que podem ser incluı́dos - bagagem, refeições, entre
outros. Caso tenha de cancelar a viagem, o prémio de seguro que irá receber é calculado com base no
valor da viagem reservada.
A Tabela 2.2 sintetiza as principais caracterı́sticas dos sistemas de reserva planeada, cujos campos
de comparação são os seguintes:
• Reserva Planeada: o sistema permite ao utilizador efetuar uma reserva antecipadamente.
• Reserva Tempo-Real: o sistema permite ao utilizador efetuar uma reserva e nesse preciso momento saber se a mesma lhe foi validada.
• Reserva Internet: o sistema permite ao utilizador efetuar uma reserva via internet.
• Perı́odo de antecedência máximo: quantidade de dias que o sistema permite que se faça uma
reserva, antes da data da viagem.
• Alteração e anulação: o sistema permite ou não que o utilizador cancele ou altere a data de uma
reserva previamente feita.
• Reembolso: no caso da reserva implicar um pagamento e de o utilizador cancelar, o sistema
reembolsa este.
Nome
Rede
Expressos
Super
Shuttle
OEBB
Reserva
Tempo
Real
Sim
Reserva
Internet
Periodo de
antecedência
Sim
30 dias
Sim
Sim
11 meses
Alteração
anulação
máximo
Sim, só na
bilheteira
Sim
Sim
Sim
-
Sim
Reembolso
Sim, até 24h
depois da data
Sim, até 2h
antes da data
Sim, através
de seguro
Tabela 2.2: Sistemas de reserva planeada: sı́ntese final.
2.2.2
Sistemas de reserva em tempo-real
Os sistemas de reserva planeada não permitem dar resposta eficaz a situações que conduzam à reserva ou cancelamento de reserva de última hora, uma vez que a informação sobre a ocupação do
veı́culo é pré-carregada nos veı́culos, antes do inı́cio do percurso. Todavia, os sistemas em tempo real
oferecem vantagens em diversas situações do dia a dia, como sejam reserva de lugares de estacionamento e o escalonamento de veı́culos nas autoestradas, e são possı́veis de implementar em virtude do
desenvolvimento das tecnologias de comunicações sem fios [4].
De entre os diversos sistemas existentes foram selecionados para análise os que têm maior relevância para o problema apresentado neste projeto, nomeadamente: o sistema Parking with Vehicular
8
Ad Hoc Networks (VANET), Car Parking Locator, SPARK , Managed Motorway e Intelligent Lane Reservation (ILR) .
O sistema Parking with VANET é um sistema descentralizado em que o veı́culo que sai do lugar de
estacionamento informa os que estiverem mais próximos da sua ação e a estes é indicado o caminho
mais curto até ao lugar, segundo o algoritmo de Dijkstra [5]. Não são permanentemente guardadas as
localizações dos lugares nem dos veı́culos, apenas são passadas as informações da localização do
lugar até que este seja ocupado. Uma vez que isto aconteça, a informação deixa de ser necessária.
Portanto é eliminada do sistema. Contudo, este sistema não garante que, mesmo sendo reservado um
determinado lugar a um e só um veı́culo, nenhum outro condutor use o espaço vazio para estacionar.
Dentro desta temática, o Car Parking Locator é um sistema desenvolvido e a operar na Universidade de Limerick, Irlanda, com o propósito de melhorar a experiência dos utilizadores quanto à reserva
de lugares de estacionamento, dentro do campus, através de dispositivos móveis (smartphones, telemóveis e computadores portáteis). O serviço permite que os utilizadores registados tenham acesso
à informação sobre os lugares disponı́veis e possam reservar um deles quando se aproximam/entram
no campus e que os visitantes tenham acesso ao mesmo através de um registo prévio temporário. Os
lugares são escolhidos pelo sistema central que recorre à informação do utilizador, bem como à lista
de lugares disponı́veis, para escolher o lugar que melhor encaixa com as suas pretensões. A lista
de lugares mantém-se atualizada graças a uma rede de sensores que periodicamente a renova. O
sistema está igualmente preparado para lidar com lugares privados para determinado pessoal - como
Presidente, Vice-Presidente, etc. - bem como para notificar a segurança da localização de um utilizador
não registado e não contactável que ocupe um lugar indevidamente. Quanto ao conteúdo apresentado aos utilizadores depende das capacidades dos dispositivos destes, ou seja se o dispositivo for
um iPhone a aplicação irá apresentar mapas com elevado detalhe, se for telemóvel com capacidades
limitadas a informação de localização será transmitida por um serviço de mensagens (Short Message
Service (SMS) ou Multimedia Messaging Service (MMS)) [6].
Do mesmo modo, SPARK é outro sistema para localização, navegação e reserva de lugares em
parques de estacionamento em tempo real e que consegue servir de sistema inteligente antirroubo,
bem como manter uma comunicação amigável entre todas as partes envolvidas. Quando um veı́culo
entra no parque, três RoadSide Unit (RSU) medem a distância entre eles e o veı́culo - para chegarem
à sua posição real, segundo um algoritmo próprio - e, tendo em conta as preferências do utilizador,
identificam o lugar vago que melhor satisfaz as pretensões deste último, com estas duas identificações,
posição do veı́culo e do lugar, calculam o percursos mais curto. Neste aspeto, os autores afirmam que
o Global Positioning System (GPS) não é a melhor solução para conseguir a localização por motivos
de precisão e por não conseguir garantir que um lugar vago neste instante também o esteja no instante
imediatamente a seguir. As informações de cada lugar de estacionamento, como posição, reserva,
ocupação entre outros, ficam guardadas em todos os RSU e assim conseguem gerir convenientemente
todo o parque de estacionamento. A proteção antirroubo é feita com recurso à informação periodicamente transmitida entre o veı́culo - necessita de uma unidade de software e hardware especı́fica - e as
RSU. Quando o condutor sai do veı́culo indica esta ação e a mesma é guardada nas RSU e quando
9
pretender deixar o lugar o condutor deve igualmente sinalizar a ação - é usada uma password para este
tipo de comunicação (lock/unlock ) - garantindo assim que a saı́da do lugar é feita pelo dono do veı́culo
e que não se trata de um roubo [7].
Já Managed Motorway consiste num sistema em que cada veı́culo teria uma slot reservada para
si numa via de uma autoestrada, de modo a diminuir acidentes e garantir a chegada ao destino a
tempo e horas. Estas garantias são conseguidas tendo em conta um compromisso entre condutores
e o sistema de gestão de autoestradas, onde o segundo garante a qualidade do serviço, as polı́ticas
de preços e timelines, desde que os primeiros também se comportem de acordo com os compromissos assumidos, tais como manter-se na slot que lhe foi destinada, manter velocidade de segurança,
entre outros. Para condutores faltosos, o sistema rege as sanções, que podem ir desde pagamentos
monetários, redução da qualidade do serviço ou até mesmo o veı́culo ser banido do sistema. Tal como
atualmente, o controlo de acesso à autoestrada também é feito por portagens nas vias de acesso, que
verificam a capacidade, a disponibilidade do serviço e a qualificação do veı́culo, permitindo a distinção
dos veı́culos por prioridades, por exemplo um veı́culo de emergência terá prioridade sobre todos os
outros [8]. A grande limitação do sistema reside no facto deste apenas poder ser utilizado por veı́culos
que tenham o software e hardware necessário.
Nesta questão das prioridades, ILR representa um sistema de reserva de slots numa pista de alta
prioridade baseado no pagamento de uma taxa. Ou seja, numa autoestrada existe uma via especı́fica
para veı́culos que reservem um espaço para determinado perı́odo e troço, e esta reserva pode ser
prévia ou feita no momento imediatamente anterior à utilização da mesma. Da mesma maneira que
permite a reserva, o sistema possibilita o cancelamento e reembolso. No que toca às entradas e saı́das
desta linha, estas têm de ser coordenadas pelo próprio sistema, enviando mensagens de aviso para
os diferentes utilizadores, de modo a evitar acidentes. O controlo de reservas válidas é feito em tempo
real, quer por câmaras digitais, que tiram fotografias às matriculas dos veı́culos e confirmam a licença,
quer por troca de informação, via peer-to-peer entre os veı́culos e, no caso de um falhar esta validação,
a informação será passada para as autoridades responsáveis, assim que exista a possibilidade de
comunicação com a rede [9].
A Tabela 2.3 sintetiza as principais caracterı́sticas dos sistemas de reserva em tempo-real. Os
campos de comparação são os mesmos que os usados para a comparação de sistemas de reserva
planeada.
2.2.3
Sı́ntese e comparação
Perante os sistemas estudados, segue-se uma sı́ntese global das propriedades mais relevantes para a
definição da presente solução: arquitetura e funcionalidades.
A Tabela 2.4 apresenta uma sı́ntese das principais propriedades que definem a arquitetura das
plataformas, nomeadamente:
• Tipo de Organização: centralizado - sistema faz uso de um servidor central que controla todo o
processamento - e distribuı́do - sistema usa os equipamentos circundantes para passar informação
10
Nome
Reserva
Planeada
Reserva
Internet
Não
Reserva
Tempo
Real
Sim
Parking with
VANET
Car Parking
Locator
SPARK
Não
Sim
Não
Não
Sim
Não
Managed
Motorway
ILR
Não
Sim
Não
Sim
Sim
Sim
Não
Periodo de
antecedência
máximo
Não
aplicável
Não
aplicável
Não
aplicável
Não
aplicável
Não
especificado
Alteração e
anulação
Reembolso
Sim
Sim
Não
aplicável
Não
aplicável
Não
aplicável
Sim
Sim
Sim
Sim
Sim
Tabela 2.3: Sistemas de reserva em tempo-real: sı́ntese final.
para todos.
• Tipo de Processamento: processamento do sistema ser feito localmente, remotamente ou de
ambas as formas.
• Tipo de Armazenamento: dados armazenados no sistema local, remotamente ou em ambos.
• Tipo de Acesso: acesso presencial, via internet ou dispositivos móveis.
Nome
OD
Matrix
EZ-Link
QR Code
Ticket
Rede
Expressos
SuperShuttle
OEBB
Parking
with VANET
Car Parking
Locator
SPARK
Managed
Motorway
ILR
Tipo
de
Organização
Centralizado
Tipo
de
Processamento
Local
Tipo
de
Armazenamento
Ambos
Tipo
de
Acesso
Presencial e
Dispositivos Móveis
Internet
(hardware especı́fico)
Dispositivo Móvel
e Internet (só consulta)
Ambos
Centralizado
Ambos
Remoto
Centralizado
Remoto
Ambos
Centralizado
Ambos
Remoto
Centralizado
Centralizado
Distribuı́do
Remoto
Remoto
Local
Remoto
Remoto
Local
Centralizado
Ambos
Ambos
Distribuido
Centralizado
Local
Ambos
Local
Remoto
Ambos
Ambos
Não
aplicável
Dispositivos
Móveis
Presencial
Presencial
Centralizado
Ambos
Remoto
Ambos
Tabela 2.4: Comparação entre as arquiteturas das soluções estudadas.
A Tabela 2.5 retrata as funcionalidades básicas das plataformas, sendo os campos de comparação
os seguintes:
• Tipo de Reserva: as reservas são planeada, em tempo real ou ambos.
11
• Processamento local: o sistema regista entradas, saı́das, outros registos - duração, estatı́sticas,
validações - ou todos os anteriores.
• Anulamento de reservas: anular uma reserva pode ser feita em tempo real, de forma planeada ou
de ambos os modos.
• Reembolso: condições em que o sistema permite reembolso - só em caso onde seja obrigatório
o pagamento prévio.
Nome
OD
Matrix
EZ-Link
QR Code
Ticket
Rede
Expressos
SuperShuttle
Tipo
de
Reserva
Não
aplicável
Não
aplicável
Tempo
Real
Ambos
Ambos
OEBB
Ambos
Parking
with VANET
Car Parking
Locator
SPARK
Tempo
Real
Tempo
Real
Tempo
Real
Tempo
Real
Ambos
Managed
Motorway
ILR
Processamento
Local
Entradas
e Saı́das
Todos
Entradas
e Saı́das
Entradas
(manualmente)
Entradas
e Saı́das
Entradas
Outros
Registos
Todos
Anulamento
de
Reservas
Não
aplicável
Não
aplicável
Não
aplicável
Ambos
(apenas para bilheteiras)
Planeado
Ambos
Tempo
Real
Não
especificado
Não
especificado
Tempo
Real
Ambos
Entradas
e Saı́das
Todos
Todos
Reembolso
Não
aplicável
Não
aplicável
Não
aplicável
Sim, até 24h
depois da data
Sim, até 2h
antes da data
Sim, através
de seguradora
Não
aplicável
Não
aplicável
Não
aplicável
Não
aplicável
Não
especificado
Tabela 2.5: Comparação entre as funcionalidades básicas das soluções estudadas.
A Tabela 2.6 retrata as funcionalidades adicionais que as plataformas podem ter. Os campos de
comparação são os seguintes:
• Conta de utilizador: o sistema disponibiliza um sı́tio onde o utilizador possa ter acesso aos dados
da sua conta.
• Pagamento: o sistema permite um pagamento automático - por transferência direta - ou presencial.
• Alertas: maneira como os alertas chegam aos utilizadores e responsáveis.
• Serviço de Localização: o sistema tem capacidade de localizar um ponto móvel, ponto fixo ou
ambos.
12
• Distância: capacidade do sistema calcular as distâncias entre dois pontos, informar caminho mais
curto ou ambos.
Nome
OD
Matrix
EZ-Link
Conta
de
Utilizador
Não
Tipo
de
Pagamento
Automático
Alertas
Não
Serviço
de
Localização
Não
Sim
Automático
Não
Não
QR Code
Ticket
Rede
Expressos
SuperShuttle
Sim
Automático
Por email
Não
Não
Ambos
Não
Sim
OEBB
Sim
Não
Não
Parking
with VANET
Car Parking
Locator
Não
Automático
(na reserva)
Automático
(na reserva)
Não
aplicável
Automático
Não
aplicável
Não
Ponto
Móvel
Ambos
SPARK
Não
Managed
Motorway
ILR
Não
Não
especificado
Automático
Sim
Automático
Aviso no
hardware
Mensagem para
utilizador ou
segurança
Mensagem para
utilizador
Aviso no
software
Mensagem para
segurenaça
Sim
Não
Distância
Não
aplicável
Não
aplicável
Não
aplicável
Não
aplicável
Não
aplicável
Não
aplicável
Ambos
Ambos
Ambos
Ambos
Ambos
Não
aplicável
Não
aplicável
Ambos
Tabela 2.6: Comparação entre as funcionalidades adicionais das soluções estudadas.
2.3
Sistemas de validação de passageiros
Com a proliferação do uso de internet, os sistema de check-in online, principalmente no que aos aeroportos diz respeito, teve um aumento notável nos últimos anos. Contudo, este não é um sistema de
reserva tı́pico, é uma mais solução que facilita a entrada dos passageiros nos respetivos voos. Em
ambas as situações estudados, os passageiros já têm em sua posse o bilhete para o voo pretendido e
fazem uso do check-in online para evitar percas de tempo e filas de espera.
Muitas vezes os passageiros são confrontados com longas filas para trocarem comprovativo de reserva e efetuarem o pagamento do voo pelo bilhete, ou para fazerem check-in, ou até mesmo para
depositarem a bagagem de porão. Esta questão parece de simples resolução, dado que basta o passageiro chegar mais cedo ao aeroporto e tratar de todos os processos com tranquilidade, no entanto
o número de passageiros tem vindo a aumentar - segundo a ANA Aeroportos de Portugal, em 2013, o
número de passageiros foi superior a 32 milhões4 - e como tal são necessários novos mecanismo que
agilizem o processo e permitam a redução de custos aos transportadores aéreos.
4 http://www.ana.pt/pt-PT/Topo/Institucional/SobreANA/Imprensa/Noticias/Paginas/Número-de-passageiros-nos-aeroportosportugueses-ultrapassa-os-32-milhões.aspx?fromlist=1, último acesso em agosto de 2014
13
Podem-se considerar três grandes tipo de check-in: via online - feito a partir de um dispositivo com
ligação à internet -, via quiosque - os balcões automáticos existentes nos aeroportos (em tudo idênticos
ao check-in online) - e presencialmente nos balcões de atendimento apropriados. Se os dois primeiro
métodos não acrescentam custos, em termos de recursos humanos, para o transportador, no que aos
balcões diz respeito, o caso muda de figura. Dá a conjuntura atual, é sabido que todas as empresas
tento reduzir ao máximo os custos e o corte nos empregados é muitas vezes a via mais fácil de o
conseguir, portanto existe desde à muito tempo uma aposta clara em tornar o processo de checkin automático, no entanto esta aposta pode ser arriscada dado que tem de existir um investimento
substancial em termos monetários e de tempo para desenvolver estes sistemas. Contudo, através
destes, o utilizador fica desde logo livre das filas e das percas de tempo e a transportadora reduz os
custos operacionais [10].
Se atendermos a estudos realizados, o método de check-in online está diretamente relacionado
com passageiros mais jovens e com conhecimentos nas áreas das novas tecnologias, uma vez que
este procedimento é frequentemente feito com recurso a dispositivos móveis [10] [11].
2.4
Tecnologias relacionadas
Nesta secção serão apresentadas as tecnologias relevantes para o desenvolvimento do sistema. Na
primeira parte será descrito o sistema informático do IST, que poderá ser usado no contexto da presente
tese. Na segunda secção serão apresentadas as plataformas de desenvolvimento para dispositivos
móveis.
2.4.1
Sistemas informáticos do IST - Fénix
O IST suporta a sua atividade em diversos sistemas informáticos. De entre estes sistemas, o Fénix é
a plataforma que foi desenvolvida para a gestão académica, efetuando a interface entre os alunos e a
escola, ”disponibilizando uma solução integrada que se espalha por todo o processo de gestão, desde
as tarefas de gestão de alto nı́vel até à comunicação diária entre alunos, faculdade e pessoal”5 .
Este ano, a equipa de desenvolvimento do Fénix decidiu disponibilizar uma Application Programming
Interface (API) para que os interessados possam desenvolver aplicações sobre o sistema. A informação
disponibilizada a cada utilizador será igual à informação presente na plataforma, que corresponde ao
utilizador em causa. Ou seja, no caso de um aluno ”X ”, este apenas poderá ter acesso à parte da
informação que diz respeito ao aluno ”X ”, sendo ela pública ou privada. Do mesmo modo, no caso de
um administradores de sistema, este também só poderá ver e alterar a sua própria informação, não
existindo informação relativa aos outros utilizadores. Todas estas informações dependem dos perfis
definidos para cada utilizador - que no caso da API são apenas três (aluno, professor e alumni) mas no
sistema Fénix são centenas.
A API utiliza o protocolo de autenticação OAuth 2.0, que fornece uma autorização especı́fica para
5 http://fenixedu.org/,
último acesso em dezembro de 2013
14
aplicações web ou desktop, dispositivos móveis ou computadores, de modo a resolver os problemas
associados às aplicações third party. Este protocolo introduz uma camada de autorização e separa
o papel do cliente do papel do proprietário dos recursos. Assim, em vez de utilizar as credenciais do
proprietário, o cliente obtém um access token - uma string que contém o âmbito, duração e outros
atributos de acesso - que é usado para aceder a recursos protegidos [12]. Deste modo a API permite
que possa ser usada para validar as contas de alunos, docentes e funcionários não docentes do IST,
o que torna possı́vel a autenticação dos utilizadores de um sistema externo, recorrendo às credenciais
que estes têm no sistema Fénix, não sendo necessário criar novas contas de utilizador.
Tendo em conta o problema inicial, era importante que o Fénix e a respetiva API tivessem alguns
dados acerca do shuttle, o que neste momento não acontece. Está programado que o sistema possa
vir a ter informação sobre serviços como o shuttle ou cantina - o desenvolvimento já foi iniciado mas
ainda não está implementado pelo facto da equipa de desenvolvimento do Fénix querer uma solução
generalista e que possa ser usada para diferentes serviços - mas não se conhece a data prevista para
este add-on ao sistema. Contudo, a informação a disponibilizar em relação ao shuttle seria relativa aos
horários, perı́odos de funcionamento e estações de paragem dos autocarros.
Apesar de ser um sistema bastante eficiente - executa entre um milhão a quatro milhões e meio
de transações diariamente - e de estar em constante melhoramento, de modo a reduzir ao máximo
o número de erros e bugs existentes, a melhor solução para o problema inicial pode não passar por
acrescentar/implementar o sistema desenvolvido ao Fénix, dado que há uma grande restrição nas funcionalidade que devem ser suportadas pelo Fénix e nos dados que usam e fornecem[13].
2.4.2
Dispositivos móveis
Os dispositivos móveis estão amplamente espalhados pelo mundo e o número de utilizadores destes
aumenta consideravelmente todos os anos. Estima-se que em 2014 o número de telefones móveis
ultrapasse a população mundial [14]. Para sustentar este crescimento, estudos publicados mostram
que o crescimento de downloads das aplicação para dispositivos móveis da Apple cresceram cerca 500
mil downloads, de 1.5 milhões para 2 milhões, em pouco mais de dois meses67 . Como tal, existe uma
necessidade cada vez maior de preparar as aplicações para serem usadas nestes dispositivos, quer
por programação direta para cada plataforma em concreto, quer por adaptação do layout das páginas
web, tornando-as mais usáveis em ecrãs de dimensões reduzidas.
Plataformas mais utilizadas
No último trimestre de 2012, os sistemas operativos para dispositivos móveis Android, iOS e BlackBerry estavam em primeiro, segundo e terceiro lugar, respetivamente, em relação à fatia de mercado,
representando 94.3% das vendas a nı́vel mundial [15].
O sistema operativo Android foi desenvolvido pela Google e conta com a contribuição de mais de 300
parceiros de software e hardware, bem como da comunidade open-source de Linux. Isto, aliado ao facto
6 http://www.apple.com/pr/library/2009/07/14apps.html,
7 www.apple.com/pr/library/2009/09/28appstore.html,
último acesso em dezembro de 2013
último acesso em dezembro de 2013
15
de disponibilizar uma poderosa framework e ferramentas para desenvolvimento, uma documentação
ı́mpar e um mercado livre e aberto para venda de aplicações, fez com que este sistema operativo
crescesse rapidamente ao ponto de, em cada dia, mais de um milhão de novos dispositivos Android
sejam ativados em todo o mundo8 . Para começar a desenvolver sobre esta plataforma o utilizador
apenas tem de fazer o download - disponı́vel no site do Android 9 - e instalar o Android Developer
Tools (ADT) Bundle, podendo ser utilizado tanto em sistemas operativos Windows, MacOS ou Linux.
Cada vez mais se aposta no design e na interação pessoa-máquina, por isso a framework facilita a
criação dos interfaces, podendo ser usado o sistema drag ’n drop, e em poucos passos e sem linhas
de código escritas o programador consegue ter a perceção de como a aplicação irá ser apresentada ao
utilizador. A partir daqui o utilizador pode começar a ”brincar”tendo a ajuda de toda a documentação,
de tutoriais e das inúmeras páginas web, fóruns e blogs de outros programadores para resolver os
problemas. A base de programação é a linguagem Java.
Quanto ao iOS, desenvolvido pela Apple, é um sistema operativo mais fechado e com mais restrições.
Para este caso a Apple também oferece plataformas para a programação de dispositivos móveis, no
entanto a framework de desenvolvimento só funciona no sistema operativo Mac OS. Existem três tipos
de programas sendo que apenas o University, projetado para estudantes e professores universitários,
que pretendam iniciar-se na programação de aplicação para iOS, tem licença gratuita. A Tabela 2.7
mostra as diferenças das caracterı́sticas entre cada programa. A base de programação é a linguagem
objective-c
10
.
Developer
iOS Software
Development Kit (SDK)
iOS SDK
(Pre-release)
Test apps on
iOS devices
Code-level
Technical Support
Ad Hoc
Distribution
App Store
Distribution
Custom B2B
App Distribution
iAd
Network
In-house
Distribution
Cost
Sim
Developer
Enterprise
Sim
Developer
University
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
Sim
Não
Sim
Sim
Não
Sim
Não
Não
Sim
Não
Não
Sim
Não
Não
Não
Sim
Não
99$/ano
299$/ano
Grátis
Tabela 2.7: Comparação entre programas.
8 http://developer.android.com/about/index.html,
último acesso em dezembro de 2013
último acesso janeiro em 2013
10 https://developer.apple.com/programs/ios/, último acesso em dezembro de 2013
9 http://developer.android.com/sdk/installing/bundle.html,
16
Em relação ao BlackBerry, criado pela empresa homónima, é o terceiro sistema operativo para
dispositivos móveis mais vendido em todo o mundo. Disponibiliza uma plataforma aberta, que permite
a criação ou importação de aplicações para o sistema operativo em causa, recorrendo a uma série de
ferramentas gratuitas e a um simulador para testes. Estas ferramentas podem ser utilizadas tanto em
Windows como Mac OS e são gratuitas. Em determinadas situações - principalmente na importação
- a BlackBerry faz distinção entre smartphones e tablets, sendo necessário programar duas vezes o
mesmo para se conseguir o melhor partido dos dois. Existe bastante documentação para a iniciação,
mas em contrapartida não existem tantos fóruns e/ou blogs que possam facultar outro tipo de ajuda,
dado que o número de utilizadores e programadores para este tipo de sistema não é tão elevado quanto
para os anteriores. Existe uma biblioteca com código fonte de algumas aplicações simples, tais como
aceder à lista de contactos, leitor de QR Code, ler e escrever ficheiro em JSON, ter acesso aos vários
sensores, serviço de localização e outras, que podem ser integradas de forma a criar uma aplicação
bastante completa. Ao nı́vel de programação, este sistema tem um espectro bem mais alargado sendo
possı́vel programar em linguagens C/C++, Java, JavaScript, HyperText Markup Language (HTML) entre
outros 11 .
O desenvolvimento de aplicações para dispositivos móveis pode ser realizada usando as plataformas especı́ficas, desenvolvidas pelos fabricantes, ou usando formas genéricas de desenvolvimento de
aplicações web.
A programação especı́fica para cada plataforma é a solução ótima, no sentido que cada dispositivo
iria ter uma versão única, sendo que cada funcionalidade e interface seria detalhada para o dispositivo em questão. No entanto, é necessário ter em atenção que isto iria implicar uma dedicação extra
a todas as plataformas e, mesmo assim, considerando apenas os sistemas operativos acima indicados, não se conseguiria cobrir a totalidade do mercado. Ou seja, apesar de ser exequı́vel, o tempo e
esforço necessários para a sua concretização não compensaria os benefı́cios que eventualmente se
alcançariam.
A acrescentar a isto, e para comprovar a dificuldade de se abranger todo o mercado dos dispositivos
móveis, dados mais recentes, referentes ao primeiro semestre de 2013, mostram que a Windows Mobile
já ultrapassou a BlackBerry no volume de vendas, passando agora este último a estar fora do top 3 dos
sistemas mais vendidos [16].
A Tabela 2.8 mostra alguns dos custos e benefı́cios que se correm ao adotar uma programação
especı́fica para cada sistema operativo. De referir que o par custo/benefı́cio em cada linha não está
relacionado.
Responsive Web Design
Outra possibilidade é a criação de uma versão web. Todos os dispositivos móveis, de última geração,
têm acesso à internet e como tal muitos dos sites mais populares têm versões para os diferentes
dispositivos. Com isto consegue-se resolver o problema para todos os tipos de dispositivos, uma vez
que a solução passa por ”reprogramar”o layout da página, de modo a torná-la usável num smartphone
11 http://developer.blackberry.com/,
último acesso em dezembro de 2013
17
Custos
Demora tempo
Dificil cobrir todo o mercado
Atualizações frequentes
Compatibilidades entre modelos e dispositivos
Diferentes linguagens
Custos elevados
Necessário instalar aplicação
Benefı́cios
APIs testadas
Performances superiores
Usa todas as capacidades
SDK especı́ficos
Funcionam offline
Experiencia do utilizador (user experience)
Segurança
Tabela 2.8: Custos e benefı́cios de programar para cada sistema operativo.
ou tablet, deixando assim de ser necessário ter em consideração o hardware de cada dispositivo.
A Figura 2.1 ilustra um exemplo de página web que usa esta solução. As principais alterações
dão-se na folha de Cascading Style Sheets (CSS) para tornar a página adaptável, com recurso a tags
especı́ficas para definir as larguras dos ecrãs12 .
Figura 2.1: Exemplo de uma página com RWD.
O RWD é um tipo de programação de versões web que oferece uma maneira de estruturar as
páginas de modo que a mesma página vá sofrendo alterações consoante o tamanho da tela, sem que
seja necessário usar a barra de navegação inferior para a visualização dos conteúdos. Ou seja, à
medida que a tela for diminuindo na sua largura, a estrutura da página vai sendo alterada e consequentemente os tópicos da mesma vão mudando de posição, não sendo necessário fazer zoom in ou zoom
out para conseguir ler as publicações e navegar corretamente na página [17].
12 https://developer.mozilla.org/en-US/docs/Web/Guide/Mobile,
último acesso em dezembro de 2013
18
Capı́tulo 3
Arquitetura
Nesta secção é feita a descrição do levantamento e dos requisitos do sistema, uma descrição geral do
sistema e uma descrição detalhada dos componentes tendo em conta, as preferências dos utilizadores
do serviço. De um modo muito geral, a solução passa por pedidos efetuados a um sistema central,
o qual devolve a resposta consoante o tipo de utilizador ou a função pedida. A Figura 3.1 mostra a
interação básica entre as diferentes partes envolvidas no processo.
Figura 3.1: Interação entre as diferentes partes do sistema.
3.1
Levantamento de requisitos funcionais
Os requisitos funcionais da aplicação foram identificados com base em inquéritos e entrevistas realizadas aos possı́veis utilizadores da mesma.
3.1.1
Elaboração do inquérito e entrevistas
Por forma a perceber os problemas existentes, as necessidades e as preferências dos utilizadores,
foram realizadas algumas entrevistas presenciais e um inquérito junto da comunidade do IST. Ambos
tiveram por objetivo avaliar o serviço atual e identificar o interesse para a comunidade dum serviço de
reserva de bilhetes, e os moldes de funcionamento do mesmo.
19
Inquérito
Objetivo O inquérito realizado tinha como objetivo avaliar o serviço atual e perspetivar o interesse e
modelo de funcionamento dum eventual serviço de reserva de bilhetes.
Formato O inquérito, de resposta fechada, era constituı́do por três blocos de perguntas. O primeiro
bloco tratava de caraterizar o inquirido; o segundo pretendia caraterizar a atual utilização do shuttle e
aferir a abertura dos inquiridos para a utilização de um sistema de reservas, e o terceiro, mais ligado ao
futuro sistema, caraterizava o sistema de reservas a desenvolver.
As perguntas que componham o primeiro bloco eram:
• 1. Indique a sua função no IST
• 2. Tem dispositivos móveis (smartphones e/ou tablets)?
• 3. Costuma aceder à internet via dispositivos móveis? (se respondeu não em 2, deve ignorar esta
questão)
O objetivo destas perguntas era avaliar se a população que estamos a atingir é de facto a pretendida
e aferir a quantidade de dispositivos móveis (smartphones e/ou tablets), bem como se os inquiridos
costumam aceder à internet através destes mesmos dispositivos móveis. Isto iria definir ou não a
necessidade de criar uma aplicação usável em dispositivos móveis.
O segundo bloco de perguntas, que diz respeito ao atual sistema, era composto pelas seguintes
perguntas:
• 4. Costuma utilizar o serviço do shuttle?
• 5. Já ficou sem lugar no shuttle? (se respondeu não em 4, deve ignorar esta questão)
• 6. Acha importante um sistema de reservas para este serviço?
O foco deste bloco de perguntas era comprovar que o problema existe e se os utilizadores achavam
que um sistema de reservas era uma boa solução a adotar, para minimizar o problema identificado.
No terceiro bloco de perguntas, eram abordadas questões mais técnicas relativas às reservas. As
perguntas que eram colocadas são as seguintes:
• 7. Acha mais interessante a possibilidade de reservar apenas uma percentagem da ocupação
total ou a totalidade dos lugares disponı́veis? (se respondeu não na questão 6, deve ignorar esta
questão)
• 8. Estaria disposto a fazer reserva de bilhetes para viagens no shuttle?
• 9. A reserva deveria ser planeada ou em tempo real? (se respondeu não na questão 8, deve
ignorar esta questão)
20
• 10. Quantifique os diferentes tipos de reserva - diária (ida OU volta), diária (ida E volta), semanal
(ida e volta), mensal (ida e volta) - quanto à sua importância. (se respondeu ”Tempo Real”na
questão 9, deve ignorar esta questão)
• 11. Considerando que o sistema permite cancelar uma reserva e que a capacidade de ocupação
é limitada, que açao sugere que se tome no caso de um utilizador não comparecer?
Todas estas questões tem por base sistemas de reservas de bilhetes já existentes, e têm por objetivo
tentar entender quais as melhores opções do ponto de vista do utilizador.
Divulgação do inquérito e caraterização da amostra
O inquérito foi divulgado via email, blogs e
grupos de alunos do IST no facebook, por forma a atingir um grande número de alunos e funcionários
docente e não docentes do IST. Obtiveram-se 129 respostas, o que possibilita tirar conclusões sobre
alguns requisitos que a solução deve apresentar.
Análise de resultados Em relação aos resultados, das 129 respostas obtidas, a Figura 3.2 mostra
a variação de respostas tendo em conta a função desempenhada por cada um dos inquiridos e a
Figura 3.3, mostra que existem 110 inquiridos que possuem pelo menos um smartphone ou tablet, dos
quais 107 acede regularmente à Internet com recurso aos mesmos.
Figura 3.2: Análise das respostas tendo em conta a função desempenhada.
Figura 3.3: Análise das respostas tendo em conta o uso de dispositivos móveis e o acesso à internet
dos mesmo.
De acordo com a Figura 3.4, da amostra de 129 respostas ao inquérito, foi possı́vel identificar que
88 dos inquiridos costumam utilizar regularmente o shuttle, e dos quais 57 já ficou sem lugar no mesmo
pelo menos uma vez.
21
Figura 3.4: Análise das respostas tendo em conta a utilização do shuttle.
De igual modo, 81 pessoas acham importante a existência de um sistema de reservas, sendo que
destas 81, 65 considera que apenas deve estar disponı́vel para reserva uma percentagem da lotação
total do veı́culo - possibilitando assim que utilizadores sem reserva possam tentar arranjar lugar no
horário pretendido. A Figura 3.5 ilustra o que a cima foi descrito.
Figura 3.5: Análise das respostas tendo em conta a importância de um sistema de reservas e a preferência de lotação.
Em relação à disposição dos inquiridos quanto a reservarem bilhetes, como é visı́vel na Figura 3.6,
91 inquiridos estão dispostos a reservar, sendo 43 opta pelas reservas planeadas e 48 pelas reservas
em tempo real.
Figura 3.6: Análise das respostas tendo em conta a disposição dos utilização do shuttle para reservarem bilhetes e o tipo de reserva que pretendem.
De todo este inquérito, o que suscitou mais diferenças e discórdia entre as respostas foi a questão
dos tipos de reserva a adotar. A amostra considerada - 88 dos inquiridos, os que costumam utilizar
22
regularmente o shuttle - as preferências recaem essencialmente entre as reservas diárias e semanais,
no entanto ainda existe um número considerável de respostas que consideram como importante as
reservas quinzenais e mensais. A Figura 3.7 mostra o número de respostas obtido para cada opção,
segundo o seu grau de importância.
Figura 3.7: Importância das diferentes modalidades de reservas.
Por fim, no que toca a penalizações - quando o utilizador faltar a uma reserva marcada, sem a
cancelar previamente - os grandes números de respostas vão para o “condicionar reservas futuras” e
”cancelar reservas, mas possibilitar o uso do shuttle”, com 68 e 32 respostas dos inquiridos, respetivamente, tal como mostra a Figura 3.8. Uma última nota para as 24 respostas de inquiridos que acham
que não deveria haver qualquer penalização.
Figura 3.8: Análise das respostas tendo em conta a preferência das penalizações a adotar.
Entrevista
Objetivo A entrevista foi realizada com o objetivo de obter mais feedback sobre a forma como o
sistema deveria ser desenvolvido, tendo em consideração a forma como era efetuado a gestão do atual
serviço e as expectativas de quem lida com este em relação ao referido sistema.
23
Formato A entrevista, de formato aberto, era constituı́da por um conjunto de perguntas básicas, a
partir das quais poderiam surgir outras questões e/ou esclarecimentos.
Depois de enquadrados com a atual situação e com o âmbito da tese, a entrevista começou com as
habituais perguntas, um pouco à semelhança dos inquéritos, que serviram de base para o inı́cio das
entrevistas:
• 1. Qual o melhor sistema a adotar - reserva em tempo real ou planeada?
• 2. As reservas deveriam ser para a totalidade ou para uma percentagem da lotação?
• 3. Que penalização deveriam ter os utilizadores que não comparecessem?
• 4. Deverá existir um sistema de prioridades?
• 5. Quais os critérios a adotar na atribuição de prioridades?
Contudo, uma vez que as entrevistas eram de cariz muito mais aberto, ao longo das mesmas foram
surgindo outras perguntas referentes ao pagamento de uma caução para as reservas, de um sistema
de créditos fictı́cios ou não, entre alunos e professores quem deveria ter prioridade nas reservas, se a
lotação dos autocarros é sempre a mesma em todas as carreiras, entre outras.
Seleção dos inquiridos e caraterização da amostra
As entrevistas foram feitas a uma população
muito mais reduzida e especifica - nomeadamente a funcionários que direta ou indiretamente lidam com
questões do shuttle e que possivelmente virão a tratar da parte de administração do sistema. Assim,
estas apenas foram realizadas com 5 funcionários, todos do Taguspark.
Análise de resultados
Das respostas obtidas salienta-se o facto da maior parte dos inquiridos estar
dividido entre um sistema em tempo real e planeado. Desta forma, confirma-se a conclusão que se retirou nos inquéritos, nos quais as respostas a esta questão foram muito divididas, uma vez que existem
situações em que um tipo de sistema é melhor que o outra. Desta forma, as respostas obtidas foram
unânimes quando se colocou a hipótese dum sistema hı́brido, que possibilitasse a existência de reservas em tempo real e planeadas. Tal como nos inquéritos, também nas entrevistas houve um consenso
quanto à possibilidade de efetuar reservas duma percentagem da lotação do veı́culo.
Por fim, quando questionados acerca das penalizações, as respostas foram sempre parar ao mesmo
ponto “uma vez que existe a possibilidade de alterar ou cancelar uma reserva, os utilizadores deverão
ser penalizados” dentro do que é aceitável, mas não impossibilitar o uso do serviço, uma vez que o
mesmo “foi criado para que os alunos e funcionários o utilizassem sempre que necessitassem”, ou seja
”tentar sensibilizar os faltosos de que estão a tirar o lugar a alguém”. Neste ponto foi também excluı́da
a possibilidade de existência de uma caução, dado que o serviço deve continuar a ser gratuito para
todos os utilizadores. No que diz respeito às prioridades, as respostas não foram tão consensuais uma
vez que há quem considere que os alunos devem ter prioridade sobre os funcionários - “por não terem
rendimentos próprios” - e quem considere que os funcionários devem ter a prioridade - ”se um professor
não apanhar o shuttle e faltar à aula são 50-70 alunos que ficam sem aula”. Em contrapartida, quando
24
inquiridos sobre se determinados casos, como incapacidade motora (permanente ou temporária), gravidez, entre outros, devem ter ou não prioridade sobre todos os outros, a resposta afirmativa foi clara e
inequı́voca.
3.1.2
Súmula dos resultados dos inquéritos e entrevistas
Dos resultados dos inquéritos e das entrevistas, filtrando um pouco os dados finais, chega-se à conclusão que:
• Na maioria, quem tem dispositivos móveis acede à Internet através dos mesmos
• Mais de 60% dos utilizadores do shuttle já ficaram sem lugar pelo menos uma vez
• Cerca de 80% dos inquiridos opta por limitar os lugares reserváveis a uma percentagem da
lotação do veı́culo
• Cerca de 70% dos inquiridos está disposto a efetuar reservas de bilhetes para o shuttle
• Há uma divisão bastante balanceada entre o tipo de reservas - planeada ou tempo real - a adotar
no sistema
• Não existe um consenso claro sobre a importância das diferentes modalidades de reserva
• Tem de existir penalizações para os faltosos, sendo que esta deve ser o condicionamento das
reservas
• As prioridades dos utilizadores devem ser analisadas caso a caso e apenas deve ser dada em determinadas situações, nomeadamente as que decorrem de situações de incapacidade temporária
ou outras situações afins.
3.2
Requisitos do sistema
O sistema é definido mediante determinados requisitos funcionais e não funcionais. Os primeiros
referem-se às funções que o sistema deve executar no seu normal funcionamento tendo em conta
os inputs e outputs esperados. Os segundos são requisitos relacionados com o uso da aplicação.
3.2.1
Requisitos funcionais
Os requisitos funcionais definem funções do sistema e dos componentes, por forma a definir o que o
sistema deve atingir.
25
Sistema de gestão de reservas
Perante os resultados obtidos nos inquéritos e entrevistas, descritos na secção anterior, esta solução
tem de permitir que os utilizadores do shuttle, ou seja a comunidade do IST, possam reservar, alterar ou
anular viagens neste serviço. As funcionalidades descritas devem poder ser efetuadas tanto em tempo
real como de forma planeada, abrangendo assim as duas opções que geram maior divisão entre as
respostas dos inquiridos.
Em segundo lugar, é necessário saber, a cada momento, a quantidade de lugares vagos para cada
horário. Deve também possibilitar as reservas em autocarros extra - adicionados ao horário normal para
situações excepcionais como testes ou exames.
O sistema deverá validar os utilizadores, por forma a garantir que os mesmo pertencem à comunidade do IST, bem como validar as reservas e registar as entradas no momento em que o utilizador
entre no autocarro, garantindo que, numa situação ideal, só entra no autocarro quem tiver feito a reserva
previamente. Esta funcionalidade permite também incutir no utilizador a sensação de responsabilidade
perante as reservas que efetua.
Por forma a satisfazer as pretensões dos inquiridos, apenas estará disponı́vel para reservas uma
percentagem da lotação total do veı́culo. Esta percentagem é variável de veı́culo para veı́culo.
Os utilizadores que não cumprirem uma reserva, ou seja reservaram uma viagem e não entraram
no autocarro, devem ser penalizados, enquanto que os cumpridores devem ter alguns benefı́cios sobre
reservas futuras. Os utilizadores com incapacidade fı́sica permanente ou por uma quantidade de tempo
limitada, devem ter prioridade sobre os restantes.
Por fim, o sistema deve continuar a ser gratuito para todos os utilizadores.
Sistema de gestão de carreiras
Como já existe uma horário para as carreiras do shuttle pré definido, tem de existir a possibilidade de
acrescentar ou eliminar carreiras, percursos e horários.
Uma vez que os veı́culos não serão os mesmos em todas as carreiras e que a percentagem de lugares disponı́veis para reserva varia consoante o veı́culo, o administrador do sistema deve poder inserir
ou eliminar veı́culos. A eliminação de veı́culo só é permitida caso os mesmo não estejam alocados a
nenhuma carreira.
Sistema de gestão de estatı́sticas
Dado que o sistema consegue indicar os utilizadores que efetuaram reservas e quais estiveram presentes ou não em determinada carreira, o sistema deve ter a capacidade de gerar estatı́sticas de utilização
automaticamente, por forma a possibilitar uma análise mais precisa da utilização do serviço de shuttle,
e assim ajustar este mesmo serviço às necessidades dos utilizadores.
26
Interface aplicação - utilizador
A aplicação deverá funcionar em diferentes tipos de dispositivos. Deverá ser simples, fácil e intuitiva,
em termos de funcionamento e usável para os diferentes dispositivos móveis existentes.
3.2.2
Requisitos não funcionais
No que respeita aos requisitos de desempenho é necessário considerar algumas questões, nomeadamente associadas às questões de segurança, autenticação, integridade, portabilidade, integração,
tempo de resposta e privacidade.
Autenticação
Uma vez que o sistema só pode ser acedido por pessoas ligadas ao IST, quer estes sejam alunos ou
funcionários docentes ou não docentes, é obrigatório que no sistema exista uma maneira do utilizador
se identificar, fornecendo credenciais válidas para aceder à aplicação.
A autenticação deve ser feita apenas uma vez pelo utilizador, devendo haver uma gestão de sessão.
Segurança
As credenciais de utilizador devem estar protegidas e codificadas, de modo a que possı́veis ataques ao
sistema não possam roubar essas credencias.
Deve-se igualmente evitar a todo o custo guardar dados crı́ticos em claro. Todas as informações
guardadas na base de dados da aplicação desenvolvida, desde informação de utilizadores, carreiras,
reservas e dados de utilização, podem não estar cifradas desde que estas não sejam informações de
senhas ou que permitam a terceiros roubar a identidade dos utilizadores.
O sistema deve manter os dados afetos a cada utilizador privados, evitando assim que terceiros
possam ver informações privadas, como por exemplo o email, e hábitos de viagem.
Integridade
Os dados guardados são preservados, sendo que a alteração dos mesmos apenas pode ser feita por
utilizadores autorizados para tal.
Não podem existir inconsistências nem duplicação de dados. Qualquer alteração ou criação de
dados implica uma validação da entrada e dos dados existentes, por forma a manter todos os dados
coerentes e únicos.
Portabilidade
O sistema deve funcionar em qualquer browser e em diferentes dispositivos móveis.
O sistema deve ajustar a janela para diferentes tamanhos de ecrã, por forma a tornar o sistema mais
usável.
27
Integração
O sistema deve estar integrado com a API do Fénix, devendo alimentar a tabela de utilizadores com
dados extraı́dos desta API.
Tempo de resposta
Os requisitos de desempenho são medidos tendo em conta o tempo decorrido a partir do momento que
um utilizador faz um pedido até receber a resposta da aplicação. Neste caso, existe a possibilidade
de ser instantâneo, em que o utilizador recebe logo a resposta/confirmação da aplicação, ou variável,
em que o utilizador terá de esperar um determinado número de dias até que a aplicação lhe envie a
resposta final.
Assim, os critérios para o tempo de resposta são:
• A autenticação deve ser instantânea
• Qualquer consulta deve ser instantânea
• Criar nova reserva deve ser instantânea, se estiver dentro do limite de lugares confirmados automaticamente ou ultrapassado o limite máximo de inscrições
• Criar nova reserva deve ser variável, se a reserva ficar em espera, sendo que a resposta só será
dada no dia anterior à data da reserva
• Cancelar uma reserva deve ser instantânea
• Criar um novo percurso deve ser instantânea
• Criar uma nova carreira, regular ou excecional, deve ser instantânea
• Criar um motorista, veı́culo, tipo de data ou perı́odo deve ser instantânea
• Eliminar percurso, carreira, motorista, veı́culo, perı́odo deve ser instantânea
• Imprimir ficha de viagem deve ser instantânea
• Atualizar dados de viagem deve ser variável, tendo em conta que estará sempre dependente da
altura em que se recebem os dados relativos às presenças nas diferentes carreiras
3.3
Descrição geral do sistema
O sistema, na sua globalidade, é composto por três atores, sendo eles o utilizador do serviço, que é
o principal interessado no sistema, o administrador de sistema, que tem ao seu dispor um conjunto de
ferramentas de análise e de gestão de carreiras, o motorista do autocarro, que está encarregue de fazer
o controlo dos passageiros, e um componente, o sistema central que faz toda a solução funcionar.
Começando pelos utilizadores, estes têm acesso, após efetuarem a autenticação no sistema, à
gestão de reservas. Aqui podem fazer, alterar ou cancelar reservas e consultar o estado das mesmas,
28
os dados sobre as carreiras, bem como os resultados de atribuição de reservas e das penalizações
amealhadas. Assim, o utilizador do serviço pode interagir com dois componentes do sistema, sendo
que a um, gestão de carreiras, apenas pode fazer pedidos de consulta.
As configurações do serviço e a análise dos dados estão a cargo do administrador de sistema, que
tem a responsabilidade de, quando assim se justificar, fazer as alterações relativas ao percurso, horário,
lotação do veı́culo, número de lugares reserváveis em cada carreira e de configurar os mecanismos de
reserva relativos às prioridades e penalizações. Estas funcionalidades estão disponı́veis no componente associado à gestão de carreiras. Do mesmo modo, as funcionalidades de business analytics1 ,
presentes na componente de análise de dados, as quais se referem à análise estatı́stica dos dados de
ocupação, reservas e de utilizadores, ficam a cargo desta mesma entidade.
Em nenhum destes momentos existe contacto direto entre os utilizadores ou administrador e o
motorista. Contudo a ficha de viagem, que contém o percurso, horário, capacidade, número e lista de
reservas, é passada para este através do componente de gestão de carreiras. Uma vez que o motorista
recebe esta ficha, este tem a responsabilidade de validar e registar as entradas dos passageiros na
viatura e de fazer chegar essas informações ao componente de análise de dados.
A nı́vel interno, as interações existentes dizem respeito à passagem e armazenamento de informação.
Do lado das funcionalidades do cliente, existe uma interação que permite a validação das credenciais do
utilizador, recorrendo à API do Fénix, enquanto que do lado das funcionalidades do administrador existe
uma que permite gerar a ficha de viagem, que é passada aos motoristas, com toda a informação necessária para a posterior análise estatı́stica. Existe ainda uma outra interação de modo a que, quando
um utilizador fizer uma reserva, os dados desta sejam passados para a ficha de viagem.
A Figura 3.9 mostras o diagrama os grandes blocos e interações entre os diferentes componentes
do sistema. Nesta figura não são incluı́dos os atores.
3.4
Descrição detalhada dos componentes
Nesta secção são descritos os vários componentes e processos que compõem esta proposta de
solução.
3.4.1
Autenticação
Como é visı́vel pela Figura 3.9, os utilizadores podem aceder ao serviço através de qualquer dispositivo
que permita acesso à Internet. A estes será apresentada uma página com informações sobre o shuttle,
desde horários a percursos e pontos de paragem, e com espaço para autenticação no sistema. As
credenciais - username e password - utilizadas neste sistema são iguais às do sistema Fénix, uma
vez que a autenticação de utilizadores será feita através da API disponibilizada pela equipa de desenvolvimento deste último, por forma a facilitar a verificação da entidade. As entidades envolvidas neste
processo são, numa primeira fase, o utilizador, que terá de fornecer as suas credenciais ao sistema, o
1 Análise focada no desenvolvimento conhecimento e compreensão de um negócio com base em dados, métodos e métricas
estatı́sticas.
29
Figura 3.9: Diagrama de blocos dos componentes do sistema.
sistema central, que tratará da verificação e validação das mesmas, e a API do Fénix onde é delegada
a autenticação.
A Figura 3.10 representa o fluxograma da componente de autenticação do sistema.
Figura 3.10: Fluxograma da autenticação.
3.4.2
Gestão de reservas
As funcionalidades de gestão de reservas englobam os processos de pedidos de reserva, alteração e
cancelamento de viagens.
O pedido de reserva terá duas fases distintas, as quais permitem uma reserva estilo First In - First
Out (FIFO), onde quem reservar primeiro terá automaticamente garantida essa mesma reserva, até ser
atingida uma percentagem dos lugares reserváveis. Após esta fase, as reservas são colocadas em
lista de espera e estão sujeitas a um critério de prioridades. Nesta questão das prioridades, fatores
como “bom comportamento” ou incumprimento das reservas e os estatutos previstos na lei (gravidez,
incapacidade motora, entre outros) serão tidos em conta para aferir que utilizadores terão prioridade
superior ou inferior. Pelos resultados do inquérito, e uma vez que o serviço visa beneficiar a comunidade
do IST, podem ser feitas reservas de ida ou volta (únicas) ou ambas, por um perı́odo de um dia a uma
30
semana. Em relação às penalizações, caso um utilizador, não cancelando a sua viagem, não registe
a entrada no autocarro, deverá ver as suas reservas futuras condicionadas. Dado que o shuttle é um
serviço para a comunidade, as viagens, apesar de gratuitas, estarão sujeitas a um sistema de créditos.
Todos os utilizadores terão o mesmo número de créditos inicialmente e à medida que forem falhando
as suas reservas ser-lhe-ão retirados créditos. Contudo, este número pode ser reposto tendo em conta
o “bom comportamento” do utilizador. A Figura 3.11 representa as interações acima descritas.
Em relação ao cancelamento das viagens, como é visı́vel na Figura 3.12, esta função estará disponı́vel em tempo real de modo a que o utilizador possa informar o sistema que existirá mais um lugar
vago numa determinada hora, lugar esse que pode ser ocupado por um utilizador sem reserva e que
decida tentar a sua sorte. Isto é compatı́vel com o algoritmo de reservas, dado que da lotação total do
veı́culo, apenas uma percentagem será utilizada para reservas, ou seja, haverá sempre alguns lugares
que não são possı́veis reservar.
Figura 3.11: Fluxograma do processo de efetuar nova reserva.
Figura 3.12: Fluxograma do processo de cancelar uma reserva.
3.4.3
Gestão de carreiras
Uma vez que o administrador pode alterar dados relativos às carreiras, é necessário que os utilizadores
estejam a par das mesmas. Assim, para além de receberem um email com as respetivas alterações,
os utilizadores têm ao seu dispor uma função de consulta de carreiras onde são mostrados todas as
informação sobre cada uma delas.
Considerando que atingida determinada percentagem de lugares reserváveis, as reservas posteriores passam para uma lista de espera, o utilizador poderá consultar o estado da mesma. De qualquer
dos modos, o utilizador será sempre informado via email da decisão final relativa à sua reserva, sendo
este um método de assegurar e comprovar a ação e resultado obtido. Cabe ao servidor central fazer a
31
computação da prioridades e escolher de forma justa quais as reservas confirmadas e as recusadas,
sendo também da responsabilidade deste informar o utilizador do resultado das mesmas. Mais uma
vez, o resultado dependerá sempre dos estatutos definidos pelo administrador e do cumprimento ou
não das reservas anteriores.
Os utilizadores cuja reserva seja confirmada, ficarão com os dados registados numa lista que será
entregue ao motorista.
Uma vez que existe um grande número de testes e exames aos sábados, muitas vezes é necessário
criar uma carreira extra para transportar os alunos entre os dois campi. Assim, é da responsabilidade
do administrador do sistema criar, através de um formulário especı́fico onde irá inserir os detalhes de
horários e paragens, uma carreira e disponibilizá-la antecipadamente por forma a, consoante a adesão,
verificar se o número de reservas justifica este extra ou não.
Dado que a lotação para lugares reserváveis não será 100% da lotação do veı́culo, cabe ao administrador de sistema alterar o número de lugares. Este número irá sempre depender do contrato
assinado pelo IST e pela empresa de transporte. Do mesmo modo, a alteração de percurso e horário
são da responsabilidade do administrador que, em qualquer dos casos, terá formulários próprios para
as ações. Assim que estiverem efetuadas e guardadas, as alterações serão comunicadas a todos os
utilizadores por email, de modo a que todos estejam a par das mesmas, e ficarão visı́veis no sistema.
O administrador do sistema terá também ao seu dispor funcionalidades para identificar os utilizadores prioritários, definir novos veı́culos e motoristas para os percursos e para definir os perı́odos em que
determinadas carreiras funcionam.
A Figura 3.13 mostra o fluxograma dos processos descritos.
Figura 3.13: Fluxograma dos processos criar nova carreira, percurso, motorista, veiculo, perı́odo e
atualizar utilizador.
Do mesmo modo, a Figura 3.14 comprova que o administrador pode igualmente eliminar carreiras,
percursos, motoristas, veı́culos e perı́odos previamente criados. No entanto estas funcionalidades estão
sujeitas a verificações e só no caso de os dados não estarem a ser usados poderão ser eliminados.
3.4.4
Gestão de estatı́sticas
As estatı́sticas de utilização são geradas automaticamente tendo em conta a entrada ou não dos utilizadores no autocarro, ou seja, o administrador pode ver o número de reservas nas carreiras regulares
32
Figura 3.14: Fluxograma dos processos criar nova carreira, percurso, motorista, veiculo e perı́odo.
e excepcionais em determinado perı́odo de tempo, definido pelo mesmo, como mostra a Figura 3.15.
Estas estatı́sticas estão disponı́veis apenas para os administradores com o intuito de facilitar a alocação
de veı́culos e melhorar o serviço.
Pode igualmente ter acesso às estatı́sticas dos utilizadores, onde estará o ”quadro negro”dos utilizadores com mais faltas, aparecendo igualmente a indicação do número de reservas efetuadas por cada
um.
Figura 3.15: Fluxograma da análise de estatı́sticas.
3.4.5
Interação com motorista
Para tornar o sistema autónomo do lado do veı́culo, o motorista, enquanto pessoa, não deveria ter
qualquer interação com o sistema. No entanto, por forma a evitar que o serviço falhe por falta do
mecanismo necessário, este recebe uma ficha de viagem que contém, entre outras informações, a
lista de reservas, onde estão os nomes dos utilizadores que têm viagem reservada. Assim, cabe ao
motorista assegurar a validação da reserva de cada utilizador e registar a sua entrada no autocarro,
facultando posteriormente esta informação ao sistema central. A Figura 3.16 demonstra, através do
diagrama de blocos, estas mesmas interações.
3.4.6
Sı́ntese
De acordo com as preferências dos utilizados, expressas através dos resultados dos inquéritos e entrevistas, foi possı́vel chegar aos requisitos que o sistema deverá ter. De um modo geral o sistema deve
33
Figura 3.16: Fluxograma das funcionalidades de interação com o motorista.
permitir uma gestão eficaz das reservas, de forma planeada e em tempo real, deve beneficiar ou prejudicar utilizadores mediante o uso responsável do serviço, deve permitir a gestão de perı́odos, carreira e
percursos pelos administradores do sistema, deve fornecer estatı́sticas de utilização e deve ser usável
em diferentes dispositivos.
Do ponto de vista do desempenho, deve igualmente ter em atenção questões como autenticidade,
segurança, privacidade, integridade e tempos de resposta.
Para a validação dos utilizadores na aplicação, esta usa a API do Fénix, sendo que cada utilizador
terá de introduzir as suas credencias para ter acesso às áreas da aplicação.
Em nenhum momento deveria existir uma intereção direta entre os diferentes atores do sistema
(utilizadores, administradores e motorista), sendo que este deveria ser o mais autónomo possı́vel. No
entanto, na atual configuração, não existe o hardware necessário para que isto aconteça, e portanto
existem interações diretas como o administrador imprimir e fornecer a ficha de viagem ao motorista e o
motorista validar as entradas com os passageiros, tendo em conta essa ficha.
34
Capı́tulo 4
Implementação
Neste capı́tulo serão apresentadas as diferentes opções de implementação existentes, bem como a
justificação da aceitação ou não de cada uma delas, em detrimento das restantes.
4.1
Opções de implementação
Tendo em conta o estado de arte previamente estudado e os requisitos do sistema, foi feita uma análise
de qual seria a melhor forma de desenvolver e implementar uma solução para o problema existente e o
qual é o âmbito desta tese. Assim, seguem as principais opções tomadas durante o desenvolvimento
da aplicação para reserva de bilhetes.
4.1.1
Nova solução versus solução existente
Perante o problema, a solução passará sempre por algo centralizado que possa conter, gerir e manipular diferentes tipo de dados.
Perante isto, e tendo em conta os requisitos de sistema identificados, a Tabela 4.1 apresenta uma
sı́ntese de alguns pontos essenciais para o correto funcionamento de toda a aplicação, comparando as
soluções já existentes quanto ao seu suporte destes requisitos. De referir que, não sendo os únicos,
sem eles o âmbito principal - possibilitar que alunos e funcionários do IST reservem viagens no shuttle
- ficará impossı́vel de ser realizado.
Assim considera-se essencial o sistema conseguir identificar diferentes utilizadores e guardar dados dos mesmos, permitir fazer reserva quer em tempo real quer de forma planeada, bem como anular
reservas previamente feitas, alertar os utilizadores quando alguma situação se alterar e que o pagamento e reembolso dos créditos para as viagens seja feito de forma automática. De notar que este
pagamento será sempre fictı́cio, através de créditos, apenas para tornar o sistema mais real e incutir
nos utilizadores a sensação de responsabilidade pelas suas reservas.
Como é facilmente identificável pela Tabela 4.1, nenhum dos sistemas existentes cobre todas as
áreas essenciais para o funcionamento da aplicação, e como tal a opção tomada foi criar uma aplicação
de raı́z, na qual algumas ideias - algoritmos não incluı́dos - foram aproveitadas de sistemas existentes.
35
Nome
Conta de
utilizador
OD
Matrix
EZ-Link
Reserva
(TR e Plane.)
Anular
reserva
Alerta
utilizadores
4
Reembolso
4
QR Code
Ticket
Rede
Expressos
SuperShuttle
4
4
4
OEBB
4
4
4
4
Parking
with VANET
Car Parking
Locator
SPARK
Pagamento
automático
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
Managed
Motorway
ILR
4
4
4
4
4
4
4
4
Tabela 4.1: Sı́ntese de componentes essenciais de outros sistemas.
4.1.2
Aplicação nativa versus aplicação web
Para qualquer aplicação que permita a interação entre cliente e servidor, existem duas grandes opções
que podem ser tomadas: optar por uma aplicação nativa ou por uma aplicação web.
A escolha, em ambas as situações, recai no tipo de utilização que é pretendido para a mesma, bem
como nos sistemas que a irão utilizar. Uma vez que o sistema de reservas em causa tem de funcionar
em diferentes dispositivos, e consequentemente em diferentes sistemas operativos, a criação de uma
aplicação web é a solução mais abrangente, tendo em conta a limitação de recursos - uma tese de
mestrado.
Como praticamente todos os dispositivos possuem uma ligação à internet e reconhecem a linguagem HTML, torna-se muito mais simples e viável criar aplicações web para resolver estas situações.
Estas aplicações continuam a ser robustas e fiáveis o suficiente para que o utilizador as use sem qualquer preocupação.
Posto isto, a decisão é desenvolver uma aplicação web, utilizando as linguagem HTML, CSS e
JavaScript (JS), tornando-a rápida, simples e intuitiva para o utilizador.
Assim, o primeiro passo foi desenvolver algumas partes da aplicação de raı́z para se poder testar
ligação com a base de dados e autenticação de utilizadores, uma vez que esta será feita através do
FénixEDU que tem vários endpoints, e tutoriais, para aplicações desenvolvidas de raı́z. Na ótica da
aplicação estes dois passos são dos mais importantes, pois esta só permite que utilizadores ligados ao
IST reservem bilhetes, e como tal a autenticação deveria ser feita com as credenciais utilizadas pelo
36
Fénix, evitando-se assim a criação de novas contas para cada utilizador.
4.1.3
Base de dados relacional versus não relacional
Em relação à base de dados, mais uma vez se pode dividir a escolha em dois grandes tipos: relacional
ou não relacional, porque esta tese é desenvolvida em colaboração com uma outra, e porque, no âmbito
da segunda - o sistema que será implementado nos veı́culos - já existem algumas partes desenvolvidas
com base de dados não relacional - exemplo: MongoDB 1 .
Desde há muito tempo que as bases de dados relacionais são utilizadas, e durante muito tempo
foram consideradas como a melhor tecnologia para gerir e analisar grandes quantidades de dados.
Oferecem variadas funcionalidades que permitem transações fiáveis e eficientes. Contudo, estas não
são suficientemente flexiveis e eficientes para gerir e analisar grandes compilações de dados semiestruturados. A diferença mais notória entre bases de dados relacionais e não relacionais é que as
últimas não incorporam o modelo tradicional de tabelas e chaves que as primeiras promovem - a Tabela
4.2 mostra algumas das diferenças entre elas [18]. As bases de dados não relacionais são utilizadas
para solucionar problemas ligados aos big data, uma vez que primam pela grande capacidade para escalarem nos recursos que possuem. Por este motivo, hoje em dia, as bases de dados não relacionais
são amplamente utilizadas por grandes empresas como Google, Yahoo, Amazon e Facebook. No entanto, por não seguirem o tı́pico modelo de tabelas - linhas e colunas - o acesso, introdução e alteração
de dados tem de ser feito com recurso a frameworks especializadas no armazenamento de dados, as
quais são acedidas por API [19, 20]. Contudo as bases de dados não relacionais pecam pelo facto do
mercado ainda não estar muito familiarizado com esta tecnologia, pelo facto de gerar desconfiança dado
se tratar de uma tecnologia open source onde ninguém é responsável quando a mesmo falha, por implementarem buffer e multithreading que obriga a mecanismos de gestão e bloqueio, sobrecarregando
o processamento, e pelo facto de sacrificarem as propriedades ACID (Atomicity, Consistency, Isolation,
Durability) em prol das propriedades BASE (Basically Available, Soft state, Eventual consistency) [21].
Contudo a utilização de diferentes tipos de estruturação de bases de dados em âmbitos diferentes
não terá grande influência no desenrolar das teses, dado que em qualquer das situações estas só se
cruzam para leitura e atualização de dados e os mesmos podem ser facilmente feitos com recursos a
uma API desenvolvida com o intuito de manipular os dados extraidos destes dois tipos de bases de
dados, por forma a que os mesmos sejam compreendidos por ambas as partes. Outra solução possı́vel
trata-se de usar um mapeamento direto entre as bases de dados relacionais e o não relacionais - mongoDB [22]. Este mapeamento é feito por pequenos trechos de código que fazem uma correspondência
direta entre os dois tipos de bases de dados2 .
Posto isto surgem duas perguntas que legitimamente ditam a escolha a fazer:
Quando utilizar bases de dados relacionais?
Caso a estrutura se encaixe em tabelas e os dados
tenham várias relações entre eles. E se os dados estiverem corretamente ordenados, posicionados e
1 http://www.mongodb.org/
2 http://code.tutsplus.com/articles/mapping-relational-databases-and-sql-to-mongodb–net-35650, último acesso em agosto de
2014
37
Bases de dados
Relacional
Não Relacional
Baixa taxa de transferência de dados
Alta taxa de transferência de dados
Menos escalável
Altamente escalável
Os dados têm de se encaixar em tabelas ou Os dados podem ser inseridos em qualquer
estrutura predefinidos
momento, sem a definição de um esquema.
É flexı́vel
Transacional
Pode implementar várias transações ao
mesmo tempo
Index válidos em várias colunas
Index único
Propriedades ACID
Propriedades BASE
Oferece mais consistência
Compromete a consistência
Elimina dados duplicados
Possı́vel duplicação de dados. Atualizar um
registo implica atualizar todos os dados duplicados, o que leva a uma maior sobrecarga
Pesquisas simples com recursos a chaves Pesquisas são ineficientes
primárias
Tabela 4.2: Diferenças entre bases de dados relacionais e não relacionais.
relacionados, deixa de existir a preocupação com o desempenho. Num caso em que seja necessário
SQL ou transações, a escolha tem de ser mesmo as bases de dados relacionais.
Quando utilizar bases de dados não relacionais? Caso os dados sejam de difı́cil modelação num
sistema de relações, não se consiga pré definir o esquema da base de dados, se pretenda guardar
registos numa mesma coleção e com campos diferentes ou até mesmo guardar objetos JavaScript
Object Notation (JSON), a escolha deverá recair sobre bases de dados não relacionais.
3 4
Dado que para este projeto é necessário guardar dados e relações entre eles a melhor opção tratase de uma base de dados relacional, desenvolvida de raı́z tendo em conta as necessidades especı́ficas
da aplicação.
De entre as várias possibilidades de bases de dados relacionais existentes, a escolha recaiu sobre o
MySQL porque é fácil de usar, segura, tem baixo custo (existem versões gratuitas), é rápida e escalável,
previne perdas de memória e funciona em vários sistemas operativos, nomeadamente Linux - que é o
sistema operativo do servidor onde a aplicação está alojada. [23]
Base de dados desenvolvida
A Figura 4.1 mostra o modelo ER da base de dados criada para o sistema em causa.
A aplicação centra-se nas reservas de viagens, e como tal, a ”tabela central”do sistema desenvolvido
é a tabela que guarda todos os dados dessas reservas, tais como a data e hora em que a reserva foi
efetuada, a data da viagem para a qual foi feita a reserva, carreira escolhida, o estado da reserva e os
dados do utilizador. Adicionalmente esta tabela tem um campo que permite saber se o utilizador esteve
presente ou não em determinada reserva.
3 http:http://www.codemag.com/Article/1309051,
último acesso em agosto de 2014
4 http://www.neonrain.com/blog/mysql-vs-mongodb-relational-and-non-relational-databases,
38
último acesso em agosto de 2014
Figura 4.1: Modelo ER da base de dados.
Os dados desta tabela dependem de outras duas tabelas bastante importantes: a dos utilizadores que guarda a informações como nome, email, número mecanográfico e números relativos às reservas
- e das carreiras - esta está dividida em dois para facilitar a diferenciação entre carreiras regulares e
excecionais.
Ambas as tables das carreiras vão beber dados das tabelas de percurso, veiculo e motorista, onde
são guardados os pontos de paragem, o proprietário e a informação do número de lugares reserváveis
de cada veı́culo e o nome do motorista, respetivamente. A única diferença prende-se com o facto de
as carreiras regulares serem constantes para um perı́odo de tempo - perı́odo esse descrito na tabela
range date - enquanto que as carreiras exececionais são apenas para um único dia e hora especı́ficos.
Por fim existe uma tabela que serve apenas para guardar os diferentes lugares de paragem de
modo a facilitar a criação de percursos. Esta tabela não está ligada com nenhuma das restantes e
serve apenas para evitar erros ou duplicação de dados na criação de novos percursos.
39
4.2
Implementação
Nesta secção é apresentada a implementação da solução desenvolvida. Serão igualmente apresentadas as simplificações efetuadas, face ao modelo inicialmente previsto, bem como as justificações
das mesmas. De referir que todas as simplicações e alterações efetuadas não põem em causa nem
a contribuição, nem o âmbito da tese. Por fim, será feita uma pequena e sintética abordagem aos
principais problemas encontrados no processo de desenvolvimento da solução.
4.2.1
Simplificações e alterações
Como foi definido desde o inı́cio, pretendia-se um sistema de reservas que permitisse aos utilizadores
gerir viagens no shuttle da maneira que lhes conviesse, aos administradores de sistema gerir as carreiras, percursos e perı́odos do shuttle e ainda que possibilitasse a validação de entradas no veı́culo e
análises estatı́sticas.
Com o avançar do desenvolvimento, algumas funcionalidades foram sendo refinadas e deram aso a
algumas mudanças, as quais são apresentadas a seguir.
Antecipar reservas e cancelamentos
Idealmente o sistema deveria funcionar em real-time, no entanto isso poderia fazer com que os utilizadores começassem a reservar bilhetes só para garantir o lugar - sem terem de facto necessidade de ir
naquele horário - e cancelarem à última da hora, sem serem punidos, podendo eventualmente retirar
um lugar a alguém que de facto pretendia ir naquele horário.
Com um sistema em tempo real, seria impossı́vel o utilizador ser informado com antecedência se
a sua reserva tinha sido confirmada e que teria lugar assegurado no shuttle, uma vez que as reservas
poderiam ser feitas até à hora do mesmo.
Assim, por decisão administrativa, a solução passou por permitir aos utilizadores fazerem novas reservas com um dia de antecedência, de forma a que o sistema gere a lista de confirmações e informe os
utilizadores do resultado da reserva a tempo deste se organizarem e arranjarem alternativas, e a permitir cancelar reservas até dois dias de antecedência das mesmas, por forma a que, uma vez cancelada,
ainda existe um dia de margem para novos utilizadores poderem reservar para aquela carreira.
Opções alterar
Inicialmente estava previsto o sistema ter uma opção que permitisse aos utilizadores e administradores
alterar reservas, carreiras, percursos, veı́culos e outros. No entanto, esta funcionalidade é em tudo
idêntica a eliminar e voltar a criar, uma vez que, por exemplo, não é permitido alterar uma carreira caso
existam reservas já efetuadas para a mesma - tal como na funcionalidade eliminar carreira. Do mesmo
modo eliminar uma reserva é idêntico a eliminar uma reserva e voltar a criar outra na nova carreira
pretendida.
40
Como tal, para simplificar a aplicação e a interação com o utilizador, as opções de alterações foram
eliminadas da aplicação.
Sistema de créditos
Dado que o sistema teria de continuar a ser gratuito para os utilizadores, teve-se de arranjar uma
forma de incutir alguma sensação de responsabilidade nos utilizadores quando estes estão a fazer as
reservas. Assim a solução passou por um sistema de créditos.
Inicialmente todos os utilizadores dispõem de 10 créditos para gerir da maneira que melhor lhes
convém. Cada reserva efetuada tem o custo de 1 crédito que é automaticamente retirado quando um
utilizador efetua uma reserva e quer esta seja automaticamente confirmada ou fica em lista de espera.
Caso o utilizador veja a sua reserva ser rejeitada posteriormente, o crédito é-lhe devolvido.
Como o sistema tem um mecanismo de controlo de entradas no autocarro é possı́vel certificar se um
utilizador com reserva confirmada esteve ou não presente nessa mesma reserva, e assim deve existir
um mecanismo que permita beneficiar os cumpridores e prejudicar os faltosos.
Deste modo, caso um utilizador reserve a viagem para determinada carreira, esta lhe seja confirma
e ele falte, não lhe é reposto o crédito e é acrescentada mais uma falta ao utilizador. Contudo, a
utilização do serviço pode apenas ficar condicionada e nunca impossibilitada, por isso os utilizadores
nunca poderão ter menos que 1 crédito. Para quem cumpre, assim que a sua presença é marcada
na carreira, é-lhe restabelecido o crédito da viagem mais 0.1 créditos. Ou seja, a cada presença
confirmada, o utilizador ganha 1.1 créditos. Com isto um utilizador que falta largamente prejudicado
e um que cumpra vai sendo beneficiado ao longo das reservas.
No atual modelo, o número de máximo de créditos de cada utilizador é 10 créditos, e a cada
presença o utilizador ganha 0.1 créditos, contudo isto são valores parametrizáveis pelo administrador
do sistema, podendo a qualquer altura alterar estes mesmos valores.
Reserva única para utilizadores esporádicos
Esta funcionalidade apenas pode ser utilizada para utilizadores que não fazendo parte do universo do
IST, possam, com a devida autorização, utilizar o serviço do shuttle.
Em determinadas situações, como conferências por exemplo, existem pessoas que não fazem parte
do IST mas que, sendo convidados, necessitem de ser transportados entre os dois campi. Como tal
tem de existir um mecanismo que permita que os mesmo possam reservar uma viagem para a carreira
pretendida.
Como estes não têm credenciais no Fénix e não faz qualquer sentido estar a criar para um convidado
que venha apenas uma vez ao IST, cabe ao administrador criar uma reserva em nome dessa mesma
pessoa. Em primeiro lugar é necessário que a pessoa em causa de facto tenha autorização para poder
utilizar o serviço, e depois é obrigatório que faculte o número de um documento de identificação e nome,
por forma a que a sua presença seja validada na entrada do veı́culo.
41
Nestes casos, a reserva é automaticamente confirmada, fica registada no sistema e estará igualmente sujeita à validação na entrada no veı́culo, sendo assim possı́vel saber se esteve ou não presente
na carreira que lhe foi reservada.
4.2.2
Algoritmos
Para o correto funcionamento da aplicação, foi necessário o desenvolvimento de dois algoritmos que
permitem automatizar parte do processamento deste serviço.
Algoritmo de prioridades
Uma das questões muito batalhadas foram as prioridades. Havia quem afirmasse que os professores
deveriam ter prioridades sobre os alunos, outras achavam o contrário e outras ainda porque diziam que
apenas de deveriam contemplar os casos extremos e ao abrigo da lei, considerando todos os restantes
utilizadores como tendo o mesmo grau de prioridade.
Em determinadas situações, um utilizador pode ser considerado prioritário, nem que seja apenas por
uma semana, por exemplo por incapacidade motora, ou por um ano, por exemplo gravidez. Isso implica
que o administrador possa sinalizar um utilizador como prioritário e isso influenciará o mecanismo que
gera a lista de reservas confirmadas. Ou seja, quem estiver sinalizado tem de ter preferência sobre os
restantes utilizadores.
Assim, ficou decidido que, inicialmente, todos os utilizadores têm o mesmo grau de prioridade,
excepto quando sinalizados pelo administrador do sistema como prioritários.
Algoritmo de reserva
Cada veı́culo tem informação da lotação total, do número de lugares disponı́veis para reserva, dos
quais parte são aceites automaticamente e outra parte ficam em lista de espera, e a informação sobre
o limite de número de inscrições.
No caso do algoritmo das reservas, até se atingir o número de reservas aceites automaticamente,
as reservas são automaticamente confirmadas aos utilizadores, garantindo-lhes o lugar na carreira
escolhida. Passado este número, as reservas passam para uma lista de espera, que fecha quando o
número de inscrições for atingido.
Estando uma reserva em lista de espera, o seu estado será alterado através de um algoritmo que
irá ordenar os utilizador pelos critérios de prioridade, rácio entre número de faltas e número de reservas
e data e hora da reserva, informando posteriormente o utilizador se a sua reserva foi confirmada ou
rejeitada.
Assim, os factor de desempate de prioridade são:
• 1. Utilizador prioritário
• 2. O rácio entre o número de faltas e o número de reservas total, ou seja quanto mais elevado for
este rácio menos prioritário é o utilizador
42
• 3. A data e hora em que o utilizador efetuou a reserva, ou seja no caso de dois utilizadores terem
a mesma prioridade e o mesmo rácio, a reserva fica confirmada para aquele que tiver feito a
mesma mais antecipadamente
Este algoritmo gera a lista de reservas confirmadas e informa os utilizadores do estado final da
reserva às 20h do dia anterior, de forma a dar tempo ao utilizadores, que viram a sua reserva rejeitada,
de arranjarem uma solução alternativa.
4.2.3
Problemas encontrados
O tempo de desenvolvimento foi longo, como altos e baixo e com alguns problemas a surgirem, e desde
logo com a forma de autenticação dos utilizadores. Aquilo que em teoria seria uma coisas simples de
fazer, uma vez que existem tutoriais e pedaços de código, tornou-se complicado e bastante demorado.
Trata-se da integração da aplicação desenvolvida com a API do Fenix.
Na teoria, bastaria registar a aplicação, baixar um dos Software Development Kit (SDK) disponibilizados, de acordo com o tipo de linguagem de programação usada para desenvolver a aplicação, criar
alguns ficheiros de configuração - existiam tutoriais para este passo bem como pedaços de código para
facilitar a tarefa - e alterar as credenciais de acesso à API por forma a que a aplicação desenvolvida
fosse identificada e pudesse aceder aos campos disponibilizados pela API. No entanto, alguma da
informação está desatualizada - vão surgindo novas versões dos SDK com mais funcionalidades, o
que faz com que alguns ficheiros sofram alterações - e com nomes diferentes, foi necessário criar mais
ficheiros do que os expressos no tutorial e foi necessário alterar pedaços de código em ficheiros que à
partida não deveriam ser alterados. Isto atrasou o processo de autenticação e integração com a API do
Fénix e foi necessária a ajuda de elementos da equipa de desenvolvimento desta para que a integração
fosse totalmente estabelecida e ficasse a funcionar corretamente.
Posto isto o desenvolvimento desenrolou-se sem problemas de maior, sempre com algumas alterações
e ajuste na base de dados e nas tabelas, até que surgiu o momento de desenvolver o algoritmo de reservas. Primeiro teve de ser revisto todo o algoritmo e mecanismos de ordenação de prioridades,
depois teve de ser estudada a melhor maneira de correr este algoritmo, se diretamente na base de dados através de um procedimento, se um Disk And Execution Monitor (DAEMON) - programa que corre
automaticamente e de forma independente em background - inserido no servidor da aplicação. A opção
recaiu sobre a segunda hipótese, uma vez que é mais fácil de se alterar o algoritmo no futuro e não
sobrecarrega o processamento da base de dados. O DAEMON foi desenvolvido em PHP: Hypertext
Preprocessor (PHP).
O facto deste sistema se tratar de algo preliminar que, apesar de estar a funcionar, muito provavelmente vai sofrer alterações num futuro próximo, acrescentando novas funcionalidades, moldando o
sistema a novas necessidades e utilizadores, faz com que praticamente todas as variáveis utilizadas
possam ser a qualquer momento editáveis. Esta premissa faz com que seja necessário existir um ficheiro de configuração onde sejam editáveis todas as constantes, e por constantes entende-se desde a
localização da base de dados ao valor máximo dos créditos para cada utilizador. Se este requisito fosse
43
identificado numa fase inicial do projeto, não existiria qualquer tipo de problema nem dificuldade, mas
como só foi identificado numa fase mais adiantada, todos os ficheiros tiveram de ser revistos e ajustados
por forma a garantir que todos os parâmetros configuráveis estejam no ficheiro de configurações.
Por fim um nota para os poucos conhecimentos na área de design, o que faz com que a aplicação
desenvolvida não esteja graficamente muito apelativa para o utilizador. Com base nos conhecimentos
de usabilidade e com o recurso a ideias retiradas de outras aplicações do género, chegou-se a um
resultado final simples e aceitável, contudo muito do aspeto gráfico poderá ser melhorado.
4.2.4
Aplicação final desenvolvida
A aplicação resultante desta tese é uma aplicação web, desenvolvida nas linguagem de HTML, CSS,
PHP e JavaScript. Usa uma base de dados relacional desenvolvida em MySQL e o Apache como
aplicação de web server.
Para os diferentes intervenientes no sistema existem diferentes funcionalidades possı́veis. Estas
mesmas são descritas a seguir.
Casos de uso
Por utilizador, entende-se todas as pessoas associadas ao IST que podem utilizar o serviço se assim o
desejarem. Para estes casos a Figura 4.2, mostra as interações possı́veis com o sistema.
Figura 4.2: Caso de uso de um utilizador do sistema.
Como é visı́vel pela Figura 4.3, um administrador de sistema tem a seu cargo toda a configuração
do serviço, destacando-se as funcionalidades de gestão de perı́odos, carreiras, percursos, motorista
e veı́culos, das prioridades dos utilizadores, de análise estatı́stica e de fazer reservas unitárias para
utilizadores que não sejam do IST.
Por fim, as interações relativas à gestão de viagem são exemplificadas na Figura 4.4. Nesta fase
esta interações terão de ser feitas manualmente, dado que ainda não existe o hardware necessário para
fazer o sistema embarcado, mas futuramente prevê-se que passem a ser funcionalidades automáticas.
44
Figura 4.3: Caso de uso de um administrador de sistema.
Figura 4.4: Caso de uso da gestão de viagens.
Interface e funcionalidades
Como qualquer site web, esta aplicação disponibiliza alguma informação sobre o shuttle, que engloba
horário e percursos, o regulamento da aplicação e uma página de contactos mesmo que o utilizador
não esteja autenticado.
A Figura 4.5 mostra a home page da aplicação.
Após fazer o login, dependendo da sua função o utilizador tem acesso a diferentes menus. Todos
os utilizadores válidos terão acesso ao menu das reservas que lhes permite criar e cancelar reservas e
consultar o estado de uma reserva previamente feita.
A Figura 4.6 mostra a home page da aplicação, depois de o utilizador efetuar o login.
Os restantes interfaces da aplicação podem ser vistos no Anexo A.2.
Caso seja um administrador do sistema, terá também acesso a um menu que permite gerir as
carreiras, criando novas ou eliminando as existentes, gerir percursos, mais uma vez engloba a criação
ou eliminação de percursos, gerir veı́culos, motoristas e perı́odos de funcionamento de cada carreira.
De referir que todas as funcionalidade de eliminar existentes só são possı́veis caso não estejam a ser
usadas no momento, ou seja se existir pelo menos uma reserva para determinada carreira, esta não
pode ser eliminada, do mesmo modo, se um percurso fizer parte de pelo menos uma carreira, este não
também não poderá ser eliminado, e assim sucessivamente.
45
Figura 4.5: Diagrama de navegação.
Figura 4.6: Diagrama de navegação.
46
O administrador do sistema terá também a seu encargo a funcionalidade de atualizar a prioridade
de um utilizador sinalizando-o ou não como prioritário, a funcionalidade de análise de estatı́sticas e
ainda a reserva de viagens únicas para pessoas que não pertencem ao IST mas que por algum motivo
podem utilizar o serviço, esta utilização requer a autorização de um dos orgãos superiores do IST.
O lado da interação com o motorista, gestão de viagem, as funcionalidades disponı́veis são imprimir a ficha de viagem, com informação sobre a data, hora, percurso e lista de alunos confirmados
naquela carreira, sendo posteriormente entregue ao motorista, bem como atualizar os dados referentes às presenças em cada carreira. Esta atualização só é possı́vel uma vez que o motorista ficará
encarregue de registar e validar todas as entradas de utilizadores no veı́culo.
A Figura 4.7 mostra o diagrama de navegação simplificado da aplicação web desenvolvida no âmbito
desta tese. O Anexo A.1, mostra o mesmo diagrama de navegação mas com um maior nı́vel de detalhe.
De modo interno, cabe ao sistema automaticamente gerar a lista de reservas confirmadas, informando os utilizadores se as reservas em espera foram confirmadas ou rejeitadas e enviar as mensagens provenientes da página de contactos para um email especı́fico e definido previamente. Todos os
emails de confirmação e informação enviados da aplicação para os utilizadores são igualmente feitos
de forma automática por esta, sem que seja necessário a intervenção externa de um administrador.
47
Figura 4.7: Diagrama de navegação.
48
Capı́tulo 5
Avaliação
Geralmente são reconhecidos quatro nı́veis de testes: testes unitários, testes de integração, testes de
sistema e testes de aceitação. Neste capı́tulo serão descritos os testes, e resultados respetivos obtidos,
feitos à aplicação desenvolvida.
De referir que os testes com utilizadores foram feitos com utilizadores reais, quer alunos quer funcionários docentes e não docentes do IST.
5.1
Objetivo dos testes
Por forma a aferir a qualidade e desempenho da aplicação desenvolvida foram feitos testes ao longo do
desenvolvimento. Esses testes, numa primeira fase, realizaram-se componente a componente, sendo
que o seu espectro se foi alargando até ser possı́vel a realização de um conjunto de testes com utilizadores reais.
Deste modo, inicialmente os testes eram feitos a pequenos pedaços de código para garantir que
as funções estavam a funcionar como esperado, tentado assim apanhar algumas falhas que poderiam
comprometer o funcionamento do sistema na sua globalidade. Depois dos módulos estarem testados,
o objetivo passou a ser garantir a correta integração dos diferentes interfaces e módulos desenvolvidos. Como os interfaces da aplicação web foram sendo construı́dos e vistos praticamente ao mesmo
tempo e em tempo real, os interface e componentes foram integrados de uma forma interativa e assim
como os testes realizados sobre eles, isto porque parte dos interfaces mostra mensagens de sucesso
ou de falhas ao utilizadores mediante o resultado de determinada ação. Por fim, já com a aplicação
praticamente finalizada, foram feitos ao sistema em geral para comprovar que atingia os requisitos
especificados.
Uma vez que estes testes não poderiam ser feitos com utilizadores reais, os dados utilizados na base
de dados não eram dados reais, muitas vezes os dados foram introduzidos diretamente nas tabelas com
o intuito de forçar que o sistema falhasse, garantindo assim que caso falhasse a totalidade do sistema
não seria comprometida, e que os dados da base de dados não fossem alterados e/ou danificados.
Segundo a contribuições descritas no Capı́tulo 1, o sistema deveria permitir aos utilizadores gerirem
49
as suas reservas, sendo garantida a estes lugar numa viagem no shuttle assim que a reserva fosse
confirmada. Em relação às questões administrativas, o sistema deveria possibilitar a gestão de carreiras, percursos e horários do shuttle. Dado que a aplicação vai ser o interface que liga o serviço do
shuttle aos seus utilizadores e administradores de sistemas, os testes são importante para garantir o
desempenho, funcionamento e usabilidade da aplicação.
Apenas uma aplicação fiável é capaz de atrair os utilizadores. Como tal, a partir do momento que
foi possı́vel realizar pequenos testes com utilizadores, estes foram feitos. O objetivo nessa altura não
era atingir a perfeição, mas ver a aceitação que o sistema tinha perante o utilizador e se os resultados
pedidos eram fáceis de se atingirem. Relembro que estes testes foram feitos em fases iniciais e a um
número muito reduzido de utilizadores.
5.2
Cenários de testes
Umas vez que foram realizados 4 nı́veis de testes - unitários, integração, sistema e de aceitação - foram
necessários vários cadernos de testes para que fossem contemplados todos os casos, especialmente
os crı́ticos.
Todos os testes foram realizados sobre o mesmo ambiente, cujas caraterı́sticas passam por um
servidor com 2 CPU’s AMD Opteron Processor 246 de 64bits, com aproximadamente 6GB de RandomAccess Memory (RAM) e com 4 discos SATA, modelo Hitachi HDS72202 configurados em Redundant
Array of Inexpensive Disks (RAID) 5 1 .
5.2.1
Testes de sistema
Enquanto que os testes unitários são realizados entre cada componente separadamente e os de
integração agregam mais que um componente em simultâneo, para garantir que os resultados obtidos em cada ação são os esperados, os testes de sistema tentam incluir todos os parâmetros de toda
a aplicação por forma a garantir que todo o sistema está conforme e a funcionar corretamente. Como
tal os testes são exaustivos, assim como as baterias de testes a realizar.
Uma vez que os testes realizados foram bastantes, assim como a bateria de testes, seguem as
explicações generalizadas do tipo de testes que foram feitos para as principais funcionalidades. Para
as opções mais crı́ticas são apresentadas as baterias de testes realizadas por forma a tornar compreensı́vel a explicação dos testes.
Consultas
As páginas de consultas não passam de queries à base de dados e portanto os testes apenas servem
para verificar se os dados que estão a ser retornados são de factos os que devem ser mostrados.
Assim para estes casos não existe nenhuma bateria de testes especifica, sendo que os mesmo se
resumem a abrir as páginas destinadas a consultas e verificar, visualmente, os resultados obtidos.
1 Sistema
de paridade para manter a integridade dos dados
50
Nova reserva
Quer no caso das reservas regulares, quer nas excecionais, existe alguns critérios que influenciam o
resultado final obtido e como tal, neste caso a bateria de testes realizado foi mais exaustiva.
Os três factores que influenciam o resultado final são o número de reservas de todos os utilizadores
para aquela carreira, o facto de o utilizador em causa já ter ou não feito uma reserva para a mesma
carreira e o número de créditos que o utilizador tem.
Cada veı́culo tem descrição da lotação do veı́culo, do número de lugares destinados para reservas, do número de reservas que são aceites automaticamente e do número máximo de inscrições
permitidas. No caso das reservas interessam essencialmente dois valor: o número de reservas que
são aceites automaticamente e o número máximo de inscrições permitidas. Assim, existem 3 estados
possı́veis em relação ao número de reservas que são:
• o número de reservas total ser menor que o número de reservas aceites automaticamente
• o número de reservas total ser maior ou igual ao número de reservas aceites automaticamente e
menor que o número máximo de inscrições permitidas
• o número de reservas total ser maior que o número máximo de inscrições permitidas
Tendo em conta estes três estados, e os restantes dois factores, a bateria de testes realizada está
descrita na Tabela 5.1.
Veı́culo
Número reservas
1
2
3
4
5
6
7
8
9
10
11
12
<aceites automaticamente
<aceites automaticamente
<aceites automaticamente
<aceites automaticamente
>= aceites automaticamente
e <máximo inscritos
>= aceites automaticamente
e <máximo inscritos
>= aceites automaticamente
e <máximo inscritos
>= aceites automaticamente
e <máximo inscritos
>= máximo inscritos
>= máximo inscritos
>= máximo inscritos
>= máximo inscritos
Utilizador
Reserva efetuadas Créditos disponı́veis
0
0
>0
>0
0
0
>0
0
>0
0
Resultado
esperado
Rejeitado
Confirmado
Rejeitado
Rejeitado
Rejeitado
0
>0
Espera
>0
0
Rejeitado
>0
>0
Rejeitado
0
0
>0
>0
0
>0
0
>0
Rejeitado
Rejeitado
Rejeitado
Rejeitado
Tabela 5.1: Bateria de testes para novas reservas.
Atualizar dados de viagem
Uma vez que as viagens são geridas tendo em conta um sistema de créditos, em que cada viagem tem
um custo e, caso o utilizador esteja presente, um abono. A Tabela 5.2 mostra a conjugação de opções
51
e resultados quando são atualizados os dados das viagens do shuttle, para as presenças, enquanto
que a Tabela 5.3 mostra a mesma conjugação para as faltas.
De referir que o número de créditos disponı́veis para cada utilizador não poderá ultrapassar um
limite máximo e o mı́nimo será sempre pelo menos 1 crédito. E que o campo presença, quandoNull,
significa que ainda não foram atualizados os dados de viagem relativos a determinada carreira.
Presença
Resultado esperado
Tabela ”reserva”
Tabela ”user”
1
Null
Créditos (valor atual +
custo + abono)
<máximo créditos - 1
2
Null
>= máximo crédito - 1
Presenca = 1
3
4
Not null
Not null
<máximo créditos -1
>= máximo crédito - 1
-
Presenca = 1
num reservas disponiveis
=
num reservas disponiveis
+ custo + abono
num reservas disponiveis
= máximo créditos
-
Tabela 5.2: Bateria de testes para atualizar dados de viagem, quando o utilizador está presente.
Presença
Resultado esperado
Tabela ”reserva”
Tabela ”user”
1
Null
Créditos (valor atual +
custo + abono)
<1
2
Null
>=1
Presenca = 0
3
4
Not null
Not null
<1
>=1
-
Presenca = 0
num reservas disponiveis
= 1 e num faltas =
num faltas + 1
num faltas = num faltas +
1
-
Tabela 5.3: Bateria de testes para atualizar dados de viagem, quando o utilizador não está presente.
Criar percurso
Todos as opções criar necessitam obrigatoriamente de uma verificação para ver se a nova entrada já
existe ou não na base de dados, isto para evitar duplicação de dados. A opção criar carreira carece
também da verificação das horas de partida e chegada da carreira.
No entanto, no caso do criar percurso, para além dessa verificação é preciso verificar cada um dos
pontos de paragem para não se criarem percursos impossı́veis ou com pontos de passagem repetidos.
Assim a Tabela 5.4 mostra a bateria de testes para a ação de criar carreira.
É possı́vel existirem mais do que três pontos intermédios, no entanto essa configuração não foi
testada.
52
1
Pontos
intermédios
0
2
0
3
1
4
1
5
1
6
2
7
2
8
2
9
3
10
3
11
3
Matriz de possibilidades
Ponto de partida = ponto de
chegada
Ponto de partida 6= ponto de
chegada
Ponto de partida = ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Ponto de partida 6= ponto 1
Resultado
esperado
Erro
Possı́vel
Erro
Ponto 1 = chegada
Ponto 1 6= chegada
Ponto 1 = ponto
2
Ponto 1 6= ponto
2
Ponto 1 6= ponto
2
Ponto 1 6= ponto
2
Ponto 1 6= ponto
2
Ponto 1 6= ponto
2
Erro
Possı́vel
Erro
Ponto 2 = chegada
Ponto 2 6= chegada
Ponto 2 = ponto
3
Ponto 2 6= ponto
3
Ponto 2 6= ponto
3
Erro
Possı́vel
Erro
Ponto 3 = chegada
Ponto 3 =
6 chegada
Erro
Possı́vel
Tabela 5.4: Bateria de testes para criar percurso.
Eliminar
Para o caso de eliminar reserva, as verificações passam por garantir que o utilizador está a eliminar
uma reserva sua, que de facto ela existe e que apenas acontecerá dois dias depois.
Para as restantes opções - eliminar carreira, percurso, veı́culo e perı́odo - para além da verificação
se existe ou não na base de dados, é necessário verificar se a mesma opção está a ser utilizada no
momento. Ou seja, não é possı́vel eliminar uma carreira se existir pelo menos uma reserva para a
mesma, assim como não é possı́vel eliminar um percurso, ou veı́culo ou perı́odo caso um carreira
esteja a usar cada um deles.
5.2.2
Testes de aceitação com utilizadores
Com a aplicação finalizada é tempo de testar a mesma em ambientes reais com utilizadores reais.
Estes são os testes que definem se a solução funciona para o ponto de vista dos utilizadores e, como
tal, têm de ser feitos para e pelos utilizadores da aplicação desenvolvida.
Os testes de aceitação com utilizadores funcionam como verificações finais aos requisitos e funcionalidades identificadas inicialmente, para a solução apresentada, e às funcionalidades do sistema. Se,
durante o perı́odo de testes, o sistema desenvolvido funcionar como expectável, o mesmo pode ser
extrapolado para ambiente real.
53
Os testes realizados são em tudo iguais a ações que poderão acontecer em cenários reais de
utilização.
Para facilitar a realização dos testes e identificar os resultados esperados, foram criados vários
cenários com o intuito de tentar cobrir todas as funcionalidades da aplicação, de modo a que se obtenha um número razoável de variações para os mesmo cenários e identificar o que deverá ou não ser
simplificado ou alterado, do ponto de vista da usabilidade. Assim, a Tabela 5.5 indica a lista de testes
realizados, descrevendo as atividades, o público alvo e os resultados, em termos de tempo demorado
e grau de dificuldade, para cada uma delas. Quantitativamente o grau de dificuldade está numa escala
crescente de dificuldade entre 1 e 5, sendo que, fazendo o mapeamento do nı́vel qualitativo, o fácil
corresponderá a valores entre 1 e 2, o médio entre 3 e 4, e o difı́cil corresponderá ao 5. Os valores de
tempo indicados na tabela são os objetivos que se pretendem atingir.
11
Atividade
Nova reserva para o dia 1/1/2015
Nova reserva para data qualquer
Consultar estado reservas
Eliminar reserva criada em 2
Enviar mensagem através do formulário dos contactos
Criar carreira com campo especı́ficos
(obriga a criar percurso, veı́culo e
perı́odo primeiro)
Eliminar carreira criado em 6
Eliminar percurso criada em 6
Atualizar prioridade de utilizador
Fazer uma reserva para um utilizador
especı́fico
Imprimir ficha de viagem
12
Atualizar dados de viagem
1
2
3
4
5
6
7
8
9
10
Público alvo
Utilizador
Utilizador
Utilizador
Utilizador
Utilizador
Resultados esperados
Tempo (min)
Dificuldade
<2
Fácil
<2
Fácil
<1
Fácil
<1
Fácil
<2
Fácil
Administrador
<3
Médio
Administrador
Administrador
Administrador
Administrado
<1
<1
<1
<2
Médio
Médio
Fácil
Fácil
Administrador/
Motorista
Administrador/
Motorista
<2
Fácil
<3
Médio
Tabela 5.5: Bateria de testes para atualizar dados de viagem, quando o utilizador não está presente.
O teste número 10 refere-se aos casos em que alguém não pertencente ao IST precise de utilizar o
shuttle para se deslocar entre os campi e tenha a devida autorização para o fazer.
Quanto ao teste 12 os resultados esperados dependem sempre do número de reservas existentes,
por exemplo se só estiverem 5 pessoas presentes no veı́culo é rápido identificar e atualizar, mas se
em 50 lugares metade for e a outra metade não torna o processo um pouco mais complicado para
identificar corretamente todos os utilizadores. No entanto não és espectável que a pessoa responsável
demore mais que 4 minutos a realizar esta atividade.
5.2.3
Testes de carga e performance
Outro indicador importante e com o qual se deve ter alguma atenção, tendo em conta o possı́vel número
de utilizadores que poderão aceder à aplicação ao mesmo tempo, é o desempenho do sistema. Mesmo
54
em alturas com pico de acessos, o sistema desenvolvido deverá responder dentro de um intervalo de
tempo razoável a um pedido, nem deixar completamente de funcionar.
Neste aspetos as partes mais crı́ticas são as relacionadas com as reservas, uma vez que existem
mais de 11 000 estudantes e mais de 1 000 funcionários docentes e não docentes que poderão utilizar
o serviço se assim o pretenderem. Como tal, é necessário que o sistema seja rápido e que aguente
com vários pedidos e acessos em simultâneo.
Para a realização deste tipo de testes existem várias plataformas na internet que permitem simular
estes mesmos testes. As diferenças entre elas são mı́nimas e sem influência para o que está em causa,
por isso a escolha recaiu sobre as que teriam os relatórios mais completos, permitindo assim obter mais
informação por forma a melhor o desempenho da aplicação.
Assim os testes de carga e performance passam por:
• Perceber quais os possı́veis bottlenecks
• Perceber como a aplicação reage a um elevado número de utilizadores a fazerem pedidos em
simultâneo
Os utilizadores estão dispositivos a esperar pela resposta de uma web page até 10 segundos. Na
realidade existem 3 valores importantes no que ao tempo de resposta dizem respeito, sendo entre 0,1
segundos a 1 segundo é o limite para que o utilizador sinta que o sistema está a reagir, não sendo
necessário nenhum feedback especial, entre 1 segundo e 10 segundos é o limite para que o pensamento do utilizador não seja interrompido, mesmo que este note o atraso, e 10 segundos é o limite para
manter a atenção de um utilizador. Para atrasos superiores, o utilizador irá perder o interesse e realizar
outras tarefas enquanto espera pela resposta. [24, 25]
Tendo por base uma análise qualitativa, as funcionalidades relativas aos utilizadores comuns são
aquelas que mais facilmente podem tornar-se bottlenecks da aplicação, uma vez que existem mais de
12 000 pessoas que podem utilizar estas mesmas funcionalidades. No que toca as funcionalidades de
administradores de sistema e à interação com o motorista, para ambos os casos apenas um pequeno
número de pessoas terá acesso a elas, não se tornando assim espetável que as mesmas venham a ter
vários pedidos em simultâneo.
Assim, os testes de carga e performance têm de ser efetuados sobre as seguintes páginas:
• Home page
• Consultar horário do shuttle
• Consultar percurso do shuttle
• Fazer nova reserva
• Cancelar reserva
• Consultar estado da reserva
• Regulamento
55
• Contactos
Mais se acrescenta que, neste tipo de testes, os mesmos devem ser feitos sobre a aplicação em si
e não sobre o servidor.
5.3
Resultados dos testes
Depois de identificados os testes e as baterias, é chegada a fase da sua realização e análise. Nesta
secção serão apresentados os resultados obtidos e a influência dos mesmo sobre a aplicação e possı́vel
trabalho futuro.
5.3.1
Testes de sistema
Uma vez que o objetivo destes testes é identificar as falhas e erros da aplicação antes da entrada em
produção, a realização dos mesmo acabou por resultar em algumas alterações que em nada afetaram
as contribuições esperadas.
As baterias indicadas na secção anterior foram realizadas mais que uma vez até que os resultados
esperados em cada um dos testes fossem exatamente iguais aos resultados obtidos, uma vez que a
aplicação foi sofrendo melhorias continuas. Só neste ponto a aplicação se pode considerar finalizada
e apta para os testes com utilizadores. Resta então referir que a aplicação passou em todos os testes
sem que fossem encontrados problemas.
5.3.2
Testes de aceitação com utilizadores
Os testes com utilizadores foram realizados em diferentes máquinas e diferentes browsers, por forma
a certificar que a aplicação funciona corretamente nas diferentes configurações. Os utilizadores que
fizeram os testes foram pessoas de vários escalões etários, ligados ou não ao IST - para resolver a
questão do login, as pessoas que fizeram os testes sem terem credenciais do Fénix, fizeram-no com a
minha conta.
As atividades dos testes com utilizadores foram cronometradas e no final de cada atividade os
utilizadores classificaram as mesmas quanto a dificuldade que apresentaram. Como o nı́vel 5 é o
grau de maior dificuldade, qualquer atividade em que grande parte dos testes indique este mesmo
nı́vel, significa que deverá ser revista e alterada, de modo que a mesma se torne mais usável para o
utilizador.
Em todos os casos, foi dado uma explicação inicial, enquadrando o utilizador com o âmbito da tese
e com a aplicação. depois foi dado algum tempo ao utilizador para que pudesse navegar livremente,
tendo assim o primeiro contacto com a aplicação para que não existisse o choque inicial nas atividades
que iria realizar. De igual modo, era dito que atividades diziam respeito aos utilizadores comuns, aos
administradores e à interação administrador/motorista.
Dos testes realizados, há a reter que os utilizadores tentam fazer as atividades demasiado depressa
e não lêem a totalidade das indicações escritas na aplicação. Isto leva a que muitas vezes os mesmos
56
façam coisas erradas, que não eram do âmbito da atividade em causa, levando a um aumento do tempo
da atividade. Foi igualmente possı́vel reparar que, no caso da atividade 1, muitos utilizadores depois
de escolherem a data e o percurso, iam diretamente ao quadro relativos às reservas excepcionais,
acabando por fazer uma reserva excepcional em vez de regular.
Ainda assim, os resultados obtidos não fogem muito do que estava previsto. Seguem os gráficos de
dispersão dos resultados obtidos, tendo em conta o tempo que os utilizadores demoraram e o grau de
dificuldade que indicaram, bem como as conclusões a retirar dos testes realizados em cada atividade.
Os testes foram realizados com uma amostra de 27 pessoas.
Atividade 1 - Nova reserva para o dia 1/1/2015
Depois da breve introdução à aplicação e do utilizador ter navegado durante algum tempo na mesma,
seguiram-se as instruções mais especı́ficas sobre os testes. Para a atividade 1, o utilizador deveria
fazer uma nova reserva regular, para o dia 1/1/2015, para o percurso Alameda-Sete Rios-Taguspark,
com partida às 08:00:00h. Apesar destes campos não estarem descritos na Tabela 5.5, referentes à
bateria de testes, por uma questão de justiça e igualdade no teste, a informação foi facultada a todos
os utilizadores antes de começarem a realizar a atividade.
O tempo médio da realização desta atividade foi de 37 segundos e o grau de dificuldade médio de
aproximadamente 1,30.
A Figura 5.1 mostra o gráfico de dispersão sobre os testes realizados para a atividade 1.
Figura 5.1: Gráfico de dispersão da atividade 1.
As sugestões e comentários que os utilizadores foram indicando prendem-se com o nome dos links
no menu, onde deveria estar ”Nova reserva”, ”Cancelar reserva”, ”Consultar estado da reserva”e mostrar uma separação clara entre as reservas regulares e as excepcionais. Um último reparo foi feito para
um botão que só deverá aparecer quando a tabela com os horários for igualmente visı́vel.
57
Atividade 2 - Nova reserva para data qualquer
Nesta atividade foi dada total liberdade ao utilizador para criar uma nova reserva para uma qualquer
carreira à escolha do mesmo, quer esta fosse regular ou excecional.
O tempo médio da realização desta atividade foi de 22 segundos e o grau de dificuldade médio de
1,04.
A Figura 5.2 mostra o gráfico de dispersão sobre os testes realizados para a atividade 2.
Figura 5.2: Gráfico de dispersão da atividade 2.
Tal como na atividade 1, as sugestões prenderam-se apenas com a questão do tı́tulo dos menus.
Atividade 3 - Consultar estado das reservas
Sobre esta atividade não existe muito a acrescentar, trata-se de uma simples consulta em relação às
reservas dos utilizadores.
O tempo médio da realização desta atividade foi de 11 segundos e o grau de dificuldade médio de
1.
A Figura 5.3 mostra o gráfico de dispersão sobre os testes realizados para a atividade 3.
Atividade 4 - Eliminar reserva criada em 2
Aqui tratava-se de eliminar a reserva que o utilizador tinha criado na segunda atividade. Foi fácil identificarem o local onde tinham de ir, mas alguns utilizadores, ainda perderam algum tempo à procura da
reserva que teriam de eliminar, mesmo que a tabela onde estas aparecem esteja ordenada por data e
hora. Esta situação aconteceu essencialmente quando o utilizador tem várias reservas efetuadas.
O tempo médio da realização desta atividade foi de 16 segundos e o grau de dificuldade médio de
1.
A Figura 5.4 mostra o gráfico de dispersão sobre os testes realizados para a atividade 4.
58
Figura 5.3: Gráfico de dispersão da atividade 3.
Figura 5.4: Gráfico de dispersão da atividade 4.
Atividade 5 - Enviar mensagem através do formulários dos contactos
Esta era a última atividade dos utilizadores comuns, prevista na bateria de testes.
A maior parte dos utilizadores teve facilidade em chegar ao local onde deveria realizar a atividade,
contudo ainda existiram uns que ficaram um pouco na dúvida, dado que pensaram que os contactos
seria apenas uma página onde apenas estivessem discriminados os contactos do IST.
Os dados inseridos pelos utilizadores foram totalmente aleatórios, e sem qualquer significado, pois
o objetivo era apenas perceber se formulário era intuitivo para o utilizador ou não.
O tempo médio da realização desta atividade foi de 29 segundos e o grau de dificuldade médio de
1,15.
A Figura 5.5 mostra o gráfico de dispersão sobre os testes realizados para a atividade 5.
Surgiram várias vezes a questão da necessidade ou não de um campo para o utilizador inserir o sue
email. Uma vez que a aplicação está ligada ao Fénix e que a aplicação pode buscar várias informação
59
Figura 5.5: Gráfico de dispersão da atividade 5.
do utilizador através da API do Fénix, a aplicação facilmente consegue saber o email do utilizador.
Contudo muito utilizadores podem querer receber o email de resposta numa diferente conta de email,
daı́ que seja necessário um campo especı́fico para isso.
Houve quem ainda fosse mais longe e tivesse ficado na dúvida se este campo de email fosse para
inserir o email do utilizador ou de um dos campi do IST. Neste caso, claramente é uma questão de
compreensão e de legenda no formulário.
Atividade 6 - Criar carreira com campos especı́ficos
Despachadas as atividades que dizem respeito aos utilizadores comuns, passemos para as que dizem
respeito aos administradores do sistema.
A primeira atividade dizia respeito à criação de uma nova carreira, com partida as 17:30:00h e
chegada as 18:30:00h, cujo percurso deveria ser ”atividade 6 inicio-atividade 6 fim”, o veı́culo indicado
é o ”atividade 6”e o perı́odo deveria ser ”atividade 6”. Relembro que se trata de um teste e como tal os
dados são dados sem qualquer interesse, apenas têm o propósito de funcionar para as atividades em
questão e posteriormente serão apagados.
Esta atividade tem o intuito de ver como o utilizador reage quando não tem dados que suportem o
que lhe foi pedido. Neste caso o utilizador apenas teria de criar o percurso, dado que todos os restantes
campos já existiam.
A atividade acabou por se tornar mais simples do que inicialmente era prevista. Com maior ou
menor dificuldade os utilizadores, na sua maioria, acabavam por perceber que tinha de criar o percurso
que era pedido, e demorando mais ou menos tempo acabavam por realizar a atividade sem dificuldades
de maior. No entanto houve alguns utilizadores que tentaram criar a carreira mesmo não indicando o
percurso.
O tempo médio da realização desta atividade foi de 2 minutos e 35 segundos e o grau de dificuldade
médio de 2,48.
60
A Figura 5.6 mostra o gráfico de dispersão sobre os testes realizados para a atividade 6.
Figura 5.6: Gráfico de dispersão da atividade 6.
Vários utilizadores aproveitaram esta atividade para dar a sugestões de colocar links ou botões que
fizessem o redirecionamento para as respetivas páginas a seguir às tabelas de percurso, veı́culo e
perı́odo, por forma a facilitar a tarefa de criar cada um destes campos ao utilizador.
Atividade 7 - Eliminar carreira criada em 6
Não existe muito a dizer sobre esta atividade, trata-se apenas de escolher a carreira e eliminá-la.
O tempo médio da realização desta atividade foi de 24 segundos e o grau de dificuldade médio de
1,11.
A Figura 5.7 mostra o gráfico de dispersão sobre os testes realizados para a atividade 7.
Figura 5.7: Gráfico de dispersão da atividade 7.
61
Atividade 8 - Eliminar percurso criada em 6
Esta atividade é em tudo idêntica à anterior. No entanto se o utilizador tentar eliminar um percurso que
esteja a ser utilizado pelo menos numa carreira, esta ação não será possı́vel.
Isso aconteceu num dos testes realizados, em que foi dito ao utilizador que deveria eliminar a carreira e percurso criados anteriormente e ele optou por tentar eliminar primeiro o percurso. Como a
aplicação mostrou a mensagem de erro com a justificação para o mesmo, o utilizador conseguiu facilmente corrigir a ação.
O tempo médio da realização desta atividade foi de 19 segundos e o grau de dificuldade médio de
1,11.
A Figura 5.8 mostra o gráfico de dispersão sobre os testes realizados para a atividade 8.
Figura 5.8: Gráfico de dispersão da atividade 8.
Atividade 9 - Atualizar prioridade de utilizador
Não havendo um utilizador especı́fico ao qual deveriam alterar a prioridade, foi indicado aos utilizadores
para alterar a prioridade deles próprios.
O tempo médio da realização desta atividade foi de 26 segundos e o grau de dificuldade médio de
1,15.
A Figura 5.9 mostra o gráfico de dispersão sobre os testes realizados para a atividade 9.
Uma vez que é preciso inserir o número mecanográfico com um formato especı́fico, alguns utilizadores não conseguirão realizar a atividade à primeira tentativa. Com isto, vários utilizadores deram
indicação de que o exemplo do formato deveria estar imediatamente antes da caixa de texto onde será
inserido o número mecanográfico.
62
Figura 5.9: Gráfico de dispersão da atividade 9.
Atividade 10 - Fazer uma reserva para um utilizador especı́fico
Existem situações em que alguém que não seja do IST, necessite de se deslocar entre os dois campi
através do shuttle. Assim, cabe ao administrador fazer uma reserva especı́fica para esse utilizador. No
caso dos testes não havia um utilizador real nestas condições, portanto foi pedido aos utilizadores que
fizessem esta reserva utilizando um número de Bilhete de Identidade determinado ou, para facilitar, que
usassem o número do Bilhete de Identidade (BI) do próprio utilizador.
O tempo médio da realização desta atividade foi de 50 segundos e o grau de dificuldade médio de
1,37.
A Figura 5.10 mostra o gráfico de dispersão sobre os testes realizados para a atividade 10.
Figura 5.10: Gráfico de dispersão da atividade 10.
Mais uma vez, alguns utilizadores demoraram mais tempo do que era previsto a descobrir o local
onde poderiam realizar esta atividade, e como tal vários disseram que o nome dado no menú não é o
melhor para este caso.
63
Atividade 11 - Imprimir ficha de viagem
As últimas atividades da bateria de testes dizem respeito à interação com o motorista. Para a atividade
10 o utilizador tem de imprimir a ficha de viagem para a carreira cujo percurso é ”atividade 11 - atividade
12”, no dia 26/02/2015.
O tempo médio da realização desta atividade foi de 30 segundos e o grau de dificuldade médio de
1,15.
A Figura 5.11 mostra o gráfico de dispersão sobre os testes realizados para a atividade 11.
Figura 5.11: Gráfico de dispersão da atividade 11.
Atividade 12 - Atualizar dados de viagem
Em relação à atividade 12, o utilizador terá de atualizar os dados para a mesma viagem que acabou de
imprimir a ficha, ou seja para a carreira do dia 26/02/2015, cujo percurso é ”atividade 11 - atividade 12”.
O tempo médio da realização desta atividade foi de 31 segundos e o grau de dificuldade médio de
1,07.
A Figura 5.12 mostra o gráfico de dispersão sobre os testes realizados para a atividade 12.
5.3.3
Testes de carga e performance
Com base nos limites de tempo que um utilizador está disposto a espera pela resposta da página, os
resultados dos testes de carga e performance identificados são a seguir apresentados sobre a forma de
gráfico, onde são mostrados o tempo de resposta e o número de utilizadores ativos a cada momento.
Os testes foram realizados com recurso ao Load Impact 2 , que gera um script de carga automático,
simulando utilizadores reais, diferentes browsers, diferentes condições da rede e comportamentos dos
visitantes, e testando esse mesmo script na aplicação pretendida. No fim são apresentados os gráficos
com os resultados.
2 http://loadimpact.com/,
último acesso em outubro de 2014
64
Figura 5.12: Gráfico de dispersão da atividade 12.
Todos estes testes foram feito com 250 utilizadores virtuais e tiveram duração de 5 minutos. Ou
seja, durante 5 minutos o número de utilizadores virtuais vai aumentando até atingir os 250.
Home page
A primeira vez que a barreira dos 10 segundos foi ultrapassada, foi a partir do momento que o teste
passou a contar com 120 utilizadores virtuais ativos.
A Figura 5.13 mostra o gráfico dos resultados dos testes de carga e performance para a home page.
Figura 5.13: Gráfico do teste de carga e performance sobre a homepage.
Consultar horário do shuttle
A barreira dos 10 segundos foi ultrapassada quando estavam 115 utilizadores virtuais ativos.
65
A Figura 5.14 mostra o gráfico dos resultados dos testes de carga e performance para consultar o
horário do shuttle.
Figura 5.14: Gráfico do teste de carga e performance para consulta de horário.
Consultar percurso do shuttle
A barreira dos 10 segundos foi ultrapassada quando estavam 115 utilizadores virtuais ativos.
A Figura 5.15 mostra o gráfico dos resultados dos testes de carga e performance para consultar os
percursos do shuttle.
Figura 5.15: Gráfico do teste de carga e performance para consultar os percursos do shuttle.
Fazer nova reserva
A barreira dos 10 segundos foi ultrapassada quando estavam 120 utilizadores virtuais ativos.
66
A Figura 5.16 mostra o gráfico dos resultados dos testes de carga e performance para fazer uma
nova reserva.
Figura 5.16: Gráfico do teste de carga e performance para fazer nova reserva.
Cancelar reserva
Com 117 utilizadores, é ultrapassada a barreira dos 10 segundos para carregar a página.
A Figura 5.17 mostra o gráfico dos resultados dos testes de carga e performance para cancelar uma
reserva.
Figura 5.17: Gráfico do teste de carga e performance para cancelar uma reserva.
Consultar estado da reserva
A barreira dos 10 segundos foi ultrapassada quando estavam 121 utilizadores virtuais ativos.
67
A Figura 5.18 mostra o gráfico dos resultados dos testes de carga e performance para consultar o
estado das reservas.
Figura 5.18: Gráfico do teste de carga e performance para consultar o estado das reservas.
Regulamento
A barreira dos 10 segundos foi ultrapassada quando estavam 117 utilizadores virtuais ativos.
A Figura 5.19 mostra o gráfico dos resultados dos testes de carga e performance para a página do
regulamento.
Figura 5.19: Gráfico do teste de carga e performance para a página do regulamento.
Contactos
A barreira dos 10 segundos foi ultrapassada quando estavam 120 utilizadores virtuais ativos.
68
A Figura 5.20 mostra o gráfico dos resultados dos testes de carga e performance para a página dos
contactos.
Figura 5.20: Gráfico do teste de carga e performance para a página dos contactos.
5.3.4
Análise de resultados
Das baterias de testes de sistema existentes, era expetável que a solução passasse em todos os testes,
tal como aconteceu, até porque de outra forma o sistema não estaria em condições de ser utilizado.
Em relação aos testes com utilizadores, apesar de não ter sido realizados um grande número de
testes, os resultados obtidos superaram as expetativas em larga escala, com alguns utilizadores a
realizarem as atividades em menos tempo do que esperado. A média de tempo demorado em todas as
atividades ficou sempre abaixo do tempo limite para a realização de cada atividade, assim como o grau
de dificuldade. Ainda assim, esporadicamente havia um ou outro utilizador que ultrapassava o tempo
espera ou que achava a que o grau de dificuldade era maior do que aquele que se previa.
Desta forma pode-se afirmar que a aplicação é simples e usável e que as funcionalidades e atividades são facilmente acedidas e efetuadas.
Em relação aos testes de carga e performance, estes estiveram abaixo do esperado. Segundo os
mesmos, a partir do momento que estejam cerca de 120 utilizadores em simultâneo a aceder a uma
página, esta vai demorar demasiado tempo a carregar. Contudo, tendo em conta que a lotação do
shuttle é de 50 lugares, e que estudos recentes de ocupação do mesmo afirmam que a média mais
elevada de passageiros por carreira é de 35 passageiros - registada em setembro de 2013 -, parece
aceitável que o sistema consiga suportar até 120 utilizadores em simultâneo, dado que é praticamente
o triplo da ocupação média registada no mês de maior afluência.
69
Capı́tulo 6
Conclusão
Neste capı́tulo são apresentadas as principais conclusões do trabalho desenvolvido ao longo da tese,
fazendo um breve enquadramento e paralelismos do âmbito inicial e contribuições esperadas com o
resultado final obtido. Serão igualmente enunciados alguns pontos que podem ser tomados num futuro
para melhorar a solução apresentada.
6.1
Sumário
Inicialmente era esperado um sistema que facilitasse a gestão de viagens no shuttle para a comunidade
do IST, por forma a evitar as filas de espera e que os utilizadores ficassem sem lugar nos autocarros,
quando tinham uma grande necessidade de se deslocar entre os dois campi. O sistema deveria permitir
aos utilizadores fazerem, alterarem e cancelarem reservas da maneira que achassem mais conveniente,
quer as reservas fossem planeadas ou em tempo real. De igual modo o sistema deveria possibilitar a
gestão de carreira, percursos e horários, sendo que estas opções apenas estariam visı́veis do lado da
administração do sistema.
Para definir estas funcionalidades e requisitos da aplicação, em muito contribuı́ram os inquéritos e
entrevistas realizadas, que permitiram um visão geral da caraterização da população alvo, do estado
atual do serviço e do pretendido num sistema futuro.
O resultado do trabalho efetuado em tudo tem a ver com o que era esperado. Houve algumas
alterações, desde logo a questão das alterações de reserva - sendo que esta funcionalidade se assemelha a eliminar uma reserva e efetuar nova reserva, não acrescentado qualquer funcionalidade extra
ao sistema - que deixou de estar disponı́vel para os utilizadores, e alguns acrescentos, como a opção
de um administrador fazer uma reserva para alguém que não seja aluno nem funcionário do IST, mas
que esteja autorizado a utilizar o shuttle.
No fundo, do objetivo e contribuições esperadas, inicialmente identificados, para o resultado final
obtido, não existem grandes diferenças, a aplicação foi sendo ajustada às necessidades ao longo do seu
desenvolvimento e todas as alteração efetuadas e novas funcionalidades adicionadas apenas servem
para facilitar e/ou complementar a aplicação, não alterando, em nenhuma medida, o âmbito da tese.
70
6.2
Conquistas
Como era espetável, foi desenvolvida a aplicação que permite aos utilizadores gerirem viagens no shuttle e aos administradores do sistema gerirem todo este serviço, desde carreiras, percursos a veı́culos.
Os testes ao sistema revelaram a aplicação funciona corretamente, sendo que os outputs das funcionalidades vão de encontro com o que era esperado tendo em conta os inputs submetidos.
No que toca aos testes com os utilizadores existem alguns pontos a rever. Tratam-se essencialmente
de questões de layout ou cores, que não sendo determinantes para o funcionamento do sistema, têm
repercussões ao nı́vel da usabilidade da mesma.
Por fim, em relação aos testes de carga e performance, para a atual configuração do ambiente de
testes, os resultado obtidos ficaram bastante aquém das expetativas. Como foi visı́vel pelos gráficos
de relatório dados pelo aplicação de testes, o tempo limite de respostas para o qual um utilizador está
disposto a esperar, é ultrapassado entre os 115 e 120 utilizadores ativos.
Contudo, ao fim de um semestre de trabalho, o principal objetivo desta tese foi conseguido: um
sistema de reserva e gestão para o shuttle.
Continua a ser um sistema preliminar, que não está perfeito, mas que neste momento é melhor do
que a solução existente e como tal é um ponto de partida que abre este campo para novos estudos e
melhorias para o serviço. Idealmente, este tipo de soluções pode levar a uma gestão sustentada do
serviço de shuttle.
6.3
Trabalho futuro
Tratando-se de uma solução inicial, dado que é a primeira solução apresentada para o problema em
questão, a mesma irá carecer constantemente de atualizações, modificações e verificações das carreiras. Esta questão pode ser resolvida fazendo a ligação desta aplicação à nova aplicação da API do
Fénix - lançada no inı́cio deste ano letivo - onde estão dados relativos ao horário do shuttle. Ou seja,
neste momento uma alteração de uma carreira do shuttle implica que a mesma seja feita na aplicação
das reservas desenvolvida no âmbito desta tese e na aplicação do Fénix, juntando as duas aplicações
passa a ser necessário uma única alteração.
Idealmente a aplicação deveria ajudar a gerir os veı́culos, por exemplo se não houver ninguém a
reservar o veı́culo para uma determinada carreira, este não deveria sair, ou até mesmo no caso de não
existir ninguém para entrar ou sair em determinada paragem, o autocarro não deveria passar por lá,
poupando-se assim tempo e combustı́vel. No entanto, na atual configuração não é possı́vel dado que
os lugares disponı́veis para reserva não correspondem à totalidade da lotação do veı́culo e pelo facto
de não ser possı́vel a um utilizador indicar a paragem de entrada e saı́da. De referir que isto resulta de
requisitos definidos pelos orgãos de gestão do IST.
Uma outra funcionalidade que deve ser considerada como trabalho futuro é a questão da aplicação
funcionar em tempo real. Atualmente o sistema não permite uma gestão completa em tempo real dado
que não há hardware que assim o permita, por exemplo é impossı́vel o sistema saber em tempo real
71
quem entra no veı́culo, neste momento esse registo terá de ser feito pelo motorista em papel, apenas
sendo introduzido no sistema posteriormente.
A juntar a isto vem também uma questão da gestão de carreiras. Na presente configuração, um
administrador do sistema não pode eliminar uma carreira caso já existam reservas para a mesma. No
entanto, isto pode levar a que só se possam eliminar carreiras num perı́odo em que o serviço não
esteja a ser utilizado, por exemplo nas férias escolar. Assim, modificar esta funcionalidade seria uma
mais valia para o sistema final.
Para tornar o sistema ainda mais autónomo e completo, a impressão da ficha de viagem deveria
ser automática e deveria igualmente ser enviada via email para alguém responsável por controlar os
passageiros. Esta funcionalidade deixará de ser necessária assim que exista um sistema do lado do
veı́culo que faça este registo automaticamente.
Uma referência ao layout da aplicação: o que foi desenvolvido terá de ser revisto e alinhado com
o aspeto gráfico das páginas do IST de modo a que não seja percetı́vel que se tratam de aplicações
completamente diferentes.
Seria igualmente interessante, para o administrador de sistemas poder configurar as variáveis globais diretamente na aplicação, ao invés de ter de abrir o script no servidor.
Por fim, uma última referência ao hardware que será desenvolvido e estará presente no veı́culo. No
estando no âmbito desta tese, este hardware é essencial para se conseguir um sistema embarcado e
que o mesmo passe a ser autónomo, como era inicialmente pretendido.
72
Anexo A
Aplicação desenvolvida
A.1
Diagrama de navegação detalhado
A Figura A.1 mostra o diagrama de navegação detalhado da aplicação.
A.2
Interfaces da aplicação
A Figura A.2 mostra a página de consulta de horários do shuttle.
A Figura A.3 mostra a página de consulta de percursos do shuttle.
A Figura A.4 mostra a página de criar uma nova reserva no shuttle.
A Figura A.5 mostra a página de eliminar uma reserva.
A Figura A.6 mostra a página de consulta do estado das reservas.
A Figura A.7 mostra a página para imprimir a ficha de viagem.
A Figura A.8 mostra a página para atualizar dados de viagem.
A Figura A.9 mostra a página para criar um novo perı́odo.
A Figura A.10 mostra a página para eliminar um perı́odo.
A Figura A.11 mostra a página para criar uma nova carreira.
A Figura A.12 mostra a página para eliminar uma carreira.
A Figura A.13 mostra a página para criar um novo motorista e veı́culo.
A Figura A.14 mostra a página para eliminar um motorista ou veı́culo.
A Figura A.15 mostra a página para atualizar a prioridade de um utilizador.
A Figura A.16 mostra a página para analisar as estatı́sticas de viagens.
A Figura A.17 mostra a página do regulamento.
A Figura A.18 mostra a página dos contactos.
73
Figura A.1: Diagrama detalhado de navegação detalhado .
74
Figura A.2: Interface da aplicação - consulta horário.
Figura A.3: Interface da aplicação - consulta percurso.
75
Figura A.4: Interface da aplicação - criar nova reserva.
Figura A.5: Interface da aplicação - eliminar reserva.
76
Figura A.6: Interface da aplicação - consulta do estado das reservas.
Figura A.7: Interface da aplicação - imprimir ficha de viagem.
77
Figura A.8: Interface da aplicação - atualizar dados de viagem.
Figura A.9: Interface da aplicação - criar perı́odo.
78
Figura A.10: Interface da aplicação - eliminar perı́odo.
Figura A.11: Interface da aplicação - criar carreira.
79
Figura A.12: Interface da aplicação - eliminar carreira.
Figura A.13: Interface da aplicação - criar motorista e veı́culo.
80
Figura A.14: Interface da aplicação - eliminar motorista ou veı́culo.
Figura A.15: Interface da aplicação - atualizar a prioridade.
81
Figura A.16: Interface da aplicação - analisar estatı́sticas.
Figura A.17: Interface da aplicação - regulamento.
82
Figura A.18: Interface da aplicação - contactos.
83
84
Referências
[1] Vassilis Kostakos and Tiago Camacho and Claudio Mantero: Wireless detection of end-to-end passenger trips on public transport buses. In International IEEE, ed.: Annual Conference on Intelligent
Transportation Systems. Volume 13., Madeira Island, Portugal (September 19-22 2010) 1795–1800
[2] Kerschbaum, F., Lim, H.W., Gudymenko, I.: Privacy-preserving billing for e-ticketing systems in
public transportation. In: Proceedings of the 12th ACM Workshop on Workshop on Privacy in the
Electronic Society. WPES ’13, New York, NY, USA, ACM (2013) 143–154
[3] Finžgar, L., Trebar, M.: Use of nfc and qr code identification in an electronic ticket system for public
transport. In: Software, Telecommunications and Computer Networks (SoftCOM), Split (Sept 15-17
2011) 1–6
[4] James Biagioni and Tomas Gerlich and Timothy Merrifield and Jakob Eriksson: EasyTracker: Automatic Transit Tracking, Mapping, and Arrival Time Prediction using Smartphones. In: Proceedings
of the 9th ACM Conference on Embedded Networked Sensor Systems. SenSys ’11, ACM (November 1-4 2011) 68–81
[5] Delot, T., Cenerario, N., Ilarri, S., Lecomte, S.:
A cooperative reservation protocol for parking
spaces in vehicular ad hoc networks. In: Proceedings of the 6th International Conference on
Mobile Technology, Application Systems. Mobility ’09, New York, NY, USA, ACM (2009) 30:1–30:8
[6] Ivan Ganchev and Máirtı́n O’Droma and Damien Meere: Intelligent Car Parking Locator Service.
Information Technologies and Knowledge 2 (2008) 166–173
[7] Lu, R., Lin, X., Zhu, H., Shen, X.: Spark: A new vanet-based smart parking scheme for large
parking lots. In: INFOCOM, IEEE (2009) 1413–1421
[8] Vinny Cahill and Aline Senart and Douglas C. Schmidt and Stefan Weber and Anthony Harrington
and Barbara Hughes: The Managed Motorway: Real-time Vehicle Scheduling. HotMobile (February
26-26 2008) 43–47
[9] Nishkam Ravi and Stephen Smaldone and Liviu Iftode and Mario Gerla: Lane Reservation for
Highways (Position Paper). In: Intelligent Transportation Systems Conference, Seattle, WA (Sept.
30-Oct. 3 2007) 795–800
85
[10] Castillo-Manzano, J.I., López-Valpuesta, L.:
Check-in services and passenger behaviour: Self
service technologies in airport systems. Comput. Hum. Behav. 29(6) (November 2013) 2431–2437
[11] Appelt, S., Batta, R., Lin, L., Drury, C.: Simulation of passenger check-in at a medium-sized us
airport. In: Simulation Conference, 2007 Winter. (December 2007) 1252–1260
[12] D. Hardt, E.: The OAuth 2.0 Authorization Framework. Microsoft. (October 2012)
[13] Carvalho, N., Cachopo, J.a., Rodrigues, L., Silva, A.R.: Versioned transactional shared memory
for the fénixedu web application. In: Proceedings of the 2Nd Workshop on Dependable Distributed
Data Management. WDDDM ’08, New York, NY, USA, ACM (2008) 15–18
[14] Pramis, J.: Number of mobile phones to exceed world population by 2014. (February 2013)
[15] IDC:
Idc
worldwide
mobile
phone
tracker.
website
-
website
-
http://www.idc.com/getdoc.jsp?containerId=prUS23946013 (Fevereiro 2013)
[16] IDC:
Idc
worldwide
mobile
phone
tracker.
https://www.idc.com/getdoc.jsp?containerId=prUS24257413 (Agosto 2013)
[17] Knight, K.: Responsive web design: What it is and how to use it. (January 2011)
[18] Jatana, N., Puri, S., Ahuja, M., Kathuria, I., Gosain5, D.: A survey and comparison of relational and
non-relational database. International Journal of Engineering Research and Technology (IJERT) 1
(August 2012)
[19] Janssen, C.: Non-relational database. website - http://www.techopedia.com/definition/25218/nonrelational-database (2013)
[20] Ordonez, C., Song, I.Y., Garcia-Alvarado, C.: Relational versus non-relational database systems for
data warehousing. In: Proceedings of the ACM 13th International Workshop on Data Warehousing
and OLAP. DOLAP ’10, New York, NY, USA, ACM (2010) 67–68
[21] Roe, C.:
Acid vs. base:
The shifting ph of database transaction processing.
web-
site - http://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/
(March 2012)
[22] Trivedi, A.: Mapping relational databases and sql to mongodb. (February 2014)
[23] Novell, Inc. Waltham, MA: NW 6.5 SP8: Novell MySQL Administration Guide. (November 2009)
[24] Nielsen, J.: Response times: The 3 important limits. In: Usability Engineering. Morgan Kaufmann,
San Francisco (1993)
[25] Dimitry: Response times: The 3 important limits. website - http://zurb.com/article/830/responsetimes-the-3-important-limits (November 2011)
86