1

Atividade Prática Supervisionada (APS)

Rede de computadores – Desenvolvimento de uma
ferramenta para comunicação em rede
São Paulo, 2020

Ciência da Computação – Pinheiros - Noturno

Douglas Ferreira Alves RA: N318CB0

Gabriel Ramos dos SantosRA: N269CE4
 2

Lucas Oliveira Novais de Araújo RA: N302CG8

Jefferson Gomes da Silva RA: D67HED2
João Victor Oliveira Camacho RA: D581651 

Sumário
Objetivo do trabalho............................................................................................................ 4
Introdução........................................................................................................................... 5
Contextualização sobre tarefa ambiental abordada no projeto aplicada à plataforma
desenvolvida....................................................................................................................... 5
Exemplos de utilização da plataforma.................................................................................6
Fundamentos da comunicação de dados em rede..............................................................7
TCP/IP................................................................................................................................ 7
Soquetes de Berkeley.......................................................................................................10
Arquitetura cliente/servidor................................................................................................11
Tecnologias utilizadas...................................................................................................13
Banco de dados................................................................................................................13
Linguagem de programação – Backend............................................................................14
Linguagem de programação - Frontend............................................................................14
Plano de desenvolvimento da aplicação...........................................................................15
Metodologia agile..............................................................................................................15
Conceito............................................................................................................................ 15
Indivíduos e iterações mais que processos e ferramentas................................................16
Software funcional mais que documentação abrangente..................................................16
Colaboração do cliente mais que negociação de contratos...............................................16
Responder a mudanças mais que seguir um plano...........................................................16
Módulos do projeto........................................................................................................ 17
Divisão das iterações (sprints)..........................................................................................17
Divisão das iterações (sprints)..........................................................................................17
Cronograma de execução.................................................................................................19
Administração do processo...............................................................................................20
Projeto: Estrutura do programa......................................................................................22
Arquitetura de módulos a serem desenvolvidos................................................................22
 3

Diagrama entidade relacionamento (DER)....................................................................24

O Banco de dados Firebase Realtime Database...........................................................24
Diagrama de classe.......................................................................................................25
O Modelo Entidade-Relacionamento e o NoSQL..............................................................26
Design........................................................................................................................... 30
Logo.................................................................................................................................. 30
Aplicação........................................................................................................................... 30
Nome................................................................................................................................ 30
Paleta de cores................................................................................................................. 30
Protótipos...................................................................................................................... 31
Iniciar sessão.................................................................................................................... 31
Página Inicial..................................................................................................................... 33
Usuários............................................................................................................................ 36
Diagramas de casos de uso..........................................................................................36
Usuário Comum:............................................................................................................... 38
Usuário Administrador:......................................................................................................38
Relatório com as linhas de código do programa............................................................39
Referências bibliográficas.................................................................................................40
Ficha de Atividades Práticas Supervisionadas..................................................................41
 4

Objetivo do trabalho

O objetivo da aplicação desenvolvida neste projeto é divulgar os crimes

ambientais e suas consequências que ocorrem no território Brasileiro.
Utilizaremos uma estrutura que permitirá que esses crimes ou suas
consequências ambientais sejam reportadas por uma plataforma semelhante à Rede
Social, que permitirá os usuários inserirem imagens e/ou vídeos no feed da
plataforma, podendo descrever o fato identificado. Para facilitar a identificação sobre
a notícia/relato a ser postada criamos uma estrutura de Tags (Estrutura de
marcação), onde permite o usuário classificar em qual categoria sua postagem se
encaixa.
Essas informações podem ser aplicadas no dia a dia das pessoas, visando
aplicar boas práticas e a boa convivência entre o ser humano e o meio ambiente,
podendo também servir de fonte de informação para transmissão aos órgãos
responsáveis sobre que acontece no Meio Ambiente e que nem sempre é divulgado
pela mídia.
Os usuários também poderão utilizar a aplicação para se comunicar
diretamente com algum contato (Usuário que utiliza o sistema) através de um Chat,
no objetivo de direcionar qualquer informação pertinente ao contexto de crimes
ambientais que ocorrem no dia a dia.
Em resumo, os principais objetivos desta plataforma se baseiam em colher
informações e transmitir de formas eficaz ao público, podendo ser classificada como
uma “Rede social ambiental”, o que auxilia o combate contra esses crimes
ambientais.
 5

Introdução

Contextualização sobre tarefa ambiental abordada no projeto aplicada à plataforma

desenvolvida
O meio ambiente é um tema muito abordado pelo mundo em todas suas
vertentes, neste trabalho estamos focados nos crimes ambientais que ocorrem pelo
Brasil, abordando principalmente suas consequências e como divulga-las para uma
ação mais eficaz.
Ao longo da história, existem inúmeros episódios trágicos envolvendo crimes
ambientais no Brasil e no Mundo, que exemplificam a importância da aplicação das
leis ambientais e suas penalidades inclusas a este tipo de crime.
Em 13/02/1998 foi criada a lei de Nº 9.605 – Lei de Crimes Ambientais, ou
Lei da Natureza, que tem como principais objetivos combater todo e qualquer tipo
de crime cometido pelo ser humano contra os componentes do meio ambientes
(Fauna, Flora, recursos naturais, patrimônio cultural). Podemos considerar Crimes
ambientais todos os tipos de agressões que ultrapassam os limites que a lei citada
acima estabelece, ou até mesmo condutas que ignoram as normas ambientais
estabelecidas, utilizando o exemplo dos gases poluentes emitidos pelos veículos
automotores que estejam fora das normas estabelecidas.
O que se percebe facilmente é que a simples penalização gerada pela Lei
não basta, uma vez que os danos ambientais causados por estes crimes acarretam
inúmeras consequências, não só ao meio adjacente, mas a toda população
próximas das áreas afetadas.
No fim desta introdução terá alguns exemplos de desastres em que o Ser Humano teve algum
tipo de ação na causa.

Partindo deste princípio, desenvolvemos uma plataforma que permite unir

postagens criadas pelos próprios usuários, que pode gerar uma conscientização
pública sobre o assunto e sua preservação, utilizando uma estrutura muito
semelhante a uma Rede Social (Twitter, Facebook), onde as pessoas possuem
familiaridade e facilidade na utilização. Uma plataforma que os usuários podem
classificar por Tags (Estrutura de marcação/Etiqueta) as postagens criadas, alguns
exemplos de Tags que podemos utilizar:
#habitat, #nicho ecológico, #reciclagem, #mudanças climáticas, #espécies
animais, #poluição.
 6

Tendo assim o reconhecimento da importância dos recursos ambientais.

Além disso podemos fazer a propagação de informações ecológicas para todos os
usuários que usarem a plataforma.
Essas informações podem ser aplicadas no dia a dia das pessoas, visando
aplicar boas práticas e a boa convivência entre o ser humano e o meio ambiente.
Em resumo, os principais objetivos desta plataforma se baseiam em colher
informações e transmitir de formas eficaz ao público e aos órgãos responsáveis de
acordo com a denúncia dentro da Tag.

Exemplos de utilização da plataforma

Abaixo demonstramos de forma resumida dois desastres ambientais que
podem ser julgados como crimes ambientais, todos os fatos abaixo poderiam ser
divulgados pela nossa plataforma, divulgando os locais e/ou seres que foram
afetados por tal desastre e suas respectivas consequências.

 Rompimento da barragem em Mariana, 2015.

https://img.r7.com/images/2016/02/25/5r5e39p7wi_4s2327aee4_file?dimensions=460x305
1https://jornalismosocioambiental.files.wordpress.com/
2016/03/12321416_1061750913864251_8128724941793527854_n.jpg?
w=1400
Mais de três anos após a tragédia ainda é
possível visualizar algumas consequências do desastre, exemplos:
• População de outras cidades afetados pela lama da barragem, sofrendo com
efeitos na contaminação da água dos rios por metais pesados, que a tornavam
imprópria para consumo, podendo causar doenças respiratórias e de pele.
• Este desastre impactou diretamente a vida aquática, onde ocorreu morte de
milhares de peixes por falta de oxigênio na água e de obstrução de suas brânquias,
além de peixes também houve diversos seres vivos mortos, que destruiu
completamente a cadeia alimentar nos ambientais atingidos
 7

 Incêndio no Amazonas

Os

https://conteudo.imguol.com.br/c/noticias/bb/2019/08/19/ceu-escuro-em-sao-paulo- https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcR5DgKWgR9py1eoDXT-
1566244250745_v2_1920x1280.jpg UsIFRQn4ZhTceCaSi1npTStwgqU98gHl&usqp=CAU

incêndios que ocorrem no Amazonas

são muitas vezes provocados pelo desmatamento causado pelo Homem, sendo
ligadas ao período de seca, sendo o ocorrido no ano de 2019 uma exceção, visto
que a seca não estava severa como se mostra a história.
Na imagem da Direita (acima) é possível identificar o quanto as fumaças
geradas pelo incêndio se alastraram pela América do Sul.
Na imagem da Esquerda (acima) é possível visualizar o céu de SP em plena
tarde sofrendo das consequências geradas por esse incêndio.
Os três maiores impactos imediatos das queimadas:
• Perdas de biodiversidade: vegetações e animais sofrem em
decorrência das queimadas;
• Perdas da qualidade do solo: terra menos fértil e gradualmente mais
frágil;
• Problemas de saúde: tendência ao aumento de casos de doenças
respiratórias nas cidades próximas a queimadas.

Fundamentos da comunicação de dados em rede

TCP/IP

O TCP/IP seria um conjunto de protocolos de comunicação entre

computadores em rede.
 8

Seu nome vem de dois protocolos: o TCP (Transmission Control Protocol -

Protocolo de Controle de Transmissão) e o IP (Internet Protocol - Protocolo de
Interconexão).

Camadas pertencentes ao TCP/IP.

O conjunto de protocolos pode ser visto como um modelo de camadas

(demonstradas visualmente acima), onde cada camada é responsável por um grupo
de tarefas, fornecendo um conjunto de serviços bem definidos para o protocolo da
camada superior.
As camadas mais altas estão logicamente mais perto do usuário, citando o
exemplo da camada de aplicação, sendo comum encontrar protocolos conhecidos,
exemplos: SMTP (e-mail), FTP (transferência de arquivos) e HTTP (navegar na
internet), também lidam com dados mais complexos, confiando em protocolos de
camadas mais baixas para tarefas de menor nível de complexidade, abaixo
podemos entender um pouco do que cada camada é responsável:
Depois de processar a requisição, a camada de aplicação se comunica com
a camada de transporte utilizando o TCP, esta camada coleta o dado enviado pela
camada de aplicação, sendo responsável por dividir estes dados em pacotes para
enviar a camada inferior em ordem, garantir também que os conteúdos dos pacotes
estão intactos. O TCP é um protocolo da camada de transporte confiável em que
existe a garantia que os dados são integralmente transmitidos para os hosts de
destino corretos na sequência pelo qual foram enviados.
A utilização do checksum (código utilizado para verificar a integridade de
dado transmitido através de um canal) permite muitas vezes no host de destino
recuperar informação em caso de erros simples na transmissão (nos casos da rede
corromper o pacote). Caso a informação seja impossível de recuperar ou o pacote
TCP/IP se tenha perdido durante a transmissão, é tarefa do TCP voltar a transmitir o
pacote. Após isso o pacote é enviado para a camada inferior (interface de rede),
quando os dados chegam nesta camada são chamados de datagramas.
 9

A Interface de Rede vai pegar os pacotes enviados pela camada de Internet

e enviar através da rede ou receber da rede, se o computador em questão estiver
recebendo dados. O conteúdo desta camada depende da rede utilizada, hoje em dia
o tipo de rede mais utilizado para comunicação entre computadores é a Ethernet que
possui inúmeras velocidades e pode ser cabeada (cabo de par trançado CAT5 ou
CAT6) ou WI-FI (sem fio).
Ainda dentro da camada de Interface de Rede Ethernet, é possível encontrar
camadas Ethernet como a LLC (Logic Link Control), MAC (Media Access Control) e
a Física que é o meio físico (cabo por exemplo). Os pacotes transmitidos através da
rede são chamados de quadros.
O Protocolo IP é responsável pela comunicação entre hosts em redes
TCP/IP. Ele é responsável pela comunicação entre cada elemento da rede para
permitir o transporte de uma mensagem de um host de origem até a um host de
destino, assim o datagrama passa por várias sub-redes (a origem e o destino são
hosts identificados por endereços IP). O protocolo IP é não-confiável, sendo está
uma responsabilidade dos protocolos das camadas superiores, nomeadamente do
TCP. Assim, não é utilizado nenhum mecanismo de controlo de fluxo ou de controlo
de erros de dados, verificando-se apenas, através de um checksum a integridade do
cabeçalho de forma a garantir que os gateways encaminhem corretamente os
datagramas.
As funções mais importantes realizadas pelo protocolo IP são a atribuição de
um esquema de endereçamento independente do endereçamento da rede utilizada
e independente da própria topologia da rede, além da capacidade de rotear e tomar
decisões de roteamento para o transporte das mensagens entre os elementos que
interligam as redes. para preencher a necessidade de comunicação entre um grande
número de sistemas de computadores e várias organizações militares dispersas.
O objetivo do projeto do TCP/IP era disponibilizar links (vínculos) de
comunicação com alta velocidade, utilizando redes de comutação de pacotes. O
protocolo deveria ser capaz de identificar e encontrar a melhor rota possível entre
dois sites (locais), além de ser capaz de procurar rotas alternativas para chegar ao
destino, caso qualquer uma das rotas tivesse sido destruída.
O objetivo principal da elaboração de TCP/IP foi na época, encontrar um
protocolo que pudesse tentar de todas as formas uma comunicação caso ocorresse
 10

uma guerra nuclear. A partir de 1972 o projeto ARPANET começou crescer em uma
comunidade internacional e hoje se transformou no que conhecemos como Internet.
O protocolo TCP/IP, atualmente é o protocolo mais usado em redes locais.
Isso deve-se basicamente à popularização da Internet, a rede mundial de
computadores.
Abaixo temos alguns dos benefícios do protocolo TCP/IP:
• Padronização: Como o próprio nome já diz, determina um padrão de
um protocolo que é o mais completo e aceito protocolo disponível atualmente, todos
os sistemas operacionais modernos oferecem suporte para este protocolo, e boa
parte das grandes redes se baseiam em TCP/IP para a maior parte de seu tráfego.
• Roteamento: Basicamente permite tecnologias mais antigas e novas se
conectarem à internet. Trabalha com protocolos de linha como P2P (point to point
protocol), permitindo conexão remota a partir de linha discada ou dedicada.
• Interconectividade: Tecnologia responsável por conectar sistemas não
similares, o FTP e Telnet utilizam desta tecnologia.
• Protocolo Robusto: escalável, multiplataforma, com estrutura para ser
utilizada em SO cliente/servidor, permitindo a utilização de aplicações desse porte
entre dois pontos distantes.
• Internet: É através dos protocolos TCP/IP que obtemos acesso a
internet, basicamente: As redes locais distribuem servidores de acesso a internet
(proxy servers) e os hosts locais se conectam a estes servidores para obter o acesso
à internet.

Soquetes de Berkeley
Soquetes Berkeley originou com o 4.2BSD Unix sistema operacional
(lançado em 1983), como uma única interface de programação. Só em 1989, no
entanto, poderia UC Berkeley versões de lançamento de seu sistema operacional e
de rede biblioteca livre das restrições de licenciamento.
Na computação, um Socket é utilizado em ligações de redes de
computadores para uma conexão bidirecional de comunicação entre dois
programas. A interface padronizada de sockets surgiu originalmente no sistema
operacional Unix BSD (Berkeley Software Distribution), desenvolvidos para
aplicações Cliente / Servidor, aonde Cliente e Servidor pode, estar em máquinas
diferentes, havendo uma comunicação através de protocolos de transportes,
 11

fazendo com que quando o aplicativo interagir com o software de protocolo, ele deve
informar se o mesmo é um cliente ou um servidor.
Um Socket por sua vez é uma abstração computacional que mapeia
diretamente a uma porta de transporte, através dos protocolos TCP ou UDP, e mais
um endereço de rede. Os Sockets, por sua vez, se abstraem e conseguem usar
qualquer um dos meios TCP ou UDP já citados acima. Com esse conceito, é
possível identificar unicamente um aplicativo ou servidor na rede de comunicação IP.
Em documentos de RFC (Request for Comments) relacionado a TCP, um
socket em um computador é definido como a combinação de um endereço IP, um
protocolo, e o número da porta do protocolo.
Sockets e RPCs têm a função de implementar numa aplicação as funções
de rede, mas fazem de formas diferentes.
A aplicação cliente utiliza a porta ‘portC’ da máquina ‘hostC’ para enviar
solicitações de serviços e para receber retornos a suas solicitações. A aplicação
servidora visualiza constantemente a porta ‘portS’ da máquina ‘hostS’ aguardando a
chegada de solicitações de serviço. Quando alguma solicitação é recebida, a
aplicação servidora executa o serviço e utiliza a conexão para enviar o retorno com
os resultados do serviço
Os "sockets" de Berkeley são uma API genérica para programação sobre
protocolos de comunicação. A implementação das system-calls desta interface é
"standard" em todos os sistemas operativos UNIX e estende-se também a muitas
outras plataformas.
Dentro do possível é mantida a semântica associada aos descritores de
ficheiros (io.h), os descritores são números inteiros usados para facultar o acesso a
controle das comunicações embebido no núcleo e são aqui conhecidos por
"sockets".

Arquitetura cliente/servidor
A tecnologia cliente/servidor é uma arquitetura na qual o processamento
da informação é dividido em módulos ou processos diferentes. Um processo é
responsável pela manutenção da informação (servidores) e outros responsáveis pela
obtenção dos dados (os clientes).
 12

Os processos cliente enviam pedidos para o processo servidor, e este por

sua vez processa e envia os resultados dos pedidos.

É no servidor que normalmente ficam os sistemas mais pesados da rede,

tais como o banco de dados. As máquinas clientes são menos poderosas, pois não
rodam aplicativos que requerem tantos recursos das máquinas.

Assim a aplicação seria utilizada no seguinte exemplo: O cliente faz um

pedido para o servidor pelo seu endereço IP e à porta que designa um serviço
específico do servidor. Em seguida, o servidor recebe o pedido e responde com a
ajuda do endereço da máquina cliente e de sua porta.
O modelo cliente-servidor foi desenvolvido na Xerox PARC durante os anos
70. Este modelo é atualmente o predominante nas redes informáticas.
Uma das vantagens para se usar o modelo cliente/servidor é para redes que
requerem um grande nível de confiança com as seguintes vantagens: recursos
centralizados, já que o servidor está no centro da rede, ele pode gerenciar recursos
comuns a todos os usuários, por exemplo, um banco de dados a fim de evitar os
problemas de redundância e contradição. Esse modelo oferece também maior
segurança pois o número de pontos de entrada que permitem o acesso aos dados é
menor, o gerenciamento do servidor e uma rede evolutiva. Graças a esta arquitetura,
é possível remover ou adicionar clientes sem perturbar o funcionamento da rede.
No entanto, a arquitetura cliente/servidor tem alguns resquícios, entre as
quais o custo elevado, o servidor é o único elo fraco da rede cliente/servidor, já que
toda a rede está estruturada em função dele. Felizmente, o servidor tem uma grande
tolerância a avarias, principalmente graças ao sistema RAID (Mecanismo criado com
o objetivo de melhorar o desempenho e segurança dos discos rígidos existentes em
 13

um PC, no quesito segurança os HDs extras são utilizados com a função de

espelhamento).
E Também os Clientes podem solicitar serviços, mas não podem oferecê-los
para outros clientes, sobrecarregando o servidor, pois quanto mais clientes, maior a
quantidade de informações que irão demandar mais banda.

Tecnologias utilizadas

Banco de dados

Para o banco de dados levamos em consideração que estaríamos

trabalhando com uma aplicação que possuiria um chat com o envio e recebimento
de arquivos e áudios. Considerando também que seria preciso manter a velocidade
no upload e download das informações de mensagens e arquivos, determinamos
que o uso de um banco NoSQL baseada na coleção de objetos, seria a ideal.
A estrutura NoSQL, como o próprio nome já diz, exclui o relacionamento
entre tabelas e as regras já conhecidas do paradigma SQL por outras estruturas que
armazenam essas informações, a fim de impulsionar a performance e velocidade na
coleta dessas informações. Uma das estruturas usadas nos modelos NoSQL são as
coleções de JSON (JavaScript Object Notation), que possuem o padrão “key
(chave)”: “value (valor)” em seus índices. Essa estrutura consome pouco espaço de
armazenamento na base de dados e aumenta a velocidade do download dessas
informações.
Sendo assim, como precisaríamos de velocidade para o envio e recebimento
das mensagens, além de ter a possibilidade de existir arquivos em trechos da
conversa o uso dessa estrutura iria nos beneficiar nesse projeto.

Linguagem de programação – Backend

Ao usar a terminologia backend estamos nos referindo a linguagem utilizada
na parte do sistema que será executada no servidor, separada da máquina do
cliente contendo regras de negócios e processos que exigem muitas vezes mais
processamento.
 14

Sendo assim, a decisão da linguagem

para o backend partiu da pesquisa das
bibliotecas de sockets das linguagens e umas
das recomendações que tivemos, inclusive com
uma aplicação de chat, foi a NodeJS, que seria
o javascript aplicado ao uso do servidor. Ela
trabalha bem com comunicação assíncrona, o que no caso de uma aplicação de
arquitetura cliente servidor é muito útil, e com bancos não relacionais. Dessa forma
ganharíamos performance tanto na escolha do banco quando na linguagem de
programação.

Linguagem de programação - Frontend

Frontend, por sua vez, é a terminologia usada para a parte do
sistema/aplicação que será executada do lado do cliente, normalmente já contendo
todas as telas do sistema e a navegação desenvolvida para elas.
No frontend do sistema desenvolvido
optamos por usar React, uma biblioteca
Javascript que permite a construção de SPAs
por meio de componentes, que agem de forma
independente, mas podem trabalhar juntos na
construção de um sistema e apresentar
resultados incríveis.
SPA significa “Single Page Application”, que seriam sistemas construídos
sem a percepção mudança de página pelo usuário ou então sem a necessidade da
abertura de novas abas do navegador, o que proporciona o aumento da
permanência do usuário dentro do sistema e a melhor experiencia de usuário (UX).
Esse conceito de SPA é utilizado na web no Facebook, Instagram, Twitter entre
outros casos que adotaram.
Com a possibilidade de ter componentes independentes e a vantagem da
construção de um sistema SPA, além da familiaridade da biblioteca por parte da
equipe, o uso dela parecia trazer grandes vantagens.
 15

Plano de desenvolvimento da aplicação

A princípio, para que a entrega do MVP do projeto pudesse ser feita sem
maiores problemas e com o mínimo de imprevistos no caminho, o grupo optou por
adotar a metodologia Agile ao decorrer do projeto. Uma vez que o uso dessa
metodologia possibilita, resumidamente, a divisão do projeto como um todo em
pequenas partes, agilizando a entrega e proporcionando maior engajamento do
time/grupo.

Metodologia agile

Conceito
Ao longo do desenvolvimento de um projeto vários pontos devem ser
levados em consideração. Esses pontos podem ser internos ao projeto, como
conhecimento técnica da equipe, quanto externos ao mesmo que influenciam
diretamente nele, como a legislação que é alterada e nessa alteração mudar
completamente a regra de negócio que o projeto visa atender.
Com isso em mente, imaginemos o desenvolvimento de um sistema que foi
estipulado um tempo total de 8 meses para sua entrega. O usuário reunia-se com a
equipe de analistas onde os requisitos do projeto eram levantados e a partir deles o
desenvolvimento era iniciado, e só depois de 8 meses o cliente tinha contato com o
produto que ele solicitou. Pensemos que se tratando da área de tecnologia em 8
meses muita coisa pode acontecer, a regra de negócio pode ter mudado, a estrutura
para implantação do sistema pode ter sido alterada, não era bem aquilo que o
cliente imaginava, dentre outros cenários ruins. Pensando em aplicativos como
Nubank, Ifood, Uber a situação se agrava ainda mais, quando a equipe está
correndo contra o tempo para entregar a solução antes de seus concorrentes.
Com esse cenário e dores passadas durante o processo de
desenvolvimento, membros influentes da comunidade de desenvolvimento reuniram-
se em Snowbird em 2001 e publicaram o Manifesto Ágil, documento que agrupa os
princípios e práticas desta metodologia de desenvolvimento. A partir deste manifesto
fundou-se a Agile Alliance, uma organização não lucrativa que promove o
desenvolvimento ágil, além de ter acontecido a adoção desta metodologia por
diversas empresas e startups.
Segundo a Agile Manifest, os principais valores da metodologia são:
 16

Indivíduos e iterações mais que processos e ferramentas

Processos e ferramentas não precisam ser completamente retirados, porém
a equipe entre si, para que possam agir em suas dificuldades, e até entre a equipe e
o cliente, para obter do próprio cliente feedbacks do caminho que está sendo
percorrido no desenvolvimento do sistema.

Software funcional mais que documentação abrangente

A documentação não é excluída, porém o valor que o sistema funcional
possui em relação a documentação é maior para o cliente, dessa forma com a
entrega parcial do sistema obtém-se um resultado mais positivo no resultado do
projeto.

Colaboração do cliente mais que negociação de contratos

Não exclui a necessidade de um contrato, porém o cliente estar interagindo
e dando constantes feedbacks no projeto traz maiores resultados ao projeto.

Responder a mudanças mais que seguir um plano

Não exclui a necessidade de um plano, porém a metodologia possibilita a
flexibilização e adaptação da equipe perante mudanças que podem ocorrer ao longo
do processo de desenvolvimento.
Com esses conceitos possuímos então um processo de desenvolvimento em
que o projeto é dividido em grandes entregas delimitadas por um período de tempo,
entregas funcionais que agregam valor ao cliente, e essas grandes entregas são
subdivididas em tarefas, partes ainda menores que determinam o que é necessário
ser feito durante aquele período para que a entrega possa ser realizada.
No meio desse processo constante interação entre a equipe e do cliente com
o projeto com a possibilidade de responder a mudanças.

Módulos do projeto

Divisão das iterações (sprints)

Foi então que utilizando a metodologia agile com o auxílio da plataforma
Azure Devops da Microsoft, plataforma que possui uma série de ferramentas e
proporcionava uma serie de insights além um melhor controle das atividades que
estavam sendo desenvolvidas pelo grupo.
 17

O primeiro passo foi a definição das iterações, ou entregas, que o projeto

teria ao longo do semestre. Essas entregas foram previamente estipuladas pelo
professor, o que facilitou parte do trabalho:

As iterações acabavam não seguindo o mesmo TimeBox (período), existindo

iterações de 7 a 14 dias que eram relacionadas normalmente a entrega que devia
ser feita.
Foi estipulado pelo grupo também que para cada iteração seguiríamos com
reuniões no início de cada iteração, definindo/revisando o que precisa ser feito
naquele período e quem fara, diariamente naquele período o grupo saber o que está
acontecendo no projeto e no final de cada iteração a revisão daquilo que foi
produzido pelo grupo. Dessa forma todos estariam a par do que estaria acontecendo
e das dificuldades.

Divisão das iterações (sprints)

Com os TimeBoxes das iterações definidos o grupo partiu para a definição
das tarefas que deviam ser realizadas. Nessa definição adotou-se o uso da seguinte
estrutura:
EPICS – Entregas funcionais ao usuário final do projeto que está sendo
desenvolvido;
Features – Dentro de cada EPIC existem várias features, que são
funcionalidades que aquela epic possuirá;
User stories – Dentro de cada Feature existem várias user stories, que são
situações de uso do usuário final daquela funcionalidade, determinando o que o
usuário quer fazer, o momento e como. Por exemplo: “Eu como usuário gostaria de
adicionar um funcionário quando clicasse no botão ‘Adicionar’”;
 18

Task – Dentro de cada User stories existem uma ou muitas tasks, que são
as tarefas a nível técnico que precisam ser realizadas para que aquela User storie
esteja completa.
Com essa estrutura para gerenciamento das tarefas conseguimos dividir o
projeto em partes pequenas, detalhando-as de forma que não fique dúvida ou
subentendido a respeito do que deve ser feito, e se mesmo assim restar dúvida
gerar a direção do que deve ser buscado pelo grupo.
Com isso em mente dividimos o projeto em 5 principais EPICS, conforme a
imagem abaixo:

• Documentação: parte documental do projeto

• Login de usuário: parte de desenvolvimento
• Chat: parte de desenvolvimento
• Transferência de arquivos de vídeo: parte de desenvolvimento
• Transferência de arquivos de áudio: parte de desenvolvimento
E dentro de cada uma delas suas respectivas Features, User stories e
Tasks.
 19

Com isso foi possível definir as tarefas que tínhamos em mente, podendo
acompanhar cada uma por meio de um status que é possível atribuir as mesmas e
uma quantidade de horas para ser realizada.
Além disso num cenário em que surge um bug na parte de desenvolvimento
ou então uma correção na parte escrita, é possível adicionar a tarefa no quadro e
atribuir um status e tempo para a tarefa ser realizada.

Cronograma de execução
Com boa parte das tarefas definidas o grupo partiu para a divisão das
responsabilidades do projeto.

No próprio Azure DevOps delegamos para cada membro as áreas de

atuação com a responsabilidade que teriam no projeto. Conforme a imagem acima
foram delegados:
 20

• 1 membro para a documentação (Documentation)

• 2 membros para o desenvolvimento do sistema (Development)
• 1 membro para organização e gerenciamento (Development)
• 1 membro para o design do projeto (Design)

Divididos dessa forma, os membros do grupo conseguiriam atuar de forma

proativa focando tanto em sua própria responsabilidade quanto ajudando as outras
áreas em suas responsabilidades.
Junto a isso foram atribuídos a cada membro um valor de horas que seria
trabalhado por cada membro do grupo.

Administração do processo
Finalmente, com a configuração das iterações definidas, tarefas
determinadas, áreas atribuídas a seus devidos responsáveis e tempo de
desenvolvimento dessas atividades determinado, conseguimos observar por meio da
dashboard que a plataforma nos oferece o andamento do projeto.

Cada usuário pode visualizar as

tarefas que estão atribuídas a ele e o status
 21

em que cada uma delas se encontra. Assim que completas essas tarefas podem ser
movidas pelo mesmo.
É possível também acompanhar se a quantidade de horas total das tarefas
passa ou não da quantidade de horas total de todos os membros daquela iteração.
Por exemplo, se temos uma iteração
de 7 dias corridos, com uma pessoa
trabalhando por 2.5 (2 horas e 30min) por dia,
multiplicamos 7 por 2.5 e teremos uma
iteração com 17,5 (17h30min) de
desenvolvimento total da equipe.
A barra verde acaba sendo as tarefas restantes da iteração atual que ainda
não tiveram seu status alterado.

E de forma geral, acompanhar como está sendo a progressão das tarefas ao

longo de toda a iteração, conseguindo determinar se em todos os dias o grupo
conseguiu trabalhar no projeto baseado na mudança de status que elas tiveram.
 22

Projeto: Estrutura do programa

Arquitetura de módulos a serem desenvolvidos

A arquitetura que será implementada neste projeto será a arquitetura REST,
que significa Representational State Transfer, onde separamos a aplicação entre
cliente e servidor mantendo a comunicação entre as duas por meio de requisições
do cliente para o servidor.
Essa arquitetura foi idealizada por Roy Fielding em sua tese de mestrado,
descrevendo essa arquitetura de comunicação em rede.

As três principais características de uma arquitetura REST são:

Recursos
Os recursos são descritos nas URIs das requisições, essas descrições
dependem do recurso que deseja ser acessado, porém, é recomendado indicar o
recurso da URI da mais genérica até a mais específica.
por exemplo:

http://meu.servidor/usuarios teremos acesso a recursos destinados aos

usuários do sistema
http://meu.servidor/usuarios/gabriel dentro de usuários, teremos um
usuário chamado Gabriel e com esse uri teremos acesso a informações do usuário
Gabriel.
 23

Podemos ainda denominar essas URI’s de endpoints, que seriam

literalmente “os pontos finais” para acessar determinado recurso.

Ações
Baseado no recurso que você terá diferentes ações a serem aplicadas a fim
de reutilizar o mesmo recurso mantendo uma lógica em cima da ação. As 4 mais
utilizadas são:

GET – Busca o conteúdo de determinado recurso

Ex: Se aplicarmos o verbo GET no recurso http://meu.servidor/usuarios,
espera-se que tenhamos todos os usuários cadastrados no sistema como resposta.

POST – Cria um conteúdo e envia para determinado recurso

Ex: Se aplicarmos o verbo POST no recurso http://meu.servidor/usuarios,
iremos estar cadastrando um novo usuário no sistema.

PUT – Atualiza determinado conteúdo de um recurso;

Ex: Se aplicarmos o verbo PUT no recurso
http://meu.servidor/usuarios/gabriel, iremos estar atualizando as informações do
usuário Gabriel, devido ao parâmetro final da URI estar especificando um nome
dentro de usuários.

DELETE - Apaga o conteúdo de determinado recurso;

Ex: Se aplicarmos o verbo POST no recurso http://meu.servidor/usuarios,
iremos estar cadastrando um novo usuário no sistema.

Conteúdo
E para que essa comunicação seja possível e necessária definir ainda o
valor que está sendo enviado. Dessa forma o Content-type da requisição irá indicar
que tipo de conteúdo que está sendo enviado pela requisição.
Os serviços RESTful (basicamente serviços que implementaram a
arquitetura REST) normalmente utilizam os formatos YAML, XML e JSON para
transitar as informações.
 24

Como no nosso projeto já teríamos que utilizar a arquitetura cliente servidor,

implementar a arquitetura REST para comunicação e construção do sistema seria o
mais lógico a se seguir, uma vez que além das características descritas temos a
vantagem de escalabilidade dos serviços oferecidos por parte do servidor com a
possibilidade de dividi-los em módulos distintos e independentes ou/e acrescentar
mais serviços de forma independente ao sistema.
Teremos no lado do cliente (frontend), uma interface desenvolvida em React
(biblioteca javascript, como descrito nas tecnologias utilizadas) que consumira os
recursos de uma API desenvolvida em NodeJS, ficando do lado do servidor
(backend) tratará das regras de negócio da aplicação. Essa API será o intermediário
entre o cliente e as informações armazenadas em nossa base NoSQL, com os
dados dos usuários e suas conversas via chat.

Diagrama entidade relacionamento (DER)

O Diagrama Entidade Relacionamento (DER) é a representação gráfica do
modelo conceitual (MER), mostrando as tabelas e os relacionamentos entre as
mesmas que o banco de dados do sistema possuirá.
Como citado anteriormente, a modelagem deste projeto utiliza um banco de
dados não relacional (NoSQL) no modelo de coleção de objetos, ou seja, as
informações que o sistema consumirá estão organizadas em coleções de JSON
(Javascript Object Location). Sendo assim listamos a estrutura dos objetos das
entidades que o sistema possuirá, por exemplo, um objeto da entidade usuário,
objeto da entidade chat, etc… além do diagrama de classes, que representa as
principais classes do sistema.

O Banco de dados Firebase Realtime Database

O Firebase é uma plataforma oferecida pelo google que oferece uma série
de serviços, como hospedagem, storage, banco de dados, dentre outros. Utilizamos
para o projeto o banco de dados Realtime, que é NoSQL.
Na figura 01, podemos ver um exemplo de um documento em representação
JSON, onde temos como chave as informações da esquerda como o nome, a idade
e os filmes favoritos e ao lado direito temos o valor de cada chave. Por usar como
 25

base objetos JavaScript, podemos armazenar como valor de chave coleções (listas)
e objetos, como pode ser visto na chave filmes-favoritos.
Figura 01 - Exemplo de documento objeto JSON gravado em um banco de
dados NoSQL:

{
  "nome":  "Jefferson da Silva",
  "Idade": 30,
  "Hobbies" : ["filmes", "jogos",
"Series"]
}

Diagrama de classe
O diagrama de classe tem como objetivo fornecer uma visão macro das
principais classes do sistema e como elas se relacionam.
A figura, mostra a estrutura básica das classes utilizadas na construção da
aplicação server-side (que fica no servidor) ou backend do projeto.
Figura01 - Diagrama de Classe

Na construção das classes do backend utilizou-se o modelo MVC, que visa

principalmente a separação dos atributos (Model) das classes, seus métodos
(Controller) e suas telas (Views). Nesse caso como separamos frontend e backend,
 26

não teremos Views em nosso backend, restando então organizar em controllers e

models.
Para cada um dos controllers teremos métodos 5 principais tipos de
métodos:

index: consulta do banco de dados e retorna todos os registros de uma

coleção especifica
store: cadastra novo um registro no banco de dados
show: procura por um registro específico
update: atualiza um registro específico
delete: exclui um registro específico

Os controllers tem esses métodos e executam a ação conforme seu nome é

a entidade que está relacionada, por exemplo, o index do controller de users
retornará todos os usuários quando executado; o store de users cadastrar um novo
usuário.
Os controllers ainda podem implementar a classe connection, que é
responsável pela conexão ao banco de dados. Deixando a conexão numa classe
única é possível ainda trocar o banco que está sendo utilizado sem afetar as outras
classes.
Cada uma desses controllers é disponibilizado por meio de rotas dentro da
API, essas rotas, como dito na arquitetura utilizada, mostram por meio da URI qual
recurso está sendo acessado. Por exemplo, os controllers que dão acesso aos
recursos do usuário destinam-se ao endpoint “/users”, os posts no endpoint “/posts”.

O Modelo Entidade-Relacionamento e o NoSQL

Para a modelagem dos dados no Firebase Realtime Database, faz-se
necessário uma abordagem diferente da convencional, pois, não temos
relacionamentos direto (chaves primárias ou estrangeiras) entre as coleções.
Apesar de não ter um relacionamento direto, podemos ter valores
fazendo referências para outros objetos em outras coleções, como pode ser visto na
figura 05, onde, cada registro da coleção Usuário possui uma lista de chat no qual
estão associados. Essa lista por sua vez, possui apenas o id do chat, que faz
referência para os valores da coleção de chat.
 27

Figura 02 - Exemplo de relacionamento entre coleções

User Collection:

{
  users: {
    -doknem: {
      id: string,
      name: string,
      login: string,
      password:
string,
      access: string
    }
  }
}

Chat Collection:

{
  "chats": {
    "ijduiohnhuiwnbd_": {
      id: string,
      participants: [{
         id: string,
         name: string,
         password: string,
         access: string
      }],
      mensagens: [{
        id: string,
        owner: {
            id: string,
            name: string,
            password:
string,
            access: string
        },
        receiver: {
            id: string,
            name: string,
            password:
 28

string,
            access: string
        },
        content: string,
        timestamp: int
       }]
      },
    }
  }
}

Message Collection:

Message: {
    -djoiwn: {
       id: string,
        owner: {
          id: string,
          name: string,
          password:
string,
          access: string
        },
       receiver: {
         id: string,
         name: string,
         password: string,
         access: string
       },
       content: string,
       timestamp: int
    }
}

Coments Collection:

Coments: {
   -snijnw:{
   id: string,
 29

    content: string,
    timestamp: int,
    owner: {
        id: string,
        name: string,
        login: string,
        password:
string,
        access: string,
leaf: int
    }
   }
}

Posts Collection:

posts: {
  -kemsom:{
   id: string,
    content: string,
    coments: [{
        id: string,
        content: string,
        timestamp: int
    }],
    tags: [string],
    owner: {
        id: string,
        name: string,
        login: string,
        password:
string,
        access: string
    },
    timestamp: int
  }
}
 30

Design

Logo
A prototipagem é uma das partes essenciais a qualquer projeto. É nela que
colocamos todas as nossas ideias e funcionalidades de uma maneira visual, mais
clara.

Aplicação
Nosso primeiro desafio foi fazer um logo que representasse naturalmente
nossa aplicação web.
Depois de diversas horas investidas em
pesquisas, achamos algo que se encaixava
perfeitamente na finalidade da nossa aplicação
web.
Dois balõezinhos retangulares paralelos
intercepto, e nesta intersecção uma folha. Os
dois balões representam, comumente na
linguagem da internet, bate-papo. Normalmente
utilizado em diversos outros logos de aplicativos
mensageiros como o WhatsApp, Facebook Messenger e tantos outros... enquanto a
folha significava o meio-ambiente/sustentabilidade.

Nome
A escolha do nome envolveu um nível grande de brainstorming. Primeiro
escolhemos palavras que nos remetiam a finalidade do nosso aplicativo web: meio-
ambiente, sustentabilidade, florestas, app, chat…
Como o inglês é um idioma muito presente na área de tecnologia,
resolvemos que o nome do nosso aplicativo deveria estar nessa língua.
Depois de diversas conversas em grupo, ficou decidido que a aplicação web
deveria se chamar Environment Chat ou Leaf Chat. Como o nosso logo tem uma
folha dentro dele, decidimos que Leaf Chat se encaixaria perfeitamente.

Paleta de cores
 31

O meio-ambiente é comumente associado com florestas que, por sua vez, é

associado com a cor verde.
Se pegarmos exemplos de aplicativos e sites relacionados ao meio
ambiente, veremos que a cor verde sempre tem seu espaço reservado na paleta de
cores. Para citarmos como exemplo, uma das organizações ambiental mais antiga
do mundo, Green Peace, tem como a cor verde predominante no seu logo.
E com o nosso aplicativo web não seria diferente. Utilizamos diversos tons
de verde para montarmos o layout da nossa aplicação web.
A cor de fundo e primária que escolhemos foi a #8AC48C, verde um pouco
fosco, achamos que combinaria com a finalidade da nossa aplicação web.
A cor secundária é o #FFFFFF, um branco básico, decidimos porque se
encaixaria perfeitamente com o verde escolhido. Ela aparece em diversas partes da
aplicação web, como as linhas divisórias, ícones, logo e cor do texto (com exceção
das palavras em placeholder).
A cor de fundo dos botões ficou com #6DE371, que, com um verde mais
claro, aparece para dar uma leveza.
A cor #6EBC71 se encontra presente no navbar onde existe um botão
clicável. Caso esteja com essa cor em volta, significa que o item está ativo.

Protótipos

Iniciar sessão

Essa é a primeira tela que aparecerá caso o usuário não esteja logado na
sua conta.
Para logar será solicitado o seu e-mail e senha.
 32

Caso não tenha um login, o usuário terá a opção de criar uma conta.

Caso não tenha um login, o usuário terá a opção de criar uma conta.
 33

Caso apenas tenha esquecido a senha, o usuário terá a opção de recuperar

a sua senha digitando o e-mail cadastrado na nossa plataforma.

Página Inicial
Logo após o usuário fazer o login, será redirecionado para a página inicial.
Onde ele terá algumas funcionalidades disponíveis
● Cadastrar novos posts, visualizar, comentar e/ou dar “leaf” na
postagem;
● Listar mensagens da conversa, enviar mensagem, enviar arquivo de
áudio, enviar arquivo de vídeo;
● Alternar entre visualizar os contatos ou conversas;
● Sair da sua conta

Na
aba
de
 34

contatos existem algumas funcionalidades. Caso o usuário queira iniciar uma

conversa com o usuário basta clicar no retângulo do usuário selecionado.
Caso queira Adicionar um novo contato basta clicar no retângulo de “Novo
contato”.
Também será possível apagar um contato existente na sua agenda, clicando
na seta para baixo, em seguida “deletar contato”.

No menu do canto direito, na aba mensagens, é possível o usuário iniciar

uma nova conversa ou deletar conversa clicando na seta virada para baixo.

Após clicar na conversa, o usuário tem a possibilidade de mandar uma

mensagem de texto, áudio, imagem ou vídeo. Para enviar um arquivo anexado, é
necessário clicar no clipe onde irá aparecer outras opções.

Após clicar no clipe o usuário poderá tirar uma foto no momento

(simbolizado pela câmera) ou anexar uma imagem ou vídeo (simbolizado pelo ícone
de imagem).
 35

Após selecionar a imagem/vídeo/áudio, o usuário poderá pré-visualizar o

item. E, caso queira enviar, é só apertar na tela do canto inferior direito do chat.

Usuários
Essa parte da página só estará disponível para contas que forem admin.
Dentro dela será possível visualizar os usuários, criar novos usuários e editar/deletar
usuários já existentes.

Diagramas de casos de uso

Caso de uso é um diagrama construído para ilustrar os tipos de usuário que

existirão no sistema e os acessos de telas e funcionalidades que eles possuirão.
Abaixo temos esse diagrama do sistema com os tipos de usuários e seus
 36

respectivos acessos aos recursos de chat e a funcionalidade ecológica que a

plataforma irá oferecer.

A funcionalidade que será implementada a fim de dar um background

ecológico ao sistema será a de um feed, onde os usuários poderão realizar
postagens ecológicas com tags que resumem o tema central do post. O objetivo dos
posts e do feed é, além de gerar engajamento nos assuntos, proporcionar a
propagação de informações ecológicas entre os usuários do sistema.
As tags que serão colocadas em cada post, serão:
● Habitat / nicho ecológico
 37

● Reciclagem
● Mudanças climáticas
● Espécies animais
● Poluição

Sendo assim, o caso de uso do sistema divide-se basicamente em duas

entidades principais, o usuário comum e o usuário administrador.

Usuário Comum:
Conforme indica o diagrama no primeiro acesso que o usuário comum terá
acesso a tela de efetuar login, recuperar sua senha ou cadastrar um novo login.
Somente ao realizar o login o usuário comum terá acesso a página home, onde ele
terá uma listagem dos posts realizados por outros usuários, uma listagem das
conversas que ele realizou com outros usuários, poderá realizar um novo post e
visualizar numa espécie de lista de contatos os usuários disponíveis para iniciar uma
conversa.
Ao estar logado o usuário terá acesso a uma listagem dos usuários do
sistema, tendo ainda a possibilidade de buscar por um específico. Caso ele queira, é
possível iniciar uma conversa ao selecionar um usuário de interesse.
O cadastro do post que o usuário tem a possibilidade de fazer será uma
mensagem ou um texto com uma tag relacionada a ecologia.
Existirá a listagem dos posts para que os usuários logados interajam lendo e
comentando nas postagens.
Finalmente, teremos uma listagem das conversas realizadas pelo usuário
que estará logado. A partir dessa listagem é possível selecionar uma conversa e
enviar novas mensagens ou então arquivos multimídia (áudios e vídeos) nessa
conversa.

Usuário Administrador:
O usuário administrador terá todos os acessos que o usuário comum tem,
com o acréscimo da tela de usuários, onde somente usuários do tipo admin além de
visualizar uma listagem de todos os usuários no sistema, conseguem cadastrar
novos usuários, editar ou ainda deletar conforme a necessidade.
 38

Relatório com as linhas de código do programa

 39

Referências bibliográficas

https://www.bbc.com/portuguese/brasil-47206026
https://brasilescola.uol.com.br/biologia/impactos-ambientais-acidente-mariana-
mg.htm
https://noticias.uol.com.br/ultimas-noticias/afp/2019/08/21/desmatamento-e-principal-
causa-de-incendios-na-amazonia-afirma-paulo-moutinho.htm
https://www.infoescola.com/ecologia/crime-ambiental/
https://rbispo77.jusbrasil.com.br/artigos/627921409/voce-sabe-o-que-sao-crimes-
ambientais
https://ibracam.com.br/blog/o-que-e-considerado-um-crime-ambiental-no-brasil
https://www.space.com/amazon-rainforest-fires-2019-nasa-satellite-views.html
https://www.json.org/json-en.html
http://www.cienciaedados.com/top-6-nosql-databases/
https://aws.amazon.com/pt/nosql/
https://www.devmedia.com.br/como-criar-um-chat-com-node-js/33719
https://www.luiztools.com.br/post/criando-um-chat-com-nodejs-e-socketio/?
gclid=CjwKCAjwvOHzBRBoEiwA48i6AlxyIkf_A5QxBGUBW1H_-5Jw7Q3T-oAtdgm-
RwtOhNZvnBhoH4g0PhoCLkQQAvD_BwE
https://blog.schoolofnet.com/o-que-e-uma-spa-single-page-application/
https://medium.com/@joaomarcuraa/o-protocolo-tcp-ip-1dc2cdb88b07 https://
paginas.fe.up.pt/~mrs01003/TCP_IP.htm
https://sites.google.com/site/rodrigoerubentic/-o-protocolo-da-internet-o-tcp-ip
https://protocolo-tcp-ip.webnode.pt/noticias/
https://wiki.portugal-a-programar.pt/dev_geral:c:sockets_de_berkeley
https://www.dei.isep.ipp.pt/~asc/doc/sockets-berkeley.html
https://pt.qwe.wiki/wiki/Berkeley_sockets#History_and_implementations
https://arqserv.wordpress.com/2012/03/17/como-funciona-a-arquitetura-cliente-
servidor/
 40

https://profsalu.com/2014/05/18/arquitetura-clienteservidor/
https://www.tecmundo.com.br/internet/982-o-que-e-cliente-servidor-.htm
https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
https://docs.microsoft.com/en-us/azure/devops/?view=azure-devops
http://sao-paulo.pm.org/pub/arquitetura-rest-e-o-servico-web-restful-
https://medium.com/@luanacm/protocolo-http-api-e-rest-de-forma-resumida-
36a5494f3da4
https://blog.caelum.com.br/rest-principios-e-boas-praticas/
https://www.ateomomento.com.br/o-que-e-caso-de-uso/
https://medium.com/operacionalti/uml-diagrama-de-casos-de-uso-29f4358ce4d5
https://firebase.google.com/docs
https://blog.totalcross.com/pt/banco-de-dados-relacional-nao-relacional/
Logo:
https://br.pinterest.com/pin/830773462497417259/

Inspiração do layout:

https://uimovement.com/design/profile-page-1/
https://web.whatsapp.com/

Ficha de Atividades Práticas Supervisionadas