• Nenhum resultado encontrado

2016.1 Anderson Cerqueira Guedes

N/A
N/A
Protected

Academic year: 2021

Share "2016.1 Anderson Cerqueira Guedes"

Copied!
75
0
0

Texto

(1)

ANDERSON CERQUEIRA GUEDES

SOLUÇÕES COMPUTACIONAIS PARA PROVER CODIFICAÇÃO DO

CENSO DA EDUCAÇÃO SUPERIOR EM NUVEM

Orientadora: Prof.ª Ana Cláudia Fiorin Pianesso

FEIRA DE SANTANA 2016

(2)

SOLUÇÕES COMPUTACIONAIS PARA PROVER CODIFICAÇÃO DO

CENSO DA EDUCAÇÃO SUPERIOR EM NUVEM

Trabalho de Conclusão de Curso apresentado ao Departamento de Tecnologia, do curso Engenharia de Computação da Universidade Estadual de Feira de Santana, utilizado como requisito parcial para obtenção do título de bacharel em Engenharia de Computação.

Orientadora: Prof.ª Ana Cláudia Fiorin Pianesso

FEIRA DE SANTANA 2016

(3)

Aluno: Anderson Cerqueira Guedes

Trabalho de Conclusão de Curso apresentado e julgado em 14/02/2017 perante a banca examinadora:

____________________________________________ Ms. Ana Cláudia Fiorin Pianesso

(Universidade Estadual de Feira de Santana - DTEC)

____________________________________________ Dr. Antônio Augusto Teixeira Ribeiro Coutinho (Universidade Estadual de Feira de Santana - DEXA)

____________________________________________ Dr. David Moisés Barreto dos Santos

(Universidade Estadual de Feira de Santana - DEXA)

____________________________________________ Coordenador do Colegiado do

(4)

Agradeço, em primeiro lugar, aos meus pais José e Conceição. Especialmente, agradeço a minha mãe pelos cuidados, diálogos e inabalável dedicação. Sem seu apoio, dificilmente teria chegado até aqui.

A minha avó, Izabel (in memoriam), pela atenção e carinho somente equiparados aos de uma mãe.

À professora Ana Cláudia, pelas constantes correções, sugestões, assistência e enorme paciência durante o desenvolvimento deste trabalho.

Ao colega Júlio, pela padronização da interface gráfica dos Codecs e aos colegas Afonso e Henderson pelo auxílio e disponibilidade durante os testes com a Nuvem.

Aos professores, em especial, Ana Lúcia, Edgar, Fernanda, Gabriela, Roberto e Thiago Maia, pelos exemplos de dedicação ao trabalho, valorização do conhecimento e respeito aos seus alunos.

Aos colegas com os quais tive a oportunidade de conviver e realizar trabalhos ao longo desses anos, pelas conversas, colaboração e momentos lúdicos que tornaram menos árdua a travessia pelos módulos PBL (Problem Based Learning) e demais disciplinas do curso.

(5)

“An eternity passed, and my torment receded, bringing me back from the precipice of madness. The descent had destroyed me... And yet, I lived”.

(6)

A proposta deste trabalho consiste em desenvolver uma aplicação desktop com camadas de interface para utilização em servidor web e Nuvem. Tal aplicação deve ser capaz de prover condições para a integração, codificação e decodificação dos dados relacionados ao Censo da Educação Superior. Objetiva-se prover esta codificação em Nuvem de modo que qualquer Instituição de Ensino possa utilizar os serviços disponibilizados. Para tanto, essa proposta é composta, essencialmente, de três etapas. A primeira é a elaboração de codificadores e decodificadores para o Censo 2015. Estes devem ser capazes de receber arquivos com dados e codificá-los ou decodificá-los de acordo com as especificações de layout estabelecidas pelo Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira (Inep), na abordagem desktop. A segunda etapa consiste na integração destas soluções com o Sistema de Gestão de Dados Educacionais, este implantado na Universidade Estadual de Feira de Santana, através de interfaces web. Aliado a estas pretensões, a terceira etapa visa disponibilizar tais soluções através de processamento em Nuvem. Como resultados, destacam-se: a solução Codec, que pode ser utilizada nas abordagens citadas; a elaboração de todo o processo do Censo da Educação Superior 2015 da UEFS utilizando esta solução e os benefícios de redução considerável de tempo; meios para rastrear as possíveis inconsistências no cruzamento de dados; além da solução poder ser utilizada por qualquer Instituição de Ensino em novas versões do Censo, pois o código do Codec poderá ser facilmente reutilizado.

Palavras-chave: Censo da Educação Superior, Integração de Dados, Codificação de Dados, Processamento em Nuvem.

(7)

This working paper consists of desktop software application development, along with software interface layers in order to obtain means for deployment into webservers as into Cloud Infrastructure. These developed assets must provide means for: data unifying; data coding and decoding, whereas the processed data is related to University Education Census, namely, the 2015 Census. The intended goal is to provide data coding services for any college institution through Web Cloud access. In order to accomplish such task, this work essentially consists of three steps, the first one regards data coders and decoders softwares for 2015 Census. These applications should be developed under a desktop application approach, providing both coding and decoding for imported files, according to Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira’s (Inep) layout specification guide instructions. The second step intends to bundle these solutions into a Education Data Management System through web interface layers. Aligned with these goals, the third step aims to provide such solutions through Web Cloud technology. One can indicate the possible outcomes: use of Codec software solutions for related issues; improved Census planning and conception; benefits regarding processing time reduction; inconsistency tracking during data-cross checking; reuse of Codec solutions (due software architectural flexibility) in future Census editions by any college institution.

(8)

Figura 1: Etapas de execução do Codec Web... 23

Figura 2: Estrutura geral do Codec Web ... 24

Figura 3: Estrutura geral do Codec Cloud ... 27

Figura 4: Versão compacta da arquitetura do Codec Desktop ... 30

Figura 5: Campo “Turno do Aluno” (regras) ... 31

Figura 6: Campo “Turno do Aluno” (mensagens de erro) ... 31

Figura 7: Arquivo com dados de docentes ... 33

Figura 8: Hierarquia de classes da estrutura Censo ... 33

Figura 9: Composição do objeto Censo2015 com layouts e os respectivos processadores ... 34

Figura 10: Estrutura interna da classe Codec ... 35

Figura 11: Processo de produção dos arquivos do Censo com o Codec Desktop ... 37

Figura 12: Arquivo codificado (docentes) ... 39

Figura 13: Erros de codificação ... 39

Figura 14: Arquivo decodificado (docentes) ... 40

Figura 15: Seção de exportação de dados no sistema GeDE ... 42

Figura 16: Página inicial do Codec Web ... 43

Figura 17: Notificação de operação realizada com sucesso ... 43

Figura 18: Notificação de erros com exibição de log ... 44

Figura 19: Exibição da lista de cursos para a opção “Discente” ... 44

(9)

Capes Coordenação de Aperfeiçoamento de Pessoal de Nível Superior

Censup Censo da educação superior (Sistema Inep)

CPC Cálculo Preliminar de Cursos

GeDE Gerenciador de Dados Educacionais

IaaS Infrastructure as a Service

IGC Índice Geral de Cursos

IES Instituição de Ensino Superior

Inep Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira

MEC Ministério da Educação e Cultura

PaaS Platform as a Service

PI Pesquisador Institucional

Prouni Programa Universidade para Todos

SaaS Software as a Service

Sinaes Sistema Nacional de Avaliação do Ensino Superior

(10)

1. INTRODUÇÃO... 8

2. FUNDAMENTAÇÃO TEÓRICA ... 13

2.1 Censo da Educação Superior ... 13

2.2 Computação e m Nuve m ... 15

2.2.1 Tipos de serviço ... 16

2.2.2 Tipos de acesso ... 17

2.2.3 Motivações... 18

2.2.4 Barreiras... 19

2.2.5 Desvantagens da Nuvem pública ... 20

3. METODOLOGIA ... 21

3.1 Inte rface de comunicação para execução do Codec em servidor Web ... 22

3.2 Inte rface para execução do Codec em Nuve m ... 26

4. RESULTADOS ... 29

4.1 Desenvolvimento do Codificador e Decodificador de arquivos do Censo 2014 e 2015 na abordagem Desktop ... 29

4.2 Aplicação dos Codificadores e Decodificadores na elaboração do Censo 2015 ... 36

4.2.1 Codificação ... 38

4.2.2 Decodificação ... 39

4.2.3 Impacto do Codec Desktop na elaboração do Censo 2015... 41

4.3 Utilizando o Codec em ambiente Web ... 42

4.4 Utilização do Codec Desktop em Nuvem ... 45

4.4.1 Implantação no OpenNebula ... 46

5. CONSIDERAÇÕES FINAIS ... 48

REFERÊNCIAS... 51

APÊNDICE A – LEVANTAMENTO DE REQUISITOS (CENSO CODEC DESKTOP) ... 53

APÊNDICE B – ESPECIFICAÇÃO DE CASO DE USO: CODIFICAÇÃO... 59

(11)

1. INTRODUÇÃO

O MEC (Ministério da Educação e Cultura) vem buscando, mais intensamente na década de 90, aprimorar as avaliações sobre a qualidade do Ensino Superior no Brasil. Atualmente, o responsável por conduzir os processos de avaliação é o Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira (Inep). A partir do ano de 2013, o Censo da Educação Superior passou a ser pré-requisito para que as Instituições de Ensino Superior (IES) participem do Sistema Nacional de Avaliação da Educação Superior (Sinaes). Mesmo que a Instituição não participe desse sistema de avaliação, o Inep recomenda que a mesma deve se preparar para adesão. Muitos aspectos relacionados à Instituição podem ser ponderados nas avaliações contidas na proposta do Sinaes.

Além de constituir parte do Sinaes, o Censo da Educação Superior é realizado anualmente pelo Inep. É um importante instrumento de obtenção de dados para a geração de informações que subsidiam a formulação, o monitoramento e a avaliação das políticas públicas. O Censo também é um importante elemento para elaboração de estudos e pesquisas sobre o setor. O Censo coleta informações sobre as IES, os cursos de graduação e sequenciais de formação específica e sobre cada aluno e docente, vinculados a esses cursos. Posteriormente, são agrupadas as informações sobre as instituições de ensino superior, tais como: cursos de graduação presencial ou à distância, cursos sequenciais, vagas oferecidas, inscrições, matrículas, ingressantes e concluintes, além de informações sobre docentes, nas diferentes formas de organização acadêmica e categoria administrativa (Inep, 2016).

Foi constatado pelo grupo de trabalho da Procuradoria Educacional Institucional da Universidade Estadual de Feira de Santana (UEFS), setor da Instituição no qual este trabalho está inserido, que a elaboração do Censo para as IES é um trabalho árduo, principalmente: 1) por tratar da integração de dados das esferas administrativas e acadêmicas; 2) pelo fato de tal integração produzir informações referentes ao ano anterior ao trabalho de coleta e preparação do Censo; 3) pela falta de quantitativo humano necessário para realizar o preenchimento manual de todos os dados requeridos pela coleta. No caso de IES que não possuem Sistemas de Informação Integrados, a problemática aumenta significativamente, como é o caso da UEFS.

A UEFS, até setembro de 2013, elaborou o Censo da Educação Superior de forma parcial e através de preenchimento dos formulários eletrônicos online disponibilizados no site do Censo. A existência, até então, de uma elaboração parcial do Censo refere-se a alguns fatores principais, como: indisponibilidade dos dados e informações necessárias à equipe de elaboração

(12)

do mesmo, causada pela inexistência de base de dados integrada que permita a extração dos dados necessários; a falta de sistematização dos dados de determinados setores; falta de atualização de dados (usualmente cadastrais); duplicidade de dados, gerando incoerência; escassez de tempo hábil para preenchimento dos formulários online, visto que são extensos, dentre outros.

Em 2014, ano de elaboração do Censo referente ao exercício anterior, passou-se a utilizar uma ferramenta computacional denominada Módulo CENSO, elaborada por uma empresa terceirizada contratada para propor soluções computacionais à instituição. Esta ferramenta computacional fornece dados e informações relacionadas ao Censo. Estes dados são inseridos na base de dados do Sistema Acadêmico SAGRES no formato de exportação para o Censo como arquivos. Estes são carregados no sistema eletrônico do Inep para realização do Censo, denominado Censo da Educação Superior (Censup), de acordo com o conceito de arquivos de lote. Apesar dessa ferramenta representar inicialmente um grande avanço na preparação do Censo, nem todos os dados e informações necessárias estão disponíveis nesta base de dados. Diante deste cenário, um processo para facilitar a coleta de dados armazenados fora da base de dados do SAGRES foi iniciado junto aos diversos setores da Instituição. Os setores envolvidos nesta coleta de dados foram aqueles relacionados aos dados necessários, porém inexistentes no Sistema Acadêmico como: dados de pesquisa, extensão, mobilidade acadêmica, monitoria, infraestrutura de laboratórios, informações de docentes em cargos administrativos como administração, planejamento e avaliação, bolsistas, apoio social aos discentes, dentre outros. A partir dessa coleta interna aos Setores, os dados foram submetidos ao Módulo CENSO (via carga de banco de dados) e a preparação dos arquivos codificados foram gerados para envio do Censo da UEFS, via lote.

No contexto deste trabalho, em relação a arquivos codificados para o Censo, entende-se por “codificação” a transformação do conteúdo de um determinado campo de um layout em um código ou número correspondente, conforme as diretrizes oficiais do Inep. A “decodificação”, por sua vez, consiste no processo inverso, recuperando a informação original de um campo cujo valor foi previamente associado àquele código ou número.

Após o envio do Censo ao Inep, este órgão realiza uma série de verificações de consistências dos mesmos. Utilizando os procedimentos relatados anteriormente para elaboração dos Censos referentes aos anos de 2013 e 2014, o Inep relatou muitas inconsistências nos dados enviados. Os problemas relatados abrangiam: formato incorreto dos dados (e.g.: CPF com número incorreto de dígitos ou inválido); eventuais mudanças na estrutura dos layouts

(13)

oficiais ao longo dos anos; falha do layout em prever situações inusitadas, tais como trancamento e matrícula de aluno em novo curso em um mesmo ano; conflitos entre as informações da base de dados e da Receita Federal, devido a alterações no sobrenome por estado civil, entre outros. Surge, então, um novo problema: como realizar o mapeamento da inconsistência para identificar a sua origem.

As tentativas de mapeamento das inconsistências evidenciaram vários problemas da UEFS como, por exemplo, a falta de integração dos dados. Não há um sistema atualmente, na instituição, capaz de integrar os dados para assegurar a consistência das informações. Outro problema reside na solução do Módulo CENSO: após análise, constatou-se que o mesmo possui regras de negócio equivocadas em seu projeto, pois não atendem de forma adequada aos requisitos dos processos aplicados na instituição.

Tais problemas geram incerteza, pois é difícil determinar se os dados coletados são realmente os dados migrados para a base de dados do Inep. Além disso, a ausência de um decodificador dificulta a validação dos dados antes da migração ser realizada. Portanto, não é possível gerar relatórios, em alguns casos, necessários à Instituição. Há ainda a impossibilidade de mapeamento de eventuais inconsistências identificadas pelo sistema do Inep, que solicita imediata correção das discrepâncias detectadas.

Os layouts são, eventualmente, modificados pelo Instituto ao longo dos anos. Essas alterações, portanto, podem levar a inconsistências, tais como arquivos de relatório gerados a partir de layouts desatualizados ou incorretos. Como não é possível analisar o código-fonte do codificador fornecido pelo Módulo CENSO da empresa terceirizada, além de não existir um decodificador, dúvidas surgem nos seguintes aspectos: a) as inconsistências estão no volume de dados da Instituição? b) as inconsistências estão na codificação dos dados? ou c) as inconsistências foram geradas a partir dos relatórios do Inep (para os quais não há controle e conhecimento de como são gerados)?

Portanto, fica evidente a necessidade de um mapeamento e identificação dos pontos de inconsistência de forma mais transparente para a Instituição. As possíveis soluções levantadas foram: criação de uma fonte única de acesso para coleta dos dados, eliminando a presente heterogeneidade de sistemas e garantindo a consistência dos dados; integração dos sistemas que participam das diversas etapas do processamento dos dados até a produção do arquivo codificado; desenvolvimento de soluções computacionais em código aberto, visando um maior controle; mapeamento mais eficiente de eventuais inconsistências encontradas, por meio de codificadores e decodificadores de dados, além de geradores de relatórios.

(14)

A importância da elaboração do Censo, cada vez mais coerente e consistente atualmente, é compreendida por várias IES. A UEFS criou, como ato administrativo em maio de 2015, o setor denominado Procuradoria Educacional Institucional. O referido setor é o responsável pela elaboração do Censo, dentre outros assuntos da esfera Federal.

A proposta desse trabalho surge de uma necessidade da UEFS e de outras IES que não possuem recursos humanos suficientes para realizar o preenchimento manual de todos os dados solicitados na coleta. Desse modo, quando a Instituição decide automatizar algumas das etapas de coleta, é necessária a codificação dos dados no formato especificado pelo Inep e posterior carga via sistema eletrônico para realização do Censo (Censup). Para tanto, tais dados são exportados pelo sistema Gerenciador de Dados Educacionais (GeDE). Este sistema, por sua vez, consiste em um conjunto de interfaces utilizadas para gerenciar e manipular um banco de dados contendo informações sobre os discentes, docentes e cursos da UEFS. A proposta é que o GeDE integre os dados dos diferentes setores em uma base de dados única.

Essa proposta é composta, essencialmente, de três etapas. A primeira é a elaboração de codificadores e decodificadores para o Censo 2015 que sejam capazes de receber arquivos com dados gerados pelo GeDE e codificá-los de acordo com as especificações de layout estabelecidas pelo Inep. Também é parte integrante desta etapa o trabalho inverso: a decodificação dos arquivos devolvidos pelo Inep para um formato legível dos dados. Nesta etapa, os codificadores e decodificadores estarão inseridos na abordagem desktop.

A segunda etapa proposta é a integração dos codificadores e decodificadores com o GeDE, através da implementação de uma camada de comunicação entre as aplicações. Com isso, os arquivos poderão ser codificados e/ou decodificados no próprio Sistema de Gestão.

Aliado a estas pretensões, objetiva-se na terceira etapa a disponibilidade de tais soluções em Nuvem, para que as vantagens do uso dos serviços possam ser trazidas não somente para a UEFS, mas para outras IES. Este interesse já foi sinalizado pelas IES, pois há uma dificuldade na codificação dos arquivos do Censo pelos fatores e dificuldades muito semelhantes aos apresentados na UEFS. As aplicações desenvolvidas serão aplicadas como piloto para testes, coletas de resultados e avaliação de viabilidade da solução, levando-se em consideração a relação custo-benefício para as instituições.

O conceito de Computação em Nuvem pode ser entendido com algo que se refere tanto às aplicações como ao hardware e sistemas de software presentes nos datacenters que fornecem sua infraestrutura como serviços pela Internet. Estes são conhecidos há algum tempo por Softwares como Serviço (Software as a Service – SaaS). O hardware e o software do datacenter

(15)

são o que se chamam de Nuvem. As vantagens do SaaS já são bem compreendidas pelos usuários finais e provedores de serviço: há uma grande simplificação nos processos de instalação e manutenção de software, além de um controle centralizado de versionamento; usuários finais podem acessar o serviço de qualquer lugar, em qualquer momento; o compartilhamento de dados e a colaboração é exercida mais facilmente; por fim, os dados são armazenados de forma segura na infraestrutura (ARMBRUST et al, 2009).

Este texto está dividido nos seguintes tópicos: revisão da literatura no tópico de fundamentação teórica, onde serão abordadas noções sobre o Censo da Educação Superior, além de noções sobre Computação em Nuvem. Em seguida, será abordada a metodologia utilizada no trabalho: a aplicação do Codec Desktop (proposta para a codificação do Censo) para elaboração do Censo em 2014 e 2015, interface para execução do Codec em um servidor web e implantação da aplicação em Nuvem. Posteriormente, serão apresentados os resultados envolvendo o desenvolvimento do Codec Desktop, a aplicação deste no Censo 2015 e a utilização do Codec nos ambientes Web e Nuvem. Por fim, serão feitas as considerações finais sobre o trabalho.

(16)

2. FUNDAMENTAÇÃO TEÓRICA

Na presente seção, serão apresentados os conceitos essenciais sobre o Censo da Educação Superior, além de algumas definições e características da Computação em Nuvem.

2.1 Censo da Educação Superior

O Censo da Educação Superior consiste na coleta de dados sobre a educação superior realizada anualmente pelo Inep, em um amplo regime de colaboração, cuja declaração obrigatória ocorre mediante uma coleta de dados descentralizada. Englobando estabelecimentos públicos e privados de educação superior, assegura-lhes o sigilo e a proteção de dados pessoais, sendo operacionalizado mediante sistema eletrônico de informações. De acordo com o Inep, o objetivo é oferecer à comunidade acadêmica e à sociedade informações detalhadas sobre as maiores tendências e a situação atual do setor. Esta coleta dos dados utiliza como referência as diretrizes gerais previstas pelo Decreto nº 6.425 de 4 de abril de 2008 (BRASIL, 2008).

O Censo da Educação Superior reúne informações sobre as instituições de ensino superior, seus cursos de graduação presencial ou a distância, cursos sequenciais, vagas oferecidas, inscrições, matrículas, ingressantes e concluintes, além de informações sobre docentes, nas diferentes formas de organização acadêmica e categoria administrativa. Visando o aprimoramento da qualidade das análises realizadas, o Censo traz as informações de aluno e docente individualizadas. De acordo com a visão do Inep, tal individualização possibilita um acompanhamento minucioso das políticas do setor e de seus participantes. O Censo ainda subsidia o planejamento e a avaliação de políticas públicas, contribuindo no cálculo de indicadores de qualidade como o Cálculo Preliminar de Curso (CPC) e o Índice Geral de Cursos (IGC).

De acordo com a Portaria nº 794/2013, o preenchimento completo e atualizado do Censo passa a ser pré-requisito para que as Instituições de Ensino Superior (IES) possam participar do Sinaes, obter a expedição de atos regulatórios das IES e de seus cursos, aderir ao Fundo de Financiamento Estudantil (Fies) e ao Programa Universidade para Todos (Prouni), e participar dos programas de bolsas da Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (Capes) (BRASIL, 2013).

(17)

Por meio do sistema eletrônico para realização do Censo – Censup –, os dados são coletados nos seguintes módulos: IES, Curso, Docente e Aluno. As informações cadastrais das IES e dos cursos são obtidas diretamente do Cadastro e-MEC, que é a base de dados oficial utilizada pelos órgãos do MEC e autarquias vinculadas, como determina a Portaria Normativa nº 40, de 12 de dezembro de 2007, republicada em 29 de dezembro de 2010 (BRASIL, [2007], 2010). Sendo assim, é de responsabilidade do Procurador Educacional Institucional manter os dados do Sistema e-MEC atualizados. Os demais dados são coletados através do preenchimento de questionários online, por parte das IES e/ou por importação de arquivos em lote gerados pelas próprias IES no padrão de codificação estabelecido pelo Inep. Este último é realizado por meio de um processo denominado “migração” pelo Inep. A migração ocorre com o envio de cargas de dados em arquivos devidamente codificados, de acordo com a especificação de layouts, disponibilizados a cada ano em que é realizada a coleta de dados.

Durante o período de preenchimento do Censo, os Procuradores Institucionais (PIs) podem fazer, a qualquer momento, alterações ou inclusões necessárias nos dados das respectivas instituições. Após a etapa do envio dos dados, o Inep verifica a consistência dos mesmos. Em seguida, o Inep executa rotinas para analisar a base de dados do Censo, com o objetivo de conferir as informações enviadas pela IES. O sistema do Censo é reaberto, iniciando o processo de conferência e validação. Caso os arquivos tenham sido aprovados na fase de conferência, o Censo é finalizado. Os dados são divulgados, acompanhados da publicação da Sinopse Estatística (relatório contendo estatísticas resultante de cruzamento dos dados dos Censos das Instituições Brasileiras). Uma vez que as estatísticas se tornam oficiais, não é possível realizar alterações nas informações fornecidas (Inep, 2016).

Em resumo, o processo de realização do Censo envolve as seguintes fases:

1) Publicação de Portaria específica: as etapas e atividades do processo de realização do Censo são publicadas no Diário Oficial da União, conforme cronograma detalhado. As publicações são responsabilidade do Inep;

2) Coleta dos dados: a partir do preenchimento de formulários específicos on-line, as instituições fornecem as informações, sendo consideradas como unidades de investigações as IES, os Cursos, os Docentes e os Alunos, possibilitando obter dados sobre número de instituições, de cursos, de matrículas, ingressos, concluintes, escolaridade docente e regime de trabalho, entre outros. A coleta desses dados é realizada pela equipe responsável por elaborar o Censo em cada Instituição;

(18)

3) Consistência dos dados coletados: durante e após o preenchimento dos formulários, são efetuadas análises de consistências dos dados com o objetivo de identificar, notificar, justificar e documentar divergências. O objetivo desta etapa é obter maior qualidade e fidedignidade nas informações estatísticas declaradas ao Censo. A verificação da consistência dos dados é responsabilidade do Inep;

4) Conferência, retificação e validação dos dados: período disponibilizado para correções das divergências identificadas nas verificações das consistências dos dados. Essa etapa é responsabilidade de cada Instituição de ensino;

5) Consolidação e homologação do Censo: os dados são submetidos a rotinas de processamento e análise para conferência final das informações, em colaboração com os pesquisadores institucionais das IES. Após a conferência, finaliza-se o Censo e a base de dados é homologada, não sendo possível efetuar novas alterações. Essa etapa é responsabilidade do Inep;

6) Divulgação do Censo: em data específica, ocorre a publicação do Censo em coletiva de imprensa e no sítio do Inep.

2.2 Computação em Nuvem

Outra abordagem que pode ser utilizada para atender os propósitos deste trabalho está inserida no contexto de Computação em Nuvem. Uma definição para esse tipo de computação ainda não é objeto de consenso geral entre os especialistas. No entanto, alguns autores fornecem algumas definições importantes sobre o conceito dessa tecnologia. Lewis (2010) define a Computação em Nuvem como um paradigma de computação distribuída, onde o foco consiste em fornecer acesso distribuído e escalável a uma infraestrutura virtualizada de hardware e/ou software por meio da internet. Citando Foster, Strowd detalha um pouco mais o conceito, descrevendo esse tipo de computação como um paradigma direcionado por economia de escala, onde um conjunto de atributos – tais como poder computacional, armazenamento, plataformas e serviços – são abstraídos, virtualizados e escaláveis dinamicamente, fornecidos sob demanda para consumidores externos através da internet (STROWD apud FOSTER, 2008).

Armburst (2009) afirma que a Nuvem se refere ao conjunto de aplicações fornecidas como serviços na internet e ao hardware e sistemas de software presentes nos datacenters que

(19)

fornecem esses serviços. Ainda segundo o autor, serviços que são comercializados pela Nuvem são caracterizados como “Computação Instrumental” ou “Computação Utilitária”.

Strowd (2010) classifica a Nuvem segundo dois tipos de perspectiva: potencialidade e acesso. A primeira diz respeito aos recursos fornecidos e a segunda trata da acessibilidade a tais recursos.

2.2.1 Tipos de serviço

Considerando a ótica da potencialidade de recursos, existem três modalidades de fornecimento (STROWD, 2010), a saber:

1) Infraestrutura como serviço (IaaS): consiste no tipo mais comum de infraestrutura computacional disponível na internet, tais como ciclos de computador, e armazenamento de dados. O usuário utiliza os recursos como se estivesse operando uma máquina proprietária. As restrições aplicadas pelos provedores da infraestrutura são mínimas, garantindo ao cliente máximo controle e acesso às configurações dos recursos. O custeio das operações fica restrito ao consumo de banda, processamento e armazenamento utilizados. Caso os recursos não sejam mais necessários, os mesmos são removidos sem custo adicional. Taxas para recursos extras são solicitadas apenas quando necessário (STROWD, 2010). Exemplos de IaaS: Amazon Elastic Compute Cloud, Amazon Simple Storage Solution, GoGrid, IBM Computing on Demand, Microsoft Live Mesh e Rackspace Cloud (LEWIS, 2010);

2) Plataforma como serviço (PaaS): refere-se ao tipo de implementação destinada a plataformas – tais como componentes de hardware e software – para desenvolvimento de aplicações que podem obter vantagem dos recursos de uma organização de grande porte para criar e hospedar aplicações em uma escala muito maior comparada ao que se poderia obter por meio de desenvolvimento individual ou até mesmo com uma empresa de pequeno porte. Entre os possíveis serviços oferecidos, estão: instalação e configuração de software, escalonamento de recursos, além de manutenção e atualização de plataformas. Antes de obter acesso a esses serviços, o usuário é informado sobre algumas restrições, tais como: linguagens de programação suportadas, mecanismos de armazenamento de dados e o nível de potencialidade para monitorar

(20)

recursos. Nessa modalidade, além de utilizar os recursos, o desenvolvedor pode implantar as próprias aplicações na Nuvem. Caso as necessidades do usuário sejam supridas pela plataforma, é possível obter um nível significativo de funcionalidade com o mínimo de esforço (STROWD, 2010). Alguns exemplos de PaaS: Akamai EdgePlataform, Force.com, Google App Engine, Microsoft Azure Services Platform e Yahoo! Open Strategy (LEWIS, 2010);

3) Software como serviço (SaaS): o foco dessa modalidade consiste em fornecer recursos aos clientes para aplicações comerciais específicas. De maneira geral, é um modelo de implantação de software onde um fornecedor licencia suas aplicações para empresas ou clientes as utilizam sob demanda. O usuário enxerga as aplicações de forma transparente, sem a necessidade de adquirir, hospedar ou instalar programas em sua própria máquina. Exemplos desse tipo serviço são: Google Apps, SalesForce.com e Zoho (STROWD, 2010).

2.2.2 Tipos de acesso

O acesso aos recursos em Nuvem recebem dois tipos de classificação:

Público: os recursos são oferecidos como serviços por meio de uma conexão com a internet. Os clientes podem elevar a utilização do serviço de acordo com a demanda, dispensando a necessidade de adquirir um hardware para executar as aplicações. O gerenciamento da infraestrutura e dos recursos requeridos pelos usuários ficam a cargo dos fornecedores da Nuvem (LEWIS, 2010).

Privado: a Nuvem implantada geralmente está protegida por um firewall, sendo gerenciada por uma organização cliente. Esse usuário é o proprietário do hardware e do software em execução na Nuvem, sendo também responsável pelo gerenciamento e fornecimento dos recursos virtualizados. Tais recursos não são compartilhados fora da organização, que exerce controle total sobre os mesmos (STROWD, 2010). Em outras palavras, a utilização da Nuvem é restrita ao ambiente de trabalho.

(21)

O Instituto Nacional de Padrões e Tecnologia (Nacional Institute Standards and

Technology - NIST) cita dois tipos adicionais de modelos de acesso à Nuvem: comunitárias e

híbridas. O primeiro trata de nuvens compartilhadas por diversas organizações, atendendo às necessidades particulares de uma comunidade. O segundo tipo abrange nuvens que possuem características de duas ou mais nuvens públicas, privadas ou comunitárias (LEWIS, 2010).

2.2.3 Motivações

Com o surgimento e adesão crescentes dessa tecnologia, a Computação em Nuvem atingiu o pico das expectativas (STROWD apud GARTNER, 2009). Baseado em suas pesquisas, Strowd enumerou uma série de motivações e barreiras para a adoção desse paradigma de computação.

Os principais motivadores (ou vantagens) são listados a seguir (STROWD, 2010):

Baixo custo de infraestrutura: o modelo de pagamento sob demanda permite que uma organização (ou indivíduo) pague apenas o valor correspondente aos recursos utilizados. Investimentos em recursos físicos são, essencialmente, desnecessários. Não há necessidade de custeio para manutenção ou atualização da infraestrutura;

Colaboração: os usuários são estimulados a enxergar a Nuvem como um meio para trabalhar simultaneamente em dados e informações comuns;

Disponibilidade: os usuários podem acessar os recursos a qualquer momento, sendo suficiente ter o acesso a uma conexão de internet;

Elasticidade: o provedor de serviços pode gerenciar os recursos de forma transparente, de acordo com a necessidade dos usuários;

Escalabilidade: os clientes tem acesso a uma vasta quantidade de recursos, que se adequam à demanda de utilização;

(22)

Redução de riscos: empresas e organizações podem testar as suas ideias de projeto em Nuvem, antes de investir em equipamentos físicos e demais tecnologias requeridas;

Virtualização: cada usuário enxerga os recursos oferecidos como se fossem únicos, independente do arranjo físico dos dispositivos físicos. Desse modo, o provedor de serviços pode atender uma grande quantidade de clientes sem necessitar, ao menos inicialmente, de muitos recursos físicos.

2.2.4 Barreiras

Embora os benefícios sejam notáveis na adoção das nuvens, Strowd (2010) ainda identificou alguns problemas. Segundo ele, os maiores obstáculos são:

Controle de Recursos: o nível de controle que o cliente pode ter sobre os recursos da Nuvem pode variar, dependendo dos provedores do serviço;

Interoperabilidade: ainda não foi definido um conjunto universal de padrões e/ou interfaces, o que pode representar um risco de dependência em relação a fabricantes ou fornecedores;

Latência: considerando que o acesso à Nuvem é realizado pela internet, um atraso é introduzido a cada comunicação entre o usuário e o provedor;

Legislação: existe uma preocupação por parte da comunidade em relação à jurisdição, proteção de dados, práticas éticas no trato de informações e à transferência internacional de dados;

Restrições de plataforma ou idioma: alguns provedores de serviço suportam apenas alguns idiomas e plataformas específicas;

Privacidade: usuários não tem controle dos dados, nem tem conhecimento sobre onde os mesmos estão armazenados.

(23)

2.2.5 Desvantagens da Nuvem pública

Segundo Erl (2013), em nuvens públicas é muito incomum o uso de frameworks de segurança padronizados ou compatíveis, o que introduz vulnerabilidades tais como o fornecimento de acesso privilegiado aos dados. A exposição dos dados somada à sobreposição de políticas de confiança podem propiciar oportunidades de adulteração ou furto de informações por parte de usuários maliciosos.

Outro problema envolve a redução do controle das operações. Uma organização tentando acessar recursos de uma Nuvem poderá, dependendo da distância geográfica, utilizar uma ou mais conexões não-confiáveis para estabelecer uma comunicação. Caso a infraestrutura dessa Nuvem seja fornecida por terceiros, a questão se agrava pois há perda de controle sobre os dados por parte da organização que utiliza o serviço. Além disso, nuvens públicas ainda necessitam lidar com questões relacionadas à portabilidade. Devido à falta de padrões impostos pela indústria, infraestruturas públicas normalmente possuem caráter proprietário. Nesse caso, usuários que utilizam tais soluções proprietárias podem enfrentar problemas ao migrar para outro provedor de serviço em Nuvem (ERL, 2013).

Erl (2013) cita ainda os aspectos legais e as políticas de privacidade envolvendo os dados hospedados em nuvens públicas. Dependendo da legislação do local onde a infraestrutura está alocada, tais dados podem ser confinados ao país ou região ou até mesmo acessados com mais facilidade por empresas governamentais.

Por sua vez, as nuvens privadas – quando aplicadas em um ambiente controlado – dificilmente apresentam os problemas citados nesta seção (ERL, 2013). Portanto, considerando os aspectos citados nessa seção, a modalidade de Nuvem privada foi escolhida para a implantação das soluções propostas neste trabalho.

(24)

3. METODOLOGIA

A metodologia para a realização do trabalho consistiu inicialmente na revisão da literatura, leis, portarias, manuais e documentos formais publicados pelo MEC e Inep relacionados ao Censo da Educação Superior. Foram elencados os conceitos envolvidos, as exigências obrigatórias, os itens que podem ser ainda considerados opcionais pelo Instituto, dentre outras questões. Os layouts de todos os arquivos foram estudados (Curso, Aluno e Docente) com o intuito de compreender o contexto e os requisitos necessários para codificação e decodificação de arquivos de exportação. Isso resultou nos documentos de levantamento de requisitos que serviram para sistematizar os dados correspondentes na Instituição (UEFS).

Após o levantamento dos requisitos, iniciou-se a fase de revisão bibliográfica sobre as abordagens de desenvolvimento Desktop, Web e Processamento em Nuvem. O objetivo principal desta etapa era definir em quais momentos da elaboração dos produtos, respeitando as restrições da Instituição e cronograma do Inep, seria possível aplicar tais abordagens.

Além dos aspectos já citados, algumas linguagens de programação foram avaliadas, na ocasião, para definir qual seria utilizada em cada etapa do desenvolvimento dos produtos. Após investigação, optou-se por utilizar a linguagem Java na primeira etapa do desenvolvimento com abordagem Desktop para desenvolver os codificadores e decodificadores. A motivação na escolha desta abordagem deve-se ao tempo reduzido de produção do programa, além da facilidade em adicionar eventuais interfaces de comunicação com servidores web.

Para a produção da aplicação no contexto desktop foram utilizados: linguagem de programação Java (ORACLE, 2016), kit de desenvolvimento JDK, versão 1.8.0 (Update 75); a ferramenta NetBeans, versão 8.0.2, como ambiente de desenvolvimento; a API JExcelAPI, versão 2.6.12, para tratar da comunicação com arquivos no formato Excel; o Log4j2, versão 2.5, para produzir arquivos de log. O programa foi desenvolvido em uma máquina portando o sistema operacional Windows® 10.

Para a validação dos componentes do Codec Desktop, foram realizados testes de unidade através do framework JUnit, versão 4.12. Para testar a funcionalidade, foram utilizados arquivos – previamente validados e considerados corretos pelo sistema do Inep, fornecidos pelo próprio Instituto – como um dos parâmetros de entrada.

A partir do desenvolvimento do Codec, foi iniciado um estudo visando a implementação de uma interface de comunicação da aplicação desenvolvida com o sistema GeDE. O objetivo deste estudo consistia em possibilitar a execução do codificador e decodificador desenvolvidos para desktop através de uma camada de comunicação, no ambiente web. Mais especificamente,

(25)

utilizando-se dos recursos do sistema GeDE para obtenção direta dos parâmetros necessários à execução, eliminando desta forma a utilização do console com linhas de texto. O fator decisivo para aplicar o PHP na elaboração do protocolo de comunicação para integração ao GeDE se deve pelo fato deste ter sido desenvolvido com a linguagem citada.

Na terceira fase do trabalho, o objetivo consistiu na adequação e implantação do Codec Desktop em uma infraestrutura de Computação em Nuvem, com o objetivo de disponibilizar a solução computacional em larga escala. Logo, foi necessário determinar qual tipo de fornecimento de serviço equivale ao proposto no modelo da aplicação. Pretende-se disponibilizar as operações de codificação e decodificação sob demanda, de modo que o usuário utilize a aplicação de forma transparente, sem conhecimento dos processos internos do sistema. Além disso, o cliente não necessitaria instalar quaisquer programas em sua máquina particular. Dentre as modalidades apresentadas na seção 2.4.1, o tipo SaaS é o mais compatível com a proposta de disponibilizar o serviço de codificação e decodificação em Nuvem.

3.1 Interface de comunicação para execução do Codec em servidor Web

O Codec Desktop desenvolvido faz parte de um conjunto de soluções que visa a integração dos diversos dados de sistemas em uso na UEFS. As informações da instituição requeridas pelo Censo da Educação Superior – referentes aos discentes, docentes e cursos – foram armazenadas em um banco de dados, além de serem desenvolvidas interfaces para a manipulação e gerenciamento de dados, cuja solução foi nomeada como GeDE. O banco, as interfaces de manipulação de dados e o Codec foram desenvolvidos paralelamente, de modo que tecnologias distintas foram utilizadas na implementação e, portanto, não eram capazes de se comunicar. Logo, os arquivos obtidos em uma consulta do banco precisavam ser transferidos manualmente para um diretório do Codec Desktop, a fim de possibilitar as codificações necessárias.

Com o objetivo de transferir os arquivos gerados pelo GeDE de forma direta para o programa codificador e tornar as operações mais transparentes para o usuário, foi elaborada uma interface de comunicação entre os dois sistemas. Dessa maneira, um script em execução no sistema do banco de dados do GeDE realiza chamadas à aplicação codificadora automaticamente, eliminando a intervenção humana no processo e acelerando a produção de arquivos no formato desejado.

(26)

Inicialmente, tal integração será realizada ao inserir o Codec Desktop em um dos diretórios do servidor do banco de dados. O programa codificador servirá, então, como um módulo para a produção de arquivos de exportação do Inep.

Neste novo cenário, considerando os aspectos funcionais, as funcionalidades resultantes da integração das duas aplicações devem permitir ao usuário, no próprio sistema GeDE, a codificação e a decodificação dos arquivos do Censo. Sendo assim, o sistema deve prover ao usuário: a) seleção do layout do arquivo a ser processado (docente, discente ou cursos); b) seleção do curso, se o layout escolhido foi do tipo “discente”; c) seleção do ano correspondente do censo; d) seleção do tipo de operação a ser realizada com o arquivo (codificação ou decodificação).

Antes de executar o Codec Desktop, a aplicação deve verificar se os arquivos foram exportados pelo sistema GeDE. Se os arquivos não estiverem na pasta pré-definida pelo Codec, o programa deve interromper a execução e notificar o usuário sobre o problema.

Figura 1: Etapas de execução do Codec Web

Fonte: Autor

O sistema deverá apresentar os resultados obtidos, informando se a operação foi ou não bem-sucedida. Caso a codificação de um arquivo não seja bem sucedida, os erros devem ser apresentados ao usuário como um arquivo de log, contendo a descrição detalhada do erro e o número da linha correspondente. A sequência simplificada de execução é apresentada na Figura 1.

(27)

O módulo CensoCodecWeb foi desenvolvido em linguagem PHP, cuja versão do interpretador foi a 7.0.10. A IDE utilizada foi o Netbeans, versão 8.1. O servidor web para realização de testes foi o Apache, versão 2.4.23.

A interface web foi estruturada, majoritariamente, através de scripts PHP. Uma representação simplificada das principais funcionalidades dos principais scripts é mostrada na Figura 2.

A página principal é estruturada no script index.php. A interface gráfica do módulo apresenta três dos parâmetros requeridos pelo Codec: tipo de layout a ser utilizado para processamento (aluno, docente, curso), ano do censo e tipo de operação (codificação ou decodificação). No caso especial do discente, o arquivo de alunos é discriminado por cursos.

A comunicação entre os sistemas se dará através da inclusão de um item de menu no sistema GeDE para iniciar o Codec Web. E por sua vez, o Codec deverá conter um botão para permitir ao usuário retornar ao sistema que o invocou (nesse caso, o sistema GeDE).

Figura 2: Estrutura geral do Codec Web

Fonte: Autor

Os dados submetidos ao servidor devem ser processados no script

requestProcessor.php. De maneira geral, as atribuições desse módulo abrangem: tratamento

dos dados externos; verificação da existência dos arquivos utilizados para codificação ou decodificação; repasse dos parâmetros para a rotina de invocação do Codec Desktop. O módulo conta ainda com o auxílio das funções disponibilizadas no script processorFunctions.php. Tal

(28)

script contém as rotinas para: inicialização das etapas de processamento; conversão dos parâmetros externos para o formato exigido pelo Codec; chamada de execução do programa desktop.

A variável POST – utilizada para recarregar a página – é filtrada através da função

htmlentities. Os parâmetros selecionados pelo usuário e enviados pelo formulário HTML

também são filtrados. Caso um ou mais desses parâmetros possuam conteúdo inadequado, o processo de execução é interrompido e uma mensagem de erro é exibida.

Em seguida, os parâmetros são convertidos para o formato aceito pelo Codec Desktop, mostrado nas seções 4.2.1 e 4.2.2. É importante ressaltar que, ao emitir a requisição, o usuário informa apenas os três primeiros parâmetros requeridos pelo Codec. O quarto parâmetro – diretório do arquivo a ser processado – é obtido internamente pelo servidor. Nesse cenário, assume-se que o módulo GeDE exportou previamente os arquivos para o diretório-padrão utilizado pelo Codec. Ainda assim, o Codec Web verifica se tais arquivos existem antes de iniciar o processamento. Caso os mesmos não sejam encontrados, o processamento é interrompido e o usuário recebe uma notificação sobre o problema na seção de resultados.

Outro passo importante no tratamento dos parâmetros refere-se ao escape dos argumentos utilizados na chamada à aplicação desktop. Considerando que o método exec do PHP – utilizado para invocar o Codec Desktop – realiza uma chamada ao sistema operacional, existe um potencial problema de segurança ao permitir que os dados fornecidos externamente (via formulário HTML) sejam utilizados sem tratamento. Logo, o método escapeshellarg foi aplicado a cada um dos argumentos antes que uma chamada ao comando exec fosse realizada. Após o tratamento dos parâmetros, o Codec Desktop é executado. Caso erros sejam detectados, a saída do programa desktop é capturada em uma variável e um log é criado no diretório

codec/logs.

Por fim, o script resultados.php é responsável por exibir as mensagens referentes ao resultado do processamento, além de fornecer as instruções responsáveis pela exibição do botão para download do log quando erros são detectados. O tratamento dos eventos disparados pelos botões de envio de requisição e visualização de log é realizado no arquivo indexHandler.js. No caso particular do botão de log, uma função javascript redireciona a página para o script

downloadLog.php, cuja tarefa é disponibilizar o arquivo de log criado no servidor. Para

contabilizar os erros, o script resultados.php verifica o número de linhas do arquivo de log. Se o arquivo de origem não apresentar inconsistências, o usuário é notificado sobre o sucesso da operação e o arquivo pós-processado (codificado ou decodificado) é criado na pasta dedicada.

(29)

Caso contrário, o script gera uma notificação sobre os problemas encontrados e o arquivo de log torna-se acessível através de um botão. Eventualmente, o script também informa o usuário sobre erros detectados durante o tratamento dos parâmetros.

3.2 Interface para execução do Codec em Nuvem

A terceira etapa do trabalho consiste em implantar a aplicação desenvolvida em Nuvem. O objetivo é ampliar o alcance da ferramenta, disponibilizando-a para outras instituições, além da UEFS. Isso se deve ao interesse já manifestado por outras IES que possuem dificuldades semelhantes à UEFS.

Nesse cenário, deve-se permitir ao usuário: a) seleção do layout do arquivo a ser processado (docente, discente ou cursos); b) seleção do ano do censo; c) seleção do tipo de operação a ser realizada com o arquivo (codificação ou decodificação) e d) carregamento do arquivo a ser processado.

Nesta implementação somente um arquivo deverá ser processado a cada execução do Codec. O sistema deve ainda impedir o carregamento de arquivos cujo tamanho seja superior a 1 MB ou cuja extensão seja diferente do tipo texto. Essas restrições são impostas pelo Inep.

Caso o processamento tenha sido bem-sucedido, uma notificação deve ser emitida e o arquivo processado (codificado ou decodificado) deve ser disponibilizado ao usuário para download. Se erros forem detectados, um arquivo de log deve ser gerado, contendo a descrição do problema e o número da linha onde foi encontrada a inconsistência no arquivo de entrada. A sequência de execução do programa é muito similar àquela apresentada na Figura 1. A única diferença está na etapa de notificação de sucesso, pois além de o usuário ser notificado, o arquivo codificado (ou decodificado) é disponibilizado.

Por fim, a aplicação deve ser implantada em uma infraestrutura de Nuvem e submetida a testes de execução em diferentes cenários para assegurar a disponibilidade do serviço.

A interface do Codec Desktop para implantação em Nuvem, denominada “Censo Codec Cloud”, também foi desenvolvida em linguagem PHP, versão 7.0.10. A IDE utilizada foi o Netbeans, versão 8.1. O servidor web para realização de testes foi o Apache, versão 2.4.23.

A infraestrutura fornecida para execução da aplicação em Nuvem consiste em uma Nuvem privada implementada através de um cluster. Este é composto por três servidores Dell

(30)

servidor possui dois processadores não-virtualizáveis Intel Xeon Quad-Core 5130 de 2.0 GHz, utilizando o Cent OS versão 6.6 como sistema operacional. A aplicação utilizada como gerenciador do cluster foi o OpenNebula Sunstone, versão 4.1.2.1.

A representação simplificada das principais funcionalidades dos scripts, bem como a hierarquia dos mesmos, é mostrada na Figura 3.

Figura 3: Estrutura geral do Codec Cloud

Fonte: Autor

A página principal contém uma referência para o arquivo indexHandler.js, responsável pelo tratamento de eventos, tais como mudança de estado ou acionamento de botões. A página inclui ainda o script requestProcessor.php, cuja tarefa é tratar os parâmetros da requisição, validar o arquivo carregado pelo usuário e encaminhar os dados para o Codec Desktop, de forma semelhante à descrita na seção 3.2.

Por fim, o script resultados.php, também incorporado à página principal, contém a lógica responsável por gerar notificações de saída para o usuário, instruções de acesso ao arquivo de logs (em caso de detecção de erros) ou de acesso ao arquivo pós-processado (no caso de processamento bem-sucedido). Quando nenhuma inconsistência é detectada no arquivo enviado pelo usuário, o script de resultados gera uma instrução HTML para invocar o script de

(31)

download do arquivo processado por intermédio de uma chamada ao script indexHandler.js. Dependendo da operação selecionada pelo usuário, o indexHandler pode acionar o arquivo

downloadArqCodificado.php ou downloadArqDecodificado.php. Estes scripts são responsáveis

(32)

4. RESULTADOS

A seção de resultados apresenta a utilização e validação das três abordagens consideradas na elaboração deste trabalho: o desenvolvimento e a utilização do Codec Desktop na elaboração do Censo 2015 da UEFS; a utilização da interface web para o Codec Desktop, juntamente com a integração com o sistema GeDE; a utilização de interfaces da versão para a Nuvem e a implantação com o OpenNebula.

4.1 Desenvolvimento do Codificador e Decodificador de arquivos do Censo 2014 e

2015 na abordagem Desktop

O desenvolvimento do programa que realiza os processos de codificação e decodificação dos arquivos de exportação do Censo da Educação Superior foi iniciado em um trabalho de Estágio Parcial, na UEFS, mais especificamente na Procuradoria Educacional Institucional.

Desde o início dos trabalhos, existiam as premissas de que o desenvolvimento estivesse alinhado com as restrições da UEFS e as exigências do Inep. Dentre as restrições e exigências, destacam-se o tempo para a implementação dos produtos finais, visando uma adequação ao calendário do Inep e a dificuldade de integração dos dados necessários à codificação. Estes foram fatores determinantes para a tomada de decisão do uso da linguagem Java devido à familiaridade do desenvolvedor com a mesma e para que o trabalho fosse dividido em 3 etapas, sendo a primeira delas a elaboração dos codificadores e decodificadores na abordagem de desenvolvimento desktop.

A elaboração dos produtos aqui descritos obedeceram aos layouts e manuais oficiais do Inep, referentes ao Censos da Educação Superior de 2015. Estes documentos estão disponíveis no site oficial do Inep ( http://portal.inep.gov.br/web/censo-da-educacao-superior/questionarios-e-manuais).

A Figura 4 apresenta a arquitetura simplificada da aplicação CensoCodecDesktop ou, resumidamente, “Codec” (Sistema de Codificação e Decodificação dos arquivos dos Censos 2014 e 2015).

(33)

Figura 4: Versão compacta da arquitetura do Codec Desktop

Fonte: Autor

A classe CensoCodec agrupa as principais entidades utilizadas em uma codificação ou decodificação de arquivos: Layout, ProcessadorLayout e FileManager. A entidade Censo é responsável por fornecer os objetos que herdam as classes Layout e ProcessadorLayout, referentes a um mesmo ano. O módulo FileManager é responsável por tratar o acesso a arquivos, sejam eles do tipo texto ou no formato Excel (xls). A entidade Layout é uma abstração dos layouts oficiais do Inep, responsável unicamente pela criação e fornecimento de uma lista de regras utilizadas para validar o preenchimento dos campos. A lista contém entidades do tipo

RegraCampo, onde cada regra determina como um campo deve ser preenchido, seus valores

válidos, dentre outros aspectos. Cada objeto do tipo RegraCampo pode ou não conter um único objeto Codec, dependendo unicamente do fato do campo permitir ou não uma codificação. Por fim, ProcessadorLayout é uma entidade abstrata, responsável por coletar a lista de objetos

RegraCampo de Layout e, desse modo, validar um arquivo de entrada, codificando-o em um

arquivo de saída.

Para fundamentar a aplicação e elaborar seu levantamento de requisitos foram estudados os layouts e os manuais oficiais que orientam sobre como os arquivos devem ser gerados para importação no sistema do Censo (Inep, 2015). Os layouts definem, entre outros aspectos: a estrutura do cabeçalho do arquivo; quais os registros pertinentes para aluno, docente e curso; o número de campos em cada registro e os valores válidos para cada campo. Para regular a

(34)

estrutura dos campos, o layout também informa o tamanho (número de caracteres requerido), o caráter de preenchimento (obrigatório, opcional ou condicional) e as eventuais dependências condicionais em relação a outros campos. Como exemplo, a Figura 5 - em conjunto com a Figura 6, mostra a linha referente ao campo “Turno do aluno”, oriundo da tabela de layout utilizada como referência para gerar os arquivos de alunos.

Figura 5: Campo “Turno do Aluno” (regras)

Fonte: Inep - Layout de Migração do Aluno (2015)

O campo “Turno do aluno” representa um exemplo de dependência condicional. Conforme a descrição da coluna “Regras”, o arquivo de saída só deve conter alguma informação relacionada ao turno do aluno caso outro campo - “modalidade do curso” - esteja preenchido com o valor “Presencial”. Caso contrário, o campo deve ficar vazio.

Figura 6: Campo “Turno do Aluno” (mensagens de erro)

(35)

Para informar o usuário sobre eventuais problemas nos dados referentes a esse campo, o layout oficial informa o que deve ser comunicado ao usuário nos possíveis cenários de erro, como mostra a Figura 6.

Portanto, antes de realizar o processo de codificação e decodificação, é necessário assegurar que o arquivo atenda aos requisitos do respectivo layout, através de uma validação. Seguindo esse princípio, o Codec verifica se o arquivo fornecido como parâmetro de entrada, está estruturado conforme as regras de seu respectivo layout.

Para validar os campos, além da abstração Layout, foram utilizadas subclasses para representar os seus subtipos (layout de aluno, docente e curso), como mostra a Figura 4. Cada subtipo de layout foi responsável por criar uma lista de objetos do tipo RegraCampo, uma superclasse que agrega as funcionalidades comuns às regras de qualquer campo de layout (e.g.: nome do campo sendo processado, número de caracteres, obrigatoriedade do campo, referência para um eventual Codec, dentre outros).

Com o intuito de efetuar o processamento dos layouts, entidades específicas foram criadas para processar cada tipo de layout. A abstração ProcessadorLayout contém os algoritmos comuns ao processamento de qualquer arquivo cujo formato seja aceitável pela aplicação. Os respectivos subtipos de ProcessadorLayout (com sufixos para alunos, docentes e cursos) estendem a funcionalidade da classe abstrata, conforme a Figura 4. As entidades processadoras contêm as variáveis de controle e os métodos para tratar os casos onde existem dependências condicionais entre os campos de um mesmo layout.

Para leitura e gravação de arquivos, foram incorporadas classes especializadas – subclasses do módulo FileManager - que realizam acesso a arquivos do tipo texto (extensão “txt”) e a planilhas do Microsoft Excel (extensão “xls"). A classe FileManagerTxt realiza o acesso aos arquivos de entrada, além de ser responsável por criar os arquivos de saída. A classe

FileManagerXls é utilizada para acessar as tabelas utilizadas na validação dos eventuais códigos

(como por exemplo, códigos de município, UF, dentre outros) presentes em campos, fornecidos pelo arquivo de entrada.

O programa requer que o arquivo de entrada contenha: um cabeçalho, indicando o tipo de arquivo e a Instituição ao qual ele se refere; um registro por linha, para os dados de cada entidade (curso, docente, discente), onde cada linha é iniciada por um código que indica os tipos de dados que estas contêm (como na Figura 7, os códigos 31 – representa os dados censitários e 32 – indica os códigos dos cursos relacionados à entidade em questão). Além disso, segundo as indicações dos manuais oficiais do Inep, os campos em cada linha devem estar separados por

(36)

barras verticais (campo1|campo2|...|campoN). Um exemplo é apresentado na Figura 7, onde é possível visualizar um registro do arquivo “professores.txt”, estruturado segundo o layout oficial de docentes. A quantidade de campos também é verificada, com o intuito de assegurar que o número de campos em um registro do arquivo corresponda à mesma quantidade determinada pelo layout. Caso o arquivo apresente qualquer um desses erros, o sistema notifica o usuário com uma mensagem sobre o problema conforme especificações da coluna “Mensagens” (Figura 6) e encerra a aplicação.

Figura 7: Arquivo com dados de docentes

Fonte: Autor

Com o objetivo de garantir a consistência entre as classes que processam o arquivo, os respectivos layouts e o período do Censo a ser processado, foi criada a classe abstrata Censo e suas extensões - Censo2014 e Censo2015. Os sufixos das subclasses representam o período de abrangência do censo. A estrutura formada pela abstração Censo e seus subtipos corresponde àquela sugerida pelo padrão de projetos conhecido como Abstract Factory (GAMMA et al, 1995).

Figura 8: Hierarquia de classes da estrutura Censo

(37)

A relação entre a classe abstrata e suas subclasses concretas é ilustrada na Figura 8. A consistência na programação é assegurada nesse caso, pois, ao invocar a classe Censo2015, o processador e o layout fornecidos pela entidade Censo seguem as diretrizes do censo do ano 2015. Os objetos fornecidos por uma subclasse do tipo Censo são mostrados na Figura 9.

Figura 9: Composição do objeto Censo2015 com layouts e os respectivos processadores

Fonte: Autor

Outro aspecto levado em consideração durante o desenvolvimento foi a possibilidade de utilizar o programa em censos posteriores. O código elaborado está preparado para ser reutilizado, estendido ou seus métodos sobrescritos no escopo de uma nova classe. No caso de um novo campo, é suficiente estender a classe RegraCampo e determinar as regras específicas para sua construção na subclasse recém-criada. A fábrica Censo, por ser abstrata, sempre requer implementação. No entanto, a estrutura da nova subclasse é muito similar às fábricas concretas já existentes. Vale ressaltar que cada instância dos censos na Figura 8 contém a mesma estrutura arquitetural apresentada na Figura 9.

Após a criação dos layouts e seus respectivos processadores pela classe fábrica Censo, a classe Layout realiza a ligação entre o processador e as regras. Caso o arquivo seja de alunos, um subtipo da classe LayoutAluno correspondente ao ano do Censo (por exemplo,

LayoutAluno2015) é invocada e este cria as regras do referido layout. Posteriormente, o

processador do layout – um subtipo de ProcessadorLayoutAluno (seguindo o exemplo anterior,

Referências

Documentos relacionados

a) Baixa aderência ao tratamento; o uso incorreto do dispositivo inalatório; o diagnóstico incorreto de asma e; a presença de comorbidades, tais como, rinossinusite, refluxo

Reciclando se diminui a poluição do meio ambiente A sustentabilidade também é uma vantagem, pois reciclar significa recapturar materiais, que voltam a ser usados em

d) Transferir de propriedade o veículo segurado e não informar à Seguradora. e) Fornecer CPF/CNPJ incorreto/inexistente na proposta de seguro. f) Retirar ou desligar o Dispositivo

void enqueue(Item item) coloca item nesta fila Item dequeue() remove o item mais. antigo desta fila boolean isEmpty() esta fila

Implemente um método chamado empilharImpar que deve inserir na pilha apenas o número que seja ímpar, caso contrário deverá ser exibido uma mensagem informando que o número não

No final, o programa deve mostrar todos os números em ordem crescente.. 10) O processo de ordenação de vetores que busca o menor elemento do vetor e o insere na primeira posição

[r]

• Retorna o elemento desejado caso existe e -1 caso o elemento não exista. Collection letras =