Desenvolvimento do Codificador e Decodificador de arquivos do Censo 2014 e

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).

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

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)

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

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

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,

estas representadas individualmente por objetos RegraCampo - com o intuito de realizar a validação e eventuais codificações/decodificações.

Por sua vez, cada objeto do tipo RegraCampo pode, eventualmente, conter uma referência para um objeto do tipo Codec e um objeto do tipo ProcessadorLayout. Tais referências são criadas no instante em que as instâncias das regras são definidas pelas classes do tipo Layout.

No entanto, nem todos os campos precisam ser decodificados ou codificados. Nesses casos, um valor nulo é atribuído à referência do Codec e, consequentemente, os campos originais são repassados sem modificação para o arquivo de saída. Já a associação entre o objeto

RegraCampo e o ProcessadorLayout visa permitir que dependências condicionais sejam

tratadas mais facilmente durante o processo de validação um campo.

O núcleo funcional da aplicação, que a caracteriza como codificadora e decodificadora de arquivos, é a classe Codec. Ela é responsável pela codificação e decodificação de um campo específico. A estrutura básica da classe é mostrada na Figura 10.

Figura 10: Estrutura interna da classe Codec

Fonte: Autor

Um objeto Codec encapsula os algoritmos para as operações de Codec, recebendo como argumento, em seu construtor, uma tabela hash encapsulada por um objeto do tipo

MapaOpcoes. Tal tabela é a representação, no programa, do conjunto de opções válidas para

um campo em particular. Uma entrada da tabela contém como chave um dos códigos aceitáveis para aquele campo. O valor associado à chave é a descrição da opção, conforme o layout oficial. Essa estrutura de processamento permite que a classe Codec seja extremamente flexível, além de possibilitar a reutilização dos seus algoritmos em qualquer conjunto de opções válidas especificado para um campo. A entidade também assegura a coerência e reversibilidade das

operações, uma vez que os métodos de codificação e decodificação utilizam os dados de uma mesma tabela como referência. Caso surja um novo campo que requer uma lista de opções codificáveis, basta implementar a respectiva tabela de opções em um objeto MapaOpcoes e repassá-la para o objeto Codec recém-criado.

Durante a validação do arquivo, é gerado um relatório de erros e advertências – por meio de logs – informando: o nome do campo do layout que originou o erro ou advertência, o número da linha onde ocorreu o problema no arquivo e uma breve descrição da causa do evento. Os logs podem ser direcionados para o console do usuário, mas é possível redirecionar a saída para um arquivo de exportação do tipo texto.

Os arquivos gerados pelo sistema são alocados em um subdiretório específico da pasta raiz da aplicação. Codificações são armazenadas no caminho raiz/arquivos/codificados e decodificações em raiz/arquivos/decodificados.