UNIVERSIDADE FEDERAL DO MARANHÃO

CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS

CURSO DE ESPECIALIZAÇÃO EM ANÁLISE E PROJETO DE SISTEMAS

LEANDRO RIBEIRO RAMOS

VOU DE ÔNIBUS: ARQUITETURA DE SISTEMA DE LOCALIZAÇÃO E

INFORMAÇÕES DE ASSISTÊNCIA AO TRANSPORTE PÚBLICO

São Luís
2015
 LEANDRO RIBEIRO RAMOS

VOU DE ÔNIBUS: ARQUITETURA DE SISTEMA DE LOCALIZAÇÃO E

INFORMAÇÕES DE ASSISTÊNCIA AO TRANSPORTE PÚBLICO

Monografia apresentada ao Curso de

Especialização em Análise e Projeto de
Sistemas da Universidade Federal do
Maranhão como parte dos requisitos
necessários para a obtenção do título de
especialista.

Orientador: Prof. Dr. Geraldo Braz Junior

São Luís
2015
RAMOS, LEANDRO RIBEIRO (SUBSTITUIR ESSE)

Vou de ônibus: Sistema de localização e informações de

assistência ao transporte público / RAMOS, LEANDRO RIBEIRO. –
São Luís, 2015.

74.f.

Impresso por computador (Fotocópia).

Orientador: Geraldo Braz Júnior.

Monografia (Especialização) – Universidade Federal do

Maranhão, Curso de Análise e Projeto de Sistemas, 2015.
 LEANDRO RIBEIRO RAMOS

VOU DE ÔNIBUS: ARQUITETURA DE SISTEMA DE LOCALIZAÇÃO E

INFORMAÇÕES DE ASSISTENCIA AO TRANSPORTE PÚBLICO

Monografia apresentada ao Curso de

Especialização em Análise e Projeto de
Sistemas da Universidade Federal do
Maranhão como parte dos requisitos
necessários para a obtenção do título de
especialista.

Orientador: Prof. Dr. Geraldo Braz Junior

Aprovada em: 09 / 07 / 2015

BANCA EXAMINADORA

_______________________________________________
Profº Dr. Geraldo Braz Junior
Orientador - UFMA

_______________________________________________
Profª Msc. Vandecia Rejane Monteiro Fernandes
1º Examinador - UFMA

________________________________________________
Profº Dr. Carlos de Salles Soares Neto
2º Examinador - UFMA

São Luís
2015
 AGRADECIMENTOS

Agradeço primeiramente a Deus por guiar meus passos e me abençoar mais e

mais a cada dia.
Ao meu orientador que foi de suma importância para o desenvolvimento e
conclusão desse trabalho.
A minha esposa por sempre me apoiar e incentivar meus estudos e minha
carreira profissional. E principalmente, por acreditar no meu potencial e me fazer
acreditar também.
Ao meu filho, pelo carinho, amor, alegria e por me deixar estudar nas horas
necessárias.
A minha mãe que sempre, me informou as oportunidades, que em alguns
momentos até insistiu para que eu estudasse e que até hoje se preocupa com meus
estudos.
E finalmente, ao meu pai que financiou meu curso, e apesar de não está
constantemente presente, sempre estendeu a mão para ajudar quando precisei.
“Seu trabalho vai ocupar uma grande parte
da sua vida. A única maneira de estar
verdadeiramente satisfeito é fazendo aquilo
que você acredita ser um ótimo trabalho. E
o único jeito de fazer um ótimo trabalho é
fazendo aquilo que você ama.”

Steve Jobs
 RESUMO

Um dos direitos fundamentais do cidadão é o de ir e vir. Para ajudar nesse

processo, existe o sistema de transporte público de cada cidade, que disponibiliza
ônibus e outros meios de transporte para ajudar a população nesse aspecto. No entanto,
o serviço de transporte público, em várias cidades, deixa muito a desejar. São
disponibilizados poucos ônibus, que em conjunto com o trânsito caótico das cidades faz
com que as pessoas esperem indefinidamente pelo seu transporte. Além disso, são
fornecidas poucas informações sobre as rotas, horários, paradas dos ônibus e outros
fatores que interessam a população.
A necessidade de informação vinculada a novas tecnologias, como por exemplo,
o GPS, smartphones com internet móvel e capacidade de usar vários aplicativos, faz
com que seja possível dar à população um sistema que seja portátil, fácil de utilizar e
que supra a necessidade do usuário do transporte público de obter informação para
otimizar o seu tempo e tomar as melhores decisões na utilização desse transporte.
Este trabalho apresenta um projeto de sistema para esse fim. Mostrando todas as
etapas do processo desde a análise de requisitos, casos de uso, passando pela estrutura
interna do sistema, banco de dados e por fim os protótipos de interface com o usuário.

PALAVRAS-CHAVE: Transporte público, Ônibus, GPS, Aplicativo, Google Maps.

 ABSTRACT

One of the fundamental rights of the citizen is of go and come. To help in this
process, there is the public transport system in each city, that provides bus and other
means of transport to help people in this regard. However, the public transport service
in several cities leaves much to be desired. Few buses available, which together with the
chaotic city traffic causes people to wait indefinitely for their transportation. Moreover,
are provided little information on routes, schedules, the bus stops and other factors
which affect the population.
The need for information linked to new technologies, such as GPS, smartphones
with mobile internet and the ability to use multiple applications, makes it possible to
give the population a system that is portable, easy to use and that meets the user's needs
public transport to get information to optimize your time and make the best decisions on
the use of such transport.
This paper presents a system design for this purpose. Showing all stages of the
process from requirements analysis, use cases, through the system of internal structure,
database and finally the user interface prototypes.

KEYWORDS: Public transportation, Bus, GPS application, Google Maps.

 LISTA DE FIGURAS

Figura 1 - Exemplo de funcionamento do Google Transit ............................................. 14

Figura 2 - Exemplo de telas do Meu Busão no android. Fonte: site oficial do software 16
Figura 3 - Exemplo de telas do aplicativo Moovit. Fonte: site oficial do software........ 17
Figura 4 - Exemplo de telas do aplicativo Cadê o Ônibus? Fonte: site oficial do software
........................................................................................................................................ 18
Figura 5 - Exemplo de sistema de informação geográfica ............................................. 21
Figura 6 - Diagrama de caso de uso geral ...................................................................... 26
Figura 7 - Caso de uso do módulo gerencial .................................................................. 27
Figura 8 - Caso de uso módulo do ônibus ...................................................................... 29
Figura 9 - Caso de uso módulo do usuário ..................................................................... 30
Figura 10 - Arquitetura de software ............................................................................... 32
Figura 11 - Diagrama de classes ..................................................................................... 33
Figura 12 - Diagrama de pacotes da visão geral do sistema ........................................... 35
Figura 13 - Diagrama de pacotes do módulo gerencial .................................................. 36
Figura 14 - Diagrama de pacotes do módulo do ônibus ................................................. 38
Figura 15 - Diagrama de pacotes do módulo do usuário ................................................ 39
Figura 16 - Diagrama de sequência monitorar viagem................................................... 41
Figura 17 - Diagrama de sequência exibir rota............................................................... 42
Figura 18 - Diagrama de sequência buscar pelo destino ................................................ 42
Figura 19 - Diagrama de estado localização ................................................................... 43
Figura 20 - Modelo físico de dados ................................................................................ 45
Figura 21 - Interface do Balsamiq Mockups. Fonte: site oficial do software ................ 49
Figura 22 - Tela de login do módulo gerencial .............................................................. 51
Figura 23 - Tela inicial do módulo gerencial ................................................................. 51
Figura 24 - Tela de gerenciamento de linhas do módulo gerencial ................................ 52
Figura 25 - Tela de gerenciamento de horários do módulo gerencial ............................ 53
Figura 26 - Tela de gerenciamento de rotas do módulo gerencial.................................. 54
Figura 27 - Tela de relatórios de viagens do módulo gerencial...................................... 55
Figura 28 - Tela de gerenciamento de perfil de usuário do módulo gerencial ............... 56
Figura 29 - Tela de gerenciamento de usuários do módulo gerencial ............................ 57
Figura 30 - Tela de gerenciamento de empresas do módulo gerencial .......................... 58
Figura 31 - Tela de gerenciamento de paradas do módulo gerencial ............................. 59
Figura 32 - Exemplo de cadastro de parada do módulo gerencial .................................. 59
Figura 33 - Tela de login do aplicativo do módulo do ônibus ........................................ 60
Figura 34 - Tela inicial do aplicativo do módulo do ônibus ........................................... 61
Figura 35 - Tela monitorar viagem do módulo do ônibus .............................................. 62
Figura 36 - Tela finalizar viagem do módulo do ônibus ................................................ 63
Figura 37 - Tela de relatório diário do módulo do ônibus .............................................. 64
Figura 38 - Tela inicial do aplicativo do módulo do usuário.......................................... 65
Figura 39 - Tela de informações do aplicativo do módulo do usuário ........................... 66
Figura 40 - Tela de rotas do aplicativo do módulo do usuário ....................................... 67
Figura 41 - Tela de Pesquisa do aplicativo do módulo do usuário ................................. 68
Figura 42 - Tela de resultado da pesquisa do aplicativo do módulo do usuário ............ 69
Figura 43 - Tela como usar do aplicativo do módulo do usuário ................................... 70
 SUMÁRIO

1 INTRODUÇÃO ...................................................................................................... 12
1.1 Objetivos ......................................................................................................... 13
2 TRABALHOS RELACIONADOS ......................................................................... 14
2.1 Google Transit ................................................................................................ 14
2.2 Meu Busão (Palmas – TO) ............................................................................ 15
2.3 Moovit ............................................................................................................. 17
2.4 Cade o Onibus? (SP) ...................................................................................... 18
2.5 Comparação dos Relacionados com a Proposta deste Trabalho ............... 19
3 PROPOSTA ............................................................................................................ 20
3.1 Turismo X SIG ............................................................................................... 21
3.2 Requisitos ........................................................................................................ 22
3.2.1 Requisitos Funcionais .................................................................................. 23
3.2.1.1 Módulo do ônibus ..................................................................................... 23
3.2.1.2 Módulo de usuário .................................................................................... 24
3.2.1.3 Módulo gerencial ...................................................................................... 25
3.2.2 Requisitos Não Funcionais ........................................................................... 25
3.3 Casos de Uso ................................................................................................... 26
3.4 Arquitetura Básica ......................................................................................... 31
3.5 Diagrama de Pacotes ..................................................................................... 34
3.6 Modelagem Dinâmica .................................................................................... 40
3.7 Banco de Dados .............................................................................................. 44
4 PROTÓTIPO ........................................................................................................... 48
4.1 Prototipação de interfaces com o usuário .................................................... 49
4.1.1 Protótipos do Módulo Gerencial .................................................................. 50
4.1.2 Protótipos do Módulo do Ônibus ................................................................. 60
4.1.3 Protótipos do Módulo do Usuário ................................................................ 64
5 CONCLUSÃO ........................................................................................................ 71
6 REFERÊNCIAS ...................................................................................................... 73
1 INTRODUÇÃO

No mundo em que vivemos hoje, o tempo se torna cada vez mais um recurso
extremamente escasso para cada uma das pessoas. Dessa maneira, somos forçados a
procurar otimizar o tempo gasto em atividades, cotidianas ou não, para que esse recurso
escasso não seja desperdiçado de forma desnecessária.
Um dos momentos em que mais se perde tempo de forma inútil é quando
ficamos em uma parada esperando um ônibus, para ir ao trabalho, para casa ou um
passeio. Em alguns casos passa-se mais tempo esperando um ônibus, do que a próprio
percurso que se vai fazer dentro do ônibus.
Quem já precisou usar transporte público em uma cidade grande, a qual não
conhece, admite que é fácil errar o caminho e se perder ou gastar um tempo ainda maior
para chegar ao local desejado. Isso acontece, dentre outros fatores, em especial em São
Luís, devido à falta de informação sobre as linhas, rotas e dos horários de viagem dos
ônibus, que não são repassados, de forma efetiva, aos usuários de ônibus, a falta de uma
fiscalização mais rígida para obrigar o cumprimento correto das viagens nos horários
certos e principalmente, pelo usuário não dispor de uma ferramenta para saber qual a
localização do ônibus na cidade, obrigando-o a esperar indefinidamente pelo seu
transporte.
Por esses motivos o desenvolvimento de um software, que auxilie o usuário do
transporte público a organizar melhor seu tempo para fazer seus percursos de ônibus e
ter todas as informações referentes aos ônibus, bem como a sua localização em tempo
real, é de suma importância para a população.
O sistema proposto, uni a comodidade do uso do smartphone, que possui
diversos sensores e recursos como internet móvel, GPS, dentre outros, que é uma
presença constante em nosso dia-a-dia, com a necessidade das pessoas de mais
informação. Ajudando desde aqueles que querem apenas saber qual o horário dos
ônibus de uma linha qualquer, em um dia específico da semana, para programar a sua
saída de casa e dirigir-se à parada no tempo certo, como também aqueles precisam
chegar a algum lugar da cidade, mas não têm nem ideia qual ônibus pegar, tão pouco
como chegar ao local de destino.

12
1.1 Objetivos

Para melhor entendimento da proposta desse trabalho, o sistema foi

fundamentado com base no objetivo geral de:
 Permitir que o usuário em qualquer ponto da cidade consulte um destino e o
sistema retorne qual a parada mais próxima a ele, as opções de ônibus, com
suas respectivas localizações atuais, que pode utilizar para chegar ao local
escolhido, e o ponto de desembarque. Tudo isso referenciado no mapa.
E nos objetivos específicos:
 Informar ao usuário diário de ônibus os horários e localização dos ônibus em
tempo real. Bem como, expor as linhas e rotas da frota de ônibus atual da
cidade;
 Ajudar os turistas a utilizar o transporte público da cidade para chegar aos
destinos pretendidos;
 Ajudar o poder público na fiscalização do cumprimento dos horários dos
ônibus.

13
2 TRABALHOS RELACIONADOS

Ao fazer uma busca por esse tipo de ferramenta é fácil encontrar na internet
iniciativas para melhorar a vida do cidadão na utilização do transporte público. No
período de levantamento de requisitos, foram analisados vários trabalhos similares e
selecionados alguns softwares para apresentação e comparação com o sistema proposto.
Sendo eles: Google Transit, Meu Busão (Palmas – TO), Moovit e Cadê o Onibus?.

2.1 Google Transit

O Google Transit, de acordo com o site oficial1, foi lançado em dezembro de

2005. Em junho de 2006, a ferramenta de planejamento de viagens em transporte
público, tornou-se parte do Google Maps e Google Earth, sendo recentemente lançado
no Google Maps para dispositivos móveis. Esta ferramenta está presente em mais de 12
países, incluindo o Brasil. Conforme apresentado na Figura 1, Brasília é um dos locais
que já possui o sistema em pleno funcionamento.

Figura 1 - Exemplo de funcionamento do Google Transit

1
http://maps.google.com.br/intl/pt-BR/help/maps/mapcontent/transit/faq.html
14
 “O Google Transit no Google Maps é uma ferramenta de planejamento para
transporte público que combina os dados mais recentes da agência com o
alcance do Google Maps. Ele integra paradas, trajetos, grades de horários e
informações sobre tarifas de transporte público para facilitar e agilizar o
planejamento de viagens.” (GOOGLE, 2015)

Para participar as agências de transporte público, de forma gratuita, fazem a

inscrição e adesão do contrato de parceria. Para que após o envio, teste e validação das
informações sobre os horários, paradas, rotas dos ônibus e outras informações
solicitadas, o sistema possa finalmente ser acessado pela população. O que garante
maior confiabilidade das informações visualizadas.

2.2 Meu Busão (Palmas – TO)

No Brasil, especificamente, na cidade de Palmas - TO, foi desenvolvido um

aplicativo denominado “Meu Busão (Palmas – TO)”. Segundo o site oficial2, o sistema
desenvolvido e mantido pela empresa Sidigital, trabalha em parceria com a Secretaria
Municipal de Acessibilidade, Mobilidade, Trânsito e Transporte da cidade, que
disponibiliza todas as informações de horários e itinerários para o aplicativo da
empresa. Esse aplicativo está disponível no Google Play para download na plataforma
Android e possui também a versão Web, disponível para outras plataformas. Tais como:
iOS, Windows Phone e Desktop, que poderão ter acesso às informações sobre horários e
rotas das linhas. A Figura 2 representa exemplos de telas do aplicativo no Android.

2
http://www.meubusao.com.br/
15
 Figura 2 - Exemplo de telas do Meu Busão no android. Fonte: site oficial do software

De acordo com o site oficial, o sistema possui as seguintes funcionalidades:

 Todas as linhas do sistema de transporte coletivo em Palmas estão
cadastradas e sempre atualizadas. Por meio de uma linha é possível ter
acesso aos horários, rota e, por meio da colaboração dos usuários, é
possível fazer visualização da localização do ônibus em tempo real, além
de adicionar a linha aos seus favoritos.
 Os horários, obtidos diretamente pelo órgão regulador do sistema de
transporte, estão sempre atualizados e são exibidos divididos por dia para
cada linha selecionada.
 Ao programar um alerta, o aplicativo te avisa quando o ônibus estiver
próximo.
 Com o aplicativo web tanto desktops quanto dispositivos móveis poderão
acessar.

16
2.3 Moovit

O Moovit é um aplicativo disponível gratuitamente paras smartphones das

plataformas IOS, Android e Windows. Que segundo o site oficial do software3, os
usuários tem a opção de compartilhar informações sobre: atraso dos ônibus, a situação
de lotação, a posição atual do ônibus em que está embarcado, através do GPS de seu
smartphone, etc. O aplicativo também permite que o usuário possa procurar um lugar,
endereço ou estação e comparar as opções de transporte público disponíveis, para que os
passageiros consigam planejar suas viagens, combinando ônibus, metrô e trem, e
navegar para seus destinos com instruções detalhadas de todo o caminho até destino
desejado. Outro recurso interessante é a possibilidade de adicionar locais de busca como
favoritos, para ser utilizado no planejamento de viagens futuras. Na Figura 3 são
apresentados exemplos de algumas telas do sistema.

Figura 3 - Exemplo de telas do aplicativo Moovit. Fonte: site oficial do software

3
http://moovitapp.com/pt-br/
17
2.4 Cade o Onibus? (SP)

Desenvolvido pela empresa Nano IT, o aplicativo “Cadê o Ônibus?” (ver Figura
4), segundo um site oficial4, está disponível para a plataforma Android desde 2012, para
IOS e Windows desde 2014, e possui as seguintes funcionalidades:
 Posição geográfica dos ônibus em tempo real. Todos os ônibus possuem
um GPS que envia informações a SPTrans (São Paulo Transporte) de
tempos em tempos. O aplicativo acessa os dados da SPTrans e EMTU
(Empresa Metropolitana de Transportes Urbanos de São Paulo) e exibe o
resultado em seu celular.
 Informa os pontos de ônibus próximos, itinerário das linhas e horário de
partida dos ônibus.
 Monitora as condições do Trânsito, mostrando, nos dois sentidos, a
velocidade e o tempo percorrido em um determinado local.
 Administração das suas linhas "favoritas", para ver mais rapidamente a
posição dos ônibus no mapa (além do trajeto da linha) ou o itinerário que
eles percorrem.
 O aplicativo informa se o ônibus possui ou não suporte para cadeirantes.

Figura 4 - Exemplo de telas do aplicativo Cadê o Ônibus? Fonte: site oficial do software

4
http://www.cadeoonibus.com.br/
18
2.5 Comparação dos Relacionados com a Proposta deste Trabalho

O sistema proposto traz muitas funcionalidades presentes em alguns dos

aplicativos analisados, tais como: informações dos horários de saída dos ônibus,
itinerários, rotas das linhas exibidas no mapa, monitoramento em tempo real dos ônibus,
dentre outras funções. No que se refere às funções mais básicas, porém essenciais para
funcionamento do sistema, foram analisadas nesse projeto com o intuito de melhorar o
modo como esses recursos são disponibilizados e exibidos ao usuário. Facilitando o seu
uso e dispor ao usuário uma boa experiência de utilização do aplicativo, tendo em vista
diminuir ao máximo o tempo gasto em cada operação do sistema.
Alguns aplicativos similares utilizam-se da colaboração dos usuários para
informar a posição atual do ônibus através do GPS. Porém, tal procedimento deixa
muito a desejar em relação à confiabilidade. Visto que, o ônibus não é acompanhado, na
maioria dos casos, em todo o trajeto de sua rota e/ou pode acontecer que pessoas mal
intencionadas passem informações incorretas para os outros usuários do aplicativo. Para
contornar essa situação, considerando que a cidade não dispõe até o presente momento
de ônibus equipados com GPS, o sistema contará com um módulo do sistema, acessado
por um smartphone, que indica o posicionamento real de cada um dos ônibus da frota, e
que será acionado somente pelo cobrador do ônibus em suas viagens, garantindo maior
confiabilidade nas informações do sistema.
Outra diferença importante é que o sistema possui seu próprio módulo de
gerenciamento de dados, que, ao contrário da maioria dos aplicativos analisados, o
deixa independente de informações repassadas por terceiros. Pois o sistema é projetado
para ser utilizado pelas empresas de transporte público em conjunto com os órgãos
reguladores do setor. Favorecendo assim todas as partes envolvidas com o transporte
público e em especial a população.

19
3 PROPOSTA

Com o intuito de auxiliar os usuários de ônibus a utilizarem esse transporte de

forma mais efetiva, este sistema, denominado “Vou de Ônibus”, tem como finalidade
prover uma ferramenta para monitoramento em tempo real dos ônibus que circulam na
cidade, exibir suas rotas no mapa, identificar cada parada da cidade e as linhas que
param em cada uma delas. Assim como outras informações referentes ao funcionamento
do sistema de transporte público da cidade.
Para atingir essa solução, a ferramenta é divida em três módulos distintos:
módulo gerencial, módulo do ônibus e módulo do usuário, onde cada módulo tem um
grupo de usuários distintos.
O primeiro módulo denominado módulo gerencial, tem a função de gerir os
cadastros e informações pertinentes à frota de ônibus, como, por exemplo: nome das
linhas, horário de saída, mapeamento das paradas (pontos de ônibus) e rotas das linhas,
dentre outras informações.
O segundo módulo conhecido como módulo do ônibus, é responsável por dispor
a localização dos ônibus em cada viagem, através do dispositivo GPS do smartphone,
que faz o acesso ao sistema. Esse smartphone fica em posse do cobrador de cada ônibus
que inicia uma viagem, sendo ele responsável por informar a linha e o horário de saída
que será cumprido no momento.
Por último o módulo do usuário, que será utilizado pelo usuário final, formado
pelas pessoas dependentes do transporte público, que através desse módulo, acessível
por qualquer dispositivo com acesso a internet com um navegador compatível com
Google Maps ou baixando o aplicativo para plataforma Android que será
disponibilizado na Google Play, poderá visualizar as informações disponibilizadas pelos
dois módulos anteriores, tais como: o monitoramento da localização atual dos ônibus, as
paradas, os horários, rotas e itinerários das linhas.
A identificação e coleta de dados geográficos, a busca por destinos e a definição
da melhor rota será realizado através de um Sistema de Informação Geográfica.
Trazendo benefícios, não só para os habitantes locais, como também, para os turistas.

20
3.1 Turismo X SIG

A cidade de São Luís com suas festas tradicionais, praias, centro histórico,
dentre outros lugares, todos os anos recebe diversos turistas dos mais diversos lugares
para conhecer ou visitar novamente a cidade. Sendo que muitos deles utilizam o
transporte público para se locomover pela cidade. Entretanto, a cidade não dispõe de
nenhum informativo sobre os horários dos ônibus, linhas disponíveis e rotas nos pontos
de ônibus em qualquer outra parte.
Visando proporcionar uma melhor experiência na utilização desse transporte e
facilitar a vida dos turistas e dos usuários da cidade, o sistema “Vou de Ônibus” visa
informatizar o processo de comunicação entre os usuários e os serviços prestados pelas
empresas de transporte público através de uma proposta de Sistema de Informação
Geográfica (SIG). Que, segundo Câmara & Queiroz (2001, p. 3-1), é o termo “aplicado
para sistemas que realizam o tratamento computacional de dados geográficos e
recuperam informações não apenas com base em suas características alfanuméricas, mas
também através de sua localização espacial”. O SIG é usado para identificar e coletar
informações sobre pontos específicos no mapa, realizando buscas de destinos para o
qual o usuário do sistema deseja ir, definir melhor rota entre dois pontos e até mesmo
calcular a distância e o tempo estimado de chegada de um ônibus a um ponto
selecionado. A Figura 5 apresenta exemplos de um sistema de informação geográfica.

Figura 5 - Exemplo de sistema de informação geográfica

21
 Em resumo, com o uso do SIG é possível identificar e dar informações
detalhadas de uma infinidade de locais em um mapa digital que possa utilizar esses
recursos. Como é o caso do Google Maps, é um servidor de mapas que possui sua
própria API (Application Programming Interface) pública para manipulação dos
elementos que trabalham em conjunto com o mapa. A API do Google Maps possui uma
vasta documentação e pode ser utilizada em qualquer software ou site de forma gratuita,
de acordo com as regras que constam na documentação oficial em seu site5.
Com base nesses recursos, o turista tem a facilidade de, ao chegar à cidade,
poder visitar qualquer lugar dentre os pontos turísticos mapeados, visualizando os
horários das linhas e as melhores rotas para fazer de acordo com a sua localização atual
passada pelo GPS do usuário para o sistema.

3.2 Requisitos

O levantamento e análise de requisitos provê o mecanismo apropriado para

entender aquilo que o cliente deseja, analisando a viabilidade, buscando e especificando
soluções práticas para os problemas encontrados e principalmente definindo um ponto
de partida para o desenvolvimento do sistema.
Segundo Sommerville (2007, p.79), “Os requisitos de um sistema são descrições
dos serviços fornecidos pelo sistema e as suas restrições operacionais. Esses requisitos
refletem as necessidades dos clientes de um sistema que ajuda a resolver algum
problema”.

“As etapas de levantamento e análise de requisitos trabalham com o domínio

do problema e tentam determinar „o que‟ o software deve fazer e se é
realmente possível desenvolver o software solicitado. Na etapa de
levantamento de requisitos, o engenheiro de software busca compreender as
necessidades do usuário e o que ele deseja que o sistema a ser desenvolvido
realize. Isso é feito, sobretudo por meio de entrevistas, nas quais o
engenheiro tenta compreender como funciona atualmente o processo a ser
informatizado e quais serviços o cliente precisa que o software forneça”
(GUEDES, 2011, p. 22)

5
https://developers.google.com/maps/
22
 Ao tratar sobre requisitos de sistemas de softwares, os autores da área de
engenharia de software e afins, normalmente, classificam os requisitos em funcionais e
não funcionais. Tais requisitos são demonstrados a seguir com base no que foi analisado
para esse sistema.

3.2.1 Requisitos Funcionais

Os requisitos funcionais estão divididos por módulos, para deixar bem claro o
que se deseja especificamente em cada um deles.

3.2.1.1 Módulo do ônibus

No módulo do ônibus, responsável por provê a localização dos ônibus em tempo

real e controle dos horários das viagens realizadas, deve existir uma tela de login que
tem a função de gerenciar o acesso ao sistema através de um login e senha, previamente
cadastrado no módulo gerencial, que identifica a qual empresa esse usuário pertence.
Com isso, o sistema exibe apenas as informações referentes à mesma.
Ao iniciar uma viagem, o sistema ativa o GPS do smartphone, inicia a contagem
do tempo de viagem, exibe informações de tempo de viagem estimado, horário de início
e itinerário da linha selecionada. Ao finalizar a viagem o usuário tem a opção de relatar
um problema ocorrido durante o percurso do ônibus caso tenha acontecido um.
O usuário também pode a qualquer momento visualizar o relatório diário de
viagens, que exibe todas as informações coletadas no dia da linha que for selecionada
pelo usuário dentro da mesma empresa.

23
3.2.1.2 Módulo de usuário

Neste módulo, encarregado por disponibilizar o acesso aos dados dos outros
módulos do sistema ao usuário de ônibus, não há necessidade de login e senha para
acessa-lo. Ou seja, qualquer pessoa tem acesso direto às funcionalidades do sistema
presentes neste módulo.
O módulo deve permitir ao usuário a visualização das informações sobre as
linhas de ônibus com seus respectivos horários de saída de cada viagem de qualquer dia
da semana, quantidade de ônibus em circulação no momento, itinerário e rota no mapa
da linha selecionada, bem como a última data de atualização dessas informações.
Através dos filtros de pesquisa por linha ou destino, que por destino entende-se
como: um bairro, um ponto turístico ou outro ponto de interesse como, por exemplo,
CEUMA, Tropical Shopping, dentre outros, o aplicativo ou página web, com a ajuda do
GPS do usuário, informa qual a parada mais próxima dele para pegar o ônibus, as
opções de linhas para o destino selecionado, em qual parada ele deve descer e a
localização atual de cada ônibus das linhas que aparecer no resultado da pesquisa
exibindo cada um com a cor que foi informada em seu cadastro no módulo gerencial.
Limitando a pesquisa a um numero x de resultados para não sobrecarregar o sistema.
Ao escolher uma das linhas do resultado da busca, a sua rota é exibida no mapa e
o usuário também tem a opção de comparar duas rotas ao mesmo tempo, para ajudá-lo a
tomar a decisão de qual linha pegar.
Caso o usuário clique em uma parada do mapa o sistema exibe todas as linhas
que param naquela parada. Ao clicar em um ônibus no mapa o sistema exibe o número,
nome da linha, tempo estimado de chegada até o ponto selecionado no mapa e também a
ultima hora da atualização recebida no sistema daquele ônibus em circulação.
Caso o usuário tenha dúvidas de como utilizar o sistema, haverá um tutorial
explicando passo-a-passo todas as funcionalidades existentes neste módulo, de forma
simples e objetiva.

24
3.2.1.3 Módulo gerencial

Por fim o módulo gerencial, que é responsável por gerenciar informações e

dados de acesso aos módulos. Ele é o único que possui dois níveis de acesso ao sistema.
O primeiro como usuário do tipo funcionário, incumbido de cadastrar, editar e apagar as
informações básicas contidas no sistema. O segundo como administrador do sistema,
que controla e gerencia o sistema com um todo, sendo apenas o usuário administrador
capaz de cadastrar e gerir os pontos de parada no mapa, gerenciar todos os outros
usuários do sistema e cadastrar novas empresas no sistema.
O usuário funcionário deve gerenciar o cadastro das linhas de sua empresa, suas
rotas no mapa, horários de saída dos ônibus em cada dia da semana, gerenciar usuário
do módulo do ônibus de sua empresa e atualizar o seu próprio perfil de acesso ao
sistema.
O sistema também permite que ambos os usuários visualizem os relatórios de
viagem de qualquer linha. O relatório contém todas as informações repassadas do
módulo do ônibus durante cada viagem realizada.

3.2.2 Requisitos Não Funcionais

Visando uma melhor usabilidade, o sistema deve prover uma interface amigável,
intuitiva e multiplataforma nos módulos de ônibus e de usuário, fator primordial para o
sucesso do sistema. Em especial no módulo de usuário, já que este não dispõe de
treinamento pessoal para uso do sistema. Entretanto, ele dispõe de um tutorial para tirar
as dúvidas do usuário.
Outro fator que deve ser observado é o desempenho do sistema que na maior
parte do tempo, será usado através de conexões móveis com a internet e justamente por
isso, o fator desempenho é essencial uma vez que o mesmo atuará com conexões de
baixa qualidade e um volume elevado de acesso ao sistema.
Com o intuito de dispor de um produto de alta flexibilidade e reusabilidade, será
adotada a linguagem Java, utilizando-se da orientação a objetos e do uso do framework

25
JSF para acesso via web e banco de dados SQL Server 2008 para prover maior
segurança no armazenamento das informações relativas ao sistema.
É primordial também que o sistema possua um layout responsivo, ou seja, uma
interface que se adapte de acordo com o dispositivo que está acessando o sistema. Para
garantir com isso o acesso de qualquer dispositivo que possua browser e acesso à
internet, maior flexibilidade e maior quantidade de pessoas com possibilidade de acessar
o sistema.

3.3 Casos de Uso

Com base no que foi relatado na análise de requisitos, foi concluído que os casos
de uso partiriam da seguinte estrutura, conforme demonstrado na Figura 6:

Figura 6 - Diagrama de caso de uso geral

O sistema possui quatro de tipos de usuários. Cada um com um papel distinto

dentro do mesmo. Como visto anteriormente, o sistema se divide em três módulos,
dessa maneira cada tipo de usuário tem acesso a apenas um módulo do sistema e essa
separação é dada de acordo com os casos de uso específicos de cada módulo expostos a
seguir:

26
 Figura 7 - Caso de uso do módulo gerencial

No módulo gerencial, apenas dois usuários têm acesso. Sendo que para acessar
qualquer recurso do sistema o usuário obrigatoriamente precisa realizar o login no
sistema, como apresentado na Figura 7. Outro fato importante é que o usuário
administrador pode acessar todas as funcionalidades acessíveis ao usuário funcionário e
mais três recursos extra, que são recursos de gerenciamento de acesso aos módulos do
sistema e outro de uso comum a todas as empresas. Isso ocorre para que seja mantida a
confiabilidade das informações contidas no sistema. Esses e todos os casos de uso serão
explicados de forma detalhada.
O caso de uso Gerenciar Linhas tem como finalidade gerenciar as linhas de cada
empresa, permitindo que o usuário visualize e pesquise as linhas cadastradas, insera,
atualize e exclua registros de uma linha. Cada linha possui um prefixo, composto por
uma letra, um número distinto e um nome único que a identifica. Além disso, deve ser
informada também no ato do cadastro uma cor que representa a linha, escolhida dentre
as disponíveis no sistema, e, opcionalmente, o tempo estimado de viagem.
O caso de uso Gerenciar Perfil permite que o usuário logado possa visualizar
suas informações de cadastro e alterar sua senha de acesso e também a senha de acesso
do usuário cobrador do módulo do ônibus vinculado a sua empresa.

27
 No caso de uso Gerenciar Horário é possível visualizar, inserir, atualizar e
excluir os horários de saída dos ônibus das linhas de sua empresa em cada dia da
semana. Necessitando apenas que a linha já esteja cadastrada previamente no sistema.
No ato do cadastro é possível também definir um horário inicial e final com um
intervalo em minutos entre uma viagem e outra, para inserir vários horários ao mesmo
tempo em todos os dias da semana que forem selecionados pelo usuário.
No caso de uso Visualizar Relatórios, o objetivo é monitorar as viagens
realizadas pelos ônibus de sua empresa, exibindo todas as informações repassadas pelo
módulo do ônibus em cada viagem ocorrida.
O caso de uso Gerenciar Rotas permite que o usuário visualize e atualize a rota
de cada linha cadastrada para sua empresa. Com o auxílio do Google Maps o usuário,
com poucos cliques, informa cada parada que a linha selecionada possui ponto de
embarque adicionando de forma ordenada a lista de paradas que compõem essa rota e
em seguida, basta salvar as alterações realizadas.
No Caso de uso Gerenciar Paradas, apenas o usuário administrador tem acesso.
E este é responsável por cadastrar e gerenciar cada parada da cidade, que serão
utilizadas para compor as rotas das linhas. Outra função importante é a possibilidade de
inserir POI (pontos de interesse) para cada parada. POI são pontos de referencias
turísticos, lugares famosos da cidade, dentre outros pontos que são de interesse de todos
e conhecimento de todos. Esses POI serão cadastrados previamente em banco de dados
e apenas adicionados a uma ou mais paradas. Servindo como base para o caso de uso
Fazer Pesquisa do módulo do usuário que é explicado mais adiante.
No Caso de uso Gerenciar Usuários, que também é acessado somente pelo
usuário administrador é possível gerenciar todos os usuários do sistema, de todos os
módulos.
O Caso de uso Gerenciar Empresas tem a finalidade de inserir, atualizar e
excluir as empresas no sistema. O cadastro da empresa possui apenas os registros de
nome fantasia e razão social da empresa.
E por fim há o Caso de uso Realizar Login que é a operação para autenticar o
usuário no sistema e é requisito obrigatório para acessar qualquer outro caso de uso
desse módulo.

28
 Figura 8 - Caso de uso módulo do ônibus

Com apenas quatro casos de uso, conforme mostrado na Figura 8, o módulo do

ônibus possui um funcionamento simples, porém indispensável ao funcionamento do
sistema.
Com apenas um tipo de usuário com acesso a esse módulo, O caso de uso
Realizar Login é responsável por validar o login e senha dos usuários para dar acesso a
qualquer funcionalidade desse módulo.
O caso de uso Monitorar Viagem, que é o principal recurso desse módulo,
permite que o usuário selecione uma linha, um horário de saída a ser realizado e inicie a
sua viagem, que com a ajuda do gps do smartphone irá fornecer a localização do ônibus
e outras informações sobre essa viagem para ser utilizado no módulo do usuário.
O caso de uso Finalizar Viagem que só pode ser acessado ao iniciar o caso de
uso Monitorar viagem tem a função de encerrar o monitoramento da viagem e parar de
transmitir os dados de localização. Sendo que ao finalizar a viagem o usuário tem a
opção de informar um problema que tenha ocorrido na viagem, fato que ficará
registrado no sistema e poderá ser visualizado posteriormente.
No caso de uso Exibir Relatório que é exibido logo após finalizar a viagem ou
acessado diretamente pelo usuário na tela inicial desse módulo, assim como no módulo
gerencial, tem a função de exibir as informações obtidas nas viagens. Porém, neste
módulo será exibido apenas o histórico diário da linha selecionada pelo usuário.

29
 Figura 9 - Caso de uso módulo do usuário

Com o acesso direto ao sistema, sem a necessidade de fazer login, neste módulo o
usuário tem como opções iniciais: Obter informações, obter ajuda e fazer pesquisa. Elas
são explicadas a seguir, juntamente, com seus casos de uso secundários conforme
exibidos na Figura 9.
O caso de uso Obter Informações oferece ao usuário a possibilidade de se
informar sobre os horários de saída de cada linha em cada dia da semana, visualizar seus
itinerários e a quantidade de ônibus circulando no momento, da linha selecionada.
No caso de uso Exibir Rota, que pode ser acessado através do caso de uso Obter
Informações, o usuário tem a possibilidade de visualizar a rota no mapa da linha
selecionada. Tendo a opção de, na mesma tela, escolher outra linha para visualizar a
rota, sem a necessidade de retornar a tela anterior.
O caso de uso Obter Ajuda serve para auxiliar o usuário a entender o
funcionamento do sistema e como utiliza-lo de maneira correta, provendo um tutorial
passo-a-posso exemplificando os recursos e funcionalidades do sistema.
Já o caso de uso Fazer Pesquisa oferece ao usuário à possibilidade de optar entre
pesquisar por linhas específicas, onde o usuário digita o nome parcial ou número da
linha que deseja buscar, ou a opção de buscar um destino, que ao digitar uma palavra ou
frase qualquer, o sistema busca em seu banco de dados de Pontos de Interesse (POI) um
possível resultado e ao encontrar, exibe no mapa a parada em que o usuário deve descer
para chegar ao destino marcado.
Em ambos os casos é exibido também como resultado a localização atual do
usuário, a parada mais próxima dele as linhas que foram encontradas como resultado,
que no caso da busca por destino, são aquelas que tem rotas que passam entre as paradas

30
próximas ao usuário e nas paradas próximas ao destino selecionado, e cada um dos
ônibus que estão em circulação no momento que fazem parte do resultado da busca. O
sistema também exibe no mapa a rota da primeira linha mostrada como resultado da
pesquisa.
O caso de uso Comparar Rota é uma opção acessível no resultado da Pesquisa do
caso de uso Fazer Pesquisa, que permite comparar duas rotas ao mesmo tempo no mapa
para que o usuário possa tomar a decisão de qual rota seguir.
Outra opção acessada através do caso de uso Fazer Pesquisa é o caso de uso
Exibir Estatística que ao selecionar qualquer parada no mapa, permite visualizar todas
as linhas que param naquela parada. E ao selecionar um dos ônibus em circulação
marcados no mapa, exibe o nome, número da linha, hora da ultima atualização da
localização do ônibus e o tempo estimado de chegada até à parada selecionada no mapa,
conforme descrito nos requisitos funcionais desse módulo.
Com base na descrição dos diagramas de casos de uso do sistema o projeto
começa a tomar forma e já é possível visualizar e projetar a arquitetura básica do
sistema.

3.4 Arquitetura Básica

O funcionamento do sistema como um todo, pode ser explicado com base na

Figura 10, que mostra a comunicação entre os módulos e o servidor de aplicação que
interagem exclusivamente através da internet.

31
 Figura 10 - Arquitetura de software

Com a exceção do módulo gerencial, todos os módulos podem acessar o sistema

de duas maneiras: através de um navegador web partindo o acesso de um computador,
tablet ou smartphone, ou através da instalação do aplicativo Android desse sistema que
será disponibilizado para download na Google Play6 e no site oficial do sistema. Apenas
o módulo gerencial não contará com versão do aplicativo.
As tecnologias utilizadas na implantação do sistema consistirão de um servidor
web com suporte aos principais recursos da linguagem de programação JAVA, para
provê um excelente desempenho, segurança e agilidade, que são as metas na utilização
do sistema e conta também para este fim com um sistema de gerenciamento de banco de
dados (SGBD) SQL Server que oferece que oferece um conjunto rico de avançados
recursos, proteção aos dados, dentre outros benefícios.
Partindo para a arquitetura básica interna do sistema, temos as entidades que
compõem esse software e suas interações entre si, conforme apresentado no diagrama
de classes na Figura 11.

6
https://play.google.com/store
32
 Figura 11 - Diagrama de classes

A entidade central do sistema é a entidade Linha que interage com a maioria das
entidades com diferentes tipos de relacionamentos entre elas. Onde as entidades
Relatório, Localização e Horário possuem a relação de composição com a entidade
Linha, o que significa que o objeto da entidade Linha compõe essas entidades e sem ele
esses objetos não existem.
Já no caso das entidades Empresa e Cor a relação com a entidade Linha é de
agregação, que é quando um objeto possui outros objetos e um não depende diretamente
do outro para existir.
Outro tipo de relacionamento é entre a entidade Parada e a entidade Linha que
ocorre a associação de muitos para muitos e gera a classe associativa Rota devido à
existência de atributos relacionados à associação que não podem ser representados em
nenhuma das outras classes envolvidas.
Diferente do relacionamento anterior, a entidade Parada e a entidade POI
possuem ocorrência de associação de multiplicidade muitos para muitos, porém não
exige a existência de outra classe associativa.
Dentre as outras associações simples presente no diagrama de estrutura que não
necessitam de explicação é necessário citar por fim o relacionamento de generalização

33
entre a entidade Usuário e seus filhos Admin, Funcionário e Cobrador, que existe na
ocorrência de herança entre classes. Essa situação é abordada por Guedes:

“Como no diagrama de casos de uso a generalização/especialização ocorre

quando existem duas ou mais classes com características muito semelhantes.
Assim, para evitar ter de declarar atributos e/ou métodos idênticos e como
uma forma de reaproveitar código cria-se uma classe geral em que são
declarados os atributos e métodos comuns a todas as classes envolvidas no
processo e, então declaram-se classes especializadas ligadas à classe geral,
que herdam todas as suas características, podendo ter atributos e métodos
próprios”. (GUEDES, 2011, p.113).

É importante esclarecer que esta visão arquitetural do sistema foi construída com
base nas notações da ISO/IEC/IEEE 42010 que é uma norma internacional que aborda
os requisitos para o desenvolvimento de descrição de arquitetura para software e
sistemas e que essa estrutura de entidades serve de apoio ao que será mostrado no
diagrama de pacotes que mostra de forma bem mais completa o funcionamento interno
do sistema.

3.5 Diagrama de Pacotes

A Figura 12 apresenta um diagrama de pacotes com foco na visão geral do

projeto, mostrando como os módulos do sistema estão integrados e as dependências
entre cada um. O módulo gerencial aparece como sistema central que fornece
informações e serviços para os demais módulos. Enquanto que o módulo do usuário
depende do módulo do ônibus no que se refere às informações de localização dos
ônibus monitorados por este módulo.

34
 Figura 12 - Diagrama de pacotes da visão geral do sistema

Conforme mostrado na Figura 13, que representa o módulo gerencial do sistema,

o objetivo do diagrama de pacotes, neste caso em específico e nos demais diagramas de
pacotes presentes neste projeto, não é mostrar as classes que compõem o sistema, mas
sim mostrar os relacionamentos dos pacotes entre si, que são agrupamentos de classes
com responsabilidades parecidas. Ou seja, cada pacote possui uma serie de classes com
funções específicas dentro do sistema. Além disso, esse diagrama serve também para
mostrar quais padrões de projeto foram aplicados e quais suas influências na
organização e estruturação do sistema.

“O diagrama de pacotes é um diagrama estrutural que tem por objetivo

representar os subsistemas ou submódulos englobados por um sistema de
forma a determinar as partes que o compõem. Pode ser utilizado de maneira
independente ou associado com outros diagramas. Esse diagrama pode ser
utilizado também para auxiliar a demonstrar a arquitetura de uma linguagem,
como ocorre com a própria UML ou ainda para definir as camadas de um
software ou de um processo de desenvolvimento.” (GUEDES, 2011, p. 33)

35
 Figura 13 - Diagrama de pacotes do módulo gerencial

Padrão de Projeto não é um projeto finalizado que possa ser diretamente

convertido em código fonte, ele é uma descrição ou modelo de como solucionar um
problema que pode ser usado em diversas situações diferentes. Em resumo, é uma
solução geral reutilizável, que foi documentada, para um problema que ocorre com
frequência dentro de um determinado contexto.

“Todos já usamos bibliotecas e molduras comerciais. Nós as pegamos,

escrevemos alguns códigos em suas API, compilamos em nossos programas e
aproveitamos um monte de códigos que outra pessoa escreveu. Pense nas API
Java e em toda a funcionalidade que elas lhes dão: rede, GUI, ES etc. As
bibliotecas e molduras demoram um tempão para chegar a um modelo de
desenvolvimento onde podemos apenas selecionar os componentes e utilizá-
los. Mas elas não nos ajudam a estruturar nossos próprios aplicativos de
maneiras mais flexíveis, fáceis de entender e manter. É aí que os Padrões de
Projetos entram.” (FREEMAN & FREEMAN,2007, p. 45).

Existem diversos padrões e frameworks de projeto que são muito utilizados, para
as mais diversas finalidades. Segundo Gamma (2000, p.26), “Alguns padrões são
frequentemente utilizados em conjunto”. Como é o caso do framework de infraestrutura
MVC, que permite dividir o projeto em camadas bem definidas e Freeman & Freeman
(2007, p. 424) afirma que o MVC é “um conjunto de padrões trabalhando juntos numa
mesma estrutura”.
Dentre as principais vantagens na utilização do MVC estão à facilidade de
manter o código sempre limpo, um melhor reaproveitamento do código, a reutilização
36
da GUI para diversas aplicações com menos trabalho, a alternativa de reescrita da GUI
ou do Controlador sem modificar o modelo do sistema, facilidade na manutenção e
inclusão de recursos, etc.

“A abordagem MVC é composta por três tipos de objetos. O Modelo é o

objeto de aplicação, A Visão é a apresentação na tela e o Controlador é o que
define a maneira como a interface do usuário reage às entradas do mesmo.
Antes da MVC, os projetos de interface para o usuário tendiam a agrupar
esses objetos. A MVC separa esses objetos para aumentar a flexibilidade e a
reutilização.” (GAMMA, 2000, p. 20).

Como apresentado na Figura 13, os elementos Controller e GUI, que utilizam

estereótipos gráficos para representar, respectivamente, as classes responsáveis pelo
controle do sistema, que serve como canal de comunicação entre a visão e o modelo, e o
outro é responsável pelas visões, que são as interfaces de comunicação do sistema com
o usuário. Já o Modelo, complementando o padrão MVC, é representado pelo pacote
entidades, que fornece toda a regra de negócio e também na leitura e escrita de dados,
juntamente com as classes do pacote DAO.
O padrão DAO, acrônimo de Data Access Object, que pode ser observado no
diagrama de pacotes com esse mesmo nome em um dos pacotes. Permite criar as classes
de dados independentemente da fonte de dados do sistema. Podendo esta ser um banco
de dados relacional, um arquivo XML, um arquivo texto, ou qualquer outra fonte de
dados que possa ser utilizada. Segundo Cordeiro (2012, p. 66) “A flexibilidade é tanta
que no caso mais simples podemos ter implementações do mesmo DAO para banco de
dados diferentes ou para mecanismos diferentes de bancos relacionais, como os bancos
NoSQL ou mesmo arquivos texto”. No DAO é possível criar uma interface genérica de
acesso aos dados e encapsular os seus mecanismos de acesso, permitindo que estes
mecanismos sejam modificados independentemente do código que utiliza os dados.
Outro padrão que será utilizado no projeto dentro do pacote Conexão, porém não
está explicito é o Singleton que conforme, Gamma (2000, p.156), “garante que uma
classe tenha apenas uma instância e fornece um ponto global de acesso a ela”.
Permitindo assim que o sistema tenha apenas um ponto de acesso à conexão com a base
de dados que será utilizada no sistema. Assegurando assim, maior controle e segurança
nas transações com o banco de dados.
O pacote chamado Framework JSF, como o próprio nome sugere, contém o
framework com mesmo nome. De acordo com Faria (2013, p. 10), “é um framework

37
web baseado em Java que tem como objetivo simplificar o desenvolvimento de
interfaces (telas) de sistemas para a web, através de um modelo de componentes
reutilizáveis”. Ainda segundo o autor, O JSF é baseado no padrão MVC, tornando o
desenvolvimento de sistemas menos complicado, e os principais componentes que o
framework fornece são: formulários, campos de entrada de texto, rótulos, links, botões,
mensagens, painéis, tabela de dados, etc.

“JavaServer Faces, também conhecido como JSF, é uma tecnologia para

desenvolvimento web que utiliza um modelo de interfaces gráficas baseado
em eventos. Esta tecnologia foi definida pelo JCP (Java Community Process),
o que a torna um padrão de desenvolvimento e facilita o trabalho dos
fornecedores de ferramentas, ao criarem produtos que valorizem a
produtividade no desenvolvimento de interfaces visuais.” (FARIA, 2013,
p.44)

Outros pacotes que fazem parte da estrutura do módulo gerencial são: a API
Google Maps, formado por um conjunto de classes que se comunicam com o servidor
de mapas e utilizam a sua API para apresentar e gerenciar os elementos que compõem
os mapas desse aplicativo, e o outro pacote, é o Driver JDBC, composto por um
conjunto de classes que permitem que uma aplicação interaja com o banco de dados.

Figura 14 - Diagrama de pacotes do módulo do ônibus

38
 A Figura 14 apresenta o diagrama de pacotes do módulo do ônibus, que se difere
do módulo gerencial apenas em alguns aspectos. A primeira diferença é o fato de não
possuir o pacote de API do Google Maps, pois este recurso não é utilizado dentro deste
módulo. A outra diferença é a utilização do pacote APP Android que representa neste
diagrama, um projeto de aplicativo da plataforma Android que utiliza o componente
Webview, dependendo diretamente da interface de usuário deste módulo. O uso dessa
estrutura exige uma interface responsiva muito bem elaborada, conforme citado nos
requisitos não funcionais do projeto proposto.
De acordo com o site oficial7 de suporte aos desenvolvedores de aplicativos da
plataforma Android, esse componente permite, com autorização prévia do usuário, que a
aplicação tenha acesso ao GPS e a vários outros sensores e recursos do dispositivo,
permitindo que aplicação possa, também, funcionar normalmente, através do aplicativo,
nos smartphones com plataforma Android.
Outra característica importante na utilização deste método é o fato de se poder
desenvolver apenas uma interface de usuário que possa trabalhar em múltiplas
plataformas. Garantindo assim, maior opção de escolha ao usuário final.

Figura 15 - Diagrama de pacotes do módulo do usuário

7
http://developer.android.com/guide/webapps/index.html
39
 A figura 15 apresenta o diagrama de pacotes do módulo do usuário. Este módulo
depende diretamente dos outros dois módulos do sistema e possui todos os pacotes
vistos nos outros diagramas de pacotes anteriores. O que dispensa novas apresentações.

3.6 Modelagem Dinâmica

O diagrama de classes é muito útil para o desenvolvimento de sistemas, pois

determina as principais classes e componentes que o software precisa possuir e serve
como base para a construção dos diagramas de sequência, estado e outros diagramas.
O diagrama de sequencia serve para detalhar as interações entre os objetos do
sistema na ocorrência de um evento específico. Segundo, Guedes (2011, p. 33), “O
diagrama de sequência é um diagrama comportamental que preocupa-se com a ordem
temporal em que as mensagens são trocadas entre os objetos envolvidos em um
determinado processo”.
Nesta etapa do processo, foram destacados alguns dos principais casos do
sistema, para mostrar de forma detalhada quais os elementos envolvidos em cada um
deles e principalmente quais os atores e eventos do sistema envolvidos no processo.
O primeiro evento a ser mostrado desse diagrama, conforme visto na Figura 16,
é o Monitorar Viagem que faz parte do Módulo do Ônibus como relatado,
anteriormente, nas descrições dos casos de uso.

40
 Figura 16 - Diagrama de sequência monitorar viagem

Esse diagrama de sequência é iniciado quando o usuário cobrador seleciona a

linha, o horário e logo em seguida clica no botão iniciar viagem. No decorrer desse
processo o sistema faz uma serie de interações entre os objetos. Primeiramente, quando
o usuário seleciona a linha o controlador solicita ao objeto horário apenas os horários
disponíveis para aquela linha em específico. Ao selecionar o horário o controlador
armazena, temporariamente, esses dados para quando o usuário clicar em iniciar
viagem, o sistema passar como parâmetro esses dados e buscar, em seguida, o tempo de
viagem da linha e o seu itinerário, cada um em seus objetos correspondentes. Logo após
retornar com essas informações, o sistema entra em um loop para atualizar e enviar a
sua localização atual, obtida pelo GPS do dispositivo, para o módulo do usuário, que só
será interrompido quando o usuário cobrador clicar em Finalizar viagem.

41
 Figura 17 - Diagrama de sequência exibir rota

O segundo diagrama de sequência a ser mostrado é o Exibir Rota que faz parte
do módulo do usuário e, conforme detalhado na Figura 17, é iniciado quando o usuário,
já na tela resultado da pesquisa, seleciona uma linha para que a sua rota seja exibida.
Após selecionar a linha o controlador faz a busca da rota e retorna o resultado para a
interface do usuário.

Figura 18 - Diagrama de sequência buscar pelo destino

O terceiro e último diagrama de sequência a ser demonstrado nesse projeto é o

Buscar pelo Destino (ver Figura 18), que assim como o diagrama anterior, também faz
parte do módulo do usuário. A sequência é iniciada com o evento de informar o destino
na tela de pesquisa do sistema, seguido do clique no botão pesquisar. O controlador

42
recebe os dados e faz à busca do destino informado no cadastro de POI do sistema, em
seguida, o controlador, automaticamente, busca e seleciona a parada mais próxima do
usuário e a parada de destino. Com posse desses dados o sistema busca todas as linhas
que tem rota passando entre os dois pontos selecionados, retorna o resultado da pesquisa
para a tela do usuário, com a primeira linha do resultado já selecionada, e faz a chamada
do evento Exibir Rota, conforme mostrado no diagrama de sequencia correspondente.
Um diagrama de sequência expõe o modo como os grupos de objetos colaboram
em algum comportamento ao longo do tempo, diferente do diagrama de estados que se
deve criar um diagrama somente para cada classe de objeto que apresente
comportamento relevante e dinâmico.
O diagrama de Estados também tem como base o diagrama de classe para sua
construção e esse diagrama tem seu foco principal o objeto, diferente do diagrama de
sequência que foca no processo de negócio. O seu objetivo é descrever um
comportamento de um objeto, onde os seus estados representam situações estáveis
durante certo intervalo de tempo. Esse diagrama deve ser usado quando um objeto
dentro do sistema possui um comportamento dinâmico e seja relevante dentro projeto.
Segundo Guedes (2011, p. 242), “Um estado representa a situação em que um
elemento (muitas vezes um objeto) se encontra em determinado momento durante o
período em que participa de um processo. Um objeto pode passar por diversos estados
dentro de um mesmo processo”.

Figura 19 - Diagrama de estado localização

43
 A Figura 19 apresenta o diagrama de estados para Localização. Esse diagrama
retrata os estados da instancia da classe Localização, no decorrer do tempo, de acordo
com os estímulos externos recebidos por esse objeto.
O Estado inicial, caracterizado por um círculo totalmente preenchido na cor
preta, tem a função somente de determinar o início da modelagem e gerar a transição
que inicia o processo. O Estado iniciando viagem representa o momento em que o
usuário Cobrador clica no botão iniciar viagem no módulo do ônibus, e o objeto
localização é criado e recebe os dados iniciais, fazendo a transição logo em seguida,
para o estado recebendo dados, onde as informações passadas ao iniciar viagem serão
validadas.
Seguindo para o próximo estado, o objeto persiste os dados que foram validados
no banco de dados para assim ficar disponível ao módulo do usuário. Ao término do
processo o objeto entra em estado de espera para uma das opções:
 A contagem de tempo chegar ao horário estipulado e executar novamente
o recebimento de dados e atualização da sua localização. Formando
assim um loop entre esses três estados;
 Ou mudar para finalizando viagem, que acontece quando o usuário clica
no botão finalizar viagem e objeto solicita ao sistema a remoção da sua
localização do banco de dados e assim chegar ao fim do processo e do
diagrama de estado.
O banco de dados nesse processo, em especial, é um fator essencial para a
comunicação entre os módulos do cobrador e do usuário. E para melhor entendimento
dessa comunicação entre os módulos, a estrutura de banco de dados desse sistema será
mostrada a seguir.

3.7 Banco de Dados

A modelagem de dados é uma técnica utilizada para especificar as regras de

negócios do sistema e as estruturas de um banco de dados. O que consiste em planejar o
sistema de informações, com foco nas entidades lógicas e nas dependências lógicas
entre elas. Ela faz parte do ciclo de desenvolvimento de um software e é de suma
importância para realizar um projeto de qualidade.
44
 Nesta etapa do projeto, para não ficar algo muito extenso e repetitivo, será
mostrado apenas o modelo físico da modelagem de dados, através da Figura 20, visto
que apenas a sua apresentação acompanhada dos diagramas exibidos anteriormente
complementam-se de maneira a esclarecer, de forma completa, os principais aspectos
estruturais do sistema.
No modelo físico é feita a modelagem física do banco de dados levando-se em
conta as restrições impostas pelo SGBD escolhido e também os recursos disponíveis em
cada um deles. Essa escolha pelo SGBD a se usar, deve sempre levar em consideração o
objetivo do seu projeto.

Figura 20 - Modelo físico de dados

A notação de James Martin ou engenharia da informação, geralmente encontrada

e representada em ferramentas CASE somente como IE, foi utilizada para a construção
desse modelo físico de banco de dados. Essa notação também é conhecida como “Pé de
galinha” e possui um padrão simples de representação dos elementos, que pode ser
facilmente entendida no decorrer da explicação desse modelo. Esta notação, segundo

45
Cougo (1997, p.147), “[...] tem sido uma das notações mais utilizadas nos últimos
tempos”.

“A notação conhecida como pé-de-galinha, ou no original Crow’s foot (pata

de corvo), não abrange, na verdade, todo um conjunto de elementos gráficos
para representação de modelos de dados. Ela somente trata, em especial, da
notação utilizada para a representação dos relacionamentos, James Martin
incorporou essa notação junto a outros elementos e disseminou, através de
seus trabalhos sobre Engenharia da Informação, essa notação que hoje muitas
vezes é tida como notação Martin. Na verdade, a notação Martin [...] é muito
mais completa, pois incorpora a notação de pé-de-galinha e dá-lhe elementos
de semântica adicional.” (COUGO, 1997, p.146)

Conforme demonstrado na Figura 20, a tabela TB_LINHA é a principal tabela

do banco de dados. É quem possui o maior numero de vínculos com as demais tabelas e
que mantém as informações de cadastro do principal elemento do sistema, que é a linha.
Essa tabela possui a relação de muitos para um com a tabela TB_COR, que guarda as
cores disponíveis para as diversas linhas de ônibus da cidade, e com a tabela empresa,
que representa as empresas cadastradas no sistema, o que significa que a cada linha
pertence a apenas uma empresa e possui apenas uma cor representante.
Já no caso do seu relacionamento com as tabelas TB_RELATORIO e
TB_LOCALIZACAO, a cardinalidade é de um para muitos onde uma mesma linha
pode aparecer em diversos relatórios em diversas localizações ao mesmo tempo. Neste
caso de um para muitos ou o inverso, a chave primária do que representa o „um‟ do
relacionamento, sempre vai para dentro da tabela com a cardinalidade „muitos‟ como
chave estrangeira.
Um detalhe importante da tabela TB_LOCALIZACAO é a utilização de um tipo
de variável especial chamada geography, que faz parte dos recursos do SQL Server
2008 e permite que um ponto geográfico, neste caso a latitude e a longitude obtida do
gps no módulo do ônibus, sejam salvos em um único campo no banco de dados e
melhor manipulados na busca de resultados dentro do módulo do usuário, utilizando os
recursos oferecidos nesse SGBD.
A tabela TB_HORARIO, que também está relacionada à tabela linha, tem
cardinalidade entre elas e também com a tabela TB_DIA de muitos para um, sendo
então executada a mesma regra citada anteriormente. Essas tabelas tem a função de
controlar os horários de saída dos ônibus, onde a TB_DIA tem o cadastro fixo dos dias
da semana de segunda a domingo, vinculados, cada dia, a diversos horários dentro da

46
tabela TB_HORARIO e a uma linha específica. Montando assim uma grade de horários
diários de cada linha.
A tabela TB_ROTA tem seus registros obtidos pela junção das chaves primárias
das tabelas TB_LINHA e TB_PARADA, somados ao campo ordem, que é a sequencia
a seguir pela linha, dão origem às rotas de cada linha do sistema. A tabela
TB_PARADA possui o cadastro de cada ponto geográfico das paradas, utilizando o
mesmo padrão da tabela TB_LOCALIZACAO, e outras informações para sua melhor
identificação.
A tabela TB_PARADA também se relaciona de forma indireta com a tabela
TB_POI, dando origem a tabela TB_DESTINO, que serve para identificar qual a parada
de destino do cidadão no módulo do usuário ao fazer uma pesquisa por destino. No caso
deste tipo de busca, o sistema pesquisa na tabela TB_POI, onde existe um cadastro dos
pontos de interesses da cidade, e ao encontrar um resultado, verifica na tabela
TB_DESTINO qual a parada mais próxima do registro encontrado.
Já a tabela TB_USUARIO é responsável por armazenar os dados de acesso ao
sistema dos usuários, utilizando criptografia no campo senha para garantir maior
segurança dos dados. Essa tabela está relacionada com a tabela TB_EMPRESA, com
cardinalidade de muitos para um. Porém pode haver ou não um usuário associada a uma
empresa, que é o caso especifico do usuário do tipo Administrador que não possui
vínculo com uma empresa. Cada usuário está associado a um tipo de usuário na tabela
TB_USUARIO_TIPO que representa o perfil de acesso ao sistema ao qual o tipo está
vinculado. Conforme representado nos diagramas de casos de uso e que serão mais bem
visualizados nas telas de protótipos do sistema que serão mostrados do decorrer desse
trabalho.

47
4 PROTÓTIPO

O protótipo é uma maneira de obter feedback dos clientes e/ou usuários do

sistema através de sua apresentação. O que possibilita a realização das correções e
ajustes necessários antes do processo de produção do produto. Dentre as diversas
vantagens da prototipação, destacam-se a facilidade de entendimento do cliente, melhor
dialogo entre quem projeta e quem vai utilizar o produto e entre os próprios membros da
equipe e a possibilidade de se obter uma aprovação formal do projeto.
Na engenharia o protótipo é um sistema ou modelo de sistema sem
funcionalidades avançadas, podendo exibir apenas funcionalidades gráficas para melhor
compreensão do projeto. Para Sommerville:

“O objetivo da prototipação é permitir que os usuários ganhem experiência

direta com a interface. A maioria de nós considera difícil pensar de maneira
abstrata sobre uma interface com o usuário para explicar exatamente o que
queremos. Entretanto, quando são apresentados exemplos, é fácil identificar
as características de que gostamos ou não.” (2007, p. 253)

Neste projeto foi utilizada para prototipação, uma ferramenta chamada Balsamiq
Mockups (ver Figura 21). Que de acordo com o site oficial8, É um software pago, com
versão de teste por sete dias, desenvolvido com a tecnologia Adobe AIR. Possui
compatibilidade com as plataformas Windows, Linux e Mac, e está disponível também
em versão online. Esse software é uma ferramenta de concepção de interfaces do
usuário do tipo wireframes (também conhecidos por moldes ou protótipos de baixa
qualidade), utilizados no estágio inicial do desenvolvimento de produtos, aplicativos,
páginas, etc. visando facilitar a comunicação e maior compreensão do projeto, em todas
as áreas envolvidas.

8
https://balsamiq.com/products/mockups/
48
 Figura 21 - Interface do Balsamiq Mockups. Fonte: site oficial do software

O software permite realizar a criação de interfaces de usuário com vários layouts

e elementos gráficos que mostram uma prévia de como será o aplicativo em sua versão
final, sem a necessidade de construir o software em si. O Balsamiq Mockups permite
também a visualização estática e bastante limitada, porém suficiente para o
entendimento do projeto, de mapas e objetos da API Google Maps, que serão utilizados
no projeto e são de vital importância para o sistema.

4.1 Prototipação de interfaces com o usuário

A construção e validação das telas do sistema foram baseadas nas 10 avaliações

heurísticas de Nielsen, porém nem todas puderam ser aplicadas na fase de prototipação.
Segundo o próprio Nielsen (2005), esse é um método de inspeção rápido, barato e fácil,
para realizar testes de usabilidade em interfaces de usuário. Sendo elas:

1. Visibilidade do status do sistema: O sistema deve sempre informar ao

usuário o que está acontecendo, através de feedback ao usuário.

49
 2. Compatibilidade entre sistema e mundo real: O sistema deve usar uma
linguagem compreensiva e familiar ao usuário.
3. Controle do usuário e liberdade: O dispor ao usuário uma saída rápida
para possíveis erros inesperados. Como, por exemplo: Um botão voltar.
4. Consistência e padrões: Usar as mesmas palavras para situações ou ações
iguais no sistema.
5. Prevenção de erros: Prevenir situações passíveis de erros. Tais como:
Campo para confirmação de senha, máscara data, CPF, etc.
6. Reconhecimento ao invés de lembrança: As ações ou instruções para uso
do sistema devem estar visíveis ou facilmente acessadas.
7. Flexibilidade e eficiência de uso: Dar melhores alternativas de uso do
sistema, tanto para usuários iniciantes como para usuários experientes.
8. Estética e Design minimalista: Manter a simplicidade, sem poluição visual
e sem informações irrelevantes.
9. Ajudar os usuários a reconhecer, diagnosticar e recuperar-se de erros:
Indicar com precisão, usando linguagem simples e sem códigos, o problema
e sugerir uma solução construtiva.
10. Ajuda e documentação: Fornecer documentação de forma objetiva ao
usuário, de maneira fácil de pesquisar e focada nas tarefas do usuário.

Para melhor compreensão desta etapa do projeto, as telas do sistema serão

apresentadas e analisadas por módulos.

4.1.1 Protótipos do Módulo Gerencial

No módulo gerencial, ao entrar no site de acesso a esse módulo do sistema, o

usuário é direcionado para a tela de login, onde deve informar login e senha válida para
poder acessar o sistema. Conforme apresentado na Figura 22 e previsto nos requisitos
funcionais do sistema e no caso de uso Realizar Login do módulo gerencial.

50
 Figura 22 - Tela de login do módulo gerencial

Após efetuar o login, o usuário é direcionado para a tela inicial do módulo, que
exibe uma mensagem de boas vindas ao usuário e o permite acessar diversas
funcionalidades através do menu, conforme apresentado na Figura 23. Sendo que
apenas o usuário do tipo Administrador tem acesso as funcionalidades contidas na aba
Admin do menu.

Figura 23 - Tela inicial do módulo gerencial

51
 A tela de gerenciamento de linhas, apresentado na Figura 24, possui uma lista de
todas as linhas cadastradas no sistema, sendo exibidas apenas as linhas correspondentes
à empresa a qual o usuário logado está vinculado, com as opções de editar e apagar cada
registro. Essa tela possui também a opção de inserir uma nova linha, bastando o usuário
informar os dados solicitados na seção Cadastrar Linha e clicar no botão SALVAR.
Sendo que as validações dos campos solicitados seguem as regras impostas no caso de
uso Gerenciar Linhas.
É importante ressaltar que nesta tela e nas demais telas que possuem o campo
denominado ativo, o sistema faz o tratamento destes campos para exibir sim ou não em
vez de 0 ou 1 para falso ou verdadeiro, como é salvo no banco de dados, conforme visto
anteriormente na Figura 20 na sessão 2.7.

Figura 24 - Tela de gerenciamento de linhas do módulo gerencial

A tela gerenciamento de horários (ver Figura 25), que trata dos horários de
viagem das linhas, conforme descrito no caso de uso Gerenciar Horário, pode ser feita
nesta tela de duas maneiras: inserindo um horário por vez à lista de horários, ao dia da
semana que estiver selecionado no momento ou inserir vários horários por vez,
informando um horário inicial e o final, o intervalo entre os horários de viagem e

52
selecionar um ou vários dias da semana e concluir o processo, clicando no botão
INSERIR HORÁRIOS. Para excluir um horário é necessário apenas selecionar um
horário na lista de horários da linha selecionada e clicar no botão excluir.

Figura 25 - Tela de gerenciamento de horários do módulo gerencial

A tela de gerenciamento de rotas, que trata a Figura 26 e que corresponde ao

caso de uso Gerenciar Rotas, mostra o momento em que uma das paradas cadastradas
no sistema está selecionada e exibindo suas informações. Para inserir as paradas a uma
rota, primeiramente deve selecionar uma linha para carregar a sua rota, em seguida
selecionar uma parada no mapa e clicar no botão "Inserir parada na rota". A parada será
inserida logo abaixo da parada que esteja marcada, no momento, como selecionada na
lista com título “Rota da Linha”. Caso nenhum registro da lista esteja selecionado, a
parada será inserida no final da lista.
As alterações realizadas na rota da linha selecionada só serão salvas após clicar
no botão “salvar alterações”. Sendo que este só será exibido quando houver alguma
alteração na lista, para facilitar a compreensão do usuário no processo. Outro recurso
importante desta tela é a opção de visualizar a rota da linha no mapa, acessado quando o

53
usuário marca o checkbox “EXIBIR ROTA NO MAPA” no canto inferior esquerdo da
tela.

Figura 26 - Tela de gerenciamento de rotas do módulo gerencial

A tela relatórios de viagens, apresentado na Figura 27, mostra como funciona a

visualização dos relatórios de viagens obtidos do módulo do ônibus de cada viagem
realizada. Esta tela possui uma lista que exibe todos os registros da linha que está
selecionada no momento, na sessão “Filtros de pesquisa”. Está sessão pode ser utilizada
também para buscar registros em um período de data específico. O usuário dispõe
também da opção de exportar a lista atual exibida na tela em forma de relatório no
formato pdf, através do botão “Exportar para PDF”, que a o ser clicado gera o arquivo
para download automaticamente.

54
 Figura 27 - Tela de relatórios de viagens do módulo gerencial

Para fazer alteração da senha do seu próprio usuário, do tipo Funcionário, e da

senha do usuário do tipo Cobrador, que estão vinculados à mesma empresa. O usuário
Funcionário acessa a tela gerenciamento de perfil de usuário, conforme apresentado na
Figura 28, e efetua as alterações desejadas. Caso esta tela seja acessada por um usuário
do tipo Administrador a sessão “Editar Usuário (Módulo Ônibus)” não estará
disponível.

55
 Figura 28 - Tela de gerenciamento de perfil de usuário do módulo gerencial

Para inserir, editar ou excluir usuários do sistema, o usuário, obrigatoriamente,

do tipo Administrador deve acessar a tela gerenciamento de usuários que está contida na
aba Admin do menu. Está tela conforme apresentada na Figura 29, dispõe de uma lista
de usuários cadastrados no sistema com a opção de editar ou excluir um registro, e na
sessão “Cadastrar Usuário” pode ser inserido um novo usuário de acordo com as
informações solicitadas na tela.

56
 Figura 29 - Tela de gerenciamento de usuários do módulo gerencial

Outra tela que só pode ser acessado pelo Administrador é a de gerenciamento de

empresas, como visto na Figura 30, exibe a lista de empresas cadastradas com a opção
de inserir, editar e excluir registros de empresas que serão utilizados por diversas outras
telas no sistema.

57
 Figura 30 - Tela de gerenciamento de empresas do módulo gerencial

E por fim, a tela de gerenciamento de paradas realiza o gerenciamento dos

pontos onde estão às paradas no mapa, bem como as informações referentes àquele
ponto, tais como, o bairro e POI registros para cada parada, sendo de acordo com o que
foi descrito no caso de uso Gerenciar Paradas, e só pode ser acessada pelo usuário
Administrador. Na própria tela, possui instruções de como inserir, alterar ou excluir
uma parada do mapa. A Figura 31 mostra o momento em que uma parada é selecionada
no mapa, exibindo suas informações e as opções de editar, excluir e ver os POI dessa
parada.

58
 Figura 31 - Tela de gerenciamento de paradas do módulo gerencial

A Figura 32 exibe uma janela modal de cadastro de parada, que é exibido após o
usuário realizar um duplo-clique em um ponto do mapa, para solicitar a adição de uma
nova parada. Após inserir os dados solicitados e clicar no ícone de disquete, que
simboliza a opção salvar, a parada é inserida no mapa. A lista de POI que aparece no ato
do cadastro da parada, já está previamente armazenada na tabela POI do banco de dados
e são exibidos apenas os registros que estão no mesmo bairro ao qual a parada pertence.

Figura 32 - Exemplo de cadastro de parada do módulo gerencial

59
4.1.2 Protótipos do Módulo do Ônibus

Como descrito nos Requisitos Funcionais do projeto, o módulo do ônibus pode

ser visualizado tanto por computadores como por dispositivos móveis, através do
aplicativo do sistema ou diretamente pelo browser do usuário. As telas apresentadas a
seguir representam somente o aplicativo, visto que a navegação no browser não difere
em nada em relação aos recursos.
Para acessar o módulo do ônibus o usuário necessita do login e senha de acesso,
como visto na Figura 33. Cada empresa tem um usuário e senha, do tipo Cobrador, para
usar no modulo do ônibus, conforme descrito no caso de uso Realizar Login desse
módulo.

Figura 33 - Tela de login do aplicativo do módulo do ônibus

Ao fazer login com sucesso, o sistema exibe automaticamente o nome da

empresa que o usuário Cobrador está vinculado e carrega para seleção a lista de linhas
cadastradas para essa empresa na tela inicial do aplicativo, como apresentado na Figura
34.

60
 Figura 34 - Tela inicial do aplicativo do módulo do ônibus

Existem apenas duas opções a seguir: iniciar viagem ou visualizar os relatórios

de viagem do dia.
Para iniciar viagem, seguindo as regras estabelecidas no caso uso Monitorar
viagem, o usuário deve, primeiramente, selecionar uma linha, em seguida um horário e
posteriormente, clicar na opção “INICIAR VIAGEM”.
Ao realizar esse processo, o módulo do ônibus exibe as informações da viagem
em vigor, como mostrado na Figura 35, e passa a atualizar periodicamente a localização
atual do ônibus, conforme apresentado no diagrama de sequência da Figura 16 e
relatado no diagrama de estado da Figura 19.

61
 Figura 35 - Tela monitorar viagem do módulo do ônibus

Ao clicar no botão "Finalizar Viagem" o usuário será redirecionado para outra tela,
como mostra a Figura 36, onde deve informar como terminou a viagem. Ao clicar no
botão "teve problemas" o sistema só finaliza a viagem se o problema foi relatado, como
pede o caso de uso Finalizar Viagem apresentado anteriormente.

62
 Figura 36 - Tela finalizar viagem do módulo do ônibus

Na tela inicial do módulo do ônibus, ao clicar na opção “Relatório Diário” ou

quando é finalizada uma viagem, é exibida uma tela com as informações do dia atual da
linha selecionada, como mostra Figura 37. Sendo que o usuário tem a possibilidade de
selecionar outras linhas da empresa e visualizar as informações passadas em cada
viagem, separados por horários de saída, conforme descrito no caso de uso Exibir
Relatório.

63
 Figura 37 - Tela de relatório diário do módulo do ônibus

4.1.3 Protótipos do Módulo do Usuário

O módulo do usuário, conforme apresentado na Figura 10 que representa a

Arquitetura de software do projeto, possui opções de acessibilidade ao sistema idêntica
ao módulo do ônibus. Onde serão mostradas no projeto somente as telas do aplicativo
desse módulo.
Como descrito no diagrama de caso de uso desse módulo (ver Figura 9), o
acesso ao sistema é irrestrito, ou seja, não necessita de login e senha para entrar. Ao
entrar no sistema o usuário é direcionado para a tela inicial, representado pela Figura 38,
e dispõe das opções: PESQUISAR, INFORMAÇÕES e COMO USAR. Que serão
mostrados a seguir.

64
 Figura 38 - Tela inicial do aplicativo do módulo do usuário

Acessando a opção INFORMAÇÕES da tela inicial, o usuário acessa a tela de

informações, apresentada na Figura 39, que disponibiliza os horários, itinerários e a
possibilidade de visualizar a rota da linha selecionada, conforme apresentado no caso de
uso Obter Informações.

65
 Figura 39 - Tela de informações do aplicativo do módulo do usuário

Ao clicar no botão “Exibir Rota no Mapa” na tela de informações, a tela de rotas

será exibida, conforme mostrado na Figura 40, Nessa tela o usuário tem a opção de
selecionar outra linha para visualizar sua rota, como descrito no caso de uso de uso
Exibir Rota e representado no diagrama de sequencia com mesmo nome na Figura 17.

66
 Figura 40 - Tela de rotas do aplicativo do módulo do usuário

Ao acessar a opção de pesquisa, o usuário será direcionado para tela de pesquisa,

que, conforme apresentado na tela abaixo do título “Tela Inicial” da Figura 41, trabalha
de forma dinâmica, variando suas informações mediante ações realizadas pelo usuário.
Como apresentado no caso de uso Fazer Pesquisa, ao entrar nessa tela o sistema mostra
a sua localização atual e as paradas no mapa. Clicando em uma das paradas é exibida
uma lista de linhas que param naquele ponto, recurso que representa o caso de uso
Exibir Estatística, que pode ser vista na tela abaixo do título “Informação da Parada”, da
Figura 41.
Ao clicar no ícone que representa o menu de aplicativos, no canto superior
esquerdo da tela, o módulo exibe o filtro de pesquisa, como mostra a tela abaixo do
titulo “Fazendo Pesquisa” da Figura 41, onde você pode optar entre pesquisar por
destino ou por uma linha.

67
 Figura 41 - Tela de Pesquisa do aplicativo do módulo do usuário

Realizando a pesquisa por destino, o sistema retorna a tela de resultado da

pesquisa, como mostra a Figura 42 na tela abaixo do título “Exibindo Resultados”.
Conforme explicado no caso de uso Fazer Pesquisa, a única diferença entre os tipos de
pesquisa é o fato de o marcador chamado destino aparecer na tela ou não.
Existem diversas camadas de componentes da API Google Maps presentes nesta
tela que correspondem a diversos elementos do sistema como, por exemplo, os
marcadores em forma de ônibus, representando as linhas com suas respectivas cores, os
marcadores das paradas, um marcador chamado você, que representa a localização do
usuário, e a rota, que não está representada na tela devido às limitações existentes no
software Mockups. Mas que pode ser visualizada mentalmente como uma linha que liga
diversas paradas em sequência no mapa, de acordo com o que foi cadastrado no
gerenciamento de rotas no módulo gerencial.
Conforme foi definido no diagrama de sequência Buscar pelo destino na Figura
18, o usuário informa um destino e clica em pesquisar. O sistema marca no mapa a
localização do destino escolhido, a localização atual do usuário, a parada mais próxima
e exibe uma lista de linhas que passam próximo ao destino escolhido e a localização
atual do usuário. Sendo que o sistema já exibe a rota de uma das linhas e marca no mapa
todos os ônibus em circulação das linhas presentes no resultado da pesquisa.
É possível também comparar duas rotas no mapa, conforme descrito no caso de
uso Comparar Rota. O acesso a essa função é através da utilização do combobox

68
localizado na parte inferior da tela (ver Figura 42) com o texto “Comparar com outra
linha”, bastando apenas o usuário selecionar uma linha dessa lista.
Outro recurso importante na tela de resultado da pesquisa é a possibilidade de
selecionar uma parada e com base na parada selecionada, quando o usuário clica em um
ônibus, o sistema faz o cálculo do tempo estimado de chegada até esse ponto marcado,
sendo utilizado para o cálculo funções da API Google Maps, no modo transporte
público e levando em consideração a rota cadastrada para essa linha e se o ônibus
selecionado já passou ou não pela parada selecionada. Feito isso, o sistema exibe essas
informações em um modal, como apresentado na tela abaixo do título “Exibindo
Estatística” da Figura 42.

Figura 42 - Tela de resultado da pesquisa do aplicativo do módulo do usuário

Caso o usuário tenha dúvidas de como usar os recursos desse módulo, basta
acessar a opção “Como usar” da tela inicial e visualizar o tutorial passo-a-passo de
como utilizar o sistema, apresentado na Figura 43 e descrito no caso de uso Obter ajuda.

69
Figura 43 - Tela como usar do aplicativo do módulo do usuário

70
5 CONCLUSÃO

O planejamento e execução de bom um projeto de sistema de TI são de suma

importância para a fase de desenvolvimento do software, pois contempla diversas visões
da estrutura e recursos que formam o sistema. O que facilita no feedback com o cliente
e usuários do sistema e minimiza erros no desenvolvimento e entrega do software.
O sistema “Vou de ônibus“, com sua implantação no sistema de transporte
coletivo da cidade pode marcar o inicio de um ciclo de melhorias para esse setor, no que
se refere a garantir a população meios que facilitem sua mobilidade de maneira mais
prática, principalmente, com a possível implantação do sistema de GPS nos ônibus e
bilhete único frota de ônibus da cidade (SMTT, 2015), onde as pessoas poderão descer
em qualquer ponto da cidade e pegar outro ônibus, segundo as regras que serão
impostas pelo sistema de transporte público da capital, onde esse software ajudará ainda
mais ao usuário de ônibus planejar seu percurso diário.
O sistema proposto é de fácil utilização, leve e intuitivo, contendo poucos
recursos complexos, que são rapidamente aprendidos com o uso da função de ajuda do
sistema. Possui também um design limpo e responsivo, que se adapta à tela do
dispositivo que o está acessando, sendo um fator primordial para aumentar o numero de
acesso ao sistema. O uso da API Google Maps e os padrões de projetos presentes no
projeto possibilitam um melhor desempenho do sistema e gama de recursos únicos para
favorecer o usuário na utilização do transporte público.
Embora possua diversos recursos para melhorar a vida do cidadão, esse sistema,
assim como todo software que está em sua primeira versão, possui certas limitações,
como por exemplo, a necessidade do cobrador de ônibus informar a cada viagem, de
forma manual, a linha e o horário que vai ser realizado no módulo do ônibus. Existe
também a necessidade constante da conexão com a internet, para que a localização dos
ônibus, em circulação, sejam passadas aos usuários, dentre outras coisas, que devem ser
melhoradas no futuro caso ocorra investimentos tecnológicos no setor.
Tais limitações e outras melhorias são propostas de trabalhos futuros no sistema,
que visam aperfeiçoar cada vez mais esse projeto. Podemos citar como exemplo: a
disponibilização dos horários e rotas das linhas offline, a utilização de um computador
de bordo nos ônibus que faça automaticamente a função do módulo do ônibus, que
possa controlar também, com o auxílio de sensores nas portas do veículo, a quantidade

71
de usuários dentro do ônibus em tempo real, fator que ajudaria o usuário a decidir
melhor qual ônibus pegar. Outras opções de melhorias muito importantes para o sistema
seria a adoção de recursos de acessibilidade, tais como: informar quais ônibus possuem
suportes a cadeirantes e adicionar reconhecimento de voz para pesquisar linhas e
adicionar alerta de aproximação do ônibus para pessoas com deficiência visual.

72
6 REFERÊNCIAS

CORDEIRO, Giliard. Aplicacoes Java para a Web Com JDF e JPA. Casa do Codigo,
2012.

COUGO, Paolo. Modelagem Conceitual e Projeto de Banco de Dados. Editora Campus,

1997.

FARIA, Thiago. Java EE 7 com JSF, Primefaces e CDI. AlgaWorks, 2013.

FREEMAN, E.; FREEMAN, E. Use a cabeça! Padrões de Projetos. 2 ed. Brasil,

Altabooks, 2007.

GAMMA, Erich. Padrões de projeto: soluções reutilizáveis de software orientado a

objetivos. Porto Alegre: Bookman, 2000.

GUEDES, G. T. A. UML 2 - Uma Abordagem Prática. 2ª Edição, Editora Novatec,

2011.

PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. 7. ed. São

Paulo: Mc Graw Hill – Bookman, 2011.

SOMMERVILLE, Ian. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-

Wesley, 2007.

CÂMARA, Gilberto, QUEIROZ, Gilberto Ribeiro de. Arquitetura de Sistemas de

Informação Geográfica. INPE. São José dos Campos. 2001. Disponível em:
<http://www.dpi.inpe.br/gilberto/livro/introd/cap3-arquitetura.pdf>. Acessado
em 17/06/2015.

GOOGLE. Programa de parceiros do Google Transit.

<http://maps.google.com.br/intl/pt-BR/help/maps/mapcontent/transit/>. Acessado em
05/06/2015, 10:00h.

Nielsen, J. (2005). Ten Usability Heuristics.

<http://www.useit.com/papers/heuristic/heuristic_list.html>. Acessado em
30/06/2015, as 20:00h.

SMTT, Secretaria Municipal de Trânsito e Transportes.

<http://www.saoluis.ma.gov.br/subportal_noticia.asp?id_noticia=9555>.
Acessado em 13/06/2015, 16:51h.

73