• Nenhum resultado encontrado

e-Chamada : o desenvolvimento e implantação de um sistema para o controle de frequência universitária

N/A
N/A
Protected

Academic year: 2021

Share "e-Chamada : o desenvolvimento e implantação de um sistema para o controle de frequência universitária"

Copied!
81
0
0

Texto

(1)

Instituto de Computa¸

ao

Departamento de Ciˆ

encia da Computa¸

ao

e-Chamada

O desenvolvimento e implanta¸c˜

ao de um sistema para o controle

de frequˆencia universit´

aria

Bruno Braga Guedes Cardoso

Leonardo Fernandes Lopes

Niter´

oi - RJ

2017

(2)

ii BRUNO BRAGA GUEDES CARDOSO E LEONARDO FERNANDES LOPES

e-Chamada

O desenvolvimento e implanta¸c˜ao de um sistema para o controle de frequˆencia universit´aria

Trabalho submetido ao Curso de Bacharelado em Ciˆencia da Computa¸c˜ao na Universidade Federal Fluminense como requisito parcial para a obten¸c˜ao do t´ıtulo de Bacharel em Ciˆencia da Computa¸c˜ao.

Orientador: Prof. Eugene F. Vinod Rebello

Niter´oi - RJ 2017

(3)
(4)

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

C268 Cardoso, Bruno Braga Guedes

e-Chamada : o desenvolvimento e implantação de um sistema para o controle de frequência universitária / Bruno Braga Guedes Cardoso, Leonardo Fernandes Lopes. – Niterói, RJ : [s.n.], 2017.

80 f.

Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.

Orientador: Eugene F. Vinod Rebello.

1. Sistema operacional. 2. Aplicativo móvel. 3. Android (Recurso eletrônico). I. Lopes, Leonardo Fernandes. II. Título.

CDD 005.44

(5)

“A alegria est´a na luta, na tentativa, no so-frimento envolvido e n˜ao na vit´oria propria-mente dita”. (Mahatma Gandhi)

(6)

vi

Agradecimentos

Agradecemos primeiramente a Deus, pelo dom da vida e pela oportunidade de cursarmos uma faculdade no n´ıvel de excelˆencia da UFF.

Agradecemos aos nossos pais, pelos ensinamentos transmitidos, pelas li¸c˜oes apren-didas e principalmente pelo est´ımulo e apoio na conclus˜ao de mais uma etapa da nossa jornada. Agradecemos a eles pela preocupa¸c˜ao em rela¸c˜ao ao estudo, bem como a insis-tˆencia e a cobran¸ca cont´ınua, pois isso s´o fez de n´os pessoas melhores e mais capacitadas a lidar com os problemas da vida.

Agradecemos a nossos professores, por todo o conhecimento que nos foi passado e por toda a sua preocupa¸c˜ao, determina¸c˜ao e resiliˆencia em suas aulas, tornando-as cada vez melhores, mais did´aticas e estimulando cada vez mais o aprendizado dos alunos. N´os vemos os seus esfor¸cos e agradecemos imensamente por isso.

Agradecemos tamb´em e, principalmente, ao nosso orientador, o professor Eugene Francis Vinod Rebello, que nos ensinou principalmente a questionar tudo o que nos ´e dito pois, afinal, tudo tem uma justificativa e ´e nosso dever busc´a-la com afinco. Ele nos ensinou a nunca desistir e a sempre buscar n˜ao apenas a forma correta, mas a melhor forma de resolver qualquer problema. A vocˆe, nossa sincera gratid˜ao, Vinod.

Agradecemos aos professores Alexandre Plastino de Carvalho e Aline de Paula Nascimento, por aceitarem nosso convite. Esperamos que este trabalho mostre a vocˆes o quanto aprendemos e o qu˜ao valiosas foram suas li¸c˜oes para n´os.

Por fim, estendemos nossos agradecimentos a todos os que, de alguma forma, nos auxiliaram para que pud´essemos estar aqui hoje. A todos vocˆes, muito obrigado!

(7)

Resumo

“Algo s´o ´e imposs´ıvel at´e que algu´em duvide e acabe provando o contr´ario”

Albert Einstein.

Este trabalho tem como objetivo desenvolver um sistema digital que permita ao professor substituir o processo atual de registrar a presen¸ca de aluno na sala de aula por um processo que consuma menos tempo e seja menos intrometido, uma vez que, atualmente, a presen¸ca ´e controlada manualmente e, ao final do per´ıodo, ´e necess´ario que o professor realize o c´alculo da frequˆencia de cada aluno para s´o ent˜ao registr´a-la no sistema acadˆemico.

O sistema proposto neste trabalho pretende facilitar o cumprimento do Regula-mento dos Cursos de Gradua¸c˜ao da UFF e permite a aloca¸c˜ao de professores e a inscri¸c˜ao de alunos em turmas bem como o registro de aulas por professores e a presen¸ca dos alunos e o c´alculo de frequˆencia durante o semestre, al´em de outras funcionalidades incluindo o uso do NFC da Carteirinha da UFF. Desenvolvido utilizando a linguagem Java, o sistema possui duas aplica¸c˜oes mobile desenvolvidas para Android e um servidor Linux, onde est´a implementado um banco de dados e uma aplica¸c˜ao web que permite que os dispositivos m´oveis interajam com o banco. Al´em disso, este sistema possui um site, tamb´em integrado a essa aplica¸c˜ao web, que permite acesso as diferentes informa¸c˜oes por quatro atores: o aluno, o professor, a coordena¸c˜ao do curso e o departamento. Ser˜ao apresentadas aqui a arquitetura do sistema, as tecnologias adotadas e a implementa¸c˜ao da vers˜ao do sistema que foi testado durante o semestre 2-2016.

Palavras-chave: Di´ario de classe, Sistema de controle acadˆemico, Servi¸co web, Aplicativo mobile Android, NFC.

(8)

viii

Abstract

“Something is only impossible until someone doubts and ends up proving otherwise” Albert Einstein.

Most educational institutions require teachers to take a roll call at every class. Normally, this manual process requires the teacher to ascertain the presence of each student in the classroom and, at the end of the semester, calculate the frequency of each student so that it may be registered on their academic record. This work aims to develop a online system that will allow the teacher to replace this current roll call process by one that consumes less time and is less intrusive.

Although the system proposed in this work aims to facilitate the adherence to academic regulations, it actually is required to do more than roll calls. It allows adminis-trators to manage disciplines and matriculate students and teachers, allocate teachers and enroll students in classes and calculate the frequency, as well as other functionalities in-cluding the use of Near Field Communication (NFC), available on student ID cards. The system has been developed using the Java programming language and is composed of two applications, both developed for Android based mobile devices, and a Linux-based web server with two components: a central database and a web application that allows mobile devices to interact with the database. In addition, this system has a website that has also been integrated to the web application to allow students, teachers, course coordinators and departments that offers disciplines, to access information, relevant and appropriate to their roles. We present the architecture of the system, the technologies adopted and the implementation of the version of the system tested during the current semester. Keywords: Frequency control, Academic management system, Web service, Android mo-bile applications, NFC.

(9)

Sum´

ario

Resumo vii

Abstract viii

Lista de Figuras xii

1 Introdu¸c˜ao 1

1.1 Descri¸c˜ao do problema . . . 1

1.2 Motiva¸c˜ao e Objetivo . . . 2

1.3 Organiza¸c˜ao da monografia . . . 4

2 Trabalhos Relacionados 6 2.1 e-Chamada: uma abordagem digital para o controle de frequˆencia escolar . 6 2.2 Riocard . . . 6

2.3 Google Classroom . . . 8

2.4 Resumo do cap´ıtulo . . . 9

3 Vis˜ao do Sistema 10 3.1 Atores envolvidos no sistema . . . 10

3.1.1 Departamento . . . 10

3.1.2 Coordena¸c˜ao de Curso . . . 12

3.1.3 Professor . . . 16

3.1.4 Aluno . . . 21

3.2 Fluxo de execu¸c˜ao dos processos do sistema . . . 22

3.3 Resumo do cap´ıtulo . . . 23

(10)

x 4 Tecnologias Relevantes 24 4.1 Linguagem . . . 24 4.1.1 Python . . . 24 4.1.2 Go . . . 25 4.1.3 Java . . . 25 4.1.4 Tecnologia Selecionada . . . 26 4.2 Sistema Operacional . . . 26

4.2.1 Microsoft Windows Server . . . 26

4.2.2 Linux . . . 27 4.2.3 Tecnologia Escolhida . . . 27 4.3 SGBD . . . 27 4.3.1 PostgreSQL . . . 28 4.3.2 MySQL . . . 30 4.3.3 SQL Server . . . 31

4.3.4 Bancos de Dados NoSQL . . . 31

4.3.5 MongoDB . . . 32 4.3.6 CockroachDB . . . 34 4.3.7 Tecnologia Selecionada . . . 35 4.4 Mobile . . . 36 4.4.1 iOS . . . 36 4.4.2 Android . . . 36 4.4.3 Tecnologia Selecionada . . . 37 4.5 NFC . . . 37 4.6 Resumo do cap´ıtulo . . . 38 5 Arquitetura do Sistema 39 5.1 Banco de dados . . . 39 5.2 Aplica¸c˜ao Web . . . 43 5.2.1 Settings . . . 45 5.2.2 DBFactory . . . 45 5.2.3 Exception . . . 46 5.2.4 Model . . . 46 5.2.5 DAO . . . 47

(11)

5.2.6 PaginasWeb . . . 47 5.2.7 WebServlet . . . 48 5.3 Aplicativo do Professor . . . 51 5.3.1 Banco de Dados . . . 51 5.3.2 Organiza¸c˜ao do C´odigo . . . 52 5.3.3 Manifesto . . . 53 5.3.4 Recursos . . . 53 5.4 Aplicativo da Coordena¸c˜ao . . . 53 5.4.1 Atividades . . . 53 5.5 Resumo do Cap´ıtulo . . . 54 6 Implanta¸c˜ao do Sistema 57 6.1 Ambiente Computacional . . . 57 6.1.1 Sistema Operacional . . . 57 6.1.2 Secure Shell (SSH) . . . 57

6.1.3 Virtual Private Network (VPN) . . . 58

6.2 Aplica¸c˜ao Web . . . 58

6.2.1 Servidor de Aplica¸c˜oes . . . 58

6.2.2 Servidor Web . . . 59

6.2.3 Acesso Seguro . . . 59

6.3 Servidor Gerenciador de Banco de Dados . . . 59

6.4 Dispositivos M´oveis . . . 59

7 Conclus˜ao 61 7.1 Dificuldades Encontradas . . . 61

7.2 Trabalhos Futuros . . . 63

7.3 Considera¸c˜oes Finais . . . 65

Siglas 67

(12)

xii

Lista de Figuras

3.1 Exemplo da tela inicial de um departamento . . . 11

3.2 Exemplo da tela de cria¸c˜ao de um professor . . . 11

3.3 Exemplo da tela de cria¸c˜ao de uma turma . . . 12

3.4 Exemplo de tela de listagem de alunos de uma coordena¸c˜ao no app mobile 13 3.5 Exemplo de tela de edi¸c˜ao de aluno de uma coordena¸c˜ao no app mobile . . 14

3.6 Exemplo da tela inicial da Coordena¸c˜ao . . . 15

3.7 Exemplo da tela de inser¸c˜ao de aluno da Coordena¸c˜ao . . . 15

3.8 Exemplo de tela de listagem de disciplinas de um professor no aplicativo mobile . . . 17

3.9 telas do aplicativo . . . 18

3.10 Exemplo de tela de listagem de disciplinas de um professor . . . 19

3.11 Exemplo de tela de detalhamento de disciplina . . . 19

3.12 Exemplo de tela de cria¸c˜ao de aula (1) . . . 20

3.13 Exemplo de tela de cria¸c˜ao de aula (2) . . . 20

3.14 Exemplo de tela de listagem de disciplinas de um aluno . . . 21

3.15 Exemplo de tela de listagem de aulas de uma determinada disciplina . . . . 22

5.1 Esquema do Banco de Dados . . . 41

5.2 Diagrama de Pacotes do Sistema . . . 45

5.3 Diagrama de classes da aplica¸c˜ao Web . . . 55

(13)

Cap´ıtulo 1

Introdu¸

ao

A educa¸c˜ao ´e a mat´eria-prima do conhecimento e, por meio dela, podemos nos desenvolver cultural, econˆomica e socialmente. Por´em este direito fundamental muitas vezes encontra obst´aculos para ser alcan¸cado. Estes obst´aculos, contudo, frequentemente podem ser suavizados a partir de iniciativas simples e acess´ıveis que podemos tomar para o bem coletivo. Com o recente avan¸co tecnol´ogico, os horizontes se ampliaram e cada vez mais novas tecnologias podem auxiliar o processo educativo das mais diversas maneiras. Este trabalho ´e uma iniciativa para fornecer instrumentos para ajudar a melhorar a educa¸c˜ao atrav´es do desenvolvimento ou utiliza¸c˜ao de novas tecnologias acess´ıveis e pr´aticas.

Um dos principais obst´aculos da educa¸c˜ao no Brasil ´e a evas˜ao escolar e ocorre quando um aluno deixa de frequentar a aula, caracterizando o abandono da escola durante o per´ıodo letivo. O abandono da escola ´e um problema em todos os n´ıveis educacionais no Brasil, desde o ensino fundamental ao ensino superior e muitas vezes ´e dif´ıcil identificar a causa deste fenˆomeno.

Para ajudar combater este problema, propomos o sistema e-Chamada para um controle mais efetivo da frequˆencia escolar. A partir deste controle, ´e poss´ıvel analisar o fenˆomeno da evas˜ao escolar, melhorar o diagn´ostico deste, identificar causas e, a partir disto, propor solu¸c˜oes para este desafio.

1.1

Descri¸

ao do problema

Atualmente o controle da frequˆencia escolar, quando este existe, ´e manualmente feito em di´arios de papel pelos pr´oprios professores, que fazem anota¸c˜oes durante todo o per´ıodo

(14)

2 letivo e ao final deste, devem calcular para cada aluno se sua frequˆencia foi suficiente ou n˜ao para aprova¸c˜ao.

Al´em do consumo de tempo dos professores e dos alunos na elabora¸c˜ao dos di´arios e durante o processo de chamada, ´e muito dif´ıcil obter informa¸c˜oes mais relevantes neste procedimento.

Dado o embara¸co que os di´arios de classe podem introduzir no processo educativo, especialmente em turmas com grande n´umero de alunos, em muitos casos, este controle de frequˆencia escolar simplesmente n˜ao ´e feito, o que impossibilita por completo a identi-fica¸c˜ao e o combate `a Evas˜ao Escolar em tempo h´abil, pois muitas vezes, este problema s´o ´e detectado no final do per´ıodo letivo vigente.

1.2

Motiva¸

ao e Objetivo

O objetivo do sistema e-Chamada proposto neste trabalho, ´e fornecer uma alternativa tecnol´ogica, pr´atica, acess´ıvel e confi´avel aos ineficientes di´arios de classe feitos manual-mente em papel. Agora, ser´a poss´ıvel que os professores realizem suas chamadas atrav´es de um sistema digital em dispositivos m´oveis.

Al´em disso, o e-Chamada tamb´em visa permitir que a institui¸c˜ao de ensino acom-panhe todo o processo de controle de frequˆencia escolar feito pelo professor, garantir que os di´arios de classes est˜ao sendo feitos corretamente, permitir um diagn´ostico dos problemas de evas˜ao em tempo ´agil, e facilitar cumprir a regulamenta¸c˜ao, como por exemplo, requirido pelo Regimento dos Cursos de Gradua¸c˜ao da Universidade Federal Fluminense [Lobo, 2015].

Com a ado¸c˜ao e avan¸cos de novas tecnologias, se faz necess´aria a discuss˜ao de certos pontos do regulamento da UFF. O primeiro artigo relevante ´e o Artigo 96, que diz:

Art. 96 – “A aprova¸c˜ao direta do discente ocorrer´a quando o mesmo obtiver m´edia parcial igual ou maior que 6,0 (seis) e sua frequˆencia igual ou maior a 75% (setenta e cinco porcento) da carga hor´aria da disciplina.”

Este artigo define a regra mais b´asica que rege a vida escolar de um aluno e a importˆancia do registro de presen¸ca na sala de aula: O mesmo deve possuir frequˆencia maior ou igual a 75% da carga hor´aria da disciplina e m´edia maior ou igual a 6,0 para ser considerado aprovado na mesma. Por´em, no Artigo 97, 101 e 102, temos requerimentos

(15)

adicionais que comprova a necessidade de implantar um processo robusto e confi´avel de verifica¸c˜ao da presen¸ca:

Art. 97, Par´agrafo ´unico – “O discente s´o poder´a ter consignada sua pre-sen¸ca e ser submetido `a verifica¸c˜ao de aprendizagem em turma em que esteja regularmente inscrito, como comprovado pelo seu registro no di´ario de classe.” Art. 101 Par´agrafo ´unico – “A partir do momento em que o discente ultrapas-sar o limite de faltas (superior a 25% da carga hor´aria total) numa disciplina, perder´a o direito de realizar as avalia¸c˜oes posteriores.”

Art. 102 - A Insuficiˆencia de Aproveitamento Escolar, para efeito de cancela-mento de matr´ıcula previsto no item (e) do Art. 60 deste Regulacancela-mento, ser´a caracterizada quando o discente: a)... d) For reprovado por frequˆencia em todas as disciplinas nas quais se inscreveu no per´ıodo de seu ingresso;

`

A princ´ıpio, Artigo 97 n˜ao ´e muito relevante ao projeto em quest˜ao. Por´em, ao realizarmos uma an´alise mais minuciosa dos processos utilizados na UFF, como 2o

cha-mada, per´ıodo de ajuste e fila de espera para uma disciplina, foi identificado o seguinte problema: A possibilidade do estudante ser inscrito em uma disciplina ap´os o in´ıcio do per´ıodo letivo. Inicialmente, o impacto desta mudan¸ca n˜ao deveria ser assim t˜ao grande, por´em o sistema acadˆemico utilizado atualmente na UFF realiza a atualiza¸c˜ao da listagem de alunos inscritos em uma determinada disciplina apenas 1 (uma) vez por mˆes, fazendo com que os alunos que sejam inscritos apenas no mˆes seguinte tenham perdido 8 aulas, o equivalente a 16 horas. Para uma disciplina de 64 horas, isto equivale a 25% da carga hor´aria. Como o Artigo 101 deixa claro que um aluno s´o poder´a realizar avalia¸c˜oes se n˜ao tiver ausˆencia maior que 25% da carga hor´aria total da disciplina, os alunos que s˜ao inseridos na turma ap´os o primeiro mˆes de aula deveriam ser, automaticamente, impos-sibilitados de realizar as provas e, como consequˆencia, reprovados na disciplina, al´em do fato de serem reprovados serem reprovados por falta, de acordo com o Artigo 96.

No caso dos alunos ingressantes oriundos de chamadas realizadas ap´os o in´ıcio do per´ıodo letivo, o artigo 102 diz, em seu item d, que o aluno ingressante que for reprovado por frequˆencia em todas as disciplinas nas quais estava inscrito no seu per´ıodo de ingresso tem sua matr´ıcula cancelada. Seguindo a mesma linha de racioc´ınio utilizada antes,

(16)

4 este aluno ingressante deveria ser, automaticamente, reprovado por falta em todas as disciplinas nas quais foi inscrito e, como consequˆencia, ter sua matr´ıcula cancelada.

Ao analisarmos o documento, percebemos que o regulamento n˜ao evoluiu e absor-veu as mudan¸cas implementadas pela automatiza¸c˜ao do processo de controle de inscri¸c˜ao de disciplinas oferecida pelo IdUFF. Por´em, ao estudarmos a forma como todo o processo funciona, percebemos que existem certas adapta¸c˜oes e exce¸c˜oes feitas pelas coordena¸c˜oes para que esses casos listados n˜ao sejam prejudicados. Para tentar criar um sistema que mais se aproximasse do que ´e utilizado hoje, o e-Chamada tamb´em foi criado tomando como base estas mesmas adapta¸c˜oes. Um exemplo disso ´e a forma como a frequˆencia de um aluno funciona: No e-Chamada, um aluno s´o tem sua presen¸ca computada durante o per´ıodo que o mesmo est´a inscrito da disciplina, e o c´alculo da frequˆencia ´e feita com base na quantidade de aulas que o mesmo assistiu durante o per´ıodo que estava inscrito. Em outras palavras, um aluno que est´a inscrito por dois meses em uma disciplina ter´a sua presen¸ca calculada utilizando apenas estes dois meses como base.

Al´em disso, como o sistema prop˜oe a automatiza¸c˜ao do processo de presen¸ca, todas as altera¸c˜oes feitas em rela¸c˜ao as inscri¸c˜oes dos alunos nas disciplinas s˜ao automaticamente refletidas para os professores, possibilitando um controle mais preciso do per´ıodo no qual seus alunos estavam inscritos na disciplina.

Por fim, o e-Chamada prop˜oe o aproveitamento de um dado que, hoje em dia, ´e imposs´ıvel de ser analisado: A frequˆencia dos alunos. Ao armazenar todas as presen¸cas de todos os alunos em todas as disciplinas, ´e poss´ıvel se realizar diversas an´alises, como por exemplo o qu˜ao impactante uma determinada aula pode ser no resultado final de uma turma, ou se todos os alunos que assistiram as aulas de um determinado t´opico acertaram as quest˜oes referentes aquele t´opico na prova. Com estas informa¸c˜oes, os professores ser˜ao capazes de coletar dados sobre o rendimento da sua turma de forma muito mais eficiente e r´apida, munindo-os da capacidade de reagir a problemas de forma mais eficiente.

1.3

Organiza¸

ao da monografia

Os pr´oximos 6(seis) cap´ıtulos desta monografia possuem os seguintes objetivos:

• Cap´ıtulo 2 - Trabalhos Relacionados: Ilustra os trabalhos que possuem rela¸c˜ao com este projeto.

(17)

• Cap´ıtulo 3 - Vis˜ao do Sistema: Apresenta uma vis˜ao do sistema desenvolvido, bem como os atores envolvidos e suas responsabilidades.

• Cap´ıtulo 4 - Tecnologias Relevantes: Cita as tecnologias que s˜ao relevantes a este projeto

• Cap´ıtulo 5 - Arquitetura do Sistema: Ilustra como o sistema est´a definido arquite-turalmente.

• Cap´ıtulo 6 - Implanta¸c˜ao do sistema: Define os requisitos necess´arios para a utili-za¸c˜ao deste sistema.

(18)

Cap´ıtulo 2

Trabalhos Relacionados

Este cap´ıtulo apresentar´a alguns projetos que possuem algum tipo de rela¸c˜ao com o e-Chamada, seja esta tecnol´ogica ou ideol´ogica. Foram selecionados 2 (dois) projetos que ser˜ao elucidados nas duas pr´oximas se¸c˜oes. Na quarta se¸c˜ao, ser´a apresentado um resumo do cap´ıtulo.

2.1

e-Chamada: uma abordagem digital para o

con-trole de frequˆ

encia escolar

O sistema proposto neste trabalho foi desenvolvido a partir da an´alise feita no trabalho de conclus˜ao de curso de Ciˆencia da Computa¸c˜ao da Universidade Federal Fluminense feito pela aluna Beatriz Barroso [Tavares Ferreira, 2016], onde, al´em da an´alise do problema foi feito a especifica¸c˜ao do sistema e implementa¸c˜ao de um prot´otipo.

2.2

Riocard

O primeiro dos sistemas selecionados para ser apresentado como trabalho relacionado ´e o sistema de Riocard [Piza, 2012]. Riocard ´e um sistema de pagamento eletrˆonico de passagens de transportes coletivos. Basicamente, o sistema funciona da seguinte forma: O usu´ario se cadastra no site e recebe um cart˜ao. A partir deste momento, o mesmo efetua recargas no cart˜ao e passa a pagar suas passagens utilizando o cart˜ao, encostando-o no leitor de Riocard.

Antes de explicar a fundo o funcionamento deste sistema, primeiro ´e necess´aria

(19)

a elucida¸c˜ao do conceito de NFC. NFC (Near Field Communication) ´e uma tecnologia que permite troca de informa¸c˜oes sem a utiliza¸c˜ao de fios, sendo necess´aria apenas a aproxima¸c˜ao f´ısica. Esta troca de informa¸c˜oes necessita de dois componentes para ser realizada. O primeiro destes chama-se tag NFC, que armazena as informa¸c˜oes. O segundo dispositivo que ´e utilizado no processo ´e chamado de leitor de tag NFC, e ´e respons´avel por ler os dados da tag ou sobrescrever os dados da mesma. Al´em disso, o leitor tamb´em ´e respons´avel pela comunica¸c˜ao com o servidor da aplica¸c˜ao.

O sistema de funcionamento do Riocard baseia-se em autentica¸c˜ao criptogr´afica. Basicamente, cada cart˜ao possui uma tag NFC onde s˜ao escritos o c´odigo identificador do usu´ario e duas chaves exclusivas daquele cart˜ao, que ser˜ao utilizadas no processo de auten-tica¸c˜ao. Para que a seguran¸ca deste m´etodo de autentica¸c˜ao seja garantida, ´e necess´ario que a chave nunca saia do pr´oprio cart˜ao, por isso ´e embutido tamb´em um microproces-sador que executar´a todos os processamentos criptogr´aficos necess´arios.

Basicamente o processo de criptografia funciona da seguinte forma: Quando o cart˜ao ´e encostado no leitor, o leitor define para o cart˜ao qual das duas chaves o mesmo deve usar. Ent˜ao o cart˜ao seleciona um n´umero aleat´orio e o envia ao leitor, como uma forma de provar a identidade do mesmo. O leitor receber´a o n´umero e o encriptar´a com a chave escolhida e o enviar´a para o cart˜ao juntamente com outro n´umero, tamb´em sorteado aleatoriamente, para que o cart˜ao tamb´em comprove sua autenticidade. Ao receber o n´umero, o cart˜ao o descriptografa e testa sua validade. Ao atestar a veracidade do valor, o cart˜ao criptografar´a o n´umero com sua pr´opria chave e o enviar´a ao leitor, que o descriptografar´a e validar´a se o n´umero recebido ´e o mesmo do enviado. Caso este processo se complete com sucesso, a tarifa ´e debitada, o saldo ´e atualizado diretamente no cart˜ao e salvo no validador para posterior sincroniza¸c˜ao com o servidor e a roleta ´e liberada.

Vale ressaltar que o saldo do usu´ario n˜ao ´e armazenado apenas no cart˜ao, esta informa¸c˜ao tamb´em fica armazenada no servidor, de forma que, caso o cart˜ao seja perdido ou furtado, o usu´ario poder´a requisitar outro cart˜ao e o seu saldo ´e preservado.

Este trabalho foi selecionado por utilizar de forma eficiente e segura uma tag NFC. No e-Chamada, as tags NFC s˜ao utilizadas para dar presen¸ca aos alunos, de forma que este trabalho serve como inspira¸c˜ao e material de estudo sobre como melhorar nosso sistema de comunica¸c˜ao entre a tag e o dispositivo que efetuar´a a leitura da mesma.

(20)

8

2.3

Google Classroom

O segundo aplicativo que foi selecionado foi o Google Classroom [Google, 2014]. Este aplicativo foi pensado de forma a automatizar uma parte espec´ıfica do ciclo escolar, que ´e a entrega de trabalhos, al´em de criar um ambiente colaborativo onde os alunos podem interagir entre si e com o professor para esclarecimentos, debates, etc.

Este aplicativo veio como uma alternativa para os professores gerenciarem entregas de trabalho, uma vez que se as entregas forem feitas por email ou alguma rede social, como Facebook, o professor precisar´a, por conta pr´opria, verificar quais alunos entregaram e quais deixaram de entregar. Al´em disso, sempre ocorrem problemas com o servidor de email e com alunos que n˜ao entregam o trabalho no prazo. Esta plataforma resolve estas duas situa¸c˜oes de uma forma bem pr´atica. A primeira situa¸c˜ao ´e resolvida da seguinte forma: para cada entrega de trabalho, uma pasta ´e criada dentro da conta do Google Drive do professor com o nome daquele aluno e todos os trabalhos entregues s˜ao salvos neste reposit´orio. Isto automatiza o processo de organiza¸c˜ao de entrega de trabalhos, uma vez que o Classroom j´a faz isto por si s´o.

O segundo ponto ´e resolvido da seguinte forma: O Google Classroom avisa a todos os alunos na tela inicial quais tarefas ele deve fazer e qual o prazo de entrega. Al´em disso, ele notifica quando a entrega est´a atrasada ou o trabalho n˜ao foi entregue no prazo, de forma que o aluno pode monitorar isto com mais tranquilidade. Al´em disso, o professor pode fechar a entrega de uma tarefa, de modo que, quando o prazo for atingido, o sistema n˜ao permitir´a mais o envio de nenhum arquivo. Isto garante que n˜ao haver´a entregas ap´os o prazo, uma vez que o pr´oprio sistema bloquear´a a tentativa de upload do aluno.

Apesar da tem´atica do Classroom n˜ao ter rela¸c˜ao no t´opico funcionalidades com o e-Chamada, este trabalho se relaciona com o projeto pois a Google foi capaz de pegar um processo que ´e simples e faz parte da dinˆamica de sala de aula e automatiz´a-lo, de forma que n˜ao h´a mais a necessidade do professor se preocupar com algumas das tarefas que a entrega de trabalho demanda, podendo utilizar melhor o seu tempo focando a corre¸c˜ao dos mesmos. Este trabalho serve de inspira¸c˜ao por mostrar que at´e o mais simples processo de automatiza¸c˜ao ´e capaz de fazer uma grande diferen¸ca na vida dos envolvidos.

(21)

2.4

Resumo do cap´ıtulo

Neste cap´ıtulo foram apresentados um trabalho anterior que levantou uma discuss˜ao sobre o problema e apresentou um prot´otipo e dois sistemas que possuem algo em comum com o e-Chamada. O primeiro aplicativo utiliza tags NFC para realizar a autentica¸c˜ao das pas-sagens do seu usu´ario, enquanto o segundo aplicativo serve para criar uma interface entre o aluno e o professor de forma a automatizar as entregas de trabalho de uma disciplina. Em ambos os casos, ´e poss´ıvel ver que a digitaliza¸c˜ao do ambiente ao qual o sistema ´e proposto gera um conforto e comodidade maiores aos seus usu´arios, j´a que em ambos os casos, os usu´arios reduzem a complexidade do processo ao qual est˜ao imersos quando este tem algum dos seus passos automatizados. No caso do Riocard, elimina-se a intera¸c˜ao de contar dinheiro e receber troco o que tornava o processo mais lento na hora de pagar a passagem. No caso do Google Classroom, cria-se um ambiente onde os alunos podem realizar discuss˜oes sobre a disciplina e automatizar a organiza¸c˜ao de entrega de trabalhos, visando agilizar este processo.

O pr´oximo cap´ıtulo apresentar´a uma vis˜ao do sistema desenvolvido durante este projeto, apresentando seus atores e seus respectivos pap´eis quando interagem com o e-Chamada.

(22)

Cap´ıtulo 3

Vis˜

ao do Sistema

O cap´ıtulo anterior apresentou sistemas que tˆem algum tipo de rela¸c˜ao e tentam fazer algo parecido em rela¸c˜ao `a proposta. Este cap´ıtulo tem como objetivo elucidar todos os atores envolvidos no sistema bem como seus respectivos pap´eis no mesmo. Al´em disso, este cap´ıtulo mapear´a todo o processo ao qual os usu´arios do sistema s˜ao submetidos, desde a cria¸c˜ao de uma turma a cria¸c˜ao de uma aula e preenchimento da presen¸ca dos alunos.

3.1

Atores envolvidos no sistema

Nesta vers˜ao do projeto, existem 4 (quatro) atores principais que interagem diretamente com o sistema e s˜ao eles: Departamento, Coordena¸c˜ao, Professor e Aluno. Cada um desses atores possui suas funcionalidades, permiss˜oes e capacidades dentro do e-Chamada.

Essa se¸c˜ao descrever´a, para cada ator, qual a sua responsabilidade dentro do sis-tema, bem como suas capacidade e obriga¸c˜oes dentro do mesmo. Por´em, dentre os quatro atores, alguns compartilham certas permiss˜oes ou possuem certas funcionalidades em co-mum que ser˜ao elucidadas ao final do cap´ıtulo.

3.1.1

Departamento

O primeiro ator do sistema ´e o departamento. Basicamente, o departamento ´e respons´avel por cadastrar os professores e as turmas do sistema, assim como sua cria¸c˜ao, remo¸c˜ao e aloca¸c˜ao de professores em turmas. O departamento utiliza apenas o sistema web para desempenhar suas tarefas, atrav´es de intera¸c˜oes que ser˜ao explicadas a seguir.

(23)

Figura 3.1: Exemplo da tela inicial de um departamento

Atrav´es da Figura 3.1 pode-se ver todas as responsabilidades do departamento. A tela ´e dividida em duas partes: `a esquerda o departamento ´e capaz de manipular os professores cadastrados no sistema vinculados a esse departamento e, `a direita, esse ator pode manipular as turmas cadastradas no sistema em per´ıodos anteriores, assim como criar novas turmas em per´ıodos futuros.

Figura 3.2: Exemplo da tela de cria¸c˜ao de um professor

A primeira funcionalidade a ser explorada ser´a a cria¸c˜ao de professores. Atrav´es da tela inicial, o departamento utilizar´a o bot˜ao ”Adicionar Novo Professor”que redirecionar´a para a tela representada pela Figura 3.2. A partir desta tela, o departamento preencher´a os dados do professor que deseja cadastrar e clicar´a no bot˜ao de salvar para que suas

(24)

12 altera¸c˜oes sejam inseridas no sistema. Vale lembrar que, na edi¸c˜ao de um professor, todo o procedimento ´e o mesmo, exceto pelo primeiro passo, que consiste em selecionar o professor na tela inicial do departamento.

Figura 3.3: Exemplo da tela de cria¸c˜ao de uma turma

A segunda responsabilidade do departamento ´e a cria¸c˜ao de uma turma. O sistema mapeia essa responsabilidade atrav´es da interface representada na Figura 3.3. Nesta tela, o departamento poder´a criar as turmas que ser˜ao ministradas no per´ıodo vigente. O usu´ario preencher´a o formul´ario com os dados necess´arios, como Disciplina, n´umero da turma, professor vinculado e dia/hora da aula. Ao finalizar o preenchimento do formul´ario, o usu´ario salvar´a e o sistema criar´a a nova turma no sistema. Ap´os a cria¸c˜ao, todas as turmas podem ser editadas. O procedimento ´e o mesmo da cria¸c˜ao, apenas sendo diferenciado no in´ıcio, quando o usu´ario escolher´a a turma que ser´a editada na tela inicial.

3.1.2

Coordena¸

ao de Curso

O segundo ator que tem participa¸c˜ao em parte do processo mapeado pelo e-Chamada ´e a Coordena¸c˜ao do Curso. Basicamente, esse ator tem como responsabilidade o cadastro de novos alunos e suas respectivas inscri¸c˜oes em turmas. Esse processo, diferentemente do processo realizado pelo departamento, ´e realizado durante todo o per´ıodo, pois com a possibilidade de haver diversas chamadas realizadas pelo pr´oprio SISU, a Coordena¸c˜ao deve ser capaz de matricular e inscrever alunos a qualquer momento do per´ıodo. Al´em disso, com a existˆencia do per´ıodo de ajuste, este ator deve ser capaz de inscrever e

(25)

desinscrever um aluno enquanto este per´ıodo estiver em vigor.

A atua¸c˜ao da coordena¸c˜ao se d´a atrav´es de 2(dois) sistemas. O primeiro sistema ´e a pr´opria aplica¸c˜ao web, atrav´es de um usu´ario especial que lhe concede permiss˜oes ´

unicas. O segundo sistema ´e uma aplica¸c˜ao mobile, que permite ao ator realizar algumas das tarefas que ele tamb´em pode realizar na aplica¸c˜ao web, por´em com um pequeno acr´escimo que ser´a elucidado a seguir.

3.1.2.1 Aplicativo Mobile

O primeiro intermedi´ario pelo qual este ator interage com sistema ´e o aplicativo Mobile da Coordena¸c˜ao. Dentro desse sistema, ele poder´a editar os dados dos alunos cadastrados. Mas, al´em disso, o aplicativo Mobile permite vincular ao usu´ario do aluno o c´odigo da sua carteirinha usando o leitor NFC do dispositivo.

(26)

14

Figura 3.5: Exemplo de tela de edi¸c˜ao de aluno de uma coordena¸c˜ao no app mobile

A partir da lista de alunos, exibida na Figura 3.4, a Coordena¸c˜ao ´e capaz de sele-cionar um aluno e editar suas informa¸c˜oes. Ao selecionar um aluno, a tela, representada na Figura 3.5 ser´a exibida e o ator poder´a editar todos os dados do aluno. Al´em disso, ele poder´a aproximar a carteirinha do celular e, se o mesmo possuir leitor de tag NFC, automaticamente o c´odigo daquele cart˜ao ser´a vinculado `aquele aluno, como sua carteiri-nha oficial cadastrada no sistema. Como a carteiricarteiri-nha ´e pessoal e intransfer´ıvel, a edi¸c˜ao de alunos atrav´es dessa plataforma ´e feita de forma individual, ou seja, apenas um aluno por vez.

3.1.2.2 Aplicativo Web

A segunda interface que ´e dispon´ıvel para a Coordena¸c˜ao ´e o aplicativo web, e ´e atrav´es dela que este usu´ario realizar´a a maior parte das suas intera¸c˜oes com o sistema. Ap´os a autentica¸c˜ao no sistema, ser´a exibida a tela de listagem de alunos, exemplificada pela Figura 3.6.

(27)

Figura 3.6: Exemplo da tela inicial da Coordena¸c˜ao

Figura 3.7: Exemplo da tela de inser¸c˜ao de aluno da Coordena¸c˜ao

Atrav´es desta tela, a coordena¸c˜ao pode optar por criar um aluno. Ao selecionar para efetuar a cria¸c˜ao, uma tela, representada pela Figura 3.7 ´e exibida. A partir da´ı, o usu´ario preencher´a com os dados do aluno e o sistema efetuar´a o salvamento dos mesmos. Para a edi¸c˜ao de alunos, o processo ´e o mesmo, exceto no primeiro passo, onde a Coor-dena¸c˜ao selecionar´a o aluno a ser editado na tela inicial. Al´em disso, durante a edi¸c˜ao, ´e poss´ıvel inscrever e desinscrever (cancelar inscri¸c˜ao) o aluno selecionado em uma deter-minada disciplina, de forma que todo o processo de per´ıodo de ajuste possa ser coberto pelo sistema.

Por fim, a ´ultima funcionalidade do sistema ´e o cadastro de alunos em lote por meio do upload de uma planilha. Essa planilha, que acompanha um formato espec´ıfico,

(28)

16 permite que a coordena¸c˜ao realize o cadastro de alunos no sistema em forma de pacote, permitindo que o usu´ario cadastre m´ultiplos alunos de uma ´unica vez.

3.1.3

Professor

O terceiro ator que interage com o sistema ´e o Professor. Esse ator ´e o ´unico que lida diretamente com a quest˜ao de presen¸cas de aluno e cria¸c˜ao de aulas das turmas nas quais ele leciona. O professor interage com o e-Chamada atrav´es de 2(dois) sistemas: O sistema Web e o aplicativo Mobile de presen¸ca, que ser˜ao explicados nas duas subse¸c˜oes a seguir:

3.1.3.1 Aplicativo Mobile

O Aplicativo Mobile do Professor, ´e um aplicativo exclusivo deste ator que tem como responsabilidade principal substituir a folha de presen¸ca que ´e utilizada normalmente em todas as aulas.

Atrav´es desta aplica¸c˜ao, o professor poder´a, durante suas aulas, efetuar sua cha-mada sem a necessidade de utilizar folhas de papel, apenas com o apertar de um bot˜ao.

Como podemos ver pela Figura 3.8, o professor pode, ap´os realizar uma autenti-ca¸c˜ao no sistema, selecionar uma disciplina e clicar no bot˜ao ”Iniciar Aula”, caso deseje fazer uma chamada vinculada `aquela disciplina.

A partir da Figura 3.9a ´e poss´ıvel observar que, mesmo que o dispositivo m´ovel do professor n˜ao contenha leitor de tag NFC, o aplicativo continuar´a funcionando, apenas desabilitando a funcionalidade de leitura da carteirinha, aceitando apenas a entrada de presen¸ca manual, atrav´es do checkbox, exibido na lista de alunos. Atrav´es da Figura 3.9b, podemos ver que, ao iniciar um aula, o professor tem `a sua disposi¸c˜ao uma tela que o diz a turma `a qual aquela lista de presen¸ca est´a vinculada, al´em da data e hora da cria¸c˜ao da mesma. Al´em disso, o professor tamb´em tem `a sua disposi¸c˜ao um campo de assunto, o qual pode ser preenchido com os t´opicos principais dados naquela aula. Por fim, abaixo do cabe¸calho, temos a lista de alunos inscritos na disciplina no momento em que a aula foi aberta. Associado ao nome de cada aluno, h´a um checkbox que ´e respons´avel pela presen¸ca daquele aluno. O professor pode marc´a-lo manualmente ou atrav´es da carteirinha do aluno, encostando-a no celular com o leitor de NFC ativo. Quando o professor marca a presen¸ca do aluno atrav´es da carteirinha, o campo de checkbox ´e desativado, para que a presen¸ca n˜ao possa ser desmarcada manualmente. Caso contr´ario, o campo continua

(29)

Figura 3.8: Exemplo de tela de listagem de disciplinas de um professor no aplicativo mobile

ativado at´e que o professor feche a lista de presen¸ca. Todos os usu´arios que possuem carteirinha cadastrada no sistema s˜ao simbolizados pelo ´ıcone de um cart˜ao ao lado do pr´oprio nome, como tamb´em ´e poss´ıvel observar na Figura 3.9b.

3.1.3.2 Aplica¸c˜ao Web

Para a interface web, as op¸c˜oes s˜ao mais diversificadas do que as do dispositivo m´ovel, que permite apenas a cria¸c˜ao de uma lista de presen¸ca.

Na tela inicial, ap´os o login do professor, ´e exibida uma lista de todas as turmas lecionadas pelo mesmo durante o semestre selecionado, como ´e poss´ıvel observar na Figura 3.10. Atrav´es da aba superior, o professor poder´a navegar dentre os semestres nos quais j´a ministrou alguma disciplina para realizar opera¸c˜oes em alguma determinada turma.

Ap´os selecionar uma disciplina na tela inicial, o professor receber´a como resposta uma tela contendo os detalhes daquela turma, como aulas ministradas, alunos inscritos,

(30)

18

(a) tela inicial (b) visualiza¸c˜ao de menu

Figura 3.9: telas do aplicativo

dias e hor´arios nos quais aquelas aulas foram ministradas, como ´e poss´ıvel ver na Figura 3.11. Atrav´es dessa tela, o professor pode realizar uma s´erie de intera¸c˜oes com o sistema, e a primeira delas ´e a cria¸c˜ao de uma nova aula.

Ao clicar no bot˜ao ”Adicionar uma nova aula” o professor receber´a como resposta uma caixa textual onde o mesmo dever´a inserir a data na qual a aula daquela disciplina foi ministrada, como ´e poss´ıvel ver na Figura 3.12. Ap´os preencher a data, uma nova aula ´e criada e o professor recebe como resposta a tela representada pela Figura 3.13, que exibe os dados b´asicos da aula, como turma e disciplina associada, mas tamb´em disponibiliza um campo de assunto, para que o professor possa introduzir os t´opicos principais que foram ministrados naquela aula. Al´em disso, por padr˜ao, a nova aula ´e criada dando presen¸ca para todos os alunos inscritos na disciplina at´e o momento da cria¸c˜ao. Para remover a presen¸ca de um aluno (dar falta ao mesmo) o professor deve ir at´e a parte de

(31)

Figura 3.10: Exemplo de tela de listagem de disciplinas de um professor

Figura 3.11: Exemplo de tela de detalhamento de disciplina

alunos presentes, encontrar o aluno buscando pelo nome e clicar no ”X” ao lado de seu nome. A partir da´ı, o aluno ser´a removido da lista de alunos presentes e adicionado a lista de alunos ausentes.

A segunda funcionalidade dispon´ıvel no sistema ´e a edi¸c˜ao de uma aula ministrada anteriormente. O processo de edi¸c˜ao da aula ´e o mesmo de cria¸c˜ao, a ´unica diferen¸ca ocorre no momento de selecionar a aula a ser editada, que acontece na tela de detalhamento de disciplina, quando o professor clica em uma aula ministrada dentre as dispon´ıveis.

Por fim, a ´ultima funcionalidade dispon´ıvel ´e o upload de di´ario, que permite ao professor atualizar os alunos inscritos na sua turma. Este upload ´e feito na tela represen-tada pela Figura 3.11, utilizando o bot˜ao no canto superior esquerdo, ao lado da foto do

(32)

20

Figura 3.12: Exemplo de tela de cria¸c˜ao de aula (1)

Figura 3.13: Exemplo de tela de cria¸c˜ao de aula (2)

usu´ario. Atrav´es do di´ario extra´ıdo do IdUFF, o professor poder´a fazer upload do mesmo no sistema e, automaticamente, os alunos novos inscritos ser˜ao matriculados assim como os alunos removidos ser˜ao retirados da lista de inscritos. Vale ressaltar que remover um aluno da disciplina n˜ao significa removˆe-lo das listas de presen¸ca que j´a existem e nas quais ele j´a possui um status. Outro detalhe importante ´e que, caso um aluno n˜ao esteja cadastrado no sistema, esse recurso n˜ao o cadastrar´a nem o matricular´a na disciplina, pois os dados advindos dessa planilha n˜ao s˜ao suficientes para a cria¸c˜ao do mesmo. Ser´a necess´ario que a coordena¸c˜ao efetue o cadastro deste indiv´ıduo para, s´o ent˜ao, o mesmo ser matriculado na turma.

(33)

3.1.4

Aluno

O ´ultimo e mais limitado dos atores envolvidos ´e o Aluno. Basicamente, o aluno s´o possui permiss˜ao de consulta dos dados j´a contidos no sistema das disciplinas nas quais ele est´a inscrito.

Figura 3.14: Exemplo de tela de listagem de disciplinas de um aluno

Como ´e poss´ıvel ver na Figura 3.14, a tela inicial `a qual o aluno tem acesso ´e a sua tela de disciplinas. Nesta tela, ´e poss´ıvel que o mesmo visualize todas as disciplinas nas quais est´a inscrito e, al´em disso, atrav´es da barra superior, o aluno poder´a navegar dentre todos per´ıodos j´a cursados e conferir seu hist´orico escolar de frequˆencia de forma r´apida e intuitiva. Al´em de exibir as disciplinas divididas por per´ıodo, a tela inicial tamb´em oferece uma pr´evia sobre quem foi o professor que lecionou naquela turma naquele per´ıodo.

A partir da Figura 3.15, ´e poss´ıvel visualizar como ´e a tela de consulta de aulas em uma determinada disciplina. A p´agina cont´em mais informa¸c˜oes acerca daquela turma, como c´odigo da disciplina, per´ıodo no qual a mesma foi lecionada, n´umero da turma, os dias e hor´arios nos quais as aulas eram realizadas e tamb´em, ´e poss´ıvel consultar a presen¸ca em cada aula individualmente. As aulas ficam divididas em dois grupos: o grupo de aulas nas quais o aluno estava presente e o grupo de aulas nas quais o aluno estava ausente. Al´em disso, cada aula possui um indicador que notifica ao aluno se aquela presen¸ca foi dada manualmente pelo professor, ou pelo pr´oprio aluno, atrav´es do sistema de valida¸c˜ao de presen¸ca via NFC.

(34)

22

Figura 3.15: Exemplo de tela de listagem de aulas de uma determinada disciplina

dados, tornando-o o ator mais limitado em rela¸c˜ao ao sistema, j´a que o mesmo n˜ao produz dados atrav´es de uma intera¸c˜ao direta com o mesmo, mas atrav´es de intera¸c˜oes com a aplica¸c˜ao de frequˆencia no dispositivo m´ovel do professor. E, por fim, apesar de o aluno n˜ao produzir diretamente dados para o sistema, ele ainda ´e um dos principais envolvidos na maioria dos processos aos quais o sistema oferece suporte, mesmo que n˜ao tenha uma influˆencia direta sobre a produ¸c˜ao desses dados.

3.2

Fluxo de execu¸

ao dos processos do sistema

Nesta se¸c˜ao, ser´a elucidada a forma como todos os processos de cada usu´ario se encaixam no sistema. Em outras palavras, ser´a feita a cria¸c˜ao de um fluxo de execu¸c˜ao que exibe a ordem na qual as tarefas devem ser executadas no sistema.

O primeiro usu´ario a realizar suas tarefas no sistema ´e o Departamento. ´E ne-cess´ario que o Departamento realize a cria¸c˜ao dos professores ingressantes no instituto e definir as novas turmas que ser˜ao oferecidas no semestre. Ap´os garantir que as turmas est˜ao criadas e que os professores est˜ao inseridos no sistema e devidamente alocados em suas turmas, cabe apenas ao departamento fazer a manuten¸c˜ao do hor´ario das aulas de cada turma, mas este passo n˜ao interfere no processo final, j´a que esta tarefa n˜ao impacta diretamente em nenhuma tarefa de nenhum outro envolvido.

Quando as turmas est˜ao criadas, o segundo passo pode ser realizado. A partir da´ı, a Coordena¸c˜ao pode iniciar a inscri¸c˜ao de alunos em suas respectivas turmas. Vale

(35)

ressaltar que o processo de cria¸c˜ao de alunos ´e independente do primeiro passo, ou seja, a Coordena¸c˜ao poder´a criar seus alunos no sistema sem precisar esperar at´e que o Depar-tamento fa¸ca a cria¸c˜ao das turmas, podendo apenas deixar a aloca¸c˜ao para ser executada neste segundo passo.

A partir da´ı, os usu´arios Professor e Aluno s˜ao capazes de utilizar o sistema ao longo de todo um per´ıodo letivo. O professor poder´a abrir as listas de presen¸ca atrav´es do seu aplicativo, ou cri´a-las atrav´es do site a qualquer momento. J´a o aluno poder´a consultar suas presen¸cas em cada aula, bem como os t´opicos dados e sua taxa de frequˆencia naquela turma at´e o momento.

3.3

Resumo do cap´ıtulo

Neste cap´ıtulo foram definidos os atores que interagem diretamente com o e-Chamada bem como suas respectivas permiss˜oes e a¸c˜oes no sistema, al´em de apresentar uma des-cri¸c˜ao detalhada do processo envolvido em cada a¸c˜ao individualmente, como resposta do sistema ap´os a realiza¸c˜ao de cada a¸c˜ao e imagens ilustrando como essa resposta deveria se apresentar. Na se¸c˜ao 3.2 foi elucidado o processo geral mapeado pelo e-Chamada, como cada ator se encaixa nele e a ordem na qual o mesmo deve executar suas a¸c˜oes de forma que o processo seja executado sem apresentar problemas a nenhum dos envolvidos, nem ao pr´oprio ator e nem aos atores cujas tarefas dependem do sucesso da tarefa realizada pelo mesmo.

O pr´oximo cap´ıtulo tratar´a das tecnologias relevantes utilizadas na implementa¸c˜ao do projeto, al´em de apresentar uma discuss˜ao sobre as candidatas que foram analisadas em conjunto com aquela tecnologia e o porquˆe desta ter sido a escolhida.

(36)

Cap´ıtulo 4

Tecnologias Relevantes

No cap´ıtulo anterior, foi apresentada a vis˜ao sobre todo o sistema que foi desen-volvido durante este projeto, assim como os atores endesen-volvidos, suas respectivas responsa-bilidades e as interfaces nas quais eles interagir˜ao para executar suas atividades. Al´em disso, foi apresentado um fluxo de atividades que mapeia a ordem nas quais as atividades devem ser executadas dentro do sistema.

Neste cap´ıtulo, ser˜ao abordadas todas as tecnologias utilizadas no projeto, exibindo todas as tecnologias que foram estudadas, explicando o seu funcionamento, e justificando o porquˆe de determinada tecnologia ter sido escolhida.

4.1

Linguagem

Nesta se¸c˜ao, ser˜ao apresentadas todas as linguagens candidatas para o desenvolvimento do sistema, junto com uma breve descri¸c˜ao do seu funcionamento e, ao final, uma conclus˜ao, justificando a escolha de uma linguagem em detrimento das demais.

4.1.1

Python

Python ´e uma linguagem script, interpretada, que foi criada em 1989 e lan¸cada em 1995 por Guido Van Roosum [Venners, 2003], baseada na linguagem ABC. Python foi escolhida para avalia¸c˜ao pois ´e uma linguagem relativamente simples de se codificar e oferece diversas bibliotecas e frameworks que auxiliam os desenvolvedores a realizar diversas tarefas de forma r´apida e f´acil, como por exemplo o framework para desenvolvimento web django. Al´em disso, esta ´e uma linguagem orientada a objetos, o que facilita bastante o processo

(37)

de desenvolvimento uma vez que a equipe j´a est´a habituada com este paradigma.

Por´em, o que pesa negativamente ´e o desempenho desta linguagem, que quando comparado a outras linguagens populares, como Java, apresentou um tempo de resposta at´e duas vezes maior em alguns testes, tornando-a pouco atrativa para o uso.

4.1.2

Go

Go ´e uma linguagem de programa¸c˜ao estruturada, open-source [gol, 2009] que torna f´acil o desenvolvimento de aplica¸c˜oes simples, confi´aveis e eficientes. Apresenta um excelente desempenho at´e mesmo quando comparada a linguagens conhecidas pelo desempenho, como C e C++, e, como Python, oferece diversas bibliotecas e frameworks para facilitar o desenvolvimento de aplica¸c˜oes, combinando o desempenho de linguagens compiladas tradicionais com a facilidade de escrita de linguagens de script.

Por´em, o que pesou negativamente ´e o fato de ser uma linguagem com a qual nenhum dos desenvolvedores tinham experiˆencia, e o tempo de aprendizado da nova lin-guagem poderia atrapalhar o cronograma do sistema. Al´em disto, n˜ao ´e poss´ıvel o de-senvolvimento de aplicativos na plataforma Android na linguagem de programa¸c˜ao Go, o que impossibilitaria a portabilidade de c´odigo entre os diferentes componentes do sistema e-Chamada.

4.1.3

Java

Java ´e uma linguagem orientada a objetos[Gosling et al., 2013], imperativa, estrutural, criada em 1991 e lan¸cada em 1995 pela Sun Microsystems. ´E uma linguagem cujo c´odigo ´e compilado para bytecode e este c´odigo ´e executado diretamente numa m´aquina virtual pr´opria da linguagem.

Java possui diversas caracter´ısticas: ´E uma linguagem relativamente f´acil de se programar, por´em ´e uma linguagem verbosa, isto ´e, por ser fortemente tipada, toda a sua sintaxe ´e fortemente definida e, por consequˆencia, seus comandos se tornaram extensos.

Apesar disso, Java apresenta diversas tecnologias sobre as quais podem se desen-volver p´aginas web, dentre elas as mais comuns s˜ao JSP e JSF. Al´em disso, Java possui o conceito de Servlet, que s˜ao servi¸cos ´unicos que possibilitam ao servidor tratar requisi¸c˜oes HTTP vindas da Web, o que ´e perfeito para se utilizar em integra¸c˜ao com os aplicativos Mobile.

(38)

26 Por fim, Java possui centenas de frameworks que apresentam as mais diversas funcionalidades, desde o Hibernate [hib, 2016], que cuida de toda a parte de requisi¸c˜oes ao banco de dados, ao Vaadim, que permite ao desenvolvedor criar interfaces de forma r´apida e f´acil.

Apesar de Java ser extremamente estruturada e excessivamente verbosa, ´e uma excelente linguagem para desenvolvimento web, uma vez que suas ferramentas permitem que o desenvolvedor fa¸ca muitas coisas de maneira r´apida e apresenta um bom desempenho quando comparada a Python e outras linguagens script.

4.1.4

Tecnologia Selecionada

Apesar de Python ser simples e apresentar diversas bibliotecas e do desempenho e faci-lidades do Go, Java foi a linguagem escolhida pela experiˆencia que os desenvolvedores j´a possu´ıam com a tecnologia. Al´em disso, Java foi a linguagem estudada pelo time durante toda a faculdade, o que a torna a linguagem com a qual a equipe tem mais horas de ex-periˆencia, reduzindo assim a probabilidade de introduzir bugs por falta de conhecimento da linguagem ou dos frameworks associados.

4.2

Sistema Operacional

O Sistema Operacional ´e uma das caracter´ısticas mais importantes para a defini¸c˜ao do ambiente computacional sobre o qual executar´a o sistema. Esta se¸c˜ao trata sobre as principais tecnologias dispon´ıveis para servidores e justifica qual foi a solu¸c˜ao utilizada.

4.2.1

Microsoft Windows Server

´

E a vers˜ao do tradicional sistema operacional Windows da Microsoft para servidores. Muito utilizado, especialmente em ambientes corporativos devido `a pouca compatibilidade de ferramentas corporativas da Microsoft com outros sistemas operacionais, o Windows Server deixa a desejar em v´arios aspectos, como o alto custo da licen¸ca e do hardware para suport´a-lo.

(39)

4.2.2

Linux

Conhecido pela sua eficiˆencia, o Linux ´e um sistema operacional open-source com v´arias distribui¸c˜oes dispon´ıveis, permitindo o uso deste sistema para diversas aplica¸c˜oes diferen-tes, como servidores, computadores pessoais, dispositivos m´oveis e at´e mesmo internet das coisas. Por causa da alta flexibilidade e abertura deste sistema, ´e poss´ıvel a escolha de melhor tecnologia poss´ıvel sem nenhum tipo de restri¸c˜ao comercial nem de licen¸ca, dei-xando o ambiente computacional mais favor´avel ao desenvolvimento de novas tecnologias. Al´em disso, o Linux ´e um sistema operacional muito est´avel, tornando o ambiente mais confi´avel e com baixo risco de falhas.

4.2.3

Tecnologia Escolhida

O CentOS, que ´e uma distribui¸c˜ao do Linux, tamb´em open-source, otimizada para uso em servidores foi o sistema operacional escolhido para uso em nosso ambiente devido `a excelente rela¸c˜ao custo-benef´ıcio. Considerando que nossas aplica¸c˜oes n˜ao dependem de nenhuma ferramenta da Microsoft que necessite de um ambiente Windows, foi poss´ıvel a escolha da melhor tecnologia para o uso em nosso servidor sem nenhuma preocupa¸c˜ao com compatibilidade de sistemas. Al´em disso, esta decis˜ao se mostrou bastante acertada durante o per´ıodo de uso do sistema, uma vez que ele atendeu `as expectativas e n˜ao apresentou nenhum tipo de falhas ou travamentos.

4.3

SGBD

No que diz respeito ao SGBD (Sistema de Gerenciamento de Banco de Dados) , algumas quest˜oes foram discutidas para que a ferramenta pudesse ser considerada adequada ao sistema. A lista a seguir define todos os crit´erios utilizados para esta avalia¸c˜ao:

• Familiaridade dos desenvolvedores: O curto tempo dispon´ıvel tornava necess´ario algum hist´orico de trabalho de ao menos parte dos desenvolvedores com esta, a fim de que fosse dispens´avel um investimento muito grande para aprender como manuse´a-la.

• Atender aos requisitos: A ferramenta deve ser capaz de armazenar os dados de forma a garantir a integridade dos mesmos e, ao mesmo tempo, permitir que os usu´arios

(40)

28 fa¸cam acessos simultˆaneos ao sistema. Al´em disso, por serem armazenados no banco dados considerados sens´ıveis, como senha e CPF, estes precisam ser protegidos con-tra acessos diretos `a base, por isso deve haver mecanismos internos de seguran¸ca de forma que tais informa¸c˜oes sejam criptografadas e escondidas de qualquer um que venha a ter acesso direto ao SGBD.

• Escalabilidade: ´E necess´ario ter um banco de dados que seja escal´avel, ou seja, tenha a capacidade de atender a um grande volume de requisi¸c˜oes de forma r´apida e que, conforme esse n´umero varie, o banco conseguisse absorver essa varia¸c˜ao e responder ativamente de alguma forma, pois, como temos uma ferramenta que disponibiliza aos alunos suas salas de aula e hor´arios, se todos estes resolvessem utilizar o sistema no mesmo instante, ter´ıamos nada menos do que 49.128 usu´arios fazendo requisi¸c˜oes simultˆaneas ao sistema e, com um n´umero t˜ao grande de usu´arios, ´e necess´ario que o sistema consiga, de alguma forma, atender a todos e respondˆe-los corretamente em um intervalo de tempo aceit´avel.

• Gerenciamento de uma grande massa de dados: Com aproximadamente 50 (cin-quenta) mil usu´arios em potencial, a massa de dados gerada diariamente seria gi-gantesca acarretando na necessidade de se ter um banco de dados que desse conta de gerir toda essa massa. Por serem dados hist´oricos que relatam sobre a vida de um aluno na universidade, desde presen¸cas a quantidade de per´ıodos, mat´erias cursadas, etc, esses dados n˜ao poderiam ser apagados, acarretando no fato de que a base s´o cresceria e nunca poderia ser reduzida, uma vez que qualquer aluno j´a inscrito no sistema pode acessar o site para realizar consultas.

• Compatibilidade: Era necess´ario ter uma ferramenta que fosse compat´ıvel com todas as demais tecnologias selecionadas para o projeto. Como todas as tecnologias eram uma decis˜ao dos desenvolvedores, a ferramenta de banco de dados tinha que ser compat´ıvel com todas as demais ferramentas, desde o Sistema Operacional at´e a Linguagem de Programa¸c˜ao escolhida.

4.3.1

PostgreSQL

O primeiro candidato ´e o PostgreSQL [The PostgreSQL Global Development Group, 2016]. Infelizmente, ele n˜ao atende ao primeiro ponto pois nenhum dos desenvolvedores do

(41)

sis-tema proposto possui hist´orico de uso com essa ferramenta.

Por ser um SGBD (Sistema de Gerenciamento de Banco de Dados), o PostgreSQL ´e capaz de atender ao segundo quesito sem problemas: Ele possui um sistema interno de controle de locks, que permite acessos simultˆaneos aos dados e garante que os dados consultados pela aplica¸c˜ao em cada conex˜ao sempre estar˜ao isolados dos dados que s˜ao produzidos pelas demais. Al´em disso, ele possui uma biblioteca que se chama pgcrypto, que permite encriptar certas colunas de determinadas tabelas do banco, de forma que esses dados sempre estejam protegidos de qualquer acesso externo que n˜ao seja atrav´es de requisi¸c˜oes da aplica¸c˜ao.

No caso do terceiro ponto, o Postgre ´e, dentre os SGBDs gratuitos, o mais utilizado em aplica¸c˜oes de grande porte, que necessitam de um grande volume de tr´afico de dados. Esse SGBD tamb´em possui heur´ısticas internas no seu m´odulo de otimiza¸c˜ao muito mais robustas e eficientes que as da maioria dos seus concorrentes, permitindo que, por exemplo, ele execute uma ordena¸c˜ao em dados de uma tabela utilizando o MergeSort antes de realizar uma busca, otimizando assim o acesso indexado a disco. Esses fatores indicam que ele atende a este ponto de forma satisfat´oria, apesar de apresentar lentid˜ao conforme o volume de dados aumenta muito.

No quarto ponto, o Postgre possui certos limites em rela¸c˜ao `a capacidade, que ser˜ao listados a seguir:

Limite Valor

Tamanho m´aximo da base Ilimitado Tamanho m´aximo de tabela 32 TB

Tamanho m´aximo de tupla 1.6 TB Tamanho m´aximo de campo 1 GB

Limite de linhas por tabela Ilimitado Limite de colunas por tabela 250 - 1600

Limite de ´ındices por tabela Ilimitado

Tabela 4.1: Limites de armazenamento do PostgreSQL

Como podemos perceber analisando a Tabela 4.1, a base de dados pode conter um tamanho ilimitado, o que atende `a demanda crescente de dados que o e-Chamada proporcionaria. Al´em disso, cada tabela possui um tamanho m´aximo de 32 TB, o que

(42)

30 tamb´em atende ao quarto ponto, pois, no geral, os dados produzidos pelo sistema s˜ao relativamente pequenos e, apesar de serem volumosos, ainda n˜ao seriam suficientes para que o limite fosse atingido com facilidade.

Em rela¸c˜ao ao quinto ponto, o PostgreSQL atende `as necessidades, pois ´e relativa-mente f´acil instal´a-lo no CentOS e trabalhar com ele utilizando Java, que, como visto nas se¸c˜oes 4.1 e 4.2, foram as tecnologias escolhidas para Sistema Operacional e Linguagem de Programa¸c˜ao, respectivamente.

4.3.2

MySQL

O segundo candidato selecionado foi o MySQL [Oracle, 2016]. Apesar de haver certo preconceito dentre os usu´arios do MySQL, este ´e o banco mais conhecido dentre os de c´odigo aberto atualmente. Criado em 1980, O MySQL ´e utilizado por diversas empresas que utilizam aplica¸c˜oes cr´ıticas, como a NASA e a Motorola, por exemplo.

Por ser um SGBD, O MySQL ´e capaz de garantir o segundo ponto com efic´acia, j´a que todos os SGBDs apresentam as propriedades ACID.

Em rela¸c˜ao ao terceiro ponto, o MySQL deixa a desejar em certos aspectos pois o seu m´odulo de otimiza¸c˜ao n˜ao ´e t˜ao robusto e poderoso como o do Oracle ou Postgre, por´em ele tamb´em ´e utilizado em aplica¸c˜oes de grande porte, o que indica que, mesmo com essa limita¸c˜ao, o MySQL consegue atender bem a esse requisito.

Limite Valor

Tamanho m´aximo da base Ilimitado

Tamanho m´aximo de tabela Varia de acordo com o SO Tamanho m´aximo de tupla 65 KB

Tamanho m´aximo de campo 65 KB Limite de linhas por tabela Ilimitado Limite de colunas por tabela 4096

Limite de ´ındices por tabela 64

Tabela 4.2: Limites de armazenamento do MySQL

Como podemos perceber pela Tabela 4.2, o MySQL limita bastante fatores como tamanho m´aximo de tupla, por´em o MySQL possui um diferencial dos demais SGBDs:

(43)

Ele armazena Blob e Text de forma diferenciada. Ele utiliza um esquema de referˆencias, n˜ao armazenando o dado propriamente dito na tabela, de forma que cada campo desses possua apenas de 9 a 12 bytes de tamanho. Apesar de todas essas limita¸c˜oes, por conta deste esquema de referˆencia, isso torna o MySQL vi´avel quando estudamos o quarto ponto. Por fim, o MySQL ´e compat´ıvel com o CentOS e existe um drive espec´ıfico para utiliz´a-lo em conjunto com Java. Isso somado com o fato de haver experiˆencia pr´evia do time com esta ferramenta torna ele um forte candidato `a aceita¸c˜ao.

4.3.3

SQL Server

Dentre os candidatos, o SQL Server ´e um dos mais promissores e um dos melhores. Po-r´em ele foi logo descartado pois, al´em de apenas funcionar em Sistemas Operacionais da Microsoft, sua licen¸ca custa $931,00. Logo, por conta deste empecilho, o SQL Server foi descartado da an´alise.

4.3.4

Bancos de Dados NoSQL

Antes de seguir com os candidatos, ´e necess´ario elucidar um conceito chave para a com-preens˜ao dos bancos de dados que vˆem a seguir, e este conceito ´e o modelo de banco de dados NoSQL [NoSQL, 2016]. Os bancos de dados NoSQL (Not Only SQL), cujo pri-meiro banco foi criado no ano de 1998, s˜ao uma alternativa ao modelo relacional que ´e t˜ao fortemente difundido e utilizado nos dias atuais. Criados para oferecer uma solu¸c˜ao diferenciada dos bancos de dados relacionais, os bancos de dados NoSQL surgiram para suprir certas demandas que os bancos de dados relacionais n˜ao eram capazes de atender ou o fazem de forma ineficiente.

O funcionamento dos bancos NoSQL se baseia no fato de o mesmos n˜ao terem como foco apresentar as propriedades ACID (Atomicity, Consistency, Isolation and Durability), que s˜ao a base de todo Sistema de Gerenciamento de Banco de Dados. Com a quebra dessa obrigatoriedade feita pelos bancos NoSQL, tornou-se poss´ıvel criar bases de dados que conseguem ser distribu´ıdas e escal´aveis sem que haja perda significativa de desempe-nho, coisa que ´e evidente num SGBD relacional. Por conta do ACID, todo SGBD tem internamente uma s´erie de t´ecnicas que possibilitam que o mesmo seja capaz de garantir que estas propriedades sejam realmente aplicadas em todas as suas bases, e ´e esse o grande problema: Quando essa base ´e distribu´ıda, gerenciar todas essas propriedades atrav´es da

(44)

32 rede se torna um processo demasiadamente lento, al´em do que, conforme a base cresce, mais conex˜oes paralelas s˜ao criadas em todas as instˆancias do banco, dificultando ainda mais este processo.

Como os bancos de dados NoSQL optam por n˜ao garantir, mesmo que parcial-mente, as propriedades ACID, eles acabam por apresentar um melhor desempenho em um ambiente distribu´ıdo quando comparados com os bancos relacionais. Ao optar por n˜ao garantir alguma dessas propriedades, como o isolamento, elimina-se uma s´erie de res-tri¸c˜oes, por exemplo o fato de todas as instˆancias do banco serem obrigadas a possuir a vers˜ao mais atualizada do dado. Ao eliminar somente esse ponto, j´a ´e eliminado tamb´em, por consequˆencia, a necessidade de ter uma comunica¸c˜ao constante entre as partes do banco, sendo poss´ıvel atender diretamente a requisi¸c˜ao do usu´ario no momento que ela ´e feita, sem necessidade de conferir se o dado que est´a sendo consultado ´e o mais atual ou bloquear o dado em todas as instˆancias quando um usu´ario vai modific´a-lo, pois bloque´ a-lo apenas na instˆancia atual seria o suficiente para eliminar qualquer tipo de incoerˆencia, o que mant´em as outras instˆancias capazes de atender a solicita¸c˜oes sobre aquele mesmo dado.

Por fim, a maioria dos bancos NoSQL armazena seus dados no formato chave-valor, o que possibilita um acesso direto ao dado que se deseja buscar. Por´em, diferentemente dos bancos de dados relacionais, realizar opera¸c˜oes de jun¸c˜ao nos NoSQL ´e um processo muito mais custoso e demorado, de forma que esse tipo de banco de dados ´e altamente recomendado para armazenamento de informa¸c˜oes que n˜ao possuam nenhum tipo de co-nex˜ao entre si.

Para a avalia¸c˜ao deste modelo de banco, foram escolhidos 2(dois) bancos de dados que possuem o princ´ıpio NoSQL: O MongoDB, que ´e totalmente NoSQL, e o Cockroach, que mistura um banco de dados relacional com armazenamento no formato chave-valor. Ambos ter˜ao seu funcionamento explicado com mais detalhamento a seguir.

4.3.5

MongoDB

O MongoDB ´e um banco de dados NoSQL, lan¸cado em 2009 e seu nome ´e derivado da palavra humongous (gigantesco) [MongoDB, Inc., 2016]. Seu funcionamento ´e orientado a documentos, o que significa que cada documento ´e autocontido e auto descritivo, ou seja, cada documento, por si s´o, faz sentido e ´e independente de qualquer outro documento

(45)

que o Mongo armazene em seu interior. A consequˆencia da orienta¸c˜ao a documentos ´e a possibilidade de existir redundˆancia e at´e mesmo inconsistˆencia. Como cada documento ´e independente dos demais, n˜ao existe nenhum mecanismo de valida¸c˜ao que impe¸ca que sejam criados dois documentos que armazenem a mesma informa¸c˜ao ou que um mesmo documento possua duplicatas de um determinado dado espec´ıfico, o que s´o seria des-coberto em tempo de execu¸c˜ao. Al´em disso, tamb´em n˜ao existe valida¸c˜ao para dados inconsistentes. Como o Mongo utiliza JSON como forma de armazenar dados dentro dos seus documentos, nada impede que um mesmo dado possua informa¸c˜oes conflitantes, uma vez que a ´unica coisa validada no momento da cria¸c˜ao de um JSON ´e a n˜ao existˆencia de duas chaves com mesmo valor. Em outras palavras, podemos ter dois objetos JSON que possuem algum tipo de rela¸c˜ao e ambos apresentam informa¸c˜oes que contradizem as informa¸c˜oes contidas na sua contraparte. Apesar dessas perdas significativas, isso acar-reta em ganhos ainda mais significativos pois, como a linguagem de escrita ´e simples e a forma de armazenamento dos documentos ´e bem definida, h´a um ganho muito elevado em flexibilidade e em performance.

Ao analisarmos a forma de funcionamento do Mongo, percebemos que ele atende ao segundo ponto, pois como sua forma de armazenamento ´e simples, ele consegue facilmente executar buscas de dados de qualquer um dos seus documentos de forma r´apida e com custo de processamento muito baixo.

Como o Mongo ´e um banco que busca maximizar a performance e ele funciona atrav´es de escala horizontal, ele divide o seu dataset dentre os clusters dispon´ıveis e, caso sua demanda seja maior que a capacidade, ele ´e capaz de levantar clusters auxiliares para atender a essa demanda. Al´em disso, por ser completamente focado em eleva¸c˜ao de performance, ele atende ao terceiro e quarto pontos com satisfa¸c˜ao.

No quinto crit´erio ele n˜ao deixa a desejar, pois, apesar de sua configura¸c˜ao e insta-la¸c˜ao serem complexas por necessitarem a cria¸c˜ao de um cluster inicial no qual o Mongo rodar´a, ele possui uma vers˜ao que atende ao CentOS e um drive espec´ıfico pra Java, al´em de possuir uma documenta¸c˜ao bem descritiva sobre como configur´a-lo e utiliz´a-lo.

Apesar de nenhum dos membros ter tido contato com esta tecnologia anterior-mente, o ponto que mais influenciou negativamente foi o fato de o Mongo permitir redun-dˆancia ou inconsistˆencias. Por trabalharmos com dados hist´oricos da faculdade, dados que s˜ao sens´ıveis e que n˜ao podem, em hip´otese alguma, ser perdidos, ter um banco de dados

(46)

34 que permite que dados redundantes sejam inseridos na base acarretaria numa valida¸c˜ao exaustiva a n´ıvel de c´odigo, o que provavelmente reduziria todo o ganho de performance que o mongo pode vir a oferecer. Como existe muita rela¸c˜ao entre os dados armazenados no sistema, acabar´ıamos com documentos contendo JSONs volumosos que acarretariam numa recupera¸c˜ao de grande parte da base para cada consulta executada, o que, por sua vez, teria um impacto ainda mais negativo na performance ganha pelo Mongo.

4.3.6

CockroachDB

O ´ultimo dos candidatos escolhidos foi o CockroachDB [Cockroach, 2016]. O Cockroa-chDB ´e um banco que promete unir o melhor dos dois mundos: Manter o banco estru-turado de uma forma relacional, permitindo que toda a estrutura seja feita em forma de tabela, por´em internamente, ele armazena seus dados no formato chave-valor, visando utilizar este formato para aumentar a escalabilidade do banco.

SQL Tradicional NoSQL CockroachDB Escal´avel N˜ao Sim Sim Consistente Sim N˜ao Sim Alta disponibilidade N˜ao Sim Sim Propriedades ACID Sim N˜ao Sim

SQL Sim N˜ao Sim

Tabela 4.3: Compara¸c˜ao do CockroachDB com outros SGBDs

O Cockroach foi desenvolvido de forma que sua escalabilidade fosse horizontal, utilizando o conceito de cria¸c˜ao de n´os sob demanda no cluster no qual ele roda. Al´em disso, o Cockroach mapeia seus dados da seguinte forma: inicialmente, o Cockroach inicia sua execu¸c˜ao com um ´unico intervalo de armazenamento vazio. Conforme as informa¸c˜oes s˜ao inseridas, esse intervalo aumenta at´e que o limite ´e atingido, que por padr˜ao ´e de 64 MB. Quando esse limite ´e atingido, os dados s˜ao divididos em dois intervalos que cobrem, cada um, um segmento cont´ınuo do espa¸co de valor chave. A partir deste processo, conforme novos dados v˜ao sendo inseridos, todo o processo se repete e os intervalos v˜ao se dividindo, fazendo com que o banco sempre lide com intervalos pequenos e bem definidos. Al´em disso, quando h´a a cria¸c˜ao ou remo¸c˜ao de um n´o do cluster, todos os intervalos s˜ao redistribu´ıdos

Referências

Documentos relacionados

5 “A Teoria Pura do Direito é uma teoria do Direito positivo – do Direito positivo em geral, não de uma ordem jurídica especial” (KELSEN, Teoria pura do direito, p..

Chora Peito Chora Joao Bosco e Vinicius 000 / 001.. Chão De Giz Camila e

Podem treinar tropas (fornecidas pelo cliente) ou levá-las para combate. Geralmente, organizam-se de forma ad-hoc, que respondem a solicitações de Estados; 2)

É primeiramente no plano clínico que a noção de inconscien- te começa a se impor, antes que as dificuldades conceituais envolvi- das na sua formulação comecem a ser

Este trabalho buscou, através de pesquisa de campo, estudar o efeito de diferentes alternativas de adubações de cobertura, quanto ao tipo de adubo e época de

O valor da reputação dos pseudônimos é igual a 0,8 devido aos fal- sos positivos do mecanismo auxiliar, que acabam por fazer com que a reputação mesmo dos usuários que enviam

São por demais conhecidas as dificuldades de se incorporar a Amazônia à dinâmica de desenvolvimento nacional, ora por culpa do modelo estabelecido, ora pela falta de tecnologia ou

Considerando que o MeHg é um poluente ambiental altamente neurotóxico, tanto para animais quanto para seres humanos, e que a disfunção mitocondrial é um