TCC EXEMPLO

Prévia do material em texto

UNIVERSIDADE FEDERAL DE SANTA CATARINA 
 
 
 
 
Sistema web de suporte ao processo de voluntariado da Iniciativa 
Computação na Escola 
 
 
 
 
Gabriel Stedile 
 
 
 
 
 
Florianópolis - SC 
 
2019/2 
UNIVERSIDADE FEDERAL DE SANTA CATARINA 
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA 
CURSO DE SISTEMAS DE INFORMAÇÃO 
 
 
Sistema web de suporte ao processo de voluntariado da Iniciativa 
Computação na Escola 
 
 
Gabriel Stedile 
 
 
 Trabalho de conclusão de curso 
 apresentado como parte dos 
 requisitos para obtenção do grau 
 de Bacharel em Sistemas de 
 Informação 
 
 
Florianópolis - SC 
2019/2 
Gabriel Stedile 
 
 
 
Sistema web de suporte ao processo de voluntariado da Iniciativa 
Computação na Escola 
 
 
Trabalho de conclusão de curso apresentado como parte dos requisitos 
para obtenção do grau de Bacharel em Sistemas de Informação 
 
 
Orientador(a): ​ ​Dr. Jean Carlo Rossa Hauck 
 
 
Banca examinadora 
Prof. José Eduardo De Lucca, Dr. 
 
Nathalie Ferreira, M.​a 
 
 
Resumo 
 
A área da tecnologia da informação tem evoluído rapidamente e se faz presente nas 
mais diversas áreas da sociedade. No entanto percebe-se um déficit quantitativo e 
qualitativo de profissionais da área, dentre vários motivos, pela alta demanda de 
conhecimento técnico inerente da área, rápida expansão do setor no país e das 
constantes inovações associadas ao mercado de tecnologia. Uma medida possível 
para se alterar essa situação é gerar interesse e curiosidade pela área ainda na 
Educação Básica, com matérias relacionadas a tecnologia, como programação e 
segurança. Para isso, iniciativas com apoio de voluntariado, como a iniciativa 
Computação na Escola, fortalecem o ensino de computação no ensino fundamental 
e médio. No entanto, a gestão do processo de voluntariado é complexa. Nesse 
contexto, o presente trabalho tem como objetivo desenvolver um sistema web com a 
finalidade de apoiar a gestão do processo de voluntariado. Com base em 
fundamentação teórica, estado da arte e entrevista com responsáveis, o sistema foi 
idealizado, desenvolvido, testado e implantado. 
 
Palavras-chave: Sistema Web, Computação na Escola, Gestão de Processos, 
Voluntariado, Ensino de Programação. 
Abstract 
 
The area of ​​information technology has evolved fast and is present in the most 
diverse areas of society. However, there is a quantitative and qualitative deficit of 
professionals in the area, among many reasons, due to the high demand for inherent 
technical knowledge of the area, fast expansion of the sector in the country and the 
constant innovations associated with the technology market. A possible measure to 
change this situation is to generate interest and curiosity for the area still in basic 
education, with technology-related subjects, such as programming and security. To 
this end, volunteer initiatives such as the Computation at School initiative strengthen 
the teaching of computing in elementary and high school. However managing the 
volunteering process is complex. In this context, this paper aims to develop and 
implement a web system to support the management of the volunteering process. 
Through theoretical foundation and interview with managers, the system was 
designed and will be developed, tested and implemented. 
 
Keywords​: Web System, School Computing, Process Management, Volunteering, 
Programming Teaching. 
Lista de Figuras 
Figura 1 - Fases do ciclo de gestão do voluntariado 
Figura 2 - Comunicação request-response 
Figura 3 - Representação de request HTTP 
Figura 4 - Representação de response HTTP 
Figura 5 - Interface do aplicativo Ivolunteer 
Figura 6 - Interface do aplicativo Samaritan 
Figura 7 - Interface do aplicativo SignUp 
Figura 8 - Interface do aplicativo Whentohelp 
Figura 9 - Interface do aplicativo Yourvolunteers 
Figura 10 - Fluxograma do processo de voluntariado - Parte 1 
Figura 11 - Fluxograma do processo de voluntariado - Parte 2 
Figura 12 - Diagrama de casos de uso 
Figura 13 - Protótipo de tela inicial 
Figura 14 - Protótipo de tela de Voluntários 
Figura 15 - Protótipo de tela de edição de Voluntários 
Figura 16 - Diagrama Entidade Relacional do CnE - Volunteer 
Figura 17 - Mapa mental de concepção do nome da aplicação 
Figura 18 - Logo com título 
Figura 19 - Logo sem título 
Figura 20 - Arquitetura geral do sistema Doate 
Figura 21 - Estrutura de pastas do projeto 
Figura 22 - Formik 
Figura 23 - Yup 
Figura 24 - Axios 
Figura 25 - Interface:Typescript 
Figura 26 - Tipagem de parâmetros: Typescript 
Figura 27 - Celebrate 
Figura 28 - Nodemailer 
Figura 29 - Email service 
Figura 30 - Express 
Figura 31 - TypeORM 
Figura 32 - Doate: Tela Inicial 
Figura 33 - Doate: Tela de contato 
Figura 34 - Doate: Email de contato 
Figura 35 - Doate: Página de login 
Figura 36 - Doate: Página de Calendário 
Figura 37 - Doate: RCnE menu 
Figura 38 - Doate: CRUD de Instituições 
Figura 39 - Doate: Nova Instituição 
Figura 40 - Doate: Email de cadastro de instituição 
Figura 41 - Doate: Editar Instituição 
Figura 42 - Doate: Novo projeto 
Figura 43 - Doate: Exemplo de tabelas 
Figura 44 - Doate: Novo material 
Figura 45 - Doate: Novo material do tipo arquivo 
Figura 46 - Doate: Novo material do tipo link externo 
Figura 47 - Doate: Novo usuário 
Figura 48 - Doate: Email novo usuário 
Figura 49 - Doate: Email novo usuário voluntário 
Figura 50 - Doate: Tela de cadastro de voluntário 
Figura 51 - Doate: Tela de cadastro de voluntário: empresa selecionada 
Figura 52 - Doate: Tela de cadastro de voluntário: empresa CnE 
Figura 53 - Doate: Email de confirmação de cadastro 
Figura 54 - Doate: Aviso de confirmação de cadastro 
Figura 55 - Doate: Tela de confirmar cadastro 
Figura 56 - Doate: Formulário de cadastro de voluntário 
Figura 57 - Doate: Exemplo de validação de formulários 
Figura 58 - Doate: Tela de captura de assinatura 
Figura 59 - Doate: Pdf Formulário de cadastro de voluntário 
Figura 60 - Doate: Primeira etapa de validação concluida 
Figura 61 - Doate: Badge de sinalização de validação de voluntário 
Figura 62 - Doate: Voluntário aguardando instituição 
Figura 63 - Doate: Revisão do formulário de cadastro de voluntário 
Figura 64 - Doate: Formulário de recomendação do voluntário 
Figura 65 - Doate: Tela de termo de responsabilidade do voluntário 
Figura 66 - Doate: Terceira etapa de validação concluida 
Figura 67 - Doate: Abas de documentos do voluntário 
Figura 68 - Doate: Calendário inicial do voluntário ativado 
Figura 69 - Doate: Tela de profile do usuário 
Figura 70 - Doate: Novo evento a partir do calendário 
Figura 71 - Doate: Exemplos de eventos no calendário 
Figura 72 - Doate: Novo evento a partir do CRUD de eventos 
Figura 73 - Doate: Tela de edição de evento 
Figura 74 - Doate: Visualizar evento 
Figura 75 - Doate: Visualizar materiais do evento 
Figura 76 - Doate: Avaliar evento 
Figura 77 - Doate: Visualizar avaliação de evento 
Figura 78 - Interface do aplicativo Insomnia 
Figura 79 - Interface do aplicativo Notion 
Figura 80 - Resultados primeira pergunta avaliação: utilidade 
Figura 81 - Resultados segunda pergunta avaliação: utilidade 
Figura 82 - Resultados avaliação: SUS 
 
Lista de Tabelas 
Tabela 1​ - Termos de busca 
Tabela 2​ - Strings de busca 
Tabela 3​ - Resultado das strings de busca executadas 
Tabela 4 ​- Análise de atendimento as funcionalidades 
Tabela 5​ - Requisitos Funcionais 
Tabela 6​ - Requisitos Não-Funcionais 
Tabela 7​ - Atores e Permissões 
Tabela 8​ - Rastreabilidade entre os casos de usoe requisitos funcionais 
Tabela 9​ - Detalhamento de caso de uso: UC4 - CRUD de voluntários 
Tabela 10​ - Detalhamento de caso de uso: UC10 - Avaliar mentoria 
Tabela 11​ - Mapeamento Casos de uso e protótipos de tela 
Tabela 12​ - Cores da identidade visual da CnE 
Tabela 13​ - Cores selecionadas do blog QuickSprout 
Tabela 14​ - Cor selecionada da identidade visual da UFSC 
Tabela 15​ - Lista de avaliadores 
Tabela 16​ - Respostas da primeira pergunta avaliação: funcionalidade 
Tabela 17​ - Respostas da segunda pergunta avaliação: funcionalidade 
Tabela 18​ - SUS: Pontuação por avaliador 
Tabela 19​ - SUS: Pontuação geral do sistema Doate 
 
 
Lista de abreviaturas e siglas 
CnE​ - Computação na Escola 
CRUD​ - ​ Create, Read, Update and Delete 
RCnE​ - Responsável pela Computação na Escola 
RF​ - Requisitos funcionais 
RFN​ - Requisitos não funcionais 
HTTP​ - Hypertext transfer protocol 
MVP​ - Minimum Viable Product 
UFSC​ - Universidade Federal de Santa Catarina 
AJAX​ - Asynchronous Javascript and XML 
JS​ - Javascript 
MIT​ - Massachussetts Institute of Technology 
URL​ - Uniform Resource Locator 
ORM​ - Object Relational Mapping 
DOM​ - Document Object Model 
 
 
SUMÁRIO 
SUMÁRIO 12 
1. INTRODUÇÃO 14 
1.2 Objetivos 19 
1.2.1 Objetivo Geral 19 
1.2.2 Objetivos Específicos 19 
1.3 Metodologia 20 
2. FUNDAMENTAÇÃO TEÓRICA 22 
2.1 Voluntariado 22 
2.2 Aplicação web 25 
2.2.1 Tecnologias 27 
Esta seção trata da apresentação de algumas das principais tecnologias 
utilizadas no desenvolvimento da solução. 27 
2.2.1.1 Servidor 27 
2.2.1.1.1 PostgreSQL 27 
2.2.1.1.2 Node.js 28 
2.2.1.2 Cliente 28 
2.2.1.2.1 React 28 
3.1 Protocolo de pesquisa 29 
3.2 Execução das buscas 32 
3.3 Resultados das buscas: Ferramentas selecionadas 34 
3.4 Análise dos resultados 41 
4 PROPOSTA DE SOLUÇÃO 44 
4.1 Requisitos 44 
4.2 Casos de uso 50 
4.3 Prototipação de Telas 55 
4.4 Modelagem do banco de dados 58 
5 DESENVOLVIMENTO 59 
5.1 - Processo criativo de concepção do nome 59 
5.2 - Identidade visual 61 
5.2.1 - Logo 61 
5.2.2 - Paleta de cores e fontes 63 
5.2.3 - Elementos de interface 64 
5.3 - Arquitetura geral do sistema 65 
5.3.1 - Cliente: React 67 
5.3.2 - Servidor: NodeJS 73 
5.3.2 - Banco de dados: Postgres 82 
5.4 - Fluxo de telas do sistema Doate 82 
5.5 - Insomnia 118 
5.6 - Notion 119 
6 AVALIAÇÃO DO SISTEMA DOATE 120 
6.1 - Definição da avaliação por usuários 120 
6.1 - Teste de utilidade 122 
6.2 - Teste de funcionalidade 124 
6.3 - Teste de usabilidade 127 
6.4 - Ameaças a validade da avaliação 129 
7 CONCLUSÃO 130 
REFERÊNCIAS 133 
APÊNDICE A - DETALHAMENTO DOS CASOS DE USO 139 
APÊNDICE B - PROTÓTIPO DAS TELAS 146 
APÊNDICE C - TERMO DE RESPONSABILIDADE DO VOLUNTÁRIO 150 
APÊNDICE D - FORMULÁRIO DE RECOMENDAÇÃO DE CADASTRO DE VOLUNTÁRIO
153 
APÊNDICE E - FORMULÁRIO DE CADASTRO DE VOLUNTÁRIO 154 
APÊNDICE F - AVALIAÇÃO DA PLATAFORMA DOATE 155 
APÊNDICE G - CÓDIGO DA PLATAFORMA DOATE 157 
APÊNDICE H - ARTIGO 158 
 
 
1. INTRODUÇÃO 
A área da tecnologia da informação tem evoluído em uma velocidade sem 
precedentes e se faz presente nas mais diversas áreas da sociedade. Cientistas e 
empresários renomados como Stephen Hawking e Bill Gates já haviam feito 
previsões sobre impactos negativos na sociedade, como aumento do desemprego 
devido à ascensão das tecnologias “Inteligentes”, robótica e algoritmos 
(BROUGHAM, 2017). Muitas ocupações profissionais que se encontram em risco 
devido a automação não são necessariamente posições de baixa qualificação: mas 
sim trabalhos às vezes bem pagos da classe média, muitos desses relacionados ao 
setor de serviços e/ou associados a tarefas rotineiras que possam ser facilmente 
automatizadas. Este processo é conhecido como polarização de mercado, com a 
valorização e disponibilidade crescente de ocupações mais complexas e também de 
ocupações de baixa habilidade. Em contrapartida, ocupações de média habilidade, 
que exigem menor formação, registram contração no número de empregados 
(MACHADO, 2017). 
Por consequência, o desenvolvimento da ciência e tecnologia exige 
desenvolvimento humano para se adequar à própria transformação que o meio vem 
sofrendo. Torna-se assim necessário que cada vez mais a população não só tenha 
acesso a informação e tecnologia, como usuário e/ou consumidor, como também 
tenha condições de avaliar e participar ativamente dessas mudanças (PINHEIRO, 
2007). 
 A Softex publicou artigo apontando um déficit aproximado de 408 mil 
profissionais de TI até 2020 (SOFTEX, 2018). Esta carência, tanto qualitativa quanto 
quantitativa por profissionais da área, gera perdas bilionárias para a indústria do 
setor. Além disso, esta necessidade é observada tanto no nível nacional como 
internacional, onde a grande maioria da participação nesse setor é do sexo 
masculino (SOFTEX, 2018). O desinteresse por parte do sexo feminino é observado 
desde o momento da escolha do curso de graduação até a conclusão de cursos na 
área (NUNES, 2015). Nesse contexto entende-se que é necessário entender melhor 
e desenvolver estratégias diversas e complementares para os diferentes sexos, a 
fim de se alcançar maiores taxas de inclusão e interesse pela área tecnológica. 
Percebe-se que a insuficiência do setor é quantitativa e qualitativa, em 
virtude, dentre vários motivos, da alta demanda de conhecimento técnico inerente 
da área, da rápida expansão do setor no país e das inovações constantes que estão 
associadas ao mercado de tecnologia (BORTOLUZZI, 2018). A baixa qualificação 
de profissionais se manifesta por exemplo na dificuldade de se trazer resultados 
satisfatórios para as empresas (OTTE, 2018), além destes não possuírem 
competências que possibilitem às corporações se inserirem em cenários de 
negócios com alta competitividade. 
Uma medida possível para se alterar essa situação, gerando interesse e 
curiosidade pela área, seria o contato precoce desde a Educação Básica com 
assuntos relacionados à tecnologia, como programação, segurança e suporte 
técnico (WANGENHEIM, 2017). No entanto, outro problema se apresenta diante 
disso: a disponibilidade de profissionais capacitados para ensinar computação nas 
escolas (ALVES, 2016). Diversas iniciativas, desde publico-privadas como 
voluntárias, se apresentam com o intuito de suprir e desenvolver pessoas para o 
futuro mercado de trabalho. 
A iniciativa Computação na Escola (CnE) é realizada por professores e 1
pesquisadores do departamento de Informática e Estatística da Universidade 
Federal de Santa Catarina (INE/UFSC), com o apoio de profissionais voluntários de 
diversas empresas. A principal meta da iniciativa é ampliar o ensino de computação 
no ensino fundamental e médio, tornando real a oportunidade de se aprender 
computação prematuramente . Para tal feito, a CnE realiza o papel de gestão e 2
mediação entre as partes interessadas nesse contexto: empresas que desejam 
contribuir e recomendar seus colaboradores para tais iniciativas; escolas que 
buscam estimular seus alunos a terem a oportunidade de complementar seu 
aprendizado com conhecimento tecnológico e inovador; voluntários tanto vinculados 
a empresas ou até mesmo pessoas que desejam atuar no programa por si própria e 
que tenham conhecimento ou interesse para participar, sendo neste caso possível 
se filiar diretamente a iniciativa CnE. Os eventos que a iniciativa promove vãodesde 
treinamentos e geração de conteúdo para todas as partes, como também mentoria e 
a ação propriamente dita de voluntariado. 
O voluntariado é a ação de pessoas que doam seu trabalho e talento para 
realização de ações de natureza social, possuindo um forte caráter de justiça e 
equidade social (RAMOS, 2016). Já pela lei brasileira, encontra-se uma definição de 
voluntariado no decreto Nº 9.906 : 
 
“​considera-se atividade voluntária a iniciativa não remunerada de pessoas físicas, 
isolada ou conjuntamente, prestada à pessoa física, a órgão ou à entidade da 
1 ​http://www.computacaonaescola.ufsc.br/ 
2 ​http://www.computacaonaescola.ufsc.br/?page_id=1656 
http://www.computacaonaescola.ufsc.br/
http://www.computacaonaescola.ufsc.br/?page_id=1656
administração pública ou entidade privada sem fins lucrativos, que tenha objetivos 
cívicos, culturais, educacionais, científicos, recreativos ou de assistência à pessoa, 
que vise ao benefício e à transformação da sociedade por meio de ações cívicas, de 
desenvolvimento sustentável, culturais, educacionais, científicas, recreativas, 
ambientais, de assistência à pessoa ou de promoção e defesa dos direitos humanos 
e dos animais.​”(BRASIL, 2019) 
 
No entanto, gerenciar um processo de voluntariado para estas iniciativas 
pode se tornar um desafio, por ser burocrático, demandar tempo e possuir diversas 
etapas. Além disso, estudos (RAMOS, 2016) sobre voluntariado apontam que, para 
resultados mais eficazes e retenção dos voluntários nos projetos, uma boa gestão é 
fundamental e deve ser muito semelhante a uma empresa: deve se preocupar com 
a vinculação da organização e seus ambientes, além de facilitar os fluxos de 
informação. 
Existem atualmente sistemas para gerenciamento de voluntariado, como por 
exemplo: ​ivolunteer , ​samaritan , ​signup , ​whentohelp e ​yourvolunteers . 3 4 5 6 7
Entretanto, essas soluções disponíveis, de modo geral, são sistemas genéricos, 
desenvolvidos de modo a atingir o máximo de clientes possíveis para 
comercialização. Não foi encontrado um sistema que tivesse funcionalidades 
3 https://ivolunteer.com/ 
4 https://samaritan.com/ 
5 https://signup.com/ 
6 https://whentohelp.com/ 
7 https://yourvolunteers.com 
específicas para as necessidades da CnE e que também se preocupasse em ter um 
interface moderna de fácil usabilidade. Além disso, todos os sistemas mais 
robustos encontrados são de código fechado e com diversas funcionalidades pagas. 
No intuito de desenvolver um sistema que supra essas necessidades 
expostas acima, foi desenvolvido um trabalho prévio de TCC (MAESTRI, 2018) 
onde foi levantado um conjunto de funcionalidades e produzido um protótipo de 
sistema. No entanto, o resultado desse trabalho produziu um protótipo inicial de 
sistema, sem contemplar as necessidades de robustez e usabilidade de um sistema 
para ser colocado em produção e sem abranger todos os requisitos necessários. 
Assim, é necessário implementar um sistema completo para ser colocado em 
produção, atendendo a todos os requisitos aprovados pelos responsáveis da CnE, 
interface web com boa experiência do usuário, e principalmente preocupado com 
usabilidade e robustez. 
A vista disso, espera-se que a existência de uma ferramenta web que 
automatize o processo completo de voluntariado da CnE facilite a interação 
empresa-escola como também aumente e retenha o interesse de voluntários nessa 
iniciativa. 
 
1.2 Objetivos 
1.2.1 Objetivo Geral 
Analisar, desenvolver e implantar uma aplicação web de gerência do processo de 
voluntariado para a iniciativa Computação na Escola. A aplicação deve contemplar o 
cadastro de: empresas, escolas e voluntários; funcionalidade de avaliação de 
eventos pelas entidades participantes; e a administração geral do processo de 
voluntariado. 
 
1.2.2 Objetivos Específicos 
a) Analisar a literatura e o estado da arte dos sistemas de suporte ao voluntariado; 
b) Analisar e modelar uma solução técnica para um sistema de suporte ao processo 
de voluntariado; 
c) Desenvolver módulos web responsáveis pelo cadastro de empresas, escolas e 
voluntários; avaliação de eventos e administração geral dos processos da 
computação na escola. 
c) Implantar em produção e avaliar os resultados do uso. 
 
 
 
 
 
1.3 Metodologia 
Com o objetivo de alcançar o escopo deste trabalho, foi adotada uma metodologia 
de pesquisa e desenvolvimento em 5 etapas: 
 
Etapa 1: Investigação da literatura sobre os conceitos essenciais ao tema deste 
trabalho. Essa etapa é composta pelas seguintes atividades: 
Atividade 1.1: Análise da literatura sobre conceitos de gestão de voluntariado. 
Atividade 1.2: Análise da literatura sobre as tecnologias utilizadas no 
desenvolvimento de sistemas web, como JavaScript, HTML5, CSS e NodeJS. 
 
Etapa 2: Levantamento e mapeamento sistemático do estado da arte sobre 
conceitos e gestão do voluntariado. Essa etapa é composta pelas seguintes 
atividades: 
Atividade 1.1: Definição dos termos e estrutura das buscas. 
Atividade 1.2: Execução das buscas e seleção de trabalhos relevantes. 
Atividade 1.3: Análise da apuração dos trabalhos. 
 
Etapa 3: Análise e engenharia de requisitos que atendam as necessidades dos 
usuários do sistema de voluntariado. Essa etapa é composta pelas seguintes 
atividades: 
Atividade 1.1: Realização de entrevistas com membros e ex-membros da CnE. 
Atividade 1.2: Análise dos dados obtidos nas entrevistas e reformulação dos 
requisitos do sistema. 
 
Etapa 4: Modelar e implementar o sistema web de auxílio ao processo de 
voluntariado da iniciativa CnE. Essa etapa é composta pelas seguintes atividades: 
Atividade 1.1: Modelagem do banco de dados, classes e funções utilizando 
diagramas UML. 
Atividade 1.2: Modelagem e definição dos protótipos de tela. 
Atividade 1.3: Desenvolvimento e implementação dos módulos do sistema. 
 
Atividade 1.4: Testes exploratórios para detecção de problemas no sistema . 
 
Etapa 5: Implantação e avaliação da usabilidade e funcionalidades do sistema. Essa 
etapa é composta pelas seguintes atividades: 
Atividade 1.1: Implantação do sistema em ambiente de produção. 
Atividade 1.2: Planejamento dos métodos de avaliação. 
Atividade 1.3: Execução da avaliação e validação com os responsáveis da iniciativa 
CnE. 
Atividade 1.4: Análise dos resultados do processo de avaliação. 
 
 
2. FUNDAMENTAÇÃO TEÓRICA 
São abordados neste capítulo conceitos teóricos centrais e necessários para 
compreensão do domínio deste trabalho. Em primeiro momento é apresentado o 
conceito de voluntariado. Em um segundo momento é debatido aspectos técnicos 
relacionados a implementação da solução proposta por este trabalho. 
2.1 Voluntariado 
 Tomando base a lei nº 9608/1998 (BRASIL, 1998), o serviço de voluntariado 
é definido por algumas diretrizes: 
1 - É uma atividade não remunerada; 
2 - Pode ser prestada por pessoa física ou instituição privada, mas que não 
tenha fins lucrativos; 
3 - Possua caráter e objetivos cívicos, culturais, educacionais, científicos, 
recreativos ou de assistência social. 
Como resultado, tal serviço não gera vínculo empregatício, nem obrigação de 
natureza trabalhista. 
No Brasil, aproximadamente 7.4 milhões de pessoas realizam algum tipo de 
trabalho voluntário, sendo equivalente a 4.4% da população com mais de 14 anosde idade (DE OLIVEIRA, 2018). Ainda nessa pesquisa, o perfil dos voluntários é 
prioritariamente de mulheres, 5,1% comparado a 3,5% dos homens. Além disso, a 
dedicação ao trabalho voluntário é maior entre as pessoas que possuem alguma 
ocupação comparado a outros que não são ocupados e existe uma maior 
porcentagem de participação entre pessoas mais velhas. 
Algumas grandes empresas que adotam programas de voluntariado no Brasil 
pode-se citar: Santander, Bosch e Nextel. Alguns benefícios citados, tanto por 
empresas como pelos funcionários que participam de ações de voluntariado, são o 
desenvolvimento de noções de trabalho em equipe, integração e solidariedade. 
Tais pontos contribuem para um melhor clima organizacional e consequentemente 
uma melhor produtividade e saúde organizacional (INÁCIA, 2019). 
No entanto, assim como existe uma tendência de crescimento do número de 
pessoas que desejam participar de ações voluntárias, existe um elevado índice de 
evasão em atividades de voluntariado, que entre alguns fatores, pesquisam 
apontaram que a principal e possível causa é a utilização de uma gestão não 
apropriada (OLIVEIRA, 2007). 
A gestão do voluntariado é o ato de estabelecer objetivos para atingir a 
finalidade proposta, se comprometendo com eficácia, eficiência e efetividade de seu 
voluntariado (RAMOS, 2016). Para que isso ocorra é essencial que a gestão 
implemente um sistema de regras, supervisão e motivação, tornando possível 
aproveitar de forma otimizada o potencial do trabalho voluntário. 
De acordo com Marcos e Amador (2014), a gestão do voluntariado pode ser 
analisada com um conjunto de fases bem definidas onde cada uma possui objetivos 
e atividades consideradas como práticas promotoras de gestão eficaz e eficiente de 
voluntariado: 
 
Figura 1 - Fases do ciclo de gestão do voluntariado (MARCOS; AMADOR, 
2014). 
1 - Tem como objetivo contextualizar o voluntário na organização e na 
estrutura de sua gestão, tendo como boas práticas a elaboração de um plano de 
voluntariado e criação de uma ferramenta de gestão que permita replicar os 
procedimentos em toda a organização. 
2 - Define as funções do voluntário, através do mapeamento de perfis 
sociodemográficos, escolares e profissionais. 
3 - Entrada e onboarding do voluntário na organização, realizado através do 
compromisso de colaboração, definindo direitos e deveres de ambas as partes. 
4 - Acompanhamento das atividades do voluntário durante suas ações, onde 
boas práticas de comunicação com líderes e integrantes do grupo possibilitam um 
acompanhamento contínuo e a manutenção da satisfação e expectativas e 
necessidades dos integrantes. 
5 - Desenvolvimento de ações de reconhecimento e valorização do 
desempenho de voluntários, manifestadas de inúmeras formas como certificados, 
prêmios ou atos públicos. 
6 - Consolidação de todas as etapas anteriores e manutenção da relação 
posterior entre a organização e o voluntário, através processos de orientação da 
saída e avaliação do voluntariado, além de comunicação regular divulgando novas 
atividades e convocações. 
2.2 Aplicação web 
Uma aplicação web pode ser definida como um sistema de informática que 
utiliza um navegador para acesso e emprega tecnologias web como HTML, 
Javascript e CSS (APLICAÇÃO WEB, 2019). Se organiza em uma estrutura de 
arquitetura denominada cliente-servidor, onde o browser é o cliente que solicita 
requisições ao servidor web, que possui a responsabilidade de processar e devolver 
esta determinada resposta (DEVMEDIA, 2012). 
Figura 2 - Comunicação request-response. (DEVMEDIA, 2012) 
O protocolo de comunicação utilizado entre cliente e servidor é o protocolo 
HTTP, que define a estrutura dos pacotes de comunicação, em outras palavras, 
quais dados e metadados podem ser inseridos em cada mensagem de ​request ou 
response (ALURA, 2019). Na figura 3 e 4 pode-se observar uma representação das 
estruturas de request e response respectivamente: 
 
Figura 3 - Representação de request HTTP 
 
Figura 4 - Representação de response HTTP 
2.2.1 Tecnologias 
Esta seção trata da apresentação de algumas das principais 
tecnologias utilizadas no desenvolvimento da solução. 
2.2.1.1 Servidor 
 
2.2.1.1.1 PostgreSQL 
 
PostgreSQL é um sistema de gerenciamento de banco de dados 
objeto-relacional que usa e estende a linguagem SQL. Algumas de suas principais 
características e pontos fortes são: arquitetura e conjunto de recursos robustos; 
integridade de dados, manutenção e evolução por parte da comunidade de código 
aberto . O serviço utiliza a linguagem SQL, popularmente conhecida para inserir, 8
acessar e gerenciar o conteúdo armazenado no banco de dados. 
8 https://www.postgresql.org/ 
2.2.1.1.2 Node.js 
 
O Node.js é um ambiente de execução javascript, que no contexto de modelo 
de aplicação cliente-servidor, se encontra do lado do servidor. Entre algumas 
vantagens de sua utilização estão: flexibilidade em instalar dependências para 
situações específicas; leveza pelo fato de seu ambiente não necessitar de grandes 
recursos computacionais e utilização de mesma linguagem no frontend e backend, 
já que javascript é a linguagem padrão para desenvolvimento web (OPUS, 2018). 
2.2.1.2 Cliente 
2.2.1.2.1 React 
 
O React é uma biblioteca javascript declarativa, eficiente e flexível criada em 
2011 pelo Facebook, com a principal função de criar interfaces através da 
estruturação da aplicação em componentes reutilizáveis. (MEDIUM, 2018) . Outro 
diferencial é o uso do conceito de Virtual DOM: uma representação de uma árvore 
de objetos que são comparados com a DOM real no browser nos processos de 
renderização. Apenas os componentes que tiveram seus estados modificados são 
re-renderizados, tornando o carregamento e atualização de páginas webs muito 
mais rápidas e elemento-específicas (IMASTERS, 2019). Está é a definição de 
Single Page Application - SPA - onde o aplicativo web reage a interação do usuário 
reescrevendo dinamicamente apenas elementos necessários, ao invés do padrão 
do navegador carregar páginas novas inteiras após receber ações ou novos dados 
de um servidor da web (​SINGLE PAGE APPLICATION, 2020​). Com isso se atinge 
o principal objetivo que é realizar transições mais rápidas e que façam o site se 
comportar como se fosse um aplicativo nativo, oferecendo uma melhor experiência 
ao usuário. 
3. ESTADO DA ARTE 
 
O mapeamento do estado da arte foi realizado por meio de ferramentas de 
busca na web. Foi utilizado como base de pesquisa o Google Scholar , pois realiza 9
suas buscas em uma grande variedade de bases de dados e possui uma boa 
funcionalidade de filtros que facilitam a triagem de resultados. Apenas termos em 
português e inglês foram usados nas buscas, sendo que somente resultados nesses 
dois idiomas foram analisados. O período de pesquisa está compreendido entre 
2015 até 2019. 
 
3.1 Protocolo de pesquisa 
 
De forma a planejar a realização da busca pelo estado da arte, é definido um 
protocolo de pesquisa, que busca responder a seguinte pergunta de pesquisa: quais 
e como são as ferramentas de apoio ao processo de voluntariadoatualmente 
disponíveis? 
 
Critérios de inclusão 
 
- O material encontrado deve apresentar features do sistema que possibilitam 
a análise e enquadramento na resolução das necessidades do sistema de 
apoio para voluntariado da iniciativa Computação na Escola. 
9 https://scholar.google.com.br 
- O material encontrado deve ser específico para gestão de processos de 
voluntariado em iniciativas de responsabilidade social. 
 
 
Critérios de exclusão 
 
- Os estudos que não possibilitem o acesso ao sistema serão desconsiderados 
devido a impossibilidade de se testar funções e interface. 
 
Critérios de qualidade 
 
- Os estudos devem preferencialmente dar soluções e se relacionar com todas 
as necessidades que o sistema de apoio para voluntariado da iniciativa 
Computação na Escola deve atender. 
- O material encontrado deve utilizar tecnologias recentes (até 5 anos) e 
levarem em consideração interface e usabilidade do sistema. 
 
Tabela 1​ - Termos de busca 
 
 
 
Termo Sinônimos Traduções 
Sistema Web Aplicativo, Aplicação, Sistema 
Informatizado, Software 
Web System, Application, 
Computerized System, Software, 
Gerenciamento 
de Processos 
Gestão, Controle Process Management, 
Management 
Voluntariado Responsabilidade Social, 
Terceiro Setor 
Social Responsibility, Corporate 
Social Responsibility / CSR, 
Voluntary, Voluntary Sector / 
Community Sector 
Tabela 2​ - Strings de busca 
 
 
Nº String de Busca 
Pesquisas por palavras chaves apenas nos títulos 
1 allintitle:(("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema 
Informatizado") AND ("Gerenciamento de Processos" OR "Gestão" OR 
"Controle") AND ("Voluntariado" OR "Responsabilidade Social" OR 
"Terceiro Setor")) PERIOD (2015 to 2019) 
2 allintitle:(("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema 
Informatizado") AND ("Gerenciamento de Processos" OR "Gestão" OR 
"Controle")) PERIOD (2015 to 2019) 
3 allintitle:(("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema 
Informatizado") AND ("Voluntariado" OR "Responsabilidade Social" OR 
"Terceiro Setor")) PERIOD (2015 to 2019) 
4 allintitle:(volunteer management system) PERIOD (2015 to 2019) 
Pesquisas por palavras chaves livre 
5 ("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema 
Informatizado" OR "Web System" OR "Application" OR "Computerized 
System" OR "Software") AND ("Gerenciamento de Processos" OR 
"Gestão" OR "Controle" OR "Process Management" OR "Management") 
AND ("Voluntariado" OR "Responsabilidade Social" OR "Terceiro Setor" 
OR "Social Responsibility" OR "Corporate Social Responsibility/ CSR" OR 
"Voluntary" OR "Voluntary Sector/ Community Sector") PERIOD (2015 to 
2019) 
6 ("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema 
Informatizado") AND ("Gerenciamento de Processos" OR "Gestão" OR 
"Controle") AND ("Voluntariado" OR "Responsabilidade Social" OR 
"Terceiro Setor") PERIOD (2015 to 2019) 
7 ( "Web System" OR "Application" OR "Computerized System" OR 
"Software") AND ( "Process Management" OR "Management") AND 
("Social Responsibility" OR "Corporate Social Responsibility/ CSR" OR 
"Voluntary" OR "Voluntary Sector/ Community Sector") 
Pesquisas por frases específicas livre 
8 Sistema web de apoio a gestão de voluntariado PERIOD (2015 to 2019) 
9 Web system to support volunteer management PERIOD (2015 to 2019) 
3.2 Execução das buscas 
 
As buscas foram realizadas durante os meses de Maio a Julho de 2019, gerando 
um total de 11 iterações de buscas. 
 
Tabela 3​ - Resultado das strings de busca executadas 
 
 
 
Primeira a Nona Execução 
 
A tabela 3 apresenta o resultado das 9 primeiras interações realizadas no google 
scholar. Foram utilizadas 3 formas de pesquisa: 
 
Nº String de Busca 
Pesquisas por palavras chaves apenas nos títulos 
1 0 
2 7 
3 0 
4 7 
Pesquisas por palavras chaves livre 
5 * 1.110.000 
6 14.600 
7 64.300 
Pesquisas por frases específicas livre 
8 9.960 
9 18.900 
1 - Palavras chaves apenas nos títulos dos artigo, onde se mostrou bastante 
escasso o retorno das buscas - no máximo de 7 resultados, sendo que nenhum 
destes atendeu aos critérios de inclusão. 
 
2 - Palavras chaves localizadas em qualquer parte do artigo, no qual retornou 
uma quantidade de artigos na casa dos milhares devido ao fato que muitas das 
palavras chaves serem comuns nos textos dos artigos, tornando o resultado desse 
tipo de estratégia de filtragem pouco eficiente. 
 
3 - A pesquisa por frases específicas encontradas de forma livre no artigo se 
mostrou também pouco eficiente, ao retornar um grande número de resultados que 
não se adequavam especificamente ao contexto do trabalho. 
 
Tanto o resultado escasso como o retorno de uma grande quantidade de resultados 
não específicos reforça a dificuldade de encontrar artigos que em seu conteúdo 
desenvolveram ou analisaram ferramentas de gestão neste setor. 
 
Décima e décima primeira interação 
Em razão do escasso resultado retornado pelo google scholar, foi realizado duas 
iterações de busca no Google , utilizando os termos definidos na tabela 1. A 10
décima interação foi com os termos em inglês e décimo primeiro com os termos em 
português, buscando por ferramentas correlatas. 
10 ​https://www.google.com/ 
https://www.google.com/
Após análise da documentação e uso quando possível de versões free ou 
trials, foi elencada para análise mais profunda 5 ferramentas atuais no mercado: 
 
1 - ivolunteer 11
2 - samaritan 12
3 - signup 13
4 - whentohelp 14
5 - yourvolunteers 15
 
3.3 Resultados das buscas: Ferramentas selecionadas 
 
Nesta seção são apresentadas as ferramentas encontradas que atendem os 
critérios de inclusão. 
 
 
11 ​https://ivolunteer.com/ 
12 ​https://samaritan.com/ 
13 ​https://signup.com/ 
14 ​https://whentohelp.com/ 
15 ​https://yourvolunteers.com 
https://ivolunteer.com/
https://samaritan.com/
https://signup.com/
https://whentohelp.com/
https://yourvolunteers.com/
1 - Ivolunteer 
 
 
 
Figura 5 - Interface do aplicativo Ivolunteer. 
 
O aplicativo possui período gratuito de 30 dias. Como pontos positivos possui 
um CRUD com muitas opções de configuração, tornando flexível a diversos 
cenários de gestão de voluntários. Durante a utilização no período free, foi 
constatado alguns limites de funcionalidade, como máximo de 15 voluntários, caixa 
de email com espaço de 250 mensagens e possibilidade de apenas 1 administrador. 
Ivolunteer apresenta uma alta complexidade, pois possui amplo espectro de funções 
e opções de configuração, exigindo um alto grau de entendimento das opções da 
plataforma a fim de dominá-la. Algumas funções relevantes são: possui diversos 
níveis de perfil de acesso; geração de ​QR code e upload de arquivos de apoio para 
eventos; controle de aviso de eventos; Log de atividade desde administrados até 
voluntários; envio e controle de emails customizáveis através de uma plataforma 
própria. Trabalha com 3 níveis de assinatura: ​Free​, ​Standard e ​Premium​, e nas duas 
últimas faz-se o acesso a mais funcionalidades avançadas, como por exemplo 
recebimento de pagamentos e doações. Como pontos negativos as contas de 
voluntários não possuem ​ids​, ​passwords​, sendo que basta cadastrar nome e email 
se tem acesso a plataforma. Isso pode tornar menos seguro por não possuir tantas 
informações obrigatórias dos voluntários. Outro pontoé que a aplicação é pseudo 
responsiva, pois apesar de em janelas e telas menores o site não ter apresentado 
quebras drásticas de elementos e interfaces, gerou muitas barras de rolagem e 
distribuição da informação de uma forma pouco efetiva ou atraente. Por fim, não 
possui visão de acesso das instituições parceiras e avaliação quantitativa dos 
voluntários e ou dos eventos. 
 
 
2 - Samaritan 
 
 
Figura 6 - Interface do aplicativo Samaritan. 
 
 
O sistema possui 3 níveis de assinatura: Simples, Standard e PRO. Como 
funcionalidades relevantes possui: número ilimitado de voluntários; envio de email 
em massa; busca por oportunidades de voluntariado através de diversos filtros e 
interesses; upload de documentos necessários; controle de horas disponibilizadas 
em eventos de voluntariado; função intuitiva de controle de agenda utilizando drag 
and drop. Em versões pagas adiciona algumas opções avançadas como verificação 
de antecedentes criminais e log de atividades. Como ponto negativo é necessário se 
submeter a um processo relativamente burocrático apenas para testar a versão free, 
sendo obrigatório solicitar o demo enviando uma grande quantidade de dados sobre 
o interessado. 
 
3 - Signup 
 
 
Figura 7 - Interface do aplicativo SignUp. 
 
O aplicativo possui 3 formas de assinatura: Starter, Plus e Max. Possui uma 
interface semi responsiva por não demonstrar quebras de elementos em tamanhos 
de janela menores em browsers ou acesso mobile, mas que gera uma redistribuição 
da informação e de alguns elementos em tela pouco intuitivos ou agradáveis à 
experiência do usuário. Como funcionalidades positivas e relevantes têm-se: 
dashboard com calendário de eventos; envio de email; controle de participantes em 
cada evento de voluntariado; envio de email como forma de convite e cadastro na 
plataforma; geração de link compartilhável do evento de voluntariado; função de 
coleta de contribuições e fundos monetários. Nas versões pagas possui serviço de 
permissão digital com intuito de minimizar burocracia e a utilização de documentos 
físicos e também possui o serviço de geração de relatórios dos projetos de 
voluntariado. Como pontos negativos sua versão free possui muitos anúncios 
distribuídos pela interface e o cadastro de usuário é realizado de uma forma pouco 
segura, necessitando apenas de email, nome e telefone. 
 
4 - Whentohelp 
 
 
Figura 8 - Interface do aplicativo Whentohelp. 
 
O aplicativo possui duas formas de assinatura: ​Lite version e ​Full version​. A 
versão ​Lite possui um período de 30 dias free e depois possui também um pequeno 
valor para continuar a utilização. Existem poucas diferenças de funcionalidade entre 
as duas assinaturas, sendo a diferença maior é no tempo disponível para cada 
versão: limite de 250 voluntários cadastrados e histórico de no máximo 18 meses na 
versão ​Lite​. Já sua versão ​Full estas funções se tornam ilimitadas e ao usuário é 
permitido salvar mensagens internas por mais de 30 dias, exportar seus dados em 
diversos formatos de arquivo, entre outras. Algumas funcionalidades relevantes em 
comum são: perfis de acesso para gerenciadores de eventos e voluntários; sistema 
de email e notificações de alertas de mensagens; sistema de ​like e ​deslike de 
eventos; função para voluntários adicionar suas habilidades e características em 
seu perfil pessoal; possibilidade de acesso de login mobile tanto para 
coordenadores como para voluntários; analisador de conflito de data e hora entre 
eventos. Seus principais pontos negativos é que sua versão free possui um limite 
baixo para quantidade máxima de voluntários, 250 por conta, e também o fato de 
seu histórico ser de apenas até 18 meses. 
 
5 - Yourvolunteers 
 
 
Figura 9 - Interface do aplicativo Yourvolunteers. 
 
A plataforma possui 3 planos de assinatura: ​Free​, ​Premium e ​Custom​. Disponibiliza 
voluntários ilimitados; possui um tutorial no moldes ​step-by-steps na primeira vez 
que um usuário se cadastrar e logar no sistema; apresenta aceite de termos de uso 
e resumo de atividades dos usuários além de integração e visualização do 
calendário do voluntário. A versão ​free no entanto apresenta muitos anúncios 
distribuídos pela interface, tornando a experiência do usuário incomoda e poluída. 
Por fim, o sistema de email está disponível apenas nas versões pagas. 
3.4 Análise dos resultados 
A fim de analisar os aplicativos elencados, foram especificados alguns 
requisitos iniciais, tomando como base o TCC anterior da ferramenta (MAESTRI, 
2018) e por meio de entrevista presencial com um dos coordenadores da CnE. 
Abaixo segue a subdivisão destes em requisitos funcionais e não funcionais: 
 
 
• RF1 - O sistema deve permitir o cadastro de voluntários. 
• RF2 - O sistema deve possuir o cadastro de representantes das empresas. 
• RF3 - O sistema deve possuir o cadastro de representantes das instituições 
beneficiadas. 
• RF4 - O sistema deve permitir o cadastro de eventos de voluntariado. 
• RF5 - O sistema deve permitir o cadastro de treinamentos. 
• RF6 - O sistema deve permitir a avaliação dos eventos de voluntariado. 
 
• RNF1 - O sistema deve ter todas suas funcionalidades gratuitas. 
• RNF2 - O sistema deve ter seu código Open-Source. 
• RNF3 - O sistema deve ser uma Aplicação web responsiva. 
• RNF4 - O sistema deve ter uma interface amigável, norteada por boas práticas de 
UX Design. 
 
A tabela 4 expõe um quadro comparativo apontando a ocorrência ou ausência dos 
requisitos básicos acima nos aplicativos do mercado elencados. Temos 4 graus de 
atendimento de cada requisito: 
T - Totalmente atendido 
P - Parcialmente atendido 
N - Não atendido 
NT - Não testado 
 
Tabela 4 ​- Análise de atendimento as funcionalidades 
 
Ivolunteer​, ​Signup e ​Whentohelp possuem RF1 parcialmente atendido por 
existir uma limitação de quantidade de voluntários cadastrados. 
RF2 se apresenta apenas parcialmente como uma funcionalidade possível no 
Whentohelp pois é possível definir um controle de perfil que possibilita simular um 
tipo de perfil diferente. A mesma situação ocorre para o caso da RF3. Todos os 
outros aplicativos trabalham apenas com a figura de um ou mais administradores 
que gerem os voluntários que se cadastram aos sistemas. 
 RF1 RF2 RF3 RF4 RF5 RF6 RNF1 RNF2 RNF3 RNF4 
Ivolunteer P N N T P N N N P P 
samaritan T NT NT T PT N N N P P 
signup P N N T N N N N P P 
whentohelp P P P T P T N N P P 
yourvolunteers T N N T N N N N P P 
Para o RF4, todos os sistemas apresentam a funcionalidade, inclusive em em 
suas versões gratuitas. 
Ivolunteer e whentohelp apresentam parcialmente a funcionalidade RF5 de 
cadastro de treinamentos, pois apesar de não terem a opção de criar eventos de 
diferentes tipos além do voluntariado, pode-se simular eventos treinamentos através 
da criação de eventos que tem como anexo de documentos e vídeos utilizados para 
treinamento. 
Das 5 ferramentas elencadas, apenas o ​Whentohelp apresenta 
funcionalidades de avaliação de eventos (RF6). 
Algumas funcionalidades não puderam ser testadas completamente devido o 
acesso destas apenas em versões pagas, como é o caso do aplicativo ​Samaritan​. 
No entanto,para todos os casos, foi consultado nos sites e documentação oficial de 
cada ferramenta sobre a disponibilidade ou não das funcionalidades elencadas. 
Dentre todas as plataformas de gestão analisadas, pode-se observar que 
Whentohelp é a que mais se aproxima das necessidades da CnE. Ainda sim não 
atende uma série de requisitos básicos, como acesso a todos funcionalidades de 
forma gratuita e possuir interface intuitiva e responsiva. 
A análise da ​stack tecnológica de cada sistema não foi possível ser realizada 
pois nenhuma das plataformas são de código aberto e em sua documentação não 
havia material contendo informação sobre esse aspecto. 
Diante da análise das plataformas elencadas e de outras possibilidades não 
citadas no presente trabalho, mas que foram encontradas durante as pesquisas, 
tem-se o conhecimento de diversas aplicações no mercado que possuem o papel de 
auxiliar na gestão de processos de voluntariado. Porém nenhuma destas consegue 
atender tanto aos requisitos básicos citados acima como outros requisitos que serão 
adicionados e debatidos ao decorrer deste documento. Dessa forma chega-se à 
conclusão que é necessário o desenvolvimento e implementação de uma sistema 
específico para o contexto da iniciativa Computação na Escola. 
4 PROPOSTA DE SOLUÇÃO 
O processo de elaboração da solução deste trabalho se desenvolve a partir 
de 4 fases: 1- definição de requisitos funcionais e não-funcionais através da análise 
do fluxo do processo de gestão de voluntários; 2- levantamento dos casos de uso e 
seus respectivos detalhamentos; 3 - definição de protótipos de tela; 4 - modelagem 
inicial de banco de dados. 
O objetivo principal da solução é a implementação de um sistema web que 
tenha o papel de apoiar o processo de gestão de todas as partes que compõem o 
processo de voluntariado, no contexto da iniciativa Computação na Escola. Para o 
desenvolvimento deste sistema foi adotado a ​stack de tecnologia javascript, devido 
a sua importância no cenário atual de tecnologia web e sua alta capacidade de 
tornar as páginas interativas (DA SILVA, 2019). 
4.1 Requisitos 
O levantamento de requisitos da solução foi realizado em 3 etapas distintas. 
A primeira etapa foi executada por meio de entrevista com o coordenador do 
projeto, onde foi exposto o domínio geral da necessidade a ser sanada. Além disso, 
foram apresentadas as expectativas da iniciativa CnE com relação às 
funcionalidades que o sistema deve atender, principalmente no que tange a 
implementação de produto com caráter profissional de uso. 
Em um segundo momento foi realizado mapeamento bibliográfico e 
levantamento de ferramentas existentes no mercado, descritas e elencadas na 
seção 4.1 deste documento, além do próprio TCC produzido anteriormente que se 
relaciona com essa solução (MAESTRI, 2018). Logo após, essas fontes foram 
utilizadas como material de apoio para identificação de novas funcionalidades ou 
aperfeiçoamento de requisitos previamente levantados na primeira etapa. 
Na terceira etapa, com os requisitos e protótipos de telas produzidos através 
de anotações reunidas na segunda etapa, foram feitas entrevistas com uma pessoa 
relacionada a CnE e com o coordenador do projeto a fim de validar e confirmar as 
propostas desenvolvidas. 
Ao fim dessas etapas foi produzido o fluxograma de gestão do processo de 
voluntariado, apresentado em duas partes nas figuras 10 e 11 logo abaixo: 
 
Figura 10 - Fluxograma do processo de voluntariado - Parte 1. 
 
Figura 11 - Fluxograma do processo de voluntariado - Parte 2. 
O resultado das 3 etapas foi a definição dos requisitos funcionais apresentado na 
tabela 5 e dos requisitos não funcionais apresentado na tabela 6: 
 
Tabela 5​ - Requisitos Funcionais 
Identificação Descrição 
RF1 O sistema deve permitir o cadastro do representante da escola 
na plataforma. 
RF2 O sistema deve permitir ao RCnE avaliar o formulário de 
cadastro do representante da escola. 
RF3 O sistema deve permitir o cadastro do representante da empresa 
na plataforma. 
RF4 O sistema deve permitir ao RCnE avaliar o formulário de 
cadastro do representante da empresa. 
RF5 O sistema deve permitir ao representante da empresa convidar 
por email potenciais voluntários. 
RF6 O sistema deve permitir o cadastro do voluntário na plataforma. 
RF7 O sistema deve permitir ao representante da empresa avaliar a 
solicitação de vínculo do voluntário à empresa. 
RF8 O sistema deve permitir ao voluntário enviar arquivos 
necessários. 
RF9 O sistema deve permitir ao representante da empresa 
recomendar a inscrição de voluntários. 
RF10 O sistema deve permitir ao RCnE avaliar a inscrição de 
voluntário recomendada. 
RF11 O sistema deve permitir ao RCnE criar, editar, deletar e acessar 
empresas. 
RF12 O sistema deve permitir ao RCnE criar, editar, deletar e acessar 
voluntários. 
 
 
RF13 O sistema deve permitir ao RCnE criar, editar, deletar e acessar 
projetos. 
RF14 O sistema deve permitir ao RCnE criar, editar, deletar e acessar 
eventos. 
RF15 O sistema deve permitir ao RCnE criar, editar, deletar e acessar 
escolas. 
RF16 O sistema deve permitir ao RCnE anexar documentos aos 
eventos. 
RF17 O sistema deve permitir ao RCnE e Voluntários avaliar 
treinamentos. 
RF18 O sistema deve permitir ao RCnE, representante da escola e 
voluntários avaliar mentorias. 
RF19 O sistema deve permitir ao RCnE acessar histórico de projetos e 
eventos. 
Tabela 6​ - Requisitos Não-Funcionais 
 
4.2 Casos de uso 
Por meio da análise dos requisitos definidos e do fluxograma apresentado 
nas figuras ​10 e 11​, foram identificadas quatro entidades externas que irão interagir 
com a solução, representando 4 papéis de atores no diagrama de casos de uso. 
São esses: Responsável na Computação na Escola (RCnE), Representante da 
escola, Representante da empresa e Voluntário. 
Além da identificação dos atores, foram analisados os requisitos funcionais 
de forma a identificar os casos de uso e, a partir desses, elaborar o diagrama de 
casos de uso. A figura ​12 apresenta o diagrama de caso de uso da plataforma de 
gestão do voluntariado. 
 
Identificação Descrição 
RNF1 O sistema deve ter todas suas funcionalidades gratuitas. 
RNF2 O sistema deve ser ​Open-Source​. 
RNF3 O sistema deve ser uma aplicação web. 
RNF4 O sistema deve possuir design responsivo nas interfaces 
gráficas. 
 
 
Figura 12 - Diagrama de casos de uso. 
 
A tabela ​7​ apresenta o que cada ator representa no mundo real e quais são 
os casos de uso que cada um respectivamente poderá acessar no sistema. 
 
 
Tabela 7​ - Atores e Permissões 
 
 
A tabela ​8 exibe a relação entre os casos de uso e quais requisitos funcionais 
estes atendem. Pode-se observar que todos os requisitos nomeados na tabela 5 
foram atendidos pelo grupo de casos de uso apresentados na imagem 7: 
 
Ator Descrição Casos de Uso Permitidos 
RCnE Representa 
coordenadores ou 
pessoas responsáveis 
pela gestão da CnE. 
UC1 - CRUD de 
Empresa. 
UC2 - CRUD de projetos. 
UC3 - CRUD de eventos. 
UC4 - CRUD de 
voluntários. 
UC6 - Alocar voluntários. 
UC7 - Avaliar 
recomendação de 
voluntário. 
UC8 - Avaliar eventos e 
projetos. 
UC9 - CRUD de escola. 
Representante da escola Representa a pessoa 
responsávelna escola 
pela comunicação e 
decisões oficiais 
relacionadas à relação 
com a CnE. 
UC9 - CRUD escola. 
UC10 - Avaliar mentoria. 
Representante da empresa Representa a pessoa 
responsável na 
empresa pela 
comunicação e 
decisões oficiais 
relacionadas à relação 
com a CnE. 
UC1 - CRUD de empresa. 
UC13 - Avalia solicitação 
de vínculo de voluntário. 
UC5 - Recomendar 
voluntário. 
Voluntário Representa a pessoa 
que irá executar 
mentorias através das 
iniciativas da CnE. 
UC4 - CRUD de 
voluntários. 
UC12 - Gerar termo de 
voluntariado. 
UC11 - Gerar termo de 
responsabilidade. 
UC10 - Avaliar mentoria. 
Tabela 8​ - Rastreabilidade entre os casos de uso e requisitos 
funcionais 
 
 
As tab​elas 9 e 10 a seguir evidenci​am com mais detalhamento os casos de 
uso “CRUD de voluntários” e “Avaliar mentoria”. Demais detalhamento dos casos de 
uso se encontram no apêndice A. 
 
Casos de uso Requisitos 
UC1 RF11, RF4 
UC2 RF13 
UC3 RF14, RF13, RF16 
UC4 RF12, RF5, RF6, RF8 
UC5 RF9 
UC6 RF9, RF10 
UC7 RF10 
UC8 RF17 
UC9 RF15, RF1, RF2 
UC10 RF18, RF19 
UC11 RF8 
UC12 RF8 
UC13 RF7 
Tabela 9​ - Detalhamento de caso de uso: UC4 - CRUD de voluntários. 
 
 
Nome do Caso de Uso UC4 - CRUD de voluntários 
Pré-Condições Ter a empresa ao qual se vincula cadastrada e 
solicitação de vínculo aceita. 
Atores Envolvidos Voluntário. 
Resumo Descreve os passos necessários para que o usuário 
cadastre um voluntário. 
Fluxo Principal - Criar Voluntário 
1. O usuário clica em “novo” na página de dashboard de Voluntários. 
2. O sistema apresenta uma modal contendo o formulário de cadastro de 
voluntário. 
3. O usuário preenche os dados necessários. 
4. O usuário clica em “salvar”. 
5. O sistema salva os dados no banco de dados e envia um e-mail avisando 
sobre o novo acesso. 
Fluxo de Exceção I - Campos obrigatórios não preenchidos 
1. No passo 4 do fluxo principal o sistema emite uma mensagem informando 
que há campos obrigatórios não preenchidos. 
2. O sistema retorna para o passo 3 do fluxo principal. 
Tabela 10​ - Detalhamento de caso de uso: UC10 - Avaliar mentoria. 
 
4.3 Prototipação de Telas 
Esta seção apresenta alguns protótipos de tela, sendo a relação com seus 
respectivos casos de uso mapeados na tabela abaixo: 
 
Nome do Caso de Uso UC10 - Avaliar mentoria 
Pré-Condições Ter evento com o status “aguardando avaliação”. 
Atores Envolvidos RCnE, Representantes da escola e Voluntários. 
Resumo Descreve os passos necessários para que RCnE, 
Representantes da escola e Voluntários possam 
avaliar o evento de voluntariado. 
Fluxo Principal - Avaliar Mentoria 
1. O usuário clica no evento a ser avaliado no dashboard de Eventos. 
2. O sistema apresenta uma modal contendo os dados do evento, onde um 
dos campos é a avaliação do evento. 
3. O usuário preenche os dados necessários. 
4. O usuário clica em “Avaliar”. 
5. O sistema salva a avaliação no banco de dados e retorna uma mensagem 
de sucesso para o usuário. 
Fluxo de Exceção I - Campos obrigatórios não preenchidos 
1. No passo 6 do fluxo principal o sistema emite uma mensagem informando 
que há campos obrigatórios não preenchidos. 
2. O sistema retorna para o passo 5 do fluxo principal. 
Tabela 11​ - Mapeamento Casos de uso e protótipos de tela 
 
 
Logo abaixo são apresentados os protótipos da “Tela inicial” para UC3, “Tela 
de Voluntários” e “Tela de edição de Voluntários” para UC4. Demais protótipos de 
tela se encontram no apêndice B. 
 
 
 
Figura 13 - Protótipo de tela inicial 
Caso de Uso Protótipo de tela 
UC3 Figura 13 
UC4 Figura 14 e 15 
UC2 Figura 21 (Apêndice B) 
UC3 Figura 22 E 23 (Apêndice B) 
UC1, UC9 Figura 24 (Apêndice B) 
 
 
Figura 14 - Protótipo de tela de Voluntários 
 
 
 
Figura 15 - Protótipo de tela de edição de Voluntários 
4.4 Modelagem do banco de dados 
Esta seção apresenta o mapeamento das entidades relacionadas ao sistema 
CnE - Volunteer através do diagrama ER abaixo. O sistema de gerenciamento de 
banco de dados adotado para o desenvolvimento desta solução foi o MYSQL. 
 
 
Figura 16 - Diagrama Entidade Relacional do CnE - Volunteer 
 
 
 
 
5 DESENVOLVIMENTO 
Este capítulo apresenta passo a passo todo o processo de concepção, 
desenvolvimento e implementação da plataforma Doate. Esclarece decisões de 
projeto, como por exemplo: seleção da tecnologia empregada; utilização de Designs 
Patterns; processo criativo do nome; origem das cores e logo empregados na 
interface visual da web; apresentação da versão final das principais telas referentes 
ao fluxo central do programa. 
5.1 - Processo criativo de concepção do nome 
 
Para criar o nome para a plataforma foi utilizado o aplicativo Whimsical . 16
Esta plataforma é um ​workspace online que possibilita a criação de ​wireframes​, 
flowcharts e ​mind maps​, sendo este último, utilizado como apoio na concepção do 
nome selecionado neste trabalho. Na figura 17 logo abaixo, pode-se observar que a 
palavra "Voluntário" é o ponto inicial, e a partir dela realizou-se um processo de 
brainstorm de outras palavras e ideias correlatas ao contexto do sistema, 
considerando que a relação "escolas - empresas - Cne/UFSC" fosse adotada como 
ideia basal e que fosse remetida no nome final. Tal ideia foi plotada separadamente, 
ao lado direto no mapa mental, em amarelo. 
16 https://whimsical.com 
 
Figura 17 - Mapa mental de concepção do nome da aplicação 
 O próximo passo foi uma rodada de novas palavras e ideias correlatas, onde 
entre algumas possibilidades, optou-se pelo conceito do nome ser uma sigla 
"simples" e "sonora", o que contribuiria para os usuários lembrarem e reconhecerem 
facilmente o sistema. Por fim, realizou-se uma última rodada, utilizando anagramas 
e conexões com base nas palavras previamente plotadas das etapas anteriores. 
Gerou-se um grande número de opções - a maioria omitidas neste documento 
devido a sua não relevância - até ser selecionado 4 possibilidades. 
Em um primeiro momento, optou-se por selecionar um nome internacional, 
utilizando a língua inglesa. Dessa forma o sistema foi batizado de "CNE Volunteers". 
No entanto, mais tarde, durante o desenvolvimento do projeto, buscando encontrar 
um nome que expressasse mais o significado e conexão com o objetivo da 
plataforma, executou-se uma nova rodada de reavaliação. Dessa vez, foi 
considerado também o próprio contexto local de influência e atuação do sistema 
proposto. Como conclusão optou-se por um nome na língua nativa brasileira que 
carregava como principal significado a ideia e sigla para "Doar-se para escola". 
Assim, o sistema foi rebatizado de Doate. 
5.2 - Identidade visual 
5.2.1 - Logo 
 
Para criação do logo foi contratado um serviço de designer para criar e 
entregar um produto profissional. O designer contratado foi Thiago Martins 
Machado. Primeiro ocorreu uma reunião de alinhamento e explicação do panorama 
geral do projeto. Além disso, foi repassado quais eram as ideias norteadoras para 
sua concepção e com qual paleta de cores da identidade visual estariam 
disponíveis. 
Após algumas reuniões de ajustes interativos, foi produzido duas versões 
finais do logo, uma com título (Figura 18) e outra contendo apenas o logo (Figura 
19). 
 
Figura 18​ - Logo com título 
 
Figura 19​ - Logo sem título 
O significado principal que a configuração do logo tem como objetivo passar 
é a união e comunicação das pessoas envolvidas, o que remete ao processo 
completo de gestão realizada pelo sistema. 
5.2.2- Paleta de cores e fontes 
 
Para seleção da paleta de cores que foram utilizadas no sistema, foi 
considerado como base um documento interno oficial da identidade visual da 
iniciativa computação na escola. Após mapear-se qual grupo de cores que seria 
necessário para atender todas as demandas da interface, foram elencadas 9 cores. 
5 foram retiradas da identidade visual da CnE e mostradas na tabela abaixo: 
Tabela 12​ - Cores da identidade visual da CnE 
 
 
Outras 3 cores que eram necessárias e não existiam referência oficial na 
identidade visual da CnE, foram selecionadas de um artigo no blog QuickSprout, 
sobre tendências para 2020 de cores para web sites (PATEL, Neil, 2019). Patel é 
uma das maiores referências na área e mantém esse blog que reúne as principais 
tendências e novidades sobre marketing digital e websites. Do artigo foram 
elencadas as seguintes cores: 
Tabela 13​ - Cores selecionadas do blog QuickSprout 
 
 
Vermelho Azul claro Verde Laranja Roxo 
 
Branco Cinza Preto 
 
A última cor foi retirada do manual de identidade visual da UFSC, como 
referência do sistema a própria instituição: 
Tabela 14 - Cor selecionada da identidade visual da UFSC 
 
Para seleção da fonte utilizada no sistema foi respeitada a fonte 
utilizada na identidade visual da CnE, a Roboto. Esta fonte faz parte de uma 
família de fontes sem serifa, desenvolvida pela Google que a descreve como 
"moderna, mas acessível e emocional" (ROBOTO, 2020). É até hoje a fonte 
padrão no sistema operacional Android. 
5.2.3 - Elementos de interface 
 
Com relação ao estilo e efeitos de interação dos elementos web em tela, 
optou-se a Material-UI , uma das bibliotecas de componentes React mais utilizados 17
para desenvolvimento de aplicativos web responsivos e com base no padrão de 
design da google, o Material Design . Os motivos para a escolha dessa biblioteca 18
foram : 
● Implementa um modelo padronizado e mundialmente conhecido; 
17 https://material-ui.com/pt/ 
18 https://material.io/design 
Azul escuro 
 
● Facilidade e agilidade no processo de desenvolvimento; 
● Vasta documentação e possibilidade de estilização dos componentes; 
● Experiência do autor com esta tecnologia, a fim de minimizar eventuais 
problemas ou curva de aprendizado para sua implementação. 
5.3 - Arquitetura geral do sistema 
 
Figura 20 - Arquitetura geral do sistema Doate 
A plataforma Doate foi desenvolvida utilizando a arquitetura cliente-servidor, 
como mostrado na ​Figura 20​. É considerado uma estrutura de aplicação distribuída, 
ou seja, as tarefas e cargas de trabalho são distribuídas entre o fornecedor de um 
recurso/serviço, nesse caso sendo responsabilidade do servidor, e os requerentes 
desses serviços, o cliente. Observando a figura pode-se notar a visão geral do fluxo 
de dados: 
1 - O usuário acessa o sistema web que para carregar a página inicia o processo de 
renderização dos componentes. Durante este processo, são necessários dados que 
estão no servidor. O React então realiza requisição HTTP através do Axios (5.3.1.3), 
com o objetivo de carregar estes dados. No contexto de um formulário sendo 
preenchido pelo usuário, é utilizado o Formik (5.3.1.1) e o Yup(5.3.1.2) 
respectivamente para controle e validação dos formulários. 
2 - O servidor Node recebe e analisa a requisição onde o celebrate (5.3.2.1) realiza 
a validação dos atributos dentro do corpo da requisição. Caso esteja tudo certo o 
servidor continua o processamento separando e destinando para a rota correta de 
serviços disponíveis. 
3 - O serviço requerido realiza conexão com o banco de dados PostegreSQL, 
através do express (5.3.2.3) e do TypeORM (5.3.2.4). 
4 - Realizado a query no banco, os dados requisitados são retornados e novamente 
processados no servidor Node pelo express e pelo TypeORM. 
5- Uma vez prontos para serem retornados ao cliente, o servidor retorna a 
requisição. No caso deste trabalho existem cenários onde nesse momento são 
enviados emails pelo nodemailer (5.3.2.2) para certos destinatários. 
6 - Por fim, o cliente React recebe a resposta da requisição, se necessário este 
realiza algum processamento ou limpeza nos dados, termina o processo de 
renderização dos componentes e mostra em tela para o usuário. 
Para escolha e utilização de cada tecnologia e solução foram levados em 
consideração três requisitos por ordem de importância: 
- Ferramenta ​free​; 
- Documentação abrangente e de fácil acesso e 
- Domínio de conhecimento prévio ou que tinha baixa curva de aprendizado 
por parte do autor do trabalho a fim de manter um processo de 
desenvolvimento ágil e efetivo. 
Nos próximos tópicos será desenvolvido as principais partes e tecnologias do 
sistema, elucidando suas respectivas funções e responsabilidades. 
5.3.1 - Cliente: React 
O projeto front end foi desenvolvido com a biblioteca Javascript React. Tem 
como principal função facilitar a criação de elementos das páginas e seu controle de 
renderização de acordo com a necessidade. 
Na figura abaixo apresenta-se a estrutura básica de pastas do projeto: 
 
Figura 21 - Estrutura de pastas do projeto 
● node_modules -> Pasta que contém as dependências e bibliotecas 
instaladas e utilizadas no projeto. 
● public -> Contém a página html principal que será carregada no 
browser e outros arquivos como o ​favicon​ do site. 
● src/assets -> Contém todas as imagens e recursos locais utilizados no 
site, como por exemplo o logo. 
● src/components -> Pasta referente a todos os componentes React 
criados ou separados para utilização e/ou re-utilização. Como exemplo 
temos nessa pasta as modais e o componente de calendário 
encontrado na página de dashboard. 
● src/core -> Contém recursos diversos mas que são utilizados ou 
referenciados por toda aplicação. Por exemplo, aqui se encontra 
constantes, dicionário e chamada de serviços. 
● src/documents -> Contém os templates de renderização dos 
documentos pdfs do sistema. 
● src/pages -> Pasta referente às páginas do sistema. 
● src/Theme -> contém todos os arquivos e valores usados nas 
estilizações de componentes, como por exemplo paleta de cores e 
fonte de texto. Além disso, contém o objeto tema, utilizado pela 
biblioteca Material-ui para aplicar os estilos configurados em todos os 
componentes do sistema. 
5.3.1.1 - Formik 
O Formik é uma biblioteca Javascript responsável por facilitar a criação e 19
controle de formulários em React. Normalmente isso é um processo bastante 
verboso e que envolve várias questões como validação dos inputs, gestão do 
estado do formulário e manipulação da submissão do formulário. ​Porém, o Formik 
reúne todas essas características com sintaxe simples e intuitiva. A ​figura 22 
apresenta um exemplo de utilização do Formik na tela de criação de eventos no 
sistema Doate. Através do objeto formikProps que é acessível como parâmetro do 
formulário, é possível ter acesso a diversos atributos e funções interessante, como 
19 https://formik.org/docs/overview 
por exemplos ao "​values​" que contém o valor de todos os atributos relacionados ao 
formulário, fazendo o papel de um controlador de estados. Além disso com o 
"touched" é possível informar quais campos sofreram alguma interação;"​errors​" 
contém cada erro de validação dos campos que são obrigatórios e validados pelo 
Yup; "​handleChange​" realiza o papel de setter para mudanças de valor nos campos; 
"​handleReset​" permite resetar todos os valores dos campos e assim retornar o 
formulário ao seu estado inicial, entre outros. 
 
Figura 22 - Formik 
 
5.3.1.2 - Yup 
O Yup é um construtor de schemas javascripts voltado para analisar e 20
validar valores. Permite construir validações complexas e interdependentes, com 
sintaxe intuitiva. A API Yup possui bastante inspiração no Joi, todavia é mais 
concisa e possui sua atuação em validar no lado do cliente. Além disso possui a 
vantagem de ser facilmente acoplada ao controle de formulário do Formik, gerando 
uma poderosa combinação de controle e validação de formulário. 
Na figura 23 abaixo pode-se observar um fragmento da utilização do Yup 
como ​schema de validação ao ser passado como objeto validador nas 
configurações do Formik, através do atributo "​validationSchema​". "​InitialValues​" 
define o estado inicial do formulário; "​onSubmit​" recebe a função que será chamada 
ao submeter o formulário. Com relação a validação realizada pelo Yup, ele permite 
uma ampla variedade de possibilidades de validação, como por exemplo definir que 
o campo "​end_date​" do formulário precisa ser do tipo ​string​. Caso tenha um erro de 
tipagem é retornado para o usuário uma mensagem definida para isso - nesse caso 
a mensagem guardada no dicionário em sua constante "REQUIRED_FIELD". Além 
disso define que esse campo é obrigatório e que além disso sofre uma segunda 
validação passada como parâmetro do ".test" que verifica se a data final é depois da 
data inicial. 
20 https://github.com/jquense/yup 
 
Figura 23 - Yup 
5.3.1.3 - Axios 
Axios é um cliente HTTP que utiliza ​Promises para realizar requisições. É 21
um projeto open source, que realiza em sua camada base requisições Ajax no 
browser via XMLHttpRequests. Permite a interceptação de ​requests e ​responses e a 
transformação dos dados em JSON automaticamente. 
Na figura abaixo é demonstrado um exemplo de utilização do axios, no 
serviço para criação de um usuário. 
21 https://github.com/axios/axios 
 
Figura 24 - Axios 
O objeto "API" é um objeto contendo uma instância do axios configurada por 
exemplo com a url base para o ​back end e também contendo alguns ​headers 
requeridos. Acho chamar a função .post() está define o verbo HTTP que será 
utilizado e recebe dois parâmetros: a url específica da rota de usuários que será 
concatenada com a url base e o "data", o objeto json passado ao ​body com os 
dados necessários para criação de um usuário. 
5.3.2 - Servidor: NodeJS 
 
O NodeJS foi utilizado para desenvolver a plataforma do ​back-end​. Seu 22
cerne é construído em cima do V8, um motor de interpretação javascript com 
origens do C++, onde sua principal função é permitir a utilização de scripts 
javascripts no contexto do servidor. Uma grande vantagem de se utilizar node para 
22 https://nodejs.org/en/ 
o back end é que torna possível utilizar uma única linguagem tanto para o ​front 
como para o ​back​. 
O Javascript é uma linguagem interpretada e estruturada, com tipagem 
dinâmica fraca e multi paradigma. Para o JS oferecer as vantagens de uma 
linguagem tipada, como segurança, performance e auxílio em tempo de 
desenvolvimento, é necessário adicionar uma camada que extenderá a linguagem 
básica, possibilitando suportar tal característica. Para isso, foi utilizado o Typescript, 
um super set ou conjunto de ferramentas que expandem novas funcionalidades para 
o JS, como por exemplo tipagens, classes e interfaces e contribui para futuramente 
o projeto ser escalável, conciso e com a possibilidade de identificar bugs durante o 
tempo de compilação. 
Na ​figura 25 é mostrado um exemplo de definição de interface do objeto 
"​ICreateEventRequest​": 
 
Figura 25 - Interface:Typescript 
Esta interface define todos os atributos que um objeto desse tipo é permitido 
ter e quais são seus respectivos valores. Os atributos com ?: significa que o campo 
é opcional. Na ​figura 26 pode-se verificar que o objeto que deve ser passado como 
parâmetro do medo de criação de um evento é do tipo "​ICreateEventRequest​": 
 
Figura 26 - Tipagem de parâmetros: Typescript 
Dessa forma é garantido um contrato de tipagem e validação dos dados que 
chegam, a fim de tornar mais seguro e correto o processamento e criação de uma 
entidade do tipo Evento. 
 
 
5.3.2.1 - Celebrate 
O celebrate é um ​middleware que utiliza Joi para realizar validação das 23
rotas do servidor. Assim se garante a corretude tanto dos parâmetros como também 
de suas respectivas tipagens, podendo analisar tanto ​params​, ​headers​, ​querys e 
body​. 
Na figura 27 é mostrado um exemplo de uso do celebrate como um 
middleware para validar os dados que estão chegando pela requisição http. Nesse 
caso o celebrate define que a rota ​post dos materiais, no ​back end denominada 
como ​artifacts​, pode receber um único arquivo dentro de um atributo "​file​" e que em 
seu corpo apenas deve existir três atributos: ​title​, sendo obrigatório; ​description​, 
sendo um parâmetro opcional e que permite valores null ou ""; e o "file" que pode 
ser de qualquer tipo. Caso o celebrate encontre alguma inconsistência o ​back end já 
retorna uma ​response contendo o erro de validação. Em caso de tudo estar 
conforme o contrato, ele passa a chamar a função "​create​" da camada ​controller dos 
artefatos e assim continua o processamento da requisição. 
23 https://github.com/arb/celebrate 
 
Figura 27 - Celebrate 
5.3.2.2 - Nodemailer 
O Nodemailer é um módulo no node que permite facilmente enviar emails. 24
Uma das principais vantagens para se optar por utilizá-lo é o fato de sua licença ser 
MIT, ou seja, de software livre. 
Na figura 28, é possível verificar a utilização do nodemailer como serviço de 
envio de emails. É injetado como uma dependência onde pode-se configurar o 
serviço a ser utilizado, neste caso gmail, a autenticação para se utilizar o email o 
qual enviará e receberá mensagens, sendo o user e pass do email. Foi necessário 
configurações adicionar no próprio email para permitir redirecionamentos e acessos 
por parte de um aplicativo externo, que no caso o Doate faz esse papel. 
24 https://nodemailer.com/about/ 
 
Figura 28 - Nodemailer 
A figura 29 apresenta um fragmento do serviço sendo configurado para ser 
usado. A variável "​welcomeEmailTemplate​" carrega um template de email em 
formato handlebars (.hbs). logo após o serviço de envio propriamente dito é 
chamado com a função .sendMail que recebe alguns parâmetros importantes como 
destinatário (​to​: ​name e ​email​); o assunto do email (​subject​); configuração do 
template de email, sendo o arquivo do template (​file​) e os valores que vão popular 
as variáveis respectivas dentro do arquivo .hbs (nesse caso ​name​ e ​link​); 
 
Figura 29 - Email service 
5.3.2.3 - Express 
O Express é o ​framework Node mais popular que oferece diversas 25