DIVULGAÇÃO DE INICIAÇÃO CIENTÍFICA NA UFRJ POR MEIO DE APLICATIVO

Gabriel Fernandes de Souza

Projeto de Graduação apresentado ao Curso de Engenharia Eletrônica e de Computação da Escola Politécnica, Universidade Federal do Rio de Janeiro, como parte dos requisitos necessários à obtenção do título de Engenheiro. Orientador: Flávio Luis de Mello

Rio de Janeiro

Junho de 2021

v

Declaração de Autoria e de Direitos Eu, Gabriel Fernandes de Souza CPF 143.414.297-36, autor da monografia Divulgação de Vagas de Iniciação Científica na UFRJ por meio de um Aplicativo Híbrido, subscrevo para os devidos fins, as seguintes informações:

1. O autor declara que o trabalho apresentado na disciplina de Projeto de Graduação da Escola Politécnica da UFRJ é de sua autoria, sendo original em forma e conteúdo.

2. Excetuam-se do item 1. eventuais transcrições de texto, figuras, tabelas, conceitos e idéias, que identifiquem claramente a fonte original, explicitando as autorizações obtidas dos respectivos proprietários, quando necessárias.

3. O autor permite que a UFRJ, por um prazo indeterminado, efetue em qualquer mídia de divulgação, a publicação do trabalho acadêmico em sua totalidade, ou em parte. Essa autorização não envolve ônus de qualquer natureza à UFRJ, ou aos seus representantes.

4. O autor pode, excepcionalmente, encaminhar à Comissão de Projeto de Graduação, a não divulgação do material, por um prazo máximo de 01 (um) ano, improrrogável, a contar da data de defesa, desde que o pedido seja justificado, e solicitado antecipadamente, por escrito, à Congregação da Escola Politécnica.

5. O autor declara, ainda, ter a capacidade jurídica para a prática do presente ato, assim como ter conhecimento do teor da presente Declaração, estando ciente das sanções e punições legais, no que tange a cópia parcial, ou total, de obra intelectual, o que se configura como violação do direito autoral previsto no Código Penal Brasileiro no art.184 e art.299, bem como na Lei 9.610.

6. O autor é o único responsável pelo conteúdo apresentado nos trabalhos acadêmicos publicados, não cabendo à UFRJ, aos seus representantes, ou ao(s) orientador(es), qualquer responsabilização/ indenização nesse sentido.

7. Por ser verdade, firmo a presente declaração.

_________________________________________ Gabriel Fernandes de Souza

vi

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou

venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

v

DEDICATÓRIA

Dedico este trabalho à minha mãe, minha namorada e todas as pessoas que, de

alguma forma, contribuíram para eu alcançar esse objetivo em minha vida.

vi

AGRADECIMENTO Agradeço a todo o corpo docente do curso de Engenharia Eletrônica e da

Computação da UFRJ, por me capacitar de forma a estar pronto para o mercado de

trabalho. Entre eles, agradeço principalmente ao meu orientador Flávio Luis de Mello, por

ser muito solícito e o seu planejamento foi muito importante ao longo de todo o projeto.

Não foi fácil, mas extremamente gratificante e espero que esse projeto possa contribuir

para melhorar a pesquisa realizada na faculdade e que proporcione novas oportunidades

para os futuros profissionais.

vii

RESUMO O presente trabalho consiste no desenvolvimento de um aplicativo com foco na

divulgação de vagas de Iniciação Científica na Universidade Federal do Rio de Janeiro

(UFRJ), centralizando as suas informações em um único lugar. Dessa forma, alunos e

professores seriam beneficiados com esse projeto, tendo mais vagas disponíveis e na

palma da mão ou a oportunidade de selecionar alunos cada vez mais capacitados.

Palavras-Chave: aplicativo, Iniciação Científica, UFRJ.

x

ABSTRACT

This project is about the development of an application focused on the distribution

of opportunities in the laboratories of Universidade Federal do Rio de Janeiro (UFRJ),

centralizing its information in a single place. In this way, students and teachers would

benefit from this project, having more opportunities to choose or to select more qualified

students.

Key-words: application, laboratories, UFRJ.

ix

SIGLAS

AACC - Atividades Acadêmico-Científico-Culturais, 1

ABC - Academia Brasileira de Ciências, 5

API - Application Programming Interface, 3

APP - Application, 44

CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior, 6

CBPF - Centro Brasileiro de Pesquisas Físicas, 5

CNPq - Conselho Nacional de Pesquisa, 5

CR - Coeficiente de Rendimento, 8

CRUD - Create, Read, Update and Delete, 32

CSS - Cascading Style Sheets, 46

DDD - Domain Driven Design, 10

DICA - Divulgação de Iniciação Científica por Aplicativo, 24

DRE - Divisão de Registro de Estudantes, 40

FAP - Fundação de Amparo à Pesquisa, 7

GPS - Global Positioning System, 24

HTML - Hyper Text Markup Language, 45

HTTP - HyperText Transfer Protocol, 31

IC - Iniciação Científica, 1

IOS - Iphone Operating System, 3

IP - Internet Protocol, 48

ITA - Instituto Tecnológico de Aeronáutica, 5

JSON - JavaScript Object Notation, 30

JSX - Javascript XML, 45

JWT - JSON Web Token, 41

MVC - Model View Controller, 32

ONU - Organização das Nações Unidas, 5

ORM - Object-Relational Mapping, 36

PIBIC - Programa Institucional de Bolsas de Iniciação Científica, 7

PIBITI - Programa Institucional de Bolsa de Iniciação em Desenvolvimento Tecnológico e Inovação, 7

PINC - Programa de Iniciação Científica, 9

PR1 - Pró-Reitoria de Graduação da Universidade Federal do Rio de Janeiro, 7

RU - Restaurante Universitário, 8

x

SBPC - Sociedade Brasileira para o Progresso da Ciência, 5

SIAC - Semana de Integração Acadêmica, 7

SIAPE - Sistema Integrado de Administração Pessoal, 40

SIGA - Sistema Integrado de Gestão Acadêmica, 8

SOLID - Princípios de Design de código, 10

SSH - Secure Shell, 66

SSL - Secure Sockets Layer, 66

UFRJ - Universidade Federal do Rio de Janeiro , 1

URL - Uniform Resource Locator, 48

UUID - Universally Unique Identifier, 37

xi

Sumário AGRADECIMENTO 5

RESUMO 6

ABSTRACT 7

Sumário 10

Lista de Figuras 12

Introdução 1 1.1 – Tema 1 1.2 – Delimitação 1 1.3 – Justificativa 1 1.4 – Objetivos 2 1.5 – Metodologia 3 1.6 – Descrição 4

Fundamentação Teórica 5 2.1 – A Iniciação Científica e sua Importância para a Formação Acadêmica 5 2.2 – A Iniciação Científica na UFRJ 7 2.3 – Outras Soluções 8 2.4 – Metodologias, Tecnologias e Padronizações 9 2.4.1 - API 9 2.4.2 - React Native 9 2.4.3 - Banco de Dados 10 2.4.4 - Design Thinking 10 2.4.5 - Domain Driven Design 10 2.4.6 - SOLID 10 2.4.7 - Scrum 10

Implementação 12 3.1 – Imersão 12 3.2 – Ideação e Prototipação 23 3.2.1 - Nome do Aplicativo 24 3.2.2 - Logo e Identidade Visual 24 3.2.3 - Protótipos das Telas 25 3.3 - Arquitetura de Software 30 3.4 - API 30 3.4.1 - Estrutura de Pastas & DDD 31 3.4.2 - Implementação do SOLID 33

xiv

3.4.3 - Banco de Dados 36 3.4.4 - Criação e Autenticação de Usuários 39 3.4.5 - Criptografia de Senha 43 3.5 - Aplicativo 43 3.5.1 - Estrutura de Pastas 44 3.5.2 - Componentização 45 3.5.3 - Estilização 46 3.5.4 - Criação de Hooks 47 3.5.5 - Chamadas a APIs 48 3.5.6 - Rotas Privadas 49 3.6 – Principais Funcionalidades 50 3.6.1 - Login 50 3.6.2 - Cadastro 51 3.6.3 - Visualização de Vagas Recomendadas 53 3.6.4 - Inscrições Realizadas pelo Aluno 56 3.6.5 - Buscar Vagas 57 3.6.6 - Visualização de Vagas Criadas pelo Professor 59 3.6.7 - Criar Vaga de IC 60 3.6.8 - Classificar/Eliminar Aluno 61 3.7 – Hospedagem da API 65 3.8 – Publicação do Aplicativo 67

Conclusões e Trabalhos Futuros 68 4.1 – Conclusões 68 4.2 – Trabalhos Futuros 68

Bibliografia 69

xv

Lista de Figuras

3.1 – Gráfico com os cursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 – Gráfico com os períodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 – Gráfico com os alunos que já fizeram IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 – Gráfico com os períodos em que os alunos ingressaram na IC .. . . . . . . . . . . . . . 14

3.5 – Gráfico com os intervalos de tempo de permanência numa IC . . . . . . . . . . . . . . 15 3.6 – Gráfico com as motivações para entrar numa IC . . . . . . . . . . . . . . . . . . . . . . . . 16

3.7 – Gráfico com os conhecimentos prévios sobre a área de IC escolhida . . . . . . . . 16

3.8 – Gráfico com formas de divulgação de vagas de IC . . . . . . . . . . . . . . . . . . . . . . 17 3.9 – Gráfico com as participações em processos seletivos de IC . . . . . . . . . . . . . . . 18

3.10 – Gráfico com as etapas de um processo seletivo para IC . . . . . . . . . . . . . . . . . 19 3.11 – Gráfico com o tempo de confirmação da vaga . . . . . . . . . . . . . . . . . . . . . . . . 20

3.12 – Gráfico com análise do impacto da bolsa acadêmica na IC . . . . . . . . . . . . . . 20 3.13 – Gráfico com possibilidades de futuras inscrições . . . . . . . . . . . . . . . . . . . . . . 21

3.14 – Gráfico com dificuldades ao procurar uma vaga de IC . . . . . . . . . . . . . . . . 22 3.15 – Gráfico com os problemas nos processos seletivos de IC . . . . . . . . . . . . . . . 22

3.16 – Logo do Aplicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.17 – Tela de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.18 – Tela de cadastro de alunos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.19 – Tela de cadastro de professores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.20 – Tela de visualização de vagas de IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.21 – Tela para procurar vagas de IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.22 – Tela para pesquisar laboratórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.23 – Tela para visualizar inscrições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.24 – Tela para criar vaga de IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.25 – Tela para visualizar candidaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.26 – Arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.27 – Organização de pastas tradicional x Organização com DDD . . . . . . . 31

3.28 – Arquivo de rotas para vagas de IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

xiv

3.29 – Serviço de listagem de cursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.30 – Serviço de criação de usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.31 – Interface de criação de usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.32 – Estrutura de pastas do domínio de cursos . . . . . . . . . . . . . . . . . . . . . . 36

3.33 – Criação de tabela de níveis de usuário com TypeORM . . . . . . . . . . . 37

3.34 – Entidade de Nível de usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.35 – Diagrama de Classes gerado pelo DBeaver . . . . . . . . . . . . . . . . . . . . 39

3.36 – Chamada POST para criação de aluno. . . . . . . . . . . . . . . . . . . . . . . . . 40 3.37 – Chamada POST para criação de professor . . . . . . . . . . . . . . . . . . . . . . 40

3.38 – Serviço de criação de professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.39 – Middleware de autenticação de usuário . . . . . . . . . . . . . . . . . . . . . . . . 42

3.40 – Chamada POST para autenticação de usuários no sistema . . . . . . . . . 42 3.41 – Provider para criptografia de senha . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.42 – Estrutura de pastas do app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.43 – Estrutura das telas do app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.44 – Página de escolher perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.45 – Arquivo de estilização da página de escolher perfil . . . . . . . . . . . . . . 47 3.46 – Hook de autenticação de usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.47 – Serviço de acesso a uma API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.48 – Criação de rotas privadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.49 – Tela de Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.50 – Tela com opções de cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.51 – Tela de cadastro de aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.52 – Tela de cadastro de professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.53 – Tela de vagas recomendadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.54 – Tela de vagas recomendadas, com todas as informações . . . . . . . . . . 55 3.55 – Confirmação de inscrição na vaga de IC . . . . . . . . . . . . . . . . . . . . . . 56

3.56 – Tela de inscrições realizadas pelo aluno . . . . . . . . . . . . . . . . . . . . . . 57 3.57 – Tela de buscar vagas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.58 – Tela de busca de vagas com os resultados encontrados . . . . . . . . . . . 59 3.59 – Tela de busca de vagas criadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.60 – Tela de criar vaga de IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.61 – Tela de inscrições pendentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.62 – Tela de inscrições pendentes após eliminar aluno . . . . . . . . . . . . . . 63

3.63 – Tela de inscrições pendentes após selecionar aluno . . . . . . . . . . . . . 64

xv

3.64 – Tela de vagas criadas após uma vaga ser totalmente preenchida . . . 65 3.65 – Configurações do servidor escolhido na Digital Ocean . . . . . . . . . . 66

1

Capítulo 1

Introdução

No primeiro capítulo ocorrerá uma apresentação sobre o tema escolhido,

contextualizando o problema a ser resolvido e propondo uma solução, com as

metodologias utilizadas. Ao final, será brevemente citado o que virá nos próximos

capítulos.

1.1 – Tema

O tema do projeto será uma abordagem sobre as Iniciações Científicas (IC) na

Universidade Federal do Rio de Janeiro (UFRJ), trazendo uma análise sobre o programa

e trazer uma proposta de solução, por meio de um aplicativo móvel, para a divulgação de

vagas.

1.2 – Delimitação

Mesmo com diversas Universidades possuírem programas de IC, o projeto se

delimita aos alunos da UFRJ, de forma a simplificar os dados que serão armazenados no

banco de dados.

1.3 – Justificativa

A área de pesquisa é de vital importância para o funcionamento de uma

universidade, tanto que boa parte dos professores conciliam a sua carga horária semanal

entre aulas e laboratórios. Caso o aluno deseje seguir a área acadêmica, uma IC é um

ótimo caminho para isso. Ela pode ocorrer com ou sem uma bolsa auxílio, podendo

escolher receber horas de Atividades Acadêmico-Científico-Culturais (AACC), que

também são importantes para concluir-se a graduação. A proposta é clara: os estudantes

2

são orientados por algum professor vinculado à universidade, auxiliando-os em alguma

área de pesquisa. Além disso, o aluno é introduzido a uma linguagem científica e a cada

seis meses ou um ano deve apresentar o que foi aprendido e desenvolvido na área. Apesar

de muitas das tecnologias mais atuais serem desenvolvidas em laboratórios de

universidades, a divulgação dessas vagas, na maioria dos casos, ocorre de forma arcaica.

Os métodos mais comuns utilizados são pequenos avisos em murais, estes com muitas

outras informações e que muitas vezes não são atualizados. Outros métodos comuns são

o aluno ir na porta de cada laboratório perguntando se existe alguma vaga disponível, ir

diretamente até algum professor perguntar sobre ou e-mails divulgando. Além disso, as

informações não são muito claras ou solicitam pré-requisitos que não são dados em sala

de aula ao longo do curso. Essa falta de clareza gera uma quebra de expectativas entre o

que o aluno acha que será aprendido e desenvolvido com o que é de fato realizado,

gerando desistências. Dessa forma, passa a ser importante divulgar de forma mais clara

as vagas de IC e de forma centralizada.

A motivação surgiu a partir da disciplina Projeto Integrado, ofertada pelo curso de

Engenharia Eletrônica e de Computação. Nela, deve-se desenvolver algum projeto,

aplicando os conhecimentos adquiridos ao longo da graduação. A ideia surgiu a partir de

problemas percebidos pela experiência de diversos alunos ao encontrar dificuldades ao

conseguir uma vaga de IC, algo muito importante para a formação acadêmica. O projeto

foi entregue e a ideia permeou de forma a ser melhor desenvolvida ao ponto de tornar-se

um Projeto de Graduação. Foram constatados alguns problemas, como as atividades

realizadas não serem muito claras, falta de retorno no contato ou a necessidade de algum

conhecimento prévio de alguma disciplina mais avançada, gerando uma frustração e uma

quebra de expectativas.

1.4 – Objetivos

O objetivo é o desenvolvimento de um aplicativo para divulgação de vagas de

Iniciação Científica na UFRJ, de forma centralizada. A proposta se deu pelo grande uso

de aplicativos em smartphones e a praticidade de se ter a solução na palma da mão, a

poucos cliques de distância.

O aplicativo é uma solução viável tanto para alunos quanto para professores.

Alunos podem visualizar e se inscrever nas vagas que aparecem disponíveis para eles,

3

enquanto os professores podem criar as vagas e visualizar os inscritos, facilitando no

processo de seleção. A usabilidade será de extrema importância, devido a boa parte do

corpo discente ter idade avançada.

Como objetivos específicos, temos algumas etapas a serem realizadas para a

conclusão do projeto:

● Pesquisa com alunos da UFRJ, para identificar os seus problemas e possíveis

soluções;

● Revisão bibliográfica sobre desenvolvimento de aplicativos voltados à UFRJ;

● Desenvolvimento de um aplicativo mobile, de forma a ser utilizado tanto para

Android quanto para Iphone Operating System (IOS).

1.5 – Metodologia

Primeiramente será realizada uma pesquisa quantitativa com os alunos da UFRJ,

por meio de um formulário. Nela, serão analisados alguns fatores, como o tempo médio

que fez uma IC, se ela agregou na sua formação acadêmica, quais os principais problemas

percebidos e possíveis soluções para eles. Com isso, serão levantadas as funcionalidades

que os solucionam.

O aplicativo será desenvolvido em React Native, que é uma biblioteca da

linguagem de programação Javascript, tendo como finalidade auxiliar o desenvolvimento

de aplicativos mobile. A vantagem dele está na portabilidade, possibilitando desenvolver

para Android e IOS ao mesmo tempo com praticamente o mesmo código, trazendo uma

solução completa, além de uma maior integração com os celulares. Ele trata apenas da

parte visual, sendo que para as regras de negócio e acesso ao banco de dados será

necessário uma Application Programming Interface (API). Ela será feita em Express, que

é um framework do Node. Sua vantagem além do desempenho está em também ser

baseado em Javascript, utilizando apenas uma linguagem para as duas partes do projeto,

diminuindo a curva de aprendizado.

Os dados serão armazenados em um banco de dados Postgresql, sendo este bem

leve, prático e fácil de se trabalhar.

Para acompanhamento do escopo e prazo do projeto, será utilizado Scrum, que é

uma metodologia ágil para desenvolvimento de projetos, focado em entregas contínuas.

4

1.6 – Descrição

O capítulo 2 será sobre a fundamentação teórica. Nele, a IC será contextualizada,

demonstrando a sua importância para a formação acadêmica. Além disso, terá uma

revisão bibliográfica com soluções de aplicativos voltados para solucionar problemas na

UFRJ.

O capítulo 3 será sobre a implementação do projeto. Nele, serão analisados os

resultados da pesquisa realizada com os alunos da UFRJ e a explicação de alguns termos

técnicos que serão importantes para o desenvolvimento do projeto como, por exemplo, o

que é uma API, autenticação de usuários, requisição de dados, etc.

Finalmente, o capítulo 4 será sobre a conclusão e trabalhos futuros.

5

Capítulo 2

Fundamentação Teórica

O segundo capítulo abordará sobre a fundamentação teórica. Nele, será

apresentado todo o contexto histórico envolvido para a criação do programa de IC no

país, demonstrando a sua importância para a formação acadêmica. Também será

apresentado o programa de IC na UFRJ e algumas outras soluções desenvolvidas para

outros problemas na faculdade, de forma a perceber a importância e a possibilidade de

implementação no dia-a-dia. Finalmente, será apresentado alguns conceitos importantes

para o desenvolvimento do aplicativo.

2.1 – A Iniciação Científica e sua Importância para a Formação Acadêmica

O Conselho Nacional de Pesquisa (CNPq) surgiu no dia 15 de janeiro de 1951,

sancionado pelo presidente Eurico Gaspar Dutra, mas a ideia de sua criação já existia a

mais de duas décadas atrás, como consequência do cenário pós Primeira Guerra Mundial

(1914-1918). Os integrantes da Academia Brasileira de Ciências (ABC) da época já

estudavam a possibilidade da criação de um órgão responsável por fomentar o

desenvolvimento tecnológico em nosso país.

O cenário mudou após a Segunda Guerra Mundial (1939-1945). Avanços

tecnológicos nas áreas bélicas, farmacêuticas, aéreas e nucleares demonstraram a

importância de se investir em pesquisa. O Almirante Álvaro Alberto da Motta e Silva,

membro da Comissão de Energia Atômica do Conselho de Segurança da Organização das

Nações Unidas (ONU), tentou criar o que veio a ser o CNPq. O impacto causado pela

bomba atômica levou a criação de diversas instituições nesse intervalo de tempo. Em

1948 foi criada a Sociedade Brasileira para Progresso da Ciência (SBPC), em 1949 o

Centro Brasileiro de Pesquisas Física (CBPF) e em 1950 o Instituto Tecnológico da

Aeronáutica (ITA). Após a criação do CNPq, o Almirante Álvaro Alberto foi nomeado o

seu primeiro presidente.

6

A ideia de trazer o desenvolvimento científico se baseou em três principais

atividades:

● Concessão de bolsas de estudo para formação de pesquisadores;

● Apoio à realização de reuniões científicas nacionais e internacionais;

● Apoio ao intercâmbio científico no país e no exterior.

No dia 11 de julho de 1951, já com o presidente Getúlio Vargas, foi criada a

Campanha Nacional de Aperfeiçoamento de Pessoal de Nível Superior (atualmente

conhecida como CAPES). Ela tinha a missão de desenvolver cientistas e pesquisadores

do ponto de vista acadêmico. Juntos, eles formam os principais pilares para o incentivo e

o desenvolvimento científico no Brasil, sendo de vital importância para os nossos atuais

e futuros pesquisadores.

Mesmo fazendo parte desde a criação do CNPq, o financiamento das atividades

só encontrou respaldo na Lei da Reforma Universitária (Art. 2º da Lei n. 5540 de

28/11/1968), que determinou a indissociabilidade ensino-pesquisa como norma

disciplinadora do ensino superior [3]. A inspiração para criação do Programa de Iniciação

Científica veio dos Estados Unidos da América e da França, países com programas já

institucionalizados.

Segundo Fava-de-Moraes [4], fazer uma IC traz inúmeras vantagens em relação

aos demais estudantes, onde pode-se destacar:

● Fuga da rotina e da estrutura curricular;

● Ler bibliografias de forma mais crítica;

● Não ter medo do novo;

● Ser termômetro da qualidade do curso;

● Melhor desempenho em programas de seleção para pós-graduação, mestrado e

doutorado, terminando mais rápido a titulação

Além disso, ele afirma que uma IC não é voltada apenas para formar cientistas, já

que ex-alunos também são mais aptos a ingressar no mercado de trabalho, desenvolvendo

um forte senso crítico e espírito de coletividade.

A IC também fornece uma bolsa auxílio, sendo importante para ajudar os alunos,

principalmente os de baixa renda, que aumentaram bastante graças às políticas de cotas

nos vestibulares. Muitos cursos permitem que seus alunos estagiem apenas a partir de um

determinado percentual da graduação concluída, sendo assim, a IC torna-se uma opção

7

viável de aprender mais sobre a sua profissão desejada e complementar a renda familiar,

mostrando a sua importância social.

Visto isso, todo aluno deveria fazer parte de alguma atividade extracurricular ao

longo da sua graduação, de forma a desenvolver melhor o seu senso crítico e não apenas

reproduzir o que lhes foi passado, transformando a faculdade num terceiro grau da escola.

Existe uma diferença entre a sala de aula, seja na pesquisa ou em algum outro trabalho

que for exercido, e a IC pode ser uma boa introdução a esse mundo.

2.2 – A Iniciação Científica na UFRJ

Segundo a definição no site da PR1 (Pró-Reitoria de Graduação da Universidade

Federal do Rio de Janeiro), a IC visa despertar a vocação científica, incentivando novos

talentos potenciais entre estudantes de graduação e contribuindo para a formação futura

de jovens pesquisadores mediante sua participação em projetos de pesquisa. Ele se

candidata a uma vaga em uma área que seja de seu interesse, respeitando o que é

determinado em edital. Existem dois programas específicos voltados para isso na

faculdade: o Programa Institucional de Bolsas de Iniciação Científica (PIBIC) e o

Programa Institucional de Bolsa de Iniciação em Desenvolvimento Tecnológico e

Inovação (PIBITI), sendo este último voltado para para práticas de inovação em projetos

de pesquisa.

De acordo com o último edital publicado no ano de 2020 [5], os recursos

financeiros são disponibilizados pelo CNPq e ofertados pelo PIBIC ou PIBITI da UFRJ.

Deve-se mencionar que não existe vínculo empregatício entre o aluno e a UFRJ ou entre

ele e o CNPq. A bolsa tem duração de doze meses, podendo ser estendida por mais doze.

É proibido o acúmulo da bolsa de IC com alguma outra ofertada pela UFRJ, CNPq, FAP

(Fundação de Amparo à Pesquisa), etc, além do aluno não poder possuir algum vínculo

empregatício.

O docente interessado pode se candidatar a até duas quotas, assumindo o

compromisso de atuar como consultor nos processos de avaliação e a participar da

Semana de Integração Acadêmica (SIAC) quando solicitado. Este último é um evento que

ocorre durante uma semana por ano, onde os alunos de IC apresentam o que foi aprendido

e desenvolvido nos projetos os quais fez parte. Caso a vaga ofertada não seja preenchida,

ela será dada a outro solicitante.

8

Após a solicitação da bolsa e aprovação dos resultados, o docente responsável

pode oferecer a vaga para algum estudante. Este precisa estar com a matrícula ativa na

sua respectiva graduação e Coeficiente de Rendimento (CR) maior ou igual a seis durante

todo o período de duração da bolsa, além de ter vinte horas semanais disponíveis para as

atividades de pesquisa. Existe a possibilidade do aluno ser voluntário em algum projeto,

tendo os mesmos direitos e deveres dos bolsistas, mas sem receber a bolsa. Eles só podem

ser inscritos no PIBIC ou PIBITI após o preenchimento de todas as bolsas.

2.3 – Outras Soluções

O programa de IC existe ao redor de diversas Universidades no Brasil, de forma

muito similar. Cada curso tem a liberdade de ofertar as vagas da forma que achar melhor,

sem existir um sistema centralizando essas informações, sendo divulgado apenas os seus

respectivos editais.

De forma mais geral, outras soluções de projetos de aplicativo já foram

desenvolvidos para solucionar problemas na UFRJ. Como exemplo, serão citadas

algumas dessas soluções.

O Portal do Aluno [6] é vinculado ao Sistema Integrado de Gestão Acadêmica

(SIGA). Nele, os alunos realizam diversas atividades importantes para a sua jornada

acadêmica, como inscrição em disciplinas e emissão de documentos. Antigamente existia

apenas uma versão web, mas conforme o crescimento exponencial de smartphones e seus

aplicativos, surgiu a necessidade de fazer um aplicativo para solucionar essa demanda. A

partir do projeto de graduação de um aluno que fazia parte do SIGA na época, surgiu o

Portal do Aluno - UFRJ, que é bastante utilizado pelos alunos.

O Caronaê [7] é um aplicativo voltado para caronas entre os estudantes da UFRJ.

Caronas existem a diversos anos e é uma prática muito comum, mas não existia uma

plataforma para centralizar a sua oferta. No máximo o que existia na época eram grupos

em redes sociais, mas voltados para regiões específicas da cidade, como por exemplo,

zonas Sul e Oeste. Dessa forma, caso existisse a necessidade de uma carona para uma

região diferente da sua, a pessoa teria que entrar em algum desses grupos antes.

Atualmente o uso de aplicativos de transporte como o Uber se popularizou bastante, mas

o Caronaê traz uma alternativa com preços mais acessíveis.

9

O Cardápio RU-UFRJ [8] (Restaurante Universitário) surgiu inicialmente para

mostrar o cardápio semanal das refeições disponibilizadas pelo Restaurante Universitário

da UFRJ, facilitando o acesso dos alunos a essas informações. Muitos alunos reclamavam

do tempo de espera nas filas, pois o intervalo de almoço era de apenas uma hora, e que

boa parte desse tempo era gasto nelas. Pensando nisso, surgiu uma funcionalidade para

agendamento do horário das refeições, ajudando muito a vida dos alunos.

O PINC [9] (Programa de Iniciação Científica) é um portal voltado para os alunos

de IC do curso de Medicina da UFRJ. Nele, é possível visualizar as vagas em aberto, áreas

de pesquisa e outras informações sobre as vagas disponíveis.

2.4 – Metodologias, Tecnologias e Padronizações

Para o desenvolvimento da solução serão utilizadas algumas metodologias e

ferramentas para estruturação da solução, padronização do código e acompanhamento do

projeto. Elas serão abordadas neste tópico, mas algumas de suas aplicações práticas

ficarão para o capítulo seguinte, focado na implementação da solução.

2.4.1 - API

Uma API é uma interface para programação de aplicações. Ela faz a ponte entre

o aplicativo e o processamento de informações em algum banco de dados. Além disso,

ela pode ser utilizada para fornecer informações para possíveis sites, programas desktop

e até mesmo outra API, mostrando a sua versatilidade de utilização.

2.4.2 - React Native

O React Native é uma biblioteca de Javascript voltada para o desenvolvimento de

aplicativos. Ele possui uma característica híbrida, permitindo a sua disponibilidade para

dispositivos Android ou IOS com praticamente o mesmo código, expandindo as

possibilidades de entrega da solução. Para o projeto foi utilizado o Typescript, que é um

superset para o Javascript, possibilitando uma utilização de tipos, pois o Javascript não

é fortemente tipado.

10

2.4.3 - Banco de Dados

O banco de dados é uma estrutura onde ficam armazenadas as informações. Para

o projeto, será utilizado um modelo relacional, baseado no relacionamento entre as

diversas tabelas que armazenam diferentes tipos de informações.

2.4.4 - Design Thinking

O Design Thinking [10] é uma abordagem muito comum para a elaboração de

novos produtos e serviços. A sua ideia é trazer um viés colaborativo, reunindo diversas

perspectivas. Suas principais etapas são imersão, ideação, prototipação e

desenvolvimento. O principal motivo da sua escolha foi um viés mais humanizado, de

forma a se entender melhor o público-alvo e propor soluções a partir dos resultados

obtidos ao invés de um viés mais pré-estabelecido. Com isso, aumenta a possibilidade do

projeto realmente resolver um problema existente e não algo que possa estar enraizado,

sem correr o risco de desenvolver algo que não resolve problema nenhum.

2.4.5 - Domain Driven Design

O Domain Driven Design (DDD) [14], ou Design orientado ao domínio, é um

conjunto de práticas que visa facilitar o desenvolvimento do software. Um domínio é um

ramo do conhecimento utilizado no projeto (como por exemplo, vagas de IC) e ela ajuda

no entendimento do código, separando os seus respectivos contextos e regras de negócios

em domínios específicos, trazendo uma abordagem mais estratégica ao projeto.

2.4.6 - SOLID

O SOLID [16] é um acrônimo para um conjunto de cinco princípios de Orientação

a Objetos voltados para o desenvolvimento de código com baixo acoplamento e alta

coesão. Dessa forma, o projeto consegue escalar de uma maneira saudável, facilitando a

sua manutenção. Seus princípios e aplicações no projeto serão discutidos durante o

capítulo três, voltado para a implementação.

2.4.7 - Scrum

11

O Scrum é uma metodologia voltada para o gerenciamento ágil de projetos, muito

utilizado no desenvolvimento de softwares. Ele permite dividir o projeto em pequenos

ciclos de aproximadamente duas semanas, chamados de sprints. Além disso, o

desenvolvimento ágil permite uma maior adaptabilidade a eventuais mudanças no escopo

do projeto.

12

Capítulo 3

Implementação

Durante esse capítulo será demonstrado de forma prática os conceitos discutidos

nas metodologias discutidas no capítulo 2.4. Além disso, serão mostradas a arquitetura

do projeto e as telas principais do aplicativo.

3.1 – Imersão

A imersão[10] é a primeira etapa. Nela, são utilizadas ferramentas para se

aprofundar na área e observando os principais problemas, de forma a trazer as melhores

soluções possíveis. É importante não tomar decisões precipitadas e de opinião pessoal,

pois isso pode não englobar o cenário como um todo.

Para essa fase, foi realizada uma pesquisa com os alunos da UFRJ de forma a

entender melhor o público-alvo e levantar os requisitos necessários para a solução desse

problema. Esse sub-tópico abordará as perguntas, suas motivações e análise sobre os

resultados obtidos. O formulário ficou disponível de 12/05/2020 até 12/01/2021, na forma

de um Google Forms [11], obtendo 228 respostas. As questões levantadas foram:

● “Curso”

Essa pergunta foi feita para identificar o curso do aluno. Inicialmente era

delimitado a apenas cursos que faziam parte da Escola Politécnica ou da Escola de

Química da UFRJ, mas foi aberto para os demais cursos, conforme verificado na Figura

3.1. Os cursos que tiveram mais alunos foram Engenharia Eletrônica e de Computação

(26), Engenharia Química (16), Engenharia Civil(13) e Engenharia Mecânica (13).

13

Figura 3.1 - Gráfico com os cursos.

A Figura 3.1 é importante para destacar a diversidade dos alunos que participaram

da pesquisa.

● “Período”

Essa pergunta foi feita para analisar se as perguntas eram mais de alunos que estão

nos períodos iniciais da faculdade ou no final, estando também disponível para pessoas

que já haviam se graduado.

Figura 3.2 - Gráfico com os períodos.

A Figura 3.2 mostra a diversidade dos períodos dos alunos que responderam ao

questionário.

● “Já fez ou atualmente faz uma IC?”

14

Apesar do público-alvo ser de alunos que fazem ou já fizeram alguma IC, ela

poderia ser respondida por pessoas que não fizeram parte. Sendo assim, essa pergunta foi

feita para analisar o percentual de alunos que fizeram IC entre aqueles que responderam

ao questionário.

Figura 3.3 - Gráfico com os alunos que já fizeram IC.

A Figura 3.3 mostra que apesar da maioria dos alunos que responderam ao

questionário fizeram IC, 36,4% não o fizeram. Esse percentual impactará nas demais

perguntas, pois nelas existem uma opção voltada para esses alunos.

● “Você entrou em qual período na IC?”

Essa pergunta foi feita para analisar em qual período aproximadamente os alunos

entram em uma IC.

Figura 3.4 - Gráfico com os períodos em que os alunos ingressaram na IC.

15

A Figura 3.4 mostra que os alunos costumam entrar nos períodos iniciais da

graduação, tendo os maiores percentuais no segundo, terceiro e quinto períodos. Esse

resultado era esperado, pois os alunos nos períodos finais da graduação costumam

procurar por estágio.

● “Por quanto tempo você fez/faz uma IC?”

Essa pergunta foi feita para analisar o tempo médio que o aluno permanece numa

IC.

Figura 3.5 - Gráfico com os intervalos de tempo de permanência numa IC.

A Figura 3.5 mostra que não existe um tempo de permanência pré-definido pelos

alunos, tendo os valores próximos entre si.

● “O que te motivou a buscar uma IC?”

Essa pergunta foi feita para verificar o que leva o aluno a buscar uma IC

atualmente e o impacto da bolsa ofertada na sua escolha. Ela teve um espaço para

colocarem outras opções que não estavam inicialmente.

16

Figura 3.6 - Gráfico com as motivações para entrar numa IC.

A Figura 3.6 mostra que interesse pela área e aprendizado curricular são os

principais motivos para os alunos ingressarem numa IC Como outras opções, algumas

delas com contextos semelhantes, pode-se destacar a busca por um currículo diferenciado

(que de certa forma está relacionado com as duas opções mais votadas), oportunidades de

aumentar as chances de conseguir uma bolsa de Mestrado ou Doutorado e motivação

para continuar o curso.

● “Você já tinha conhecimento prévio sobre a área escolhida?”

Essa pergunta foi feita para analisar se o aluno já possuía interesse prévio na área

na qual fez IC.

Figura 3.7 - Gráfico com conhecimentos prévios sobre a área de IC escolhida.

A Figura 3.7 mostra que não existe uma regra, com o resultado de alunos que

possuíam conhecimento prévio bem similar aos que não a possuíam.

17

● “Como você soube sobre a vaga?”

Essa pergunta foi feita para analisar as formas mais utilizadas e eficazes para

divulgar as vagas de IC atualmente. Ela também deixou um espaço aberto para os alunos

colocarem mais opções.

Figura 3.8 - Gráfico com formas de divulgação de vagas de IC.

A Figura 3.8 mostra que apesar de existirem diversas formas de divulgação online

das vagas, a maioria dos alunos que fizeram IC souberam das vagas por professores ou

amigos. Entre as outras opções, a maior parte são de forma indireta, a partir de algum

professor, seja o aluno enviando email para ele, indo a algum laboratório ou a partir da

recomendação de algum professor para outra vaga que estava aberta.

● “Você já participou de algum processo seletivo para vaga de IC?”

Essa pergunta foi feita para analisar o percentual de alunos que participaram de

processos seletivos, pois inicialmente existe a premissa de que as indicações e contato

direto com os professores que ofertam as vagas são as formas mais eficazes de se

conseguir uma vaga, não ocorra muita concorrência.

18

Figura 3.9 - Gráfico com participações em processos seletivos de IC.

A Figura 3.9 mostra que na maioria dos casos ocorreu processo seletivo de

seleção, ao contrário do que se presumia inicialmente. A forma que as opções foram

propostas não permitiram visualizar o percentual de alunos que fizeram uma IC sem ter

feito processo seletivo e os alunos que nunca fizeram uma IC, mas já participaram de um

processo seletivo.

● “O processo possuía qual/quais etapas?”

Essa pergunta foi feita para analisar quais etapas são mais importantes para filtrar

e escolher os alunos selecionados. Nela, podia-se escolher mais de uma opção e tinha um

espaço aberto para mais opções. Além disso, ela não era obrigatória. Caso um aluno não

tivesse participado de nenhuma etapa, poderia deixar essa pergunta em branco.

19

Figura 3.10 - Gráfico com as etapas de um processo seletivo para IC.

A Figura 3.10 mostra que as principais etapas num processo seletivo para uma

vaga de IC são entrevista, análise de histórico acadêmico e análise curricular. Apesar de

que para muitos alunos a IC pode ser uma primeira oportunidade de contato com a

profissão escolhida, a análise curricular foi bastante votada. Entre os métodos alternativos

citados pelos alunos, pode-se visualizar a escrita de um texto ou relatório sobre o tema

escolhido, envio de carta de intenção e dinâmica de grupo.

● “Quanto tempo levou da sua candidatura até a confirmação da vaga?”

Ela também parte da premissa da pergunta anterior. Devido às indicações,

presume-se que o resultado da vaga ocorra com pouca diferença de tempo a partir do

contato inicial com o professor.

20

Figura 3.11 - Gráfico com o tempo de confirmação da vaga.

A Figura 3.11 mostra que os processos seletivos são bem curtos, levando até duas

semanas no máximo para a confirmação da vaga por parte do professor.

● “Você recebe/recebia bolsa? Caso sim, você continuaria caso não recebesse?”

Essa pergunta visa analisar o impacto da bolsa auxílio na escolha de uma IC.

Figura 3.12 - Gráfico com análise do impacto da bolsa acadêmica na IC.

A Figura 3.12 mostra que a maioria dos alunos que responderam e fizeram IC

continuariam na IC mesmo sem a bolsa. Além disso, o percentual de alunos de IC sem

bolsa é maior que aqueles que recebem, mas não continuariam caso não recebessem. Isso

mostra que apesar de ser um incentivo importante para os alunos, ela não é o fator

principal para as suas permanências na IC.

21

● “Você tem interesse em fazer IC em alguma outra área? Você acredita que

conseguirá mais facilmente que da primeira vez?”

Essa pergunta também parte da premissa das indicações. Ao realizar um IC, já

existe um contato com um professor, que pode indicar futuras oportunidades.

Figura 3.13 - Gráfico com possibilidades de futuras inscrições.

A Figura 3.13 mostra um percentual bem semelhante entre as opções, onde os

alunos que fizeram IC e tem interesse em outra área e acreditam que teria maior facilidade

foi a mais votada. Apesar de ser um resultado esperado, esperava-se um percentual maior,

demonstrando que já ter feito uma IC antes não dá tanta vantagem em relação aos demais

candidatos em um processo de seleção.

● “Você já teve ou conhece alguém que já teve dificuldades em procurar por uma

vaga de IC?”

Essa pergunta visa analisar se existem problemas gerais em todo o processo que

engloba a IC ou se são apenas casos isolados.

22

Figura 3.14 - Gráfico com dificuldades ao procurar uma vaga de IC.

A Figura 3.14 mostra que 81,1% dos alunos já tiveram ou conhecem alguém que

já teve problemas na hora de procurar por uma vaga de IC. Esse resultado é bastante

expressivo e fundamenta a ideia de proposta de um projeto para solucioná-lo.

● “Você acredita que exista algum problema no processo que envolve desde a

divulgação até confirmação da vaga?”

Essa pergunta visa analisar os principais problemas encontrados no processo que

envolve a IC. Ela tinha uma opção para os alunos colocarem outras opções. Além disso,

eles poderiam escolher mais de uma opção.

Figura 3.15 - Gráfico com os problemas nos processos seletivos de IC.

23

A Figura 3.15 mostra que o principal problema está na divulgação das vagas e na

informação dos seus pré-requisitos. Isso demonstra que a melhor forma de solucionar esse

problema é na melhora da divulgação das informações do processo seletivo. Entre as

opções informadas pelos alunos, destaca-se a cobrança por um CR mínimo.

● “O que você acha que poderia ser feito para melhorá-lo?”

Essa pergunta foi feita de forma aberta, sem opções de resposta e de forma

opcional. Dessa forma, pode-se analisar melhor o que os alunos pensam que pode ser feito

para solucionar esse problema.

A principal solução citada para esse problema é a criação de um portal unificado

para a divulgação de IC, centralizando as suas informações e permitindo que alunos de

todos os cursos possam ter acesso às oportunidades, com processos seletivos mais

imparciais e transparentes, com informações sobre o andamento do processo seletivo.

Outra solução bastante citada é na divulgação sobre as informações dos

laboratórios, informando as áreas de pesquisa e o que vem sendo feito, podendo ocorrer

visitas para os mesmos, de forma a despertar o interesse em mais alunos e trazendo o

cotidiano do mundo acadêmico para mais perto deles.

Após a coleta de dados a partir da pesquisa, pôde-se perceber que a divulgação

das vagas e das informações do processo seletivo são os principais problemas e que a

melhor solução apontada é a criação de um portal unificado para centralizar essas

informações.

3.2 – Ideação e Prototipação

Após entender os problemas, deve-se propor soluções para eles. Isso ocorre na

ideação [10], onde ocorrem diversas metodologias para isso, sendo brainstorming a mais

conhecida. A partir dos dados coletados pelos alunos e o entendimento do cenário, serão

propostas as principais funcionalidades que os solucionarão.

Logo após ocorre a etapa de prototipação [10], que serve para se ter uma

visualização inicial da solução do problema, de forma a colher feedbacks contínuos sobre.

Ela é muito importante, pois permite que se possa antecipar eventuais problemas que

possam ocorrer, tanto na parte visual quanto na funcional, economizando no tempo de

desenvolvimento da solução.

24

3.2.1 - Nome do Aplicativo

O aplicativo será chamado de DICA, que é uma sigla para Divulgação de Iniciação

Científica por Aplicativo. Dica também pode ser uma informação ou indicação dada para

alguém, o que se relaciona diretamente com problema a ser solucionado.

3.2.2 - Logo e Identidade Visual

A logo foi desenvolvida de forma a apresentar a solução de forma simples e

intuitiva. O símbolo se assemelha ao utilizado para localização ou Global Positioning

System (GPS), que é um sistema de posicionamento global, mostrando que ele auxiliará

o usuário a encontrar algo desejado. Seu formato ao invés de arredondado é hexagonal,

assemelhando-se a um diamante, demonstrando o seu valor e importância. Dentro dele

está um béquer, que é um símbolo comumente associado a laboratórios.

Abaixo do símbolo está o nome do aplicativo. Pode-se observar que o símbolo de

localização está logo acima das letras I e C, representando a ideia de ajudar a encontrar a

IC desejada.

As cores utilizadas foram um azul com uma tonalidade mais escura, (#222680),

um vermelho mais claro (#F76769) e branco (#FFFFFF). As duas cores principais trazem

uma ideia de contraste e serão utilizadas como base no aplicativo. O azul será utilizado

para caixas de texto e o vermelho para os botões.

Figura 3.16 - Logo do Aplicativo

25

3.2.3 - Protótipos das Telas

Os protótipos foram feitos no Figma [12], que é uma ferramenta para criação de

protótipos de sistemas e aplicativos.

● Login

A ideia inicial para o login está na integração com o SIGA, permitindo que os

alunos entrassem no aplicativo a partir da conta no Portal do Aluno da UFRJ. Como isso

não foi possível, será necessário um cadastro no sistema, com o usuário acessando o

sistema a partir do seu email cadastrado e a senha.

Figura 3.17 - Tela de login.

● Cadastro

Como informado anteriormente, será necessário um cadastro no sistema, tanto

para alunos quanto para professores. Nele, devem constar as principais informações sobre

cada tipo de usuário.

26

Figura 3.18 - Tela de cadastro de alunos.

Figura 3.19 - Tela de cadastro de professores.

● Visualizar Vaga

Será possível visualizar em um Dashboard na sua página inicial com todas as

vagas disponíveis para o seu curso. Além disso, será possível visualizar também vagas de

laboratórios e/ou áreas de interesse cadastradas. Em cada vaga será possível ver diversas

informações, como laboratório, área, valor da bolsa, número de vagas e horas semanais.

27

Figura 3.20 - Tela de visualização de vagas de IC.

● Procurar Vaga

Será possível pesquisar por uma vaga desejada.

Figura 3.21 - Tela para procurar vagas de IC.

● Pesquisar Laboratório

Será possível pesquisar por um laboratório e visualizar todas as vagas abertas nele.

28

Figura 3.22 - Tela para pesquisar laboratórios.

● Visualizar inscrições

Será possível visualizar todas as vagas nas quais o aluno se inscreveu e verificar

em que etapa está.

Figura 3.23 - Tela para visualizar inscrições.

29

● Criar Vaga

Será possível criar uma vaga de IC para ser visualizada pelos alunos. Essa

funcionalidade só será possível para os professores.

Figura 3.24 - Tela para criar vaga de IC.

● Visualizar Candidatos

Os professores poderão visualizar todos os candidatos inscritos num processo

seletivo e verificar as suas informações.

Figura 3.25 - Tela para visualizar candidaturas.

30

3.3 - Arquitetura de Software

O projeto será desenvolvido a partir do modelo abaixo:

Figura 3.26 - Arquitetura de software.

A Figura 3.26 demonstra o fluxo de informações entre as diferentes camadas do

projeto e como elas se comunicam entre si. O usuário fará alguma requisição para a API,

que se comunicará com o banco de dados e processará as informações necessárias. A

implementação da cada uma dessas camadas será demonstrada nos tópicos seguintes, com

um viés mais prático.

3.4 - API

O back-end foi construído utilizando o Express [13], que é um framework de

Node. Seu objetivo é receber as solicitações (requests) dos usuários, processar essas

informações, armazenar ou no banco de dados, fazer as modificações necessárias e

devolver a resposta (response) aos usuários, com um código de status e a resposta. O seu

padrão de resposta será o formato Javascript Object Notation (JSON), que é a notação

padrão para objetos em Javascript.

A seguir, serão apresentados alguns pontos importantes para a implementação da

API.

31

3.4.1 - Estrutura de Pastas & DDD

Conforme comentado no capítulo 2.4.2, o DDD foi escolhido para organização do

código. A partir dele, o projeto foi dividido em domínios, centralizando as suas

informações ao invés de dividi-las ao longo de pastas voltadas, por exemplo, em rotas e

serviços. Conforme o projeto escalar, isso pode tornar-se problemático.

Figura 3.27 - Organização de pastas tradicional x Organização com DDD.

A Figura 3.27 mostra essa diferença. O lado direito mostra a organização a partir

do DDD. Cada pasta representa um domínio e dentro de cada uma delas existem as pastas

do lado esquerdo, caso seja necessário. Pastas que mexem com configurações globais ou

mexem com informações compartilhadas com os demais domínios ficam em pastas

separadas. As principais informações necessárias para criar um domínio são:

● Rotas: executam chamadas a métodos HTTP (HyperText Transfer Protocol)

● Controllers: abstração do conteúdo dentro das rotas

● Serviços: abstração das regras de negócio

● Repositórios: comunicação com o banco de dados

● Modelos: entidades/classes

A API é executada a partir de uma rota utilizada por algum serviço externo(que

no caso, será o aplicativo). Ela é chamada a partir de uma requisição (request), chama o

seu respectivo controller e pode retornar ou não uma resposta (response), que estará em

formato JSON. Caso seja necessário, a rota possuirá um middleware, que é uma função

32

que intercepta a chamada da rota, podendo modificar uma solicitação ou executar alguma

função. Um exemplo disso é nas rotas autenticadas, como criação de vagas de IC, pois o

professor precisa estar conectado no aplicativo para executar essa funcionalidade.

Figura 3.28 - Arquivo de rotas para vagas de IC.

A Figura 3.28 mostra um exemplo de arquivo de rotas com middleware de

autenticação de usuários. Como ele foi chamado logo após a criação da rota, a partir do

método use(), ela está disponível para todas as suas respectivas rotas. Caso apenas uma

rota precise ser autenticada, o middleware viria logo após o caminho da rota.

O controller, muito comum em arquiteturas MVC (Model View Controller), aqui

atua apenas como uma proxy e chama o serviço. Este, é responsável por lidar com as

regras de negócio do projeto. Ele possui apenas um método, chamado execute(), e realiza

apenas chamadas do tipo CRUD (Create, Read, Update and Delete). Ao final disso, ele

chama um repositório que se comunicará com o banco de dados.

33

Dentro de rotas de criação e atualização de dados, os dados vindos no corpo da

requisição terão seus tipos e obrigatoriedades validados pela biblioteca celebrate [15].

3.4.2 - Implementação do SOLID

Conforme comentado no capítulo 2.4.6, o SOLID foi escolhido para o projeto.

Nesse tópico, será apresentado cada um deles e como foi aplicado no projeto.

● Single Responsibility Principle: cada classe deve possuir apenas uma única

responsabilidade, de forma a evitar que regras de negócio se repitam.

Figura 3.29 - Serviço de listagem de cursos.

A Figura 3.29 mostra um exemplo da regra. Cada serviço possui apenas um

método chamado execute, que tem apenas uma única responsabilidade. Nesse caso, o

serviço tem como responsabilidade listar todos os cursos existentes. Toda vez que for

necessário a funcionalidade, basta chamar esse serviço, ao invés de repetir regra de

negócio em alguma outra parte do código.

● Open Close Principle: classes estão abertas para extensão e fechadas para

modificação.

Um exemplo desse princípio está nos níveis de acesso. Um usuário está

responsável por se conectar no sistema. Como existem alunos e professores com

responsabilidades diferentes, não faz sentido colocá-los como uma classe única. Para isso,

eles foram separados em classes diferentes, tratando dos seus casos de forma diferente.

34

Um outro exemplo prático está no polimorfismo, mas ele não foi aplicado no

projeto.

● Liskov Substitution Principle: mudar a instância de um subtipo não deve alterar o

funcionamento do programa, criando abstrações.

Um exemplo prático está na injeção de dependências. Ela é útil para remover

dependências desnecessárias no arquivo.

Figura 3.30 - Serviço de criação de usuário.

A Figura 3.30 mostra um exemplo de injeção de dependências. A biblioteca

utilizada foi o tsyringe [17]. Nesse exemplo, ela injeta duas dependências: o repositório

de usuários para conexão com o banco de dados e o provider que fornece os hashes para

criptografia da senha, que será comentada em tópico posterior. Elas são chamadas dentro

do construtor do serviço. Injetar uma dependência possibilita o serviço a não ficar preso

a bibliotecas e funcionalidades externas.

35

Apesar disso, esse princípio trata apenas do provider. Ele funciona no projeto

como um repositório externo, que pode ser compartilhado com os demais serviços e

geralmente dependem de alguma biblioteca externa. Caso seja necessário substituir a

biblioteca que fornece a criptografia, basta criar o seu arquivo separadamente com a

execução das respectivas funcionalidades, criar a dependência e injetá-la no serviço.

Além disso, caso algum outro serviço precise de alguma funcionalidade , basta injetá-la

diretamente no serviço desejado.

● Interface Segregation Principle: deve-se criar diversas interfaces para

determinado domínio ao invés de agrupá-los em uma única interface.

Figura 3.31 - Interface de criação de usuários.

A Figura 3.31 mostra uma interface para criação de usuários. Apesar da entidade

de usuário possuir mais propriedades, apenas essas são importantes para a criação de

usuário. Apesar do Typescript possibilitar a desestruturação de um objeto para pegar as

propriedades desejadas, centralizar tudo em apenas uma interface possibilita que

propriedades que não são necessárias sejam importadas, podendo gerar erros futuros no

projeto. É possível também criar uma interface para determinar o retorno de um método.

● Dependency Inversion Principle: deve-se depender de uma abstração ao invés de

uma implementação.

Um exemplo prático consiste em injetar a dependência de um repositório dentro

do construtor de um serviço, como visto na Figura 3.29.

36

Figura 3.32 - Estrutura de pastas do domínio de cursos.

Ao contrário do que possa parecer, o serviço não depende do repositório, mas sim

da interface. A Figura 3.32 demonstra isso. Existem duas pastas de repositórios: uma

dentro da pasta de cursos, com a interface que determina quais métodos serão executados

pelo repositório. A outra fica dentro da pasta typeform, com a execução dos métodos.

Caso seja necessário substituir o TypeORM [18] por algum outro ORM [19] (Object-

Relational Mapping), que faz a ponte entre o banco dados e a API, basta criar suas

respectivas entidades e seus repositórios, executando os métodos determinados pela

interface. Para ela, não importa o funcionamento interno ou banco de dados utilizados,

apenas que o método pode possuir parâmetros na entrada e na saída.

3.4.3 - Banco de Dados

Para a construção do banco de dados foram utilizadas cinco tecnologias:

PostgreSQL [20] , Docker [21] e TypeORM . Todos os bancos de dados foram criados a

partir de contêineres em Docker, facilitando a sua construção e publicação em diversos

ambientes, como desenvolvimento e produção.

O banco de dados escolhido como o principal foi o PostgreSQL. Ele é bem leve e

fácil de utilizar, o que facilitou em sua escolha. Ele é um banco relacional e foi usado

para a criação das tabelas e seus relacionamentos. Para a criação das suas tabelas foi

utilizado o TypeORM, que é um ORM voltado para Typescript, permitindo criar scripts

37

de Banco de Dados com essa linguagem. Cada arquivo possui dois métodos: um para

criação e outro para remoção dos comandos. É importante ressaltar que os comandos de

remoção devem ser feitos na ordem inversa dos de criação. Além disso, cada arquivo,

chamado de migration, funciona como um histórico de comandos, bastando apenas

executá-los para estar com o banco de dados atualizado.

Figura 3.33 - Criação de tabela de níveis de usuário com TypeORM.

Conforme visto na Figura 3.33, o id é a chave primária e é do tipo UUID

(Universally Unique Identifier). Um UUID é uma string que fornece um id único,

diferente de qualquer um já criado anteriormente. Ele é muito importante para a segurança

38

do projeto, pois colocar um id numérico e sequencial permite acessar outros dados com

uma maior facilidade por outros usuários mal intencionados.

Para relacionar a tabela do banco de dados com a entidade, são utilizados

decorators do TypeORM dentro dela.

Figura 3.34 - Entidade de Nível de usuário.

Para visualização das tabelas foi utilizado o DBeaver [22], que traz como

vantagem a visualização dos relacionamentos entre as tabelas, importante para o

entendimento do projeto.

39

Figura 3.35 - Diagrama de Classes gerado pelo DBeaver.

A Figura 3.35 mostra os relacionamentos que a tabela curso possui, informando

suas chaves primárias, estrangeiras e demais campos.

.

3.4.4 - Criação e Autenticação de Usuários

O ideal para o projeto seria a conexão com a API do SIGA e o usuário acessar

com as mesmas credenciais utilizadas no Portal do Aluno da UFRJ. Como isso não foi

possível, foi desenvolvida outra solução.

O projeto possui dois níveis de usuário: aluno e professor. Um professor pode criar

uma vaga de IC e visualizar os alunos inscritos, enquanto o aluno pode visualizar as vagas

abertas e se inscrever. De forma a evitar a repetição de código, foi criado um domínio de

usuário, contendo as informações necessárias para acessar o sistema, como email e senha.

Para relacioná-los, foi criada uma tabela para o nível de um usuário, com o seu código

referenciado nas tabelas de aluno e professor a partir de chaves estrangeiras.

Como não é possível fazer rotas do tipo POST via localhost, foi utilizado o

Insomnia [23].

40

Figura 3.36 - Chamada POST para criação de aluno.

Figura 3.37 - Chamada POST para criação de professor.

Como não houve a conexão com a API do SIGA, não tem como verificar se o

DRE (Divisão de Registro de Estudantes) do aluno ou SIAPE (Sistema Integrado de

Administração Pessoal) do professor existe e está cadastrado no SIGA ou se é válido. A

única verificação feita está no número de caracteres e se todos são numéricos.

Como a parte de email e senha pertencem ao modelo de usuário, deve-se criar um

usuário, pegando o seu id, antes de criar um aluno ou professor. Sendo assim, caso seja

possível criar um usuário mas não seja possível criar um aluno ou professor, esse usuário

é excluído da base dados. Para isso, é injetada a dependência do repositório de usuários

dentro do respectivo serviço.

41

Figura 3.38 - Serviço de criação de professor.

A Figura 3.38 mostra um trecho de código relacionado com a criação de um

professor. A validação do SIAPE é feita a partir da injeção de uma dependência externa.

A partir do momento que essa validação for feita a partir de uma nova forma (por

exemplo, a API do SIGA), basta fazer a alteração apenas no provider, pois o serviço não

sabe como essa funcionalidade funciona internamente.

A autenticação de usuário foi feita a partir da biblioteca jsonwebtoken [24]. A

cada login de um usuário, é gerado um código JWT (JSON Web Token), que será utilizado

para rotas e telas autenticadas dentro da aplicação, evitando que um usuário realize

alguma função que não tenha acesso. É possível determinar o prazo de validade de um

token, permitindo que o usuário acesse o aplicativo sem passar pela tela de Login. Para o

projeto, foi utilizado um token de vinte e quatro horas de validade.

42

Figura 3.39 - Middleware de autenticação de usuário.

Figura 3.40 - Chamada POST para autenticação de usuário no sistema.

43

A Figura 3.40 mostra uma chamada POST para acesso ao sistema. Ela retorna os

dados do usuário, sem informar a senha, e o token de acesso.

3.4.5 - Criptografia de Senha

Uma senha não pode estar disponível para visualização dos demais usuários.

Dessa forma, ela precisa ser criptografada. Para isso, foi utilizada a biblioteca bcryptjs

[25]. Ela pega uma senha e um salto e gera um hash com a senha criptografada.

Figura 3.41 - Provider para criptografia de senha.

Para o projeto foi criado um provider para lidar com a criptografia, com uma

função para gerar a senha criptografada, útil para criação de usuário, e outra para

comparar uma senha não criptografada com uma já criptografada, útil para autenticar um

usuário para acessar o aplicativo. A Figura 3.29 mostra um exemplo de utilização do

provider dentro do serviço de criação de um usuário.

3.5 - Aplicativo

O front-end foi construído utilizando React Native, que é um framework

Javascript para desenvolvimento de aplicativos. Ele é muito utilizado no mercado

atualmente e traz um conceito de componentização, o que permite a reutilização de

códigos com funcionamentos específicos.

A seguir, serão apresentados alguns pontos importantes para a implementação do

aplicativo.

44

3.5.1 - Estrutura de Pastas

O projeto do aplicativo não segue uma arquitetura específica. Sua estrutura de

pastas é feita segundo a figura abaixo:

Figura 3.42 - Estrutura de pastas do aplicativo.

Cada pasta tem a seguinte finalidade:

● @types: declaração de tipos e bibliotecas não reconhecidas pelo Typescript

● assets: imagens padrão utilizadas pelo app (application)

● components: componentes que serão reutilizados em outros componentes ou telas

● hooks: recursos personalizados

● pages: telas do app

● routes: rotas para as telas do app

● services: conexão com apis

● utils: funções úteis

Dentro das pastas de pages e components, suas respectivas telas e componentes

encontram-se no formato de pastas, com dois arquivos dentro: index para o componente

e styles para a estilização.

45

Figura 3.43 - Estrutura das telas do app.

3.5.2 - Componentização

Componentes são funções que podem aceitar parâmetros (propriedades) e

retornam um elemento JSX (Javascript XML). Dentro de cada componente podem existir

propriedades (props), que são as variáveis e seus estados (states), que são os valores

dessas variáveis em um determinado instante. Sua estrutura de hierarquia de componentes

é similar ao do HTML (Hyper Text Markup Language), inclusive sendo a maior diferença

entre entre o React e o React Native. O React pode utilizar HTML no seu código, enquanto

o React Native não, tendo que importar componentes próprios.

46

Figura 3.44 - Página de escolher perfil.

Todo o retorno de um componente deve estar dentro de uma única tag. Geralmente

é utilizada uma tag vazia para isso, chamada de Fragment.

3.5.3 - Estilização

O React Native não permite utilizar CSS (Cascading Style Sheets) diretamente no

seu código. Para a estilização dos componentes, foi utilizada uma biblioteca chamada

styled-components [25]. Ela possibilita criar componentes de estilização, permitindo

utilizar o CSS e criando componentes padrão do React Native de forma específica.

47

Figura 3.45 - Arquivo de estilização da página de escolher perfil.

3.5.4 - Criação de Hooks

Hooks são recursos padrão para executar diversas funcionalidades distintas e bem

comuns. Eles lidam com, por exemplo, criação e alteração de propriedades, evitar

renderização excessiva, etc. Apesar disso, caso seja necessário, é possível criar um hook

próprio para um projeto. Todos eles começam com o prefixo use.

48

Figura 3.46 - Hook de autenticação de usuários.

A Figura 3.46 mostra um hook criado para autenticar usuários. Ele lida com outro

conceito importante, chamado context API [26]. Ele permite compartilhar estados de

forma global, o que não é permitido pelo React Native, apenas para componentes filhos.

Dessa forma, ele permite que as informações dos usuário e seu token de autenticação

estejam disponíveis para toda a aplicação.

3.5.5 - Chamadas a APIs

As requisições HTTP da API são acessadas a partir de uma biblioteca chamada

axios [27]. Nele, é passado a URL (Uniform Resource Locator) padrão da API. Para o

ambiente de desenvolvimento, a API do projeto roda na localhost, sendo acessado no

aplicativo pelo IP (Internet Protocol) da máquina, mas isso não permite que endereços de

imagens que venham da máquina sejam exibidas no aplicativo, como por exemplo as

fotos de perfil dos usuários. Dessa forma, é necessário utilizar um programa chamado

ngrok [28]. Ele permite expor a sua máquina local para ser acessada externamente. É

49

importante informar que cada vez que for executado, ele gera um novo link, que precisa

ser atualizado para o aplicativo. O ambiente de produção terá um caminho próprio, que

será comentado posteriormente no tópico 3.6, sobre hospedagem.

Figura 3.47 - Serviço de acesso a uma API.

Para acessar APIs externas, basta colocar a sua URL em um outro arquivo de

serviços, seguindo o mesmo modelo da Figura 3.47. Não é necessário o ngrok.

3.5.6 - Rotas Privadas

Algumas telas serão visualizadas apenas para alunos, como inscrição, e outras

apenas por professores, como criação de vagas de IC. Dessa forma, elas devem ser

acessadas apenas por quem possui esse nível de acesso.

Figura 3.48 - Criação de rotas privadas.

50

Conforme visto na Figura 3.48, a partir do hook criado para a autenticação de

usuários, é possível verificar o seu nível de acesso, permitindo a visualização das telas de

forma segregada.

3.6 – Principais Funcionalidades

A partir das informações obtidas na pesquisa com os estudantes e da prototipação

de um modelo, foram desenvolvidas as telas do projeto. O seu objetivo é a realização das

principais funcionalidades voltadas para cada tipo de usuário. É importante afirmar que

um usuário não pode realizar funcionalidades com as quais não possui acesso.

As principais funcionalidades do aluno são:

● Visualizar vagas de IC

● Inscrição em vaga de IC

● Visualizar inscrições

● Pesquisar vagas de IC

● Cancelar inscrição

As principais funcionalidades do professor são:

● Visualizar vagas de IC criadas

● Criar vaga de IC

● Visualizar alunos inscritos

● Selecionar/Eliminar aluno

3.6.1 - Login

Ao iniciar o aplicativo pela primeira vez, será exibida a tela de Login. Caso o

usuário já tenha iniciado uma sessão, a primeira tela exibida será referente ao seu

respectivo perfil.

51

Figura 3.49 - Tela de Login.

A Figura 3.49 mostra a tela de Login do aplicativo. O usuário acessa o sistema a

partir do seu email e senha já cadastrados. Caso o usuário não possua um cadastro, ele

pode criar uma conta clicando em “Criar uma conta”.

3.6.2 - Cadastro

Ao realizar um cadastro, o sistema pergunta qual tipo de conta será criada. Existem

duas opções: aluno e professor, conforme a Figura 3.50.

52

Figura 3.50 - Tela com opções para cadastro.

A partir da opção escolhida, estará disponível a respectiva tela de cadastro, com

as suas informações, conforme as Figuras 3.51 e 3.52.

53

Figuras 3.51 e 3.52 - Telas de cadastro de aluno(3.51) e professor(3.52).

Caso os dados tenham sido informados corretamente, o usuário será redirecionado

para a tela de Login para então acessar o sistema.

3.6.3 - Visualização de Vagas Recomendadas

Caso o usuário seja um aluno, a primeira tela a ser exibida após o login será a de

vagas recomendadas.

54

Figura 3.53 - Tela de vagas recomendadas.

A Figura 3.53 mostra a tela de vagas recomendadas. Em cada vaga aparece as suas

principais informações, como laboratório, nome do professor, valor da bolsa e número de

horas por semana. A recomendação é feita a partir do curso.

55

Figura 3.54 - Tela de vagas recomendadas, com todas as informações.

O usuário pode expandir o card relacionado à vaga, visualizando assim todas as

suas informações, conforme a Figura 3.54.

Caso o aluno tenha interesse em se candidatar a alguma vaga, basta clicar no botão

“Inscreva-se”. Após a candidatura, será exibida a seguinte informação:

56

Figura 3.55 - Confirmação de inscrição na vaga de IC.

A Figura 3.55 mostra a confirmação de inscrição em uma vaga de IC. Após essa

ação, ele pode visualizar todas as suas inscrições realizadas ou voltar para as vagas

recomendadas. Como a inscrição foi realizada com sucesso, a vaga inscrita não aparecerá

novamente nas vagas recomendadas até que o aluno cancele a sua inscrição.

3.6.4 - Inscrições Realizadas pelo Aluno

Caso o aluno deseje visualizar todas as inscrições realizadas, basta acessar a

respectiva tela.

57

Figura 3.56 - Tela de inscrições realizadas pelo aluno.

A Figura 3.56 mostra a tela de inscrições realizadas. Cada inscrição estará em um

determinado card, podendo expandi-lo para visualizar mais informações. Caso deseje

cancelar a inscrição, basta clicar em “Cancelar inscrição”. Após essa ação, o usuário será

redirecionado para a tela inicial (Figura 3.54) e a vaga ficará disponível para uma nova

inscrição.

3.6.5 - Buscar Vagas

Caso o usuário deseje pesquisar por vagas além das recomendadas, basta acessar

a respectiva tela.

58

Figura 3.57 - Tela de buscar vagas.

A Figura 3.57 mostra a tela de buscar vagas. Nela, é possível filtrar todas as vagas

abertas a partir dos cursos, áreas e laboratórios, não sendo obrigatório realizá-la utilizando

todos os critérios.

59

Figura 3.58 - Tela de busca de vagas com os resultados encontrados.

A Figura 3.58 mostra os resultados obtidos a partir dos filtros desejados. O card

funciona da mesma forma que na Figura 3.55, sendo possível expandi-lo para visualizar

mais informações e realizar uma inscrição.

3.6.6 - Visualização de Vagas Criadas pelo Professor

Caso o usuário seja um professor, a primeira tela a ser exibida após o login será a

de vagas criadas.

60

Figura 3.59 - Tela de busca de vagas criadas.

A Figura 3.59 mostra a tela de vagas criadas. Cada vaga corresponde a um card,

com as suas principais informações exibidas, como laboratório e os números de vagas,

inscritos e selecionados. Ele também pode ser expandido, para visualizar todas as suas

informações e existem três opções possíveis: visualizar todos os alunos inscritos, editar

as informações da vaga ou excluí-la.

3.6.7 - Criar Vaga de IC

Caso o professor deseje criar uma vaga de IC, basta acessar o menu e escolher

essa opção.

61

Figura 3.60 - Tela de criar vaga de IC.

A Figura 3.60 mostra a tela de criar vaga, com todas as informações necessárias

para a sua criação.

3.6.8 - Classificar/Eliminar Aluno

Para classificar ou eliminar um aluno, é necessário visualizar todos os alunos

inscritos na respectiva vaga.

62

Figura 3.61 - Tela de inscrições pendentes.

A Figura 3.61 mostra as inscrições realizadas para uma determinada vaga. É

possível selecionar ou eliminar o aluno.

63

Figura 3.62 - Tela de inscrições pendentes após eliminar aluno.

A Figura 3.62 mostra como fica a tela de inscrições após eliminar um candidato.

O seu respectivo card desaparece e o número de inscrições pendentes é atualizado. Além

disso, essa vaga não aparece como recomendada novamente para o aluno eliminado.

64

Figura 3.63 - Tela de inscrições pendentes após selecionar aluno.

A Figura 3.63 mostra como fica a tela de inscrições após selecionar um candidato.

O seu respectivo card fica com a borda verde e o número de vagas preenchidas é

atualizado. Caso todas as vagas disponíveis sejam preenchidas, o card relacionado a

respectiva vaga na tela de vagas criadas também ficará com a borda verde, conforme

Figura 3.64.

65

Figura 3.64 - Tela de vagas criadas após uma vaga ser totalmente preenchida.

3.7 – Hospedagem da API

Após o desenvolvimento de todas as funcionalidades do projeto, é necessário

disponibilizá-lo para os usuários finais. Dessa forma, foram utilizadas duas abordagens

diferentes: hospedagem da API em um servidor e publicação do aplicativo. Esse tópico

será sobre a primeira forma.

A API será disponibilizada na Digital Ocean [29], que é uma das principais

plataformas de hospedagem em nuvem no mercado. Suas principais vantagens [30] são o

baixo custo (será utilizado um servidor com custo mensal de US$5,00) e a escalabilidade,

disponibilizando mais recursos conforme a aplicação cresce. Para diminuir custos, essa

etapa foi realizada apenas ao final do projeto.

Para criar o droplet (servidor) na Digital Ocean, basta criar uma conta e realizar o

login no sistema. Após isso, basta clicar em “Get Started with a droplet” e configurar

com as opções que desejar.

66

Figura 3.65 - Configurações do servidor escolhido na Digital Ocean

A Figura 3.65 mostra as configurações escolhidas para o servidor na Digital

Ocean. A conexão com o contêiner do Docker é feita a partir de uma chave SSH (Secure

Shell) [31], gerada a partir da sua máquina local. Para criá-la e acessá-la no Windows, é

preciso instalar um programa chamado PuTTY [32]. Após a criação, ele disponibilizará

dois arquivos, um para a chave pública e outro para a privada. Basta copiar o seu conteúdo

dentro das configurações da Digital Ocean.

Com o servidor já criado, basta acessá-lo a partir do PuTTY, informando o IP

disponibilizado. Nele, é preciso instalar o Node e clonar o repositório com o código do

projeto. Com ele instalado, deve-se convertê-lo de Typescript de volta para Javascript.

A próxima etapa consiste em configurar um banco de dados para produção, de

forma semelhante ao realizado para o ambiente de desenvolvimento, a partir da criação

de um contêiner do Docker, e colocar as suas informações no arquivo ormconfig.json. É

importante lembrar que o código que será utilizado é o convertido para Javascript. Dessa

forma, nesse mesmo arquivo deve-se alterar as terminações de todos os arquivos que

forem do Typescript.

Com tudo configurado, basta iniciar o contêiner e executar o projeto (em

Javascript). Para lidar com variáveis de ambiente e manter o projeto executando, é

necessário instalar um gerenciador de processos chamado PM2 [33].

Após isso, é necessário configurar um domínio para o projeto e o SSL [34], para

realizar uma conexão segura entre um servidor web e o navegador, de forma

criptografada. O domínio foi criado a partir do Google Domains [35], com um custo de

R$50,00. Essa opção não está disponível para polimail e é necessário utilizar outro tipo

de email da Google. Com ele criado, basta vinculá-lo na Digital Ocean, referenciando-o

ao IP do projeto. Toda vez que o domínio for acessado, ele será redirecionado para o

servidor criado. O certificado SSL é criado a partir do certbot [36].

Com tudo instalado e funcionando, foi preciso cadastrar as informações

relacionadas a cursos, laboratórios e áreas de pesquisa, para serem utilizados para

cadastro de alunos e professores. Foi preciso criar uma conta de professor para criar vagas

67

de testes para validação do fluxo completo relacionado a criação, inscrição e seleção das

vagas de IC.

3.8 – Publicação do Aplicativo

O segundo ponto para disponibilização do aplicativo para os usuários consiste em

publicá-lo nas lojas de aplicativos (Google Play Store,para Android e App Store, para

IOS). Para isso, será necessário criar [37]. O primeiro tem um custo de US$25,00 e o

segundo de US$99,00 por ano, além de ser necessário ter um dispositivo Mac para realizar

a publicação. Esses valores não são por aplicativo, mas sim por assinatura, não sendo

necessário pagar os mesmos valores para futuras publicações. Por esses motivos, o

aplicativo será disponibilizado apenas para Android.

A publicação do aplicativo precisa de alguns passos. O primeiro deles consiste em

gerar um arquivo com o executável do projeto para enviar ao Google Play Store. Deve-

se gerar uma chave de publicação, seguindo os passos informados em [38]. Após tudo

configurado, basta acessar a pasta android dentro do projeto e executar o comando

gradlew bundleRelease.

Com o executável gerado, é possível realizar o seu upload dentro da Google Play

Store. Basta criar um novo aplicativo, informar todas as informações necessárias,

incluindo o arquivo. Após a confirmação de todos os dados, é preciso aguardar a

verificação do aplicativo a ser feita pela Google, de forma a validar se ele é seguro e seu

conteúdo não é vulgar. Essa validação não é instantânea, sendo preciso aguardar um

período de tempo que pode variar entre algumas horas e alguns dias. Caso não tenha sido

validado, será necessário realizar todo o procedimento novamente.

68

Capítulo 4

Conclusões e Trabalhos Futuros 4.1 – Conclusões

O protótipo inicialmente montado foi muito importante para entendimento do

fluxo de informações e os principais dados a serem cadastrados e exibidos, mesmo o

resultado final não sendo totalmente fiel ao planejado.

Além disso, os principais problemas percebidos a partir da pesquisa com os alunos

da UFRJ foram atacados satisfatoriamente, como a divulgação de vagas e informações

dos pré-requisitos, conforme visto na Figura 3.15.

4.2 – Trabalhos Futuros

Para trabalhos futuros, alguns pontos ficaram pendentes em relação ao protótipo

inicialmente previsto, como recuperação de senha e listagem de laboratórios, que

acabaram removidas da versão a ser entregue aos usuários. Além disso, seria importante

a conexão com a API do SIGA, para já extrair as informações de alunos,

professores,cursos e laboratórios e validar DRE e SIAPE de forma mais satisfatória.

Como último ponto interessante, um serviço de filas para trabalhar com uma possível alta

de acessos simultâneos.

Outro possível ponto a ser implementado posteriormente está nas informações

sobre os laboratórios, informando as suas respectivas pesquisas em andamento, algo que

foi percebido na pesquisa inicial com os alunos da UFRJ.

69

Bibliografia

[1] Centro de Memória - CNPq. Disponível em: <http://centrodememoria.cnpq.br/Missao2.html>. Acesso em: 21 de dez. de 2020.

[2] NETO, Manuel Domingos. Centro de Memória - CNPq. Disponível em: <http://centrodememoria.cnpq.br/domingos1.html>. Acesso em: 21 de dez. de 2020.

[3] MASSI, Luciana. QUEIROZ, Salete Linhares. Estudo sobre Iniciação Científica no Brasil: Uma Revisão. Cadernos de Pesquisa - . 2010.

[4] FAVA-DE-MORAES, Flávio. FAVA, Marcelo A Iniciação Científica: muitas vantagens e poucos riscos.

[5] Edital PIBIC / PIBITI 2020. Disponível em: <https://pibic.ufrj.br/content/files/edital_pibic_pibiti_2020_publicado.pdf>. Acesso em: 26 de dez. de 2020.

[6] Portal do Aluno UFRJ. Disponível em: <https://play.google.com/store/apps/details?id=br.ufrj.gnosys.mobile>. Acesso em: 05 de jan. de 2021.

[7] Caronaê. Disponível em: <https://caronae.org/>. Acesso em: 05 de jan. de 2021. [8] Cardápio RU-UFRJ. Disponível em:

<https://play.google.com/store/apps/details?id=br.ufrj.nce.cardapioru>. Acesso em: 05 de jan. de 2021.

[9] PINC - UFRJ. Disponível em: <https://pinc.tic.ufrj.br/>. Acesso em: 12 de jan. de 2021.

[10] Design Thinking: Uma forma inovadora de pensar e resolver problemas. Disponível em: <https://rockcontent.com/br/blog/design-thinking/>. Acesso em: 12 de jan. de 2021.

[11] Formulário de Pesquisa sobre divulgação de vagas de IC. Disponível em: <https://forms.gle/WCUNZ9cVFBwme7ou8>.

[12] Figma. Disponível em: <https://www.figma.com>. Acesso em: 12 de jan. de 2021.

[13] Express. Disponível em: <https://expressjs.com/pt-br/>. Acesso em: 22 de fev. de 2021.

[14] O que é DDD - Domain Driven Design? Disponível em: <https://fullcycle.com.br/domain-driven-design/>. Acesso em: 22 de fev. de 2021.

[15] Celebrate. Disponível em: <https://www.npmjs.com/package/celebrate>. Acesso em: 23 de fev. de 2021.

[16] O que é SOLID? Disponível em: <https://www.venturus.org.br/o-que-e-solid/>. Acesso em: 23 de fev. de 2021.

[17] Tsyringe. Disponível em: <https://www.npmjs.com/package/tsyringe>. Acesso em: 23 de fev. de 2021.

[18] TypeORM. Disponível em: <https://typeorm.io/#/>. Acesso em: 23 de fev. de 2021.

[19] ORM: Objective Relational Mapper. Disponível em: <https://www.devmedia.com.br/orm-object-relational-mapper/19056>. Acesso em: 23 de fev. de 2021.

[20] PostgreSQL. Disponível em: <https://www.postgresql.org/>. Acesso em: 23 de fev. de 2021.

70

[21] Docker. Disponível em: <https://www.docker.com/>. Acesso em: 23 de fev. de 2021.

[22] DBeaver. Disponível em: <https://dbeaver.io/>. Acesso em: 23 de fev. de 2021. [23] Insomnia. Disponível em: <https://insomnia.rest/>. Acesso em: 23 de fev. de

2021. [24] jsonwebtoken - npm. Disponível em:

<https://www.npmjs.com/package/jsonwebtoken>. Acesso em 23 de fev. de 2021. [25] Styled-components. Disponível em: <https://styled-components.com/>. Acesso

em: 28 de fev. de 2021. [26] Context API - React. Disponível em: <https://pt-

br.reactjs.org/docs/context.html>. Acesso em: 28 de fev. de 2021. [27] Axios. Disponível em: <https://github.com/axios/axios>. Acesso em: 28 de fev.

de 2021. [28] Ngrok. Disponível em: <https://ngrok.com/>. Acesso em: 28 de fev. de 2021. [29] Digital Ocean. Disponível em: <https://www.digitalocean.com/>. Acesso em: 16

de mai. de 2021. [30] Digital Ocean: o que é, como usar, vantagens e desvantagens. Disponível em:

<https://rockcontent.com/br/blog/digital-ocean/#quais>. Acesso em: 16 de mai. de 2021.

[31] O Que é SSH e Como Funciona? Disponível em: <https://www.weblink.com.br/blog/tecnologia/acesso-ssh-o-que-e/>. Acesso em: 16 de mai. de 2021.

[32] PuTTY. Disponível em: <https://www.putty.org/>. Acesso em: 16 de mai. de 2021.

[33] PM2. Disponível em: <https://pm2.keymetrics.io/>. Acesso em 16 de mai. de 2021.

[34] O que é certificado SSL e porque você deve utilizar no seu site. Disponível em: <https://www.hostgator.com.br/blog/o-que-e-certificado-ssl-e-porque-voce-deve-utilizar-no-seu-site/>. Acesso em: 16 de mai. de 2021.

[35] Google Domains. Disponível em: <https://domains.google.com/>. Acesso em: 16 de mai. de 2021.

[36] Certbot. Disponível em: <https://certbot.eff.org/>. Acesso em: 16 de mai. de 2021.

[37] Como criar uma conta na App Store e Google Play para publicar um aplicativo? Disponível em: <https://www.olivas.digital/blog/desenvolvimento/como-publicar-um-aplicativo/>. Acesso em: 16 de mai. de 2021.

[38] Publishing to Google Play Store. Disponível em: <https://reactnative.dev/docs/signed-apk-android>. Acesso em: 16 de mai. de 2021.