Estrutura

Para tal, arquitetamos uma estrutura que conseguisse suprir todos os requisitos, contendo uma ferramenta de extração de dados (ETL) transportando os dados dos sistemas ativos

CAPÍTULO 4.ANÁLISE E DISCUSSÃO DE RESULTADOS

33

no IPB em bancos de dados Oracle e transformando-os em documentos do MongoDB, e uma aplicação Web que conseguisse traduzir os resultados em uma interface amigável com níveis de acesso entre escolas e cursos. Para entender melhor a organização estrutural projetada para esta ferramenta, desenvolvemos o diagrama da Figura 7.

Figura 7: Diagrama da estrutura da ferramenta

Como podemos notar pela Figura 7, a ferramenta ETL é responsável por três das quatros ações principais desta estrutura (representadas pelas setas), sendo a primeira ação (1) efetuar a extração dos dados dos sistemas do IPB, a segunda (2) é transportar para o MongoDB, já com os dados em formato correto para classificação e por último, a terceira ação (3) é notificar a aplicação Web que os dados foram transportados e estão aptos a serem utilizados. Por sua vez a aplicação Web termina nosso ciclo de tarefas com a quarta ação (4), na qual deve-se verificar os dados fornecido pela ferramenta ETL e aplicar o modelo, calculando no final os novos atributos.

O principal motivo de não executarmos todas as ações na aplicação Web, é a segurança dos dados. Na estrutura proposta, conseguimos instalar nos servidores do IPB, a ferramenta ETL em uma máquina que não concede acesso por meios externos, com privilégios de leitura aos sistema ativos, sendo capaz de extrair e processar esses dados sem informações pessoais dos alunos e transportar para o MongoDB, no qual a aplicação Web já possui acesso, garantindo que agentes maliciosos não acessem os servidores ativos no IPB.

CAPÍTULO 3.DESENVOLVIMENTO

34

3.6.2. ETL

Ferramentas ETL são softwares responsáveis por efetuar extrações de fontes operacionais heterogêneas de dados, transformá-los, aplicando conversões, associações, limpeza, entre outras técnicas, e carregá-los em outro sistema, normalmente em Data Warehouses. As etapas deste software devem ser bem estruturadas e auditáveis, pois, são consideradas peças chaves para o sucesso da aplicação final [46].

Partindo do pressuposto que iremos aplicar inicialmente esta ferramenta apenas ao IPB, iremos integrar unicamente com banco de dados Oracle. Assim como os dados fornecidos, trabalharemos com três conjunto de dados providos de três sistemas distintos, o LMS, sistema de notas, dados demográficos e sistema de presenças. O código desenvolvido para a extração de dados foi baseado no estudo descrito como pré- processamento (capítulo 3.3), porém ao invés de agregações em MongoDB, tivemos que lidar com os relacionamentos do modelo relacional e efetuamos as contagens necessárias entre intervalos de datas.

Apesar de serem volumosos e de fontes distintas os dados que pretendemos extrair, como o intervalo de datas é pequeno, sempre de uma semana, o Oracle foi capaz de retornar todos os dados em apenas uma query, porém alguns atributos desejáveis ainda necessitaram de transformações antes de serem enviados ao MongoDB.

A aplicação ETL foi escrita como um script em Python, necessitando de apenas três bibliotecas como requisito, cx_Oracle, pymongo e requests, sendo respectivamente, a biblioteca responsável por fazer a ligação com o Oracle, a biblioteca responsável por fazer a ligação com o MongoDB e a biblioteca responsável por efetuar requisições online, como o método POST para a aplicação online, anunciando o fim da extração.

Instalamos a ferramenta em um servidor Linux e agendamos através do serviço cron, uma tarefa de executar nosso script todas as segundas feiras a 01:00 AM, período no qual tende a ter menos usuários ativos no sistema, caso o processo cause lentidão. Para a auditoria da ferramenta, a aplicação produz logs em um arquivo a cada início de atividade, como inicialização do script, acesso ao banco de dados e requisição da aplicação Web, além disso, é enviado ao MongoDB informações de cada coleta quando termina o processo.

CAPÍTULO 4.ANÁLISE E DISCUSSÃO DE RESULTADOS

35

3.6.3. Aplicação Web

Considerando a expansão dos múltiplos dispositivos nos últimos anos e os avanços tecnológicos dos sistemas operacionais móveis, a escolha de uma aplicação online, acessível por múltiplos ambientes se fez evidente. Apesar dos aplicativos móveis ganharem um volume considerável e serem recomendado para diversos casos, neste projeto optamos por desenvolver um web site, no qual também consegue ser acessível por smartphones e possui uma visualização dos elementos melhor em desktops, por exemplo, os gráficos e as tabelas, que perdem detalhes quando muito reduzidos.

A linguagem para o desenvolvimento da aplicação também foi o Python, devido a economia de tempo que conseguimos mantendo os códigos desenvolvidos para o modelo, visto que tínhamos a certeza que responderiam exatamente igual no mesmo ambiente. Além disto, Python também oferece ótimas soluções web, como o Framework Flask escolhido para este projeto. Inicialmente comparamos o Flask com o Framework Django, porém apesar de eficiente e de fácil aprendizagem, com diversos módulos pré-instalados que normalmente facilitam o desenvolvedor, para nós não tinha muita utilidade, aumentando a complexidade do projeto sem necessidade.

Entretanto, como já descrito, Flask é um microframework, no qual não requer um paradigma de programação específico ou uma determinada estrutura de arquivos, sendo possível desenvolver um servidor completo em apenas um arquivo de forma procedural, porém como desejamos produzir um código de fácil entendimento, habilitando outros desenvolvedores a aplicar manutenções e melhorias, é necessário a utilização de padrões de projeto e de arquitetura.

3.6.3.1. Estrutura de arquivos

Para a estrutura do projeto escolhemos o padrão Model-View-Controller (MVC), devido a sua capacidade de manter o código organizado e enxuto, permitindo de forma simples a reciclagem do mesmo sem dificuldade e com segurança. A arquitetura MVC tem o objetivo de separar a lógica do sistema e a interface do usuário, para isto, é sugerido a divisão do software em três componentes Modelo, Visão e Controle. Podemos definir a camada Modelo como a componente responsável de se comunicar com o armazenamento dos dados e trabalha na manipulação dos dados internos. A componente Visão, também

CAPÍTULO 3.DESENVOLVIMENTO

36

conhecida como apresentação, é responsável por capturar as ações do usuário e fornecer a interface da aplicação. Por fim, a camada Controle é responsável por controlar o fluxo entre as camadas, executar as funcionalidade que envolvem o comportamento da aplicação e gerar as respostas aos usuários [47].

A partir disso, iniciamos a aplicação organizando os arquivos com base na arquitetura MVC, dividindo-os em subpastas que representam diferentes componentes e criamos os arquivos de configuração e os arquivos básicos de cada camada. Para melhorar o entendimento desta hierarquia, desenvolvemos a Listagem 1.

Listagem 1: Estrutura básica da aplicação WEB. 1 config.py 2 index.py 3 app/ 4 ├─── __init__.py 5 ├─── controllers/ 6 │ ├─── users.py 7 │ └─── __init__.py 8 ├─── forms/ 9 │ └─── user.py 10 ├─── models/ 11 │ ├─── base.py 12 │ └─── user.py 13 ├─── static/ 14 │ ├─── css/ 15 │ └─── js/ 16 │ └─── imgs/ 17 └─── templates/ 18 ├─── error.html 19 ├─── login.html 20 ├─── layout.html 21 └─── users/

Como podemos notar na Listagem 1, na linha 1 e 2 possui dois arquivos fora da pasta principal (app), estes arquivos são de inicialização da aplicação. O primeiro config.py é responsável por armazenar as configurações do banco de dados, diretório do projeto, chave secreta2_{, informações da aplicação, e-mails e níveis de acesso. Já o segundo arquivo} index.py, é responsável pela chamada de ligação com a pasta principal, normalmente separamos estes dois arquivos da pasta principal quando se possui mais de um serviço associado, conseguindo inicializar e configurá-los juntos, porém apesar de termos apenas um serviço, mantemos esta separação por questão de organização.

CAPÍTULO 4.ANÁLISE E DISCUSSÃO DE RESULTADOS

37

Na pasta app, possui apenas um arquivo chamado __init___.py (linha 4), este documento é responsável por três questões fundamentais da aplicação. A primeira é importar as bibliotecas base para aplicação, sendo as duas principais, o próprio Framework Flask e a biblioteca de ligação com o MongoDB, chamada Mongo Engine. A segunda é instanciar e interligar estas bibliotecas com as configurações pré-definidas no arquivo config.py. Por último, este arquivo também é responsável por criar variáveis, objetos e funções globais, como variáveis da semana e do ano letivo, objeto do banco de dados, funções de rota para erros, entre outros. Podemos considerar que este é o arquivo base da aplicação, pois após sua chamada o servidor já está configurado e funcionando, porém, não possui nenhuma rota além das páginas de erro (403, 404, 405 e 500).

Para a camada Controle da arquitetura MVC, reservamos a pasta controllers (linha 5), na qual irá conter múltiplos arquivos divididos por conjunto de rotas que desejamos criar, a nomenclatura destes arquivos devem ser em plural, como exemplo, na Listagem 1 na linha 6, temos o arquivo users.py, nele são encontrados todas as rotas referente aos usuários do sistema, incluindo o CRUD, login, logout, recuperação de senha entre outros. Como todas as rotas precisam estar ativas na inicialização da aplicação, a pasta controllers é importada pelo arquivo base do projeto e através do arquivo de inicialização da pasta controllers (linha 7) os arquivos de controle são retornados.

A pasta models ficou determinada para o componente Modelo do MVC, nela deverá conter os arquivos separados por entidades, com sua nomenclatura em singular, como exemplo, na linha 12 da Listagem 1, o arquivo user.py é responsável por armazenar informações dos campos da entidade usuário. O arquivo base.py (linha 11) é uma classe abstrata, na qual fornece um escopo para as outras entidades. A pasta forms, é responsável por armazenar os arquivos referentes aos formulários, como exemplo, o arquivo user.py (linha 9), deverá conter os formulários de login, cadastro e edição do usuário.

Para a camada da interface do usuário (Visão), foi necessário um conjunto de pastas para nos organizarmos. Primeiramente na pasta principal do projeto, foram divididos os arquivos HTML dos arquivos CSS, Javascript e as imagens, respectivamente nas pastas templates e static, após este processo, subdividimos os arquivos HTML entre os pertencentes a uma determinada rota, com novas pastas utilizando a mesma nomenclatura do controle (como exemplo, a pasta users da linha 18) e os arquivos modelo de cada

CAPÍTULO 3.DESENVOLVIMENTO

38

layout da aplicação. Como esta camada possui uma complexidade maior em termos de organização e utiliza diversas bibliotecas exclusivas para layout, criamos a seção a seguir.

3.6.3.2. Interface do usuário

Dado que possuíamos o requisito de uma interface amigável aos usuários e facilmente podemos encontrar painéis administrativos com esta e outras características de código aberto, optamos por utilizar um painel já estruturado ao invés de desenvolvê-lo. O AdminLTE escolhido para este projeto, é um modelo de painel administrativo baseado em Bootstrap 3 de código aberto, no qual possui um vasto conjunto de elementos responsivos a múltiplos dispositivos, com uma ótima documentação que facilita a implementação, além de uma interface intuitiva de boa aparência.

A partir disto, como já mencionado na seção 3.6.3.1, nós dividimos a interface em dois conjuntos, os modelos e os núcleos das páginas. Os arquivos modelos (error.html, login.html, layout.html), contém as partes estáticas de cada layout, como exemplo, o arquivo layout.html contém o cabeçalho, menu lateral e rodapé do layout da aplicação, faltando unicamente o corpo, no qual deverá ser importado o conteúdo da rota em questão.

Para versão inicial da aplicação, desenvolvemos quatro conjuntos de rotas essenciais para o projeto, descritas a seguir:

• Estatísticas (Página inicial): Geral, escolas e cursos;

• Estudantes: Listagem dos estudantes e visualização individual. • Coletas: Listagem das coletas;

• Usuários: CRUD, login e recuperação de senha;

Nesta aplicação, também foi utilizado algumas bibliotecas Javascript para melhorar a interação do usuário com o sistema, sendo as duas principais JQuery e AngularJS. A primeira biblioteca JQuery, é requerida pelo painel AdminLTE para gerenciamento de alguns elementos e foi utilizada nos conjuntos de rotas estudantes, coletas e usuários. A segunda biblioteca AngularJS, foi utilizada exclusivamente na página inicial, visto que, precisaríamos de uma dinâmica maior para gerenciar múltiplas requisições, além de diversos gráficos e tabelas, esta biblioteca se fez necessária, conseguindo manipular de forma simples os dados e os elementos após ao retorno das requisições.

CAPÍTULO 4.ANÁLISE E DISCUSSÃO DE RESULTADOS

39

3.6.3.3. Níveis de acesso

Para solucionar a questão dos níveis de acesso com base na hierarquia do IPB, no qual são necessários no mínimo três regras com limitação de conteúdo, criamos uma função decoradora e um atributo chamado role na entidade usuário. Uma função decoradora ou decoradores de funções, são funções de extensão ou de aprimoramento de uma outra função. Seu objetivo principal é executar algum procedimento antes ou depois da função principal ser executada sem modificá-la. Neste projeto, a função decoradora é chamada antes de cada rota, na qual deverá especificar qual o mínimo usuário de acesso para validação.

O atributo role é do tipo inteiro, no qual apenas pode assumir os valores determinados por uma lista enumerada encontrada no arquivo config.py. A ideia da lista enumerada é criar uma hierarquia nos níveis de acessos, em nossa aplicação, como padrão definimos três níveis, no qual denominados de administrator, coordinator e master, e possuem a numeração 0, 1 e 2 respectivamente, com isto, através da função decoradora será validado o usuário com o mínimo de permissão necessária para utilizar a rota, restringindo ou liberando o acesso a partir do resultado. A partir disso, seguindo esta lógica de hierarquias, é possível adicionar outros níveis de acesso apenas adicionando mais um rótulo na lista enumerada. Para entendermos melhor o que cada nível terá acesso, desenvolvemos o diagrama de caso de uso da Figura 8.

CAPÍTULO 3.DESENVOLVIMENTO

40

O diagrama de caso de uso da Figura 8 é uma versão simplificada da aplicação com os principais casos de uso. Como é possível visualizar os atores possuem uma hierarquia representada pela herança, sendo o master topo da hierarquia, conseguindo acessar todos os casos e o administrator o último, apenas com um caso de uso.

Cada usuário com nível de acesso abaixo do master, possui um código associado. Se caso for administrator, o código de um curso e se caso for coordinator, o código de uma escola. Com isto, a aplicação só irá mostrar as informações atreladas a este código específico, como exemplo, um usuário coordinator, conseguirá acesso a todas as informações da escola, como comparações entre cursos, levantamentos, entre outros e o acesso a todos os cursos pertencentes aquela escola, já o administrator só terá acesso a um curso específico.

3.6.3.4. Integração com a ferramenta ETL e hospedagem

Com as interfaces desenvolvidas e a aplicação já estruturada com os níveis de acesso, só nos faltava desenvolver a integração com a ferramenta ETL e instalar a aplicação em um servidor. Sendo assim, relembrando do diagrama da estrutura da Figura 7, após os dados serem extraídos e enviados para o MongoDB, a própria ferramenta ETL enviará uma requisição notificando os dados extraídos, nos restando a tarefa de calcular os dois atributos criados e aplicar o modelo de classificação.

Para resolver este problema, criamos duas funções, sendo elas, o pré-processamento e a própria requisição que deverá aplicar o modelo. A função pré-processamento é capaz de aplicar as funções de agregação do MongoDB e retornar os novos atributos já calculados, restando apenas a tarefa de associá-los aos devidos alunos na semana extraída. Já a função para aplicação do modelo, primeiramente faz a chamada do pré-processamento e após gera a classificação utilizando os dados de treino dos últimos 4 anos relativos a semana. Por fim os dados são editados no MongoDB com a predição e os novos atributos atualizados, liberando a plataforma exibi-los na interface.

A aplicação Web e o banco de dados MongoDB foram instalados no mesmo servidor Linux com acesso público. Entretanto para o Framework Flask funcionar corretamente no servidor, foi necessário instalarmos três outros serviços. O primeiro chamado Gunicorn, é um servidor Python WSGI, no qual foi instalado a aplicação; O segundo denominado Supervisor, é um serviço que permite monitorar e controlar os processos do Gunicorn; Por último, instalamos o serviço Nginx como servidor de proxy reverso.

41