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
3.3 Resumo do capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
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.3.7 Tecnologia Selecionada . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.3 Tecnologia Selecionada . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Resumo do capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Arquitetura do Sistema 39
5.1 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 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.
3.3 Resumo do capıtulo
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.
4.3.7 Tecnologia Selecionada
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.
4.4.3 Tecnologia Selecionada
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.
4.6 Resumo do capıtulo
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.
66
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.