MongoDB

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

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

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

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

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

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

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

4.3.6

CockroachDB

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

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

SQL Sim N˜ao Sim

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

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

entre os n´os restantes que possuem a maior capacidade, de forma que haja um equil´ıbrio de utiliza¸c˜ao entre todos os n´os do cluster.

Por conta de seu funcionamento e de sua escalabilidade, o CockroachBD atente com satisfa¸c˜ao aos pontos 2 (dois), 3 (trˆes) e 4 (quatro). Ao armazenar os dados oferecendo um interface de um modelo relacional, o Cockroach est´a garantindo as propriedades ACID, o que possibilita ao banco garantir a integridade dos dados e, por ser capaz de criar n´os sob demanda e redistribuir seus dados dentre esses n´os, isso torna o banco capaz de atender a crescente demanda que o sistema teria, tanto de conex˜oes simultˆaneas de usu´arios como de gerˆencia da massa de dados.

Outro ponto importante ´e que o Cockroach tem vers˜ao desenvolvida para Linux, o que o torna completamente compat´ıvel com o CentOS e, apesar de possuir um esquema de organiza¸c˜ao dos dados de forma n˜ao-relacional, a interface relacional oferecida pelo Coc- kroach ´e compat´ıvel com todos os drivers feitos para PostgreSQL, tornando-o compat´ıvel tamb´em 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, ent˜ao n˜ao seria prudente arriscar e coloc´a-lo em uma aplica¸c˜ao que lida com dados sens´ıveis, pois ainda h´a o risco de perda de informa¸c˜oes e isto seria algo muito ruim para o e-Chamada.

4.3.7

Tecnologia Selecionada

Dentre as 5 (cinco) op¸c˜oes, os que mais chamaram a aten¸c˜ao por seus resultados foram o MySQL, o PostreSQL, o MongoDB e o CockroachDB. A primeira op¸c˜ao seria o Coc- kroachDB, pois, por ele unir o melhor dos dois lados, ele resolveria todos os problemas propostos de uma forma considerada ´otima. Por´em, o que pesou contra ele e acarretou na decis˜ao de o mesmo n˜ao ser escolhido foi que ele est´a em Testes Alpha, ou seja, n˜ao se tem uma vers˜ao est´avel do sistema na qual se possa rodar e, com uma aplica¸c˜ao como o e-Chamada, ´e necess´ario um banco que seja est´avel, coisa que o Cockroach, atualmente, n˜ao ´e.

Apesar da escalabilidade, a possibilidade de existir inconsistˆencias fez com que o Mongo tamb´em fosse descartado, pois para a nossa aplica¸c˜ao, acarretaria num aumento da complexidade de c´odigo desenvolvido em Java de forma a garantir a elimina¸c˜ao de certas ambiguidades que os SGBDs relacionais j´a 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 hist´orico de trabalho com a ferramenta, o que acarretaria num ganho de tempo, que seria investido treinando o time para lidar com o PostgreSQL, j´a que ningu´em anteriormente havia trabalhado com essa ferramenta.

4.4

Mobile

Esta se¸c˜ao fala das principais tecnologias dispon´ıveis para o desenvolvimento de aplicativos em dispositivos m´oveis 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, atr´as apenas do Android. ´E um sistema extremamente fechado para modifica¸c˜oes e desenvolvimento de aplica¸c˜oes, sendo necess´ario um registro junto `a Apple para a instala¸c˜ao de aplicativos em dispositivos f´ısicos.

A linguagem de programa¸c˜ao utilizada no desenvolvimento de aplica¸c˜oes no iOS ´e o Objective-C, uma linguagem n˜ao 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 v´arias facilidades no desenvolvimento de novas aplica¸c˜oes, como por exemplo as APIs que facilitam o uso de tecnologias NFC e Bluetooth. Al´em disso, n˜ao ´e necess´ario nenhum tipo de registro nem pagamento de licen¸ca para o desenvolvimento neste ambiente, deixando o processo de cria¸c˜ao de novos aplicativos livre e desburocrati- zado.

Os aplicativos no Android s˜ao desenvolvidos na linguagem de programa¸c˜ao Java, que ´e muito popular e permite a reutiliza¸c˜ao de c´odigo de outros componentes do sistema

e-Chamada, que tamb´em s˜ao escritos em Java.

4.4.3

Tecnologia Selecionada

Devido ao elevado n´umero de aparelhos especialmente no Brasil, onde o Android est´a 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 n˜ao permite que aplica¸c˜oes de terceiros utilize a tecnologia NFC dos aparelhos. Al´em disso, com o grande uso do Android no Brasil, ´e o sistema operacional que nos garante o maior n´umero de usu´arios atingidos pelo nosso sistema.

4.5

NFC

O NFC (Near Field Communication), ´e uma tecnologia de comunica¸c˜ao de curt´ıssimo alcance, onde os componentes NFC precisam praticamente se tocar para que a comuni- ca¸c˜ao ocorra. Pode ser utilizada de forma semelhante ao Bluetooth na comunica¸c˜ao de dois aparelhos pr´oximos (peer to peer) para transferˆencia de arquivos ou outros fluxos de dados ou pode ser usado como leitor/escritor de tags. Al´em 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 n˜ao necessitam de fontes de energia como fios ou baterias.

Esta modalidade de uso com tags se destaca pela facilidade de uso e pela ampla aplica¸c˜ao em sistemas de bilhetagem eletrˆonica em sistemas de transporte p´ublico e em novas tecnologias de pagamento contactless. Em ambos os casos s˜ao utilizados cart˜oes que s˜ao tags NFC e um aparelho leitor de NFC, como os validadores dos ˆonibus e esta¸c˜oes ou as maquininhas de cart˜ao de cr´edito para pagamentos contactless.

O uso do NFC em sistemas de pagamento se tornou t˜ao confi´avel que nos permitiu utiliz´a-lo na identifica¸c˜ao para validar a presen¸ca deste na sala de aula. O processo ´e facilitado pelo fato de que grande parte dos smartphones s˜ao compat´ıveis com a tecnologia e todos os alunos de institui¸c˜oes de ensino como a Universidade Federal Fluminense j´a possuem carteirinhas fornecidas pela universidade compat´ıveis com o NFC. Todos estes fatores nos permitiram utilizar o NFC com confian¸ca 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 pr´oximo cap´ıtulo, ser´a 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 implementa¸c˜ao deste projeto. Al´em disso, apresentou uma breve discuss˜ao que justificava a escolha de uma determinada tecnologia em detrimento das demais apresentadas.

Este cap´ıtulo consiste em descrever a elabora¸c˜ao e implementa¸c˜ao do banco de dados e do sistema, detalhando como o sistema est´a projetado a n´ıvel de c´odigo e como ´e feita toda a parte de gerˆencia e controle de informa¸c˜oes do sistema. Al´em disso, ser´a 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 gr´afica da empresa Oracle Corporation para trabalhar com servidores e bancos de dados. Esta ferramenta oferece uma interface f´acil e pr´atica para que os usu´arios possam interagir diretamente com o banco de dados, sendo poss´ıvel manipular conex˜oes com seus servidores, realizar modelagens gr´aficas, desenvolver atrav´es de SQL, realizar backups dos bancos, monitorar o desempenho dos bancos, entre outras funcionalidades.

O MySQL Workbench tamb´em oferece um sistema de controle de permiss˜oes, onde ´e poss´ıvel criar diversos usu´arios e dar a cada um deles diferentes n´ıveis de acesso a cada uma das bases. Os tipos de permiss˜oes poss´ıveis de se conceder ou revogar a um usu´ario sobre um determinado Schema de banco de dados no MySQL Workbench s˜ao:

• Direitos sobre um objeto: Este tipo de permiss˜ao determina qual o n´ıvel da capaci- 39

40 dade de um usu´ario em manipular os dados contidos naquela base. Estas permiss˜oes se dividem em: DELETE, que permite a remo¸c˜ao de tuplas da base; INSERT, que permite a inser¸c˜ao de dados na base; SELECT, que permite a consulta de dados na base; e UPDATE, que permite a edi¸c˜ao de dados na base.

• Direitos sobre DLL: Este tipo de permiss˜ao determina quais tipos de comandos SQL aquele usu´ario est´a autorizado a executar naquela base. Estes comandos se dividem em: ALTER e ALTER ROUTINE, que permitem ao usu´ario editar tabelas e rotinas, respectivamente; CREATE TABLE, CREATE VIEW e CREATE ROUTINE, que permitem ao usu´ario criar, respectivamente, tabelas, views e rotinas; INDEX, que permite ao usu´ario criar ´ındices em tabelas; REFERENCES, que permite ao usu´ario criar chaves estrangeiras; TRIGGER, que permite ao usu´ario a cria¸c˜ao de Triggers utilizando PLSQL.

• Outros direitos: S˜ao permiss˜oes diversas, que v˜ao de concess˜ao de permiss˜ao a lock de tabelas. Estas permiss˜oes se dividem em: GRANT OPTIION, que permite ao usu´ario conceder as mesmas permiss˜oes que ele possui para outro usu´ario; CRE- ATE TEMPORARY TABLE, que permite ao usu´ario criar tabelas tempor´arias no sistema; LOCK TABLES, que permite ao usu´ario dar um lock em tabelas sobre as quais ele tem permiss˜ao de SELECT, ou seja, permite ao usu´ario, explicitamente, impedir que uma tabela seja utilizada por outros usu´arios em paralelo.

Al´em 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.

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 respons´avel por armazenar informa¸c˜oes pertinentes a todos os usu´arios do sistema, como login, senha e tokens de usu´ario, por exemplo. O conceito de token foi utilizado da seguinte forma: O usu´ario se autenticar´a no sistema utilizando sua senha padr˜ao e, ap´os a aplica¸c˜ao confirmar a autenticidade do usu´ario, ela gerar´a um token aleat´orio de 32 caracteres e armazenar´a nesta tabela. Se o login foi feito atrav´es do site, o token ´e armazenado na coluna tokenWeb ou se o login foi feito atrav´es de um dos dispositivos mobile, o token ´e armazenado na coluna tokenMobile. A partir deste momento, toda itera¸c˜ao do usu´ario ´e validada a partir do token, protegendo a senha do usu´ario, que n˜ao ser´a trafegada em cada requisi¸c˜ao feita ao servidor. Esta estrat´egia

42 permite, ainda, que o usu´ario possa ficar conectado simultaneamente no site e na aplica¸c˜ao mobile, por´em este token s´o permitir´a que o usu´ario tenha apenas uma sess˜ao por vez. Caso o usu´ario esteja conectado no site em uma m´aquina e o mesmo tentar se conectar no site atrav´es de outra m´aquina, um novo token ser´a gerado e as requisi¸c˜oes feitas a partir da m´aquina antiga ser˜ao rejeitadas.

Al´em disso, a pr´opria tabela USUARIO ´e utilizada para mapear uma heran¸ca. Esta tabela ´e a tabela principal, que armazena todas as informa¸c˜oes pertinentes a todos os usu´arios 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 usu´ario se autentique no sistema sem que seja necess´ario acessar nenhuma das outras tabelas, buscando a senha de cada usu´ario. Al´em disso, a tabela USUARIO possui uma coluna chamada tipo, que armazena a informa¸c˜ao de qual tipo aquele usu´ario ´e. Isto facilita bastante o acesso, n˜ao se fazendo necess´ario consultar as quatro tabelas tamb´em no momento em que uma requisi¸c˜ao acessa os dados espec´ıficos de um tipo usu´ario.

Em seguida, temos a tabela TURMA, que ´e respons´avel por armazenar os dados de cada turma que j´a foi cadastrada no sistema, como seu ano, per´ıodo, e chave artificial (atributo conhecido como idTurma). Al´em disso, esta tabela possui chaves estrangeiras para as tabelas PROFESSOR e MATERIA, nos quais s˜ao armazenados qual o professor leciona ou lecionou naquela turma e de qual disciplina aquela turma ´e, respectivamente. Atrav´es da tabela CURSA, o banco ´e capaz de armazenar quais alunos j´a possu´ıram algum tipo de rela¸c˜ao 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 inscri¸c˜ao. Para fins hist´oricos, este ´e um tipo de dado que n˜ao pode ser perdido, ent˜ao para isso, existe um atributo chamado inscrito, que armazena o estado daquele aluno naquela turma. Al´em disso, esta tabela armazena a frequˆencia 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 informa¸c˜oes necess´arias sobre uma turma, foi criada a tabela COORDENACAO TURMA, que armazena a informa¸c˜ao sobre qual turma est´a dispon´ıvel para quais coordena¸c˜oes. Al´em disso, esta tabela tamb´em armazena a quanti- dade de vagas que esta coordena¸c˜ao tem direito naquela turma.

Para armazenar as informa¸c˜oes pertinentes `as presen¸cas dos alunos, foram criadas duas tabelas: LISTA PRESENCA e ALUNO PRESENCA. A tabela LISTA PRESENCA ´e respons´avel por armazenar todas as aulas ministradas por um professor em uma turma. Ela cont´em uma chave estrangeira referenciando a turma `a qual essa lista pertence, al´em 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, j´a que o sistema armazena apenas uma lista por aula. J´a a tabela de ALUNO PRESEN ¸CA ´e respons´avel por armazenar a presen¸ca individual de cada aluno em uma determinada lista de presen¸ca. Para isso, ela conta com duas chaves estrangeiras que referenciam as tabelas de ALUNO e LISTA PRESENCA, al´em de dispor de mais 4(quatro) campos: situacao,