APRENDENDO PROGRAMAÇÃO DE COMPUTADORES COM EXPERIÊNCIAS LÚDICAS

APRENDENDO PROGRAMAÇÃO DE COMPUTADORES COM

EXPERIÊNCIAS LÚDICAS

Adilson Vahldick

, Mauro Marcelo Mattos

1 Adilson Vahldick, Professor Substituto do Departamento de Sistemas e Computação da Fundação Universidade Regional de Blumenau, adilsonv@furb.br 2 Mauro Marcelo Mattos, Professor Titular do Departamento de Sistemas e Computação da Fundação Universidade Regional de Blumenau, mattos@furb.br

Abstract  In an educational perspective, teachers can be considered as learning facilitators. In this case, learning is an active process on which teachers adapts their teaching model based on student responses. This paper describes the experience in adopting a game metaphor in teaching an introductory computer programming discipline to motivate students. The metaphor is supported by a tool named Furbot. This paper presents the framework and the experience in adopting it in programming classes.

Index Terms  Learning computer programming; Game

programming; Teaching Java.

I

As dificuldades enfrentadas pelos alunos no aprendizado de algoritmos no primeiro semestre são bem conhecidas. Para resolvê-los exige-se um preparo no raciocínio metodológico, ou seja, no modo como o aluno divide um problema, e a organização do caminho que ele estabelece para resolvê-lo. Vários trabalhos têm sido desenvolvidos, como em [1]-[4], visando auxiliar o aluno a superar as dificuldades e traumas iniciais no aprendizado de programação.

Segundo [5], o aprendizado é mais eficiente quando o aluno é motivado. Essa motivação depende de um conteúdo interessante, de um ambiente empolgante e da didática dos professores. Em [6] comenta-se que existem duas formas de ativar a motivação: através da curiosidade e do desafio. Essas qualidades, segundo os autores, podem ser obtidas quando o professor apresenta uma questão em que a resposta é desconhecida, e a tarefa dos alunos é desvendá-la. Outra possibilidade é a resposta conhecida, mas o processo para alcançá-lo não. A partir de variáveis de entradas e saídas, os alunos são desafiados a elaborar o caminho entre ambas as extremidades. Porém, essas questões devem possibilitar a tentativa, a investigação, e a experimentação por parte dos estudantes, dentro de uma situação instigante e que faça parte da realidade deles.

Os autores desse artigo são professores da disciplina de Programação de Computadores dos cursos de Ciências da Computação e Sistemas de Informação da Universidade Regional de Blumenau (FURB). Essa disciplina é ofertada no primeiro semestre do curso. A experiência desses professores mostra que os alunos não se sentem motivados em resolver exercícios com enunciados como "digite cinco nomes e notas de alunos e mostre a média da sala, a maior e

menor nota". Apesar da solução não ser trivial para os alunos iniciantes, eles não se sentem desafiados.

Pensando em prover um ambiente desafiador, os professores decidiram em adotar alguma solução que permitisse aos alunos resolver problemas de programação utilizando a metáfora de jogos de computador.

Os autores testaram alguns ambientes como Robocode ([7]) e Greenfoot ([8]), porém eles divergiram em alguns aspectos para uma disciplina introdutória de programação, entre eles, a carga de informações necessária para o início das atividades que estes ambientes demandam.

Concluiu-se que esse ambiente almejado precisava ser desenvolvido. Para isso, os autores realizaram uma análise dos pontos fortes e fracos dos ambientes estudados, e desenvolveram um framework denominado de Furbot.

Esse artigo apresenta o framework e relata a sua aplicação em sala de aula. Nas duas próximas seções são apresentados os ambientes que inspiraram o desenvolvimento do Furbot e a avaliação desses ambientes. Em seguida, são relacionados os requisitos e características do framework. Na seção subseqüente é relatada a experiência dos professores. A última seção apresenta as conclusões dessa experiência e os próximos caminhos na evolução da adoção dessa estratégia.

T

C

Essa seção apresenta dois ambientes de programação estudados como possibilidade de utilização na disciplina de Programação de Computadores. Ambos são baseados em objetos e cenários animados e são desenvolvidos em Java – linguagem de programação oficial dos cursos onde o experimento foi executado.

O primeiro deles foi o Greenfoot ([8]). Este ambiente, conforme relatado em [9], foi sido utilizado por um dos autores em uma disciplina do terceiro semestre.

O Greenfoot é um framework e um ambiente para criar aplicações interativas e simulações num plano bidimensional [10]. Ele consiste de somente quatro classes e, segundo [9], "oferecem possibilidades abrangentes de exercícios e o tamanho limitado do framework favorece a compreensão do todo por parte dos alunos".

O aluno desenvolve duas classes: o mundo e o ator. O mundo é uma matriz bidimensional onde podem ser distribuídos vários objetos (os atores). Os atores são os elementos centrais nesse ambiente. O foco nos exercícios é a implementação do comportamento dos atores. Um ator pode

se mover pelo mundo, adicionar e remover outros atores, e "enxergar" o mundo. Uma representação gráfica (ícone) precisa ser atribuída inicialmente a um ator (posteriormente ela pode ser substituída em função da alteração do comportamento do ator).

A figura 1 apresenta o ambiente do Greenfoot. Nas áreas 1 e 2 estão, em forma de árvore, as classes de mundo (World) e de ator (Actor). A área 3 representa o mundo onde vivem os atores. Ela reflete a instância da classe descendente de World. Somente é possível haver uma classe de mundo. Os atores que vivem nesse mundo são objetos das classes que estão representadas na área 2. Esses objetos podem ser criados no próprio código do mundo, ou arrastados pelo usuário a partir da área 2. Por fim, a área 4 representa a execução dos atores. Ao clicar em [Run], o Greenfoot ciclicamente seleciona cada um dos atores e invoca um método específico (act()) da classe. A inteligência de cada ator está nesse método. Cada ator ganha a sua vez para executar esse método.

FIGURA 1

AMBIENTE DO GREENFOOT

No exemplo da figura 1, o ator Automovel não pode implementar o deslocamento dele até BombaCombustivel de uma única vez no método act(). Para que o aluno possa perceber visualmente o veículo se deslocando, a cada vez que o método act() é invocado ele deve fazer um único movimento caso contrário o efeito seria de um salto da posição inicial do Automovel para a posição final desejada.

Para implementar esta funcionalidade, o programador desenvolve o comportamento dos atores utilizando máquinas de estados, ou seja, a ação atual (o que o ator precisa fazer agora) depende do estado atual do mundo, da última ação realizada e dos objetivos do ator.

Sob o ponto de vista de interação do ator com o aluno, não existe o conceito de evento para utilizar o teclado e o mouse. O ator invoca um método para obter a última tecla pressionada, ou sobrescreve um método que posiciona o ator no mundo (para representar o arrastar do ator no mundo).

O Greenfoot é integrado ao BlueJ ([11]), outro ambiente de programação bem conhecido para o ensino de Orientação a Objetos o que facilita o processo de edição do código, compilação e execução dos programas.

Outro ambiente estudado foi o Robocode ([7]). Nele são programados robôs com objetivo de destruir robôs adversários. Eles atiram, possuem radares, batem uns nos outros, e movimentam-se livremente em qualquer ângulo dentro de uma área denominada: arena (figura 2).

A API do Robocode ([12]) é bem extensa, garantido recursos para a construção de robôs guerreiros dos mais variados tipos.

FIGURA 2

AMBIENTE DO ROBOCODE

A interatividade com o aluno é programada através de eventos para tratamento do mouse e teclado. Além disso, existem eventos para avisar ao robô quando ele acerta um tiro ou é acertado, quando ele é eliminado da batalha, ou quando ela é finalizada.

O ambiente apresentado na figura 2 contém um editor de código fonte para programar os robôs. Além disso, também existe um plugin para o ambiente Eclipse.

AVALIAÇÃO DOS AMBIENTES

ESTUDADOS

Essa seção apresenta uma análise dos ambientes apresentados na seção anterior sob a perspectiva da adoção dos mesmos em uma disciplina introdutória de programação evidenciando os aspectos positivos e negativos da sua adoção. Esta análise norteou o desenvolvimento do Furbot.

Como referido anteriormente ([9]), a partir da experiência na adoção do Greenfot para desenvolvimento de atividades de programação evidenciou que o ambiente possui uma quantidade limitada de recursos disponível, mas não impediu o desenvolvimento de um jogo como atividade de final de semestre. Contudo, a necessidade de programar os atores através de máquinas de estados dificulta a adoção em uma disciplina introdutória de programação. Um resultado mais efetivo seria obtido se fosse possível programar os atores através de uma seqüência lógica de

comandos facilitando a visualização e o entendimento das construções lógicas envolvidas na solução de um problema

Sob este aspecto o ambiente do Robocode é mais apropriado: quando uma batalha começa, um método específico dos robôs é disparado, e a inteligência dele é codificada nesse método. Enquanto esse método estiver executando, provavelmente o robô está andando e atirando no mundo.

Entretanto, no Robocode o único tipo de elemento existente são os robôs. As metáforas, tal como utilizadas no Greenfoot, poderiam ser mapeadas no Robocode, mas não teriam uma representação gráfica adequada. Por exemplo, um robô poderia representar o papel de uma bomba de combustível, porém, visualmente teria uma representação incompatível com o contexto da aplicação de abastecimento.

Além disso, a execução do robô exige a criação de uma arena onde o mesmo é adicionado. A depuração dos robôs é muito complicada, e essa é uma atividade importante no ensino de programação. A API é mais adequada para programadores com alguma experiência, pois os robôs utilizam eventos e demandam informações baseadas em ângulos para realização dos movimentos.

Ambos os ambientes possuem editores onde fica evidenciada a necessidade de recursos como auto-completar e destaque de sintaxe. Embora o Robocode possua um plugin para o Eclipse, ainda assim a execução abre o ambiente onde é necessário criar uma arena (ou carregá-la de um arquivo).

R

A partir da análise realizada, foram definidos os seguintes requisitos para o Furbot:

• o código deve ser tão simples de implementar quanto no Greenfoot, porém, a seqüência lógica precisa ser expressa como no Robocode;

• a codificação deve ser feita em qualquer ambiente de programação (IDE) Java, facilitando o processo de depuração;

• a criação das atividades é de responsabilidade do professor, e o aluno não deve gastar tempo configurando o ambiente para cada execução;

• como Java é a linguagem de programação adotada nos cursos onde o ambiente será aplicado, o Furbot deverá ser desenvolvido em Java.

CARACTERÍSTICAS DO FURBOT

O elemento central do Furbot é a programação de um robô que vive num mundo bidimensional juntamente com outros tipos de objetos, que também podem ser programados. Tal como nos ambientes analisados, e para o cumprimento do primeiro requisito identificado, esse robô é estendido de uma classe, e o aluno precisa programar toda a lógica do seu robô em um método denominado inteligencia().

Os comandos do robô, tais como "andarAcima", "ehVazio" e "diga" são expressos em português facilitando o processo de desenvolvimento da inteligência do mesmo. O robô tem a capacidade de andar uma célula de cada vez, visualizar as células na sua vizinhança, falar (enviar mensagens para o aluno), pegar objetos na vizinhança, adicionar e remover objetos no mundo (figura 3).

FIGURA 3

EXEMPLO DE PROGRAMAÇÃO DA INTELIGÊNCIA DO FURBOT

O framework Furbot (segundo requisito) é distribuído em um arquivo compactado no formato "jar". O aluno cria seu projeto na IDE de preferência (viabilizando a utilização de ambientes profissionais que ele poderá encontrar nas empresas aonde vier a trabalhar), adiciona o arquivo como uma biblioteca e cria uma nova classe estendendo da classe Furbot, que se encontra na biblioteca.

Para atender ao terceiro requisito definiu-se que as atividades são montadas através de arquivos XML disponibilizadas pelos professores. Nesse arquivo estão definidas as dimensões do mundo, a posição inicial do robô e outros elementos que compõem o cenário. O Furbot contém algumas classes que podem ser utilizadas pelo professor com objetivo de montar as atividades: Alien, Parede, Numero, Booleano e Tesouro (figura 4).

FIGURA 4

EXEMPLO DE DEFINIÇÃO DE MODELO DE MUNDO

Nesse arquivo podem ser definidas quaisquer quantidades desses objetos e seus posicionamentos. Tanto a quantidade quanto o posicionamento também podem ser aleatórios. Outro recurso para as atividades é a criação de composições desses elementos, permitindo que se criem edificações que variam de local e forma.

Para o aluno executar seu robô, a classe precisa ter um método "main" que carrega o arquivo XML (figura 5).

FIGURA 5

CARGA DO ARQUIVO XML

Ao executar o método main(), o mundo configurado na figura 4 é criado com o robô na posição (0,0) e com três

objetos do tipo Alien nas posições (2,1), (2,2) e (2,5) sendo apresentada uma janela como mostrado na figura 6.

Nessa janela o aluno pode ler o enunciado do exercício (área 1), controlar a execução do robô (área 2), visualizar o robô cumprindo com o que foi programado em sua inteligência (área 3) e ler as mensagens que o robô fala ao mundo (área 4).

FIGURA 6

AMBIENTE DO FURBOT

Na área 2, o botão [Run] executa a inteligência do robô. O botão [New] reinicia o mundo. Como existe a possibilidade de configurar aleatoriamente o posicionamento dos elementos, isso permite o teste em situações diversas.

E

S

O experimento foi realizado com quatro turmas de Programação de Computadores (primeiro semestre) do curso de Ciências da Computação da FURB. A utilização do Furbot não deveria eliminar a utilização de exercícios como "digite cinco notas e calcule a média", mas oferecer outro foco para eles. Por exemplo, "fazer o robô procurar pelos tesouros no mundo, e falar a soma total dos tesouros, qual foi o menor e o maior tesouro encontrado. Por fim, deve falar a média dos valores dos tesouros". O exercício é o mesmo, mas agora é mais estimulante fazer o robô andar e caçar os tesouros no mundo, e no final falar o resultado de sua exploração.

A disciplina é estruturada 60% em sala e o restante em laboratório. Os conteúdos são apresentados sempre em sala, e as aulas de laboratório são utilizadas exclusivamente para a prática. Nas aulas em sala são feitos os exercícios mais simples e a correção de todos eles.

Na segunda aula do semestre o Furbot é contextualizado e são feitos os primeiros exercícios para movimentar o robô dentro do mundo. Assim, eles começam a se habituar à seqüência lógica de comandos, interpretarem enunciados e resolvê-los. O tradicional Portugol foi substituído pelos recursos de movimentação do Furbot expressos em português: andarAcima(), ehVazio(),etc.

Na primeira aula de laboratório, são apresentadas duas IDEs mais conhecidas: NetBeans e Eclipse. O professor mostra como configurar os ambientes, os recursos que facilitam a codificação, e as ferramentas de depuração.

O semestre é dividido em três partes, cada uma delas encerrada por uma prova. Na primeira parte da disciplina são trabalhados os conceitos de uso de variáveis, as estruturas

se-então e faça-enquanto. Na segunda parte são

contempladas as estruturas para-cada e escolha-caso, invocação de métodos de outros objetos (o robô consegue obter um objeto na vizinhança e solicitar que ele ande pelo mundo), e divisão da inteligência do robô em métodos privados (modularização do programa). Na última parte da disciplina os alunos instanciam objetos, desenvolvem novas classes referentes aos outros objetos do mundo, aprendem a invocar esses novos métodos que suas classes possuem e utilizam matrizes unidimensionais.

Todos os exercícios podem ser praticados em sala ou laboratório, nas aulas ou extraclasse. Os arquivos XML desses exercícios são disponibilizados em um site da disciplina.

Além das três provas, os alunos recebem como atividade extraclasse o desenvolvimento de um jogo utilizando o Furbot. No semestre em que foi implantada essa metodologia, foram desenvolvidos três jogos (em turmas distintas). As duas turmas do mesmo professor desenvolveram o jogo "Bomberman", que consiste em um herói com capacidade de soltar bombas no mundo, que explodem após um tempo. Esse mundo é formado por um labirinto onde coexistem inimigos que tentam matar o herói. Outra turma desenvolveu o tradicional jogo "Come-come" e a última turma o jogo "Invasores do espaço". Esse último jogo consiste em destruir um grupo de naves que avançam sobre o jogador que comanda a sua nave. A figura 7 apresenta a interface do trabalho de um aluno quanto ao jogo "Bomberman".

FIGURA 7

EXEMPLO DO JOGO BOMBERMAN NO FURBOT.

Com esse trabalho os alunos ganham experiência no desenvolvimento de um programa com maior complexidade,

que necessita de várias classes (cada inimigo é uma classe que ele precisa também desenvolver, além do herói).

O trabalho trouxe novos assuntos à sala, pois alguns tipos de problemas e recursos da linguagem não são tratados durante o semestre, e as ferramentas sugerem automaticamente alguma solução para resolver o erro de compilação do código, que os alunos desconheciam a possibilidade.

Para dar suporte ao jogo, vários recursos foram incorporados, e inclusive confeccionado um manual para utilização desses recursos. Entre eles, um método que retorna a tecla pressionada pelo usuário (tal como acontece no Greenfoot), e recursos para mudança de fases, o que facilita o carregamento de novos mundos.

O Furbot foi amadurecendo durante o semestre. À medida que os professores montavam seus exercícios, novas possibilidades surgiam e que fomentavam o aprimoramento do framework.

C

F

O principal objetivo em adotar a estratégia citada nesse artigo é permitir que o aluno experimente o máximo possível em programação. Para ele fazer essa experimentação, ele precisa de motivação em fazê-lo. Quando o aluno programa o robô do Furbot para explorar o mundo, contar e guardar os objetos que ele vai encontrando, é como se ele estivesse programando um jogo. Foram desenvolvidos 36 exercícios e ainda o jogo no fim do semestre.

A tabela I apresenta os dados referentes ao desempenho de duas turmas no semestre. Metade dos alunos obteve nota acima de cinco na primeira prova. Percebeu-se que muitos ainda não haviam instalado uma IDE em casa, ou seja, não praticavam fora de sala. As desistências durante o semestre foram contabilizadas como nota zero nessa tabela. Nota-se que a última prova teve uma quantidade muito baixa com notas acima de 5. Como o trabalho é entregue antes dessa prova, alguns alunos já estavam aprovados na disciplina, e concentraram seus esforços em outras disciplinas. Pode-se notar que a segunda prova foi determinante para a aprovação. Essa prova é a que possui a maior quantidade de assunto, e é nesse momento que o aluno identifica-se com a disciplina, e por conseqüência com o curso.

TABELA I

ESTATÍSTICAS DOS ALUNOS

Quesito Quantidade Percentual (%)

Universo

Primeira Prova (Nota >= 5) Segunda Prova (Nota >= 5) Trabalho (Nota >= 5) Terceira Prova (Nota >= 5) Aprovados 71 37 31 37 20 30 - 52% 43% 52% 28% 42%

Essa experiência aconteceu no primeiro semestre de 2008. O semestre seguinte, onde os alunos aprovados estão na disciplina de Programação Orientada a Objetos I, o

professor titular dessa disciplina, que não esteve envolvido na disciplina do primeiro semestre, mencionou que os alunos estão mais participativos nos debates. Acredita-se que isso acontece porque eles têm mais autoridade sobre o assunto, se comparados com aqueles dos semestres anteriores. Essa capacidade se atribui a quantidade de exercícios que esses alunos programaram.

Os próximos passos, e que já estão em andamento, é a organização de material instrucional aos alunos, listas de exercícios extras e disponibilização de mais monitores para dar suporte aos alunos. O objetivo é contemplar mais alunos quanto a vencer as dificuldades iniciais, e assim diminuir a quantidade de desistências e o aumento de aprovações na disciplina.

R

[1] Mattos, M. M.; Fuchs, J. F. "Qualifica: Uma ferramenta para apoio a construção de algoritmos estruturados". XVI Seminário de

Computação - SEMINCO, Blumenau, 2007. Anais... Blumenau: Furb,

2007. p. 75-87.

[2] Raabe, A. L. A. "Uma proposta de arquitetura de Sistema Tutor Inteligente baseada na teoria das experiências de aprendizagem mediadas", 2005. 152f. Tese (Doutorado) – Programa de Pós-Graduação em Informática na Educação, Universidade Federal do Rio Grande do Sul, Porto Alegre.

[3] Rapkiewicz, C. E. et al. "Estratégicas pedagógicas no ensino de algoritmos e programação associadas ao uso de jogos educacionais". Rio Grande do Sul, 2006. Disponível em:

<http://www.cinted.ufrgs.br/renote/dez2006/artigosrenote/25157.pdf> [4] Theiss, F. "Linguagem visual orientada por figuras geométricas

voltada para o ensino de programação: versão 2.0". 2006. 83 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.

[5] Bergin, J. et al. "Patterns for experiental learning". Disponível em: < http://csis.pace.edu/~bergin/patterns/ExperientialLearning.html >. [6] Tapia, J. A.; Fita, E. C. "A motivação em sala de aula: o que é, como

se faz", 4. ed. São Paulo : Loyola, 2001. 148p.

[7] "Robocode Home" Disponível em <http://robocode.sourceforge.net/>. [8] Henriksen, P; Kölling, M. "Greenfoot – The Java Object World".

Disponível em: <http://www.greenfoot.org/>.

[9] Vahldick, A. "Uma experiência lúdica no ensino de programação orientada a objetos". I Workshop de Ambientes de Apoio à

Aprendizagem de Algoritmos e Programação – Simpósio Brasileiro de Informática na Educação, 2007.

[10] Henriksen, P.; Kölling, M. "greenfoot: Combining Object Visualisation with Interaction". 19th annual ACM SIGPLAN

conference on Object-oriented programming systems, languages, and applications (OOPSLA), p. 73-82, Vancouver, 2004.

[11] Barnes, D. J.; Kolling, M. "Programação orientada a objetos com Java: uma introdução prática com BlueJ". São Paulo: Pearson Education: Prentice Hall, 2004. 368 p.

[12] "Robocode 1.6.1 API". Disponível em: