A avaliação e os testes do ambiente de integração são apresentados nas próximas subseções seguintes.
6.1 Discussões do BOCA-LAB
O ambiente de integração desenvolvido foi, inici- almente, implantado em um servidor do Departamento de Engenharia de Teleinformática (DETI) da Universidade Federal do Ceará (UFC). Experimentações iniciais foram realizadas no ano de 2011 em turmas da disciplina de Técnicas de Programação para Engenharia I, do curso de Engenharia de Teleinformática, e de Fundamentos de Programação, do Departamento de Computação. Foi avaliada a percepção dos alunos sobre o ambiente e os resultados podem ser vistos em [29].
O ambiente encontra-se atualmente instalado em um servidor mantido em colaboração entre o DETI e a UFC Virtual, e vem sendo usado, com acompanhamento da equipe responsável por esta pesquisa, em turmas nu- merosas de primeiro ano do curso de Engenharia de Te- leinformática desde 2012. As experiências de alunos e professores com a ferramenta tem permitindo o amadure- cimento de aspectos relacionados à usabilidade e à inter- face. Essa experiência é importante para realizar os ajus- tes necessários e garantir a confiabilidade antes que a ferramenta seja disponibilizada para a comunidade em vários formatos: integração com Moodle, versão standa-
lone do BOCA-LAB e módulo independente para a Aná-
lise de Similaridade.
Uma dificuldade que se apresentou para o uso sistemático do BOCA-LAB nas práticas de laboratório semanal é a necessidade de elaboração de exercícios com as restrições impostas pelo sistema BOCA, em que um programa deve ser avaliado para uma entrada e uma saída padronizadas. Isso requer que o professor não só elabore o enunciado, mas prepare os arquivos de entrada e de saída que serão usados como insumo para a validação das soluções dos alunos. Além disso, para testar diversas condições de um problema, é preciso preparar diversas pares de arquivos de entrada e saída. A fim de certificar- se que as entradas e as saídas estão absolutamente corre- tas, faz-se necessário, nessa abordagem, que o professor
desenvolva também a solução para o problema. Essa situação não ocorre usualmente em abordagens tradicio- nais com a proposição de listas de problemas em turmas de programação, em que o professor, pela sua própria experiência, precisa inferir apenas o nível de dificuldade de uma questão antes de apresentá-la aos alunos.
Pelo fato de a validação da saída ser efetuada por comparação de strings (comando diff), outra dificuldade se revela: o sistema é muito sensível a pequenas altera- ções de formatação e apresentação de saídas (ex.: uso de diferentes textos como prompt de entrada, uso de caracte- res especiais como separadores de valores de saída, etc.). Isso requer uma elaboração de enunciado muito detalhada e precisa por parte do professor, e atenção especial por parte do aluno no desenvolvimento de sua solução. Essas restrições acrescentam dificuldades que não são direta- mente associadas à natureza do problema. Em uma mara- tona de programação, esse tipo de restrição não represen- ta obstáculos aos usuários, em geral, programadores mais experientes. Entretanto, para um público de iniciantes, restrições dessa natureza exigem um aculturamento que apenas se constrói em múltiplas práticas.
Do ponto de vista do professor, as limitações dis- cutidas, entretanto, podem ser mitigadas com o desenvol- vimento de algumas rotinas de apoio e melhorias na inter- face. Requisitos associados a este tipo de limitação vem sendo elencados, discutidos e estão servindo de insumo para a melhoria da ferramenta. O uso repetido da ferra- menta vem permitindo, também, que se forme uma base de exercícios e enunciados que atendem aos requisitos do ambiente desenvolvido, o que irá facilitar, sobremaneira, a utilização em diferentes turmas ao longo do tempo. É importante salientar que, se o BOCA-LAB, por um lado, requer um tempo maior para elaboração e preparação de atividades, por outro lado, vem demonstrando grande vantagem para validação de trabalhos propostos aos alu- nos em aulas de laboratório, otimizando o tempo de pro- fessores e monitores. Além disso, o sistema vem sendo utilizado com eficácia para a proposição de atividades em forma de prova, dispensando o tempo usualmente empre- gado para correção e atribuição de notas, situação crítica para o professor em turmas numerosas.
Pela perspectiva do aluno iniciante, uma dificul- dade de cunho operacional se manifestou logo nas primei- ras atividades. O desenvolvimento da prática de laborató- rio não é feita diretamente no BOCA-LAB. A metodolo- gia empregada é a de utilização do compilador e testes na máquina local e submissão do programa fonte ao BOCA- LAB apenas após o desenvolvimento supostamente cor- reto por parte do aluno. Percebeu-se que, sistematicamen- te, o aluno submetia o arquivo errado para validação remota. Esse problema foi mitigado com a submissão do código através de um editor embutido na atividade criada
Sistema de apoio a atividades de laboratório de programação via Moodle com suporte ao balanceamento de carga e análise de similaridade de código
França et al.
101
no Moodle, em que o aluno pode “colar” o seu código- fonte e, em seguida, realizar a submissão. Outra dificul- dade inicial é a interpretação das mensagens de erro apre- sentadas pelo sistema, principalmente quando a mensa- gem indica um problema de apresentação, o que requer as adequações de formatação já discutidas anteriormente. Apesar do tempo necessário para ambientação com esse tipo de ferramenta, percebe-se o desenvolvimento pro- gressivo de maior autonomia do aluno para o desenvol- vimento das soluções aos problemas propostos, em que ele se torna capaz de reagir às mensagens da ferramenta e corrigir os problemas sem a necessidade contínua de interação com professores e monitores.
A subseção seguinte apresenta os resultados de testes relativos ao balanceamento de carga.
6.2 Testes sobre o Controle e Balanceamento de Carga
Para avaliar a eficácia do balanceamento de carga, dois cenários de teste, ambos com 3 Servidores BOCA- LAB foram configurados. No cenário I, o Servidor I foi configurado com o compilador C e C++, o Servidor II foi configurado com os compiladores C e Java e o Servidor III foi configurado apenas com o compilador C++. Nesse cenário, todos os servidores foram limitados para o pro- cessamento de até 50 jobs simultâneos.
Para o primeiro teste, foram submetidos 80 códigos fonte divididos da seguinte maneira: 70 códigos em C e 10 códigos em Java.
Ao final do primeiro teste, a divisão dos códigos entre os servidores se deu da seguinte maneira: 33 jobs proces- sados no Servidor I, 47 jobs processados no servidor II e 0 no servidor
No cenário de teste I, portanto, temos que: o servidor I recebeu 33 códigos da linguagem C; dos 47 códigos recebidos pelo servidor II, 37 foram da linguagem C e 10 da linguagem Java e; como esperado, o servidor III não recebeu nenhum código fonte, pois somente apresentava o compilador para a linguagem C++.
No segundo cenário, os servidores I e II foram confi- gurados de maneira idêntica, contendo compiladores C e C++ e com capacidade de processar até 50 jobs simultâ- neos. O Servidor III foi configurado com apenas o compi- lador Java e com o limite de 25 jobs simultâneos.
Para esse segundo cenário, foram submetidos simulta- neamente 90 códigos, divididos da seguinte maneira: 45 códigos em C, 25 códigos em Java e 20 em C++.
Conforme especificado, a distribuição dos códigos pe- los servidores ocorreu da seguinte maneira: os Servidores
I e II receberam todos os 65 jobs relativos aos programas em C e C++, sendo distribuídos em número de 30 para o primeiro e 35 para o segundo. Já o Servidor III, único que disponibiliza o compilador Java, recebeu todos os 25 jobs nessa linguagem.
Dos códigos recebidos pelo servidor I, 17 foram em linguagem C e 13 em C++. No servidor II, 28 códigos em linguagem C e 7 em C++ foram recebidos. No servidor III, único que possui compilador na linguagem Java, os 25 códigos nessa linguagem foram recebidos.
Através desses dois testes em cenários diferentes, foi possível verificar o funcionamento adequado da distribui- ção e do balanceamento de carga da arquitetura, em fun- ção da capacidade configurada e dos compiladores dispo- níveis em cada servidor, bem como a capacidade de ende- reçamento executada pelo módulo Minfo.
6.3 Avaliação do Módulo de Análise de Simi- laridade
A análise de similaridade foi avaliada em uma turma iniciante em programação, com a linguagem C, durante o 1º semestre de 2012. A turma é formada por 97 alunos divididos em 4 grupos. Cada grupo realizou 4 atividades contendo 2 problemas diferentes, perfazendo, ao todo, 32 problemas.
Para avaliar as quatro técnicas de normalização de có- digos desenvolvidas, os resultados da análise de similari- dade foram comparados entre si. Além disso, compara- ram-se, também, aos resultados apresentados pelas ferra- mentas JPlag e MOSS.
Tabela 4: Comparação entre as 4 técnicas de normalização
A Tabela 4 relaciona a quantidade de códigos que apresentam índice de similaridade maior do que 20% e 70% para cada tipo de normalização. A análise da Tabela mostra que, em geral, a sensibilidade à identificação de similaridade apresenta um comportamento crescente da técnica 1 para a técnica 4. Entretanto, pode-se observar que, para alguns problemas, como o de número 8, essa característica não se confirma em relação às técnicas 2, 3
RBIE V.21 N.1 – 2013 França et al.
102
e 4, sendo, na verdade, invertidas. Isso mostra que as técnicas podem revelar semelhanças que vão além da organização estrutural do código, fornecendo elementos de análise diferenciados para o professor.
As Figuras 6, 7, 8 e 9 apresentam os gráficos compa- rativos do número de ocorrência de similaridades para os grupos A, B, E e D da turma de programação, levando-se em consideração apenas as técnicas de normalização 1 e 4, além do JPlag e do MOSS. Pela baixa incidência de similaridade apontada pela técnica de normalização 1 em relação às demais, infere-se que a técnica 1 produz os resultados menos significativos. Além disso, o JPlag, praticamente em todos os problemas, indica o maior nú- mero de casos de similaridade, e, por outro lado, o MOSS sempre aponta o menor número de similaridades registra-
das. Isso demonstra que a sensibilidade utilizada pelo MOSS é a mais conservadora para indicação de similari- dade. A técnica de normalização 4, com o uso do Sher- lock, apresenta resultados intermediários entre os do MOSS e do JPlag em 62% dos problemas para os regis- tros de similaridades acima de 70%. demonstrando, as- sim, constituir-se em uma promissora ferramenta de análi- se. Um aspecto importante da técnica 4 associada ao Sherlock é a redução expressiva do tamanho do código a ser comparado devido à eliminação de grande parte do código, o que, na maioria das vezes, permitirá o proces- samento mais rápido da comparação.
Figura 6: Grupo A: relação da técnica 1 e 4 com JPlag e MOSS
Figura 7: Grupo B: relação da técnica 1 e 4 com JPlag e MOSS
Sistema de apoio a atividades de laboratório de programação via Moodle com suporte ao balanceamento de carga e análise de similaridade de código
França et al.
103
Figura 9: Grupo D: relação da técnica 1 e 4 com JPlag e MOSS
O uso do Sherlock com a técnica de normalização 4, em algumas situações, pode apresentar maior ocorrência de similaridade do que o JPlag, como pode ser observado pelo problema 31, que propõe a impressão por extenso do valor de um algarismo inteiro. A análise visual dos códi- gos dos alunos mostrou que quase todos desenvolveram uma solução com o uso do swicth, com código bastante semelhante, o que foi feito por orientação do professor (e poderia também ter sido conseqüência da uso de algum exemplo encontrado em fontes de referência). Na pers- pectiva da similaridade, os resultados não são, portanto, considerados falsos positivos para essa questão. Assim, verifica-se que os resultados do Sherlock com a normali- zação 4 foram mais significativos do que os apresentados pelo JPlag e MOSS.