Relatório Final Sangue Bom

INSTITUTO AVANÇADO DE ENSINO SUPERIOR E DESENVOLVIMENTO HUMANO
Gabriela Espinoza de Souza, RA- 2022103060
Luiz Felipe Paes de Souza, RA- 2021202096
Marcel Yassumoto, RA- 2021201791
Sérgio Adriano Sousa Santos, RA- 2021201960
Weverton Gomes, RA- 2020201169
DOCUMENTAÇÃO DO PROJETO
SANGUE BOM: PLATAFORMA PARA DOAÇÃO DE SANGUE E MEDULA ÓSSEA
CAMPO GRANDE MS
2023
SUMÁRIO
1. VISÃO GERAL DO SANGUE BOM.................................................................................4
2. INTRODUÇÃO...................................................................................................................4
3. LEVANTAMENTO DE REQUISITOS.............................................................................5
3.1. Requisitos funcionais do usuário..................................................................................5
3.2. Requisitos funcionais do administrador.......................................................................6
3.3. Requisitos não funcionais.............................................................................................8
4. REGRAS DE NEGÓCIO..................................................................................................11
5. LEVANTAMENTO DOS CASOS DE USO....................................................................17
5.1. Diagrama de Casos de Uso.........................................................................................21
6. ESCOLHA DO BANCO DE DADOS..............................................................................23
7. DESENVOLVIMENTO DO SISTEMA...........................................................................24
7.1. Responsividade do Site..............................................................................................24
7.2. Tecnologias Utilizadas...............................................................................................24
7.3. Metodologia de Desenvolvimento.............................................................................24
8. DESENVOLVIMENTO DO BANCO DE DADOS.........................................................25
8.1. Diagrama de Entidade e Relacionamento..................................................................25
8.2. Diagrama de Classes..................................................................................................26
8.3. Aspectos Técnicos e Infraestrutura do Banco de Dados............................................28
9. DESENVOLVIMENTO DA SEGURANÇA DO SISTEMA...........................................33
10. CONCLUSÃO...............................................................................................................38
APÊNDICE A – LOGOMARCA SANGUE BOM..............................................................39
APÊNDICE B- MASCOTE SANGUE BOM.......................................................................39

LISTA DE FIGURAS
Figura 1: Diagrama de Casos de Uso........................................................................................22
Figura 2: Diagrama de Entidade e Relacionamento (DER)......................................................26
Figura 3: Diagrama de Classes.................................................................................................27
Figura 4: Instância do banco de dados......................................................................................28
Figura 5: Método “define”........................................................................................................29
Figura 6: Tabelas do banco de dados da plataforma.................................................................30
Figura 7: Tabela usuário com todos os atributos colocados no código....................................30
Figura 8: Rotas..........................................................................................................................31
Figura 9: Route usuário.............................................................................................................32
Figura 10: Rodando o Servidor.................................................................................................32
Figura 11: Exemplo de envio de dados para cadastro de usuário.............................................33
Figura 12: Registro no banco de dados.....................................................................................33
Figura 13: Regras para validação de senha no front-end..........................................................33
Figura 14: Código para teste de senha no back-end.................................................................34
Figura 15: Método de cadastro de usuário................................................................................35
Figura 16: Método que faz o login do usuário..........................................................................36
Figura 17: Mensagem encriptada e decriptada.........................................................................36
Figura 18: Middleware verifyJWT...........................................................................................37
Figura 19: VerifyJWT no token de requisição..........................................................................37
LISTA DE TABELAS
Tabela 1: Requisitos Funcionais do Usuário..............................................................................4
Tabela 2: Requisitos Funcionais do Administrador....................................................................6
Tabela 3: Requisitos não Funcionais..........................................................................................8
Tabela 4: Regras de negócio do Sangue Bom..........................................................................11
Tabela 5: Casos de Uso do Sangue Bom..................................................................................17
Tabela 6: Níveis de acesso........................................................................................................27
1. VISÃO GERAL DO SANGUE BOM
A plataforma Sangue Bom tem como objetivo possibilitar fins assistenciais para
doação de sangue e medula óssea, facilitando e agilizando a comunicação entre Hemocentros,
postos de coleta e os usuários. Sangue Bom é focado em ajudar pacientes que necessitam de
doação de sangue e medula óssea.
O usuário terá acesso ao histórico de doação, coleta de informações e requisitos para
doação de sangue.
No Web App será possível a divulgação de campanhas de doação para o
abastecimento dos hemocentros, como também em casos de urgência, por exemplo, um
paciente que precise de transfusão de um tipo sanguíneo que esteja em baixo estoque.
Usuários também poderão divulgar campanhas, caso aprovadas pelos administradores.
No cadastro o usuário terá a possibilidade de adicionar também a doação de medula
óssea para em caso de necessidade, existir no banco de dados o público que está disposto a
essa respetiva doação.
2. INTRODUÇÃO
A doação de sangue e medula óssea é um ato de generosidade e solidariedade que
desempenha um papel crucial na vida de inúmeras pessoas em todo o mundo. Através desse
gesto altruísta, vidas são salvas, e esperança é oferecida a pacientes enfrentando condições
médicas graves. É um compromisso com a humanidade, uma demonstração de empatia e um
testemunho da força da comunidade global.
Nos últimos anos, o campo da doação de sangue e medula óssea tem avançado
significativamente, mas também enfrenta desafios contínuos. A demanda por produtos
sanguíneos seguros e compatíveis está em constante crescimento, e encontrar doadores
compatíveis é muitas vezes uma corrida contra o tempo. Além disso, garantir a segurança dos
procedimentos de doação é de extrema importância para a saúde tanto dos doadores quanto
dos receptores.
Nesse contexto, apresentamos com grande orgulho a documentação abrangente do
nosso Sistema de Doação de Sangue e Medula Óssea. Este sistema representa um
compromisso com a missão de tornar a doação mais acessível, eficiente e segura para todos os
envolvidos.
Ao longo das próximas seções deste relatório, vamos mergulhar profundamente na
importância, funcionalidades, do nosso sistema.
Com esta iniciativa, buscamos não apenas atender às necessidades imediatas da
comunidade, mas também contribuir para o avanço contínuo do campo da doação de sangue e
medula óssea. Estamos dedicados a oferecer esperança, salvar vidas e fazer a diferença no
mundo.
3. LEVANTAMENTO DE REQUISITOS
3.1. Requisitos funcionais do usuário
Tabela 1: Requisitos Funcionais do Usuário.
RF-01 Cadastrar Usuário

Descrição O usuário realiza o cadastro no site.
Nome, Telefone, Data de Nascimento, CPF, E-mail, Senha, UF,

Entrada
Cidade, Tipo Sanguíneo, Doação de Medula Óssea.
O sistema valida as informações e insere no Banco de Dados
Processo
atribuindo um ID Sequencial.
Saída O sistema exibe mensagem de “Usuário cadastrado com sucesso”.
RF-02 Login
Descrição O usuário faz o login no sistema.
Entrada E-mail e Senha.
O sistema validade os dados informados, verifica se o e-mail e senha

Processo
existem do banco de dados e permite a autenticação.
Saída O sistema exibe mensagem de “Login realizado com sucesso”.
RF-03 Página Inicial

O usuário terá acesso às informações básicas da plataforma, como
Descrição também as redes sociais do Sangue Bom (facebook, instagram e
email).
O sistema exibe as informações básicas e redes sociais do Sangue
Saída
Bom.
RF-04 Página Saiba Mais
O usuário tem acesso aos requisitos e informações de quem pode ou
Descrição
não doar sangue ou medula óssea da plataforma Sangue Bom.
O sistema exibe os requisitos e informações de quem pode ou não
Saída
doar sangue ou medula óssea.
RF-05 Hemocentros
O usuário tem acesso a todos os hemocentros cadastrados na
Descrição
plataforma Sangue Bom.
O sistema exibe todos os hemocentros cadastrados na plataforma
Saída
Sangue Bom.
RF-06 Visualizar Campanhas

O usuário tem acesso a todas as campanhas cadastradas na plataforma
Descrição
Sangue Bom.
O sistema exibe todas as campanhas cadastradas na plataforma
Saída
Sangue Bom.
RF-07 Cadastrar Usuário

Descrição O usuário realiza o cadastro de uma campanha na plataforma.
Entrada Título, Tipo Sanguíneo, Descrição.

Processo
Saída O sistema exibe mensagem de “Campanha enviada para aprovação”.
3.2. Requisitos funcionais do administrador
Tabela 2: Requisitos Funcionais do Administrador.
RF-08 Página Inicial

O administrador terá acesso aos dados mensal e anual de doações
Descrição
realizadas na plataforma.
Saída O sistema exibe a página inicial com os dados mensal e anual de
doações realizadas na plataforma.
RF-09 Cadastrar Hemocentro

O administrador consegue cadastrar qualquer hemocentro na
Descrição
Entrada Nome, CEP, Endereço, Bairro, Cidade, Estado, Número.

Processo
O sistema exibe mensagem de “Hemocentro cadastrado com
Saída
sucesso”.
RF-10 Editar Hemocentro

O administrador consegue editar todos os hemocentros cadastrados
Descrição
na plataforma Sangue Bom.

Processo
mantendo o mesmo ID e atualizando as alterações.
Saída O sistema exibe mensagem de “Hemocentro editado com sucesso”.
RF-11 Excluir Hemocentro

O administrador consegue excluir todos os hemocentros cadastrados
Descrição
na plataforma Sangue Bom.
O sistema valida as informações removendo o hemocentro do banco

Processo
de dados.
Saída O sistema exibe mensagem de “Hemocentro excluído com sucesso”.
RF-12 Aprovar Campanhas

O administrador consegue aprovar as campanhas solicitadas pelos
Descrição
usuários.
Saída O sistema exibe a mensagem de “Campanha aprovada com sucesso”.
RF-13 Excluir Campanhas
O administrador consegue excluir qualquer campanha na plataforma
Descrição
Sangue Bom.
Saída O sistema exibe a mensagem de “Campanha excluída com sucesso”.
RF-14 Editar Estoque

O administrador consegue editar o qualquer estoque de sangue na
Descrição
Saída O sistema exibe a mensagem de “Quantidade alterada com sucesso”.
RF-15 Editar Usuário / Administrador

O administrador consegue editar os usuários podendo tornar qualquer
Descrição
usuário em administrador.
Saída O sistema exibe a mensagem de “Usuário editado com sucesso”.
RF-16 Visualizar Estoque

O usuário/administrador consegue visualizar todo o estoque do
Descrição
Sangue Bom.
Saída O sistema exibe o estoque do Sangue Bom.
Os requisitos funcionais descritos acima neste relatório estabelecem a base para o

desenvolvimento de um sistema de banco de dados eficaz para a biblioteca.
O sistema deverá gerenciar informações detalhadas sobre categorias, livros, autores,
funcionários, usuários e empréstimos, além de manter os relacionamentos entre essas
entidades. Isso garantirá um controle eficiente do acervo, empréstimos e interações dos
usuários com a biblioteca, tornando a experiência do usuário mais eficiente e organizada.
3.3. Requisitos não funcionais
Requisitos não funcionais são critérios ou características que descrevem a qualidade e
as restrições do sistema, em oposição aos requisitos funcionais, que descrevem o que o
sistema deve fazer. Esses requisitos se concentram em como o sistema deve realizar suas
funções, em vez de definir as próprias funções.
Tabela 3: Requisitos não Funcionais.
RNF-01 Desempenho
O sistema deve ser responsivo, garantindo que as consultas de busca
Descrição e recuperação de informações sejam concluídas em um tempo
aceitável, mesmo quando há um grande volume de dados.
RNF-02 Segurança
O acesso aos dados do sistema deve ser restrito apenas a usuários
Descrição autorizados. Deve haver medidas de autenticação, autorização e
criptografia de dados confidenciais.
RNF-03 Confiabilidade
O sistema deve estar disponível a maior parte do tempo, com tempo
Descrição de inatividade mínimo. Deve ser implementada uma estratégia de
backup e recuperação de dados para evitar perda de informações.
RNF-04 Escalabilidade
O sistema deve ser capaz de lidar com um aumento no número de
Descrição usuários e no volume de dados sem degradação significativa no
desempenho.
RNF-05 Usabilidade
A interface do usuário deve ser intuitiva e de fácil utilização. Deve
Descrição ser realizada usabilidade e testes de acessibilidade para garantir que
o sistema seja acessível a todos os usuários.
RNF-06 Manutenibilidade
Descrição O sistema deve ser projetado de forma modular, permitindo
atualizações e manutenção sem interromper o funcionamento normal
do sistema.
RNF-07 Compatibilidade
O sistema deve ser compatível com diferentes navegadores da web e
Descrição
dispositivos para atender a diversos tipos de usuários.
RNF-08 Padrões e Regulamentações

O sistema deve cumprir com as normas e regulamentações
Descrição
aplicáveis, como leis de proteção de dados e direitos autorais.
RNF-09 Integração
O sistema deve ser capaz de se integrar a outros sistemas utilizados
Descrição pela biblioteca, como sistemas de gerenciamento de bibliotecas e
sistemas de autenticação.
RNF-10 Tolerância a Falhas

O sistema deve ser projetado para lidar com falhas de hardware ou
Descrição software de forma a minimizar o impacto sobre a disponibilidade e
integridade dos dados.
RNF-11 Tempo de Resposta

O sistema deve fornecer tempos de resposta aceitáveis para garantir
Descrição
uma experiência do usuário satisfatória.
RNF-12 Privacidade
Deve haver salvaguardas para proteger a privacidade dos dados dos
Descrição usuários, incluindo informações de empréstimo e histórico de
pesquisa.
RNF-13 Economia de Recursos

O sistema deve ser projetado para ser eficiente em termos de uso de
Descrição
recursos de hardware e energia.
RNF-14 Desenvolvimento
O sistema deve ser desenvolvido na linguagem JavaScript, usando
Descrição
React e Node.js, utilizando o banco de dados SQL Server.
RNF-15 Criptografia
Descrição Deverá existir criptografia na senha do usuário/administrador.
4. REGRAS DE NEGÓCIO
Regras de negócio são declarações ou diretrizes que definem como uma organização
conduz suas operações e processos de negócios. Essas regras estabelecem as políticas,
procedimentos e restrições que orientam o comportamento dos sistemas de informação e dos
profissionais de TI em uma empresa ou projeto. As regras de negócio têm o objetivo de
garantir que as operações de TI atendam aos objetivos de negócios da organização de forma
consistente, eficiente e alinhada com suas estratégias.
RN-01 – Cadastro de Usuários

Módulo Usuários
Data de criação 08/10/2023
Ator Equipe de Desenvolvimento
Última alteração 08/10/2023
Autor Sérgio Adriano Sousa Santos
Versão 1
Dependências N/A
Todos os usuários devem se cadastrar no sistema,
fornecendo informações pessoais válidas, incluindo
nome, endereço, número de contato e dados médicos
Descrição
relevantes, como tipo sanguíneo e histórico de doações.
A verificação de autenticidade deve ser realizada por e-
mail ou número de telefone.
Tabela 4: Regras de negócio do Sangue Bom.
3
RN-02 – Aprovação de Campanhas de Doação

Módulo Campanhas
Ator Administradores
Versão 1
Dependências N/A
Todas as campanhas de doação propostas pelos usuários
devem ser revisadas e aprovadas por administradores
Descrição antes de serem divulgadas publicamente no sistema.
Somente campanhas aprovadas serão visíveis para outros
usuários.
RN-03 – Histórico de Doações
Módulo Doações
Versão 1
Dependências N/A
O sistema deve manter um registro completo e acessível
do histórico de doações de sangue e medula óssea de
Descrição
cada usuário. Isso inclui datas, tipos sanguíneos doados
e locais de doação.
RN-04 – Privacidade e Segurança de Dados

Módulo Segurança
Versão 1
Dependências N/A
O sistema deve garantir a segurança e a privacidade dos

dados pessoais e médicos dos usuários, em conformidade
Descrição
com as regulamentações de proteção de dados. Todas as
informações devem ser armazenadas de forma segura.
RN-05 – Comunicação com Hemocentros
Módulo Comunicação
Versão 1
Dependências N/A
Estabelecer um sistema de comunicação eficaz entre o
sistema e os hemocentros, permitindo que os
Descrição hemocentros atualizem o status de estoque de sangue em
tempo real. Isso ajuda a garantir que as doações sejam
direcionadas para onde são mais necessárias.
RN-06 – Confirmação de Disponibilidade

Módulo Agendamento
Ator Usuários
Versão 1
Dependências N/A
Antes de agendar uma doação, os usuários devem
receber uma confirmação de que a data e o horário
Descrição escolhidos estão disponíveis nos centros de coleta ou
hemocentros selecionados. Isso evita conflitos de
horário e garante uma experiência de doação suave.
RN-07 – Feedback dos Doadores

Módulo Usuários
Ator Usuários
Versão 1
Dependências N/A
Oferecer aos doadores a oportunidade de fornecer
feedback sobre sua experiência de doação, incluindo a
qualidade do atendimento, a condição das instalações e
Descrição
qualquer sugestão de melhoria. Esse feedback pode ser
valioso para aprimorar o sistema e garantir uma
experiência positiva para os doadores.
RN-08 – Comunicação com os Hemocentros
Módulo Comunicação
Versão 1
Dependências N/A
Estabelecer um sistema de comunicação eficaz entre o
sistema e os hemocentros, permitindo que os
Descrição hemocentros atualizem o status de estoque de sangue em
tempo real. Isso ajuda a garantir que as doações sejam
direcionadas para onde são mais necessárias.
RN-09 – Pesquisa de Locais de Doação

Módulo Localização
Ator Usuários
Versão 1
Dependências N/A
Fornecer aos usuários a capacidade de pesquisar e
encontrar os hemocentros e postos de coleta mais
Descrição
próximos de sua localização, facilitando o planejamento
de doações.
RN-10 – Autenticação de Usuários

Módulo Autenticação
Versão 1
Dependências N/A
Implementar um sistema robusto de autenticação de
usuários, que inclui login seguro com identificação de
usuário e senha. Além disso, considerar a possibilidade
Descrição
de autenticação de dois fatores (2FA) para aumentar a
segurança das contas dos doadores e dos profissionais de
saúde.
RN-11 – Permissões de Acesso
Módulo Segurança
Versão 1
Dependências N/A
Definir os níveis de permissão de acesso para diferentes
tipos de usuários (por exemplo, administradores,
Descrição
doadores e profissionais de saúde) para controlar o
acesso a funcionalidades específicas do sistema.
RN-12 – Registro de Doadores

Módulo Doações
Versão 1
Dependências N/A
Registrar informações detalhadas sobre os doadores,
Descrição incluindo histórico de doações, tipo sanguíneo e
critérios de elegibilidade.
RN-13 – Agendamento de Doações

Módulo Agendamento
Ator Usuários
Versão 1
Dependências Registro de Doadores
Permitir que os doadores agendem suas doações,
Descrição
escolhendo data, horário e local convenientes.
RN-14 – Campanhas de Doação
Módulo Campanhas
Versão 1
Dependências N/A
Definir e gerenciar campanhas de doação para abastecer
Descrição os hemocentros, bem como campanhas específicas em
casos de urgência.
RN-15 – Divulgação de Campanhas

Módulo Campanhas
Ator Administradores, Usuários
Versão 1
Dependências Campanhas de Doação
Permitir a divulgação de campanhas de doação pelos
Descrição administradores e pelos próprios usuários, após
aprovação.
RN-16 – Regras de Elegibilidade para Doação

Módulo Doações
Versão 1
Dependências N/A
Estabelecer regras claras de elegibilidade para doação de
Descrição sangue e medula óssea com base em critérios médicos e
de segurança.
RN-17 – Confirmação de Doação Realizada
Módulo Doações
Versão 1
Registrar e confirmar as doações efetuadas pelos
Descrição doadores após o processo de coleta de sangue ou medula
óssea.
RN-18 – Rastreamento de Doadores

Módulo Doações
Versão 1
Manter um registro completo e atualizado das doações
Descrição de cada doador, incluindo data, tipo de doação e
quantidade coletada.
5. LEVANTAMENTO DOS CASOS DE USO

Após o levantamento dos requisitos funcionais e não funcionais, demos inicio à
criação dos casos de uso, uma ferramenta fundamental na análise e no design de sistemas de
software. Na Linguagem de modelagem unificada (UML), o diagrama de caso de uso resume
os detalhes dos usuários do seu sistema (também conhecidos como atores) e as interações
deles com o sistema.
À medida que avançamos, examinaremos cada caso de uso em detalhes, destacando os

atores envolvidos, os fluxos de eventos principais e alternativos e outros elementos essenciais
para sua compreensão.
Tabela 5: Casos de Uso do Sangue Bom.
CU-01 Cadastrar-se como Doador
Permite que os usuários se cadastrem como doadores de sangue e

Descrição
medula óssea.
Ator Principal Usuário
Pré-condições O usuário deve acessar a página de registro.
1. O usuário acessa a página de registro.

2. O sistema exibe um formulário de registro com campos
obrigatórios.
3. O usuário preenche os campos necessários, incluindo Nome,
Telefone, Data de Nascimento, CPF, E-mail, Senha, UF, Cidade,
Fluxo Normal Tipo Sanguíneo, Doação de Medula Óssea.
4. O sistema valida os dados fornecidos.
5. Se os dados forem válidos, o sistema cria a conta e redireciona o
usuário para a página de login com uma mensagem de sucesso.
6. Se os dados forem inválidos, o sistema exibe mensagens de erro
apropriadas e permite que o usuário corrija os campos.
1A1. Erro de Cadastro:
Fluxos  Se o usuário tentar se registrar com um endereço de e-mail já
Alternativos existente, o sistema exibirá uma mensagem de erro e solicitará ao
usuário que escolha um endereço de e-mail diferente.
CU-02 Fazer Login
Permite que os usuários acessem suas contas no sistema, fornecendo

Descrição
autenticação segura.
Pré-condições O usuário deve ter uma conta registrada.
Fluxo Normal 1. O usuário acessa a página de login.

2. O sistema exibe campos para inserção de e-mail e senha.
3. O usuário insere seu e-mail e senha.
4. O sistema verifica as credenciais do usuário.
5. Se as credenciais forem válidas, o sistema redireciona o usuário
para o painel principal.
6. Se as credenciais forem inválidas, o sistema exibe uma mensagem
de erro.
2A1. Esqueceu a Senha:
Fluxos
 Se o usuário esquecer a senha, ele pode solicitar a redefinição da
Alternativos
senha por e-mail.
CU-03 Pesquisar Hemocentros e Postos de Coleta
Os doadores podem procurar hemocentros e postos de coleta próximos à

Descrição
sua localização.
Ator Principal Usuário (Doador)
Pré-condições O usuário deve estar logado como Doador.
1. O doador acessa a função de pesquisa de hemocentros e postos de

coleta.
2. O sistema exibe um campo de pesquisa e uma lista de opções de
filtragem.
Fluxo Normal 3. O doador insere critérios de pesquisa, como localização ou tipo de
doação.
4. O sistema exibe uma lista de hemocentros e postos de coleta
correspondentes.
5. O doador pode clicar em um resultado para ver mais detalhes.
CU-04 Agendar Doações de Sangue
Permite que os usuários acessem suas contas no sistema, fornecendo

Descrição
autenticação segura.
Pré-condições O doador deve estar logado.
Fluxo Normal 1. O doador acessa a função de agendamento de doações.

CU-05 Registrar Doações de Sangue
Permite que os doadores registrem suas doações de sangue, incluindo

Descrição
informações sobre a data e o local da doação.
Pré-condições O doador deve estar logado.
1. O doador acessa a função de registro de doações.

2. O sistema solicita informações sobre a doação, incluindo data, local
Fluxo Normal e tipo de doação.
3. O doador insere as informações necessárias.
4. O sistema registra a doação no perfil do doador.
2. O sistema exibe uma lista de disponibilidade de horários em
hemocentros ou postos de coleta.
3. O doador seleciona uma data e horário disponíveis.
4. O sistema confirma a reserva e envia uma notificação ao doador
com os detalhes.
CU-06 Fornecer Informações sobre Doação
O sistema fornece informações educacionais sobre doação de sangue e

Descrição
medula óssea aos usuários.
Ator Principal Sistema
Pré-condições O doador ou Hemocentro acessa a aba de informações sobre doação.
1. O usuário acessa a seção de informações sobre doação.

2. O sistema fornece conteúdo educativo sobre doação de sangue e
Fluxo Normal
medula óssea.
3. O usuário lê as informações disponíveis.
CU-07 Gerenciar Perfil de Usuário

Os usuários podem atualizar suas informações de perfil, por exemplo o
Descrição
contato telefônico.
Pré-condições O usuário deve estar logado.
1. O usuário acessa a função de gerenciamento de perfil.

2. O sistema exibe o perfil do usuário.
Fluxo Normal
3. O usuário pode editar suas informações de contato.
4. O sistema salva as alterações no perfil do usuário.
CU-08 Administrar Hemocentros e Postos de Coleta
Os usuários podem atualizar suas informações de perfil, como contato e

Descrição
preferências de notificação.
Ator Principal Administrador do Sistema
Pré-condições O administrador do sistema está logado.
1. O administrador acessa a função de administração de hemocentros

e postos de coleta.
Fluxo Normal 2. O sistema exibe uma lista de hemocentros e postos de coleta.
3. O administrador pode adicionar, editar ou excluir informações
sobre esses locais.
CU-09 Visualizar Estoque de Sangue
Os administradores do sistema podem visualizar o banco de sangue para

Descrição
saber a quantidade disponível de cada tipo sanguíneo.
Ator Principal Administrador do Sistema
Pré-condições O administrador do sistema está logado.
1. O administrador acessa a função de visualização de estoque de

sangue.
Fluxo Normal 2. O sistema exibe informações atualizadas sobre a quantidade
disponível de cada tipo sanguíneo nos hemocentros e postos de
coleta.
5.1. Diagrama de Casos de Uso
Na figura 01 temos o diagrama de casos de uso, uma representação gráfica usada na
modelagem de sistemas, especialmente em engenharia de software. Ele tem como objetivo
principal descrever as interações entre os atores.
Figura 1: Diagrama de Casos de Uso.

Fonte: Elaborado pelos alunos.
6. ESCOLHA DO BANCO DE DADOS

A escolha do MySQL Workbench 8.0 CE como Sistema de Gerenciamento de Banco
de Dados (SGBD) para o Sistema de Gerenciamento de Biblioteca é fundamentada em várias
razões:
 Licença de Código Aberto: O MySQL é uma opção de código aberto amplamente
adotada, o que significa que é altamente acessível e não requer custos de licenciamento
significativos. Isso é particularmente benéfico para organizações com orçamentos limitados,
como bibliotecas.
 Desempenho Robusto: O MySQL é conhecido por seu desempenho confiável e
rápido. Isso é fundamental para garantir que as operações de empréstimo e devolução de
livros possam ser executadas eficientemente, mesmo durante os horários de pico.
 Comunidade Ativa: O MySQL possui uma grande comunidade de desenvolvedores e
uma vasta quantidade de documentação disponível online. Isso simplifica o desenvolvimento,
manutenção e solução de problemas do sistema.
 Recursos de Segurança: O MySQL oferece recursos de segurança avançados, como
autenticação, controle de acesso e criptografia. Isso é essencial para proteger informações
confidenciais dos usuários e funcionários da biblioteca.
 Escalabilidade: O MySQL é escalável, o que significa que o sistema pode crescer à
medida que a biblioteca adiciona mais livros e usuários. Isso garante que o sistema continue
atendendo às necessidades futuras.
7. DESENVOLVIMENTO DO SISTEMA
O desenvolvimento web é uma parte essencial do nosso projeto, pois é a interface que
permitirá aos usuários interagir com nossa aplicação. Abaixo, descrevemos os principais
aspectos do desenvolvimento web:
7.1. Responsividade do Site

O site desenvolvido será altamente responsivo, garantindo uma experiência de usuário
consistente em dispositivos de diferentes tamanhos e resoluções, como computadores desktop,
tablets e smartphones. A responsividade é crucial para alcançar um público amplo e
proporcionar acessibilidade e usabilidade em qualquer dispositivo.
7.2. Tecnologias Utilizadas

 JavaScript: JavaScript é uma linguagem de programação fundamental para o
desenvolvimento web interativo. Ele será amplamente utilizado para criar interações
dinâmicas no site, melhorando a experiência do usuário e permitindo funcionalidades
avançadas.
 Framework React: Optamos por utilizar o framework React para a construção
da interface do usuário. O React é amplamente reconhecido por sua eficiência e facilidade de
desenvolvimento, tornando-o uma escolha sólida para a criação de componentes reutilizáveis
e interfaces de usuário dinâmicas.
 Node.js: Node.js será a base do nosso servidor web. Ele é conhecido por ser
escalável e eficiente, adequado para a criação de aplicativos em tempo real e baseados em
eventos. Isso permitirá que nossa aplicação forneça respostas rápidas e em tempo real às
solicitações dos usuários.
7.3. Metodologia de Desenvolvimento
Para o desenvolvimento web do nosso projeto, adotamos uma abordagem ágil que
enfatiza a colaboração, a flexibilidade e a entrega incremental. Esta metodologia ágil é
fundamental para o sucesso do projeto, e aqui estão os principais aspectos:
 Iteração Contínua: Em vez de seguir um plano de projeto rígido, nosso

desenvolvimento web é organizado em iterações curtas e focadas. Cada iteração, geralmente
com duração de duas a quatro semanas, envolve o desenvolvimento de funcionalidades
específicas. Isso nos permite entregar valor aos usuários mais rapidamente e responder às
mudanças de requisitos de forma eficaz.
 Feedback dos Stakeholders: Durante cada iteração, buscamos feedback ativo dos
stakeholders, incluindo clientes, usuários finais e membros da equipe. Esses insights valiosos
nos ajudam a ajustar e refinar continuamente a direção do projeto, garantindo que o que
estamos desenvolvendo atenda às reais necessidades e expectativas.
 Desenvolvimento Incremental: Em vez de esperar até que todos os aspectos do
projeto estejam completamente desenvolvidos, começamos com um conjunto mínimo de
recursos (MVP - Minimum Viable Product) que fornece valor imediato aos usuários. À
medida que o projeto avança, adicionamos funcionalidades de acordo com as prioridades e o
feedback recebido.
 Flexibilidade para Mudanças: Reconhecemos que os requisitos podem evoluir à
medida que o projeto avança ou que novos insights surjam. Nossa abordagem ágil nos permite
abraçar essas mudanças e ajustar a direção do projeto de forma eficaz.
8. DESENVOLVIMENTO DO BANCO DE DADOS
8.1. Diagrama de Entidade e Relacionamento

Dando continuidade ao desenvolvimento do banco de dados, criamos o Diagrama de
Entidade e Relacionamento (DER) do projeto.
O DER, como consta na figura 2, é uma representação mais detalhada e específica do

modelo conceitual apresentado no MER. Ele inclui informações adicionais, como atributos
(propriedades) associados a entidades, cardinalidade dos relacionamentos (quantos para
quantos), chaves primárias e estrangeiras, e outras características de implementação.
O DER é usado na fase de projeto físico de banco de dados, quando os detalhes de

como os dados serão armazenados e relacionados são especificados.
Figura 2: Diagrama de Entidade e Relacionamento (DER).
8.2. Diagrama de Classes

Diagramas de calsses estão entre os tipos mais úteis de diagramas UML pois mapeiam
de forma clara a estrutura de um determinado sistema ao modelar suas classes, seus atributos,
operações e relações entre objetos.
O diagrama de classes padrão é composto de três partes:
 Parte superior: contém o nome da classe. Esta parte é sempre necessária, seja falando do
classificador ou de um objeto.
 Parte do meio: contém os atributos da classe. Use esta parte para descrever as qualidades
da classe. É necessário somente quando se descreve uma instância específica de uma
classe.
 Parte inferior: inclui as operações da classe (métodos). Exibido em formato de lista,
cada operação ocupa sua própria linha. As operações descrevem como uma
classe interage com dados.
Modificadores de acesso de membro
Todas as classes têm diferentes níveis de acesso, dependendo do modificador de

acesso (visibilidade). Veja os níveis de acesso com seus símbolos correspondentes:
Tabela 6: Níveis de acesso.

Público (+) Privado (-) Protegido (#) Pacote (~) Derivado (/) Estático (sublinhado)
Segue a representação do diagrama de Classes na figura 3:
Figura 3: Diagrama de Classes.
8.3. Aspectos Técnicos e Infraestrutura do Banco de Dados

Na sequência optou-se pela utilização da biblioteca chamada “Sequelize” pelo seu
método de conectar os bancos ao código do sistema, iniciando uma instância do banco de
dados, passando o nome, usuário e senha.
A criação de tabelas no banco, utilizando o “Sequelize” especificado na figura 4, por

trabalhar com modelos ou “models”, sendo que um modelo é uma abstração que representa
uma tabela em seu banco de dados.
O modelo informa ao “Sequelize” diversas informações sobre a entidade que ele
representa, sendo alguma delas o nome da tabela no banco de dados e quais colunas ela possui
(e seus tipos de dados).
Figura 4: Instância do banco de dados.
Dando continuidade ao projeto, iniciamos com instância do banco de dados. Esta pode
conter vários bancos de dados que foram criados pelos usuários, sendo possível o seu acesso
através das mesmas ferramentas ou aplicativo do cliente.
Na sequência, foi utilizado o método “define” como na figura 5, para criação de uma
nova tabela no banco de dados. Esse método recebe o nome da tabela e todos os atributos
dela, bom como todos os campos que essa tabela vai possuir. Exemplo: nome, CPF, e-mail,
cidade, entre outras informações que podem ser de interesse das instituições.
Figura 5: Método “define”.

Após criado a “model” foi utilizado o método “sync” do Sequelize, para poder seguir
realmente com a criação da tabela:
1. Model.sync() - cria a tabela se ela não existir (e não faz nada se já existir);
2. Model.sync({ force: true }) - cria a tabela, descartando-a primeiro se ela já existir;
3. Model.sync({ alter: true }) - verifica qual é o estado atual da tabela no banco de dados
(quais colunas ela possui, quais são seus tipos de dados, entre outros), e então realiza as
alterações necessárias na tabela para que ela corresponda ao modelo.
As figuras 6 e 5 mostram o resultado da organização das pastas, evidenciando a tabela

criada no banco de dados:
Figura 6: Tabelas do banco de dados da plataforma.

Figura 7: Tabela usuário com todos os atributos colocados no código.
Depois da “model” criada, tabela e banco conectado, planejamos as rotas que serão
consumidas pelo front-end, para acesso e manipulação das tabelas no banco. Para isso foi
utilizado o conceito de controller: responsável por intermediar as requisições enviadas pelo
View com as respostas fornecidas pelo model, processando os dados que os usuários
informaram, e repassando para outras camadas.
Na controller do usuário estarão todos os métodos e rotas. Esta é responsável por

exemplo: cadastrar um usuário (criar um usuário no banco), editar um usuário, deletar um
usuário, consultar os usuários, entre outras funcionalidades.
Esta camada é responsável pela intermediação das requisições fornecidas pelo View
com respostas fornecidas pelo model. Exemplo prático na figura 8.
Utiliza-se do método post, responsável por criar um registro de usuário no banco de

dados, que são acessados através de uma rota especifica, exemplo: “/usuário”. Para isso temos
um arquivo chamado “Routes” que armazena as rotas que cada controller acessa, e cada
método que será executado. Exemplificado na figura 9 o trecho do código referente ao route
usuário.
O método post é utilizado para submeter um recurso específico, causando mudanças

frequentes no estado do recurso. Já o get solicita as representações de recursos específicos,
devendo retornar apenas dados.
Figura 8: Rotas.
Figura 9: Route usuário.

Resumidamente a requisição post é mais utilizada para enviar informações a serem

processadas, já as requisições tipo get, são recomendadas para obtenção de dados de um
determinado recurso.
Ou seja, para conseguir cadastrar um novo usuário, o nosso front-end terá que enviar
os dados na rota “/usuário”. Na figura 10 está a demonstração do servidor rodando na porta
8000 no arquivo index.js:
Figura 10: Rodando o Servidor.
Seguindo para página de cadastro de usuário, o mesmo poderá preencher os dados do

formulário e clica em “Cadastrar”, ao clicar nesse botão, a função “onFinish”, constando na
figura 11, capturará todos os dados dos campos que ele digitou. A seguir envia estes dados
para a rota http://localhost:8000/usuario/, com isso localiza a rota “/usuário” e
consequentemente cria um registro no banco de dados.
Figura 11: Exemplo de envio de dados para cadastro de usuário.

A função “onFinish” tem como objetivo retorna a chamada após o envio das
informações do formulário, bem como a verificação dos dados. Na figura 12 segue o registro
no banco de dados como exemplo:
Figura 12: Registro no banco de dados.
Fon
te: Elaborado pelos alunos.
9. DESENVOLVIMENTO DA SEGURANÇA DO SISTEMA

Inicialmente foi desenvolvido a validação de senha, trazendo mais segurança ao
usuário, no qual utilizamos as seguintes regras:
 Precisa conter um número;
 Precisa conter um caractere especial;
 Precisa conter uma letra maiúscula.
Na figura 13 mostra o resultado no front-end das regras para validação de senha:
Figura 13: Regras para validação de senha no front-end.

Usamos também “Regex” que são padrões utilizados para identificar determinadas
combinações ou cadeias de caracteres em um texto.
Figura 14: Código para teste de senha no back-end.
Na figura 14 é apresentado uma função em que a senha é testada varias vezes para
verificar se segue as regras citadas acima, caso ela não siga alguma regra a senha é invalidada,
fazendo assim com que o usuário não consiga concluir o cadastro.
Após o cadastro do usuário a senha é criptografada, a criptografia é um conjunto de

técnicas pensadas para proteger uma informação de modo que apenas o emissor e receptor
consigam compreendê-la. É utilizada em comunicações digitais, como na troca de mensagens
ou em pagamentos online.
Na figura 15 está o método de cadastro de usuário, e na parte destacada mostra

exatamente em que linha está sendo feita a criptografia da senha. E para isso foi utilizada a
biblioteca “bcript” com o método “hash”.
Figura 15: Método de cadastro de usuário.
Exemplo de entrada e saída de senha:
Senha: teste123
Depois da criptografia:
$2b$08$JoFlp1cwelca6n7XEUpMWeJFf6bePRoZ07BDCwuVUeOztgiszl9uW
Dessa forma a senha fica mais protegida contra possíveis acessos e tentativas de
fraude.
Também realizamos o uso de “Token de segurança”, e para isso utilizamos a
biblioteca JWT ou JSON Web Token que é um padrão da indústria definido pela RFC7519
que tem como objetivo transmitir ou armazenar de forma compacta e segura objetos JSON
entre diferentes aplicações.
O JWT é digitalmente assinado usando uma chave secreta com o algoritmo HMAC ou
um par de chaves pública e privada RSA ou ECDSA.
O token é “liberado” geralmente no login após o usuário logar no sistema, e que

contem dados do usuário, perfis que aquele usuário possui, tempo de expiração, etc…
Na figura 16 está o método que faz o login do usuário, e na linha destacada a

vermelho, nesta parte onde é gerado o token.
Figura 16: Método que faz o login do usuário.
Exemplo de token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ik
pvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6y
JV_adQssw5c
Na figura 17 exemplifica uma mensagem encriptada e decriptada:
Figura 17: Mensagem encriptada e decriptada.

Também foi feito o uso de middleware que é um software que diferentes aplicações
usam para se comunicar umas com as outras. Ele oferece funcionalidade para conectar
aplicações de modo inteligente e eficiente, para que você possa inovar mais rapidamente.
No nosso caso o middleware executa sempre que uma rota especifica da API é
chamada, exemplo destacado a vermelho na figura 18:
Figura 18: Middleware verifyJWT.
O “VerifyJWT” é nosso middleware, que sempre que é chamado ele pega os

“cabeçalhos” da requisição que é onde o token é enviado, e valida se ele está com a data de
expiração menor que a data atual.
 Os cabeçalhos HTTP permitem que o cliente e o servidor passem informações

adicionais com a solicitação ou a resposta HTTP.
 Um cabeçalho de solicitação é composto por seu nome case-insensitive (não diferencia

letras maiúsculas e minúsculas), seguido por dois pontos ':' e pelo seu valor (sem
quebras de linha). Espaços em branco antes do valor serão ignorados.
 Cabeçalhos proprietários personalizados podem ser adicionados usando o prefixo 'X-'.
O método “verify” que esta destacado a vermelho, na figura 19, realiza essa ação, se
for um token valido ele consegue prosseguir naquela requisição.
Figura 19: VerifyJWT no token de requisição.

10. CONCLUSÃO
A criação do sistema "Sangue Bom" é uma resposta direta às necessidades crescentes
na área de doação de sangue e medula óssea. Com base em uma pesquisa sólida e nas
referências fornecidas, a plataforma tem o potencial de salvar vidas, simplificando o processo
de doação e melhorando a comunicação entre doadores e hemocentros. Além disso, a
implementação eficaz de um banco de dados robusto e medidas rigorosas de segurança de
dados são elementos-chave para garantir que as informações dos doadores e pacientes estejam
protegidas e acessíveis apenas por partes autorizadas.
A criação de um banco de dados centralizado permitirá o armazenamento seguro e

eficiente de informações de doadores, hemocentros e campanhas de doação. Essa
infraestrutura de banco de dados desempenhará um papel crítico na facilitação de registros
precisos de doações, no rastreamento de estoques de sangue e medula óssea e na comunicação
entre os atores envolvidos. A capacidade de acessar rapidamente informações relevantes é
essencial para coordenar e responder a necessidades urgentes de doação.
Além disso, a segurança de dados é uma prioridade máxima para garantir a

privacidade e a confidencialidade das informações dos doadores. A implementação de
protocolos de segurança robustos, como criptografia de dados, autenticação segura e controle
de acesso restrito, garantirá que apenas pessoas autorizadas tenham acesso aos dados do
sistema. Isso não apenas protegerá os doadores e pacientes, mas também fortalecerá a
confiança na plataforma "Sangue Bom".
Portanto, considerando tanto os aspectos de eficácia operacional quanto de segurança

de dados, é inegável que a criação do sistema "Sangue Bom" não apenas atende às
necessidades da sociedade e da saúde pública, mas também demonstra um compromisso
sólido com a proteção e a confiabilidade das informações. Este sistema tem o potencial de
impactar positivamente inúmeras vidas ao facilitar doações de sangue e medula óssea de
maneira segura e eficiente.
APÊNDICE A – LOGOMARCA SANGUE BOM
APÊNDICE B- MASCOTE SANGUE BOM

Relatório Final Sangue Bom

Enviado por

Dados do documento

Título original

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

Relatório Final Sangue Bom

Enviado por

Direitos autorais:

Formatos disponíveis

INSTITUTO AVANÇADO DE ENSINO SUPERIOR E DESENVOLVIMENTO HUMANO

Gabriela Espinoza de Souza, RA- 2022103060

Luiz Felipe Paes de Souza, RA- 2021202096

Marcel Yassumoto, RA- 2021201791

Sérgio Adriano Sousa Santos, RA- 2021201960

Weverton Gomes, RA- 2020201169

SANGUE BOM: PLATAFORMA PARA DOAÇÃO DE SANGUE E MEDULA ÓSSEA

3.1. Requisitos funcionais do usuário..................................................................................5

3.2. Requisitos funcionais do administrador.......................................................................6

3.3. Requisitos não funcionais.............................................................................................8

5. LEVANTAMENTO DOS CASOS DE USO....................................................................17

5.1. Diagrama de Casos de Uso.........................................................................................21

6. ESCOLHA DO BANCO DE DADOS..............................................................................23

7.1. Responsividade do Site..............................................................................................24

7.2. Tecnologias Utilizadas...............................................................................................24

7.3. Metodologia de Desenvolvimento.............................................................................24

8. DESENVOLVIMENTO DO BANCO DE DADOS.........................................................25

8.1. Diagrama de Entidade e Relacionamento..................................................................25

8.2. Diagrama de Classes..................................................................................................26

8.3. Aspectos Técnicos e Infraestrutura do Banco de Dados............................................28

9. DESENVOLVIMENTO DA SEGURANÇA DO SISTEMA...........................................33

APÊNDICE A – LOGOMARCA SANGUE BOM..............................................................39

APÊNDICE B- MASCOTE SANGUE BOM.......................................................................39

3.1. Requisitos funcionais do usuário

Tabela 1: Requisitos Funcionais do Usuário.

RF-01 Cadastrar Usuário

Nome, Telefone, Data de Nascimento, CPF, E-mail, Senha, UF,

Entrada E-mail e Senha.

O sistema validade os dados informados, verifica se o e-mail e senha

RF-03 Página Inicial

RF-06 Visualizar Campanhas

RF-07 Cadastrar Usuário

Entrada Título, Tipo Sanguíneo, Descrição.

O sistema valida as informações e insere no Banco de Dados

3.2. Requisitos funcionais do administrador

Tabela 2: Requisitos Funcionais do Administrador.

RF-08 Página Inicial

RF-09 Cadastrar Hemocentro

O sistema valida as informações e insere no Banco de Dados

RF-10 Editar Hemocentro

O sistema valida as informações e insere no Banco de Dados

RF-11 Excluir Hemocentro

O sistema valida as informações removendo o hemocentro do banco

RF-12 Aprovar Campanhas

RF-14 Editar Estoque

RF-15 Editar Usuário / Administrador

RF-16 Visualizar Estoque

Os requisitos funcionais descritos acima neste relatório estabelecem a base para o

Tabela 3: Requisitos não Funcionais.

RNF-08 Padrões e Regulamentações

RNF-10 Tolerância a Falhas

RNF-11 Tempo de Resposta

RNF-13 Economia de Recursos

RN-01 – Cadastro de Usuários

RN-02 – Aprovação de Campanhas de Doação

RN-04 – Privacidade e Segurança de Dados

O sistema deve garantir a segurança e a privacidade dos

RN-06 – Confirmação de Disponibilidade

RN-07 – Feedback dos Doadores

RN-09 – Pesquisa de Locais de Doação

RN-10 – Autenticação de Usuários

RN-12 – Registro de Doadores

RN-13 – Agendamento de Doações