Desenvolvimento do protótipo de um APP Android para ......Comercial. (DOZE TI, 2018). A automação...
66
PEDRO CARVALHO GRASSETTI Desenvolvimento do protótipo de um APP Android para Automação Comercial de Fichas de Consumo Sorocaba 2018
Transcript of Desenvolvimento do protótipo de um APP Android para ......Comercial. (DOZE TI, 2018). A automação...
PEDRO CARVALHO GRASSETTI
Desenvolvimento do protótipo de um APP Android para Automação Comercial de
Fichas de Consumo
Sorocaba
2018
PEDRO CARVALHO GRASSETTI
DESENVOLVIMENTO DO PROTÓTIPO DE UM APP ANDROID PARA
AUTOMAÇÃO COMERCIAL DE FICHAS DE CONSUMO
Trabalho de Conclusão de Curso
apresentado ao Instituto de Ciência e
Tecnologia de Sorocaba, Universidade
Estadual Paulista (UNESP), como parte
dos requisitos para obtenção do grau de
Bacharel em Engenharia de Controle e
Automação.
Orientador: Prof. Dr. Galdenoro Botura Jr.
Sorocaba
2018
Ficha catalográfica elaborada pela Biblioteca da Unesp Instituto de Ciência e Tecnologia – Câmpus de Sorocaba
Grassetti, Pedro Carvalho. Desenvolvimento do protótipo de um app Android para automação comercial de fichas de consumo / Pedro Carvalho Grassetti, 2018. 66 f.: il. Orientador: Galdenoro Botura Junior. Trabalho de Conclusão de Curso (Graduação) – Universidade Estadual Paulista "Júlio de Mesquita Filho". Instituto de Ciência e Tecnologia (Câmpus de Sorocaba), 2018. 1. Automação comercial. 2. Android. 3. Android Studio. 4. Automação bares e restaurantes. I. Universidade Estadual Paulista "Júlio de Mesquita Filho". Instituto de Ciência e Tecnologia (Câmpus de Sorocaba). II. Título.
Bibliotecário responsável: Bruna B. Guimarães – CRB 8/8855
AGRADECIMENTOS
Aos meus pais, meu irmão e namorada por todo o apoio durante minha formação
acadêmica.
Ao Prof. Dr. Galdenoro Botura Jr. pela atenção e disponibilidade em todas as etapas
de desenvolvimento do trabalho.
Aos meus amigos e colegas de curso por todo o tempo da graduação e pela
superação dos grandes desafios apresentados ao longo do curso.
Ao corpo docente do curso de engenharia de controle e automação e também à todos
os colaboradores da Unesp Campus de Sorocaba pelos aprendizados durante o período de
graduação.
RESUMO
Com o avanço da tecnologia, os dispositivos móveis têm se tornado um
componente muito importante dentro da automação comercial, deixando os sistemas mais
eficientes e mais baratos. Isso por causa da quantidade imensa de funcionalidades e
possibilidades de integração que os sistemas operacionais e hardwares possuem. Devido
a necessidade de realizar uma automação comercial de um estabelecimento no ramo de
bares e restaurantes, o objetivo desse projeto foi apresentar um protótipo para solução
fácil e robusta da automação de fichas de consumo. Para a realização das etapas de
desenvolvimento, utilizou-se a plataforma Android juntamente com o ambiente de
programação Android Studio, também fornecido pelo Google. Esse projeto foi
desenvolvido com o intuito de oferecer um controle maior ao dono do estabelecimento,
diminuir custos operacionais de recursos humanos e deixar a automação do controle da
venda de uma ficha de consumo mais rápida, o que pode determinar, portanto, um
aumento do consumo médio dos consumidores. Com a automação, o consumo tende a
aumentar e o estabelecimento ganhar mais eficiência e, no mercado, quando falamos de
eficiência estamos falando de redução de custos e consequentemente aumento da
lucratividade. Esse trabalho foi projetado e desenvolvido 100% para plataforma Android,
porém toda a inteligência aplicada e estrutura pode ser utilizada em um aplicativo para
celulares com sistema iOS.
Palavras-chave: Automação Comercial. Android. Android Studio. Automação
Bares e Restaurantes.
ABSTRACT
Mobile devices have become, with the advancement of technology, a very important
piece in the commercial automation area, making the systems more efficient and cheaper.
This is explained by the huge quantity of functions and different ways of integration with
other systems. Given the need of a commercial automation of a business in the bars and
restaurants sector, the main objective of this project was to present an easy and robust
solution for this system. To perform these steps the Android platform and Android Studio,
also provided by Google, were used. , provided by Google, was used. This Project was
developed to offer greater control to the owner of the establishment, reduce operational
costs of human resources and leave the purchase of a faster consumption sheet, which
can therefore determine an increase in average consumer consumption. With this
automation system, the amount of consumption tends to increase causing more efficiency
for the shop and when we talk about efficiency, we are saying that the profits are
increasing. This work was designed and developed 100% for Android platform, however
all applied intelligence and structure can be used in an app for mobile phones with iOS
system.
Keywords: Commercial Automation. Android. Android Studio. Bars and Restaurants
Automation.
LISTA DE FIGURAS
Figura 1 - Máquina Registradora ................................................................................................ 12
Figura 2 - Código de Barras Linear.............................................................................................. 12
Figura 3 - Foto do aparelho T-Mobile G1. Primeiro a possuir Android ..................................... 14
Figura 4 - Pesquisa Gartner. ....................................................................................................... 15
Figura 5 - Camadas da Plataforma Android ............................................................................... 17
Figura 6 - Opções de conexões para login do usuário ............................................................... 23
Figura 7 - Exemplo banco de dados Firebase. ........................................................................... 24
Figura 8 - Modelo Venda de Fichas de Papel ............................................................................. 26
Figura 9 - Aplicativo utilizado para referência ........................................................................... 28
Figura 10 - Modelo do Aplicativo STUE ...................................................................................... 29
Figura 11 - Estrutura Básico do Aplicativo do Projeto ............................................................... 31
Figura 12 - Página WEB Android Studio ................................................................................... 333
Figura 13 - Tela Login .................................................................................................................. 35
Figura 14 - Tela 1 Cadastro - Senha e Usuário ........................................................................... 36
Figura 15 - Tela 2 Cadastro - Informações Pessoais .................................................................. 36
Figura 16 - Produtos disponíveis venda Cervejas ...................................................................... 37
Figura 17 - Produtos Disponíveis Dose ...................................................................................... 37
Figura 18 - Produtos Disponíveis Refrigerantes ........................................................................ 38
Figura 19 - Produtos Cadastrados .............................................................................................. 38
Figura 20 - Aba Fichas Disponíveis ............................................................................................. 39
Figura 21 - Aba produtos já retirados (Histórico) ...................................................................... 39
Figura 22 - Tela de administrador para iniciar leitura ............................................................... 40
Figura 23 - Tela de Administrador para confirmação de dados do produto ............................ 40
Figura 24 - Estrutura Macro do Banco de Dados ....................................................................... 42
Figura 25 - Estrutura Nó Venda .................................................................................................. 42
Figura 26 - Estrutura Fichas Disponíveis .................................................................................... 43
Figura 27 - Estrutura Fichas Histórico ........................................................................................ 45
Figura 28 - Estrutura Informações Usuários .............................................................................. 46
Figura 29 - Celular Motorola G5 ................................................................................................. 47
Figura 30 - Telas cadastro do usuário Pedro .............................................................................. 48
Figura 31 - Tela Cadastro Usuário Bárbara ................................................................................ 49
Figura 32 - Tela de gestão dos Usuários..................................................................................... 50
Figura 33 - Estrutura Banco de Dados Usuários ........................................................................ 50
Figura 34 - Tela Produtos Usuários Teste .................................................................................. 51
Figura 35 - Estrutura Banco de Dados Produtos Teste .............................................................. 52
Figura 36 - Telas de Navegação Usuários ................................................................................... 53
Figura 37 - Telas de Produtos Disponíveis Usuários Testes ...................................................... 53
Figura 38 - QR Code gerado para retirada do produto .............................................................. 54
Figura 39 - Tela do administrador para validar um QR Code .................................................... 55
Figura 40 - Leitor de QR ativado para uma leitura .................................................................... 55
Figura 41 - Tela de conferência dos dados do produto ............................................................. 56
Figura 42 - Tela dos itens já retirados - Histórico ...................................................................... 57
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface
APP - Aplicativo
OHA – Open Handset Aliance
PDV – Ponto de Venda
QoS – Quality of Service
SLA – Service Level Agreement
SMS – Show Message Service
SO – Sistema Operacional
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................. 11
1.1. Contextualização ....................................................................................................... 11
1.1.1. Automação Comercial ....................................................................................... 11
1.1.2. Android e Dispositivos Móveis ......................................................................... 13
1.2. Objetivos .................................................................................................................... 16
2. FUNDAMENTAÇÃO TEÓRICA ............................................................................... 17
2.1. Estrutura Android..................................................................................................... 17
2.1.1. Núcleo Linux ...................................................................................................... 17
2.1.2. Bibliotecas .......................................................................................................... 18
2.1.3. Tempo de Execução (Android Runtime) ......................................................... 18
2.1.4. Framework de Aplicativos ................................................................................ 19
2.1.5. Aplicações ........................................................................................................... 19
2.2. Computação em Nuvem ............................................................................................ 19
2.2.1. Serviço sob demanda ......................................................................................... 20
2.2.2. Independência de localização ........................................................................... 21
2.2.3. Elasticidade e Escalabilidade ........................................................................... 21
2.2.4. Medição dos Serviços ........................................................................................ 21
2.3. Google Firebase ......................................................................................................... 22
2.3.1. Login de Usuários (Authentication) ................................................................. 23
2.3.2. Realtime Database ............................................................................................. 23
2.4. Proposição .................................................................................................................. 25
2.5. Metodologia ............................................................................................................... 25
2.6. Definição do Escopo do Projeto ............................................................................... 27
2.6.1. Cliente (1) ........................................................................................................... 29
2.6.2. Realizando o Pedido e Pagamento (2) .............................................................. 29
2.6.3. Envio do Pedido (3) ........................................................................................... 30
2.6.4. Entrega do Pedido (4) ....................................................................................... 30
3. DESENVOLVIMENTO ............................................................................................... 33
3.1. Preparação do Ambiente Android ........................................................................... 33
3.2. Estrutura Geral das Telas ........................................................................................ 34
3.3. Tela Inicial de Login ................................................................................................. 34
3.4. Telas Cadastro Usuário ............................................................................................ 35
3.5. Tela Compra Ficha.................................................................................................... 36
3.6. Telas Gestão de Fichas .............................................................................................. 38
3.7. Telas Retirada Produto Balcão ................................................................................ 39
3.8. Estrutura Banco de Dados ........................................................................................ 41
4. Resultados e Discussões ................................................................................................ 47
5. CONCLUSÃO ............................................................................................................... 58
REFERÊNCIAS ...................................................................................................................... 59
ANEXOS.................................................................................................................................. 61
11
1. INTRODUÇÃO
1.1. Contextualização
1.1.1. Automação Comercial
Com o avanço da tecnologia das redes móveis, o acesso a informação tem tornado
o consumidor, de maneira geral, mais exigente e, de certa, forma impaciente na compra
de qualquer produto ou serviço. Ao invés de esperar por horas na fila de um
supermercado, ou mesmo em caixas de bancos, hoje, em poucos minutos, é possível
realizar pagamentos de contas e até mesmo abastecer a geladeira de maneira fácil e rápida.
Assim, essa agilidade provoca uma série de mudanças em todo o mercado,
alterando desde a estrutura de recursos humanos da empresa até o relacionamento
consumidor-fornecedor. Dessa maneira a constante evolução da tecnologia passou a não
ser mais um diferencial, e sim uma questão de sobrevivência no mercado (CEPE, MAIA
2017).
Todo o processo repetitivo básico de qualquer empresa, como compra, venda e
controle de estoque, por exemplo, que antigamente era feito de forma manual, cada vez
mais vem se tornando mais automática, definindo o que conhecemos por Automação
Comercial. (DOZE TI, 2018).
A automação teve seu marco inicial com a invenção das chamadas máquinas
registradoras, que não eram nem um pouco parecidas com o que temos hoje nas lojas.
Essas máquinas eram utilizadas para realizar a somatória dos produtos, sumarizar as
vendas e facilitar o trabalho do operador de caixa.
Nos anos 90, as primeiras integrações surgiram o que possibilitou a troca mais
eficiente de informações e também uma segurança e confiabilidade de armazenamento de
dados. (A NOVA ERA DA AUTOMAÇÃO COMERCIAL, 2017)
12
Figura 1 - Máquina Registradora
A partir dessa integração dos dados, apareceram os primeiros sistemas que
consideravam os PDVs (Pontos de Vendas) nos estabelecimentos. Esses terminais
trabalhavam apenas como um ponto de captura das informações dos produtos, que com o
passar do tempo começaram a contar com o leitor de código de barras para facilitar esse
lançamento. Devido ao grande sucesso desse tipo de terminal, as empresas investiram em
uma padronização internacional de identificação dos produtos. Na figura 2, temos um
exemplo de um modelo linear do código de barras. Atualmente, a tecnologia da
padronização atingiu o modelo do QR CODE, do inglês Quick Response. (PINTO, 2018).
Figura 2 - Código de Barras Linear
Acompanhando toda essa evolução na venda e controle das informações em
ambiente comercial, o setor de bares e restaurantes também sofreu gigantes mudanças no
comportamento. Neste sentido, apareceram empresas especializadas para esses tipos de
automações gerando excelentes resultados operacionais, diminuindo prejuízos e
otimizando os custos.
Até o surgimento dos dispositivos móveis, as automações comerciais eram
basicamente utilizadas pelos colaboradores da empresa, por meio de hardwares
específicos e dedicados, facilitando assim retirar o pedido do cliente, enviar para a
cozinha algum prato ou mesmo realizar o fechamento da conta. Porém, com o advento
13
desses aparelhos móveis, o cliente passa a ser parte necessária e integrante da automação,
alterando por completo a experiência desse consumidor e todos os dados que ele gera para
a empresa.
Por fim, toda a automação visa garantir o acesso aos dados, concentração de
informações e mais agilidade no atendimento do consumidor que cada vez deseja perder
menos tempo com coisas simples.
1.1.2. Android e Dispositivos Móveis
O Android é a plataforma móvel mais popular do Mundo e vem crescendo cada vez
mais. Segundo o site de tecnologia TecMundo (acesso realizado em 18/04/2018) em 2017
tínhamos 85% dos aparelhos do mundo com sistema operacional gerenciado pelo Google.
Desde o surgimento dos aparelhos celulares, diversos modelos foram criados e
lançados pelas grandes produtoras, porém todos possuíam basicamente as mesmas
funcionalidades diferenciando-se um do outro apenas pelo seu formato, pelo tamanho,
etc.
Funcionalidades tais como: agenda de contatos, câmeras de baixa resolução, rádio
FM e praticamente nenhuma integração com qualquer outro device de nosso cotidiano.
Dessa maneira, no ano de 2005, o Google realizou uma parceria com essas grandes
indústrias, como LG, Sony, Samsung entre outras e criaram um grupo chamado OHA
(Open Handset Aliance) com a finalidade de criar uma plataforma única para o
desenvolvimento de dispositivos móveis. (USE A CABEÇA, 2016).
Assim, a partir dessa iniciativa surgiu o Android, que é um ambiente operacional
baseado em Linux, com código open source.
Essa plataforma tem como conceito principal ser totalmente aberta, ou seja, oferece
gratuitamente diversos recursos para o desenvolvimento de novos aplicativos fazendo que
com o passar o tempo tenhamos mais bibliografias a respeito.
No início, seu destino era somente o campo de dispositivos móveis, entretanto a
grande variedade de serviços, aplicações e suporte totalmente funcional possibilitou que
se tornasse útil em outras plataformas com diversas aplicações e um ambiente
extremamente flexível. (USE A CABEÇA, 2016).
14
Em outubro de 2008 o primeiro aparelho a funcionar com o sistema operacional
Android começou a ser comercializado. O aparelho levou o nome de T-Mobile G1, que
pode ser observado na figura 3. (FINCOTTO, SANTOS, 2014).
Figura 3 - Foto do aparelho T-Mobile G1. Primeiro a possuir Android
As vendas superaram as expectativas e a plataforma se tornou um sucesso entre os
fabricantes. Um dos principais motivos para essa impressionante evolução nos últimos
anos é estar baseado em “Código Aberto”. Sistema baseados em uma estrutura que pode
ser modificada por qualquer usuário que tenha conhecimento de linguagens de
programação ou mesmo de sistemas. Esses sistemas se diferenciam de sistemas
operacionais usados atualmente, por exemplo o Windows. (COSTA, SANTOS, 2015).
E, por esse e outros fatos que serão abordados ao longo desse trabalho, pode-se
afirmar que o Android, hoje, é utilizado por quase todas as empresas do ramo, liderando
o mercado mundial de dispositivos móveis. (KINOTO,COSTA)
Ocorre, porém, que o Android não está sozinho nesse nicho de alto giro financeiro,
que só entre os meses de abril e junho de 2016 movimentou mais de 11,4 bilhões no
Brasil. Isso porque, sistemas como IOS (presente em produtos Apple), Windows (muito
conhecido na indústria de computadores) e Blackberry, compartilham os altos números
desse mercado.
Prova disso é que, de acordo com a consultoria americana Gartner,
aproximadamente 408 milhões de aparelhos foram vendidos somente no 4 trimestre de
2017, considerando que 82% desse total com o SO do Google.
15
Na figura 4 é possível observar o quanto o Android tornou-se expressivo no
mercado de Smartfones. Observa-se também que muitos sistemas operacionais, como por
exemplo o Windows, saíram do mercado dos dispositivos móveis dando espaço
praticamente para dois players.
Figura 4 - Pesquisa Gartner (Disponível em https://www.gartner.com/newsroom/id/3859963)
Sendo assim, seria muito contraditório a não utilização dessa ferramenta no ramo
da automação, já que é possível realizar diversas integrações com diferentes sistemas.
Além das infinitas integrações, os aparelhos também possuem um baixo custo de
aquisição e até mesmo manutenção quando comparamos com hardwares dedicados.
Esse cenário permite que os desenvolvedores explorem os potentes hardwares que
os telefones possuem. Como exemplo, é possível utilizar a câmera para algum tipo de
realidade virtual aumentada, consultar um endereço no Google Maps ou até mesmo
explorar o acelerômetro do dispositivo. Dessa forma, a eficiência da plataforma
juntamente com a alta oferta de internet facilitou e barateou a automação comercial.
Há alguns anos, para que um restaurante conseguisse uma automação simples de
pedido, ou seja, realizar o atendimento do cliente e envio para o local responsável dentro
do estabelecimento era necessário um dispositivo dedicado. Isso aumentava o preço de
custo, manutenção e até mesmo de melhoria e atualização do sistema, pois tudo era muito
restrito aos desenvolvedores e técnicos de manutenção.
Hoje, utilizando-se apenas um celular é possível realizar uma conexão com um
servidor, que recebe o pedido e direciona para um computador ou mesmo um outro
dispositivo, o qual a encaminhará à área interna. Isso com toda a certeza trouxe avanços
para grandes empresas, mas beneficiando também pequenos empreendedores que
conseguiram automatizar seus processos de maneira barata.
16
1.2. Objetivos
O tema escolhido para esse trabalho foi desenvolver um protótipo de automação do
processo de venda de fichas de consumo para o setor de bares e restaurantes, desde a
criação do login e carteira digital do cliente, como o direcionamento e armazenamento de
todas as informações de produtos e usuários diretamente na nuvem, utilizando uma
plataforma do Google.
O foco do projeto será na criação de toda a automação para a venda de fichas e na
entrega do produto pelo balconista, onde ambos utilizarão o mesmo aplicativo, gerando
eficiência e integração total dos dados. Nesse projeto, entretanto, não foi considerado a
implementação de nenhuma empresa financeira para realizar a venda no cartão de crédito
efetivamente.
A escolha do tema tem como motivo, a redução de custos, aumento de eficiência e
também a criação de um banco de dados com todas as informações dos consumidores do
estabelecimento que é extremamente valioso para qualquer ação de publicidade ou venda
e que hoje apenas as grandes empresas se utilizam dessas informações.
17
2. FUNDAMENTAÇÃO TEÓRICA
2.1. Estrutura Android
A plataforma Android é formada por diversas camadas e muitos componentes
diferentes e distintos desde funções básicas como armazenamento de contatos a até
mesmo um conjunto de APIs e bibliotecas de apoio.
A plataforma Android pode ser considerada, ou melhor, comparada a uma pilha de
softwares distribuída em camadas com conjunto de bibliotecas e APIs e seu
SDK(Software Development Kit). A figura 5 abaixo, é capaz de exemplificar toda essa
estrutura. (FINCOTTO, 2014)
Figura 5 - Camadas da Plataforma Android
2.1.1. Núcleo Linux
A camada que está sob todas as outras da “pilha”, ou seja, a base da plataforma é
denominada Núcleo Linux. Essa parte da estrutura é a responsável por realizar toda a
18
comunicação entre as aplicações, ou seja, a parte virtual do aplicativo e o hardware. Isso
determina que essa camada seja o intermediário entre o comando realizado via código, e
o componente do dispositivo, por exemplo, uma câmera ou a saída de som. Além dessa
ponte entre o virtual e o real, o núcleo também é responsável pelo gerenciamento de
memória, processos e aplicações. (FINCOTTO, 2014).
2.1.2. Bibliotecas
Nessa camada estão todas as bibliotecas nativas do Android, ou seja, aquelas
bibliotecas que estão disponíveis para qualquer desenvolvedor fazer e que já estão
contempladas no sistema operacional. Essa biblioteca reúne diversas classes, auxiliando,
portanto, no desenvolvimento das aplicações e sistemas. Essas bibliotecas são escritas em
código C e C++, que são expostas por meio das APIs de framework. (GRIFFITHS, 2014)
As bibliotecas mais utilizadas são:
• Webkit: Biblioteca utilizada para interpretar e exibir páginas WEB e
conteúdos HTML (HyperText Markup).
• Telephony Manager: utilizada para obter os dados básicos do telefone, como
por exemplo rede de cobertura, bateria, status de conexão.
• Location Manager: Utilizado para obter dados de geolocalização do
dispositivo, muito utilizado em aplicações que utilizam uma referência de
posicionamento global (GPS – Global Positioning System).
2.1.3. Tempo de Execução (Android Runtime)
Essa camada possui um grupo de bibliotecas do núcleo Java e da máquina virtual
Dalvik. Todas as linhas de código programadas em código Java no Android, são
executadas sobre essa máquina virtual em um processo e instâncias únicos. (FINCOTTO,
2014).
Essa máquina virtual foi projetada para ter alto desempenho e executar vários
processos paralelos e não executar os byte-codes do Java mas compilar e converter para
um formato específico executado na máquina virtual.
19
2.1.4. Framework de Aplicativos
Essa camada possui os programas que gerenciam as funcionalidades básicas do
telefone. Esse nível possui um grupo de recursos que possibilitam o desenvolvimento das
aplicações dos sistemas, tais como criação de listas, botões e até mesmo as integrações
com os hardwares do dispositivo. (ANDROID DEVELOPERS, 2014)
2.1.5. Aplicações
As aplicações são todas as funcionalidades virtuais intrínsecas do telefone. Todo
dispositivo Android vem com um conjunto de aplicativos básicos, como por exemplo,
Envio de SMS, Calendários, Navegador de Internet e outro bem conhecidos pelos
usuários de smartphones.
Esses aplicativos “nativos” do Android não possuem qualquer condição especial
que qualquer outro aplicativo que o usuário venha a instalar, ou seja, caso o usuário queira
trocar o aplicativo que envia SMS ou mesmo a agenda de contatos, ele conseguirá sem
problemas. Mas o ponto mais relevante dessas aplicações, é que eles podem ser facilmente
acessados por qualquer outro aplicativo, sendo ele nativo ou não. Por exemplo: se em um
desenvolvimento do sistema, uma parte do processo automático contempla o envio de
SMS.
Nesse caso, não é necessário gastar tempo e investimento com essa programação.
Basta realizar a integração com a aplicação de envio de SMS nativo da plataforma e focar
todos os esforços no desenvolvimento do que realmente é necessário. (BORGES, 2015)
2.2. Computação em Nuvem
Atualmente qualquer empresa que visa manter competitividade no mercado, deve
investir em tecnologia, e nesse caso em tecnologia da informação para manter todos os
sistemas interligados com muita rapidez, estabilidade e alto desempenho. Dessa maneira,
a computação em nuvem, é o mais novo recurso que grandes players do mercado estão
utilizando para usar e extrair resultado de informações que são geradas e capturadas. Com
o avanço das startups, ou seja, pequenos empreendedores da tecnologia com foco no
trabalho colaborativo, companhias de pequeno porte também estão se interessando e
20
conseguindo utilizar o armazenamento de dados em uma “nuvem”. Além do
armazenamento, os empresários podem transferir grande parte das camadas de TI de uma
empresa para os provedores, e assim ter um foco mais concentrado nas estratégias de
negócio da empresa deixando de lado questões processuais e operacionais que a gestão
de TI determina.
Podemos definir a computação em nuvem como um conjunto de serviços baseado
na WEB com o intuito de fornecer diferentes funcionalidades e soluções para as
companhias. Até o surgimento e a definição do conceito de computação em nuvem, para
que isso fosse possível um alto investimento era necessário e é o que determina a
característica marcante na solução: o modelo de cobrança. Essa alteração do modelo,
determinou uma verdadeira revolução nas empresas pois um paradigma do ponto de vista
financeiro foi quebrado. (BORGES, 2015)
O NIST (National Institute of Standards and Technology – USA), define a
computação em nuvem como um conveniente modelo de acesso, a um grupo de recursos
compartilhados configuráveis, que são disponibilizados de maneira ágil, com o mínimo
de interação possível com o provedor dos serviços. Algumas características essenciais
também foram definidas pelo instituto Americano:
• Virtualização de recursos
• Serviços sob demanda
• Independência de localização
• Elasticidade e Escalabilidade
• Medição dos Serviços
• Repositórios de Recursos
Dentre as características acima definidas pelo NIST, podemos destacar a questão
do Serviço Sob Demanda, Independência de Localização, Elasticidade e Escalabilidade e
a Medição dos serviços.
2.2.1. Serviço sob demanda
Um dos aspectos marcantes desse tipo de tecnologia, onde o cliente pode requerer
maior ou menor quantidade de recursos, sem a necessidade de interação humana com o
21
provedor. Isso determina que o próprio cliente, através de um aplicativo do celular, uma
aplicação no computador ou mesmo uma solução WEB possa requisitar mais recursos
para sua empresa em situações pontuais onde um aumento no processamento de dados é
necessário.
2.2.2. Independência de localização
Todo o serviço está disponível através de rede e internet, tornando o usuário capaz
de acessar as informações de diferentes dispositivos, em plataformas diferentes como por
exemplo: telefones, computadores e tablets. Nesse caso, a nuvem funciona como um
acesso centralizado, disponível a todo tempo e em qualquer lugar. Isso faz com que a
empresa possa mudar de endereço, de cidade e até mesmo de país de uma maneira muito
mais fácil e rápida já que toda a camada de TI está alocada em uma nuvem.
2.2.3. Elasticidade e Escalabilidade
A elasticidade é a característica que mais quebra os paradigmas da tecnologia da
informação nas companhias. Ela é definida pela capacidade de fornecer e remover
recursos em tempo de execução, não dependendo de quanto o cliente solicitou.
(BORGES, 2015).
Aliada a elasticidade, a escalabilidade é definida basicamente pelo aumento da
capacidade de processamento ou trabalho pela adição de recursos proporcionalmente.
(BORGES, 2015)
Dessa maneira, todo o serviço é disponibilizado sete dias por semana, 24 horas por
dia onde em períodos de pico recursos são fornecidos, e quando a demanda cai, ocorre a
retirada de capacidade.
2.2.4. Medição dos Serviços
Essa é a característica mais interessante do ponto de vista financeiro da empresa,
pois é possível mensurar exatamente o gasto com o serviço, melhorando, portanto, o
controle se está acima ou abaixo, não onerando em nenhum momento a eficiência do
serviço. Dessa maneira, a empresa tem a plena certeza que está utilizando a estrutura
22
correta para o tamanho do processamento de dados, evitando lentidão dos servidores por
falta de investimento ou mesmo gastos desnecessários com componentes extras. Vamos
utilizar o exemplo de contas de água e luz. Esses serviços estão disponíveis para todos,
24 horas por dia, 7 dias por semana, porém existe a cobrança quando ocorre o uso,
portanto caso você precise 1000 litros de água basta abrir a torneira que o fornecimento
acontece e o mesmo é válido caso seja necessário apenas 1 litro. Essa analogia define
exatamente o modelo normalmente utilizado na computação em nuvem. Este modelo
agrega transparência no serviço, tanto para o fornecedor quanto para o cliente, com base
em SLAs (Service Level Agreement) e QoS(Quality of Serviece) para especificar os
valores a serem cobrados.
Dessa maneira, devido todas essas características, cada vez mais, as empresas estão
evoluindo suas camadas de TI determinando, portanto, um desenvolvimento acelerado de
provedores de serviços de computação em nuvem pois, como citamos acima, é um
investimento assertivo onde o desperdício é zero. (BORGES, 2015)
2.3. Google Firebase
Desenvolvido pelo Google, o Firebase é uma plataforma que contém diversos
produtos distribuídos de forma gratuita para os usuários. Porém, a disponibilização possui
limites de utilização em alguns casos. As funcionalidades são as mais diversas, porém,
utilizamos nesse trabalho, os seguintes produtos:
Serviço de Hospedagem
Monitoramento de Usuário
Login e Gestão de Usuários
Banco de Dados
Essa potente ferramenta WEB possui bibliotecas prontas e integrações estruturadas
que com poucas linhas de código é possível adicionar o banco de dados, inserir o modelo
de gestão de usuários e até mesmo armazenar figuras e imagens. Essas funcionalidades
facilitam o desenvolvimento da aplicação e agilizam o trabalho. (FIREBASE GOOGLE)
A utilização do Firebase está interligada com uma conta Google, ou seja, é um
produto fornecido pela Google para todos os usuários que possuem uma conta Gmail.
Abaixo estão todos os produtos que foram utilizados nesse trabalho.
23
2.3.1. Login de Usuários (Authentication)
Em praticamente todos os aplicativos, é necessário ou no mínimo interessante,
reconhecer a identidade do usuário. Assim, essa funcionalidade do Firebase permite que
os usuários se cadastrem, fornecendo algumas informações que são armazenadas no
banco de dados.
Nesse sentido, o produto de autenticação do Firebase fornece SDKs prontas e fáceis
de usar, bem como bibliotecas para implementar rapidamente o ponto de cadastro dos
usuários. Ele permite que essa autenticação seja feita de diferentes maneiras, por diversas
redes sociais e informações. Na figura 6, pode-se observar todas as opções que o produto
de usuários do Firebase nos fornece.
Figura 6 - Opções de conexões para login do usuário
2.3.2. Realtime Database
Dentro da plataforma do Firebase, existe o “produto” ou podemos chamar de
funcionalidade do banco de dados. Esse banco é alocado na nuvem, ou seja, fica
armazenado direto na plataforma nos servidores do Google, e possui uma arquitetura
NoSQL, ou seja, não existe uma estrutura de tabela, e sim uma lógica de “nós”.
(FIREBASE GOOGLE, 2016)
24
Todas as informações que são alocados no DataBase do Firebase são armazenadas
como objetos JSON, sendo que o banco de dados funciona como uma árvore JSON
hospedada na nuvem. Esse tipo de estrutura “em árvore” não apresenta nenhum tipo de
tabelas nem registros, e em toda marcação que fazemos no banco, ela se torna um nó
associado a uma chave que podemos classificar como principais e filhos. Podemos ter até
32 níveis de chaves, e como boa prática nesse tipo de estrutura deve-se evitar o uso de
chaves muito “profundas” e buscar sempre a redundância das informações para garantir
a rapidez e simplicidade na hora de recuperar os dados do banco. Abaixo temos um
exemplo de um banco de dados que armazena dados dos usuários, suas expressões e
quantos votos cada expressão obteve:
Figura 7 - Exemplo banco de dados Firebase. Retirada de https://www.appcoda.com/wp-content/uploads/2016/02/joke-firebase-data.png
No exemplo acima, temos dois nós principais “jokes” e “users”. O nó “users” estão
todas as informações dos usuários (e-mail, provider e username) e também o nó “votes”
que contabiliza todos os votos do usuário. Temos dois usuários cadastrados nesse banco
de dados identificados no nó com um ID alfanumérico gerado pelo próprio Firebase para
distinguir os usuários.
No outro nó estão as informações das expressões, ou como estão denominadas no
exemplo “Jokes”, e todas as suas informações. Percebe-se que temos informações
duplicadas nos nós, como por exemplo número de votos, ou mesmo o nome do autor,
25
porém para simplificar as consultas e extração dos dados, a redundância determina uma
boa prática para esse tipo de estrutura de dados.
2.4. Proposição
Levando em consideração todos os tópicos apresentados na introdução deste
trabalho, pontos abordados na revisão de literatura e também visando uma possível
implementação real do projeto, decidiu-se desenvolver uma automação para vendas de
fichas virtuais com foco em estabelecimentos do setor de bares e restaurantes. Visou-se
correlacionar todo o conceito da programação aprendida durante o cursou de controle e
automação com a aplicabilidade dos principais elementos da automação comercial. Esse
trabalho não visa a implementação de um sistema de venda envolvendo moedas reais, e
sim o conceito da automação e lógica do sistema.
2.5. Metodologia
Esse projeto tem como proposição o desenvolvimento de um aplicativo capaz de
automatizar a venda e retirada de produtos que são vendidos em bares e restaurantes. Toda
a estrutura leva em consideração uma venda simples sem a efetivação da cobrança por
cartão de crédito, que pode ser facilmente integrada com qualquer plataforma.
O aplicativo proposto tem o intuito de facilitar a venda em estabelecimentos que
utilizam fichas de consumo ao invés de comandas eletrônicas. A rastreabilidade e
validação dos dados é feito tudo vida QrCode, melhorando a segurança e como utilizamos
base de dados em nuvem a blindagem das informações é garantida.
Para facilitar o desenvolvimento, dividimos as atividades em etapas:
• Etapa 1: Mapeamento do fluxo existente nos bares e identificação dos pontos de
automação.
• Etapa 2: Esboço da estrutura principal do aplicativo
• Etapa 3: Preparação do ambiente de desenvolvimento (Android Studio)
• Etapa 4: Integração com a plataforma Firebase
26
• Etapa 5: Leitura e geração de QrCode
Antes de qualquer tipo de programação, ou mesmo desenho de tela, foi necessário
realizar um mapeamento completo de um ambiente de venda de fichas. Para isso
utilizamos exemplos de estabelecimentos que possuem esse tipo de sistema (fichas de
papel) e foram mapeadas diversas oportunidades de melhorias e também de automação.
Dessa maneira, após todo o estudo desse simples modelo de venda de fichas, foi
possível determinar um fluxo de como funciona a venda com fichas de papel e assim
determinar os pontos a serem automatizados. Abaixo temos o fluxo do uso de fichas
físicas:
Figura 8 - Modelo Venda de Fichas de Papel
No fluxo acima, aparentemente parece muito simples, com poucas etapas, porém
da percepção de controle, automação e mesmo na questão de experiência do cliente é
muito precário. O sistema de uso de fichas de papel não possui nenhum armazenamento
computacional, sequer uma validação dos dados. Abaixo todos os passos desse sistema.
• O passo 1 é momento que o cliente deve ir até o caixa e realizar a compra da
ficha. Nesse momento é necessário um funcionário para realizar a cobrança do
produto e a entrega da ficha, e há a possibilidade do consumidor ficar na fila
para realizar a compra, impactando e muito a experiência de nosso cliente.
• Após realizar a compra, o cliente armazena as fichas de papel para ir realizar a
retirada. Esse armazenamento é de feito pelo próprio cliente, que coloca as
fichas no bolso ou na carteira.
27
• Na retirada é necessário ir até o balcão e entregar a ficha, e assim o colaborador
do estabelecimento realiza a entrega.
Observa-se, portanto, um trabalho muito grande desde o início da compra, onde é
necessário ficar numa fila, realizar o pagamento e também dirigir-se para retirar o produto
desejado e também um investimento por parte do estabelecimento em diversos
funcionários para fazer o atendimento. Além do custo e da experiência do cliente, temos
que existe o risco de fraude no sistema de ficha de papel, podendo causar prejuízos
enormes para a empresa.
Assim, listamos nossos 4 pontos principais para o desenvolvimento da estrutura do
protótipo do aplicativo:
• Experiência do Cliente
• Custo com funcionário
• Fraude
• Big DATA
2.6. Definição do Escopo do Projeto
Após a estruturação de todo o conceito e objetivo da automação, foi necessário
realizar uma pesquisa (benchmarking) para entender e conhecer as principais
características de outros aplicativos disponíveis no mercado. Esse mapeamento tem como
principal função levantar os pontos relevantes de outros sistemas e aplicar no projeto.
Nessa pesquisa realizada, não foi encontrado nenhum aplicativo semelhante ao proposto
neste trabalho, porém foi identificado um sistema com funcionalidades com algum grau
de proximidade. A automação que foi considerada mais próxima ao do escopo proposto
é do restaurante STUE.
28
Figura 9 - Aplicativo utilizado para referência
Esse restaurante possui uma culinária brasileira, com o conceito de pratos menores,
ou seja, em uma porção mais diminuta. Esse modelo permite que o consumidor tenha a
chance de provar mais de um prato em uma refeição, aproveitando melhor o cardápio.
Dessa maneira, o consumidor realiza diversos pedidos, ou seja, a frequência que um
garçom teria que atendê-lo seria muito maior e consequentemente o número de garçons
teria que ser aumentado para que todos tivessem um bom atendimento. Com isso, o
aplicativo do estabelecimento auxilia na velocidade e também na facilidade dos pedidos.
Na figura 10 abaixo, temos uma estrutura de como funciona o aplicativo em questão.
29
Figura 10 - Modelo do Aplicativo STUE
2.6.1. Cliente (1)
O cliente entra no estabelecimento e é recebido por um funcionário do restaurante
que o acomoda na mesa mais apropriada. Essa função de receber o consumidor e
acomodá-lo não é interessante retirar, já que faz parte da experiência do usuário.
Porém, uma diferença existe, o garçom não entrega um cardápio para o consumidor
pois o consumidor consegue realizar o pedido diretamente do celular, sem
necessitar chamar o colaborador novamente.
2.6.2. Realizando o Pedido e Pagamento (2)
Após ser recebido, analisar o cardápio o cliente pode escolher sozinho quais opções
que deseja e realizar o pedido. Esse pedido é feito diretamente pelo seu próprio
celular, portanto cada um faz seu próprio pedido, e já realiza o pagamento via cartão
de crédito.
30
2.6.3. Envio do Pedido (3)
Após realizar o pagamento, o pedido é enviado para o local correto dentro do
estabelecimento, ou seja, o sistema é capaz de enviar para a cozinha tudo que for
comida, e também envia para o balcão todas as bebidas. Dessa maneira, a entrega
se torna mais rápida e mais eficiente, possibilitando um aumento de faturamento
para a empresa.
2.6.4. Entrega do Pedido (4)
Assim que o pedido está pronto, seja na cozinha ou no balcão, o garçom é avisado
e realiza a entrega para o consumidor. Como o pedido foi pago antecipadamente, o cliente
pode levantar e ir embora a hora que desejar evitando, portanto, filas e qualquer tipo de
espera para o fechamento da conta.
Levando em consideração a referência do aplicativo pesquisado, foram levantados
todos os pontos que poderiam ser utilizados como exemplo nesse trabalho e assim
definimos o escopo do sistema considerando as peculiaridades do negócio em questão, e
também as limitações que o ambiente possui.
O aplicativo em questão é o mesmo para o estabelecimento e também para o
empresário, ou seja, o tipo de usuário é determinado logo na autenticação. Na tela inicial,
o usuário deve necessariamente realizar o login e caso não tenha, deverá realizar o
cadastro. O cadastro é realizado somente para usuário comuns, enquanto os
administradores do sistema, isto é, os colaboradores do estabelecimento são cadastrados
diretamente na ferramenta Firebase. O armazenamento na nuvem garante que exista uma
segurança a respeito do acesso aos dados do banco de dados, pois existe uma blindagem
e, portanto, apenas o administrador consegue acessar os dados.
A estrutura de banco de dados escolhida atende todos os requisitos do projeto que
tem como principal função o acesso fácil e rápido por dispositivos móveis. Além disso,
temos a segurança que os dados não serão perdidos, ou seja, fica localizado em um bando
de dados em nuvem.
Na figura 11, temos a estrutura básica do aplicativo:
31
Figura 11 - Estrutura Básico do Aplicativo do Projeto
Primeiramente existe um cadastro do usuário para que o cliente consiga ser
identificado pelo sistema. Essa validação é essencial pois toda a estrutura do banco de
dados está no ID do usuário que o Firebase gera, pois ele é único e cada “tabela” que no
banco de dados “noSql” é chamado de nó, é determinada pelo usuário.
Após a validação do usuário no aplicativo, que é realizada por uma funcionalidade
raiz do Firebase o consumidor pode escolher o produto e realizar a compra que é
representada pelo bloco “Venda da Ficha”. Como a estrutura de validação do usuário é
fornecida diretamente pela plataforma, nem mesmo o administrador do sistema tem
acesso às informações dos usuários, determinando uma blindagem completa das
informações sensíveis. Vale ressaltar que nesse projeto não está sendo considerada a
venda por completo, ou seja, realizar o cadastro de cartão de crédito e a venda de fato,
porém toda a estrutura está preparada para receber essa funcionalidade.
Cada ficha que é vendida, é armazenada no banco de dados na “carteira digital” do
cliente com um número único que será utilizado para realizar a retirada do produto. Esse
número único será utilizado para gerar o QrCode necessário para a validação no banco
de dados. Essa validação ocorre para evitar fraudes, confirmando sempre se a ficha está
paga, foi retirada ou simplesmente não existe.
O código gerado é transparente para o usuário final, e, portanto, apena é visível de
forma bem simples todas as fichas que o usuário tem disponível para retirar. Esse
32
armazenamento determina uma carteira virtual do consumidor que possibilita uma gestão
de todas as fichas.
No momento da retirada, o cliente seleciona a ficha desejada e gera o QR Code na
tela do aplicativo. Para validar o produto, é necessário apresentar esse código para o
funcionário do estabelecimento que vai realizar a leitura com um outro dispositivo mível.
Essa função realiza a consulta no banco de dados e retorna todas as informações da ficha,
informando para o colaborador se deve ou não entregar o produto.
33
3. DESENVOLVIMENTO
Considerando todo o escopo apresentado, as telas foram desenhadas e
desenvolvidas de acordo com as ferramentas disponibilizadas.
3.1. Preparação do Ambiente Android
O Android Studio é o ambiente oficial para qualquer desenvolvimento para a
plataforma do Google. Esse IDE, Ambiente de Desenvolvimento Integrado em Português,
é baseado no IntellJ IDEA que possui muitas outras ferramentas para incrementar e
aumentar as funcionalidades dos aplicativos Android. (DEVELOPER ANDROID, 2017).
IntellJ IDEA é um ambiente de desenvolvimento Java para computadores que
utilizam sistema operacional Linux e que trabalham com Frameworks, serviços
corporativos e dispositivos móveis. (DEVELOPER ANDROID, 2017).
Assim, determinou-se que essa seria a ferramenta principal para todo o
desenvolvimento do sistema. Esse ambiente de desenvolvimento está disponível
gratuitamente no site do Google (https://developer.android.com/studio), conforme a
imagem 12.
Figura 12 - Página WEB Android Studio
34
3.2. Estrutura Geral das Telas
Aplicativos Android são feitos basicamente de telas e comandos de como elas se
relacionam. Dessa maneira, na construção do aplicativo determinou-se telas principais,
ou seja, quais eram as funcionalidades que necessariamente o aplicativo requisitava e,
após a estruturação dessas telas principais outras telas suportes foram construídas.
Abaixo, foi listada todas as telas que direcionam todo o funcionamento do aplicativo.
• Tela Inicial de Login
• Telas de Cadastro de Usuário
• Telas de Compra de Ficha
• Telas Gestão de Fichas
• Tela de Retirada de Produto Balcão
As telas foram desenvolvidas com o apoio das bibliotecas do Android Studio que
são baseadas em código xml com o auxílio do ambiente da plataforma de
desenvolvimento.
3.3. Tela Inicial de Login
A tela de login é a primeira tela do aplicativo e contém os campos para a realização
da validação do usuário bem como a logomarca da empresa utilizada como exemplo.
Assim, é nesse primeiro momento que a identificação do usuário é realizada, e caso o
usuário não tenha cadastro no sistema, ou seja, caso seja o primeiro acesso um botão para
então realizar o envio dos dados é disponibilizado. Na imagem 13, temos a primeira tela
que o usuário interage.
35
Figura 13 - Tela Login
Portanto, para seguir com a utilização do aplicativo o usuário deve se logar, ou seja,
o sistema deve validar quem é que está usando o aplicativo e dessa maneira resgatar todas
as informações do usuário em questão na base de dados. Na automação proposta,
determinou-se que o login é formado por um e-mail e a senha deve ser composta por letras
e números.
3.4. Telas Cadastro Usuário
Todo usuário do sistema deve realizar o cadastro para conseguir acessar. É nesse
ponto do processo que capturamos informações muito importantes para identificar o
usuário. Toda a estrutura de cadastro de dados pessoas desse projeto é baseado em
informações simples, porém é possível colocar diversos itens para enriquecer o banco de
dados de usuários, que pode ser utilizado para outros fins como, por exemplo, estudos e
análises, mediante um termo de uso que regulamente a manipulação dos dados.
O cadastro é feito em duas telas diferentes:
• Tela de inserção de login, senha e confirmação de senha.
36
Figura 14 - Tela 1 Cadastro - Senha e Usuário
• Tela de cadastro de informações pessoais do usuário:
Figura 15 - Tela 2 Cadastro - Informações Pessoais
As caixas de textos foram programadas para formatar os campos automaticamente,
ou seja, os campos CPF levam um formato padrão (XXX.XXX.XXX-XX) e o telefone
(XX) X XXXX-XXX. Na tela de entrada de senha, caso as senhas não sejam compatíveis
o usuário não consegue realizar o acesso.
3.5. Tela Compra Ficha
Após o login do usuário, a tela de compra de fichas é automaticamente aberta, e
dessa maneira possibilita o cliente dar o comando de compra de qualquer produto ali
37
disponível. Na tela de compra, temos 3 grandes grupos de produtos, divididos por sua
categoria: Cervejas, Doses e Refrigerantes. Dessa maneira o usuário consegue navegar
mais rapidamente pelos comandos e também facilitar o bloqueio de algumas seções por
parte do aplicativo, caso o usuário seja identificado como menor de idade.
Cada produto disponível é apresentado de forma horizontal, e cada linha possui a
foto, informações relevantes (preço, origem, entre outros) e o botão para efetuar a venda.
Figura 16 - Produtos disponíveis venda Cervejas
Figura 17 - Produtos Disponíveis Dose
38
Figura 18 - Produtos Disponíveis Refrigerantes
Figura 19 - Produtos Cadastrados
3.6. Telas Gestão de Fichas
Após o usuário comprar a ficha desejada, esse voucher fica disponível na tela de
gestão de fichas. Essa tela possui duas abas: Fichas Disponíveis e Histórico. Na primeira
aba, é possível visualizar todas as fichas que o usuário efetuou a compra e que ainda não
retirou, ou seja, as fichas que ele ainda tem na carteira. Nessa seção, observa-se as
informações da ficha: Quantidade, Nome, Data da Compra e Preço.
Na segunda aba, denominada de histórico, apresenta para o usuário todas aquelas
fichas que já foram retiradas no balcão do estabelecimento. Essa parte fornece ao usuário
o controle das fichas já utilizadas e quando foram utilizadas. Dessa maneira, uma ficha
que foi comprada, aparece inicialmente na aba de fichas existentes, e após a retirada é
retirada dessa página e aparece no item histórico da tela de gestão de fichas.
39
Figura 20 - Aba Fichas Disponíveis
Figura 21 - Aba produtos já retirados (Histórico)
3.7. Telas Retirada Produto Balcão
As telas apresentadas no item anterior, são exclusivamente utilizadas pelo usuário,
ou seja, pelo cliente ou consumidor. Mas no sistema proposto, o colaborador do
estabelecimento utiliza o mesmo aplicativo, diminuindo custos e facilitando a
manutenção. Assim, existe uma diferenciação do usuário comum com o administrador,
ou seja, do funcionário que irá confirmar a compra da ficha pelo cliente realizando a
leitura do QR CODE gerado e assim entregar o produto. A tela do administrador é
simples, sendo necessário, portanto, apenas um botão para realizar a leitura, e outra tela
40
que traz todas as informações da ficha. Na figura 22, temos as telas que compõe a vista
de administrador.
Figura 22 - Tela de administrador para iniciar leitura
Figura 23 - Tela de Administrador para confirmação de dados do produto
Dessa maneira, o funcionário é capaz de validar a quantidade de produtos, preço e
também data da compra, visto que a ficha permanece na carteira do cliente. Todas as
informações são capturadas a partir do QR CODE que foi lido, pois cada ficha possui um
ID único, e a partir desse número todas as informações são acessadas no banco de dados.
41
O campo mais importante dessa tela, é o campo “Status”. No banco de dados, a
ficha tem a informação se já foi retirada ou não, ou mesmo se teve algum problema no
pagamento. A entrega do produto só é feita se o Status está como “Pago”. Isso evita
fraudes, já que toda a validação é feita diretamente no banco de dados.
3.8. Estrutura Banco de Dados
Toda a estrutura do aplicativo é baseado no banco de dados fornecido pelo Firebase,
uma plataforma Google. Essa plataforma possui toda a API necessária para que o
aplicativo acesse o banco, escreve e recupere os dados necessário.
A conexão do banco de dados é determinada no mesmo momento em que
adicionamos o Firebase ao nosso projeto, ou seja, após essa sincronização todas as
funções da plataforma estão disponíveis para serem utilizadas.
Inicialmente para definir a nossa estrutura de banco de dados, levantamos todos os
tipos de “tabelas” que seriam necessárias, isso pois no Firebase não possuímos tabelas e
sim nós. No Firebase existe uma orientação de utilizar dados redundantes em diferentes
tabelas, para facilitar e agilizar a leitura. Levando isso em consideração, 4 nós foram
determinados e estão representados na figura 24.
• Informações das Vendas: Esse nó é uma base onde todas as vendas são
armazenadas, ou seja, uma base analítica que traz todas as informações.
• Fichas Disponíveis: Nó utilizado exclusivamente para armazenar as fichas
disponíveis.
• Fichas Retiradas ou Histórico: Nó utilizado para armazenar todas as informações
de fichas já retiradas.
• Informações dos usuários: Nesse nó as informações dos usuários são
armazenadas.
42
Figura 24 - Estrutura Macro do Banco de Dados
Dessa maneira, as informações são armazenadas abaixo desses nós. Cada nó raiz
pode ter vários nós filhos, ou seja, podemos expandir várias vezes e assim relacionar as
informações que desejamos.
Todas as vendas possuem um ID único, ou seja, nenhuma outra venda possuirá esse
código e, portanto, utilizamos essa chave para criar os nós “filhos”, pois assim
conseguimos facilmente recuperar os dados específicos de uma venda na tela do
aplicativo.
Portanto, utilizamos para o nó que armazenamos todas as vendas realizadas:
Figura 25 - Estrutura Nó Venda
Na imagem 25, conseguimos visualizar todas as informações de uma venda:
• dia: Data da compra da Ficha
• dia_retirado: Data da retirada do produto
• func_retirado: Nome do colaborador que realizou a retirada do produto
• preço: qual foi o preço pago por cada produto
43
• produto: Qual foi o produto em questão
• quantidade: Número de produtos comprados
• Status: Nesse item a marcação do produto é realizada, ou seja, é o campo
que sabemos se o item foi retirado ou não.
• User: quem foi o cliente que compro. Nesse campo não é marcado o nome
que o cliente cadastrou, mas sim o número que o firebase gerou para o
usuário que é um número única para cada usuário.
Em nosso outro nó, armazenamos todas as fichas disponíveis de cada usuário. Nessa
estrutura foi determinado que além do nó com o ID da venda temos também um nó filho
com o ID do usuário. Dessa maneira, temos 3 níveis de nós sendo que o primeiro é o nó
Mãe, seguido pelo nó do usuário e na ponta temos o nó da venda em si. Essa estrutura foi
escolhida, pois facilita, e muito, a recuperação dos dados melhorando o processamento
de dados tornando a recuperação mais rápida.
Figura 26 - Estrutura Fichas Disponíveis
Na figura 26 é possível perceber a relação das informações. No primeiro nível, na
raiz, temos o nó de fichas disponíveis como o nó mãe. O segundo nível é formado pelo
usuário, ou seja, pelo cliente e tudo o que está abaixo desse nó pertence a esse cliente.
Dessa maneira, agrupamos as informações de forma redundante, porém isso facilita o
44
acesso e recuperação das informações. No terceiro nível temos todas as fichas do usuário,
e as informações dessa ficha. Assim podemos assumir que os nós dessa estrutura
assumem a seguinte hierarquia:
No Mãe -> Filho 1 -> Filho 2 -> Informações
Assim, o que interessa para o aplicativo nessa estrutura são as informações,
enquanto todos os outros nós são apenas para conseguirmos navegar e retornar as
informações desejadas. Nessa estrutura, temos o “nó filho 1” que é o agrupamento por
usuário das fichas, enquanto o “nó filho 2” é a ficha em questão. Dessa maneira, temos
sempre uma relação entre os nós e assim é possível recuperar a venda certa.
No código de recuperação de dados, conseguimos determinar qual nó filho vamos
procurar pois o usuário está identificado, e assim realizamos uma espécie de filtro e
procuramos o nó do usuário e assim recuperamos todas as fichas disponíveis e são
mostradas na tela de fichas disponíveis.
Portanto, dessa maneira armazenamos nesse nó:
• dia: data da compra da ficha
• idvenda: número único da venda
• preco: valor pago em cada ficha no momento da compra
• produto: produto que foi comprado
• quantidade: número de produtos comprado
Foi criada uma tabela de fichas já utilizadas, com o nome de
“user_fichas_historico” e possui a mesma relação de nós filhos e nós mães do mostrado
na estrutura de fichas disponíveis. As informações armazenadas são praticamente as
mesmas, porém são usadas em telas diferentes e em situações distintas. Como já
apresentamos nesse documento, a redundância é uma característica dessa estrutura de
banco de dados pois deixa as consultas mais rápidas.
45
Figura 27 - Estrutura Fichas Histórico
Nesse nó temos todas as informações do outro mais a informação do colaborar que
atendeu. Dessa maneira, basicamente transferimos os dados de um nó para outro quando
ocorre a retirada do produto. A hierarquia entre nós é a mesma do nó anterior, portanto
temos as fichas agrupadas por cliente, facilitando a recuperação.
O último nó de nosso banco de dados traz todas as informações do cliente. Esses
dados são capturados durante o cadastro no primeiro login. Essa é a parte mais valiosa no
quesito de estratégia de publicidade. Com as informações capturadas e armazenadas nessa
parte, é possível cruzar com os dados de vendas e estabelecer estratégias de campanhas
publicitárias.
Nesse projeto determinamos alguns dados, porém quanto mais informações for
capturada dos clientes, mais rica a base de dados se torna.
46
Figura 28 - Estrutura Informações Usuários
Conforme podemos observar na figura 28, a estrutura é mais simples que a de
fichas. Nessa base, armazenamos os seguintes dados:
• cidade: Cidade do Usuário
• datanascimento: Data de Nascimento do Usuário
• endereço: Endereço do Usuário
• estado: Estado
• Nome: Nome do usuário
• Telefone: telefone do usuário
Assim, todo o aplicativo está baseado nesses quatro nós abordados, e ao cruzarmos
todos esses dados, conseguimos relacionar as telas e manipular os dados através dos
códigos.
Toda essa funcionalidade fica armazenada na nuvem, e acontece em tempo real e é
possível observar com o aplicativo em funcionamento.
47
4. Resultados e Discussões
Após toda a estruturação e programação, realizamos um teste completo com uma
jornada completa. Para isso, foi necessário instalar em dois aparelhos verdadeiro o
sistema, para que fosse possível testar a compra e a retirada da ficha. Utilizou-se um
aparelho Motorola Moto G5 Plus com um sistema Android 7.0.
Figura 29 - Celular Motorola G5
Dessa maneira, após a instalação iniciamos os testes fora do ambiente virtual do
Android Studio para analisar o comportamento de todos os comandos e telas. Para iniciar
esse funcionamento, utilizamos 2 usuários diferentes com o objetivo de observar o
comportamento da base de dados e também do processamento de dados. Na figura 30, é
possível observar a simulação da inserção dos dados de cadastro.
48
Figura 30 - Telas cadastro do usuário Pedro
Consideramos os dados abaixo para os testes no banco de dados:
Usuário 1
Nome: Pedro Carvalho Grassetti
Data de Nascimento: 10/06/1992
Endereço: Rua Bahia 999
Cidade: Avaré
Estado: São Paulo
Telefone: (11) 9 8765-4321
Email: [email protected]
Senha: pedro123
49
Figura 31 - Tela Cadastro Usuário Bárbara
Usuário 2
Nome: Barbara Castro Vieira
Data de Nascimento: 07/11/1986
Endereço: Avenida Gilberto Filgueiras 1234
Cidade: Avaré
Estado: São Paulo
Telefone: (11) 9 2345-6789
Email: [email protected]
Senha: barbara123
Cada um dos usuários inseriu essas informações diretamente no aparelho para
realizar a criação de um novo acesso na plataforma. Todas essas informações foram
armazenadas na base de dados e também na parte de autenticação da plataforma Firebase,
que automaticamente gera um ID único do usuário e não deixa a senha disponível nem
para o administrador do ambiente. Nas figuras 32 e 33, é possível observar a tela de
controle dos usuários cadastrados no sistema.
50
Figura 32 - Tela de gestão dos Usuários
Figura 33 - Estrutura Banco de Dados Usuários
Como é possível observar nas figuras 32 e 33, cada usuário possui um ID único
gerado pelo próprio Firebase, que é utilizado pelo aplicativo para a geração de nós e
organização de todas as informações visão usuário no database.
Dessa maneira, os usuários possuem cadastro e conseguem realizar o login no
aplicativo. Os usuários, portanto, utilizam e-mail e senha cadastrada para acessar o
sistema e conseguir realizar ações.
51
Figura 34 - Tela Produtos Usuários Teste
Após o login, o usuário acessa a tela da figura 34, e dessa maneira é possível realizar
as ações de incluir os produtos em sua carteira virtual. Para essa situação, consideramos
diferentes compras para os dois usuários de teste, e cada usuário realizou as ações
separadamente.
Usuário 1:
1 Stella Artois
2 Água com Gás
1 Amstel
Usuário 2
2 Smirnoff
1 Refrigerante
1 Heineken
52
Após a compra, todas as fichas foram armazenadas nos respectivos nós no banco
de dados, para que fossem recuperadas sempre que o usuário acessar a aba de fichas
disponíveis em seu dispositivo.
Na figura 35, podemos ver a estrutura do banco de dados das fichas disponíveis de
cada usuário, e também a aba de disponíveis no celular de cada usuário.
Figura 35 - Estrutura Banco de Dados Produtos Teste
Percebe-se na figura 35, que temos o nó “mãe”, logo abaixo do nó
“user_fichas_disponiveis”, que é comum para os dois usuários,
“user_fichas_disponíveis”, e cada usuário possui seu próprio nó que armazena as
respectivas fichas. Cada venda possui um ID único que é utilizada por todo o sistema para
buscar e recuperar as informações, tanto na retirada como em consultas feitas pelo
usuário.
Portanto, para mostrar ao usuário todas as fichas disponíveis, o sistema realiza uma
busca em todo o nó do usuário que está “logado”, interpreta as informações e aloca na
tela de fichas. Esse caminho das fichas é denominado de “Minhas Fichas” no menu do
aplicativo, que traz uma personalização com o nome do usuário logado.
53
Figura 36 - Telas de Navegação Usuários
Assim, ao clicar no ícone de Minhas Compras, automaticamente o usuário é
direcionado para a tela que mostra todas as fichas disponíveis na conta do usuário. Nesse
momento, o aplicativo vai até o banco de dados que está na nuvem, e recupera todos os
dados de fichas disponíveis do usuário que está logado. Todo esse processamento é
realizado diretamente na plataforma Firebase e, é possível acessar de qualquer lugar, e a
qualquer hora.
Na figura 37, temos as telas que foram formadas pelos dados recuperados pelo
aplicativo, para os dois usuários da figura 36.
Figura 37 - Telas de Produtos Disponíveis Usuários Testes
54
Assim, a partir das telas apresentadas, o usuário é capaz de realizar a retirada do
produto a partir de um QR code. Ao clicar no botão para retirada, automaticamente um
QrCode é gerado e assim o usuário pode dirigir-se ao balcão e retirar o produto. Abaixo,
na imagem 38, temos um exemplo para o produto “Amstel” do usuário 1.
Figura 38 - QR Code gerado para retirada do produto
Ao se dirigir ao balcão de retirada, o colaborador do estabelecimento possui o
mesmo aplicativo, porém, ao realizar o login com um usuário administrador, é
direcionado para outra tela que possui um ícone para realizar a leitura do QR Code. A tela
é bem simples e ao clicar no botão para validar o código do usuário o aplicativo acessa a
câmera do dispositivo para realizar a leitura, como podemos observar na figura 39 abaixo:
55
Figura 39 - Tela do administrador para validar um QR Code
Figura 40 - Leitor de QR ativado para uma leitura
Com a leitura, o aplicativo busca na base de dados o produto em questão, e, mostra
automaticamente todas essas informações para o responsável em realizar a entrega do
produto. Na figura 41, podemos conferir essa tela para o QRCode apresentado na figura
49.
56
Figura 41 - Tela de conferência dos dados do produto
No momento da entrega do produto, o usuário administrador tem que avisar o
sistema da retirada do produto e aciona o botão "Retirar". Ao clicar nesse botão, o sistema
realiza basicamente três ações da base de dados:
• Coloca no Status do nó Venda como: Retirado
• Retira do nó de produtos disponíveis do usuário
• Insere na base histórica do usuário
Após essas movimentações que ocorrem em tempo real, o usuário pode conferir
que o produto que estava disponível em sua carteira digital foi retirado, e está agora na
parte de histórico conforme a figura 42.
57
Figura 42 - Tela dos itens já retirados - Histórico
Dessa maneira, o sistema fecha um ciclo da compra, armazenamento na carteira
digital e retirada, conforme estrutura e lógica esperada.
Como esse projeto não contempla toda a jornada de compra de fichas, pois não foi
considerada a venda com a validação de todos os dados de cartão de crédito e também o
código de segurança, a automação pode receber qualquer interface de venda virtual.
A automação é capaz de adquirir todos os dados do usuário, realizando as ações de
leitura e recuperação dos dados, bem como a geração e leitura de QRCode para a retirada
dos produtos.
58
5. CONCLUSÃO
Objetivo desse trabalho é demonstrar e aplicar toda a estrutura de uma automação
comercial de vendas de fichas de consumo para bares e restaurantes. Tratou-se aqui, desde
a evolução dos aparelhos celulares, até o desenho da base de dados, design e programação
de botões e funcionalidades.
Desta forma, construiu-se o protótipo de um aplicativo para Android (mas que,
frisa-se, com as devidas modificações estruturais pode ser perfeitamente adequado a outro
sistema, como, por exemplo, o iOS) que possui uma base para o desenvolvimento de um
produto totalmente comercial que tem como finalidade dar praticidade à experiência do
consumidor dentro de um estabelecimento comercial. Isso porque, facilita tanto o modo
como o consumidor faz seus pedidos, como o pagamento de sua conta ao final de sua
estada no bar/restaurante.
Assim sendo, foi possível demonstrar toda a visão comercial de uma automação,
utilizando conhecimentos e pesquisas do setor de bares e restaurantes, somado com todas
as funcionalidades e opções que a plataforma Android possibilita.
Frisa-se, por fim, que como o projeto se finalizou sem a implementação de fato de
uma venda em si, ou seja, sem o cadastro de qualquer cartão de crédito e nenhuma
plataforma de cobrança, somente foi possível realizar teste em ambientes controlados e
com produtos não reais. Todavia, em fases futuras do projeto, basta acoplar qualquer
estrutura de cobrança com cartão de crédito e débito que o aplicativo pode ser colocado
em produção.
59
REFERÊNCIAS
MAIA, Mariana Paes da Fonseca. A informação tecnológica como fator de
sobrevivência e vantagem competitiva. Disponível em
<http://www.machadosobrinho.com.br/revista_online/publicacao/artigos/Artigo01R
EMS7.pdf>. Acesso em 16 de abril de 2018.
DOZE TI. E-social e processos repetitivos podem ser feitas rapidamente por
automação A informação tecnológica como fator de sobrevivência e vantagem
competitiva. Disponível em <http://doze-ti.com.br/artigos/esocial-e-processos-
repetitivos-podem-ser-feitas-rapidamente-por-automacao >. Acesso em 16 de abril de
2018.
INGRAMMICRO. A nova era da automação comercial, 2017. Disponível em
<http://www.ingrammicro.com.br/portal/a-nova-era-da-automacao-comercial/>.
Acesso em 16 de abril de 2018.
ALVES PINTO, Marcelo Caballero, 2014.Código de barras. Um estudo de
múltiplos casos. Disponível em <
http://lyceumonline.usf.edu.br/salavirtual/documentos/2623.pdf >. Acesso em 16 de
abril de 2018.
GRIFFITHS, Dawn; GRIFFITHS, David. Use a Cabeça! Desenvolvendo para
Android.
FINCOTTO, Marcos Apolinário; SANTOS, Marilde Terezinha Prado, 2014.
Automação Comercial utilizando Aplicativo Móveis – Um Foco na Plataforma
Android. Disponível em
<http://www.revistatis.dc.ufscar.br/index.php/revista/article/viewFile/85/79>.
Acesso em 18 de abril de 2018.
60
DA COSTA, Reinaldo Candido; DOS SANTOS, Rosaria Ferreira Otoni.
Conhecendo o Software Livre. Disponível em
<http://www.periodicos.letras.ufmg.br/index.php/ueadsl/article/viewFile/2504/2456
>. Acesso em 18 de abril de 2018.
ANDROID DEVELOPERS. Arquitetura da Plataforma. Disponível em <
https://developer.android.com/guide/platform/index.html?hl=pt-br#api-framework>.
Acesso em 25 de janeiro de 2018.
BORGES, Hélder Pereira; DE SOUZA, José Neuman; SCHULZE, Bruno; MURY,
Antonio Roberto. Computação em Nuvem. Disponível em <
http://livroaberto.ibict.br/bitstream/1/861/1/COMPUTA%C3%87%C3%83O%20E
M%20NUVEM.pdf>. Acesso em 23 de Março de 2018.
FIREBASE GOOGLE. Firebase Realtime Database. Disponível em <
https://firebase.google.com/docs/database/?hl=pt-br#top_of_page>. Acesso em 23 de
Março de 2018.
DEVELOPER ANDROID. Conheça o Android Studio. Disponível em <
https://developer.android.com/studio/intro/index.html?hl=pt-br>. Acesso em 01 de
Fevereiro de 2018.
61
ANEXOS
Conforme já foi abordado anteriormente nesse trabalho, o Firebase foi a plataforma
escolhida para implementar algumas das principais funcionalidades do aplicativo. Para
realizar a utilização desse serviço, foi necessário utilizar uma conta Google para acessar
a plataforma e realizar a criação de um novo projeto. Na figura abaixo, temos a tela inicial
após o login.
Dessa maneira, conseguimos iniciar a criação de um novo projeto, para depois
sincronizar com nosso aplicativo no Android Studio. Ao clicar em “Adicionar Projeto”,
começamos a configuração de um novo arquivo, e podemos nomear como desejamos.
62
Após esse passo, já concluímos a criação do projeto no Firebase, de maneira fácil e
rápida. Nosso próximo passo foi realizar o sincronismo com o nosso projeto do Android
Studio. Para isso, na tela inicial da plataforma, selecionamos a opção de “Adicionar o
Firebase ao seu projeto” com o objetivo de conectar o nosso projeto no Android Studio.
Para realizar essa conexão, precisamos preencher o campo package com o nome do
pacote de nosso projeto. Esse nome deve ser exatamente o mesmo, para que ocorra o
sincronismo. Essa informação pode ser capturada nas classes de nosso projeto, conforme
observamos na figura a seguir:
63
Assim, preenchemos o primeiro campo, com o nosso de nosso package e
avançamos essa etapa. Com todas as informações que incluímos até agora, a plataforma
gera um arquivo json, via download.
64
Esse arquivo gerado é um pacote de informações, que deve ser colocado dentro do
diretório app de nosso projeto do Android Studio, conforme imagem abaixo:
Figura 29 - Diretório Android Studio
Após a inserção desse pacote de informações que geramos na plataforma do
Firebase em nosso aplicativo, foi necessário realizar algumas alterações nos arquivos
build.gradle no projeto e no módulo. Inicialmente, realizamos a inserção do código
“classpath ‘com.google.gms:google-services:3.0.0’ no nível de projeto.
65
Para finalizar devemos clicar em “Sync now” para que todas as sincronizações e
configuração sejam por fim realizadas.
Agora, após todas as configurações do Firebase em nosso projeto, tivemos que
adicionar as bibliotecas das funcionalidades da plataforma Firebase que utilizamos. No
caso desse projeto, foram utilizadas as bibliotecas de autenticação e banco de dados.
• com.google.firebase:firebase-auth:10.2.1
• com.google.firebase:firebase-database:10.2.1
66
