Sistema Gerenciador de Filas Remotas: Mitigando Os Efeitos Negativos Da Espera em Estabelecimentos Comerciais

UNIVERSIDADE FEDERAL DO ESPRITO SANTO
CENTRO TECNOLGICO
DEPARTAMENTO DE INFORMTICA
JOS MARQUES SOARES JNIOR
SISTEMA GERENCIADOR DE FILAS REMOTAS:

MITIGANDO OS EFEITOS NEGATIVOS DA ESPERA
EM ESTABELECIMENTOS COMERCIAIS
VITRIA
2017

Trabalho de Concluso de Curso apresentado ao

Departamento de Informtica da Universidade
Federal do Esprito Santo, como requisito parcial
para a obteno do grau de Bacharel em Cincia
da Computao.
Orientador: Prof. Jadir Eduardo Souza Lucas.
VITRIA
2017

Trabalho de Concluso de Curso apresentado ao

Departamento de Informtica da Universidade
Federal do Esprito Santo, como requisito parcial
para a obteno do grau de Bacharel em Cincia
da Computao.
Aprovada em ____ de _____________ de 2018.
BANCA EXAMINADORA
RESUMO
Devido ao constante aumento da demanda por bens e servios em reas urbanas,
torna-se cada vez mais comum a formao de filas. Preocupados com isso, os
donos de estabelecimentos comerciais buscam alternativas para minimizar o
desconforto causado pela espera e uma consequente insatisfao dos clientes em
relao aos servios prestados. Sendo assim, este trabalho tem o objetivo de mitigar
o desconforto causado pela espera ociosa em estabelecimentos comerciais. Para
isso, foi desenvolvido um sistema de controle de filas remotas, onde o cliente pode
planejar tanto a sua entrada na fila quanto a sua permanncia na mesma. Esse
sistema foi dividido em duas aplicaes: uma servidor desenvolvido com o
framework Web Django embarcado num Raspberry Pi; um aplicativo para a
plataforma Android. Com o servidor, o dono do estabelecimento comercial pode
gerenciar filas e funcionrios. Tambm possvel conectar o Raspberry Pi a uma TV
e exibir informaes sobre a fila e sobre o estabelecimento. J o cliente do
estabelecimento, pode usar o aplicativo Android para visualizar o status da fila, antes
mesmo de retirar uma senha. Com o aplicativo, o cliente se mantm informado
acerca da sua situao, recebendo notificaes quando o seu atendimento est
prximo. Outro recurso do aplicativo a possibilidade de gerenciar vrias senhas
para filas diferentes, permitindo a espera em vrias filas ao mesmo tempo.
Palavras-chave: Filas remotas. Gerenciamento de filas. Raspberry Pi. Django.
Android.
ABSTRACT
Due to the constant increase in demand for services in urban areas, queuing is
becoming more common. Concerned about this, shop owners seek alternatives to
minimize the discomfort caused by waiting and consequent customer dissatisfaction
with the services provided. Therefore, this work aims to mitigate the discomfort
caused by idle waiting in commercial areas. For this, a remote queuing control
system has been developed, where the client can plan both their queue entry and
their stay in the queue. This system was divided in two applications: a server
developed with the Web framework Django embedded in a Raspberry Pi; An
application for Android platform. With the server, the business owner can manage
queues and employees. You can also connect Raspberry Pi to a TV and display
information about a queue and about the establishment. The establishment's
customer can use the Android application to view the status of the queue before get
a ticket. With the application, the client keeps informed about their situation, receiving
notifications when they are attended is soon. Another feature of the application is a
possibility to manage multiple tickets for different queues, allowing the waiting in
multiple queues at the same time.
Keywords: Remote queues. Queue management. Raspberry Pi. Django. Android.
LISTA DE FIGURAS
Figura 1 - Sistema de filas bsico. ............................................................................ 14
Figura 2 - Filas lineares em diferentes configuraes. .............................................. 15
Figura 3 - Tickets retirados pelo sistema FASTPASS ............................................... 17
Figura 4 - Jornada de um cliente em uma sistema de fila remota. ............................ 19
Figura 5 - componentes de hardware presentes no Raspberry Pi 3 model B ........... 21
Figura 6 - Atualizando informaes de senhas retiradas. ......................................... 29
Figura 7 - Diagrama de casos de uso do sistema SmartLine .................................... 30
Figura 8 - Diagrama de classes do sistema SmartLine ............................................. 31
Figura 9 Login para o painel administrativo do SmartLine ..................................... 37
Figura 10 - Painel administrativo do SmartLine ......................................................... 37
Figura 11 - Formulrio para criao de conta de usurio. ......................................... 38
Figura 12 - Formulrio para a criao de filas (parte 1). ........................................... 39
Figura 13 - Popup com formulrio para a criao de servios. ................................. 39
Figura 14 - formulrio para a criao de filas (parte 2) .............................................. 40
Figura 15 - Formulrio para a criao de terminais. .................................................. 40
Figura 16 - Representao da nova fila criada. ......................................................... 41
Figura 17 - Display informativo exibindo informaes sobre a fila 1. ......................... 42
Figura 18 - Mensagem de erro exibida no display. .................................................... 44
Figura 19 - O dispensador virtual de senhas. ............................................................ 45
Figura 20 - Senha retirada no dispensador virtual..................................................... 45
Figura 21 - Estado atual da senha. ........................................................................... 46
Figura 22 - Tela de autenticao para conexo em terminais. .................................. 47
Figura 23 - Terminal da Balana 01 conectado. ........................................................ 47
Figura 24 - Menu da pgina do terminal. ................................................................... 49
Figura 25 - Controle bluetooth VX Case Compact. ................................................... 50
Figura 26 Transio entre a atividade principal e o leitor de QR Code.. ................ 51
Figura 27 - Senha informativa. .................................................................................. 52
Figura 28 - Nova senha retirada. ............................................................................... 53
Figura 29 - Lista de senhas retiradas. ....................................................................... 54
Figura 30 Registrando-se no Firebase. .................................................................. 55
Figura 31 - Recebendo notificaes atravs do Firebase. ........................................ 56
Figura 32 - cone indicador de notificao. ................................................................ 57
Figura 33 - Senha com atendimento finalizado. ........................................................ 57
LISTA DE TABELAS
Tabela 1 - Modelos, configuraes e preos do Raspberry Pi .................................. 20

SUMRIO
1. INTRODUO ................................................................................................... 11
1.1 - Objetivos ........................................................................................................... 12
1.1.1 - Objetivos gerais ............................................................................................. 12
1.1.2 - Objetivos Especficos ..................................................................................... 13
2 FUNDAMENTAO TERICA ........................................................................... 13
2.1 - Processo de Filas Bsico .................................................................................. 13
2.2 - Psicologia das Filas .......................................................................................... 16
2.3 - Filas Virtuais e Remotas ................................................................................... 17
2.4 RasPberry Pi .................................................................................................... 19
2.5 Django .............................................................................................................. 21
2.6 Android ............................................................................................................. 23
2.6.1 Android Studio ............................................................................................... 23
2.6.2 Barcode Scanner API .................................................................................... 23
2.6.3 Google Firebase ............................................................................................ 24
3 METODOLOGIA .................................................................................................. 25
3.1 - Tipo de Pesquisa .............................................................................................. 25
3.2 - Procedimentos .................................................................................................. 25
4 RESULTADOS E DISCUSSO ........................................................................... 26
4.1 - Consideraes Iniciais ...................................................................................... 26
4.2 - Caractersticas .................................................................................................. 27
4.2.1 - SLS - SmartLine Server e a Plataforma Django ............................................. 27
4.2.2 - SLM - SmartLine Mobile e a Plataforma Android ........................................... 27
4.2.3 - Comunicao Entre Aplicaes ..................................................................... 28

4.3 - UML - Modelando o SmartLine ......................................................................... 30
4.3.1 - Diagrama de Casos de Uso ........................................................................... 30
4.3.2 - Diagrama de Classes ..................................................................................... 31
4.4 - Implementao .................................................................................................. 35
4.4.2 - O Display Informativo ..................................................................................... 41
4.4.3 - O Dispensador Virtual e a Senha Retirada .................................................... 44
4.4.4 - Se Conectando a um Terminal ....................................................................... 46
4.4.5 - O Controle Remoto Bluetooth ....................................................................... 49
4.4.6 - SLM - A Aplicao Mvel ............................................................................... 50
4.4.7 - Enviando Notificaes Aos Clientes ............................................................... 54
4.4.8 - Monitorando a Atividade dos Usurios ........................................................... 58
5 - Consideraes Finais ........................................................................................... 58
5.1 - Concluso ......................................................................................................... 58
5.2 - Trabalhos Futuros ............................................................................................. 59
6 REFERNCIAS....................................................................................................60
1. INTRODUO
Desde a revoluo industrial, os centros urbanos vm aumentando rapidamente. Em

1995 haviam 22 grandes cidades e 14 megacidades no mundo, nmeros que
dobraram em 2015 (MORENO, ARIMAH, et al., 2016). Dados do IBGE confirmam o
aumento da urbanizao em territrio brasileiro: entres os anos 2000 e 2010, cerca
de 23 milhes de pessoas ingressaram em reas urbanas, um aumento de 3,2%
(Censo Demogrfico 2010).
A urbanizao rpida e intensa que ocorreu a partir da revoluo industrial tem
gerado problemas para os setores de atendimento ao pblico, pois criou gargalos
devido ao aumento da demanda por bens e servios. No momento em que a
demanda por servios excede a capacidade do sistema de atender a essa demanda,
formam-se as filas (PAGLIARUSSI, 2016). Tornou-se comum a perda de horas em
funo de congestionamentos nas estradas, filas em bancos, shoppings, mercados e
outros estabelecimentos. S nos EUA, estima-se que a populao gaste, por ano, 37
bilhes de horas em filas (FITZSIMMONS e FITZSIMMONS, 2014).
Esse aumento crescente da demanda por servios e da competitividade do
mercado, tem feito com que administradores pensem na melhor maneira de atenuar
os efeitos negativos da espera e aumentar a satisfao do cliente, fazendo da
qualidade do servio prestado um diferencial. Segundo Baterson e Hoffman (2016),
"quanto maior a satisfao, maior a manuteno de clientes e, quanto maior o
ambiente de competio, maior a necessidade de se alcanar ndices superiores de
satisfao do cliente".
O aborrecimento e o desconforto causados pela sensao de tempo perdido
frequente em filas de espera, e desconsiderado na maioria dos modelos estatsticos
da teoria das filas ou modelos oriundos de simulaes. Entretanto, existem alguns
estudos enfatizando esses e outros efeitos psicolgicos recorrentes em filas. Larson
(1987) destaca a injustia social, o tempo ocioso e a falta de feedback como alguns
dos principais fatores que aborrecem aqueles que precisam aguardar atendimento.
O autor prope que os estabelecimentos ocupem o tempo ocioso dos clientes com
algum tipo de atividade, fazendo com que eles no percebam que esto esperando.
As expectativas do cliente afetam diretamente a maneira como ele se sente com
relao a fila e ao tempo esperado. A incerteza de no saber quanto tempo ter que
aguardar para ser atendido e a falta de informao sobre o motivo da demora
tendem a deixar o cliente estressado e insatisfeito com os servios.
Com o objetivo de possibilitar um melhor uso do tempo por parte dos clientes e
maior estabilidade no atendimento, os gerentes da Disney implementaram um
sistema de fila virtual que consistia, basicamente, em permitir que os clientes
retirassem tickets com perodo de retorno impresso. Com o perodo de retorno
definido, os clientes passaram a consumir outros servios do parque enquanto
aguardavam virtualmente na fila. Para o parque, os tickets tinham a funo de
distribuir uniformemente a frequncia absoluta de entrada na fila durante o dia e,
dessa forma, controlar a estabilidade do sistema. Com a implantao do novo
sistema de filas virtuais, o tempo de espera nas filas caiu consideravelmente, vindo a
ser implementado em todos os parques Disney (DICKSON, FORD e LAVAL, 2005).
De acordo com Karu (2013), quando se trata de ocultar o tempo de espera
percebido, a fila virtual acaba sendo pouco eficiente em ambientes monofuncionais
em reas isoladas, uma vez que o cliente fica sem opes para investir o tempo
ocioso. O mesmo autor prope um sistema de fila remota, visando uma maior
interatividade e transparncia com o cliente, e possibilitando um planejamento prvio
do tempo.
No sistema de fila remota, o cliente retira tickets virtuais - atravs de aplicativo
instalado no smartphone do prprio cliente e acompanha as mudanas de estado
da fila, podendo, com isso, se ausentar fisicamente da fila enquanto aguarda, e
possibilitando planejar o uso do seu tempo para chegar no momento exato em que
dever ser atendido.
1.1 - OBJETIVOS
1.1.1 - Objetivos gerais
Este trabalho teve como objetivo mitigar o desconforto causado pelo tempo ocioso,
despendido pelos clientes, em filas de espera situadas em estabelecimentos
comerciais. Beneficiando, assim, tanto os clientes quanto os donos desses
estabelecimentos.
1.1.2 - Objetivos Especficos
Para alcanar o objetivo geral, foi necessrio:

Revisar a teoria inerente aos principais conceitos de gerenciamento de
filas de espera;
Propor um sistema computacional capaz de dispensar a presena do
cliente na rea da fila, possibilitando que o mesmo possa realizar outras
tarefas enquanto aguarda atendimento;
Representar, atravs da UML, as principais funes do sistema,
modelando a soluo proposta;
Implementar a soluo em um Raspberry Pi 3 model B, utilizando o
framework Django, a fim de minimizar os custos de implantao e o tempo
de desenvolvimento;
Implementar um aplicativo para smartphone, capaz de dispensar senhas e
notificar o cliente quando houver mudana relevante no estado da fila;
Desenvolver um mdulo capaz de se comunicar com uma impressora
trmica, a fim de dispensar senhas para o cliente que no puder ( ou no
quiser) usar o aplicativo;
2 FUNDAMENTAO TERICA
2.1 - PROCESSO DE FILAS BSICO
Esperar por um servio uma situao comum. Seja no banco, no supermercado ou

no hospital, um dia ou outro estaremos sujeitos a esperar por um servio. Nessa
situao, normal que se forme um sistema de filas de espera.
Um sistema de filas pode ser definido como clientes chegando, esperando pelo
servio (se no forem atendidos imediatamente) e saindo do sistema aps terem
sido atendidos (WIKIPDIA, 2017). O processo de filas bsico assumido pela
maioria dos modelos filas o seguinte: Clientes, demandando algum servio, entram
no sistema atravs de uma fonte de entrada; Esses clientes entram em uma
estrutura do sistema chamada Fila; Em algum momento, um dos clientes
selecionado seguindo uma regra conhecida como disciplina da fila; O mecanismo de
atendimento realiza o atendimento necessrio ao cliente selecionado; Finalizado o
atendimento, o cliente sai do sistema de filas (HILLIER e LIEBERMAN, 2006). O
processo representado na Figura 1.
Figura 1 - Sistema de filas bsico.
Fonte: (HILLIER e LIEBERMAN, 2006)
Uma classe muito comum de sistemas de filas aquela pertencente aos sistemas de
atendimento comercial, onde clientes externos recebem atendimento de
organizaes comerciais. Essa classe envolve atendimento pessoa a pessoa, em
uma rea fixa, como em caixas de supermercado, barbearia, caixas em um banco ou
em parque de diverso. Em sistemas de atendimento comercial, as entidades que
entram na fila so os clientes do estabelecimento, enquanto o mecanismo de
atendimento se refere aos funcionrios do estabelecimento.
Filas podem ser configuradas de vrias formas. Filas de espera podem ser divididas,
basicamente, entre lineares, virtuais e remotas.
Filas lineares so aquelas em que os clientes se organizam, presencialmente, em
uma rea fixa do estabelecimento comercial e o tipo mais comum de fila de
espera. Esse tipo de fila pode ser configurado das seguintes formas:
Single-Queue-Single-Service-Point (SQSSP) - clientes se organizam em uma fila

nica e so atendidos atravs de um nico canal de atendimento;
Multiple-Queue-Multiple-Service-Points (MQMSP) - os clientes se organizam em
duas ou mais filas na rea de espera e so atendidos atravs de vrios canais de
atendimento, cada canal com sua respectiva fila e atendente;
Single-Queue-Multiple-Service-Points (SQMSP) - os clientes se organizam em uma
nica fila e so atendidos atravs de vrios canais de atendimento, cada canal com
seu respectivo atendente (GUPTA, 1992).
Figura 2 - Filas lineares em diferentes configuraes.
Fonte: Prprio (2017)
J nas filas virtuais, os clientes no se limitam a nenhum ponto de espera especfico

e, portanto, no esto conscientes da posio que eles tm na fila em relao aos
outros clientes (KARU, 2013). Para manter a disciplina da fila, o estabelecimento
proporcionar algum mecanismo de chamada de clientes, que pode ser um display
responsvel por exibir o nome ou a senha do prximo cliente a ser atendido. As filas
virtuais sero melhor exploradas na seo 2.3.
Assim como as filas virtuais, as filas remotas tambm no limitam os clientes a
permanecerem em uma rea de espera especfica. A principal caracterstica da fila
remota a transparncia ao que acontece no sistema: atravs de um aplicativo
disponibilizado pelo estabelecimento e instalado no smartphone do cliente, outro
software - responsvel por gerir a fila envia notificaes sempre que ocorre um
evento relevante no sistema, possibilitando que o cliente planeje seu tempo presente
no estabelecimento. As filas remotas sero melhor exploradas na seo 2.3.
2.2 - PSICOLOGIA DAS FILAS
Para muitas pessoas, esperar 5 minutos na fila de uma farmcia parece uma espera
interminvel, enquanto os 30 minutos esperando uma bebida na mesa de um bar
com os amigos, parecem passar voando. As pessoas esto dispostas a gastar 50%
de seu tempo em uma visita ao parque de diverses, mas reclamam quando
precisam esperar cinco minutos na fila da cafeteria (MCGUIRE, KIMES, et al.). O
tempo efetivo (aquele medido pelo relgio) e o tempo psicolgico nem sempre
andam no mesmo passo. O primeiro bem definido, mensurvel, e permite
flexibilidade apenas em situaes muito especiais (aquelas descobertas por Einstein
no incio do sculo XX); o segundo puramente de natureza subjetiva, e est sujeito
a situaes e ao ambiente em que o indivduo se encontra.
A fila um dos ambientes onde o tempo percebido e o psicolgico pode chegar a
diferenas considerveis. Segundo pesquisas, essa diferena entre tempos pode
chegar a 36 porcento, em mdia (STONE, 2012). Os psiclogos sugerem que as
filas de espera so repreensveis porque: desperdiam tempo; tiram, do cliente, o
controle da situao; provocam tdio; levam sensao de aglomerao; atrasa a
sensao de gratificao (CARMON, SHANTHIKUMAR e CARMON).
Em geral, as pessoas que aguardam atendimento sem fazer qualquer tipo de
atividade para passar o tempo, alm de ficarem aborrecidas, tendem a superestimar
o tempo de espera. Larson (1987) destaca o tempo ocioso, a "injustia social" e a
falta de feedback como alguns dos principais fatores que aborrecem aqueles que
precisam aguardar atendimento.
Muitos estudos foram realizados com foco no tempo percebido em filas de espera.
Esses estudos podem ser resumidos pelas seguintes afirmaes (DICKSON, FORD
e LAVAL, 2005):
1. Tempo desocupado parece mais longo que tempo ocupado;
2. Clientes ansiosos, tristes e irritados parecem esperas mais que clientes
relaxados;
3. Esperas incertas parecem mais longas que esperas certas;
4. Esperas inexplicadas parecem mais longas que esperas explicadas;
5. Esperas desconfortveis parecem mais longas que esperas confortveis;
6. Esperas injustas parecem mais longas que esperas justas.
2.3 - FILAS VIRTUAIS E REMOTAS
Em 1998, aps vrias tentativas de minimizar as longas esperas e reclamaes

causadas pelas filas das principais atraes do parque temtico Walt Disney World,
os gerentes do parque desenvolveram, pela primeira vez, o conceito de fila virtual. O
sistema consistia em instalar mquinas fora das atraes que possibilitavam que os
clientes inserissem seus ingressos e retirassem tickets para aquela atrao. No
ticket, era impresso um intervalo de tempo para retorno do cliente, levando em
considerao o nmero de pessoas j alocados na fila virtual. Dessa forma, o cliente
poderia andar pelo parque e visitar outras atraes enquanto aguardava o seu
intervalo de retorno.
Figura 3 - Tickets retirados pelo sistema FASTPASS
Fonte: (Tips About Disneyland From a Native Cali Annual Pass Holder, 2012)
Os resultados da instalao do novo sistema foram bem positivos: os clientes

gastaram menos tempo nas filas, consumiram mais, e assistiram mais atraes.
Com o sucesso do sistema, em 1999 ele foi ampliado para mais atraes e batizado
como FASTPASS, vindo a ser instalado em todos os parques da Disney ao redor do
mundo.
O FASTPASS permite a retirada de apenas um ticket por intervalo de tempo. Apesar
da limitao, o sistema permite que o cliente aguarde em uma fila tradicional por
uma atrao menor, permitindo que o mesmo assista duas atraes num intervalo
de tempo que seria ocupado apenas por uma. O intervalo de tempo estimado
tambm se torna til para os gerentes do parque, que podem monitorar a
estabilidade do sistema (DICKSON, FORD e LAVAL, 2005).
A partir de 2013, o sistema recebeu novas funcionalidades e passou a se chamar
FASTPASS+. Dentre os novos recursos, esto: tickets de papel substitudos por
cartes eletrnicos e pulseiras com etiquetas RFID; agendamento de 3 fastpasses
para o dia da visita, podendo agendar fastpasses extras, um por vez, aps o trmino
dos trs primeiros; agendamento de fastpass feito pelo site da Disney (antes da
visita) ou em quiosques espalhados pela parque; reagendamento de fastpass feito
por aplicativo ou site da Disney (NOVAIS, 2014).
As filas virtuais conseguem ter sucesso quando se pretende ocultar o tempo de
espera percebido, mas no para todos os ambientes. No caso da Disney, os clientes
podem entrar na fila virtual e consumir outros produtos e servios no parque
enquanto aguardam a vez na atrao principal. Porm, em ambientes onde se
presta um nico tipo de servio em um local isolado, no h qualquer atividade
alternativa para ocupar o tempo do cliente. Alm disso, quando algum desiste de
esperar e deixa a fila, o tempo agendado para aquele cliente torna-se vago no
sistema um desperdcio, uma vez que outro cliente poderia ser atendido naquele
momento.
Para mitigar os problemas das filas convencionais, Karu (2013) classifica um novo
sistema que atribui uma maior transparncia ao que acontece na fila. Trata-se de um
sistema onde o cliente pode retirar tickets virtualmente, atravs de aplicativo
instalado no smartphone. O aplicativo seria responsvel por exibir o estado atual da
fila e enviar notificaes para o cliente acerca da sua situao na fila. O autor chama
esse sistema de fila remota, e elenca as seguintes vantagens em relao aos outros
sistemas:
1. O cliente pode visualizar a situao do local antecipadamente,
permitindo que ele decida por entrar ou no na fila, evitando, assim,
retiradas de tickets apenas para verificar quantas pessoas esto na
sua frente;
2. Retirar tickets remotamente, permitindo que o cliente tenha um ticket
antes mesmo de chegar na fila, reduzindo, assim, o tempo de espera;
3. O cliente informado sobre o andamento da fila, ajudando-o a chegar
no momento exato em que dever ser atendido, e permitindo se
ausentar enquanto no chega sua vez.
Figura 4 - Jornada de um cliente em uma sistema de fila remota.
Fonte: (KARU, 2013, p. 15)
A Figura 4 ilustra a jornada de um cliente em uma fila remota. A partir do aplicativo

instalado no smartphone, o cliente pode visualizar o status da fila e planejar sua
entrada na mesma, fazendo um uso mais eficiente do tempo. Caso algum cliente
deixe a fila, os demais clientes so informados atravs do aplicativo que, mesmo no
havendo qualquer pessoa presente, realiza constantes atualizaes acerca da fila.
2.4 RASPBERRY PI
O Raspberry Pi um single-board computer (SBC), do tamanho de um carto de

crdito, que pode ser conectado a uma TV e um teclado USB. Ele capaz de
reproduzir vdeos em alta definio e executar vrias tarefas que um PC desktop
executa, como manipulao de planilhas, processamento de textos e jogos
(Raspberry Pi FAQs, 2017).
O projeto mantido pela Raspberry Pi Foundation, sediada no Reino Unido, e foi
desenvolvido com o objetivo de ensinar fundamentos de programao a crianas.
Para isso, a fundao se compromete a desenvolver dispositivos fceis de usar e de
baixo custo (GARRETT, 2014). Em Novembro de 2017, a Raspberry Pi Foundation
anunciou sua primeira revendedora autorizada no Brasil: o loja virtual FilipeFlop
(BRAND NEW AND BLUE: OUR BRAZILIAN RASPBERRY PI 3). Atualmente, a loja
vende o Raspberry Pi model B a partir de R$ 199,00 a unidade (Raspberry Pi 3
Model B Anatel, 2017).
Existem, ao todo, seis modelos oficiais j lanados. A Tabela 1 exibe os diferentes
modelos, configuraes de hardware e preos (em dlar).
Tabela 1 - Modelos, configuraes e preos do Raspberry Pi
Raspberry
Raspberry Pi model Raspberr Rasberry Pi Raspberry Raspberr
Pi A+ y Pi 2 Zero Pi Zero W y Pi 3
B
Lanament 01/02/201 29/02/201

10/11/2014 15/02/2012 30/11/2015 28/02/2017
o 5 6
Preo US$ US$20.00 US$35.00 US$5.00 US$10.00 US$35.00
Broadco Broadco
Broadcom Broadcom Broadcom Broadcom
Tipo Chip m m
BCM2835 BCM2835 BCM2835 BCM2835
BCM2836 BCM2837
Cortex-
ARM1176JZ ARM1176JZ ARM1176JZ ARM1176JZ
Tipo Core Cortex-A7 A53 64-
F-S F-S F-S F-S
bit
N Core 1 1 4 1 1 4
Clock CPU 700 MHz 700 MHz 900 MHz 1 GHz 1 GHz 1.2 GHz
VideoCore VideoCore VideoCor VideoCore VideoCore VideoCor
GPU
IV IV e IV IV IV e IV
512 MB (256
RAM 256 MB 1 GB 512 MB 512 MB 1 GB
- model A)
Wireless X X X X 802.11n 802.11n
Bluetooth X X X X 4.1 4.1
Consumo 200 mA 700 mA 800 mA 160 mA 180 mA 800 mA
Fonte: (WIKIPDIA, 2017)
O Raspberry Pi 3 model B foi o primeiro a incorporar o Bluetooth 4.1 como uma mais
uma opo de conectividade sem fio. Esse tambm o modelo que traz o melhor
desempenho em termos de capacidade de processamento, contando com um
processador de quatro ncleos Cortex-A53 de 1,2 GHz. A Figura 5 ilustra os
componentes de hardware presentes nesse SBC.
Figura 5 - componentes de hardware presentes no Raspberry Pi 3 model B
Fonte: (Raspberry Pi 3 Model B Technical Specifications, 2016)
2.5 DJANGO
Django um framework para desenvolvimento Web escrito em Python, e incentiva o

rpido desenvolvimento, o pragmatismo e a clareza no projeto. Ele gratuito e seu
cdigo aberto (Meet Django, 2017). O framework utiliza o princpio DRY (Dont
Repeat Yourself), onde o desenvolvedor levado a aplicar ao mximo o conceito de
reusabilidade.
Django proporciona um servidor Web de desenvolvimento leve, escrito puramente
em Python, o que evita a necessidade de se configurar um servidor antes de iniciar o
desenvolvimento (Escrevendo seu primeiro app Django, 2017).Outra ferramenta
disponvel uma interface opcional que proporciona a manuteno do contedo do
sistema em tempo de execuo. Essa ferramenta agiliza o desenvolvimento quando
o projeto requer um dashboard para administrao de contedo requisito muito
comum em aplicaes web (The Django Admin Site, 2017).
2.5.1 O Padro MTV
Django adota o padro de projeto MTV (Model-Template-View), muitas vezes

diretamente relacionado ao popular padro MVC (Model-View-Controller).
No padro MVC, o modelo (M) representa os dados e as regras de negcio da
aplicao. O modelo encapsula as funcionalidades da aplicao e, por isso, deve
implementar meios para que o controlador (C) acesse as funcionalidades da
aplicao. O componente de visualizao (V) renderiza o contedo de uma parte do
modelo e encaminha as aes do usurio para o controlador; o mesmo componente
tambm responsvel por acessar, via controlador, os dados do modelo e definir
como esses dados sero exibidos (MACORATTI, 2002).
Apesar das semelhanas com o MVC, o padro MTV utilizado no Django se
diferencia em alguns pontos:
[No MVC], view representa os dados que so apresentados ao usurio.

No necessariamente como a informao apresentada, mas qual
informao mostrada. [J no MTV, ] a view representa qual informao
voc v, no como voc v.
[...]
Onde o controller se encaixa, ento? No caso do Django, provavelmente o
prprio framework - o maquinrio que envia uma requisio para a view
apropriada, de acordo com a configurao de URL do Django. (FAQ: Geral,
2017)
2.5.2 ORM e SQLite
O ORM (Object-relational mapping), um dos principais recursos disponveis no

Django.
Com a tcnica de desenvolvimento ORM, as tabelas do banco de dados so
representadas pelas prprias classes, sendo os registros dessa tabela
representados como instncias das classes (WIKIPDIA, 2017).
Django acompanha, por padro, o banco de dados SQLite. O seu uso
recomendado para iniciantes ou aqueles que querem experimentar o framework.
Caso a seja necessrio um banco de dados mais escalvel, possvel realizar a
troca por quaisquer dos principais bancos de dado relacionais disponveis no
mercado (FAQ: Bancos de Dados e modelos, 2017).
2.6 ANDROID
O Android um sistema operacional baseado em Linux. Seu enfoque so

dispositivos mveis com telas touchscreen, como smartphones e tablets.
Em 2005, a Google comprou Android Inc, uma empresa de Palo Alto, California. A
Android Inc. vinha trabalhando no desenvolvimento de um sistema operacional para
smartphone, visando competir com o Symbian (Nokia) e o Windows Mobile
(Microsoft). O primeiro aparelho com sistema operacional Android foi lanado em
2008 nos Estados Unidos: o HTC Dream (GUIMARES, 2013).
Na conferncia anual Google I/O de 2017, a Google revelou a existncia de mais de
2 bilhes de usurios Android ativos (ROSSIGNOL, 2017). Grande parte desse
sucesso se deve ao fato de seu cdigo ser aberto, o que permite que seu cdigo
seja livremente modificado e distribudo por fabricantes de smartphone no mundo
inteiro (SALUTES, 2017).
2.6.1 Android Studio
O Android Studio o ambiente de desenvolvimento integrado (IDE), baseado no

software IntelliJ IDEA, escolhida pela Google como IDE para desenvolvimento
Android nativo.
Dentre as vrias ferramentas que acompanham a IDE, est o Android Emulator: um
software que permite emular vrios verses do sistema operacional Android e
dispositivos reais, incluindo sensores e diferentes configuraes de hardware (Tudo
de que voc precisa para criar aplicativos no Android, 2017).
2.6.2 Barcode Scanner API
Desenvolvida e disponibilizada gratuitamente pela Google, o Barcode Scanner API

permite decodificar, em tempo real, vrios formatos de cdigos de barra, a partir da
cmera do dispositivo Android. Ele suporta capaz de decodificar os seguintes
formatos:
Cdigos de barra 1D - EAN-13, EAN-8, UPC-A, UPC-E, Code-39, Code-93,
Code-128, ITF, Codabar;
Cdigos de barra 2D - QR Code, Data Matrix, PDF-417, AZTEC.
O Barcode Scanner API faz parte da Mobile Vision API, primeiramente introduzida
na verso 7.8 do Google Play Services, e compatvel com o Android 4.2.2 e
posteriores (Barcode API Overview, 2017).
2.6.3 Google Firebase
Adquirida pela Google em 2014, o Firebase um kit de servios baseados na nuvem

disponibilizados gratuitamente, podendo ser utilizada em diversas plataformas.
Alguns desses servios so:
Firebase Cloud Messaging permite enviar mensagens, gratuitamente, para

usurios em diferentes plataformas. Com este servios, possvel enviar
push de notificaes, para dispositivos, em poucas linhas de cdigo;
Firebase Auth oferece diversos mtodos de autenticao de usurios,
incluindo autenticao por contas do Facebook e Google;
Firebase Database um banco de dados NoSQL utilizado para armazenar
dados JSON;
Firebase Storage servios de armazenamento de objetos, permitindo que o
desenvolvedor armazene e veicule dados gerados pelos usurios;
Google Analytics permite monitorar o comportamento dos usurios, verificar
dados de falha e a gerao de relatrios gratuitos e ilimitados (Firebase
Produtos, 2017).
Essas so apenas cinco dos mais de dez servios oferecidos pelo Google Firebase.
Os servios so gratuitos para os que querem conhecer as funcionalidades do
Firebase, mas tambm oferece um plano flexvel, com preos baseados em
consumo, para aqueles que quiserem uma integrao total ao sistema (AVRAM,
2016).
3 METODOLOGIA
3.1 - TIPO DE PESQUISA
Segundo Jung (2004) e observando a luz do mtodo cientfico, chega-se a

concluso de que este projeto de natureza aplicada, com objetivos de carter
exploratrio, utilizando procedimentos experimentais.
Por fazer uso dos conhecimentos da engenharia de software e conhecimentos
bsicos sobre gerenciamento de filas para a criao de um novo produto que,
neste caso, seria um gerenciador de filas remotas -, este projeto caracteriza-se como
sendo de natureza aplicada.
Os objetivos so de carter exploratrio, pois pretende-se obter um novo produto de
software, caracterizando-se como inovao tecnolgica.
Os procedimentos utilizados so experimentais, pois foram desenvolvidos dois
softwares: um embarcado num single-board computer, e outro instalado em
smartphones.
3.2 - PROCEDIMENTOS
Para a concretizao deste trabalho, foi feito um estudo sobre os diferentes tipos
sistemas de filas bsicas e as formas de gerenci-las, assim como os efeitos
negativos que o ato de esperar, em filas, causa nos clientes. Paralelamente, foram
feitos estudos acerca do framework de desenvolvimento Web Django, da plataforma
de desenvolvimento para dispositivos mveis Android e o SBC (single-board
computer) Raspberry Pi.
Aps a fase de aquisio de conhecimento, deu-se incio ao desenvolvimento.
Primeiramente, foi feita a modelagem do sistema a partir da UML. Para a
implementao, foi utilizado um Raspberry Pi 3 Model B.
Para auxiliar no desenvolvimento da aplicao Django, foi utilizada o IDE PyCharm
Community Edition verso 2.3 juntamente com o template SB Admin 2 Bootstrap
(para a implementao da interface) e o framework Django verso 1.11.6.
Para a implementao do aplicativo, foi utilizado o IDE Android Studio verso 3.0 e o
Android SDK 26 para a compilao do cdigo.
Aps o desenvolvimento do aplicativo, foram feitos testes atravs do Android
Emulator 2.0 simulando um smartphone Nexus One (API 22), relativa ao Android 5.1
(Lollipop).
Um controle remoto bluetooth foi utilizado como boto chamador de senhas. Embora
tenha sido implementada uma interface Web para a chamada de clientes, ter um
meio "offline" de chamada acaba sendo uma boa soluo em ambientes com
limitao de espao ou infraestrutura de rede. Foi utilizado um controle de basto de
fotos VX Case Compact, composto de 3 botes e uma bateria interna recarregvel.
Por limitaes financeiras, no foi possvel adquirir uma impressora trmica para a
impresso dos tickets. No entanto, foi implementado uma interface Web simulando
as funcionalidades do dispensador fsico.
4 RESULTADOS E DISCUSSO
4.1 - CONSIDERAES INICIAIS
Ao fim da pesquisa realizada, obteve-se como resultado o SmartLine: um prottipo

de sistema gerenciador de filas remotas. O sistema composto por duas aplicaes
remotas, uma assumindo o papel de servidor e a outra o cliente.
Uma dessas aplicaes responsvel por gerenciar as filas (o servidor), e
implementa as regras de negcio do sistema. Essa aplicao, que recebeu o
acrnimo de SLS (SmartLine Server), foi implementada em Django e instalada num
Raspberry Pi 3 model B.
A outra aplicao, chamada SLM (SmartLine Mobile), foi implementada para a
plataforma Android e responsvel por gerenciar as senhas (tickets) do cliente,
assim como disparar notificaes de acordo com o estado da fila e a senha do
cliente.
Nas prximas sees, so apresentadas as principais caractersticas e funes do
sistema, assim como a modelagem UML gerada a partir da soluo proposta. A
seguir, sero apresentados detalhes de implementao do sistema como um todo.
4.2 - CARACTERSTICAS
4.2.1 - SLS - SmartLine Server e a Plataforma Django
A plataforma de desenvolvimento web Django, por ser uma ferramenta que j

implementa alguns servios comuns s aplicaes web - como servios de
autenticao, sistema de cache e painel administrativo -, torna o desenvolvimento
desse tipo de aplicao muito mais rpido. Haja vista essas caractersticas e o fato
de ser escrito em Python, Django foi escolhido como framework para o
desenvolvimento do SLS.
Seguindo o padro MTV (model-template-view) do framework, foi possvel dividir
apresentao (template), controle (view) e modelo (model) com as facilidades que o
framework apresenta: aps a modelagem da soluo a partir da UML, foram
implementadas as classes em Python; como Django conta com um ORM, as tabelas
do banco de dados so representadas pelas prprias classes implementadas, o que
agiliza ainda mais o desenvolvimento.
Por se tratar do desenvolvimento de um prottipo, este trabalho permaneceu com as
configuraes padres de banco de dados. Portanto, neste projeto, o SQLite foi
mantido como banco de dados do SLS.
As apresentaes visuais (templates) foram, quase todos, implementados com
Bootstrap, visando a responsividade e rapidez no desenvolvimento. Apenas uma
template no foi desenvolvida em Bootstrap: o Display, cuja funcionalidade exibir o
status atual da fila e emitir avisos sonoros quando uma nova senha chamada.
Como o SLS foi todo codificado em Python e HTML5, foi possvel desenvolv-lo num
ambiente desktop e, posteriormente, ser instalado no Raspberry Pi 3 com o mnimo
de esforo de implantao.
4.2.2 - SLM - SmartLine Mobile e a Plataforma Android
A necessidade de um aplicativo instalado no smartphone do cliente, surgiu a partir

da necessidade de notificar o cliente dadas certas situaes. Uma soluo mais
simples seria o envio de mensagens SMS. Porm, outras funcionalidades no
poderiam ser implementadas a partir de trocas de mensagens SMS, pois tornaria a
comunicao onerosa, visto que, na maioria dos casos, o servio de envio de SMS
no gratuito. Alm disso, a interatividade seria prejudicada, uma vez que a
comunicao seria feita atravs de trocas de mensagens de texto.
Como no haveria tempo suficiente para desenvolver um aplicativo para cada
plataforma ou estudar um framework capaz de auxiliar no desenvolvimento de um
aplicativo multi-plataforma, optou-se pela plataforma mobile que abarcasse a maior
fatia do mercado, que neste caso o Android .
A verso da plataforma, escolhida para este projeto, foi o Android 4.4 (apelidada de
Kitkat). Sua respectiva API est na verso 19 e seus aplicativos so compatveis
com mais de 90% dos smartphones Android, segundo o ambiente de criao de
projetos do Android Studio.
4.2.3 - Comunicao Entre Aplicaes
Este projeto fez uso da arquitetura cliente/servidor, com o SLS assumindo o papel de
servidor e os as instncias do SLM assumindo o papel de clientes.
O SLS, na implementao deste projeto, opera de forma passiva na maior parte do
tempo, o que significa dizer que os clientes precisam assumir a iniciativa da
comunicao. Portanto, para consultar o status de uma dada fila, por exemplo, uma
instncia do SLM precisaria realizar pulling com uma certa frequncia. Como o
status da fila no se altera o tempo inteiro, fcil concluir que muitas das
requisies por status retornaro dados repetidos. Essa desvantagem era sabida
antes da implementao do sistema, no entanto optou-se por manter essa estratgia
devido a limitaes de tempo de desenvolvimento.
Para a troca de mensagens, foi utilizado o formato JSON, devido a sua facilidade de
interpretao e gerao, alm de ser independente de linguagem de programao.
A Figura 6 ilustra o diagrama de sequncia para as atualiza de informaes de
senhas.
Figura 6 - Atualizando informaes de senhas retiradas.
O processo de atualizao comea a partir da entrada de uma nova senha na

instncia de SLM Updater. Logo aps a retirada de uma nova senha (requisitada
pelo cliente), o SLM instancia um objeto Senha e adiciona esse objeto lista de
senhas do SLM Updater.
O SLM Updater a classe responsvel por requisitar e atualizar informaes sobre
cada senha retirada pelo cliente. Para cada senha na lista, o SLM Updater realiza o
seguinte procedimento:
1. Cria uma thread para chamar a view info_senha (implementada no

SLS), enviando a identificao da senha em formato JSON;
2. Recebe o retorno de info_senha e atualiza as informaes da senha;
3. Envia a lista de senhas atualizada para o SLM.
Os mesmos procedimentos acontecem quando o cliente requisita, manualmente, a

atualizao de uma senha especfica. Este mtodo ser discutido na seo 4.4.5
deste captulo.
4.3 - UML - MODELANDO O SMARTLINE
Considerando as pesquisas realizadas para este trabalho, pode-se chegar a

confeco de modelos UML que representassem uma soluo que satisfizesse o
objetivo do trabalho: mitigar o desconforto em filas de espera.
Na subseo 4.3.1 , ser confeccionado um diagrama de casos de uso, onde ser
possvel visualizar os atores e suas relaes com as principais funcionalidades do
sistema. Em seguida, na subseo 4.3.2, ser confeccionado o diagrama de classes.
4.3.1 - Diagrama de Casos de Uso
A Figura 7 apresenta o diagrama de casos de uso do SmartLine. Compem o

sistema: trs autores e onze funcionalidades.
Figura 7 - Diagrama de casos de uso do sistema SmartLine
Clientes podem retirar senhas, descartar senhas e acompanhar o status da fila. O

tipo de senha varia de acordo com o servio e a prioridade - atributos definidos pelo
cliente durante a retirada da senha. Pode ser retirado mais de uma senha por
cliente, desde que cada senha esteja vinculada a uma fila diferente.
O atendente o responsvel por chamar senhas, rechamar senhas e retroceder
chamada. Ele o prestador de servio do canal de atendimento, e deve realizar
login para estar apto a realizar atendimentos.
O gerente assume o papel administrativo do sistema. Gerentes podem realizar
manuteno nos perfis de atendentes, nos servios prestados por cada fila e
tambm nas prprias filas. Apesar do grande poder atribudo a esse ator, o gerente
no capaz de afetar a organizao da fila, nem manipular senhas de clientes.
Todos os atores do sistema devem acompanhar o status da fila.
4.3.2 - Diagrama de Classes
De acordo com Guedes (2011), o principal enfoque do diagrama de classes

possibilitar a visualizao das classes, seus atributos e mtodos, bem como
demonstrar a maneira com que essas classes se interagem. A Figura 8 apresenta o
diagrama de classes do SmartLine.
Figura 8 - Diagrama de classes do sistema SmartLine

O gerente de filas deve criar filas e terminais, assim como gerenciar as contas dos
atendentes que se conectaro aos terminais. Ao criar uma nova fila, o gerente deve
definir quais servios sero prestados nela. Esses servios podero ser criados pelo
gerente antes ou durante o processo de criao da fila. O gerente tambm
responsvel por ativar e desativar filas (mtodos ativar e desativar da classe Fila).
Filas ativas esto liberadas para receber novas senhas, enquanto as desativadas
no s esto inaptas a receber senhas como tambm tem todas as suas senhas,
anteriores desativao, descartadas.
Tendo cadastrado a fila e seus servios, o gerente tem a opo de gerar um QR
Code para a fila, bastando, para isso, chamar o mtodo gerarQRCode,
especificando um servio e se as senhas retiradas a partir do QR Code sero ou no
do tipo preferencial. O mtodo retorna o caminho para o arquivo PNG contendo o
QR Code. Esse arquivo nomeado pelo prprio mtodo, e segue o padro:
<nome-da-fila>_<prefixo-do-servico>_<preferencial-ou-comum>.png
Ao entrar no estabelecimento, o cliente ter duas opes para retirar senhas: ler o
QR Code a partir do SLM (mtodo lerQRCode) ou a partir da impressora trmica.
Optando pelo SLM, o cliente receber como resultado da leitura uma senha
disponvel contendo uma estimativa do tempo de espera para aquela senha e o
nmero de pessoas sua frente. Essa senha ainda no pertence ao cliente, e no
entra na fila de fato. Ela serve para o cliente obter informaes sobre a fila e planejar
a sua entrada na mesma. Ao receber a senha informativa, o SLM exibe dois botes,
logo abaixo das informaes sobre a fila:
Boto Entrar - ao clicar nesse boto, o SLM chama o mtodo

retirarSenha implementado pela classe Fila, passando como parmetro
o servio desejado, o UUID (Universal Unique Identifier - identificador
nico gerado pelo SLM e utilizado para identificar clientes) e o tipo de
senha (preferencial ou no). O mtodo retorna uma senha que
atribuda unicamente para aquele usurio. A partir do momento em que
um usurio retira uma senha para uma dada fila, no poder retirar
outras senhas para aquela mesma fila, mesmo que seja para outro
servio;
Boto Descartar - ao clicar nesse boto, o SLM retorna para o leitor de
QR Code.
Uma vez retirada, a senha vai para a lista de senhas no SLM. A lista ordena as
senhas de acordo com o instante em que so retiradas (senhas retiradas primeiro,
ficaro no topo da lista). Cada senha exibe: o prefixo do servio concatenado com
identificador de tipo de senha, o nmero da senha, o tempo previsto para o
atendimento, nmero de pessoas frente do cliente e a situao da senha. Alm
das informaes sobre a senha, abaixo de cada senha o SLM exibe dois botes:
Boto Renew - clicando nesse boto, o SLM chama o mtodo

infoSenha da classe Senha, que retorna dados atualizados sobre o
tempo de espera previsto para aquela senha, o nmero de pessoas
frente na fila e a situao da senha.
Boto Descartar - clicando nesse boto, o SLM chama o mtodo
descartar da classe Senha. Ao descartar uma senha, ela sai da lista de
senhas do SLM e no poder ser chamada nem receber notificaes
sobre o status da fila.
Optando por retirar uma senha atravs da impressora, o cliente deve pressionar o
boto da impressora que corresponde fila, servio e tipo de senha que ele deseja.
A senha impressa conter: o prefixo do servio concatenado com identificador de
tipo de senha, o nmero da senha, o tempo previsto para o atendimento e o nmero
de pessoas sua frente. Com essas informaes, o cliente pode planejar sua
entrada na fila.
Para estar apto a chamar senhas, um atendente deve efetuar login em um terminal
disponvel. Ao efetuar login, o mtodo conectarTerminal da classe Terminal
chamado, recebendo como parmetro o atendente que ficar alocado naquele
terminal. Estando alocado ao terminal, o atendente pode iniciar os atendimentos a
partir do mtodo chamarSenha da classe Terminal. Ao chamar uma senha, uma
notificao ser enviada para a o cliente que possuir a senha chamada - isso,
claro, se o cliente possuir o SLM instalado no smartphone. Caso haja algum atraso
na chegada do cliente ao terminal, o atendente poder realizar uma rechamada a
partir do mtodo rechamarSenha da classe Terminal. Assim como chamarSenha,
esse mtodo tambm envia uma notificao para o cliente que possui a senha
chamada.
H casos onde o atendente quer desfazer uma chamada e chamar uma senha
anterior. Isso tambm poder ser feito chamando o mtodo retrocederChamada da
classe Terminal. Assim como os dois mtodos anteriores, o possuidor da senha
receber uma notificao de chamada.
A indicao de que um atendimento foi finalizado a realizao de uma nova
chamada. Sendo assim, o atendimento de uma senha ser finalizado sempre que
uma nova chamada for realizada.
Uma senha, uma vez finalizada, recebe o status atendimento finalizada. Senhas
finalizadas permanecem na lista de senhas do SLM, mas no recebem atualizaes
sobre o status da sua respectiva fila.
As possveis situaes que uma senha pode assumir so:
senha disponvel - quando um usurio l o QR Code de uma

determinada fila, o que ele recebe como resultado uma senha
disponvel. Como dito anteriormente, senhas disponveis serve apenas
para apresentar estatsticas sobre a fila e dar ao cliente a possibilidade
de planejar a sua entrada na fila;
aguardando atendimento - a senha j est vinculada a um usurio e
est aguardando atendimento na fila;
prxima a ser chamada - a senha ser a prxima da fila a ser
chamada;
em atendimento - essa situao indica que a senha est em
atendimento no finalizado;
atendimento finalizado - o atendimento para aquela senha j foi
finalizado;
senha descartada - a senha foi descartada pelo cliente ou o sistema a
descartou devido a desativao da fila.
O atendente poder efetuar logout e se desconectar do terminal a qualquer
momento (mtodos doLogout da classe Atendente e desconectarTerminal da classe
Terminal).
4.4 - IMPLEMENTAO
Na prxima seo sero discutidos detalhes de implementao, tanto do SLM

quanto do SLS, e como essas duas aplicaes se comunicam entre si, que tipo de
informaes elas trocam e em quais situaes as mensagens so trocadas.
Tambm ser explicado, em detalhes, como feita a interao do sistema com os
usurios.
4.4.1 - Instalao e Operaes Administrativas do SLS
O SLS foi desenvolvido num desktop com processador Intel e sistema operacional
Linux, mas foi instalado em um Raspberry Pi 3 model B com processador ARM e
sistema operacional Raspbian (distribuio Linux customizada para o Raspberry).
Todo o cdigo foi escrito em Python 3 utilizando o framework Django.
Apesar das diferenas entre ambiente de desenvolvimento e ambiente de produo,
no houve qualquer problema no processo de implantao, graas ao interpretador
Python 3 disponvel para ambos os ambientes.
No Raspbian foi necessrio instalar, alm do interpretador Python 3, o framework
Django e o mdulo bluetooth para o Raspberry receber os eventos de bluetooth do
controle remoto.
Para a instalao do sistema, basta copiar os arquivos do SLS para o diretrio que
desejar. Isso pode ser feito remotamente via SSH ou localmente com um pendrive.
Em uma primeira instalao, ser necessrio criar uma instncia do banco de dados,
assim como a conta administrativa do mesmo.
Para instanciar o banco de dados, execute os comandos:
> python3 manage.py makemigrations

> python3 manage.py migrate
O primeiro comando diz ao Django que foram feitas alteraes no modelo e que
deseja-se que essas alteraes sejam armazenadas como uma migrao. Essas
migraes contm comandos SQL para efetuar as alteraes no banco de dados.
Como estamos instalando o SLS e no temos qualquer instncia do banco de
dados, o arquivo de migrao gerado ter comandos SQL para a criao do banco e
de todas as tabelas suas tabelas.
O segundo comando executa os comandos SQL contidas no arquivo de migrao,
efetuando a criao do banco de dados e suas tabelas.
Em seguida, necessrio criar uma conta administrativa para o banco de dados
criado. Essa conta assume o papel de gerente do sistema, portanto ela
indispensvel para o seu funcionamento.
O seguinte comando inicia o processo de criao da conta administrativa:
> python3 manage.py createsuperuser
O Django solicitar um nome para a conta de administrador; em seguida, ser

solicitado um endereo de e-mail; e por ltimo, ser solicitada uma senha para nova
conta.
E assim termina a instalao do sistema.
Para executar o SLS, basta efetuar o seguinte comando no terminal:
> python3 manage.py runserver <ip>:<porta>
Onde <ip> se refere ao IP atribudo interface em que o Raspberry est conectado;

e <porta> a porta na qual o SLS escutar as requisies dos clientes.
Esse comando executar o servidor de desenvolvimento do Django. Esse servidor
no deve ser utilizado num ambiente de produo, mas como se trata de um
prottipo, no h problema em utiliz-lo, por enquanto.
Supondo que o comando foi executado da seguinte forma:
> python3 manage.py runserver 192.168.0.1:8080

Ao digitar o endereo 192.168.0.1:8080/admin no navegador Web, dever ser
exibida a tela de acesso como ilustrada na Figura 9.
Figura 9 Login para o painel administrativo do SmartLine
O gerente dever informar o seu usurio e sua senha criados no processo de

instalao dos sistema. Feito isso, o gerente ser direcionado para o painel
administrativo, ilustrado na Figura 10.
Figura 10 - Painel administrativo do SmartLine
No bloco AUTENTICAO E AUTORIZAO o gerente faz a manuteno das

contas de atendentes. Apenas o gerente tem o poder de criar contas para os
atendentes, e isso inclui definir senhas para os mesmos.
Para criar uma nova conta de atendente, basta clicar em Adicionar, ao lado do
campo Usurios. Isso levar para o formulrio de criao de contas de usurios,
ilustrado na Figura 11.
Figura 11 - Formulrio para criao de conta de usurio.
Basta definir um nome de usurio e uma senha para o novo atendente, clicando em
Salvar para efetuar a operao.
Fazer a manuteno de filas, servios e terminais, tambm simples: na seo
SMARTLINE, basta clicar em Adicionar ao lado do campo referente ao objeto que se
quer criar.
Para criar uma fila, por exemplo, basta clicar em Adicionar ao lado do campo Filas.
O gerente ser direcionado ao formulrio de criao de filas, como ilustrado na
Figura 12.
Figura 12 - Formulrio para a criao de filas (parte 1).
Alm dos campos referentes prpria fila, o gerente precisar informar os servios
prestados naquela fila (campo Servios prestados). Como pode ser observado na
Figura X, no h qualquer servio disponvel para cadastro na fila, mas o gerente
poder adicionar um novo servio clicando no sinal + e preenchendo o formulrio
apresentado no popup que se apresenta como ilustrado na Figura 13.
Figura 13 - Popup com formulrio para a criao de servios.
Tendo definido o nome da fila, uma mensagem informativa e os servios prestados,

o gerente deve optar por marcar o checkbox de atividade da fila: marcando o
checkbox, o gerente mantm a fila ativada e pronta para receber novas senhas;
deixando o checkbox desmarcado, a fila ficar desativada.
Alm dos campos mencionados, poder ser informado o caminho para uma imagem
que sirva como papel de parede para o display que exibir as informaes sobre a
fila. Da mesma forma, poder ser informado o caminho para um arquivo de vdeo
que tambm ser exibido no display.
O ltimo campo a ser preenchido a Localizao, e tambm utilizado pelo display
para exibir a temperatura da cidade em que a fila est instalada. A Figura 14 ilustra
os ltimos campos mencionados.
Figura 14 - formulrio para a criao de filas (parte 2)
Tendo criada a fila e seus servios, resta criar ao menos um terminal para que o
sistema esteja pronto para operar.
Voltando pgina inicial e clicando em Adicionar ao lado do campo Terminais, o
gerente ser direcionado para o formulrio de criao de terminais, como ilustrado
na Figura X.
Figura 15 - Formulrio para a criao de terminais.

Neste formulrio, o gerente dever informar a fila na qual o terminal ser vinculado,
o tipo de local em que esse terminal se encontra e o nmero do terminal. Esto
disponveis 7 tipos de terminais diferentes: Atendente, Balana, Balco, Bancada,
Caixa, Guich e Local. O nmero um valor numrico definido pelo prprio gerente.
O ltimo campo desse formulrio se refere ao nmero MAC do controle remoto
bluetooth que chamar senhas em nome do terminal. Esse campo no obrigatrio
e pode ser deixado em branco.
Ao fim desse processo de cadastro de servios, terminais e filas, o SLS estar
pronto para gerenciar as filas ativas. Para exibir a lista das filas cadastradas, basta ir
at a pgina inicial do painel administrativo e clicar no nome Filas. Ser exibida uma
lista com os IDs das filas seguidos por seus respectivos nomes. Na Figura 16
possvel ver uma fila criada com ID 1 e nome Fila do Aougue.
Figura 16 - Representao da nova fila criada.
4.4.2 - O Display Informativo
Um display estar disponvel para cada fila ativada.

A funo do display exibir o status da fila e emitir avisos sonoros quando uma nova
senha for chamada. Ele foi desenvolvido para executar em qualquer navegador que
suporte HTML5. No Raspbian, o navegador padro o Chromium - um navegador
de cdigo-aberto no qual o Google Chrome se baseia. O desempenho desse
navegador na reproduo de vdeos se mostrou, empiricamente, bem superior ao
demais navegadores disponveis para o Raspbian. Por isso, ao utilizar o display no
Raspberry Pi, recomendado que se utilize o Chromium como navegador.
Supondo que se queira apresentar o display da Fila do Aougue apresentada na
Figura 16, basta digitar o seguinte endereo no navegador:
<ip>:<porta>/smartline/display/1
Onde <ip> e <porta> so o IP e a porta especificados na execuo do servidor Web.

O nmero 1 no final da URL se refere ao ID da fila que se quer acompanhar. Feita a
requisio por essa pgina, o Django retornar a template, renderizada, referente ao
display da fila especificada. A Figura 17 ilustra o display para a fila de ID 1.
Figura 17 - Display informativo exibindo informaes sobre a fila 1.
No lado superior esquerdo do display, exibido o vdeo institucional; logo abaixo,

est o nome da fila e uma mensagem com at 512 caracteres. Todas essas
informaes, so definidas pelo gerente atravs da manuteno das filas no painel
administrativo.
Do lado inferior direito, esto dados sobre a temperatura na cidade em que a fila
est instalada, a hora local, ms e dia da semana. Essas informaes so obtidas
atravs de consultas a servios externos na Internet e atravs do relgio do sistema
operacional.
J no lado superior direito, esto os dados sobre o status da fila. Essa seo do
display dividida em duas partes:
Senha e local atuais - exibe a senha chamada por ltimo e o terminal

que a chamou;
Histrico de chamadas - exibe as trs senhas anteriores a senha atual,
assim como os respectivos terminais que as chamaram.
Como a fila acabou de ser criada e no h qualquer senha chamada at o momento,

o display senhas XXX 000 e terminais Local 00.
A atualizao do display feita atravs de requisies ajax que so feitas a cada
segundo. Portanto, o display realiza pulling com uma frequncia 1 segundo para
obter dados sobre o status da fila. A atualizao do display segue a seguinte ordem:
1 - enviada uma requisio para a URL

<ip>:<porta>/smartline/getstatus/<id-fila>, onde <id-fila> o ID referente a fila do
display;
2 - A view getstatus recebe a requisio e verifica se existe uma fila cujo ID
o mesmo da requisio. Se existir, retorna um JSON contendo os dados da ltima
senha chamada e as trs ltimas senhas anteriores a atual; caso contrrio, retorna
um JSON com uma mensagem de erro;
3 - O display recebe o JSON e checa se a ltima senha do display a mesma
ltima senha da resposta. Se for a mesma, no faz nada; caso contrrio, atualiza a
senha atual, atualiza o histrico e emite o aviso sonoro indicando uma nova
chamada.
Caso alguma requisio de atualizao retorne um timeout error, o painel exibir

uma mensagem de erro no canto superior esquerdo do display (Figura 18).
Figura 18 - Mensagem de erro exibida no display.
Isso pode acontecer por alguma queda no servidor ou algum outro problema na
comunicao entre o display e o servidor Web. A mensagem ser removida to logo
a conexo seja restabelecida.
4.4.3 - O Dispensador Virtual e a Senha Retirada
No projeto deste trabalho, era previsto o desenvolvimento de um mdulo que se

comunicaria com uma impressora trmica dotada de botes para dispensar senhas
de acordo com a preferncia do cliente. No entanto, por problemas financeiros, no
foi possvel adquirir uma impressora trmica para o projeto. Sendo assim, foi
desenvolvido um dispensador virtual para simular as funcionalidades da impressora
prevista no projeto original.
Ao acessar o endereo <ip>:<porta>/smartline/dispensador, o usurio direcionado
pgina do dispensador virtual. O template renderizado como ilustrado na Figura
19.
Figura 19 - O dispensador virtual de senhas.
No dispensador virtual o cliente dever definir a fila e o servio que deseja, bem
como o tipo de fila - se preferencial ou no.
Ao selecionar uma fila, a lista de servios atualizada a partir de uma requisio
ajax para o endereo <ip>:<porta>/smartline/listar_servicos/<id-fila>, onde <id-fila>
se refere ao ID da fila selecionada na lista do dispensador.
Clicando em Retirar Senha, o cliente direcionado para a pgina referente a nova
senha. A template senha renderizada como ilustrada na Figura 20.
Figura 20 - Senha retirada no dispensador virtual.
Nesta pgina, so exibidas as informaes que seriam impressas na senha

dispensada pela impressora. Dentre informaes sobre o tempo de espera estimada
e dados sobre a senha, est o aviso sobre o estado atual da senha na fila. A
mensagem exibida na parte inferior da pgina, neste caso, diz que o cliente deve se
dirigir a fila, pois no h qualquer cliente a frente dele na fila. Caso existisse algum
cliente sua frente, seria exibida uma mensagem como ilustrada na Figura 21
.
Figura 21 - Estado atual da senha.
Diferentemente de uma senha impressa, a pgina de senhas atualiza o estado atual

da senha a cada segundo, tambm via requisies ajax.
4.4.4 - Se Conectando a um Terminal
Tendo ao menos um terminal e um atendente cadastrado no sistema, o atendente

poder se conectar ao terminal a partir da pgina de login. A URL para pgina
<ip>:<porta>/smartline/login e renderizada como ilustrada na Figura 22.
Figura 22 - Tela de autenticao para conexo em terminais.
Figura: Prprio (2017)
na pgina de login que o atendente escolhe a fila e o respectivo terminal que

deseja se conectar. Apenas terminais desconectados (sem atendentes alocados)
sero exibidos na lista de terminais. Ao selecionar uma nova fila, a lista de terminais
atualizada.
Uma vez conectado a um terminal, o atendente s poder se conectar a outro
terminal se efetuar logout no terminal em que estiver conectado. Por isso, antes de
se ausentar do terminal em que estiver logado, importante que o atendente efetue
o logout e evite, assim, problemas de alocao no futuro.
Sendo o login bem-sucedido, o atendente redirecionado para a pgina terminal
(Figura 23).
Figura 23 - Terminal da Balana 01 conectado.
Fonte: Prrpio (2017)

O terminal proporciona vrias informaes sobre o status da fila e da senha a ser
atendida.
Na parte superior do termina, no bloco Em Atendimento, so exibidas as
informaes da senha em atendimento no terminal. No lado direito do bloco,
renderizado um grfico descrevendo o nmero de clientes que entram no sistema a
cada 30 minutos. J na parte inferior do bloco, so exibidos os botes:
Voltar Senha - responsvel por retroceder chamadas. Ao clicar nesse

boto, feita uma requisio ajax para a URL
<ip>:<porta>/smartline/retrocederChamada. Ao receber essa
requisio, a view retrocederChamada executada, desfazendo a
chamada senha atual e chamando a senha anterior. O retorno dessa
requisio um JSON com o novo status da fila.
Rechamar - responsvel por chamar novamente a senha em
atendimento. Esse boto enviar a requisio para a URL
<ip>:<porta>/smartline/rechamar, que tratada pela view rechamar. A
view seta a flag rechamada da fila em que o terminal est vinculado.
Ao receber o novo status da fila, o display vinculado a fila verifica a flag
rechamada e, caso a flag esteja setada, emite um aviso sonoro de
chamada. Essa requisio no retorna nada, uma vez que ela no
muda o status da fila.
Chamar Prximo - responsvel por finalizar o atendimento atual e
chamar a prxima senha da fila. A URL utilizada por esse boto
<ip>:<porta>/smartline/chamarSenha. Essa URL se refere view
chamarSenha, que responsvel por finalizar a senha em atendimento
e chamar a prxima senha a ser atendida. O retorno dessa requisio
um JSON com o novo status da fila.
No bloco Status da Fila, so exibidas informaes sobre a ltima senha chamada

(no necessariamente a senha atendido neste terminal), a prxima senha da fila a
ser chamada, e alguns dados estatsticos acerca da fila.
Todas as informaes exibidas no terminal so atualizadas via requisies ajax
feitas a cada 5 segundos. As requisies so feitas para a URL
<ip>:<porta>/smartline/touch, que executa a view touch, que por sua vez retorna um
JSON contendo o status completo da fila.
No canto superior direito da pgina do terminal, encontra-se um pequeno menu.
Neste menu encontra-se a opo de efetuar logout (Figura 24).
Figura 24 - Menu da pgina do terminal.
Como dito anteriormente, de suma importncia que o atendente, ao se ausentar do

terminal por um longo tempo, efetue logout do terminal. Caso isso no seja feito, o
atendente poder ter problemas ao tentar se alocar em um terminal no futuro.
4.4.5 - O Controle Remoto Bluetooth
Alm do terminal, o SLS permite que um atendente chame senhas a partir de um

controle remoto bluetooth. Para isso, o gerente precisa registrar o endereo MAC do
controle em um terminal cadastrado, conforme descrito na seo 4.4.1. Alm disso,
necessrio executar o script python que gerencia os eventos do controle. Para
isso, estando no diretrio raz da aplicao, basta executar o seguinte comando:
> python3 bluebutton.py <id-fila>
Onde <id-fila> refere-se ao ID da fila que se quer vincular os eventos de chamada.

O controle remoto utilizado neste projeto foi o VX Case Compact (FIgura 25).
Figura 25 - Controle bluetooth VX Case Compact.
Esse controle possui 3 botes e uma chave liga/desliga, mas emite apenas dois
cdigos de evento diferentes:
o cdigo 115 - emitido ao pressionar o boto + no controle, o script
bluebutton.py interpreta esse cdigo como a chamada de uma nova senha.
Esse mesmo script chama o mtodo chamarSenha da classe Terminal;
O cdigo 114 - emitido quando o boto - pressionado, o bluebutton.py
chama o mtodo retrocederChamada da classe Terminal.
O terceiro boto emite os dois cdigos ao mesmo tempo e, por isso, deve ser
ignorado pelo utilizador.
4.4.6 - SLM - A Aplicao Mvel
Alm do dispensador de senhas impressas, o cliente poder retirar senhas a partir

do aplicativo SmartLine Mobile (SLM).
Desenvolvido para a plataforma Android, o SLM possibilita, alm da gerncia das
senhas retiradas pelo cliente, o recebimento de notificaes.
Ao chegar num estabelecimento comercial com o sistema SmartLine instalado, o
cliente, portando o SLM, deve se dirigir ao dispensador de senhas - que pode ser a
impressora trmica ou apenas uma placa informativa. Afixados ao dispensador,
estaro dois QR Codes: um para dispensar senhas comuns e o outro para senhas
preferenciais, mas ambos para a mesma fila e servio. Cada QR Code contm um
objeto JSON com apenas um par nome-valor, e segue o seguinte formato:
{url:http://<ip>:<porta>/smartline/senha_diponivel/<id-fila>/<id-servico>/<prefer>}
Onde: <ip> e <porta> representam o IP e a porta por onde o servidor Web est
escutando as requisies; <id-fila> o ID da fila em que se quer entrar; <id-servico>
o ID do servio prestado pela fila; <prefer> indica se as senhas dispensadas por
este cdigo so ou no preferenciais. Todos esses valores so numricos, exceto
<ip>, pois poder assumir um hostname como valor.
Para retirar uma senha informativa, basta executar o SLM e clicar no boto flutuante
no canto inferior direito (Figura 26-a). A activity principal ento interrompida e
ento inicializa a activity para leitura de QR Code (Figura 26-b).
Figura 26 Transio entre a atividade principal e o leitor de QR Code.
Basta apontar a cmera para o QR Code referente ao tipo de senha que deseja
retirar e o aplicativo decodificar a URL contida no QR Code. A partir desse
momento, o SLM tentar efetuar uma requisio ao SLS atravs da URL obtida.
Todas as conexes de rede do SLM so feitas atravs de threads separadas das
classes das activitys, evitando, assim, erros em tempo de execuo.
Se a requisio for bem-sucedida, o SLM receber como retorno um objeto JSON
contendo os dados da senha informativa. A Figura 27 ilustra uma senha informativa
retirada a partir da leitura de um QR Code.
Figura 27 - Senha informativa.
A senha informativa exibe estimativas sobre a fila e possibilita que o cliente retire
uma senha vlida para aquela fila. Cabe ao cliente analisar os dados da senha
informativa e avaliar se deve ou no entrar na fila. Na Figura 27, a senha possui
tempo de espera igual a 1 minuto e no h pessoas esperando na fila, o que indica
uma boa hora para retirar uma senha e ser atendido logo!
Para retirar a senha, basta clicar no boto PEGAR. Essa ao enviar uma
requisio do tipo POST para a view retirar_senha_disponivel implementada no SLS,
que associar o UUID do cliente nova senha retirada. O retorno da requisio ser
um objeto JSON contendo os dados da nova senha, como pode ser visto na Figura
28.
Figura 28 - Nova senha retirada.
A aplicao retorna a execuo para a activity principal e insere a nova senha na

lista de senhas do usurio. Como pode ser observado na Figura 28, abaixo das
informaes sobre a senha e a fila, esto dois botes:
Descartar (cone da lixeira) - esse boto envia uma requisio do tipo POST
para a view descartar_senha implementada no SLS. Como o prprio nome
sugere, a view descarta a senha informada, removendo qualquer vnculo do
cliente com a senha e sua respectiva fila. Aps clicar nesse boto, a senha
automaticamente removida da lista de senhas do cliente.
Renew (cone das setas) - esse boto envia uma requisio POST para a
view info_senha, que retorna um dados atualizados sobre tempo de espera
previsto, nmero de pessoas a frente, e a situao da senha.
O cliente poder retirar quantas senhas quiser, desde que cada senha seja para
uma fila diferente. Todas as senhas retiradas ficaro na lista de senhas
implementada na activity principal. A Figura 29 ilustra a lista de senhas agora com
duas senhas retiradas: uma para a Fila do Aougue e outra para o Pronto
Atendimento.
Figura 29 - Lista de senhas retiradas.
Embora exista um boto renew para cada senha da lista, o cliente no precisa se
preocupar em clicar nesse boto para garantir a atualizao do status, pois o SLM
implementa uma thread que atualiza o status de todas as senhas da lista. Essa
atualizao automtica feita a cada 5 segundos e acontece sempre que existir ao
menos uma senha na lista, mesmo que o aplicativo tenha sido encerrado pelo
cliente.
4.4.7 - Enviando Notificaes Aos Clientes
O sistema de notificaes do SmartLine foi implementado utilizando o Google

Firebase - um servio em nuvem para desenvolvimento de aplicaes mobile e Web.
Para estar apto a receber notificaes, o SLM precisa se registrar no servio FCM,
devendo seguir os seguintes passos (Figura 30):
Figura 30 Registrando-se no Firebase.
1. Ao ser executado pela primeira vez, o SLM requisita, ao FCM, um token de

registro. O FCM retorna o token nico para a instncia do SLM que
requisitou;
2. O SLM envia o token de registro para o servidor da aplicao (o SLS). O
servidor, ento, instancia um novo Cliente e atribui o token ao UUID do
cliente;
3. Quando for necessrio enviar qualquer notificao para um cliente, o SLS
enviar uma mensagem de notificao ao FCM, especificando o token de
registro do destinatrio e a mensagem a ser enviada;
4. O FCM entrega a mensagem de notificao ao cliente que possuir o dado
token.
Portanto, pode-se dizer que o FCM funciona como um proxy na comunicao entre o
SLS e o SLM.
O token de registro pode mudar quando: o SLM restaurado em um novo
dispositivo; o cliente desinstala/reinstala o SLM; o cliente limpa os dados de cache
do SLM. Para esses casos, o aplicativo repete os passos de registro de token
apresentados anteriormente, e o cliente passa a ser representado, no SLS, como
uma nova instncia da classe Cliente.
O envio de notificaes a nica ao que faz o SLS deixar sua condio passiva
na comunicao com o SLM.
O cliente SLM receber notificaes sempre que:
No houver ningum sua frente - nessa situao, o cliente receber a

mensagem A sua senha a prxima a ser chamada! Dirija-se rea de
espera da fila;
A senha do cliente for chamada - a mensagem de notificao recebida
ser Sua senha foi chamada! Dirija-se ao local de atendimento.
A Figura 31 ilustra o recebimento de uma notificao onde o cliente o prximo a ter

sua senha chamada.
Figura 31 - Recebendo notificaes atravs do Firebase.
Todas as notificaes, alm do alerta visual, ativam um alerta sonoro e vibratrio.

Ao clicar na mensagem da notificao, o cliente levado a activity principal do SLM.
Al, ele poder visualizar a senha relacionada com a notificao, que estar marcada
com um cone info (sinal de exclamao) no canto superior esquerdo da senha
(Figura 32).
Figura 32 - cone indicador de notificao.
Finalizado o atendimento, a senha mudar sua situao de Em atendimento para

Atendimento finalizado, e mudar sua paleta de cores para tons de cinza. A partir
desse momento, essas senha deixar de receber qualquer atualizao de status ou
notificaes, e poder ser descartada pelo cliente (Figura 33).
Figura 33 - Senha com atendimento finalizado.
Note que os cones renew e info so removidas da senha, e os campos Espera

prevista e Na sua frente no exibem os seus respectivos dados.
4.4.8 - Monitorando a Atividade dos Usurios
Alm do FCM, este projeto fez uso de outro servio oferecido pelo Firebase: o
Google Analytics for Firebase. Com essa soluo possvel monitorar a atividade
dos usurios e a forma como eles utilizam o aplicativo. As informaes podem ser
segmentadas de acordo com pblicos-alvo personalizados, eventos personalizados
ou propriedades dos usurios.
5 - CONSIDERAES FINAIS
5.1 - CONCLUSO
Este trabalho apresentou um sistemas de controle de filas remotas, cujo principal

objetivo era mitigar o desconforto causado pela espera por atendimento. Para tanto,
este trabalho apresentou o SmartLine que um sistema de controle de filas remotas
dividido em duas aplicaes: o SmartLine Server e o SmartLine Mobile. O primeiro
foi instalado num Raspberry Pi 3 model B e era responsvel por manter as filas e
seu usurios, assim como enviar notificaes para os clientes. O segundo foi
desenvolvido para a plataforma Android e era responsvel por manter as senhas do
cliente.
O SmartLine tambm possibilitou ao cliente planejar a sua entrada na fila, uma vez
que o sistema exibia o status da fila em uma senha informativa.
Ao retirar uma senha, o cliente no mais precisava permanecer na rea de espera
do estabelecimento, j que o prprio SmartLine enviava informaes atualizadas
sobre o status de cada senha (nmero de pessoas na fila, tempo de espera previsto
e situao da senha).
Graas versatilidade das plataformas Django e Android, foi possvel desenvolver
um sistema funcional em um curto prazo de tempo. Alm dessas duas plataformas,
foi utilizado o servio Firebase Cloud Messaging, responsvel por intermediar o
envio de notificaes. Esse servio, includo no pacote Google Firebase, agilizou o
processo de desenvolvimento em alguns dias!
Os testes do SmartLine Server foram feitos, primeiramente, num computador
desktop e posteriormente testado no Raspberry Pi 3 model B. No houve qualquer
problema na troca de ambientes, graas versatilidade da mquina virtual Python. O
nico ponto a se destacar com relao ao Raspberry Pi foi a necessidade de se
instalar dissipadores de calor, uma vez que a reproduo de vdeo, nesse
dispositivo, consome boa parte dos recursos de processamento do mesmo, levando
ao superaquecimento e, consequentemente, queda no desempenho.
O mesmo Raspberry Pi se mostrou eficiente na captura dos eventos de controle
bluetooth, porm o controle bluetooth, utilizado neste projeto, no se mostrou o ideal
para a aplicao. Uma vez ligado, o controle se conecta ao Raspberry Pi e assim
permanece por 5 minutos. Aps esse tempo, o controle entra em standby e fica
impossibilitado de enviar eventos, at que um primeiro toque reative o controle e a
conexo seja restabelecida.
J o SmartLine Mobile, por falta de um dispositivo Android real, teve de ser testado
apenas em emuladores. O aplicativo foi testado em dois emuladores diferentes: um
com Android 5.1 (Lollipop), 512 MB de memria principal, e utilizando dois ncleos
do processador hospedeiro; e outro com Android 8.0 (Orea), com 1 GB de memria,
e utilizando dois ncleos do processador hospedeiro. Nos dois emuladores, a
webcam do computador hospedeiro foi utilizado como cmera traseira do dispositivo.
Nos dois emuladores testados, o aplicativo se comportou de maneira estvel e
eficaz.
5.2 - TRABALHOS FUTUROS
Por ter sido inserido no final da implementao, o Google Firebase foi pouco
explorado, sendo utilizado apenas no servio de notificao de status de senhas.
Entretanto, seus servios poderiam ter sido explorados, por exemplo, para atualizar
as informaes da lista de senhas, eliminando a necessidade de realizar pulling a
cada 5 segundos.
Uma soluo mais eficiente para a atualizao de senhas seria o envio de
notificaes push sempre que o estado de uma dada fila se alterasse. O SmartLine
Server, ao identificar uma alterao em alguma fila, enviaria as atualizaes de
status dessa fila ao FCM, que se encarregaria de entregar os dados de atualizao a
todos os clientes que estivessem naquela fila.
Outro possvel ponto a ser trabalhado a questo do desempenho do Display no
navegador do Raspberry Pi. A reproduo de vdeo e a renderizao de alguns
elementos CSS (eg., efeitos de sombra e superposio), fazem com que o
Raspberry Pi consuma mais da metade de seus recursos computacionais apenas
exibindo o Display. A substituio das sombras - renderizadas em tempo real - por
imagens com fundo transparente, pode melhorar o desempenho. Uma outra soluo
poderia ser a substituio do vdeo institucional por uma apresentao de slides.
Ainda no SmartLine Server, seria interessante escrever um script python auxiliar na
instalao e execuo do sistema. O script que escuta os eventos bluetooth poderia
ser integrado a esse novo script de instalao/execuo.
Uma alternativa ao atual controle bluetooth pode ser sugerida. Pode-se, por
exemplo, substituir o controle bluetooth por um sistema alternativo de transmisso
via rdio.
Por fim, o SmartLine poderia mudar o seu enfoque, passando a ser um servio Web.
O Raspberry Pi serviria apenas para a comunicao com o servidor Web e a
exibio do Display. Sendo assim, todas as atividades do sistema seriam
gerenciadas na nuvem, no mais por um dispositivo instalado no estabelecimento
comercial.
6 REFERNCIAS
AVRAM, A. Google Firebase: back-end completo para aplicaes web e mobile.

InfoQ, 2016. Disponivel em: <https://www.infoq.com/br/news/2016/07/google-
firebase>. Acesso em: 19 Novembro 2017.
BARCODE API Overview. Google Developers, 2017. Disponivel em:

<https://developers.google.com/vision/android/barcodes-overview>. Acesso em: 19
Novembro 2017.
BATERSON, J. E. G.; HOFFMAN, K. D. Princpios de marketing de servios:

conceitos, estratgias e casos. Traduo de Cristina Bacellar. 4. ed. So Paulo:
[s.n.], 2016.
BRAND NEW AND BLUE: OUR BRAZILIAN RASPBERRY PI 3. Raspberry Pi
Foundation. Disponivel em: <https://www.raspberrypi.org/blog/raspberry-pi-brazil/>.
CARMON, Z.; SHANTHIKUMAR, J. G.; CARMON, T. F. A Psychological Perspective

on Service Segmentation Models: The Significance of Accounting for Consumers'
Perceptions of Waiting and Service. Management Science, v. 41, n. 11, p. 1806-
1815.
DICKSON, D.; FORD, R. C.; LAVAL, B. Managing Real and Virtual Waits in
Hospitality and Service Organizations. Cornell Hotel and Restaurant
Administration Quarterly, v. 46, n. 1, p. 52-68, 2005.
ESCREVENDO seu primeiro app Django. Django Documentation, 2017. Disponivel

em: <https://docs.djangoproject.com/pt-br/1.11/intro/tutorial01/#the-development-
server>. Acesso em: 20 Novembro 2017.
FAQ: Bancos de Dados e modelos. Django Documentation, 2017. Disponivel em:

<https://docs.djangoproject.com/pt-br/1.11/faq/models/>. Acesso em: 20 Novembro
2017.
FAQ: Geral. Django Project, 2017. Disponivel em:

<https://docs.djangoproject.com/pt-br/1.11/faq/general/#django-appears-to-be-a-mvc-
framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-
you-don-t-use-the-standard-names>. Acesso em: 19 Novembro 2017.
FIREBASE Produtos. Google Firebase, 2017. Disponivel em:

<https://firebase.google.com/products/?hl=pt-br>. Acesso em: 19 Novembro 2017.
FITZSIMMONS, J. A.; FITZSIMMONS, M. J. Administrao de Servios. Traduo

de Lene Belon Ribeiro. 6. ed. Porto Alegre: 2014, 2014.
GARRETT, F. Como funciona o Raspberry Pi? Entenda a tecnologia e sua

aplicabilidade. TechTudo, 2014. Disponivel em:
<http://www.techtudo.com.br/noticias/noticia/2014/11/como-funciona-o-raspberry-pi-
entenda-tecnologia-e-sua-aplicabilidade.html>. Acesso em: 19 Novembro 2017.
GUIMARES, G. A histria do sistema operacional Android. Pet News, 2013.

Disponivel em:
<http://www.dsc.ufcg.edu.br/~pet/jornal/agosto2013/materias/historia_da_computaca
o.html>. Acesso em: 19 Novembro 2017.
GUPTA, C. B. Contemporary Management. Delhi: Ashish Publishing House, 1992.
HILLIER, F. S.; LIEBERMAN, G. J. Introduo Pesquisa Operacional. Traduo

de Ariovaldo Griesi. 8. ed. So Paulo: McGraw-Hill, 2006.
JUNG, C. F. Metodologia para pesquisa e desenvolvimento: aplicada a novas

tecnologias, produtos e processos. Rio de Janeiro: Axcel Books do Brasil Editora,
2004.
KARU, M. Implementing a service software to relieve waiting line frustration.

Dissertao (Design and Development of Virtual Environments) - University of Tartu
Viljandi Culture Academy. Tallinn, p. 63. 2013.
LARSON, R. C. Perspectives on queues: social justice and psychology of queueing.

Operations Research, Cambridge, v. 35, n. 6, p. 895-905, Dezembro 1987.
MACORATTI, J. C. Padres de Projeto : O modelo MVC - Model View Controller.

Macoratti, 2002. Disponivel em: <http://www.macoratti.net/vbn_mvc.htm>. Acesso
em: 19 Novembro 2017.
MCGUIRE, K. A. et al. A Framework for Evaluating the Customer Wait. Journal of

Service Management, v. 22, n. 3, p. 269-290.
MEET Django. Django Project, 2017. Disponivel em:

<https://www.djangoproject.com/>. Acesso em: 19 Novembro 2017.
MORENO, E. et al. Urbanization and Development: Emerging Futures. United
Nations Human Settlements Programme. Nairobi, p. 247. 2016. (978-92-1-133395-
4).
NOVAIS, A. Como funciona o Fast Pass+ da Disney? Disney Guia, 2014. Disponivel
em: <http://www.disneyguia.com.br/site/como-funciona-o-fast-pass-da-disney/>.
Acesso em: 19 Novembro 2017.
PAGLIARUSSI, M. S. Oimizao de Sistemas de Transporte. Rio de Janeiro:
[s.n.], 2016.
RASPBERRY Pi 3 Model B Anatel. FilipeFlop, 2017. Disponivel em:

<https://www.filipeflop.com/produto/raspberry-pi-3-model-b/>. Acesso em: 19
Novembro 2017.
RASPBERRY Pi 3 Model B Technical Specifications. Element14, 2016. Disponivel

em: <https://www.element14.com/community/docs/DOC-80899/l/raspberry-pi-3-
model-b-technical-specifications>. Acesso em: 19 Novembro 2017.
RASPBERRY Pi FAQs. Raspberry Pi Foundation, 2017. Disponivel em:

<https://www.raspberrypi.org/help/faqs/#introWhatIs>. Acesso em: 19 Novembro
2017.
ROSSIGNOL, J. Google Says There Are Now More Than 2 Billion Monthly Active
Android Devices. MacRumors, 2017. Disponivel em:
<https://www.macrumors.com/2017/05/17/2-billion-active-android-devices/>. Acesso
em: 19 Novembro 2017.
SALUTES, B. AOSP: saiba o que e para que serve. Android Pit, 2017. Disponivel
em: <https://www.androidpit.com.br/aosp-android-open-source-project>. Acesso em:
19 Novembro 2017.
SENSO Demogrfico 2010. Instituto Brasileiro de Geografia e Estatstica.
Disponivel em: <https://www.ibge.gov.br/estatisticas-
novoportal/sociais/populacao/9662-censo-demografico-2010.html>. Acesso em: 19
Novembro 2017.
STONE, A. Why Waiting Is Torture. The New York Times, 2012. Disponivel em:
<http://www.nytimes.com/2012/08/19/opinion/sunday/why-waiting-in-line-is-
torture.html?_r=2>. Acesso em: 19 Novembro 2017.
THE Django Admin Site. The Django Book, 2017. Disponivel em:
<https://djangobook.com/django-admin-site/>. Acesso em: 19 Novembro 2017.
TIPS About Disneyland From a Native Cali Annual Pass Holder. Travel 4 The Soul,
2012. Disponivel em: <https://travelista1.wordpress.com/tag/fast-pass/>. Acesso em:
19 Novembro 2017.
TUDO de que voc precisa para criar aplicativos no Android. Android Developers,
2017. Disponivel em: <https://developer.android.com/studio/features.html?hl=pt-br>.
WHAT IS A RASPBERRY PI? Raspberry Pi Foundation. Disponivel em:

<https://www.raspberrypi.org/help/what-%20is-a-raspberry-pi/>. Acesso em: 19
Novembro 2017.
WIKIPDIA, C. D. Mapeamento objeto-relacional. Wikipdia, a enciclopdia livre.,

2017. Disponivel em:
<https://pt.wikipedia.org/w/index.php?title=Mapeamento_objeto-
relacional&oldid=49230328>. Acesso em: 20 Novembro 2017.
WIKIPDIA, C. D. Raspberry Pi. Wikipdia, a enciclopdia livre., 2017. Disponivel

em: <https://pt.wikipedia.org/w/index.php?title=Raspberry_Pi&oldid=50463660>.
WIKIPDIA, C. D. Teoria das filas. Wikipdia, a enciclopdia livre, 2017.
Disponivel em:
<https://pt.wikipedia.org/w/index.php?title=Teoria_das_filas&oldid=48101327>.

Sistema Gerenciador de Filas Remotas: Mitigando Os Efeitos Negativos Da Espera em Estabelecimentos Comerciais

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sistema Gerenciador de Filas Remotas: Mitigando Os Efeitos Negativos Da Espera em Estabelecimentos Comerciais

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDADE FEDERAL DO ESPRITO SANTO

JOS MARQUES SOARES JNIOR

SISTEMA GERENCIADOR DE FILAS REMOTAS:

SISTEMA GERENCIADOR DE FILAS REMOTAS:

Trabalho de Concluso de Curso apresentado ao

SISTEMA GERENCIADOR DE FILAS REMOTAS:

Trabalho de Concluso de Curso apresentado ao

Aprovada em ____ de _____________ de 2018.

Tabela 1 - Modelos, configuraes e preos do Raspberry Pi .................................. 20

1.1 - Objetivos ........................................................................................................... 12

1.1.1 - Objetivos gerais ............................................................................................. 12

1.1.2 - Objetivos Especficos ..................................................................................... 13

2 FUNDAMENTAO TERICA ........................................................................... 13

2.1 - Processo de Filas Bsico .................................................................................. 13

2.2 - Psicologia das Filas .......................................................................................... 16

2.3 - Filas Virtuais e Remotas ................................................................................... 17

2.4 RasPberry Pi .................................................................................................... 19

2.5 Django .............................................................................................................. 21

2.6 Android ............................................................................................................. 23

2.6.1 Android Studio ............................................................................................... 23

2.6.2 Barcode Scanner API .................................................................................... 23

2.6.3 Google Firebase ............................................................................................ 24

3.1 - Tipo de Pesquisa .............................................................................................. 25

3.2 - Procedimentos .................................................................................................. 25

4 RESULTADOS E DISCUSSO ........................................................................... 26

4.1 - Consideraes Iniciais ...................................................................................... 26

4.2 - Caractersticas .................................................................................................. 27

4.2.1 - SLS - SmartLine Server e a Plataforma Django ............................................. 27

4.2.2 - SLM - SmartLine Mobile e a Plataforma Android ........................................... 27

4.2.3 - Comunicao Entre Aplicaes ..................................................................... 28

4.3.1 - Diagrama de Casos de Uso ........................................................................... 30

4.3.2 - Diagrama de Classes ..................................................................................... 31

4.4 - Implementao .................................................................................................. 35

4.4.2 - O Display Informativo ..................................................................................... 41

4.4.3 - O Dispensador Virtual e a Senha Retirada .................................................... 44

4.4.4 - Se Conectando a um Terminal ....................................................................... 46

4.4.5 - O Controle Remoto Bluetooth ....................................................................... 49

4.4.6 - SLM - A Aplicao Mvel ............................................................................... 50

4.4.7 - Enviando Notificaes Aos Clientes ............................................................... 54

4.4.8 - Monitorando a Atividade dos Usurios ........................................................... 58

5 - Consideraes Finais ........................................................................................... 58

5.1 - Concluso ......................................................................................................... 58

5.2 - Trabalhos Futuros ............................................................................................. 59

Desde a revoluo industrial, os centros urbanos vm aumentando rapidamente. Em

1.1.1 - Objetivos gerais

Para alcanar o objetivo geral, foi necessrio:

2.1 - PROCESSO DE FILAS BSICO

Esperar por um servio uma situao comum. Seja no banco, no supermercado ou

Figura 1 - Sistema de filas bsico.

Fonte: (HILLIER e LIEBERMAN, 2006)

Single-Queue-Single-Service-Point (SQSSP) - clientes se organizam em uma fila

Figura 2 - Filas lineares em diferentes configuraes.

Fonte: Prprio (2017)

J nas filas virtuais, os clientes no se limitam a nenhum ponto de espera especfico

Em 1998, aps vrias tentativas de minimizar as longas esperas e reclamaes

Figura 3 - Tickets retirados pelo sistema FASTPASS

Os resultados da instalao do novo sistema foram bem positivos: os clientes

Figura 4 - Jornada de um cliente em uma sistema de fila remota.

Fonte: (KARU, 2013, p. 15)

A Figura 4 ilustra a jornada de um cliente em uma fila remota. A partir do aplicativo

O Raspberry Pi um single-board computer (SBC), do tamanho de um carto de

Tabela 1 - Modelos, configuraes e preos do Raspberry Pi

Aprovada em de _________ de 2018.