TCC Desenvolvimento de Um Sistema Agregador de Barbearias

INSTITUTO FEDERAL DO ESPÍRITO SANTO
CURSO SUPERIOR DE SISTEMAS DE INFORMAÇÃO
EWERSON VIEIRA NASCIMENTO
DESENVOLVIMENTO DE UM SISTEMA AGREGADOR DE BARBEARIAS
Serra
2022
Trabalho de Conclusão de Curso apresentado à

Coordenadoria do Curso de Sistemas de Informação
do Instituto Federal do Espírito Santo, Campus Serra,
como requisito parcial para a obtenção do título de
Bacharel em Sistemas de Informação.
Orientador: Prof. Me. Daniel Ribeiro Trindade
Serra
2022
Dados Internacionais de Catalogação na Publicação (CIP)
N244d Nascimento, Ewerson Vieira

2022 Desenvolvimento de um sistema agregador de barbearias /
Ewerson Vieira Nascimento. - 2022.
100 f.; il.; 30 cm
Orientador: Prof. Me. Daniel Ribeiro Trindade.

Monografia (graduação) - Instituto Federal do Espírito Santo,
Coordenadoria de Informática, Curso de Bacharelado em Sistemas
de Informação, 2022.
1. Software de aplicação – Desenvolvimento. 2. Aplicações Web.

3. Barbearias. 4. Smartphones. I. Trindade, Daniel Ribeiro. II.
Instituto Federal do Espírito Santo. III. Título.
CDD 005.1
Bibliotecária Rogeria Gomes Belchior - CRB6/ES 417

Trabalho de Conclusão de Curso apresentado

como parte das atividades para obtenção do
título de Bacharel em Sistemas de Informação,
do curso de Bacharelado em Sistemas de
Informação do Instituto Federal do Espírito
Santo.
Aprovado em 11 de fevereiro de 2022.
COMISSÃO EXAMINADORA
_________________________________________________
Prof. Me. Daniel Ribeiro Trindade (Orientador)
Instituto Federal do Espírito Santo - Campus Serra
__________________________________________________
Profª Drª Cristina Klippel Dominicini
___________________________________________________
Prof. Me. Felipe Frechiani de Oliveira
MINISTÉRIO DA EDUCAÇÃO
INSTITUTO FEDERAL DO ESPÍRITO SANTO
SISTEMA INTEGRADO DE PATRIMÔNIO, ADMINISTRAÇÃO E
FOLHA DE ASSINATURAS
CONTRATOS
Emitido em 11/02/2022
FOLHA DE APROVAÇÃO-TCC Nº 1/2022 - SER - CCTMSI (11.02.32.01.08.02.09)
(Nº do Protocolo: NÃO PROTOCOLADO)
(Assinado digitalmente em 11/02/2022 14:43 ) (Assinado digitalmente em 11/02/2022 12:25 )

CRISTINA KLIPPEL DOMINICINI DANIEL RIBEIRO TRINDADE
PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO
SER-CGEN (11.02.32.01.08.02) SER - CCTMSI (11.02.32.01.08.02.09)
Matrícula: 2154146 Matrícula: 2277933
(Assinado digitalmente em 11/02/2022 13:59 )

FELIPE FRECHIANI DE OLIVEIRA
PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO
SER-CGEN (11.02.32.01.08.02)
Matrícula: 2275103
Para verificar a autenticidade deste documento entre em https://sipac.ifes.edu.br/documentos/ informando seu

número: 1, ano: 2022, tipo: FOLHA DE APROVAÇÃO-TCC, data de emissão: 11/02/2022 e o código de
verificação: 10ff4123fc
Aos meus pais
Ao meu irmão
À todos aqueles que me acompanharam nessa caminhada
AGRADECIMENTOS
Agradeço ao meu pai, Gilberto Nascimento Filho, por todo apoio, compreensão e motivação,
nos momentos bons e nos ruins, para que eu jamais desistisse.
Agradeço a meu orientador, Prof. Me. Daniel Ribeiro Trindade, por toda a paciência,
dedicação e ajuda prestada.
Por fim, agradeço a todos os colegas e professores que estiveram comigo durante essa
caminhada no curso, tornando minha jornada a melhor possível.
O insucesso é apenas uma oportunidade para recomeçar com mais inteligência.
(FORD, 2007)
RESUMO
O mercado de beleza masculina vem crescendo ano após ano em todo o mundo, com
relatórios apontando crescimento, no Brasil, de 70% entre 2012 e 2017. Dentre os diversos
setores que compõem este mercado, o setor de barbearias é um dos que recebem mais
investimentos, seja em infraestrutura, capacitação de pessoas e até mesmo tecnologia. Outra
área que cresceu muito nos últimos anos foi a popularização do uso de smartphones. Além
do surgimento de aplicativos para resolverem demandas específicas, surgiram também
aplicativos agregadores, condensando em um mesmo app diversas alternativas para o
usuário acerca de um mesmo tema, como o iFood no setor alimentício, o Flipboard
no setor de notícias e o Anchor para distribuição de podcasts. Com esses pontos em
mente surgiu o presente trabalho, onde foi desenvolvido um sistema para gerenciamento
de barbearias. Foram desenvolvidas duas interfaces: uma web, utilizando a biblioteca
React, e outra mobile, utilizando o React Native, para diferentes tipos de usuários. Além
disso, uma API foi desenvolvida utilizando Node.js para permitir a comunicação das
interfaces com os dados da aplicação. Dentre as diversas funcionalidades do sistema, as
principais são a possibilidade do usuário visualizar diversas barbearias e agendar sua
visita a um estabelecimento por meio de um aplicativo móvel, e facilitar o controle da
agenda dos barbeiros dessas barbearias. Para demonstrar os resultados produzidos, foram
disponibilizadas ao final deste trabalho imagens do sistema com descrições das telas e das
funcionalidades produzidas, utilizando dados fictícios.
Palavras-chave: Barbearia. React. Node.js.

ABSTRACT
The male beauty market has been growing year after year around the world, with reports
pointing to a growth of 70% in Brazil between 2012 and 2017. Among the various
sectors that make up this market, the barbershop sector is one of those that receive more
investments, whether in infrastructure, people trainment and even technology. Another
area that has grown a lot in recent years has been the popularization of the use of
smartphones. In addition to the emergence of applications to solve specific demands,
aggregating applications have also emerged, condensing in the same app several alternatives
for the user on the same topic, such as iFood in the food sector, Flipboard in the news
sector and Anchor for podcasts distribution. With these points in mind, the present work
emerged, with the development of a system for managing barbershops. Two interfaces were
developed: a web interface, using the React library, and a mobile interface, with React
Native, for different types of users. In addition, an API was developed using Node.js to
allow interfaces to communicate with application data. Among the various functionalities
of the system, the main ones are the possibility for the users to view several barbershops
and schedule their visit to an establishment through a mobile application, and facilitate the
control of the barbers’ agenda in these barbershops. To demonstrate the results achieved,
at the end of this paper images of the system with descriptions of the screens and the
produced functionalities were made available, using fictitious data.
Keywords: Barbershop. React. Node.js.

LISTA DE FIGURAS
Figura 1 – Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figura 2 – Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 3 – Padrão MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 4 – Requisição HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figura 5 – React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 6 – Arquitetura REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figura 7 – Tradução de componentes do React Native . . . . . . . . . . . . . . . 25
Figura 8 – Tela inicial do iFood (iOS) . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 9 – Diagrama geral da aplicação . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 10 – Diagrama de caso de uso (mobile) . . . . . . . . . . . . . . . . . . . . 33
Figura 11 – Diagrama de caso de uso (web) . . . . . . . . . . . . . . . . . . . . . . 34
Figura 12 – Diagrama de caso de uso (web) . . . . . . . . . . . . . . . . . . . . . . 35
Figura 13 – Diagrama de classes do backend . . . . . . . . . . . . . . . . . . . . . 36
Figura 14 – Diagrama entidade relacionamento . . . . . . . . . . . . . . . . . . . . 40
Figura 15 – Tela de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 16 – Tela de cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figura 17 – Tela de detalhes da barbearia (vazio) . . . . . . . . . . . . . . . . . . 47
Figura 18 – Modal para criação de barbearia . . . . . . . . . . . . . . . . . . . . . 48
Figura 19 – Modal para criação de barbeiros . . . . . . . . . . . . . . . . . . . . . 49
Figura 20 – Modal para criação de serviços . . . . . . . . . . . . . . . . . . . . . . 49
Figura 21 – Modal para criação de horário de funcionamento . . . . . . . . . . . . 50
Figura 22 – Tela de detalhes da barbearia . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 23 – Tela de detalhes da barbearia (responsivo) . . . . . . . . . . . . . . . 51
Figura 24 – Tela de perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 25 – Tela de detalhes da agenda . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 26 – Tela de detalhes da agenda (responsivo) . . . . . . . . . . . . . . . . . 54
Figura 27 – Tela de perfil (responsivo) . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 28 – Tela de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 29 – Tela de cadastro de usuário . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 30 – Tela de listagem de barbearias . . . . . . . . . . . . . . . . . . . . . . 58
Figura 31 – Tela de busca por barbearias . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 32 – Tela de realização de agendamento . . . . . . . . . . . . . . . . . . . . 60
Figura 33 – Tela de confirmação do agendamento . . . . . . . . . . . . . . . . . . . 61
Figura 34 – Tela de listagem de agendamentos passados . . . . . . . . . . . . . . . 62
Figura 35 – Tela de listagem dos próximos agendamentos (vazio) . . . . . . . . . . 63
Figura 36 – Tela de listagem dos próximos agendamentos . . . . . . . . . . . . . . 64
Figura 37 – Tela de cancelamento de agendamento . . . . . . . . . . . . . . . . . . 65
Figura 38 – Tela de avaliação do atendimento . . . . . . . . . . . . . . . . . . . . . 66
Figura 39 – Tela de perfil do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . 67
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 DEFINIÇÃO DO PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . 15
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . 16
2.1 ENGENHARIA DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.4 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.5 Model-View-Controller ou MVC . . . . . . . . . . . . . . . . . . . . . 19
2.2 DESENVOLVIMENTO WEB . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1 Protocolo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4 Arquitetura REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 DESENVOLVIMENTO MOBILE . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 TRABALHOS CORRELATOS . . . . . . . . . . . . . . . . . . . . . . . . 26
3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 DESCRIÇÃO GERAL DO SISTEMA . . . . . . . . . . . . . . . . . . . . 29
3.2 REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3 Modelagem do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3.1 Diagrama geral da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.3.2 Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.3.3 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 PROCESSO DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . 36
3.3.1 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2.1 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.2.2 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2.3 Aplicação mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2.4 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.3 API REST de comunicação frontend - backend . . . . . . . . . . . 44
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1 APRESENTAÇÃO DOS RESULTADOS . . . . . . . . . . . . . . . . . . . 45
4.1.1 Web - Roteiro de uso de donos de barbearias . . . . . . . . . . . . 45
4.1.2 Web - Roteiro de uso de barbeiros . . . . . . . . . . . . . . . . . . . 52
4.1.3 Mobile - Roteiro de uso de clientes de barbearias . . . . . . . . . . 55
4.2 DISCUSSÃO SOBRE OS RESULTADOS . . . . . . . . . . . . . . . . . . 67
5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . 69
5.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
APÊNDICE A – DOCUMENTAÇÃO DA API . . . . . . . . . . 74
13
1 INTRODUÇÃO
A profissão de barbeiro é uma das mais antigas de que se tem registro. Estudos indicam
que a prática de barbear pode ter surgido cerca de 6000 anos atrás em serviços oferecidos
para a nobreza Egípcia, onde utilizavam pedras afiadas ou conchas de ostras (SCALI-
SHEAHAN, 2010). Na Grécia de 500 a.C. barbeiros cuidavam não somente da barba,
como de machucados e cicatrizes nos rostos dos homens. Em 290 a.C. a profissão já era
muito popular em Roma, onde as barbearias eram lugares onde os homens podiam não
apenas barbear, mas discutir sobre política e notícias do dia. Com o surgimento da navalha
em 1740 e seu aperfeiçoamento em 1840 por William Henson, que criou o sistema de
barbear em forma de “T”, aliado ao surgimento de cursos profissionalizantes, que tornaram
obrigatórias licenças ou certificações para exercer a profissão de barbeiro, o número de
barbearias nos Estados Unidos sofreu um aumento muito rápido e o sucesso se espalhou
por todos os nichos da sociedade (BARBEIROS, 2018d). Este sucesso se tornou o modelo
de empreendimento das barbearias que conhecemos atualmente.
No entanto, as formas com que consumimos alguns produtos e serviços sofreram mudanças
depois da popularização dos smartphones. Aplicativos móveis tornaram-se uma opção
muito fácil e rápida para consumirmos produtos de setores como alimentação, transporte,
acomodação e notícias. Os maiores destaques são os aplicativos agregadores, como iFood1 e
Uber Eats2 para alimentação, Flipboard3 para notícias, Booking4 para acomodações, entre
outros. Estes aplicativos atuam como facilitadores, tanto para quem consome, como para
quem oferece produtos e serviços por meio deles, já que incluem várias fontes diferentes
em seus catálogos, oferecendo diversas opções para seus usuários.
No final de 2019 surgiu um novo fator que modificou não apenas a dinâmica como
consumimos produtos e serviços, mas como nos relacionamos como sociedade: a COVID-
19. É uma doença causada pelo novo coronavírus SARS-CoV-2 que possui alta taxa de
transmissão e distribuição global (Governo Federal, 2021). A velocidade com que o vírus se
espalhou pelo mundo fez com que a OMS declarasse que vivemos numa pandemia do novo
coronavírus e, com isso, diversos países adotaram medidas de isolamento social a fim de
preservar a saúde de seus cidadãos. Essas medidas envolvem o uso de máscaras, controle
do número de indivíduos presentes em estabelecimentos, maior rigor na higienização dos
ambientes e até mesmo o lockdown, que é uma imposição do Estado para bloqueio total
de atividades a fim de desacelerar a propagação do vírus. Com isso, o período de espera
comumente presente em comércios e lojas de prestadores de serviços se tornou algo a ser
evitado.
1
https://www.ifood.com.br/
2
https://www.ubereats.com/br
3
https://pt-br.about.flipboard.com/
4
https://www.booking.com/index.pt-br.html
14
Com estes pontos em mente, surgiu a ideia de criar um aplicativo móvel que agregasse
diversas barbearias e facilitasse o consumo e a prestação dos serviços das mesmas através
do gerenciamento dos horários de atendimento destas barbearias, contribuindo com as
novas necessidades de isolamento social advindas do momento de pandemia que vivemos.
1.1 DEFINIÇÃO DO PROBLEMA
Para o desenvolvimento de uma aplicação para gerencimento de horários em uma barbearia,

se faz necessário a realização de diversas etapas. Primeiramente, é necessário entender
a estrutura de uma barbearia e seus principais elementos para o atendimento ao cliente.
Em seguida, é preciso mapear essa lógica de negócio do mundo real para um software,
aplicando as regras particulares deste tipo de empreendimento. Por fim, há a construção
das interfaces com que os usuários interagirão. A partir deste momento, com a interação
entre essas diferentes partes, a aplicação pode oferecer diversas informações relevantes para
seus três tipos de usuários: os donos do estabelecimento, os profissionais que realizam os
serviços mapeados nas estapas anteriores, e os clientes destes estabelecimentos. Os donos
de barbearias podem ter ciência da eficiência de seus estabelecimentos e da satisfação dos
clientes com os serviços prestados, além de conquistarem novos clientes. Para os demais
usuários, tem-se um melhor aproveitamento do tempo, já que reduz-se, ou até mesmo
elimina-se, o tempo de espera para o atendimento.
Posto isso, este trabalho visa desenvolver um sistema para gerenciamento de horários em
barbearias a fim de possibilitar que as vantagens citadas possam ser usufruidas por um
público maior.
1.2 OBJETIVOS
1.2.1 Objetivo geral
O objetivo deste trabalho é produzir um software agregador de barbearias para geren-

ciamento de horários nestes estabelecimentos, sendo o principal produto um aplicativo
móvel para Android e iOS, além de uma interface web. A abordagem foi feita a partir dos
processos iniciais de esboço das interfaces aos processos de desenvolvimento de software
e integração entre as diferentes aplicações desenvolvidas. Além disso, foi pensado o
desenvolvimento de interfaces e funções para os diferentes tipos de usuários da aplicação:
consumidor, dono do estabelecimento e funcionário, contribuindo, dessa forma, no grau
de satisfação dos clientes, na gestão dos serviços das barbearias e na organização das
informações relativas ao negócio.
15
1.2.2 Objetivos específicos
Os seguintes objetivos específicos foram identificados para que o objetivo geral fosse
atingido:
• Mapear barbearias e suas informações sobre os horários de funcionamento, serviços e

quais os seus barbeiros;
• Possibilitar que consumidores realizem agendamentos de horários nas barbearias;
• Permitir que os consumidores avaliem as barbearias após utilizarem seus serviços;
• Permitir que barbeiros dos estabelecimentos cadastrados gerenciem suas agendas;
• Permitir que os donos de estabelecimentos cadastrem e gerenciem suas barbearias.
1.3 ESTRUTURA DO TRABALHO
O trabalho está dividido da seguinte forma: neste capítulo foi apresentada uma introdução
sobre o assunto, a contextualização do tema, a motivação do trabalho, a definição do
problema e os objetivos pretendidos. No capítulo 2 é apresentado o referencial teórico
do trabalho, onde é explicado o funcionamento de uma barbearia bem como algumas
de suas características, além de abordar alguns softwares existentes nesta área que se
correlacionam com o deste trabalho. No capítulo 3 é demonstrada a metodologia utilizada
no desenvolvimento deste sistema de gerenciamento de barbearias. No capítulo 4 são
apresentados os resultados obtidos e são discutidas decisões de design e desenvolvimento
do código da solução proposta. Por fim, o capítulo 5 contém a conclusão e são discutidos
possíveis melhorias e trabalhos futuros que podem ser desenvolvidos a partir desse trabalho.
16
2 REFERENCIAL TEÓRICO
Para a realização deste trabalho, faz-se necessário o entendimento de três áreas do

conhecimento: Engenharia de Software, Desenvolvimento Web e Desenvolvimento Mobile.
A primeira área tem o objetivo de apoiar o desenvolvimento de todo o sistema. A segunda
área elucida como as aplicações se comunicam e compartilham dados, além de mostrar o
que é necessário para criação e manutenção da parte web do sistema. Já a terceira área
clarifica os meios para desenvolver aplicações móveis.
2.1 ENGENHARIA DE SOFTWARE
A engenharia de software é uma disciplina da informática que se ocupa de todos os aspectos

da produção de software, desde as primeiras etapas de especificação do sistema, até a
manutenção desse sistema e depois que o mesmo já se encontra em uso (SOMMERVILLE,
2011). Neste trabalho serão utilizados diversos conceitos presentes na área da engenharia
de software, como o modelo arquitetural Model-View-Controller, ou MVC, e algumas
ferramentas como os diagramas de caso de uso e os diagramas de classes.
2.1.1 Diagrama de casos de uso
Este tipo de diagrama descreve uma possível utilização do sistema do ponto de vista
do usuário. Para tanto, ele descreve as principais funcionalidades e interações dessas
funcionalidades com os usuários (JACOBSON, 1992). A fim de representar os pontos
mencionados, os diagramas de casos de uso são compostos de 4 principais elementos: o
cenário, que representa a sequência de eventos decorrentes da interação do usuário com o
sistema; os atores, que são os diferentes possíveis usuários do sistema no caso de uso em
questão; o caso de uso propriamente dito, que é justamente a tarefa ou funcionalidade a
ser realizada pelo usuário; e a comunicação, sendo o que liga os atores com os casos de
uso. Um exemplo de caso de uso pode ser observado na imagem a seguir.
17
Figura 1 – Diagrama de caso de uso
Fonte: Wikipedia
No diagrama presente na Figura 11 é observado que no sistema do restaurante em questão

a ação que o ator Chef realiza é a de cozinhar, Cook Food, enquanto o ator Food Critic
pode realizar as ações de comer, Eat Food, pagar pela comida consumida, Pay for Food, e
consumir vinho, Drink Wine.
2.1.2 Diagrama de classes
O diagrama de classes é útil para ilustrar e documentar a estrutura e as relações das classes
que servem de modelo para os objetos (FALBO, 2017). Este tipo de diagrama mapeia
os atributos, operações e relações entre os objetos do sistema, descrevendo exatamente
aquilo que deve estar presente no sistema a ser modelado. Nestes diagramas, as classes e
interfaces são representadas por retângulos com 3 divisões horizontais: a primeira para
informar o nome da classe; a segunda para os atributos da classe; e a terceira informa os
métodos que a classe possui. Além da definição dos elementos, outro ponto de grande
relevância no diagrama são as interações entre os componentes, marcadas pelas ligações
feitas por diversos tipos de linhas, podendo representar associação, generalização ou
herança, composição ou agregação. O comportamento deste tipo de diagrama pode ser
observado na Figura 2.
1
https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso
18
Figura 2 – Diagrama de classes
Fonte: Wikipedia
Na Figura 22 observamos como um diagrama de classes é formado, com os retângulos

representando as classes e, dentro desses retângulos, as divisões horizontais separando o
nome da classe de seus atributos e métodos. Há também o relacionamento entre as classes,
representado pela ligação entre elas, com a “Classe Dependente” sendo composta pela
classe “Nome da Classe” e tendo um método adicional.
2.1.3 Requisitos funcionais
Os requisitos funcionais representam todas as ações que o software deve realizar por meio
de suas funções ou serviços (FALBO, 2017). São descrições das interações entre o sistema e
o ambiente e de seus comportamentos através de entradas específicas. Os requisitos devem
ser descritos de forma objetiva e não ambígua. No sistema abordado neste trabalho, um
exemplo de requisito funcional seria “o sistema deve permitir a realização de agendamentos
de serviços nas barbearias”.
2.1.4 Requisitos não funcionais
Utilizados para definir restrições e limitações no desenvolvimento dos sistemas, os requisitos

não funcionais têm origem em restrições de orçamento, necessidades dos usuários finais ou
mesmo integração com outros sistemas, a fim de garantir a interoperabilidade entre eles
(FALBO, 2017). Um exemplo de requisito não funcional neste trabalho seria “o sistema
deve ser construído utilizando a linguagem de programação JavaScript”.
2
https://pt.wikipedia.org/wiki/Diagrama_de_classes
19
2.1.5 Model-View-Controller ou MVC
Este padrão arquitetural é composto por três camadas que estão presentes em seu nome:
Model, a camada responsável pela lógica da aplicação, que realiza as operações do sistema de
fato; View, a parte que o usuário interage, responsável por toda a exibição das informações
para o usuário; e Controller, responsável por gerenciar o fluxo de dados e ações entre as
requisições dos usuários e o que é repassado para a Model. O MVC é muito utilizado por
conta da sua separação de responsabilidades entre as diferentes partes do mesmo sistema
(GAMMA et al., 2006), isolando a lógica da regra de negócio da apresentação para o
usuário, possibilitando a existência de diversas interfaces, ou Views, que interagem com o
restante do sistema.
Figura 3 – Padrão MVC
Fonte: Medium - Leonardo Vilarinho
A Figura 33 mostra o funcionamento desse tipo de arquitetura, onde o usuário realiza as

requisições ao Controller que, por sua vez, utiliza ou não dados da Model para criar a
visualização, View, de resposta ao usuário.
2.2 DESENVOLVIMENTO WEB
Ao desenvolvimento web é conferida a responsabilidade de elaborar e codificar páginas

e soluções para a internet. Esse trabalho se dá tanto pela parte que toca o usuário, o
frontend, quanto pelo que está por trás do que o usuário enxerga, o backend. Apesar dessa
divisão de responsabilidades entre as partes do desenvolvimento, a comunicação entre elas
se dá a partir da utilização de um mesmo protocolo: o Hypertext Transfer Protocol.
2.2.1 Protocolo HTTP
Como base para toda troca de dados realizada na internet temos o Hypertext Transfer
Protocol, ou HTTP. É um protocolo que estabelece uma relação cliente-servidor entre as
3
https://medium.com/trainingcenter/bf95a744c66d
20
partes, onde o cliente inicia as requisições a fim de obter recursos de um servidor (Mozilla
Developer Network, 2021). Esses recursos podem ser imagens, vídeos, textos ou mesmo
páginas web inteiras.
Nos primórdios da internet, era comum que nessas requisições o cliente recebesse como
resposta uma página web inteira. Essas páginas possuíam conteúdos estáticos, ou seja, não
sofriam alterações após sua renderização em tela. Com o avanço da internet, esse tipo de
abordagem foi se tornando cada vez menos frequente, já que se deseja mais interatividade
entre os usuários e os sites. Dessa forma, o surgimento de páginas web dinâmicas foi um
caminho natural, onde certas partes do conteúdo se modificam de acordo com a interação
do usuário, seja para exibir uma lista de resultados em uma pesquisa, renderizar um mapa
de acordo com o endereço informado, etc.
O HTTP evoluiu com o tempo e hoje possui diversos métodos de requisição, dentre eles os
mais utilizados neste trabalho são:
• GET, para solicitar algum dado específico.
• POST, para enviar dados ao servidor. (geralmente criando novas entradas na base de
dados).
• PUT, utilizado para alterar ou substituir uma instância de um recurso.
• DELETE, utilizado para remover um recurso específico da base de dados.

21
Figura 4 – Requisição HTTP
Fonte: Elaborado pelo autor (2021)
A Figura 4, obtida utilizando o software Insomnia4 , mostra o exemplo de uma requisição

HTTP contida neste trabalho. A fim de realizar o login na aplicação o frontend faz
uma requisição do tipo POST para a rota http://localhost:3333/sessions, enviando as
informações de email e senha no formato JSON. O backend por sua vez processa a
4
https://insomnia.rest/
22
requisição e, em caso de sucesso, retorna as informações do usuário logado e seu token de

sessão.
É com base nesses métodos de requisição que a interface do usuário (frontend) interage
com o servidor (backend) da aplicação.
Assim como o protocolo HTTP, o frontend e o backend evoluíram ao longo do tempo.
2.2.2 Frontend
O frontend é a parte da aplicação responsável pelos componentes com que o usuário

interage para utilizar o software em questão, ou seja, é o intermediário entre o usuário e
o backend (Frontend Masters, 2021). Nesse quesito, o frontend pode ser uma interface
web, mobile, ou até mesmo desktop. Como os navegadores de internet compreendem
apenas a linguagem JavaScript, a interface web deste trabalho também foi construída
nessa linguagem, fazendo uso da biblioteca React5 .
Existem diversas bibliotecas e frameworks JavaScript no mercado a fim de apoiar o

desenvolvimento das aplicações, sendo que os mais notáveis são: Angular6 , React e Vue7 .
O Angular foi criado pelo Google e adota o TypeScript8 (uma versão tipada do JavaScript)
em seu desenvolvimento, sendo conhecido pela sua curva de aprendizagem maior já que
sua estrutura impõe uma organização de código que limita a liberdade do desenvolvedor.
O React é mais leve que muitos de seus concorrentes e é famoso por sua modularização, já
que os componentes são, via de regra, construídos em forma de função, o que facilita a
implementação de novas funcionalidades. Já o Vue é o mais amigável dos três, com uma
documentação bem detalhada, sendo ele mais conhecido por sua velocidade de execução e
pela padronização de código, onde num mesmo arquivo o desenvolvedor deposita todo o
código do template, o JavaScript e o CSS daquela página ou componente.
A escolha do React neste trabalho se deu, principalmente, por conta da reutilização de

conhecimentos e de código nos dois frontends, web e mobile, já que a ferramenta utilizada
para construir a aplicação mobile, o React Native, pode ser abordada como um subconjunto
do React como mostra a Figura 59 .
5
https://pt-br.reactjs.org/
6
https://angular.io/
7
https://vuejs.org/
8
https://www.typescriptlang.org/
9
https://reactnative.dev/docs/intro-react-native-components
23
Figura 5 – React Native
Fonte: Meta Platforms, Inc.
O React é uma biblioteca gratuita de código aberto construída pelo Facebook em 2011
para construção de interfaces de usuário ou componentes da interface de usuário. No
desenvolvimento web, o foco do React se dá na criação de single-page applications, ou
SPAs, conhecidos como “aplicativos de página única” no português. Os SPAs são páginas
dinâmicas que consomem o conteúdo de acordo com as ações do usuário sem recarregar a
página, fornecendo uma experiência de usuário semelhante à de uma aplicação desktop.
Hoje o React é utilizado por milhares de empresas em todo o mundo, como Uber, Airbnb,
Facebook, Netflix, Instagram, Twitter e muitas outras.
2.2.3 Backend
Responsável pelas regras de negócio da aplicação, o backend é uma parte do sistema

que possibilita uma maior flexibilidade na escolha da linguagem de programação a ser
utilizada no desenvolvimento do software. Isso se deve ao fato de esta parte do sistema ser
executada no servidor. Uma das linguagens que foram adicionadas ao rol de possibilidades
do backend nos últimos anos foi o JavaScript, com o Node.js10 .
Essa utilização do JavaScript no backend levou 14 anos desde a criação da linguagem, em

1995, e só foi possível após a evolução da linguagem e dos navegadores que competiam para
oferecer uma performance melhor para o usuário. Neste cenário o Google criou um motor
JavaScript chamado V8 para o seu navegador, o Google Chrome. Este motor também está
presente no Node, sendo ele o fator que possibilitou a utilização do JavaScript no servidor.
Além de frameworks JavaScript, existem diversos outros frameworks baseados em outras

10
https://nodejs.org/pt-br/
24
linguagens, como o Laravel11 para PHP, Spring12 para Java ou Django13 para Python.
Neste trabalho, com o intuito de simplificar a base de código reutilizando conhecimentos e
linguagens de programação, optou-se pela utilização de Node.js na construção do backend,
utilizando a arquitetura REST.
2.2.4 Arquitetura REST
REST, sigla para Representational State Transfer ou Transferência Representacional de

Estado em português, é um estilo de arquitetura que define como a troca de informações
será feita entre o frontend e o backend (Red Hat, Inc., 2021). Sendo multiplataforma e
exigindo a separação entre cliente e servidor, o REST apresenta a possibilidade de diversas
interfaces de usuário diferentes interagirem com o mesmo backend, já que elas só precisam
seguir as mesmas regras de comunicação estabelecidades pelo backend. A comunicação
deve ser feita utilizando requisições com dados no formato JSON14 . Na figura 4 pode-se
observar um exemplo de envio de JSON numa requisição, que nada mais é que um objeto
JavaScript.
Figura 6 – Arquitetura REST
Fonte: Voximplant
A Figura 615 mostra como a arquitetura REST funciona, onde o frontend faz uma requisição
HTTP para a API REST e ela, por sua vez, faz as validações e consultas necessárias para
retornar as informações solicitadas pelo frontend.
2.3 DESENVOLVIMENTO MOBILE
Com a popularização dos smartphones a partir de 2007, depois da criação do iPhone,

surgiu no mercado mais uma forma de estar próximo aos usuários: através de aplicações
11
https://laravel.com/
12
https://spring.io/
13
https://www.djangoproject.com/
14
https://www.json.org/json-pt.html
15
https://voximplant.com/blog/what-is-a-rest-api
25
móveis. Para desenvolver esse tipo de aplicação, por muito tempo a única maneira possível
era escrevendo código específico de cada plataforma, ou seja, o desenvolvedor precisaria
escrever cada aplicação em código nativo: utilizando Java ou Kotlin para Android, e
Swift ou Objective-C para o iOS. Com o avanço da tecnologia, surgiram ferramentas de
desenvolvimento multiplataforma, onde os desenvolvedores escrevem o código utilizando
uma única linguagem e a ferramenta realiza o trabalho de traduzir esse código para a
plataforma nativa do sistema.
Uma dessas ferramentas é o React Native16 , uma biblioteca criada pelo Facebook em 2015,
baseada no React, com foco no desenvolvimento de aplicações móveis multiplataforma
utilizando JavaScript. Em contraponto aos frameworks que fazem uso de WebViews,
ou seja, o aplicativo é basicamente um website exibido no smartphone, o diferencial do
React Native é a conversão do código JavaScript para a linguagem nativa do sistema
operacional do smartphone, o que torna a experiência mais próxima do que seria uma
aplicação totalmente nativa.
Figura 7 – Tradução de componentes do React Native
Fonte: Meta Platforms, Inc.
Na Figura 717 temos um exemplo de como funciona a conversão do código React Native
para as plataformas nativas, onde cada elemento é transformado no seu equivalente em
código nativo de cada plataforma, como exemplo: o elemento Image do React Native é
16
https://reactnative.dev/
17
https://reactnative.dev/docs/intro-react-native-components
26
transformado em ImageView nos dispositivos Android e UIImageView em dispositivos que

utilizam o iOS.
A opção por construir aplicações utilizando ferramentas multiplataforma tem crescido

a medida que essas ferramentas evoluem e entregam uma performance melhor. Porém,
diversas empresas ainda mantêm o desenvolvimento de suas aplicações em código nativo
para Android e iOS. Isso se deve porque hoje as aplicações nativas ainda possuem uma
performance melhor, possuem suporte às mais novas funcionalidades de seus sistemas
operacionais e geralmente entregam uma experiência de usuário melhor.
Neste trabalho a biblioteca React Native foi escolhida pois possibilita o reuso de código
entre as interfaces de usuário web e mobile, utiliza JavaScript como o restante do sistema,
fazendo com que o mesmo conhecimento seja reaproveitado no desenvolvimento dos diversos
componentes da aplicação, o que facilita a manutenção e reduz o time to market, ou tempo
de colocação no mercado, que é o tempo para que o produto seja desenvolvido até estar
disponível para os usuários finais. Além disso, facilita para que mais pessoas possam
continuar o desenvolvimento do projeto no futuro, já que demanda menos recursos por
ser uma base mais enxuta de conhecimento, ferramentas, linguagens de programação e
hardware para o desenvolvimento de aplicações móveis.
2.4 TRABALHOS CORRELATOS
Alguns trabalhos acadêmicos possuem, como resultado final, um software que também
soluciona um dos principais problemas que o presente trabalho se propõe a resolver: realizar
o gerenciamento de uma barbearia.
Uma dessas soluções é o software Two Style (MARTINS, 2019), que foca seus esforços
numa solução desktop para um único estabelecimento, não permitindo que o cliente escolha
entre diferentes estabelecimentos. Este software permite o cadastro, a listagem, atualização
e remoçao de clientes, serviços, agendamentos e funcionários.
Outra solução é o Sistema Beleza Vip (ÁVILA, 2013), que, além de ter as mesmas
funcionalidades presentes no software Two Style, oferece a possibilidade de gerar relatórios,
informando para o dono do estabelecimento a quantidade de serviços prestados em
determinada data ou período, bem como o número de clientes atendidos e o valor recebido
por esses serviços. Esta é uma funcionalidade que não está presente no software produzido
no presente trabalho. O sistema desenvolvido e aqui exposto atua como um gerenciador
de barbearias, porém é mais do que isso: é um agregador de serviços.
Existem diversos aplicativos cujo objetivo é funcionar como um agregador de serviços:

27
Uber Eats, na área de entrega de alimentos, Skyscanner18 , para a pesquisa de passagens e

pacotes turísticos, além de vários outros em diferentes ramos. No Brasil uma aplicação
que se destacou muito nos últimos anos foi o iFood, cuja função é permitir que usuários
possam pedir comida em diferentes restaurantes, além de permitir que os usuários avaliem
estes mesmos restaurantes (Figura 8).
Figura 8 – Tela inicial do iFood (iOS)
Este trabalho segue a linha do iFood e estende o conceito para os serviços de barbearias.
Esse modelo foi usado principalmente por conta do sucesso da plataforma iFood no país e a
18
https://www.skyscanner.com.br/
28
familiaridade que os usuários tem com a aplicação. Portanto, além de ser um gerenciador de
barbearias, este trabalho possui como diferencial a proposta de ser um software agregador
de barbearias, tendo, além de uma interface web como um dos resultados finais, um
aplicativo móvel para Android e iOS.
29
3 METODOLOGIA
Neste trabalho foi desenvolvido um sistema de gerenciamento de horários em barbearias,

cujo objetivo é mapear os serviços prestados pela barbearia aos seus clientes para reduzir
o tempo de espera do atendimento e obter um controle melhor de suas atividades. Foi
desenvolvido um sistema web para utilização por parte dos donos do estabelecimento, a
fim de prover aos mesmos informações gerenciais e configurações a respeito da barbearia, e
para os barbeiros, para que possam fazer o controle de seus horários. Para os clientes das
barbearias, foi desenvolvido um sistema mobile, disponível para as plataformas Android e
iOS, para que esses usuários possam encontrar barbearias e realizar seus agendamentos.
Como base para o desenvolvimento das interfaces foi utilizado como fonte de inspiração o
aplicativo iFood, por ter uma boa avaliação nas lojas de aplicativos e ser um sistema que
também gerencia as atividades de diversos estabelecimentos, porém de nichos diferentes.
O sistema foi desenvolvido com a linguagem de programação JavaScript, utilizando a

plataforma Node.js além das bibliotecas React e React Native para construção das interfaces
do usuário. As próximas seções mostram as metodologias utilizadas na construção das
diferentes partes do sistema proposto a fim de realizar o gerenciamento das barbearias.
3.1 DESCRIÇÃO GERAL DO SISTEMA
O sistema para gerenciamento das atividades de barbearias presente neste trabalho foi
dividido em duas interfaces distintas: uma interface web para utilização por parte dos
donos de barbearias e também pelos barbeiros que realizam os serviços ofertados pelos
estabelecimentos; e uma aplicação móvel a fim de atender os clientes dessas barbearias. Na
interface web o dono de uma barbearia pode cadastrá-la, informando os dados da mesma,
os dias e horários de funcionamento, os serviços que ela oferece e os barbeiros que atendem
no estabelecimento. Ao barbeiro é possível visualizar sua agenda com os atendimentos
realizados, cancelados e futuros, com a identificação do cliente e o horário marcado. Já
o cliente que acessa a aplicação móvel tem acesso à lista de barbearias cadastradas na
plataforma, a localização, avaliação, os serviços ofertados, os valores cobrados por cada
um dos serviços, os barbeiros disponíveis e datas e horários disponíveis para agendar a
ida até o estabelecimento. Este usuário pode agendar um serviço pelo aplicativo, cancelar
um agendamento, avaliar a prestação de serviço dos agendamentos que ele realizou, editar
suas informações de cadastro e pesquisar barbearias,
3.2 REQUISITOS
Para construir este projeto foi necessário definir algumas funcionalidades essenciais para a
consistência da aplicação. Essas definições estão apresentadas abaixo, começando pelos
30
requisitos funcionais, que ditam o que a aplicação deve fazer, enquanto os requisitos
não funcionais dão suporte aos requisitos funcionais informando como o sistema deve
realizar tais funções. Nas tabelas abaixo temos a apresentação desses requisitos com seus
identificadores e uma descrição sobre cada um deles.
3.2.1 Requisitos funcionais

Identificador Descrição
RF01 O sistema deve permitir que os usuários sejam autenti-
cados informando login e senha.
RF02 O sistema deve permitir o cadastro de diferentes tipos
de usuários: donos de barbearias, funcionários e clientes.
RF03 O sistema deve permitir que os usuários que sejam
donos de barbearias realizem o cadastro de seus
estabelecimentos.
RF04 O sistema deve permitir que donos de barbearias cadas-
trem os serviços que seus estabelecimentos oferecem.
RF05 O sistema deve permitir que donos de barbearias
cadastrem os barbeiros que trabalham em seus esta-
belecimentos.
RF06 O sistema deve permitir que usuários mobile visualizem
a lista das barbearias cadastradas.
RF07 O sistema deve permitir que usuários mobile pesquisem
barbearias.
RF08 O sistema deve permitir que os usuários mobile editem
seus cadastros.
RF09 O sistema deve permitir que os usuários mobile agendem
atendimentos em barbearias cadastradas.
RF10 O sistema deve permitir que os usuários mobile cancelem
seus agendamentos.
RF11 O sistema deve permitir que os usuários mobile avaliem
uma barbearia após um atendimento na mesma.
RF12 O sistema deve permitir que funcionários de barbearias
visualizem seus atendimentos.
31
3.2.2 Requisitos não funcionais

Identificador Descrição
RNF01 O sistema deve ser construído utilizando uma linguagem
de fácil manutenção.
RNF02 O usuário deve ser capaz de utilizar as principais
atividades do sistema em, no máximo, 2 minutos.
RNF03 O sistema deve ser feito para Android e iOS.
RNF04 As pesquisas dos usuários devem ser retornadas em menos
de 10 segundos.
RNF05 Os módulos que compõem o sistema devem estar bem
separados.
RNF06 O sistema deve dar um feedback claro à respeito dos
erros que eventualmente ocorrerem.
RNF07 O sistema deve controlar o acesso dos usuários às rotas
específicas de cada um deles.
RNF08 O usuário deve ser avisado quando estiver realizando
alguma ação crítica (agendamento/cancelamento).
RNF09 O acesso ao banco de dados deve ser feito de forma
separada, possibilitando a utilização do mesmo banco
em uma versão Web.
3.2.3 Modelagem do sistema
3.2.3.1 Diagrama geral da aplicação
O sistema desenvolvido neste trabalho foi idealizado para ter interfaces distintas interagindo
com uma mesma API, que, por sua vez, é a responsável pela lógica de negócio da aplicação
e pela interação com os dados no banco de dados. A Figura 9 ilustra o funcionamento
geral da aplicação.
32
Figura 9 – Diagrama geral da aplicação
Como se pode ver na Figura 9, o banco de dados da aplicação se encontra centralizado no

backend da aplicação. As interfaces mobile e web se comunicam e tem acesso ao banco
de dados através de uma API REST. Esse modelo tem como vantagem permitir uma
interface única que pode ser acessada por diferentes tipos de clientes. Neste trabalho,
foram implementados um cliente móvel, para uso dos clientes das barbearias, e um cliente
web usado pelos barbeiros e donos de barbearias.
3.2.3.2 Diagramas de casos de uso
Além da disposição dos elementos que compõem o sistema, para o seu desenvolvimento
foram desenhados alguns cenários utilizando diagramas de caso de uso. O primeiro deles
(Figura 10) representa as possíveis ações de um usuário em um dispositivo móvel, ou seja,
um cliente de uma barbearia.
33
Figura 10 – Diagrama de caso de uso (mobile)
O segundo diagrama (Figura 11) mostra as ações que um barbeiro pode realizar por meio
de sua área na interface web. Este usuário pode, propositalmente, realizar um número
menor de ações, já que não é o tipo de usuário principal do sistema.
34
Figura 11 – Diagrama de caso de uso (web)
Por fim, um último diagrama de uso (Figura 12) foi desenhado listando as possibilidades
para um usuário que fosse dono de uma barbearia. Este também acessaria a interface web
e suas funcionalidades estão mais ligadas à gerência dos componentes de sua barbearia,
como os barbeiros que atuam no seu estabelecimento, os horários de funcionamento e os
serviços oferecidos.
35
Figura 12 – Diagrama de caso de uso (web)
3.2.3.3 Diagrama de classes
As classes do backend do sistema foram criadas de acordo com a necessidade no decorrer

do desenvolvimento do código. Por conta disso, a estrutura das classes e o relacionamento
entre elas ficaram bem semelhantes ao que consta no modelo entidade relacionamento
do banco de dados, pois eram criadas ao mesmo tempo. Parte do que está presente nas
classes só foi feito desta forma devido à utilização das ferramentas citadas ao longo do
capítulo 2. A Figura 13 ilustra a disposição dessas classes no sistema.
36
Figura 13 – Diagrama de classes do backend
3.3 PROCESSO DE DESENVOLVIMENTO
O processo de desenvolvimento deste trabalho foi distribuído em três etapas: idealização,

prototipação e codificação. A primeira delas, a idealização, foi composta pelos requisitos e
modelos apresentados anteriormente. Estes foram componentes essenciais para estruturar
a ideia do sistema criado, definindo, mesmo que de forma geral, os objetivos a serem
alcançados durante as etapas seguintes. A prototipação utilizou as definições criadas
no passo anterior para ilustrar a aparência e o comportamento da aplicação, expondo
de forma mais palpável seu funcionamento. Esta foi uma etapa importante pois os
protótipos das telas da aplicação serviram de base para o desenvolvimento do código,
facilitando e agilizando a criação do frontend. Por fim, a etapa de codificação resumiu-se
à implementação de fato de todas as regras e telas que haviam sido definidas nas etapas
anteriores. Foi a parte mais longa de todo o trabalho, pois envolveu o desenvolvimento
37
de um backend responsável pela lógica da aplicação, alinhada aos requisitos descritos

anteriormente, e as duas interfaces, uma web e outra mobile, que se comunicam com este
backend fornecendo as interações necessárias para os usuários do sistema.
3.3.1 Ferramentas
Para a construção do sistema presente neste trabalho, foi necessário o uso de diversas
ferramentas de desenvolvimento. Como base para o desenvolvimento do código foi utilizado
o editor de código Visual Studio Code1 , pela flexibilidade fornecida com o uso das extensões
presentes no software. Para a configuração inicial da aplicação o Docker2 foi utilizado.
Docker é uma plataforma que possibilita a conteinerização de softwares, onde o programador
descreve em um arquivo os softwares que ele necessita e, rodando apenas algumas linhas
de código, consegue subir um ambiente de desenvolvimento com tudo o que necessita.
No desenvolvimento, o Docker foi utilizado para agilizar o setup inicial da aplicação e
possibilitar o desenvolvimento a partir de computadores diferentes. Uma ferramenta que o
Docker possibilita configurar mais rapidamente é o PostgreSQL3 , que foi o banco de dados
relacional utilizado para construir as tabelas do sistema.
Sobre as ferramentas focadas no desenvolvimento do backend, um dos destaques é o Node.js,

que é um ambiente de execução utilizado para possibilitar o uso da linguagem JavaScript no
processo de criação da API. Em conjunto com o Node.js, o Express4 foi utilizado em todo
o processo de desenvolvimento do backend. Ele é um framework JavaScript para ambientes
Node.js que agiliza o trabalho de desenvolvimento de uma API, facilitando a criação de
rotas, middlewares e na manipulação de erros. Para testar as rotas criadas com Express,
foi utilizado o software Insomnia, que funciona como um cliente de uma API REST. Ele
possibilita que os testes sejam feitos de forma rápida e fácil, como exemplificados na Figura
4.
Para o desenvolvimento das interfaces, o React foi a principal ferramenta. Focado em

construir aplicações de página única, ou SPAs (Single Page Applications) na sigla em
ingês, o React agiliza a criação das interfaces por tratar todos os seus componentes como
componentes funcionais, ou seja, para reutilizar um componente é necessário apenas
invocá-lo como uma função JavaScript, o que facilita um maior reaproveitamento de código.
Essa vantagem ganha maior destaque com o uso da biblioteca Styled Components5 , que
serve para utilizar código CSS em arquivos JavaScript. Dessa forma, é possivel criar um
componente estilizado e reaproveitá-lo em diferentes locais na interface, algo comum de ser
feito para botões, tabelas e inputs, campos de entrada de dados do usuário. Para testar e
1
https://code.visualstudio.com/
2
https://www.docker.com/
3
https://www.postgresql.org/
4
https://expressjs.com/pt-br/
5
https://styled-components.com/
38
visualizar as interfaces criadas, é necessário fazer uso de um navegador de internet. Neste

trabalho o navegador Chrome, da Google, foi utilizado apenas por preferência do autor.
Como um dos focos deste trabalho foi tirar vantagem da possibilidade de reaproveitar tanto
código quanto conhecimento, a aplicação mobile seguiu o padrão da interface web, usando
a versão mobile do React, o React Native. A diferença do React Native para o React
utilizado na web é basicamente o foco na criação de interfaces mobile. No desenvolvimento
do app mobile também foi utilizada a biblioteca Styled Components com o mesmo princípio
empregado em sua utilização na web. E, por fim, para visualizar e interagir com a aplicação
foi necessário utilizar um emulador de celular. Como a aplicação foi desenvolvida utilizando
um computador com o sistema operacional Ubuntu na versão 18, não foi possível emular a
versão iOS do app, já que isso só é possível em um computador com o macOS da Apple.
Portanto, foi escolhido o Android Studio6 para emular um celular Android e possibilitar a
visualização do resultado do código produzido.
A disposição das ferramentas mencionadas nesta seção pode ser verificada a seguir,
onde é indicado o contexto em que cada uma das ferramentas foi utilizada durante
o desenvolvimento do código.
Ferramenta Contexto
Ubuntu 18.0.4 Backend, Frontend e Mobile
Visual Studio Code Backend, Frontend e Mobile
Docker Backend, Frontend e Mobile
PostgreSQL Backend
Node.js Backend
Express Backend
Insomnia Backend
React Frontend
Styled Components Frontend e Mobile
Google Chrome Frontend
React Native Mobile
Android Studio Mobile
3.3.2 Implementação
O processo de desenvolvimento do código deste trabalho foi iniciado pelo backend da

aplicação. Primeiramente idealizou-se o que a aplicação necessitaria mostrar para os
diferentes tipos de usuário e quais seriam as ações que estes usuários poderiam realizar.
Dessa forma, o maior esforço foi empregado na construção da lógica presente na API do
6
https://developer.android.com/studio/intro
39
sistema. Essa decisão favoreceu o posterior desenvolvimento das interfaces, já que os testes
poderiam ser feitos utilizando as rotas reais já validadas no backend. A primeira interface
a ser desenvolvida foi a aplicação mobile. Isso se deu por conta do processo de criação
dos protótipos de tela, que neste trabalho foram destinados apenas ao processo criativo
do app mobile. Apenas após a finalização da aplicação mobile se deu o desenvolvimento
do frontend web. Os testes, até esse ponto, que se utilizavam de ações dos usuários deste
frontend eram feitos com inserção de dados por chamadas diretas à API, utilizando o
software Insomnia. Nas subseções a seguir, serão detalhados os fluxos de implementação
de cada uma das partes do sistema.
3.3.2.1 Banco de dados
O banco de dados objeto-relacional escolhido para o sistema deste trabalho foi o PostgreSQL,
dada sua facilidade para integrar com o código JavaScript utilizando o ORM Sequelize7 .
Um ORM, sigla para Object Relational Mapper, ou mapeamento objeto-relacional no
português, é uma técnica para facilitar o desenvolvimento de código orientado a objetos ao
utilizarmos um banco de dados relacional (Wikipedia, 2021), de forma que as bibliotecas
ou frameworks ORM mapeiam os objetos dessas classes para as tabelas do banco de
dados, tornando os atributos das classes em colunas dessas tabelas, fazendo com que
o desenvolvedor não precise criar códigos SQL para cuidar da persistência dos dados.
Para a criação de tabelas e relacionamentos entre elas, alguns frameworks ORM utilizam
o conceito de migrations (Prisma, 2021), que, no caso do ORM Sequelize, são códigos
JavaScript descrevendo alterações no modelo de dados, criando ou removendo: tabelas,
colunas em alguma tabela ou até mesmo relacionamentos entre tabelas.
Como o foco deste trabalho está no desenvolvimento do software em si, o uso do banco de
dados se deu de forma simples, com sua evolução na aplicação se dando exclusivamente
da forma mais cômoda para o desenvolvedor: através de código, e, neste caso, JavaScript.
Todas as tabelas, atributos e relacionamentos entre as tabelas foram desenvolvidos sob
demanda, a partir da necessidade de alguns destes itens no decorrer do desenvolvimento das
funcionalidades do backend. Na Figura 14 é possível visualizar um esquema da disposição
final do banco de dados da aplicação onde cada bloco desse diagrama representa uma
tabela do banco de dados. Dentro desses blocos estão os atributos, ou colunas, de cada
tabela. E, por fim, interligando as tabelas, estão os relacionamento entre elas.
7
https://sequelize.org/v5/
40
Figura 14 – Diagrama entidade relacionamento
3.3.2.2 Backend
A primeira parte da aplicação a ser desenvolvida foi a API REST responsável pela lógica
de negócio do projeto. Esse desenvolvimento só foi iniciado após a definição de alguns
requisitos funcionais, apresentados na Seção 3.2.1, pois eles funcionaram como um guia
para o que a API deveria realizar.
41
A organização do backend, assim como das demais interfaces, seguiu com um repositório
independente e uma estrutura de arquivos particular. Os arquivos referentes às variáveis de
ambiente e a pasta tmp, contendo arquivos temporários como os uploads de imagens, ficaram
na raiz do projeto, assim como os arquivos de configurações dos pacotes NPM8 utilizados
na aplicação. Os pacotes NPM (Node Package Manager) são basicamente pacotes contendo
códigos Node.js de terceiros a fim de abstrair determinadas funcionalidades necessárias
no desenvolvimento do código, como: utilização de um ORM, upload de imagens ou
manipulação de datas no JavaScript.
Dentro do diretório src encontram-se os arquivos do desenvolvimento de fato, separados

nas pastas app, que contém a lógica do sistema, config, que apresenta alguns arquivos
de configuração de algumas funcionalidades como autenticação e upload de arquivos,
e database, contendo todas as migrations criadas e a conexão com o banco de dados.
Dentro da pasta app estão os controladores da aplicação, ou seja, as ações que as classes
do sistema realizam, as models, que são as classes do sistema, e uma pasta para os
middlewares da aplicação, contendo apenas o middleware de autenticação no estágio atual
do desenvolvimento. Essa disposição é apresentada abaixo:
/
src
app
controllers
middlewares
models
config
database
migrations
tmp
uploads
As tabelas do banco de dados foram todas criadas via código, utilizando o conceito de
migrations com o ORM Sequelize. Isso facilitou a realização de alterações no banco de
dados durante o desenvolvimentos pois com poucos comandos era possível modificar todo
o trabalho já realizado sem perder tempo solucionando conflitos. As classes da aplicação
foram desenvolvidas definindo apenas seus atributos e suas associações. Todos os métodos
referentes a essas classes ficaram separados nos controladores, cujos arquivos possuem o
mesmo nome das classes acrescidos do complemento "Controller", exemplo: Barber.js e
BarberController.js. Esses controladores possuem no máximo 5 métodos cada:
• store, para criar um novo item de uma classe;

8
https://www.npmjs.com/
42
• index, que lista todos os itens da classe;
• update, para atualizar um registro de uma classe;
• delete para deletar um registro de uma classe;
• show, que exibe um registro específico de uma determinada classe.
Para a construção de cada um desses métodos, foi necessário realizar a validação dos dados
de entrada, já que os mesmos serão enviados para o banco de dados e devem respeitar
certos tipos de dados, assim como alguns parâmetros não podem estar vazios em alguns
casos.
Todas as rotas desenvolvidas para a API ficaram contidas no arquivo routes.js dentro
do diretório src e para invocá-las é necessário que o usuário esteja autenticado. Essa
autenticação é feita por meio do uso de tokens JWT9 , que é um padrão utilizado para
autenticação em requisições web onde o token é um código Base64 e seu conteúdo
decodificado é um JSON que possui dados que possibilitam a autenticação da requisição
(TreinaWeb Tecnologia, 2021). Para obter esse token JWT é necessário que o usuário
realize login no sistema, ou seja, crie uma nova sessão na aplicação. Por conta disso, apenas
as rotas de cadastro e de login na aplicação não fazem uso do middleware de autenticação,
em todas as outras rotas temos o middleware atuando e impedindo que as requisições
sejam feitas por usuários não autenticados. Os testes dessa dinâmica da API e de todas as
rotas desenvolvidas nesta etapa de desenvolvimento do sistema foram feitos utilizando o
software Insomnia.
3.3.2.3 Aplicação mobile
Antes de iniciar o processo de desenvolvimento do aplicativo móvel, foi necessário pensar a

respeito dos atores deste sistema, isto é, os usuários que fariam uso dessa aplicação. Neste
ponto, foi considerado manter um aplicativo móvel com diferentes visões de acordo com o
tipo de usuário que está acessando a aplicação, ou seja, um mesmo aplicativo exibiria telas
diferentes com ações diferentes para cada um dos tipos de usuários. Porém, ao estudar
um pouco mais a necessidade de cada um dos usuários, ficou claro que a visualização em
um smartphone não seria a melhor solução para todas as diferentes necessidades de cada
um deles. O dono de uma barbearia tiraria melhor proveito das métricas e dos gráficos
disponíveis acessando um frontend web, com uma tela maior. O profissional de uma
barbearia não poderia tolerar quebras na aplicação devido a atualizações do aplicativo e
ainda esperar por uma correção destas falhas, que poderiam ser demoradas já que esse
9
https://jwt.io/
43
processo de atualização tem a loja de aplicativos de cada plataforma, iOS ou Android,

como intermediário, aumentando o tempo para uma correção ter efeito. Deste modo, foi
decidido que apenas o usuário cliente dos estabelecimentos cadastrados no sistema deveria
ter acesso à aplicação mobile, já que este perfil de usuário busca uma praticidade maior e
tem maior tolerância aos possíveis problemas oferecidos por essa decisão.
O início do desenvolvimento do app se deu pelas telas inicias para o usuário final, ou seja,
as telas de login e cadastro do usuário. Estas telas já estavam presentes no layout e, embora
não tenham sido construídas exatamente como no protótipo, sofreram grande influência
desse design inicial. A esta altura do desenvolvimento do sistema como um todo o backend
já havia sido construído, portanto todo o desenvolvimento desta aplicação se tornou mais
um trabalho de estilização e controle dos componentes da mesma. Desta forma, por já saber
que as requisições feitas à API estavam com o funcionamento correto, a implementação
teve seu foco nos componentes visuais e em seus comportamentos, simulando interações
e preenchimento dos dados diretamente no código. Apenas após a finalização de toda a
estilização da aplicação esses dados e requisições falsas foram substituídos pelas invocações
reais das rotas criadas na API.
Em relação ao armazenamento de dados, esta interface apenas fez uso deste recurso
para a autenticação do usuário. Uma vez que um usuário realiza o login no app, os
dados desta requisição são salvos no armazenamento local do dispositivo, conhecido como
AsyncStorage 10 . O AsyncStorage é global para o aplicativo e, como o nome sugere, realiza
operações assíncronas, guardando dados no formato chave-valor de forma não criptografada.
Quando o usuário realiza o logout da aplicação, as informações mencionadas anteriormente
são deletadas do AsyncStorage. Essa dinâmica que permite o controle de acesso dos
usuários às telas da aplicação, de acordo com este status do login.
3.3.2.4 Frontend
O desenvolvimento do frontend web não contou com a criação de mockups para criação
das telas da aplicação, porém, em questão de design, a interface foi feita em harmonia
com o que foi desenvolvido no aplicativo móvel, utilizando a mesma paleta de cores. Este
projeto contou com uma estrutura de diretórios bem simples, exemplificada abaixo:
/
public
src
assets
components
pages
layouts
10
https://reactnative.dev/docs/asyncstorage
44
routes
services
No diretório public fica o HTML base da página, que conta basicamente com o favicon, ou
ícone do site, e a instrução para a cor do tema do site em dispositivos mobile. Em src está
todo o conteúdo de fato desta aplicação, começando pelas logos dentro de assets. Dentro
de components ficaram alguns elementos que se repetem na aplicação, como botões, a barra
lateral e a barra inferior. Na pasta pages estão todas as páginas da aplicação e, dentro de
layouts, as configurações padrões de design para páginas em que o usuário está logado
e para as que ele não está logado. Todos os componentes e páginas estão organizados
em suas próprias pastas, contendo apenas dois arquivos: index.js, contendo a lógica do
componente, e styles.js, onde estão as estilizações do componente ou página em questão.
Por fim, no diretório routes estão as rotas da aplicação e em services a configuração de
navegação.
O código foi iniciado pela criação das telas de login e cadastro de usuário, com design
semelhante ao que foi implementado no aplicativo móvel. Em seguida, o desenvolvimento
seguiu com as telas a serem utilizadas pelos donos das barbearias, com ênfase na criação
de gráficos dispondo informações relevantes para este tipo de usuário. Após a finalização
destas telas, deu-se início ao desenvolvimento das telas para os barbeiros destas barbearias.
Como o foco desta interface web foi a simplicidade, imaginando que seu uso seria menor
em comparação ao aplicativo móvel, existem apenas duas telas para cada um dos tipos de
usuário: tela principal, mostrando as informações principais para cada tipo de usuário,
e a tela de edição de perfil do usuário. Apesar da simplicidade, houve uma atenção à
responsividade da aplicação já que é esperado que, ao menos os barbeiros, façam uso desta
parte do sistema por meio de um smartphone.
3.3.3 API REST de comunicação frontend - backend
No apêndice A estão documentadas todas as rotas da API deste trabalho, com exemplos
de requisições, separadas em subseções de acordo com o que cada uma delas manipula. As
requisições à API, de modo geral, foram feitas utilizando o header "Content-Type"com o
valor "application/json"e fazendo uso de um Bearer Token, que é adquirido ao realizar login
na aplicação. As exceções ficam por conta da requisição para criação de novos usuários, que
não necessita de autenticação para ser acessada, e a requisição para upload de avatares para
usuários e barbearias, onde o header "Content-Type"possui o valor "multipart/form-data".
45
4 RESULTADOS
Neste capítulo serão apresentados os resultados obtidos pelo desenvolvimento do software

proposto neste trabalho. As telas apresentadas neste capítulo foram geradas utilizando
dados fictícios apenas para fins de teste.
Para tornar mais objetiva a análise deste software, é importante especificar quais são as
principais funcionalidades a serem levadas em consideração. Neste caso, as funcionalidades
principais são a listagem das barbearias, já que isso envolve o correto cadastro das
informações do estabelecimento e também do dono da mesma; a realização de agendamentos
por parte dos clientes das barbearias, que é a principal funcionalidade do sistema; e a
visualização destes agendamentos por parte dos barbeiros e dos clientes que realizaram
essa ação. Além das funcionalidades em si, é necessário observar também se as informações
nas interfaces estão sendo dispostas de forma clara para os usuários, atentando-de à
responsividade no caso do uso da interface web por usuários que sejam barbeiros.
Na próxima seção os resultados serão separados em roteiros de uso dos diferentes tipos de
usuários do sistema, com o objetivo de mostrar um ciclo de uso de cada um deles com as
principais funcionalidades de cada interface.
4.1 APRESENTAÇÃO DOS RESULTADOS
Nesta seção serão apresentados três diferentes roteiros de uso do sistema para os diferentes
usuários da aplicação: um roteiro para donos de barbearias, um para os barbeiros destas
barbearias e, por fim, um roteiro para os clientes das barbearias. Destes roteiros, os
resultados dos dois primeiros são apresentados utilizando a interface web, já o último,
referente aos clientes das barbearias, contará com a exibição das telas do aplicativo móvel.
4.1.1 Web - Roteiro de uso de donos de barbearias
A tela inicial para os usuários da interface web é a tela de login (Figura 15. Uma tela
bastante similar à que está presente no aplicativo móvel, onde o usuário deve inserir apenas
seu login e senha.
46
Figura 15 – Tela de login
Caso seja o primeiro acesso do usuário, o mesmo deve se registrar na aplicação. Para isso
existe a tela de cadastro de usuário (Figura 16, exigindo apenas o nome, e-mail e a criação
de uma senha para que o usuário esteja apto a utilizar o sistema.
Figura 16 – Tela de cadastro

47
Após realizar o login, a tela a ser exibida dependerá do tipo de usuário que está acessando
o sistema. No caso deste roteiro, o usuário é dono de uma barbearia e, portanto, sua tela
inicial quando estiver logado será a de detalhes da barbearia (Figura 17). Se o usuário
não registrou uma barbearia no sistema ainda, a tela irá conter apenas um botão para
realizar o cadastro da barbearia.
Figura 17 – Tela de detalhes da barbearia (vazio)
Para criar a barbearia, o usuário deve clicar no botão "Cadastrar Barbearia". Após
o clique um modal surgirá na tela solicitando algumas informações a respeito do
estabelecimento a ser cadastrado, como nome, cnpj e o endereço do mesmo (Figura
18).
48
Figura 18 – Modal para criação de barbearia
Após clicar em "criar barbearia", o usuário verá as informações de sua barbearia listadas
na tela que antes abrigava apenas o botão para cadastro de uma barbearia (Figura 19).
Porém, para uma exibição completa dos dados, é necessário que o usuário cadastre cada
um dos itens que fazem parte da sua barbearia: os barbeiros, os serviços oferecidos e os
horários de funcionamento. Para cadastrá-los, há um botão para cada uma dessas ações,
cujo funcionamento é semelhante ao de cadastrar uma barbearia: ao clicar no botão, um
modal se abre e basta que o usuário informe os dados necessários e clique no botão de
ação ao final de cada modal para cadastrar o item (Figuras 19, 20 e 21).
49
Figura 19 – Modal para criação de barbeiros
Figura 20 – Modal para criação de serviços

50
Figura 21 – Modal para criação de horário de funcionamento
Com os dados cadastrados corretamente, um exemplo de visualização dos detalhes da

barbearia segue na Figura 22. São exibidos o nome da barbearia, o endereço da mesma e
seu cnpj, os horários de funcionamento de cada dia em que se encontra aberta, os barbeiros
que trabalham nesta barbearia e os serviços oferecidos, bem como o valor, em reais, de
cada um deles.
Figura 22 – Tela de detalhes da barbearia

51
Toda a interface foi desenvolvida de modo que as telas sejam responsivas, ou seja, caso o
usuário acesse o sistema através do navegador web de um celular, as páginas da aplicação
se ajustarão ao tamanho da tela do dispositivo e a visualização por parte do usuário não
será prejudicada. A Figura 23 um exemplo de visualização desta tela de detalhes da
barbearia de modo responsivo.
Figura 23 – Tela de detalhes da barbearia (responsivo)
Por fim, outra página presente na visualização dos usuários web é a página de perfil (Figura
24). Ela é comum tanto aos donos de barbearia quanto aos barbeiros destas barbearias.
Nesta página o usuário pode alterar seus dados e sua foto de perfil, além de poder realizar
52
o logout da aplicação.
Figura 24 – Tela de perfil
4.1.2 Web - Roteiro de uso de barbeiros
Assim como no roteiro de uso dos donos de barbearias, os barbeiros que utilizam a interface
web do sistema irão se deparar inicialmente com as telas de login e registro na aplicação.
Porém, já que os donos de barbearias registram cada um dos barbeiros na aplicação, estes
já acessam o sistema estando aptos a realizar login. Após o login, a tela inicial para estes
usuários é a tela de detalhes da agenda, onde o barbeiro pode visualizar cada um dos
horários de atendimento de seu dia de trabalho, com estilizações distintas para horários
passados, horários que possuem um agendamento cadastrado e horários disponíveis (Figura
25). É nesta tela também que o barbeiro pode, se desejar, cancelar um atendimento à um
cliente. Para isso, basta clicar no ícone vermelho de agenda com um X ao centro. Uma
mensagem de confirmação será exibida e, após o usuário confirmar, o atendimento será
cancelado.
53
Figura 25 – Tela de detalhes da agenda
Assim como as demais telas da aplicação, esta tela possui um design responsivo, já que
foi pensada, intencionalmente, para que os barbeiros a utilizem preferencialmente via
smartphones (Figura 26).
54
Figura 26 – Tela de detalhes da agenda (responsivo)
Um detalhe a respeito da tela de perfil do usuário é que, na visualização em telas de

dispositivos menores, como a de um celular, a barra lateral dá espaço à barra inferior, que,
por sua vez, não possui um botão para que o usuário saia da aplicação. Isso se dá por
uma escolha que leva em conta a experiência do usuário, evitando que o mesmo clique
sem intenção no botão. Por conta disso, um botão para realizar logout do sistema foi
adicionado à tela de perfil (Figura 27).
55
Figura 27 – Tela de perfil (responsivo)
4.1.3 Mobile - Roteiro de uso de clientes de barbearias
A primeira tela que um usuário irá se deparar no aplicativo móvel, caso não tenha iniciado
uma sessão, é a tela de login (Figura 28). Caso o usuário já tenha cadastro na aplicação,
basta que insira seu e-mail, a senha e clique em Entrar.
56
Figura 28 – Tela de login
Se o usuário ainda não possuir cadastro, existe uma tela para cadastro de usuário (Figura
29). Ela pode ser acessada ao clicar no botão Criar conta. Para o cadastro é necessário
informar apenas o nome completo, o e-mail e uma senha. O perfil do usuário será criado
após o clique em Cadastrar.
57
Figura 29 – Tela de cadastro de usuário
Após realizar o login na aplicação, a sessão do usuário ficará salva, com o app tendo
facilmente à disposição os dados inseridos para realizar login e o token JWT obtido como
resposta da requisição. Neste caso, o usuário pode fechar o aplicativo e sempre que abrí-lo
novamente a tela inicial será a de listagem de barbearias, que possui o nome Início
na barra de navegação inferior (Figura 30). A partir deste ponto, o aplicativo enviará
automaticamente o token JWT em todas as requisições do usuário.
Na listagem de barbearias cada item retornado pela API é exibido como um pequeno card
contendo a imagem de identificação da barbearia, o nome da mesma, seu endereço e sua
58
avaliação no aplicativo, que é composta pela média das notas que os usuários deram para
os atendimentos realizados na barbearia em questão.
Figura 30 – Tela de listagem de barbearias
Selecionar uma barbearia é uma das principais funcionalidades do aplicativo já que, para
realizar o agendamento de um serviço em uma barbearia, o primeiro passo do usuário é
visualizar e selecionar o estabelecimento de sua preferência dentre os que estão listados.
Para facilitar essa escolha, foi criada a tela de busca por barbearias (Figura 31), onde
o usuário pesquisa estabelecimentos cadastrados no sistema pelo nome. Em questão
de funcionalidade, a diferença da requisição feita nesta tela para a tela de listagem de
59
barbearias fica por conta apenas da inclusão de um filtro para que o nome das barbearias
listadas correspondam ao que o usuário está digitando. Nesta busca foi utilizada a técnica
de debounce, onde a requisição para buscar barbearias é disparada automaticamente 300
milisegundos após o usuário parar a digitação.
Figura 31 – Tela de busca por barbearias
Após a escolha da barbearia de sua preferência, o usuário é direcionado para uma tela
que contém detalhes do estabelecimento selecionado (Figura 32), exibindo os serviços
oferecidos, seus barbeiros e os horários disponíveis de acordo com seu funcionamento. É
nesta tela que o usuário tem a possibilidade de realizar um agendamento selecionando
60
cada um dos itens mencionados anteriormente.
Os serviços são identificados pelo nome e o valor cobrado em reais. A exibição dos barbeiros
conta com uma foto de identificação (avatar) e seus respectivos nomes. Já os horários
para realização de agendamentos seguem um padrão de duração de 30 minutos para cada
um deles no intervalo definido pelo dono da barbearia entre o início e o encerramento das
operações de cada dia.
Figura 32 – Tela de realização de agendamento
Antes que o agendamento seja realmente realizado, é necessário que o usuário confirme a
ação. Para isso, após selecionar todos os campos necessários na tela anterior e clicar em
61
Agendar, o usuário é direcionado para a tela de confirmação do agendamento (Figura 33).

Nesta tela o usuário pode conferir as informações do agendamento e, caso as informações
estejam corretas, pode clicar em Confirmar para que o agendamento seja finalmente
criado.
Figura 33 – Tela de confirmação do agendamento
Assim que o usuário agenda um atendimento em uma barbearia, as informações deste

agendamento ficam disponíveis para consulta na tela de listagem de agendamentos (Figura
34). Para acessá-la, basta clicar em Agendamentos na barra inferior. A visualização
inicial será dos agendamentos que já foram concluídos ou cancelados, ou seja, agendamentos
feitos em datas passadas.
62
Figura 34 – Tela de listagem de agendamentos passados
O usuário também pode visualizar os agendamentos de atendimentos que estão por vir ao
clicar na aba PRÓXIMOS. Se não existirem atendimentos futuros, a tela será exibida
sem nenhum resultado, com uma mensagem informando a situação ao usuário (Figura 35).
63
Figura 35 – Tela de listagem dos próximos agendamentos (vazio)
Caso o usuário tenha algum atendimento futuro para comparecer, este será exibido com
uma nova funcionalidade: a possibilidade de cancelar o agendamento.
64
Figura 36 – Tela de listagem dos próximos agendamentos
Para cancelar um agendamento, basta que o usuário clique no ícone vermelho de agenda
com um X ao centro, no canto superior direito do card de agendamento (Figura 36). Como
é uma ação crítica, é necessário que o usuário confirme a ação. Por isso, ao clicar no botão
mencionado, uma janela surgirá para informar o usuário dos riscos da ação e solicitar a
confirmação da mesma (Figura 37). Caso o usuário confirme a ação, ela aparecerá com o
status Cancelado na lista de agendamentos anteriores.
65
Figura 37 – Tela de cancelamento de agendamento
Além da possibilidade de cancelar agendamentos, a tela de listagem de agendamentos

possui outra funcionalidade: a avaliação de atendimentos por parte do usuário. Para
submeter uma avaliação, basta que o usuário clique em Avaliar atendimento em um card
na aba de agendamentos anteriores. Isto o levará para a tela de avaliação do atendimento
(Figura 38), onde o mesmo poderá dar uma nota, de 1 a 5 estrelas, e, caso queira, deixar
um comentário sobre o atendimento da barbearia em que foi atendido. Para submeter a
avaliação basta que o usuário clique em Avaliar.
66
Figura 38 – Tela de avaliação do atendimento
Por fim, o usuário pode consultar e alterar as informações de seu perfil na aba Perfil da
barra de navegação (Figura 39). Nesta tela é possível alterar a foto de perfil, o nome e a
senha do usuário, além de possibilitar a realização do logout da aplicação. Para atualizar
as informações é necessário que o usuário clique em Atualizar perfil após modificar os
valores dos campos desejados. Caso o usuário deseje encerrar sua sessão no aplicativo,
basta clicar em Sair do Barbex e ele será redirecionado para a tela de login do aplicativo.
67
Figura 39 – Tela de perfil do usuário
4.2 DISCUSSÃO SOBRE OS RESULTADOS
Após a apresentação dos resultados, é possível verificar consistência entre os layouts das
interfaces web e mobile, fazendo com que o sistema possua uma identidade própria. O
nome da aplicação (Barbex) foi dado de forma a ter um nome simples, fácil e que remetesse
ao tema em que está inserida. Além disso, foram usadas poucas cores no design das
interfaces, com o laranja atuando como realce para a marca e para os botões para ações
do usuário, o vermelho para situações de alerta em ações críticas como o cancelamento
de um agendamento ou a realização de logout, e tons de cinza e branco para os textos
68
presentes no sistema, já que foi escolhido um fundo escuro tanto para a interface web
quanto para a mobile. Com a utilização de diferentes tons dessas cores e tamanhos das
fontes dos textos foi possível hierarquizar e priorizar os conteúdos mais importantes a
serem exibidos, chamando a atenção do usuário.
A aplicação web, apesar de ser teoricamente uma interface a ser utilizada em notebooks e
desktops, foi pensada de forma responsiva pelo crescimento da utilização de smartphones
para a navegação na web. Não apenas isso, mas a responsividade oferece maior conforto
e facilidade para os usuários desta aplicação, principalmente os barbeiros, que podem
consultar a agenda rapidamente, bastando apenas realizar o login no site.
De modo geral, o sistema é enxuto, com a maior parte das funcionalidades presentes no
aplicativo móvel. Isso se dá por ser um trabalho de conclusão de curso, onde o escopo deve
ser menor para que sua realização seja factível com o tempo disponível para sua elaboração.
Porém, a aplicação permite que, com mais tempo de desenvolvimento, possa se tornar ou
ser usada como um produto de fato. Isso acontece, em partes, pela facilidade de incorporar
novas funcionalidades na API do sistema, onde, no momento, já existem funcionalidades
prontas que não tiveram seu uso implementado nas interfaces web ou mobile. Algumas
delas são: a possibilidade de notificar o barbeiro a respeito de um agendamento, ou um
usuário sobre o cancelamento de um atendimento; a possibilidade do usuário do aplicativo
móvel favoritar os estabelecimentos que mais gostou; e, também no aplicativo móvel,
possibilitar que o usuário tenha uma lista de endereços salvos, podendo alternar entre
eles quando quiser. Todas essas funcionalidades possuem lógica desenvolvida no backend
e tabelas prontas. Mais informações sobre essas possibilidades podem ser conferidas na
seção 5.1, onde serão discutidos trabalhos futuros.
Por fim, foi possível verificar que, ao final do desenvolvimento e apresentação das telas de
cada interface, os usuários de cada parte do sistema estão aptos a visualizar as informações
disponíveis e seus dados cadastrados de forma clara, com as aplicações exibindo apenas as
informações necessárias, de forma objetiva. Com isso os usuários podem realizar qualquer
ação disponível em seus contextos em menos de 10 cliques.
69
5 CONSIDERAÇÕES FINAIS
Neste trabalho foi desenvolvido um sistema para gerenciar horários de barbearias utilizando
o ecossistema da linguagem de programação JavaScript. O sistema é composto por uma
API responsável pela lógica de negócio e duas interfaces, uma web e outra mobile, e
possibilita a interação de donos de barbearias, barbeiros e clientes de barbearias com a
aplicação.
Para desenvolvimento do projeto, vários conceitos foram utilizados. Entre eles podem ser
citados: arquitetura MVC, arquitetura REST, fundamentos de desenvolvimento web e
mobile e conceitos de experiência do usuário e interface de usuário. Também foi estudado
o funcionamento das bibliotecas React e React Native para desenvolvimento do sistema.
Para que fosse possível gerenciar os horários de barbearias foi necessário mapear os itens
necessários para o funcionamento das mesmas. Após a identificação desses itens, a API
foi construída para possibilitar a manipulação destes dados, como endereço, barbeiros
cadastrados e serviços oferecidos. O resultado obtido é observado através das interfaces
construídas, tanto web quanto mobile, para interagir com essa API.
Um grande desafio encontrado no desenvolvimento da aplicação foi a definição de

responsabilidades de cada uma das interfaces. Devido a diversidade de possibilidades,
considerou-se no início apenas uma interface mobile responsável pelas informações de
barbeiros e clientes de barbearias, tornando o desenvolvimento mais cômodo. Porém,
visando um foco maior na experiência do usuário, decidiu-se por separar da interface
mobile a responsabilidade de atender as demandas dos barbeiros e estas funcionalidades
foram incluídas na interface web, reduzindo o impacto de manutenções e atualizações para
este tipo de usuário.
Os resultados obtidos com as interfaces web e mobile mostram que o sistema foi capaz de
realizar com sucesso as principais ações necessárias para o gerenciamento das atividades
de barbearias, como o cadastro de barbearias e barbeiros, a listagem de barbearias para
os clientes e a realização de agendamentos no app mobile, bem como o cancelamento dos
mesmos e a avaliação dos serviços prestados.
Após análise, os resultados encontrados se mostraram qualitativamente satisfatórios. Com

isso, é possível inferir que o sistema desenvolvido pode ser utilizado futuramente como um
gerenciador e agregador de barbearias em geral de forma ampla.
5.1 TRABALHOS FUTUROS
Ainda que os objetivos apresentados tenham sido alcançados, melhorias podem ser aplicadas
por trabalhos futuros:
70
• Incluir gráficos e métricas de gerenciamento na interface web para donos de barbearias.
• Permitir, no aplicativo móvel, que um usuário cadastre mais de um endereço em seu

perfil.
• Filtrar as barbearias exibidas no app mobile utilizando geolocalização.
• Possibilitar o cadastro e o login na aplicação utilizando outros serviços de autorização

de empresas como Apple, Facebook e Google.
• Implementar recuperação de senha.
• Adicionar lógica para efetuar pagamentos pelos serviços diretamente pelo aplicativo
móvel.
• Implementar, na interface web, notificações para os barbeiros sobre novos agendamentos.
• Realizar envio de e-mails para clientes de barbearias e barbeiros referente a novos

agendamentos e cancelamento de agendamentos.
• Possibilitar, no aplicativo móvel, que um usuário favorite uma barbearia.
• Implementar notificações push no app mobile.

71
REFERÊNCIAS
BARBEIROS, Curso de. História da barbearia. 2018d. Disponível em: <https:

//www.cursodebarbeiros.com.br/blog/historia-da-barbearia/>. Acesso em: 10 dez. 2021.
FALBO, Ricardo de Almeida. Engenharia de Requisitos - Notas de Aula. [s.n.], 2017.

Disponível em: <http://www.inf.ufes.br/~vitorsouza/falbo/Notas_Aula_Engenharia_
Requisitos_Falbo_2017.pdf>.
FORD, Henry. My life and work. [S.l.]: Cosimo, 2007.
Frontend Masters. What Is a Front-End Developer? 2021. Disponível em:

<https://frontendmasters.com/guides/front-end-handbook/2018/what-is-a-FD.html>.
Acesso em: 13 dez. 2021.
GAMMA, E. et al. Padrões de Projetos: Soluções Reutilizáveis. Bookman, 2006.

ISBN 9788573076103. Disponível em: <https://books.google.com.br/books?id=
V0Ey1KF3zwcC>.
Governo Federal. O que é a Covid-19? 2021. Disponível em: <https://www.gov.br/saude/

pt-br/coronavirus/o-que-e-o-coronavirus>. Acesso em: 10 dez. 2021.
JACOBSON, Ivar. Object Oriented Software Engineering: A Use Case Driven

Approach. Addison-Wesley, 1992. Disponível em: <http://www.amazon.com/
Object-Oriented-Software-Engineering-Approach/dp/0201544350>.
MARTINS, T. A. Fernandes E. F. R. Two Style: Um Software De Agendamento e

Gerenciamento. 34 f. Monografia (Curso Técnico) — Instituto Federal De Educação,
Ciência E Tecnologia Do Rio Grande Do Norte, Rio Grande do Norte, 2019.
Mozilla Developer Network. Uma visão geral do HTTP. 2021. Disponível em:
<https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Overview>. Acesso em: 12 dez.
2021.
Prisma. What are database migrations? 2021. Disponível em: <https:

//www.prisma.io/dataguide/types/relational/what-are-database-migrations#
what-are-database-migrations>. Acesso em: 21 dez. 2021.
Red Hat, Inc. O que é API REST? 2021. Disponível em: <https://www.redhat.com/
pt-br/topics/api/what-is-a-rest-api>. Acesso em: 17 dez. 2021.
SCALI-SHEAHAN, Maura. Milady’s Standard Professional Barbering. Milady

Publishing Company, 2010. ISBN 9781133169390. Disponível em: <https:
//books.google.com.br/books?id=scI8AAAAQBAJ>.
SOMMERVILLE, I. Engenharia de software. Pearson Prentice Hall, 2011.

ISBN 9788579361081. Disponível em: <https://books.google.com.br/books?id=
H4u5ygAACAAJ>.
TreinaWeb Tecnologia. O que é JWT? 2021. Disponível em: <https://www.treinaweb.

com.br/blog/o-que-e-jwt>. Acesso em: 21 dez. 2021.
Wikipedia. Mapeamento objeto-relacional. 2021. Disponível em: <https://pt.wikipedia.

org/wiki/Mapeamento_objeto-relacional>. Acesso em: 20 dez. 2021.
72
ÁVILA, D. P. de. Sistema Gerenciador Para Um Salão De Beleza. 71 f. Monografia

(Graduação) — Fundação Universidade do Contestado, Concórdia, 2013.
APÊNDICES
74
APÊNDICE A – DOCUMENTAÇÃO DA API
DOCUMENTAÇÃO DA API DE COMUNICAÇÃO FRONTEND - BACKEND
A.1 SESSÕES
A.1.1 Criação de sessão
POST - base url/sessions

1 {
2 " email " : " novousuario@gmail . com " ,
3 " password " : " 1 2 3 4 5 6 "
4 }
Resposta
1 {
2 " user " : {
3 " id " : 1 7 ,
4 " name " : " Novo Usuario " ,
6 " barber " : false ,
7 " avatar " : null
8 },
9 " token " : " eyJhbGciOiJIUzI 1 NiIsInR 5 cCI 6 IkpXVCJ 9 . eyJpZCI 6
MTcsImlhdCI 6 MTY 0 MDYxMjU 0 OCwiZXhwIjoxNjQxMjE 3 MzQ 4 fQ .
wATUqNpBpdaiS 4 Dl - K 0 Hxn 0 LpDTMiOQgCKi 2 z 5 YcFF 8 "
10 }
A.2 USUÁRIOS
A.2.1 Criação de usuários
POST - base url/users

1 {
4 " password " : " 1 2 3 4 5 6 "
5 }
Resposta
75
1 {
2 " id " : 1 7 ,
5 " barber " : false
6 }
A.2.2 Atualização de usuários
PUT - base url/users

1 {
3 " email " : " novo_usuario@email . com " ,
4 " oldPassword " : " 1 2 3 4 5 6 " ,
5 " password " : " 1 2 3 4 5 6 7 " ,
6 " confirmPassword " : " 1 2 3 4 5 6 7 "
7 }
Resposta
1 {
2 " id " : 1 7 ,
4 " email " : " novo_usuario@email . com " ,
6 " avatar " : null
7 }
A.3 IMAGENS
A.3.1 Upload de imagens
POST - base url/images

1 {
2 " file " : " 1 0 5 6 7 8 B 4 -7 0 5 7 -4 3 7 9 -9 DA 5 -5 2 1 6 0 FD 3 3 8 8 4 . jpg "
3 }
Resposta
76
1 {
2 " url " : " http : // localhost : 3 3 3 3 / images / 2 6 1 3 0 4 2 5 8 9 1 b 9 d 6 0 ad 9 f 3 0
b 2 2 1 9 1 a 0 9 9 . jpg " ,
3 " id " : 7 ,
4 " name " : " 1 0 5 6 7 8 B 4 -7 0 5 7 -4 3 7 9 -9 DA 5 -5 2 1 6 0 FD 3 3 8 8 4 . jpg " ,
5 " path " : " 2 6 1 3 0 4 2 5 8 9 1 b 9 d 6 0 ad 9 f 3 0 b 2 2 1 9 1 a 0 9 9 . jpg " ,
6 " updatedAt " : " 2 0 2 2 -0 1 -1 2 T 0 1 : 3 2 : 3 7 . 6 0 0 Z " ,
7 " createdAt " : " 2 0 2 2 -0 1 -1 2 T 0 1 : 3 2 : 3 7 . 6 0 0 Z "
8 }
A.4 BARBEIROS
A.4.1 Criação de barbeiros
POST - base url/barbershops/26/barbers

1 {
2 " name " : " Barbeiro " ,
3 " email " : " barbeiro@gmail . com " ,
4 " password " : " 1 2 3 4 5 6 "
5 }
Resposta
1 {
2 " id " : 9 ,
3 " user " : {
4 " id " : 2 0 ,
5 " name " : " Barbeiro " ,
6 " email " : " barbeiro@gmail . com " ,
7 " avatar " : null
8 },
9 " barbershop " : {
10 " id " : 2 6 ,
11 " name " : " Novissima Barbearia "
12 }
13 }
A.4.2 Listagem de barbeiros
GET - base url/barbershops/25/barbers

77
Resposta
1 [
2 {
3 " id " : 6 ,
4 " user " : {
5 " id " : 7 ,
6 " name " : " Dougras " ,
7 " email " : " dougras@gmail . com " ,
8 " barber " : true ,
9 " avatar " : null
10 }
11 },
12 {
13 " id " : 7 ,
14 " user " : {
15 " id " : 1 5 ,
16 " name " : " Teco " ,
17 " email " : " teco@email . com " ,
18 " barber " : true ,
19 " avatar " : null
20 }
21 }
22 ]
A.4.3 Deleção de barbeiros
DELETE - base url/barbershops/26/barbers/9
Resposta
A requisição de sucesso apresenta apenas um código HTTP 200 como resposta.
A.5 AGENDAMENTOS
A.5.1 Criação de agendamentos
POST - base url/appointments

1 {
2 " date " : " 2 0 2 2 -0 1 -0 5 T 1 1 : 0 0 : 0 0 -0 3 : 0 0 " ,
3 " barber_id " : " 6 " ,
4 " barbershop_service_id " : " 1 " ,
78
5 " barbershop_id " : " 2 5 "

6 }
Resposta
1 {
2 " past " : false ,
3 " cancelable " : true ,
4 " id " : 5 1 ,
5 " date " : " 2 0 2 2 -0 1 -0 5 T 1 4 : 0 0 : 0 0 . 0 0 0 Z " ,
6 " service " : " Corte de cabelo " ,
7 " price " : 2 4 . 9 ,
8 " canceled_at " : null ,
9 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 6 8 7 Z " ,
10 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 6 8 7 Z " ,
11 " rating_id " : null ,
12 " barber " : {
13 " id " : 6 ,
14 " user " : {
15 " id " : 7 ,
19 }
20 },
22 " id " : 2 5 ,
23 " name " : " Maltadas Barbershop " ,
24 " address " : {
25 " id " : 4 ,
26 " street " : " Avenida S o Paulo " ,
27 " number " : " 3 5 8 4 " ,
28 " complement " : " Loja 2 " ,
29 " neighborhood " : " I t a p u " ,
30 " cep " : " 2 9 1 0 1 5 0 2 " ,
31 " city " : {
32 " id " : 1 ,
33 " city " : " Vila Velha " ,
34 " state " : {
35 " id " : 4 ,
79
36 " state " : " ES "

37 }
38 }
39 }
40 }
41 }
A.5.2 Listagem de agendamentos
GET - base url/appointments?page=1
Resposta
1 [
2 {
5 " id " : 5 1 ,
6 " date " : " 2 0 2 2 -0 1 -0 5 T 1 4 : 0 0 : 0 0 . 0 0 0 Z " ,
8 " price " : 2 4 . 9 ,
10 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 6 8 7 Z " ,
11 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 6 8 7 Z " ,
12 " barber " : {
13 " id " : 6 ,
14 " user " : {
15 " id " : 7 ,
19 }
20 },
22 " id " : 2 5 ,
24 " avatar " : {
25 " url " : " http : // localhost : 3 3 3 3 / images / 7 5 c 9 ca 3 2 6 f 5 1 d 7 3
fcd 6 fb 2 af 5 6 9 5 e 9 af . jpeg " ,
26 " id " : 5 ,
27 " path " : " 7 5 c 9 ca 3 2 6 f 5 1 d 7 3 fcd 6 fb 2 af 5 6 9 5 e 9 af . jpeg "
80
28 },
29 " address " : {
30 " id " : 4 ,
32 " number " : " 3 5 8 4 " ,
35 " cep " : " 2 9 1 0 1 5 0 2 " ,
36 " city " : {
37 " id " : 1 ,
39 " state " : {
40 " id " : 4 ,
41 " state " : " ES "
42 }
43 }
44 }
45 },
46 " rating " : null
47 }
48 ]
A.5.3 Deleção de agendamentos
DELETE - base url/appointments/51
Resposta
A.6 AGENDA
A.6.1 Listagem da agenda de um barbeiro
GET - base url/schedule?date=2022-01-05
Resposta
1 {
2 " appointments " : [
3 {
81

6 " id " : 5 1 ,
7 " date " : " 2 0 2 2 -0 1 -0 5 T 1 4 : 0 0 : 0 0 . 0 0 0 Z " ,
9 " price " : 2 4 . 9 ,
11 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 6 8 7 Z " ,
12 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 6 8 7 Z " ,
13 " rating_id " : null ,
14 " user_id " : 1 7 ,
15 " barber_id " : 6 ,
16 " barbershop_id " : 2 5 ,
17 " user " : {
18 " id " : 1 7 ,
21 }
22 }
23 ]
24 }
A.7 NOTIFICAÇÕES
A.7.1 Listagem de notificações
GET - base url/notifications
Resposta
1 [
2 {
3 " read " : false ,
4 " _id " : " 6 1 d 5 3 6 ba 3 9 fb 7 c 4 b 9 2 4 2 9 c 5 f " ,
5 " content " : " Novo agendamento de Novo Usuario para dia 0 5
de janeiro , s 1 1 : 0 0 h " ,
6 " user " : 7 ,
7 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 7 5 3 Z " ,
8 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 7 5 3 Z " ,
9 " __v " : 0
10 }
11 ]
82
A.7.2 Atualização de notificações
PUT - base url/notifications/61d536ba39fb7c4b92429c5f
Resposta
1 {
2 " read " : true ,
3 " _id " : " 6 1 d 5 3 6 ba 3 9 fb 7 c 4 b 9 2 4 2 9 c 5 f " ,
4 " content " : " Novo agendamento de Novo Usuario para dia 0 5 de
janeiro , s 1 1 : 0 0 h " ,
5 " user " : 7 ,
6 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 1 2 : 1 0 . 7 5 3 Z " ,
7 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 6 : 2 1 : 3 9 . 9 5 1 Z " ,
8 " __v " : 0
9 }
A.8 HORÁRIOS DISPONÍVEIS
A.8.1 Listagem de horários disponíveis
GET - base url/barbershops/25/barbers/6/available?date=1641444995554
Resposta
1 [
2 {
3 " time " : " 0 8 : 0 0 " ,
4 " value " : " 2 0 2 2 -0 1 -0 6 T 0 8 : 0 0 : 0 0 -0 3 : 0 0 " ,
5 " available " : true
6 },
7 {
8 " time " : " 0 8 : 3 0 " ,
9 " value " : " 2 0 2 2 -0 1 -0 6 T 0 8 : 3 0 : 0 0 -0 3 : 0 0 " ,
11 },
12 {
13 " time " : " 0 9 : 0 0 " ,
14 " value " : " 2 0 2 2 -0 1 -0 6 T 0 9 : 0 0 : 0 0 -0 3 : 0 0 " ,
16 },
17 {
18 " time " : " 0 9 : 3 0 " ,
83
19 " value " : " 2 0 2 2 -0 1 -0 6 T 0 9 : 3 0 : 0 0 -0 3 : 0 0 " ,

21 },
22 {
23 " time " : " 1 0 : 0 0 " ,
24 " value " : " 2 0 2 2 -0 1 -0 6 T 1 0 : 0 0 : 0 0 -0 3 : 0 0 " ,
26 },
27 {
28 " time " : " 1 0 : 3 0 " ,
29 " value " : " 2 0 2 2 -0 1 -0 6 T 1 0 : 3 0 : 0 0 -0 3 : 0 0 " ,
31 },
32 {
33 " time " : " 1 1 : 0 0 " ,
34 " value " : " 2 0 2 2 -0 1 -0 6 T 1 1 : 0 0 : 0 0 -0 3 : 0 0 " ,
36 },
37 {
38 " time " : " 1 1 : 3 0 " ,
39 " value " : " 2 0 2 2 -0 1 -0 6 T 1 1 : 3 0 : 0 0 -0 3 : 0 0 " ,
41 },
42 {
43 " time " : " 1 2 : 0 0 " ,
44 " value " : " 2 0 2 2 -0 1 -0 6 T 1 2 : 0 0 : 0 0 -0 3 : 0 0 " ,
46 },
47 {
48 " time " : " 1 2 : 3 0 " ,
49 " value " : " 2 0 2 2 -0 1 -0 6 T 1 2 : 3 0 : 0 0 -0 3 : 0 0 " ,
51 },
52 {
53 " time " : " 1 3 : 0 0 " ,
54 " value " : " 2 0 2 2 -0 1 -0 6 T 1 3 : 0 0 : 0 0 -0 3 : 0 0 " ,
56 },
57 {
84
58 " time " : " 1 3 : 3 0 " ,

59 " value " : " 2 0 2 2 -0 1 -0 6 T 1 3 : 3 0 : 0 0 -0 3 : 0 0 " ,
61 },
62 {
63 " time " : " 1 4 : 0 0 " ,
64 " value " : " 2 0 2 2 -0 1 -0 6 T 1 4 : 0 0 : 0 0 -0 3 : 0 0 " ,
66 },
67 {
68 " time " : " 1 4 : 3 0 " ,
69 " value " : " 2 0 2 2 -0 1 -0 6 T 1 4 : 3 0 : 0 0 -0 3 : 0 0 " ,
71 },
72 {
73 " time " : " 1 5 : 0 0 " ,
74 " value " : " 2 0 2 2 -0 1 -0 6 T 1 5 : 0 0 : 0 0 -0 3 : 0 0 " ,
76 },
77 {
78 " time " : " 1 5 : 3 0 " ,
79 " value " : " 2 0 2 2 -0 1 -0 6 T 1 5 : 3 0 : 0 0 -0 3 : 0 0 " ,
81 },
82 {
83 " time " : " 1 6 : 0 0 " ,
84 " value " : " 2 0 2 2 -0 1 -0 6 T 1 6 : 0 0 : 0 0 -0 3 : 0 0 " ,
86 },
87 {
88 " time " : " 1 6 : 3 0 " ,
89 " value " : " 2 0 2 2 -0 1 -0 6 T 1 6 : 3 0 : 0 0 -0 3 : 0 0 " ,
91 },
92 {
93 " time " : " 1 7 : 0 0 " ,
94 " value " : " 2 0 2 2 -0 1 -0 6 T 1 7 : 0 0 : 0 0 -0 3 : 0 0 " ,
96 },
85
97 {
98 " time " : " 1 7 : 3 0 " ,
99 " value " : " 2 0 2 2 -0 1 -0 6 T 1 7 : 3 0 : 0 0 -0 3 : 0 0 " ,
101 }
102 ]
A.9 HORÁRIOS DE FUNCIONAMENTO
A.9.1 Criação de horários de funcionamento
POST - base url/barbershops/26/operations

1 {
2 " weekday " : " segunda - feira " ,
3 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,
4 " closing_hour " : " 1 8 : 0 0 : 0 0 "
5 }
Resposta
1 {
3 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,
4 " closing_hour " : " 1 8 : 0 0 : 0 0 " ,
6 " id " : 2 6 ,
7 " name " : " Novissima Barbearia " ,
8 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 5 7 "
9 }
10 }
A.9.2 Listagem de horários de funcionamento
GET - base url/barbershops/26/operations
Resposta
1 [
2 {
3 " id " : 2 1 ,
86
5 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,

6 " closing_hour " : " 1 8 : 0 0 : 0 0 "
7 },
8 {
9 " id " : 2 2 ,
10 " weekday " : " t e r a - feira " ,
11 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,
12 " closing_hour " : " 1 8 : 0 0 : 0 0 "
13 },
14 {
15 " id " : 2 3 ,
16 " weekday " : " sexta - feira " ,
17 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,
18 " closing_hour " : " 1 8 : 0 0 : 0 0 "
19 },
20 {
21 " id " : 2 4 ,
22 " weekday " : " quinta - feira " ,
23 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,
24 " closing_hour " : " 1 8 : 0 0 : 0 0 "
25 }
26 ]
A.9.3 Atualização de horários de funcionamento
PUT - base url/barbershops/26/operations/23

1 {
2 " closing_hour " : " 2 3 : 0 0 : 0 0 "
3 }
Resposta
1 {
2 " id " : 2 3 ,
3 " opening_hour " : " 1 0 : 0 0 : 0 0 " ,
4 " closing_hour " : " 2 3 : 0 0 : 0 0 "
5 }
87
A.9.4 Deleção de horários de funcionamento
DELETE - base url/barbershops/26/operations/23
Resposta
A.10 BARBEARIAS
A.10.1 Criação de barbearias
POST - base url/barbershops

1 {
2 " name " : " Nova Barbearia " ,
3 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 5 7 " ,
4 " address_id " : 1 5
5 }
Resposta
1 {
2 " id " : 2 6 ,
4 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 5 7 " ,
5 " grade " : null ,
6 " createdAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 2 1 : 3 7 . 3 0 3 Z " ,
7 " updatedAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 2 1 : 3 7 . 3 0 3 Z " ,
8 " avatar_id " : null ,
9 " address " : {
10 " id " : 1 5 ,
11 " street " : " Rua nova " ,
12 " number " : " 1 2 3 4 " ,
13 " complement " : null ,
15 " cep " : " 2 9 1 0 1 6 1 0 " ,
16 " city " : {
17 " id " : 1 ,
19 " state " : {
20 " id " : 4 ,
21 " state " : " ES "
88
22 }
23 }
24 },
25 " User " : {
26 " id " : 1 7 ,
30 " avatar_id " : null
31 },
33 }
A.10.2 Listagem de barbearias
GET - base url/barbershops?page=1search
Resposta
1 [
2 {
3 " id " : 2 6 ,
6 " address " : {
7 " id " : 1 5 ,
9 " number " : " 1 2 3 4 " ,
12 " cep " : " 2 9 1 0 1 6 1 0 " ,
13 " city " : {
14 " id " : 1 ,
16 " state " : {
17 " id " : 4 ,
18 " state " : " ES "
19 }
20 }
21 },
89
23 },
24 {
25 " id " : 2 5 ,
27 " grade " : 4 ,
28 " address " : {
29 " id " : 4 ,
31 " number " : " 3 5 8 4 " ,
34 " cep " : " 2 9 1 0 1 5 0 2 " ,
35 " city " : {
36 " id " : 1 ,
38 " state " : {
39 " id " : 4 ,
40 " state " : " ES "
41 }
42 }
43 },
44 " avatar " : {
45 " url " : " http : // localhost : 3 3 3 3 / images / 7 5 c 9 ca 3 2 6 f 5 1 d 7 3 fcd
6 fb 2 af 5 6 9 5 e 9 af . jpeg " ,
46 " id " : 5 ,
48 }
49 },
50 {
51 " id " : 2 1 ,
52 " name " : " Barbearia do Lukinhas " ,
54 " address " : {
55 " id " : 1 1 ,
56 " street " : " Alameda Z " ,
57 " number " : " 6 3 " ,
59 " neighborhood " : " Interlagos " ,
60 " cep " : " 2 9 1 0 7 5 6 3 " ,
90
61 " city " : {

62 " id " : 1 ,
64 " state " : {
65 " id " : 4 ,
66 " state " : " ES "
67 }
68 }
69 },
71 }
72 ]
A.10.3 Atualização de barbearias
PUT - base url/barbershops/26

1 {
2 " name " : " Novissima Barbearia "
3 }
Resposta
1 {
2 " id " : 2 6 ,
4 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 5 7 " ,
6 " createdAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 2 1 : 3 7 . 3 0 3 Z " ,
7 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 3 : 3 5 : 3 8 . 7 0 0 Z " ,
8 " avatar_id " : null ,
9 " address " : {
10 " id " : 1 5 ,
12 " number " : " 1 2 3 4 " ,
15 " cep " : " 2 9 1 0 1 6 1 0 " ,
16 " city " : {
17 " id " : 1 ,
91
19 " state " : {

20 " id " : 4 ,
21 " state " : " ES "
22 }
23 }
24 },
25 " User " : {
26 " id " : 1 7 ,
30 " avatar_id " : null
31 },
33 }
A.10.4 Deleção de barbearias
DELETE - base url/barbershops/26
Resposta
A.10.5 Visualizar uma barbearia
GET - base url/barbershops/26
Resposta
1 {
2 " id " : 2 6 ,
4 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 5 7 " ,
6 " createdAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 2 1 : 3 7 . 3 0 3 Z " ,
7 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 3 : 3 5 : 3 8 . 7 0 0 Z " ,
8 " address " : {
9 " id " : 1 5 ,
11 " number " : " 1 2 3 4 " ,
92

14 " cep " : " 2 9 1 0 1 6 1 0 " ,
15 " city " : {
16 " id " : 1 ,
18 " state " : {
19 " id " : 4 ,
20 " state " : " ES "
21 }
22 }
23 },
25 }
A.11 ENDEREÇOS
A.11.1 Criação de endereços
POST - base url/addresses

1 {
3 " number " : " 1 2 3 " ,
5 " cep " : " 2 9 1 0 1 6 1 0 " ,
7 " state " : " ES "
8 }
Resposta
1 {
2 " id " : 1 5 ,
4 " number " : " 1 2 3 " ,
7 " cep " : " 2 9 1 0 1 6 1 0 " ,
8 " createdAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 0 0 : 0 7 . 3 5 1 Z " ,
9 " updatedAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 0 0 : 0 7 . 3 5 1 Z " ,
10 " city_id " : 1 ,
93
11 " city " : {

13 " state " : {
14 " state " : " ES "
15 }
16 }
17 }
A.11.2 Atualização de endereços
PUT - base url/addresses/15

1 {
2 " number " : " 1 2 3 4 "
3 }
Resposta
1 {
2 " id " : 1 5 ,
4 " number " : " 1 2 3 4 " ,
7 " cep " : " 2 9 1 0 1 6 1 0 " ,
8 " city " : {
9 " id " : 1 ,
11 " state " : {
12 " id " : 4 ,
13 " state " : " ES "
14 }
15 }
16 }
A.11.3 Deleção de endereços
DELETE - base url/addresses/10
Resposta

94
A.12 LISTAS DE ENDEREÇOS
A.12.1 Criação de lista de endereços
POST - base url/users/addresseslists

1 {
2 " address_id " : 1 0
3 }
Resposta
1 {
2 " id " : 7 ,
3 " user_id " : 1 7 ,
4 " address_id " : 1 0 ,
5 " updatedAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 0 9 : 5 0 . 6 9 6 Z " ,
6 " createdAt " : " 2 0 2 2 -0 1 -0 4 T 1 8 : 0 9 : 5 0 . 6 9 6 Z " ,
7 " main " : false
8 }
A.12.2 Visualizar lista de endereços
GET - base url/users/addresseslists
Resposta
1 [
2 {
3 " id " : 7 ,
4 " main " : false ,
5 " address " : {
6 " id " : 1 0 ,
7 " street " : " Alameda S " ,
8 " number " : " 6 9 " ,
11 " cep " : " 2 9 1 0 7 5 6 9 " ,
12 " city " : {
13 " id " : 1 ,
15 " state " : {
16 " id " : 4 ,
95
17 " state " : " ES "

18 }
19 }
20 }
21 }
22 ]
A.12.3 Atualização de lista de endereços
PUT - base url/users/addresseslists/7

1 {
2 " main " : true
3 }
Resposta
1 {
2 " id " : 7 ,
3 " main " : true ,
4 " address " : {
5 " id " : 1 0 ,
6 " street " : " Alameda S " ,
7 " number " : " 6 9 " ,
10 " cep " : " 2 9 1 0 7 5 6 9 " ,
11 " city " : {
12 " id " : 1 ,
14 " state " : {
15 " id " : 4 ,
16 " state " : " ES "
17 }
18 }
19 }
20 }
96
A.13 FAVORITOS
A.13.1 Criação de favoritos
POST - base url/favorites

1 {
2 " barbershop_id " : 2 5
3 }
Resposta
1 {
2 " id " : 9 ,
4 " id " : 2 5 ,
6 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 1 2 " ,
7 " grade " : 4 ,
8 " address_id " : 4 ,
9 " owner " : 1 ,
10 " avatar_id " : 5 ,
11 " avatar " : {
12 " url " : " http : // localhost : 3 3 3 3 / images / 7 5 c 9 ca 3 2 6 f 5 1 d 7 3 fcd
6 fb 2 af 5 6 9 5 e 9 af . jpeg " ,
13 " id " : 5 ,
15 }
16 }
17 }
A.13.2 Listagem de favoritos
GET - base url/favorites
Resposta
1 [
2 {
3 " id " : 9 ,
5 " id " : 2 5 ,
97
7 " cnpj " : " 1 2 3 3 3 3 3 3 4 4 4 4 1 2 " ,

8 " grade " : 4 ,
9 " address_id " : 4 ,
10 " owner " : 1 ,
11 " avatar_id " : 5 ,
12 " avatar " : {
13 " url " : " http : // localhost : 3 3 3 3 / images / 7 5 c 9 ca 3 2 6 f 5 1 d 7 3
fcd 6 fb 2 af 5 6 9 5 e 9 af . jpeg " ,
14 " id " : 5 ,
16 }
17 }
18 }
19 ]
A.13.3 Deleção de favoritos
DELETE - base url/favorites/9
Resposta A requisição de sucesso apresenta apenas um código HTTP 200 como resposta.
A.14 AVALIAÇÕES
A.14.1 Criação de avaliações
POST - base url/ratings

1 {
2 " appointment_id " : 5 0 ,
3 " grade " : 5 ,
4 " comment " : " Atendimento muito bom !!!"
5 }
Resposta
1 {
2 " id " : 2 2 ,
3 " user_id " : 8 ,
5 " grade " : 5 ,
6 " comment " : " Atendimento muito bom !!!" ,
7 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 4 : 4 1 : 2 9 . 4 3 4 Z " ,
98
8 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 4 : 4 1 : 2 9 . 4 3 4 Z "

9 }
A.14.2 Listagem de avaliações de uma barbearia
GET - base url/ratings/25
Resposta
1 [
2 {
3 " id " : 2 1 ,
4 " grade " : 4 ,
5 " comment " : " Muito boa !" ,
6 " createdAt " : " 2 0 1 9 -1 1 -0 2 T 0 3 : 3 2 : 3 9 . 5 2 2 Z " ,
7 " user " : {
8 " name " : " Magno " ,
9 " avatar " : null
10 }
11 },
12 {
13 " id " : 2 0 ,
14 " grade " : 4 ,
15 " comment " : null ,
16 " createdAt " : " 2 0 1 9 -1 1 -0 2 T 0 3 : 3 2 : 0 3 . 9 5 3 Z " ,
17 " user " : {
18 " name " : " Magno " ,
20 }
21 }
22 ]
A.15 SERVIÇOS DE BARBEARIAS
A.15.1 Criação de serviços para uma barbearia
POST - base url/barbershops/26/services

1 {
2 " service_id " : 2 ,
3 " price " : 1 5 . 9 5
4 }
99
Resposta
1 {
2 " id " : 5 ,
3 " service_id " : 2 ,
4 " price " : 1 5 . 9 5 ,
6 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 4 : 0 7 : 0 0 . 1 7 3 Z " ,
7 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 4 : 0 7 : 0 0 . 1 7 3 Z "
8 }
A.15.2 Listagem de serviços de uma barbearia
GET - base url/barbershops/26/services
Resposta
1 [
2 {
3 " id " : 5 ,
4 " price " : 1 5 . 9 5 ,
5 " Service " : {
6 " name " : " Aparar barba "
7 }
8 }
9 ]
A.15.3 Atualização de serviços de uma barbearia
PUT - base url/barbershops/26/services/5

1 {
2 " price " : 2 0
3 }
Resposta
1 {
2 " id " : 5 ,
3 " price " : 2 0 ,
4 " createdAt " : " 2 0 2 2 -0 1 -0 5 T 0 4 : 0 7 : 0 0 . 1 7 3 Z " ,
5 " updatedAt " : " 2 0 2 2 -0 1 -0 5 T 0 4 : 1 0 : 2 8 . 6 8 6 Z " ,
100
7 " service_id " : 2

8 }
A.15.4 Deleção de serviços de uma barbearia
DELETE - base url/barbershops/26/services/5
Resposta A requisição de sucesso apresenta apenas um código HTTP 200 como resposta.

TCC Desenvolvimento de Um Sistema Agregador de Barbearias

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Desenvolvimento de Um Sistema Agregador de Barbearias

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO FEDERAL DO ESPÍRITO SANTO

CURSO SUPERIOR DE SISTEMAS DE INFORMAÇÃO

EWERSON VIEIRA NASCIMENTO

DESENVOLVIMENTO DE UM SISTEMA AGREGADOR DE BARBEARIAS

DESENVOLVIMENTO DE UM SISTEMA AGREGADOR DE BARBEARIAS

Trabalho de Conclusão de Curso apresentado à

Orientador: Prof. Me. Daniel Ribeiro Trindade

N244d Nascimento, Ewerson Vieira

Orientador: Prof. Me. Daniel Ribeiro Trindade.

1. Software de aplicação – Desenvolvimento. 2. Aplicações Web.

Bibliotecária Rogeria Gomes Belchior - CRB6/ES 417

DESENVOLVIMENTO DE UM SISTEMA AGREGADOR DE BARBEARIAS

Trabalho de Conclusão de Curso apresentado

Aprovado em 11 de fevereiro de 2022.

FOLHA DE APROVAÇÃO-TCC Nº 1/2022 - SER - CCTMSI (11.02.32.01.08.02.09)

(Nº do Protocolo: NÃO PROTOCOLADO)

(Assinado digitalmente em 11/02/2022 14:43 ) (Assinado digitalmente em 11/02/2022 12:25 )

(Assinado digitalmente em 11/02/2022 13:59 )

Para verificar a autenticidade deste documento entre em https://sipac.ifes.edu.br/documentos/ informando seu

Palavras-chave: Barbearia. React. Node.js.

Keywords: Barbershop. React. Node.js.

Figura 1 – Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.1 DEFINIÇÃO DO PROBLEMA

Para o desenvolvimento de uma aplicação para gerencimento de horários em uma barbearia,

1.2.1 Objetivo geral

O objetivo deste trabalho é produzir um software agregador de barbearias para geren-

1.2.2 Objetivos específicos

• Mapear barbearias e suas informações sobre os horários de funcionamento, serviços e

• Possibilitar que consumidores realizem agendamentos de horários nas barbearias;

• Permitir que os consumidores avaliem as barbearias após utilizarem seus serviços;

• Permitir que barbeiros dos estabelecimentos cadastrados gerenciem suas agendas;

• Permitir que os donos de estabelecimentos cadastrem e gerenciem suas barbearias.

1.3 ESTRUTURA DO TRABALHO

Para a realização deste trabalho, faz-se necessário o entendimento de três áreas do

2.1 ENGENHARIA DE SOFTWARE

A engenharia de software é uma disciplina da informática que se ocupa de todos os aspectos

2.1.1 Diagrama de casos de uso

Figura 1 – Diagrama de caso de uso

No diagrama presente na Figura 11 é observado que no sistema do restaurante em questão

2.1.2 Diagrama de classes

Figura 2 – Diagrama de classes

Na Figura 22 observamos como um diagrama de classes é formado, com os retângulos

2.1.3 Requisitos funcionais

2.1.4 Requisitos não funcionais

Utilizados para definir restrições e limitações no desenvolvimento dos sistemas, os requisitos

2.1.5 Model-View-Controller ou MVC

Fonte: Medium - Leonardo Vilarinho

A Figura 33 mostra o funcionamento desse tipo de arquitetura, onde o usuário realiza as

2.2 DESENVOLVIMENTO WEB

Ao desenvolvimento web é conferida a responsabilidade de elaborar e codificar páginas

2.2.1 Protocolo HTTP

• GET, para solicitar algum dado específico.

• PUT, utilizado para alterar ou substituir uma instância de um recurso.

• DELETE, utilizado para remover um recurso específico da base de dados.

Figura 4 – Requisição HTTP

Fonte: Elaborado pelo autor (2021)

A Figura 4, obtida utilizando o software Insomnia4 , mostra o exemplo de uma requisição

requisição e, em caso de sucesso, retorna as informações do usuário logado e seu token de

Assim como o protocolo HTTP, o frontend e o backend evoluíram ao longo do tempo.

O frontend é a parte da aplicação responsável pelos componentes com que o usuário

Existem diversas bibliotecas e frameworks JavaScript no mercado a fim de apoiar o

A escolha do React neste trabalho se deu, principalmente, por conta da reutilização de

Figura 5 – React Native

Fonte: Meta Platforms, Inc.