avaliaÇÃo empÍrica da utilizaÇÃo de um jogo para auxiliar a ...siaibib01.univali.br/pdf/elieser...
TRANSCRIPT
ELIESER ADEMIR DE JESUS
AVALIAÇÃO EMPÍRICA DA UTILIZAÇÃO DE UM JOGO PARA AUXILIAR A APRENDIZAGEM DE PROGRAMAÇÃO
São José (SC), agosto de 2010
UNIVERSIDADE DO VALE DO ITAJAÍ
CURSO DE MESTRADO ACADÊMICO EM
COMPUTAÇÃO APLICADA
AVALIAÇÃO EMPÍRICA DA UTILIZAÇÃO DE UM JOGO PARA AUXILIAR A APRENDIZAGEM DE PROGRAMAÇÃO
por
Elieser Ademir de Jesus Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Computação Aplicada. Orientador: André Luis Alice Raabe, Dr.
São José (SC), agosto de 2010
FOLHA DE APROVAÇÃO
Esta página é reservada para inclusão da folha de assinaturas, a ser disponibilizada pela
Secretaria do Curso para coleta da assinatura no ato da defesa.
Dedico este trabalho à minha esposa Edmara Gazaniga (concubina para fins de declaração de IR), companheira de longa data com quem tenho dividido minhas conquistas e minhas derrotas, e com
quem tenho encarado a missão de educar nossa pequena Sofia.
AGRADECIMENTOS
Agradeço a meu orientador André L. A. Raabe pelas grandes contribuições em minha jovem
carreira de professor e pesquisador.
Agradeço também aos membros da banca deste trabalho que deram valiosas contribuições
para o enriquecimento da pesquisa.
Agradeço a professora Elisangela Maschio de Miranda que gentilmente permitiu que a sua
disciplina de Algoritmos fosse invadida durante a realização dos experimentos.
Agradeço ao colega Luiz Fernando Noschang, pois sem ele vários problemas nos softwares
que foram utilizados nos experimentos não teriam sido detectados e corrigidos a tempo.
Agradeço aos colegas do laboratório L2S na UNIVALI que ajudaram a testar cada um dos
softwares que foram desenvolvidos durante esta pesquisa.
Agradeço a colega Rúbia Alexandra de Souza, que mais uma vez “salvou o dia”
emprestando o seu talento como designer para melhorar a aparência do jogo.
Agradeço a todos os alunos das 3 turmas dos primeiros períodos que participaram desta
pesquisa, pois sem eles não haveriam dados para analisar.
Agradeço a todos os demais que mereciam agradecimentos e que provavelmente eu me
esqueci de agradecer!
AVALIAÇÃO EMPÍRICA DA UTILIZAÇÃO DE UM JOGO PARA AUXILIAR A APRENDIZAGEM DE PROGRAMAÇÃO
Elieser Ademir de Jesus
agosto / 2010
Orientador: André Luis Alice Raabe, Dr.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Inteligência Aplicada
Palavras-chave: Programação Introdutória, Avaliação Empírica, Aprendizagem Baseada em Jogos.
Número de páginas: 151
RESUMO As disciplinas introdutórias sobre lógica de programação de computadores costumam
apresentar altos índices de reprovação e desistência. Ao longo dos anos professores e pesquisadores vêm adotando diversas alternativas para apoiar a aprendizagem de programação, entre elas, a utilização de jogos digitais. Nesta pesquisa buscou-se avaliar quantitativamente a seguinte questão: De que forma a utilização de um jogo de computador focado na resolução de problemas algorítmicos influencia a aprendizagem de programação introdutória? Foram realizados experimentos com três turmas de alunos que responderam um pré-teste, utilizaram um software e responderam a um pós-teste. Nestes experimentos os alunos solucionaram problemas algorítmicos em uma ferramenta construída para permitir a elaboração de programas graficamente através do encaixe de componentes. A ferramenta foi dotada de um mecanismo de correção automática dos problemas propostos, de maneira que os alunos puderam obter feedback automatizado sobre a corretude das suas soluções. Todos os alunos resolveram o mesmo conjunto de problemas, mas cada uma das três turmas trabalhou com um nível diferente de contextualização nos enunciados. A turma que lidou com os enunciados mais abstratos (nível mais baixo de contextualização) foi tratada como o grupo de controle, e as duas turmas que utilizaram níveis mais altos de contextualização foram tratadas como grupos experimentais. No nível mais alto de contextualização os alunos resolveram os desafios algorítmicos dentro de um jogo. Esta variação no nível de contextualização foi utilizada para responder a uma segunda questão: A utilização de um jogo melhora a aprendizagem ou este mesmo resultado pode ser alcançado apenas com a utilização de problemas de programação melhor contextualizados? Estas questões foram respondidas comparando-se o desempenho das turmas de alunos entre si. O desempenho das turmas foi determinado por dois aspectos: 1) a média das diferenças entre a pontuação de pós e pré teste; e 2) o progresso nos níveis da taxonomia de Bloom. Para isto foi elaborado um instrumento de avaliação (aplicado tanto no pré quanto no pós teste) com questões classificadas segundo esta taxonomia. A análise dos dados mostrou que o progresso dos grupos experimentais não foi superior ao progresso do grupo de controle (eles foram equivalentes entre si). Entretanto, foram obtidas evidências mais fracas (sem comprovação estatística) sugerindo que o jogo pode auxiliar a aprendizagem de alunos com dificuldades, além de favorecer a aplicação do conhecimento adquirido. A validade destes resultados é discutida em maiores detalhes nas conclusões deste trabalho.
EMPIRICAL EVALUATION ABOUT THE USE OF A GAME TO AID THE PROGRAMMING LEARNING
Elieser Ademir de Jesus
August / 2010
Advisor: André Luis Alice Raabe, Dr.
Area of Concentration: Applied Computer Science
Research Line: Applied Intelligence
Keywords: Introductory Programming, Empirical Evaluation, Game Based Learning.
Number of pages: 151
ABSTRACT
Introductory courses on logic programming have high dropout and failure rates. Over the years, teachers and researchers have tried various options to support the learning of computer programming, including the use of digital games. This study quantitatively evaluates the question: How does the use of a computer game focused on solving algorithmic problems influence the introductory learning of programming? Experiments were conducted with three groups of students who answered a pre-test, using a software program, and completed a post-test. In the experiments, the students solved a set of algorithmic problems in a tool built to enable the graphic development of programs, by dragging and dropping components. The tool was equipped with an automatic correction mechanism of the proposed algorithm problems, so that the students could receive feedback on the correctness of their solutions. All the students solved the same set of problems, but each of the three groups worked with a different level of contextualization in the description of the problems. The class that dealt with the more abstract descriptions (lowest level of contextualization) was treated as the control group, and the two groups who used higher levels of contextualization were treated as experimental groups. At the highest level of contextualization, the students solved the algorithmic challenges in a game. This variation in the level of contextualization was used to answer a second question: Does using a game improve learning, or can the same improvement be achieved with the use of better contextualized programming problems? These questions were answered by comparing the performance of the two groups of students. The performance of the groups was determined by: 1) the average differences between the pre- and post-test scores, and 2) progress in the levels of Bloom's taxonomy. An assessment tool (used both in the pre- and post-tests) was prepared with questions classified according to this taxonomy. The data analysis showed that the progress of the experimental groups was not higher than that of the control group (both groups were the same). However, weaker evidence (no statistical results) was obtained, suggesting that the game can assist students classified as "having difficulty", and promote the application of the knowledge acquired. The validity of these results is discussed in the conclusions of this work.
LISTA DE ILUSTRAÇÕES
Figura 1. Esquema que foi utilizado em cada um dos experimentos.................................................23 Figura 2. Estrutura da taxonomia de Bloom revisada........................................................................37 Figura 3. Exemplo do processo de construção e serialização de uma AST.......................................48 Figura 4. Laços aninhados - projeto Game2Learn .............................................................................55 Figura 5. Configurando o corpo de um loop aninhado do W’us Castle.............................................57 Figura 6. Uma batalha em andamento no Robocode .........................................................................59 Figura 7. Agente Javy fornecendo uma explicação para o aluno.......................................................61 Figura 8. Visão geral do software Alice ............................................................................................62 Figura 9. Aspecto de um programa no Scratch..................................................................................65 Figura 10. Componentes da linguagem Escracho sendo usados para construir um programa..........75 Figura 11. Representação em árvore de um programa construído no Escracho ................................76 Figura 12. Classes utilizadas para representar os comandos da linguagem Escracho .......................77 Figura 13. Classes dos tipos de expressões disponíveis na linguagem Escracho..............................78 Figura 14. Classes utilizadas na correção de um algoritmo...............................................................81 Figura 15. Software utilizado com o grupo de controle (enunciados sem contextualização)............85 Figura 16. Software do 2º experimento (nível intermediário de contextualização)...........................86 Figura 17. Vista de cima da estação espacial onde o robô está sendo controlado pelo aluno ...........88 Figura 18. Visão geral do jogo...........................................................................................................89 Figura 19. Fatores de aprendizagem das classes de alunos (classificação pelo pós-teste) ..............105 Figura 20. Fatores de aprendizagem das classes de alunos (classificação pela MF) .......................107 Figura 21. Desempenho das turmas nos níveis da taxonomia de Bloom.........................................111 Figura 22. Sala do desafio 1.............................................................................................................135 Figura 23. Robô em uma sala com buracos no chão........................................................................137 Figura 24. Sala com interruptores de energia ..................................................................................138 Figura 25. Sala com duas fileiras de interruptores de energia .........................................................138 Figura 26. Sala com uma matriz de interruptores de energia...........................................................139 Figura 27. Sala do desafio 9.............................................................................................................140 Quadro 1. Níveis da taxonomia de Bloom revisada e seus respectivos verbos .................................38 Quadro 2. Síntese da interpretação da taxonomia de Bloom em programação .................................43 Quadro 3. Algoritmo para o cálculo da distância de Levenshtein .....................................................49 Quadro 4. Pesquisas sobre o papel dos jogos na aprendizagem de programação introdutória..........53 Quadro 5. Síntese dos trabalhos que utilizam jogos para auxiliar a aprendizagem de programação 69 Quadro 6. Características dos softwares de apoio a aprendizagem de programação.........................71 Quadro 7. Algoritmo em pseudocódigo para a correção automática dos programas ........................82 Quadro 8. Programa na linguagem Escracho e sua AST serializada.................................................83 Quadro 9. Enredo do jogo ..................................................................................................................87 Quadro 10. Um enunciado sendo apresentado em níveis diferentes de contextualização.................90
LISTA DE TABELAS
Tabela 1. Pré-testes das 3 turmas de alunos.......................................................................................96 Tabela 2. Resultados dos testes de Shapiro-Wilk para os pré-testes .................................................97 Tabela 3. Exercícios realizados pelo grupo de controle e pelo segundo grupo experimental ...........99 Tabela 4. Exercícios realizados pelo primeiro grupo experimental.................................................100 Tabela 5. Dados do pós-teste ...........................................................................................................101 Tabela 6. Acertos no pré e pós-teste ................................................................................................103 Tabela 7. Fatores de aprendizagem das classes de alunos (classificação pelo pós-teste) ................104 Tabela 8. Acertos no pré e pós-teste e média final (MF) na disciplina............................................106 Tabela 9. Fatores de aprendizagem das classes de alunos (classificação pela MF).........................106 Tabela 10. Progresso das classes de alunos .....................................................................................108 Tabela 11. Desempenho dos alunos nos níveis da taxonomia de Bloom ........................................109 Tabela 12. Dados dos pré-testes das 3 turmas de alunos .................................................................149 Tabela 13. Exercícios realizados pelo grupo de controle e pelo 2º grupo experimental .................150 Tabela 14. Exercícios realizados pelo grupo experimental 1 (utilizaram o jogo)............................151 Tabela 15. Dados dos pós-testes das 3 turmas de alunos.................................................................151
LISTA DE ABREVIATURAS E SIGLAS
ACM Association for Computing Machinery ASEE American Society for Engineering Education AST Árvore Sintática Abstrata CPU Central Processing Unit GUI Graphical User Interface IEEE Institute of Electrical and Electronics Engineers JVM Java Virtual Machine MCA Mestrado em Computação Aplicada POO Programação Orientada a Objetos RAM Random Access Memory RBIE Revista Brasileira de Informática na Educação RISC Reduced Instruction Set Computer ROM Read Only Memory SIGCSE Special Interest Group on Computer Science Education SBC Sociedade Brasileira de Computação SBIE Simpósio Brasileiro de Informática na Educação XML Extensible Markup Language UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí
SUMÁRIO
1 INTRODUÇÃO.................................................................................... 12 1.1 PROBLEMA DE PESQUISA........................................................................... 14 1.1.1 Solução Proposta ............................................................................................. 16 1.1.2 Delimitação de Escopo .................................................................................... 17 1.1.3 Justificativa...................................................................................................... 19 1.2 OBJETIVOS ...................................................................................................... 20 1.2.1 Objetivo Geral ................................................................................................. 20 1.2.2 Objetivos Específicos ...................................................................................... 20 1.3 METODOLOGIA.............................................................................................. 21 1.3.1 Metodologia da Pesquisa ................................................................................ 21 1.3.2 Procedimentos Metodológicos........................................................................ 21 1.4 ESTRUTURA DA DISSERTAÇÃO................................................................ 24
2 FUNDAMENTAÇÃO TEÓRICA...................................................... 26 2.1 PROGRAMAÇÃO INTRODUTÓRIA ........................................................... 26 2.1.1 Tópicos de Programação Considerados Difíceis .......................................... 27 2.1.2 Linguagens de Programação Mais Utilizadas e Seus Problemas ............... 28 2.1.3 Ensino Focado em Objetos ou em Funções? ................................................ 29 2.2 UTILIZAÇÃO DOS JOGOS DE COMPUTADOR NA EDUCAÇÃO ....... 32 2.2.1 Jogos de Computador no Ensino de Programação Introdutória ............... 33 2.3 TAXONOMIA DE BLOOM............................................................................. 35 2.3.1 Revisões da Taxonomia de Bloom ................................................................. 36 2.3.2 Interpretação da Taxonomia em Programação Introdutória .................... 38 2.4 CORREÇÃO AUTOMÁTICA DE ALGORITMOS..................................... 43 2.4.1 Técnicas Dinâmicas......................................................................................... 44 2.4.2 Técnicas Estáticas ........................................................................................... 45 2.5 CONSIDERAÇÕES .......................................................................................... 50
3 TRABALHOS RELACIONADOS .................................................... 52 3.1 PROTOCOLO DE ANÁLISE.......................................................................... 52 3.2 JOGOS NA APRENDIZAGEM DE PROGRAMAÇÃO.............................. 52 3.3 UTILIZAÇÃO DOS JOGOS COMO FERRAMENTAS DIDÁTICAS...... 54 3.3.1 Game2Learn .................................................................................................... 54 3.3.2 Maze Framework ............................................................................................ 55 3.3.3 W’us Castle ...................................................................................................... 56 3.3.4 Metodologia de ensino baseada em jogos ..................................................... 58 3.3.5 Robocode.......................................................................................................... 58 3.3.6 JV2M ................................................................................................................ 60 3.4 SOFTWARES DE APOIO AO ENSINO DE PROGRAMAÇÃO ............... 61 3.4.1 Alice .................................................................................................................. 61
3.4.2 Greenfoot ......................................................................................................... 63 3.4.3 JavaTool ........................................................................................................... 64 3.4.4 Scratch.............................................................................................................. 64 3.5 ANÁLISE COMPARATIVA............................................................................ 66 3.6 CONSIDERAÇÕES .......................................................................................... 72
4 DESENVOLVIMENTO...................................................................... 74 4.1 A LINGUAGEM DE PROGRAMAÇÃO ESCRACHO ............................... 74 4.1.1 Representação Lógica dos Programas Construídos em Escracho ............. 75 4.1.2 Correção Automática dos Programas........................................................... 79 4.2 SOFTWARES UTILIZADOS NOS EXPERIMENTOS............................... 84 4.2.1 Software Utilizado pelo Grupo de Controle ................................................. 84 4.2.2 Software Utilizado pelo 2º Grupo Experimental ......................................... 85 4.2.3 Software Utilizado pelo 1º Grupo Experimental - O Jogo.......................... 86 4.2.4 Elaboração dos Enunciados dos Problemas Algorítmicos .......................... 89 4.3 INSTRUMENTO DE AVALIAÇÃO DO PRÉ E PÓS-TESTE.................... 90 4.4 CONSIDERAÇÕES .......................................................................................... 91
5 RESULTADOS .................................................................................... 95 5.1 PRÉ-TESTES..................................................................................................... 96 5.2 INTERVENÇÕES COM AS TURMAS DE ALUNOS ................................. 97 5.3 PÓS-TESTES ................................................................................................... 100 5.4 PROGRESSO DOS ALUNOS DO PRÉ PARA O PÓS-TESTE ................ 102 5.5 FATORES DE APRENDIZAGEM DAS CLASSES DE ALUNOS ........... 103 5.5.1 Classificação dos Alunos em Função do Pós-Teste.................................... 104 5.5.2 Classificação dos Alunos em Função das Médias Finais........................... 105 5.6 PROGRESSO DAS CLASSES DE ALUNOS .............................................. 107 5.7 PROGRESSO NOS NÍVEIS DA TAXONOMIA DE BLOOM.................. 109 5.8 CONSIDERAÇÕES ........................................................................................ 111
6 CONCLUSÕES.................................................................................. 115 6.1 AMEAÇAS A VALIDADE INTERNA ......................................................... 118 6.2 AMEAÇAS A VALIDADE EXTERNA ........................................................ 122 6.3 CONTRIBUIÇÕES DA DISSERTAÇÃO .................................................... 123 6.4 TRABALHOS FUTUROS.............................................................................. 124
REFERÊNCIAS ..................................................................................... 126
APÊNDICE A – DESAFIOS DO JOGO ......................................... 135
APÊNDICE B – INSTRUMENTO DO PRÉ E PÓS TESTE........ 141
APÊNDICE C – DADOS COLETADOS......................................... 149
12
1 INTRODUÇÃO
A aprendizagem de programação introdutória é entendida como sendo um dos pilares da
formação em computação e áreas afins (CRISTÓVÃO, 2008). Sheard et al (2009) mencionam que a
grande quantidade de literatura relacionada à programação introdutória é reflexo do amplo
reconhecimento de que este assunto é difícil de aprender e de ensinar. Beauboef e Mason (2005)
dizem que muitas universidades estimam taxas de reprovação entre 30 e 40% para as disciplinas de
programação introdutória.
Pesquisando sobre os problemas na aprendizagem de programação, McCracken et al (2001)
trabalharam com alunos de diferentes países e concluíram que as dificuldades não são casos
isolados, pois acontecem de forma semelhante em várias regiões do mundo, independentemente do
sistema educacional onde os alunos e professores estão inseridos. A conclusão dos autores é que ao
final do primeiro semestre os alunos não atingem os objetivos estabelecidos pelos seus professores,
ou seja, não conseguem programar no nível esperado pelos docentes.
O estudo realizado por McCracken et al (2001) levantou alguns dos problemas na
aprendizagem de programação mas não indicou quais eram as suas causas. Por este motivo, Lister
et al (2004) realizaram experimentos em sete países com o objetivo de testar a capacidade de alunos
iniciantes em programação para ler e entender código. Muitos alunos apresentaram desempenho
abaixo do esperado, sugerindo um domínio superficial de habilidades que são pré-requisitos para a
capacidade de resolver problemas.
As pesquisas de McCracken et al (2001) e Lister et al (2004) envolveram alunos dos
primeiros semestres de cursos de graduação, pois é neste período que os tópicos relacionados à
programação introdutória são tradicionalmente abordados. Miliszewska e Tan (2007) dizem que o
primeiro semestre é bastante crítico, pois é justamente quando os alunos são mais influenciados
sobre decisões como, por exemplo, abandonar os cursos. Kinnunen e Malmi (2006) analisaram os
principais fatores que provocam o abandono dos cursos de computação e, de maneira geral, os
alunos apontaram a falta de tempo e de motivação para os estudos como os dois principais fatores.
Quanto aos fatores mencionados no trabalho de Kinnunen e Malmi (2006), torna-se bastante
difícil para o professor trabalhar a questão da falta de tempo dos alunos. Por exemplo, dificilmente
algum aluno consideraria abandonar seu emprego ou sua namorada para que lhe sobre mais tempo
13
para os estudos. Estas alternativas não são viáveis na prática, apesar de teoricamente possíveis.
Entretanto, no que se refere ao aumento da motivação dos alunos existem algumas estratégias
possíveis, como por exemplo, a utilização dos jogos de computador como ferramentas de apoio à
aprendizagem. Cabe mencionar que o aumento da motivação por si só não resolve a questão da falta
de habilidade para resolução de problemas apontada no trabalho de Lister et al (2004), mas pode
fazer com que alguns alunos busquem suprir suas deficiências, possivelmente melhorando a
aprendizagem.
Becker e Parker (2005) dizem que na universidade onde atuam de 65% a 75% dos alunos
ingressantes procuram o curso de Ciência da Computação porque jogam vídeo game. Por outro
lado, o trabalho de DiSalvo e Bruckman (2009) mostra que existe uma pequena correlação entre ser
jogador de vídeo game e o interesse em computação, e que outras variáveis devem ser consideradas
como mais influentes. Becker e Parker (2005) ainda chamam a atenção para o fato de que os alunos
geralmente entendem muito melhor os problemas relacionados aos jogos do que os problemas
tradicionais como programas de controle de estoque e folha de pagamento. De forma semelhante,
Feldgen e Clúa (2004) sugerem que os alunos não devem mais ser ensinados com os tradicionais
programas “Hello, World”, mas sim através de jogos eletrônicos, já que estes fazem parte do
cotidiano de muitos estudantes. Ainda neste sentido, Cliburn (2006) e Bayllis (2009) chamam a
atenção para o crescente interesse dos professores pela utilização de jogos na educação, já que estes
fazem parte da realidade cultural de muitos dos alunos.
Parece haver um senso comum estabelecido de que os jogos de vídeo game provocam
melhoria na aprendizagem. Entretanto, as evidências existentes na literatura consultada mostram
que talvez haja algum entusiasmo exagerado sobre o assunto. Sendo assim, esta pesquisa procura
contribuir para a área de Educação em Computação investigando empiricamente a influência de um
jogo de computador na aprendizagem de programação introdutória.
O jogo avaliado nesta pesquisa foi construído especialmente para subsidiá-la. Trata-se de um
jogo onde os alunos precisam resolver nove desafios algorítmicos utilizando uma linguagem de
programação não-textual, também construída para atender as necessidades da pesquisa. Nesta
linguagem os elementos de um programa são componentes gráficos que podem ser arrastados e
encaixados uns nos outros. Além disso, a pesquisa também requereu a construção de um mecanismo
de correção automática de pequenos programas (os detalhes são apresentados na Seção 4.1.2 ), já
que durante o jogo os programas construídos pelos alunos precisam ser corrigidos de forma
14
automatizada. Por fim, elaborou-se um instrumento de avaliação que foi utilizado nos pré e pós-
testes, aplicados respectivamente no início e no fim de cada experimento com os alunos. Os
detalhes deste instrumento de avaliação são apresentados no Apêndice B e uma discussão é
apresentada em Jesus e Raabe (2009).
1.1 PROBLEMA DE PESQUISA
Pesquisas vêm sendo realizadas com o objetivo de mensurar a influência dos jogos de
computador na aprendizagem de programação introdutória. Cliburn (2006) realizou um estudo onde
concluiu que com a presença dos jogos os alunos tornam-se mais motivados e engajados, mas não
foram observadas melhorias nas notas1. Bayliss (2007) também não observou nenhuma diferença
significativa nas notas dos alunos dos primeiros semestres após a utilização de jogos. Entretanto, o
estudo da autora sugere que os benefícios podem aparecer mais tarde, nos semestres subseqüentes.
Bierre e Phelps (2004) relatam, assim como Long (2007), o aumento da motivação dos
alunos ao utilizarem o Robocode2, um ambiente onde tanques de guerra programados pelos alunos
batalham entre si. Entretanto, apesar do aumento da motivação nenhum destes autores relata alguma
melhoria nas notas dos alunos. Barnes et al (2007) também concluíram que não houve melhora
significativa na aprendizagem após a utilização de um jogo sobre os principais tópicos de
programação introdutória. As notas dos alunos continuaram, nas palavras dos próprios autores,
surpreendentemente baixas.
Por outro lado, Eagle e Barnes (2008, 2009) observaram melhorias nas notas de alunos que
utilizaram um jogo para praticar especificamente o conceito de loops. Bayllis (2009) também cita
resultados significativamente positivos no ensino de programação introdutória baseado na utilização
de jogos. Feldgen e Clúa (2004) relatam uma diminuição na taxa de abandono do curso depois da
inserção dos jogos no currículo, ainda que os próprios autores reconheçam que tal efeito seja uma
conseqüência da implementação de diversas mudanças, entre elas a inserção dos jogos.
1 Os trabalhos pesquisados utilizam as pontuações de testes dos alunos como indicadores da aprendizagem. 2 http://robocode.sourceforge.net/
15
Analisando os resultados das pesquisas citadas anteriormente observa-se que, em geral,
existem indícios de que os jogos aumentam a motivação dos alunos de programação introdutória.
Entretanto, a situação não é a mesma quando trata-se das notas, pois neste caso existem evidências
de melhorias tanto quanto existem evidências de que a melhora não existe. Considerando que as
notas dos alunos são utilizadas como indicadores de aprendizagem em grande parte das pesquisas
analisadas neste trabalho, o que se observa é que o efeito da utilização de jogos na aprendizagem de
programação introdutória é uma questão em aberto.
Sendo assim, assumindo que o efeito dos jogos3 na motivação dos alunos já é bem
conhecido, o objetivo desta pesquisa foi responder a seguinte questão problema: De que forma a
utilização de um jogo de computador focado na resolução de problemas algorítmicos influencia a
aprendizagem de programação introdutória?
Outra questão que também foi avaliada nesta pesquisa está relacionada à forma
contextualizada como os desafios dos jogos são apresentados. Em um jogo, cada desafio está
fortemente vinculado ao enredo. As ações do jogador dentro do jogo contribuem, direta ou
indiretamente, para o salvamento de uma princesa, a libertação de escravos oprimidos, a aniquilação
de alienígenas invasores, etc. É comum que os exercícios de programação não possuam este nível
de contextualização e resumam-se a “calcule isto” e “resolva aquilo”, onde o resultado do cálculo
ou da resolução não é utilizado para algo que faça sentido dentro de um contexto maior. Nestes
casos específicos, observa-se que existe uma relação inversamente proporcional entre a
contextualização de um enunciado e o seu nível de abstração. Quanto menos contextualizado o
enunciado mais abstrato ele se torna, e vice-versa. Então, partindo destas considerações, este
trabalho também procurou responder a seguinte questão problema: Um jogo promove melhorias na
aprendizagem ou este mesmo resultado pode ser alcançado apenas com a utilização de problemas
de programação melhor contextualizados?
3 Neste trabalho a palavra jogo é utilizada para descrever um “jogo de computador”.
16
1.1.1 Solução Proposta
Para responder as questões mencionadas anteriormente foram realizados experimentos com
3 turmas de alunos de programação introdutória, onde em cada experimento os alunos estiveram
expostos a enunciados com níveis diferentes de contextualização. Um mesmo conjunto de
exercícios relacionados com alguns tópicos básicos de programação foi utilizado em todos os 3
experimentos. Durante o experimento com o nível mais alto de contextualização os problemas
algorítmicos foram resolvidos dentro de um jogo, cujo enredo serviu como contexto para os
problemas algorítmicos. Este foi o experimento com o maior nível de contextualização, pois a
solução dos problemas algorítmicos estava diretamente relacionada com os desafios do jogo. Em
um segundo experimento os alunos utilizaram outro software, onde os enunciados dos mesmos
problemas algorítmicos utilizados no jogo foram apresentados com um nível intermediário de
contextualização, contendo descrições textuais e imagens dos cenários e situações do jogo. A
principal diferença entre estes dois experimentos é que no primeiro os alunos utilizaram um jogo, já
no segundo eles apenas imaginaram um jogo a partir de descrições e imagens. Finalmente, no nível
mais baixo de contextualização os alunos utilizaram um software onde os enunciados dos mesmos
problemas algorítmicos presentes no jogo foram apresentados de forma mais abstrata, sem nenhuma
referência ao jogo ou quaisquer outras situações concretas.
Através da realização dos experimentos citados anteriormente testou-se as seguintes
hipóteses:
H1: Exercícios de programação com enunciados mais contextualizados melhoram a
aprendizagem; e
H2: O uso do jogo promove melhores resultados na aprendizagem do que apenas a
utilização de exercícios mais contextualizados;
Estas hipóteses ainda foram pormenorizadas através da categorização dos alunos em três
classes: alunos ótimos, medianos ou com dificuldades. Imaginou-se, por exemplo, que alunos com
dificuldades poderiam se beneficiar mais da contextualização de enunciados do que os demais
alunos.
A aprendizagem dos grupos de alunos mencionados anteriormente foi mensurada de duas
formas. Primeiramente foi calculada a pontuação de cada uma das turmas tomando como base o
17
número de questões respondidas corretamente no pré e também no pós-teste. A diferença entre estas
pontuações (pós-teste – pré-teste) foi utilizada como um dos indicadores de progresso dos alunos.
Outro indicador utilizado foi o quanto os alunos progrediram em relação aos níveis da taxonomia de
objetivos de aprendizagem de Bloom (KRATHWOL, 2002), já que as questões do instrumento de
avaliação utilizado tanto no pré como no pós-teste foram classificadas de acordo com esta
taxonomia. A taxonomia divide-se em níveis hierárquicos, onde quanto mais alto o nível mais
complexas são as atividades cognitivas envolvidas.
1.1.2 Delimitação de Escopo
As hipóteses mencionadas anteriormente foram verificadas através de dados coletados em 3
experimentos com alunos iniciantes em programação. O que se pretendeu com estas
experimentações foi identificar o quanto um jogo onde é necessário programar para vencer
contribui para a aprendizagem de programação em um nível introdutório. Vale ressaltar que o
escopo deste trabalho esteve restrito à programação introdutória, e que nenhum tópico avançado
sobre o assunto foi tratado nesta pesquisa. Além disso, mesmo no que se refere aos tópicos
introdutórios de programação esta pesquisa tratou de apenas três deles: os desvios condicionais, os
arrays e os laços de repetição.
A questão da inserção de jogos no currículo certamente pode ser abordada sob diversos
aspectos, mas o único aspecto que foi tratado neste trabalho é a aprendizagem. Outros aspectos não
foram considerados, como por exemplo o aumento da motivação dos alunos ao utilizarem jogos. No
caso específico do aumento da motivação dos alunos julgou-se que tal efeito já foi suficiente
discutido na literatura relacionada e que não valeria a pena investigá-lo novamente nesta pesquisa.
De maneira geral, o que se fez foi realizar 3 intervenções didáticas diferentes, e em cada uma delas
foram utilizadas pontuações para mensurar os ganhos de aprendizagem e finalmente comparou-se
as pontuações entre si para determinar qual a abordagem promoveu melhores resultados.
Também foi analisado o impacto do nível de abstração de enunciados de problemas
algorítmicos na aprendizagem. Para evitar ambigüidades convém definir o sentido da palavra
abstração utilizado neste trabalho. No contexto desta pesquisa a abstração pode ser entendida como
uma medida de similaridade entre a descrição de um problema e uma situação do mundo real.
Quanto mais distante de uma situação real estava a descrição mais abstrata ela foi considerada. Um
enunciado foi considerado abstrato quando o problema algorítmico foi apresentado apenas
18
textualmente e as relações entre variáveis foram apresentadas em notação matemática (f = 2g + h,
por exemplo). Quanto o mesmo problema foi descrito com auxílio de imagens do jogo, usando
textos e imagens explicativas onde seria utilizada a álgebra, então o enunciado tornou-se menos
abstrato. Este foi o sentido da palavra abstração utilizado no decorrer deste trabalho.
Outra idéia já mencionada é a contextualização dos enunciados, e convém defini-la
adequadamente. A contextualização foi entendida nesta pesquisa como uma medida sobre o quanto
a utilidade da solução de um problema fica evidente no seu enunciado. Se ao ler o enunciado de um
problema o aluno não é capaz de identificar a serventia da solução então o problema, e o seu
enunciado, é considerado pouco contextualizado. Um exemplo seria uma situação onde o aluno
deve construir um programa para calcular a média de um conjunto de valores. Geralmente o aluno
não sabe o que significam os números do conjunto de dados, e, portanto, não sabe exatamente que
média está calculando. Está calculando a média de pesos de pessoas? De medidas de objetos? De
notas? Apenas os dados numéricos não respondem estas perguntas. Neste caso, quando o aluno
desconhece o significado dos dados que está manipulando o problema é considerado pouco
contextualizado. Outro indício da pouca contextualização é a falta de utilidade para a média
computada. Uma vez calculada, onde esta média será utilizada? Em uma situação como esta, onde
uma média é apenas calculada, entende-se que não há contextualização, pois o cálculo da média
não faz parte de um contexto maior, uma situação problema que requeira o cálculo da média. No
sentido inverso, nesta pesquisa o enunciado de um problema cuja solução faz parte de um contexto
maior foi considerado como contextualizado.
Em todos os três experimentos que foram realizados nesta pesquisa os problemas
algorítmicos foram resolvidos através de uma linguagem de programação não-textual, onde as
partes de um programa podem ser arrastadas e encaixadas umas dentro das outras. Sendo assim, foi
desenvolvido um interpretador de comandos que é o responsável pela execução dos programas
construídos nesta linguagem. Este interpretador é bastante simples se comparado com um
interpretador ou compilador de propósito geral. O interpretador foi construído apenas para atender
as necessidades desta pesquisa, e por este motivo não suporta alguns recursos mais avançados como
funções e procedimentos, programação orientada a objetos, etc.
Um mecanismo de correção de programas foi construído e integrado com a linguagem de
programação não-textual mencionada anteriormente. Este mecanismo de correção é útil apenas em
situações onde para cada programa que se pretende avaliar é possível predefinir as variáveis de
19
entrada e de saída e seus respectivos valores, estruturas de algoritmos que possam solucionar o
problema, entre outros. Este método de correção aplica-se somente em situações onde pequenos
exercícios de programação são avaliados. O mecanismo de correção utilizado nesta pesquisa
dificilmente daria resultados positivos ao avaliar programas maiores, possivelmente pelo baixo
desempenho. Além disso, grandes programas possuiriam conjuntos de variáveis de entrada e de
saída igualmente grandes, o que tornaria impraticável a tarefa de pré-definir todos os itens
requeridos pelo mecanismo de correção automática.
É possível que a utilização da linguagem de programação não-textual durante os
experimentos promova por si só alguma melhoria na aprendizagem. Entretanto, este trabalho não
avaliou especificamente este ponto. Para a verificação das hipóteses definidas nesta pesquisa
interessava apenas que a linguagem de programação mencionada estivesse presente em todos os
experimentos, ou seja, que todos os participantes dos experimentos tivessem acesso a este recurso.
Esta mesma idéia se aplica ao mecanismo de correção automática de programas. A correção
automática mostrou aos alunos os seus erros e possivelmente os guiou na direção das soluções
corretas para os problemas algorítmicos. Esta é uma característica que por si só também pode
promover melhorias na aprendizagem. Porém, novamente, não fez parte do escopo deste trabalho
avaliar o impacto do mecanismo de correção na aprendizagem, pois para os objetivos da pesquisa
interessava apenas que o mecanismo de correção fosse utilizado em todos os experimentos.
1.1.3 Justificativa
Mesmo com todas as pesquisas já realizadas sobre as dificuldades na aprendizagem de
programação as disciplinas relacionadas ainda costumam apresentar altas taxas de reprovação e
desistência. Os trabalhos de McCracken et al (2001) e Lister et al (2004) abordam este tema e
mostram que as dificuldades de aprendizagem não são um problema isolado nesta ou naquela
universidade. Sendo assim, investigar formas de melhorar a aprendizagem – e possivelmente
minimizar as taxas de reprovação e desistência - torna-se um problema relevante para muitas
universidades que ofertam disciplinas relacionadas à programação introdutória.
Ao longo das décadas diferentes tipos de software (sistemas tutores inteligentes, ambientes
colaborativos, entre outros) vêm sendo utilizados para auxiliar a aprendizagem de programação.
Cliburn (2006) e Bayllis (2009) mostram que muitos professores vêm adotando os jogos como
ferramentas didáticas, pois em geral, muitos assumem que os jogos beneficiam a aprendizagem.
20
Neste caso, a relevância deste trabalho está no avanço do entendimento sobre como um jogo pode
influenciar a aprendizagem de programação, utilizando para isto uma metodologia experimental
rigorosa (com pré e pós-teste e grupo de controle), já que algumas das publicações sobre o mesmo
assunto nem sempre observam este último aspecto. Também foi analisada a influência do nível de
contextualização nos enunciados dos problemas algorítmicos na aprendizagem. Com esta análise
buscou-se verificar se um jogo era realmente necessário ou se seria possível melhorar a
aprendizagem de programação apenas utilizando problemas que pudessem ser considerados mais
úteis pelos alunos, ou seja, problemas melhor contextualizados.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho foi avaliar quantitativamente o efeito da utilização de um
jogo focado na resolução de problemas algorítmicos na aprendizagem de programação introdutória.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho foram:
1. Implementar a linguagem de programação não-textual necessária para a resolução dos
exercícios de programação durante os experimentos;
2. Definir uma métrica para a correção automática de programas com base na literatura;
3. Implementar o mecanismo de correção de programas de acordo com a métrica
estabelecida no objetivo anterior;
4. Elaborar a concepção do jogo e um conjunto de desafios algorítmicos relacionados à
idéia do jogo;
5. Implementar os softwares que foram utilizados pelos alunos durante os experimentos
com os três níveis diferentes de contextualização; e
6. Elaborar o instrumento de avaliação utilizado no pré e pós-teste e realizar os
experimentos com as 3 turmas para avaliar quantitativamente o impacto dos softwares
construídos na aprendizagem dos alunos.
21
1.3 METODOLOGIA
Nesta seção apresenta-se uma classificação da metodologia utilizada nesta pesquisa bem
como os procedimentos metodológicos utilizados.
1.3.1 Metodologia da Pesquisa
Esta pesquisa utilizou o método hipotético-dedutivo, já que o trabalho partiu de um
problema e seguiu para a obtenção da sua solução por meio da verificação de hipóteses (MARCONI
e LAKATOS, 2000). A pesquisa também foi de natureza aplicada, pois conceitos e tecnologias
computacionais já existentes foram utilizados para verificar hipóteses relacionadas à aprendizagem.
O problema central desta pesquisa (a influência de um jogo na aprendizagem de
programação introdutória) foi abordado de maneira quantitativa. O que se fez foi mensurar
quantitativamente a aprendizagem de alunos iniciantes em programação quando utilizando
diferentes ferramentas para apoio à aprendizagem de programação, entre elas um jogo.
De acordo com a definição de Gil (2002), esta pesquisa classifica-se como explicativa, já
que se examinou como os fatores presença de um jogo e nível de contextualização nos enunciados
contribuem para a ocorrência do fenômeno aprendizagem.
1.3.2 Procedimentos Metodológicos
Para a realização dos experimentos com os alunos de programação introdutória foram
construídos três softwares, e cada um deles foi utilizado em um dos três experimentos realizados. O
que diferenciou estes experimentos entre si é que em cada um deles os enunciados dos problemas
foram apresentados com um nível de contextualização diferente.
1.3.2.1 Os experimentos
No primeiro experimento os alunos lidaram com os enunciados mais abstratos, com
descrições principalmente textuais e utilizando notação algébrica. Nestes enunciados não se fez
nenhuma referência para situações concretas onde os resultados dos problemas resolvidos pudessem
ser aplicados. A idéia era que neste experimento os alunos apenas “resolvessem por resolver”, ao
invés de resolver para aplicar em uma situação problema mais abrangente. Os alunos participantes
22
deste experimento foram tratados como o grupo de controle desta pesquisa, e o desempenho destes
alunos foi utilizado como base para comparação com as outras duas turmas.
No segundo experimento os enunciados possuíam um nível intermediário de
contextualização. Os mesmos problemas utilizados com o grupo de controle foram apresentados aos
alunos, porém foram utilizadas descrições textuais e imagens do jogo. No terceiro experimento os
alunos utilizaram o jogo. Neste caso os enunciados possuíam o maior nível de contextualização,
pois havia um propósito bem definido para a resolução de cada problema apresentado: avançar no
jogo.
Em todos os experimentos os alunos resolveram problemas relacionados especificamente à:
laços de repetição, desvios condicionais, e arrays. A pesquisa foi delimitada a esses três tópicos por
entender-se (de acordo com a literatura consultada) que são alguns dos mais difíceis de aprender na
perspectiva dos alunos iniciantes. Um conjunto de problemas de programação relacionados com
estes tópicos foi elaborado. Estes mesmos exercícios foram utilizados em todos os experimentos e
também foram resolvidos com as mesmas ferramentas (linguagem de programação não-textual e
correção automática dos programas). Neste caso, o que se fez foi em cada experimento variar o grau
de contextualização dos exercícios apresentados aos alunos e manter constantes ao menos aquelas
poucas variáveis que são controláveis em experimentos desta natureza.
1.3.2.2 Pré e pós-teste
Em todos os experimentos os alunos responderam o mesmo teste antes e depois das
intervenções (pré e pós-teste). Para a realização deste teste foi elaborado um questionário com
questões de múltipla escolha envolvendo os tópicos arrays, desvios condicionais e loops (este
instrumento de avaliação é apresentado no Apêndice B deste trabalho). Foram utilizadas questões
de múltipla escolha para minimizar a subjetividade na correção dos testes. Como sugerem Lister et
al (2004), o problema em se utilizar questões discursivas onde o aluno deve, por exemplo, descrever
o funcionamento de um trecho de código é que o aluno pode ter um desempenho ruim não por falta
de entendimento sobre o funcionamento de programas, mas sim pela própria dificuldade de
escrever. Além disso, cada questão do teste foi classificada em um nível da taxonomia de objetivos
de aprendizagem de Bloom. Desta forma, buscou-se mensurar a proporção de alunos que
responderam corretamente questões relacionadas a cada um dos níveis da taxonomia. Utilizou-se a
taxonomia revisada de Bloom (KRATHWOHL, 2002), e apenas os quatro primeiros níveis da
23
taxonomia estavam contemplados no instrumento de avaliação (a taxonomia possui seis níveis no
total).
O pré-teste foi aplicado antes que os professores das turmas participantes dos experimentos
iniciassem a apresentação do tópico desvios condicionais, pois tradicionalmente este tópico é
apresentado antes dos laços de repetição e dos arrays. A intervenção com cada um dos softwares
(inclusive o jogo) foi realizada apenas depois que os três tópicos de interesse para esta pesquisa
foram trabalhados em sala de aula. Depois destas intervenções, próximo ao final do semestre letivo,
finalmente foi aplicado o pós-teste. A Figura 1 ilustra a ordem em que as etapas dos experimentos
aconteceram ao longo de um semestre letivo de 18 semanas.
Figura 1. Esquema que foi utilizado em cada um dos experimentos
1.3.2.3 Avaliação do Desempenho dos Alunos nos Testes
Para cada aluno foi atribuído uma pontuação para o pré e outra para o pós-teste, onde a
pontuação foi equivalente à quantidade de problemas resolvidos corretamente pelo aluno. A
diferença entre as pontuações de pré e pós-teste foi utilizada como um fator de aprendizagem.
Quanto maior a diferença entre as duas pontuações maior foi o progresso alcançado pelo aluno. Um
teste t pareado foi utilizado para determinar se cada uma das turmas progrediu ou não do pré para o
pós-teste.
Todos os testes de hipóteses realizados foram executados com 95% de confiança (α = 0.05).
Para a comparação entre os fatores de aprendizagem dos alunos das 3 turmas inicialmente utilizou-
se o teste de Shapiro-Wilk para verificar a suposição de normalidade dos dados amostrais. Como
24
este teste apontou que uma das amostras não estava normalmente distribuída utilizou-se os testes
Kruskal-Wallis para a comparação dos fatores de aprendizagem das 3 turmas.
Os alunos participantes de cada um dos experimentos foram separados em três classes de
acordo com dois indicadores: a pontuação do pós-teste e a média final (MF) na disciplina de
programação introdutória. Tanto a MF quanto a pontuação do pós-teste variaram entre 0 e 10, e o
critério para classificação dos alunos foi:
1. Alunos ótimos (pontuação entre 8 e 10);
2. Alunos medianos (pontuação maior ou igual a 6 e menor que 8); e
3. Alunos com dificuldades (pontuação menor que 6).
Os fatores de aprendizagem de cada uma das três classes de alunos listadas anteriormente
foram calculados e comparados entre si com o teste de Kruskal-Wallis. Com esta classificação
buscou-se uma análise mais pormenorizada, pois imaginou-se que, por exemplo, o jogo poderia não
influenciar significativamente os alunos classificados como ótimos, mas poderia promover uma
diferença efetiva na aprendizagem dos alunos classificados como medianos ou com dificuldades.
Cada questão do instrumento de avaliação utilizado tanto no pré quanto no pós-teste foi
associada a um dos níveis da taxonomia de Bloom. Sendo assim, ao final de cada experimento foi
possível comparar o desempenho dos alunos no pré e pós-teste para cada nível da taxonomia. Com
esta mensuração procurou-se observar se haveria um aumento de percentual de questões
respondidas corretamente em cada um dos níveis da taxonomia de Bloom, ou seja, se alguma das
intervenções realizadas teria provocado mais progresso em algum dos níveis da taxonomia.
1.4 ESTRUTURA DA DISSERTAÇÃO
Este trabalho está organizado em seis capítulos. O primeiro é o capítulo introdutório, onde
são apresentados o contexto onde a pesquisa está inserida, o problema que se buscou resolver e a
solução adotada. Neste capítulo inicial ainda são apresentados os objetivos da pesquisa e uma
descrição sobre a metodologia que foi empregada no decorrer dos trabalhos.
O segundo capítulo deste trabalho apresenta a fundamentação teórica da pesquisa, onde
discute-se as questões relacionadas com a programação introdutória, a utilização dos jogos na
25
educação em geral e na aprendizagem de programação em específico, a taxonomia de objetivos de
aprendizagem de Bloom e as técnicas utilizadas para correção automática de algoritmos.
O terceiro capítulo apresenta um conjunto de trabalhos que foram considerados similares a
esta pesquisa. Estes trabalhos foram divididos em três classes: aqueles onde houve alguma forma de
avaliação do efeito dos jogos na aprendizagem de programação introdutória; trabalhos onde os
jogos foram utilizados como ferramentas didáticas (sem preocupação com a mensuração do efeito
na aprendizagem); e os softwares construídos para apoiar a aprendizagem de programação.
No quarto capítulo são apresentados detalhes mais técnicos sobre a construção dos softwares
que foram desenvolvidos para a realização desta pesquisa. Um software diferente foi construído
para cada um dos 3 experimentos realizados, já que em cada experimento os enunciados dos
problemas foram apresentados aos alunos com um nível de contextualização diferente.
Os resultados obtidos nesta pesquisa são apresentados no quinto capítulo. Por fim, no sexto
capítulo são apresentadas as conclusões do trabalho, bem como uma discussão sobre a validade dos
resultados alcançados.
26
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são discutidos os principais temas de interesse desta pesquisa, a saber: os
problemas relacionados à aprendizagem de programação introdutória; a utilização dos jogos de
computador como ferramentas pedagógicas; a taxonomia de objetivos de aprendizagem de Bloom e
as técnicas utilizadas para correção automática de programas. Ao final do capítulo apresenta-se uma
seção com considerações gerais sobre os assuntos abordados.
2.1 PROGRAMAÇÃO INTRODUTÓRIA
O desenvolvimento do raciocínio lógico exerce forte influência no desempenho dos alunos
em disciplinas relacionadas com a programação de computadores (RAABE; DAZZI; SANTIAGO,
2007). Segundo Raabe e Silva (2005), este desenvolvimento do raciocínio lógico inicia-se com a
aprendizagem dos fundamentos de algoritmos, que por sua vez, são a base para os conceitos e a
prática da programação.
Miliszewska e Tan (2007) dizem que a disciplina de programação introdutória é um
componente fundamental no currículo de Ciência da Computação, e por este motivo é uma
disciplina obrigatória. Segundo os autores, esta também é uma das disciplinas que mais amedronta
alunos ingressantes, que muitas vezes decidem abandonar o curso, seja por conta de um
desempenho insatisfatório ou mesmo de uma reprovação.
O medo que muitos alunos sentem das disciplinas de programação introdutória parece ser
justificado, pois como afirmam Robins, Roundtree e Roundtree (2003), programar é uma atividade
difícil, principalmente para alunos ingressantes com uma ampla gama de deficiências. Quanto a
estas deficiências, Yuen (2007) diz que no primeiro semestre os alunos precisam lidar com
conceitos abstratos e uma alta demanda pela habilidade de solucionar problemas, o que torna este
período extenuante para muitos alunos. De maneira um pouco mais específica, Raabe e Silva (2005)
dizem que os alunos precisam desenvolver estratégias de solução de problemas com base lógico-
matemática, o que é algo muito abstrato e distante do cotidiano de muitos dos estudantes.
McCracken et al (2001) realizaram um estudo conjunto entre universidades dos Estados
Unidos, Israel, Austrália, Reino Unido e Polônia com o objetivo de responder a pergunta: os
estudantes das disciplinas de programação introdutória sabem como programar no nível esperado
27
pelos seus professores? Os resultados da pesquisa indicaram que não, os alunos não sabiam o que
seus professores esperavam que eles soubessem. Além disso, por ter sido realizado em
universidades de vários países o estudo sugere que as dificuldades na aprendizagem de
programação não são casos geograficamente isolados.
Yuen (2007) analisou como alunos de programação introdutória aplicam o conhecimento
adquirido, e os resultados do trabalho apontaram que muito dos alunos mostraram-se impelidos a
codificar antes de planejar as soluções dos problemas. McCracken et al (2001) dizem que para
muitos alunos o objetivo das disciplinas de programação é a aprendizagem da sintaxe de alguma
linguagem de programação de computadores. Isto leva muitos alunos a super direcionarem seus
esforços para atividades de implementação, em detrimento de atividades que envolvam
planejamento, projeto ou teste de programas. Como colocam Sajaniemi e Kuittinen (2007), um
aluno de programação introdutória deve ser capaz de aplicar os conceitos assimilados tanto em
vários paradigmas quanto em várias linguagens de programação na resolução de problemas
computacionais.
2.1.1 Tópicos de Programação Considerados Difíceis
Dale (2006) realizou uma pesquisa onde trezentos e cinqüenta professores universitários
responderam algumas questões sobre as principais dificuldades enfrentadas no ensino de
programação introdutória. Os resultados da pesquisa indicaram que os problemas mais citados caem
em quatro categorias: resolução de problemas e projeto, tópicos gerais de programação, conceitos
de programação orientada a objetos e a falta de maturidade dos alunos. No que se refere aos tópicos
gerais de programação, o estudo mostrou que os parâmetros (de funções ou métodos), os arrays, os
laços de repetição (loops) e por último a manipulação de arquivos (file I/O) são os assuntos
considerados mais difíceis, listados aqui em ordem crescente de dificuldade.
Lahtinen, Ala-Mutka e Järvinen (2005) realizaram um estudo onde mais de 500 estudantes e
professores foram entrevistados sobre as principais dificuldades em programação introdutória. Os
mesmos tópicos gerais de programação citados na pesquisa de Dale (2006) surgiram como sendo
problemáticos, embora a ordem de dificuldade associada aos tópicos não tenha sido exatamente a
mesma. De forma semelhante, o trabalho de Robins, Roundtree e Roundtree (2003) elenca os loops,
os desvios condicionais, os arrays e a recursão como os tópicos mais problemáticos para
programadores iniciantes.
28
Schulte e Bennedsen (2006) coletaram a opinião de 349 professores de programação
introdutória sobre quais tópicos de ensino eles julgavam mais relevantes para um primeiro semestre.
Os conceitos de laço de repetição e desvio condicional foram considerados os mais relevantes,
acompanhados dos conceitos de estruturas de dados simples, parâmetros, escopo, classes e objetos.
Para o contexto deste trabalho optou-se por tratar apenas de três tópicos que estão entre os
citados como mais difíceis em algumas das pesquisas mencionadas anteriormente, são eles: os
loops, os arrays e os desvios condicionais.
2.1.2 Linguagens de Programação Mais Utilizadas e Seus Problemas
Pears et al (2007) diz que Java, C e C++ estão no topo da lista das linguagens mais
utilizadas tanto na indústria quanto no meio acadêmico. Os autores basearam-se no índice fornecido
pelo site tiobe4 em 2007 (a ordem das linguagens apenas mudou para C, Java e C++ em 2010). Os
autores dizem que apesar da popularidade de linguagens como Java, C e C++ existe muito debate
sobre o quão adequadas elas são para o ensino introdutório de programação. Segundo os autores,
estas linguagens não foram projetadas com propósitos educacionais como é o caso das linguagens
Python, Logo, Eiffel e Pascal.
Chalk e Fraser (2006) realizaram um estudo com 44 universidades (35 na Inglaterra, 6 na
Escócia, uma no país de Gales e uma na Irlanda) sobre a linguagem de programação mais utilizada
nas disciplinas introdutórias. O estudo também mostrou que Java é a linguagem mais usada, seguida
por C++ e uma mistura de outras oito linguagens diferentes.
Esteves e António (2003) dizem que migraram da linguagem C para Java em um curso
introdutório de programação na esperança de que isso tornasse as coisas mais fáceis para os alunos.
Entretanto, depois de alguns anos, as dificuldades enfrentadas por muitos estudantes não mudaram
significativamente. Muitos continuavam com problemas para entender conceitos de programação e
projeto de algoritmos. Conceitos como classes, objetos, referências e mensagens não eram
assimilados por muitos dos alunos.
4 http://www.tiobe.com/
29
Malan e Leitner (2007), dizem que para os alunos iniciantes a maioria das linguagens de
programação parecem uma confusão de símbolos, pois são uma mistura do idioma inglês,
simbologia matemática e outros símbolos não familiares. Os autores ainda falam sobre a grande
quantidade de palavras reservadas e outros detalhes sintáticos que são apresentados aos alunos logo
nas primeiras aulas. Os autores dizem que nas primeiras semanas os detalhes sintáticos das
linguagens de programação retardam o trabalho e desencorajam muitos alunos para a aprendizagem
do que realmente é fundamental: o raciocínio lógico e a sua representação computacional através de
desvios condicionais, laços de repetição, variáveis, etc. Segundo os autores, com linguagens de
programação como Java os alunos precisam tornar-se especialistas em sintaxe antes de começarem
a resolver problemas.
Clua (2008) diz que, apesar do debate sobre qual a melhor metodologia para o ensino de
programação introdutória, muitos educadores concordam que as atividades de aprendizagem devem
ser focadas nos conceitos de algoritmos, lógica e matemática, ao invés de detalhes específicos de
linguagens ou tecnologias.
De acordo com os autores mencionados anteriormente, existem muitos problemas
relacionados à sintaxe na utilização de linguagens de programação tradicionais como Java e C++
com alunos iniciantes. Por este motivo, nesta pesquisa optou-se por utilizar uma linguagem de
programação bastante diferente, baseada no encaixe de componentes visuais onde os erros sintáticos
são severamente minimizados. Mais detalhes sobre esta linguagem de programação são
apresentados na seção 4.1.
2.1.3 Ensino Focado em Objetos ou em Funções?
Lister el al (2006) sumarizam um debate sobre o ensino de programação introdutória
ocorrido em uma lista de discussão dos membros do SIGCSE (Special Interest Group on Computer
Science Education – Grupo de Interesse Especial em Educação em Ciência da Computação). Neste
debate os participantes discutiram se as disciplinas de programação introdutória deveriam ser
ensinadas através do paradigma procedural ou da abordagem object-first, onde os conceitos de POO
são os primeiros a serem apresentados aos alunos. Lister el al (2006) identificaram as principais
convicções presentes nas opiniões dos participantes do debate e as compararam com as evidências
presentes na literatura. Em geral, os autores apresentam evidências que dão suporte às duas
30
vertentes do debate. Porém, a maioria das opiniões do debate eram mais favoráveis ao ensino de
programação introdutória sob a abordagem object-first.
Sajaniemi e Kuittinen (2007) dizem que a presença marcante tanto de POO como de Java na
construção de programas vem criando a ilusão de que programar é sinônimo de programar orientado
a objetos, e em Java. Os autores dizem que o ensino de programação vem mudando para o
paradigma da POO por influência da indústria da Tecnologia da Informação, já que praticamente
não existem resultados de pesquisas sobre Psicologia da Programação e Educação em Computação
que indiquem que esta mudança seja desejável, necessária, ou benéfica para a aprendizagem.
Robins, Roundtree e Roundtree (2003) dizem que a identificação de objetos não é um
processo fácil para os alunos iniciantes e que eles precisam construir um modelo procedimental da
solução para só então projetar classes e objetos. Estes argumentos parecem enquadrar-se na
abordagem object-later, ainda que os autores não a defendam explicitamente. Nesta abordagem o
ensino é iniciado com conceitos fundamentais de programação (laços de repetição, desvios
condicionais, etc.) e só depois de assimilados estes conceitos é que são apresentados aos alunos os
conceitos de POO, o que é geralmente feito de forma superficial (GAL-EZER; VILNER; ZUR,
2009) para evitar uma sobrecarga mental. Chalk e Fraser (2006) coletaram dados de 44 instituições
de vários países e constataram que a abordagem object-later é mais utilizada do que a abordagem
object-first no ensino de programação introdutória.
Vilner, Zur e Gal-Ezer (2007) compararam o desempenho de 94 alunos de programação
introdutória que aprenderam sob o paradigma procedural com o desempenho de 76 alunos que
aprenderam sob o paradigma da POO. Os dois grupos foram avaliados com apenas três questões:
uma questão relacionada à recursividade, outra relacionada à eficiência de algoritmos e uma última
relacionada com projeto de software. Os resultados não indicaram diferenças significativas para os
conceitos de recursão e eficiência de algoritmos, mas indicaram que os alunos que aprenderam POO
apresentaram um desempenho melhor no tópico projeto de software. Em outra publicação, Gal-
Ezer, Vilner e Zur (2009) compararam a taxa de aprovação na disciplina de estruturas de dados dos
alunos que aprenderam programação introdutória procedural com aqueles que aprenderam POO. A
conclusão do estudo é que não houve diferença significativa no percentual de alunos aprovados,
sugerindo que o paradigma utilizado nas disciplinas de programação introdutória não influenciou o
desempenho dos alunos nas disciplinas posteriores.
31
Reges (2006) relata uma volta para o que o autor chama de “a era Pré-Java” no que se refere
ao ensino de programação introdutória. O autor diz que o currículo baseado na abordagem objects
early (outra denominação para a abordagem object-first) foi substituído por um currículo mais
tradicional, baseado no paradigma procedural. O autor ainda apresenta alguns resultados
quantitativos que - embora não conclusivos, como reconhece o autor – sugerem um aumento
significativo no número de ingressantes depois das mudanças, em especial no número de mulheres
matriculadas. O estudo de Reges também mostra que a opinião dos alunos sobre o curso melhorou
significativamente após o retorno para a “era Pré-Java”.
Por outro lado, existem bons argumentos vindos do lado de quem defende o ensino de
programação introdutória sob a abordagem object-first. Kölling et al (2003) dizem que ensinar POO
não é uma tarefa mais complexa do que ensinar programação procedural, ao contrário do que
muitos professores relatam. Segundo os autores o problema reside na falta de ferramentas
adequadas e experiência de ensino com o paradigma da POO. De fato, ensino de POO é uma tarefa
bem diferente do ensino de programação procedural, pois, como afirmam Sajaniemi e Kuittinen
(2007), aquilo que funcionava no ensino de programação imperativa e procedural não
necessariamente funcionará no ensino de POO. Atualmente Michael Kölling mantém o BlueJ5, um
software para apoiar a aprendizagem de POO seguindo a abordagem object-first. O site do projeto
lista 913 universidades que utilizam o BlueJ como ferramenta de ensino, o que possibilita um
vislumbre da aceitação tanto do software quanto do paradigma de programação que ele apóia.
Quanto a esta pesquisa, a linguagem de programação que foi implementada utiliza mais
fortemente as idéias da programação procedural. Isto se deve principalmente ao fato do pequeno
tamanho dos problemas que foram resolvidos pelos alunos (ver Apêndice A). Além disso, o foco
principal da pesquisa foi a aprendizagem de conceitos fundamentais que, na verdade, independem
do paradigma de programação.
5 http://www.bluej.org/
32
2.2 UTILIZAÇÃO DOS JOGOS DE COMPUTADOR NA EDUCAÇÃO
A utilização de jogos de computador na educação é um tema que vem ganhando cada vez
mais espaço, seja dentro ou fora do meio acadêmico. Microsoft e MIT (Massachusetts Institute of
Technology – Instituto de Tecnologia de Massachusetts) uniram-se para concretizar o projeto
chamado Games-to-Teach6, cujo objetivo é construir jogos para a aprendizagem de conceitos
considerados difíceis em Física, Ciências Ambientais, entre outros.
A empresa Lucas Arts7 disponibiliza planos de aula em seu site para auxiliar professores no
uso dos seus jogos como ferramentas pedagógicas. O exército americano construiu o jogo
America’s Army8 com o objetivo de ajudar a recrutar jovens jogadores para as forças armadas.
Atualmente o site do projeto mostra mais de 10 milhões de usuários registrados, sendo que
aproximadamente metade destes jogadores concluíram todo o jogo. No caso mais específico da
computação, Tiffany Barnes lidera o projeto Game2Learn9, cujo objetivo é produzir pequenos jogos
para serem utilizados como ferramentas de apoio à aprendizagem de conceitos de computação.
Prensky (2003) é um forte defensor da utilização dos jogos como recursos educacionais. O
autor diz que é muito difícil para a maioria dos professores acompanharem a linguagem e o ritmo
frenético dos alunos das novas gerações, e por outro lado, os mais jovens entendem instintivamente
que os seus jogos são os seus melhores professores.
Mitchell e Savill-Smith (2004) analisaram uma extensa bibliografia sobre os jogos de
computador. Entre os vários tópicos discutidos na obra (implicações psico-sociais dos jogos, os
jogos violentos, etc.) os autores também discutem a influência dos jogos no desempenho acadêmico
dos jogadores. Este trabalho mostra que não existe uma relação causal claramente definida entre a
utilização de jogos e o desempenho acadêmico, pois existem indícios tanto de efeitos positivos
quanto de negativos. Os autores mostram algumas evidências apontando que jogar com freqüência
diminuiu o rendimento escolar dos alunos. Uma das possíveis causas é que jogar diminuiu o tempo
disponível para os estudos. Por outro lado, os autores também apresentam algumas evidências de
6 http://www.educationarcade.org/gtt/home.html 7 http://www.lucaslearning.com/edu/lesson.htm 8 http://www.americasarmy.com 9 http://playground.uncc.edu/Game2Learn
33
que os jogos melhoram as habilidades espaciais dos alunos, que podem ajudar alunos com pouco
interesse ou pouca auto-confiança e que os jogos de aventura em particular estimulam a inferência e
o pensamento pró-ativo.
Como visto no parágrafo anterior, não é uma tarefa trivial determinar com precisão qual a
influência dos jogos na aprendizagem, dada a complexidade e a quantidade de aspectos envolvidos.
Apesar de Mitchell e Savill-Smith (2004), citados anteriormente, terem tratado da influência dos
jogos de computador na educação em geral, a situação é muito semelhante no caso específico da
utilização de jogos como apoio à aprendizagem de programação introdutória.
2.2.1 Jogos de Computador no Ensino de Programação Introdutória
Como colocam Feldgen e Clúa (2004), é muito provável que cada aluno já tenha utilizado
um jogo em algum momento da sua vida. Para estes autores os jogos consistem em um
conhecimento comum, algo familiar para os alunos e que pode ser utilizado para iniciar o
desenvolvimento das suas habilidades de resolução de problemas. Seguindo a mesma corrente de
pensamento, Becker e Parker (2005) dizem que os jogos são elementos culturais, e que por esse
motivo não podem ser ignorados pelos educadores.
Clua (2008) coloca que nos jogos os exemplos e soluções oferecem feedback imediato,
visual e prático, auxiliando os aprendizes. O autor ainda argumenta que a motivação causada pelo
jogo freqüentemente encoraja alunos a se aventurarem fora dos limites da ementa da disciplina de
programação introdutória. Além disso, o autor ainda diz que os jogos são universalmente
reconhecidos como a aplicação mais divertida da Ciência da Computação, e questiona a utilização
de bancos de dados, estatística ou exemplos textuais de “Hello World” no ensino de programação.
Valentine (2005) descreve a utilização do jogo Reversi (um jogo de tabuleiro também
conhedico como “Othelo”) no ensino de programação introdutória. Reversi era um dos items do
pacote de jogos das versões mais antigas do Microsoft Windows. Segundo Valentine, Chris Long -
que foi o gerente do grupo de desenvolvimento do Microsoft Word – programou o Reversi como
um exercício para aprender a programar na linguagem C.
Becker e Parker (2005) defendem os jogos arcade clássicos como sendo as ferramentas
ideais para se aprender a programar. Clua (2008) cita alguns destes jogos considerados simples,
34
familiares, divertidos e que podem ser programados por alunos iniciantes, são eles: Space Invaders,
Pac Man, Pong e Asteroids.
Cliburn (2006) realizou um estudo onde verificou o tipo de tarefas de programação
preferidas pelos alunos. Os resultados mostraram que tanto os alunos como as alunas em geral
preferem exercícios relacionados com jogos ao invés dos exercícios tradicionais. O estudo também
mostrou que os alunos têm uma preferência um pouco maior por este tipo de tarefa do que as
alunas.
O estudo de Cliburn e Miller (2008) sugere que os alunos medianos sentem-se mais
motivados para completar um projeto quando sabem exatamente o que deve ser feito. Já os alunos
mais avançados parecem preferir tarefas não estruturadas, onde possuam mais liberdade de criação.
Segundo os autores, os jogos bem conhecidos são bastante familiares para os alunos iniciantes, de
forma que quando estes jogos são utilizados como tarefas de programação os alunos sabem
exatamente o que deve ser feito para concluir o jogo. As diretrizes gerais sugeridas pelos autores
são: deixar muito claro para os alunos iniciantes o que deve ser feito no jogo; sempre que possível
utilizar jogos bem conhecidos; e sempre que possível utilizar jogos com elementos gráficos.
Existem algumas críticas quanto a utilização de tarefas de programação relacionadas com os
jogos. Becker e Parker (2005) dizem que uma das críticas mais comuns é que os gráficos e os sons
dos jogos são irrelevantes para outros tipos de aplicações. Outra crítica diz que a natureza orientada
a eventos de muitos dos jogos coloca-os em uma sub classe muito restrita de problemas de
programação: os problemas orientados a eventos. A idéia geral destas críticas é que a aplicabilidade
dos jogos como ferramentas educacionais é restrita, pois é adequada somente para alguns cursos, e
somente para algumas unidades de ensino destes cursos.
Quanto a primeira crítica citada anteriormente, Becker e Parker (2005) admitem que, apesar
de divertida, a GUI (Graphical User Interface – Interface Gráfica com o Usuário) é um assunto
muito complexo para ser tratado em disciplinas de programação introdutória. Entretanto, os autores
dizem que é possível construir muitos jogos sem uma utilização pesada de recursos visuais, como
por exemplo, os jogos clássicos do tipo arcade. Quanto a segunda crítica, os autores também
admitem que, assim como programação de GUI, programação orientada a eventos é um tópico
demasiadamente complexo para uma disciplina de programação introdutória. Entretanto, os autores
dizem que ao menos no caso dos jogos mais simples a programação orientada a eventos é
35
dispensável e pode ser facilmente substituída por mecanismos mais triviais, que podem ser
entendidos e programados por alunos iniciantes.
A julgar pela quantidade de trabalhos publicados relacionados à utilização de jogos no
ensino de programação introdutória, não é exagero afirmar que muitos pesquisadores concordam
sobre a utilidade dos jogos como ferramentas para o ensino de programação. Percebe-se duas
principais vertentes na literatura pesquisada sobre a utilização dos jogos no ensino de programação:
em uma delas a aprendizagem acontece através da programação de jogos, e na outra a aprendizagem
acontece enquanto o aluno joga um jogo (previamente programado) cujos desafios estão
relacionados à programação introdutória. Apesar de geralmente os trabalhos publicados situarem-se
numa ou noutra classificação, entende-se que não são abordagens mutuamente exclusivas, mas sim
complementares. O jogo construído para a investigação realizada neste trabalho enquadra-se no
segundo tipo das abordagens mencionadas anteriormente: um jogo com desafios de programação.
Outra característica que fica evidente nas pesquisas citadas anteriormente é a recomendação
da utilização de jogos simples, de preferência que sejam familiares para os alunos. Alguns dos
autores defendem a utilização dos jogos clássicos do tipo arcade, que em geral possuem todas as
características citadas como desejáveis. Apesar de não ser explicitamente baseado em nenhum jogo
arcade clássico, o jogo construído neste trabalho segue os princípios de simplicidade sugeridos
pelos autores.
2.3 TAXONOMIA DE BLOOM
Fuller et al (2007) dizem que tanto o desempenho dos alunos em avaliações quanto os
objetivos de aprendizagem destas últimas podem ser descritos por uma linguagem comum definida
em uma taxonomia10. Uma vez que esta pesquisa pretende mensurar a influência de um jogo de
computador na aprendizagem de programação introdutória, optou-se por utilizar nesta mensuração a
taxonomia de objetivos de aprendizagem de Bloom.
10 Segundo a Wikipedia, as taxonomias são esquemas utilizados para classificação, e quase tudo - objetos animados, inanimados, lugares e eventos - pode ser classificado de acordo com algum esquema taxonômico.
36
Segundo Krathwohl (2002), Benjamin S. Bloom inicialmente pensou a taxonomia esperando
que ela reduzisse a atividade trabalhosa de preparar exames finais. Segundo o autor, Bloom buscava
uma forma de facilitar a troca de questões de testes entre professores de várias universidades, cada
questão avaliando o mesmo objetivo de aprendizagem. Para concretizar sua idéia Bloom reuniu uma
equipe de especialistas de universidades dos Estados Unidos, cujo trabalho iniciado em 1949 foi
definitivamente publicado em 1956, sendo comumente referenciado como a taxonomia de Bloom.
Segundo Forehand (2009), a taxonomia de Bloom é uma estrutura com três domínios: o
cognitivo, o afetivo e o psicomotor. Destes três domínios apenas o primeiro é utilizado nos
trabalhos analisados nesta pesquisa, de maneira que esta revisão bibliográfica se atém
especificamente ao domínio cognitivo da taxonomia.
Segundo Krathwohl (2002), a taxonomia original de Bloom (existem algumas revisões da
taxonomia, descritas mais adiante) provê definições cuidadosas para cada uma das seis principais
categorias do domínio cognitivo. Estas categorias são: 1) conhecimento; 2) compreensão; 3)
aplicação; 4) análise; 5) síntese; e 6) avaliação. Segundo o autor, estas categorias são ordenadas da
mais simples para a mais complexa, da mais concreta para a mais abstrata. Além disso, a taxonomia
representa uma hierarquia cumulativa, onde uma categoria mais simples é pré-requisito para a
próxima categoria mais complexa, ou seja, para atingir o nível de Compreensão (nível 2) da
taxonomia é necessário atingir o nível de Conhecimento (nível 1), para atingir o nível de Aplicação
(nível 3) é necessário atingir os dois primeiros níveis (Conhecimento e Compreensão).
Existem alguns verbos associados a cada um dos níveis da taxonomia discutidos
anteriormente. Estes verbos auxiliam na classificação de uma questão de avaliação em um dos
níveis da taxonomia. Mais adiante apresenta-se estes verbos e como alguns deles são interpretados
no contexto da programação introdutória.
2.3.1 Revisões da Taxonomia de Bloom
Segundo Fuller et al (2007) de todas as versões da taxonomia de Bloom a mais utilizada
ainda é a original. A autora destaca a simplicidade da taxonomia como um dos principais fatores da
sua aceitação por parte dos educadores. Entretanto, Fuller também faz algumas críticas à taxonomia,
dizendo que as categorias nem sempre são fáceis de serem aplicadas, que existe uma sobreposição
significativa entre elas e que existe algum debate sobre a ordem em que as categorias análise,
37
síntese e avaliação aparecem na hierarquia. Além disso, segundo a autora, a simplicidade da
taxonomia, que por um lado é considerada um dos seus pontos fortes, indica que cada categoria
combina diferentes tipos de atividades cognitivas, o que não seria desejável.
Segundo Krathwohl (2002), existem muitas variantes da taxonomia original de Bloom, mas
a revisão mais conhecida foi publicada 45 anos depois da publicação da versão original. Segundo o
autor, ao invés de uma estrutura com apenas uma dimensão esta revisão da taxonomia possui duas
dimensões: Conhecimento e Processos Cognitivos. O autor diz que a dimensão do Conhecimento
engloba as subcategorias da categoria de mesmo nome na taxonomia original. Já a dimensão dos
Processos Cognitivos abrange as seis categorias da taxonomia original, porém renomeadas, em
alguns casos apenas para suas formas verbais. A categoria Conhecimento tornou-se Lembrar,
Compreensão tornou-se Entender, Síntese tornou-se Criar (e foi promovida para a categoria mais
alta da hierarquia), Aplicação, Análise e Avaliação tornaram-se respectivamente Aplicar, Analisar e
Avaliar. Segundo o autor, estas categorias foram arranjadas em uma estrutura hierárquica, porém de
maneira menos rígida que na taxonomia original. Além disso, as duas dimensões (Conhecimento e
Processos Cognitivos) formam uma tabela que permite classificar de forma concisa e visual
objetivos, atividades e avaliações (ver Figura 2).
Figura 2. Estrutura da taxonomia de Bloom revisada
Fonte: Adaptado de Krathwohl (2002).
38
Krathwohl (2002) ainda apresenta uma estrutura mais detalhada da taxonomia revisada onde
são listados os verbos envolvidos em cada categoria. Estes verbos auxiliam na categorização de
questões de avaliações em um dos níveis da taxonomia (ver Quadro 1).
1-Lembrar 2-Entender 3-Aplicar 4-Analisar 5-Avaliar 6-Criar Reconhecer Interpretar Executar Diferenciar Verificar Gerar Relembrar Exemplificar Implementar Organizar Criticar Planejar
Classificar Atribuir Produzir Sumarizar Inferir Comparar Explicar
Quadro 1. Níveis da taxonomia de Bloom revisada e seus respectivos verbos
Johnson e Fuller (2007) publicaram um artigo com um título intrigante: Is bloom’s taxonomy
apropriate for Computer Science? Neste artigo os autores colocam que os professores de Ciência da
Computação não costumam considerar os termos síntese e avaliação úteis para a descrição dos
objetivos de aprendizagem nas disciplinas de programação, especialmente no nível introdutório. Por
outro lado, os professores consideram a aplicação do conhecimento como a habilidade mais
importante que os alunos devem desenvolver. Segundo os autores, este foi o principal motivo que
os levou a propor uma nova revisão da taxonomia de Bloom.
Fuller (2007) publicou a “revisão da revisão” da taxonomia de Bloom feita especificamente
para Ciência e Engenharia da Computação, com ênfase na avaliação de tarefas de programação. A
idéia geral proposta por Fuller é a separação dos seis níveis da taxonomia em duas dimensões:
Produzindo (inclui os níveis Aplicar e Criar) e Interpretando (inclui os níveis Lembrar, Entender,
Analisar e Avaliar).
2.3.2 Interpretação da Taxonomia em Programação Introdutória
Thompson et al (2008) relatam os resultados de um estudo onde cinco professores
classificaram as questões de uma prova de programação introdutória de acordo com os níveis da
taxonomia de Bloom. Ao comparar as classificações os autores observaram discrepâncias
significativas entre elas. Segundo os autores, o que gerou as diferenças nas classificações foi o fato
de que nem todos os professores conheciam o contexto da disciplina onde as questão seriam
aplicadas. Depois que este contexto foi explicado aos professores não envolvidos com a disciplina a
39
questão foi classificada no nível Aplicar de forma unânime. Sendo assim, os autores concluem que
não basta ler uma questão para classificá-la neste ou naquele nível da taxonomia de Bloom, é
necessário entender como o assunto que está sendo avaliado foi apresentado aos alunos.
Em Whalley et al (2006) os autores descrevem seus esforços para categorizar as questões de
um instrumento de avaliação de acordo com a taxonomia de Bloom. Este instrumento foi utilizado
para mensurar as habilidades de leitura e compreensão de código de programadores iniciantes.
Sobre a taxonomia de Bloom, os autores dizem que a categorização das questões foi um trabalho
desafiador, mesmo para um grupo experiente de professores de programação. Os autores dizem que
muitas das descrições dos níveis da taxonomia são difíceis de ser interpretados no contexto dos
exercícios de programação, e sugerem que talvez existam algumas deficiências na taxonomia
quando aplicada a este tipo de problemas.
Por conta das dificuldades mencionadas anteriormente, a seguir descreve-se cada uma das
categorias da taxonomia de Bloom revisada e exemplos de como essas categorias11 vêm sendo
interpretadas e utilizadas no contexto da programação introdutória. Alguns autores descrevem suas
interpretações utilizando os termos da taxonomia original. Nestes casos, as citações foram incluídas
nas subseções nomeadas com os termos equivalentes da taxonomia revisada.
2.3.2.1 Interpretação da Categoria Lembrar
Thompson et al (2008) dizem que o processo cognitivo representado por esta categoria é
definido como recuperar conhecimento relevante da memória de longo termo. Para os autores,
questões que enquadram-se neste nível são: a) a identificação de elementos específicos em um
trecho de código; b) reconhecimento da implementação de um determinado conceito; c)
reconhecimento da descrição mais apropriada para um determinado conceito; e d) a lembrança de
qualquer assunto trabalhado na ementa, como a lembrança de uma definição de um conceito, de um
processo, de um algoritmo, um design pattern, entre outros.
11 Nesta seção as palavras categoria e nível são utilizadas como sinônimos para representar as partes da estrutura hierárquica proposta por Bloom.
40
2.3.2.2 Interpretação da Categoria Entender
Segundo Forehand (2009), esta categoria caracteriza-se pela construção de significados
através de linguagem oral, escrita ou gráfica, usando para isto a interpretação, exemplificação,
classificação, sumarização, inferência e explicação.
Hernán-Losada, Pareja-Flores e Velázquez-Iturbide (2008) exemplificam o nível da
Compreensão na taxonomia original (Entender na taxonomia revisada) através de uma tarefa onde
deve-se implementar um programa que implementa a descrição de um algoritmo conhecido,
representado em pseudo-código, fluxograma ou linguagem natural. Outro exemplo citado pelos
autores é a utilização de tarefas onde os alunos recebem um trecho de código com partes faltantes
que devem ser preenchidas com fragmentos de códigos. Scott (2003) também cita exemplos de
questões de avaliação onde o aluno deve explicar em palavras o comportamento de um trecho de
código, predizer os valores de algumas variáveis a cada iteração de um loop, entre outros.
2.3.2.3 Interpretação da Categoria Aplicar
Segundo Thompson et al (2008), no contexto da programação introdutória esta categoria
fica caracterizada quando:
1. O processo, algoritmo ou design pattern é conhecido pelo aluno e ambos são aplicados a
um problema familiar, desde que tal problema ainda não tenha sido resolvido pelo aluno
no mesmo contexto, ou com os mesmos dados, ou com as mesmas ferramentas; e
2. O processo, algoritmo ou design pattern é conhecido pelo aluno, e ambos são aplicados
na resolução de um problema não familiar.
Hernán-Losada, Pareja-Flores e Velázquez-Iturbide (2008) sugerem que os alunos poderiam
receber um programa que implementa o teorema de Pitágoras, e a partir deste programa exemplo
deveriam implementar programas para outros propósitos, como cálculo da área de um círculo,
conversão da escala Fahrenheit para Celsius, etc. Outro exemplo citado pelos autores é a ordenação
de um vetor de elementos não numéricos, assumindo que os alunos já tenham estudado os
algoritmos para ordenação de vetores numéricos.
Thompson et al (2008) fornecem um exemplo de um problema classificado na categoria
Aplicar onde o aluno deve executar mentalmente uma expressão como: 2 + 4 / 7 * 5 % 3 = = 7. Se a
41
expressão é simples, como “1 + 2”, o aluno poderia avaliar a expressão apenas usando a memória, e
então a questão enquadraria-se na categoria Lembrar. No caso do primeiro exemplo dado, a
complexidade da expressão requer que o aluno observe as regras que determinam a ordem de
precedência para só então executar as operações na ordem correta. Segundo os autores, o que
classifica uma questão como esta na categoria Aplicar é o fato de que o aluno aplica um processo
conhecido para resolver um problema familiar, porém os dados do problema não lhe são familiares.
Os autores ainda chamam a atenção para o fato de que embora a palavra avaliar seja utilizada na
descrição do exemplo (avaliar uma expressão) o significado da palavra neste caso não é o mesmo
do processo cognitivo Avaliar da taxonomia, que é caracterizado pela realização de julgamentos
tomando critérios e padrões como base. Este nível da taxonomia é descrito mais adiante.
2.3.2.4 Interpretação da Categoria Analisar
Thompson et al (2008) dizem que no contexto da programação introdutória esta categoria
adquire as seguintes interpretações: 1) dividir uma tarefa de programação em suas partes
componentes (classes, componentes de software, etc.); 2) organizar as partes componentes para
atingir um objetivo geral; 3) identificar componentes críticos para o desenvolvimento; e 4)
identificar componentes ou requisitos não importantes.
Thompson et al (2008) ainda fornecem exemplos de duas questões que poderiam ser
utilizadas para avaliar os alunos na categoria Analisar. Dado um código para uma classe de nome
Circulo, as questões sugeridas pelos autores são: 1) O que é o método Circulo na classe? 2) Como
ele se diferencia dos outros métodos da classe? Neste exemplo, as respostas esperadas seriam: 1) é
um construtor; e 2) ele é invocado quando um novo objeto é criado. Segundo os autores, a primeira
questão (o que é) envolve apenas lembrar que um método com o mesmo nome da classe é um
construtor. Entretanto, na segunda questão os alunos devem diferenciar o construtor dos demais
métodos da classe, o que enquadraria a questão na categoria Analisar.
2.3.2.5 Interpretação da Categoria Avaliar
Thompson et al (2008) dizem que a avaliação pode ser definida como a realização de
julgamentos baseados em critérios e padrões. Os autores fornecem dois exemplos para esta
categoria: 1) determinar se um trecho do código satisfaz os requisitos definindo uma estratégia de
teste apropriada; e 2) criticar a qualidade de um trecho de código baseando-se em boas práticas de
42
programação ou critérios de eficiência. Os autores ainda citam um exemplo onde dois trechos de
código são apresentados aos alunos, ambos os trechos com o mesmo propósito: encontrar o menor
valor em um array através de loops. Então, solicita-se aos alunos que discutam as diferenças entre
as soluções. Segundo os autores, ao discutir as diferenças os alunos estão comparando os dois loops
e contrastando suas utilizações, o que se enquadra na categoria Entender. Porém, além disso os
alunos devem discutir qual dos dois métodos é mais apropriado, o que significa avaliar o uso de
dois loops com o mesmo propósito.
2.3.2.6 Interpretação da Categoria Criar
Thompson et al (2008) definem a criação como o ato de juntar elementos para formar um
todo coerente e funcional. Os exemplos desta categoria fornecidos pelos autores são: 1) propor um
novo algoritmo alternativo ou hipotetizar que uma nova combinação de algoritmos resolverá o
problema; 2) conceber um processo alternativo ou estratégia para resolver um problema; e 3)
construir um segmento de código ou programa utilizando algoritmos inventados ou aplicando
algoritmos conhecidos em uma combinação ainda não utilizada pelo aluno.
No Quadro 2 são apresentados exemplos de atividades retiradas dos trabalhos mencionados
anteriormente bem como suas respectivas classificações na taxonomia de Bloom.
43
Categoria Interpretação da categoria da taxonomia no contexto da programação
Lembrar
Recuperação de conhecimento relevante da memória de longo termo. Identificar elementos específicos em um trecho de código. Reconhecer a implementação de um determinado conceito. Reconhecer a descrição mais apropriada para um determinado conceito. Lembrar de um conceito, processo, algoritmo, etc. Listar operadores de acordo com a ordem de precedência. Definir o propósito de um método construtor. Descrever um determinado padrão de projeto. Citar os nomes dos tipos de loops em uma linguagem de programação. Listar N métodos que executem operações de entrada e saída de dados.
Entender
Construção de significados através de diferentes tipos de linguagens. Escrever em pseudo-código, fluxograma ou linguagem natural um programa que calcule uma fórmula bem conhecida. Completar partes faltantes de um programa utilizando fragmentos de código. Explicar com palavras o comportamento de um trecho de código. Predizer valores de variáveis depois da execução de um trecho de código. Traduzir um algoritmo de uma forma de representação para outra. Explicar um conceito, algoritmo ou padrão de projeto. Apresentar exemplos de um conceito, algoritmo ou padrão de projeto.
Aplicar
Utilização de processos conhecidos para executar ou implementar. Implementar um programa utilizando como exemplo um código que resolva um problema semelhante. Implementar ordenação de vetores não numéricos com alunos que já tenham ordenado vetores numéricos. Executar mentalmente expressões seguindo as regras de precedência. Resolver um problema familiar, mas com dados ou ferramentas não familiares. Modificar o código de um loop do tipo for para um do tipo while.
Analisar
Decomposição de um problema em suas partes constituintes e determinação das relações entre as partes e o todo. Dividir uma tarefa de programação em suas partes componentes. Organizar as partes componentes para atingir um objetivo geral. Identificar componentes críticos para o desenvolvimento. Identificar componentes ou requisitos não importantes. Diferenciar um método construtor dos demais métodos de uma classe.
Avaliar
Realização de julgamentos baseados em critérios e padrões. Determinar se um código satisfaz os requisitos definindo uma estratégia de teste apropriada. Criticar a qualidade de um código baseando-se em boas práticas de programação ou critérios de eficiência do código. Avaliar qual de dois algoritmos que resolvem a mesma tarefa é mais adequado. Encontrar um erro de lógica em um trecho de código dado.
Criar
Juntar elementos para formar um todo coerente e funcional. Propor algoritmo, processo ou estratégia alternativa para um problema. Hipotetizar que uma nova combinação de algoritmos resolverá o problema Construir um programa utilizando algoritmos inventados. Aplicar algoritmos conhecidos em uma combinação não familiar para o aluno.
Quadro 2. Síntese da interpretação da taxonomia de Bloom em programação
2.4 CORREÇÃO AUTOMÁTICA DE ALGORITMOS
A correção automática fez-se necessária nesta pesquisa principalmente pelo fato de que o
progresso dos alunos no jogo dependia da corretude dos seus algoritmos. Como os desafios
presentes no jogo estavam relacionados à resolução de problemas algorítmicos, foi necessário um
44
mecanismo que avaliasse automaticamente os programas construídos pelos alunos, e em função do
resultado desta avaliação determinasse se o aluno poderia ou não avançar nos níveis do jogo. A
correção manual dos algoritmos por um professor seria impraticável, já que no caso do jogo o aluno
precisaria esperar pela correção manual para só então prosseguir jogando.
Segundo Rahman e Nordin (2007), existem duas abordagens mais comuns na avaliação
automática de exercícios de programação: a abordagem dinâmica e a estática. Na abordagem
dinâmica a avaliação é realizada através da execução do programa. Neste caso, dada uma entrada o
programa é considerado correto se a sua saída é igual a um determinado valor esperado. Já na
abordagem estática a avaliação é realizada sem a necessidade da execução do código. A seguir
discute-se em maiores detalhes as duas abordagens.
2.4.1 Técnicas Dinâmicas
Como dito anteriormente, as técnicas dinâmicas de avaliação de programas caracterizam-se
pela execução do programa. Nestes casos apenas a saída do programa é confrontada com um
conjunto de valores considerados corretos. Douce (2005) chama a atenção para o fato de que em
muitos sistemas de avaliação automática que seguem esta abordagem é possível que mesmo um
programa mal construído produza os resultados corretos, o que diminui a qualidade da avaliação
automatizada. A solução sugerida pelo autor é uma avaliação composta por sub-avaliações, cada
uma delas com um critério diferente.
Daly e Horgan (2004) desenvolveram o RoboProof, um ambiente de aprendizagem que gera
e avalia exercícios de programação, provê feedback durante as atividades e detecta plágio. O
RoboProof possui 51 exercícios que devem ser resolvidos pelos alunos ao longo de um semestre em
uma disciplina de programação introdutória. Segundo os autores, o sistema de avaliação compara os
valores de saída do programa do aluno com a saída esperada usando um conjunto de dados de teste
pré-definido para cada questão ou um conjunto de teste aleatório.
Douce (2005) diz que os sistemas de avaliação automática têm vários problemas em comum.
Para o autor, o problema mais significativo está relacionado com os requisitos necessários para a
avaliação de cada exercício. Para que se consiga avaliar automaticamente os algoritmos dos alunos
todos os exercícios devem ser cuidadosamente especificados, entradas, saídas e esquemas de
marcação precisam ser definidos, entre outros detalhes.
45
Assim como Blumenstein et al (2004), Suleman (2008) também utiliza um esquema de
marcação com XML onde são definidas as configurações da avaliação automática de cada
exercício. O trabalho de Suleman apenas compara a saída dos programas dos alunos com um
conjunto de valores pré-definidos como corretos.
A avaliação de programas por meio da verificação das saídas geralmente implica na adoção
de padrões rígidos de formatação desta saída. Tome-se como exemplo um sistema de avaliação que
espera por um número como saída de um programa de cálculo de fatorial. Se o programa do aluno
apresenta a saída no formato “o fatorial de 3 é 6”, ou “fat(3) = 6”, ou ainda “3! = 6” o programa
seria considerado incorreto, ainda que o cálculo do fatorial tenha sido implementado corretamente
pelo aluno. Saikkonen, Malmi, e Korhonen (2001) resolveram este problema avaliando os valores
retornados por cada função ao invés de avaliar a saída de todo o programa. Sendo assim, desde que
os valores retornados pelas funções estejam de acordo com as respostas pré-definidas para cada
exercício a formatação da saída utilizada pelo aluno não interferirá na corretude do programa.
2.4.2 Técnicas Estáticas
Conforme Truong, Roe, e Bancroft (2004), as técnicas para a análise estática de um
programa que vêm sendo adotada pelos pesquisadores variam desde comparação de strings baseada
no código fonte (a forma mais simples) até a comparação de grafos que representam as estruturas
dos programas (a forma mais complexa).
Rahman e Nordin (2007) citam algumas análises que podem ser feitas em exercícios de
programação e que enquadram-se na abordagem estática, tais como: análise do estilo de
programação, análise dos erros sintáticos ou semânticos, avaliação de métricas de software, análise
de similaridade estrutural e não-estrutural, análise de palavras chave, detecção de plágio, entre
outras.
Saikkonen, Malmi, e Korhonen (2001) descrevem o Scheme-Robo, um sistema que além de
realizar a verificação dinâmica do código do aluno também provê ferramentas para analisar a
estrutura e tempo de execução dos programas, além de permitir a detecção de plágio. O sistema
também utiliza listas de palavras chave para a correção dos algoritmos. No Scheme-Robo a análise
da estrutura dos programas dos alunos e a detecção de plágio são feitas através da criação de uma
árvore sintática abstrata. Os nomes das variáveis são removidos e, por exemplo, definições e
46
argumentos são ordenados. Dessa forma duas árvores podem ser comparadas. Segundo os autores a
técnica não funciona bem quando os exercícios são muito pequenos.
Rahman e Nordin (2007) também descrevem a análise estrutural, utilizada para determinar a
similaridade entre a estrutura dos programas dos alunos e a solução do problema criada pelo
professor. Esquemas da estrutura tanto do programa do professor quanto do aluno são gerados e
então comparados. Segundo os autores, dependendo da complexidade do problema vários esquemas
alternativos deverão ser criados pelo professor, de maneira que algumas das possíveis variações das
soluções dos alunos sejam contempladas pelo mecanismo de correção automática.
Blumenstein et al (2004) criaram um sistema que analisa a estrutura dos códigos fonte dos
alunos avaliando os comentários, a identação e o estilo de programação nas linguagens Java, C e
C++. Segundo os autores, os comentários são analisados em função do número total de linhas no
código do programa. Os autores propõem que o percentual de comentários em um programa deve
ser no mínimo 30% da quantidade de linhas de código não comentadas. A utilidade dos
comentários não é considerada, ou seja, o aluno poderia escrever qualquer coisa como um
comentário apenas para burlar o sistema de avaliação. Segundo os autores, a identação do código é
avaliada calculando a porcentagem média de identação em cada um dos arquivos submetidos por
um aluno. As identações são procuradas em lugares estratégicos do código fonte, como início de
funções, comandos de controle e variáveis globais. A métrica utilizada para avaliar as identações é
uma razão entre o número de identações encontradas e o número de pontos estratégicos do código
que foram analisados. Quanto ao estilo de programação do aluno, o software desenvolvido pelos
autores compara o número de funções no código fonte com o número de blocos de comentário e
verifica a utilização de “números mágicos”, valores numéricos que são utilizados ao longo do
código e que poderiam ser definidos como constantes. Os próprios autores admitem que estas
métricas são um tanto simplistas no que se refere à avaliação dos códigos dos alunos.
Truong, Roe, e Bancroft (2004) descrevem um framework para realizar a análise estática de
programas de alunos iniciantes escritos em Java. O framework verifica: 1) o número total de
variáveis, declarações de comandos e expressões; 2) se a variável foi declarada tanto no escopo do
método quanto da classe; 3) número de decisões lógicas em um programa (complexidade
ciclomática); 4) se existem parâmetros não utilizados; 5) expressões redundantes (como x == true);
6) variáveis não utilizadas; 7) utilização de números mágicos; 8) utilização adequada dos
modificadores de acesso (private, protected e public); 9) se todos os comandos switch possuem o
47
caso default e se em cada bloco case existe um comando break; 10) se o número de caracteres por
linha é no máximo 80; e 11) se o aluno utilizou espaços em branco ao invés da tecla TAB para
identar o código. Um conjunto de critérios semelhantes também é utilizado no trabalho de Ala-
Mutka, Uimonen e Järvinen (2004).
2.4.2.1 Comparação de Árvores Sintáticas Abstratas
Alguns dos trabalhos mencionados anteriormente representam os programas como árvores
sintáticas abstratas, e então comparam estas estruturas com o objetivo de determinar o grau de
similaridade entre os programas.
Sager et al (2006) utilizam algoritmos para comparação de árvores sintáticas abstratas
(AST) com o objetivo de determinar a similaridade entre o código de duas classes Java. Uma das
técnicas mencionadas é a tree edit distance. Esta técnica é utilizada para determinar quantos passos
são necessários para transformar uma árvore em outra aplicando um conjunto de operações
elementares de edição, como inserção, substituição e remoção de nós. No algoritmo usado pelos
autores cada passo da transformação tem um custo associado. O algoritmo então calcula o menor
custo de transformação entre duas árvores e este custo é normalizado pela soma do número de nós
em cada uma das árvores comparadas. Quanto menor este custo de transformação maior é a
similaridade entre as duas árvores.
Baker (1992) desenvolveu um software chamado Dup com o objetivo de encontrar trechos
de código duplicados ou relacionados em sistemas com uma grande quantidade de código. Este não
é um trabalho que trata especificamente da correção automática de programas, porém, a detecção de
código duplicado envolve a comparação e a determinação de um grau de similaridade entre trechos
de programas. Para detectar os trechos de código duplicados o Dup utiliza o próprio texto do código
fonte, mas antes de realizar as comparações ele: remove os caracteres de tabulação, espaços e
comentários; sobrescreve os identificadores de funções, variáveis e tipos com um valor pré-
definido; concatena todas as linhas em uma única linha e atribui um identificador único para cada
linha. O resultado do algoritmo é um conjunto de pares de strings consideradas como clonadas.
O framework apresentado no trabalho de Truong, Roe, e Bancroft (2004) faz a análise da
estrutura do programa baseado em uma representação em XML da sua árvore sintática abstrata.
Este arquivo XML é composto por nós genéricos, como por exemplo um nó loop para representar
48
qualquer tipo de laço de repetição. Da mesma forma existem nós genéricos para expressões e
desvios condicionais. Os autores chamam isto de forma normalizada dos blocos de código, e
mencionam que esta normalização ajuda a minimizar o número de variações possíveis para a
solução de um problema.
Como citado anteriormente, duas ASTs podem ser comparadas utilizando as técnicas de tree
edit distance. Entretanto, determinar o custo para transformar uma árvore em outra através desta
técnica não é um processo trivial. Uma alternativa mais simples é transformar as ASTs que
representam os programas em texto, ou seja, serializá-las, e então compará-las utilizando técnicas
de string edit distance. Segundo Ristad e Yianilos (1998), esta técnica permite que se calcule a
similaridade entre duas strings por meio do número mínimo de inserções, deleções e substituições
de caracteres que são necessárias para transformar uma string em outra. Baxter el al (1998)
propõem um formato de serialização da AST onde os nós das sub-árvores são visitados na ordem:
raiz, filho esquerdo e filho direito. O rótulo e o número de nós descendentes de cada um dos nós
visitados é concatenado em uma string que conterá a versão serializada da AST (ver Figura 3).
Seqüência de código
AST representando o
código
AST representada textualmente (serializada)
Figura 3. Exemplo do processo de construção e serialização de uma AST
Fonte: Adaptado de Baxter el al (1998).
49
Navarro (2001) menciona algumas técnicas que podem ser utilizadas para comparar strings.
O autor cita pesquisas onde estas técnicas vêm sendo utilizadas para, por exemplo, recuperar a
forma original de um sinal depois de transmitido por canais ruidosos, encontrar subseqüências de
DNA depois de possíveis mutações, pesquisa de texto onde existem erros de digitação ou
ortográficos, reconhecimento de texto manuscrito, detecção de vírus e programas intrusos, entre
outros. O autor ainda enumera algumas variações mais utilizadas das técnicas de comparação de
strings, sendo que a variação que mais importa para este estudo é a distância de Levenshtein,
também conhecida simplesmente por edit distance.
Na década de 60 Vladimir I. Levenshtein publicou um artigo chamado “Binary codes
capable of correcting deletions, insertions, and reversals”12. É neste trabalho que tem origem o que
mais tarde ficou conhecida como a distância de Levenshtein, que representa o custo de se
transformar uma string em outra utilizando a remoção, inserção ou substituição de caracteres.
Gilleland (2009) descreve o algoritmo para o cálculo da distância de Levenshtein como
demonstrado na Quadro 3.
n recebe o tamanho da string de entrada s m recebe o tamanho da string t com a qual será feita a comparação Se n = 0, retorna m e finaliza Se m = 0, retorna n e finaliza Construa a matriz d (distâncias) contendo 0..m linhas e 0..n colunas Inicialize a primeira linha com os valores 0..n Inicialize a primeira coluna com os valores 0..m Para cada caractere de s (contador i de 1 até n) Para cada caractere de t (contador j de 1 até m) Se s[i] é igual a t[j], o custo é 0, senão é 1 A matriz d na posição [i,j] deve receber o mínimo entre:
d[i-1, j] + 1. d[i, j-1] + 1.
d[i-1, j-1] + custoAcumulado. Ao final das iterações o custo está armazenado na célula d[n,m].
Quadro 3. Algoritmo para o cálculo da distância de Levenshtein
Fonte: Adaptado de Gilleland (2009).
Gilleland (2009) ainda descreve um exemplo onde a distância de Levenshtein é calcula na
transformação da string “GUMBO” em “GAMBOL”. O autor diz que o algoritmo corresponde à
12 http://www.niuf.nist.gov/dads/HTML/Levenshtein.html
50
nossa intuição de que para executar a transformação é necessário substituir “A” por “U” e adicionar
a letra “L” ao final da palavra original. Então, o processo é completado com uma substituição e uma
inserção, o que gera um custo de edição igual a 2.
2.5 CONSIDERAÇÕES
Este capítulo iniciou abordando as questões relacionadas à programação introdutória. Foram
apresentados os problemas relacionados com a aprendizagem de programação em nível
introdutório, cujas disciplinas relacionadas costumam apresentar altas taxas de evasão e reprovação.
Também foram abordados alguns dos tópicos de programação freqüentemente considerados como
de difícil aprendizagem pelos alunos. Os resultados variam de uma pesquisa para outra, mas em
geral, percebe-se que tópicos como loops, arrays, recursividade, desvios condicionais, herança e
polimorfismo sempre encabeçam a lista dos tópicos considerados mais difíceis.
Verificou-se também que as linguagens de programação mais utilizadas em disciplinas
introdutórias são JAVA e C++. Ambas as linguagens são baseadas em texto, e alguns trabalhos vêm
apontando os problemas relacionados à aprendizagem de sintaxe destas linguagens ou de linguagens
semelhantes. Alguns autores colocam que quando utilizam estas linguagens os alunos precisam
aprender sintaxe antes de aprender a resolver problemas. Uma alternativa seriam as linguagens de
programação sintaticamente simplificadas, criadas especificamente com fins didáticos. Estas
linguagens resolvem um problema mas criam outro: a dificuldade na transição para uma linguagem
“real”, sintaticamente mais difícil.
Quanto aos paradigmas de programação adotados nas disciplinas introdutórias, as
publicações analisadas parecem apontar em duas principais direções: programação procedimental
(ou procedural) e programação orientada a objetos. Esta última divide-se em duas variantes: object-
first e object-later. Na primeira, conceitos fundamentais de POO como classes e objetos são
apresentados logo de início para os alunos, antes mesmo de tópicos como variáveis ou tipos de
dados. Já na vertente object-later faz-se o caminho inverso, iniciando com conceitos fundamentais
(variáveis e tipos de dados) e ao final do semestre apresenta-se os conceitos de POO. A literatura
consultada não mostra evidências de que uma ou outra abordagem seja mais adequada para a
aprendizagem. Os defensores da abordagem object-first argumentam que muitos professores não
sentem-se seguros para ensinar POO, e por isso evitam este paradigma. Além disso, a POO parece
exigir estratégias e ferramentas didáticas bem específicas, o que acaba por dificultar ainda mais a
51
adoção do paradigma por muitos professores. Por outro lado, os defensores de abordagens mais
tradicionais argumentam que o ensino de programação introdutória com POO desvia o foco da
resolução de problemas para o projeto de sistemas, o que seria inadequado para um primeiro contato
com programação. Outra crítica baseia-se no argumento de que a utilização de POO é influenciada
por forças do mercado, e não por pesquisas que indiquem que tal mudança seja benéfica para a
aprendizagem.
Analisando a literatura consultada observou-se que há um interesse na utilização de jogos
para apoiar a aprendizagem em várias áreas e disciplinas. Entretanto, não existem indícios claros de
que a utilização de jogos na educação promova melhorias na aprendizagem, seja em programação
introdutória ou em disciplinas de outras áreas. As publicações analisadas que relatam casos onde
jogos foram utilizados para apoiar a aprendizagem de programação introdutória sugerem que podem
haver melhorias na motivação dos alunos. Já no caso da aprendizagem a literatura consultada
apresenta evidências tanto de que jogos melhoram a aprendizagem quanto apresentam evidências de
que esta melhoria não acontece.
A taxonomia de objetivos de aprendizagem de Bloom também foi abordada neste capítulo,
já que optou-se por avaliar o progresso dos alunos nos níveis da taxonomia com o objetivo de não
utilizar apenas uma pontuação (uma nota) como indicador da aprendizagem. Algumas das revisões
da taxonomia foram apresentadas, com ênfase na chamada “taxonomia revisada”, a revisão
considerada como a mais conhecida. Além disso, discutiu-se de que forma a taxonomia de Bloom
vem sendo interpretada no contexto da programação introdutória e que tipos de atividades de
programação vêm sendo desenvolvidas para cada um dos níveis da taxonomia.
Por fim, discutiu-se o tema “Correção Automática de Algoritmos”, onde foram discutidas as
técnicas dinâmicas e estáticas para avaliação automática de programas. Nas técnicas estáticas o
algoritmo não é executado, e por este motivo os resultados gerados (as saídas) não interessam para a
correção. As técnicas estáticas analisam um código fonte ou uma estrutura que o represente. Alguns
exemplos de análises estáticas são: verificação de plágio, análise do estilo de programação do aluno,
análise de similaridade estrutural, entre outras. Nas técnicas dinâmicas o programa é realmente
executado e suas saídas são comparadas com resultados esperados. Se houver equivalência entre
estes últimos então o programa é considerado correto. Neste trabalho utilizou-se uma métrica
híbrida para a avaliação dos programas dos alunos com base nas pesquisas mencionadas no final
deste capítulo. Os detalhes desta métrica são apresentados na Seção 4.1.2 .
52
3 TRABALHOS RELACIONADOS
Nesta seção são descritos alguns trabalhos relacionados ao tema de pesquisa desta
dissertação. Três classes de trabalhos foram consideradas como sendo similares a esta pesquisa: 1)
os trabalhos que tratam da influência dos jogos na aprendizagem de programação introdutória; 2) os
trabalhos que relatam a utilização de jogos no ensino de programação introdutória; e 3) os softwares
utilizados como ferramenta de apoio à aprendizagem de programação introdutória.
3.1 PROTOCOLO DE ANÁLISE
A análise dos trabalhos similares foi realizada respeitando as três classes de trabalhos
descritas anteriormente. Das publicações encontradas deu-se preferência àquelas que demonstravam
resultados mais sólidos. Este critério foi particularmente observado na análise de ambientes de
apoio ao ensino de programação, pois esta é uma área onde muitos artigos são publicados na forma
de “propaganda de um produto” (WAZLAWICK, 2008), e nestes casos não apresentam resultados
sobre o impacto da ferramenta construída na aprendizagem de programação. Cabe também ressaltar
que não foi feita uma revisão sistemática sobre os assuntos estudados, ao menos no sentido mais
rigoroso do termo. A seguir descreve-se as três classes de trabalhos considerados similares.
3.2 JOGOS NA APRENDIZAGEM DE PROGRAMAÇÃO
Os trabalhos que analisam o impacto da utilização de jogos na aprendizagem de
programação introdutória contribuíram para esta pesquisa fornecendo um referencial quanto à
metodologia utilizada nas experimentações, nos casos em que estas foram realizadas.
A maioria das pesquisas analisadas sobre a utilização dos jogos na aprendizagem de
programação relatam melhorias na motivação dos alunos. De maneira geral, esses resultados são
obtidos através da aplicação de questionários logo após uma intervenção onde os alunos utilizam
um jogo. Analisando os resultados apresentados nas pesquisas consultadas observou-se que nem
sempre o aumento da motivação provocado pela utilização de jogos transforma-se em melhoria na
aprendizagem. O Quadro 4 sumariza alguns detalhes sobre as principais publicações analisadas onde
a influência dos jogos na motivação ou aprendizagem foi mencionada.
53
Publicação Métodos Utilizados Resultados Cliburn (2006)
The effectiveness of games as assignments in an introductory programming course.
Motivação mensurada através de questionário. A aprendizagem foi mensurada através da comparação da média final dos alunos que jogaram com a média dos que não jogaram.
Alunos mais motivados, porém sem melhorias nas notas.
Bayliss (2007) The Effects of Games in CS1-3.
Os alunos declararam-se mais satisfeitos com os jogos do que sem eles. A aprendizagem foi mensurada através da comparação da média final dos alunos que utilizaram jogos com a média dos que não utilizaram.
Alunos mais motivados, porém sem melhorias nas notas. Entretanto a autora sugere que os resultados positivos podem aparecer nos semestres seguintes.
Bierre e Phelps (2004) The use of MUPPETS in an introductory java
programming course. Percepção do professor sobre a motivação dos alunos.
Alunos mais motivados. Não mencionam melhorias nas notas.
Bierre et al (2006) Motivating OOP by blowing things up: an
exercise in cooperation and competition in an introductory java
programming course.
Questionário de avaliação da disciplina com perguntas sobre à percepção do aluno sobre a sua aprendizagem. Testes estatísticos foram utilizados para comparar as opiniões dos alunos.
Alunos declararam-se mais motivados e disseram que aprenderam mais.
Long (2007) Just For Fun: using programming games in
software programming training and education.
Questionário aplicado à participantes da comunidade online do Robocode. Haviam questões relacionadas à motivação e a aprendizagem de novas habilidades de programação.
Aumento na motivação. A maioria dos participantes declarou que suas habilidades de programação melhoraram
Eagle e Barnes (2008) Wu's castle: teaching arrays and loops in a
game.
Pré e pós-teste e um questionário de natureza qualitativa. O desempenho no exame final dos alunos também foi considerado.
Melhorias foram observadas nas notas.
Eagle e Barnes (2009) Experimental Evaluation of an Educational
Game for Improved Learning in Introductory Computing.
Foi utilizado pré e pós-teste. Depois do pós-teste os alunos escolheram mais uma de duas intervenções possíveis e realizaram mais um pós-teste de acordo com a intervenção escolhida. O mesmo instrumento foi utilizado no pré e pós-teste, mudando apenas a ordem das questões e das suas respostas. As questões foram classificadas segundo a taxonomia de Bloom.
Participantes foram divididos em dois grupos: os que jogaram antes de aprender loops e os que construíram um programa antes de aprender o mesmo assunto. Os alunos que jogaram tiveram melhor desempenho que os outros.
Barnes et al (2007) Game2Learn: building CS1 learning games
for retention.
Entrevista com os alunos e análise de artefatos produzidos por eles, tais como blogs, relatórios e apresentações finais.
Melhorias na motivação.
Esta Pesquisa
Experimentos com 3 turmas onde uma delas foi tratada como grupo de controle. Utilização de pré e pós-teste em todos os experimentos para identificar progressos na aprendizagem. As questões dos testes foram classificadas segundo a taxonomia de Bloom.
Não foram identificadas melhorias significativas na aprendizagem. Indícios mais fracos apontaram que o jogo pode auxiliar alguns grupos de alunos.
Quadro 4. Pesquisas sobre o papel dos jogos na aprendizagem de programação introdutória
54
Observando os dados do Quadro 4 verifica-se que tanto existem indícios de que a utilização
dos jogos melhora a aprendizagem quanto existem indícios de que isso não acontece. Outro aspecto
que deve ser observado nas pesquisas citadas é a utilização da diferença entre as pontuações de pré
e pós-teste como um indicador da aprendizagem. Ou seja, quanto maior a diferença entre as
pontuações maior o nível de aprendizagem atingido pelo aluno e vice-versa. Considerando que uma
pontuação nada mais é do que uma nota, o que se observa é que a praxe na mensuração da
aprendizagem consiste em representar a aquisição de conhecimentos através de um número. Mesmo
considerando que existem dimensões do conhecimento que possivelmente não seriam
representáveis por pontuações, este trabalho também utilizou a diferença entre pré e pós-teste como
um indicador da aprendizagem. Porém, além as pontuações o progresso nos níveis da taxonomia de
Bloom foi utilizado na mensuração do desempenho dos alunos.
3.3 UTILIZAÇÃO DOS JOGOS COMO FERRAMENTAS DIDÁTICAS
Nesta seção são apresentados alguns trabalhos que mostram como os jogos podem ser
utilizados na aprendizagem de programação introdutória. Como um dos objetivos específicos desta
pesquisa foi construir um jogo com desafios em forma de problemas algorítmicos, os trabalhos
similares citados a seguir serviram como inspiração para a criação tanto do jogo quanto dos seus
desafios.
3.3.1 Game2Learn
Barnes et al (2007) descrevem o Game2Learn, um projeto que utiliza a implementação de
jogos de computador como metáfora para o ensino de conceitos de programação, game design,
usabilidade, entre outros. Barnes et al descrevem dois jogos que foram implementados por alunos
no verão de 2006: Saving Princess Sera e The Catacombs.
No primeiro jogo os alunos devem resolver problemas implementando pequenos programas
para libertar a princesa Sera, raptada no início da trama. Quando os alunos cometem erros
(programas com problemas, por exemplo) eles devem lutar contra um inseto respondendo questões
sobre Ciência da Computação. Em um dos desafios os alunos respondem questões de múltipla
escolha para ajustar dois loops aninhados (ver Figura 4), determinando quando os contadores
ultrapassam os limites de uma grade onde devem ser colocados os ovos para ajudar um fazendeiro.
55
Figura 4. Laços aninhados - projeto Game2Learn
Fonte: Barnes et al (2007).
Em outro desafio os alunos precisam ajustar um loop do tipo do-while selecionando e
ordenando linhas de código disponibilizadas no próprio ambiente do jogo. Para montar o código da
solução final o aluno conta com comentários que fornecem dicas sobre onde devem estar
posicionadas as linhas de código para que o problema do desafio seja solucionado.
Outro jogo do projeto Game2Learn é o The Catacombs. Neste jogo o aluno é um aprendiz
de feiticeiro que deve dominar a aplicação de três feitiços (programas) progressivamente mais
complexos para salvar duas crianças que estão presas em catacumbas. O primeiro feitiço utiliza dois
desvios condicionais para destrancar uma porta. O segundo utiliza loops aninhados para construir
uma ponte, e o terceiro feitiço utiliza loops aninhados para resolver um criptograma.
3.3.2 Maze Framework
Nevison e Wells (2004) descrevem um framework contendo classes que modelam um
labirinto. Estas classes são fornecidas aos alunos como “caixas pretas”, ou seja, os alunos apenas
utilizam os serviços de cada classe sem conhecerem os detalhes de implementação. Como primeiro
trabalho com o framework os autores propõem a implementação de um personagem que caminha
pelo labirinto. Entretanto, a tarefa dos alunos é apenas preencher o corpo de um único método
(onMazeInput) com o código necessário para movimentar o personagem em resposta as entradas:
“para frente”, “para trás”, “para direita” e “para esquerda”. Os autores ainda propõem algumas
56
variações desta tarefa. Por exemplo, em reposta à entrada “para direita” o personagem que caminha
no labirinto poderia não apenas virar para a direita, mas também caminhar para a célula do lado
direito caso esta não fosse um muro. Estes exemplos trabalham com o conceito de desvio
condicional.
Nevison e Wells (2004) também apresentam algumas possibilidades de uso do framework
do labirinto para a experimentação com laços de repetição. Os autores sugerem, por exemplo, a
programação de um personagem que caminhe várias células (ao invés de apenas uma) em resposta
ao comando “para frente” até que encontre um muro. Outra possibilidade é a implementação de um
personagem que caminhe aleatoriamente pelo labirinto, onde em cada iteração de um laço de
repetição uma nova direção é sorteada para o personagem. Uma variação desta tarefa consiste no
armazenamento das células por onde o personagem já passou em alguma estrutura de dados, e
permitir que o personagem caminhe em uma célula já visitada somente quando não houver outra
opção. Outra variação é implementar o personagem como se este caminhasse pelo labirinto sempre
com a mão esquerda ou direita encostada na parede. Os autores ainda sugerem a implementação de
um personagem que caminhe pelo labirinto utilizando recursão ao invés do laço de repetição.
Um dos autores do trabalho, Wells, relata que utilizou o framework do labirinto em um
curso de programação introdutória em Java com grande sucesso. Os desafios mais simples foram
apresentados aos alunos logo que estes aprenderam (em sala de aula) o conceito de desvio
condicional. Segundo Nevison e Wells (2004) os alunos descreveram a experiência como
desafiadora e sentiram-se motivados a implementar um personagem que conseguisse chegar até a
saída do labirinto. Muitos alunos implementaram suas próprias variações de personagens que
caminhavam pelo labirinto.
3.3.3 W’us Castle
Eagle e Barnes (2008) descrevem o jogo denominado W’us Castle, um rpg (role playing
game) cujo objetivo é ensinar arrays e laços de repetição de uma forma visual e interativa. Em um
primeiro nível do jogo o aluno explora arrays unidimensionais utilizando um laço de repetição do
tipo for. Em um segundo nível o jogador deve fazer o seu personagem caminhar usando loops
aninhados, e o jogador deve responder questões de múltipla escolha sobre o código do loop, tais
como: “Qual a variável controla o loop externo?”. Em um terceiro nível, o jogador utiliza loops do
tipo for aninhados para modificar arrays bidimensionais. O jogo provê a estrutura de um loop for
57
em C++ e permite que os alunos modifiquem a condição inicial, a condição de parada e o tamanho
do passo do loop. O jogador define o corpo do loop, que consiste em uma série de instruções que
“mostrarão” à personagem Machina quais as posições do array ela deverá visitar e qual tipo de
boneco de neve deverá ser colocado em cada posição do array (através do corpo do loop). A
travessia de Machina pelo array permite a visualização de como os parâmetros do loop controlam
os movimentos desta personagem e determinam quais as posições do array são visitadas (Figura 5).
Figura 5. Configurando o corpo de um loop aninhado do W’us Castle
Fonte: Eagle e Barnes (2008).
Para avançar no jogo o aluno deve completar todas as missões de cada um dos níveis.
Alguns desafios apresentados ao aluno são: editar todo o array, editar somente as posições pares,
somente as posições ímpares, editar uma subseção do array, etc.
Eagle e Barnes (2008) realizaram um experimento utilizando o W’us Castle com alunos de
programação introdutória onde verificaram uma diferença estatisticamente significativa entre as
notas finais dos alunos que jogaram e dos que não jogaram. Como possível causa para este
resultado positivo os autores citam o feedback em tempo real e a visualização interativa da
58
execução do código. Os autores relatam outros resultados positivos em outro experimento com o
mesmo jogo (EAGLE e BARNES, 2009).
3.3.4 Metodologia de ensino baseada em jogos
Clua (2008) apresenta uma metodologia para o ensino de programação sob a metáfora dos
jogos de computador. A metodologia é baseada nos tópicos que a Sociedade Brasileira de
Computação (SBC) considera como sendo essenciais para o ensino de programação introdutória.
Segundo Clua (2008), não é recomendado que sejam trabalhados tópicos avançados como
Inteligência Artificial complexa ou física, e a simplicidade é a melhor estratégia. Como bons
exemplos de jogos que podem ser implementados pelos iniciantes o autor recomenda os clássicos
Space Invaders, Pac Man, Pong e Asteroids.
A respeito dos loops Clua (2008) recomenda a animação da movimentação de um sprite
como de forma de demonstrar visualmente ao aluno o resultado de um loop. O autor sugere que o
conceito de laço de repetição seja apresentado através da idéia de que um jogo que é, na verdade,
um loop que lê os dados de entrada, modifica as variáveis de acordo com as entradas, apresenta os
resultados na tela e verifica se o jogo acabou. Se não acabou, o loop retorna ao seu início.
Clua (2008) propõe que se ensine as expressões condicionais após os trabalhos com os
loops. O autor sugere um exercício onde o aluno deve implementar um sprite que bate em uma das
bordas da tela do jogo e muda de direção em conseqüência da colisão. Outros tópicos abordados na
metodologia proposta pelo autor são as estruturas de dados (grafos, especificamente) e conceitos
iniciais de Engenharia de Software.
3.3.5 Robocode
O Robocode13 é um jogo que foi desenvolvido pela IBM em 2001 e propicia a aprendizagem
da linguagem Java. O ambiente do jogo consiste em uma arena de batalha retangular populada por
tanques de guerra. Estes tanques de guerra procuram e destroem outros tanques presentes na arena
13 http://robocode.sourceforge.net/
59
(ver Figura 6). Os tanques podem ser programados pelos alunos, que podem utilizar ações pré-
definidas para andar para frente e para trás, virar o canhão em uma determinada quantidade de
graus, atirar, etc.
Figura 6. Uma batalha em andamento no Robocode
Possivelmente o grande trunfo do Robocode é a competição, naturalmente estimulada pelas
batalhas entre os tanques. Com forte ênfase na competição é possível que os alunos sintam-se
impelidos a melhorarem seus algoritmos de defesa e ataque para maximizar as possibilidades de
sucesso nas batalhas.
Long (2007) realizou um experimento enviando 500 questionários (83 deles foram
respondidos) para membros da comunidade Robocode. Aproximadamente 80% dos participantes
indicaram um aumento das suas habilidades de programação após jogar o Robocode. O estudo
indicou que a motivação principal dos participantes é a diversão oferecida pelo jogo, e que não
apenas os mais jovens divertem-se, mas também aqueles com mais idade e experiência em
programação. O autor também diz que dentre uma lista de fatores que tornariam o Robocode
60
divertido os participantes indicaram mais freqüentemente “a possibilidade de resolver problemas
por si próprios”. O estudo ainda demonstrou que a atividade considerada preferida, e mais divertida,
pelos participantes foi a descoberta de algoritmos/estratégias de batalha. As tarefas de escrever o
código, teste e depuração foram indicadas como menos interessantes.
Bierre e Phelps (2004) relatam, assim como Long (2007), as muitas características positivas
da utilização do Robocode como ferramenta pedagógica. Entretanto, Bierre e Phelps (2004)
verificaram que muitos alunos construíam seus robôs copiando trechos de códigos encontrados na
internet ao invés de programá-los por si mesmos. Quando estes autores perceberam que não era
mais possível distinguir o código criado pelos alunos daqueles copiados na internet acabaram por
abandonar o Robocode como recurso pedagógico.
3.3.6 JV2M
JV2M é um sistema tutor/jogo que tem como objetivo principal ensinar como funciona a
compilação de um programa escrito em Java bem como a sua execução na JVM (Java Virtual
Machine – Máquina Virtual Java). Além disso, o software auxilia o entendimento dos mecanismos
relacionados a programação orientada a objetos (GÓMEZ-MARTIN, GÓMEZ-MARTIN e
GONZÁLEZ-CALERO; 2004).
Um agente pedagógico chamado Javy habita este ambiente virtual e fornece dicas ao aluno,
assumindo o papel do tutor. Para avançar no jogo o aluno precisa compilar e executar no ambiente
virtual códigos escritos em Java.
Um dos aspectos que mais chamam a atenção no JV2M é o enredo criado para o jogo. O
avatar do usuário (personagem principal do jogo) é raptado para um mundo virtual (Yogyakarta) do
qual ele pretende fugir. Entretanto, isto só é possível com o entendimento das regras do estranho
lugar. Yogyakarta é a JVM metafórica e entendê-la significa executar sobre ela programas escritos
em Java. Neste mundo virtual o personagem principal não está sozinho, pois o mundo é populado
por camponeses oprimidos que não tem tempo nem conhecimento suficiente para organizar uma
guerra pela libertação. Cabe então ao aluno, o herói do jogo, aprender como este mundo virtual
funciona resolvendo exercícios cada vez mais difíceis para libertar cada vez mais camponeses
oprimidos e, eventualmente, abrir a porta secreta de comunicação com o mundo livre. Uma visão
geral deste software é apresentada na Figura 7.
61
Figura 7. Agente Javy fornecendo uma explicação para o aluno
3.4 SOFTWARES DE APOIO AO ENSINO DE PROGRAMAÇÃO
Nesta seção são apresentados alguns softwares que influenciaram fortemente a adoção nesta
pesquisa de uma linguagem de programação não-textual, baseada no encaixe de objetos. A seguir
são apresentados os detalhes destes trabalhos e, em alguns casos, os resultados da sua utilização na
aprendizagem dos conceitos de programação introdutória.
3.4.1 Alice
Alice14 é um software para construção de ambientes virtuais populados por objetos
tridimensionais. Estes objetos podem ser movidos, girados, sua cor pode ser alterada, podem reagir
a eventos de mouse ou teclado, entre outros (ver Figura 8).
14 http://www.alice.org/
62
Figura 8. Visão geral do software Alice
No ambiente Alice os alunos constroem seus programas clicando e arrastando componentes
visuais que representam estruturas de programação como laços de repetição, desvios condicionais,
variáveis, etc.
Howard (2004) descreve os resultados de um experimento qualitativo com 89 alunos de um
curso introdutório de programação onde o Alice foi utilizado durante duas semanas e meia. Os
resultados foram positivos principalmente no que se refere à motivação dos alunos, porém nenhuma
avaliação quantitativa foi realizada sobre a aprendizagem dos conceitos básicos de programação.
Brown (2008) levanta alguns pontos negativos e positivos do Alice, fruto da utilização do
software em sala de aula. Os aspectos positivos ressaltados são o grande potencial motivacional do
software, aumento na auto-confiança dos alunos e vantagens no ensino de conceitos abstratos.
63
Brown ainda destaca que a construção de programas encaixando blocos de programação elimina os
problemas de sintaxe largamente enfrentados pelos alunos iniciantes, pois no Alice os blocos se
encaixam de acordo com as restrições sintáticas. Como aspectos negativos do software Brown
ressalta a necessidade de um hardware relativamente poderoso (e nem sempre disponível em
laboratórios de instituições de ensino); um modelo pobre do conceito de herança (mudanças nas
classes base não são propagadas para as subclasses); a inaplicabilidade do Alice em domínios que
não sejam a animação de estórias; e a dificuldade dos alunos na transição do estilo de programação
do Alice (baseado no encaixe de componentes visuais) para uma linguagem de programação
baseada em texto (como Java ou C++).
Segundo Powers, Ecott e Hirshfield (2007) mais de 100 instituições acadêmicas (até 2007)
já haviam adotado o Alice e 3 livros sobre o software haviam sido publicados até 2006. Os autores
destacam o aumento da auto-confiança e retenção dos alunos em decorrência da utilização do Alice.
Como aspectos negativos os autores também mencionam o modelo de herança problemático
adotado no software e a dificuldade dos alunos em fazer a transição do Alice para uma linguagem
de programação baseada em texto.
3.4.2 Greenfoot
Greenfoot15 é um framework e um ambiente educacional voltado para o ensino de
programação introdutória composto por objetos interativos. O ambiente fornecido pelo Greenfoot
permite a criação de aplicações baseadas em simulação em um plano bidimensional. O software
permite que os alunos executem interativamente os métodos disponíveis nos objetos criados na
simulação. Cada objeto tem uma representação gráfica e uma posição dentro de um mundo virtual
de duas dimensões. Dessa forma, as interações com o objeto podem ser observadas nas mudanças
da sua posição e aparência. O Greenfoot ainda inclui edição de código, compilação, criação de
novas classes, inspeção de objetos e debugger.
Vahldick (2008) relata uma experiência de utilização do Greenfoot com 56 alunos de uma
disciplina de programação orientada a objetos. Segundo o autor não houveram melhorias
15 http://www.greenfoot.org/
64
estatisticamente significativas nas notas dos alunos em comparação com as turmas anteriores que
não utilizavam o Greenfoot. O autor relata que, apesar dos números não serem animadores, os
alunos apresentaram códigos de maior qualidade do que em semestres anteriores. Como possíveis
causas dessa melhoria qualitativa o autor cita o feedback imediato que os alunos recebem sobre o
estado do seu código no Greenfoot e o desafio de implementar uma simulação com mais recursos.
3.4.3 JavaTool
Mota, Pereira e Favero (2008) descrevem o JavaTool, uma ferramenta cujo objetivo é
facilitar a aprendizagem de programação utilizando um subconjunto dos recursos da linguagem
Java. Apesar de se utilizar de um subconjunto da linguagem Java – uma linguagem orientada a
objetos - o JavaTool não aborda conceitos de programação orientada a objetos, numa tentativa,
segundo os autores, de facilitar o aprendizado dos alunos iniciantes.
A linguagem utilizada no JavaTool é bastante simplificada, eliminando grande parte das
complexidades sintáticas. Segundo os autores esta simplicidade tem um caráter pedagógico e é
focada no ensino de programação introdutória. Assim, o JavaTool permite que o alune execute uma
seqüência de linhas de código sem especificação de classes ou métodos, sem as declarações para
importação de classes, etc. A idéia da sintaxe simplificada é focalizar os fundamentos de
programação sem onerar o estudante com conceitos de programação mais avançados, que seriam
apresentados mais adiante no curso.
3.4.4 Scratch
Scratch16 é um ambiente de programação desenvolvido com o objetivo de facilitar a criação
de estórias interativas, animações, jogos, música, arte digital, e possibilitar o compartilhamento
destas criações através da web. Apesar de ter sido projetado para jovens com idade a partir de 8
anos existem alguns casos (descritos mais adiante) onde o Scratch foi utilizado com sucesso no
ensino superior.
16 http://scratch.mit.edu/
65
O Scratch é baseado em uma metáfora de construção com blocos, em que os alunos
constroem pequenos trechos de programas encaixando blocos gráficos que representam as
estruturas de programação como variáveis, desvios condicionais, laços de repetição, etc. Comandos
e tipos de dados são representados por blocos de diferentes formatos e cores. Os blocos encaixam-se
apenas da maneira sintaticamente correta. Não existe, por exemplo, a possibilidade de um aluno
encaixar um laço de repetição na área da condição de um desvio condicional. Esta abordagem
minimiza drasticamente os erros sintáticos e permite que o aluno iniciante mantenha-se focado na
solução do problema. Na Figura 9 é apresentado um pequeno programa construído no Scratch.
Figura 9. Aspecto de um programa no Scratch
Cristóvão (2008) descreve os resultados do uso do Scratch com duas turmas de programação
introdutória (em média 60 alunos) em dois semestres letivos. Segundo o autor, vários alunos que
reprovaram na disciplina quando outro método era utilizado (portugol e fluxogramas ao invés do
Scratch) relataram uma melhor adaptação e apropriação do conhecimento, e sentiram-se mais
confiantes em construir programas. O autor ainda relata uma série de efeitos positivos que foram
observados no decorrer da utilização do Scratch, tais como aumento na motivação dos alunos, maior
apropriação das estruturas algorítmicas, menor impacto na transição para Java, rapidez no
66
aprendizado de estruturas mais complexas, os alunos passaram mais tempo programando, entre
outras.
Malan e Leitner (2007) descrevem os resultados de um experimento onde a maioria dos
alunos (75% de um total de 25 estudantes) classificou como positiva a experiência inicial com o
Scratch. Os autores ainda descrevem uma série de frases proferidas pelos alunos mostrando que o
Scratch foi considerado divertido, permitiu que os alunos pensassem como programadores de forma
intuitiva, entre outros. Um dos alunos que classificou o Scratch como uma influência negativa no
aprendizado da linguagem Java (linguagem utilizada depois do Scratch) argumentou que o software
é divertido e fácil, porém, a codificação em Java era muito mais difícil e os resultados bem menos
interessantes.
3.5 ANÁLISE COMPARATIVA
Nesta pesquisa foram analisadas três classes de trabalhos similares, todos os trabalhos
relacionados à programação introdutória, a saber: 1) as pesquisas que tratam da influência dos jogos
na aprendizagem; 2) os trabalhos que relatam a utilização de jogos no ensino; e 3) os softwares
utilizados como ferramenta de apoio à aprendizagem.
Esta pesquisa difere da primeira classe de trabalhos similares pela forma como a
aprendizagem será mensurada. Em geral, as pesquisas analisadas utilizam apenas as pontuações dos
testes como indicadores da aprendizagem dos alunos. Nesta pesquisa, além das pontuações, foi
considerado o progresso dos alunos nos níveis da taxonomia de Bloom. Além disso, nem todas as
pesquisas similares analisadas utilizam um delineamento experimental com um grupo de controle, o
que foi feito neste trabalho. Por fim, a maioria das pesquisas analisadas trata também da motivação
dos alunos e não apenas da aprendizagem. Como os trabalhos analisados apontam quase que
unanimemente um aumento na motivação, decidiu-se por dar a questão como suficientemente
pesquisada e focar apenas na aprendizagem.
O Quadro 4, apresentado anteriormente, sumariza algumas das características da primeira
classe de trabalhos similares analisados, e por este motivo o quadro não é apresentado novamente
nesta seção. A segunda classe de trabalhos similares é formada por trabalhos que incentivam e
mencionam a utilização de jogos no ensino de programação introdutória. Estes trabalhos relatam
experiências de professores que utilizaram a implementação de jogos como tarefas de programação.
67
Neste caso, os alunos jogam apenas quando terminam de programar seu próprio jogo. O jogo que
foi utilizado nesta pesquisa difere desta abordagem na medida em que o aluno programa parte do
jogo (mais especificamente um robô) enquanto joga, e o avanço no jogo é determinado pela
corretude do programa construído. O Quadro 5 sumariza as características desta pesquisa e dos
trabalhos similares analisados.
A terceira e última classe de trabalhos similares a esta pesquisa é constituída pelos softwares
que são utilizados como ferramentas de apoio à aprendizagem de programação introdutória. Os
softwares analisados influenciaram fortemente as idéias utilizadas neste trabalho. A adoção de uma
linguagem de programação baseada no encaixe de componentes visuais, por exemplo, foi baseada
nos softwares Scratch e Alice. O Quadro 6 sumariza as principais características dos softwares
utilizados no apoio a aprendizagem de programação que foram analisados nesta pesquisa.
68
Publicação Contextualização dos Problemas
Desafios Tipo de linguagem de programação
Barnes et al (2007) Game2Learn: building CS1 learning games for retention.
Boa contextualização, o aluno pode identificar facilmente qual a utilidade da solução do problema dentro dos jogos. Entretanto, cada nível do jogo se parece com um mini-jogo isolado, e os níveis parecem pouco relacionados entre si.
Derrotar um inseto respondendo questões sobre ciência da computação. Ajudar um fazendeiro a colocar ovos em uma grade ajustando dois loops aninhados. Ajustar um loop do tipo do-while selecionando e ordenando linhas de código disponibilizadas no próprio ambiente do jogo. Utilizar desvios condicionais para destrancar uma porta, utilizar loops aninhados para construir uma ponte, e utilizar loops aninhados para resolver um criptograma.
O aluno não chega a programar, apenas utiliza a interface do jogo para responder questões de múltipla escolha, ordenar instruções de programação, preencher trechos de código, entre outros.
Nevison e Wells (2004) Using a maze case study to teach: object-oriented programming and design patterns.
Boa contextualização. A utilidade da resolução de cada problema é bastante clara, pois todos os exercícios são programados com a intenção de fazer um personagem movimentar-se em um labirinto.
Implementação de um personagem que caminha em um labirinto. Evitar “muros” do labirinto utilizando desvios condicionais. Programação de um personagem que caminhe várias células (ao invés de apenas uma) em uma direção até que encontre um muro utilizando um loop.
Os alunos programam em uma linguagem baseada em texto (como JAVA ou C++). Recebem classes prontas do professor e apenas alteram métodos específicos para cada atividade realizada. Os detalhes das classes que implementam o labirinto não são apresentados aos alunos.
Eagle e Barnes (2008, 2009) Wu's castle: teaching arrays and loops in a game. Experimental Evaluation of an Educational Game for Improved Learning in Introductory Computing.
O jogo aborda apenas loops e arrays. Alguns desafios apresentados aos alunos são: editar todo o array, editar somente as posições pares, somente as posições ímpares, editar uma subseção do array, etc. Não fica claro se estes desafios têm algum propósito relacionado com o jogo, aparentemente são apenas tarefas que devem ser concluídas para avançar no jogo.
Fazer um personagem caminhar usando loops aninhados. Responder questões de múltipla escolha sobre o código de um loop, tais como: “Qual a variável controla o loop externo?”.
Nenhuma linguagem de programação é utilizada. O jogo provê, por exemplo, a estrutura de um loop for em C++ e permite que os alunos modifiquem a condição inicial, a condição de parada e o tamanho do passo do loop via interface do jogo. Nenhum código é realmente digitado pelos alunos.
Clua (2008) A Game Oriented Approach for
Há um bom nível de contextualização, pois o autor sugere situações concretas onde os
O autor sugere a animação da movimentação de um sprite como forma de entender visualmente o resultado de um loop.
Nenhuma linguagem foi utilizada ou sugerida, pois o trabalho propõe uma metodologia de ensino baseada em jogos, e
69
Teaching Computer Science.
conceitos de programação podem ser aplicados no contexto dos jogos.
Outra sugestão é um exercício onde o aluno deve implementar um sprite que bate em uma das bordas da tela do jogo e muda de direção em conseqüência da colisão. Este último exemplo trabalharia os desvios condicionais.
não um jogo propriamente dito. Por esse motivo as idéias discutidas pelo autor poderiam ser aplicadas em qualquer linguagem.
Long (2007) Just For Fun: using programming games in software programming training and education.
Boa contextualização. A utilidade da solução dos problemas de programação fica evidente no comportamento dos tanques de guerra programados. Quanto melhor for a programação melhor será o poder de batalha do tanque programado. Toda programação é feita com um objetivo muito específico: programar um bom algoritmo de batalha.
Programar tanques de guerra para procurar e destruir outros tanques presentes em uma arena. Os alunos podem utilizar ações pré-definidas para controlar o tanque.
Os alunos utilizam uma linguagem baseada em texto (JAVA) apenas para invocar funções básicas de controle dos robôs. A visualização dos próprios robôs e mesmo da arena de batalha é uma “caixa preta” para os alunos.
Gómez-Martin, Gómez-Martin e González-Calero (2004). Game-driven intelligent tutoring systems.
Os autores não mencionam se existe relação entre a solução dos problemas (construção de programas) e o enredo do jogo. Aparentemente os programas construídos pelos jogadores não tem utilidade no contexto do jogo, são apenas desafios que precisam ser vencidos.
Os autores não especificam os desafios em maiores detalhes, mencionam apenas que os jogadores constroem programas dentro de um ambiente lúdico que simula uma máquina virtual JAVA.
Os alunos devem escrever programas na sintaxe da linguagem Java. Além disso, devem compilar o programa dentro do ambiente do jogo, pois um dos objetivos deste último é facilitar o entendimento do processo de compilação.
O jogo que foi utilizado nesta pesquisa
Boa contextualização dos problemas. O resultado de cada solução de problema é utilizado para algo dentro do enredo do jogo, de maneira que o aluno saiba para quê está construindo cada programa.
Utilizar desvios condicionais para verificar estados de interruptores e fazer com que um robô execute ações de acordo com os estados. Utilizar loops e testes condicionais para encontrar um interruptor que gere a maior quantidade de energia para suprir uma base espacial onde o personagem do jogo (um robô) se encontra.
Os alunos utilizam uma linguagem de programação onde as partes de um programa podem ser arrastadas e encaixadas umas nas outras. Nenhum código é digitado. Os programas construídos são corrigidos automaticamente e os problemas encontrados são apresentados aos alunos.
Quadro 5. Síntese dos trabalhos que utilizam jogos para auxiliar a aprendizagem de programação
70
Software Idéia geral Prós Contras Alice Permite a construção de ambientes
virtuais em três dimensões. A programação é feita através do encaixe de componentes disponibilizados no software. Modelos tridimensionais podem ser colocados no mundo virtual e manipulados com instruções de programação.
A idéia de programar encaixando blocos elimina as dificuldades com sintaxe presente em linguagens de programação baseadas em texto. A criação de ambientes virtuais com três dimensões fica bastante facilitada com as funcionalidades oferecidas pelo software. Howard (2004) e Brown (2008) utilizaram o Alice com alunos e mencionam um aumento da motivação. Powers, Ecott e Hirshfield (2007) mencionam um aumento na retenção.
Autores mencionam que o software requer recursos computacionais acima da média, o software é considerado “pesado”. Autores também relatam que o modelo de herança utilizado é problemático, e que os alunos apresentam dificuldade na transição do Alice para uma linguagem de programação textual como Java.
Greenfoot Permite a criação de aplicações baseadas em simulação em um ambiente bidimensional. Permite a execução interativa dos métodos dos objetos criados na simulação. Cada objeto tem uma representação gráfica e uma posição dentro de um mundo virtual. As interações com os objetos podem ser observadas nas mudanças das suas posições e aparência.
Inclui edição de código, compilação, criação de novas classes, inspeção de objetos e debugger. Vahldick (2008) relata suas impressões sobre a utilização do software dizendo que os alunos apresentaram códigos de maior qualidade do que em semestres anteriores, quando o Greenfoot não foi utilizado.
Vahldick (2008) relata uma experiência de utilização do Greenfoot onde relata que não houveram melhorias estatisticamente significativas nas notas dos alunos em comparação com turmas anteriores que não utilizaram o software.
JavaTool Facilita a aprendizagem de programação utilizando um subconjunto dos recursos da linguagem Java. Não aborda conceitos de programação orientada a objetos com o objetivo de facilitar o aprendizado para os alunos iniciantes.
A linguagem utilizada no JavaTool é bastante simplificada, eliminando grande parte das complexidades sintáticas. Segundo os autores do software esta simplicidade tem um caráter pedagógico e é focada no ensino de programação introdutória.
Mesmo com a simplificação sintática mencionada pelos autores os alunos ainda precisam aprender alguma sintaxe da linguagem Java. Os autores não apresentam resultados sobre o impacto da utilização da ferramenta com alunos.
Scratch Facilita a criação de estórias interativas, animações, jogos, música e arte digital. Os alunos constroem pequenos trechos de programas encaixando blocos gráficos que representam as estruturas de programação. O Scratch permite que o aluno programe comportamentos para personagens que movem-se pela tela.
Os blocos encaixam-se apenas da maneira sintaticamente correta. Não existe, por exemplo, a possibilidade de um aluno encaixar um laço de repetição na área da condição de um desvio condicional. Esta abordagem elimina por completo os erros sintáticos e permite que o aluno iniciante mantenha-se focado na solução do problema.
A ausência dos tipos nas variáveis pode prejudicar a transição para linguagens fortemente tipadas como Java e C++. O aluno programa sem preocupar-se com detalhes de nível mais baixo. A transição para uma linguagem de programação “real” (uma que realmente seja utilizada para construir aplicações) pode ser frustante, já que muitas das
71
As variáveis não são “tipadas”, um detalhe que pode facilitar ainda mais a construção de programas por alunos iniciantes. Cristóvão (2008) e também Malan e Leitner (2007) descrevem uma série de impressões positivas sobre a utilização do software com alunos de programação introdutória.
facilidades oferecidas pelo software não estarão presentes.
Escracho (linguagem utilizada nesta pesquisa)
Permite a construção de pequenos programas utilizando a idéia de arrastar e encaixar partes componentes. Corrigir automaticamente os programas construídos pelos alunos, desde que os programas façam parte de um conjunto de exercícios com respostas pré-definidas.
A idéia de programar arrastando e encaixando componentes elimina os erros sintáticos mais corriqueiros e facilita a programação para alunos iniciantes. O mecanismo de correção automática permite que os alunos testem se suas soluções geram os resultados esperados e se as estruturas de programação adequadas foram utilizadas.
Alguns alunos utilizaram o mecanismo de correção automática para obter dicas daquilo que precisaria ser programado antes mesmo de pensar sobre as estruturas de programação mais adequadas para o problema. As facilidades da linguagem de programação não-textual podem deixar os alunos frustrados na transição para linguagens baseadas em texto como C++ ou Java, onde tais facilidades não existem.
Quadro 6. Características dos softwares de apoio a aprendizagem de programação
72
3.6 CONSIDERAÇÕES
Neste capítulo foram apresentados alguns trabalhos considerados similares a esta pesquisa.
Estes trabalhos foram divididos em três classes: 1) trabalhos onde foram publicadas avaliações
sobre o efeito de jogos na aprendizagem de programação introdutória; 2) trabalhos onde os jogos
foram utilizados como ferramenta didática no ensino de programação; e 3) trabalhos que discutem
softwares de apoio à aprendizagem de programação.
Com a primeira classe de trabalhos pôde-se analisar principalmente a metodologia utilizada
para a mensuração do efeito dos jogos na aprendizagem. Foi possível observar que poucas
pesquisas utilizam um delineamento experimental com grupo de controle. São comuns as
publicações onde aplica-se um jogo (a intervenção ou tratamento) e mede-se a aprendizagem
através de um teste. O problema com esta abordagem é que não se pode comparar o desempenho da
turma de alunos com um desempenho que possa ser considerado referência. Nesta pesquisa toda
comparação de desempenho dos alunos foi feita com um desempenho de referência, o desempenho
do grupo de controle. Outra característica dos trabalhos similares desta primeira classe é a utilização
de uma pontuação (uma nota) como medida da aprendizagem dos alunos. Este é um ponto que
certamente tem potencial para controvérsias, pois dificilmente uma pontuação seria suficiente para
mensurar algo tão complexo quanto a aprendizagem. Neste trabalho foram utilizadas pontuações
para quantificar a aprendizagem dos alunos e também foi verificado o progresso dos alunos nos
níveis da taxonomia de Bloom.
A segunda classe de trabalhos analisados engloba aqueles que mencionam a utilização de
jogos como ferramentas de apoio à aprendizagem de programação. Estes trabalhos contribuíram
com esta pesquisa mostrando o tipo de desafios de programação que poderiam ser inseridos em
jogos. Muitos trabalhos apresentam exemplos para tópicos específicos de programação, como
desafios que envolvem desvios condicionais ou loops, o que foi de grande valia como ponto de
partida para a elaboração das idéias do jogo que foi utilizado neste trabalho. Os trabalhos similares
também contribuíram para esta pesquisa no que se refere à utilização de enredos e uma boa
amarração entre desafios do jogo e enredo, características nem sempre observadas em jogos
educacionais.
73
A terceira e última classe de trabalhos similares enquadra os softwares criados com o
objetivo de auxiliar a aprendizagem de programação. Existem muitos softwares criados com esta
finalidade, e por este motivo apenas aqueles que apresentaram alguma contribuição clara para esta
pesquisa foram analisados. Com esta classe de trabalhos foi possível verificar o tipo de linguagem
de programação que vem sendo utilizado com alunos iniciantes. Em geral, estes softwares
costumam apresentar ou versões simplificadas de linguagens conhecidas (como JAVA ou C++) ou
então linguagens totalmente novas, mas sempre com um número reduzido de recursos visando
diminuir a sobrecarga na aprendizagem. Alguns trabalhos recentes, e de expressão mundial
significativa como Alice e Scratch, utilizam linguagens onde os programas são construídos por
meio do encaixe de componentes que representam estruturas de programação. Neste trabalho optou-
se por seguir esta mesma abordagem construindo um interpretador de comandos para uma pequena
linguagem de programação visual, cujos detalhes são apresentados no capítulo seguinte.
74
4 DESENVOLVIMENTO
Nesta seção são apresentados os detalhes dos softwares que foram utilizados pelos alunos
nos três experimentos realizados nesta pesquisa. Inicialmente são apresentados os detalhes da
linguagem de programação não-textual e do mecanismo de correção automática de programas, já
que ambos estiveram embutidos em todos os softwares. Em seguida são descritas as características
de cada um dos três softwares: um primeiro onde são utilizados enunciados sem contextualização,
um segundo onde os enunciados possuem um nível intermediário de contextualização, e um terceiro
software que é um jogo, onde os enunciados têm o maior nível de contextualização. Por fim,
discute-se também o instrumento de avaliação que foi utilizado no pré e pós-teste de cada um dos
experimentos realizados.
4.1 A LINGUAGEM DE PROGRAMAÇÃO ESCRACHO
Em todos os experimentos que foram realizados nesta pesquisa os alunos resolveram
problemas algorítmicos utilizando uma linguagem de programação não-textual. Esta linguagem de
programação foi bastante inspirada nos softwares Alice e Scratch, cuja idéia central é permitir a
construção de programas através do encaixe de componentes visuais que representam comandos de
programação. Nesta abordagem não se digita código (ou se digita muito pouco) para construir
programas, ao contrário das linguagens de programação textuais (como Java ou C++). Esta
abordagem de programação também é chamada de point and click, e já era utilizada em softwares
como o GameMaker17 mesmo antes da existência do Alice ou do Scratch.
A motivação para a utilização da metáfora de blocos que se encaixam para formar
programas baseia-se no fato de que estes blocos possuem formatos diferentes, de maneira que o
aluno não consegue, mesmo que queira, cometer erros sintáticos mais simples como encaixar um
desvio condicional dentro de uma atribuição. Os aspectos sintáticos ficam bastante facilitados com
este tipo de abordagem, e então os alunos podem voltar sua atenção para a lógica da solução dos
problemas.
17 http://www.yoyogames.com/make
75
Na Figura 10 pode-se ter uma visão de um pequeno programa construído na linguagem de
programação que foi construída para esta pesquisa, apelidada de Escracho em homenagem ao
software Scratch. Ao lado esquerdo da figura estão alguns dos comandos de programação que o
aluno pode clicar e arrastar para o lado direito, onde está o programa construído através do encaixe
das partes componentes.
Figura 10. Componentes da linguagem Escracho sendo usados para construir um programa
4.1.1 Representação Lógica dos Programas Construídos em Escracho
Para representar logicamente e executar os programas construídos através do encaixe dos
componentes visuais foi utilizada uma estrutura chamada árvore sintática abstrata. Esta árvore é
criada na memória de maneira que várias ações podem ser aplicadas aos seus nós, como por
exemplo, executar o comando representado por cada um dos nós da árvore ou gerar uma
representação textual da mesma transformando cada nó em um bloco de texto diferente, de acordo
com o tipo do nó. Utilizou-se o padrão de projeto Visitor (GAMA et al, 2000) para desacoplar a
76
estrutura da árvore dos algoritmos que podem ser aplicados a ela. Alguns dos algoritmos aplicados
são mencionados mais adiante.
Ao lado esquerdo da Figura 11 pode-se ver um pequeno programa construído na linguagem
Escracho, enquanto que no lado direito pode-se ver a representação deste mesmo programa através
de uma árvore onde cada nó é um comando de programação.
Figura 11. Representação em árvore de um programa construído no Escracho
Na Figura 12 é apresentado o diagrama de classes utilizado para modelar os comandos de
programação disponíveis na linguagem Escracho. Neste diagrama pode-se ver a classe Comando, a
classe base para todos os comandos de programação disponibilizados. A classe ComandoComposite
77
representa comandos que podem conter dentro de si outros comandos. As classes Loop, Se e
SeSenao são exemplos deste caso, pois podem conter vários comandos dentro de si, inclusive outros
loops e desvios condicionais do tipo Se ou SeSenao. Esta é uma instância do padrão de projeto
Composite (GAMMA et al, 2000). Para tornar o diagrama mais legível apenas os relacionamentos
entre as classes são apresentados no diagrama, os métodos e atributos das classes foram omitidos.
Figura 12. Classes utilizadas para representar os comandos da linguagem Escracho
Na Figura 13 é apresentada a hierarquia de classes que modela as expressões utilizadas na
linguagem Escracho. Para reduzir o espaço necessário para a apresentação de toda a hierarquia as
classes que derivam de uma mesma classe base foram colocadas em retângulos, e para evitar a
sobreposição de muitos conectores de herança apenas a classe mais acima do retângulo foi
conectada com a classe base. Estas estratégias não fazem parte da notação padrão da UML (Unified
Modeling Language – Linguagem de Modelagem Unificada) e foram utilizadas apenas como
recurso para tornar o diagrama de classes mais legível.
78
Alguns comandos disponíveis precisam avaliar expressões durante a sua execução. Por
exemplo, um objeto da classe Enquanto espera uma condição que deve ser qualquer objeto que
descenda da classe ExpressaoLogica, apresentada na Figura 13. Entre os descendentes da classe
ExpressaoLogica estão as classes que representam as operações com operadores lógicos (e, ou e
negação) e todas as expressões relacionais. Dessa forma, um objeto do tipo Enquanto não precisa
saber que tipo de expressão ele contém, ele precisa saber apenas que a expressão lhe retornará um
valor lógico que será utilizado para dar ou não continuidade nas suas iterações. A mesma idéia se
aplica aos desvios condicionais e outros comandos que avaliam uma condição durante a execução.
Figura 13. Classes dos tipos de expressões disponíveis na linguagem Escracho
No modelo apresentado na Figura 13 pode-se ver a utilização de uma interface para
representar todas as expressões que possuem dois operandos, a interface
IExpressaoComDoisOperandos. Esta interface é útil em situações onde um comando precisa saber
apenas que uma expressão deve possuir dois operandos que são expressões, sendo que os detalhes
específicos do tipo de expressão utilizada como operando não importam. Esta estratégia ajuda na
minimização do acoplamento entre as classes, pois as classes que conhecem esta interface não
79
conhecem maiores detalhes sobre as classes concretas que a implementam. Com o objetivo de
facilitar o entendimento do diagrama apresentado na Figura 13 algumas classes foram omitidas. Por
exemplo, as RaizQuadrada, Seno, Arcoseno Tangente, etc. derivam da classe ExpressaoAritmetica
mostrada no diagrama. De forma semelhante, um conjunto de classes que representam expressões
aritméticas derivam da classe ExpressaoAritmeticaBinaria e outro conjunto de classes que
representam expressões relacionais especializam a classe ExpressaoRelacional.
4.1.2 Correção Automática dos Programas
A correção automática de programas contribuiu para esta pesquisa por pelo menos dois
motivos: primeiro, a corretude18 dos programas construídos foi usada para determinar o avanço dos
alunos dentro do jogo; e segundo, o mecanismo de correção automática facilitou a realização dos
experimentos na medida em que eliminou a necessidade de correção manual, o que teria
inviabilizado as experimentações da maneira como elas aconteceram.
Decidiu-se por compor o sistema de correção com a verificação de três aspectos de um
programa: a verificação da sintaxe, a verificação das saídas e a comparação da estrutura do
programa do aluno com um conjunto de estruturas consideradas como solução para o problema. Por
fim, uma quarta característica foi adicionada ao mecanismo: a verificação de estruturas de
programação obrigatórias.
A verificação da sintaxe do programa consiste em analisar se é possível executá-lo, ou seja,
se cada um dos comandos contidos na AST que representa o programa podem ser executados
corretamente. Por exemplo, um programa que contém um comando do tipo Enquanto não pode ser
executado caso este último não contenha uma condição. O mesmo acontece no caso de comandos
do tipo Se ou SeSenao (ver Figura 12). Se nenhum erro sintático é encontrado no programa
construído pelo aluno então as outras duas etapas da verificação são realizadas.
A segunda etapa da correção consiste na análise da estrutura do programa do aluno. Esta
análise é feita através de uma comparação entre a estrutura do programa que está sendo verificado e
18 Termo comumente utilizado em Ciência da Computação para descrever a qualidade de um algoritmo que gera os resultados esperados.
80
algumas das estruturas que são soluções pré-definidas para o problema algorítmico. As estruturas
dos programas dos alunos, inicialmente representadas por uma AST, são convertidas em uma
representação textual (são serializadas) e então comparadas usando a distância de Levenshtein (ver
Seção 2.4.2.1). Assim, o processo de comparação das estruturas se resume a uma comparação de
duas strings, e quanto mais similares as strings tanto mais similares serão os programas que elas
representam.
Na última etapa da correção automática o programa do aluno é executado e as suas saídas
são comparadas com um conjunto de “saídas esperadas”. É necessário que todas as variáveis de
saída do programa tenham exatamente os mesmos valores do conjunto de saídas esperadas.
O algoritmo original da distância de Levenshtein retorna um número inteiro indicando o
custo necessário para a transformação de uma string em outra. O valor deste custo depende da
quantidade de caracteres das strings que estão sendo comparadas. Quanto maiores as strings sendo
analisadas pelo algoritmo maior poderá ser o número de operações elementares necessárias para a
transformação. Esta variação do custo de transformação em função do tamanho das strings não
interessava para este trabalho, e então este custo foi normalizado para um número real entre 0 e 1,
representando respectivamente os extremos nenhuma similaridade e similaridade total entre as
strings. O custo normalizado é obtido a partir da Equação (1), onde DL representa o valor calculado
com a distância de Levenshtein, EPA representa a quantidade de caracteres na Estrutura do
Programa do Aluno, e ES representa a quantidade de caracteres na Estrutura da Solução.
Custo normalizado = ( )ES,EPA
DL1
Max−
(1)
Na Figura 14 é apresentado o diagrama das classes que são utilizadas para resolver o
problema da correção automática de um programa criado pelo aluno. Nesta figura é possível
observar que cada uma das partes do processo de correção foi encapsulada em uma classe diferente,
a saber: VerificadorSintatico, VerificadorDeSaida e VerificadorDeEstrutura. Estas três classes
possuem algumas características em comum, e por esse motivo são subclasses de
VerificadorDeAlgoritmo. Todas estas classes têm a capacidade de avaliar um programa, cada classe
fazendo a avaliação sob um aspecto diferente. Além disso, em todas as avaliações podem ser
encontrados erros que devem ser armazenados para serem apresentados ao aluno. Um erro
81
detectado na análise estrutural ou na verificação da saída dos programas consiste em apenas uma
string contendo a descrição do erro. Já no caso da verificação sintática um erro contém, além da sua
descrição textual, uma referência para o elemento da AST onde o problema foi detectado. Desta
forma é possível indicar visualmente o componente do programa que contém o erro sintático.
Figura 14. Classes utilizadas na correção de um algoritmo
A classe CorretorDeAlgoritmo informa se um determinado algoritmo está ou não está
correto. As classes VerificadorDeEstrutura e VerificadorSintatico implementam a interface
IAlgoritmoVisitor. Neste caso utilizado o padrão de projeto Visitor (GAMA et al, 2000) para
permitir que operações algorítmicas diferentes fossem executadas na AST sem que esta última
precisasse sofrer alterações. Cada visitor consegue “passar” em toda a estrutura da AST e então
82
realizar o trabalho que lhe interessa. Outros visitors poderiam ser implementados para, por exemplo,
transformar os nós da AST em um código na linguagem Java ou C++, ou mesmo outra forma de
representação gráfica como um fluxograma.
No mecanismo de correção automática que foi implementado um programa é considerado
correto quando não são encontrados erros de sintaxe, a estrutura do programa do aluno é similar às
estruturas consideradas como solução para o problema, e as saídas do programa do aluno possuem
os mesmos valores das saídas esperadas. Como um problema tem um conjunto não vazio de
estruturas de programas que o solucionam, a estrutura do programa criado pelo aluno é comparada
com todos os elementos do conjunto. Cada uma destas comparações poderá resultar em um grau de
similaridade diferente, e o maior grau de similaridade é usado como indicador da semelhança entre
as duas estruturas de programas analisadas. O Quadro 7 ilustra como é realizada a correção
automática dos programas através de um pseudocódigo.
Se( não existem erros sintáticos) { Se( o programa têm similaridade suficiente com o gabarito){ Se( as saídas do programa são iguais as saídas esperadas){ Sinaliza que o programa está correto } } } Sinaliza que o programa está incorreto e exibe os problemas encontrados
Quadro 7. Algoritmo em pseudocódigo para a correção automática dos programas
A similaridade entre as estruturas dos programas é calculada através da comparação de
strings que representam árvores sintáticas abstratas (ASTs), que por sua vez representam na
memória os programas criados. O padrão que se utilizou para serializar as ASTs, ou seja,
transformá-las em strings, foi baseado no trabalho de Truong, Roe, e Bancroft (2004), onde os
autores utilizam as ASTs “normalizadas”. Esta normalização se dá pela utilização de nós genéricos
que representam classes de estruturas de programação. Por exemplo, no momento da serialização de
uma AST, todos os laços de repetição são representados pelo mesmo tipo de nó, ao invés de um tipo
específico para cada tipo de laço. Entretanto, a ordem em que os nós da AST são concatenados no
processo de serialização é baseada no trabalho de Baxter el al (1998), onde os nós das sub árvores
de uma AST são visitados na ordem: raiz, e filhos da esquerda para direita. Além disso, cada nó da
AST é serializado como um número, de acordo com o tipo do nó. Para cada tipo de nó atribuiu-se
um identificador numérico único.
83
Inicialmente pensou-se em utilizar palavras para representar cada nó da AST: SE,
SE_SENAO, ENQUANTO, etc. Entretanto, a comparação entre strings é feita comparando cada um
dos caracteres da palavra, e isto faria com que o algoritmo encontrasse similaridade onde na
verdade não haveria nenhuma. Tome-se como exemplo dois algoritmos bastante simples, o primeiro
contendo apenas um laço de repetição (ENQUANTO) em sua estrutura e o segundo contendo
apenas um desvio condicional (SE_SENAO). As estruturas serializadas utilizando palavras para
representar estruturas de programação são mostradas a seguir:
E N Q U A N T O S E _ S E N A O
Como se pode observar na tabela acima, a última e ante-penúltima letra das duas palavras
coincidem. Esta coincidência faria com que nenhuma alteração fosse necessária para a
transformação de uma letra em outra, de acordo com o algoritmo de Levenshtein. Ou seja, o
algoritmo interpretaria estes caracteres iguais como semelhança entre as strings, e
conseqüentemente isto seria interpretado pelo mecanismo de correção automática como semelhança
entre as estruturas das ASTs, quando na verdade não haveria nenhuma semelhança. No Quadro 8 é
apresentado um exemplo de programa construído na linguagem Escracho e a sua AST serializada
com identificadores numéricos únicos para cada tipo de comando. Todos os desvios condicionais
encontrados são identificados pelo número 1, e as atribuições são representadas pelo número 5.
Programa na linguagem Escracho AST serializada
155155
Quadro 8. Programa na linguagem Escracho e sua AST serializada
84
4.2 SOFTWARES UTILIZADOS NOS EXPERIMENTOS
Nesta pesquisa foram construídos 3 softwares, um para cada experimento realizado. Cada
experimento foi realizado com uma turma diferente de alunos e cada turma utilizou um software
diferente.
O primeiro software construído foi utilizado com o grupo de controle da pesquisa. Neste
software os enunciados dos problemas não estavam contextualizados, ou seja, os alunos resolveram
os problemas apenas por resolvê-los. Além disso, as descrições dos problemas eram bastante
abstratas e genéricas, sem nenhuma referência a situações mais concretas.
Em todos os três softwares os alunos resolveram o mesmo conjunto de 9 desafios
algorítmicos, sendo que em cada software o nível de contextualização dos enunciados foi diferente.
Nos dois primeiros softwares o acesso aos desafios foi seqüencial. A cada desafio completado o
aluno tinha acesso ao próximo, até que todos os desafios estivessem completados. Um desafio só
era considerado completado quando o aluno executava o programa e nenhum erro era encontrado
pelo mecanismo de correção automática dos programas. Já no terceiro software, o jogo, os alunos
puderam resolver os desafios na ordem em que desejaram e puderam visualizar o seu desempenho e
o dos colegas através de um rank, o que adicionou competição ao jogo.
4.2.1 Software Utilizado pelo Grupo de Controle
Na Figura 15 apresenta-se uma imagem do primeiro software, utilizado pelo grupo de
controle. Ao centro da figura pode-se visualizar o enunciado de um dos desafios. Ao lado esquerdo
da figura é possível visualizar as ferramentas de programação disponibilizadas para os alunos: os
comandos de programação (atribuição, desvios condicionais, loops, etc.) e uma tabela contendo os
nomes das variáveis do programa e os seus respectivos valores (teste de mesa). Como pode ser visto
no topo da figura os alunos puderam testar o algoritmo criado no ambiente e executá-lo passo a
passo. O botão nomeado como console mostra os erros encontrados nos programas construídos.
85
Figura 15. Software utilizado com o grupo de controle (enunciados sem contextualização)
Neste primeiro software os programas foram construídos pelos alunos na área onde pode se
ver o enunciado do desafio, a área central da Figura 15. Ao clicar no checkbox nomeado Enunciado
os alunos alternavam entre exibir ou não o enunciado de um desafio. Quando o enunciado não
estava sendo visualizado o programa que estava sendo construído pelo aluno era mostrado nesta
mesma área.
4.2.2 Software Utilizado pelo 2º Grupo Experimental
A diferença deste software para o anterior reside na forma como os enunciados dos
problemas algorítmicos foram apresentados aos alunos. Neste software, ao invés de enunciados
abstratos foram utilizadas descrições textuais e imagens dos desafios do jogo (ver Figura 16). Os
nomes de variáveis não eram mais nomes genéricos, mas sim nomes relacionados com a imagem do
jogo que era apresentada ao aluno.
86
Figura 16. Software do 2º experimento (nível intermediário de contextualização)
4.2.3 Software Utilizado pelo 1º Grupo Experimental - O Jogo
Este software foi na verdade um jogo (chamado de EscrachoBot), e os enunciados
apresentados aos alunos tinham o maior nível de contextualização em relação aos demais softwares
utilizados na pesquisa. No início do jogo o enredo é apresentado ao aluno, e trata-se de uma
pequena história usada como pano de fundo para os desafios (ver Quadro 9).
Ano 2035...
Houve uma terrível escassez de água potável que causou a morte de
dois terços da população da Terra. Uma estação de pesquisa foi
construída em Marte para verificar a possibilidade de utilizar a água
existente no subsolo do planeta.
Todos os pesquisadores que trabalhavam na estação espacial morreram
repentinamente de causa desconhecida. Desde então, a base na Terra não
recebe informações da estação espacial. Um robô foi construído para
ser enviado até a estação em Marte. Seu objetivo é utilizar o robô para
87
coletar e transmitir para a base na Terra as últimas informações
obtidas pelos pesquisadores.
O robô está a deriva na estação espacial. A única esperança da
equipe que está na Terra é uma conexão remota com o robô usando rádio
freqüência. A equipe consegue se conectar remotamente ao robô, apesar
da demora para o sinal chegar ao espaço. Sendo assim, resta apenas uma
opção: manter-se conectado ao robô remotamente e ir reprogramando-o de
acordo com as necessidades.
Você foi convocado para programar o robô e conseguir recuperar os
dados armazenados nos servidores da estação espacial, e então
transmiti-los para os pesquisadores na Terra. Um sistema de câmeras
instalado na estação espacial envia os sinais de vídeo para a estação
base na Terra. Uma câmera mostra uma vista de cima de toda a área da
estação espacial e outras câmeras mostram as salas. Utilize as setas
para guiar o robô até uma das salas da estação espacial. Quando o robô
entra em uma sala a porta de saída se fecha, e a única maneira de sair
é resolvendo um desafio. Boa sorte!
Quadro 9. Enredo do jogo
Depois de ler a pequena história o aluno segue para o jogo propriamente dito. O jogo inicia
com uma vista superior do ambiente de uma estação espacial (ver Figura 17) onde pode-se observar
várias salas vistas de cima. O jogador deve usar as setas do teclado para fazer com que o robô entre
nestas salas, pois os desafios do jogo acontecem dentro delas. Uma vez que o robô entra em uma
sala a única maneira de sair é resolvendo um desafio algorítmico. O objetivo final do jogo é chegar
até a sala onde estão os servidores que contém os dados armazenados pelos pesquisadores que
morreram na estação espacial (ver Quadro 9 com a história do jogo). O robô deve coletar os dados e
enviá-los para a estação base na Terra para dar a missão como cumprida.
O acesso às salas da estação espacial, e conseqüentemente aos seus desafios, pode ser feito
em qualquer ordem, diferentemente dos dois primeiros softwares onde os desafios foram
apresentados seqüencialmente ao aluno (o primeiro desafio, depois o segundo, o terceiro, e assim
por diante). A única exceção a esta regra é que no jogo não é possível entrar na sala onde está o
servidor – o desafio final – antes de se ter resolvido todos os outros desafios. Para entrar na última
sala o jogador deve inserir um código de 8 dígitos, que a princípio ele desconhece. Em cada desafio
resolvido o jogador recebe um desses dígitos. Ao resolver todos os desafios o código de acesso para
a sala do servidor finalmente estará completo.
88
Figura 17. Vista de cima da estação espacial onde o robô está sendo controlado pelo aluno
Quando o robô entra em uma das salas da estação espacial o jogo apresenta o enunciado do
problema que deve ser resolvido para que o robô consiga sair daquela sala. Na Figura 18 é mostrada
uma visão geral de como os desafios foram apresentados para os alunos dentro do jogo. Pode-se ver
a imagem do robô preso dentro de uma das salas da estação espacial, o enunciado descrevendo o
que o jogador deve fazer para resolver o problema algorítmico relacionado à sala, e as ferramentas
que podem ser utilizadas para construir o programa que será metaforicamente executado pelo robô.
No desafio mostrado na imagem o robô deve ativar interruptores em uma determinada seqüência.
Para isto, o aluno deve atribuir valores numéricos para dois arrays que representam os interruptores.
A ordem em que os interruptores devem ser acionados é exibida na parede da sala onde está o robô.
Robô
89
Figura 18. Visão geral do jogo
4.2.4 Elaboração dos Enunciados dos Problemas Algorítmicos
Em todos os três softwares apresentados anteriormente os alunos resolveram os mesmos
desafios algorítmicos, um total de nove problemas. Primeiramente foram elaborados os desafios do
jogo. Em seguida, os enunciados dos desafios do jogo foram modificados para ficarem com menos
contextualização. No caso dos enunciados utilizados no primeiro software foram retiradas quaisquer
menções ao jogo, ou seja, retirou-se o contexto. O que restou foi um conjunto de enunciados mais
abstratos, com variáveis nomeadas genericamente, tais como x ou y. O Quadro 10 ilustra como um
mesmo problema algorítmico foi apresentado de maneiras diferentes em cada um dos três softwares,
variando-se o nível de contextualização. Vale ressaltar que no 2º software (nível intermediário de
contextualização) os alunos vêem apenas imagens estáticas retiradas do jogo.
90
Na primeira linha do Quadro 10 pode-se ver um problema algorítmico representado através
de variáveis com nomes genéricos. Não há nada no enunciado que permita a identificação da
utilidade da solução do problema dentro de um contexto maior. Uma vez que o problema é
resolvido não se sabe para quê ele foi resolvido. Essa é o significado de não-contextualização
utilizado nesta pesquisa. Já na terceira linha do quadro o mesmo problema estaria sendo
apresentado ao aluno dentro do jogo, como parte da trama do mesmo.
Software Enunciado do problema algorítmico
1º
Neste desafio existe uma matriz de variáveis lógicas chamada interruptores. Esta matriz é quadrada e tem tamanho N. Você deve fazer um programa que altera somente os valores da diagonal principal da matriz para true. Os valores da matriz são acessados através de dois índices numéricos que representam a linha e a coluna, nesta ordem.
2º
Existem vários interruptores na sala e para resolver o problema é necessário ativar apenas os interruptores certos. Os interruptores podem ser acessados através de uma matriz, e para ativar um interruptor basta colocar o valor true na posição da matriz que corresponde ao interruptor desejado. As posições da matriz são acessadas através de dois índices numéricos que representam a linha e a coluna, nesta ordem.
3º (Jogo)
Texto exibido no jogo:
O sistema de energia da estação espacial continua oscilando e isto pode danificar o servidor principal onde estão armazenados os dados que o robô deve recuperar. Existem vários interruptores na sala e para resolver o problema é necessário ativar apenas os interruptores certos. Os interruptores podem ser acessados através de uma matriz, e para ativar um interruptor basta colocar o valor true na posição da matriz que corresponde ao interruptor desejado. As posições da matriz são acessadas através de dois índices numéricos que representam a linha e a coluna, nesta ordem.
Quadro 10. Um enunciado sendo apresentado em níveis diferentes de contextualização
4.3 INSTRUMENTO DE AVALIAÇÃO DO PRÉ E PÓS-TESTE
O desempenho dos alunos nos tópicos de interesse desta pesquisa (arrays, desvios
condicionais e laços de repetição) foi mensurado antes (pré-teste) e depois (pós-teste) da utilização
91
de cada um dos softwares descritos anteriormente por meio de um instrumento de avaliação. Este
mesmo instrumento foi utilizado para o pré e pós-teste. 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
última semana do semestre.
O instrumento de avaliação utilizado contém 10 questões de múltipla escolha envolvendo os
tópicos de programação introdutória que interessavam para esta pesquisa. Cada uma das questões
do instrumento foi classificada em um dos níveis da taxonomia de Bloom. Tanto as questões como
a classificação destas na taxonomia são baseadas no trabalho de Whalley et al (2006), que por sua
vez foi baseado no trabalho de Lister et al (2004). Duas questões relacionadas somente com desvios
condicionais foram incluídas no instrumento de avaliação, uma vez que as questões propostas pelos
autores citados anteriormente não tratavam deste tópico isoladamente, mas sempre em conjunto
com arrays e laços de repetição.
Os códigos das questões retiradas do trabalho de Whalley et al (2006), originalmente
escritos em Java e C++, foram traduzidos para a sintaxe do Portugol, a linguagem de pseudocódigo
utilizada com as turmas de alunos com as quais foram realizados os experimentos. Estes alunos
utilizaram a linguagem C ao final do semestre, entretanto, iniciaram com o Portugol. Como no
momento dos pré-testes os alunos conheciam somente a sintaxe do Portugol optou-se por utilizá-la
ao invés da sintaxe da linguagem C. Os detalhes de cada uma das questões do instrumento de
avaliação são apresentados no Apêndice B. Ao lado do título de cada questão do instrumento de
avaliação é indicado o nível da taxonomia de Bloom em que a questão foi classificada.
Uma discussão sobre este instrumento de avaliação foi publicada em Jesus e Raabe (2009).
Motta (2010) utilizou este instrumento como pré e pós-teste em um experimento que visou
mensurar o potencial pedagógico do JavaTool, uma ferramenta para apoiar a aprendizagem de
programação na linguagem Java.
4.4 CONSIDERAÇÕES
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
92
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
93
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
94
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.
95
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
96
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).
5.1 PRÉ-TESTES
Na Tabela 1 são apresentados os dados sobre as questões respondidas corretamente nos pré-
testes das 3 turmas de alunos. O instrumento de avaliação utilizado possui 10 questões (ver
Apêndice B), permitindo então um máximo de 10 acertos. Cabe ressaltar que a Tabela 1 mostra
apenas os dados dos alunos que participaram de todas as etapas dos experimentos. Apenas 11 dos
30 alunos que iniciaram no grupo de controle participaram de todas as etapas. No grupo
experimental 1 (os alunos que utilizaram o jogo) apenas os dados de 9 dos 21 alunos que iniciaram
os experimentos foram analisados na pesquisa. Por fim, no segundo grupo experimental (nível
intermediário de contextualização) apenas os dados de 20 dos 37 alunos que iniciaram os
experimentos foram analisados.
Tabela 1. Pré-testes das 3 turmas de alunos
Quantidade de questões corretas Aluno Grupo de Controle Grupo Exp. 1 (utilizou o jogo) Grupo Exp. 2
1 7 7 9
2 7 7 8
3 6 7 8
4 6 6 7
5 6 5 7
6 5 4 7
7 4 3 6
8 4 2 6
9 3 2 5
10 1 - 5
11 0 - 4
12 - - 4
13 - - 4
14 - - 3
15 - - 3
16 - - 3
17 - - 3
18 - - 2
19 - - 0
20 - - 0
Média 4,45 4,78 4,70
Desvio padrão 2,34 2,11 2,56
97
Para comparar o desempenho das 3 turmas no pré-teste primeiramente testou-se a
normalidade da distribuição dos dados coletados com o teste de Shapiro-Wilk. Este teste retorna um
valor (sig.) que deve ser maior do que a significância adotada para o teste (0,05) para que os dados
sejam considerados normais. A hipótese nula deste teste assume a normalidade da distribuição dos
dados, ou seja, se a hipótese nula não pode ser rejeitada então os dados podem ser considerados
normais. A Tabela 2 mostra que os 3 conjuntos de dados do pré-teste podem ser considerados
normalmente distribuídos.
Tabela 2. Resultados dos testes de Shapiro-Wilk para os pré-testes
Grupo Significância retornada pelo
teste (sig.) Resultado
Grupo de controle 0.178 Grupo experimental 1 0.110 Grupo experimental 2 0.524
sig > 0.05 para todos os casos. Os dados podem ser considerados como normalmente distribuídos.
Uma vez que os dados puderam ser considerados como aproximadamente normais utilizou-
se o teste paramétrico ANOVA para determinar se havia diferença entre a pontuação média das
turmas no momento do pré-teste. A hipótese nula do teste ANOVA assume que não existe diferença
significativa entre as médias das 3 amostras. O resultado do teste apontou um valor p igual a 0,94.
Como este valor p é bem maior que o nível de significância adotado para o teste (α = 0.05) a
hipótese nula não pôde ser rejeitada, e então se concluiu que não existia diferença significativa entre
o conhecimento das três turmas no momento do pré-teste.
5.2 INTERVENÇÕES COM AS TURMAS DE ALUNOS
Durante as intervenções cada turma de alunos resolveu o mesmo conjunto de problemas
algorítmicos utilizando a linguagem de programação não-textual e o mecanismo de correção
automática descritos respectivamente na Seção 4.1. Entretanto, em cada intervenção o mesmo
conjunto de problemas estava inserido dentro de um software diferente, ou seja, cada uma das 3
turmas utilizou um software diferente. A diferença entre estes softwares estava no nível de
contextualização com que os enunciados dos problemas algorítmicos foram apresentados aos
alunos. O grupo de controle utilizou um software onde os enunciados eram abstratos e sem
contextualização. Já a segunda turma (o primeiro grupo experimental) utilizou um software onde os
problemas foram apresentados dentro do contexto de um jogo, e este foi o nível mais alto de
contextualização em todas as 3 intervenções. Uma terceira turma de alunos (o segundo grupo
98
experimental) utilizou um software com um nível intermediário de contextualização, onde os
enunciados apenas faziam menção a alguns aspectos do jogo utilizado pelo segundo grupo
experimental.
Os alunos utilizaram os softwares por aproximadamente duas horas nos laboratórios de
informática da universidade onde foram realizados os experimentos. A turma de alunos que utilizou
o software com nível intermediário de contextualização (grupo experimental 2) acabou utilizando o
software durante toda a aula, o que possivelmente aumentou a quantidade de problemas resolvidos
por esta turma. Após o término dos experimentos os alunos de cada turma puderam continuar
utilizando os softwares a partir de casa através da internet. Entretanto, de maneira geral verificou-se
que poucos alunos resolveram problemas fora do horário da aula onde aconteceu a intervenção.
Esta pesquisa foi realizada com o foco em três tópicos de programação introdutória: os
arrays, os desvios condicionais e os laços de repetição (loops). O instrumento de avaliação utilizado
nos testes e os problemas algorítmicos que foram resolvidos pelos alunos durante as intervenções
tratavam apenas destes tópicos. Para que as mensurações realizadas nos experimentos fossem
efetivas era necessário que os envolvidos nos experimentos resolvessem todos os problemas
algorítmicos durante as intervenções. Nem todos os problemas foram resolvidos pelos alunos, e
então os resultados da pesquisa estão limitados àqueles tópicos abordados nos problemas que foram
resolvidos. Durante as intervenções foi possível observar que muitos alunos tiveram dificuldades
para entender os próprios enunciados dos problemas. É possível que muitos alunos não tenham
resolvido os problemas porque nem mesmo chegaram a entender o que deveria ser feito.
A Tabela 3 mostra os dados sobre os exercícios que foram realizados pelos alunos do grupo
de controle e do segundo grupo experimental durante as intervenções com os softwares. Nos
softwares utilizados por estes grupos os problemas algorítmicos foram apresentados
seqüencialmente, e por este motivo alguns alunos não chegaram a resolver os últimos problemas.
Os 4 primeiros desafios apresentados aos alunos tratavam apenas de desvios condicionais. Do
quinto ao sétimo desafios os alunos resolveram problemas utilizando loops para percorrer arrays,
portanto exercitaram os dois tópicos simultaneamente. Os dois últimos desafios apresentados aos
alunos abordavam somente os loops, e poucos alunos chegaram a resolvê-los.
99
Tabela 3. Exercícios realizados pelo grupo de controle e pelo segundo grupo experimental
Grupo de controle Grupo experimental 2
Aluno Último exercício realizado
Desvios condicionais
Arrays +
loops
Somente loops
Último exercício realizado
Desvios condicionais
Arrays + loops
Somente loops
1 9/9 9/9
2 9/9 9/9
3 9/9 9/9
4 8/9 9/9
5 6/9 7/9
6 6/9 5/9
7 5/9 5/9
8 5/9 5/9
9 4/9 5/9
10 4/9 5/9
11 2/9 4/9
12 - - - - 3/9
13 - - - - 3/9
14 - - - - 3/9
15 - - - - 3/9
16 - - - - 3/9
17 - - - - 2/9
18 - - - - 2/9
19 - - - - 2/9
20 - - - - 2/9
Na Tabela 4 são apresentados os exercícios realizados pelo primeiro grupo experimental.
Este grupo utilizou o jogo, onde o acesso aos problemas algorítmicos não foi seqüencial e os alunos
puderam resolver os problemas na ordem que desejaram. Por este motivo os dados deste grupo são
apresentados em uma tabela separada (Tabela 4) onde pode-se observar quais exercícios foram
realizados por cada um dos alunos participantes da intervenção.
Como pode-se observar na Tabela 3 e na Tabela 4, os resultados desta pesquisa não poderão
ser utilizados para afirmar algo a respeito da influência de um jogo na aprendizagem do tópico
loops, já que poucos alunos exercitaram este tópico isoladamente. Sendo assim, os resultados estão
focados principalmente na aprendizagem de desvios condicionais e com um pouco menos de ênfase
na aprendizagem de arrays e loops, nos casos de problemas em que estes tópicos são trabalhados
simultaneamente.
100
Tabela 4. Exercícios realizados pelo primeiro grupo experimental
Desvio Condicional
Loops + Arrays Somente
Loops Aluno Ex. 1 Ex. 2 Ex. 3 Ex. 4 Ex. 5 Ex. 6 Ex. 7 Ex. 8 Ex. 9
1 - - - - - - - -
2 - - - - - - - -
3 - - -
4 - - -
5 - - - - - - - -
6 - -
7 - - - - - - - -
8 - - -
9 - - - - - - - -
5.3 PÓS-TESTES
Os pós-testes foram aplicados no final dos semestres letivos em que foram realizados os
experimentos com os alunos (2009-II e 2010-II). Ao final dos semestres muitos dos alunos já
haviam desistido das disciplinas, fato muito comum em se tratando de programação introdutória.
Apenas 11 dos 30 alunos do grupo de controle que realizaram o pré-teste estavam presentes na
realização do pós-teste. No primeiro grupo experimental (o grupo que utilizou o jogo) 18 dos 21
alunos realizaram o pós-teste. Por fim, no segundo grupo experimental 25 dos 37 alunos que
iniciaram o semestre realizaram o pós-teste. Destes alunos que realizaram os pós-testes nem todos
participaram das intervenções com os softwares, o que reduziu ainda mais o tamanho das amostras
que puderam ser analisadas nesta pesquisa.
Na Tabela 5 são apresentados os números de acertos de cada um dos alunos participantes
dos pós-testes. O objetivo deste trabalho não é determinar a diferença de desempenho entre as
turmas analisando apenas o resultado do pós-teste, mas sim o que se chamou de fator de
aprendizagem (a diferença entre as pontuações do pós e do pré-teste). Mesmo assim, os dados
apresentados na Tabela 5 mostram que o grupo que utilizou o jogo conseguiu uma pontuação média
de pós-teste um pouco maior que os demais grupos.
Verificou-se se a diferença entre o desempenho médio nos pós-testes foi realmente
significativa. Inicialmente foi verificada a suposição de normalidade com o teste de Shapiro-Wilk.
101
Os resultados deste teste apontaram que os dados do grupo de controle (sig. = 0.285) e do grupo
experimental 2 (sig. = 0.68) podiam ser considerados normalmente distribuídos. Entretanto, o teste
também mostrou que os dados do grupo que utilizou o jogo (grupo experimental 1) não eram
normalmente distribuídos (sig. = 0.006).
Tabela 5. Dados do pós-teste
Número de acertos em 10 questões Identificador do Aluno Grupo de
controle Grupo experimental 1
(utilizou o jogo) Grupo
experimental 2 1 9 10 10
2 8 8 9
3 8 8 9
4 7 8 9
5 7 8 9
6 7 7 9
7 7 7 8
8 6 7 8
9 5 7 8
10 4 - 8
11 4 - 7
12 - - 6
13 - - 6
14 - - 5
15 - - 5
16 - - 4
17 - - 4
18 - - 3
19 - - 2
20 - - 1
Média 6,55 7,78 6,50 Desvio padrão 1,63 0,97 2,65
Mediana 7 8 7,5
Quando não se pode considerar o conjunto de dados como normalmente distribuído (este é o
caso do grupo experimental 1) o mais adequado é utilizar testes não-paramétricos. Sendo assim, o
teste de Kruskal-Wallis foi utilizado para verificar se existia uma diferença significativa entre as
medianas (este teste não compara médias) das pontuações de pós-teste das 3 turmas. A hipótese
nula deste teste assume que as amostras vêm todas da mesma população. O teste retornou um valor
p igual a 0.402, que é bem maior que o nível de significância adotado (0,05). Sendo assim, não é
102
possível rejeitar a hipótese nula, e conclui-se que não existe uma diferença significativa nas
medianas das 3 turmas nas pontuações do pós-teste.
5.4 PROGRESSO DOS ALUNOS DO PRÉ PARA O PÓS-TESTE
Na Tabela 6 são apresentados os acertos dos alunos tanto no pré quanto no pós-teste. Foram
realizados testes-t pareados para verificar se a diferença entre a média de acertos do pré para o pós-
teste em cada uma das turmas foi significativa com 95% de confiança (α = 0,05). Em todos os 3
testes realizados os valores p são bem menores que o nível de significância (ver Tabela 6), o que
permite a rejeição das hipóteses nulas de que não há diferença significativa entre as médias de pré e
pós-teste. Isto permite concluir que em todas as turmas a média de acertos no pós-teste é
significativamente maior do que a média no pré-teste, e que todas as turmas evoluíram ao longo do
semestre.
A diferença entre as pontuações do pré e pós-teste de cada aluno foi utilizada como o fator
de aprendizagem do estudante. Este fator de aprendizagem foi tomado como uma medida do
progresso de cada aluno ao longo do semestre. Estes fatores são apresentados na Tabela 6, onde
também são apresentadas as médias e medianas destes fatores para cada uma das turmas.
Um dos objetivos deste trabalho foi comparar os fatores de aprendizagem das turmas entre si
para verificar se existia diferença significativa entre eles. Primeiramente, foi verificada a suposição
de normalidade do conjunto de fatores de aprendizagem de cada uma das 3 turmas com o teste de
Shapiro-Wilk. O teste retornou um valor sig. = 0,007 para o grupo de controle, um valor sig =
0,298 para o primeiro grupo experimental e 0,515 para o segundo grupo experimental. Estes valores
indicam que os dados do grupo de controle não são normalmente distribuídos (sig < 0.05).
Dada a não-normalidade de uma das amostras de fatores de aprendizagem, os fatores das
turmas de alunos foram comparados com o teste de Kruskal-Wallis. Este teste retornou um valor
0.566 que é maior que o nível de significância adotado (α = 0.05). Sendo assim, aceitou-se a
hipótese nula de que as amostras vinham todas da mesma população, e de que não havia diferença
significativa entre elas. Ou seja, segundo o teste não é possível afirmar que uma das turmas
apresentou um progresso maior do que as demais.
103
Tabela 6. Acertos no pré e pós-teste
Grupo de Controle Grupo
Experimental 1 (utilizou o jogo)
Grupo Experimental 2 Aluno
Pré teste
Pós teste
Fator de aprendizagem
Pré teste
Pós teste
Fator de aprendizagem
Pré teste
Pós teste
Fator de aprendizagem
1 7 9 2 5 10 5 4 10 6
2 6 8 2 7 8 1 7 9 2
3 7 8 1 6 8 2 7 9 2
4 4 7 3 2 8 6 6 9 3
5 5 7 2 2 8 6 5 9 4
6 0 7 7 7 7 0 5 9 4
7 6 7 1 7 7 0 4 8 4
8 6 6 0 4 7 3 8 8 0
9 4 5 1 3 7 4 7 8 1
10 1 4 3 - - - 3 8 5
11 3 4 1 - - - 6 7 1
12 - - - - - - 9 6 -3
13 - - - - - - 8 6 -2
14 - - - - - - 4 5 1
15 - - - - - - 0 5 5
16 - - - - - - 2 4 2
17 - - - - - - 0 4 4
18 - - - - - - 3 3 0
19 - - - - - - 3 2 -1
20 - - - - - - 3 1 -2
Média 4,45 6,55 2,09 4,78 7,78 3,00 4,70 6,50 1,80
Desvio padrão
2,34 1,63 1,87 2,11 0,97 2,40 2,56 2,65 2,59
Mediana 5 7 2 5 8 3 4,5 7,5 2
Valor p do teste-t
0,0020 0,0027 0,0028
5.5 FATORES DE APRENDIZAGEM DAS CLASSES DE ALUNOS
Os alunos participantes desta pesquisa também foram classificados segundo dois indicadores: o
desempenho no pós-teste e a média final (MF) nas disciplinas de programação introdutória. Em
cada uma das turmas os alunos foram divididos em 3 classes: alunos ótimos, medianos ou com
dificuldades.
Os alunos foram classificados segundo as suas pontuações do pós-teste pelo fato de
que no momento do pré-teste os alunos sequer haviam aprendido os tópicos de programação que
interessavam para esta pesquisa, de maneira que as pontuações do pré-teste não representariam o
104
nível de conhecimento dos alunos. Já a classificação pela pelas médias finais dos alunos nas
disciplinas (MF) foi utilizada por se entender que qualquer melhoria na aprendizagem produzida
pela utilização do jogo deveria se traduzir em médias finais mais altas, ao invés de apenas
pontuações de pós-teste mais altas.
5.5.1 Classificação dos Alunos em Função do Pós-Teste
Na Tabela 7 são apresentados os fatores de aprendizagem (F.A.) para cada uma das classes de
alunos mencionados anteriormente. Os alunos com pontuação do pós-teste entre 8 e 10 foram
classificados como Ótimos; aqueles com pontuação do pós-teste maior ou igual a 6 e menor que 8
foram classificados como Medianos; e aqueles com pontuação do pós-teste menor que 6 foram
classificados como alunos Com Dificuldades.
Tabela 7. Fatores de aprendizagem das classes de alunos (classificação pelo pós-teste)
Turma Classe N Média
Pré-teste Média
Pós-teste F.A. Médio
Com dificuldades 3 2,67 4,33 1,67
Medianos 5 4,20 6,80 2,60 Grupo de Controle
Ótimos 3 6,67 8,33 1,67
Medianos 4 5,25 7,00 1,75 Grupo Experimental 1 (utilizaram o jogo) Ótimos 5 4,40 8,40 4,00
Com dificuldades 7 2,14 3,43 1,29
Medianos 3 7,67 6,33 -1,33 Grupo Experimental 2
Ótimos 10 5,60 8,70 3,10
A turma de alunos que utilizou o jogo (Grupo Experimental 1) não possui integrantes com
pontuação de pós-teste inferior a 7, e por este motivo nenhum dos alunos da turma foi classificado
como Com dificuldades. Cabe ressaltar que neste caso o termo “todos os alunos” significa na
verdade “todos os que participaram de todas as etapas dos experimentos”.
Os fatores de aprendizagem (valores da Tabela 6) de cada uma das classes de alunos foram
comparados entre si com o teste de Kruskal-Wallis. O teste retornou um valor sig = 0.289 para os
alunos ótimos, um valor de 0.163 para os alunos medianos e 0.729 para os alunos com dificuldades.
Como nenhum destes valores é menor do que o nível de significância adotado para os testes (0.05)
não se pode rejeitar a hipótese nula sobre a igualdade das amostras. Sendo assim, não se pode
afirmar que houve diferença significativa no progresso das turmas em qualquer uma das classes.
105
Apesar de não se ter encontrado nenhuma diferença significativa entre o progresso dos
alunos, aqueles classificados como Ótimos nos dois grupos experimentais apresentaram um fator de
aprendizagem médio maior do que os alunos Ótimos no grupo de controle (ver Figura 19). Os
alunos Medianos do Grupo experimental 2 regrediram, apresentando um fator de aprendizagem
negativo. No caso dos alunos Medianos, o grupo de controle apresentou um progresso maior do que
os dois grupos experimentais.
Figura 19. Fatores de aprendizagem das classes de alunos (classificação pelo pós-teste)
5.5.2 Classificação dos Alunos em Função das Médias Finais
Os alunos também foram reclassificados em função das suas médias finais na disciplina de
programação introdutória. Fez-se a mesma classificação apresentada anteriormente, mas neste caso
ao invés das pontuações de pós-teste os alunos foram classificados pelas suas médias finais (MF).
Na Tabela 8 são apresentados as pontuações dos alunos e também as suas médias finais na
disciplina de programação introdutória. Cabe ressaltar que os alunos com média final menor que 6
foram reprovados. Utilizou-se o seguinte critério de classificação:
Alunos ótimos (MF entre 8 e 10);
1. Alunos medianos (MF maior ou igual a 6 e menor que 8); e
2. Alunos com dificuldades (MF menor que 6).
106
Tabela 8. Acertos no pré e pós-teste e média final (MF) na disciplina
Grupo de Controle
Grupo Exp. 1 (utilizou o jogo)
Grupo Exp. 2 Aluno Pré teste Pós teste MF Pré teste Pós teste MF Pré teste Pós teste MF
1 7 9 9,5 7 7 9,5 6 9 10
2 5 7 9,5 7 8 8,5 7 9 9,5
3 4 7 9 4 7 8,5 8 8 9,5
4 6 7 9 2 8 7,5 7 8 9,5
5 6 8 8,5 7 7 7,5 7 9 8,5
6 6 6 8,5 5 10 7 4 8 8,5
7 3 4 8 3 7 7 3 8 8,5
8 4 5 7,5 6 8 6,5 9 6 8,5
9 0 7 7 2 8 5 6 7 8
10 7 8 6,5 - - - 5 9 7,5
11 1 4 4,5 - - - 4 10 7
12 - - - - - - 5 9 7
13 - - - - - - 2 4 7
14 - - - - - - 0 4 7
15 - - - - - - 8 6 6
16 - - - - - - 3 2 6
17 - - - - - - 0 5 5,5
18 - - - - - - 4 5 4,5
19 - - - - - - 3 3 4
20 - - - - - - 3 1 3,5
Média 4,45 6,55 7,95 4,78 7,78 7,44 4,70 6,50 7,28
Desvio padrão 2,34 1,63 1,51 2,11 0,97 1,31 2,56 2,65 1,90
Mediana 5 7 8,50 5 8 7,50 4,5 7,5 7,25
Na Tabela 9 são apresentados os fatores de aprendizagem para as classes de alunos em cada
uma das turmas, sendo esta classificação feita em função da média final (MF).
Tabela 9. Fatores de aprendizagem das classes de alunos (classificação pela MF)
Turma Classe N Média Pré-teste Média Pós-teste F.A. Médio
Ótimos 7 5,29 6,86 1,57
Medianos 3 3,67 6,67 3,00 Grupo de Controle
Com dificuldades 1 1,00 4,00 3,00
Ótimos 3 6,00 7,33 1,33
Medianos 5 4,60 8,00 3,40 Grupo Exp. 1 (utilizaram o jogo)
Com dificuldades 1 2,00 8,00 6,00
Ótimos 9 6,33 8,00 1,67
Medianos 7 3,86 6,29 2,43 Grupo Exp. 2
Com dificuldades 4 2,50 3,50 1,00
107
Os fatores de aprendizagem das classes de alunos foram novamente comparados entre si
com o teste de Kruskal-Wallis. O teste retornou um valor sig = 0.873 para os alunos ótimos, um
valor de 0.837 para os alunos medianos e 0.287 para os alunos com dificuldades. Novamente,
nenhum destes valores foi menor do que o nível de significância adotado para os testes (0.05), e por
este motivo não foi possível afirmar que houve diferença significativa no progresso das turmas em
qualquer uma das classes de alunos.
Na Figura 20 os fatores de aprendizagem das classes de alunos são apresentados
graficamente. É possível observar que os fatores variam pouco de uma turma para a outra, exceto no
caso dos alunos com dificuldades. O grupo experimental 1 (que utilizou o jogo) teve apenas um
aluno classificado como com dificuldades, e este aluno obteve um fator de aprendizagem igual a
seis, o que explica a discrepância observada no gráfico. É interessante observar que mesmo com um
bom progresso do pré para o pós-teste este aluno terminou o semestre como reprovado (MF < 6).
Figura 20. Fatores de aprendizagem das classes de alunos (classificação pela MF)
5.6 PROGRESSO DAS CLASSES DE ALUNOS
Além da análise do fator de aprendizagem de cada classe de alunos também foi analisada a
transição dos alunos de uma classe para outra. Neste caso, o que se desejava saber era se, por
exemplo, os alunos com dificuldades tornaram-se alunos ótimos no decorrer do semestre, ou então
se alunos medianos se tornaram alunos ótimos, e assim por diante. Para esta análise os alunos
108
receberam duas classificações: utilizou-se a pontuação de pré-teste para determinar em que classe
os alunos estavam no início dos experimentos e a pontuação de pós-teste para classificá-los ao final
do experimento. A Tabela 10 sumariza a quantidade (#) e porcentagem (%) de alunos nas classes
mencionadas anteriormente, a saber: alunos com dificuldades, alunos medianos e alunos ótimos.
Tabela 10. Progresso das classes de alunos
Grupo de Controle
(N=11)
Grupo Exp. 1 (utilizou o jogo)
(N=9)
Grupo Exp. 2 (N=20)
Alunos que...
# % # % # %
Progrediram de com dificuldades para ótimo
0 0,0% 3 33,3% 4 20,0%
Progrediram de mediano para ótimo
3 27,3% 4 44,4% 5 25,0%
Progrediram de com dificuldades para mediano
3 27,3% 2 22,2% 0 0,0%
Progrediram 6 54,5% 7 77,8% 11 45,0%
Regrediram 0 0,0% 0 0,0% 2 10,0%
Iniciaram com dificuldades 6 54,5% 5 55,5% 12 60,0%
Continuaram com dificuldades 3 27,3% 0 0,0% 7 35,0%
Continuaram medianos 2 18,2% 2 22,2% 1 5,0%
Continuaram ótimos 0 0,0% 0 0,0% 1 5,0%
Na Tabela 10 pode se observar que a turma que utilizou o jogo (grupo experimental 1)
progrediu mais do que as outras turmas. Nos dois grupos experimentais alguns alunos inicialmente
classificados como com dificuldades (33,3% e 20%) tornaram-se alunos ótimos. Isto não aconteceu
com o grupo de controle, o que sugere que os níveis mais altos de contextualização tenham
ocasionado esta diferença. Além disso, o grupo que jogou também tem o maior percentual de alunos
medianos que se tornaram alunos ótimos (44,4%). Todas as 3 turmas iniciaram com
aproximadamente o mesmo percentual de alunos com dificuldades, e somente a turma de alunos que
utilizou o jogo (grupo experimental 1) acabou os experimentos sem nenhum indivíduo classificado
dessa forma.
109
5.7 PROGRESSO NOS NÍVEIS DA TAXONOMIA DE BLOOM
As questões do instrumento de avaliação utilizado no pré e no pós-teste foram classificadas
segundo a taxonomia revisada de Bloom. O objetivo desta classificação foi mensurar o progresso
dos alunos nos níveis da taxonomia, já que estes níveis são progressivamente mais complexos.
Apenas 4 dos 6 níveis da taxonomia foram abordados no instrumento de avaliação. Os dois níveis
superiores (os mais complexos) não foram tratados pelo instrumento de avaliação. O nível mais
inferior da taxonomia (Lembrar) não foi tratado diretamente no instrumento de avaliação, mas foi
tratado indiretamente em todas as questões, já que na taxonomia os níveis superiores englobam os
níveis mais inferiores. Ou seja, em todas as questões os alunos precisaram Lembrar, ainda que
nenhuma das questões tenha se restringido somente a este nível.
A Tabela 11 apresenta o percentual de acertos nos níveis da taxonomia de Bloom para os
alunos que participaram de todas as etapas dos experimentos. Estes percentuais de acertos foram
obtidos como uma razão entre o número de questões respondidas corretamente em um determinado
nível da taxonomia e o total de acertos possíveis no mesmo nível. De forma mais resumida, isto
equivale ao número de acertos dos alunos dividido pelo total de acertos possíveis.
Tabela 11. Desempenho dos alunos nos níveis da taxonomia de Bloom
Nº de acertos Percentual de acertos Nível da Taxonomia
Turma N Pré Teste
Pós Teste
Pré Teste
Pós teste
Pós - Pré
Grupo de controle 11 19/33 29/33 57,5% 87,8% 30,3%
Grupo exp. 1 (jogo) 9 19/27 24/27 70,3% 88,8% 18,5% Entender (3 questões)
Grupo exp. 2 20 35/60 45/60 58,3% 75,0% 16,7%
Grupo de controle 11 22/55 32/55 40,0% 58,1% 18,1%
Grupo exp. 1 (jogo) 9 18/45 37/45 40,0% 82,2% 42,2% Aplicar (5 questões)
Grupo exp. 2 20 44/100 60/100 44,0% 60,0% 16,0%
Grupo de controle 11 8/22 11/22 36,3% 50,0% 13,7%
Grupo exp. 1 (jogo) 9 6/18 9/18 33,3% 50,0% 16,7% Analisar (2 questões)
Grupo exp. 2 20 15/40 25/40 37,5% 62,5% 25,0%
O número total de acertos possíveis em um determinado nível da taxonomia foi obtido
multiplicando-se o numero de questões do instrumento de avaliação classificadas no nível pelo
total de alunos na turma. Por exemplo, o instrumento de avaliação utilizado no pré e pós-teste
contém 3 questões classificadas no nível Entender da taxonomia. No grupo de controle 11 alunos
110
participaram de todas as etapas dos experimentos, o que resulta em um total de 3 questões x 11
alunos, totalizando 33 acertos possíveis para o grupo de controle no nível Entender da taxonomia.
O mesmo princípio foi utilizado para os demais níveis da taxonomia, sendo que o instrumento de
avaliação contém cinco questões classificadas no nível Aplicar e duas no nível Analisar. Os grupos
experimentais 1 e 2 possuem respectivamente 9 e 20 alunos.
Analisando os dados da Tabela 11 pode-se observar que os percentuais de acertos em todos
os níveis da taxonomia aumentaram do pré para o pós-teste. Estes dados também mostram que no
momento dos pré-testes as 3 turmas tinham um desempenho muito próximo nos níveis Aplicar
(aproximadamente 40% de acertos para todas as turmas) e Analisar (aproximadamente 35% de
acertos para todas as turmas). Os percentuais do pós-teste mostram que o grupo que utilizou o jogo
(grupo experimental 1) apresentou um bom progresso no nível Aplicar da taxonomia, pois no pós-
teste acertou 40,2% a mais de questões classificadas neste nível. Além disso, o grupo experimental
2 (nível intermediário de contextualização) parece ter apresentado um desempenho ligeiramente
melhor que as outras turmas no nível Analisar da taxonomia. O progresso dos alunos no nível
Entender já não é tão simples como os anteriormente mencionados, pois os percentuais de acertos
das turmas no pré-teste diferem bastante entre si, o que dificulta uma comparação mais direta com
os percentuais do pós-teste. Ainda assim, aparentemente o grupo de controle saiu-se um pouco
melhor que os demais grupos nas questões classificadas no nível Entender da taxonomia de Bloom.
Na Figura 21 os mesmos percentuais apresentados na Tabela 11 são mostrados
graficamente. Nesta figura também é possível visualizar o efeito do aumento da complexidade dos
níveis da taxonomia de Bloom na quantidade de questões respondidas corretamente pelos alunos.
Os níveis da taxonomia estão representados no eixo horizontal da figura, e estão ordenados segundo
o nível de complexidade, da esquerda para a direita. Os gráficos mostram que em geral tanto no pré
como no pós-teste o percentual de acertos diminui à medida que a complexidade do nível da
taxonomia aumenta. Isto condiz com a idéia de que questões mais complexas sejam naturalmente
mais difíceis de se responder corretamente.
111
Figura 21. Desempenho das turmas nos níveis da taxonomia de Bloom.
Cabe salientar que o instrumento de avaliação utilizado não possui o mesmo número de
questões para cada um dos níveis da taxonomia que foram abordados. São 3 questões no nível
menos complexo (Entender), 5 questões em um nível intermediário (Aplicar), e 2 questões em um
nível mais complexo (Analisar). Sendo assim, os alunos tiveram menos chances de acertar as
questões mais complexas, já que existem apenas duas delas no instrumento de avaliação. Além
disso, as questões mais complexas eram a penúltima e antepenúltima do teste. Como os testes
duraram pouco mais de uma hora é possível que a fadiga tenha induzido os alunos ao erro ou
mesmo ao “chute“ (o instrumento de avaliação é composto por questões de múltipla escolha), pois
ao final dos testes os alunos poderiam ter escolhido aleatoriamente uma das possíveis respostas
apenas para finalizar a atividade da maneira mais rápida possível.
5.8 CONSIDERAÇÕES
Os alunos que participaram dos experimentos faziam parte de 3 turmas do primeiro semestre
de um curso de Ciência da Computação da UNIVALI. Os experimentos com o grupo de controle
foram realizados no segundo semestre de 2009, e os demais experimentos no primeiro semestre de
2010. As 3 turmas estavam sob a responsabilidade de 2 professores, sendo duas delas sob a
responsabilidade de um professor e a terceira sob a responsabilidade de outro. Nos semestres em
que foram realizados os experimentos os professores trabalharam de forma integrada e utilizaram
112
planos de ensino bastante semelhantes. Isto contribuiu para que o mesmo cronograma pudesse ser
utilizado para os experimentos com as diferentes turmas e em diferentes semestres, pois os tópicos
de interesse desta pesquisa foram apresentados nas disciplinas praticamente nas mesmas semanas,
com pouca ou nenhuma variação.
Para o pós-teste aplicou-se exatamente o mesmo instrumento de avaliação utilizado no pré-
teste, pois considerou-se que o tempo entre as duas mensurações (13 semanas) seria longo o
suficiente para diluir qualquer aprendizagem causada pelo próprio instrumento de avaliação. De
qualquer maneira, ainda que tal aprendizagem tenha ocorrido, o mesmo cronograma foi utilizado
nos experimentos com todas as turmas de alunos, o que permitiu que todos os alunos tivessem as
mesmas chances de aprender com o instrumento de avaliação, eliminando qualquer influência
relacionada a comparação entre as turmas.
Durante a intervenção com as turmas, onde os softwares foram utilizados, alguns alunos não
conseguiram resolver todos os problemas algorítmicos disponíveis. Isto diminui em algum grau o
alcance dos resultados deste trabalho, já que os desafios apresentados aos alunos estavam
relacionados aos tópicos de interesse da pesquisa (desvios condicionais, arrays e loops).
Entretanto, vale ressaltar que durante as intervenções com os alunos do grupo de controle e
do 2º grupo experimental registrou-se (através de um log) apenas a última questão respondida
corretamente por cada aluno, já que nestas intervenções o acesso aos problemas algorítmicos foi
seqüencial. É bem provável que os alunos destas turmas tenham trabalhado em mais um problema
além daquele último que foi resolvido corretamente, e neste caso, o próprio ato de tentar resolver o
problema, ainda que sem sucesso, pode ter impactado na aprendizagem do aluno. No caso do jogo
(utilizado pelo 1º grupo experimental) isto pode ter acontecido de forma ainda mais intensa, pois no
jogo o acesso aos problemas não era seqüencial. Os alunos acessavam os desafios na ordem em que
desejavam, e a qualquer momento podiam desistir de um problema e tentar resolver outro, desde
que este outro problema ainda estivesse sem solução. Ou seja, no caso do jogo é necessário
considerar que mesmo aqueles alunos para os quais não se registrou nenhum acerto podem ter
tentado resolver todos os desafios do jogo, e possivelmente aprendido com isto.
Durante as intervenções observou-se que alguns alunos estavam utilizando o mecanismo de
correção automática de programas a seu favor. Quando prosseguiam para um novo desafio a
primeira ação destes alunos era invocar a correção do programa. Como o programa criado pelo
113
aluno ainda não continha nenhuma estrutura de programação o mecanismo de correção acabava por
informar quais estruturas eram obrigatórias para que o programa fosse considerado correto. Alguns
alunos utilizaram esta funcionalidade como “dica” para saber que estruturas precisariam utilizar
para atender ao mecanismo de correção.
Os pós-testes foram realizados por volta do final do semestre letivo. Esta decisão mostrou-se
bastante problemática, já que em disciplinas de programação introdutória o número de alunos
costuma diminuir drasticamente ao final do semestre. Sendo assim, o número de alunos
participantes de todas as etapas dos experimentos foi pequeno se comparado a quantidade de alunos
que realizaram os pré-testes.
A realização do pós-teste ao final do semestre letivo ainda acarretou um segundo problema
relacionado à “qualidade das amostras”. Ao final de um semestre letivo restam apenas os
“sobreviventes” de uma disciplina de programação introdutória, apenas aqueles alunos que
apresentaram desempenho minimamente satisfatório durante todo o semestre. Os demais, aqueles
que não obtiveram boas notas, tendem a evadir antes mesmo do final do semestre, já que na
instituição onde o experimento foi realizado freqüentemente os alunos têm consciência da possível
reprovação já por volta do segundo terço do semestre. Sendo assim, além de pequenas, as amostras
que foram analisadas nesta pesquisa devem ser consideradas como enviesadas, pois tendem a ser
compostas na sua maioria pelos melhores alunos, os “sobreviventes”.
Algumas considerações também devem ser mencionadas em relação ao instrumento de
avaliação que foi utilizado no pré e pós-teste. Percebeu-se que os alunos já apresentavam sinais de
fadiga ao final da atividade com o instrumento de avaliação. O instrumento contém 10 questões de
múltipla escolha (ver Apêndice B) que requerem uma significativa quantidade de esforço intelectual
para um aluno de primeiro semestre. Esta fadiga causada pelo instrumento de avaliação pode ter
aumentado o número de questões respondidas aleatoriamente (o “chute”). É claro que os alunos
poderiam “chutar” as respostas a qualquer momento do teste, estando ou não fatigados, mas é
possível que a fadiga tenha lhes empurrado ainda mais nesta direção.
Analisando o desempenho dos alunos do pré para o pós-teste verificou-se que houve uma
melhoria significativa na quantidade de acertos das questões. Certamente este resultado não é algo
surpreendente, já que naturalmente espera-se que os alunos apresentem mais conhecimento ao final
do semestre letivo de que o faziam no início. Entretanto, a melhoria estatisticamente significativa
114
mostra que as mensurações realizadas, mesmo com todos os problemas já discutidos, apresentam
resultados condizentes com a realidade. Ou seja, os resultados obtidos condizem com os resultados
esperados.
Os dados coletados também permitiram visualizar como os níveis da taxonomia de Bloom
estão relacionados com a quantidade de acertos nas questões. Foi possível observar que quanto mais
complexo é um nível da taxonomia menor é o percentual de acertos nas questões classificadas neste
nível. É fundamental salientar que esta análise é superficial por pelo menos 3 motivos:
1. As análises foram realizadas com amostras pequenas;
2. O instrumento de avaliação utilizado nos pré e pós-testes não possui o mesmo número de
questões para todos os níveis da taxonomia, e então os alunos não têm as mesmas
chances de acertar as questões de todos os níveis; e
3. As questões mais complexas foram apresentadas somente ao final do teste, momento em
que a fadiga pode tornar muito tentadora a escolha aleatória da resposta.
Entretanto, mesmo com estes problemas mencionados, os dados coletados mais uma vez
adéquam-se àquilo que se consideraria como resultado esperado. Espera-se que questões mais
complexas sejam mais difíceis de responder do que as questões mais fáceis. Sendo assim, a
mensuração do progresso dos alunos nos níveis da taxonomia de Bloom parece ser possível e
satisfatória da maneira como foi realizada.
115
6 CONCLUSÕES
Esta pesquisa avaliou quantitativamente o efeito da utilização de um jogo na aprendizagem
de programação introdutória. A pesquisa como um todo foi norteada por dois questionamentos
principais, a saber:
1. Como a utilização de um jogo de computador focado na resolução de problemas
algorítmicos influencia a aprendizagem de programação introdutória? e
2. Um jogo promove melhorias na aprendizagem ou este mesmo resultado pode ser
alcançado apenas com a utilização de problemas de programação melhor
contextualizados?
As hipóteses relacionadas com os questionamentos apresentados anteriormente eram:
H1: Exercícios de programação com enunciados mais contextualizados melhoram a
aprendizagem; e
H2: O uso do jogo promove melhores resultados na aprendizagem do que apenas a
utilização de exercícios mais contextualizados;
Estas hipóteses ainda foram pormenorizadas através da categorização dos alunos que
participaram dos experimentos em três classes: alunos ótimos, medianos ou com dificuldades, pois
se imaginou que alunos com dificuldades poderiam beneficiar-se mais da contextualização de
enunciados do que as outras classes de alunos. Além disso, também foi mensurado o progresso dos
alunos nos níveis da taxonomia de Bloom, assumindo que a utilização do jogo ou de enunciados
melhor contextualizados poderia fazer com que os alunos acertassem mais questões classificadas
nos níveis superiores da taxonomia.
Com as análises realizadas nesta pesquisa não foi possível afirmar que enunciados mais
contextualizados melhoraram a aprendizagem de desvios condicionais, loops ou arrays. Nenhuma
evidência estatisticamente significativa que permitisse a aceitação da hipótese 1 mencionada
anteriormente foi encontrada nos dados analisados. Também não foi possível afirmar que o uso do
jogo (nível mais alto de contextualização) promoveu melhores resultados para a aprendizagem do
que a utilização de um nível intermediário de contextualização. A análise dos dados permitiu
116
concluir que, ao menos no contexto em que esta pesquisa foi realizada, as mudanças no nível de
contextualização não produziram nenhum efeito significativo na aprendizagem, já que os grupos
experimentais apresentaram um desempenho médio equivalente ao grupo de controle.
Entretanto, surgiram alguns indícios que merecem ser ressaltados, ainda que nenhum deles
tenha sido comprovado estatisticamente. Os alunos que participaram dos experimentos foram
classificados como com dificuldades, medianos ou ótimos. Quando se analisou a transição dos
alunos entre estas classes o percentual daqueles que progrediram foi ligeiramente maior no caso do
grupo que utilizou o jogo. Além disso, todas as 3 turmas iniciaram com aproximadamente o mesmo
percentual de alunos com dificuldades, e somente a turma que utilizou o jogo acabou os
experimentos sem nenhum aluno classificado desta forma. Isto sugere que os alunos com
dificuldades podem ter se beneficiado um pouco mais da utilização do jogo do que as outras classes
de alunos. Entretanto, é importante ressaltar que nenhuma evidência significativa que apóie esta
sugestão foi encontrada.
A análise do progresso dos alunos nos níveis da taxonomia de Bloom revelou alguns
indicadores que merecem alguma discussão. O grupo que utilizou o jogo apresentou um progresso
superior aos outros dois grupos no nível Aplicar da taxonomia, acertando 42,2% a mais de questões
no pós-teste. Além disso, o grupo experimental 2 (nível intermediário de contextualização)
apresentou um desempenho ligeiramente melhor que os demais grupos no nível Analisar da
taxonomia. Estas informações sugerem que níveis de contextualização mais altos promovem
ascensão aos níveis superiores da taxonomia de Bloom, e que a utilização do jogo, em particular,
estaria favorecendo a Aplicação do conhecimento adquirido. Novamente ressalta-se que nenhuma
evidência estatisticamente significativa sobre estas melhorias foi encontrada nas análises realizadas.
Através dos resultados alcançados nesta pesquisa pode-se finalmente responder as questões
problema inicialmente levantadas. A primeira questão era: Como a utilização de um jogo de
computador focado na resolução de problemas algorítmicos influencia a aprendizagem de
programação introdutória? As evidências encontradas mostram que um jogo não produziu
qualquer efeito significativo na aprendizagem de programação introdutória, seja este efeito positivo
ou negativo. Ou seja, os alunos que jogaram não progrediram e nem regrediram mais do que os que
não jogaram, pois tiveram o mesmo desempenho quando comparados entre si. Nesta pesquisa
investigou-se apenas o efeito do jogo sobre a aprendizagem, pois se considerou como certa a
influência do jogo sobre a motivação. Sendo assim, se ao jogar os alunos aprendem tanto quanto
117
aprenderiam com outras estratégias mais tradicionais, mas o fazem com mais motivação, então
podemos considerar os jogos como ferramentas didáticas úteis.
Outro aspecto que não se pode deixar de considerar é a própria qualidade do jogo que foi
utilizado nos experimentos desta pesquisa e a sua influência nos resultados obtidos. Partiu-se do
pressuposto que o fato dos problemas algorítmicos estarem sendo resolvidos dentro de um jogo,
onde os alunos poderiam competir entre si para resolver mais problemas em menos tempo, seria
suficiente para criar um contexto mais concreto para a resolução de tais problemas. Quando
comparado com os jogos utilizados pelos alunos cotidianamente (os jogos da indústria do
entretenimento) o jogo utilizado nesta pesquisa é bastante simples. É possível que um jogo que se
assemelhe mais com aqueles que os alunos jogam para se divertirem produza outros (e
possivelmente melhores) resultados na aprendizagem e na motivação.
A segunda questão que se buscou responder nesta pesquisa foi: Um jogo promove melhorias
na aprendizagem ou este mesmo resultado pode ser alcançado apenas com a utilização de
problemas de programação melhor contextualizados? Para que esta pergunta fosse respondida
afirmativamente o desempenho das turmas deveria ser o seguinte: o grupo experimental que
trabalhou com o nível intermediário de contextualização (grupo experimental 2) teria um
desempenho melhor que o grupo de controle; e o grupo experimental que trabalhou com o nível
mais alto de contextualização (o jogo) teria um desempenho maior que o grupo experimental 2. Ou
seja, se estes resultados fossem confirmados então se poderia dizer que quanto maior o nível de
contextualização maior seria o efeito observado na aprendizagem dos alunos. Os resultados obtidos
indicaram que o nível de contextualização dos enunciados não produziu efeito significativo sobre a
aprendizagem, e que os alunos que utilizaram descrições abstratas dos problemas (grupo de
controle) aprenderam tanto quanto aqueles que resolveram os mesmos problemas dentro de
situações supostamente mais concretas. Algumas limitações do experimento relacionadas com estes
aspectos são discutidas mais adiante.
Todos os objetivos específicos planejados para esta pesquisa foram alcançados. A
linguagem de programação não-textual foi implementada e utilizada pelos alunos durante os
experimentos. Além da linguagem de programação também foi desenvolvido um mecanismo de
correção automática para pequenos programas utilizando uma métrica híbrida, baseada na
verificação sintática, verificação estrutural, verificação das saídas geradas e a verificação da
presença de estruturas obrigatórias. Três softwares foram implementados fazendo uso dos recursos
118
descritos anteriormente e contendo um mesmo conjunto de desafios algorítmicos. Em cada software
mudou-se o nível de contextualização dos desafios, e no nível mais alto implementou-se um jogo.
Um instrumento de avaliação foi elaborado para ser aplicado no pré e pós-teste de cada experimento
com os alunos (ver Apêndice B). Por fim, todos estes artefatos produzidos foram utilizados nos três
experimentos realizados, o que permitiu a obtenção dos resultados apresentados nesta pesquisa.
Certamente os resultados obtidos não são definitivos e são passíveis de discussão. Sendo
assim, a seguir são discutidas a validade interna e externa dos experimentos realizados. Os tipos de
ameaças discutidos a seguir são baseados no trabalho de Wainer (2007).
6.1 AMEAÇAS A VALIDADE INTERNA
De acordo com Wainer (2007), a validade interna é uma medida da confiança que se tem de
que a experimentação realizada realmente produziu o efeito observado, e que este efeito não tenha
sido produzido por outros fatores externos a experimentação. Qualquer explicação alternativa para
explicar o efeito observado é considerada como uma ameaça à validade interna, pois coloca em
dúvida a causa do efeito observado.
Ameaças de Instrumentação
Estas ameaças são caracterizadas por problemas relacionados com as mensurações
realizadas, e neste trabalho existem alguns problemas desta natureza que merecem ser discutidos.
Este trabalho partiu do pressuposto de que os problemas algorítmicos eram exatamente os mesmos
em cada um dos experimentos com as diferentes turmas, e que apenas o nível de contextualização
estava variando entre os experimentos. Retirar o contexto de um problema algorítmico sem
transformá-lo em outro problema não é um processo simples, e é possível que as versões de alguns
dos problemas algorítmicos utilizados nos experimentos tenham se tornado suficientemente
diferentes entre si, e que as três versões de cada problema tenham se tornado três problemas
diferentes.
O instrumento de avaliação que foi utilizado nos pré e pós-testes desta pesquisa contém 10
questões de múltipla escolha, onde cada uma das questões foi classificada segundo a taxonomia de
Bloom revisada. Durante a aplicação deste instrumento verificou-se que estava um tanto longo, a
ponto de causar fadiga nos alunos e levar alguns alunos a responder as últimas questões de forma
119
aleatória apenas para terminar o teste rapidamente. Se muitos alunos “chutaram” suas respostas (e
não há como saber quantos deles fizeram isto) então existe a possibilidade de que alguns acertaram
sem realmente saber, e de que outros erraram quando sabiam o suficiente para não errar.
Ameaça de Testagem
Este tipo de ameaça diz respeito às situações onde os alunos aprendem com os próprios
testes. Ou seja, o desempenho em um pós-teste seria em parte reflexo da aprendizagem ocorrida no
pré-teste. Esta ameaça pode ser considerada como inexistente nesta pesquisa por dois motivos.
Primeiro, o tempo decorrido entre o pré e o pós-teste foi de aproximadamente 13 semanas, o que
pode se considerar como tempo suficiente para evitar que os alunos aprendam com o pré-teste.
Além disso, nenhuma correção sobre os erros do pré-teste foi realizada com os alunos, que nem
mesmo souberam quantas questões acertaram no momento do pré-teste. Esta informação só foi
revelada aos alunos após o pós-teste. Em segundo lugar, mesmo que se considere que os alunos
aprenderam com o pré-teste, esta premissa deveria valer para todas as turmas, já que o mesmo
delineamento experimental foi utilizado em todas as situações. Ou seja, se uma turma aprendeu com
o pré-teste então as outras turmas também o fizeram, e a comparação do desempenho das turmas
entre si ainda continuaria justa. Ou seja, o que garante a validade da comparação neste caso é a
presença do grupo de controle, a base para todas as comparações e que elimina a ameaça de
testagem.
Ameaça de Maturação
Esta ameaça está relacionada com o fato de que os alunos amadurecem com o tempo,
independentemente dos experimentos realizados. Como houve bastante tempo entre o pré e o pós-
teste (aproximadamente 13 semanas) certamente houve tempo para que os alunos naturalmente
amadurecessem. Entretanto, a utilização de um grupo de controle e o fato de se ter utilizado o
mesmo período de tempo entre pré-teste, intervenção e pós teste para todas as turmas elimina este
tipo de ameaça, já que assim como os grupos experimentais o grupo de controle também
amadureceu.
120
Ameaça de História
Este tipo de ameaça se caracteriza pelo acontecimento de algum evento durante o período de
experimentação que possa modificar o efeito observado, como por exemplo, aulas extras para uma
das turmas. Os eventos que aconteceram entre os pré e pós-testes desta pesquisa acontecem
normalmente nas disciplinas de Algoritmos e Programação na instituição onde foram realizados os
experimentos (UNIVALI), tais como aulas, exercícios, avaliações, entre outros. Nenhum evento
especial aconteceu durante os experimentos que possa ser considerado como ameaça.
Ameaça de Mortalidade Seletiva
Este tipo de mortalidade se caracteriza quando uma das amostras possui maior propensão
para abandonar o experimento. Nesta pesquisa houve um problema bastante sério de abandono de
participantes dado o alto índice de evasão nas primeiras fases dos cursos de Ciência da
Computação. Além disso, como já discutido neste trabalho, ao final dos experimentos cada turma
continha apenas os alunos “sobreviventes”. Entretanto, isto aconteceu em todas as 3 turmas, pois
todas passaram pelos mesmos problemas de evasão, reprovação e abandono. Sendo assim, esta
ameaça pode ser considerada como inexistente nesta pesquisa, pois certamente houve muita
mortalidade, mas não foi seletiva.
Ameaça de Seleção
Este tipo de ameaça é preocupante quando grupos com características desejáveis são
deliberadamente escolhidos para participar de situações que se acredita levarem aos resultados
desejados. Esta pesquisa foi realizada com 3 turmas de alunos. O grupo de controle realizou os
experimentos no segundo semestre de 2009. No primeiro semestre de 2010 os dois grupos
experimentais realizaram os experimentos, sendo que cada turma estava sob a tutela de um
professor diferente. Um destes professores era o orientador deste trabalho, e para evitar a ameaça
por seleção a turma de alunos dirigida pelo orientador deste trabalho não utilizou o jogo, mas sim o
software onde os enunciados possuíam um nível intermediário de contextualização. A turma de
alunos que utilizou o jogo foi dirigida por uma professora sem nenhuma ligação com este trabalho.
Na universidade onde foi realizado o experimento alguns professores consideram que as
turmas de verão (ingressam no início do ano por meio do vestibular) são um pouco melhores do que
as turmas de inverno (ingressam no meio do ano letivo). O grupo de controle desta pesquisa foi uma
121
turma de inverno e os dois grupos experimentais foram duas turmas de verão. Ou seja, o grupo de
controle era teoricamente a pior turma e utilizou o que se supunha como o pior software, aquele
onde os enunciados possuíam o nível mais baixo de contextualização. Ainda assim, nenhuma
diferença significativa foi observada entre o progresso médios das turmas, de maneira que não se
pode afirmar que existiu alguma diferença real entre turmas de verão e inverno.
Ameaça de Contaminação
Esta ameaça existe quando membros de um grupo repassam conhecimentos para membros
dos outros grupos participantes dos experimentos. Nesta pesquisa, um dos grupos experimentais
possuía um aluno repetente que havia participado do experimento no semestre anterior com o grupo
de controle. Este aluno pode ter passado informações para seus colegas e provocado alguma
contaminação. Além disso, como os experimentos com os dois grupos experimentais aconteceram
em paralelo no mesmo semestre é possível que os alunos tenham interagido entre si e ensinado uns
aos outros sobre coisas específicas dos experimentos. Se isto de fato aconteceu não foi suficiente
para fazer com que algum dos grupos experimentais obtivesse desempenho significativamente
melhor que o grupo de controle.
Ameaça de Comportamento Competitivo
Este tipo de ameaça deve ser considerado quando um dos grupos entra em um “clima” de
competição com os demais grupos e por conta disto se aplica mais nos estudos, o que pode provocar
melhores resultados não pelas intervenções realizadas, mas sim por causa da motivação extra
causada pela competição. Os dois grupos experimentais realizaram os experimentos em paralelo, e é
possível que alguns alunos realmente tenham entrado no “clima” de competição mencionado
anteriormente. Porém, o grupo de controle realizou o experimento um semestre antes dos grupos
experimentais, o que diminuiu muito as chances de competição entre os grupos experimentais e o
grupo de controle.
Ameaça de Comportamento Compensatório
Esta ameaça acontece quando por algum motivo medidas compensatórias são aplicadas a
uma das amostras. Por exemplo, um dos professores poderia aplicar exercícios relacionados
122
especialmente com o tipo de problemas que seriam resolvidos nos testes para melhorar o
desempenho da sua turma. Nenhuma compensação deste tipo foi realizada com as turmas.
Ameaça de Expectativa do Sujeito
Esta ameaça torna-se preocupante quando o sujeito sabe que está sendo avaliado e em
conseqüência disto altera a sua performance. Nesta pesquisa o mesmo protocolo foi utilizado com
todas as 3 turmas de alunos, e todas foram comunicadas que estavam participando de um
experimento sobre aprendizagem de algoritmos. Apesar de não conhecerem maiores detalhes sobre
os experimentos os alunos sabiam que estavam participando deles, o que realmente poderia
provocar alguma “expectativa”. Entretanto, como o mesmo protocolo foi utilizado com todas as
turmas esta “expectativa” também estaria presente em todas as turmas, incluindo o grupo de
controle, a base para as comparações realizadas.
Ameaça de Expectativa do Experimentador
Esta ameaça torna-se problemática quando o interesse do experimentador causa algum viés
nos resultados. Durante os experimentos com os alunos os professores das disciplinas e o autor
deste trabalho estavam presentes nos locais de realização das tarefas. Entretanto, a turma que
apresentou um desempenho ligeiramente melhor nos experimentos foi justamente a turma que
estava sob a direção de uma professora desconhecedora das hipóteses de pesquisa deste trabalho.
Ou seja, se a expectativa dos experimentadores provocou algum efeito este não foi suficiente para
fazer com que os grupos experimentais apresentassem melhor desempenho do que o grupo de
controle.
6.2 AMEAÇAS A VALIDADE EXTERNA
A validade externa diz respeito às possibilidades de generalização dos resultados, e este é
possivelmente o aspecto mais problemático desta pesquisa e também de todas as que se assemelham
a esta. Não se pode generalizar os resultados obtidos neste trabalho para quaisquer outros jogos,
pois os resultados aplicam-se somente ao jogo que foi utilizado, nas condições em que foi utilizado.
A utilização do mesmo jogo em situações um pouco diferentes já poderia gerar outros resultados.
Por exemplo, é possível que se o mesmo jogo for utilizado durante todo o semestre, como uma
123
ferramenta integrada com um número maior de aulas dos professores, os resultados apontem em
outras direções.
Também não se pode generalizar a idéia de que níveis de contextualização mais altos não
melhoram a aprendizagem. O que se pode afirmar é que: da forma como se tratou os diferentes
níveis de contextualização nesta pesquisa nenhum efeito significativo foi observado na
aprendizagem de loops, arrays e desvios condicionais. Este resultado não deve ser generalizado em
hipótese alguma, pois é possível (e é uma crença do autor deste trabalho) que em outros contextos,
com outras ferramentas e outras metodologias, a contextualização produza resultados positivos na
aprendizagem.
6.3 CONTRIBUIÇÕES DA DISSERTAÇÃO
O instrumento de avaliação elaborado para os pré e pós-testes desta pesquisa é uma das
principais contribuições do trabalho. A elaboração deste tipo de instrumento não é uma tarefa
trivial, e a apresentação de todos os detalhes do instrumento no Apêndice B permitirá que outros
pesquisadores utilizem e aperfeiçoem-no, já que este instrumento também é baseado no trabalho de
dois outros grupos de pesquisadores (Whalley et al (2006) e Lister et al (2004)). Até o momento da
produção deste texto publicou-se um artigo sobre este instrumento de avaliação (JESUS e RAABE,
2009) e o mesmo foi reutilizado na pesquisa de Motta (2010).
A linguagem de programação construída para a realização dos experimentos (Escracho)
também é por si só uma contribuição, pois trata-se de uma ferramenta que pode facilitar um
primeiro contato com os aspectos da programação, eliminando muitos dos problemas relacionados à
sintaxe e permitindo que os alunos foquem na resolução de problemas.
O mecanismo de correção automática de programas também é um subproduto deste
trabalho. A métrica de avaliação hibrida que foi utilizada – verificação de sintaxe, verificação
estrutural, verificação de saídas e estruturas obrigatórias - pode ser reaproveitada em outros
trabalhos, especialmente naqueles com interesse em avaliar pequenos programas, o que é o caso dos
exercícios de programação em disciplinas introdutórias.
A contribuição mais significativa deste trabalho está relacionada aos aspectos da realização
dos experimentos. Os procedimentos metodológicos utilizados neste trabalho podem ser utilizados
124
como base para outras pesquisas onde se queira mensurar quantitativamente o impacto de um
artefato qualquer na aprendizagem. Espera-se que este trabalho sirva de referência para outras
pesquisas no sentido da importância e necessidade de experimentação (especialmente utilizando
grupos de controle), que apesar de complexa e laboriosa consiste em um caminho seguro (ou quase)
para o entendimento dos fenômenos que nos cercam, incluindo aí este fenômeno chamado
aprendizagem.
6.4 TRABALHOS FUTUROS
O principal trabalho futuro desta pesquisa é a replicação dos experimentos com um número
maior de alunos, pois é possível que com amostras maiores as pequenas diferenças que foram
encontradas na análise dos dados coletados tornem-se estatisticamente significativas.
A linguagem de programação construída para a realização dos experimentos (Escracho) –
não foi avaliada isoladamente quanto ao seu potencial pedagógico. Nesta pesquisa a linguagem
Escracho foi utilizada em todos os experimentos, de maneira que não há como identificar quanto do
desempenho dos alunos deve-se especificamente às facilidades oferecidas pela linguagem. Um
experimento onde um grupo de alunos usa Escracho por todo o semestre e outro grupo não usa
(grupo de controle) poderia mostrar a contribuição da linguagem na aprendizagem de programação.
Outra possibilidade de trabalho futuro relacionado com a linguagem Escracho seria utilizá-la para
permitir a criação de jogos.
O mecanismo de correção de programas desenvolvido nesta pesquisa também abre
possibilidades para trabalhos futuros. Da maneira como o mecanismo está implementado ele
funciona localmente, ou seja, corrige no computador do aluno os programas que ele construiu. O
mesmo mecanismo poderia ser implementando como um WebService, e outros softwares poderiam
consumir o serviço de correção automática de programas. Por exemplo, um sistema de apoio à
aprendizagem de algoritmos poderia enviar ao WebService os dados necessários para a correção do
algoritmo. O WebService responderia dizendo se o algoritmo é considerado correto ou não, e
possivelmente retornaria também uma lista de erros encontrados no caso de algoritmos incorretos.
Para viabilizar esta arquitetura de correção automática de algoritmos seria necessário a definição de
padrões para troca de informações entre os softwares consumidores do serviço e o WebService. O
WebService poderia receber apenas um arquivo XML contendo os dados serializados da árvore
sintática abstrata que representa o programa que deve ser corrigido, algo semelhante ao que foi
125
utilizado neste trabalho. Com isto, o serviço de correção automática se tornaria independente de
linguagem de programação, uma vez que apenas a estrutura serializada da árvore sintática abstrata
interessaria para a verificação do programa. Neste caso seria necessária uma ferramenta capaz de
transformar algoritmos escritos em diversas linguagens para uma representação em árvore sintática
abstrata, e converter esta árvore em uma string onde cada nó fosse representado de forma exclusiva,
de acordo com o tipo de nó, o que também abre espaço para alguma pesquisa.
O jogo que foi implementado para a realização dos experimentos nesta pesquisa poderia ser
melhorado no que se refere ao feedback oferecido aos alunos. Durante a resolução dos desafios do
jogo os alunos devem alterar algumas variáveis que estão relacionadas com o robô protagonista do
jogo. Entretanto, se o aluno constrói um algoritmo que, por exemplo, movimenta o robô e executa o
seu algoritmo passo a passo, não é possível observar o efeito da alteração das variáveis relacionadas
ao robô no mundo virtual do jogo. Ou seja, as variáveis têm seus valores alterados mas isso não se
reflete nos objetos do mundo do jogo. É possível que este tipo de feedback possa melhorar a
aprendizagem de algoritmos, já que os alunos poderiam visualizar em tempo real o efeito causado
pela combinação de instruções dos seus algoritmos. Por outro lado, este feedback imediato também
poderia incentivar um comportamento de tentativa e erro, já que os erros seriam rapidamente
visualizados, por exemplo, pelo comportamento errático do robô no mundo do jogo. Um
experimento entre Jogo sem feedback e Jogo com feedback poderia ser realizado, onde o jogo sem o
feedback seria utilizado por um grupo de controle.
Outro trabalho futuro consiste em avaliar a influência da utilização do jogo nos semestres
subseqüentes, ou seja, avaliar como os alunos que jogaram no primeiro semestre se comportam nas
disciplinas seguintes (programação, estruturas de dados, etc.) em comparação com alunos que não
jogaram.
Esta pesquisa foi realizada com um foco exclusivamente quantitativo. Se por um lado este
tipo de pesquisa oferece um rigor metodológico aos moldes das ciências naturais, por outro, os
resultados tornam-se um tanto frios e quase que desprovidos de alguma humanidade. O que se quer
dizer com isto é que ao final da pesquisa tornou-se evidente que os números não nos contam tudo.
Em uma pesquisa como a que foi realizada neste trabalho certamente existem aspectos qualitativos
que podem enriquecer os resultados obtidos, desde que a pesquisa qualitativa também seja feita com
o devido rigor científico. Um trabalho futuro poderia incluir a opinião de professores e alunos sobre
a utilização do jogo, agregando aspectos qualitativos aos resultados já apresentados neste trabalho.
126
REFERÊNCIAS
ALA-MUTKA, Kirst; UIMONEN, Toni; JÄRVINEN, Hannu-Matti. Supporting students in C++ programming courses with automatic program style assessment. Journal of Information Technology Education, USA, v. 3, p. 245-262, 2004.
BAKER, Brenda S. A Program for Identifying Duplicated Code. Computing Science and Statistics, 24, p. 49-57, 1992.
BARRY, S. Fagin; MERKLE, Laurence. Quantitative analysis of the effects of robots on introductory computer science education. In: ACM Journal of Educational Resources in Computing, junho, 2002.
BARNES, Tiffany et al. Game2Learn: building CS1 learning games for retention. In: ANNUAL SIGCSE CONFERENCE ON INNOVATION AND TECHNOLOGY IN COMPUTER SCIENCE EDUCATION, 12., 2007, Dundee, Scotland. Proceedings… New York:ACM, 2007. p. 121-125.
BAYLISS, Jessica D. The Effects of Games in CS1-3, In: MICROSOFT ACADEMIC DAYS CONFERENCE ON GAME DEVELOPMENT IN COMPUTER SCIENCE EDUCATION, 2., 2007. Proceedings… 2007. p. 59-63.
______. Using games in introductory courses: tips from the trenches. In: ACM TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, 40., 2009, Chattanooga, USA. Proceedings… New York:ACM, 2009. p. 337-341.
BAXTER, Ira D. et al. Clone Detection Using Abstract Syntax Trees. In: INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE, 1998. Proceedings… Washington:IEEE Computer Society, 1998. p. 368.
BEAUBOUEF, Theresa; MASON, John. Why the high attrition rate for computer science students: some thoughts and observations. In: ACM SIGCSE Bulletin, USA, v. 37, n. 2, p. 103-106, jun. 2005.
BECKER, Katrin; PARKER, J. R. All I ever needed to know about programming, I learned from re-writing classic arcade games. In: FUTURE PLAY, THE INTERNATIONAL CONFERENCE ON THE FUTURE OF GAME DESIGN AND TECHNOLOGY, 2005, East Lansing, Michigan, USA. Proceedings... 2005.
127
BERCHT, Magda.; FERREIRA, Luis de França.; SILVEIRA, Sidnei Renato. Aprendendo a construir algoritmos através da mediação digital. Revista Novas Tecnologias na Educação, Porto Alegre, v. 3, n. 1, 2005.
BIERRE, Kevin et al. Motivating OOP by blowing things up: an exercise in cooperation and competition in an introductory java programming course. In: SIGCSE TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, 37. 2006, Houston, Texas, USA. Proceedings... New York:ACM, mar. 2006. p. 354-358.
BIERRE, Kevin J.; PHELPS, Andrew M. The use of MUPPETS in an introductory java programming course. In: CONFERENCE ON INFORMATION TECHNOLOGY EDUCATION, 5., 2004, Salt Lake City, UT, USA. Proceedings... New York:ACM, 2004. p. 122-127.
BLUMENSTEIN, Michael et al. An experimental analysis of GAME: a generic automated marking environment. In: ANNUAL SIGCSE CONFERENCE ON INNOVATION AND TECHNOLOGY IN COMPUTER SCIENCE EDUCATION, 9., Leeds, UK. Proceedings… USA:ACM Press, 2004. p. 67–71.
BROWN, Peter H. Some field experience with Alice. Journal of Computing Sciences in Colleges, USA, v. 24, n. 2, p. 213-219, dez. 2008.
CHALK, Bernard; FRASER, Karen. A Survey on the teaching of introductory programming in Higher Education. In: JICC10 ANNUAL CONFERENCE, 10., 2006, London Metropolitan University. Proceedings… 2006.
CLIBURN, Daniel C. The effectiveness of games as assignments in an introductory programming course. In: ANNUAL ASEE/IEEE FRONTIERS IN EDUCATION CONFERENCE, 36. 2006, San Diego, California, USA. Proceedings… USA:IEE, 2006. p. 6–10.
CLIBURN, Daniel C.; MILLER, Susan M. What makes a "good" game programming assignment? Journal of Computing Sciences in Colleges archive, v. 23, n. 4, p. 201-207 , apr. 2008.
CLUA, Esteban Walter Gonzalez. A Game Oriented Approach for Teaching Computer Science. In: CONGRESSO DA SBC – WEI – WORKSHOP SOBRE EDUCAÇÃO EM COMPUTAÇÃO, 18., Belém do Pará, Pará. Anais... 2008.
128
CRISTÓVÃO, Henrique Monteiro. Aprendizagem de Algoritmos num Contexto Significativo e Motivador: um relato de experiência. In: CONGRESSO DA SBC – WEI – WORKSHOP SOBRE EDUCAÇÃO EM COMPUTAÇÃO, 18., Belém do Pará, Pará. Anais... 2008.
CURREL, Graham; DOWMAN, Antony. Essential Mathematics and Statistics for Science. John Wiley & Sons, 2009.
DALE, Nell B. Most difficult topics in CS1: results of an online survey of educators. ACM SIGCSE Bulletin, USA, v. 38, n.2, p. 49-53, jun. 2006.
DALY, Charlie; HORGAN, Jane M. An automated learning system for Java programming. IEEE Transactions on Education, USA, p. 10-17, feb. 2004.
DERSHEM, Herbert L. Problem related to card games for an introductory programming course. SIGCSE Bulletin, USA, v. 2, n. 5, p. 48-49, 1970.
DiSALVO, Betsy James; BRUCKMAN, Amy. Questioning video games’ influence on CS intereset. In: INTERNATIONAL CONFERENCE ON THE FOUNDATIONS OF DIGITAL GAMES, 4., Orlando, Flórida. Proceedings… USA:ACM, 2009. p. 272-278.
DOUCE, Christopher; LIVINGSTONE, David; ORWELL, James. Automatic test-based assessment of programming: a review. Journal on Educational Resources in Computing (JERIC), USA, v. 5, n. 3, p. 4-es, sep. 2005.
EAGLE, Michael; BARNES, Tiffany. Wu's castle: teaching arrays and loops in a game. In: ANNUAL CONFERENCE ON INNOVATION AND TECHNOLOGY IN COMPUTER SCIENCE EDUCATION, 13., Madrid, Spain. Proceedings… USA:ACM, 2008. p. 245-249.
EAGLE, Michael; BARNES, Tiffany. Experimental Evaluation of an Educational Game for Improved Learning in Introductory Computing. In: TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, 40., Chattanooga, USA. Proceedings… USA: ACM, 2009. p. 321-325.
ESTEVES, Micaela; MENDES, António. OOP-Anim, a system to support learning of basic object oriented programming concepts. In: COMPSYSTECH' 2003 - INTERNATIONAL CONFERENCE ON COMPUTER SYSTEMS AND TECHNOLOGIES, Sofia, Bulgaria. Proceedings… USA:ACM, 2003. p. 573-579.
129
FELDGEN, Maria; CLÚA, Osvaldo. Games as a motivation for freshman students learn programming. In: ASEE/IEEE FRONTIERS IN EDUCATION, 34., Savannah, GA. Proceedings... 2004. p. S1H11-S1H16.
FOREHAND, Mary. Bloom's taxonomy. Disponível em: <http://www.coe.uga.edu/epltt/bloom.htm>. Acesso em: 12 maio, 2009.
FULLER, Ursula et. al. Developing a Computer Science-Specific Learning Taxonomy. SIGCSE Bulletin, USA, v. 39, n. 4, p. 152-170, dez. 2007.
GAL-EZER Judith; VILNER, Tamar; ZUR, Ela. Has the paradigm shift in CS1 a harmful effect on data structures courses: a case study. In: ACM TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, 40., Chattanooga, USA. Proceedings… USA:ACM, 2009. p. 126-130.
GAMMA, E. et al. Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos. Porto Alegre: Bookman, 2000.
GIL, Antonio Carlos. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.
GILLELAND, Michael. Levenshtein Distance, in Three Flavors. Disponível em: <http://www.merriampark.com/ld.htm>. Acesso em: 16 jun. 2009.
GÓMEZ-MARTIN, Marco A.; GÓMEZ-MARTIN, Pedro P.; GONZÁLEZ-CALERO, Pedro A. Game-driven intelligent tutoring systems. In: ENTERTAINMENT COMPUTING - ICEC 2004, 3. Eindhoven, Netherlands. Proceedings… Heidelberg:Springer Berlin, 2004. p. 108-113.
HERNÁN-LOSADA, Isidoro; PAREJA-FLORES, Cristóbal; VELÁZQUEZ-ITURBIDE, J. Ángel. Testing-Based Automatic Grading: a proposal from Bloom's taxonomy. In: IEEE INTERNATIONAL CONFERENCE ON ADVANCED LEARNING TECHNOLOGIES, 8. Proceedings… USA:EEE Computer Society, jul. 2008. p. 847-849.
HOWARD, Elizabeth et al. A Qualitative Look at Alice and Pair-Programming. In: ANNUAL INFORMATION SYSTEMS EDUCATION CONFERENCE - ISECON, 21., Newport, Rhode Island. Proceedings… 2004.
130
JESUS, Elieser Ademir de; RAABE, André L. Alice. Interpretações da Taxonomia de Bloom no Contexto da Programação Introdutória. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 20., Florianópolis, Santa Catarina. Anais... 2009.
JOHNSON, Colin. G.; FULLER, Ursula. Is Bloom's taxonomy appropriate for computer science? In: BALTIC SEA CONFERENCE ON COMPUTING EDUCATION, 6., Uppsala, Sweden. Proceedings... USA:ACM, nov. 2007. p. 120-123.
KINNUNEN, Päivi; MALMI, Lauri. Why students drop out CS1 course? In: INTERNATIONAL WORKSHOP ON COMPUTING EDUCATION RESEARCH, Canterbury, UK. Proceedings... USA:ACM, set. 2006. p. 97-108.
KÖLLING, Michael et al; The BlueJ system and its pedagogy. Journal of Computer Science Education, Special issue on Learning and Teaching Object Technology, USA, v. 13, n. 4, p. 249-268, 2003.
KRATHWOHL, David R. A revision of bloom's taxonomy: an overview. Theory into Practice, n. 41, v. 4, p. 212-218, 2002.
LAHTINEN, Essi; ALA-MUTKA Kisrt; JÄRVINEN, Hannu-Matti. A study of the difficulties of novice programmers. In: ANNUAL SIGCSE CONFERENCE ON INNOVATION AND TECHNOLOGY IN COMPUTER SCIENCE EDUCATION, 10., Caparica, Portugal. Proceedings… USA:ACM, 2005. p. 14-18.
LARSON, R.; FARBER, E. Estatística aplicada. 2. ed. São paulo: Prentice Hall, 2004.
LISTER, Raymond et al. A multi-national study of reading and tracing skills in novice programmers. ACM SIGCSE Bulletin, USA, v. 36, n. 4, p. 119-150, dez. 2004.
LISTER, Raymond et al. Research perspectives on the objects-early debate. ACM SIGCSE Bulletin, USA, v. 38, n. 4, p. 146-165, dez. 2006.
LONG, Ju. Just For Fun: using programming games in software programming training and education. Journal of Information Technology Education, USA, v. 6, p. 279-290, 2007.
131
MALAN, David J.; LEITNER, Henry H. Scratch for budding computer scientists. In: SIGCSE TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, 38., Covington, Kentucky, USA. Proceedings… USA:ACM, mar. 2007. p. 223-227.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Fundamentos de Metodologia Científica. 3. ed. São Paulo: Atlas, 2000.
McCRACKEN, Michael et al.A Multi-National, Multi- Institutional Study of Assessment of Programming Skills of First-year CS Students. SIGCSE Bulletin, USA, n. 33, v. 4, p. 125-140, 2001.
MITCHELL, Alice; SAVILL-SMITH, Carol. The use of computer and video games for learning: a review of the literature. London: Learning and Skills Development Agency, 2004.
MILISZEWSKA, Iwona; TAN, Grace. Befriending Computer Programming: A Proposed Approach to Teaching Introductory Programming. Issues in Informing Science and Information Technology, USA, v. 4, n. 1, p. 278-289, 2007.
MOSER, Robert; A fantasy adventure game as a learning environment: why learning to program is so difficult and what can be done about it. ACM SIGCSE Bulletin, USA, v. 29, n. 3, p. 114-116, jun. 1997.
MOTA, Marcelle. P. Ambiente de Aprendizagem de Programação com Visualização e Avaliação Automática de Programas. 2010. 84 f. Dissertação de Mestrado - Universidade Federal do Pará, Pará, PA, 2010.
MOTA, Marcelle Pereira; PEREIRA, Lis W. Kanashiro; FAVERO, Eloi Luiz Fávero. JavaTool: uma ferramenta para o ensino de programação. In: CONGRESSO DA SBC – EWI – WORKSHOP SOBRE EDUCAÇÃO EM COMPUTAÇÃO, 28. Belém do Pará, Pará. Anais… 2008.
NAVARRO, Gonzalo. A guided tour to approximate string matching. ACM Computing Surveys (CSUR), USA, v. 33, n. 1, p. 31-88, mar. 2001.
NEVISON, Chris; WELLS, Barbara. Using a maze case study to teach: object-oriented programming and design patterns. In: CONFERENCE ON AUSTRALASIAN COMPUTING EDUCATION, 6., Dunedin, New Zealand. Proceedings… Darlinghurst:Australian Computer Society, 2004. p. 207-215.
132
PEARS, Arnold et al. A survey of literature on the teaching of introductory programming. ACM SIGCSE Bulletin, USA, v. 39, n. 4, p. 204–223, 2007.
POWERS, Kris; ECOTT, Stacey; HIRSHFIELD, Leanne. Through the Looking Glass: teaching CS0 with Alice. ACM SIGCSE Bulletin, USA, v. 30, n. 1, p. 213-217, 2007.
PRENSKY, Marc. Digital game-based learning. Computers in Entertainment (CIE), USA, v. 1, n. 1, p. 21-25, out. 2003.
RAABE, André L. A.; SILVA, Júlia M. Carvalho da. Um ambiente para atendimento as dificuldades de aprendizagem de algoritmos. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 25., São Leopoldo, Rio Grande do Sul. Anais... RS:SBC, 2005.
RAABE, André Luis Alice; DAZZI, Rudimar L. Scaranto.; SANTIAGO, Rafael. Adquirindo experiência na construção de ferramentas de apoio a aprendizagem de algoritmos. In: WORKSHOP DE AMBIENTES DE APOIO A APRENDIZAGEM DE ALGORITMOS E PROGRAMAÇÃO - SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 18., São Paulo. Anais... SP:SBC, 2007.
RAHMAN, Khirulnizam A.; NORDIN, Md. Jan. A Review on the Static Analysis Approach in the Automated Programming Assessment Systems. In: NATIONAL CONFERENCE ON PROGRAMMING 07, Kuala Lumpur, Malaysia. Proceedings… dez. 2007.
REGES, Stuart. Back to basics in CS1 and CS2. In: SIGCSE TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, Houston, 37., Texas, USA. Proceedings… USA:ACM, mar. 2006. p. 293-297.
RISTAD, Eric Sven; YIANILOS, Peter N. Learning string edit distance. IEEE Transactions on Pattern Analysis and Machine Intelligence, USA, v. 20, n. 5, p. 522-532, 1998.
ROBINS, Anthony; ROUNDTREE, Janet; ROUNDTREE, Nathan. Learning and Teaching Programming: a review and discussion. Computer Science Education, USA, v. 13, n. 2, p. 137–172, 2003.
SAIKKONEN, Riku; MALMI, Lauri; KORHONEN, Ari. Fully automatic assessment of programming exercises. ACM SIGCSE Bulletin, USA, v. 33, n. 3, p. 133-136, 2001.
133
SAGER, Tobias et al. Detecting similar Java classes using tree algorithms. In: INTERNATIONAL WORKSHOP ON MINING SOFTWARE REPOSITORIES, Shanghai, China. Proceedings… USA:ACM, 2006. p. 65-71.
SAJANIEMI, Jorma; KUITTINEN, Marja. From Procedures to Objects: what have we (not) done?. In: ANNUAL WORKSHOP OF PPIG (PSYCHOLOGY OF PROGRAMMING INTEREST GROUP), 19., Finland. Proceedings… July 2007.
SCHULTE, Carsten; BENNEDSEN, Jens. What do teachers teach in introductory programming? In: INTERNATIONAL WORKSHOP ON COMPUTING EDUCATION RESEARCH, Canterbury, United Kingdom. Proceedings… USA:ACM, sep. 2006. p. 17-28.
SCOTT, Terry. Bloom's taxonomy applied to testing in computer science classes. Journal of Computing Sciences in College, USA, v. 19, n. 1, p. 267-274, 2003.
SHEARD, Judy et al. Analysis of research into the teaching and learning of programming. In: INTERNATIONAL COMPUTING EDUCATION RESEARCH WORKSHOP, 5., 2009, Berkeley, USA. Proceedings… USA: ACM, 2009. p. 93-104.
SULEMAN, Hussein. Automatic marking with Sakai. In: ANNUAL RESEARCH CONFERENCE OF THE SOUTH AFRICAN INSTITUTE OF COMPUTER SCIENTISTS AND INFORMATION TECHNOLOGISTS ON IT RESEARCH IN DEVELOPING COUNTRIES: RIDING THE WAVE OF TECHNOLOGY, Wilderness, South Africa. Proceedings… USA:ACM, 2008. p. 229-236.
THOMPSON, Erool et al. Bloom’s taxonomy for CS assessment. In: AUSTRALASIAN COMPUTING EDUCATION CONFERENCE - ACE, 10., Wollongong, Australia. Proceedings… Darlinghurst: Australian Computer Society, jan. 2008. p. 155-161.
TRUONG, Nghi; ROE Paul; BANCROFT, Peter. Static analysis of students' Java programs. In: CONFERENCE ON AUSTRALASIAN COMPUTING EDUCATION, 6., Dunedin, New Zealand. Proceedings… Darlinghurst:Australian Computer Society, jan. 2004. p. 317-325.
VAHLDICK, Adilson. Uma experiência lúdica no ensino de programação orientada a objetos. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 19., Fortaleza, Ceará. Anais... CE:SBC, 2008.
VALENTINE, David W. Playing around in the CS curriculum: reversi as a teaching tool. Journal of Computing Sciences in Colleges, USA, v. 20, n.5, p. 214-222, may 2005.
134
VILNER, Tamar; ZUR, Ela; GAL-EZER Judith. Fundamental Concepts of CS1: procedural vs. object oriented paradigm - a case study. ACM SIGCSE Bulletin, USA, v. 39, n. 3, p. 171-175, 2007.
WAINER, J. Métodos de pesquisa quantitativa e qualitativa para a Ciência da computação. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 17. Rio de Janeiro, Rio de Janeiro. Anais…, SBC, 2007.
WHALLEY, Jacqueline L. et al. An Australasian Study of Reading and Comprehension Skills in Novice Programmers, using the Bloom and SOLO Taxonomies. In: AUSTRALASIAN COMPUTING EDUCATION CONFERENCE (ACE2006), 8., Hobart, Australia. Proceedings… Darlinghurs:Australian Computer Society, 2006. p. 243-252.
YUEN, Timothy T. Novices' knowledge construction of difficult concepts in CS1.ACM SIGCSE Bulletin, USA, v. 39, n. 4, p. 49-53, dez. 2007.
135
APÊNDICE A – DESAFIOS DO JOGO
Os desafios do jogo foram elaborados para abranger os tópicos que programação
introdutória que foram o foco desta pesquisa, a saber: os desvios condicionais, os arrays e os laços
de repetição (loops). Estes desafios acontecem dentro das salas da estação espacial onde o robô
programável está a deriva. A seguir são apresentados os detalhes e algumas telas dos desafios que
fizeram parte do jogo.
Desafio 1
Neste desafio o robô encontra-se preso em uma sala onde existem dois botões posicionados
nas paredes laterais (ver Figura 22). Quando um dos botões é pressionado a porta de saída da sala
abre-se pela metade. Para que a porta se abra completamente é necessário que ambos os botões
sejam pressionados. Este desafio exigirá que o jogador use um desvio condicional para testar se o
robô encostou em um botão (basta que o robô encoste no botão para que este seja acionado). Em
caso afirmativo, o robô deve virar-se para o lado onde está o outro botão, e então disparar a sua
arma. O tiro da arma irá acionar o segundo botão, abrindo a porta de saída completamente e
permitindo que o robô saia da sala.
Figura 22. Sala do desafio 1
136
Desafio 2
Neste desafio o robô coleta automaticamente um spray refrigerador a base de pó químico
logo que entra na sala. O gerador de energia da estação espacial está na sala e está superaquecido. É
necessário utilizar o spray refrigerador para resolver o problema e evitar que toda a estação espacial
fique sem o suprimento de energia. Entretanto, o gerador é sensível à quantidade de pó químico
borrifado sobre ele, e a quantidade de pó que deve ser utilizada depende da temperatura do gerador
superaquecido. O spray coletado pelo robô pode ser disparado apenas uma vez, mas o disparo pode
ser longo, médio ou curto. A quantidade de pó químico emitido pelo spray varia de acordo com a
duração de cada disparo. Quanto mais longo o disparo maior a quantidade de pó químico borrifado.
O jogador recebe as seguintes informações para a resolução do problema: a temperatura
normal do gerador é de 39 a 40 graus Celsius. Em hipótese alguma a temperatura pode ficar abaixo
de 39 graus. Os diferentes tempos de disparo do spray causam os seguintes efeitos na temperatura
do gerador:
• Disparo longo: diminui 5 graus na temperatura;
• Disparo médio: diminui 3 graus na temperatura; e
• Disparo curto: diminui 1 grau na temperatura.
Desafio 3
Neste desafio o robô está em uma sala onde existe um gerador de números inteiros aleatórios
e dois botões, um de cada lado do recinto. Estes botões estão interligados com o gerador de
números aleatórios. Se um número par é gerado somente o botão do lado direito da sala pode ser
ativado. Se o número aleatório gerado for ímpar então apenas o botão do lado esquerdo da sala pode
ser ativado. Se esta regra é observada a porta de saída da sala abre-se, caso contrário, ela permanece
fechada.
O algoritmo que resolve este problema deve usar um desvio condicional para verificar o
número aleatório gerado, decidir para que lado da sala virar o robô e então fazer com que ele atire.
Quando o tiro do robô acerta o botão correto a porta de saída da sala é desbloqueada.
137
Desafio 4
Cada um dos buracos no chão desta sala (Figura 23) pode estar coberto por uma plataforma
(o buraco no centro da sala, por exemplo) ou com um campo magnético desativado. Se o buraco
está fechado o robô deve se mover por cima da sua plataforma. Caso contrário, o campo magnético
que sai do buraco deve ser ativado, e isto fará com que o robô flutue por cima do buraco, empurrado
pelo magnetismo. Próximo a cada buraco existe um sensor de presença interligado ao botão que está
na lateral da sala. Quando o botão é acionado o campo magnético do buraco onde é detectada uma
presença próxima é ativado. Ao entrar na sala o robô não tem como saber se os buracos estão
abertos ou fechados, e o robô precisa de um algoritmo que verifique o estado de todos os 3 buracos.
Se um buraco está fechado basta caminhar sobre a sua plataforma. Caso contrário, é necessário
atirar no botão para ativar o campo magnético do buraco mais próximo, e neste caso o algoritmo
não deve fazer o robô andar automaticamente. Quando o robô ultrapassa o último sensor de
presença a porta de saída da sala é desbloqueada.
Figura 23. Robô em uma sala com buracos no chão
Desafio 5
Neste desafio o robô encontra-se em uma sala onde existem alguns interruptores de energia
(ver Figura 24). Houve uma pane no sistema de iluminação da estação espacial. O robô precisa
acionar um dos interruptores que estão na sala e reativar o sistema de iluminação. Entretanto, cada
interruptor ativa um subsistema de energia. Apenas um dos interruptores ativa todos os subsistemas
ao mesmo tempo, e este é o interruptor que deve ser acionado pelo robô. Sendo assim, o algoritmo
que resolve este problema deve encontrar qual interruptor fornece mais energia quando ativado.
138
Figura 24. Sala com interruptores de energia
Desafio 6
Este desafio é baseado no anterior. Entretanto, nesta sala existem duas fileiras de
interruptores de energia ao invés de apenas uma. Neste caso ambas as fileiras de interruptores
devem ser acionadas em seqüência. A cada interruptor acionado corretamente a porta de saída abre-
se um pouco mais. Entretanto, as duas fileiras de interruptores devem ser ativadas em ordem
invertida. A fileira superior (ver Figura 25) deve ser ativada da esquerda para a direita, enquanto
que a fileira inferior deve ser percorrida na direção contrária. Qualquer falha nesta seqüência de
ativação dos interruptores fará com que a porta de saída fique totalmente bloqueada.
Figura 25. Sala com duas fileiras de interruptores de energia
139
Desafio 7
Este desafio é uma terceira variação do desafio 5, pois também envolve o acionamento de
interruptores. Neste caso o robô estará em uma sala onde existe uma matriz de interruptores. Como
no desafio anterior, os interruptores precisam ser acionados na seqüência correta, e apenas aqueles
que estão nas posições correspondentes a diagonal principal da matriz devem ser acionados (ver
Figura 26).
Figura 26. Sala com uma matriz de interruptores de energia
Desafio 8
Este desafio é similar ao desafio 2, porém envolve o uso de um laço de repetição. No desafio
2 os botões são acionados com apenas um toque. Neste desafio os botões precisam ser acionados
várias vezes e alternadamente, sendo que em cada acionamento a porta de saída se abre um pouco
mais. Para solucionar o problema o jogador deverá obrigatoriamente utilizar um laço de repetição.
Desafio 9
Neste desafio o robô encontra-se em uma sala onde existe um dispositivo gerador de
números inteiros aleatórios ao fundo da sala e um botão próximo a porta de saída (ver Figura 27).
Este gerador de números aleatórios está conectado ao botão da seguinte maneira: sempre que o
gerador de números aleatórios sorteia um valor N são necessários os mesmos N empurrões no botão
para pressioná-lo completamente. Além disso, o gerador de números é programado para repetir este
140
processo um número indefinido de vezes, para só então desbloquear completamente a porta de saída
da sala.
Figura 27. Sala do desafio 9
141
APÊNDICE B – INSTRUMENTO DO PRÉ E PÓS TESTE
Questão 1 (Categoria Aplicar)
Considere o seguinte trecho de código:
programa ex1 declaracoes defina TAM 5 inteiro x[TAM] inteiro limite, i, soma inicio
x <- {2, 1, 4, 5, 7}
limite <- 3
i <- 0
soma <- 0
enquanto ( soma < limite E i < TAM) faca
i <- i + 1
soma <- soma + x[i];
fimenquanto
fim
Qual é o valor da variável “i” após a execução do código? a) 0 b) 1 c) 2 d) 3
Discussão
A classificação desta questão segundo à taxonomia de Bloom não é trivial. Nesta questão os
alunos devem predizer o resultado da variável “i” depois da execução do código, o que encaixa-se
perfeitamente na categoria Entender da taxonomia. Entretanto, para fazer a predição os alunos
precisam seguir a lógica de execução do algoritmo, respeitar a precedência dos operadores, etc, ou
seja, precisam seguir um processo bem conhecido. Sendo assim, neste caso a atividade cognitiva
dos alunos não resume-se a predizer e vai um pouco além, até o nível da aplicação do conhecimento
sobre a execução das instruções.
Questão 2 (Categoria Entender)
Em um fluxograma são utilizados elementos gráficos para representar um fluxo de eventos,
ou seja, a ordem em que as coisas acontecem. Cada tipo de evento é representado por uma figura
geométrica diferente, e setas são utilizadas para indicar a ordem em que os eventos acontecem. Na
tabela mostrada a seguir são mostradas 3 figuras geométricas e o significado delas em um
fluxograma.
142
Figura Significado
Atribuição
Desvio condicional
Operação de entrada ou saída
(leia ou escreva)
Considere o seguinte trecho de código:
programa ex2 declaracoes defina MAX 3 inteiro valor inicio
valor <- 0
enquanto (valor < MAX) faca
escreva (valor)
valor <- valor + 1
fimenquanto
fim
Qual dos 4 fluxogramas a seguir possui a mesma lógica do trecho de código acima?
a) b)
não
sim
valor = 0
valor < 3
exibe valor
valor= valor + 1
não
sim
valor = 0
valor < 3
exibe valor
valor= valor + 1
valor < 3
exibe valor
valor = 0
143
c) d)
Questão 3 (Categoria Entender)
Observe o diagrama a seguir. Neste diagrama, array1 e array2 são vetores contendo MAX
números inteiros. Qual dos trechos de código mostrados a seguir implementa corretamente a lógica
mostrada no diagrama?
não
sim
valor = 0
valor < 3
exibe valor
valor= valor + 1
não
sim
valor = 0
valor < 3
exibe valor
valor= valor + 1
Questão 3
Inicializa indice1 como 0
Inicializa indice2 para MAX
Enquanto indice1 for menor que MAX
Decrementa
indice2
Copia número na posição indice1 do
array1 para a posição indice2 do array2
Incrementa
indice1
144
a) programa ex3 declarações defina MAX (qualquer valor) inteiro indice1, indice2 inteiro array1[MAX], array2[MAX] inicio
indice1 <- 0
indice2 <- MAX
enquanto (indice1 <= MAX) faca
indice2 = indice2 - 1
array1[indice1] <- array2[indice2]
indice1 <- indice1 + 1
fimenquanto
fim
b) programa ex3 declarações defina MAX (qualquer valor) inteiro indice1, indice2 inteiro array1[MAX], array2[MAX] inicio
indice1 <- 0
indice2 <- MAX
enquanto (indice1 < MAX) faca
indice2 <- indice2 - 1
array1 [indice1] <- array2 [indice2]
indice1 <- indice1 + 1
fimenquanto
fim
c) programa ex3 declarações defina MAX (qualquer valor) inteiro indice1, indice2 inteiro array1[MAX], array2[MAX] inicio
indice1 <- 0
indice2 <- MAX
enquanto (indice1 <= MAX) faca
indice2 <- indice2 - 1
array2 [indice2] <- array1 [indice1]
indice1 <- indice1 + 1
fimenquanto
fim
d) programa ex3 declarações defina MAX (qualquer valor) inteiro indice1, indice2 inteiro array1[MAX], array2[MAX] inicio
indice1 <- 0
indice2 <- MAX
enquanto (indice1 < MAX) faca
indice2 <- indice1 - 1
array2 [indice2] <- array1 [indice1]
indice1 <- indice1 + 1
fimenquanto
fim
Questão 4 (Categoria Entender)
O trecho de código a seguir verifica se o valor da variável x está no intervalo entre MIN e
MAX, incluindo tanto MIN quanto MAX e assumindo que MAX é maior que MIN. Se o valor de x
está dentro deste intervalo a variável flag recebe o valor true, caso contrário recebe o valor false.
programa ex4 declarações logico flag inteiro x defina MAX (qualquer valor) defina MIN (um valor menor que MAX) inicio
se( ?????? ) entao
flag <- verdadeiro
senao
flag <- falso
fimse
fim
145
Qual destas opções completa o código para que ele execute de acordo com a lógica
mencionada?
a) x != MIN OU x != MAX b) x >= MIN E x < MAX
c) x >= MIN OU x <= MAX d) x >= MIN OU x <= MAX
Discussão
Nesta questão o aluno deve completar a parte faltante do algoritmo com um trecho de código
dado, o que enquadra a questão na categoria Entender da taxonomia de Bloom. Entretanto, é
possível argumentar que a questão enquadra-se na categoria Analisar da taxonomia, que entre
outras coisas trata da organização de partes componentes para atingir um objetivo geral. Neste
caso, é preciso atentar para o fato de que o aluno não organiza as partes faltantes do código, apenas
indica qual das partes disponibilizadas completa o algoritmo corretamente. A questão trabalharia o
processo cognitivo da Análise se, por exemplo, o aluno recebesse vários trechos de códigos
embaralhados entre si e precisasse ordenar estes trechos para formar um algoritmo coerente. Neste
caso o aluno realmente precisaria organizar os trechos de códigos, e então a questão enquadraria-se
na categoria Analisar da taxonomia.
Questão 5 (Categoria Aplicar)
Considere este trecho de código:
01 programa ex5 02 declaracoes 03 inteiro val 04 inicio 05 leia (val) 06 se (val MOD 2 = 0) entao 07 se (val > 0) entao 08 escreva (??????) 09 fimse 10 fimse 11 fim
Qual a mensagem deve ser exibida na linha 8 do trecho de código acima?
a) “par e positivo” b) “ímpar e positivo” c) “maior que dois” d) “positivo ou zero”
146
Questão 6 (Categoria Aplicar)
Considere o algoritmo a seguir:
programa ex6 declaracoes inteiro x, y inicio leia (x, y) se (x > y OU x <= y) entao escreva (“ok”) senao se (x != y) entao escreva (“certo”) fimse fimse fim
Qual será a saída deste algoritmo? Repare que o teste lógico independe do valor de x e y.
a) certo b) ok e certo c)ok d) ok e ok
Questão 7 (Categoria Aplicar)
Considere o trecho de código abaixo:
Qual das opções a seguir descreve o que este trecho de código realiza?
a) Soma todos os elementos do array. b) Soma todos os elementos do array, exceto o primeiro e o último.
c) Soma todos os elementos do array, com exceção do último elemento.
d) Soma todos os elementos do array, exceto o primeiro.
programa ex8 declarações defina TAM 7 inteiro array[TAM]; inteiro i, s inicio
array <- {1, 2, 3, 4, 5, 6, 7}
i <- 0
s <- 0
enquanto( i < TAM-1 ) faca
i <- i + 1
s <- s + array[i]
fimenquanto
fim
147
Questão 8 (Categoria Analisar)
O trecho de código a seguir soma os elementos do array números até que a soma ultrapasse
o valor armazenado na variável limite.
Ao final da execução do código a variável indice deve conter a primeira posição do array
onde a soma excedeu o valor de limite, e a variável soma deve conter o somatório dos elementos do
array entre 0 e indice, inclusive.
Entretanto, o código possui uma falha. Por exemplo, se o array numeros for inicializado com
os valores {2, 1, 4, 5, 7}, ao final da execução a variável indice deveria ser 2 a soma deveria ser 7.
Ao invés disso, depois de executado o código acima, índice é 2 e soma é 5. O problema deste
código pode ser resolvido:
a) Substituindo indice = 0 por indice = -1 b) Substituindo soma = 0 por soma = -1
c) Substituindo soma <= limite por soma < limite d) Invertendo a ordem dos comandos dentro do loop
Questão 9 (Categoria Analisar)
O algoritmo de ordenação ascendente (do menor para o maior) mostrado abaixo está
incompleto. Qual é a seqüência de instruções que completa o algoritmo corretamente?
a) 4, 2, 6, 3, 1, 5 b) 2, 4, 6, 5, 1, 3 c) 4, 2, 6, 5, 1, 3 d) 2, 4, 6, 1, 5, 3
programa ex9 declarações defina MAX (qualquer valor) inteiro numeros[MAX] inteiro limite, índice, soma inicio
numeros <- {…valores do array...}; limite <- 3 indice <- 0 soma <- 0 enquanto ( soma <= limite E indice < MAX) faca
indice <- indice + 1 soma <- soma + numeros[indice]
fimenquanto
fim
148
Instruções que completam o algoritmo: 1) array[i] <- array[j] 2) para j <- i ate TAM-1 passo 1 3) array[j] <- temp 4) para i <- 0 ate TAM-1 passo 1 5) temp <- array[i] 6) se (array[j] < array[i]) entao
Questão 10 (Categoria Aplicar)
Considere o trecho de código:
Qual das opções a seguir descreve o que o trecho de código anterior realiza?
a) Verifica se o array tem apenas números ímpares
b) Verifica se o array está em ordem crescente
c) Verifica se o array tem apenas números primos
d) Verifica se o array está em ordem decrescente
programa ex11 declarações defina TAM 5 inteiro temp, i, j
inteiro array[TAM]
inicio array <- {4, 3, 2, 1, 0} ???? ???? ???? ???? ???? ???? fimse fimpara fimpara fim
programa ex12 declarações
logico valido
inteiro i
defina MAX (qualquer valor)
inteiro números[MAX]
inicio
valido <- verdadeiro
para i <- 0 ate MAX-1 passo 1
se (numeros[i] > numeros[i+1]) entao
valido <- falso;
fimse
fimpara
fim
149
APÊNDICE C – DADOS COLETADOS
Este apêndice contém os dados de todos os alunos que participaram de cada etapa dos
experimentos, a saber: o pré-teste, a intervenção com um software e um pós-teste. Na Tabela 12 são
apresentados todos os dados dos pré-testes.
Tabela 12. Dados dos pré-testes das 3 turmas de alunos
Quantidade de questões respondidas corretamente Aluno Grupo de Controle Grupo Exp. 1 Grupo Exp. 2
1 7 8 9
2 7 7 8
3 7 7 8
4 7 7 7
5 6 6 7
6 6 6 7
7 6 5 6
8 6 5 6
9 5 5 6
10 5 5 5
11 5 5 5
12 4 4 5
13 4 4 5
14 4 4 5
15 4 4 4
16 4 4 4
17 4 3 4
18 4 3 3
19 3 3 3
20 3 2 3
21 3 2 3
22 3 - 3
23 3 - 3
24 2 - 3
25 2 - 2
26 2 - 2
27 1 - 2
28 1 - 2
29 1 - 2
30 0 - 2
31 - - 1
32 - - 1
33 - - 1
34 - - 1
35 - - 0
36 - - 0
37 - - 0
150
Na Tabela 13 são apresentados todos os exercícios realizados pelo grupo de controle e pelo
segundo grupo experimental.
Tabela 13. Exercícios realizados pelo grupo de controle e pelo 2º grupo experimental
Grupo de controle Grupo experimental 2 Aluno Último
exercício realizado
Desvios condicionais
Arrays +
loops
Somente loops
Último exercício realizado
Desvios condicionais
Arrays + loops
Somente loops
1 9/9 9/9 2 9/9 9/9 3 9/9 9/9 4 9/9 9/9 5 9/9 7/9 6 9/9 6/9 7 9/9 6/9 8 9/9 5/9 9 9/9 5/9
10 8/9 5/9 11 6/9 5/9 12 6/9 5/9 13 6/9 4/9 14 6/9 4/9 15 5/9 4/9 16 5/9 3/9 17 5/9 3/9 18 5/9 3/9 19 5/9 3/9 20 4/9 3/9 21 4/9 3/9 22 4/9 3/9 23 4/9 2/9 24 4/9 2/9 25 3/9 2/9 26 2/9 2/9 27 1/9 2/9 28 1/9 2/9
Na Tabela 14 são apresentados todos os exercícios resolvidos pelo grupo experimental 1, o
grupo que utilizou o jogo. No jogo os problemas podiam ser resolvidos em qualquer ordem pelos
alunos, diferentemente dos dados apresentados na tabela anterior (Tabela 13) onde os problemas
foram resolvidos seqüencialmente.
151
Tabela 14. Exercícios realizados pelo grupo experimental 1 (utilizaram o jogo)
Desvio Condicional Loops + Arrays Somente Loops Aluno Ex. 1 Ex. 2 Ex. 3 Ex. 4 Ex. 5 Ex. 6 Ex. 7 Ex. 8 Ex. 9
1 - - - - - - - -
2 - - - - - - - -
3 - - -
4 - - -
5 - - - - - - - -
6 - - -
7 - - - - - - - -
8 - - - - - - - -
9 - - -
10 - - - - - - - -
11 - - - - - - - -
12 - -
13 - -
14 - - - - - - - -
Na Tabela 15 são apresentados os dados dos pós-testes das 3 turmas de alunos.
Tabela 15. Dados dos pós-testes das 3 turmas de alunos
Quantidade de questões corretas Aluno Grupo de Controle Grupo Exp. 1 Grupo Exp. 2
1 9 8 10
2 8 8 9
3 8 8 9
4 7 8 9
5 7 8 9
6 7 8 9
7 7 8 8
8 6 8 8
9 5 7 8
10 4 7 8
11 4 7 7
12 - 7 6
13 - 7 6
14 - 7 5
15 - 7 5
16 - 6 5
17 - 6 4
18 - - 4
19 - - 4
20 - - 4
21 - - 3
22 - - 3
23 - - 2
24 - - 1
25 - - 1