e-Chamada · 2018. 3. 14. · uso do NFC da Carteirinha da UFF. Desenvolvido utilizando a linguagem...

Universidade Federal Fluminense

Instituto de Computacao

Departamento de Ciencia da Computacao

e-Chamada

O desenvolvimento e implantacao de um sistema para o controle

de frequencia universitaria

Bruno Braga Guedes Cardoso

Leonardo Fernandes Lopes

Niteroi - RJ

2017

ii

BRUNO BRAGA GUEDES CARDOSO E LEONARDO FERNANDES LOPES

e-Chamada

O desenvolvimento e implantacao de um sistema para o controle de frequencia

universitaria

Trabalho submetido ao Curso de

Bacharelado em Ciencia da Computacao

na Universidade Federal Fluminense como

requisito parcial para a obtencao do tıtulo

de Bacharel em Ciencia da Computacao.

Orientador: Prof. Eugene F. Vinod Rebello

Niteroi - RJ

2017

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

v

“A alegria esta na luta, na tentativa, no so-

frimento envolvido e nao na vitoria propria-

mente dita”. (Mahatma Gandhi)

vi

Agradecimentos

Agradecemos primeiramente a Deus, pelo dom da vida e pela oportunidade de

cursarmos uma faculdade no nıvel de excelencia da UFF.

Agradecemos aos nossos pais, pelos ensinamentos transmitidos, pelas licoes apren-

didas e principalmente pelo estımulo e apoio na conclusao de mais uma etapa da nossa

jornada. Agradecemos a eles pela preocupacao em relacao ao estudo, bem como a insis-

tencia e a cobranca contınua, pois isso so fez de nos 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 preocupacao, determinacao e resiliencia em suas aulas, tornando-as cada

vez melhores, mais didaticas e estimulando cada vez mais o aprendizado dos alunos. Nos

vemos os seus esforcos e agradecemos imensamente por isso.

Agradecemos tambem 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 busca-la com afinco. Ele nos

ensinou a nunca desistir e a sempre buscar nao apenas a forma correta, mas a melhor

forma de resolver qualquer problema. A voce, nossa sincera gratidao, Vinod.

Agradecemos aos professores Alexandre Plastino de Carvalho e Aline de Paula

Nascimento, por aceitarem nosso convite. Esperamos que este trabalho mostre a voces o

quanto aprendemos e o quao valiosas foram suas licoes para nos.

Por fim, estendemos nossos agradecimentos a todos os que, de alguma forma, nos

auxiliaram para que pudessemos estar aqui hoje. A todos voces, muito obrigado!

vii

Resumo

“Algo so e impossıvel ate que alguem duvide e acabe provando o contrario”

Albert Einstein.

Este trabalho tem como objetivo desenvolver um sistema digital que permita ao professor

substituir o processo atual de registrar a presenca de aluno na sala de aula por um processo

que consuma menos tempo e seja menos intrometido, uma vez que, atualmente, a presenca

e controlada manualmente e, ao final do perıodo, e necessario que o professor realize o

calculo da frequencia de cada aluno para so entao registra-la no sistema academico.

O sistema proposto neste trabalho pretende facilitar o cumprimento do Regula-

mento dos Cursos de Graduacao da UFF e permite a alocacao de professores e a inscricao

de alunos em turmas bem como o registro de aulas por professores e a presenca dos alunos

e o calculo de frequencia durante o semestre, alem de outras funcionalidades incluindo o

uso do NFC da Carteirinha da UFF. Desenvolvido utilizando a linguagem Java, o sistema

possui duas aplicacoes mobile desenvolvidas para Android e um servidor Linux, onde esta

implementado um banco de dados e uma aplicacao web que permite que os dispositivos

moveis interajam com o banco. Alem disso, este sistema possui um site, tambem integrado

a essa aplicacao web, que permite acesso as diferentes informacoes por quatro atores: o

aluno, o professor, a coordenacao do curso e o departamento. Serao apresentadas aqui a

arquitetura do sistema, as tecnologias adotadas e a implementacao da versao do sistema

que foi testado durante o semestre 2-2016.

Palavras-chave: Diario de classe, Sistema de controle academico, Servico web, Aplicativo

mobile Android, NFC.

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.

Sumario

Resumo vii

Abstract viii

Lista de Figuras xii

1 Introducao 1

1.1 Descricao do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Motivacao e Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Organizacao da monografia . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Trabalhos Relacionados 6

2.1 e-Chamada: uma abordagem digital para o controle de frequencia escolar . 6

2.2 Riocard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Google Classroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Resumo do capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Visao do Sistema 10

3.1 Atores envolvidos no sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Departamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Coordenacao de Curso . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.3 Professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.4 Aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Fluxo de execucao dos processos do sistema . . . . . . . . . . . . . . . . . 22


ix

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.4 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


4.5 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


5 Arquitetura do Sistema 39

5.1 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Aplicacao 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

xi

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 Organizacao do Codigo . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3.3 Manifesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.4 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Aplicativo da Coordenacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4.1 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.5 Resumo do Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6 Implantacao 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 Aplicacao Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.2.1 Servidor de Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . 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 Moveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7 Conclusao 61

7.1 Dificuldades Encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.3 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Siglas 67

Referencias bibliograficas 67

xii

Lista de Figuras

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

3.2 Exemplo da tela de criacao de um professor . . . . . . . . . . . . . . . . . 11

3.3 Exemplo da tela de criacao de uma turma . . . . . . . . . . . . . . . . . . 12

3.4 Exemplo de tela de listagem de alunos de uma coordenacao no app mobile 13

3.5 Exemplo de tela de edicao de aluno de uma coordenacao no app mobile . . 14

3.6 Exemplo da tela inicial da Coordenacao . . . . . . . . . . . . . . . . . . . . 15

3.7 Exemplo da tela de insercao de aluno da Coordenacao . . . . . . . . . . . . 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 criacao de aula (1) . . . . . . . . . . . . . . . . . . . . 20

3.13 Exemplo de tela de criacao 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 aplicacao Web . . . . . . . . . . . . . . . . . . . . 55

5.4 Diagrama do Banco de Dados do Aplicativo . . . . . . . . . . . . . . . . . 56

Capıtulo 1

Introducao

A educacao e a materia-prima do conhecimento e, por meio dela, podemos nos desenvolver

cultural, economica e socialmente. Porem este direito fundamental muitas vezes encontra

obstaculos para ser alcancado. Estes obstaculos, contudo, frequentemente podem ser

suavizados a partir de iniciativas simples e acessıveis que podemos tomar para o bem

coletivo. Com o recente avanco tecnologico, 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 educacao

atraves do desenvolvimento ou utilizacao de novas tecnologias acessıveis e praticas.

Um dos principais obstaculos da educacao no Brasil e a evasao 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 fenomeno.

Para ajudar combater este problema, propomos o sistema e-Chamada para um

controle mais efetivo da frequencia escolar. A partir deste controle, e possıvel analisar o

fenomeno da evasao escolar, melhorar o diagnostico deste, identificar causas e, a partir

disto, propor solucoes para este desafio.

1.1 Descricao do problema

Atualmente o controle da frequencia escolar, quando este existe, e manualmente feito em

diarios de papel pelos proprios professores, que fazem anotacoes durante todo o perıodo

1

2

letivo e ao final deste, devem calcular para cada aluno se sua frequencia foi suficiente ou

nao para aprovacao.

Alem do consumo de tempo dos professores e dos alunos na elaboracao dos diarios

e durante o processo de chamada, e muito difıcil obter informacoes mais relevantes neste

procedimento.

Dado o embaraco que os diarios de classe podem introduzir no processo educativo,

especialmente em turmas com grande numero de alunos, em muitos casos, este controle

de frequencia escolar simplesmente nao e feito, o que impossibilita por completo a identi-

ficacao e o combate a Evasao Escolar em tempo habil, pois muitas vezes, este problema

so e detectado no final do perıodo letivo vigente.

1.2 Motivacao e Objetivo

O objetivo do sistema e-Chamada proposto neste trabalho, e fornecer uma alternativa

tecnologica, pratica, acessıvel e confiavel aos ineficientes diarios de classe feitos manual-

mente em papel. Agora, sera possıvel que os professores realizem suas chamadas atraves

de um sistema digital em dispositivos moveis.

Alem disso, o e-Chamada tambem visa permitir que a instituicao de ensino acom-

panhe todo o processo de controle de frequencia escolar feito pelo professor, garantir

que os diarios de classes estao sendo feitos corretamente, permitir um diagnostico dos

problemas de evasao em tempo agil, e facilitar cumprir a regulamentacao, como por

exemplo, requirido pelo Regimento dos Cursos de Graduacao da Universidade Federal

Fluminense [Lobo, 2015].

Com a adocao e avancos de novas tecnologias, se faz necessaria a discussao de

certos pontos do regulamento da UFF. O primeiro artigo relevante e o Artigo 96, que diz:

Art. 96 – “A aprovacao direta do discente ocorrera quando o mesmo obtiver

media parcial igual ou maior que 6,0 (seis) e sua frequencia igual ou maior a

75% (setenta e cinco porcento) da carga horaria da disciplina.”

Este artigo define a regra mais basica que rege a vida escolar de um aluno e a

importancia do registro de presenca na sala de aula: O mesmo deve possuir frequencia

maior ou igual a 75% da carga horaria da disciplina e media maior ou igual a 6,0 para ser

considerado aprovado na mesma. Porem, no Artigo 97, 101 e 102, temos requerimentos

3

adicionais que comprova a necessidade de implantar um processo robusto e confiavel de

verificacao da presenca:

Art. 97, Paragrafo unico – “O discente so podera ter consignada sua pre-

senca e ser submetido a verificacao de aprendizagem em turma em que esteja

regularmente inscrito, como comprovado pelo seu registro no diario de classe.”

Art. 101 Paragrafo unico – “A partir do momento em que o discente ultrapas-

sar o limite de faltas (superior a 25% da carga horaria total) numa disciplina,

perdera o direito de realizar as avaliacoes posteriores.”

Art. 102 - A Insuficiencia de Aproveitamento Escolar, para efeito de cancela-

mento de matrıcula previsto no item (e) do Art. 60 deste Regulamento, sera

caracterizada quando o discente: a)... d) For reprovado por frequencia em

todas as disciplinas nas quais se inscreveu no perıodo de seu ingresso;

A princıpio, Artigo 97 nao e muito relevante ao projeto em questao. Porem, ao

realizarmos uma analise 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 apos o inıcio do

perıodo letivo. Inicialmente, o impacto desta mudanca nao deveria ser assim tao grande,

porem o sistema academico utilizado atualmente na UFF realiza a atualizacao da listagem

de alunos inscritos em uma determinada disciplina apenas 1 (uma) vez por mes, fazendo

com que os alunos que sejam inscritos apenas no mes seguinte tenham perdido 8 aulas,

o equivalente a 16 horas. Para uma disciplina de 64 horas, isto equivale a 25% da carga

horaria. Como o Artigo 101 deixa claro que um aluno so podera realizar avaliacoes se

nao tiver ausencia maior que 25% da carga horaria total da disciplina, os alunos que sao

inseridos na turma apos o primeiro mes de aula deveriam ser, automaticamente, impos-

sibilitados de realizar as provas e, como consequencia, reprovados na disciplina, alem do

fato de serem reprovados serem reprovados por falta, de acordo com o Artigo 96.

No caso dos alunos ingressantes oriundos de chamadas realizadas apos o inıcio do

perıodo letivo, o artigo 102 diz, em seu item d, que o aluno ingressante que for reprovado

por frequencia 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,

4

este aluno ingressante deveria ser, automaticamente, reprovado por falta em todas as

disciplinas nas quais foi inscrito e, como consequencia, ter sua matrıcula cancelada.

Ao analisarmos o documento, percebemos que o regulamento nao evoluiu e absor-

veu as mudancas implementadas pela automatizacao do processo de controle de inscricao

de disciplinas oferecida pelo IdUFF. Porem, ao estudarmos a forma como todo o processo

funciona, percebemos que existem certas adaptacoes e excecoes feitas pelas coordenacoes

para que esses casos listados nao sejam prejudicados. Para tentar criar um sistema que

mais se aproximasse do que e utilizado hoje, o e-Chamada tambem foi criado tomando

como base estas mesmas adaptacoes. Um exemplo disso e a forma como a frequencia de

um aluno funciona: No e-Chamada, um aluno so tem sua presenca computada durante

o perıodo que o mesmo esta inscrito da disciplina, e o calculo da frequencia 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 esta inscrito por dois meses em uma disciplina tera

sua presenca calculada utilizando apenas estes dois meses como base.

Alem disso, como o sistema propoe a automatizacao do processo de presenca, todas

as alteracoes feitas em relacao as inscricoes dos alunos nas disciplinas sao 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 propoe o aproveitamento de um dado que, hoje em dia, e

impossıvel de ser analisado: A frequencia dos alunos. Ao armazenar todas as presencas

de todos os alunos em todas as disciplinas, e possıvel se realizar diversas analises, como

por exemplo o quao impactante uma determinada aula pode ser no resultado final de uma

turma, ou se todos os alunos que assistiram as aulas de um determinado topico acertaram

as questoes referentes aquele topico na prova. Com estas informacoes, os professores serao

capazes de coletar dados sobre o rendimento da sua turma de forma muito mais eficiente

e rapida, munindo-os da capacidade de reagir a problemas de forma mais eficiente.

1.3 Organizacao da monografia

Os proximos 6(seis) capıtulos desta monografia possuem os seguintes objetivos:

• Capıtulo 2 - Trabalhos Relacionados: Ilustra os trabalhos que possuem relacao com

este projeto.

5

• Capıtulo 3 - Visao do Sistema: Apresenta uma visao do sistema desenvolvido, bem

como os atores envolvidos e suas responsabilidades.

• Capıtulo 4 - Tecnologias Relevantes: Cita as tecnologias que sao relevantes a este

projeto

• Capıtulo 5 - Arquitetura do Sistema: Ilustra como o sistema esta definido arquite-

turalmente.

• Capıtulo 6 - Implantacao do sistema: Define os requisitos necessarios para a utili-

zacao deste sistema.

• Capıtulo 7 - Conclusao: Apresenta a conclusao e trabalhos futuros.

Capıtulo 2

Trabalhos Relacionados

Este capıtulo apresentara alguns projetos que possuem algum tipo de relacao com o e-

Chamada, seja esta tecnologica ou ideologica. Foram selecionados 2 (dois) projetos que

serao elucidados nas duas proximas secoes. Na quarta secao, sera apresentado um resumo

do capıtulo.

2.1 e-Chamada: uma abordagem digital para o con-

trole de frequencia escolar

O sistema proposto neste trabalho foi desenvolvido a partir da analise feita no trabalho de

conclusao de curso de Ciencia da Computacao da Universidade Federal Fluminense feito

pela aluna Beatriz Barroso [Tavares Ferreira, 2016], onde, alem da analise do problema

foi feito a especificacao do sistema e implementacao de um prototipo.

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 eletronico de

passagens de transportes coletivos. Basicamente, o sistema funciona da seguinte forma:

O usuario se cadastra no site e recebe um cartao. A partir deste momento, o mesmo efetua

recargas no cartao e passa a pagar suas passagens utilizando o cartao, encostando-o no

leitor de Riocard.

Antes de explicar a fundo o funcionamento deste sistema, primeiro e necessaria

6

7

a elucidacao do conceito de NFC. NFC (Near Field Communication) e uma tecnologia

que permite troca de informacoes sem a utilizacao de fios, sendo necessaria apenas a

aproximacao fısica. Esta troca de informacoes necessita de dois componentes para ser

realizada. O primeiro destes chama-se tag NFC, que armazena as informacoes. O segundo

dispositivo que e utilizado no processo e chamado de leitor de tag NFC, e e responsavel

por ler os dados da tag ou sobrescrever os dados da mesma. Alem disso, o leitor tambem

e responsavel pela comunicacao com o servidor da aplicacao.

O sistema de funcionamento do Riocard baseia-se em autenticacao criptografica.

Basicamente, cada cartao possui uma tag NFC onde sao escritos o codigo identificador do

usuario e duas chaves exclusivas daquele cartao, que serao utilizadas no processo de auten-

ticacao. Para que a seguranca deste metodo de autenticacao seja garantida, e necessario

que a chave nunca saia do proprio cartao, por isso e embutido tambem um microproces-

sador que executara todos os processamentos criptograficos necessarios.

Basicamente o processo de criptografia funciona da seguinte forma: Quando o

cartao e encostado no leitor, o leitor define para o cartao qual das duas chaves o mesmo

deve usar. Entao o cartao seleciona um numero aleatorio e o envia ao leitor, como uma

forma de provar a identidade do mesmo. O leitor recebera o numero e o encriptara

com a chave escolhida e o enviara para o cartao juntamente com outro numero, tambem

sorteado aleatoriamente, para que o cartao tambem comprove sua autenticidade. Ao

receber o numero, o cartao o descriptografa e testa sua validade. Ao atestar a veracidade

do valor, o cartao criptografara o numero com sua propria chave e o enviara ao leitor,

que o descriptografara e validara se o numero recebido e o mesmo do enviado. Caso este

processo se complete com sucesso, a tarifa e debitada, o saldo e atualizado diretamente

no cartao e salvo no validador para posterior sincronizacao com o servidor e a roleta e

liberada.

Vale ressaltar que o saldo do usuario nao e armazenado apenas no cartao, esta

informacao tambem fica armazenada no servidor, de forma que, caso o cartao seja perdido

ou furtado, o usuario podera requisitar outro cartao 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 sao utilizadas para dar presenca aos alunos, de forma que este

trabalho serve como inspiracao e material de estudo sobre como melhorar nosso sistema

de comunicacao entre a tag e o dispositivo que efetuara a leitura da mesma.

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, alem 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 precisara, por conta propria, verificar quais alunos entregaram e

quais deixaram de entregar. Alem disso, sempre ocorrem problemas com o servidor de

email e com alunos que nao entregam o trabalho no prazo. Esta plataforma resolve estas

duas situacoes de uma forma bem pratica. A primeira situacao 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 sao salvos

neste repositorio. Isto automatiza o processo de organizacao de entrega de trabalhos, uma

vez que o Classroom ja faz isto por si so.

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. Alem disso,

ele notifica quando a entrega esta atrasada ou o trabalho nao foi entregue no prazo, de

forma que o aluno pode monitorar isto com mais tranquilidade. Alem disso, o professor

pode fechar a entrega de uma tarefa, de modo que, quando o prazo for atingido, o sistema

nao permitira mais o envio de nenhum arquivo. Isto garante que nao havera entregas apos

o prazo, uma vez que o proprio sistema bloqueara a tentativa de upload do aluno.

Apesar da tematica do Classroom nao ter relacao no topico 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 dinamica de sala de aula e automatiza-lo, de forma

que nao ha 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 correcao dos

mesmos. Este trabalho serve de inspiracao por mostrar que ate o mais simples processo

de automatizacao e capaz de fazer uma grande diferenca na vida dos envolvidos.

9

2.4 Resumo do capıtulo

Neste capıtulo foram apresentados um trabalho anterior que levantou uma discussao sobre

o problema e apresentou um prototipo e dois sistemas que possuem algo em comum com o

e-Chamada. O primeiro aplicativo utiliza tags NFC para realizar a autenticacao das pas-

sagens do seu usuario, 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 digitalizacao do ambiente ao qual o sistema e

proposto gera um conforto e comodidade maiores aos seus usuarios, ja que em ambos os

casos, os usuarios reduzem a complexidade do processo ao qual estao imersos quando este

tem algum dos seus passos automatizados. No caso do Riocard, elimina-se a interacao

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 discussoes sobre a disciplina e automatizar a organizacao de entrega de trabalhos,

visando agilizar este processo.

O proximo capıtulo apresentara uma visao do sistema desenvolvido durante este

projeto, apresentando seus atores e seus respectivos papeis quando interagem com o e-

Chamada.

Capıtulo 3

Visao do Sistema

O capıtulo anterior apresentou sistemas que tem algum tipo de relacao e tentam fazer

algo parecido em relacao a proposta. Este capıtulo tem como objetivo elucidar todos os

atores envolvidos no sistema bem como seus respectivos papeis no mesmo. Alem disso,

este capıtulo mapeara todo o processo ao qual os usuarios do sistema sao submetidos,

desde a criacao de uma turma a criacao de uma aula e preenchimento da presenca dos

alunos.

3.1 Atores envolvidos no sistema

Nesta versao do projeto, existem 4 (quatro) atores principais que interagem diretamente

com o sistema e sao eles: Departamento, Coordenacao, Professor e Aluno. Cada um desses

atores possui suas funcionalidades, permissoes e capacidades dentro do e-Chamada.

Essa secao descrevera, para cada ator, qual a sua responsabilidade dentro do sis-

tema, bem como suas capacidade e obrigacoes dentro do mesmo. Porem, dentre os quatro

atores, alguns compartilham certas permissoes ou possuem certas funcionalidades em co-

mum que serao elucidadas ao final do capıtulo.

3.1.1 Departamento

O primeiro ator do sistema e o departamento. Basicamente, o departamento e responsavel

por cadastrar os professores e as turmas do sistema, assim como sua criacao, remocao e

alocacao de professores em turmas. O departamento utiliza apenas o sistema web para

desempenhar suas tarefas, atraves de interacoes que serao explicadas a seguir.

10

11

Figura 3.1: Exemplo da tela inicial de um departamento

Atraves 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 criacao de um professor

A primeira funcionalidade a ser explorada sera a criacao de professores. Atraves da

tela inicial, o departamento utilizara o botao ”Adicionar Novo Professor”que redirecionara

para a tela representada pela Figura 3.2. A partir desta tela, o departamento preenchera

os dados do professor que deseja cadastrar e clicara no botao de salvar para que suas

12

alteracoes sejam inseridas no sistema. Vale lembrar que, na edicao 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 criacao de uma turma

A segunda responsabilidade do departamento e a criacao de uma turma. O sistema

mapeia essa responsabilidade atraves da interface representada na Figura 3.3. Nesta tela,

o departamento podera criar as turmas que serao ministradas no perıodo vigente. O

usuario preenchera o formulario com os dados necessarios, como Disciplina, numero da

turma, professor vinculado e dia/hora da aula. Ao finalizar o preenchimento do formulario,

o usuario salvara e o sistema criara a nova turma no sistema. Apos a criacao, todas

as turmas podem ser editadas. O procedimento e o mesmo da criacao, apenas sendo

diferenciado no inıcio, quando o usuario escolhera a turma que sera editada na tela inicial.

3.1.2 Coordenacao de Curso

O segundo ator que tem participacao em parte do processo mapeado pelo e-Chamada e

a Coordenacao do Curso. Basicamente, esse ator tem como responsabilidade o cadastro

de novos alunos e suas respectivas inscricoes 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 proprio SISU, a Coordenacao

deve ser capaz de matricular e inscrever alunos a qualquer momento do perıodo. Alem

disso, com a existencia do perıodo de ajuste, este ator deve ser capaz de inscrever e

13

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

A atuacao da coordenacao se da atraves de 2(dois) sistemas. O primeiro sistema

e a propria aplicacao web, atraves de um usuario especial que lhe concede permissoes

unicas. O segundo sistema e uma aplicacao mobile, que permite ao ator realizar algumas

das tarefas que ele tambem pode realizar na aplicacao web, porem com um pequeno

acrescimo que sera elucidado a seguir.

3.1.2.1 Aplicativo Mobile

O primeiro intermediario pelo qual este ator interage com sistema e o aplicativo Mobile da

Coordenacao. Dentro desse sistema, ele podera editar os dados dos alunos cadastrados.

Mas, alem disso, o aplicativo Mobile permite vincular ao usuario do aluno o codigo da

sua carteirinha usando o leitor NFC do dispositivo.

Figura 3.4: Exemplo de tela de listagem de alunos de uma coordenacao no app mobile

14

Figura 3.5: Exemplo de tela de edicao de aluno de uma coordenacao no app mobile

A partir da lista de alunos, exibida na Figura 3.4, a Coordenacao e capaz de sele-

cionar um aluno e editar suas informacoes. Ao selecionar um aluno, a tela, representada

na Figura 3.5 sera exibida e o ator podera editar todos os dados do aluno. Alem disso,

ele podera aproximar a carteirinha do celular e, se o mesmo possuir leitor de tag NFC,

automaticamente o codigo daquele cartao sera vinculado aquele aluno, como sua carteiri-

nha oficial cadastrada no sistema. Como a carteirinha e pessoal e intransferıvel, a edicao

de alunos atraves 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 Coordenacao e o aplicativo web, e e

atraves dela que este usuario realizara a maior parte das suas interacoes com o sistema.

Apos a autenticacao no sistema, sera exibida a tela de listagem de alunos, exemplificada

pela Figura 3.6.

15

Figura 3.6: Exemplo da tela inicial da Coordenacao

Figura 3.7: Exemplo da tela de insercao de aluno da Coordenacao

Atraves desta tela, a coordenacao pode optar por criar um aluno. Ao selecionar

para efetuar a criacao, uma tela, representada pela Figura 3.7 e exibida. A partir daı, o

usuario preenchera com os dados do aluno e o sistema efetuara o salvamento dos mesmos.

Para a edicao de alunos, o processo e o mesmo, exceto no primeiro passo, onde a Coor-

denacao selecionara o aluno a ser editado na tela inicial. Alem disso, durante a edicao,

e possıvel inscrever e desinscrever (cancelar inscricao) 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,

16

permite que a coordenacao realize o cadastro de alunos no sistema em forma de pacote,

permitindo que o usuario cadastre multiplos 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 questao de presencas de aluno e criacao de aulas das turmas nas quais

ele leciona. O professor interage com o e-Chamada atraves de 2(dois) sistemas: O sistema

Web e o aplicativo Mobile de presenca, que serao explicados nas duas subsecoes 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 presenca que e utilizada normalmente em

todas as aulas.

Atraves desta aplicacao, o professor podera, durante suas aulas, efetuar sua cha-

mada sem a necessidade de utilizar folhas de papel, apenas com o apertar de um botao.

Como podemos ver pela Figura 3.8, o professor pode, apos realizar uma autenti-

cacao no sistema, selecionar uma disciplina e clicar no botao ”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 movel do

professor nao contenha leitor de tag NFC, o aplicativo continuara funcionando, apenas

desabilitando a funcionalidade de leitura da carteirinha, aceitando apenas a entrada de

presenca manual, atraves do checkbox, exibido na lista de alunos. Atraves da Figura 3.9b,

podemos ver que, ao iniciar um aula, o professor tem a sua disposicao uma tela que o diz

a turma a qual aquela lista de presenca esta vinculada, alem da data e hora da criacao

da mesma. Alem disso, o professor tambem tem a sua disposicao um campo de assunto,

o qual pode ser preenchido com os topicos principais dados naquela aula. Por fim, abaixo

do cabecalho, temos a lista de alunos inscritos na disciplina no momento em que a aula

foi aberta. Associado ao nome de cada aluno, ha um checkbox que e responsavel pela

presenca daquele aluno. O professor pode marca-lo manualmente ou atraves da carteirinha

do aluno, encostando-a no celular com o leitor de NFC ativo. Quando o professor marca

a presenca do aluno atraves da carteirinha, o campo de checkbox e desativado, para que

a presenca nao possa ser desmarcada manualmente. Caso contrario, o campo continua

17

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

mobile

ativado ate que o professor feche a lista de presenca. Todos os usuarios que possuem

carteirinha cadastrada no sistema sao simbolizados pelo ıcone de um cartao ao lado do

proprio nome, como tambem e possıvel observar na Figura 3.9b.

3.1.3.2 Aplicacao Web

Para a interface web, as opcoes sao mais diversificadas do que as do dispositivo movel,

que permite apenas a criacao de uma lista de presenca.

Na tela inicial, apos 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. Atraves da aba superior, o professor podera navegar dentre os semestres nos quais

ja ministrou alguma disciplina para realizar operacoes em alguma determinada turma.

Apos selecionar uma disciplina na tela inicial, o professor recebera como resposta

uma tela contendo os detalhes daquela turma, como aulas ministradas, alunos inscritos,

18

(a) tela inicial (b) visualizacao de menu

Figura 3.9: telas do aplicativo

dias e horarios nos quais aquelas aulas foram ministradas, como e possıvel ver na Figura

3.11. Atraves dessa tela, o professor pode realizar uma serie de interacoes com o sistema,

e a primeira delas e a criacao de uma nova aula.

Ao clicar no botao ”Adicionar uma nova aula” o professor recebera como resposta

uma caixa textual onde o mesmo devera inserir a data na qual a aula daquela disciplina

foi ministrada, como e possıvel ver na Figura 3.12. Apos 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 basicos da aula, como turma e disciplina associada, mas tambem disponibiliza

um campo de assunto, para que o professor possa introduzir os topicos principais que

foram ministrados naquela aula. Alem disso, por padrao, a nova aula e criada dando

presenca para todos os alunos inscritos na disciplina ate o momento da criacao. Para

remover a presenca de um aluno (dar falta ao mesmo) o professor deve ir ate a parte de

19

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 sera removido da lista de alunos presentes e adicionado a

lista de alunos ausentes.

A segunda funcionalidade disponıvel no sistema e a edicao de uma aula ministrada

anteriormente. O processo de edicao da aula e o mesmo de criacao, a unica diferenca 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 diario, 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 botao no canto superior esquerdo, ao lado da foto do

20

Figura 3.12: Exemplo de tela de criacao de aula (1)

Figura 3.13: Exemplo de tela de criacao de aula (2)

usuario. Atraves do diario extraıdo do IdUFF, o professor podera fazer upload do mesmo

no sistema e, automaticamente, os alunos novos inscritos serao matriculados assim como

os alunos removidos serao retirados da lista de inscritos. Vale ressaltar que remover um

aluno da disciplina nao significa remove-lo das listas de presenca que ja existem e nas

quais ele ja possui um status. Outro detalhe importante e que, caso um aluno nao esteja

cadastrado no sistema, esse recurso nao o cadastrara nem o matriculara na disciplina,

pois os dados advindos dessa planilha nao sao suficientes para a criacao do mesmo. Sera

necessario que a coordenacao efetue o cadastro deste indivıduo para, so entao, o mesmo

ser matriculado na turma.

21

3.1.4 Aluno

O ultimo e mais limitado dos atores envolvidos e o Aluno. Basicamente, o aluno so possui

permissao de consulta dos dados ja contidos no sistema das disciplinas nas quais ele esta

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 esta inscrito e, alem disso, atraves da barra superior, o aluno podera navegar dentre

todos perıodos ja cursados e conferir seu historico escolar de frequencia de forma rapida e

intuitiva. Alem de exibir as disciplinas divididas por perıodo, a tela inicial tambem oferece

uma previa 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 pagina contem mais informacoes acerca daquela turma,

como codigo da disciplina, perıodo no qual a mesma foi lecionada, numero da turma, os

dias e horarios nos quais as aulas eram realizadas e tambem, e possıvel consultar a presenca

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.

Alem disso, cada aula possui um indicador que notifica ao aluno se aquela presenca foi

dada manualmente pelo professor, ou pelo proprio aluno, atraves do sistema de validacao

de presenca via NFC.

Como foi possıvel observar, as permissoes do aluno sao apenas de consulta aos

22

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

dados, tornando-o o ator mais limitado em relacao ao sistema, ja que o mesmo nao produz

dados atraves de uma interacao direta com o mesmo, mas atraves de interacoes com a

aplicacao de frequencia no dispositivo movel do professor. E, por fim, apesar de o aluno

nao 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 nao tenha uma

influencia direta sobre a producao desses dados.

3.2 Fluxo de execucao dos processos do sistema

Nesta secao, sera elucidada a forma como todos os processos de cada usuario se encaixam

no sistema. Em outras palavras, sera feita a criacao de um fluxo de execucao que exibe a

ordem na qual as tarefas devem ser executadas no sistema.

O primeiro usuario a realizar suas tarefas no sistema e o Departamento. E ne-

cessario que o Departamento realize a criacao dos professores ingressantes no instituto e

definir as novas turmas que serao oferecidas no semestre. Apos garantir que as turmas

estao criadas e que os professores estao inseridos no sistema e devidamente alocados em

suas turmas, cabe apenas ao departamento fazer a manutencao do horario das aulas de

cada turma, mas este passo nao interfere no processo final, ja que esta tarefa nao impacta

diretamente em nenhuma tarefa de nenhum outro envolvido.

Quando as turmas estao criadas, o segundo passo pode ser realizado. A partir

daı, a Coordenacao pode iniciar a inscricao de alunos em suas respectivas turmas. Vale

23

ressaltar que o processo de criacao de alunos e independente do primeiro passo, ou seja,

a Coordenacao podera criar seus alunos no sistema sem precisar esperar ate que o Depar-

tamento faca a criacao das turmas, podendo apenas deixar a alocacao para ser executada

neste segundo passo.

A partir daı, os usuarios Professor e Aluno sao capazes de utilizar o sistema ao

longo de todo um perıodo letivo. O professor podera abrir as listas de presenca atraves do

seu aplicativo, ou cria-las atraves do site a qualquer momento. Ja o aluno podera consultar

suas presencas em cada aula, bem como os topicos dados e sua taxa de frequencia naquela

turma ate o momento.


Neste capıtulo foram definidos os atores que interagem diretamente com o e-Chamada

bem como suas respectivas permissoes e acoes no sistema, alem de apresentar uma des-

cricao detalhada do processo envolvido em cada acao individualmente, como resposta do

sistema apos a realizacao de cada acao e imagens ilustrando como essa resposta deveria se

apresentar. Na secao 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 acoes de forma

que o processo seja executado sem apresentar problemas a nenhum dos envolvidos, nem

ao proprio ator e nem aos atores cujas tarefas dependem do sucesso da tarefa realizada

pelo mesmo.

O proximo capıtulo tratara das tecnologias relevantes utilizadas na implementacao

do projeto, alem de apresentar uma discussao sobre as candidatas que foram analisadas

em conjunto com aquela tecnologia e o porque desta ter sido a escolhida.

Capıtulo 4

Tecnologias Relevantes

No capıtulo anterior, foi apresentada a visao sobre todo o sistema que foi desen-

volvido durante este projeto, assim como os atores envolvidos, suas respectivas responsa-

bilidades e as interfaces nas quais eles interagirao para executar suas atividades. Alem

disso, foi apresentado um fluxo de atividades que mapeia a ordem nas quais as atividades

devem ser executadas dentro do sistema.

Neste capıtulo, serao abordadas todas as tecnologias utilizadas no projeto, exibindo

todas as tecnologias que foram estudadas, explicando o seu funcionamento, e justificando

o porque de determinada tecnologia ter sido escolhida.

4.1 Linguagem

Nesta secao, serao apresentadas todas as linguagens candidatas para o desenvolvimento do

sistema, junto com uma breve descricao do seu funcionamento e, ao final, uma conclusao,

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 lancada em 1995

por Guido Van Roosum [Venners, 2003], baseada na linguagem ABC. Python foi escolhida

para avaliacao 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 rapida e facil, como por exemplo o framework para desenvolvimento web django.

Alem disso, esta e uma linguagem orientada a objetos, o que facilita bastante o processo

24

25

de desenvolvimento uma vez que a equipe ja esta habituada com este paradigma.

Porem, o que pesa negativamente e o desempenho desta linguagem, que quando

comparado a outras linguagens populares, como Java, apresentou um tempo de resposta

ate duas vezes maior em alguns testes, tornando-a pouco atrativa para o uso.

4.1.2 Go

Go e uma linguagem de programacao estruturada, open-source [gol, 2009] que torna facil

o desenvolvimento de aplicacoes simples, confiaveis e eficientes. Apresenta um excelente

desempenho ate 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 aplicacoes, combinando o desempenho de linguagens compiladas

tradicionais com a facilidade de escrita de linguagens de script.

Porem, o que pesou negativamente e o fato de ser uma linguagem com a qual

nenhum dos desenvolvedores tinham experiencia, e o tempo de aprendizado da nova lin-

guagem poderia atrapalhar o cronograma do sistema. Alem disto, nao e possıvel o de-

senvolvimento de aplicativos na plataforma Android na linguagem de programacao Go, o

que impossibilitaria a portabilidade de codigo 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 lancada em 1995 pela Sun Microsystems. E uma linguagem cujo codigo

e compilado para bytecode e este codigo e executado diretamente numa maquina virtual

propria da linguagem.

Java possui diversas caracterısticas: E uma linguagem relativamente facil de se

programar, porem e uma linguagem verbosa, isto e, por ser fortemente tipada, toda a sua

sintaxe e fortemente definida e, por consequencia, seus comandos se tornaram extensos.

Apesar disso, Java apresenta diversas tecnologias sobre as quais podem se desen-

volver paginas web, dentre elas as mais comuns sao JSP e JSF. Alem disso, Java possui o

conceito de Servlet, que sao servicos unicos que possibilitam ao servidor tratar requisicoes

HTTP vindas da Web, o que e perfeito para se utilizar em integracao com os aplicativos

Mobile.

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 requisicoes

ao banco de dados, ao Vaadim, que permite ao desenvolvedor criar interfaces de forma

rapida e facil.

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 faca muitas coisas de maneira rapida 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 experiencia que os desenvolvedores ja

possuıam com a tecnologia. Alem 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-

periencia, 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 definicao do

ambiente computacional sobre o qual executara o sistema. Esta secao trata sobre as

principais tecnologias disponıveis para servidores e justifica qual foi a solucao utilizada.

4.2.1 Microsoft Windows Server

E a versao 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 varios aspectos, como o alto custo da licenca e do hardware

para suporta-lo.

27

4.2.2 Linux

Conhecido pela sua eficiencia, o Linux e um sistema operacional open-source com varias

distribuicoes disponıveis, permitindo o uso deste sistema para diversas aplicacoes diferen-

tes, como servidores, computadores pessoais, dispositivos moveis e ate 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 restricao comercial nem de licenca, dei-

xando o ambiente computacional mais favoravel ao desenvolvimento de novas tecnologias.

Alem disso, o Linux e um sistema operacional muito estavel, tornando o ambiente mais

confiavel e com baixo risco de falhas.

4.2.3 Tecnologia Escolhida

O CentOS, que e uma distribuicao do Linux, tambem open-source, otimizada para uso

em servidores foi o sistema operacional escolhido para uso em nosso ambiente devido a

excelente relacao custo-benefıcio. Considerando que nossas aplicacoes nao 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 preocupacao

com compatibilidade de sistemas. Alem disso, esta decisao se mostrou bastante acertada

durante o perıodo de uso do sistema, uma vez que ele atendeu as expectativas e nao

apresentou nenhum tipo de falhas ou travamentos.

4.3 SGBD

No que diz respeito ao SGBD (Sistema de Gerenciamento de Banco de Dados) , algumas

questoes foram discutidas para que a ferramenta pudesse ser considerada adequada ao

sistema. A lista a seguir define todos os criterios utilizados para esta avaliacao:

• Familiaridade dos desenvolvedores: O curto tempo disponıvel tornava necessario

algum historico de trabalho de ao menos parte dos desenvolvedores com esta, a

fim de que fosse dispensavel um investimento muito grande para aprender como

manusea-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 usuarios

28

facam acessos simultaneos ao sistema. Alem 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 seguranca de

forma que tais informacoes sejam criptografadas e escondidas de qualquer um que

venha a ter acesso direto ao SGBD.

• Escalabilidade: E necessario ter um banco de dados que seja escalavel, ou seja, tenha

a capacidade de atender a um grande volume de requisicoes de forma rapida e que,

conforme esse numero varie, o banco conseguisse absorver essa variacao e responder

ativamente de alguma forma, pois, como temos uma ferramenta que disponibiliza

aos alunos suas salas de aula e horarios, se todos estes resolvessem utilizar o sistema

no mesmo instante, terıamos nada menos do que 49.128 usuarios fazendo requisicoes

simultaneas ao sistema e, com um numero tao grande de usuarios, e necessario que

o sistema consiga, de alguma forma, atender a todos e responde-los corretamente

em um intervalo de tempo aceitavel.

• Gerenciamento de uma grande massa de dados: Com aproximadamente 50 (cin-

quenta) mil usuarios 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 historicos que relatam sobre a vida de um

aluno na universidade, desde presencas a quantidade de perıodos, materias cursadas,

etc, esses dados nao poderiam ser apagados, acarretando no fato de que a base so

cresceria e nunca poderia ser reduzida, uma vez que qualquer aluno ja inscrito no

sistema pode acessar o site para realizar consultas.

• Compatibilidade: Era necessario ter uma ferramenta que fosse compatıvel com todas

as demais tecnologias selecionadas para o projeto. Como todas as tecnologias eram

uma decisao dos desenvolvedores, a ferramenta de banco de dados tinha que ser

compatıvel com todas as demais ferramentas, desde o Sistema Operacional ate a

Linguagem de Programacao escolhida.

4.3.1 PostgreSQL

O primeiro candidato e o PostgreSQL [The PostgreSQL Global Development Group, 2016].

Infelizmente, ele nao atende ao primeiro ponto pois nenhum dos desenvolvedores do sis-

29

tema proposto possui historico 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 simultaneos aos dados e garante que os dados

consultados pela aplicacao em cada conexao sempre estarao isolados dos dados que sao

produzidos pelas demais. Alem 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 nao seja atraves de

requisicoes da aplicacao.

No caso do terceiro ponto, o Postgre e, dentre os SGBDs gratuitos, o mais utilizado

em aplicacoes de grande porte, que necessitam de um grande volume de trafico de dados.

Esse SGBD tambem possui heurısticas internas no seu modulo de otimizacao muito mais

robustas e eficientes que as da maioria dos seus concorrentes, permitindo que, por exemplo,

ele execute uma ordenacao 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 satisfatoria, apesar de apresentar lentidao conforme

o volume de dados aumenta muito.

No quarto ponto, o Postgre possui certos limites em relacao a capacidade, que

serao listados a seguir:

Limite Valor

Tamanho maximo da base Ilimitado

Tamanho maximo de tabela 32 TB

Tamanho maximo de tupla 1.6 TB

Tamanho maximo 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. Alem disso, cada tabela possui um tamanho maximo de 32 TB, o que

30

tambem atende ao quarto ponto, pois, no geral, os dados produzidos pelo sistema sao

relativamente pequenos e, apesar de serem volumosos, ainda nao seriam suficientes para

que o limite fosse atingido com facilidade.

Em relacao ao quinto ponto, o PostgreSQL atende as necessidades, pois e relativa-

mente facil instala-lo no CentOS e trabalhar com ele utilizando Java, que, como visto nas

secoes 4.1 e 4.2, foram as tecnologias escolhidas para Sistema Operacional e Linguagem

de Programacao, respectivamente.

4.3.2 MySQL

O segundo candidato selecionado foi o MySQL [Oracle, 2016]. Apesar de haver certo

preconceito dentre os usuarios do MySQL, este e o banco mais conhecido dentre os de

codigo aberto atualmente. Criado em 1980, O MySQL e utilizado por diversas empresas

que utilizam aplicacoes crıticas, como a NASA e a Motorola, por exemplo.

Por ser um SGBD, O MySQL e capaz de garantir o segundo ponto com eficacia,

ja que todos os SGBDs apresentam as propriedades ACID.

Em relacao ao terceiro ponto, o MySQL deixa a desejar em certos aspectos pois

o seu modulo de otimizacao nao e tao robusto e poderoso como o do Oracle ou Postgre,

porem ele tambem e utilizado em aplicacoes de grande porte, o que indica que, mesmo

com essa limitacao, o MySQL consegue atender bem a esse requisito.

Limite Valor

Tamanho maximo da base Ilimitado

Tamanho maximo de tabela Varia de acordo com o SO

Tamanho maximo de tupla 65 KB

Tamanho maximo 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 maximo de tupla, porem o MySQL possui um diferencial dos demais SGBDs:

31

Ele armazena Blob e Text de forma diferenciada. Ele utiliza um esquema de referencias,

nao 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 limitacoes, por conta

deste esquema de referencia, isso torna o MySQL viavel quando estudamos o quarto ponto.

Por fim, o MySQL e compatıvel com o CentOS e existe um drive especıfico para

utiliza-lo em conjunto com Java. Isso somado com o fato de haver experiencia previa do

time com esta ferramenta torna ele um forte candidato a aceitacao.

4.3.3 SQL Server

Dentre os candidatos, o SQL Server e um dos mais promissores e um dos melhores. Po-

rem ele foi logo descartado pois, alem de apenas funcionar em Sistemas Operacionais da

Microsoft, sua licenca custa $931,00. Logo, por conta deste empecilho, o SQL Server foi

descartado da analise.

4.3.4 Bancos de Dados NoSQL

Antes de seguir com os candidatos, e necessario elucidar um conceito chave para a com-

preensao dos bancos de dados que vem 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, sao uma alternativa ao modelo relacional que e

tao fortemente difundido e utilizado nos dias atuais. Criados para oferecer uma solucao

diferenciada dos bancos de dados relacionais, os bancos de dados NoSQL surgiram para

suprir certas demandas que os bancos de dados relacionais nao eram capazes de atender

ou o fazem de forma ineficiente.

O funcionamento dos bancos NoSQL se baseia no fato de o mesmos nao terem como

foco apresentar as propriedades ACID (Atomicity, Consistency, Isolation and Durability),

que sao 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 escalaveis sem que haja perda significativa de desempe-

nho, coisa que e evidente num SGBD relacional. Por conta do ACID, todo SGBD tem

internamente uma serie de tecnicas 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 atraves da

32

rede se torna um processo demasiadamente lento, alem do que, conforme a base cresce,

mais conexoes paralelas sao criadas em todas as instancias do banco, dificultando ainda

mais este processo.

Como os bancos de dados NoSQL optam por nao 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

nao garantir alguma dessas propriedades, como o isolamento, elimina-se uma serie de res-

tricoes, por exemplo o fato de todas as instancias do banco serem obrigadas a possuir a

versao mais atualizada do dado. Ao eliminar somente esse ponto, ja e eliminado tambem,

por consequencia, a necessidade de ter uma comunicacao constante entre as partes do

banco, sendo possıvel atender diretamente a requisicao do usuario no momento que ela e

feita, sem necessidade de conferir se o dado que esta sendo consultado e o mais atual ou

bloquear o dado em todas as instancias quando um usuario vai modifica-lo, pois bloquea-

lo apenas na instancia atual seria o suficiente para eliminar qualquer tipo de incoerencia,

o que mantem as outras instancias capazes de atender a solicitacoes 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. Porem, diferentemente

dos bancos de dados relacionais, realizar operacoes de juncao 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 informacoes que nao possuam nenhum tipo de co-

nexao entre si.

Para a avaliacao 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 terao seu funcionamento explicado com mais detalhamento a seguir.

4.3.5 MongoDB

O MongoDB e um banco de dados NoSQL, lancado 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 so, faz sentido e e independente de qualquer outro documento

33

que o Mongo armazene em seu interior. A consequencia da orientacao a documentos e a

possibilidade de existir redundancia e ate mesmo inconsistencia. Como cada documento

e independente dos demais, nao existe nenhum mecanismo de validacao que impeca que

sejam criados dois documentos que armazenem a mesma informacao ou que um mesmo

documento possua duplicatas de um determinado dado especıfico, o que so seria des-

coberto em tempo de execucao. Alem disso, tambem nao existe validacao para dados

inconsistentes. Como o Mongo utiliza JSON como forma de armazenar dados dentro dos

seus documentos, nada impede que um mesmo dado possua informacoes conflitantes, uma

vez que a unica coisa validada no momento da criacao de um JSON e a nao existencia

de duas chaves com mesmo valor. Em outras palavras, podemos ter dois objetos JSON

que possuem algum tipo de relacao e ambos apresentam informacoes que contradizem as

informacoes 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, ha 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 rapida e com

custo de processamento muito baixo.

Como o Mongo e um banco que busca maximizar a performance e ele funciona

atraves 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. Alem disso, por ser completamente focado em elevacao de

performance, ele atende ao terceiro e quarto pontos com satisfacao.

No quinto criterio ele nao deixa a desejar, pois, apesar de sua configuracao e insta-

lacao serem complexas por necessitarem a criacao de um cluster inicial no qual o Mongo

rodara, ele possui uma versao que atende ao CentOS e um drive especıfico pra Java, alem

de possuir uma documentacao bem descritiva sobre como configura-lo e utiliza-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-

dancia ou inconsistencias. Por trabalharmos com dados historicos da faculdade, dados que

sao sensıveis e que nao podem, em hipotese alguma, ser perdidos, ter um banco de dados

34

que permite que dados redundantes sejam inseridos na base acarretaria numa validacao

exaustiva a nıvel de codigo, o que provavelmente reduziria todo o ganho de performance

que o mongo pode vir a oferecer. Como existe muita relacao entre os dados armazenados

no sistema, acabarıamos com documentos contendo JSONs volumosos que acarretariam

numa recuperacao 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, porem internamente, ele armazena seus dados no formato chave-valor, visando

utilizar este formato para aumentar a escalabilidade do banco.

SQL Tradicional NoSQL CockroachDB

Escalavel Nao Sim Sim

Consistente Sim Nao Sim

Alta disponibilidade Nao Sim Sim

Propriedades ACID Sim Nao Sim

SQL Sim Nao Sim

Tabela 4.3: Comparacao do CockroachDB com outros SGBDs

O Cockroach foi desenvolvido de forma que sua escalabilidade fosse horizontal, utilizando

o conceito de criacao de nos sob demanda no cluster no qual ele roda. Alem disso, o

Cockroach mapeia seus dados da seguinte forma: inicialmente, o Cockroach inicia sua

execucao com um unico intervalo de armazenamento vazio. Conforme as informacoes sao

inseridas, esse intervalo aumenta ate que o limite e atingido, que por padrao e de 64 MB.

Quando esse limite e atingido, os dados sao divididos em dois intervalos que cobrem, cada

um, um segmento contınuo do espaco de valor chave. A partir deste processo, conforme

novos dados vao sendo inseridos, todo o processo se repete e os intervalos vao se dividindo,

fazendo com que o banco sempre lide com intervalos pequenos e bem definidos. Alem disso,

quando ha a criacao ou remocao de um no do cluster, todos os intervalos sao redistribuıdos

35

entre os nos restantes que possuem a maior capacidade, de forma que haja um equilıbrio

de utilizacao entre todos os nos do cluster.

Por conta de seu funcionamento e de sua escalabilidade, o CockroachBD atente com

satisfacao aos pontos 2 (dois), 3 (tres) e 4 (quatro). Ao armazenar os dados oferecendo

um interface de um modelo relacional, o Cockroach esta garantindo as propriedades ACID,

o que possibilita ao banco garantir a integridade dos dados e, por ser capaz de criar nos sob

demanda e redistribuir seus dados dentre esses nos, isso torna o banco capaz de atender a

crescente demanda que o sistema teria, tanto de conexoes simultaneas de usuarios como

de gerencia da massa de dados.

Outro ponto importante e que o Cockroach tem versao desenvolvida para Linux, o que

o torna completamente compatıvel com o CentOS e, apesar de possuir um esquema de

organizacao dos dados de forma nao-relacional, a interface relacional oferecida pelo Coc-

kroach e compatıvel com todos os drivers feitos para PostgreSQL, tornando-o compatıvel

tambem com a linguagem Java.

Entretanto, o que mais pesou negativamente foi o fato de ele estar em desenvolvimento.

Este banco e relativamente novo e acabou de entrar em fase de testes Alpha, entao nao

seria prudente arriscar e coloca-lo em uma aplicacao que lida com dados sensıveis, pois

ainda ha o risco de perda de informacoes e isto seria algo muito ruim para o e-Chamada.


Dentre as 5 (cinco) opcoes, os que mais chamaram a atencao por seus resultados foram

o MySQL, o PostreSQL, o MongoDB e o CockroachDB. A primeira opcao seria o Coc-

kroachDB, pois, por ele unir o melhor dos dois lados, ele resolveria todos os problemas

propostos de uma forma considerada otima. Porem, o que pesou contra ele e acarretou

na decisao de o mesmo nao ser escolhido foi que ele esta em Testes Alpha, ou seja, nao se

tem uma versao estavel do sistema na qual se possa rodar e, com uma aplicacao como o

e-Chamada, e necessario um banco que seja estavel, coisa que o Cockroach, atualmente,

nao e.

Apesar da escalabilidade, a possibilidade de existir inconsistencias fez com que o

Mongo tambem fosse descartado, pois para a nossa aplicacao, acarretaria num aumento

da complexidade de codigo desenvolvido em Java de forma a garantir a eliminacao de

certas ambiguidades que os SGBDs relacionais ja garantem de forma otimizada.

36

Por fim, apesar do PostgreSQL ser bem mais robusto que o MySQL, optamos por

usar o MySQL, pois, para as demandas atuais, o MySQL atende satisfatoriamente e ainda

tem a vantagem da equipe de desenvolvimento como um todo ter um historico de trabalho

com a ferramenta, o que acarretaria num ganho de tempo, que seria investido treinando o

time para lidar com o PostgreSQL, ja que ninguem anteriormente havia trabalhado com

essa ferramenta.

4.4 Mobile

Esta secao fala das principais tecnologias disponıveis para o desenvolvimento de aplicativos

em dispositivos moveis e justifica a escolha da tecnologia utilizada no desenvolvimento do

sistema e-Chamada.

4.4.1 iOS

O iOS e o sistema operacional dos aparelhos da Apple e e o segundo sistema operacional

mais utilizado em smartphones, atras apenas do Android. E um sistema extremamente

fechado para modificacoes e desenvolvimento de aplicacoes, sendo necessario um registro

junto a Apple para a instalacao de aplicativos em dispositivos fısicos.

A linguagem de programacao utilizada no desenvolvimento de aplicacoes no iOS

e o Objective-C, uma linguagem nao muito popular mas muito utilizada em todos os

produtos da Apple.

4.4.2 Android

Desenvolvido pela Google, o Android e o sistema operacional mais utilizado em smartpho-

nes em todo o mundo. Pelo fato de ser open-source o Android e um sistema operacional

aberto e oferece varias facilidades no desenvolvimento de novas aplicacoes, como por

exemplo as APIs que facilitam o uso de tecnologias NFC e Bluetooth. Alem disso, nao

e necessario nenhum tipo de registro nem pagamento de licenca para o desenvolvimento

neste ambiente, deixando o processo de criacao de novos aplicativos livre e desburocrati-

zado.

Os aplicativos no Android sao desenvolvidos na linguagem de programacao Java,

que e muito popular e permite a reutilizacao de codigo de outros componentes do sistema

37

e-Chamada, que tambem sao escritos em Java.


Devido ao elevado numero de aparelhos especialmente no Brasil, onde o Android esta

instalado em mais de 94% dos aparelhos celulares, contra 4% do iOS e 1% do Windows

Phone, o Android foi a tecnologia escolhida. Devido ao uso do Android, foi possıvel o

uso de outras tecnologias como o NFC, uma vez que o iOS nao permite que aplicacoes

de terceiros utilize a tecnologia NFC dos aparelhos. Alem disso, com o grande uso do

Android no Brasil, e o sistema operacional que nos garante o maior numero de usuarios

atingidos pelo nosso sistema.

4.5 NFC

O NFC (Near Field Communication), e uma tecnologia de comunicacao de curtıssimo

alcance, onde os componentes NFC precisam praticamente se tocar para que a comuni-

cacao ocorra. Pode ser utilizada de forma semelhante ao Bluetooth na comunicacao de

dois aparelhos proximos (peer to peer) para transferencia de arquivos ou outros fluxos de

dados ou pode ser usado como leitor/escritor de tags. Alem disso, o NFC pode ser muito

aplicado em tecnologias que utilizam a Internet das Coisas, devido ao baixıssimo custo e

consumo de energia dos dispositivos NFC ou das tags NFC, que nao necessitam de fontes

de energia como fios ou baterias.

Esta modalidade de uso com tags se destaca pela facilidade de uso e pela ampla

aplicacao em sistemas de bilhetagem eletronica em sistemas de transporte publico e em

novas tecnologias de pagamento contactless. Em ambos os casos sao utilizados cartoes

que sao tags NFC e um aparelho leitor de NFC, como os validadores dos onibus e estacoes

ou as maquininhas de cartao de credito para pagamentos contactless.

O uso do NFC em sistemas de pagamento se tornou tao confiavel que nos permitiu

utiliza-lo na identificacao para validar a presenca deste na sala de aula. O processo e

facilitado pelo fato de que grande parte dos smartphones sao compatıveis com a tecnologia

e todos os alunos de instituicoes de ensino como a Universidade Federal Fluminense ja

possuem carteirinhas fornecidas pela universidade compatıveis com o NFC. Todos estes

fatores nos permitiram utilizar o NFC com confianca de que e uma tecnologia segura,

38

acessıvel e com alta compatibilidade para o uso no sistema e-Chamada.


Neste capıtulo foram apresentadas as principais tecnologias utilizadas para desenvolver

o aplicativo, bem como a justificativa de sua escolha em detrimento das demais apre-

sentadas. No proximo capıtulo, sera apresentada a forma como todo o e-Chamada foi

estruturado e desenvolvido.

Capıtulo 5

Arquitetura do Sistema

O capıtulo anterior citou as tecnologias relevantes para implementacao deste projeto.

Alem disso, apresentou uma breve discussao que justificava a escolha de uma determinada

tecnologia em detrimento das demais apresentadas.

Este capıtulo consiste em descrever a elaboracao e implementacao do banco de

dados e do sistema, detalhando como o sistema esta projetado a nıvel de codigo e como

e feita toda a parte de gerencia e controle de informacoes do sistema. Alem disso, sera

realizado um aprofundamento sobre as tecnologias utilizadas no sistema, apresentando

quais das suas funcionalidades foram utilizadas bem como seu funcionamento.

5.1 Banco de dados

O esquema foi construıdo utilizando a ferramenta MySQL Workbench, que e uma ferra-

menta grafica da empresa Oracle Corporation para trabalhar com servidores e bancos de

dados. Esta ferramenta oferece uma interface facil e pratica para que os usuarios possam

interagir diretamente com o banco de dados, sendo possıvel manipular conexoes com seus

servidores, realizar modelagens graficas, desenvolver atraves de SQL, realizar backups dos

bancos, monitorar o desempenho dos bancos, entre outras funcionalidades.

O MySQL Workbench tambem oferece um sistema de controle de permissoes, onde

e possıvel criar diversos usuarios e dar a cada um deles diferentes nıveis de acesso a cada

uma das bases. Os tipos de permissoes possıveis de se conceder ou revogar a um usuario

sobre um determinado Schema de banco de dados no MySQL Workbench sao:

• Direitos sobre um objeto: Este tipo de permissao determina qual o nıvel da capaci-

39

40

dade de um usuario em manipular os dados contidos naquela base. Estas permissoes

se dividem em: DELETE, que permite a remocao de tuplas da base; INSERT, que

permite a insercao de dados na base; SELECT, que permite a consulta de dados na

base; e UPDATE, que permite a edicao de dados na base.

• Direitos sobre DLL: Este tipo de permissao determina quais tipos de comandos SQL

aquele usuario esta autorizado a executar naquela base. Estes comandos se dividem

em: ALTER e ALTER ROUTINE, que permitem ao usuario editar tabelas e rotinas,

respectivamente; CREATE TABLE, CREATE VIEW e CREATE ROUTINE, que

permitem ao usuario criar, respectivamente, tabelas, views e rotinas; INDEX, que

permite ao usuario criar ındices em tabelas; REFERENCES, que permite ao usuario

criar chaves estrangeiras; TRIGGER, que permite ao usuario a criacao de Triggers

utilizando PLSQL.

• Outros direitos: Sao permissoes diversas, que vao de concessao de permissao a lock

de tabelas. Estas permissoes se dividem em: GRANT OPTIION, que permite ao

usuario conceder as mesmas permissoes que ele possui para outro usuario; CRE-

ATE TEMPORARY TABLE, que permite ao usuario criar tabelas temporarias no

sistema; LOCK TABLES, que permite ao usuario dar um lock em tabelas sobre as

quais ele tem permissao de SELECT, ou seja, permite ao usuario, explicitamente,

impedir que uma tabela seja utilizada por outros usuarios em paralelo.

Alem disso, esta plataforma oferece a funcionalidade de Engenharia Reversa, ou

seja, ela permite que, a partir do banco de dados seja extraıdo o esquema de toda a base.

O diagrama apresentado na Figura 5.1 foi extraıdo do sistema utilizando esta mesma

funcionalidade.

41

Figura 5.1: Esquema do Banco de Dados

O esquema e composto por 14 tabelas: ALUNO, ALUNO PRESENCA, BLOCO,

COORDENACAO, COORDENACAO TURMA, CURSA, DEPARTAMENTO, INSTI-

TUICAO, LISTA PRESENCA, MATERIA, PROFESSOR, TURMA, HORARIO e USU-

ARIO.

A tabela USUARIO e responsavel por armazenar informacoes pertinentes a todos

os usuarios do sistema, como login, senha e tokens de usuario, por exemplo. O conceito

de token foi utilizado da seguinte forma: O usuario se autenticara no sistema utilizando

sua senha padrao e, apos a aplicacao confirmar a autenticidade do usuario, ela gerara um

token aleatorio de 32 caracteres e armazenara nesta tabela. Se o login foi feito atraves

do site, o token e armazenado na coluna tokenWeb ou se o login foi feito atraves de um

dos dispositivos mobile, o token e armazenado na coluna tokenMobile. A partir deste

momento, toda iteracao do usuario e validada a partir do token, protegendo a senha

do usuario, que nao sera trafegada em cada requisicao feita ao servidor. Esta estrategia

42

permite, ainda, que o usuario possa ficar conectado simultaneamente no site e na aplicacao

mobile, porem este token so permitira que o usuario tenha apenas uma sessao por vez.

Caso o usuario esteja conectado no site em uma maquina e o mesmo tentar se conectar no

site atraves de outra maquina, um novo token sera gerado e as requisicoes feitas a partir

da maquina antiga serao rejeitadas.

Alem disso, a propria tabela USUARIO e utilizada para mapear uma heranca.

Esta tabela e a tabela principal, que armazena todas as informacoes pertinentes a todos

os usuarios do sistema, enquanto as tabelas ALUNO, PROFESSOR, COORDENACAO e

DEPARTAMENTO possuem uma chave estrangeira que referenciam a chave principal da

tabela USUARIO, permitindo assim que um usuario se autentique no sistema sem que seja

necessario acessar nenhuma das outras tabelas, buscando a senha de cada usuario. Alem

disso, a tabela USUARIO possui uma coluna chamada tipo, que armazena a informacao

de qual tipo aquele usuario e. Isto facilita bastante o acesso, nao se fazendo necessario

consultar as quatro tabelas tambem no momento em que uma requisicao acessa os dados

especıficos de um tipo usuario.

Em seguida, temos a tabela TURMA, que e responsavel por armazenar os dados

de cada turma que ja foi cadastrada no sistema, como seu ano, perıodo, e chave artificial

(atributo conhecido como idTurma). Alem disso, esta tabela possui chaves estrangeiras

para as tabelas PROFESSOR e MATERIA, nos quais sao armazenados qual o professor

leciona ou lecionou naquela turma e de qual disciplina aquela turma e, respectivamente.

Atraves da tabela CURSA, o banco e capaz de armazenar quais alunos ja possuıram

algum tipo de relacao com aquela turma, uma vez que o aluno pode ser inscrito em uma

determinada turma e, no perıodo de ajuste pedir o trancamento daquela inscricao. Para

fins historicos, este e um tipo de dado que nao pode ser perdido, entao para isso, existe

um atributo chamado inscrito, que armazena o estado daquele aluno naquela turma.

Alem disso, esta tabela armazena a frequencia de cada aluno inscrito na coluna de nome

frequencia e o seu valor e calculado a partir da quantidade de aulas nas quais o aluno

estava presente dividida pela quantidade de aulas ministradas daquela turma.

Ainda buscando capturar informacoes necessarias sobre uma turma, foi criada a

tabela COORDENACAO TURMA, que armazena a informacao sobre qual turma esta

disponıvel para quais coordenacoes. Alem disso, esta tabela tambem armazena a quanti-

dade de vagas que esta coordenacao tem direito naquela turma.

43

Para armazenar as informacoes pertinentes as presencas dos alunos, foram criadas

duas tabelas: LISTA PRESENCA e ALUNO PRESENCA. A tabela LISTA PRESENCA

e responsavel por armazenar todas as aulas ministradas por um professor em uma turma.

Ela contem uma chave estrangeira referenciando a turma a qual essa lista pertence, alem de

conter a data na qual aquela lista foi criada e o assunto daquela aula. A partir desta tabela,

e inferida a quantidade de aulas que um professor ministrou em uma determinada turma, ja

que o sistema armazena apenas uma lista por aula. Ja a tabela de ALUNO PRESENCA e

responsavel por armazenar a presenca individual de cada aluno em uma determinada lista

de presenca. Para isso, ela conta com duas chaves estrangeiras que referenciam as tabelas

de ALUNO e LISTA PRESENCA, alem de dispor de mais 4(quatro) campos: situacao,

que armazena a situacao do aluno naquela aula (Presente ou Ausente); responsavel, que

armazena se a presenca foi dada pelo aluno ou pelo professor; justificativa, que armazena

a justificativa de uma determinada ausencia; e metodo, que armazena o meio pelo qual a

presenca foi feita, se foi atraves do site ou do aplicativo Mobile. Desta tabela e retirada

a quantidade de presencas de um aluno em uma determinada turma.

Por fim, as tabelas de HORARIO e BLOCO permitem ao sistema armazenar os

locais e horarios das aulas de cada turma. A tabela de BLOCO armazena os dados re-

ferentes as salas disponıveis no sistema atraves dos campos bloco, campus e sala. Esta

tabela ainda armazena a capacidade de uma determinada sala atraves do campo lotacao.

Por fim, a tabela HORARIO armazena os horarios e os locais das aulas de uma deter-

minada turma. Ela armazena o local atraves de uma chave estrangeira para a tabela

BLOCO e as demais informacoes que ela armazena sao os horarios de inıcio e fim de uma

determinada aula e o dia da semana que aquela aula acontece. Vale acrescentar que este

armazenamento e unico, ou seja, os dados armazenados nesta tabela sao referentes a uma

turma durante todo o perıodo, logo, se uma turma tem entradas nesta tabela com dias

segunda e quarta e horarios de inıcio e fim de 9 as 11 respectivamente, isso significa que

as aulas daquela turma se dao semanalmente as segundas e quartas das 9 as 11.

5.2 Aplicacao Web

Esta secao tratara de explicar como a Aplicacao Web foi estruturada, especificando as

tecnologias utilizadas e como tudo foi feito.

44

A aplicacao web foi desenvolvida com dois objetivos: Ser a ponte entre os aplica-

tivos Mobile e oferecer aos usuarios uma forma de interagir com o sistema sem que seja

obrigatorio que o mesmo possua um aparelho com Android. Para o primeiro objetivo, era

necessario que as informacoes fossem guardadas em um lugar seguro, que houvesse algum

repositorio central de onde todos os usuarios obteriam informacoes e, caso produzissem

algum dado, este seria enviado diretamente para la. Com essa demanda, foi necessaria

a criacao de um servidor que possuısse um SGBD interno e que houvesse uma forma de

todos os aplicativos se comunicarem com esse servidor. Ja para o segundo, seria necessaria

a criacao de um software que rodasse na maquina dos usuarios ou pudesse ser aberto em

qualquer dispositivo e que permitisse que os usuarios que nao possuıssem um smartphone

pudessem acessar o sistema sem problemas.

Para atender a essa demanda, seria necessaria a criacao de uma aplicacao que

fosse capaz de receber requisicoes da Web, processa-las atraves de consultas ou escritas

no banco de dados, produzir uma resposta num padrao previamente definido e envia-la

ao cliente novamente atraves da web. Alem disso, esta aplicacao deveria ser capaz de se

comunicar com todas as outras aplicacoes que seriam desenvolvidas de forma que fosse

possıvel os usuarios acessarem o sistema sem o uso de um smartphone. Entao foi necessa-

rio optar entre criar uma aplicacao desktop ou um site para que esta funcionalidade fosse

implantada com sucesso. Porem, se fosse escolhida criar uma aplicacao desktop, uma

serie de medidas seriam necessarias para garantir que todas as maquinas nas quais esta

aplicacao fosse instalada fossem compatıveis, alem de correr o risco de terem problemas

de compatibilidade devido ao uso de versoes diferentes da JVM. Por conta dessas ques-

toes, a escolha foi de desenvolver uma aplicacao web que se comunicasse com o usuario

atraves de um site, pois assim eliminarıamos todos estes problemas, uma vez que so seria

necessario configurar o Java no servidor da aplicacao, eliminando assim qualquer processo

de execucao de codigo Java no usuario.

A partir destas premissas, foi desenvolvida uma aplicacao web que, simultanea-

mente, atende requisicoes vindas de aplicativos mobiles e navegadores, processando-as e

e montando um tipo de retorno de acordo com a requisicao. Para atender as demandas

vindas dos dispositivos moveis, sao utilizadas Servlets e, para atender as requisicoes de

site, sao construıdas paginas utilizando JSP.

45

Figura 5.2: Diagrama de Pacotes do Sistema

A Figura 5.2 exibe como esta organizada, a nıvel de pacotes, a aplicacao Web. As

subsecoes a seguir explicarao no detalhe qual a finalidade de cada pacote, bem como seu

conteudo.

5.2.1 Settings

O primeiro pacote do sistema e o pacote Settings, que contem as classes responsaveis

pelas configuracoes da aplicacao. Dentro dele, existem duas classes, a classe Sttings e

a classe Environment. A classe Settings contem todas as configuracoes relacionadas as

variaveis de ambiente que sao utilizadas para criar as conexoes com o banco de dados. Ja

a classe Environment cria um objeto de Settings preenchendo com os valores das variaveis

e ambientes e gerenciando este objeto, atraves do padrao Singleton.

A partir deste pacote, e possıvel configurar o ambiente de forma que as conexoes

ao banco de dados possam ser criadas, tornando o processo de configuracao independente

do processo de criacao de conexoes e possibilitando um desacoplamento entre essas duas

partes do sistema, de forma que as variaveis de ambiente podem ser modificadas a qualquer

momento e nao sera necessario realizar nenhuma mudanca no pacote de conexao com o

banco.

5.2.2 DBFactory

Este e o pacote responsavel por produzir as conexoes com o banco. Utilizando um padrao

de projeto conhecido como Factory, este pacote possui apenas uma classe, conhecida como

46

DBConnection.

A classe DBConnection possui um unico metodo, chamado getConexao(), que cria

uma nova conexao com o banco de dados a partir dos dados contidos nas classes de

configuracao. Em outras palavras, este metodo utiliza as configuracoes feitas previamente

nas variaveis de ambiente para criar as conexoes com o banco de dados, e isso nos permite

nao ter, em lugar algum no codigo fonte, os dados de usuario e senha que sao utilizados

pela aplicacao para se conectar no banco, ja que os mesmos ficam armazenados dentro

do sistema operacional, em suas variaveis de ambiente locais. Esta medida simples nos

permite proteger o usuario que acessa o banco, de forma que se tenha certeza de que

os acessos sao realizados apenas por maquinas autorizadas. Logo, se a aplicacao for

baixada em algum outro local, porem esta maquina nao possuir as variaveis de ambiente

devidamente configuradas, a aplicacao nao conseguira realizar nenhum acesso a base.

5.2.3 Exception

O pacote Exception contem todas as classes de excecao que o sistema pode lancar em

diversos pontos da sua execucao. Composto por 12 classes, este pacote esta fortemente

vinculado ao pacote DAO, pois e neste pacote que a maioria das falhas de sistema pode

vir a ocorrer.

5.2.4 Model

Este pacote e onde todas as classes do modelo da aplicacao sao armazenadas. Basicamente,

este pacote contem todas as classes que representam os dados que sao armazenados em

tabelas no banco de dados.

Atraves da Figura 5.3, e possıvel visualizar o diagrama de classes que mapeia as

classes deste pacote bem como os relacionamentos dentre elas.

47

Como e possıvel ver no diagrama, todas as classes que mapeiam objetos do modelo

sao utilizadas apenas para armazenamento e manipulacao de informacoes, tornando-as

livres de qualquer tipo de logica que e referente as funcionalidades implementadas. Essa

boa pratica torna possıvel absorver mudancas no modelo de forma mais rapida e menos

impactante para o modelo de negocios em si, uma vez que qualquer mudanca no modelo

resultaria em uma mudanca direta nas tabelas do banco e vice-versa.

5.2.5 DAO

Este pacote contem as classes que manipulam as informacoes do banco. Atraves das

classes do pacote DAO, a aplicacao consegue consultar valores no banco, criar objetos que

armazenem aqueles valores e retorna-los para que sejam processados.

Este pacote contem um total de 12(doze) classes de acesso ao banco de dados, onde

cada classe e responsavel por mapear uma entidade e, consequentemente, preencher uma

ou mais tabelas associadas aquela entidade.

5.2.6 PaginasWeb

O pacote de PaginasWeb e um dos dois pacotes que contem objetos que realmente geram

algum tipo de resposta. Todos os pacotes, ate o momento, eram de gerencia de erros

interna, mapeamento, configuracao ou manipulacao de dados, porem, este e primeiro

pacote que possui conteudo que gera respostas para os usuarios. Este pacote contem

objetos feitos em JSP que sao responsaveis pelo site web com o qual os usuarios interagirao

ao longo do seu perıodo letivo.

JSP e uma tecnologia de Java lancada em 1999 com o intuito de permitir a criacao

de paginas web geradas dinamicamente. Um arquivo com extensao .jsp e escrito nati-

vamente em HTML, porem esta tecnologia permite que haja a insercao de codigo Java

dentro deste HTML, que sera processado e executado antes do envio da pagina. Com

essa liberdade, os desenvolvedores podem construir suas paginas combinando codigo Java

e HTML, possibilitando a insercao de logica de programacao no momento de construcao

de uma pagina, algo que, utilizando apenas HTML, e impossıvel.

Esta tecnologia e traduzida, em tempo de execucao, em uma Servlet da aplicacao,

que tem como resposta uma pagina HTML que e gerada de acordo com os dados recebidos

de entrada. Cada JSP e traduzido em um Servlet que ficara armazenado em cache ate que

48

o arquivo JSP seja reescrito, eliminando assim a necessidade de recompilar este arquivo

a cada nova operacao, tornando esta tecnologia tao eficiente quanto uma Servlet comum.

O pacote PaginasWeb e subdividido em 4(quatro) subpastas, sendo elas nomeadas

aluno, professor, coordenacao e departamento. Cada uma destas subpastas contem ar-

quivos JSP que atendem a requisicoes de usuarios especıficos dentro da aplicacao, sendo

cada JSP convertido em uma Serlvet e gerando uma pagina dinamicamente no momento

da requisicao. Por exemplo: Se um professor faz login na aplicacao, ele sera redirecionado

para a Servlet referente ao arquivo index.jsp dentro da pasta professor e esta gerara a

pagina dinamicamente, enviando-a como resultado para o usuario. Caso o coordenador

faca login, ele sera redirecionado para a Servlet referente ao arquivo index.jsp dentro da

pasta coordenacao, que repetira o mesmo processo. Vale ressaltar que cada tipo de usuario

nao pode acessar paginas que sao geradas para outros tipos, ficando limitado a acessar os

dados que lhe sao conferidos em suas interfaces.

5.2.7 WebServlet

Por fim, o ultimo pacote do sistema e o pacote WebServlet. Este pacote e responsavel por

criar objetos que responderao a requisicoes tanto do site quanto das aplicacoes Mobile.

A tecnologia utilizada para que esta resposta fosse processada foram as Servlets,

que sao nativas do Java. Uma Servlet e uma classe Java que possibilita ao programa

estender as funcionalidades de um servidor, ou seja, atraves da Servlet, o codigo Java

pode se comunicar com a rede utilizando o protocolo HTTP, atraves de qualquer um dos

9 metodos de requisicao. A vantagem de se utilizar Servlets e, acima de tudo, a praticidade

e a liberdade que seu uso confere. Uma Servlet responde a requisicoes HTML, porem ela

pode gerar como resposta qualquer tipo de arquivo, desde uma pagina HTML a um JSON

ou uma foto. No geral, as respostas geradas pela Servlet sao do tipo JSON, porem existe

uma Servlet que retorna uma imagem como resposta. JSON e um forma facil e simples

de transmitir dados entre duas aplicacoes ou em uma aplicacao cliente-servidor, como e

o caso do e-Chamada. Ele armazena seus dados no formato chave-valor, permitindo que

todos os dados do sistema possam ser transmitidos as paginas web ou aos apps mobile de

uma forma padronizada e com um custo relativamente baixo, dependendo da quantidade

de informacao transitadas.

As Servlets sao utilizadas no e-Chamada para atender, principalmente, a requisi-

49

coes do site, uma vez que, atraves de JavaScript, podemos criar requisicoes assıncronas e

o tempo de processamento e entrega da pagina nao e afetado pelo resultado da Servlet.

Em outras palavas, o site pode, atraves de JavaScript, delegar um processamento mais pe-

sado para a aplicacao atraves de uma Servlet e ficar aguardando a resposta, sem que seja

necessario que a pagina do usuario seja recarregada ou que o mesmo seja redirecionado.

Dentre as 18(dezoito) servlets que estao, atualmente, no sistema, foram seleciona-

das as 5 principais para serem explicadas, ja que elas sao as mais utilizadas pelo sistema:

• A primeira Servlet e chamada de Login, e e a Servlet que recebe requisicoes de todos

os aplicativos Mobile, realiza o login deles no sistema e retorna um tokenWeb valido

para o sistema. Ela recebe os dados de um usuario inseridos na tela do aplicativo,

faz a validacao de usuario e senha, gera o tokenMobile daquela sessao e envia um

JSON atraves da rede para o dispositivo, que autoriza o login e segue para a proxima

tela.

• A proxima Servlet e a Servlet de presenca. Apesar de existir uma pagina de aula

onde o professor pode modificar o estado de um aluno, esta pagina, por si so nao

poderia processar este tipo de acao, entao, por isso, a Servlet atua como um suporte,

dando a possibilidade desta acao ser executada. Quando o professor clica no botao

para mudar o estado de um aluno, o JavaScript gera uma requisicao assıncrona para

a servlet de presenca que recebe os dados do professor, da turma e do aluno ao

qual a presenta esta sendo alterada, bem como o token gerado para aquele professor

naquela secao. A integridade da secao e validada, assim como a existencia do aluno,

se o mesmo esta inscrito naquela turma e se o professor e o professor daquela dis-

ciplina. Caso todos os testes deem positivo, o estado do aluno e alterado no banco

atraves da DAO correspondente e e criado um JSON de resposta dizendo que a al-

teracao foi bem sucedida. Caso algum teste nao seja bem sucedido ou haja alguma

falha no processo de salvamento, tambem e gerado um JSON com uma informacao,

notificando qual a falha correspondente.

• A terceira Servlet selecionada e a Servlet chamada Foto. Esta Servlet e utilizada

para atender a requisicoes que recebam o id de um determinado usuario e, a partir

dele, retorne a foto que corresponde aquele usuario. Esta Servlet e utilizada em

todas as telas que possuem fotos do usuario, mas seu maior exemplo de utilizacao

50

e na tela inicial da Coordenacao: Para cada imagem que e carregada de um aluno,

uma requisicao assıncrona e submetida para esta Servlet, que retorna a imagem

correspondente ao aluno. Caso as imagens fossem processadas no momento da cons-

trucao da pagina, o tempo de resposta seria tao lento que a conexao se encerraria

por time-out, uma vez que a quantidade de fotos a serem processadas e tao grande

quanto a quantidade de alunos de uma coordenacao. O isolamento desta funcio-

nalidade numa Servlet permite que o usuario receba a pagina gerada rapidamente,

carregando as fotos apos o carregamento da pagina.

• A Servlet selecionada neste topico e a Servlet de ManipularTurma. Apesar desta ter

sido selecionada, existem outras duas, chamadas ManipularProfessor e ManipularA-

luno, que funcionam no mesmo conceito, mudando apenas os dados de entrada e a

resposta. Esta Servlet e utilizada na criacao, edicao ou exclusao de uma turma do

sistema. Utilizando requisicoes do tipo POST, PUT e DELETE, a mesma Servlet e

capaz de realizar 3(tres) operacoes diferentes sobre os dados. Atraves da requisicao

do tipo POST, o sistema realiza a insercao de uma turma, utilizando os dados en-

viados pelo front e retornando um JSON informando o sucesso ou fracasso daquela

operacao. No caso da requisicao do tipo PUT, ela e utilizada no momento em que

e necessario editar uma turma, funcionando no mesmo padrao da requisicao POST:

recebendo os dados modificados como entrada e respondendo com um JSON infor-

mando o sucesso ou fracasso da operacao. Por fim, a requisicao do tipo DELETE

e utilizada para excluir uma turma do sistema permanentemente. Ela recebe como

parametro o id da turma e realiza a exclusao, tambem retornando um JSON como

resposta para o front.

• Por fim, a ultima Servlet selecionada e a Servlet Diario. Esta Servlet recebe como

entrada a lista de alunos de uma turma, juntamente com os dados da turma e do

professor, e atualiza o estado de todos os alunos da turma, de acordo com o estado

(inscrito ou nao inscrito). O front recebe como entrada uma planilha excel extraıda

diretamente do IdUFF e realiza um pre-processamento nela, extraindo apenas os

dados aproveitados e os envia ao backend. No backend, a aplicacao faz a alteracao

no estado dos alunos, trancando os que estao como inscritos mas nao apareceram

na lista recebida e inscrevendo os que nao estavam inscritos mas foram recebidos na

lista. Vale ressaltar que esta Servlet precisa receber as planilhas sequencialmente

51

ordenada por mes de emissao, uma vez que a insercao de dados em ordem aleatoria

podera causar inconsistencias no que foi gerado.

A partir destes 5 (cinco) exemplos, foi possıvel perceber o quao util e quao poderosa

uma Servlet pode ser e, por conta disso, esta tecnologia foi imensamente explorada durante

todo este projeto.

5.3 Aplicativo do Professor

O aplicativo mobile do professor foi desenvolvido na plataforma Android e escrito na

linguagem de programacao Java, que e a linguagem de programacao utilizada para o

desenvolvimento de aplicativos Android. No desenvolvimento do aplicativo, foi usada a

ferramenta Android Studio, que e o Integrated Development Environment oficial da pla-

taforma. Este aplicativo se comunica com a aplicacao web atraves das Servlets, que sao

responsaveis pela integracao entre os diferentes componentes do sistema. Na comunica-

cao entre o aplicativo e a aplicacao web, e utilizado o protocolo HTTPS, que garante a

seguranca das informacoes transferidas.

Considerando a importancia do funcionamento do aplicativo do professor na sala

de aula durante o processo de chamada, este aplicativo foi planejado para funcionar de

forma independente da disponibilidade de acesso a internet, uma vez que este nao pode

ser um impedimento para o seu funcionamento, pois atrapalharia a dinamica da aula e

poderia prejudicar os nossos usuarios em vez de ajuda-los. Portanto, no momento do

login, o aplicativo, apos a validacao das credenciais fornecidas pelo usuario, salva todas

as informacoes necessarias para o seu funcionamento em um banco de dados local no

dispositivo e garante que mesmo sem acesso a internet, o professor podera confiar no

e-Chamada para fazer a chamada durante a aula.

5.3.1 Banco de Dados

Localmente, as informacoes do aplicativo sao salvas em um banco de dados SQLite, que

e um banco de dados relacional salvo em um arquivo e oferece uma biblioteca de progra-

macao para a aplicacao. O SQLite fornece a aplicacao uma visao semelhante a um SGBD

tradicional e tambem e compatıvel com a linguagem SQL.

52

Diferentemente do banco de dados do servidor, o banco de dados do aplicativo

guarda apenas as informacoes necessarias para o seu funcionamento, que sera, em geral,

um subconjunto do banco de dados do servidor e possui 10 tabelas, como ilustrado na

figura 5.4.

5.3.2 Organizacao do Codigo

Uma vez que o aplicativo foi escrito na linguagem de programacao Java, que e uma

linguagem orientada a objetos, todo o codigo fonte do projeto esta em classes. As classes,

por sua vez, estao organizadas divididas em pacotes. Exstem tres pacotes principais, sao

eles: Ctrl, Model e Database.

5.3.2.1 Pacote Ctrl

Neste pacote estao as classes com os componentes que contem a interface do usuario. Ma-

joritariamente, o componente utilizado para a criacao da interface e chamado Atividade.

Este componente representa uma tela do aplicativo. Existem tres Atividades principais

neste aplicativo:

• LoginActivity: a tela de login do aplicativo e a primeira tela que o usuario ve

quando abre o aplicativo e esta pede as credenciais do usuario (email e senha) para

autentica-lo no sistema.

• ProfessorActivity: e a principal tela do aplicativo que o professor ve apos se auten-

ticar na tela de login e esta tela lista as turmas que o professor ministra.

• ListaActivity: nesta tela o professor abre uma lista de presenca e pode marcar a

presenca dos seus alunos (manualmente ou atraves do sensor NFC com as carteiri-

nhas).

5.3.2.2 Pacote Model e Pacote Database

O pacote Model contem as classes com a modelagem do sistema e o pacote database e

responsavel pela comunicacao do aplicativo com o banco de dados local SQLite. Nestes

pacotes estao implementadas todas as funcionalidades especificadas. Estes pacotes estao

diretamente relacionados, uma vez que todas as tabelas do banco estao mapeadas na

aplicacao.

53

5.3.3 Manifesto

O Manifesto e um arquivo xml (AndroidManifest.xml) onde estao todas as informacoes do

aplicativo que a Android Virtual Machine precisa para executar o aplicativo corretamente.

As principais informacoes que este arquivo contem sao:

• Versao: o codigo da versao do aplicativo (versao 1, versao 2, ...).

• Permissoes: as permissoes que o usuario precisa conceder para que o aplicativo

funcione (acesso a internet, acesso ao armazenamento, acesso ao sensor NFC, ...).

• SDK: as versoes do Android necessarias para a execucao do aplicacao, no caso deste

aplicativo, a versao mınima e a 4.2.

• Atividades: as atividades do aplicativo (que estao implementadas no pacote Ctrl),

bem como informacoes de qual a atividade principal que a AVM deve abrir quando

comecar a execucao do aplicativo.

5.3.4 Recursos

Na pasta ”res” encontram-se as imagens, layouts, menus e arquivos relacionados com

a interface do aplicativo. Nesta pasta, as imagens tem uma peculiaridade pois devem

estar em diferentes resolucoes para serem exibidas adequadamente em dispositivos com

diferentes tamanhos e resolucoes de tela.

5.4 Aplicativo da Coordenacao

O aplicativo da coordenacao foi desenvolvido utilizando as mesmas ferramentas e seguindo

a mesma logica e estrutura (organizacao de codigo, manifesto e recursos) do aplicativo

do professor. Este aplicativo permite que a coordenacao gerencie seus alunos e utiliza o

sensor NFC para a leitura das carteirinhas e e mais simples e mais leve que o aplicativo

do professor, uma vez que neste caso, nao ha a necessidade de cache local das informacoes

para o funcionamento offline.

5.4.1 Atividades

Toda a interface com o usuario neste aplicativo se resume a essas tres telas:

54

• LoginActivity: a tela de login do aplicativo e a primeira tela que o usuario ve quando

abre o aplicativo e esta tambem pede as credenciais do usuario (e-mail e senha) para

autentica-lo no sistema, como no aplicativo do professor.

• MainActivity: e a principal tela do aplicativo que o usuario ve apos se autenticar

na tela de login, esta tela lista os alunos cadastrados na coordenacao e permite o

cadastro de um novo aluno.

• AlunoDetailActivity: esta tela mostra todas as informacoes de um aluno e permite

que a coordenacao edite as informacoes, bem como o uso do sensor NFC para a

leitura da carteirinha.

5.5 Resumo do Capıtulo

Neste capıtulo estao as informacoes sobre a estrutura e desenvolvimento dos diferentes

componentes do e-Chamada desde o Banco de Dados do servidor, Aplicacao Web aos

aplicativos mobile da Coordenacao e do Professor, bem como seu banco de dados local

para o cache de informacoes.

55

Figura 5.3: Diagrama de classes da aplicacao Web

56

Figura 5.4: Diagrama do Banco de Dados do Aplicativo

Capıtulo 6

Implantacao do Sistema

Os capıtulos anteriores citaram as tecnologias usadas no desenvolvimento do sistema e

tambem descreveram a forma como ele foi implementado. Este capıtulo descrevera a

infraestrutura necessaria para o funcionamento do sistema, utilizando tecnologias descritas

no Capıtulo 4.

6.1 Ambiente Computacional

6.1.1 Sistema Operacional

O sistema operacional escolhido para os servidores foi o CentOS 7. O CentOS (Commu-

nity Enterprise Operating System) e distribuicao do Linux de codigo aberto e e conside-

rado um dos melhores sistemas operacionais disponıveis para servidores. Durante todo o

processo de testes do sistema, o CentOS se mostrou bastante estavel, teve bom desempe-

nho e nao apresentou nenhum travamento nem provocou nenhuma indisponibilidade ao

sistema decorrente de erros. Alem disso, o CentOS conta com o gerenciador de pacotes

RPM que facilita a instalacao de pacotes no servidor e junto com a ferramenta de linha

de comando Yellowdog Updater, Modified (yum), e possıvel instalar e atualizar pacotes a

partir dos repositorios online de forma facil e rapida.

6.1.2 Secure Shell (SSH)

[The OpenBSD Project, 2016]

SSH e um protocolo de rede criptografico que permite o login e a execucao de linhas de

57

58

comando remotamente de forma segura no servidor. Para o funcionamento do protocolo

SSH, foram utilizadas a ferramenta de servidor OpenSSH e o cliente MobaXTerm, que alem

de implementarem o protocolo SSH para a execucao de linhas de comando, implementam

o protocolo SFTP que possibilita a transferencia segura de arquivos. O uso do SSH,

combinado com o VPN, permitiu a configuracao e manutencao do servidor remotamente

de forma segura mesmo pela internet.

6.1.3 Virtual Private Network (VPN)

[Dunston, 2016]

O VPN permite o acesso de forma segura a rede privada do laboratorio onde o servidor esta

fisicamente localizado a partir da internet. A tecnologia de VPN utilizada e o OpenVPN,

um software livre publicado sob licenca GNU General Public License. Este software cria

redes privadas virtuais do tipo ponto-a-ponto ou server-to-multiclient (solucao utilizada)

atraves de tuneis criptografados entre computadores. Para prover a criptografia das cone-

xoes VPN, o OpenVPN utiliza a biblioteca OpenSSL que implementa o protocolo SSL, que

e um padrao global em tecnologia de seguranca. Utilizando a rede VPN, foi possıvel aces-

sar com seguranca aplicacoes implantadas no servidor que nao podem ser disponibilizadas

para acesso direto (como o SGBD, por exemplo) atraves da internet.

6.2 Aplicacao Web

6.2.1 Servidor de Aplicacoes

Como a aplicacao web do e-Chamada e inteiramente escrita em Java, utilizamos o ser-

vidor de aplicacoes Apache Tomcat 8, uma implementacao open-source de Java Servlet

e JavaServer Pages. Todas as paginas do site utilizam a tecnologia JavaServer Pages e

todos os endpoints da API utilizam a tecnologia Java Servlet, entao o Servidor de Apli-

cacoes se torna extremamente vital para o funcionamento de todo o sistema e qualquer

falha que este apresente pode ser fatal, por isso utilizamos o Apache Tomcat 8, que alem

de ser o servidor de aplicacoes Java mais utilizado, teve bom desempenho e se mostrou

muito estavel e nao apresentou falhas em nenhum momento. O Apache Tomcat 8 tambem

implementa Java Expression Language e tecnologias Java WebSocket.

59

6.2.2 Servidor Web

Apesar do bom desempenho apresentado pelo Apache Tomcat 8 na API, este nao e a

melhor opcao para servir os arquivos estaticos que sao muito utilizados no site, entao

utilizamos, alem do Apache Tomcat 8, o Nginx, um servidor HTTP de alta performance,

open-source e proxy reverso. Todas as conexoes originadas externamente sao enderecadas

para o Nginx, que pode encaminhar a requisicao para o Apache Tomcat 8 e fazer cache de

arquivos como imagens, arquivos CSS ou JS que sao sempre estaticos. O uso deste cache

pode reduzir de forma significativa a quantidade de requisicoes que chegam nos servidores

de aplicacoes e tambem o tempo de resposta para o usuario. Alem disso, com o Nginx,

podemos criar um cluster de servidores Apache Tomcat 8 e utiliza-lo como balanceador

de carga.

6.2.3 Acesso Seguro

Considerando que trafegaremos dados sigilosos do usuario, como senha e outros dados

pessoais, utilizamos o protocolo HTTPS para garantir privacidade, autenticidade e in-

tegridade das requisicoes com o servidor. Este protocolo e implementado pelo servidor

web Nginx. Alem disso, utilizamos a autoridade certificadora Let’s Encrypt, que e uma

autoridade certificadora livre, automatizada, aberta, facilmente implantavel e prove um

certificado confiavel pelos navegadores.

6.3 Servidor Gerenciador de Banco de Dados

Para o servico do banco de dados, utilizamos o MySQL Community Server, um servidor

de banco de dados que apresentou facilidade de uso, de instalacao e de configuracao, alem

de disponibilizar todas as funcionalidades necessarias para o funcionamento do sistema

e-Chamada.

6.4 Dispositivos Moveis

Para a aplicacao movel do e-Chamada, utilizamos a plataforma do Android, que alem de

ser o sistema operacional movel mais utilizado no Brasil, oferece funcionalidades essenciais

para o e-Chamada, como as APIs abertas da tecnologia NFC (o que nao e oferecido por

60

outros sistemas operacionais, como por exemplo o iOS ). Alem de ser o sistema opera-

cional movel mais utilizado, o desenvolvimento de aplicativos na plataforma Android e

na linguagem de programacao Java, o que permite a portabilidade de codigos de outros

componentes do sistema e-Chamada que e quase todo escrito em Java.

Capıtulo 7

Conclusao

Este capıtulo e dividido em 3(tres) secoes. Na primeira secao, serao abordadas algumas

das dificuldades encontradas ao longo deste projeto. Na segunda secao, serao apresentadas

algumas sugestoes de trabalhos futuros. Por fim, na terceira secao, serao apresentadas

algumas consideracoes finais.

7.1 Dificuldades Encontradas

Durante este projeto, algumas dificuldades que foram encontradas apresentaram-se como

um obstaculo que impactou em algum grau na continuidade do projeto. Foram selecio-

nadas 3(tres) dificuldades principais, das quais 2(duas) sao decorrentes da arquitetura do

sistema e apenas 1(uma) e um fator externo.

A primeira dificuldade encontrada esta na forma como a arquitetura do banco foi

definida na tabela USUARIO. Ao utilizarmos o campo tipo para reduzir a quantidade

de consultas no banco, introduzimos uma limitacao sutil que so foi percebida no final do

projeto: Um usuario nao podera ter mais de um tipo. Com essa limitacao, o sistema nao

daria suporte a uma mudanca de tipo de usuario, como por exemplo, um professor se

tornando coordenador de curso (seria necessario dois usuarios diferentes para cada papel

no sistema, o que prejudicaria a experiencia do usuario por ter que trocar de usuario

constantemente para utilizar o sistema). Alem disso, na forma como o sistema esta proje-

tado hoje, um mesmo usuario nao pode nem possuir duas tuplas de aluno ou duas tuplas

de professor o referenciando, ja que o campo idUsuario e a chave primaria de ambas as

tabelas tabelas ALUNO e PROFESSOR.

61

62

A segunda dificuldade encontrada foi tambem em relacao a estrutura dos usua-

rios. Da forma como esta estruturado atualmente, cada coordenacao possui apenas uma

unica tupla na tabela COORDENACAO e, como consequencia, possui um unico usuario

associado. Considerando que pode haver a necessidade de se possuir mais de um usuario

com o mesmo nıvel de acesso que uma determinada coordenacao, o sistema nao tera como

absorver essas particularidades. Alem disso, o fato de existir o token e limitar a uma unica

secao por usuario, nao ha como duas pessoas utilizarem o mesmo usuario de coordenacao

simultaneamente para realizar suas acoes no sistema, uma vez que, no momento em que o

segundo efetuar login, o token do primeiro sera automaticamente invalidado e sua sessao,

encerrada.

Por fim, a terceira dificuldade encontrada no sistema e nao termos uma integracao

formal com o IdUFF. Por razoes administrativas, nao possuımos nenhuma forma de acessar

os dados existentes na base do IdUFF, entao foi necessario realizar uma carga manual

na base de e-Chamada para que o desenvolvimento pudesse ser iniciado. Alem disso,

como algumas das tabelas tem insercao de dados em perıodos regulares, era necessario

que houvesse alguma forma de possibilitar que essa base pudesse ser constantemente

abastecida com novos dados. Porem, com o volume de alunos que entram em cada perıodo,

depender da criacao de cada aluno individualmente seria um trabalho que demandaria

muito tempo da coordenacao e inviabilizaria a utilizacao do sistema.

Alem do problema de cadastros de alunos, que acontece semestralmente, existe

um segundo problema que e mais grave que o primeiro: A mudanca mensal da folha de

presenca. Como os alunos tem a opcao de, no primeiro mes, cancelar sua inscricao numa

disciplina caso estejam inscritos ou, caso contrario, optar por esperar por uma vaga na

mesma, isso acaba criando uma certa volatilidade nas listas durante os primeiros meses

do perıodo, de forma que, a cada mes, estas sao atualizadas com informacoes que as

anteriores nao continham, necessitando que o sistema consiga refletir esta atualizacao. Se

fosse necessario executar o controle disso manualmente no sistema, a coordenacao perderia

muito tempo so para tornar os dados da base consistentes, o que tambem inviabilizaria o

uso do sistema.

Para solucionar estes dois problemas, foram criados dois uploads de diarios diferen-

tes: uma para os professores e um para a coordenacao. No caso do upload da coordenacao,

este permite que o usuario crie uma lista em formato .xls e, seguindo um padrao especıfico,

63

construa toda a relacao de alunos ingressantes numa planilha e submeta-a ao site. Ao

receber esta planilha, o sistema automaticamente executara a criacao de todos os alunos

no sistema, eliminando assim a criacao manual de usuarios. Ja no caso do upload do

professor, o formato esperado e a planilha que e extraıda do proprio sistema do IdUFF

com a relacao de alunos inscritos na disciplina. Isto permite que o professor possa, mes a

mes, atualizar sua propria lista de presenca, de modo que a necessidade da coordenacao

gerenciar estes dados seja eliminada.

7.2 Trabalhos Futuros

A primeira sugestao de trabalhos futuros e a remocao das limitacoes citadas no item

7.1. Eliminar a impossibilidade de um usuario ter mais de um tipo ou poder ter mais

de uma tupla na tabela de aluno ou professor que o referencie e fundamental para que

o sistema possa ter sucesso, uma vez que e possıvel que um usuario se forme, preste

os exames e entre novamente na faculdade. Nestes casos, o sistema precisara que uma

nova tupla seja inserida na tabela ALUNO sem a criacao de um novo usuario. No caso

do segundo problema, tambem e necessaria sua resolucao, uma vez que uma coordenacao

possui funcionarios que, na maioria das vezes, interagem com o sistema concorrentemente.

Se o sistema nao possibilitar esta concorrencia, o processo de interacao com o sistema sera

prejudicado, uma vez que este so permite uma sessao por usuario.

A proxima sugestao e a de oferecer a coordenacao uma forma de acompanhar a

frequencia de seus alunos nas suas respectivas turmas. Como este e um dado importante

para que algumas regras sejam cumpridas, a coordenacao precisaria ter acesso a essa

informacao, coisa que nao ocorre no sistema atual.

Alem disso, o ideal para um controle de frequencia mais efetivo, seria necessario

deixar de considerar a presenca pontual do aluno para medir a presenca de forma contınua,

ou seja, em vez de registrar a presenca em um momento especıfico, registar o momento

de entrada e saıda do aluno da sala de aula. Desta forma e possıvel diminuir o risco de

marcar a presenca ou falta de um aluno indevidamente.

Por fim, a ultima sugestao ao projeto e que seja implementada uma nova forma

de autenticacao, para agilizar ainda mais o processo de chamada. Desenvolvendo uma

aplicacao Mobile do e-Chamada para o aluno, cria-se uma infinidade de possibilidades com

64

as quais a autenticacao poderia ser realizada, alem da utilizacao de carteirinha. Realizar

a autenticacao utilizando WiFi Direct ou Bluetooth, por exemplo, possibilitaria a total

automatizacao do processo, uma vez que so seria necessario que os usuarios estivessem

autenticados nos seus respectivos aplicativos.

65

7.3 Consideracoes Finais

Este projeto teve como objetivo desenvolver um sistema que pudesse agregar valor ao

sistema de ensino. O foco do e-Chamada e tornar o processo de presenca mais rapido,

facil e seguro, reduzindo o trabalho do professor ao fazer a chamada, transformando o

preenchimento de varias folhas de papel ofıcio em um apertar de botao e garantindo a

ele mais tempo para que o mesmo possa dar sua aula normalmente. Alem disso, o sis-

tema retiraria do professor a responsabilidade de gerenciar diretamente a assiduidade de

seus alunos, ja que o e-Chamada controla a frequencia e as presencas todas automatica-

mente, fazendo com que o tempo do professor seja melhor gasto e retirando um pouco da

burocracia envolvida no processo de presenca.

O processo de informatizacao e algo constante, ja que a tecnologia faz parte do

cotidiano e, cada vez mais, vem se tornando indispensavel para a sociedade. Este projeto

e uma alternativa ao processo que existe atualmente, buscando fazer com que a tecnologia

possa ganhar espaco nas escolas e faculdades, para mostrar que e possıvel unir educacao

e tecnologia e que, a partir dessa combinacao, as aulas podem ser muito mais dinamicas

e proveitosas para todos.

67

Siglas

ACID Atomicity, Consistency, Isolation and Durability. 31, 32, 35

AVM Android Virtual Machine. 53

IDE Integrated Development Environment. 51

NFC Near Field Communication. 37

NoSQL Not Only SQL. 31, 32

SGBD Sistema de Gerenciamento de Banco de Dados. 27–31, 35

UFF Universidade Federal Fluminense. 2, 6, 37

Referencias Bibliograficas

[gol, 2009] (2009). The Go Programming Language. Disponıvel em: https://golang.org/.

[hib, 2016] (2016). Hibernate orm. Disponıvel em: http://hibernate.org/orm/.

[Cockroach, 2016] Cockroach (2016). Cockroach db.

[Dunston, 2016] Dunston, D. (2016). Openvpn: An introduc-

tion and interview with founder, james yonan. Disponıvel em:

http://www.linuxsecurity.com/content/view/117363/49/.

[Google, 2014] Google (2014). Google classroom. Disponıvel em:

https://support.google.com/edu/classroom/answer/6020279?hl=en.

[Gosling et al., 2013] Gosling, J., Joy, B., Steele, G., Bracha, G., and Buckley, A. (2013).

The Java R© Language Specification - Java SE 8 Edition. Oracle America, Inc. Dispo-

nıvel em: https://docs.oracle.com/javase/specs/jls/se8/jls8.pdf.

[Lobo, 2015] Lobo, A. d. P. (2015). Regulamento dos Cursos de

Graduacao da Univerisade Federal Fluminense, Resolucao CEP

001/2015. Disponıvel em: http://www.uff.br/sites/default/files/001-

2015 regulamento do curso de graduacao 0.pdf.

[MongoDB, Inc., 2016] MongoDB, Inc. (2016). Mongodb. Disponıvel em:

https://mongodb.com.

[NoSQL, 2016] NoSQL (2016). Guide to the non-relational universe. Disponıvel em:

http://nosql-database.org.

[Oracle, 2016] Oracle (2016). Mysql documentation. Disponıvel em:

http://dev.mysql.com/doc/.

68

69

[Piza, 2012] Piza, P. (2012). Riocard, bilhete Unico... saiba como

funcionam cartoes para pagar transportes. Disponıvel em:

http://www.techtudo.com.br/artigos/noticia/2012/07/riocard-bilhete-unico-saiba-

como-funcionam-cartoes-para-pagar-transportes.html.

[Tavares Ferreira, 2016] Tavares Ferreira, B. B. (2016). e-Chamada: Uma abordagem di-

gital para o controle de frequencia escolar. Trabalho de Conclusao de Curso (Graduacao

em Ciencia de Computacao), Departamento de Ciencia de Computacao, Universidade

Federal Fluminense.

[The OpenBSD Project, 2016] The OpenBSD Project (2016). OpenSSH. Disponıvel em:

https://www.openssh.com/.

[The PostgreSQL Global Development Group, 2016] The PostgreSQL Global Develop-

ment Group (2016). Postgresql.

[Venners, 2003] Venners, B. (2003). The making of python. Disponıvel em:

http://www.artima.com/intv/pythonP.html.

e-Chamada · 2018. 3. 14. · uso do NFC da Carteirinha da UFF. Desenvolvido utilizando a linguagem...

Documents

Transcript of e-Chamada · 2018. 3. 14. · uso do NFC da Carteirinha da UFF. Desenvolvido utilizando a linguagem...