Este capítulo iniciou discutindo a construção da linguagem de programação apelidada de Escracho. Trata-se de uma linguagem onde os programas são construídos através do encaixe de componentes visuais que representam estruturas de programação. Esta linguagem foi embutida em
todos os três softwares que foram utilizados nos experimentos com os alunos, de maneira que a variável “presença da linguagem Escracho” permaneceu constante em todos os experimentos.
Além da linguagem de programação mencionada anteriormente esta pesquisa requereu a construção de um mecanismo de correção automática de programas. Com este mecanismo foi possível automatizar o processo de correção dos programas construídos pelos alunos e permitir, por exemplo, que avançassem ou não no jogo de acordo com a corretude dos seus programas.
A primeira etapa da correção automatizada dos programas construídos pelos alunos é a verificação sintática. As estruturas de programação disponibilizadas na linguagem Escracho podem ser encaixadas umas nas outras, desde que sejam respeitadas algumas restrições sintáticas. Por exemplo, não é possível colocar um laço de repetição como condição para um desvio condicional.
Desta maneira, a verificação sintática realizada pelo mecanismo de correção automática fica bastante simplificada, já que muitos dos possíveis erros sintáticos tornam-se impossíveis de serem cometidos. Então, a verificação sintática neste caso resume-se a coisas como: verificar se um desvio condicional ou um loop possui uma condição, verificar se um componente de atribuição possui uma variável e uma expressão (a expressão é atribuída para a variável), etc.
Uma segunda etapa na correção automática dos programas é a verificação estrutural. Neste ponto do processo de correção, a estrutura do programa é comparada com um conjunto de estruturas que representam possíveis soluções para o problema algorítmico que está sendo corrigido. Os programas dos alunos são representados logicamente como árvores sintáticas abstratas (ASTs).
Durante a comparação, estas ASTs são convertidas em uma representação textual, onde cada nó da árvore é convertido em um identificador numérico único, de acordo com o tipo do nó. Sendo assim, a representação textual de uma AST consiste na concatenação de uma séria de números, cada um deles representando um tipo de estrutura de programação (um nó da AST). As soluções para um determinado problema também são representadas textualmente, seguindo o mesmo procedimento da serialização das ASTs. Sendo assim, a comparação entre as estruturas de dois programas resume-se à comparação de duas strings, uma representando a estrutura do programa do aluno e outra contendo a estrutura gabarito.
Para determinar o grau de similaridade entre as strings que representam as estruturas dos programas foi utilizado o algoritmo da distância de Levenshtein. Este algoritmo retorna o custo necessário para se transformar uma string em outra, considerando as inserções, remoções ou
substituições de caracteres. Cada uma destas ações provoca um aumento no custo total de transformação retornado pelo algoritmo. Entretanto, o custo total fornecido é um número que pode aumentar em função da quantidade de caracteres das strings que estão sendo comparadas. Sendo assim, fez-se uma pequena alteração no algoritmo para retornar um custo normalizado, um valor entre 0 e 1, onde 0 representa nenhuma similaridade entre as strings e 1 representa similaridade total.
A linguagem de programação e o mecanismo de correção foram utilizados nos três softwares, cada software construído para um experimento com uma turma de alunos diferente. Nos dois primeiros os alunos só acessavam o segundo desafio depois de ter resolvido o primeiro, só acessavam o terceiro depois de ter resolvido o segundo, e assim por diante. Já no terceiro protótipo, o jogo, o acesso aos desafios podia acontecer em qualquer ordem. Entretanto, para resolver o último desafio do jogo todos os demais precisavam estar resolvidos. A princípio, havia se planejado que o acesso aos desafios dentro do jogo também seria seqüencial. Entretanto, esta seqüencialidade não é desejável em um jogo, pois é interessante dar ao jogador a opção de atingir o mesmo objetivo final por diferentes caminhos.
Em todos os três softwares os alunos resolveram o mesmo conjunto de problemas algorítmicos. Entretanto, em cada software utilizou-se um nível de contextualização diferente para os enunciados dos problemas. Inicialmente os enunciados foram criados para o jogo, onde o nível de contextualização foi o mais alto. No segundo software os enunciados tinham um nível intermediário de contextualização, pois os alunos receberam apenas imagens e descrições textuais do jogo, mas não jogaram realmente. O primeiro software tinha o nível mais baixo de contextualização, e os enunciados não faziam qualquer referência ao jogo. A descrição dos problemas era mais abstrata e, por exemplo, as referências aos elementos do jogo foram substituídas por variáveis genéricas como x e y.
O desempenho dos alunos foi mensurado antes (pré-teste) e depois (pós-teste) da utilização de cada um dos softwares por meio de um mesmo instrumento de avaliação. Os pré-testes foram realizados por volta da terceira semana de aula do semestre letivo, enquanto os pós-testes foram realizados por volta da penúltima semana. O instrumento de avaliação que foi utilizado continha 10 questões de múltipla escolha envolvendo os tópicos de interesse da pesquisa. As questões foram classificadas segundo a taxonomia de Bloom, tomando como base as classificações feitas por Whalley et al (2006) e Lister et al (2004). Os detalhes do instrumento de avaliação são apresentados
no Apêndice B. Uma discussão sobre este instrumento foi publicada em Jesus e Raabe (2009), e Motta (2010) utilizou-o em um experimento para mensurar o potencial pedagógico de uma ferramenta para apoiar a aprendizagem de programação em Java.
5 RESULTADOS
Para responder aos questionamentos levantados nesta pesquisa foram realizados experimentos com 3 turmas de alunos de programação introdutória. Cada experimento foi dividido em 3 etapas, a saber: pré-teste no início do semestre letivo, intervenção com um software em meados do semestre e um pós-teste ao final do período letivo.
Participaram dos experimentos alunos de 3 turmas do primeiro semestre de Ciência da Computação na Universidade do Vale do Itajaí (UNIVALI). Uma destas turmas de alunos foi tratada como grupo de controle, e as duas turmas restantes foram tratadas respectivamente como grupo experimental 1 e 2. Os experimentos com o grupo de controle foram realizados no segundo semestre de 2009, e os experimentos com os dois grupos experimentais foram realizados no primeiro semestre de 2010. Na ocasião da realização dos experimentos dois professores eram responsáveis pelas turmas de alunos, sendo que duas das turmas estavam sob a responsabilidade de um professor e a terceira turma sob a responsabilidade de outro. Os professores trabalharam de forma integrada e os planos de ensino utilizados nas disciplinas eram bastante semelhantes. Isso contribuiu para que o mesmo cronograma planejado para os experimentos pudesse ser aplicado sem maiores alterações em todas as 3 turmas.
Neste capítulo são apresentados apenas os dados dos alunos que participaram de todas as etapas dos experimentos mencionados anteriormente: o pré-teste, a intervenção com um software e o pós-teste. Os dados dos alunos que não participaram de qualquer uma destas 3 etapas foram excluídos das análises. Muitos alunos iniciaram os experimentos respondendo ao pré-teste mas não participaram das outras etapas (utilização do software e pós-teste). Como os pós-testes foram realizados ao final do semestre letivo muitos dos alunos que iniciaram o experimento acabaram desistindo da disciplina, fato muito comum em disciplinas de programação introdutória. Alunos que, por exemplo, faltaram as aulas nos dias em que foram realizadas as intervenções também foram excluídos da amostra. Todos os dados coletados, incluindo aqueles que não são analisados neste capítulo, são apresentados no Apêndice C.
Na discussão dos resultados dos experimentos alguns testes estatísticos foram aplicados, e nestes casos utilizou-se o valor p para determinar a aceitação ou rejeição de hipóteses. Currel e Dowman (2009) definem o valor p como a probabilidade de rejeitar a hipótese nula quando de fato
ela é verdadeira. Segundo Larson e Farber (2004), a hipótese nula deve ser rejeitada quando o valor p for menor ou igual ao nível de significância adotado para o teste (geralmente 0,05).