PaginasWeb

O pacote de PaginasWeb ´e um dos dois pacotes que contˆem objetos que realmente geram algum tipo de resposta. Todos os pacotes, at´e o momento, eram de gerˆencia de erros interna, mapeamento, configura¸c˜ao ou manipula¸c˜ao de dados, por´em, este ´e primeiro pacote que possui conte´udo que gera respostas para os usu´arios. Este pacote cont´em objetos feitos em JSP que s˜ao respons´aveis pelo site web com o qual os usu´arios interagir˜ao ao longo do seu per´ıodo letivo.

JSP ´e uma tecnologia de Java lan¸cada em 1999 com o intuito de permitir a cria¸c˜ao de p´aginas web geradas dinamicamente. Um arquivo com extens˜ao .jsp ´e escrito nati- vamente em HTML, por´em esta tecnologia permite que haja a inser¸c˜ao de c´odigo Java dentro deste HTML, que ser´a processado e executado antes do envio da p´agina. Com essa liberdade, os desenvolvedores podem construir suas p´aginas combinando c´odigo Java e HTML, possibilitando a inser¸c˜ao de l´ogica de programa¸c˜ao no momento de constru¸c˜ao de uma p´agina, algo que, utilizando apenas HTML, ´e imposs´ıvel.

Esta tecnologia ´e traduzida, em tempo de execu¸c˜ao, em uma Servlet da aplica¸c˜ao, que tem como resposta uma p´agina HTML que ´e gerada de acordo com os dados recebidos de entrada. Cada JSP ´e traduzido em um Servlet que ficar´a armazenado em cache at´e que

48 o arquivo JSP seja reescrito, eliminando assim a necessidade de recompilar este arquivo a cada nova opera¸c˜ao, tornando esta tecnologia t˜ao 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 cont´em ar- quivos JSP que atendem a requisi¸c˜oes de usu´arios espec´ıficos dentro da aplica¸c˜ao, sendo cada JSP convertido em uma Serlvet e gerando uma p´agina dinamicamente no momento da requisi¸c˜ao. Por exemplo: Se um professor faz login na aplica¸c˜ao, ele ser´a redirecionado para a Servlet referente ao arquivo index.jsp dentro da pasta professor e esta gerar´a a p´agina dinamicamente, enviando-a como resultado para o usu´ario. Caso o coordenador fa¸ca login, ele ser´a redirecionado para a Servlet referente ao arquivo index.jsp dentro da pasta coordenacao, que repetir´a o mesmo processo. Vale ressaltar que cada tipo de usu´ario n˜ao pode acessar p´aginas que s˜ao geradas para outros tipos, ficando limitado a acessar os dados que lhe s˜ao conferidos em suas interfaces.

5.2.7

WebServlet

Por fim, o ´ultimo pacote do sistema ´e o pacote WebServlet. Este pacote ´e respons´avel por criar objetos que responder˜ao a requisi¸c˜oes tanto do site quanto das aplica¸c˜oes Mobile.

A tecnologia utilizada para que esta resposta fosse processada foram as Servlets, que s˜ao nativas do Java. Uma Servlet ´e uma classe Java que possibilita ao programa estender as funcionalidades de um servidor, ou seja, atrav´es da Servlet, o c´odigo Java pode se comunicar com a rede utilizando o protocolo HTTP, atrav´es de qualquer um dos 9 m´etodos de requisi¸c˜ao. A vantagem de se utilizar Servlets ´e, acima de tudo, a praticidade e a liberdade que seu uso confere. Uma Servlet responde a requisi¸c˜oes HTML, por´em ela pode gerar como resposta qualquer tipo de arquivo, desde uma p´agina HTML a um JSON ou uma foto. No geral, as respostas geradas pela Servlet s˜ao do tipo JSON, por´em existe uma Servlet que retorna uma imagem como resposta. JSON ´e um forma f´acil e simples de transmitir dados entre duas aplica¸c˜oes ou em uma aplica¸c˜ao 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 informa¸c˜ao transitadas.

¸c˜oes do site, uma vez que, atrav´es de JavaScript, podemos criar requisi¸c˜oes ass´ıncronas e o tempo de processamento e entrega da p´agina n˜ao ´e afetado pelo resultado da Servlet. Em outras palavas, o site pode, atrav´es de JavaScript, delegar um processamento mais pe- sado para a aplica¸c˜ao atrav´es de uma Servlet e ficar aguardando a resposta, sem que seja necess´ario que a p´agina do usu´ario seja recarregada ou que o mesmo seja redirecionado.

Dentre as 18(dezoito) servlets que est˜ao, atualmente, no sistema, foram seleciona- das as 5 principais para serem explicadas, j´a que elas s˜ao as mais utilizadas pelo sistema: • A primeira Servlet ´e chamada de Login, e ´e a Servlet que recebe requisi¸c˜oes de todos os aplicativos Mobile, realiza o login deles no sistema e retorna um tokenWeb v´alido para o sistema. Ela recebe os dados de um usu´ario inseridos na tela do aplicativo, faz a valida¸c˜ao de usu´ario e senha, gera o tokenMobile daquela sess˜ao e envia um JSON atrav´es da rede para o dispositivo, que autoriza o login e segue para a pr´oxima tela.

• A pr´oxima Servlet ´e a Servlet de presen¸ca. Apesar de existir uma p´agina de aula onde o professor pode modificar o estado de um aluno, esta p´agina, por si s´o n˜ao poderia processar este tipo de a¸c˜ao, ent˜ao, por isso, a Servlet atua como um suporte, dando a possibilidade desta a¸c˜ao ser executada. Quando o professor clica no bot˜ao para mudar o estado de um aluno, o JavaScript gera uma requisi¸c˜ao ass´ıncrona para a servlet de presen¸ca que recebe os dados do professor, da turma e do aluno ao qual a presenta est´a sendo alterada, bem como o token gerado para aquele professor naquela se¸c˜ao. A integridade da se¸c˜ao ´e validada, assim como a existˆencia do aluno, se o mesmo est´a 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 atrav´es da DAO correspondente e ´e criado um JSON de resposta dizendo que a al- tera¸c˜ao foi bem sucedida. Caso algum teste n˜ao seja bem sucedido ou haja alguma falha no processo de salvamento, tamb´em ´e gerado um JSON com uma informa¸c˜ao, notificando qual a falha correspondente.

• A terceira Servlet selecionada ´e a Servlet chamada Foto. Esta Servlet ´e utilizada para atender a requisi¸c˜oes que recebam o id de um determinado usu´ario e, a partir dele, retorne a foto que corresponde `aquele usu´ario. Esta Servlet ´e utilizada em todas as telas que possuem fotos do usu´ario, mas seu maior exemplo de utiliza¸c˜ao

50 ´

e na tela inicial da Coordena¸c˜ao: Para cada imagem que ´e carregada de um aluno, uma requisi¸c˜ao ass´ıncrona ´e submetida para esta Servlet, que retorna a imagem correspondente ao aluno. Caso as imagens fossem processadas no momento da cons- tru¸c˜ao da p´agina, o tempo de resposta seria t˜ao lento que a conex˜ao se encerraria por time-out, uma vez que a quantidade de fotos a serem processadas ´e t˜ao grande quanto a quantidade de alunos de uma coordena¸c˜ao. O isolamento desta funcio- nalidade numa Servlet permite que o usu´ario receba a p´agina gerada rapidamente, carregando as fotos ap´os o carregamento da p´agina.

• A Servlet selecionada neste t´opico ´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 cria¸c˜ao, edi¸c˜ao ou exclus˜ao de uma turma do sistema. Utilizando requisi¸c˜oes do tipo POST, PUT e DELETE, a mesma Servlet ´e capaz de realizar 3(trˆes) opera¸c˜oes diferentes sobre os dados. Atrav´es da requisi¸c˜ao do tipo POST, o sistema realiza a inser¸c˜ao de uma turma, utilizando os dados en- viados pelo front e retornando um JSON informando o sucesso ou fracasso daquela opera¸c˜ao. No caso da requisi¸c˜ao do tipo PUT, ela ´e utilizada no momento em que ´

e necess´ario editar uma turma, funcionando no mesmo padr˜ao da requisi¸c˜ao POST: recebendo os dados modificados como entrada e respondendo com um JSON infor- mando o sucesso ou fracasso da opera¸c˜ao. Por fim, a requisi¸c˜ao do tipo DELETE ´

e utilizada para excluir uma turma do sistema permanentemente. Ela recebe como parˆametro o id da turma e realiza a exclus˜ao, tamb´em retornando um JSON como resposta para o front.

• Por fim, a ´ultima Servlet selecionada ´e a Servlet Di´ario. 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 n˜ao inscrito). O front recebe como entrada uma planilha excel extra´ıda diretamente do IdUFF e realiza um pr´e-processamento nela, extraindo apenas os dados aproveitados e os envia ao backend. No backend, a aplica¸c˜ao faz a altera¸c˜ao no estado dos alunos, trancando os que est˜ao como inscritos mas n˜ao apareceram na lista recebida e inscrevendo os que n˜ao estavam inscritos mas foram recebidos na lista. Vale ressaltar que esta Servlet precisa receber as planilhas sequencialmente

ordenada por mˆes de emiss˜ao, uma vez que a inser¸c˜ao de dados em ordem aleat´oria poder´a causar inconsistˆencias no que foi gerado.

A partir destes 5 (cinco) exemplos, foi poss´ıvel perceber o qu˜ao ´util e qu˜ao 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 programa¸c˜ao Java, que ´e a linguagem de programa¸c˜ao 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 aplica¸c˜ao web atrav´es das Servlets, que s˜ao respons´aveis pela integra¸c˜ao entre os diferentes componentes do sistema. Na comunica- ¸c˜ao entre o aplicativo e a aplica¸c˜ao web, ´e utilizado o protocolo HTTPS, que garante a seguran¸ca das informa¸c˜oes transferidas.

Considerando a importˆancia 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 n˜ao pode ser um impedimento para o seu funcionamento, pois atrapalharia a dinˆamica da aula e poderia prejudicar os nossos usu´arios em vez de ajud´a-los. Portanto, no momento do login, o aplicativo, ap´os a valida¸c˜ao das credenciais fornecidas pelo usu´ario, salva todas as informa¸c˜oes necess´arias para o seu funcionamento em um banco de dados local no dispositivo e garante que mesmo sem acesso `a internet, o professor poder´a confiar no e-Chamada para fazer a chamada durante a aula.

5.3.1

Banco de Dados

Localmente, as informa¸c˜oes do aplicativo s˜ao salvas em um banco de dados SQLite, que ´e um banco de dados relacional salvo em um arquivo e oferece uma biblioteca de progra- ma¸c˜ao para a aplica¸c˜ao. O SQLite fornece `a aplica¸c˜ao uma vis˜ao semelhante a um SGBD tradicional e tamb´em ´e compat´ıvel com a linguagem SQL.

52 Diferentemente do banco de dados do servidor, o banco de dados do aplicativo guarda apenas as informa¸c˜oes necess´arias para o seu funcionamento, que ser´a, em geral, um subconjunto do banco de dados do servidor e possui 10 tabelas, como ilustrado na figura 5.4.

5.3.2

Organiza¸c˜ao do C´odigo

Uma vez que o aplicativo foi escrito na linguagem de programa¸c˜ao Java, que ´e uma linguagem orientada a objetos, todo o c´odigo fonte do projeto est´a em classes. As classes, por sua vez, est˜ao organizadas divididas em pacotes. Exstem trˆes pacotes principais, s˜ao eles: Ctrl, Model e Database.

5.3.2.1 Pacote Ctrl

Neste pacote est˜ao as classes com os componentes que contˆem a interface do usu´ario. Ma- joritariamente, o componente utilizado para a cria¸c˜ao da interface ´e chamado Atividade. Este componente representa uma tela do aplicativo. Existem trˆes Atividades principais neste aplicativo:

• LoginActivity: a tela de login do aplicativo ´e a primeira tela que o usu´ario vˆe quando abre o aplicativo e esta pede as credenciais do usu´ario (email e senha) para autentic´a-lo no sistema.

• ProfessorActivity: ´e a principal tela do aplicativo que o professor vˆe ap´os 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 presen¸ca e pode marcar a presen¸ca dos seus alunos (manualmente ou atrav´es do sensor NFC com as carteiri- nhas).

5.3.2.2 Pacote Model e Pacote Database

O pacote Model cont´em as classes com a modelagem do sistema e o pacote database ´e respons´avel pela comunica¸c˜ao do aplicativo com o banco de dados local SQLite. Nestes pacotes est˜ao implementadas todas as funcionalidades especificadas. Estes pacotes est˜ao diretamente relacionados, uma vez que todas as tabelas do banco est˜ao mapeadas na aplica¸c˜ao.

5.3.3

Manifesto

O Manifesto ´e um arquivo xml (AndroidManifest.xml) onde est˜ao todas as informa¸c˜oes do aplicativo que a Android Virtual Machine precisa para executar o aplicativo corretamente. As principais informa¸c˜oes que este arquivo cont´em s˜ao:

• Vers˜ao: o c´odigo da vers˜ao do aplicativo (vers˜ao 1, vers˜ao 2, ...).

• Permiss˜oes: as permiss˜oes que o usu´ario precisa conceder para que o aplicativo funcione (acesso `a internet, acesso ao armazenamento, acesso ao sensor NFC, ...). • SDK: as vers˜oes do Android necess´arias para a execu¸c˜ao do aplica¸c˜ao, no caso deste

aplicativo, a vers˜ao m´ınima ´e a 4.2.

• Atividades: as atividades do aplicativo (que est˜ao implementadas no pacote Ctrl), bem como informa¸c˜oes de qual a atividade principal que a AVM deve abrir quando come¸car a execu¸c˜ao 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 tˆem uma peculiaridade pois devem estar em diferentes resolu¸c˜oes para serem exibidas adequadamente em dispositivos com diferentes tamanhos e resolu¸c˜oes de tela.

5.4

Aplicativo da Coordena¸c˜ao

O aplicativo da coordena¸c˜ao foi desenvolvido utilizando as mesmas ferramentas e seguindo a mesma l´ogica e estrutura (organiza¸c˜ao de c´odigo, manifesto e recursos) do aplicativo do professor. Este aplicativo permite que a coordena¸c˜ao 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, n˜ao h´a a necessidade de cache local das informa¸c˜oes para o funcionamento offline.

5.4.1

Atividades

54 • LoginActivity: a tela de login do aplicativo ´e a primeira tela que o usu´ario vˆe quando abre o aplicativo e esta tamb´em pede as credenciais do usu´ario (e-mail e senha) para autentic´a-lo no sistema, como no aplicativo do professor.

• MainActivity: ´e a principal tela do aplicativo que o usu´ario vˆe ap´os se autenticar na tela de login, esta tela lista os alunos cadastrados na coordena¸c˜ao e permite o cadastro de um novo aluno.

• AlunoDetailActivity: esta tela mostra todas as informa¸c˜oes de um aluno e permite que a coordena¸c˜ao edite as informa¸c˜oes, bem como o uso do sensor NFC para a leitura da carteirinha.

5.5

Resumo do Cap´ıtulo

Neste cap´ıtulo est˜ao as informa¸c˜oes sobre a estrutura e desenvolvimento dos diferentes componentes do e-Chamada desde o Banco de Dados do servidor, Aplica¸c˜ao Web aos aplicativos mobile da Coordena¸c˜ao e do Professor, bem como seu banco de dados local para o cache de informa¸c˜oes.

56

Cap´ıtulo 6

Implanta¸c˜ao do Sistema

Os cap´ıtulos anteriores citaram as tecnologias usadas no desenvolvimento do sistema e tamb´em descreveram a forma como ele foi implementado. Este cap´ıtulo descrever´a a infraestrutura necess´aria 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 distribui¸c˜ao do Linux de c´odigo 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 est´avel, teve bom desempe- nho e n˜ao apresentou nenhum travamento nem provocou nenhuma indisponibilidade ao sistema decorrente de erros. Al´em disso, o CentOS conta com o gerenciador de pacotes RPM que facilita a instala¸c˜ao 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 reposit´orios online de forma f´acil e r´apida.

6.1.2

Secure Shell (SSH)

[The OpenBSD Project, 2016]

SSH ´e um protocolo de rede criptogr´afico que permite o login e a execu¸c˜ao de linhas de

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 al´em de implementarem o protocolo SSH para a execu¸c˜ao de linhas de comando, implementam o protocolo SFTP que possibilita a transferˆencia segura de arquivos. O uso do SSH, combinado com o VPN, permitiu a configura¸c˜ao e manuten¸c˜ao do servidor remotamente de forma segura mesmo pela internet.