UNIVERSIDADE CRUZEIRO DO SUL
PROGRAMA DE PÓS-GRADUAÇÃO
DOUTORADO EM ENSINO DE CIÊNCIAS E MATEMÁTICA
Relações entre o Pensamento Computacional e a
Matemática em atividades didáticas de construção de
jogos digitais
THIAGO SCHUMACHER BARCELOS
Orientador: Prof. Dr. Ismar Frango Silveira
Tese apresentada ao Doutorado em Ensino
de Ciências e Matemática, da Universidade
Cruzeiro do Sul, como parte dos requisitos
para a obtenção do título de Doutor em
Ensino de Ciências e Matemática.
SÃO PAULO
2014
AUTORIZO A REPRODUÇÃO E DIVULGAÇÃO TOTAL OU PARCIAL DESTE
TRABALHO, POR QUALQUER MEIO CONVENCIONAL OU ELETRÔNICO,
PARA FINS DE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE.
FICHA CATALOGRÁFICA ELABORADA PELA
BIBLIOTECA CENTRAL DA
UNIVERSIDADE CRUZEIRO DO SUL
B218r
Barcelos, Thiago Schumacher.
Relações entre o pensamento computacional e a matemática
em atividades didáticas de construção de jogos digitais / Thiago
Schumacher Barcelos. -- São Paulo; SP: [s.n], 2014.
276 p. : il. ; 30 cm.
Orientador: Ismar Frango Silveira.
Tese (doutorado) - Programa de Pós-Graduação em Ensino de
Ciências e Matemática, Universidade Cruzeiro do Sul.
1. Pensamento computacional. 2. Conhecimentos matemáticos.
3. Jogos digitais. I. Silveira, Ismar Frango. II. Universidade Cruzeiro
do Sul. Programa de Pós-Graduação em Ensino de Ciências e
Matemática. III. Título.
CDU: 004.4(043.2)
UNIVERSIDADE CRUZEIRO DO SUL
PROGRAMA DE PÓS-GRADUAÇÃO
Relações entre o Pensamento Computacional e a
Matemática em atividades didáticas de construção de
jogos digitais
Thiago Schumacher Barcelos
Tese de doutorado defendida e aprovada
pela Banca Examinadora em 27/03/2014.
BANCA EXAMINADORA:
Prof. Dr. Ismar Frango Silveira
Universidade Cruzeiro do Sul
Presidente
Profa. Dra. Cintia Aparecida Bento dos Santos
Universidade Cruzeiro do Sul
Prof. Dr. Jaime Sandro da Veiga
Universidade Cruzeiro do Sul
Prof. Dr. Leônidas de Oliveira Brandão
Universidade de São Paulo
Profa. Dra. Pollyana Notargiacomo Mustaro
Universidade Presbiteriana Mackenzie
AGRADECIMENTOS
É realmente verdade que gratidão gera gratidão, e lamúria gera lamúria.
Isso acontece porque o coração agradecido comunica-se com Deus.
(Meishu-Sama)
Um trabalho deste porte e com essa duração não seria possível sem a
participação de muitas pessoas; posso dizer que nunca estive sozinho durante a sua
realização e, nestas poucas páginas, me cabe a árdua, mas muito prazerosa tarefa
de (tentar) agradecer a todos os envolvidos.
Antes de tudo, deixo minha profunda e sincera gratidão a Deus e a MeishuSama por sua Divina proteção e orientação, bem como pela permissão de encontrar
todas as pessoas maravilhosas que encontrei, por vezes em circunstâncias
misteriosas, e que contribuíram de forma incomensurável para a existência deste
trabalho. É meu sincero desejo que os resultados deste trabalho possam contribuir
de alguma forma para a paz, saúde e prosperidade no plano terrestre.
No aspecto pessoal, agradeço imensamente a meus pais, Raul e Ivonete, por
acreditarem neste trabalho e por todo o estímulo e suporte a meus estudos. Meu
carinho e gratidão por vocês estão impregnados nesta tese, e são extensivos a toda
minha família, que me possibilitou estar aqui no dia de hoje. À Haifa, minha eterna
namorada, companheira e amiga, agradeço de todo o coração por sua presença em
todos os momentos deste trabalho, pelo seu apoio, curiosidade, preocupação e
torcida.
No aspecto profissional, devo o primeiro e maior agradecimento ao meu
orientador, Prof. Dr. Ismar Frango Silveira. Sua confiança, dedicação, competência e
amizade foram meu exemplo, estímulo e motivação ao longo desta trajetória e
resgataram minha vontade de me tornar um pesquisador. Esta tese também é um
pouco (ou muito) sua, Ismar ☺. À Universidade Cruzeiro do Sul, devo meu
agradecimento pelo suporte ao desenvolvimento deste trabalho e pela confiança
depositada em mim por meio do oferecimento de uma bolsa CAPES/PROSUP.
Agradeço à Universidade de São Paulo pela minha formação anterior ao Doutorado
e por fomentar em mim o interesse pela pesquisa acadêmica.
Agradeço pelas excelentes observações e sugestões feitas pelos membros da
banca de qualificação: Profa. Dra. Pollyana Mustaro, Prof. Dr. Leônidas Brandão,
Profa. Dra. Cintia Bento dos Santos e Prof. Dr. Jaime Sandro da Veiga. Seus
comentários certamente contribuíram para melhorar a qualidade deste trabalho.
Este trabalho não seria possível sem a participação de vários alunos de
graduação e pós-graduação que estiveram sob a minha orientação nos últimos
quatro anos. Seu empenho e motivação por vezes alimentaram meu próprio
empenho e motivação, e uma parte desta tese certamente é deles também ☺. Meu
agradecimento especial a Thiago Delanholo Cavalheiro Carvalho e a Geiza Caruline
Costa pela ativa participação na definição da proposta e na análise dos resultados.
Também foi muito importante a participação de Amadeu Shigeo de Almeida, Lucas
Nóbrega Freitas, Marcelo José do Nascimento e Joyce Gomes Daniel.
A participação e empenho dos profissionais das instituições de ensino nas
quais a Oficina de Produção de Jogos Digitais foi oferecida possibilitou a coleta de
dados que permitiu a realização de várias das análises da tese. Assim, agradeço ao
Prof. Cleber Silva de Oliveira, do Instituto Federal de São Paulo, pela parceria
demonstrada desde o primeiro momento e pelas inúmeras sugestões. Outra parceria
extremamente produtiva com a Universidad de Valparaíso, no Chile, foi possibilitada
pelo empenho e dedicação do Prof. Roberto Felipe Muñoz Soto e pela participação
do aluno Roberto García Mercado na condução da Oficina com os alunos daquela
universidade. Os alunos participantes da Oficina em ambas as instituições também
aceitaram a proposta e se engajaram ativamente nela; a eles também devo minha
gratidão. Agradeço, ainda, ao Instituto Federal de São Paulo pelo afastamento de
minhas atividades, concedido em um importante momento em que aconteciam a
análise e escrita do texto final desta tese.
O auxílio e companhia de grandes amigos e colegas estiveram presentes em
muitos momentos deste trabalho. Seria impossível agradecer nominalmente a todos;
no entanto, é imprescindível deixar meu agradecimento a Juliana Rodrigues Peixe
por sua ajuda profissional em um momento crítico, e a Julio César Avero por sua
imensa generosidade em hospedar minha família durante a realização de um
congresso em Curitiba.
“Aprender por aprender é estudo morto, enquanto que aprender algo
para ser utilizado na sociedade é estudo vivo”
MOKITI OKADA (MEISHU-SAMA)
Filósofo e religioso japonês (1882-1955)
BARCELOS, T. S. Relações entre o pensamento computacional e a matemática
em atividades didáticas de construção de jogos digitais. 2014. 276 f. Tese
(Doutorado em Ensino de Ciências e Matemática)–Universidade Cruzeiro do Sul,
São Paulo, 2014.
RESUMO
A definição de Pensamento Computacional propõe que algumas competências e
habilidades relacionadas à Computação deveriam ser desenvolvidas por todos os
alunos desde o ensino básico. No entanto, mostra-se necessário compreender de
forma aprofundada as relações entre o Pensamento Computacional e as disciplinas
já presentes no currículo escolar de forma a estabelecer os possíveis benefícios do
desenvolvimento de estratégias didáticas conjuntas. Dessa forma, esta tese tem
como objetivo evidenciar quais competências e habilidades da Matemática e do
Pensamento Computacional podem ser mobilizadas e desenvolvidas por alunos em
atividades didáticas que envolvam a construção de jogos. Um mapeamento de
competências
comuns
ao
Pensamento
Computacional e
à
Matemática
é
apresentado. É então proposta uma Oficina de Produção de Jogos Digitais, inspirada
por princípios do construcionismo e da Aprendizagem Baseada em Problemas
(ABP), com o objetivo de desenvolver competências e habilidades do Pensamento
Computacional relacionadas à programação e mobilizar alguns conteúdos da
Matemática do ensino médio. A Oficina foi oferecida a alunos de duas instituições de
ensino, no Brasil e no Chile. A análise dos resultados utilizou a etnografia, a análise
documental e um quase experimento na perspectiva de triangulação de métodos. Os
resultados indicam que a carência em tópicos da Matemática Discreta, em particular
o raciocínio combinatório, prejudica a correta enumeração de condições lógicas nos
algoritmos desenvolvidos. No entanto, os alunos parecem adquirir maior
desenvoltura ao lidar com tópicos de geometria como o posicionamento e distância
entre pontos no plano. A experiência prévia com jogos se apresentou como um
relevante aspecto de motivação, levando os alunos a utilizar estratégias como
paralelismo e reutilização de código e buscar uma melhor qualidade da interação
humano-computador nos jogos desenvolvidos. As diretrizes propostas permitem a
criação de outras atividades didáticas com objetivo semelhante.
Palavras-chave: Pensamento computacional, Conhecimentos matemáticos, Jogos
digitais.
BARCELOS, T. S. The relationship between computational thinking and
mathematics in didactic activities based on building digital games. 2014. 276 f.
Tese (Doutorado em Ensino de Ciências e Matemática)–Universidade Cruzeiro do
Sul, São Paulo, 2014.
ABSTRACT
Computational Thinking is a definition of a subset of skills related to Computing that
should be developed by all students since the basic educational levels. However, it is
necessary to obtain a deeper understanding of the relationships between
Computational Thinking and disciplines that are already included in school curricula,
in order to understand which would be the potential benefits of developing joint
didactic strategies. This research work aims at identifying which skills related to
Mathematics and Computational Thinking can be developed and used by students in
didactic activities related to building digital games. Firstly, a mapping between
Computational Thinking and Math skills is presented. Then a Game Building
Workshop is proposed. Its definition was inspired by some principles of
constructionism and Problem-Based Learning (PBL). Its activities were designed to
facilitate the development of Computational Thinking skills related to programming
and, at the same time, demand that students apply some Math knowledge at the
High School level. The workshop was offered to students enrolled to two institutions
in Brazil and Chile. The gathered data was analyzed under a method triangulation
perspective, and the research methods used include ethnography, documental
analysis and a quasi-experiment. The results indicate that insufficient knowledge
about Discrete Mathematics topics, in particular those related to combinatorial
reasoning, negatively affects the students’ skill to correctly enumerate logical
conditions in algorithms. On the other hand, students seem to achieve better results
at dealing with problems related to planar geometry, such as the positioning of points
and distance between points on the Cartesian plane. The students’ previous
experience with games was a relevant motivational factor. It led students to use
programming strategies such as parallelism and reuse of code. It also led students to
search for ways to improve the quality of human-computer interaction in the games
they developed. The proposed guidelines can also be used to create new didactic
activities with similar goals.
Keywords: Computational thinking, Math knowledge, Digital games.
LISTA DE ILUSTRAÇÕES
Figura 1
Representação esquemática da Zona de Desenvolvimento Proximal
............................................................................................................... 48
Figura 2
Esquema indicativo da Teoria do Fluxo ............................................. 49
Figura 3
Associação da Zona de Desenvolvimento Proximal à Teoria do
Fluxo e sua aplicação à construção de jogos digitais ...................... 49
Figura 4
Triangulação de métodos: contribuição de cada método de coleta
para as análises apresentadas na tese .............................................. 64
Figura 5
Exemplo de correspondência entre representações algébrica e
algorítmica de um problema matemático ........................................... 71
Figura 6
Revisão
sistemática:
quantidade
de
estudos
selecionados,
segmentados por tipo (2006 a 2013) ................................................... 82
Figura 7
Exemplo de estrutura condicional SE em uma linguagem de
programação estruturada .................................................................. 104
Figura 8
Ambiente de programação do Scratch ............................................. 105
Figura 9
Estruturas de controle de fluxo no Scratch com equivalente direto
em linguagens estruturadas.............................................................. 106
Figura 10 Programa de troca de valores entre variáveis utilizando os blocos
do Scratch ........................................................................................... 107
Figura 11 Configuração inicial do primeiro programa manipulado pelos
alunos e código vinculado ao sprite do gato................................... 111
Figura 12 Configuração inicial do jogo de Pescaria e código vinculado ao
sprite do peixe .................................................................................... 112
Figura 13 Versão final do jogo de Pescaria: exibição do percentual de peixes
de cada tipo que foram clicados pelo jogador ................................ 113
Figura 14 Jogo de Adivinhação: entrada de dados via teclado e resposta do
personagem ........................................................................................ 114
Figura 15 Indicação de vitória e derrota no jogo Pedra, papel ou tesoura .... 115
Figura 16 Resultado esperado para o jogo Simulação de Guerra .................. 116
Figura 17 Resultado esperado para o jogo Breakout ...................................... 117
Figura 18 Pacman: movimentação do personagem sobre as linhas da grade ....
............................................................................................................. 118
Figura 19 Pacman: substituição da imagem da grade pela imagem do labirinto
............................................................................................................. 118
Figura 20 Pacman: funcionamento do sprite indicador de colisão com uma
parede do labirinto ............................................................................. 119
Figura 21 Pacman: código para atualização das variáveis que indicam colisão
com uma parede do labirinto ............................................................ 119
Figura 22 Pacman: diagrama do funcionamento esperado dos fantasmas
inimigos............................................................................................... 120
Figura 23 Primeira questão do teste: expressões algébricas e identificação de
padrões ............................................................................................... 122
Figura 24 Segunda questão do teste: ângulo replementar ............................. 123
Figura 25 Terceira questão do teste: porcentagem ......................................... 123
Figura 26 Quarta questão do teste: coordenadas cartesianas e variação nos
eixos x e y ........................................................................................... 124
Figura 27 Quinta questão do teste: identificação de pontos no plano
cartesiano ........................................................................................... 125
Figura 28 Sexta questão do teste: distância entre pontos no plano cartesiano .
............................................................................................................. 125
Figura 29 Sétima questão do teste: aritmética e uso da divisão inteira......... 126
Figura 30 Oitava questão do teste: raciocínio combinatório .......................... 127
Figura 31 Frequência de uso de jogos digitais pelos participantes da Oficina ...
............................................................................................................. 135
Figura 32 Critérios de jogabilidade mais relevantes para os alunos brasileiros
............................................................................................................. 136
Figura 33 Critérios de jogabilidade mais relevantes para os alunos chilenos ....
............................................................................................................. 136
Figura 34 Encontro do gato com o rato: código vinculado ao sprite do gato e
fornecido inicialmente aos alunos .................................................... 138
Figura 35 Ambiente do laboratório de informática utilizado no IFSP para a
realização da Oficina .......................................................................... 138
Figura 36 Indicação das coordenadas cartesianas do ponteiro do mouse e do
sprite atual no sistema de coordenadas do palco do Scratch ....... 141
Figura 37 Uso de estruturas condicionais aninhadas para criar dois níveis de
dificuldade no Jogo de Pescaria ....................................................... 142
Figura 38 Solução para o funcionamento de um dos peixes no jogo de
Pescaria, incluindo o cálculo de porcentagem ................................ 142
Figura 39 Atribuição de valor a variável resultante da saída da função
“sorteie” .............................................................................................. 145
Figura 40 Ilustração
do
erro
de
Isabel
(P20):
comando
colocado
‘incorretamente fora do laço ............................................................. 146
Figura 41 Funcionalidade adicional feita por Andrés (P18) no Jogo de
Advinhação: dica informada por meio de um intervalo numérico . 148
Figura 42 Enumeração não-sistemática das possibilidades do jogo Pedra,
Papel e Tesoura feita por Isabel (P20) .............................................. 152
Figura 43 Enumeração sistemática das possibilidades do jogo Pedra, Papel e
Tesoura feita por Pedro (P31) ........................................................... 152
Figura 44 Versão do jogo Pedra, Papel e Tesoura com mensagem no fundo da
tela, e implementação mínima requerida para essa funcionalidade ....
............................................................................................................. 153
Figura 45 Código parcial para identificação do resultado final do jogo Pedra,
Papel e Tesoura .................................................................................. 154
Figura 46 Trecho de código para verificação da vitória no jogo Pedra, Papel
ou Tesoura utilizando “espera ocupada”......................................... 155
Figura 47 Solução proposta por
Fabrício (P14) para
o problema de
sincronização de jogadas no jogo Pedra, Papel e Tesoura............ 156
Figura 48 Erro na enumeração sistemática das possibilidades do jogo Pedra,
Papel e Tesoura feita por Bruno (P38).............................................. 157
Figura 49 Uso do comando “aponte para” para mudar a orientação da bala no
jogo Simulação de Guerra ................................................................. 159
Figura 50 Estrutura de repetição com teste de colisão com outro sprite no
jogo Simulação de Guerra ................................................................. 161
Figura 51 Código inicial para movimentação da bola no jogo Arkanoid ....... 163
Figura 52 Contorno do problema de colisão entre a bola e o bloco no jogo
Arkanoid .............................................................................................. 165
Figura 53 Código para identificar se o Pacman está posicionado sobre uma
linha horizontal e vertical ao mesmo tempo .................................... 166
Figura 54 Enumeração definida por Lucas (P4) das possíveis situações que
permitem a mudança de direção do Pacman................................... 168
Figura 55 Enumeração das possíveis situações para que o Pacman se
movimente quando não há um obstáculo a sua frente ................... 169
Figura 56 Estratégia para o fantasma patrulhador proposta aos alunos do
IFSP – Turma A ................................................................................... 170
Figura 57 Estratégia para o fantasma patrulhador proposta aos alunos do
IFSP – Turma B ................................................................................... 171
Figura 58 Diagrama ilustrando as tarefas da Oficina que envolvem o uso de
estruturas de repetição ...................................................................... 175
Figura 59 Uso de laço com número definido de iterações no jogo de Pescaria .
............................................................................................................. 175
Figura 60 Utilização do operador booleano OU no laço de repetição do Jogo
de Advinhação .................................................................................... 177
Figura 61 Exemplo de três estratégias para implementar a movimentação do
fantasma patrulhador no jogo Pacman ............................................ 179
Figura 62 Proporção de jogos desenvolvidos com funcionalidades mínimas e
funcionalidades adicionais................................................................ 181
Figura 63 Funcionalidade adicional: mensagem indicando o resultado do jogo
Pedra, Papel e Tesoura ...................................................................... 183
Figura 64 Solução para o disparo da bala no jogo Simulação de Guerra
utilizando o envio de mensagens ..................................................... 184
Figura 65 Funcionalidade adicional: animação de esmaecimento da barra no
jogo Arkanoid ..................................................................................... 185
Figura 66 Funcionalidade adicional: vários blocos no jogo Arkanoid ........... 186
Figura 67 Funcionalidade adicional: exibição da quantidade de vidas no jogo
Pacman................................................................................................ 187
Figura 68 Funcionalidade adicional: exemplo de tela inicial e de indicação de
fim de jogo no Pacman ...................................................................... 188
Figura 69 Funcionalidade adicional: frutas para obter pontuação extra no
Pacman................................................................................................ 188
Figura 70 Exemplo de sprite utilizado para detectar a posição da bola no jogo
Arkanoid .............................................................................................. 190
Figura 71 Exemplo de sprite utilizado para identificar a posição do Pacman .....
............................................................................................................. 191
Figura 72 Diagrama ilustrando as tarefas da Oficina que envolveram o uso de
colisão entre sprites .......................................................................... 192
Figura 73 Porcentagens de respostas corretas às questões do pré e pós-teste
............................................................................................................. 198
LISTA DE TABELAS
Tabela 1
Processos de abstração, automação e análise em três domínios
segundo Lee et al. (2011)................................................................... 40
Tabela 2
Revisão sistemática: estatísticas de estudos selecionados .......... 81
Tabela 3
Revisão sistemática: segmentação de estudos classificados como
discussão conceitual (DI) ou experiência didática (EXP), por base
de dados ............................................................................................. 82
Tabela 4
Revisão sistemática: segmentação de estudos por nível de ensino
do público-alvo ................................................................................... 83
Tabela 5
Revisão sistemática: ferramentas e materiais utilizados em
atividades "plugadas" e "desplugadas" .......................................... 85
Tabela 6
Revisão sistemática: classificação dos estudos pelo nível de
formalismo da avaliação da aprendizagem ..................................... 86
Tabela 7
Revisão
sistemática:
estudos
com
validação
formal
de
competências ou conteúdos matemáticos ...................................... 87
Tabela 8
Revisão sistemática: instrumentos de coleta de dados utilizados
em estudos com validação da aprendizagem ................................. 89
Tabela 9
Revisão
sistemática:
exemplos
de
conteúdos
matemáticos
desenvolvidos .................................................................................... 91
Tabela 10
Programação de atividades da Oficina de Produção de Jogos ... 110
Tabela 11
Jogos da Oficina e conceitos matemáticos ................................... 121
Tabela 12
Heurísticas extraídas de Barcelos et al. (2011) ............................. 129
Tabela 13
Quantidade de instâncias de cada jogo desenvolvido na Oficina .....
........................................................................................................... 174
Tabela 14
Estruturas de repetição utilizadas pelos alunos no Jogo de
Advinhação ....................................................................................... 176
Tabela 15
Estratégias utilizadas para implementar o fantasma patrulhador
(alunos do Brasil) ............................................................................. 179
Tabela 16
Funcionalidades adicionais no jogo Pedra, Papel e Tesoura ...... 182
Tabela 17
Funcionalidades adicionais no jogo Simulação de Guerra .......... 183
Tabela 18
Funcionalidades adicionais no jogo Arkanoid .............................. 185
Tabela 19
Funcionalidades adicionais no jogo Pacman ................................ 187
Tabela 20
Estratégias utilizadas para verificar posição da bola no jogo
Arkanoid............................................................................................ 190
Tabela 21
Estratégias utilizadas para verificar se personagem do jogo
Pacman entrou no túnel .................................................................. 191
Tabela 22
Categorias de análise para a questão “Você usou alguma
matemática para implementar os fantasmas?” ............................. 193
Tabela 23
Intenção dos alunos de acrescentar funcionalidades no jogo
Pacman e heurísticas associadas .................................................. 195
SUMÁRIO
CAPÍTULO 1
INTRODUÇÃO ............................................................................ 19
1.1
Objetivo ....................................................................................................... 23
1.2
Estrutura do texto ....................................................................................... 24
1.3
Contribuição e originalidade ..................................................................... 25
CAPÍTULO 2
FUNDAMENTAÇÃO TEÓRICA .................................................. 27
2.1
A natureza da Computação e sua relação com a Matemática ................ 27
2.2
Matemática no ensino e na prática profissional em Computação ......... 27
2.2.1
Matemática e desempenho acadêmico de alunos de Computação ....... 28
2.2.2
Competências, habilidades e conteúdos: algumas visões ..................... 29
2.2.3
Matemática e a prática profissional em Computação ............................. 34
2.3
Pensamento Computacional ..................................................................... 37
2.4
Construção de Jogos Digitais como estratégia didática ........................ 42
2.4.1
Jogos, design de interação e fluência digital........................................... 43
2.4.2
Construcionismo ........................................................................................ 46
2.4.3
Zona de Desenvolvimento Proximal ......................................................... 47
2.4.4
Experiências didáticas e seus resultados ................................................ 50
CAPÍTULO 3
METODOLOGIA DA PESQUISA................................................ 55
3.1
Revisão sistemática da literatura .............................................................. 56
3.2
Análise documental .................................................................................... 58
3.3
Etnografia .................................................................................................... 60
3.4
Quase experimentos (quasi-experiments) e pesquisa educacional ...... 62
3.5
Triangulação de métodos .......................................................................... 63
CAPÍTULO 4
PENSAMENTO COMPUTACIONAL E MATEMÁTICA .............. 67
4.1
Análise das diretrizes curriculares para o ensino de Matemática ......... 68
4.1.1
Competência 1 – Alternar entre diferentes representações semióticas 70
4.1.2
Competência 2 – Identificar regularidades e padrões ............................. 72
4.1.3
Competência 3 – Construir modelos descritivos e representativos ...... 74
4.2
Revisão sistemática da literatura .............................................................. 75
4.2.1
Planejamento .............................................................................................. 76
4.2.2
Estatísticas gerais dos estudos ................................................................ 81
4.2.3
Público-alvo ................................................................................................ 83
4.2.4
Ferramentas e materiais utilizados ........................................................... 84
4.2.5
Métodos e técnicas de pesquisa para avaliação da aprendizagem ....... 85
4.2.6
Competências, habilidades e conteúdos da Matemática ........................ 90
4.2.7
Discussões conceituais ............................................................................. 93
4.2.8
Conclusões da revisão sistemática .......................................................... 95
4.3
Implicações da análise de diretrizes curriculares e da revisão
sistemática para a pesquisa ...................................................................... 97
CAPÍTULO 5
OFICINA DE PRODUÇÃO DE JOGOS DIGITAIS ..................... 99
5.1
Contexto .................................................................................................... 100
5.1.1
O Instituto Federal de São Paulo............................................................. 100
5.1.2
A Universidad de Valparaíso ................................................................... 102
5.2
Paradigma estruturado e o ambiente de programação do Scratch ..... 103
5.3
Estrutura da Oficina ................................................................................. 107
5.3.1
Atividade 1: Encontro do gato com o rato ............................................. 110
5.3.2
Atividade 2: Pescaria................................................................................ 112
5.3.3
Atividade 3: Jogo de adivinhação ........................................................... 113
5.3.4
Atividade 4: Pedra, papel e tesoura ........................................................ 114
5.3.5
Atividade 5: Simulação de Guerra........................................................... 115
5.3.6
Atividade 6: Arkanoid ............................................................................... 116
5.3.7
Atividade 7: Pacman................................................................................. 117
5.4
Pré e pós-teste de conhecimentos matemáticos ................................... 121
5.4.1
Questão 1 – Expressões algébricas e identificação de padrões .......... 122
5.4.2
Questão 2 – Ângulo replementar............................................................. 122
5.4.3
Questão 3 – Porcentagem ........................................................................ 123
5.4.4
Questão 4 – Coordenadas cartesianas e variação nos eixos x e y ...... 123
5.4.5
Questão 5 – Identificação de pontos no plano cartesiano.................... 124
5.4.6
Questão 6 – Distância entre pontos no plano cartesiano ..................... 125
5.4.7
Questão 7 – Aritmética e o uso da divisão inteira ................................. 126
5.4.8
Questão 8 – Raciocínio combinatório..................................................... 126
5.5
Identificação do perfil dos alunos ........................................................... 127
5.6
Observação etnográfica das atividades de aula .................................... 129
5.7
Análise dos jogos produzidos pelos alunos .......................................... 130
5.8
Entrevistas finais ...................................................................................... 131
CAPÍTULO 6
RESULTADOS E ANÁLISE ..................................................... 133
6.1
Perfil dos participantes ............................................................................ 134
6.2
Observação etnográfica ........................................................................... 137
6.2.1
Atividade 1: Encontro do gato com o rato ............................................. 137
6.2.2
Atividade 2: Pescaria................................................................................ 140
6.2.3
Atividade 3: Jogo de adivinhação ........................................................... 144
6.2.4
Atividade 4: Pedra, Papel e Tesoura ....................................................... 150
6.2.5
Atividade 5: Simulação de Guerra........................................................... 158
6.2.6
Atividade 6: Arkanoid ............................................................................... 162
6.2.7
Atividade 7: Pacman................................................................................. 165
6.3
Jogos desenvolvidos ............................................................................... 173
6.3.1
Conceitos de programação ..................................................................... 174
6.3.2
Funcionalidades adicionais e jogabilidade ............................................ 180
6.3.3
Reconhecimento
de
padrões
e
reutilização
de
estratégias
de
construção ................................................................................................ 189
6.4
Entrevistas baseadas em artefatos ......................................................... 192
6.5
Pré e pós-teste de conhecimentos matemáticos ................................... 197
6.6
Discussão.................................................................................................. 200
6.6.1
Mobilização de conteúdos matemáticos ................................................ 200
6.6.2
Pensamento Computacional e a construção de jogos .......................... 206
6.6.3
Design de interação e funcionalidades adicionais nos jogos .............. 211
6.6.4
Desenvolvimento das competências comuns ....................................... 214
CONSIDERAÇÕES FINAIS .................................................................................... 219
REFERÊNCIAS
.................................................................................................. 225
Apêndice A
Dados da revisão sistemática da literatura........................... 237
Apêndice B
Rubrica educacional da Oficina ............................................. 245
Apêndice C
Material didático da Oficina .................................................... 251
Apêndice D
Questionário de levantamento de perfil ................................ 267
Apêndice E
Lista dos participantes da Oficina ......................................... 271
Apêndice F
Estatísticas do teste de conhecimentos matemáticos ........ 275
19
Capítulo 1
INTRODUÇÃO
A maioria das atividades econômicas da sociedade contemporânea está
intimamente ligada ao avanço científico e tecnológico da Computação e da
Tecnologia da Informação (TI). Por outro lado, se apresentam alguns entraves à
formação de recursos humanos nessas áreas. No Brasil, já há alguns anos verificase um déficit na formação de profissionais. Em um recente estudo da Associação
Brasileira de Empresas de Tecnologia de Informação e Comunicação (BRASSCOM)
estima-se que, em 2014, a demanda por profissionais de TI nos oito principais
mercados brasileiros (São Paulo, Rio de Janeiro, Distrito Federal, Paraná, Minais
Gerais, Bahia, Pernambuco e Rio Grande do Sul) chegará a 78 mil profissionais,
mas apenas 33 mil alunos concluirão os cursos superiores em Computação e TI
oferecidos no país nesse mesmo período.
Soma-se a esse quadro a diminuição na procura por cursos superiores em
Computação e TI e o alto índice de evasão nesses cursos, que seria de
aproximadamente 87%, sem considerar ainda a ociosidade de vagas em cursos da
área nas universidades e faculdades brasileiras (BRASSCOM, 2011). Porém, esse
quadro crítico não se apresenta apenas na realidade brasileira. Muratet et al. (2009)
afirmam que no período de 2005 a 2009 houve uma redução de cerca de 20% no
número de estudantes de Ciência da Computação na França, enquanto que
Crenshaw et al. (2008) reportam queda de 50% no interesse de estudantes
americanos pela área ao longo dos anos 2000. Essa diminuição do interesse dos
estudantes pela formação em Computação pode parecer paradoxal, em se tratando
de uma área com forte demanda por postos de trabalho. Além disso, o uso da
tecnologia
atualmente
permeia
várias
atividades
cotidianas
de
crianças,
adolescentes e jovens adultos, principalmente por meio de dispositivos digitais, tais
como computadores, celulares, tablets e videogames.
A singularidade da relação desses jovens indivíduos com a tecnologia fez
com que Prensky (2001) definisse o termo nativos digitais para se referir a eles.
Tapscott (2010) alternativamente utiliza o termo geração digital1 para descrever
1
Do original em inglês net generation.
20
algumas características desses indivíduos. Ambos os autores argumentam que os
jovens dessa nova geração têm uma postura mais ativa e exploratória frente à
tecnologia e são mais propensos a trabalhar de forma colaborativa, em grupos
menos hierarquizados do que aqueles frequentemente encontrados nas empresas
em um passado recente. Os argumentos de Prensky e Tapscott foram
posteriormente criticados pela falta de embasamento em evidências empíricas e
pelo apoio excessivo em argumentos de “senso comum” (BENETT; MATON;
KERVIN, 2008). Selwyn (2009) indica que os nascidos após os anos 1980 não se
constituem como uma geração homogênea no que se refere ao uso da tecnologia e
que esse uso pode ser mais passivo e desprovido de senso crítico do que se
esperaria a partir da definição de nativos digitais. No entanto, há evidências que,
pelo menos, o acesso à Internet e a dispositivos computacionais que possibilitam
esse acesso é um fenômeno crescente em todas as classes sociais. Por exemplo,
esse fato pode ser identificado no contexto latino-americano (RUIZ, 2013;
CETIC.BR, 2012), apesar do acesso dos jovens à tecnologia ser maior à medida que
aumenta a renda familiar.
A falta do domínio adequado de conhecimentos de Matemática pelos alunos é
um possível fator explicativo para a falta de interesse e evasão em cursos da área
de Computação. Uma revisão da literatura permite apontar que diversos
pesquisadores (CAMPBELL; MCCABE, 1984; WILSON; SHROCK, 2001; SETTI,
2009; ASSIS, 2011) indicam possíveis correlações entre o conhecimento
matemático prévio dos alunos e seu desempenho em cursos introdutórios de
Computação, bem como a relevância de tópicos do conhecimento matemático para
uma melhor compreensão e modelagem dos processos computacionais.
Porém, a relevância exata da Matemática para os alunos ingressantes em
cursos de Computação é ainda um tanto controversa. Ralston (2005) argumenta que
a maioria dos egressos dos cursos de Computação que atuarão profissionalmente
como engenheiros de software utilizarão pouca ou nenhuma Matemática de maneira
formal. No entanto, sua argumentação é feita em tom provocativo, com clara
intenção de fomentar a discussão sobre o tema. O autor reforça e admite a
importância da Matemática no desenvolvimento de habilidades essenciais, como o
raciocínio lógico. Ainda, argumenta que tópicos de Matemática Discreta tem
inicialmente um papel mais importante nesse desenvolvimento do que, por exemplo,
21
o Cálculo. Pioro (2006) corrobora essa tese com um estudo estatístico que indica a
correlação entre as notas de alunos em cursos introdutórios em Computação e as
notas dos mesmos alunos em disciplinas de Matemática Discreta.
Passar a considerar a Computação como uma ciência básica, ou seja, como
um tópico ou disciplina a ser abordada na Educação Básica, seria uma possível
iniciativa para reforçar a importância da Computação como uma área de
conhecimento relevante e útil para todos os estudantes. Tal iniciativa poderia
fomentar o interesse de mais estudantes por carreiras na área de Computação.
Frost et al. (2009) reportam que um currículo de referência para o ensino de
Computação na Educação Básica já é produzido desde 2003 nos Estados Unidos
pela Computer Science Teachers Association (CSTA), enquanto que até o presente
momento não há uma iniciativa semelhante no Brasil.
Nos últimos anos, o enfoque das diretrizes para o ensino de Computação na
Educação Básica tem gradualmente se afastado do mero uso da Computação – ou
seja, do domínio do uso de software para aplicações específicas – e se aproximado
do desenvolvimento de competências e habilidades relacionadas à compreensão,
projeto e construção de artefatos computacionais – ou seja, o fazer Computação
(HU,
2011).
Vários
autores
(BARR;
STEPHENSON,
2011;
FELLEISEN;
KRISHNAMURTHI, 2009; HU, 2011) sinalizam que esse domínio de competências e
habilidades, que naturalmente já são empregadas pelos cientistas da computação,
podem também ser aplicadas à compreensão de conteúdos de outras ciências
básicas como a Matemática.
Wing (2006) definiu o termo Pensamento Computacional2 para descrever tais
competências e habilidades. Entretanto, a argumentação da autora é baseada em
exemplos de atividades cotidianas, que poderiam ser compreendidas sob a ótica da
Computação, e na apresentação de algumas características gerais do que seria
essa modalidade de pensamento. Desde essa primeira tentativa de definição, vários
autores se debruçaram sobre a elaboração de uma “definição operacional” para o
Pensamento Computacional, de forma a embasar a criação de diretrizes
educacionais. Um dos resultados desse esforço foi a definição proposta pela CSTA
2
Do inglês Computational Thinking
22
(2011), segundo a qual o Pensamento Computacional seria uma “abordagem para a
resolução de problemas que possa ser implementada utilizando um computador”3.
A construção de artefatos computacionais pelos alunos é uma estratégia
didática para o desenvolvimento do Pensamento Computacional que vem sendo
frequentemente utilizada. Além de se relacionar com o “fazer Computação”, proposto
por Hu (2011), essa estratégia revisita a clássica proposta do construcionismo de
Papert (1980). Atualmente, as possibilidades de atividades que envolvam a
construção de artefatos computacionais se ampliam devido a uma maior
disponibilidade de ambientes de desenvolvimento voltados ao usuário principiante,
tais como Scratch (MIT MEDIA LAB, 2012), Alice (CARNEGIE MELLON
UNIVERSITY, 2013), Greenfoot (UNIVERSITY OF KENT, 2013), GameMaker
(YOYO GAMES, LTD., 2014) e Kodu Game Lab (MICROSOFT RESEARCH, 2014).
Tais ambientes permitem o desenvolvimento de jogos, animações e histórias
interativas com pouca ou nenhuma necessidade de conhecimentos prévios de
sintaxe de linguagens de programação.
O desenvolvimento de jogos digitais vem se mostrando como uma alternativa
promissora nesse contexto. Os jogos digitais estão inseridos no contexto cultural dos
nativos digitais de tal forma que Peppler e Kafai (2009) propõem que os estudantes
das novas gerações deveriam desenvolver uma fluência em jogos, ou seja, uma
maior compreensão das suas características enquanto mídia digital como, por
exemplo, sua mecânica e os procedimentos necessários para sua construção.
Alguns relatos da avaliação de atividades de criação de jogos digitais por estudantes
(DENNER; WERNER; ORTIZ, 2012; MALONEY et al., 2008) evidenciam que a
necessidade de incorporar aspectos de interação nos jogos pode ter contribuído para
um uso mais intensivo de algumas estruturas de programação ou mesmo a
aprendizagem de alguns conceitos por estudantes de forma autônoma, isto é, sem a
supervisão de instrutores.
Assim, a motivação desta pesquisa surge a partir de duas diferentes
constatações embasadas na revisão da literatura. Por um lado, a diminuição do
interesse em cursos de Computação e sua possível – porém não completamente
3
Do original: “CT is an approach to solving problems in a way that can be implemented with a
computer” (CSTA, 2011, p.10).
23
esclarecida – relação com os subsídios matemáticos previamente trazidos pelos
alunos. Por outro lado, a possibilidade do ensino da Computação como uma ciência
básica apoiar o ensino de Matemática a partir da construção de jogos digitais, que
pode se constituir como uma estratégia didática significativa para a geração dos
nativos digitais.
1.1 Objetivo
Frente ao exposto, esta pesquisa foi desenvolvida sob a hipótese que existe
uma influência mútua entre um subconjunto de competências e habilidades
relacionadas à Matemática e ao Pensamento Computacional. A partir dessa
hipótese, a pesquisa visa evidenciar quais competências e habilidades da
Matemática
e
do
Pensamento
Computacional
podem
ser
mobilizadas
e
desenvolvidas por alunos mediante atividades didáticas que envolvam a construção
de jogos digitais. As atividades práticas foram organizadas no formato de uma Oficina
de Produção de Jogos Digitais, inspirada pelos princípios do construcionismo
(HAREL; PAPERT, 1991) e da Aprendizagem Baseada em Problemas (MERRIL,
2002), que teve como público-alvo os alunos ingressantes em um curso técnico em
Informática em Guarulhos, Brasil, e os alunos ingressantes em um curso superior de
Engenharia Informática em Valparaíso, Chile.
De forma mais específica, o objetivo desta pesquisa é orientado pelas
seguintes questões norteadoras:
(Q1) Como conhecimentos prévios em Matemática podem ser mobilizados
durante o desenvolvimento do Pensamento Computacional?
(Q2) Que competências e habilidades do Pensamento Computacional são
desenvolvidas pelos alunos durante uma oficina de construção de jogos digitais?
(Q3) Como a construção de jogos digitais influencia a motivação dos alunos
para mobilizar e/ou desenvolver competências e habilidades?
(Q4) Como as competências e habilidades matemáticas dos alunos se
modificam ao longo da participação em uma oficina de construção de jogos digitais?
24
1.2 Estrutura do texto
No Capítulo 1, foram brevemente apresentadas a motivação e a justificativa
desta tese. No Capítulo 2, será apresentada a fundamentação teórica da pesquisa, a
partir de três eixos: as definições para o conceito de Pensamento Computacional
presentes na literatura; as relações construídas historicamente entre o corpo de
conhecimento da Matemática e da Computação; e a construção de jogos digitais
como estratégia didática e sua relação com os referenciais teóricos trazidos pelo
processo de design de interação (SALEN; ZIMMERMAN, 2003; WINOGRAD, 1997;
SCHÖN; BENNETT, 1996), pelo Construcionismo (PAPERT, 1980) e pela
perspectiva sociocultural do processo de ensino-aprendizagem de Vygotsky (1978).
No Capítulo 3 serão apresentados os fundamentos e a justificativa para a
utilização dos métodos utilizados no desenvolvimento desta tese. São eles: a revisão
sistemática da literatura e a análise documental, utilizados em um primeiro momento;
a etnografia, o quase experimento (SHADISH; COOK; CAMPBELL, 2002) e a
triangulação de métodos (incluindo novamente a análise documental), que são
utilizados em um segundo momento, na pesquisa de campo.
O Capítulo 4 descreve um estudo teórico que se constituiu como o primeiro
momento da pesquisa, mencionado acima. Nesse estudo, utilizou-se a análise
documental para explorar as relações entre o Pensamento Computacional e a
Matemática por meio de um mapeamento entre competências e habilidades
presentes em diretrizes curriculares para o ensino de Matemática e trabalhos da
literatura que discutem o conceito de Pensamento Computacional. A seguir, é
apresentada uma revisão sistemática da literatura, desenvolvida com o objetivo de
levantar e classificar estudos que envolvem o desenvolvimento conjunto de
competências e habilidades do Pensamento Computacional e da Matemática. Dessa
forma, pretende-se apresentar duas visões complementares dos avanços e lacunas
dessa área de estudo.
No Capítulo 5 é apresentado o trabalho em campo que se constitui como o
segundo momento da pesquisa. Inicialmente, é apresentada a estrutura e atividades
propostas para a Oficina de Produção de Jogos Digitais, sua relação com as
competências
e
habilidades
do
Pensamento
Computacional
e
conceitos
25
matemáticos, bem como o contexto que motivou sua criação. A seguir, são descritos
os procedimentos de coleta e análise de dados conduzidos com o objetivo de
continuar a exploração das questões de pesquisa propostas.
No Capítulo 6 são apresentados e discutidos os resultados obtidos a partir do
trabalho em campo. O capítulo inicia-se com uma descrição detalhada do perfil dos
alunos participantes e das atividades da Oficina que foram conduzidas nas
instituições nos dois países. A seguir, os jogos desenvolvidos pelos alunos são
analisados
na
perspectiva
dos
conceitos
relacionados
ao
Pensamento
Computacional e à Matemática que estão presentes. São descritos os resultados de
uma entrevista final com os alunos e de um teste de conhecimentos matemáticos,
instrumento do quase experimento empregado. A seguir, os resultados obtidos a
partir da construção de jogos digitais são analisados por meio da triangulação de
métodos nas seguintes perspectivas: mobilização de conhecimentos matemáticos;
desenvolvimento de competências e habilidades do Pensamento Computacional; a
influência do design de interação e da qualidade da interação dos jogos no
desenvolvimento do Pensamento Computacional; por fim, o desenvolvimento das
competências comuns, elencadas no Capítulo 4, é analisado na perspectiva dos
dados obtidos empiricamente. No Capítulo 7, são feitas as considerações finais da
pesquisa e apontados alguns possíveis trabalhos futuros.
1.3 Contribuição e originalidade
As contribuições desta tese para o estado da arte se concentram em três
pontos: o primeiro deles é o mapeamento de competências comuns à Matemática e
ao Pensamento Computacional, apresentado na seção 0, que pode organizar a
discussão e a definição de atividades didáticas nas quais se pretenda envolver o
desenvolvimento de ambas as áreas.
O
segundo
ponto
refere-se
a
um
conjunto
de
diretrizes
para
o
desenvolvimento de atividades didáticas envolvendo a construção de jogos digitais,
apresentado na seção 0, que propõe uma organização sistemática dos conteúdos a
serem mobilizados e desenvolvidos pelos alunos e leva em consideração a presença
dos jogos digitais como um elemento familiar para as novas gerações. Os resultados
da pesquisa de campo, em especial em termos da motivação dos alunos para a
26
participação nas atividades, são associados às diretrizes que foram utilizados na
definição da Oficina de Produção de Jogos Digitais e embasam esta contribuição.
Considerando que a pesquisa foi predominantemente desenvolvida seguindose o paradigma da pesquisa qualitativa, o terceiro ponto relaciona-se ao emprego
dos métodos e procedimentos de pesquisa. Esta tese apresenta uma descrição
aprofundada de um contexto real de aprendizagem, intencionalmente organizado
para o desenvolvimento do Pensamento Computacional e a mobilização da
Matemática. A análise do processo de ensino-aprendizagem nesse contexto real
utiliza a triangulação de dados para obter uma visão mais completa e precisa dos
fenômenos associados. A ausência de uma análise utilizando tais procedimentos de
validação se constitui como uma limitação das pesquisas já existentes, conforme é
discutido nas conclusões da revisão sistemática da literatura apresentada na seção
0.
A maioria das contribuições desta tese foi, até o presente momento, validada
pela comunidade científica por meio da publicação de artigos aceitos em
conferências e periódicos. Ao longo do texto serão informadas as partes do trabalho
que foram resultantes de tais publicações.
27
Capítulo 2
FUNDAMENTAÇÃO TEÓRICA
2.1 A natureza da Computação e sua relação com a Matemática
O início da história da Computação moderna (isto é, dos avanços
tecnológicos da Computação ao longo dos séculos XX e XXI) tem uma relação muito
próxima com a viabilidade da realização de cálculos numéricos. O clássico artigo de
Alan
Turing,
“On
computable
numbers,
with
an
application
to
the
Entscheidungsproblem” (TURING, 1936), que define as bases estruturais da
Computação como hoje é conhecida, é essencialmente uma prova matemática a
respeito da viabilidade da realização de cálculos numéricos a partir de uma máquina
conceitual, posteriormente denominada Máquina Universal de Turing. Porém, para
viabilizar a construção de máquinas de computação eletrônica e o posterior
desenvolvimento de linguagens de programação e compiladores, outras áreas do
conhecimento foram incorporadas à Computação de maneira a estruturar o seu
corpo de conhecimento (Body of Knowledge).
Denning (2005) discute que, ao longo do seu desenvolvimento e maturação,
as atividades da Computação buscaram suporte em três áreas distintas do
conhecimento, a saber: as ciências ditas naturais, a Engenharia e a Matemática. O
método científico, baseado no princípio da experimentação, é utilizado no
desenvolvimento de algoritmos heurísticos ou na definição de modelos para o
processo de desenvolvimento de software. Já o projeto e desenvolvimento de
software se constituem claramente como atividades de Engenharia, ou seja, da
aplicação da técnica. Por sua vez a Matemática, com sua representação simbólica e
sistema de dedução fundamentado em axiomas, é base para o estudo da
complexidade de algoritmos e da análise numérica.
2.1. Matemática no ensino e na prática profissional em Computação
Apesar de parte da fundamentação teórica da Computação ser proveniente
da Matemática, há uma discussão histórica na literatura sobre o exato papel da
Matemática dentro do currículo de cursos de Computação. Ralston e Shaw (1980)
argumentam que, no intervalo de dez anos entre a definição da primeira e da
28
segunda edições das recomendações curriculares da ACM para cursos de
graduação em Ciência da Computação, a quantidade de disciplinas de Matemática
consideradas obrigatórias havia diminuído de oito para cinco4. Além disso, tais
disciplinas deixaram de ser consideradas como pré-requisito para o estudo de vários
tópicos da Ciência da Computação, como Estruturas de Dados e Análise de
Algoritmos. Ainda segundo os autores, a recomendação da elaboração de
disciplinas de Matemática específicas para as necessidades dos estudantes de
Ciência da Computação havia sido, de certa forma, “abrandada” na segunda edição
do documento. Naquele momento, os autores consideraram como temerária essa
diminuição da importância e da contextualização da Matemática e recomendam
quais deveriam ser as bases de Cálculo, Matemática Discreta5 e Probabilidade e
Estatística que seriam mais importantes no estudo da Ciência da Computação.
2.1.1 Matemática e desempenho acadêmico de alunos de Computação
Na
mesma
época,
Campbell
e
McCabe
(1984)
tentaram
analisar
quantitativamente como o desempenho dos alunos ingressantes em cursos de
Ciência da Computação estaria correlacionado com seu desempenho em
Matemática. A partir de uma amostra de 256 alunos ingressantes em um curso de
graduação em Computação de uma universidade do meio-oeste americano, os
autores concluem que as notas de Matemática dos alunos no ensino médio, bem
como a nota nos exames SAT, são preditores estatísticos significativos da
continuidade do aluno no curso de graduação. O exame SAT é uma prova
padronizada, oferecida várias vezes ao ano, cujo resultado é utilizado como critério
de seleção ao ingresso na maioria das universidades americanas.
Wilson e Shrock (2001) desenvolveram mais recentemente um estudo
semelhante, porém mais abrangente, em que doze possíveis fatores de sucesso em
4
Na primeira edição das recomendações curriculares da ACM, de 1968, as disciplinas
obrigatórias em Matemática eram: Introdução ao Cálculo, Análise Matemática I, Probabilidade,
Álgebra Linear, Estruturas Discretas e Cálculo Numérico. Recomendava-se ainda a escolha de duas
dentre as seguintes disciplinas optativas: Análise Matemática II, Cálculo em Múltiplas Variáveis,
Estruturas Algébricas e Probabilidade e Estatística. Na atualização de 1978, a disciplina de Cálculo
Numérico foi suprimida, bem como as disciplinas optativas de Cálculo em Múltiplas Variáveis e
Estruturas Algébricas. Além disso, as disciplinas optativas deixaram de ser recomendadas a todas as
carreiras, resultando assim em um número mínimo de cinco disciplinas obrigatórias em Matemática.
5
Cerca de 25 anos depois, Ralston (2005) ainda apresenta o mesmo argumento; porém,
acredita que a ênfase da Matemática Discreta deve aumentar como uma primeira disciplina, enquanto
que, proporcionalmente, a relevância de um conhecimento aprofundado em Cálculo diminuiu.
29
um curso introdutório à Ciência da Computação são analisados: auto-avaliação dos
alunos sobre a importância de fatores para o sucesso na disciplina (sorte, esforço,
dificuldade das tarefas e habilidade); número de semestres em disciplinas de
Matemática cursadas no ensino médio; auto-avaliação de eficiência no domínio,
obtida a partir do somatório de respostas em um questionário padronizado
(RAMALINGAM; WIEDENBECK, 1998); estímulo externo (familiares, amigos) para
estudar na área; nível de conforto durante o andamento da disciplina (derivado de
sete questões sobre o nível de assistência obtida do professor e monitores ao tirar
dúvidas, dificuldade dos exercícios e dificuldade em compreender os conteúdos em
comparação com os colegas de classe); preferência de estilo de trabalho;
experiência prévia com programação de computadores; experiência prévia em uso
de computadores e gênero. A partir de um modelo de regressão linear combinando
os doze fatores, os autores concluem que dois fatores tem significativa correlação
positiva com a aprovação na disciplina: o nível de conforto e o número de semestres
de Matemática cursados no ensino médio. A auto-atribuição do sucesso na disciplina
à sorte tem correlação negativa com a aprovação na disciplina (como seria esperado
de forma intuitiva, inclusive).
2.2.2 Competências, habilidades e conteúdos: algumas visões
Ao explorar as relações presentes na literatura entre a Computação e a
Matemática, torna-se necessário definir em que nível essa comparação é feita, de
forma precisa (ou, ao menos, o mais precisamente possível) de forma a orientar os
esforços da pesquisa e facilitar a compreensão do leitor. Para tanto, antes de
prosseguir, é conveniente nos ancorarmos nos conceitos de competência e
habilidade, conforme definidos na literatura educacional.
O planejamento do trabalho escolar vem passando por um redirecionamento,
diminuindo-se a ênfase dada a uma simples definição de conteúdos a serem
apresentados e passando a se pautar pela identificação de competências a serem
desenvolvidas pelos estudantes. Segundo Valente (2003), tal redirecionamento tem
suas raízes históricas na Escola Nova ou Escola Renovada, buscando uma
aprendizagem mais direcionada à resolução de problemas reais. A autora ainda
afirma que essa tendência sofreu inicialmente a influência de uma visão tecnicista,
30
voltada ao mundo do trabalho, onde o “saber fazer”6 adquire uma importância
fundamental.
No entanto, a competência não se limita a uma mera operacionalização do
saber. Uma das principais características que pautam as definições de competência
presentes na literatura é a adaptabilidade do conhecimento a múltiplas situações. No
documento Competencias clave para un aprendizaje a lo largo de la vida, da
Comissão Europeia (2004, p. 7), indica-se que as competências são “um pacote
multifuncional e transferível de conhecimentos, destrezas e atitudes que todos os
indivíduos necessitam para sua realização e desenvolvimento pessoal, inclusão e
emprego”. Sob tal concepção, uma análise baseada em competências torna-se
conveniente no âmbito desta tese, já que pretende-se analisar a Computação e a
Matemática como duas áreas que, potencialmente, fazem com que o aluno construa
alguns saberes (ou competências) que seriam contextualizados de diferentes formas
em cada uma das áreas.
Se por um lado a ideia de competência tem sido intensamente mencionada
em diretrizes de currículo e avaliação, por outro lado perduram muitas incertezas e
imprecisões relacionadas à sua definição (VALENTE, 2003). Neste trabalho, optouse pela definição de Perrenoud (2007), segundo o qual competência é a faculdade
de mobilizar uma série de recursos cognitivos para solucionar com pertinência e
eficácia uma série de situações.
Segundo a definição acima, os recursos cognitivos relacionados a uma
competência são, necessariamente, de “alto nível”, envolvendo a capacidade de
abstração de modo a permitir sua aplicação não apenas a uma situação, mas a uma
série delas. Essa diferenciação nos permite compreender o conceito de habilidade
como uma tomada de ação mais específica, aplicada, operacional. Segundo
Perrenoud:
6
Oriunda dos quatro pilares da aprendizagem para o século XXI propostos por Delors (1998),
a saber: aprender a conhecer, aprender a fazer, aprender a conviver e aprender a ser.
31
A partir do momento em que ele fizer “o que deve ser feito” sem pensar
porque já o fez, não mais se fala em competências, mas sim em habilidades
ou hábitos. No meu entender, esses últimos fazem parte da competência
[...] Seria paradoxal que a competência desaparecesse no momento exato
em que alcança sua máxima eficácia.
(PERRENOUD, 1999, p. 26)
A noção de habilidade por vezes se confunde com a noção de competência
(VALENTE, 2003); porém, tomando a definição de Perrenoud (1999), no âmbito de
nossas futuras análises, é possível entender uma competência como composta por
uma ou mais habilidades, que por sua vez permitem a operacionalização da
competência a contextos específicos.
Porém, uma abordagem baseada em competências e habilidades não pode
prescindir de uma negação ou abandono dos conteúdos escolares concretos,
palpáveis. Para preencher essa potencial lacuna no arcabouço conceitual que está
sendo adotado, recorremos a Machado (2009), que indica que, para que uma
competência seja desenvolvida, é fundamental que o aluno possa mobilizar e
articular conteúdos que já aprendeu anteriormente. Complementando essa visão,
Perrenoud (1999, p. 22) afirma que “construir uma competência significa aprender a
identificar e a encontrar os conhecimentos pertinentes” e daí transformá-los e aplicálos ao contexto necessário.
Alguns autores vinculados à prática docente em Computação procuraram
discutir nos últimos anos qual seria exatamente essa relação entre os conteúdos
matemáticos e a aprendizagem da Computação. Beaubouef (2002) argumenta que
competências e habilidades relacionadas à resolução de problemas matemáticos
são necessárias para o estudante de Ciência da Computação. A autora cita com
exemplo de uma habilidade fundamental a capacidade de compreender o que
significa uma solução adequada para um dado problema. Também é apresentada a
relevância de vários conteúdos matemáticos ao estudo da Computação. Para a
programação de computadores, é mencionada a necessidade de se ter um
adequado domínio da aritmética (incluindo aí a divisão inteira, pouco ou nada
enfatizada após os primeiros anos da educação básica), funções, o conceito de
variável na Álgebra. O estudo dos bancos de dados relacionais exige o domínio dos
conceitos de conjuntos e relações entre conjuntos. O estudo de outras áreas da
Computação exige o conhecimento de tópicos de Matemática Discreta e Cálculo,
32
tipicamente abordados já no ensino superior. Por exemplo, o estudo da Inteligência
Artificial tem como pré-requisitos o conhecimento da teoria dos grafos e do cálculo
de predicados. A autora também menciona a necessidade de se estudar árvores,
relações e provas por indução para compreender a Análise de Algoritmos, e do
estudo de representações como os gráficos de Gantt para cálculos de caminho
crítico em projetos de Engenharia de Software.
Bruce et al. (2003) discutem a importância da Matemática Discreta para a
resolução de problemas em Computação a partir de alguns problemas de pesquisa.
Inicialmente, os autores ilustram seu argumento mencionando o problema da
implementação de vetores com capacidade de alocação dinâmica, ou seja, um vetor
que aumenta seu tamanho toda vez que a capacidade de armazenamento se
esgota. Uma possível estratégia nessa situação seria alocar um novo espaço de
memória, maior que o anteriormente disponível, e copiar os elementos atualmente
no vetor para essa nova área de memória. Para decidir qual deve ser o tamanho
desse espaço adicional de forma a minimizar o custo de novas inserções (ou seja, o
tempo necessário para copiar os elementos do vetor a cada nova alocação de
espaço), é necessário aplicar algum conhecimento sobre séries geométricas.
Problemas de otimização, como escalonar o atendimento de táxis em uma cidade
que recebe um grande evento esportivo, podem recair um problema do tipo NPCompleto7, e identificar tal situação exige conhecer os procedimentos necessários
para redigir uma prova matemática. Os autores ainda abordam o problema da
especificação formal de sistemas computacionais, técnica que visa assegurar os
resultados produzidos por um programa. A técnica apresenta certo grau de
complexidade, porém é necessária para sistemas críticos, tais como o controle de
aviação. A prova formal do funcionamento de sistemas exige a modelagem
utilizando estruturas como árvores e o uso de técnicas de demonstração matemática
como a indução. Krone et al. (2011) também defendem a prova formal da corretude
7
Problemas computacionais para os quais não existe um algoritmo capaz de produzir uma
solução em tempo polinomial (ou seja, cujo tempo de execução pode ser expresso através de um
polinômio em função do tamanho dos dados de entrada). Problemas NP-Completos só podem ser
resolvidos por algoritmos do tipo “força-bruta”, ou seja, testando-se todas as possibilidades de saída
para uma dada entrada e analisando qual (ou quais) saídas atendem às restrições do problema. A
definição de NP-completude indica que, dada uma instância de solução para o problema, existe um
algoritmo de verificação que executa em tempo polinomial ao tamanho da entrada (CORMEN;
LEISERSON; RIVEST, 1989).
33
de sistemas como uma ferramenta didática relevante no ensino, bem como também
enfatizam a importância da Matemática Discreta.
O professor Peter Henderson contribuiu com uma seção intitulada Math
Counts (“Matemática importa”, em uma tradução livre) na revista Inroads da ACM,
que é focada na comunicação de resultados de pesquisas e pontos de vista sobre
educação em Computação. A seção discutia, utilizando variadas abordagens, a
importância da Matemática para o ensino de Computação. Destacamos aqui duas
contribuições de Henderson a essa discussão. A primeira é seu artigo “Mathematical
reasoning in Computing education” (HENDERSON, 2011), em que o autor
inicialmente defende a importância de que o currículo de cursos de Computação
incorpore ao menos duas disciplinas de Matemática Discreta, ao menos uma de
Cálculo (de forma a apresentar as diferenças entre o raciocínio discreto e o
contínuo), tópicos de Álgebra Linear e Probabilidade e Estatística, uma disciplina de
tópicos avançados, e uma disciplina de teoria de autômatos para alunos que
considerem seguir estudos em nível de pós-graduação. Além disso, o autor aponta a
dificuldade, enfrentada atualmente pelas universidades, para que os alunos
consigam contextualizar a Matemática que aprendem nas disciplinas introdutórias
em problemas das disciplinas de formação específica em Computação.
A segunda contribuição é trazida em conjunto com Maria Letvin e Gary Litvin
no artigo “Pre-college Math Concepts vs Skills: Preparation for Computing Studies”
(HENDERSON; LETVIN; LITVIN, 2007), onde os autores argumentam que o
pensamento abstrato é a principal contribuição que o ensino de Matemática pode
oferecer, durante o ensino médio, para um futuro estudante de Computação.
Criticam ainda o que seria uma abordagem para o ensino de Matemática no ensino
médio americano muito voltada ao desenvolvimento de habilidades (no original,
skills) e que pouco enfatiza o desenvolvimento de competências relacionadas ao
pensamento rigoroso8. Seria ainda desejável que a Matemática ensinada se
relacionasse de alguma forma com as tecnologias do mundo atual, corroborando a
ideia anterior. Álgebra Booleana, circuitos, grafos e combinatória são propostos
como tópicos simples, sem pré-requisitos conceituais mais complexos do que a
Álgebra do ensino médio, mas que são raramente ensinados nas escolas norte8
Acreditamos que essa crítica dos autores também se aplicaria ao ensino médio brasileiro.
34
americanas. Um exemplo bem-sucedido de contextualização que atende à proposta
de Henderson e colegas é o projeto “Sem Matemática não existe Computação”
(SCAICO et al., 2011), que visa o desenvolvimento de atividades didáticas que
contextualizam tópicos de Matemática do ensino médio a temas como a
manipulação de imagens e desenvolvimento de jogos digitais 2D.
Vimos que as competências e habilidades relacionadas à resolução de
problemas, bem como aos conteúdos de Matemática Discreta, são frequentemente
mencionados nas argumentações dos autores. Outro trabalho de base quantitativa
realizado por Pioro (2006) vem complementar essa constatação. O autor analisa as
notas obtidas por 96 alunos na última prova da disciplina Programming II, cursada
por alunos de Ciência da Computação, Engenharia Elétrica e Sistemas de
Informação de uma universidade da Carolina do Norte, Estados Unidos. As notas
foram analisadas em comparação com as notas dos mesmos alunos em Matemática
Discreta, Cálculo I e Cálculo II. Verificou-se então que, para os grupos de alunos que
já haviam cursado Cálculo I e Matemática Discreta, as notas da disciplina de
programação tem forte correlação com a nota média das disciplinas de Matemática.
Já para alunos que não tem Matemática Discreta na grade (caso do curso de
Engenharia Elétrica), essa correlação não se faz presente. Pioro argumenta que os
processos de resolução de problemas aprendidos na disciplina de Matemática
Discreta podem ter contribuído com os resultados.
2.2.3 Matemática e a prática profissional em Computação
Ralston (2005) argumenta que, se fosse considerado apenas o estado atual
da prática profissional em Computação, não haveria bons argumentos para ensinar
qualquer Matemática nos cursos superiores da área. Apesar do argumento ser uma
clara provocação com o objetivo de chamar à atenção do leitor (o autor
posteriormente tece considerações favoráveis ao ensino de Matemática), Ralston
desconsidera como a Matemática pode ser apropriada de formas não previstas em
um ambiente profissional. Noss et al. (2000) identificam em um estudo etnográfico
com profissionais de outras áreas que a utilização de estratégias matemáticas para a
resolução de problemas do ambiente de trabalho pode acontecer de forma nãoconvencional; ou seja, a Matemática está presente, seja na forma de estratégias
35
mentais de aproximação ou algoritmos específicos para o domínio, mas sua forma e
linguagem não são aquelas da Matemática escolar.
Uma evidência representativa desse fenômeno na prática profissional em
Computação (inclusive pela carência até o momento de pesquisas nessa linha) pode
ser encontrada na tese de Assis (2011), desenvolvida no Programa de PósGraduação em Educação Matemática da PUC/SP. A autora investiga os paralelos
entre os processos cognitivos de resolução de problemas em Matemática e os
processos de manutenção de sistemas de software desenvolvidos pelos profissionais
de uma empresa multinacional americana, prestadora de serviços na área de
consultoria, desenvolvimento e manutenção de software. Trinta e quatro profissionais
de um mesmo departamento da empresa foram os sujeitos de pesquisa. Os
participantes informaram, por meio de uma entrevista prévia, qual foi sua formação
técnica na área de Computação (graduação e pós-graduação, quando aplicável),
idade, cargo atual na empresa, e como caracterizavam o seu desempenho em
disciplinas técnicas e em disciplinas de Matemática na graduação. Durante cinco dias
de trabalho, os participantes executaram em seus computadores de trabalho uma
aplicação de logging que registrava todas as interações do usuário com programas
(inicialização e término de programas, interação via mouse e teclado, mudança de
foco entre janelas de programas abertos, dentro outros) e também solicitava que o
usuário, a cada 15 minutos, escrevesse uma curta mensagem indicando qual o
objetivo do seu trabalho naquele momento, e no que ele estaria pensando. O usuário
poderia utilizar até 300 caracteres em cada mensagem ou mesmo se abster de
escrever qualquer mensagem quando assim o desejasse.
As
mensagens
informadas
pelos
participantes
foram
posteriormente
analisadas utilizando-se a grounded theory (teoria fundamentada) de Glasser e
Strauss. A partir de tal análise foram identificadas quatro categorias conceituais dos
dados. Assis (2011) identifica uma aproximação entre essas categorias e algumas
heurísticas para resolução de problemas matemáticos discutidas por Polya (1995):
•
Busca sistemática de padrões: o processo de manutenção de sistemas
muitas vezes envolve a identificação, pelo programador, de módulos ou
funcionalidades semelhantes que possam ser reaproveitadas, substituindo-se
parâmetros de entrada de dados ou alterando-se ligeiramente a especificação
36
do processamento. Diniz associa essa categoria às heurísticas de analogia,
identificação de problemas correlatos e abstração definidas por Polya (1995).
•
Independência: nessa categoria estão agrupados os eventos que indicam a
necessidade do programador utilizar sua autonomia e senso crítico, no sentido
da necessária familiaridade com as estratégias de manutenção, bem como o
questionamento sobre a validade dos resultados obtidos após a aplicação das
mesmas. Essa categoria é associada às heurísticas de demonstração por
absurdo, demonstração indireta e decomposição e recomposição.
•
Julgamento: relaciona-se às boas práticas de programação, à percepção que
o programador deve ter sobre as possíveis implicações de uma alteração local
no código no sistema como um todo, bem como aos aspectos de autoregulação utilizados pelo programador. Esta categoria é comparada à última
fase de resolução de um problema matemático conforme definida por Polya,
que é o retrospecto da solução obtida. Entretanto, há a ressalva que um
programa de computador não precisa necessariamente estar em um estado
completo para que essa atividade se realize.
•
Originalidade:
refere-se
aos
momentos
em
que
os
programadores
identificaram possibilidades de inovar nas soluções propostas durante o
processo de manutenção de software. A inovação pode estar tanto
relacionada a manter a qualidade atual do sistema ou mesmo a antever
implicações futuras na manutenção, à medida que o sistema pode aumentar
seu escopo. Essa categoria é associada ao processo de intuição que Polya
indica que pode ser desenvolvido a partir da extensiva prática na resolução de
problemas.
No processo de análise que culminou na definição das categorias acima, é
identificado ainda mais um indício relevante da relação entre a formação matemática
prévia dos participantes e sua prática profissional. Os quatro participantes que
indicaram, na entrevista prévia, que seu desempenho em Matemática na graduação
foi insatisfatório, tiveram o registro de suas ações analisado em detalhe, quando
verificou-se que esses profissionais gastaram grande parte do seu expediente de
trabalho na atividade de testes, e um tempo muito menor na escrita de especificações
técnicas ou na efetiva alteração dos programas. Esse resultado pode indicar que
37
esses profissionais utilizaram uma abordagem de tentativa-e-erro para resolução dos
problemas, ao invés de alguma abordagem mais sistemática.
Dessa forma, a tese de Assis (2011) vem corroborar, com um experimento
bastante detalhado, os pontos de vista apresentados por Henderson et al. (2007),
Pioro (2006), Ralston (2005) e Beaubouef (2002), que indicam de várias formas que
a contribuição da Matemática para o ensino de Computação pode estar, em sentido
amplo, nas competências relacionadas à resolução de problemas matemáticos. Por
outro lado, a comunidade de Educação em Computação vem indicando que a
Computação também pode ter seus mecanismos particulares de abordar e resolver
problemas. Na próxima seção, começamos a explorar quais são esses mecanismos,
de forma a posteriormente compreender suas possíveis relações com a Matemática.
2.3 Pensamento Computacional
Apesar de buscar seus fundamentos em outras áreas, a Computação parece
trazer mecanismos singulares de raciocínio para a resolução de problemas, cujas
aplicações ultrapassam as fronteiras da Computação em si. Pode-se considerar, por
exemplo, as recentes aplicações de métodos computacionais a questões de
pesquisa da Biologia e das Ciências Sociais, permitindo a análise de uma
quantidade de dados muito superior ao que seria possível sem atacar tais questões
sob um ponto de vista computacional. No contexto educacional, algumas aplicações
dos mecanismos de raciocínio inerentes à Computação têm sido reportadas tanto
em áreas próximas à Computação, como o design de games (SETTLE, 2011),
quanto em áreas em que essa relação não é tão direta, como a química, física e
biologia (AHAMED et al., 2010; QIN, 2009).
Como outras áreas do conhecimento podem se beneficiar de parte das
competências específicas da Computação, torna-se conveniente então definir quais
seriam tais competências. Um trabalho pioneiro nessa direção foi o artigo de Wing
(2006) no periódico Communications of the ACM. A autora argumenta mediante de
vários exemplos como aspectos da Ciência da Computação estão presentes na vida
cotidiana e poderiam ser ensinados a crianças e adolescentes de forma a possibilitar
uma melhor compreensão de um mundo permeado por dispositivos computacionais.
Por exemplo, uma criança arrumando a mochila para ir à escola, empacotando os
38
itens que vai necessitar durante o dia, está criando um tipo de memória cache.
Escolher a melhor fila no supermercado envolve conceitos de escalonamento de
processos. Explicar como um telefone funciona mesmo na ausência de energia
elétrica envolve conceitos de redundância e tolerância a falhas. A partir dessa
argumentação, Wing define o nome Pensamento Computacional para se referir ao
conjunto de competências e habilidades da Computação que podem ser úteis em
outras áreas do conhecimento. As características propostas pela autora para o
Pensamento Computacional são os seguintes:
•
Conceituar ao invés de programar. Resolver um problema aplicando o
pensamento
computacional
significa
reduzir
problemas
grandes
e
aparentemente insolúveis em problemas menores e mais simples de resolver.
Isso exige a capacidade de pensar de forma abstrata e em múltiplos níveis, e
não a mera aplicação de técnicas de programação;
•
É
uma
habilidade
fundamental
e
não
utilitária.
O
pensamento
computacional não é uma habilidade mecânica ou utilitária, mas algo que
permite a resolução de problemas diversos utilizando um recurso ubíquo na
sociedade atual – os computadores – e por isso deveria ser desenvolvido por
todos os estudantes;
•
É a maneira na qual pessoas pensam e não os computadores. A
resolução de problemas utilizando o pensamento computacional é um
tratamento especifico do problema de forma que ele possa ser resolvido por
computadores
e
não
uma
redução
do
raciocínio
para
simular
o
processamento do computador;
•
Complementa e combina a Matemática e a Engenharia. A definição de
Wing considera o aporte da Matemática e da Engenharia para a Computação,
conforme mencionamos anteriormente, e reconhece as particularidades
trazidas pelo enfoque computacional;
•
Gera ideias e não artefatos. O pensamento computacional não deve ter
necessariamente como resultado final a produção de software e hardware e
reconhece que os conceitos fundamentais da Computação estarão presentes
para resolver problemas em vários contextos do cotidiano;
•
Para todos, em qualquer lugar. Por fim, o pensamento computacional pode
ser útil para todas as pessoas, em diversas aplicações.
39
O conceito de Pensamento Computacional foi, desde então, detalhado e
discutido por vários autores. Hu (2011) argumenta que Wing, na realidade, não traz
uma definição precisa, indicando, por exemplo, quais seriam os elementos,
estruturas ou peculiaridades do Pensamento Computacional. Porém, o valor de uma
definição precisa também é questionado pelo autor. Segundo Hu, é possível que
alguns aspectos do Pensamento Computacional tenham sido usados até mesmo
antes do advento dos computadores modernos. Nesse sentido, o Pensamento
Computacional pode ser visto como uma mistura de elementos de raciocínio
previamente relacionados a outros paradigmas – lógico, matemático, analítico ou
orientado à engenharia. Dessa forma, ainda segundo Hu, introduzir uma cultura do
fazer Computação pode ser a maneira mais eficaz de fomentar o Pensamento
Computacional em diferentes níveis educacionais.
Essa visão do Pensamento Computacional orientada à execução de
atividades pode também ser identificada na discussão apresentada por Lee et al.
(2011). Os autores relatam experiências didáticas previamente desenvolvidas com o
objetivo de desenvolver competências e habilidades do Pensamento Computacional
e identificam três domínios promissores para promover o engajamento dos
estudantes: modelagem e simulação (por exemplo, de fenômenos biológicos),
robótica, e projeto e desenvolvimento de jogos digitais. Três habilidades
fundamentais foram identificadas no processo de resolução de problemas
empregado pelos alunos participantes das atividades: abstração, automação e
análise. Na concepção assumida pelos autores, a abstração é o processo de
identificação das características essenciais de uma classe de situações que
constituem um problema, eliminando as características de casos particulares que
não são importantes para sua solução. A automação é o processo de delegar tarefas
repetitivas para um computador por meio da programação ou da definição de
parâmetros em um software específico. A análise é o processo final de validação da
automação construída, a fim de verificar se o processo foi bem-sucedido. Na Tabela
1 transcrevemos os exemplos do processo de abstração, automação e análise
apresentados por Lee et al. (2011) em cada um dos três domínios indicados.
40
Tabela 1 – Processos de abstração, automação e análise em três domínios segundo
Lee et al. (2011)
Abstração
Selecionar
características do
mundo real a serem
incorporadas no
modelo
Automação
Análise
Simulação do modelo
passo-a-passo
As abstrações corretas
foram feitas?
O modelo corresponde
à realidade?
Robótica
Projetar um robô para
reagir a um conjunto
de condições
O programa verifica
sensores para
monitorar condições
Há situações que não
foram levadas em
consideração?
Jogos digitais
Jogos são abstraídos
para um conjunto de
cenas, contendo
personagens
O jogo responde a
ações do usuário
Os elementos
incorporados fazem
com que o jogo seja
divertido?
Modelagem e
simulação
O processo de abstração pode levar à construção de modelos que
representam a realidade de alguma forma. Com base nessa associação, Isbell et al.
(2010) apresentam uma visão alternativa sobre o Pensamento Computacional. A
partir da consolidação dos resultados de um debate sobre a natureza da
Computação conduzido com o objetivo de orientar o currículo de cursos de
graduação, os autores concluem que o conceito de computação estaria centrado na
produção de modelos representativos de um determinado domínio, modelos esses
que devem ser expressos em uma determinada linguagem e que podem ser
manipulados, interpretados e modificados por uma máquina. Nesse caso os
conceitos chave que permeiam o Pensamento Computacional9 são: modelos;
abstração; interpretação (de dados ou padrões); escala e limites para o
processamento; simulação de sistemas a partir de modelos e possibilidade de
automação dos modelos. Podemos constatar algumas similaridades com a definição
de Wing, especialmente nos conceitos de abstração e limites. No entanto, a ideia da
construção de modelos permite uma aproximação específica com a Matemática que
será retomada mais adiante neste capítulo.
Barr e Stephenson (2011) relatam os resultados de um grupo de trabalho com
o objetivo de produzir uma definição operacional de Pensamento Computacional
9
Isbell
et
al.
optam
por
usar
o termo computationalist
thinking (“pensamento
computacionalista”, em uma tradução livre) para ressaltar que a ênfase do conceito argumentado está
na forma de pensar “de quem faz computação”. Do original: “(...) the mindset or way of thinking of
computationalists (that is, those who do computing).”
41
para orientar a produção de diretrizes curriculares do ensino de Computação na
educação básica norte-americana. Os resultados do grupo de trabalho incluem uma
lista abrangente de conceitos-chave do Pensamento Computacional e uma
discussão sobre como esses conceitos se relacionam com a Ciência da
Computação e com disciplinas da educação básica. Os conceitos incluídos são:
coleta, análise e representação de dados, decomposição de problemas, abstração,
algoritmos e procedimentos, automação, paralelização e simulação. Os autores
apresentam alguns exemplos de conteúdos de disciplinas da educação básica
(Matemática, Ciências, Estudos Sociais, Línguas e Artes) nos quais cada um dos
conceitos enumerados pode ser aplicado.
É possível identificar alguma convergência entre as definições apresentadas
por Lee et al. (2011), Barr e Stephenson (2011) e Isbell et al. (2010). Os três
trabalhos indicam que aplicar o Pensamento Computacional pode estar fortemente
relacionado à abstração de um processo (ou seja, a identificação de seus aspectos
fundamentais) de forma a permitir sua automação. Essa abstração pode ser
concebida mediante a coleta e análise de dados, e então representada através de
um modelo para permitir sua implementação em um computador em um formato
algorítmico.
Em outra direção está a definição proposta por Basawapatna et al. (2011),
que define o Pensamento Computacional através de padrões de funcionalidades
identificadas em jogos digitais implementados por estudantes usando uma
linguagem de programação visual. Essa proposta é notavelmente mais específica
que as anteriores por não definir o Pensamento Computacional como um paradigma
de raciocínio, mas sim apresentar o seu potencial para transferência de
competências para outros domínios. Segundo os autores, os padrões identificados
podem também ser encontrados em simulações de fenômenos físicos e biológicos,
permitindo que os alunos também compreendam tais fenômenos através, por
exemplo, da construção de simulações. Os padrões identificados são: geração,
colisão, transporte, difusão e hill climbing10. A transferência de competências é um
10
Termo da área de Inteligência Artificial utilizado para descrever um algoritmo de otimização
em que, a partir de uma solução arbitrária para um problema, uma melhor solução é buscada
alterando um único elemento da solução anterior, assemelhando-se assim ao processo de escalada
em uma montanha (RUSSELL; NORVIG, 2003). O algoritmo itera até que não haja melhora na
42
aspecto fundamental da discussão das relações entre o Pensamento Computacional
e a Matemática; esse tema é retomado e aprofundado no Capítulo 3.
2.4 Construção de Jogos Digitais como estratégia didática
A construção de jogos digitais por alunos tem sido utilizada como uma
estratégia para o desenvolvimento de competências e habilidades em áreas
relacionadas ao Pensamento Computacional (SETTLE, 2011), raciocínio lógico
(SOUZA; DIAS, 2012) e fundamentos de programação (HERNANDEZ et al., 2010).
Uma das razões frequentemente mencionadas para a utilização de tais estratégias é
a atração que os jogos proporcionam para os estudantes das novas gerações.
Prensky (2001) definiu o termo nativos digitais para se referir a esses indivíduos.
Nascidos após a década de 1990, muitos deles tiveram acesso a variados
dispositivos computacionais interativos, como telefones celulares, computadores e
videogames desde a infância. Dessa forma, a familiaridade desses indivíduos com
tais dispositivos tende a ser maior do que aquela apresentada pelos seus pais e
professores, pertencentes a gerações anteriores (e chamados por Prensky de
imigrantes digitais).
Os jogos digitais têm assumido uma posição de destaque dentre os
dispositivos computacionais presentes no cotidiano das novas gerações. Segundo
Salen (2007, p. 302), os jogos digitais se constituem como “portas de entrada de
vários jovens ao letramento digital, a comunidades sociais, e à definição de sua
identidade como indivíduos fluentes em tecnologia11”. Em uma recente pesquisa do
CETIC.BR sobre o uso de Tecnologias da Informação e Comunicação por crianças e
jovens brasileiros, verificou-se que do universo de entrevistados, abrangendo todas
as regiões do país e variados estratos sociais, 35% dos jovens de 11 a 16 anos
afirmam ter utilizado a Internet para jogar com outras pessoas todos os dias ou
quase todos os dias; 45% dos entrevistados da mesma faixa etária afirma realizar
essa atividade uma ou duas vezes por semana. 19% dos entrevistados realizam a
atividade esporadicamente, uma ou duas vezes por mês, e apenas 1% não
solução encontrada, caracterizando-se pela localização de um máximo (ou mínimo) local como
solução.
11
Do original: “(…) entry points for many young people into digital literacy, social communities,
and tech-savvy identities”.
43
souberam responder (CETIC.BR, 2012). Assim, mesmo desconsiderando o uso de
jogos em outras plataformas como consoles e computadores pessoais, é possível
afirmar que os jogos digitais constituem uma mídia com a qual os alunos das novas
gerações estão, no mínimo, bastante familiarizados.
2.4.1 Jogos, design de interação e fluência digital
Para a área de Interação Humano-Computador, um jogo digital pode ser
entendido como um tipo específico de sistema interativo. Uma definição para o
processo de interação, no escopo dessa área, é dada por Norman (1986), que o
define como o processo através do qual o usuário formula uma intenção e planeja
suas ações sobre uma interface. Uma vez que o usuário atua sobre a interface, esta
produz uma resposta, percebida pelo usuário, que avalia se seu objetivo foi atingido
ou não. A interface, por sua vez, é constituída de todas as partes do sistema com as
quais o usuário mantém contato motor ou perceptual durante a interação (MORAN,
1981). Dessa forma, no modelo mental do usuário regular, a interface pode se
constituir como o próprio sistema (HIX; HARTSON, 1993).
A partir dessas definições é possível constatar a importância da qualidade do
projeto de uma interface para que um sistema interativo possa ser efetivamente
utilizado por seus usuários. Dessa forma, o projeto da interface assume as
características do projeto de um artefato de comunicação com o usuário, não se
limitando aos aspectos técnicos inerentes ao processo de programação de
computadores, apesar de estar vinculado a estes. Winograd (1996, 1997) organizou
de forma pioneira a percepção que o projeto de um sistema interativo se constitui
como uma atividade de design de interação. O autor enumera algumas
características do design que se aplicam ao design de interação: ele é uma atividade
consciente, que busca manter os objetivos do ser humano no centro do processo; é
uma atividade criativa, inerentemente social, que busca comunicar a intenção do
designer e as possibilidades de uso através do objeto que está sendo construído.
Ainda, trata-se de um processo iterativo e emergente, que exige do designer a
percepção das possibilidades e limitações que surgem ao longo do processo, se
constituindo assim como uma reflexão em ação (SCHÖN; BENNETT, 1996) sobre os
materiais que são utilizados no processo, sejam eles tangíveis ou não.
44
Por ser um sistema interativo, o jogo digital também é construído por meio do
processo de design de interação. No entanto, há características particulares de um
jogo que devem ser levadas em consideração no processo de design. Segundo
Salen e Zimmerman (2003, p. 80), um jogo é um “sistema no qual os jogadores se
engajam em um conflito artificial, definido por regras e que resulta em um resultado
quantificável”12. As regras constituem o aspecto formal e determinístico de um jogo;
segundo Schell (2008), as regras em um jogo digital se relacionam aos seguintes
aspectos:
•
Espaço: definição dos possíveis locais em que o jogo ocorre, e a relação
entre eles. Nessa concepção, o espaço é puramente abstrato e limita como
as ações do jogo podem ocorrer. Por exemplo, o espaço de um jogo da velha
é uma grade de 3x3 espaços, onde cada espaço pode ser preenchido com
um único caracter; o espaço de um jogo de futebol é bidimensional, no qual
se deslocam os jogadores.
•
Objetos: são os elementos que preenchem o espaço do jogo. Cada objeto
tem atributos que o descreve e pode estar em diferentes estados.
•
Ações: representam a enumeração das operações que podem ser feitas pelo
jogador para interagir com o mundo do jogo. Usualmente, as ações em um
jogo digital são limitadas, mas devem passar ao jogador uma sensação de
razoável liberdade, dentro do contexto proposto pelo espaço do jogo.
•
Habilidades: podem ser pré-requisitos para que o jogador seja capaz de
tomar as ações necessárias no jogo, ou mesmo habilidades que são
desenvolvidas ao longo do próprio jogo. Manter o nível de desafio, ou seja,
equilibrar as regras do jogo de modo que as ações requeridas estejam
sempre ligeiramente acima do nível de habilidade do jogador, é um dos
princípios que garantem a qualidade do design.
•
Aleatoriedade: a inserção de elementos probabilísticos nas regras de um jogo
diminui a percepção do jogador de que o comportamento do jogo pode ser
totalmente previsto. A criação de eventos incertos que surpreendam o jogador
é outro dos princípios fundamentais da qualidade do design de um jogo.
12
Do original em inglês: “A game is a system in which players engage in an artificial conflict,
defined by rules, that results in a quantifiable outcome” (SALEN; ZIMMERMAN, 2003)
45
Os princípios enumerados acima ilustram uma das singularidades do jogo
digital em relação a outros sistemas interativos: a qualidade de um jogo não está
diretamente relacionada à facilidade de uso, mas à diversão proporcionada pela
atividade de jogar. Em última instância, a busca de elementos lúdicos orienta a
maioria dos aspectos do design do jogo.
As particularidades dos jogos digitais enquanto sistemas interativos e sua
ampla inserção no cotidiano de crianças e adolescentes já levantou discussões
sobre a necessidade de se fornecer subsídios para que as novas gerações adquiram
maior compreensão e visão crítica sobre os jogos. Peppler e Kafai (2009, p. 46)
discutem as concepções de vários autores que argumentam que os jogos digitais
são uma “mídia cultural” em seus próprios termos, e defendem que compreender as
características dessa mídia por meio da produção de artefatos digitais faz parte de
uma educação crítica. As autoras definem a fluência em jogo13 como “as habilidades
necessárias para projetar, modificar e jogar jogos, refletir criticamente sobre jogos,
engajar-se em produções artísticas, e levar em consideração a fluência tecnológica
necessária para jogar e construir jogos”14. Naturalmente, no escopo desta pesquisa
a fluência tecnológica é de particular interesse, por suas relações com o
Pensamento Computacional. Salen (2007) corrobora que o design de jogos em um
contexto educacional vai além do mero ensino de programação, podendo fomentar
competências relacionadas à modelagem de sistemas, estética, escrita de histórias
– e, logicamente, design de interação. Buckingham (2007) estende esse conceito
para as mídias digitais em geral, argumentando que as instituições educacionais
deveriam fomentar as habilidades criativas e críticas das crianças frente a essas
mídias. A necessidade de se desenvolver uma “fluência digital” nas crianças e
jovens é ressaltada por Resnick et al. (2009) em sua discussão sobre o ambiente de
programação Scratch.
O desenvolvimento da fluência em jogos pode ser considerado como uma
possível resposta à critica de Selwyn (2009), alertando que, atualmente, a relação
dos jovens com o conteúdo online se caracteriza mais como um consumo passivo
13
Do original gaming fluencies. Preferimos a tradução fluência em jogo pela própria
observação do texto original das autoras, que entendem que tal fluência não estaria restrita ao
artefato jogo em si, mas também ao processo de interação com ele.
14
Do original: “Gaming fluencies include the abilities to design, modify, and play games, to
reflect critically on games, to engage in artistic production, and to bring to bear the technology
fluencies needed to produce and play games”.
46
do que como uma criação ativa de conteúdo. O autor ainda argumenta que
“professores, bibliotecários e outros ainda possuem um papel valioso de autoridade
para educar, informar, gerenciar e dirigir as atividades tecnológicas de crianças e
jovens”. Ressalte-se que atividades que fomentem a fluência em jogos podem estar
inseridas nesse contexto15.
2.4.2 Construcionismo
A construção de artefatos digitais por estudantes como uma estratégia de
construção de conhecimento antecede em muito a sua contextualização no domínio
dos jogos digitais. A linguagem Logo, desenvolvida no final da década de 1960 por
Seymour Papert e Wally Feurzeig, foi uma das primeiras ferramentas de software
que ajudariam a modelar o paradigma de ensino-aprendizagem posteriormente
denominado por Papert (1980) de construcionismo. O termo é derivado diretamente
do construtivismo de Piaget, e compartilha com essa teoria o conceito de que a
aprendizagem acontece com a construção de estruturas de conhecimento pelo
próprio estudante, por meio das suas ações sobre o mundo que o rodeia.
Adicionalmente, o construcionismo situa a aprendizagem no contexto da construção
de “artefatos públicos e compartilhados” (HAREL; PAPERT, 1991). Tais artefatos
são tipicamente digitais, como software, imagens ou jogos, mas podem inclusive ser
artefatos físicos. Harel e Papert (1991) citam como exemplo uma atividade
construcionista que utiliza apenas pedaços de corda e é baseada na construção de
famílias de nós pelos alunos. Então, o papel proeminente do computador como
ferramenta de criação em atividades construcionistas reside na grande variedade de
contextos para construção de artefatos que podem ser proporcionados.
Como mencionado anteriormente, a construção de jogos digitais assume
características do processo de design, em particular aquela que Schön denomina
reflexão em ação (SCHÖN; BENNETT, 1996). Schön cita como exemplo desse
processo um software que foi inicialmente criado para o cálculo da resistência de
estruturas, no qual o usuário desenhava a estrutura de forças de uma ponte,
15
Na visão de Buckingham (2007), seria possível (e desejável) desenvolver a fluência em
outras mídias além dos jogos digitais. Concordamos com essa visão e acreditamos que o design de
interação poderia ser aplicado, em um contexto educacional, a outras mídias interativas. A escolha
pelos jogos digitais se deu pelas características motivacionais inerentes a essa mídia.
47
indicava uma determinada carga, e o software mostrava a deflexão das estruturas. O
software foi utilizado por alunos de engenharia do MIT e teve uma aceitação muito
maior do que softwares educacionais em que os mesmos conceitos eram
simplesmente apresentados16. Construir o modelo da ponte consistia em um
processo de reflexão-em-ação para os alunos: interagir com o modelo, obter
resultados às vezes surpreendentes, construir suas próprias explicações e inventar
novas estratégias de ação. A autonomia do pensamento proporcionada pelo
processo de construção de um artefato é uma característica crucial do
construcionismo.
2.4.3 Zona de Desenvolvimento Proximal
Além da interação com o próprio meio (ou mídia) de construção do artefato
computacional, as interações sociais entre os alunos engajados no processo, e
destes com o professor, também devem ser consideradas na análise do fenômeno
de aprendizagem. Esse aspecto vai ao encontro da visão sociocultural do processo
de aprendizagem discutida por Vygotsky (1978). É particularmente interessante
nesse contexto o conceito de Zona de Desenvolvimento Proximal (ZDP), segundo o
qual as experiências de aprendizagem devem se situar o máximo possível em uma
zona “intermediária”. Abaixo dessa zona estariam as atividades que o aluno é capaz
de fazer sozinho, sem nenhum auxílio; acima dessa zona estariam as atividades que
o aluno não é capaz de fazer, dado seu desenvolvimento cognitivo até o presente
momento. Uma representação esquemática das três zonas de desenvolvimento é
apresentada na Figura 1. A Zona de Desenvolvimento Proximal consiste então nas
tarefas que o aluno é capaz de fazer desde que auxiliado por professores ou por
colegas com maior habilidade.
16
Essa é a mesma dicotomia entre o instrucionismo e o construcionismo discutida por Kafai
(2006), apesar de Schön não usar esses termos.
48
Aprendiz não é capaz de fazer
Aprendiz é capaz de fazer de maneira
independente
Zona de Desenvolvimento Proximal
Figura 1 – Representação esquemática da Zona de Desenvolvimento Proximal
Uma atividade construcionista de produção de jogos digitais, analisada sob o
ponto de vista do design de software, pode ser vista como uma atividade social,
segundo Winograd (1996). Dessa forma, analisando-se essa atividade sob o ponto
de vista do processo de ensino-aprendizagem, também é possível encontrar suporte
ao seu desenvolvimento na teoria de Vygotsky. Em termos práticos, a atividade de
construir um jogo digital assume um caráter inerentemente social, “livre”, quando é
conduzida em um laboratório de computadores tal como ele é estruturado em muitos
ambientes escolares de hoje. Esse aporte teórico já foi incorporado em experiências
didáticas anteriores: por exemplo, Harel (1991) discute o papel da instrução na
manutenção da ZDP em um estudo prolongado com alunos de 4ª série que
desenvolvem jogos digitais para o ensino de frações para seus colegas mais novos.
Mais recentemente, Basawapatna et al. (2013) propõem, a partir de sua
experiência com atividades didáticas de construção de jogos digitais, uma
associação
do
conceito
de
ZDP
com
a
teoria
do
fluxo
(NAKAMURA;
CSIKSZENTMIHALYI, 2009). A teoria do fluxo, na psicologia, refere-se a um estado
prolongado de concentração e imersão que equilibra a habilidade de superar
desafios com a complexidade dos desafios propostos. Quando o desafio supera
largamente as habilidades do indivíduo, advém um estado de ansiedade; já quando
o desafio é inferior às habilidades do indivíduo, o resultado é tédio e desmotivação
49
(Figura 2). Tal teoria pode ser aplicada a várias áreas da atividade humana e vem
sendo empregada para embasar princípios de game design.
desafio
ansiedade
Fluxo
tédio, desmotivação
Habilidade
Figura 2 – Esquema indicativo da Teoria do Fluxo
Fonte: Basawapatna et al. (2013) – traduzido
Na associação proposta por Basawapatna et al. (2013), nas atividades de
construção de jogos o estado de fluxo é inicialmente pressuposto pelo aspecto
motivador inerente à atividade. A introdução de conceitos do Pensamento
Computacional deve ser feita à medida que se mostram necessários para o
desenvolvimento do jogo, colocando assim os alunos na ZDP. A introdução de
conceitos antes da sua efetiva aplicação a um projeto real levaria ao estado de
desmotivação, onde se encontra o paralelo com a Teoria do Fluxo (Figura 3).
desafio
ansiedade
ZDP
Conceitos ao longo do projeto
Fluxo
Conceitos antes do projeto
tédio, desmotivação
habilidade
Figura 3 – Associação da Zona de Desenvolvimento Proximal à Teoria do Fluxo e sua
aplicação à construção de jogos digitais
Fonte: Basawapatna et al. (2013, p. 5) – traduzido
50
Dessa forma, por um lado esta tese se apoia no aspecto social da construção
de jogos digitais compreendido como uma atividade de design e, assim, envolvendo
a interação de um aluno com seus pares. Por outro lado, também identifica e
reconhece o papel do professor como um agente social relevante nesse processo,
tanto como organizador e planejador das atividades a serem desenvolvidas pelos
alunos quanto como mentor e orientador durante o desenvolvimento das mesmas.
Em cada um dos momentos mencionados, o professor planeja e atua como
responsável por manter os alunos dentro da Zona de Desenvolvimento Proximal.
2.4.4 Experiências didáticas e seus resultados
Uma vez que o aspecto motivacional relacionado a atividades de construção
de jogos pareça evidente, nos deparamos com a questão sobre o que os alunos
aprendem ao se engajar em atividades desse tipo, e de que forma eles aprendem.
Recentes trabalhos identificados na literatura reportam que justamente o
engajamento dos alunos na atividade pode trazer expressivos resultados de
aprendizagem de conceitos relacionados ao Pensamento Computacional e à área de
Ciências e Matemática, mesmo fora do ambiente escolar formal. Maloney et al.
(2008) analisaram 425 projetos feitos no Scratch por crianças e adolescentes em
atividades extraclasse desenvolvidas em um centro comunitário de acesso a
computadores.
Identificou-se
que
muitos
projetos
incorporaram
conceitos
computacionais razoavelmente complexos, como interação com o usuário (53,6%
dos projetos), laços de repetição (51,8%) e sincronização entre processos (24,7%).
Um fator relevante é que, no contexto do centro comunitário, o uso do Scratch foi
livre e não-supervisionado, ou seja, não houve o suporte de qualquer curso ou
treinamento formal. Além disso, foi possível inferir que o uso do Scratch pelos jovens
foi frequente, apesar de várias outras ferramentas estarem disponíveis nos
computadores do centro. Essa constatação foi obtida a partir de anotações em
campo registradas pelos monitores do centro comunitário e de entrevistas com
usuários do centro. Acredita-se que a mecânica simplificada de funcionamento da
ferramenta, bem como o feedback imediato fornecido pela mesma tenha atraído os
alunos para seu uso. No entanto, é feita a ressalva que outros conceitos
computacionais, como o uso de variáveis, foi pouco identificado, em apenas 9,6%
dos projetos analisados; baseando-se em observações in loco, os autores acreditam
51
que o domínio dos jogos digitais não traz oportunidades tão frequentes de aplicação
de alguns conceitos, ou mesmo que o suporte de um instrutor seja necessário em
tais situações.
Stolee e Fristoe (2011) realizam uma análise semelhante na comunidade
online Xbox Live, que permite que os usuários do Kodu Game Lab publiquem os
projetos de jogos desenvolvidos com a ferramenta. Neste caso, o trabalho é
organizado em torno de três perguntas de pesquisa: (i) quais conceitos
computacionais podem ser expressos utilizando o Kodu Game Lab? (ii) quanto
tempo os usuários gastam projetando os aspectos gráficos e codificando durante
uma sessão de uso do Kodu? (iii) com que frequência os conceitos computacionais
podem ser identificados nos projetos publicados na comunidade online? Em uma
análise inicial da ferramenta, os autores identificaram que os seguintes conceitos
podem potencialmente ser expressos através da ferramenta: variáveis com escopo
local e global, geração de números aleatórios, lógica booleana (negação, conjunção
e disjunção), instanciação de objetos (por meio da “clonagem” de personagens) e
controle de fluxo utilizando a transição entre páginas de código. Uma análise da
interação dos usuários com a ferramenta mostrou que os usuários passaram, em
média, 30,2% do tempo codificando ou modificando parâmetros do jogo (e 22% do
tempo efetivamente jogando!). Ao contrário do estudo de Maloney et al. (2008), os
autores identificaram um expressivo uso de variáveis, em mais de 60% dos projetos;
entretanto, tal resultado pode ter sido enviesado pelo fato dos projetos analisados
terem sido selecionados pelos próprios usuários para publicação, e por isso podem
ter um nível de complexidade maior. O aspecto motivacional do uso do Kodu Game
Lab para aspectos relacionados ao raciocínio lógico no ensino médio, em especial
sua linguagem baseada em regras, é brevemente discutido por Souza e Dias (2012).
Marinho et al. (2011) relatam uma experiência didática realizada com alunos
do ensino médio em uma escola pública do estado do Rio de Janeiro. Em encontros
semanais, no contraturno das aulas, os alunos foram apresentados ao ambiente do
Scratch e desenvolveram várias atividades relacionadas ao desenvolvimento de
jogos digitais relacionados a conteúdos do currículo escolar a partir de ideias
fornecidas pelos professores de disciplinas de Química, Espanhol e Educação
Física. A pesquisa foi conduzida com base na técnica de observação participante e
os autores apresentam, a partir da descrição de episódios dessa observação, alguns
52
achados parciais da pesquisa: (i) os conteúdos matemáticos de variável, parâmetro
de função e coordenadas cartesianas são mobilizados pelos alunos para o
posicionamento de objetos na tela do Scratch; (ii) foi possível promover
oportunidades de colaboração e cooperação entre os alunos, e entre estes e o
professor; (iii) foi possível constatar um visível engajamento nos alunos; (iv) as
atividades promoveram a mobilização interdisciplinar de conhecimentos, à medida
que os alunos produziam jogos com conteúdo educacional; (v) a diversidade de
ideias em sala de aula pôde ser promovida, ideias essas relacionadas às propostas
para resolver problemas que surgiam durante a construção dos jogos.
Um resultado similar quanto ao uso da ferramenta Scratch é apresentado por
Taylor et al. (2010), que analisam sob a perspectiva de Vygotsky o uso da lousa
digital como plataforma de colaboração e compartilhamento de conhecimento entre
alunos de 10 anos na Nova Zelândia. São descritos episódios de atividades em que
os alunos são solicitados a movimentar objetos na tela em uma trajetória quadrada,
retangular e circular. Posteriormente, os alunos constroem protótipos de jogos de
labirinto. Em sua análise, os autores constataram que alunos com bom
desenvolvimento de competências e habilidades em matemática exploraram com
sucesso conceitos de perímetro, ângulos e coordenadas cartesianas para resolver
problemas que surgiram ao longo das atividades. Ainda, que mesmo alunos com
dificuldade em Matemática e baixa sociabilidade se dispuseram a colaborar com
seus pares e lidar com desafios conceituais. Os autores argumentam que a lousa
digital ofereceu suporte para que os alunos desenvolvessem uma “cognição
compartilhada socialmente”. Porém, ressalvam que as diferentes soluções
possibilitadas pelo ambiente do Scratch podem levar alunos a explorar tópicos
matemáticos completamente diferentes.
Hernandez et al. (2010) descrevem uma experiência didática com alunos do
primeiro semestre de um Curso Superior de Tecnologia. A disciplina de Lógica de
Programação do curso foi reformulada para utilizar o GameMaker como ferramenta
para a construção de jogos digitais que motivaram a apresentação dos tópicos
tradicionais da disciplina. O conceito de variável foi inicialmente introduzido por meio
de variáveis disponibilizadas automaticamente pela ferramenta, representando a
quantidade de vidas, pontuação e nível de “saúde” do jogador. Posteriormente, os
alunos definiam comportamentos personalizados para as variáveis utilizando
53
pequenos trechos de código. Estruturas condicionais foram introduzidas para lidar
com eventos como a colisão entre dois objetos, a identificação do vencedor do jogo
ou o início de uma nova fase. Já as estruturas de repetição tiveram seu uso
motivado pela mudança gradual de características visuais do jogo. A taxa de
aprovação na disciplina, bem como a quantidade de exercícios entregues pelos
alunos aumentou após a experiência, o que pode indicar uma maior motivação dos
alunos em aprender os fundamentos de programação mediante a nova estratégia
proposta.
Experiências como a apresentada por Hernandez et al. (2010) indicam que
estudantes de graduação também podem se beneficiar de estratégias didáticas
envolvendo a construção de jogos. Malan e Leitner (2007) apresentam uma
disciplina de Lógica de Programação em nível de graduação que foi modificada de
forma a apresentar os fundamentos de programação usando o Scratch.
Posteriormente, a sintaxe da linguagem Java foi apresentada, estabelecendo as
relações com as estruturas fundamentais vistas no Scratch. A partir de um
questionário respondido pelos alunos ao longo da disciplina, foi possível identificar
que 75% dos respondentes tiveram a percepção que a abordagem diferenciada para
a disciplina os auxiliou a lidar com a complexidade da sintaxe da linguagem de
programação. Adicionalmente, o ambiente do Scratch parece ter permitido que os
alunos inicialmente se concentrassem apenas nos aspectos lógicos dos projetos
desenvolvidos.
Outras experiências semelhantes na graduação são descritas por Rizvi et al.
(2011), Leutenegger (2006) e Bayliss e Strout (2006). Tais experiências no ambiente
escolar são relevantes, pois se constituem como um campo de experimentação
voltado à necessidade de se resolver um problema atual – a evasão nos cursos de
Computação, que foi discutido na introdução desta tese. Apesar do desenvolvimento
do Pensamento Computacional não se reduzir ao mero aprendizado da
programação de computadores, a partir dos trabalhos apresentados nesta seção é
possível constatar que aspectos de programação devem ser aprendidos e
mobilizados, de alguma forma, para viabilizar a construção de jogos como estratégia
didática para o desenvolvimento do Pensamento Computacional.
54
É possível constatar que a avaliação das experiências apresentadas, em
particular no ambiente escolar, tem se baseado na análise das notas obtidas pelos
alunos, na observação in loco ou na identificação da auto-avaliação dos alunos
sobre sua motivação com a experiência. Entretanto, poucos estudos têm lidado com
a questão das competências e habilidades que podem ter sido realmente adquiridas
pelos alunos a partir do seu engajamento em uma experiência desse tipo. Estudos
com esse enfoque são frequentemente direcionados a atividades extra-curriculares
de incentivo e divulgação da área de Ciência da Computação (FRANKLIN et al.,
2013; ADAMS; WEBSTER, 2012; DENNER; WERNER; ORTIZ, 2012) e em geral
são focados em verificar como habilidades relacionadas à programação foram
adquiridas pelos alunos. No entanto, pouca atenção tem sido dada a competências e
habilidades mais gerais que tais atividades de programação possam desenvolver ou
mobilizar, de forma a identificar possíveis relações com outras áreas do
conhecimento.
55
Capítulo 3
METODOLOGIA DA PESQUISA
As atividades de pesquisa relacionadas a esta tese foram divididas em dois
momentos razoavelmente distintos: o primeiro deles envolveu a identificação de
competências comuns entre o Pensamento Computacional e a Matemática por meio
de uma análise documental (LÜDKE; ANDRÉ, 1986) das diretrizes curriculares para
o ensino de Matemática nas séries finais da educação básica no Brasil17 e no
Chile18. Ainda nesse primeiro momento, foi realizada uma revisão sistemática da
literatura (KITCHENHAM, 2004) para mapear os trabalhos anteriores sobre o tema,
suas abordagens de pesquisa e seus resultados, com o objetivo de identificar as
lacunas do estado da arte. Dessa forma, durante esse primeiro momento, foram
buscados subsídios para o posterior desenvolvimento de uma intervenção didática e
para responder a questão de pesquisa Q1: Como conhecimentos prévios em
Matemática podem ser mobilizados durante o desenvolvimento do Pensamento
Computacional?
A partir da identificação das competências comuns e das limitações de
trabalhos anteriores, no segundo momento é então proposta uma intervenção
didática, a Oficina de Produção de Jogos Digitais, que foi oferecida aos alunos
ingressantes em cursos na área de Informática nas instituições participantes da
pesquisa, no Brasil e no Chile, durante o primeiro semestre de 2013. Nesse segundo
momento, a pesquisa passou a ser conduzida na perspectiva de uma etnografia
educacional (GOETZ; LECOMPTE, 1984); adotou-se novamente a análise
documental, desta vez relacionada aos artefatos produzidos pelos alunos durante a
Oficina. A análise dos dados obtidos a partir da etnografia e dos artefatos produzidos
pelos alunos foi realizada por meio da triangulação (CRESWELL; MILLER, 2000), de
forma a obter mais subsídios para responder às quatro questões de pesquisa
definidas na seção 0. Complementando a coleta de dados realizada durante a
intervenção didática, a pesquisa ainda se apoiou em um quase experimento
(SHADISH; COOK; CAMPBELL, 2002), baseado na mensuração, por meio de um
17
Orientações Curriculares Complementares aos Parâmetros Curriculares Nacionais – PCN+
Ensino Médio (BRASIL, 2002)
18
Objetivos fundamentales y contenidos mínimos obligatórios de la Educación Media (CHILE,
1998)
56
pré-teste e de um pós-teste, do conhecimento dos alunos participantes da Oficina
em tópicos de Matemática que potencialmente seriam mobilizados durante a
realização da mesma.
Assim, neste capítulo será apresentada a fundamentação teórica dos
métodos e técnicas de pesquisa empregados e sua contextualização às diferentes
etapas da pesquisa. Para maior clareza, os métodos e técnicas serão apresentados
em uma perspectiva mais ampla, e os procedimentos específicos de coleta e análise
de dados serão detalhados nos capítulos subsequentes. O leitor poderá encontrar
identificações, sempre que aplicável, do ponto posterior do texto no qual a utilização
de cada método ou técnica será retomada.
3.1 Revisão sistemática da literatura
Uma parte significativa da identificação do estado da arte para esta pesquisa
foi realizada por meio de uma revisão sistemática da literatura. Esta é uma técnica
de identificação, análise e interpretação de evidências relacionadas a um
determinado tema de pesquisa, tópico ou fenômeno de interesse (KITCHENHAM,
2004). A técnica surgiu no âmbito da pesquisa em Medicina, mas, ao longo dos anos
2000, passou a também ser incorporada como uma técnica de pesquisa na
Engenharia de Software Experimental (BRERETON et al., 2007), devido à
necessidade de construir novo conhecimento naquela área a partir de evidências
empíricas. Mais recentemente, temos exemplos da aplicação da revisão sistemática
da literatura especificamente a tópicos de pesquisa em Informática na Educação,
como a utilização da robótica como estratégia didática (BENITTI, 2012) e o impacto
e resultados da utilização de jogos digitais para fins de aprendizagem e engajamento
(CONNOLLY et al., 2012).
O princípio que direciona a realização de uma revisão sistemática da literatura
é a obtenção de um panorama, o mais completo e preciso possível, dos resultados
já obtidos em um determinado tema de pesquisa. Isso se torna mais viável já que
uma grande quantidade de estudos se encontra disponível atualmente em bases de
dados online. Dessa forma, é necessária a definição de procedimentos rigorosos
para identificação, análise e interpretação dos estudos que sejam considerados
relevantes. Neste trabalho, foram adotadas as diretrizes propostas por Kitchenham
57
(2004), a partir de revisões sistemáticas na área de medicina, e posteriormente
sistematizadas por Wohlin et al. (2012). As diretrizes propõem a execução de
atividades em três grupos: planejamento, condução e relato de resultados.
O planejamento de uma revisão sistemática inicia-se com a própria
identificação da necessidade de uma revisão, que pode ser justificada pelas lacunas
de revisões já disponíveis na literatura. No caso desta tese, uma busca em bases de
dados relacionadas a trabalhos acadêmicos nas áreas de Educação, Informática na
Educação e Ensino de Computação não permitiu a identificação de nenhuma revisão
sistemática relacionando o Pensamento Computacional e a Matemática. Devido ao
fato da pesquisa sobre o Pensamento Computacional ser razoavelmente recente,
pelo menos dentro do arcabouço conceitual proposto por Wing (2006), acredita-se
ser esta uma iniciativa pioneira.
O próximo passo consiste na definição de uma pergunta de pesquisa a ser
respondida com a revisão sistemática. No contexto original da Engenharia de
Software experimental, sugere-se que a pergunta de pesquisa esteja relacionada a
algum dos seguintes aspectos: a população para a qual a evidência é coletada; a
intervenção aplicada no estudo empírico; a comparação entre populações
empregada; os resultados do experimento; o contexto do experimento; o design
experimental. A definição da pergunta de pesquisa deve delimitar claramente os
estudos que serão obtidos, evitando assim a criação de uma revisão impossível de
se gerenciar.
Por fim, deve-se definir um protocolo de revisão, que é a formalização dos
procedimentos para busca e seleção dos estudos, que permite tanto a condução da
revisão, em termos práticos, quanto a verificação de sua validade. A definição de um
protocolo de revisão se inicia com a seleção das bases de dados a serem
consultadas; então, é feita a definição da string de busca a ser executada em cada
base de dados, de forma a obter os estudos a serem potencialmente incluídos na
revisão. Então, definem-se procedimentos e critérios para a inclusão e exclusão de
estudos que forem obtidos na busca. Tais critérios devem ser definidos antes da
execução das buscas, de forma a evitar um viés na seleção. Um procedimento
adicional em algumas revisões é a definição de critérios de qualidade dos estudos,
em
termos
dos
métodos
empregados.
Posteriormente,
são
definidos
os
58
procedimentos para extração de dados dos estudos, de acordo com a pergunta de
pesquisa definida. Tais dados podem ser puramente quantitativos, quando o objetivo
da revisão é conduzir uma meta-análise de resultados, ou pode envolver também
dados qualitativos, como os métodos de pesquisa empregados, a caracterização dos
sujeitos de pesquisa ou as conclusões obtidas.
Devido ao fato da relação entre o Pensamento Computacional e outras áreas
do conhecimento ser um tema de pesquisa relativamente recente, foi constatado que
seria viável definir uma revisão sistemática mais abrangente de forma a identificar as
tendências de pesquisa de forma mais precisa. Os procedimentos detalhados para
condução da revisão e sua análise, que incluiu 55 artigos, serão apresentados na
seção 0.
3.2 Análise documental
A análise documental envolve o estudo de evidências que podem estar
contidas em vários tipos de documentos – cartas, manuais, discursos, leis,
anotações – desde que se constituam como fontes primárias, ou seja, não tenham
passado por nenhum tratamento analítico (SÁ-SILVA; ALMEIDA; GUINDANI, 2009).
Lüdke e Andre (1986) argumentam que o uso de documentos na pesquisa
educacional é relevante e deve ser explorada com o objetivo de identificar
problemas que poderão ser, posteriormente, melhor explorados por outros métodos.
Nesse contexto, que documentos deveriam ser analisados? Corseti (2006, p. 33),
descrevendo as experiências em um programa de pós-graduação em Educação,
indica os documentos que devem ser analisados:
[...] documentos legais (sobretudo a legislação), os diferentes materiais
escolares (cadernos e livros escolares), registros de professores e alunos,
enfim, toda a documentação que permita recuperar as práticas pedagógicas
e a formação do educador (CORSETI, 2006, p. 33).
Adicionalmente, é necessário considerar que, no contexto das atividades
didáticas propostas nesta tese, o principal artefato produzido pelos alunos – ou seja,
o jogo – será necessariamente digital. As estruturas de programação construídas
pelos alunos em cada jogo poderão refletir a sua compreensão de conceitos
matemáticos e computacionais. Essa análise é inspirada na perspectiva proposta
59
por Brennan e Resnick (2012), na qual a aquisição do Pensamento Computacional
pode ser analisada por três diferentes abordagens19: focando as práticas
fomentadas pela construção de artefatos digitais (pensamento incremental e
iterativo, teste e depuração, reuso, abstração e modularização); focando os
conceitos (na visão dos autores20, programação estruturada, paralelismo e eventos);
ou focando a mudança de perspectiva dos alunos ao participarem de atividades
(expressão, conexão com os pares e questionamento sobre o mundo ao redor).
Segundo os autores, a aquisição de novos conceitos pode ser avaliada por
meio da análise dos artefatos produzidos pelos alunos; à medida que novas
estruturas de programação são utilizadas, isso pode ser interpretado como um
indicativo que os conceitos subjacentes foram compreendidos pelos alunos.
Entretanto, como Brennan e Resnick (2012) também alertam, uma mera análise dos
artefatos não permite apontar se um conceito foi incorporado pelo aluno por
realmente compreendê-lo, ou por reutilização de projetos anteriores, ou mesmo por
interação com seus pares – em outras palavras, dessa forma ainda não é possível
identificar que práticas estão associadas à incorporação de um novo conceito. Para
tanto, é proposto o uso de entrevistas baseadas em artefatos, que serão
incorporadas a esta pesquisa dentro do contexto da etnografia, descrita na próxima
seção.
A análise documental das diretrizes curriculares para o ensino de Matemática
no Brasil e no Chile e sua associação com as definições de Pensamento
Computacional expressas na literatura é apresentada na seção 0. Em um segundo
momento, são analisados os jogos desenvolvidos pelos alunos; os procedimentos
para análise são descritos na seção 0, e os resultados da análise são apresentados
na seção 0.
19
O leitor atento poderá traçar um paralelo com a clássica divisão conceitual de objetivos
educacionais em competências, habilidades e atitudes.
20
Os autores pertencem ao grupo de pesquisa que desenvolveu o Scratch e, dessa forma,
sua visão de conceitos é razoavelmente direcionada pelas possibilidades criadas por aquela
ferramenta. Assim, a adoção dessa visão é conveniente nesta tese, onde será proposta uma
atividade didática que também utiliza o Scratch (vide seção 0).
60
3.3 Etnografia
A etnografia é um método de pesquisa proveniente das Ciências Sociais, em
particular da antropologia cultural e da sociologia qualitativa (SANDÍN ESTEBAN,
2010). Seu objetivo original é o estudo do modo de vida de algum grupo social e a
palavra etnografia pode se referir tanto ao processo de estudo quanto ao relato final
da investigação. Os antropólogos do início do século XX foram os primeiros
pesquisadores a denominar como etnografia a descrição monográfica de seus
estudos sobre o modo de vida dos povos que eram ethnoi, antigo termo grego que
significava “os outros”, ou seja, os povos bárbaros que não eram gregos
(ERICKSON, 1989).
Latorre, Del Rincón e Arnal (1996) elencam as principais características que
descrevem uma pesquisa etnográfica:
•
Caráter holista: uma etnografia descreve os fenômenos de maneira global,
contextualizada, levando em consideração que a descrição de um cenário
natural é inerentemente complexa. Goetz e LeCompte (1984) propõem um
arcabouço conceitual que procura orientar o pesquisador a respeito de
questões básicas a identificar em campo, tais como as características do
grupo, por que ele se reúne, onde se reúne, e quais são as suas motivações.
•
Condição naturalista: o etnógrafo estuda as pessoas em seu ambiente
natural: observa, anota, escuta e interage, evitando as formas controladas de
interação.
•
Usa a via indutiva: uma pesquisa etnográfica apoia-se nas evidências
obtidas em campo para produzir suas concepções e teorias, e na empatia e
habilidade geral do pesquisador para estudar outras culturas.
•
Caráter fenomenológico: a fenomenologia é um paradigma de pesquisa no
qual os fenômenos ou conceitos são estudados sob o ponto de vista das
experiências ou vivências das pessoas envolvidas (CRESWELL, 1998). A
etnografia é um método de pesquisa que se enquadra nesse paradigma.
•
Os dados aparecem contextualizados: dentro de uma perspectiva holista,
um fenômeno descrito por meio da etnografia deve apresentar os dados
dentro de uma perspectiva mais ampla.
61
•
Livre de julgamentos de valor: o etnógrafo evita emitir julgamentos de valor
sobre as observações. Uma descrição isenta, preservando as falas e eventos
tal e qual foram observados, pode ser considerado como um critério de
qualidade para a contribuição científica de uma pesquisa qualitativa (SANDÍN
ESTEBAN, 2010, p. 135).
•
Caráter reflexivo: como o pesquisador faz parte do mundo que estuda, a
etnografia reconhece a influência do pesquisador sobre o ambiente de
campo, e deste sobre o pesquisador.
Segundo Sandín Esteban (2010), a utilização da etnografia na pesquisa
educacional tem a clara finalidade de compreender os processos educacionais “de
dentro”, ou seja, na perspectiva dos atores envolvidos no processo. Há um
manifesto interesse de compreender como alunos e professores percebem e
atribuem significado aos fenômenos educacionais, bem como suas opiniões. Goetz
e LeCompte (1984) informam possíveis usos da etnografia educacional: estudos de
histórias biográficas e de papeis desempenhados pelos indivíduos; estudos de
classes e instalações escolares como se fossem pequenas sociedades; e estudos
de menor porte, denominados “microetnografias”, de grupos de trabalho ou jogos em
classes.
Neste tese, o método etnográfico foi empregado em uma perspectiva de
compreensão in loco dos fenômenos relacionados ao desenvolvimento do
Pensamento Computacional e da mobilização dos conhecimentos matemáticos dos
alunos durante a intervenção didática proposta. A pesquisa assume então um
caráter fenomenológico, à medida que se procura compreender o significado da
aquisição e mobilização de conhecimentos na perspectiva dos alunos, enquanto
estão engajados em uma atividade de construção de jogos.
Ainda que a criação prévia da intervenção didática (Oficina de Produção de
Jogos Digitais – vide Capítulo 5) tenha a intenção de desenvolver nos alunos um
subconjunto específico de competências e habilidades, a etnografia é conduzida em
uma perspectiva naturalista a partir da qual se pretende compreender o fenômeno
educacional além do seu aspecto controlado e planejado a priori, dentro do ambiente
onde a Oficina é conduzida. Dentro do contexto da tese, a etnografia é conduzida
com uma hipótese prévia – relacionada à influência mútua entre a Matemática e o
62
Pensamento Computacional – mas está sujeita a ajustes ao decorrer da
investigação, à medida que a realidade investigada torna-se mais clara (SANDÍN
ESTEBAN, 2010).
Uma identificação prévia do perfil dos alunos participantes da Oficina foi feita
através de um questionário, cujos procedimentos são descritos na seção 0; Os
procedimentos para observação das atividades de aula são descritos na seção 0;
por fim, a observação das atividades é complementada com uma entrevista baseada
em artefatos (BRENNAN; RESNICK, 2012) com os alunos, descrita na seção 0. A
descrição dos achados da etnografia é feita na seção 0, os resultados da entrevista
são apresentados na seção 0 e as demais análises são apresentadas de forma
integrada ao longo do Capítulo 6.
3.4 Quase experimentos (quasi-experiments) e pesquisa educacional
Um quase experimento (tradução direta do inglês quasi-experiment) é um
estudo experimental que, em vários aspectos, se assemelha a um experimento: o
valor de uma ou mais variáveis (ditas independentes) é manipulado de forma a
mensurar o impacto dessa manipulação no resultado de uma variável (dita
dependente). A principal diferença de um experimento para um quase experimento
está na forma de atribuir os participantes do experimento a diferentes grupos. Em
um experimento, essa atribuição é feita de forma aleatória, de forma a eliminar (ou
minimizar) influências relacionadas à autosseleção dos indivíduos.
Em um experimento, o grupo a que pertence um determinado indivíduo
tipicamente atua como uma variável dependente: um grupo (chamado de grupo de
controle) não recebe a intervenção cuja influência se deseja medir, enquanto que um
segundo grupo (chamado de grupo experimental) recebe a intervenção. Em geral,
espera-se obter alguma diferença mensurável na variável dependente no grupo
experimental (WHOLIN et al., 2000, p. 11). Um quase experimento é projetado
quando, por alguma razão, não é possível a atribuição aleatória de sujeitos aos
grupos. Esse é frequentemente o caso no contexto da pesquisa educacional: por
exemplo, há questões éticas e operacionais envolvidas quando uma intervenção
didática é oferecida a um grupo de alunos e não a outro, com o objetivo de criar um
grupo de controle (SHADISH; COOK; CAMPBELL, 2002).
63
Segundo Shadish, Cook e Campbell (2002), a análise de dados de quase
experimentos traz algumas dificuldades adicionais. Como a atribuição de indivíduos
aos grupos não faz parte do projeto experimental, é possível que causas
relacionadas à autosseleção tenham influência nos resultados. Ainda, é necessário
enumerar explicações alternativas (além da manipulação das variáveis livres) para
explicar qualquer efeito observado. Nesta tese, esta análise foi feita por meio da
triangulação de dados, que será descrita na próxima seção.
O quase experimento utilizado é um pré e pós-teste de conhecimentos
matemáticos, respondido pelos participantes da Oficina. A estrutura do teste é
apresentada na seção 0, e seus resultados são apresentados na seção 0.
3.5 Triangulação de métodos
Os
métodos
de
pesquisa
empregados
nesta
tese
seguem,
predominantemente, o paradigma qualitativo de pesquisa. No entanto, não
pretendemos tomar um posicionamento de oposição entre os paradigmas qualitativo
e quantitativo; nesse sentido, concordamos com Creswell (2013) e Günther (2006),
que argumentam que a utilização de métodos e técnicas de ambos os paradigmas
podem trazer uma visão complementar e mais aprofundada do fenômeno estudado.
Dentro do paradigma qualitativo, devem ser definidos procedimentos
específicos para assegurar a validade da pesquisa. Creswell e Miller (2000)
apresentam nove possíveis procedimentos de validação, cuja aplicabilidade está
associada à audiência do estudo, à disponibilidade dos indivíduos e ao custo de
utilização. A triangulação é um procedimento vinculado à visão do pesquisador21,
que envolve a busca de convergências entre diferentes fontes de informação para
formar temas e categorias em um estudo.
A triangulação pode ser feita entre diferentes fontes de dados, do mesmo tipo
(por exemplo, produzidas por diferentes sujeitos); entre teorias (quando um mesmo
fenômeno é analisado por meio de diferentes referenciais teóricos, de forma a
21
As demais visões propostas por Creswell e Miller (2000) são a visão dos próprios sujeitos
participantes do estudo e a visão de pessoas externas ao estudo. Dentro das possibilidades de tempo
e recursos desta pesquisa, os procedimentos utilizados nessas duas lentes foram, respectivamente, o
“engajamento prolongado em campo” e a “descrição densa e rica”.
64
identificar se as mesmas conclusões são obtidas); entre diferentes métodos de
coleta e análise (entrevistas, observações, documentos); ou entre diferentes
pesquisadores (quando as perspectivas pessoais dos pesquisadores frente ao
fenômeno observado são confrontadas). Nesta tese, optou-se por utilizar a
triangulação entre métodos de coleta e análise de dados obtidos no segundo
momento da pesquisa, o oferecimento da Oficina de Jogos Digitais: a etnografia foi
complementada pela análise dos resultados do pré e pós-teste de conhecimentos
matemáticos (seção 0), pela análise dos jogos e atividades produzidos pelos alunos
(seção 0), e pela entrevista final com cada equipe formada pelos alunos
participantes (seção 0). Na Figura 4 é apresentado um esquema indicando a
contribuição de cada método de coleta para as análises desenvolvidas por meio da
triangulação.
Figura 4 – Triangulação de métodos: contribuição de cada método de coleta para as
análises apresentadas na tese
Na subseção 0 é discutida a mobilização de conhecimentos matemáticos
pelos alunos a partir dos resultados obtidos com o pré e pós-teste de conhecimentos
matemáticos, com a análise dos jogos e atividades e com a etnografia. Os mesmos
65
três métodos embasam a discussão da subseção 0 sobre o desenvolvimento das
competências comuns entre o Pensamento Computacional e a Matemática. Apenas
dois métodos, a análise dos jogos desenvolvidos e a etnografia (em particular, o
perfil dos alunos e as entrevistas) conjuntamente embasaram a análise da subseção
0 sobre a aplicação do Pensamento Computacional para a construção dos jogos e a
análise da subseção 0 sobre a incorporação de funcionalidades adicionais nos jogos
e sua relação com aspectos de qualidade da interação humano-computador.
67
Capítulo 4
PENSAMENTO COMPUTACIONAL E MATEMÁTICA
Atualmente,
uma
das
principais
referências
curriculares
para
o
desenvolvimento de competências e habilidades do Pensamento Computacional na
educação básica é o currículo de referência norte-americano produzido pela CSTA,
o K-12 Standards for Computer Science Education (CSTA, 2011). Os autores do
documento ressaltam que “a educação básica é um ambiente altamente complexo e
politizado onde múltiplas prioridades, ideologias, pedagogias e ontologias disputam
por atenção”22. Adicionalmente, os autores argumentam que qualquer mudança
nesse ambiente exige uma profunda compreensão de sua realidade. Dessa forma, a
incorporação do Pensamento Computacional na educação básica deveria ser
baseada em uma abordagem prática; ao considerá-lo como uma estratégia para
resolução de problemas, torna-se possível aplicá-lo de forma transdisciplinar.
No capítulo anterior, foram apresentadas algumas contribuições da literatura à
identificação dos aportes da Matemática à Computação, por intermédio dos seus
processos de resolução de problemas e conteúdos. Também foram apresentados os
aportes da Computação como ferramenta didática, reunidos na definição do
Pensamento Computacional. Com base nessa apresentação e na premissa para
incorporar o Pensamento Computacional à educação básica apresentada no
parágrafo acima, este capítulo tem como objetivo identificar as relações
apresentadas na literatura entre a Matemática e o Pensamento Computacional. Ele
é desenvolvido em duas etapas, que utilizam distintas técnicas de pesquisa. No seu
primeiro momento, apresentamos uma análise documental (LÜDKE; ANDRÉ, 1986)
de diretrizes curriculares para o ensino de Matemática na educação básica, com o
objetivo de identificar competências e habilidades convergentes com as definições
de Pensamento Computacional já apresentadas anteriormente. Então, em seu
segundo momento, realizamos uma revisão sistemática da literatura na perspectiva
de Kitchenham (2004) com o objetivo de identificar da forma mais abrangente
possível os avanços e lacunas presentes atualmente na literatura referente a
22
Do original: “K-12 education is a highly complex, highly politicized environment where
multiple competing priorities, ideologies, pedagogies, and ontologies all vie for attention”.
68
associações do Pensamento Computacional com a Matemática. Por fim, discutimos
a relação entre os achados nesses dois momentos.
4.1 Análise das diretrizes curriculares para o ensino de Matemática23
Segundo Lüdke e André (1986), a análise documental visa identificar dados
factuais em documentos a partir de questões ou hipóteses de interesse. A partir
dessa técnica de pesquisa, analisamos um aspecto particular da nossa hipótese,
previamente definida na seção 0: se diretrizes curriculares para o ensino de
Matemática podem definir competências e habilidades que também estão presentes
nas definições de Pensamento Computacional presentes na literatura. A análise
desse aspecto foi motivada por três características identificadas na literatura e
discutidas no Capítulo 2: (i) a análise da natureza da Computação, cujo corpo de
conhecimento foi parcialmente construído pela Matemática (Seção 0); (ii) as
indicações de uma importância, mesmo que difusa, da Matemática para o ensino e a
prática profissional em Computação (Seção 2.1); e (iii) as relações entre o
Pensamento Computacional e a Matemática inicialmente indicadas por alguns
autores (BARR; STEPHENSON, 2011; HU, 2011) e comentadas na Seção 0.
Como será detalhado no próximo capítulo, o ambiente de campo inicialmente
definido para esta pesquisa era um curso de formação profissionalizante de nível
médio. Dessa forma, optamos por focar nossa análise nas diretrizes curriculares dos
anos finais da educação básica. Durante o percurso da pesquisa, foi agregado um
segundo ambiente de campo, em uma universidade chilena. Dessa forma, a análise
documental que será apresentada a seguir abrangerá as Orientações Curriculares
Complementares aos Parâmetros Curriculares Nacionais – PCN+ Ensino Médio
(BRASIL, 2002); e o documento Objetivos fundamentales y contenidos mínimos
obligatórios de la Educación Media (CHILE, 1998), editado pelo Ministério da
23
O mapeamento apresentado nesta seção é baseado no conteúdo das seguintes
publicações:
•
•
BARCELOS, T. S.; SILVEIRA, I. F. Pensamento Computacional e Educação Matemática:
relações para o ensino de Computação na educação básica. In: XX WORKSHOP SOBRE O
ENSINO DE COMPUTAÇÃO, 2012, Curitiba. Anais do XXXII Congresso da Sociedade
Brasileira de Computação. Curitiba: SBC, 2012.
BARCELOS, T. S.; SILVEIRA, I. F. Teaching computational thinking in initial series. In:
XXXVIII CONFERENCIA LATINOAMERICANA EN INFORMÁTICA, 2012, Medellín.
Proceedings of CLEI 2012. Medellín: Centro Latinoamericano de Estudios en Informática,
2012.
69
Educação do Chile. Assim, a comparação será estabelecida entre as diretrizes para
o ensino médio do Brasil e a enseñanza media do Chile.
Inicialmente, é possível constatar que ambas as diretrizes curriculares
indicam a necessidade de se incorporar recursos tecnológicos ao ensino de
Matemática. A reforma educacional do Chile, iniciada em 1997, teve como uma de
suas diretrizes que boa parte do trabalho manual (por exemplo, cálculos numéricos e
construção de gráficos e figuras geométricas) deveria ser substituído por recursos
tecnológicos de forma a ampliar as possibilidades de experimentação e testes de
hipóteses pelos próprios alunos. As diretrizes chilenas para informática educativa
nas escolas (ENLACES, 2012, p. 9) claramente definem que a Computação deveria
ser entendida não apenas como um instrumento para resolver problemas técnicos,
mas também como um modelo de raciocínio. Nesse modelo, a Computação tem
uma identidade própria, tanto em relação às questões que tenta responder quanto
em relação aos métodos que aplica para a resolução desses problemas. Ainda de
acordo com essas diretrizes, a relação entre a Matemática e a Computação é direta.
De acordo com os PCNs do ensino médio brasileiro, “o impacto da tecnologia
na vida de cada indivíduo vai exigir competências que estão além do simples lidar
com as máquinas” (BRASIL, 1999, p. 41). Coincidentemente, esse é o mesmo
argumento
utilizado
para
diferenciar
as
competências
do
Pensamento
Computacional do letramento computacional, ou seja, a habilidade de (apenas)
operar adequadamente os computadores para cumprir determinadas tarefas. Ainda
segundo os PCNs, o impacto da tecnologia exige um redirecionamento do ensino de
Matemática, a partir do qual “o indivíduo possa se reconhecer e se orientar nesse
mundo do conhecimento em constante movimento” (BRASIL, 1999, p. 41).
Alguma variação pode também ser identificada no nível de detalhe na
apresentação das diretrizes. Enquanto que as diretrizes brasileiras são fortemente
direcionadas à definição de competências e habilidades mais gerais, as diretrizes
chilenas definem um conjunto de habilidades específicas para cada um dos quatro
anos da educação secundária e, então, associam essas competências e habilidades
com cada conteúdo obrigatório que deve ser abordado. Considerando as
similaridades e diferenças entre as diretrizes, as competências matemáticas que
serão discutidas no decorrer desta seção foram selecionadas com base em dois
70
critérios. O primeiro deles foi que a competência deveria apresentar um potencial
para ser transferida (ou aplicada) em outros domínios do conhecimento, além da
Matemática. Isso foi feito para identificar as conexões com as competências do
Pensamento Computacional. O segundo critério foi a proximidade da competência
selecionada com atividades didáticas relacionadas ao Pensamento Computacional já
descritas na literatura. Não é possível afirmar que essa associação é exaustiva;
porém, ela reflete as principais tendências de pesquisa no desenvolvimento do
Pensamento Computacional e permite a identificação de possíveis caminhos para o
seu desenvolvimento conjunto com a Matemática.
4.1.1 Competência 1 – Alternar entre diferentes representações semióticas
A leitura e interpretação dos símbolos, códigos e nomenclaturas da linguagem
matemática fazem parte das competências esperadas dos alunos. Em particular,
espera-se que o aluno seja capaz de traduzir uma situação dada em uma linguagem
em outra; por exemplo, transformar situações dadas em linguagem discursiva em
gráficos, tabelas, fórmulas e outras representações, e vice-versa (BRASIL, 2002, p.
114). Dentro do domínio das diferentes representações permitidas pela linguagem
matemática, também se espera que o aluno seja capaz de “traduzir” uma
representação em outra como, por exemplo, converter os dados de uma tabela em
um gráfico e, posteriormente, deduzir sua representação algébrica (CHILE, 1998, p.
87).
Representar a solução para uma determinada situação na linguagem
algorítmica é uma das competências fundamentais do Pensamento Computacional
(CSTA, 2011). A representação de algoritmos na forma procedural traz algumas
semelhanças com a linguagem algébrica, em particular na representação de
variáveis; porém, o algoritmo se constitui em um modelo dinâmico, em oposição à
representação algébrica, que tipicamente é utilizada para expressar relações entre
grandezas desconhecidas, relações essas que são estáticas (ISBELL et al., 2010).
Segundo Mor e Noss (2008), a natureza sequencial do algoritmo, definido por
procedimentos que devem ser seguidos passo a passo, o aproxima da linguagem
discursiva. Dessa forma, representar um problema na forma algorítmica pode se
constituir como uma etapa intermediária entre a narração verbal e a linguagem
71
algébrica, podendo promover uma transição mais “suave” para a compreensão da
linguagem matemática.
Uma evidência inicial do enriquecimento tanto da linguagem algorítmica
quanto da matemática expressadas por alunos é apresentada por Lewis e Shah
(2012). Os autores identificam uma correlação positiva entre as notas de alunos da
quarta série em testes padronizados de conhecimento matemático e as notas dos
mesmos alunos em testes sobre conceitos básicos a respeito da construção de
algoritmos, implementados utilizando a plataforma Scratch durante uma oficina
extraclasse. Os autores apontam algumas possíveis sobreposições entre conteúdos
matemáticos e conteúdos desenvolvidos nas aulas da oficina. Como exemplo,
apresentamos na Figura 5 uma das possíveis relações apresentadas.
No problema y = x + 4, se x vale 7, quanto vale y?
Preencha os espaços em branco para desenhar
uma forma geométrica de 5 lados:
Figura 5 – Exemplo de correspondência entre representações algébrica e algorítmica
de um problema matemático
Fonte: Lewis e Shah (2012)
O tópico matemático em questão refere-se às relações lineares entre
grandezas, expressas no primeiro caso em uma equação com duas incógnitas em
que o valor de x é conhecido. Pretende-se avaliar se o aluno compreende que o
valor de y pode ser obtido com as informações dadas. No segundo caso,
evidentemente há mais conteúdos em jogo – o problema remete ao desenho de um
polígono regular, e exige o conhecimento adicional que a soma dos ângulos internos
de um polígono deve ser de 360 graus, logo a cada passo da repetição o aluno deve
comandar um giro de 360/N graus, dependente do número N de lados do polígono a
traçar, que também se constitui no número de passos da estrutura de repetição.
Está presente aí o mesmo conceito de relação linear entre grandezas, porém a
linguagem narrativa do algoritmo pode permitir que o aluno identifique e teste suas
72
próprias hipóteses, construindo ativamente o seu próprio formalismo matemático a
partir da construção do algoritmo.
Antes de alternar entre as representações matemática e algorítmica, os
alunos devem ser capazes de alternar entre uma solução informal para um
problema, expressa verbalmente, e uma representação algorítmica para esse
mesmo problema. Essa questão foi encaminhada no trabalho de Mota, Faria e de
Souza (2012), que desenvolveram um sistema de documentação automática que
produz uma descrição em linguagem natural para cada regra implementada pelos
alunos em um ambiente de programação visual. Uma avaliação preliminar indicou
que o acesso a essas descrições auxiliou os alunos a encontrar seus próprios erros
e compreender como seus pares resolveram os mesmos problemas. A importância
da descrição verbal dos algoritmos no processo de aprendizagem não é novo:
Soloway (1986) já havia argumentado que os instrutores deveriam frequentemente
apresentar explicações verbais de como e porquê um dado algoritmo funciona, e
encorajar os alunos a fazerem o mesmo com os algoritmos que constroem.
4.1.2 Competência 2 – Identificar regularidades e padrões
Os PCNs definem como uma competência esperada que o aluno seja capaz
de “identificar regularidades em situações semelhantes para estabelecer regras,
algoritmos e propriedades” (BRASIL, 2002, p. 116). Um conteúdo recomendado nas
diretrizes chilenas é a “resolução de desafios numéricos (...) incluindo cálculos
orientados à resolução de regularidades numéricas” (CHILE, 1998, p. 87). A partir
dessas recomendações, é possível inferir que o aluno deve ser estimulado a assumir
uma postura exploratória frente ao mundo e que, a partir dessa postura, estabeleça
ativamente as relações matemáticas. Aqui também encontramos similaridades com
as propostas da literatura, já que Wing (2006) considera a identificação de padrões
como uma das primeiras competências associadas ao pensamento computacional.
Apesar da identificação de padrões visuais ser uma habilidade cognitiva
fundamental a ser desenvolvida pelas crianças desde a primeira infância, a
identificação de regularidades em diferentes padrões e a subsequente abstração de
tais regularidades demandam estruturas e processos cognitivos mais complexos.
Esse tipo de abstração permite, por exemplo, operações mentais que vão desde a
73
extrapolação de resultados dedutíveis a partir de sequências numéricas até
inferências mais complexas. Polya (1995) define três habilidades relacionadas à
abstração que deveriam ser desenvolvidas para permitir a resolução de problemas:
a analogia, que é a capacidade de identificar que o problema a ser resolvido tem
similaridades com outros problemas previamente resolvidos; generalização, que se
relaciona a identificação de características comuns em problemas relacionados; e,
finalmente, a especialização, relacionada a enquadrar corretamente um novo
problema em uma categoria de problemas previamente identificada.
A formação de
sequências
numéricas
é
um
conteúdo matemático
frequentemente explorado em experiências didáticas envolvendo a identificação de
padrões associada a recursos computacionais. Mor e Noss (2008) relatam três
episódios de atividades pedagógicas, todas envolvendo a identificação das regras
de formação de sequências por alunos a partir da elaboração de algoritmos em um
software educativo. A identificação da regularidade na formação das sequências
surge na narrativa dos alunos, e sua transformação, inicialmente em algoritmo e
depois na representação matemática, parece contribuir para essa identificação.
A identificação de padrões está na raiz da definição de Pensamento
Computacional de Basawapatna et al. (2011) e também no modo de avaliar a
apropriação das competências por alunos. Professores de educação básica e de
faculdades de tecnologia participaram de um workshop de duas semanas sobre
métodos de aplicação do game design para ensinar os princípios do Pensamento
Computacional segundo a definição dos autores. Os participantes foram então
solicitados a identificar esses padrões em vídeos e imagens apresentando situações
do cotidiano; por exemplo, uma colisão entre um trenó de neve e uma pessoa
deveria ser associado ao padrão colisão, e um vídeo de um líquido se misturando a
outro deveria ser associado ao padrão difusão24. A maioria das questões teve uma
alta taxa de acertos, o que pode indicar a transferência de conhecimento entre
diferentes domínios. Segundo os autores, o uso de padrões pode ser útil como
estratégia didática.
24
Da mesma forma que um personagem de um jogo “difunde” seu “cheiro” no espaço de
jogo, de forma que inimigos possam rastrear sua posição.
74
4.1.3 Competência 3 – Construir modelos descritivos e representativos
A terceira competência a discutir refere-se à definição e interpretação de
modelos e representações matemáticas para analisar situações. Segundo os PCNs,
as situações devem estar tipicamente associadas ao cotidiano do aluno, tais como:
cálculos de lucro e prejuízo envolvendo gráficos, estimação das intenções de voto
em uma campanha eleitoral envolvendo conceitos de estatística e probabilidade,
entre outros (BRASIL, 2002, p. 117). Nesse contexto, a construção de modelos
pelos próprios alunos é de particular interesse; de acordo com as diretrizes chilenas,
os alunos deveriam ser progressivamente estimulados a construir modelos
representando situações cotidianas desde o segundo dos quatro anos do ensino
médio (CHILE, 1998, p. 89).
Quando a modelagem é utilizada em uma perspectiva didática, a validade de
um modelo assume um papel diferente daquele aplicado quando a modelagem é
uma atividade profissional. Segundo Bassanezi (2002), um modelo matemático é útil
do ponto de vista didático se expressa ideias de maneira clara e sem ambiguidades,
além de possibilitar o uso de elementos computacionais para calcular suas soluções
numéricas. Essa concepção de modelagem matemática pode ser ampliada em
conjunto com as competências do Pensamento Computacional. A modelagem e
simulação de fenômenos define, inclusive, uma das áreas de competências que
compõem os objetivos educacionais do pensamento computacional em (CSTA,
2011).
Enquanto Villarreal (2012) aponta que ainda existem resistências por parte de
professores (e da opinião pública em geral) ao uso de tecnologias no ensino de
Matemática, Diniz e Borba (2012) indicam que o suporte computacional para
atividades de modelagem matemática está tipicamente relacionado ao uso de
planilhas eletrônicas, de software para construção de gráficos e da obtenção de
dados a partir da navegação na Internet. Ou seja, o uso da tecnologia está restrito
ao nível do letramento computacional, enquanto que a utilização de ferramentas de
software mais poderosas pode permitir o desenvolvimento e aplicação de
competências do pensamento computacional. Um exemplo desse direcionamento é
relatado por Lee et al. (2011), que descrevem uma atividade didática em que alunos
produzem e testam um modelo de contágio de doenças considerando a quantidade
75
de alunos e a disposição física dos ambientes da sua escola. O modelo é testado
utilizando o StarLogo TNG, uma linguagem de programação em blocos baseada na
criação de agentes computacionais.
Pesquisas também revelam que a forma que os conceitos matemáticos são
apresentados em uma ferramenta computacional influencia o uso dos conceitos
matemáticos e a consequente geração dos modelos. Confrey et al. (2010)
descrevem o design e avaliação de duas ferramentas de software. A primeira
permite a construção de sequências animadas de figuras bidimensionais e a
segunda é um kit de construção de jogos digitais para personalizar os movimentos
de objetos em um jogo com temática de viagem espacial. Na primeira ferramenta,
conceitos matemáticos como escala, translação, rotação e coordenadas são
apresentados explicitamente na interface com o usuário, em contraste com as
ferramentas comerciais com a mesma finalidade, em que tais conceitos são
tipicamente “escondidos” dos usuários. Os autores argumentam que essa estratégia
de design levou os alunos a lidar com novos conceitos matemáticos com maior
motivação. Por outro lado, a avaliação da interação dos alunos com o kit de
construção de jogos levou à conclusão que os alunos não precisaram explorar
detalhes relacionados à gravidade e momento linear, pois a ferramenta apresentava
opções para personalizar os objetos do jogo em menor nível de detalhe.
4.2 Revisão sistemática da literatura
Para o desenvolvimento de uma revisão sistemática da literatura sobre as
relações entre o Pensamento Computacional e a Matemática, seguimos as diretrizes
propostas por Kitchenham (2004) e sistematizadas por Wohlin et al. (2012),
enumeradas a seguir:
•
Planejamento
o Identificação da necessidade de uma revisão;
o Definição da pergunta de pesquisa;
o Definição do protocolo da revisão.
•
Condução
o Identificação das pesquisas;
o Seleção de estudos primários;
76
o Verificação da qualidade dos estudos;
o Extração e monitoramento de dados;
o Síntese de dados.
•
Relato dos resultados.
É importante ressaltar que a descrição dos procedimentos a serem
conduzidos em cada etapa, de acordo com a literatura, foi feita previamente na
seção 0. Nas próximas seções, descreveremos como as etapas foram conduzidas;
quando necessário, serão apontadas as eventuais adaptações feitas devido às
características particulares deste estudo.
4.2.1 Planejamento
Conforme a compilação de diretrizes apresentadas por Wohlin et al. (2012) e
apresentadas na seção 0, após a identificação da necessidade de uma revisão
sistemática deve ser definida uma pergunta de pesquisa a ser respondida. Naquele
momento, foram apresentados alguns aspectos norteadores da questão de
pesquisa: a população para a qual a evidência é coletada; a intervenção aplicada no
estudo empírico; a comparação entre populações empregada; os resultados do
experimento; o contexto do experimento; o design experimental.
Em um paralelo com a pesquisa educacional, verifica-se que alguns dos
aspectos acima podem ser relevantes, como a definição da população (aqui
relacionada ao nível educacional em que as experiências são desenvolvidas) e os
aspectos ligados ao design experimental, tais como a intervenção e a comparação
entre populações. Porém, acreditamos que duas ressalvas devem ser feitas.
Primeiramente, uma definição muito específica desses aspectos para a seleção dos
estudos primários pode indiretamente criar um viés para a seleção de trabalhos de
pesquisa quantitativa, enquanto que é sabido que o paradigma da pesquisa
qualitativa norteia boa parte da produção de conhecimento em Educação25 (SANDÍN
ESTEBAN, 2010). A segunda ressalva refere-se a estudos de cunho teórico ou
argumentativo, em que não há um experimento explícito, e por isso também seriam
25
Essa também pode ser uma limitação para as revisões sistemáticas na área de Engenharia
de Software Experimental, que vem usando técnicas de análise relacionadas ao paradigma
qualitativo, como a pesquisa-ação, o estudo de caso e a teoria fundamentada em dados (grounded
theory).
77
excluídos de uma busca mais restritiva. A análise do percurso metodológico e das
conclusões desses estudos também pode contribuir para traçarmos o panorama das
associações entre o Pensamento Computacional e a Matemática.
A partir das constatações acima, propõe-se um objetivo um pouco mais
abrangente para esta revisão sistemática26, norteado pelas seguintes perguntas de
pesquisa:
(1) Como as relações entre o Pensamento Computacional e a Matemática
têm sido discutidas na literatura, do ponto de vista teórico?
(2) Como as relações entre o Pensamento Computacional e a Matemática
têm sido evidenciadas na literatura em experiências didáticas?
É importante ressaltar que essas questões estão diretamente relacionadas a
uma questão de pesquisa mais abrangente desta tese: Como conhecimentos prévios
em Matemática podem ser mobilizados durante o desenvolvimento do Pensamento
Computacional? (questão Q1). A questão 1 visa abarcar a análise de estudos
teóricos sobre as relações entre as duas áreas do conhecimento, tais como os
apresentados por Barr e Stephenson (2011) e Hu (2011), dentre outros que,
eventualmente, possam ser identificados durante o processo de identificação dos
estudos. Por sua vez, a questão 2 visa abarcar os estudos em que experiências
didáticas que associam o Pensamento Computacional e a Matemática são
apresentadas e validadas de alguma forma. Nesse caso, o protocolo da revisão
levará em consideração a identificação de características do design experimental
para análise dos estudos, incluindo aí os métodos de coleta e análise de dados
empregados e as conclusões obtidas a partir dos experimentos.
O terceiro e último passo do planejamento é a definição do protocolo da
revisão, que define os procedimentos de condução da revisão sistemática. Seus
aspectos são definidos a seguir:
Bases de dados – são incluídos os repositórios de trabalhos acadêmicos mais
diretamente relacionados à Computação, seu ensino em diferentes níveis, e a
26
Revisões em que o escopo da pesquisa é mais amplo e a área de pesquisa ainda é pouco
explorada são definidas por Wohlin et al. (2012) como estudos de mapeamento (mapping studies).
Contudo, optamos por utilizar o termo revisão sistemática e utilizar as adaptações ao método
propostas por aqueles autores.
78
tecnologia educacional em geral. As pesquisas foram feitas nas bases: ACM,
IEEExplore, ERIC, SpringerLink e ScienceDirect. A ACM e a IEEExplore agregam
artigos das comunidades de pesquisa em Computação e Engenharia, que foram
responsáveis pela definição do conceito de Pensamento Computacional e pelos
primeiros trabalhos de pesquisa envolvendo esse conceito. A ERIC foi incluída por
ser uma base que consolida trabalhos voltados à pesquisa em vários temas da
Educação. A SpringerLink e a ScienceDirect foram incluídas por agregarem artigos
de periódicos com alto impacto nas áreas de Computação e Tecnologia
Educacional.
String de busca – define a consulta ao banco de dados de cada base em questão.
Como mencionamos anteriormente, por ser este um tema de pesquisa bastante
recente, buscou-se uma estratégia inclusiva de busca baseada na seguinte
expressão booleana:
"computational thinking" E ("math" OU "mathematics")
Em cada uma das bases de dados consultadas, a busca foi configurada para
abranger o texto completo dos trabalhos, exceto quando essa opção já era definida
como o padrão. Algumas bases não oferecem suporte à busca por prefixo das
palavras; assim, a opção pelo uso da subexpressão "math" OU "mathematics"
permitiu que uma mesma expressão de busca pudesse ser utilizada em todas as
bases. Maiores detalhes sobre os procedimentos de busca podem ser encontrados
no Apêndice A.
Critério para seleção dos estudos – a partir da obtenção dos resultados nas bases
de dados, a seleção dos estudos a incluir na revisão será manual e dividida em duas
etapas. A primeira etapa consiste na análise do título e resumo de cada trabalho de
pesquisa e pode resultar na atribuição do trabalho a um dentre três grupos: inclusão
imediata na revisão (S), exclusão imediata da revisão (N), ou indicação de análise
posterior (V). Os trabalhos do terceiro grupo, marcados para revisão posterior, são
analisados na segunda etapa que consiste na leitura do artigo completo de forma a
indicar se ele deve ser por fim incluído (SV) ou excluído da revisão (NV). Os prefixos
S e SV são utilizados para criar uma identificação única para cada um dos artigos
79
selecionados, no contexto deste mapeamento. Tanto na primeira quanto na segunda
etapa serão utilizados os seguintes critérios para inclusão de um trabalho:
i.
o trabalho aponta alguma relação entre o Pensamento Computacional, ou o
ensino de Computação, e algum conteúdo, competência ou habilidade que
podem ser relacionados à Matemática;
ii.
o trabalho é um artigo completo (comunicação de resultados consolidados
de uma pesquisa) ou um artigo resumido (comunicação de resultados
parciais ou preliminares). Devido a maior abrangência da estratégia de
busca, optou-se por incluir trabalhos que ainda não tem resultados
consolidados;
iii.
se o trabalho apresenta uma experiência didática, é incluída uma avaliação
experimental (ou seja, são excluídos trabalhos que apenas propõem, de
forma argumentativa, atividades a serem desenvolvidas junto a alunos);
iv.
o trabalho não é proposta de tutorial, demonstração ou mesa de discussão.
Tais registros, que podem ser encontrados nas bases de dados
selecionadas,
apenas
descrevem
uma
atividade
a
ser
conduzida
presencialmente em uma reunião científica. Em uma análise preliminar dos
resultados da busca, constatou-se que tais documentos são bastante breves
e não permitem a identificação clara de uma proposta ou de resultados que,
em geral, são comunicados oralmente.
Critério para verificação da qualidade dos estudos – Wohlin et al. (2012) definem
que em um mapeamento mais abrangente da literatura, como é o caso deste
trabalho, a definição rígida de critérios de qualidade não é essencial e pode levar à
exclusão de estudos que auxiliem na importante identificação de tendências de
pesquisa (como é, por exemplo, o caso dos artigos resumidos). Dessa forma, não
foram definidos critérios de exclusão baseados em verificação de qualidade.
Extração, monitoramento e síntese de dados – A partir do conjunto de estudos
selecionados, pode-se proceder à extração de dados que permitam sua posterior
análise para o relato das conclusões da revisão. Originalmente, essa extração
refere-se a dados quantitativos que permitam a realização de uma “meta-análise”
envolvendo os dados obtidos a partir de vários estudos. Porém, considerando as
80
particularidades deste trabalho, optamos por um procedimento adicional de
separação dos estudos para daí identificar seus aspectos metodológicos principais:
(1) Classificação do estudo como:
•
Experiência didática (EXP), quando o estudo envolve a aplicação
concreta de uma atividade ou proposta curricular junto a indivíduos,
matriculados ou não em um curso formal, e ainda apresenta alguma
validação, formal ou informal, dos resultados da experiência;
•
Discussão conceitual (DI), quando sua argumentação for baseada em
uma análise documental, ponto de vista do autor, relato de experiência,
proposta curricular ou qualquer outro trabalho de cunho teórico.
(2) Para os estudos categorizados como experiência didática, são extraídos os
seguintes dados para análise:
•
Se a atividade relatada envolve o uso de algum software ou tecnologia
computacional, ou se é realizada sem o uso de tais artefatos27;
•
Conteúdos, competências ou habilidades relacionadas à Matemática
que são desenvolvidas pela atividade;
•
Se a experiência tem uma validação, formal ou informal, e qual o
objetivo de pesquisa da validação;
•
Os instrumentos de coleta de dados utilizados;
•
O público-alvo da atividade (nível educacional e/ou faixa etária);
•
Os resultados obtidos com a avaliação.
(3) Cada estudo categorizado como discussão conceitual é enquadrado em uma
das categorias a seguir. As categorias foram definidas através de análise
prévia dos artigos selecionados. A classificação é feita de forma independente
por dois pesquisadores e, posteriormente, os resultados são comparados e
eventuais discrepâncias são corrigidas. As categorias definidas são:
27
•
Ponto de vista;
•
Mapeamento curricular;
•
Revisão da literatura.
No contexto do desenvolvimento do Pensamento Computacional, tais atividades vem sendo
categorizadas como computação desplugada. Ver, por exemplo, www.csunplugged.org.
81
4.2.2 Estatísticas gerais dos estudos
A partir do protocolo de revisão definido na seção anterior, as atividades da
revisão se iniciaram com a execução da busca nas cinco bases de dados
selecionadas e a subsequente extração dos trabalhos que resultaram das buscas.
As buscas foram executadas entre os dias 13 e 20 de maio de 2013 e resultaram em
um total de 598 artigos. A seguir, foi realizada a seleção manual dos estudos
primários a serem incluídos na revisão, conforme os critérios previamente
apresentados. Na Tabela 2 apresentamos as estatísticas de seleção de estudos,
considerando as duas etapas de revisão.
Tabela 2 – Revisão sistemática: estatísticas de estudos selecionados
Base
S
SV
N
NV
Total
ACM
24
3
299
18
344
ERIC
2
0
6
0
8
IEEExplore
10
4
83
15
112
ScienceDirect
3
2
15
6
26
SpringerLink
5
2
93
8
108
Total
55
543
598
Legenda: S – selecionado a partir da leitura de título e resumo; SV – selecionado em segunda etapa, a partir de leitura
completa; N – rejeitado a partir da leitura de título e resumo; NV – rejeitado em segunda etapa, a partir de leitura completa.
É possível verificar que a maioria dos estudos que atendem ao critério de
inclusão foram obtidos a partir da base ACM, seguida da base IEEExplore. Essa é
uma indicação que a maioria dos trabalhos relacionados ao Pensamento
Computacional ainda é proveniente das comunidades de pesquisa em Computação
e Engenharia, áreas da maioria dos estudos que compõem as duas bases de dados.
A alta taxa de rejeição de estudos pode ser explicada por três razões. A primeira é a
grande quantidade de artigos, em especial na base ACM, que incluem o termo
“computational thinking” em contextos alheios à discussão do tema. Uma quantidade
menor de artigos, apesar de ter como tema o Pensamento Computacional, menciona
a Matemática apenas de forma superficial, não se enquadrando nos critérios de
aceite descritos na seção anterior. Ainda, alguns poucos trabalhos, em especial na
área de aprendizado de máquina, utilizavam o termo antes de 2006 (ou seja, antes
da definição de Wing) com outro significado.
82
A classificação de cada estudo resultou em 34 artigos classificados como
experiência didática e 21 artigos classificados como discussão conceitual. Na Tabela
3 apresentamos a segmentação dos estudos por base de dados, e na Figura 6
apresentamos um gráfico com a evolução dos trabalhos, ano a ano.
Tabela 3 – Revisão sistemática: segmentação de estudos classificados como
discussão conceitual (DI) ou experiência didática (EXP), por base de dados
Base
DI
EXP
Total por base
ACM
11
16
27
ERIC
2
0
2
IEEExplore
5
9
14
ScienceDirect
0
5
5
SpringerLink
3
4
7
Total
21
34
55
12
10
8
DI
6
EXP
4
2
0
2006
2007
2008
2009
2010
2011
2012
2013
Figura 6 – Revisão sistemática: quantidade de estudos selecionados, segmentados
por tipo (2006 a 2013)
É possível constatar que, apesar da relação entre a Matemática e o
Pensamento Computacional estar presente desde as primeiras discussões
conceituais sobre o tema, apenas em 2008 surgem os três primeiros estudos que
efetivamente propõem uma abordagem didática que envolve a associação entre as
duas áreas. Dois anos depois, em 2010, a quantidade absoluta de trabalhos dessa
modalidade ultrapassa de forma significativa a quantidade de discussões conceituais
sobre o tema. Após uma queda em 2011, a quantidade de experiências didáticas
tem um salto em 2012 e superam numericamente as discussões conceituais,
83
tendência que se mantém em 2013, considerando que os dados para esse ano
abrangem somente os artigos publicados até o mês de maio.
4.2.3 Público-alvo
Em cada artigo que apresenta uma experiência didática foi identificado qual o
público-alvo da atividade ou proposta relatada. Devido ao fato das bases de dados
consultadas disponibilizarem, predominantemente, artigos em inglês, foi adotada na
classificação a terminologia norte-americana para os níveis de ensino: elementary
school, para os cinco primeiros anos da educação básica; middle school, para os
três anos subsequentes da educação básica; e high school, para os quatro anos
finais, que correspondem aproximadamente ao ensino médio brasileiro. Em geral, os
autores de artigos que realizam experiências fora do contexto norte-americano
também utilizaram essa terminologia para reportar suas experiências. Para os
artigos em que essa estratégia não foi utilizada, o nível de ensino foi inferido de
modo a uniformizar a contagem. Os dados são apresentados na Tabela 4.
Tabela 4 – Revisão sistemática: segmentação de estudos por nível de ensino do
público-alvo
Elementary School
4
Percentual dos estudos
(n = 34)
11,8%
Middle School
5
14,7%
High School
4
11,8%
Graduação
13
38,2%
Professores
2
5,9%
Elementary School / Middle School
1
2,9%
Middle School / High School
2
5,9%
High School / Graduação
1
2,9%
Graduação / Professores
1
2,9%
Graduação / Middle School
1
2,9%
Total
34
100,0%
Nível
Quantidade de estudos
Públicos mistos:
É possível identificar que uma expressiva quantidade de estudos (16 artigos)
apresentam experiências voltadas a um ou mais níveis da educação básica; estão
incluídos aí os artigos que relatam experiências voltadas a mais de um público (um
artigo que relata uma experiência para alunos da elementary ou middle school e dois
84
artigos que descrevem experiências voltada a alunos da middle ou high school). Por
outro lado, foram identificados 13 artigos que tem como alvo exclusivamente o
ensino de graduação, ou tiveram sua validação experimental realizada neste
ambiente. Apesar da definição original de Pensamento Computacional (WING, 2006)
considerar o seu desenvolvimento como uma proposta predominantemente voltada
à educação básica, muitos pesquisadores vem propondo atividades voltadas ao
desenvolvimento do Pensamento Computacional de forma aliada com a Matemática
para alunos de graduação. Tais atividades são predominantemente voltadas para
disciplinas introdutórias, visando atenuar os altos índices de evasão e reprovação
em cursos da área de Computação. Uma exceção representativa é o trabalho de
Manson e Olsen (2010), que descrevem a modificação de duas disciplinas de física
básica de um bacharelado em Física para incorporar atividades computacionais.
Destaca-se ainda a carência de estudos relacionados à formação ou
atualização de professores para trabalhar conjuntamente a Matemática e o
Pensamento Computacional: nas bases pesquisadas, foram identificados apenas 3
artigos, sendo que um deles (ATER-KRANOV et al., 2010) na realidade apresenta
uma pesquisa com professores e alunos sobre quais competências e habilidades
estariam relacionadas ao Pensamento Computacional na visão dos respondentes.
Os outros dois estudos (JENKINS; JERKINS; STENGER, 2012; AHAMED et al.,
2010) referem-se especificamente a atividades de formação visando apresentar a
professores do ensino médio (high school) algumas potencialidades de ferramentas
computacionais (planilhas eletrônicas, Phyton e atividades do CS Unplugged)
aplicadas ao ensino de Ciências e Matemática.
4.2.4 Ferramentas e materiais utilizados
As experiências didáticas que desenvolvem a Matemática juntamente com o
Pensamento Computacional vêm utilizando, predominantemente, ferramentas
computacionais durante o seu desenvolvimento. A partir do mapeamento das
ferramentas e materiais utilizados nos artigos (Tabela 5), foram identificadas 29
ocorrências do uso de ferramentas computacionais e apenas 7 ocorrências do uso
de atividades que não dependem do computador (“computação desplugada”). É
85
preciso ressaltar que um estudo pode apresentar mais de uma ocorrência de uso de
ferramentas e materiais.
Tabela 5 – Revisão sistemática: ferramentas e materiais utilizados em atividades
"plugadas" e "desplugadas"
Atividades “plugadas”
Ferramenta
Atividades “desplugadas”
Ocorrências
Material
Ocorrências
Scratch
3
CS Unplugged
2
Phyton
Objetos de aprendizagem de
finalidade específica
Planilha eletrônica
3
Atividades Lápis-e-papel
5
NetLogo
2
Logo
2
MATLAB / Octave
2
Kit de Robótica
2
Java
2
AgentCubes / AgentSheets
1
Lisp
1
Jogo + Controle físico
1
Kit de montagem de eletrônica
1
Ferramenta não mencionada
3
TOTAL
29
TOTAL
7
3
3
Um variado conjunto de ferramentas computacionais é utilizado para o
desenvolvimento de atividades. Das 29 ocorrências identificadas, pelo menos 21
referem-se a linguagens (ex: Java, MATLAB, Phyton), ambientes (ex: Scratch,
AgentSheets) ou aplicações que permitem que o aluno desenvolva seus próprios
artefatos computacionais. As atividades de “computação desplugada”, que utilizam o
conjunto de materiais CS Unplugged (BELL et al., 2010), são utilizadas na formação
de professores (JENKINS; JERKINS; STENGER, 2012) e como um estudo de caso
para avaliar a associação entre a Matemática e a Ciência da Computação na visão
dos alunos (TAUB; ARMONI; BEN-ARI, 2012).
4.2.5 Métodos e técnicas de pesquisa para avaliação da aprendizagem
A seguir, procurou-se identificar que tipo de avaliação da aprendizagem foi
proposta e conduzida nos estudos. Para tanto, os estudos foram divididos
86
inicialmente em dois grupos: o primeiro contém os estudos que apresentam uma
avaliação classificada como formal, sob o ponto de vista do rigor da metodologia de
pesquisa empregada. No caso de estudos que adotam o paradigma quantitativo,
consideramos como formais aqueles estudos que empregam um experimento
(atribuição aleatória de indivíduos em grupos de controle e experimental) ou quase
experimento (comparação entre grupos não-equivalentes, sem atribuição aleatória
dos indivíduos) (TROCHIM; DONELLY, 2006).
No caso de estudos que adotam o paradigma qualitativo, nos apoiamos nos
critérios de validade propostos por Creswell e Miller (2000). Segundo esses autores,
a validade de ume estudo qualitativo pode ser analisada por meio de três “lentes”: do
pesquisador, dos participantes do estudo, ou de pessoas externas ao estudo. Ainda,
a escolha da quantidade e tipo dos procedimentos de validação empregados
depende da audiência esperada do estudo, da disponibilidade de pessoas e do
custo (financeiro ou de tempo) para utilizá-los. Para esta revisão, consideramos
como formais os estudos que adotaram procedimentos relacionados a, pelo menos,
duas das “lentes” propostas por Creswell e Miller. As técnicas de validação utilizadas
por todos os estudos qualitativos selecionados relacionaram-se aos critérios de
“engajamento prolongado em campo”28 e “descrição densa e rica”. Os resultados
encontram-se na Tabela 6.
Tabela 6 – Revisão sistemática: classificação dos estudos pelo nível de formalismo da
avaliação da aprendizagem
Quantidade de estudos
Percentual dos
estudos (n = 34)
22
62,9%
(apenas evidência empírica ou observacional ou amostra
de tamanho não significativo)
12
34,3%
Total
34
100,0%
Avaliação da aprendizagem
Formal
(experimento, quase-experimento ou estudo qualitativo
com algum nível de rigor)
Informal
Dos 22 estudos que apresentaram uma avaliação formal da aprendizagem, 13
descreveram especificamente a avaliação de competências e habilidades ou
conteúdos relacionados à Matemática. Na Tabela 7 esses estudos são enumerados,
28
Segundo Creswell e Miller (2000), o engajamento prolongado em campo tipicamente dura
de quarto meses a um ano, e esse foi o critério utilizado nesta revisão sistemática.
87
juntamente com o nível de ensino das experiências didáticas e as competências ou
conteúdos matemáticos desenvolvidos e avaliados.
Tabela 7 – Revisão sistemática: estudos com validação formal de competências ou
conteúdos matemáticos
Competências / habilidades /
conteúdos matemáticos
Razão
Proporção
Área
Equações algébricas simples
Velocidade
Aceleração
Gráficos tempo x velocidade
Abstração
Modelagem matemática de pré e pós
condições
Álgebra básica, Matrizes, Sistemas
Lineares, Números complexos,
Vetores, Forças e Torques
Geometria planar
Geometria esférica
Abstração
Generalização
Redação de justificativas
Varáveis
Aritmética
Relações geométricas
Aceleração constante
Interpretação e geração de gráficos
tempo x velocidade
Distância, velocidade e aceleração
Coordenadas cartesianas
Identificação de padrões
Iteração
Funções
Estatística descritiva
Artigo
Nível de ensino
Chiu et al. (2013)
Middle school
Sengupta et al. (2013)
Middle school
Cook et al. (2012)
Graduação
Hoji, Vianna e Felix (2012)
High school
Hsi e Einsenberg (2012)
Elementary school / Middle school
Jenkins, Jerkins e Stenger (2012)
Professores – High school
Lewis e Shah (2012)
Elementary school
Sengupta e Farris (2012)
Elementary school
Boyce et al. (2011)
Middle school / High school
Yeh, Xie e Ke (2011)
Graduação
Manson e Olsen (2010)
Graduação
Mecânica newtoniana
Taylor, Harlow e Forret (2010)
Elementary school
Coordenadas cartesianas
Figuras geométricas planas
Ângulos
Medidas de tempo e distância
Mittermeir et al. (2008)
High school
Funções
Dos artigos remanescentes, um deles (LARKINS; HARVEY, 2010) utiliza a
avaliação feita por alunos de graduação, por meio de um questionário, sobre os
tópicos apresentados em uma oficina de técnicas de visão computacional para
concluir que as atividades propostas são compreensíveis, dado o nível de
conhecimento de Ciências e Matemática daqueles alunos. Ahmed et al. (2010)
analisam a importância atribuída ao Pensamento Computacional e ao uso de
tecnologia por professores participantes de um workshop de três dias sobre o
assunto. Os artigos de Lawson, Szajda e Barnett (2013), Turbak et al. (2012), Rizvi
88
et al. (2011) e Bryant et al. (2011) apresentam experiências didáticas voltadas a
fomentar o interesse de alunos ingressantes em cursos de graduação na área de
tecnologia para tópicos da Ciência da Computação; apesar de descreverem que as
atividades propostas podem mobilizar tópicos da Matemática, a avaliação
apresentada em tais artigos é focada no interesse e motivação dos alunos após
participarem da experiência e não no aprendizado.
Três estudos não apresentam uma experiência didática, mas foram incluídos
nesta categoria por proporem uma coleta e análise de dados seguindo o método
científico. O objetivo dos estudos é identificar as relações percebidas por alunos
entre o Pensamento Computacional e a Matemática; assim, todos utilizam o
questionário como instrumento de coleta de dados. Taub, Armoni e Ben-Ari (2012)
têm como sujeitos de pesquisa alunos de 7º ano que participam de atividades
baseadas no CS Unplugged; os autores concluem que, após as atividades, os
alunos aumentam sua percepção sobre a necessidade de um “raciocínio
matemático” para se trabalhar com Ciência da Computação. No entanto, a
necessidade de se utilizar a Matemática em si na Computação não é tão clara para
esses alunos. Ater-Kranov et al. (2010) aplicam um mesmo questionário a instrutores
e alunos de um curso universitário modular para o desenvolvimento do Pensamento
Computacional. A importância da lógica, da Matemática e da abstração para resolver
problemas é indicada como sendo altamente relevante para o Pensamento
Computacional por ambos os públicos. No entanto, os alunos indicam a relevância
da modelagem matemática em proporção mais elevada do que os instrutores.
Possíveis motivos para essa discrepância não são discutidos pelos autores. O
terceiro trabalho, por Jenkins et al. (2013), procura compreender o que os autores
chamam de um “estereótipo anti-simbiótico” entre a Matemática e a Computação,
supostamente presente entre alunos de graduação em Computação. A partir de um
questionário aplicado a 46 alunos de um programa de graduação interdisciplinar, os
autores concluem, a partir de respostas dadas para questões abertas, que muitos
alunos não veem nenhuma relação entre a Matemática estudada no curso e a
Computação.
Na Tabela 8 são apresentados os instrumentos de coleta de dados utilizados
nos 22 estudos que apresentam alguma validação formal da aprendizagem. Deve-se
ressaltar que, por vezes, um estudo utiliza mais de um instrumento.
89
Tabela 8 – Revisão sistemática: instrumentos de coleta de dados utilizados em
estudos com validação da aprendizagem
Instrumento
Quantidade de
ocorrências
Percentual dos
estudos (n = 22)
Questionário
14
60,9%
7
30,4%
6
26,1%
Entrevista
6
26,1%
Observação de aulas
3
13,0%
Índices de aprovação
2
8,7%
Análise de artefatos produzidos
2
8,7%
Notas
2
8,7%
Avaliação de aprendizagem – apenas após
intervenção
Avaliação de aprendizagem – antes e após
intervenção
A partir dos dados é possível identificar um uso intensivo de questionários
pelos pesquisadores. Dentre os objetivos do uso desse instrumento, destacam-se a
auto-avaliação dos participantes sobre sua motivação e interesse sobre as
atividades propostas, bem como o levantamento de perfil dos participantes. A
avaliação da aprendizagem em si é tipicamente feita através de avaliações com
conteúdo da Matemática escolar ou usando-se os resultados de avaliações oficiais
já disponíveis. Observa-se uma menor frequência da utilização de instrumentos de
coleta associados ao paradigma qualitativo, como entrevistas (6 ocorrências) e
observação de aulas (3 ocorrências).
Como vimos na seção anterior, a maioria dos estudos descreve experiências
didáticas nas quais os alunos manipulam ferramentas computacionais de forma a
construir seus próprios artefatos, tais como pequenos programas, jogos digitais,
desenhos e planilhas de cálculo. Mesmo assim, apenas dois estudos mapeados
afirmam ter utilizado a análise dos artefatos produzidos pelos alunos. Taylor, Harlow
e Forret (2010) incluem programas produzidos através do Scratch em um variado
conjunto de dados coletados com o objetivo de produzir uma análise qualitativa dos
conceitos matemáticos explorados por alunos de 10 anos durante atividades de
criação de jogos. Sengupta e Farris (2012) utilizam uma perspectiva semelhante
para analisar a aquisição de novos conceitos de cinemática à medida que alunos do
ensino fundamental constroem suas próprias simulações.
90
4.2.6 Competências, habilidades e conteúdos da Matemática
A análise seguinte refere-se a quais competências, habilidades e conteúdos
da Matemática vêm sendo desenvolvidos. Para obter um panorama mais abrangente
das tendências de pesquisa, nesta análise foram incluídos tanto os estudos que
apresentavam validação formal da aprendizagem quanto aqueles que apresentavam
uma validação menos rigorosa, ou seja, baseada apenas no relato da experiência ou
na descrição de evidências isoladas do aprendizado. A partir do agrupamento dos
estudos que desenvolvem temas afins, foram separados oito grupos:
•
Habilidades cognitivas de alto nível: 6 estudos;
•
Álgebra e Cálculo: 13 estudos;
•
Modelagem Matemática: 2 estudos;
•
Aritmética: 7 estudos;
•
Geometria Planar: 8 estudos
•
Estatística: 5 estudos
•
Álgebra Linear: 9 estudos
•
Física: 5 estudos.
É conveniente ressaltar que um mesmo estudo pode ter sido associado a
mais de um grupo por ter mencionado o desenvolvimento de tópicos de mais de uma
área (por exemplo, Álgebra e Física). O mapeamento detalhado dos tópicos
desenvolvidos em cada estudo às respectivas categorias pode ser encontrado no
Apêndice A. A partir desse mapeamento, é possível observar que uma ampla
variedade de competências e conteúdos matemáticos vem sendo abordada, não
havendo predominância de nenhum dos grupos. Além disso, de forma até esperada,
os estudos que abordam o desenvolvimento de tópicos de Aritmética e Geometria
Planar são predominantemente voltados ao público alvo da educação fundamental
(elementary school), enquanto que os estudos que abordam tópicos de Álgebra e
Cálculo, Estatística e Álgebra Linear são predominantemente voltados para alunos
do ensino médio (high school) e de graduação.
Um primeiro grupo de trabalhos enfatiza o desenvolvimento de competências
cognitivas mais gerais, argumentando sobre suas relações com a Matemática.
Jenkins, Jerkins e Stenger (2012) apresentam um programa de formação de curta-
91
duração voltado a professores de matemática do ensino médio que visa capacitá-los
a utilizar a linguagem Phyton para desenvolver pequenos programas que
demonstrem conceitos matemáticos. Uma avaliação escrita aplicada antes e após a
formação demonstrou que os participantes aumentaram sua conscientização sobre o
uso de habilidades de abstração e generalização na resolução de problemas. Outros
trabalhos visam o desenvolvimento de habilidades de identificação de padrões
através do desenvolvimento de montagens geométricas (BOYCE et al., 2011) ou
padrões visuais (BRYANT et al., 2011). Vale ressaltar que a generalização, através
da identificação de padrões é uma das competências comuns que foram
identificadas no mapeamento curricular apresentado na seção 0. O uso da
linguagem matemática como canal de comunicação entre equipes de alunos de
países diferentes, engajados em um projeto comum de construção e manipulação de
robôs, é descrito por Maxwell et al. (2013).
Para os demais sete grupos de estudos, exemplos dos conteúdos
matemáticos que foram desenvolvidos são apresentados na Tabela 9.
Tabela 9 – Revisão sistemática: exemplos de conteúdos matemáticos desenvolvidos
Grupo
Álgebra e Cálculo
Modelagem
Matemática
Exemplos de conteúdos
Uso de variáveis, equações algébricas, desigualdades, números complexos
Análise de gráficos, criação de funções, gradiente, derivadas parciais
Modelagem de pré e pós condições de funções computacionais
Modelagem de máquinas de estado
Aritmética
Operações básicas, divisão inteira, razão, proporção, sistemas de numeração
decimal e hexadecimal
Geometria Planar
Área, escala, ângulos, propriedades de figuras geométricas planas
Estatística
Probabilidade, árvores de decisão, princípio fundamental da contagem
Álgebra Linear
Sistema de coordenadas cartesiano, matrizes, vetores, geometria analítica
Física
Velocidade, aceleração, forças, torques, interpretação de gráficos de velocidade
em função do tempo
Os tópicos de Álgebra e Cálculo são utilizados para contextualizar aplicações
nas áreas de visão computacional (LARKINS; HARVEY, 2010), projeto de
engenharia (CHIU et al., 2013), sensores para projetos de robótica (MITTERMEIR et
al., 2008) e processamento de dados via planilhas eletrônicas (YEH; XIE; KE, 2011).
Na aritmética, um exemplo representativo é o uso da divisão inteira, pouco
explorada na educação básica, para demonstrar algoritmos simples de criptografia
(CARTER; BLANK; WALZ, 2012). Estudos que utilizam ferramentas de programação
92
visual como o Scratch, Logo e VPhyton invariavelmente exploram o desenvolvimento
de tópicos da geometria plana e analítica, pelas próprias características das
ferramentas. Lewis e Shah (2012) e Taylor, Harlow e Forret (2010) discutem a
apropriação de relações geométricas e coordenadas cartesianas por alunos do
ensino fundamental (elementary school) ao produzir seus programas com o Scratch.
Ambientes de programação em 3D (IOANNIDOU; REPENNING; WEBB, 2009)
podem inclusive exigir a mobilização de conceitos de geometria espacial.
Conceitos de probabilidade são explorados na formação de professores
(JENKINS; JERKINS; STENGER, 2012), na modelagem de análise de falhas
(YEVSEYEVA; TOWHIDNEJAD, 2012), e aplicados a um problema simples de
análise combinatória (FLATLAND; MATTHEWS, 2009). Trabalhos relacionados à
Física, em particular a conceitos de cinemática, aparecem na revisão devido à
abordagem matemática necessária para sua análise. Os trabalhos de Sengupta et
al. (2012) e Sengupta e Farris (2012) apresentam uma abordagem utilizando
programação baseada em agentes para introduzir conceitos de velocidade e
aceleração para alunos do ensino fundamental. Hoji, Vianna e Felix (2011)
apresentam uma estratégia didática que introduz conceitos de forças e torques para
alunos de um curso técnico em mecânica no Brasil utilizando o Octave, uma
linguagem de programação matemática.
Deve-se notar a carência de trabalhos que utilizam a estratégia da
Modelagem Matemática, visto que a construção e interpretação de modelos podem
também ser consideradas como competência comum à Matemática e ao
Pensamento Computacional (vide seção 0). Apenas dois trabalhos utilizam essa
abordagem. Cook et al. (2012) utilizam a modelagem matemática de pré e pós
condições como uma estratégia para ensinar a alunos de graduação aspectos da
especificação formal de sistemas computacionais. Os autores argumentam que a
estratégia levou os alunos a produzirem especificações com sucesso, mas que
ainda apresentaram dificuldades em escrever provas matemáticas da corretude do
funcionamento de sistemas. Weller, Do e Gross (2008) apresentam um dispositivo
eletrônico reconfigurável utilizado para especificar o comportamento de personagens
em um jogo de labirinto similar ao Pacman. A montagem do dispositivo aplica
conceitos da modelagem de máquinas de estado; no entanto, a atividade é validada
apenas preliminarmente com alunos.
93
4.2.7 Discussões conceituais
Como mencionado no planejamento da revisão (seção 0), os estudos que não
apresentam uma avaliação experimental foram agrupados na categoria de
discussões conceituais. Na concepção de revisão sistemática adotada nesta
pesquisa (WOHLIN et al., 2012), as perguntas de pesquisa que direcionam a revisão
devem estar focadas nas evidências experimentais trazidas pelos estudos e nos
aspectos associados a elas. Entretanto, as particularidades da pesquisa em
Educação, contexto no qual esta revisão se insere, justificam ao menos um olhar
mais detalhado sobre os estudos conceituais.
A partir de uma análise prévia dos estudos, foram definidas três categorias
para agrupamento dos estudos:
•
Ponto de vista: trabalhos cuja argumentação se embasa predominantemente
na experiência ou opinião pessoal do autor;
•
Mapeamento curricular: trabalhos que procuram analisar comparativamente
as
competências,
habilidades
e
conteúdos
presentes
em
diretrizes
curriculares nas áreas de Matemática e Computação;
•
Revisão da literatura: trabalhos que mencionam ou analisam a Matemática e
a Computação através de uma revisão da literatura.
A classificação dos 22 artigos incluídos na categoria de discussões
conceituais resultou na seguinte divisão:
•
Ponto de vista: 11 estudos;
•
Mapeamento curricular: 5 estudos;
•
Revisão da literatura: 5 estudos.
A classificação completa dos estudos pode ser encontrada no Apêndice A.
Os
artigos
na
categoria
Mapeamento
curricular
buscam
identificar
convergências entre o Pensamento Computacional e outros conteúdos do currículo
escolar, mencionando necessariamente a Matemática nessa análise. Pokorny (2013)
analisa o currículo de referência da CSTA para o ensino de Computação na
Educação Básica e os National Educational Technology Standards for Computer
94
Science Educators (NETS-CSE), voltado para o ensino médio, em comparação com
o Common Core State Standards. A modelagem de problemas do mundo real foi
identificada como sendo a principal competência compartilhada entre o currículo da
CSTA e o Common Core. A construção e análise de modelos também é discutida no
artigo de Bell et al. (2012), onde são apontadas as contribuições dessa competência
e do Pensamento Computacional para o desenvolvimento do pensamento científico
nos alunos do ensino básico.
Liu e Wang (2010) identificam relações entre a Matemática Discreta e o
Pensamento Computacional, corroborando a hipótese proposta por Ralston (2005).
São apontadas possibilidades de desenvolvimento do Pensamento Computacional
utilizando teoria dos conjuntos, teoria de grafos, lógica matemática e álgebra
abstrata. Já Micheuz (2008) apresenta uma tentativa de mapeamento de conteúdos
e processos do currículo do National Council of Teachers of Mathematics (NCTM)
com uma proposta de currículo unificado de Informática para as escolas básicas
alemãs. Uma extensão do mapeamento apresentado por Barcelos e Silveira (2011)
já foi apresentada na seção 0 deste trabalho.
Os estudos classificados na categoria Revisão da literatura exploram apenas
marginalmente as relações entre o Pensamento Computacional e a Matemática.
Dois aspectos relevantes são identificados em uma recente revisão da literatura
sobre o Pensamento Computacional, por Grover e Pea (2013, p.42). O primeiro é a
sinalização que as pesquisas na área não vem explorando “a ideia da Computação
ser uma mídia para o ensino de outras disciplinas”29 (inclua-se aí a Matemática); o
segundo é a indicação da grande carência de estudos que explorem o aspecto
sócio-cultural do processo de aprendizagem, bem como a aprendizagem situada.
Dois estudos tem como foco a formação de professores para o ensino de
Computação na educação básica. Armoni (2011) analisa a literatura sobre formação
de professores de Matemática para recomendar características que deveriam ser
levadas em consideração na formação de professores de Computação; dentre elas,
destacam-se a instrumentação dos futuros professores em uma base construtivista,
bem como promover junto a eles uma imagem correta da Ciência da Computação.
29
(…)”.
Do original em inglês: “(…) the idea of computing as a medium for teaching other subjects
95
Liu et al. (2011) analisam onze iniciativas de universidades americanas para
formação de professores e concluem que, apesar de não haver ainda evidências do
impacto desses programas junto aos alunos, os professores participantes
demonstraram capacidade de incorporar às suas aulas os conhecimentos e
materiais obtidos durante a formação. Em quatro desses programas, os professores
envolvidos eram da área de Matemática.
Zhi-Wei e Dan-Dan (2011) confrontam o conceito de Pensamento
Computacional com o conceito de computação ternária para as massas30, proposto
por pesquisadores chineses, e informam que um módulo sobre algoritmos foi
incorporado ao ensino de Matemática no ensino médio na China. Por fim, McMaster,
Rague e Anderson (2010) analisam a frequência de palavras em estudos
relacionados a três paradigmas de pensamento: Pensamento Abstrato, Pensamento
Matemático e Pensamento Computacional. Os autores concluem que o termo
“modelo”
foi
raramente
utilizado
em
estudos
relativos
ao
Pensamento
Computacional; em contrapartida, o termo “algoritmo” também é raramente utilizado
em estudos relacionados ao Pensamento Matemático. Os autores sinalizam que isso
pode indicar pouca integração entre as áreas.
Por sua vez, os artigos classificados na categoria Ponto de vista são, de certa
forma, iniciados pelo trabalho seminal de Wing (2006). Em sua maioria, já foram
apresentados e discutidos na seção 0 e por isso não serão feitas maiores
considerações aqui.
4.2.8 Conclusões da revisão sistemática
A partir desta revisão sistemática, pode-se inferir que há um aumento do
interesse da comunidade científica em explorar as relações entre o Pensamento
Computacional e a Matemática. O aumento significativo, nos últimos anos, na
quantidade de estudos que apresentam experiências didáticas contribui para essa
conclusão. As atividades didáticas não se restringem apenas à educação básica;
30
De forma resumida, o conceito de computação ternária para as massas propõe que se
estenda o conceito da computação tradicional (dita “unária”, por utilizar apenas recursos
computacionais para resolver problemas) para resolver problemas em sistemas que envolvam
pessoas, recursos computacionais (presentes no ciberespaço) e recursos físicos (naturais ou
produzidos pelo homem). Essa nova computação se aproximaria, por exemplo, de soluções
baseadas em sensoriamento inteligente e big data (ZHI-WEI E DAN-DAN, 2011).
96
verifica-se, na prática, um número aproximadamente igual de experiências
direcionadas ao ensino médio e ao ensino de graduação. Por um lado, isso indica
que a definição de competências e habilidades oferecida pelo Pensamento
Computacional tem se mostrado útil na organização das pesquisas que tem como
finalidade resolver os problemas de evasão e reprovação em cursos de tecnologia,
já mencionados anteriormente. Entretanto, isso não deixa de se caracterizar como
um “desvio” nos objetivos originais do Pensamento Computacional, já que podemos
considerar que a graduação é tipicamente o campo de aplicação mais próximo da
realidade da pesquisa das universidades. Por outro lado, a maioria dos estudos
incluídos na revisão que apresentaram uma validação formal da aprendizagem
matemática envolve atividades didáticas que foram aplicadas a alunos da educação
básica.
As atividades didáticas desenvolvidas se relacionam a uma variedade de
conteúdos matemáticos, e utilizam ferramentas computacionais bastante diversas.
Esse pode ser um indicativo da grande flexibilidade e potencial dos conceitos e
ferramentais computacionais como suporte para ensinar e contextualizar a
Matemática. Essa evidência contradiz parcialmente a revisão de Grover e Pea
(2013), ao mencionar que o Pensamento Computacional não vem sendo utilizado
para ensinar outras disciplinas. No entanto, a limitação do ponto de vista
metodológico, apontada por aqueles autores, se verifica também nos resultados
desta revisão. A grande maioria dos estudos identificados na literatura não utiliza
múltiplas fontes de dados de forma a analisar os resultados do processo de ensinoaprendizagem sob diferentes pontos de vista.
O questionário, como instrumento para obter os dados demográficos dos
alunos e sua avaliação subjetiva sobre as atividades aparece nos estudos de forma
mais frequente do que as avaliações de aprendizagem. Apesar da significativa
maioria das experiências didáticas utilizar ferramentas para criação de artefatos
computacionais pelos alunos, apenas dois estudos utilizaram a análise dos artefatos
produzidos pelos alunos para evidenciar o processo de aprendizagem. Talvez essa
opção metodológica dos estudos possa ser explicada pelo fato da análise
quantitativa aparecer como paradigma predominante, seguindo uma tradição das
comunidades de Computação e Engenharia, nas quais emergiu a pesquisa sobre o
Pensamento Computacional.
97
O fenômeno de transferência de habilidades entre áreas diferentes é
inerentemente complexo; dessa forma, a aplicação de técnicas de pesquisa que
limitam uma análise mais aprofundada desse fenômeno pode ser considerada a
principal
limitação
de
vários
dos
estudos
que
integraram
esta
revisão.
Adicionalmente, apesar de ter sido possível identificar algumas iniciativas para
formação e capacitação de professores, tais iniciativas ainda são muito incipientes e
carecem de uma maior sistematização.
4.3 Implicações da análise de diretrizes curriculares e da revisão sistemática
para a pesquisa
Neste capítulo foram apresentadas duas visões diferentes e complementares
para as relações entre o Pensamento Computacional e a Matemática. Um
mapeamento das diretrizes curriculares para o ensino da Matemática em dois países
permitiu a identificação de três competências que parecem também estar muito
presentes nas atividades de fomento ao Pensamento Computacional: alternar entre
diferentes representações semióticas; estabelecer relações e identificar padrões;
construir modelos descritivos e representativos.
Apesar desse mapeamento não ser exaustivo, pode-se identificar algumas
relações entre ele e os estudos analisados na revisão sistemática, apresentada a
seguir. Os estudos identificados que desenvolvem habilidades cognitivas de alto
nível objetivam, em sua maioria, o desenvolvimento de abstração, generalização e
identificação de padrões, que integram a segunda competência identificada no
mapeamento. Ainda foi possível identificar estudos que detalham a construção de
modelos utilizando a Matemática, mesmo que em menor número (apenas dois).
Dessa forma, a partir das duas visões apresentadas, é possível concluir que
as lacunas da literatura encontram-se atualmente nos seguintes pontos:
•
Ausência de uma maior diversidade paradigmática na análise da aquisição de
novas competências matemáticas e computacionais pelos alunos;
•
Carência de trabalhos que explorem a construção de modelos matemáticos
no desenvolvimento do Pensamento Computacional;
98
•
Carência31 de trabalhos que explorem a alternância entre diferentes
representações
semióticas
(verbal,
algorítmica,
matemática)
no
desenvolvimento do Pensamento Computacional.
Assim, a pesquisa de campo proposta nesta tese, a ser apresentada no
próximo capítulo, tem como objetivo proporcionar um ambiente de ensinoaprendizagem real que possa ser analisado sob a ótica das competências comuns
identificadas; ainda, com a análise dos seus resultados, pretende-se contribuir
parcialmente em preencher as lacunas identificadas no estado da arte por meio da
revisão sistemática apresentada neste capítulo.
31
Uma ressalva deve ser feita aos trabalhos do grupo da Profª. Clarisse Sikenius de Souza,
da PUC-RIO (MOTA; FARIA; DE SOUZA, 2012; DE SOUZA, C. S. et al., 2011), que explora a
aquisição do Pensamento Computacional sob a ótica da Engenharia Semiótica, uma das bases
conceituais da Interação Humano-Computador. Pode ser incluída nesse grupo a tese de Setti (2009),
que explora as dificuldades de alunos de graduação em alternar entre as representações matemática
e algorítmica para sequências numéricas regulares.
99
Capítulo 5
OFICINA DE PRODUÇÃO DE JOGOS DIGITAIS
Neste capítulo serão apresentados a construção e os pressupostos
pedagógicos da Oficina de Produção de Jogos Digitais. Na seção 0, serão
apresentadas as principais características do público-alvo e dos cursos das duas
instituições nas quais a Oficina foi aplicada: o Instituto Federal de Educação, Ciência
e Tecnologia de São Paulo – Campus Guarulhos, e a Universidad de Valparaíso. O
autor desta tese leciona na primeira instituição e à segunda instituição está
vinculado um dos membros do grupo de pesquisa no âmbito do qual esta pesquisa
foi desenvolvida. Um histórico de interação entre as duas instituições em atividades
de pesquisa e a facilidade de acesso aos docentes motivaram inicialmente a escolha
das instituições para a pesquisa. Ainda, as duas instituições apresentam alguns
problemas em comum no oferecimento dos seus cursos, como altas taxas de
evasão e repetência em disciplinas de introdução à programação de computadores.
Na seção 0 é apresentada a justificativa para o uso do Scratch como ambiente de
programação na Oficina, considerando o público-alvo e contexto da sua aplicação
nas duas instituições descritas anteriormente. Na seção 0 apresentamos a estrutura
de atividades planejada para a Oficina, bem como sua associação a tópicos do
Pensamento Computacional e da Matemática.
A seguir, serão apresentados os procedimentos de coleta e análise de dados
conduzidos com o objetivo de explorar as questões de pesquisa definidas no
Capítulo 1. A partir dos resultados da revisão da literatura apresentada na seção 0,
pode-se constatar que uma pequena quantidade de trabalhos tem estudado o
fenômeno do ensino-aprendizagem do Pensamento Computacional levando em
consideração a sua complexidade, envolvendo de forma integrada fatores como: os
alunos; seus conhecimentos anteriores; a construção do conhecimento por
intermédio da interação entre os pares e com o professor; em um ambiente apoiado
por uma ferramenta computacional específica.
Creswell e Miller (2000) apontam que a triangulação de métodos é um dos
possíveis critérios de validação de uma pesquisa qualitativa; André (2007) aponta a
falta de análises com essa característica como uma limitação das pesquisas
100
recentes na área de Educação. Tais princípios são levados em consideração na
definição dos procedimentos de pesquisa, descritos na sequência deste capítulo. Os
procedimentos utilizados são: um teste de conhecimentos matemáticos, respondido
pelos alunos antes e após a participação na Oficina (seção 0); um questionário de
identificação do perfil dos alunos enquanto jogadores (seção 0); procedimentos para
observação etnográfica das atividades de aula (seção 0) e para análise dos jogos
desenvolvidos (seção 0); e uma entrevista final com os alunos após a participação
da Oficina (seção 0).
5.1 Contexto
5.1.1 O Instituto Federal de São Paulo
O Instituto Federal de São Paulo é uma instituição federal de ensino
especializada na educação tecnológica em seus diferentes níveis, desde a formação
inicial e continuada de trabalhadores, passando pelo ensino técnico, cursos
superiores de tecnologia, licenciaturas e engenharias, chegando à pós-graduação
lato e strictu sensu. Sua origem remonta ao início do século XX, quando o
presidente Nilo Peçanha implementa as primeiras escolas técnicas mantidas pelo
governo federal para o ensino de ofícios. Atualmente, o IFSP é uma instituição
multicampi, distribuída em vários municípios do estado de São Paulo (IFSP, 2008).
O campus de Guarulhos teve o início de seu funcionamento em 2006 com o
oferecimento de oitenta vagas para o Curso Técnico em Programação e
Desenvolvimento de Sistemas. Atualmente, na área de Informática, o campus
oferece o curso técnico em Manutenção e Suporte em Informática; o curso superior
de tecnologia em Análise e Desenvolvimento de Sistemas; e a pós-graduação lato
sensu em Gestão de Projetos em Desenvolvimento de Sistemas de Software (IFSP,
2008).
O primeiro ambiente de campo da nossa pesquisa é o curso técnico em
Manutenção e Suporte em Informática. O curso oferece semestralmente 40 vagas e
sua duração é de três semestres. O seu projeto pedagógico (CEFET/SP, 2007)
prevê a capacitação profissional dos alunos em três eixos de formação: manutenção
101
de microcomputadores e redes, desenvolvimento de sistemas voltados para Internet
e desenvolvimento de sistemas em programação estruturada.
Verifica-se que há uma estreita ligação entre esses objetivos e aqueles
preconizados para o desenvolvimento do Pensamento Computacional na educação
básica. No currículo de referência da ACM CSTA (CSTA, 2011), constam
habilidades relacionadas a conhecimentos básicos de hardware, redes de
computadores, construção de algoritmos para automação de processos e
programação, com a única diferença que no curso técnico essas habilidades são
desenvolvidas com finalidade profissionalizante.
Adicionalmente, no contexto brasileiro os cursos técnicos na área de
Informática constituem-se como o primeiro acesso de um grande contingente de
alunos a um curso de aprofundamento em tecnologia. Segundo o Censo Nacional da
Educação Básica de 2012 (INEP/MEC, 2012), os cursos técnicos em Informática
agregam a maior quantidade de matrículas em cursos técnicos na rede pública
(88.734 matrículas, ou 12,2% do total de matrículas na rede pública) e são o quarto
curso mais procurado na rede privada (38.812 matrículas, ou 6,1% do total de
matrículas na rede privada), o que indica a relevância do desenvolvimento de
intervenções didáticas nesse nível de ensino.
No escopo deste projeto, são analisadas as competências e habilidades do
Pensamento Computacional que, no curso técnico, são desenvolvidas em uma
disciplina introdutória à Lógica de Programação. Vale ressaltar que a atividade de
programação de computadores demanda um recorte de competências e habilidades,
no contexto das quais pretende-se compreender como ocorre a mobilização da
Matemática pelos alunos.
A disciplina é oferecida aos alunos ingressantes no curso e prevê em sua
ementa a introdução dos conceitos fundamentais da programação estruturada:
variáveis, estruturas condicionais e de repetição e sub-rotinas. Essa ementa
corresponde ao objetivo 5 do nível 2 na categoria Computer Practice and
Programming do currículo de referência (CSTA, 2011). Devido a um histórico de
baixo aproveitamento e retenção de alunos, a Oficina de Produção de Jogos Digitais
foi inicialmente criada como uma reformulação da abordagem didática daquela
102
disciplina. O projeto pedagógico do curso prevê que todas as aulas da disciplina
sejam ambientadas em um laboratório de informática. Além disso, a organização
didática da instituição prevê que as turmas em laboratório tenham no máximo 25
alunos. Por essa razão, a disciplina de Lógica de Programação usualmente abre
duas turmas a cada semestre.
5.1.2 A Universidad de Valparaíso
A Universidad de Valparaíso foi fundada como tal em 12 de fevereiro de 1981,
aglutinando os cursos que, até aquele momento, eram oferecidos pela sede de
Valparaíso da Universidad de Chile, que havia sido criada em 1972. Anteriormente a
essa data, a Universidade de Chile já era responsável pelo oferecimento de cursos
superiores públicos na região de Valparaíso. O curso mais antigo é o de direito,
fundado em 18 de maio de 1911 como Curso Fiscal de Leis de Valparaíso.
Atualmente, a universidade tem 16.000 alunos distribuídos em 41 cursos de
graduação, 32 programas de mestrado, 5 de doutorado, 28 especialidades médicas
e 5 especialidades odontológicas. O ambiente desta pesquisa é o curso de
graduação denominado Ingeniería Civil en Informática, com seis anos de duração,
oferecido desde o ano de 2005. O objetivo do curso é “formar engenheiros
integradores das Tecnologias de Comunicação e Informação (...) com sólidos
conhecimentos em ciências básicas, Engenharia e Informática” (UNIVERSIDAD DE
VALPARAÍSO, 2013). O curso também sofre com altos índices de reprovação e
evasão. De acordo com as estatísticas da escola (UNIVERSIDAD DE VALPARAÍSO,
2012), a maior evasão ocorre no quarto semestre do curso. No primeiro semestre, as
disciplinas com maior índice de reprovação são: Cálculo, Álgebra, Física e
Fundamentos de Programação. Esta última disciplina introduz os fundamentos da
programação estruturada (tipos de dados, estruturas de controle e utilização de
algoritmos para solução de problemas). Os alunos aprovados em Fundamentos de
Programação devem se matricular na disciplina Programação 1, na qual são
introduzidos os fundamentos da linguagem C. Ainda segundo as estatísticas da
escola, a taxa de reprovação média em Fundamentos de Programação é de cerca
de 65%, e acima de 45% em Programação 1.
103
O corpo docente do curso tem oferecido várias atividades extracurriculares
aos alunos do primeiro semestre de forma a aumentar o interesse e motivação dos
mesmos, bem como contribuir com a redução das taxas de reprovação. Após uma
recente iniciativa bem sucedida com atividades de robótica (BARCELOS et al., 2013)
conduzida pelo autor desta tese em conjunto com professores da instituição, foi
possível obter o apoio de um docente para o oferecimento da Oficina de Produção
de Jogos Digitais como uma atividade complementar aos alunos do primeiro
semestre do curso, agregando assim o segundo ambiente de campo da pesquisa.
5.2 Paradigma estruturado e o ambiente de programação do Scratch
A Oficina de Produção de Jogos Digitais foi desenvolvida com o foco no
desenvolvimento de algumas habilidades do Pensamento Computacional. Conforme
descrevemos na seção anterior, os alunos que participaram do oferecimento inicial
da Oficina são ingressantes em cursos de formação específica em Computação.
Dessa forma, há uma preocupação natural que os alunos adquiram, de forma
adequada,
competências
e
habilidades
relacionadas
à
programação
de
computadores. Nesse ponto, a formação profissionalizante se confunde com as
diretrizes para o desenvolvimento do Pensamento Computacional na educação
básica: as diretrizes curriculares da CSTA (2011), na categoria Computing Practice
and Programming, definem em seu objetivo 2-5: “implementar soluções para
problemas utilizando uma linguagem de programação incluindo: execução de laços,
estruturas condicionais, lógica, expressões, variáveis e funções”32.
Os conteúdos elencados na descrição desse objetivo fazem uma menção
indireta ao paradigma estruturado (ou imperativo33) de programação. Nesse
paradigma, a linguagem de programação é definida por comandos que atualizam o
valor de variáveis, armazenadas na memória (WATT, 1990). A execução dos
comandos pode ser controlada em função dos valores armazenados nas mesmas
variáveis, dando origem a estruturas de controle de fluxo, que podem ser
tipicamente condicionais (executadas apenas quando uma determinada expressão
32
Do original em inglês: “Implement problem solutions using a programming language
including: looping behavior, conditional statements, logic, expressions, variables and functions”
(CSTA, 2011, p. 58).
33
Do latim imperare, que significa “comandar” (WATT, 1990).
104
lógica assume valor verdadeiro) ou iterativas (indicando a repetição de um conjunto
de comandos enquanto uma expressão lógica assume valor verdadeiro ou falso). Na
maioria das linguagens de programação que seguem o paradigma estruturado, a
sintaxe das estruturas de controle de fluxo indica um alinhamento (ou endentação)
dos comandos associados às estruturas, de forma a contribuir com a clareza e
legibilidade. Várias linguagens de programação que são amplamente utilizadas na
atualidade, como Java, PHP e C#, se baseiam conceitualmente no paradigma
orientado a objetos e no paradigma de programação concorrente; no entanto, estes
são derivados do paradigma estruturado, e daí vem a importância do seu estudo
como uma introdução à programação de computadores.
Alguns livros didáticos para o ensino de Lógica de Programação estruturada
(p. ex., FORBELLONE; EBERSPÄCHER, 2005) apresentam uma sintaxe “fictícia”,
porém associada à endentação das estruturas de controle utilizada nas linguagens
de programação reais, de forma a treinar os alunos desde o início para escrever
programas nesse formato. Na Figura 7 apresentamos um exemplo de estrutura
condicional apresentada nessa sintaxe, de modo a ilustrar as suas particularidades.
VARIÁVEIS
inteiro A, B, aux
INÍCIO
LEIA A
LEIA B
SE A > B ENTÃO
aux ← A
A←B
B ← aux
FIM-SE
ESCREVA A
ESCREVA B
FIM
Figura 7 – Exemplo de estrutura condicional SE em uma linguagem de programação
estruturada
Fonte: Fornellone e Eberspächer (2005)
Nesse ponto reside uma das principais vantagens do Scratch para sua
adoção na Oficina de Produção de Jogos Digitais que será apresentada neste
105
capítulo. Em sua apresentação dos princípios que direcionaram o projeto do
ambiente do Scratch, Resnick et al. (2009) mencionam que pretendeu-se emular a
estrutura de kits de robótica como o Lego Mindstorms, que permitem amplas
oportunidades de exploração pelas crianças. Tais kits são baseados na ideia de
blocos que podem ser encaixados para a definição do formato e funcionamento dos
robôs. Dessa forma, no ambiente de programação do Scratch, definiu-se uma “área
de trabalho” onde blocos de comandos podem ser encaixados de várias formas.
Essa área corresponde à parte central da interface do Scratch, exibida na Figura 8.
As restrições da sintaxe são indicadas pelo formato do encaixe, e assim torna-se
possível testar várias possibilidades de codificação de forma bastante rápida. Ainda,
blocos individuais podem ser movidos para a área de trabalho; eles podem ser
testados imediatamente por meio de um duplo clique com o mouse.
Figura 8 – Ambiente de programação do Scratch
Esse ambiente que favorece a exploração permite que, segundo Resnick et
al. (2009), o ambiente do Scratch tenha um “chão baixo”, ou seja, permita a
obtenção dos primeiros resultados de forma rápida e com poucas dificuldades
(relacionadas, por exemplo, a detalhes de sintaxe). Por outro lado, as várias
funcionalidades disponíveis permitem um “teto alto”, ou seja, a criação de projetos
com uma combinação de funcionalidades poderosas. Ao mesmo tempo, ainda
segundo Resnick et al. (2009), pretende-se que o ambiente tenha “paredes largas”,
106
ou seja, permita a criação de projetos de diversos tipos, atendendo a grupos com
interesses igualmente diversos (jogos, histórias, animações, e assim por diante).
O Scratch disponibiliza estruturas de controle de fluxo que se assemelham
bastante àquelas definidas pelas linguagens de programação tradicionais que
seguem o paradigma estruturado. Tais estruturas tem a cor amarela e tem um
formato de “C”, dando a indicação visual que é possível “encaixar” comandos dentro
delas (Figura 9).
Figura 9 – Estruturas de controle de fluxo no Scratch com equivalente direto em
linguagens estruturadas
Essa similaridade das estruturas do Scratch com as estruturas de controle
das linguagens estruturadas traz consigo um potencial para que os alunos façam
uma transição conceitual mais suave para uma linguagem de programação
estruturada. Essa vantagem pode ser particularmente interessante para alunos que
seguirão estudando programação, como é o caso no contexto inicial de aplicação da
oficina. Como exemplo da possível associação conceitual com as linguagens
estruturadas, na Figura 10 é apresentado um programa equivalente ao apresentado
na Figura 7, construído com os blocos do Scratch.
107
Figura 10 – Programa de troca de valores entre variáveis utilizando os blocos do
Scratch
Outros ambientes voltados especificamente para o desenvolvimento de jogos,
como o GameMaker (YOYO GAMES, LTD., 2014), oferecem uma maior amplitude
de possibilidades de criação, porém não permitem a mesma associação conceitual
trazida pelas estruturas do Scratch. Da mesma forma, ambientes que permitem a
criação de mundos em três dimensões, como o Alice (CARNEGIE MELLON
UNIVERSITY, 2013) e o Kodu Game Lab (MICROSOFT RESEARCH, 2014)
possibilitam a construção de jogos mais complexos (e, talvez, com resultados que se
aproximassem mais da vivência dos nativos digitais com jogos); no entanto, a maior
complexidade para criação e gerenciamento dos elementos gráficos poderia tomar
um tempo excessivo34 e tirar o foco do objetivo principal da Oficina, ou seja, o
desenvolvimento de competências do Pensamento Computacional.
5.3 Estrutura da Oficina
Tendo em vista o desenvolvimento do Pensamento Computacional como uma
estratégia de resolução de problemas, pretendeu-se que esse objetivo fosse, na
realidade, atingido dentro do contexto da construção de jogos digitais e que essa
temática permeasse todas as atividades da Oficina. Mesmo que as atividades
34
Veremos na descrição das atividades da Oficina que, devido ao tempo limitado disponível
(cerca de 12 semanas), optamos sempre que possível pelo uso de elementos gráficos já
disponibilizados pelo ambiente do Scratch ou produzidos previamente.
108
estejam atualmente inseridas em um curso de formação específica em Computação,
não há impedimento para oferecê-las também a estudantes não matriculados em
cursos de formação específica em tecnologia.
As atividades da Oficina foram distribuídas ao longo de 12 semanas; cada
encontro semanal durou aproximadamente duas horas e meia. Em cada encontro, o
professor propõe a construção de um ou mais mecanismos de interação
relacionados à construção de um jogo digital. Para tal, os alunos foram convidados a
explorar conceitos relacionados ao desenvolvimento de jogos (animação de
sprites35, colisão, controles por teclado e mouse) e a fundamentos de programação
(variáveis, estruturas condicionais, laços e mensagens).
A partir dos tópicos a serem cobertos pela ementa das disciplinas nas quais a
Oficina seria aplicada, foram definidas atividades de acordo com quatro diretrizes:
(1) A construção de jogos deve motivar o desenvolvimento de todas as
atividades da oficina. Esta diretriz se embasa no princípio de fluência em jogos
proposto por Peppler e Kafai (2009), que argumentam que o processo de design e
construção de artefatos no contexto cultural dos jogos digitais pode promover um
processo de reflexão e aprendizagem significativa para os alunos.
(2) As atividades devem progressivamente levar à construção da
mecânica de um jogo completo. Em trabalhos anteriores que discutem o
desenvolvimento e condução de atividades práticas com o objetivo de fomentar o
Pensamento Computacional, Lee et al. (2011) propõem o arcabouço Usar –
Modificar – Criar, no qual este princípio se embasa. Inicialmente, os alunos são
apresentados a pequenos programas prontos com os quais possam interagir e
compreender seu funcionamento. A partir da compreensão obtida nessa primeira
etapa, os alunos são convidados a introduzir modificações no funcionamento e na
aparência dos programas. Por fim, à medida que os alunos adquirem maior
confiança, eles passam a criar seus próprios jogos, aplicando os conhecimentos
35
Um sprite (do latim spiritus) é uma imagem bidimensional que pode ser redesenhada em
uma tela, mudando de posição inúmeras vezes sem deixar traços da sua passagem – daí a analogia
com um “espírito” (BATTAIOLA et al., 2001). Nas primeiras arquiteturas computacionais voltadas para
jogos digitais, várias otimizações de hardware e software foram desenvolvidas para permitir a
manipulação de gráficos como sprites. Atualmente (por exemplo, no contexto do Scratch) o termo
sprite é utilizado para denominar qualquer imagem bidimensional que é renderizada em um jogo.
109
adquiridos nas etapas anteriores. Vale ressaltar que essa estratégia não se aplica de
forma estritamente linear: um aluno pode atuar como “criador” em uma determinada
etapa do processo de aprendizagem e em uma etapa seguinte voltar a atuar como
“usuário” para compreender um novo conceito. Porém, a estrutura das atividades e
os conhecimentos e habilidades a serem mobilizados induzem o aluno a atuar cada
vez mais como “criador” ao longo da Oficina. A estratégia ainda tem impacto na
manutenção de um nível adequado de desafio, como veremos na próxima diretriz.
(3) As atividades devem progressivamente demandar que novos
conceitos sejam explorados pelos alunos e, ao mesmo tempo, solicitar que o
aluno utilize novamente conceitos explorados anteriormente. A introdução de
novos conceitos de forma paulatina nas atividades (através do arcabouço Usar –
Modificar – Criar) tem como objetivo introduzir continuamente novos desafios que
induzam o aluno a buscar novos conhecimentos. Ao propor novos desafios ao
mesmo tempo em que conceitos já explorados são requisitados novamente, esperase manter os alunos em um estado de fluxo (NAKAMURA; CSIKSZENTMIHALYI,
2009) no que se refere ao seu trabalho autônomo na construção dos jogos. Da
mesma forma, espera-se que o professor possa atuar como um facilitador nos
momentos em que os alunos apresentem dificuldades pontuais relacionadas, por
exemplo, com a falta de um conceito específico. Nesses casos, espera-se que a
sequência
planejada
das
atividades
mantenha
os
alunos
na
Zona
de
Desenvolvimento Proximal (VYGOTSKY, 1978), permitindo assim seu avanço nas
atividades.
(4) A mecânica dos jogos, apesar de simples, deve trazer referências ao
universo dos jogos “reais” que sejam significativas para os alunos, quando
novamente nos embasamos na fluência em jogos proposta por Peppler e Kafai
(2009).
Consonante com uma proposta construcionista, em que a construção de
artefatos digitais pelos estudantes demanda uma postura razoavelmente autônoma,
as atividades da oficina seguem a abordagem de aprendizagem baseada em
problemas (ABP). Segundo Merril (2002), a aprendizagem baseada em problemas é
uma estratégia centrada no estudante, que trabalha de maneira colaborativa na
solução de algum problema, na qual a figura do professor serve como auxílio e a
110
construção do conhecimento é gradativa e empírica. Dessa forma, em cada
atividade da oficina, os estudantes recebem instruções sobre os objetivos propostos
para o jogo; além disso, são apresentados a um exemplo do jogo proposto sendo
executado e a partir daí iniciam o trabalho. O professor atua como um facilitador,
observando o trabalho e intervindo à medida que os alunos solicitam maiores
esclarecimentos.
Nas primeiras semanas da Oficina, as atividades são relacionadas aos
fundamentos de programação e da utilização do ambiente do Scratch. A partir do
quarto encontro os alunos começam a implementar jogos com funcionalidades
completas. Os jogos propostos são: Pedra-Papel-Tesoura, um jogo de Simulação de
Guerra e protótipos dos famosos jogos Breakout (“paredão”) e Pacman.
Tabela 10 – Programação de atividades da Oficina de Produção de Jogos
Semana
2
Atividade / conteúdo
Conceito de algoritmo. Familiarização com o ambiente do Scratch. Conceitos
de sprite e colisão entre sprites.
Variáveis e laços de repetição
3
Laços de repetição e estruturas condicionais
4
Criar o jogo Pedra-Papel-Tesoura
5-6
Criar o jogo Simulação de Guerra
7-8
Criar o jogo Breakout
1
9
10-11
12
Pacman – Criar a mecânica básica de movimentação do personagem
Pacman – Implementar as demais características do jogo (Projeto final)
Apresentação dos projetos finais
A seguir, descrevemos brevemente cada uma das sete atividades propostas
na Oficina e os principais conteúdos relacionados ao Pensamento Computacional e
à Matemática que devem ser mobilizados e desenvolvidos em cada uma delas. Uma
rubrica educacional das atividades é apresentada no Apêndice B. O material didático
disponibilizado aos professores da Oficina é apresentado no Apêndice C.
5.3.1 Atividade 1: Encontro do gato com o rato
A atividade proposta na primeira semana consiste inicialmente em manipular
um programa pronto, no qual apenas um sprite está presente. Os desenvolvedores
do ambiente Scratch optaram por utilizar essa terminologia, própria do domínio da
111
construção de jogos, para se referir a cada objeto apresentado na tela (chamada
pelo ambiente de palco). Cada sprite pode ter vinculado a si várias representações
gráficas intercambiáveis (chamadas de trajes) e comandos, cuja execução está
tipicamente vinculada à ocorrência de eventos no ambiente do jogo.
Dessa forma, o objetivo dessa primeira atividade é familiarizar o aluno com
todos esses novos conceitos através de um exemplo muito simples: o sprite com a
representação gráfica do gato, mascote do ambiente Scratch, traz dois blocos de
comandos, que permitem o deslocamento horizontal do sprite no palco quando as
setas direcionais esquerda ou direita do teclado são pressionadas. Um dos
comandos apresenta uma estrutura condicional, vinculada à colisão do sprite que
representa o gato com o segundo sprite, que representa o rato. Quando essa
situação é identificada durante o pressionamento da tecla, é exibida uma mensagem
em uma balão (Figura 11).
Figura 11 – Configuração inicial do primeiro programa manipulado pelos alunos e
código vinculado ao sprite do gato
Algumas intencionalidades estão presentes na configuração desse primeiro
programa distribuído para os alunos. Primeiramente, espera-se que o aluno
identifique que é possível alterar a representação gráfica do palco (já que a
representação padrão, que é um fundo branco, foi previamente trocada pela imagem
de uma sala de aula). Ainda, espera-se que o aluno identifique desde o início que
um programa pode ser composto por vários sprites e que pode haver código
vinculado a cada um deles. Seguindo essa mesma intenção, a primeira atividade de
alteração (LEE et al., 2011) solicitada aos alunos é reproduzir o código presente no
sprite do gato para que o rato também possa se movimentar de forma análoga,
112
porém sendo controlado por teclas diferentes do teclado, e que também o rato “diga”
uma mensagem quando houver uma colisão com o gato.
5.3.2 Atividade 2: Pescaria
A segunda atividade consiste em um jogo de pescaria. É fornecida aos alunos
uma implementação inicial onde um peixe aparece sucessivamente em posições da
tela sorteadas de forma aleatória. Quando um clique do mouse é efetuado no peixe,
isso ocasiona o incremento de uma variável, cujo valor é apresentado no canto
superior esquerdo da tela (Figura 12). Assim, a manipulação inicial do jogo pelos
alunos abre para o professor a oportunidade de discutir e apresentar o conceito de
variável como área de armazenamento de dados em um programa, bem como a
repetição da execução de comandos em laços, presente na estrutura de bloco
Sempre.
Figura 12 – Configuração inicial do jogo de Pescaria e código vinculado ao sprite do
peixe
O posicionamento do peixe em posições aleatórias da tela traz pela primeira
vez o conceito matemático da representação do palco como um plano cartesiano. É
possível notar que o posicionamento do peixe, através do comando vá para, é
definido pelo sorteio de dois valores aleatórios, correspondentes ao posicionamento
nos eixos x e y. No ambiente do Scratch, o posicionamento dos sprites no plano é
dado por coordenadas inteiras, variando entre -240 e 240 no eixo x e entre -180 e
180 no eixo y.
Nesta atividade, os alunos devem ampliar a funcionalidade do jogo, incluindo
mais um peixe, que adicione dois pontos à pontuação do jogo quando for clicado.
113
Em uma segunda etapa, o jogo deve ficar mais “difícil” quando o jogador atingir 20
pontos: nesse momento, o intervalo de exibição dos peixes deve ser reduzido. Essa
é uma oportunidade para mobilizar o conceito de execução condicional de
comandos, apresentada na atividade anterior. A terceira etapa de alteração exige a
mobilização do conceito matemático de proporcionalidade: é solicitado aos alunos
que definam uma quantidade limitada de exibições de cada peixe, e que ao final do
jogo seja exibido o percentual de aparições de cada peixe que foram clicadas com
sucesso pelo jogador. Além disso, faz-se necessário o uso de mais variáveis para
armazenar a quantidade de “cliques” efetuada em cada peixe, bem como a
quantidade de aparições de cada peixe.
Figura 13 – Versão final do jogo de Pescaria: exibição do percentual de peixes de
cada tipo que foram clicados pelo jogador
5.3.3 Atividade 3: Jogo de adivinhação
A terceira atividade é o primeiro jogo que deve ser produzido desde o início
inteiramente pelos alunos. O mecanismo de geração de números aleatórios pelo
Scratch deve ser utilizado para armazenar em uma variável um número entre 1 e
100. Um sprite, representando um personagem de livre escolha, deve perguntar ao
jogador qual foi o número “pensado” por ele. Quando o jogador informa sua
tentativa, o personagem informa se o número sorteado é menor ou maior do que a
aposta do jogador, e permite uma nova tentativa (Figura 14). Além de retomar os
conceitos de geração de números aleatórios e de execução de comandos em laços
de repetição, a atividade introduz a entrada de dados via teclado, pouco usual no
contexto de jogos, mas fundamental para as aplicações convencionais que
possivelmente serão desenvolvidas pelos alunos no futuro.
114
Em um segundo momento, os alunos são solicitados a limitar a quantidade
possível de tentativas a serem feitas pelo jogador para advinhar o número. Essa
restrição adicional abre a possibilidade de discutir qual a melhor estratégia para
acertar o número sorteado, em termos da quantidade mínima de tentativas
necessárias; essa é uma questão que fomenta a exploração de aspectos da
Matemática Discreta e algoritmos de busca. Discutiremos essa possibilidade com
maiores detalhes no próximo capítulo.
Figura 14 – Jogo de Adivinhação: entrada de dados via teclado e resposta do
personagem
5.3.4 Atividade 4: Pedra, papel e tesoura
A quarta atividade é uma implementação do clássico jogo de pedra, papel e
tesoura. Dois sprites devem ser criados, correspondentes a cada um dos jogadores.
Cada sprite deve ser acionado por um conjunto de três teclas, sendo que cada uma
delas muda o traje para o gesto de pedra, papel ou tesoura. As imagens que
representam os gestos são previamente fornecidas para os alunos.
Assim que ambos os jogadores pressionam uma tecla, o jogo deve informar
de alguma forma qual jogador venceu ou se houve empate. Essa funcionalidade
exige que o aluno identifique corretamente as nove possíveis configurações finais de
jogo, tarefa que exige a mobilização do raciocínio combinatório. Do ponto de vista do
Pensamento Computacional, existe ainda a necessidade de se lidar com a
sincronização de eventos que ocorrem de forma paralela: o resultado do jogo
somente pode ser verificado quando ambos os jogadores pressionam suas teclas.
115
Figura 15 – Indicação de vitória e derrota no jogo Pedra, papel ou tesoura
Em uma segunda etapa, a questão de sincronização de eventos é mobilizada
novamente: os alunos são solicitados a construir uma segunda versão do jogo, na
qual um dos jogadores é o computador. Uma jogada aleatória é sorteada pelo
computador assim que o jogador humano escolhe sua jogada, e então o resultado
do jogo é exibido.
5.3.5 Atividade 5: Simulação de Guerra
Na quinta atividade os alunos desenvolvem uma simulação de guerra, com
dois sprites representando tanques. Um dos tanques fica estático no canto inferior
esquerdo da tela e pode apenas ser rotacionado no sentido horário ou anti-horário.
Quando a barra de espaços é pressionada, este tanque deve disparar um projétil,
representado por um terceiro sprite (Figura 16). Os alunos devem construir um
algoritmo que define a trajetória linear do projétil. Para tanto, a execução de
comandos em laços de repetição deve ser mobilizada novamente pelos alunos.
Neste caso, o problema induz a definição explícita da condição de parada para o
laço que define a trajetória do projétil – a colisão contra o inimigo ou contra os limites
da tela.
116
Figura 16 – Resultado esperado para o jogo Simulação de Guerra
O tanque inimigo inicialmente parte de uma posição fixa da tela e deve se
deslocar em direção ao tanque fixo, que se defende disparando o projétil. Se o
projétil atinge o tanque inimigo, ele explode. No entanto, se o tanque inimigo atinge o
tanque fixo, é o fim do jogo. Em uma segunda etapa, é solicitado que o tanque
inimigo surja na tela em uma posição aleatória ao longo do eixo x ou do eixo y, de
forma a criar uma dificuldade adicional. Para a solução deste problema em particular
os alunos devem aplicar corretamente conceitos relacionados ao posicionamento do
sprite do tanque no plano cartesiano tradicional.
5.3.6 Atividade 6: Arkanoid
O Breakout é um jogo clássico desenvolvido inicialmente em 1976 pela Atari
para máquinas de fliperama e que deu origem a várias versões e adaptações nos
anos seguintes (GOLDBERG, 2007). Um popular clone do Breakout, desenvolvido
inicialmente para máquinas de fliperama e posteriormente adaptado para
computadores de 8 bits, é denominado Arkanoid, título que dá nome a esta
atividade36. A mecânica a ser construída pelos alunos na atividade consiste em uma
plataforma, que se desloca apenas ao longo do eixo horizontal e se posiciona na
parte inferior da tela. A plataforma pode rebater uma bola que se desloca
linearmente pela tela e atinge blocos que se posicionam na parte superior da tela. A
bola sofre uma reflexão na sua trajetória quando atinge qualquer um dos três blocos,
mas cada um deles tem um comportamento diferente quando atingido: o bloco
36
A escolha do nome Arkanoid para a atividade se deu unicamente pela memória afetiva do
autor desta tese relacionada aos computadores de 8 bits da linha MSX. Entretanto, acredita-se que o
nome Breakout é mais significativo para o público internacional deste trabalho e foi utilizado em
publicações derivadas. No Brasil, o jogo é popularmente conhecido como “paredão”.
117
amarelo desaparece imediatamente, o bloco verde só desaparece ao ser atingido
três vezes pela bola e o bloco vermelho desaparece imediatamente mas libera uma
cápsula que, se atingida pela barra, fornece mais uma vida ao jogador.
Figura 17 – Resultado esperado para o jogo Breakout
Se a bola ultrapassar o limite vertical em que puder ser alcançada pela
plataforma, o jogador perde uma vida e a bola deve ser lançada novamente. Além
do deslocamento de sprites através de laços de repetição, nesta atividade também é
mobilizado novamente o uso de variáveis (para indicar a pontuação do jogo e o
estado dos blocos) e de estruturas condicionais. Do ponto de vista matemático, a
reflexão da bola quando atinge a plataforma ou um bloco consiste na identificação
do ângulo suplementar ao ângulo direcional do sprite da bola. Cabe ressaltar que o
Scratch permite a manipulação direta das coordenadas x e y de um sprite para sua
movimentação, mas também disponibiliza uma forma alternativa de manipulação,
baseada na definição de um ângulo direcional e de uma quantidade de “passos” de
deslocamento. Essa alternativa se assemelha à definição de coordenadas polares,
ou à sintaxe para deslocamento da tartaruga de desenho na linguagem Logo.
5.3.7 Atividade 7: Pacman
A última atividade da Oficina consiste na construção parcial da mecânica do
jogo Pacman. Devido à maior complexidade dessa tarefa, optou-se por dividi-la em
várias tarefas que ocupam as quatro últimas semanas da programação da Oficina.
As suas últimas etapas são desenvolvidas como o projeto final da Oficina, utilizado
para fins de consolidação do aprendizado e avaliação dos alunos.
118
Inicialmente os alunos devem fazer com que o personagem se movimente
somente sobre as linhas de uma grade pré-definda com quadrados de 16 pixels de
lado (Figura 18). Essa estratégia tem como objetivo permitir um deslocamento
controlado do personagem dentro do labirinto do jogo, que posteriormente substituirá
a imagem da grade. Essa atividade foi definida após algumas experiências onde
verificou-se que o mecanismo de colisão do Scratch não se mostrava adequado
para emular a movimentação restrita dentro de um labirinto, presente no jogo
original.
Figura 18 – Pacman: movimentação do personagem sobre as linhas da grade
Figura 19 – Pacman: substituição da imagem da grade pela imagem do labirinto
Na segunda semana da atividade, os alunos são orientados a usar um
mecanismo para impedir que o Pacman mude de direção quando há uma parede do
labirinto impedindo. Cria-se um novo sprite indicador (Figura 20) que acompanha o
sprite do Pacman de forma a permitir a identificação da colisão entre as cores do
indicador e a cor azul das paredes do labirinto.
119
Figura 20 – Pacman: funcionamento do sprite indicador de colisão com uma parede
do labirinto
A partir da definição desse novo sprite, solicita-se que os alunos implementem
um trecho de código (Figura 21) que permite a constante atualização de quatro
variáveis, indicando se o Pacman está próximo de colidir com uma parede em
alguma das quatro direções (cima, embaixo, direita ou esquerda). Essa
implementação guiada pelo professor abre a oportunidade de discutir com os alunos
quais condições devem ser satisfeitas para que o Pacman continue se
movimentando (por exemplo, se o sprite tem seu ângulo direcional apontando para a
direita e a variável “tocando na direita” tem o valor falso, a movimentação é
possível). Tem-se aí o objetivo de mobilizar novamente aspectos do raciocínio
combinatório e introduzir o conceito do operador booleano E. O sprite indicador pode
ser posteriormente ocultado sem prejuízo de sua funcionalidade, permitindo um
aspecto visual mais “limpo” para o jogo.
Figura 21 – Pacman: código para atualização das variáveis que indicam colisão com
uma parede do labirinto
Após fazer com que o Pacman se movimente corretamente dentro do
labirinto, os alunos ingressam na terceira e última etapa da atividade, que consiste
na mecânica do jogo per se: implementar a coleta dos pontos amarelos pelo
Pacman e a consequente pontuação, e incorporar inimigos ao jogo. No primeiro
caso, trata-se de identificar a colisão do Pacman com a cor amarela (já que os
pontos amarelos fazem parte da imagem de fundo e não são sprites por si só) e usar
120
o mecanismo de desenho do Scratch para cobrir o ponto com a cor preta. No
segundo caso, solicita-se que os alunos implementem dois inimigos (os
“fantasmas”). Um deles deve patrulhar uma região fixa do labirinto e o outro deve
perseguir o Pacman. Trata-se de duas tarefas com diferentes níveis de
complexidade: no primeiro caso, a movimentação do fanatasma é análoga àquela
que os alunos já terão implementado para movimentar o tanque na Simulação de
Guerra ou a bola no Breakout. Na Figura 22 é indicada uma possível trajetória nesse
caso. Já no segundo caso, seguindo a mecânica original do jogo (PITTMAN, 2011),
é necessário calcular a distância do fantasma vermelho para o Pacman (Figura 22)
de forma a orientar a tomada de decisão quando houver mais de uma possibilidade
de direção para o deslocamento do fantasma. Para tanto, é necessário o cálculo da
distância euclidiana entre dois pontos no plano, conceito matemático que se
pretende que os alunos mobilizem.
Figura 22 – Pacman: diagrama do funcionamento esperado dos fantasmas inimigos
121
5.4 Pré e pós-teste de conhecimentos matemáticos
Em seu contexto de aplicação, a Oficina de Produção de Jogos não se
constitui como um ambiente formal de ensino e aprendizagem de Matemática.
Porém, considerando as evidências do uso não formal da Matemática fora do
ambiente escolar, discutidas por Noss et al. (2000), pretendemos identificar, a partir
de um pré-teste, qual a familiaridade prévia dos alunos com os conceitos
matemáticos que podem ser mobilizados, formalmente ou não, durante as atividades
da Oficina. Tais conceitos, identificados no processo de mapeamento dos conteúdos
vinculados às atividades da Oficina, estão resumidos na Tabela 11.
Tabela 11 – Jogos da Oficina e conceitos matemáticos
Jogo
Conceito matemático
Pescaria
Proporcionalidade e expressões algébricas
Intervalos numéricos (números reais)
Pontos no plano cartesiano
Jogo de Advinhação
Intervalos numéricos (números inteiros)
Pedra, papel e tesoura
Princípio fundamental da contagem
Simulação de Guerra
Arkanoid
Pacman
Intervalos no plano cartesiano
Variação de posições nos eixos x e y
Círculo trigonométrico
Ângulo replementar e expressões algébricas
Resto da divisão
Distância entre pontos no plano cartesiano
Para tanto, foram utilizadas questões relativas a cada conceito já aplicadas na
Prova Brasil e ENEM e disponibilizadas publicamente no sítio do INEP na Internet
(INEP/MEC, 2013, 2011, 2008). Adicionalmente, foi necessário recorrer ao uso de
questões do ENEM (INEP/MEC, 2005), apesar de ser uma avaliação aplicada ao
final do ensino médio, ou seja, além do nível de ensino dos participantes da Oficina
no Brasil; tais questões foram utilizadas quando não foi possível identificar questões
com o perfil desejado já aplicadas na Prova Brasil. A avaliação é repetida como um
pós-teste ao final da Oficina com o intuito de identificar se alguma alteração no
domínio dos conceitos ou no processo de resolução dos problemas pelos alunos
pode ser identificada. Para efeito de comparação dos resultados com o grupo de
alunos do Chile, assegurou-se que os conceitos cobertos na avaliação estivessem
presentes nas diretrizes curriculares para o ensino médio em ambos os países.
122
5.4.1 Questão 1 – Expressões algébricas e identificação de padrões
A primeira questão (Figura 23) apresenta uma sequência numérica,
apresentada a partir da disposição gráfica de pequenos círculos. Além de identificar
a regularidade na formação da sequência (correspondente à Competência 2 –
Identificar regularidades e padrões, apresentada na seção 0), o aluno deve
identificar a fórmula algébrica que produz corretamente o n-ésimo elemento da
sequência.
As figuras mostradas a seguir estão organizadas dentro de um padrão que se repete.
Mantendo essa disposição, a expressão algébrica que representa o total de pontos T em
função da ordem n (n = 1, 2, 3,...), é
(a)
(b)
(c)
(d)
T = 2n – 1.
T = 2n + 1.
2
T = n – 1.
2
T = n + 1.
Figura 23 – Primeira questão do teste: expressões algébricas e identificação de
padrões
Fonte: (INEP/MEC, 2013)
5.4.2 Questão 2 – Ângulo replementar
Na segunda questão (Figura 24), é utilizada a figura dos ponteiros de um
relógio para que o aluno identifique os dois ângulos formados a partir das semi-retas
representadas pelos ponteiros, além de ser necessário mobilizar que a soma de dois
ângulos replementares totaliza 360º.
123
Os 2 ângulos formados pelos ponteiros de um relógio às 8 horas medem
(a)
(b)
(c)
(d)
60° e 120°.
120° e 160°.
120° e 240°.
140° e 220°.
Figura 24 – Segunda questão do teste: ângulo replementar
Fonte: (INEP/MEC, 2011)
5.4.3 Questão 3 – Porcentagem
A terceira questão (Figura 25) envolve o cálculo de porcentagens, que é
mobilizado no Jogo de Pescaria.
Distribuímos 120 cadernos entre as 20 crianças da 1ª série de uma escola. O número de
cadernos que cada criança recebeu corresponde a que porcentagem do total de
cadernos?
(a)
(b)
(c)
(d)
5%
10%
15%
20%
Figura 25 – Terceira questão do teste: porcentagem
Fonte: (INEP/MEC, 2011)
5.4.4 Questão 4 – Coordenadas cartesianas e variação nos eixos x e y
A quarta questão (Figura 26) solicita que o aluno, dado um ponto de partida,
identifique a partir de variações nos eixos x e y, descritas em linguagem informal
(subir, descer, virar à direita ou à esquerda) qual o ponto de chegada. Essa questão
foi selecionada devido à similaridade da sua linguagem e operações com os
comandos para movimentação de sprites no Scratch, necessários para a
implementação de vários dos jogos da Oficina.
124
A figura abaixo ilustra as localizações de alguns pontos no plano.
João sai do ponto X, anda 20m para a direita, 30m para cima, 40 m para a direita e 10m
para baixo.
Ao final do percurso, João estará no ponto:
(a)
(b)
(c)
(d)
A
B
C
D
Figura 26 – Quarta questão do teste: coordenadas cartesianas e variação nos eixos x
ey
Fonte: (INEP/MEC, 2008)
5.4.5 Questão 5 – Identificação de pontos no plano cartesiano
Ainda no plano cartesiano, a quinta questão (Figura 27) solicita que o aluno
compreenda e aplique o conceito de coordenadas para a identificação de um ponto
solicitado (ao contrário da questão anterior, na qual os pontos são diretamente
identificados por letras maiúsculas).
125
A figura a seguir indica um mapa bastante simplificado de uma cidade, em que estão
marcados alguns de seus pontos de interesse.
Legenda:
X – Teatro
K – Shopping
L – Quadra Poliesportiva
Z – Estádio de Futebol
P – Catedral
Y – Cinema
Nesse mapa, a coordenada (5, G) indica a localização:
(a)
(b)
(c)
(d)
da catedral
da quadra poliesportiva
do teatro
do cinema
Figura 27 – Quinta questão do teste: identificação de pontos no plano cartesiano
Fonte: (INEP/MEC, 2013)
5.4.6 Questão 6 – Distância entre pontos no plano cartesiano
Esta questão (Figura 28) foi criada a partir do contexto construído pela
questão 5 de forma a mobilizar o cálculo da distância entre dois pontos em um plano
cartesiano, utilizando o Teorema de Pitágoras. Esse problema é encontrado pelos
alunos na implementação do Pacman, quando o inimigo precisa identificar qual a
sua distância para o Pacman de modo a persegui-lo.
Considerando o mapa da questão anterior, qual a distância em linha reta entre o cinema
e o shopping?
(a)
(b)
(c)
(d)
2
3
4
5
Figura 28 – Sexta questão do teste: distância entre pontos no plano cartesiano
Fonte: Adaptada pelo autor a partir da questão original em (INEP/MEC, 2013)
126
5.4.7 Questão 7 – Aritmética e o uso da divisão inteira
Esta questão (Figura 29), apesar de mobilizar apenas conceitos aritméticos,
foi retirada do ENEM 2005 (INEP/MEC, 2005). A questão foi selecionada por
mobilizar o conceito da divisão inteira, que é tipicamente pouco explorado em
problemas na educação básica mas é relevante em contextos computacionais.
Durante a Oficina, os alunos puderam se deparar com um problema de identificação
de coordenadas múltiplas de um determinado valor para fazer o sprite que
representa o Pacman se deslocar dentro dos limites do labirinto.
Os números de identificação utilizados no cotidiano (de contas bancárias, de
CPF, de Carteira de Identidade etc) usualmente possuem um dígito de verificação,
normalmente representado após o hífen, como em 17326-9. Esse dígito adicional tem a
finalidade de evitar erros no preenchimento ou digitação de documentos.
Um dos métodos usados para gerar esse dígito utiliza os seguintes passos:
•
•
•
•
multiplica-se o último algarismo do número por 1, o penúltimo por 2, o
antepenúltimo por 1, e assim por diante, sempre alternando multiplicações por 1
e por 2.
soma-se 1 a cada um dos resultados dessas multiplicações que for maior do que
ou igual a 10.
somam-se os resultados obtidos .
calcula-se o resto da divisão dessa soma por 10, obtendo-se assim o dígito
verificador.
O dígito de verificação fornecido pelo processo acima para o número 24685 é
(a)
(b)
(c)
(d)
(e)
1
2
4
6
8
Figura 29 – Sétima questão do teste: aritmética e uso da divisão inteira
Fonte: (INEP/MEC, 2005)
5.4.8 Questão 8 – Raciocínio combinatório
O raciocínio combinatório simples deve ser empregado pelos alunos para
identificar todos os possíveis resultados finais do jogo Pedra, papel e tesoura, de
forma que o jogo exiba uma mensagem informando qual jogador ganhou. O públicoalvo brasileiro participante da pesquisa é composto, em sua maioria, por cursantes
127
do segundo ano do ensino médio. Assim, não é possível assumir que tais alunos
teriam conhecimentos mais avançados em combinatória, como o cálculo de
permutações e combinações, que tipicamente são abordados mais ao final do
ensino médio. Paralelamente a isso, identificou-se uma carência de questões
relacionadas à combinatória na Prova Brasil, mesmo sendo o Princípio Fundamental
da Contagem um tópico recomendado para o ensino fundamental (BRASIL, 1997).
Por outro lado, as questões apresentadas no ENEM tendem a envolver aspectos
mais avançados do raciocínio combinatório, e não unicamente o Princípio
Fundamental da Contagem. Dessa forma, nos apoiamos no trabalho de Vazquez e
Malagutti (2010), que relata experiências com o desenvolvimento do raciocínio
combinatório em turmas do ensino médio, de onde foi extraída a oitava questão
(Figura 30).
Um semáforo é um aparelho de sinalização urbana, rodoviária ou ferroviária que
orienta o tráfego por meio de luzes. A escolha da sequência de cores: vermelho no topo,
amarelo no meio e verde embaixo é uma forma de não confundir o motorista e segue
convenções internacionais.
Suponha que vamos construir outros semáforos usando as cores vermelho,
amarelo e verde, levando em consideração a ordem em que as cores aparecem. Ou
seja, um semáforo (vermelho, amarelo, verde) e (verde, amarelo, vermelho) são
diferentes.
I.
Quantos são os diferentes sinais de trânsito que podemos construir com três
cores, respeitando a ordem e sem repeti-las?
II. Quantos semáforos podemos formar se for possível repetir as cores?
As respostas às perguntas I e II são, respectivamente:
(a)
(b)
(c)
(d)
6 e 27
5 e 27
5e9
6e9
Figura 30 – Oitava questão do teste: raciocínio combinatório
Fonte: (VAZQUEZ; MALAGUTTI, 2010)
5.5 Identificação do perfil dos alunos
Conforme Goetz e LeCompte (1984), a utilização do método etnográfico
demanda a identificação clara do perfil dos sujeitos da pesquisa, de forma a
128
contextualizar as ações observadas durante a pesquisa de campo. Para tanto foi
definido um questionário, respondido pelos alunos no primeiro encontro da Oficina,
para identificação inicial do seu perfil enquanto usuários de jogos digitais. Além dos
dados demográficos usuais (sexo, idade, escolaridade), os alunos foram
questionados sobre a frequência com que jogam jogos digitais, o tipo de dispositivo
em que jogam e há quanto tempo jogam.
Os alunos também foram solicitados a responder, usando uma escala Likert
de 1 a 5 (LIKERT, 1932), sua preferência por jogos dos seguintes gêneros: RolePlaying Games (RPG), Esporte, Educacionais, Simulação, Tiro, Aventura e
Estratégia. Essas categorias combinam as classificações propostas por Sellers
(2006) e Pinelle, Wong e Stach (2008). Além dessas, optou-se por incluir a categoria
de jogos casuais, refletindo o recente fenômeno dos jogos de curta duração,
voltados predominantemente para dispositivos móveis (JUUL, 2010). Cada categoria
foi apresentada junto a exemplos populares de jogos pertencentes a ela, de forma a
facilitar a identificação pelos respondentes.
A seguir, os alunos foram solicitados a classificar, também usando uma
escala Likert de 1 a 5 (LIKERT, 1932), o grau de importância de dezenove critérios
de qualidade na sua experiência como jogadores. Os critérios de qualidade foram
baseados nos resultados de uma pesquisa anterior (BARCELOS et al., 2011) que
indicou que esse conjunto consolidado de critérios, ao ser utilizado em avaliações
heurísticas de jogos, tende a permitir a classificação dos mesmos problemas que
conjuntos de critérios mais numerosos (e com um nível de redundância
potencialmente maior). Os critérios foram apresentados no questionário em uma
linguagem simplificada; na Tabela 12 são apresentados o texto original das
heurísticas definidas em (BARCELOS et al., 2011) e a redação apresentada no
questionário. O questionário completo é apresentado no Apêndice D.
129
Tabela 12 – Heurísticas extraídas de Barcelos et al. (2011)
H1
H2
H3
H4
Os controles devem ser claros, personalizáveis e fisicamente confortáveis; suas respectivas
ações de resposta devem ser imediatas
O jogador deve poder personalizar o áudio e o vídeo do jogo de acordo com suas
necessidades
O jogador deve conseguir obter com facilidade informações sobre seu status e pontuação no
jogo
O jogo deve possibilitar que o jogador desenvolva habilidades que serão necessárias
futuramente
H5
O jogador deve encontrar um tutorial claro de treinamento e familiarização com o jogo
H6
Todas as representações visuais devem ser de fácil compreensão pelo jogador
H7
O jogador deve ser capaz de salvar o estado atual para retomar o jogo posteriormente
H8
O layout e os menus devem ser intuitivos e organizados de forma que o jogador possa
manter o seu foco na partida
H9
A história deve ser rica e envolvente criando um laço com o jogador e seu universo
H10
Os gráficos e a trilha sonora devem despertar o interesse do jogador
H11
Os atores digitais e o mundo do jogo devem parecer realistas e consistentes
H12
O objetivo principal do jogo deve ser apresentado ao jogador desde o início
H13
O jogo deve propor objetivos secundários e menores, paralelos ao objetivo principal
H14
O jogo deve possuir vários desafios e permitir diferentes estratégias
H15
O ritmo do jogo deve levar em consideração a fadiga e a manutenção dos níveis de atenção
H16
O desafio do jogo pode ser ajustado de acordo com a habilidade do jogador
H17
O jogador deve ser recompensado pelas suas conquistas de forma clara e imediata
H18
A inteligência artificial deve representar desafios e surpresas inesperadas para o jogador
H19
O jogo oferece dicas, mas não muitas
5.6 Observação etnográfica das atividades de aula
Conforme descrito na seção 0, a Oficina foi aplicada a dois ambientes de
pesquisa: um curso técnico no Instituto Federal de São Paulo e um curso superior na
Universidad de Valparaíso. A necessidade operacional de separação das turmas
para o uso de laboratórios de informática e, devido a isso, a necessidade de contar
com mais de um professor para acompanhar as turmas, criou a necessidade de
definição de procedimentos bem definidos para o registro da observação em sala de
aula.
130
O autor desta tese foi responsável por uma das turmas no Instituto Federal de
São Paulo, enquanto que um colega foi responsável pela outra turma. Na
Universidad de Valparaíso, um aluno bolsista foi inicialmente responsável por duas
turmas. É um procedimento padrão daquela universidade que alunos bolsistas sejam
responsáveis por atividades extracurriculares de monitoria (lá chamadas de
ayudantia), como foi o caso da Oficina. Foi definido que todos os professores
registrassem em um diário de bordo as atividades realizadas, seu andamento, bem
como os questionamentos e comentários dos alunos. Adicionalmente, na turma sob
a responsabilidade do autor desta tese, foram obtidas gravações de áudio de todos
os encontros, com o consentimento prévio dos participantes, para auxiliar no
processo de construção do diário de bordo. Quando foi necessário complementar a
coleta de dados das turmas sob responsabilidade dos outros professores, foram
realizadas entrevistas semiestruturadas com os mesmos. O contato com os
participantes do Chile foi feito por email e por conferências de vídeo utilizando o
Skype.
5.7 Análise dos jogos produzidos pelos alunos
Todos os jogos desenvolvidos pelos estudantes durante a Oficina também
foram coletados para análise posterior. Dentro de uma perspectiva construcionista,
espera-se que as competências e habilidades adquiridas pelos alunos sejam
evidenciadas nos artefatos construídos por eles (BRENNAN; RESNICK, 2012;
DENNER; WERNER; ORTIZ, 2012).
A primeira análise refere-se às estratégias empregadas pelos alunos para
resolver cada uma das tarefas propostas em cada atividade, elencadas no Apêndice
B. A identificação das estratégias envolve, do ponto de vista da programação, os
tipos de comandos e condições utilizados e, do ponto de vista matemático, os
conceitos empregados para a resolução, da forma com que foram expressos na
linguagem de programação do Scratch. A partir do mapeamento de competências,
habilidades e conteúdos que foi realizado, pretendeu-se evidenciar estratégias
esperadas ou novas para resolução dos problemas propostos.
A segunda análise refere-se aos aspectos motivacionais relacionados à
jogabilidade dos jogos construídos. Para tanto, os jogos foram separados em duas
131
categorias: (i) jogos que incorporaram somente as funcionalidades mínimas
requeridas na atividade; (ii) jogos que incorporaram funcionalidades extras. A partir
dessa separação, pretendeu-se investigar quais seriam os fatores que poderiam
influenciar
os
estudantes
a
acrescentar
mais
funcionalidades
aos
jogos
desenvolvidos. Com esse objetivo, foi realizada uma avaliação heurística de cada
jogo que incorporou funcionalidades extras.
A avaliação heurística é uma técnica de inspeção originalmente proposta por
Nielsen e Molich (1990) para identificação de problemas de usabilidade em sistemas
interativos tomando como base da inspeção um conjunto de critérios heurísticos de
usabilidade previamente definidos. Porém, no contexto deste trabalho, a técnica foi
adaptada para possibilitar a identificação dos critérios de jogabilidade aos quais
poderiam ser associadas as funcionalidades adicionais implementadas pelos
estudantes. Dessa forma, dois pesquisadores analisaram os jogos de forma
independente, associando uma ou mais heurísticas de jogabilidade propostas por
Barcelos et al. (2011) a cada funcionalidade adicional. Finalmente, os resultados dos
avaliadores foram verificados novamente a fim de identificar discrepâncias; a
combinação dos resultados foi então comparada com a avaliação dos critérios de
qualidade feita pelos estudantes nos questionários.
5.8 Entrevistas finais
Nas últimas atividades da Oficina, os alunos trabalharam no desenvolvimento
de um projeto final, que consistiu na finalização do jogo Pacman. Conforme descrito
na seção 0, o uso de entrevistas baseadas em artefatos pode revelar a perspectiva
das práticas utilizadas pelos alunos para incorporar conceitos do Pensamento
Computacional nos artefatos produzidos (BRENNAN; RESNICK, 2012). Dessa
forma, para complementar as evidências coletadas com a observação das atividades
de aula e as perguntas respondidas a cada aula, foi definida uma entrevista
semiestruturada, realizada pelo professor com cada equipe e motivada pela
apresentação, no computador, do jogo final construído pelos alunos. As questões
direcionadoras dessa entrevista foram:
132
•
Você usou alguma matemática para implementar os fantasmas?
Esta pergunta tem por objetivo identificar as concepções dos alunos sobre a
necessidade de mobilizar conceitos matemáticos (distância entre pontos no plano
cartesiano, variação de coordenadas nos eixos x e y, e outras) para cumprir as
tarefas solicitadas.
•
O que você achou mais difícil de implementar no jogo?
Pergunta de propósito geral, visando identificar as dificuldades surgidas no
desenvolvimento da atividade como um todo.
•
O que você incluiria em uma segunda versão do jogo para torná-lo mais
interessante, se tivesse mais tempo?
A última pergunta teve como objetivo identificar a concepção dos alunos
sobre possíveis expansões para o design de interação proposto inicialmente para o
jogo; também pretendeu-se identificar como essa concepção se relaciona com o
perfil inicial de preferências dos alunos enquanto jogadores.
As entrevistas com os alunos brasileiros foram gravadas, com prévio
consentimento dos participantes, de modo a facilitar a transcrição posterior. Os
alunos chilenos responderam às perguntas por meio de um questionário eletrônico,
disponibilizado em uma página web cujo endereço foi divulgado previamente37. Esse
procedimento foi necessário devido a um atraso na finalização do semestre letivo,
que limitou o tempo disponível em aula para entrevistar os alunos pessoalmente.
37
Google Docs, atualmente denominado Google Drive (http://drive.google.com)
133
Capítulo 6
RESULTADOS E ANÁLISE
Neste capítulo serão apresentados e discutidos os dados coletados na
pesquisa de campo conduzida a partir do oferecimento da Oficina de Produção de
Jogos Digitais, no Instituto Federal de São Paulo (IFSP) e na Universidad de
Valparaíso (UV), durante o primeiro e segundo semestres de 2013. De acordo com a
proposta de triangulação de métodos, discutida na seção 0 e detalhada por meio dos
instrumentos de coleta de dados definidos no Capítulo 5, este capítulo se inicia com
a descrição dos dados identificados por meio de cada um dos instrumentos,
separadamente.
Dessa forma, o capítulo se inicia com a apresentação do perfil dos alunos
participantes da Oficina (seção 0), obtido por meio do questionário de identificação
de perfil, seguido da descrição detalhada da observação etnográfica das atividades
da Oficina em cada uma das instituições participantes (seção 0); essa descrição é o
ponto de partida para as análises conjuntas com os artefatos produzidos pelos
alunos. Na seção 0, os jogos produzidos durante a Oficina são analisados em três
diferentes aspectos: aquisição e utilização pelos alunos de conceitos de
programação; funcionalidades adicionadas pelos alunos e sua relação com a
jogabilidade dos jogos produzidos; e reutilização de estratégias para construção dos
jogos, com indícios do uso de habilidades de reconhecimento de padrões. Na seção
6.4, são apresentadas as impressões dos alunos sobre o desenvolvimento do
projeto final e da utilização da Matemática para a sua construção, obtidas por meio
da entrevista final; por fim, na seção 6.5, são apresentados os resultados do préteste e do pós-teste de conhecimentos matemáticos.
Feita a apresentação dos resultados obtidos a partir de cada instrumento, é
apresentada na seção 0 a discussão integrada dos achados da pesquisa de campo,
agrupados em quatro eixos temáticos: a mobilização de conteúdos da Matemática e
sua influência no desenvolvimento das atividades da Oficina (subseção 0); a
influência da construção de jogos digitais no desenvolvimento de competências do
Pensamento Computacional (seção 0), aspectos de design de interação e da
experiência anterior dos alunos enquanto jogadores no desenvolvimento de
134
funcionalidades adicionais nos jogos (subseção 0); por fim, a relação das
competências comuns entre o Pensamento Computacional e a Matemática com os
resultados identificados na pesquisa (subseção 0).
6.1 Perfil dos participantes
Conforme descrito na seção 0, a identificação do perfil dos participantes da
Oficina foi feita por meio de um questionário. As respostas ao questionário foram
obtidas no quarto encontro da Oficina; tal procedimento foi tomado para tentar
garantir maior representatividade dos resultados, já que em semestres anteriores já
havia sido constatada a evasão e posterior inclusão de novos alunos nas turmas do
curso técnico do IFSP, devido às consecutivas chamadas de candidatos do
processo seletivo para ingresso no curso. No caso da UV, onde a Oficina foi
oferecida como uma atividade extracurricular, esse mesmo procedimento foi
conveniente para obter o perfil dos alunos que estivessem efetivamente
frequentando as atividades. As respostas foram fornecidas pelos alunos por meio
digital, na plataforma de gerenciamento de questionários Surveymonkey38.
Trinta alunos do grupo brasileiro e vinte e seis alunos do grupo chileno
responderam ao questionário39. A maioria dos alunos brasileiros (76%) tem 15, 16
ou 17 anos de idade. Os demais são alunos mais velhos (min: 19 anos, max: 36
anos) que também podem se matricular em cursos técnicos dessa modalidade40. O
grupo chileno, formado por ingressantes no ensino superior, é um pouco mais velho:
em sua quase totalidade (93%) é formado por alunos com 18, 19 ou 20 anos de
idade. Apenas três alunos têm 21 anos ou mais (min: 21 anos, max: 26 anos). O
grupo brasileiro foi composto por mais alunas (nove, ou 30% do total), enquanto que
o grupo chileno era majoritariamente masculino (com apenas quatro alunas, ou 16%
do total).
38
A plataforma Surveymonkey (http://www.surveymonkey.com) permite a criação de
questionários com controle lógico da sequência de respostas, conforme o perfil do respondente, e a
análise e segmentação dos resultados em uma interface online. O acesso à plataforma foi
gentilmente adquirido pela Universidad de Valparaíso.
39
A amostra do questionário é representativa ao se considerar a frequência média dos alunos
à Oficina: 28,7 alunos por encontro no IFSP (min: 24; max: 31) e 20,3 alunos por encontro na UV
(min: 5; max: 26).
40
Essa modalidade de curso técnico é denominada concomitante (pois é aberta a alunos que
concluíram ao menos o primeiro ano do Ensino Médio) ou subsequente (pois também é aberta a
alunos que já concluíram o Ensino Médio).
135
Os participantes do grupo brasileiro têm uma relativa experiência com o uso
de jogos digitais: 77% dos alunos declararam ser jogadores regulares: 47% deles
afirmam passar de 1 a 5 horas por semana jogando e outros 20% afirmam ocupar de
5 a 15 horas por semana com essa atividade; 7% deles jogam por mais de 15 horas
por semana. Ainda, 66% deles jogam há três anos ou mais. Os alunos do grupo
chileno tem uma experiência ainda mais frequente com jogos: 25 dos 26
respondentes afirmam serem jogadores regulares. Desses alunos, 28% afirmam
passar de 1 a 5 horas por semana jogando; 36% passam de 5 a 15 horas jogando;
28% passam mais de 15 horas por semana com essa atividade. Nesse grupo, 91,7%
dos alunos afirma jogar há três anos ou mais. Esses dados são apresentados
graficamente na Figura 31.
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Brasil - IFSP
Chile - UV
Não jogo
Menos de uma hora semanal
De 1 a 5 horas
De 5 a 15 horas
Mais de 15 horas
Figura 31 – Frequência de uso de jogos digitais pelos participantes da Oficina
Identificou-se uma diferença entre os grupos relacionada aos gêneros de
jogos preferidos pelos alunos. No grupo brasileiro, os três gêneros preferidos pelos
alunos, em ordem decrescente de preferência, foram: ação e aventura (90% de
indicações 4 e 5 na escala Likert); Role-Playing Games (72% de indicações) e
simulação (72%). Já no grupo chileno o gênero preferido pelos alunos foi tiro em
primeira pessoa (88%), seguido por ação e aventura (84%) e Role-Playing Games
(80%). Vale ressaltar que, no grupo brasileiro, o gênero de tiro em primeira pessoa
foi apenas o nono gênero preferido dentre as dez opções oferecidas no questionário.
Os critérios de qualidade mais frequentemente citados pelos alunos como
sendo altamente influentes para sua experiência como jogadores (ou seja,
136
classificados com 4 ou 5 na escala Likert) são apresentados nas Figuras 32 e 33. Os
critérios mais influentes são relacionados à possibilidade de armazenar o estado do
jogo para retomar posteriormente (H7), à qualidade da história (H9), à variedade de
desafios e estratégias (H14), aos desafios promovidos pela Inteligência Artificial
(H18), ao conforto e tempo de resposta dos controles (H1) e à qualidade de gráficos
e som (H10). Apenas na resposta dos alunos brasileiros é indicada a importância do
jogo contar com recursos visuais compreensíveis (H6), e apenas na resposta dos
alunos chilenos aparece a heurística relativa à clareza da disposição dos itens e
menus do jogo (H8). Possivelmente essa diferença reflete as diferenças na
preferência pelos gêneros de jogos manifestada entre os grupos.
Brasil - IFSP
1 (Menos importante)
0%
20%
2
3
40%
4
60%
5 (Mais importante)
80%
100%
H7
H6
H9
H14
H18
H1
H10
Figura 32 – Critérios de jogabilidade mais relevantes para os alunos brasileiros
Chile - UV
1 (Menos importante)
0%
20%
2
40%
3
4
60%
5 (Mais importante)
80%
100%
H7
H8
H9
H18
H1
H14
H10
Figura 33 – Critérios de jogabilidade mais relevantes para os alunos chilenos
137
6.2 Observação etnográfica
Nesta seção serão descritas as observações das atividades de aula, obtidas a
partir dos registros dos professores responsáveis pelas turmas da Oficina nos diários
de bordo e complementadas pelas entrevistas semiestruturadas realizadas pelo
autor desta tese com os demais professores envolvidos. Seguindo a perspectiva de
Latorre, Rincón e Arnal (1996), discutida na seção 0, na qual o método etnográfico
se caracteriza por uma apresentação naturalista do contexto estudado, se
estabeleceu uma separação entre a descrição objetiva dos fenômenos observados,
que será apresentada nesta seção, e a análise desses fenômenos por meio da
triangulação, que será apresentada na seção 0.
De forma que o leitor possa identificar de forma mais rápida os sujeitos da
pesquisa que são referenciados ao longo da descrição, foi criada uma identificação
numérica sequencial, de P1 a P86, para cada sujeito. Ainda, para tornar a descrição
dos episódios mais natural, foi atribuído um nome fictício a cada sujeito referenciado
no texto, permitindo assim uma identificação mais rápida do gênero e assegurando
ainda o direito à privacidade dos pesquisados. Uma tabela com a identificação
numérica, escolaridade e nome fictício dos sujeitos que serão referenciados no texto
pode ser encontrada no Apêndice E.
6.2.1 Atividade 1: Encontro do gato com o rato
A primeira atividade da Oficina ocorreu no dia 25/02/2012 na turma A do IFSP
e no dia seguinte na turma B. Neste semestre, a disciplina de Lógica de
Programação do curso técnico estava alocada às segundas-feiras em uma turma e
às terças-feiras na outra turma. Por se tratar de uma atividade introdutória à própria
disciplina, nesse primeiro encontro os professores fizeram uma exposição dialogada
sobre o conceito de algoritmo e sobre como uma linguagem para expressar
algoritmos não pode ter ambiguidades para que possa atender aos seus objetivos.
O ambiente Scratch foi então apresentado aos alunos, bem como os
mecanismos para abrir e salvar projetos no ambiente. Os alunos então iniciaram a
modificação do programa a ser utilizado na aula, definindo o funcionamento do rato.
Uma das perguntas a serem respondidas durante a aula questionava sobre quantos
138
comandos eram executados quando a seta para direita era pressionada, evento
associado
ao
sprite
do
gato
(Figura
34).
Tal
pergunta
suscitou
vários
questionamentos dos alunos sobre se o condicional “se” e a definição do evento
“quando tecla pressionada” deveriam também ser considerados como comandos.
Muitos alunos descobriram rapidamente que era possível trocar o fundo da
tela, especialmente as meninas das duas turmas. Os meninos também
experimentaram trocar o fundo, embora em menor número. A proximidade entre os
alunos, devido à disposição dos computadores na sala (Figura 35) parecia estimular
os alunos a tentarem implementar alterações já realizadas com sucesso pelos
colegas próximos.
Figura 34 – Encontro do gato com o rato: código vinculado ao sprite do gato e
fornecido inicialmente aos alunos
Figura 35 – Ambiente do laboratório de informática utilizado no IFSP para a
realização da Oficina
139
A experimentação com o aspecto visual do jogo foi intensa nessa primeira
atividade, que pode ser exemplificada com o episódio a seguir. Guilherme (P15),
trabalhando junto com Jéssica (P16), tentou uma modificação mais ousada: trocou o
sprite do rato por um carro, e o fundo de tela por uma estrada. Nesse momento, os
alunos perguntaram ao professor se seria possível fazer o carro “andar” pela
estrada, e foram orientados que, pelo fato dos sprites serem bidimensionais, seria
preciso encontrar uma imagem da traseira do carro para dar a sensação de
movimento. Apenas alguns instantes depois, os alunos estavam utilizando o sítio de
uma ferramenta de buscas41, procurando por uma imagem adequada. Mais tarde,
constatando sua dificuldade inicial para importar imagens externas ao ambiente do
Scratch, os alunos optaram por modificar o cenário para um oceano e o sprite do
carro para um barco. Após essa nova tentativa, Jéssica (P16) volta a perguntar ao
professor como fazer o barco se movimentar “sozinho”, sem o pressionamento de
uma tecla.
No Chile, a primeira atividade aconteceu no dia 26/03/2013 para a turma 1 e
no dia 08/04/2013 para a turma 2. A divisão dos alunos em turmas em duas turmas
seguiu a divisão utilizada para a aula teórica de Fundamentos de Programação, na
qual os participantes estavam simultaneamente matriculados. Os encontros para a
turma 1 ocorreram usualmente às sextas-feiras, e os encontros para a turma 2, às
segundas-feiras. O encontro com a primeira turma teve uma frequência bem maior:
24 alunos, contra apenas 3 alunos no encontro com a turma 2. Segundo o professor
responsável, isso foi devido a uma suspensão de atividades para um evento da
universidade, que acabou por dispersar os alunos naquela semana.
A dúvida sobre o conceito de comando também foi identificada nessas
turmas. Entretanto, como os alunos chilenos assistem paralelamente a uma aula
teórica sobre os conceitos de programação, seu vocabulário parece ser mais formal,
como expresso na dúvida de um aluno42 da turma 1: “¿La condición si cuenta como
un comando?”. Da mesma forma que no IFSP, o interesse em modificar o desenho
do fundo da tela também pôde ser identificado em vários alunos da UV.
41
Google Imagens (http://images.google.com)
Os registros de aula referentes às atividades do Chile não indicaram o nome dos alunos
envolvidos em cada evento registrado; em algumas ocasiões, que aparecem ao longo da descrição, a
identificação pessoal dos alunos envolvidos foi possível. Nas demais, será feita a referência genérica,
como neste caso.
42
140
6.2.2 Atividade 2: Pescaria
A segunda atividade aconteceu no IFSP nos dias 04 e 05/03/2013 para as
turmas A e B, respectivamente. Na UV a atividade foi realizada nos dias 05/04/2013,
para a turma 1, e 08/04/2013 para a turma 2 – nesta turma, o professor optou por
propor as duas primeiras atividades no mesmo dia, pois os alunos presentes que
compareciam à Oficina pela primeira vez declararam já ter familiaridade com o
Scratch.
Nas turmas brasileiras, a atividade ocupou as aulas de duas semanas
consecutivas. Na primeira semana, os alunos se concentraram em construir um
segundo peixe, cuja frequência de mudança de posições na tela deveria aumentar
quando o jogo acumulasse 20 pontos. Essa funcionalidade envolveu o domínio da
estrutura condicional se...senão para a modificação da estrutura lógica construída
previamente e fornecida para os alunos no código do primeiro peixe. Na segunda
semana, o jogo foi modificado para incorporar uma condição de parada nas
estruturas de repetição (envolvendo assim uma quantidade máxima de “aparições”
de cada peixe) e o cálculo do percentual de peixes de cada tipo que foram clicados
pelo jogador.
Um episódio no início da atividade na turma A ilustra a dificuldade inicial dos
alunos com o conceito de intervalos na reta43. O professor apresentou no projetor o
trecho de código apresentado anteriormente na Figura 12, associado ao sprite do
primeiro peixe, que foi fornecido aos alunos para modificação.
O diálogo entre o professor e os alunos se focou no funcionamento da
geração de números aleatórios, presente na função “sorteie” e utilizado dentro do
comando “vá para”:
[Professor]
E aí, vocês acham que o peixe pode aparecer em qualquer
lugar?
[Aluna]
Sim.
[Aluno]
Ah, pode, mas... “peraí” (sic)... Só se for de menos 240 a 240,
e de menos 180 a 180 que ele pode aparecer.
43
Deve ser feita a ressalva que o ambiente Scratch, como a maioria das linguagens e
ambientes gráficos, utiliza coordenadas discretas para referencias posições na tela. Essa limitação se
relaciona à organização da memória de vídeo, composta por conjuntos de bytes, cada um deles
representando um pixel na tela.
141
[Professor]
Este comando que está em verde tem um nome meio
sugestivo, “sorteie”. “sorteie número entre -240 e 240” e “sorteie número
entre -180 e 180”. Alguém parou pra pensar o porquê desses números?
[Alunos]
É o espaço, o espaço da tela...
O posicionamento dos sprites é feito por meio das coordenadas cartesianas
“discretizadas” pelo ambiente do Scratch e, a julgar pela indicação genérica ao
“espaço da tela”, esse conceito não parecia estar muito formalizado pelos alunos. O
diálogo prossegue nesse sentido:
[Professor]
Se você passar o mouse por aqui [palco], o que está
aparecendo aqui [indicações das coordenadas x e y da posição do mouse]?
[Aluno]
É o tamanho.
[Professor]
Bem, tem até uma relação com o tamanho do objeto, mas na
verdade essas aqui são as coordenadas do ponto, x e y. Isso é importante
porque tudo que a gente for fazer em duas dimensões depende dessas
coordenadas.
A referência no diálogo transcrito acima foi feita em relação a um item da
interface do Scratch, exibido abaixo do palco, onde é possível identificar as
coordenadas x e y da posição atual do mouse (Figura 36). Uma indicação
semelhante, exibida na mesma figura, é feita acima da área de código e indica a
posição atual do sprite cujo código está sendo editado.
Figura 36 – Indicação das coordenadas cartesianas do ponteiro do mouse e do
sprite atual no sistema de coordenadas do palco do Scratch
Nesse primeiro momento, as dificuldades dos alunos se concentraram no uso
da estrutura condicional se...senão e na construção de uma condição booleana
envolvendo o valor de uma variável (tal como “pontos > 20”) para definir o aumento
na frequência de mudança de posições do peixe na tela. Fabrício (P14) manifestou
uma ideia para incrementar a dificuldade do jogo: “E se eu quiser fazer um outro
nível, tipo, aumenta a velocidade no 10, e depois aumenta a velocidade no 20?”,
referindo-se à quantidade de pontos que dispara a aumento na frequência de
mudanças de posição do peixe. A partir da manifestação dessa intenção, o aluno foi
orientado a explorar o uso de duas estruturas condicionais aninhadas (Figura 37), de
modo a obter o resultado desejado.
142
Figura 37 – Uso de estruturas condicionais aninhadas para criar dois níveis de
dificuldade no Jogo de Pescaria
Na segunda semana, os alunos se concentraram em implementar as
alterações para que o jogo tivesse um final, limitando a quantidade de aparições de
cada peixe e exibindo o percentual de peixes clicados com sucesso. Nesse
momento, o cálculo do percentual se constituiu como a maior dificuldade. Os
professores sugeriram para os alunos que fossem criadas duas novas variáveis,
“peixe1” e “peixe2”, que aumentassem de valor em uma unidade cada vez que um
peixe de cada tipo fosse clicado, aproveitando o código para tratamento do evento
de clique que já havia sido implementado anteriormente. Um exemplo de solução
“mínima” (no sentido da concisão do código) para o funcionamento completo de um
dos peixes é apresentado na Figura 38.
Figura 38 – Solução para o funcionamento de um dos peixes no jogo de Pescaria,
incluindo o cálculo de porcentagem
143
Uma dúvida que foi expressa pela maioria dos alunos foi o porquê de não
estar correto calcular o percentual de peixes clicados utilizando uma expressão
como “peixe1 / pontos”. Aparentemente, ainda não estava claro para esses alunos
qual proporcionalidade estava sendo calculada e a necessidade de saber o total de
vezes que um peixe apareceu para que o cálculo estivesse correto. Mesmo após o
cálculo, Guilherme (P19) usa o próprio jogo construído por ele para expressar sua
dúvida sobre a correção do cálculo efetuado:
[Guilherme] Olha só, vê se está certo, aí eu clico... [executando o jogo e
clicando nos peixes]
[Professor] Deu 0.28? E os peixes estão aparecendo 25 vezes cada? Então
a gente pode testar na calculadora [Guilherme inicia o aplicativo de
calculadora]. O peixe 1 está aparecendo sete [vezes]... Dividido por 25... Dá
0.28, vezes 100... Dá 28, 28 por cento de acertos. Então está certo,
entendeu?
A ideia de criar uma condição de parada para o laço estava muito associada à
mecânica do jogo para Caio (P21), que à essa altura estava trabalhando junto com
Guilherme (P19) na construção do jogo. O aluno usava uma condição de baseada
em uma pontuação máxima, o que ia ao encontro da proposta pedida, que
especificava que cada peixe deveria aparecer uma quantidade determinada de
vezes, o que não seria possível com o código construído.
[Caio]
E como a gente faz para acabar o jogo?
[Professor]
Depois que ele [o peixe] aparecer 20 vezes, o jogo acaba. Aí
você pode usar um [bloco] “repita 20”, que ele vai aparecer 20 vezes, e no
final você consegue fazer a conta, porque você sabe que os peixes
apareceram 20 vezes (...)
[Caio]
E aí, acabou o jogo...
[Guilherme] Mas [o peixe] tem que ficar mais rápido com menos pontos,
não tem que ser 20, tenta diminuir pra 10!
Ao analisar a estrutura do laço, Guilherme parece identificar um problema que
não se refere à lógica, mas à própria mecânica do jogo, que pode ficar mais difícil ou
interessante se a frequência de movimentação do peixe aumentar mais cedo
durante a partida.
Na Turma 1 do Chile, um problema muito comum foi que vários alunos
tentaram associar à diminuição do tempo de exibição do peixe ao evento de clique, e
não ao laço que era executado ao se clicar na “bandeira verde”, que inicia a
execução do programa (vide Figura 12). Surgiram algumas dúvidas sobre o intervalo
144
de valores numéricos utilizados para o sorteio da posição do peixe, mas que foram
resolvidas pelos próprios colegas. Em ambas as turmas, o cálculo da porcentagem
foi alvo de várias dúvidas, o que exigiu a intervenção do professor para explicar
como os valores armazenados nas variáveis se relacionavam para o cálculo. Na
turma 1, isso exigiu a finalização da atividade na aula seguinte.
Por fim, vale ressaltar um problema semiótico, relacionado à tradução do
ambiente Scratch, que foi constatado nas turmas do Brasil e do Chile durante esta
atividade. O Scratch disponibiliza dois comandos diferentes para alterar valores de
uma variável; um deles funciona como a atribuição de valor convencional, presente
nas linguagens de programação estruturadas, e o outro realiza um incremento na
variável de acordo com o valor passado como argumento do comando. O comando
de atribuição foi traduzido como “mude <variável> para”, enquanto que o comando
de incremento foi traduzido como “mude <variável> por”. Na versão em espanhol do
Scratch, as traduções são, respectivamente “fijar <variable> a” e “cambiar <variable>
por”. Aparentemente, nas traduções para ambos os idiomas foi feita uma
interpretação muito literal do inglês “set <variable> to” e “change <variable> by”,
perdendo assim o sentido presente no idioma original. Na turma A do IFSP foram
registrados dois relatos de alunos que utilizaram o comando de atribuição, pensando
estar usando o comando de incremento. Na turma 1 da UV, houve registro da dúvida
de alguns alunos que, inversamente, utilizaram o comando de incremento, pensando
estar utilizando a atribuição.
6.2.3 Atividade 3: Jogo de adivinhação
A terceira atividade aconteceu no IFSP nos dias 18 e 19/02/2013 para as
turmas A e B, respectivamente. Na UV, a atividade aconteceu no dia 15/04/2013,
para a turma 2, e no dia 19/04/2013, para a turma 1.
Uma das demandas iniciais da construção do Jogo de Advinhação era que o
aluno compreendesse que um número aleatório (gerado utilizando-se a função
“sorteie”, que já era necessária na atividade anterior) deveria ser armazenado em
uma variável, que por sua vez seria comparada com o valor inserido pelo jogador via
teclado. A atribuição de um valor inicial a uma variável, sendo esse valor inicial o
145
resultado de uma função (Figura 39), foi alvo de muitas perguntas dos alunos nos
momentos iniciais.
Figura 39 – Atribuição de valor a variável resultante da saída da função “sorteie”
Essa dúvida pode ser ilustrada na pergunta de Guilherme (P19), que
apresentava dificuldades para iniciar a atividade e procurou o professor:
[Guilherme] Como é que eu vou fazer pra ele [personagem do jogo]
“pensar um número”?
[Professor]
Bom, “pensar” é só o modo da gente dizer, né, na verdade
você vai fazer ele sortear o número, e guardar em uma variável. Você usa o
“mude” da variável pra ele guardar o que foi sorteado, e para isso você usa
o comando “sorteie” que a gente já tinha usado.
Uma curiosa confusão semiótica foi identificada por um aluno no Brasil e dois
alunos no Chile: a descrição da atividade, distribuída aos professores responsáveis
pela Oficina (0), mencionava que o personagem do jogo deveria “pensar” em um
número aleatório. Muito provavelmente este termo foi usado pelos professores ao
descrever a atividade deste dia, o que levou os alunos mencionados a tentar utilizar
o bloco “pense”, disponível dentre os comandos do Scratch. No entanto, tal bloco é
apenas uma forma de um sprite exibir uma mensagem dentro de um “balão de
pensamento”, similar àqueles que aparecem em histórias em quadrinhos.
No projeto da Oficina, era esperado que a realização desta atividade fosse
uma oportunidade para os alunos lidarem pela primeira vez de forma autônoma com
a construção de uma estrutura de repetição incluindo uma condição de parada. Essa
condição, quando a atividade estivesse completa, seria composta por dois eventos:
o acerto do valor sorteado pelo programa ou o esgotamento do número de tentativas
definidas. De forma bastante esperada, as dificuldades subsequentes dos alunos se
concentraram na definição da condição booleana para parada da repetição e na
própria ordenação dos comandos para executar a repetição. Uma dúvida expressa
por Isabel (P20) ilustra um problema muito frequente. A aluna montou seu código
colocando o comando de entrada de dados “acima” da estrutura de repetição,
impedindo que a pergunta fosse feita mais de uma vez (Figura 40).
146
Figura 40 – Ilustração do erro de Isabel (P20): comando colocado incorretamente
fora do laço
A própria identificação da necessidade de uma estrutura de repetição aparece
em outro episódio. Camila (P8) e Diana (P10) optaram por trabalhar juntas na
maioria das atividades. Uma intensa discussão e exploração era frequente entre as
alunas sobre as estratégias e resultados dos programas desenvolvidos. Nesta
ocasião, as alunas haviam construído a lógica de comparações entre a variável
sorteada e o valor inserido pelo jogador de forma correta; no entanto, parecia
incômodo para Camila ter que “clicar na bandeira verde” para que fosse possível
tentar novamente:
[Camila]
Então, ele vai falar que é 50 [referindo-se ao número
sorteado], só que no outro instante [clica na bandeira novamente] ele já vai
dizer que é outro número!
[Professor]
O problema é que o programa de vocês não está fazendo
uma repetição mesmo. Você está repetindo “na marra”, clicando na
bandeira. Você precisa de uma estrutura que “agarre” todo o código e faça
com que o programa pergunte várias vezes.
[Diana]
Mas e o que a gente fez até agora, está certo?
[Professor]
Está, só falta fazer a repetição
As alunas seguem as orientações passadas. Cerca de 10 minutos depois,
elas voltam a chamar o professor, dessa vez para contar, animadas, que o programa
funcionou a contento após a intervenção. Nesse diálogo, Camila indica (com algum
exagero) a relevância da intervenção feita para a resolução do problema com
sucesso:
[Camila]
Tá certo, agora a gente conseguiu!
[Professor]
Então vocês usaram um “repita até que número = resposta”...
[fazendo um teste no programa] Então quando ele perguntar o número e for
igual a resposta... Ele indica que acertou! Certinho!
[Camila]
Legal! Se a gente estivesse sozinha, a gente ia parar aqui,
ó... No “sorteie”!
Na Turma A, os alunos foram orientados coletivamente pelo professor a exibir
o valor atribuído para cada variável na tela, de forma a facilitar o monitoramento da
lógica do algoritmo em construção. A incompatibilidade entre a necessidade de
visualização das variáveis e as regras de um jogo de adivinhação foi alvo de uma
147
reflexão de Lucas (P4), quando estava sendo orientado a definir a atribuição de uma
variável para o sorteio:
[Professor]
Aí quando você define “mude variável para...”, o valor do
“sorteie” fica nela, e aparece aqui [indicando a visualização da variável no
topo do palco]
[Lucas]
Mas aí o valor fica aparecendo, eu vou saber a resposta, né?
[Professor]
Não tem problema, quando você for colocar para funcionar
“de verdade”, é só clicar aqui [apontando a caixa] e desaparece o valor.
No Chile, a atividade da turma 1 (19/04) foi marcada por uma menor
frequência de alunos do que na turma 2 (15/04). No entanto, os alunos
apresentaram
poucas
dificuldades
em
estruturar
a
lógica
sequencial
de
comparações entre os valores para verificar se o jogador acertou o número. As
maiores dificuldades relatadas se concentraram na definição da estrutura de
repetição, em episódios similares ao relatado anteriormente com as alunas
brasileiras. Andrés (P33) opta por uma estratégia diferente: ele informa ao professor
que deseja que a dica do seu jogo não seja simplesmente se o número é maior ou
menor que a tentativa informada, mas que informe um intervalo restrito de valores no
qual esteja o número sorteado. Em cerca de 30 minutos o aluno discute com o
professor uma solução aproximada para o problema, exibida na Figura 41. No
entanto, o aluno identifica uma limitação: quando o número sorteado é próximo de 0,
o limite inferior do intervalo informado pelo jogo acaba sendo negativo. O professor
sugeriu, então, que o aluno utilizasse um repetição com condição que identifique
essa situação e sorteie novamente o número para definir o intervalo inferior44. Tal
implementação não foi feita no jogo final entregue pelo aluno. Vale ressaltar que o
aluno também não utilizou estruturas de repetição em seu código.
44
Fica a ressalva que também há uma solução alternativa mais simples, envolvendo
adicionar uma estrutura condicional que defina o valor da variável a2 para 0, caso o valor definido
seja negativo.
148
Figura 41 – Funcionalidade adicional feita por Andrés (P18) no Jogo de
Advinhação: dica informada por meio de um intervalo numérico
Na atividade da Turma 2, em 14/04, compareceram cerca de 20 pessoas,
mas cerca de metade delas estava comparecendo às atividades de monitoria pela
primeira vez. Dessa forma, o professor teve que apresentar uma rápida introdução
ao funcionamento do Scratch, exibindo o jogo de Pescaria que havia sido feito no
encontro anterior. Ao iniciarem a atividade, dois alunos pertencentes a esse grupo
que estava comparecendo pela primeira vez exploraram a importação de objetos e
as ferramentas visuais para desenho de sprites presentes no Scratch. Um desses
alunos questionou o professor se seria possível exibir um sol no fundo de tela, que
seria o objeto a informar se o jogador ganhou ou perdeu. O professor fez uma breve
explicação sobre a diferença de funcionamento entre um sprite e o fundo de tela, e
informou que seria possível implementar a funcionalidade desejada com qualquer
uma das estruturas45.
Outro aluno que comparecia pela primeira vez procurou o professor pois não
tinha ideia do que fazer. Após uma explicação sobre o uso do comando “perguntar”
e da localização das estruturas condicionais, em 15 minutos o aluno conseguiu
montar as estruturas de entrada de dados e condicionais para o funcionamento
básico do jogo, ficando assim bastante motivado para finalizá-lo. Por outro lado,
Jorge (P59), um aluno que havia comparecido a todos os encontros anteriores da
Oficina, terminou a atividade muito antes do horário e se dispôs a ajudar os colegas
com dificuldades. Alguns poucos alunos não conseguiram incorporar a estrutura de
45
Uma possível solução exigiria o uso da sincronização entre objetos (sprite ou fundo de tela)
utilizando mensagens, mas esse recurso só seria utilizado pela primeira vez na atividade seguinte
(Pedra, Papel e Tesoura).
149
repetição ao jogo; para esses alunos, o professor deixou como tarefa para o próximo
encontro a finalização do jogo.
Na execução desta atividade no Brasil, um tempo razoável pôde ser dedicado
para que os alunos elaborassem a resposta a uma das perguntas da aula: “Uma
forma simples (mas não muito esperta) de chegar ao número correto seria ir
tentando os números de 1 a 100, um por um. Você consegue imaginar uma
estratégia para tentar ganhar o jogo mais rapidamente? Qual é o número máximo de
tentativas necessárias para acertar o número na sua estratégia?”. Ao observar a
análise que os alunos fizeram do problema, foi possível constatar várias soluções
com algum grau de sofisticação, e se aproximando de um algoritmo de divisão e
conquista semelhante à busca binária. Foi o caso de Jéssica (P16), que contou para
o professor qual seria sua estratégia:
[Jéssica]
Professor, eu pensei assim: se são 100 tentativas, eu vou
tentar o 50. Se disser que é menor que 50, eu vou tentar no 25. Aí vai ficar
entre 1 e 25, ou entre 25 e 50. Se for menor aí eu penso no 14, que é
praticamente a metade de 25, 14 e meio, como não tem vírgula, é 14. Aí
pode ser maior que 14, ou menor que 14.
[Professor]
E se for menor que 14, o que você faz?
[Jéssica]
Aí eu vou pensar no 7.
[Professor]
Ah, você deu o exemplo, né, e agora como você explicaria
essa estratégia?
[Jéssica]
Primeiro eu penso na metade do 100, que vai ser o 50, depois
na metade do 50, que vai ser o 25...
[Professor]
Então você pensa sempre na metade do intervalo que você
está considerando, né? É razoável, porque você sempre elimina metade
dos números que estão sobrando no intervalo.
O engajamento dos alunos nessa atividade pareceu evidente, e mesmo
alunos com alguma dificuldade recorreram ao professor para construir e aprimorar o
conceito da sua estratégia. Foi o caso de Breno (P7), que iniciou a conversa com o
professor jogando seu próprio jogo e escolhendo como primeira tentativa o número
90. O jogo informou que o número sorteado era maior, e por isso Breno inicialmente
achou que sua estratégia era válida:
[Professor]
Mas você deu sorte, não acha? Tenta de novo e joga o 90
para a gente ver o que acontece [Breno joga novamente].
[Breno]
Menor... [informando a mensagem dada pelo jogo]
Como sua estratégia pareceu ser invalidada pela nova tentativa, o diálogo
passa a envolver a definição de uma nova estratégia:
150
[Professor]
Mas se eu não sei qual é o número, qual o melhor chute que
eu posso dar no começo?
[Breno]
O 50.
[Professor]
Por quê?
[Breno]
Por que ele ia me falar se era maior que o 50 ou menor que o
50. Bom, já eliminei 50 tentativas... Agora eu tenho mais nove tentativas
para acertar [na lógica do programa, Breno configurou inicialmente 10
tentativas para acertar o número]. Posso tentar o 60 ou o 90.
[Professor]
Por que o 60 ou 90? Não poderia ser o 50 ou 70?
[Breno]
É... Ah, mas pode ser o 75.
[Professor]
É uma escolha melhor?
[Breno]
Bem... É a metade de novo!
Breno começou a escrever seu algoritmo depois dessa conversa e, com
alguns testes e jogadas no computador, perguntou alguns momentos depois ao
professor: “O máximo é 7, não é? Dá para fazer com menos?”. O número de passos
de uma busca binária, no pior caso, é proporcional a log2N, onde N é o número de
elementos do vetor. No caso, log2100 é aproximadamente 6,64.
6.2.4 Atividade 4: Pedra, Papel e Tesoura
O jogo Pedra, Papel e Tesoura foi construído pelos alunos do IFSP nos dias
25/03/2013, na turma A, e no dia 26/03/2013, na turma B. Como a atividade previa a
construção de duas versões diferentes do jogo (uma com os dois jogadores
humanos e outra com um dos jogadores sendo controlado aleatoriamente pelo
computador), a segunda versão do jogo foi desenvolvida pelos alunos na semana
seguinte. Na UV, a atividade foi realizada nos dias 22/04/2013 (turma 2) e
26/04/2013 (turma 1).
Conforme o projeto da Oficina (vide seção 0) era esperado que os alunos
tivessem que mobilizar o raciocínio combinatório para construir a verificação de
vitória e derrota no jogo e, dessa forma, uma das perguntas a ser respondida
durante a aula envolvia a enumeração de todas as possíveis configurações de jogo
e os resultados correspondentes a cada uma delas. A proposta inicial era que,
respondendo às perguntas, os alunos estivessem mais preparados para construir o
jogo. No entanto, desde o início, as atividades da Oficina assumiram uma
organização razoavelmente “livre”, na qual a única obrigatoriedade era cumprir o
objetivo final proposto pelo professor. Os alunos poderiam se organizar da forma
que achassem mais adequada e gerenciar seu tempo para cumprir as metas
151
propostas46; nesta atividade, isso se refletiu no fato que boa parte dos alunos
optaram por iniciar o trabalho diretamente no código, e deixar a resposta para as
perguntas da aula em segundo plano. Observou-se que 15 dos 22 alunos presentes
na turma A seguiu essa estratégia; na turma B, 8 dos 12 alunos presentes atuaram
da mesma forma.
Dentre os alunos que iniciaram a atividade respondendo à pergunta, ou seja,
enumerando todas as possibilidades de jogo, verificou-se a ocorrência de muitas
dúvidas. Alguns alunos questionaram como deveria ser organizada a resposta, um
deles perguntando se deveria ser uma “tabelinha”. A fala de Isabel (P20) revela uma
expectativa de aplicar outro conteúdo matemático:
[Isabel]
Professor, como é aquela fórmula mesmo?... A das
probabilidades?...
[Professor]
Bem, aqui você não vai usar o cálculo de probabilidades, é
mesmo o princípio fundamental da contagem. Quantas possibilidades o
primeiro jogador tem? Três, não é? Então, para cada uma dessas três
possibilidades, o outro jogador pode fazer o quê?
[Isabel]
Colocar pedra, papel ou tesoura
[Professor]
Isso, então para cada uma das três possibilidade de um
jogador, o outro tem três. São três vezes três. Nove possibilidades.
A resposta de Isabel, apresentada na Figura 42, denota a dificuldade em
enumerar e apresentar as possibilidades de jogo de forma sistematizada, mesmo
após a orientação do professor. No entanto, essa não foi a tônica da atividade; como
muitos alunos deixaram para responder a atividade escrita após construir o jogo, foi
possível constatar que muitos discutiram e compartilharam “melhores” estratégias
entre si para enumerar as possibilidades. Na turma A, de 22 alunos presentes, 17
(77,2%) entregaram respostas nas quais estava presente um processo de
sistematização das possibilidades do jogo. Na turma B, isso aconteceu em 9 (75%)
das 12 respostas entregues. Na Figura 43 é apresentada a resposta de Pedro (P31),
exemplificando o uso de uma estrutura tabular para sistematizar a enumeração das
possibilidades.
46
Essa diretriz se relaciona com a proposta construcionista e baseada na Aprendizagem
Baseada em Problemas – vide a seção 0 e a subseção 0.
152
Figura 42 – Enumeração não-sistemática das possibilidades do jogo Pedra, Papel
e Tesoura feita por Isabel (P20)
Figura 43 – Enumeração sistemática das possibilidades do jogo Pedra, Papel e
Tesoura feita por Pedro (P31)
Nos primeiros momentos da atividade nas turmas do Brasil, foi mostrada para
os alunos no projetor uma versão finalizada do jogo, elaborada pelo autor desta
tese. Nele, a mensagem de vitória, derrota ou empata aparecia no fundo da tela
(Figura 44). Esse procedimento aconteceu na maioria dos encontros, e foi feita por
ambos os professores responsáveis. Essa versão do jogo era um teste do autor, e
sua apresentação para os alunos foi acidental, já que a implementação da
153
mensagem no fundo da tela não era um objetivo principal da atividade. Devido ao
tempo restrito, no planejamento da Oficina já era considerado suficiente que os
alunos implementassem a mensagem de vitória ou derrota utilizando o comando
“diga”, vinculado a um dos sprites (Figura 45).
Figura 44 – Versão do jogo Pedra, Papel e Tesoura com mensagem no fundo da
tela, e implementação mínima requerida para essa funcionalidade
Ao ver a versão inicialmente apresentada, vários alunos questionavam como
fazer uma mensagem similar aparecer em seu jogo. Um aluno, inclusive, já iniciou a
construção do aspecto visual do jogo exatamente pela criação de um sprite cujos
trajes imitavam a mensagem exibida na tela. Nesse momento, houve uma diferença
de postura entre os professores responsáveis pelas turmas no IFSP. Enquanto que
o autor desta tese enfatizou junto à sua turma que o importante nesse momento era
indicar corretamente qual dos jogadores que ganhou, independentemente do
formato da saída, o professor da outra turma estimulou os alunos a inicialmente
resolver o problema considerando que a mensagem estaria no fundo da tela47.
Boa parte dos alunos da turma A, orientados a primeiramente indicar qual
jogador ganhou sem se preocuparem com o formato, utilizaram o disparo de evento
“quando tecla pressionada” para criar essa funcionalidade. Cada sprite do jogo
reconhece o pressionamento de três teclas, correspondendo à jogada de “pedra”,
“papel” ou “tesoura”. Adicionalmente, o código associado ao pressionamento das
teclas em um dos sprites verifica qual a combinação de resultados vigente e informa
o resultado do jogo. Um exemplo desse código é mostrado na Figura 45. O
pressionamento da tecla “O” está associado à jogada de “pedra” no segundo
4747
Essa diferença teve impacto no surgimento dessa funcionalidade adicional em vários
jogos, como será apresentado na subseção 0.
154
jogador, e o código identifica as possibilidades de jogada para informar o resultado
do jogo.
Figura 45 – Código parcial para identificação do resultado final do jogo Pedra,
Papel e Tesoura
No entanto, essa estratégia gerou muitas dúvidas nos alunos da turma, que
estiveram concentradas em dois aspectos. O primeiro deles foi a ausência da
definição de alguma das configurações finais do jogo nas condições. Foi muito
frequente encontrar o caso de alunos que, ao testar o jogo, verificavam que alguma
das possíveis jogadas não resultava em nenhuma mensagem, ou seja, não foram
definidas exatamente as três condições necessárias em cada pressionamento de
tecla. O segundo aspecto é a necessidade, imposta pelo Scratch, de verificar o traje
de um outro sprite utilizando-se unicamente o sensor “traje #”, que exige que o aluno
saiba o número sequencial do traje no outro sprite. Em contraste, a referência a um
traje do próprio sprite é feita por um nome descritivo, como no comando “mude para
o traje”, apresentado na Figura 45.
Na turma B, após a orientação do professor, muitos alunos estruturaram a
construção do seu jogo em função da exibição da mensagem de vitória ou derrota
no fundo da tela. Para tanto, o código de verificação da situação do jogo foi
vinculado ao palco pela maioria dos alunos. Um exemplo dessa estratégia pode ser
observado no trecho de código da Figura 46, produzido por Paulo (P30). Em sua
estratégia, Paulo construiu uma estrutura de seleção para cada possível
configuração final do jogo, representada pelos números dos trajes dos sprites de
155
Figura 46 – Trecho de código para verificação da vitória no jogo Pedra, Papel ou
Tesoura utilizando “espera ocupada”
cada jogador. As estruturas de seleção estão aninhadas em um laço de repetição
“sempre”, executado continuamente. O resultado final é a alteração do fundo de tela,
que apresenta a mensagem referente à vitória de um dos jogadores ou ao empate.
Assim, Paulo e vários de seus colegas acabaram por descobrir uma estratégia
rudimentar de sincronização de processos, chamada de “espera ocupada” na área
de sistemas operacionais (TANENBAUM; WOODHULL, 2008).
A sincronização entre eventos no jogo também foi vista por alunos, em ambas
as turmas, como um problema a afetar a própria experiência do jogo. A fala de
Lucas (P4), na atividade da turma A, exemplifica essa preocupação:
[Lucas]
Professor, aqui vai ter um problema de jogabilidade, porque
olha só: [testando o jogo] o primeiro jogador pode fazer a jogada, e o
segundo esperar um pouquinho para ver o que o primeiro coloca... Dá para
“roubar”! Não tem como resolver isso?
Lucas identificou um problema cuja solução dependeria do uso de comandos
de sincronização do Scratch, que seriam explorados na atividade seguinte, o jogo
Pedra, Papel e Tesoura com um jogador automático. Nesta mesma atividade,
Fabrício (P14), um aluno mais velho que frequentemente explorava possibilidades
adicionais fornecidas pelo ambiente, mostrou ao professor uma solução para o
problema apontado por Lucas, usando o comando “espere” (Figura 47). Com a
solução proposta por Fabrício, o traje do sprite do primeiro jogador só se altera
quando o segundo fizer sua jogada, permitindo que a jogada aconteça de forma
assíncrona.
156
Figura 47 – Solução proposta por Fabrício (P14) para o problema de sincronização
de jogadas no jogo Pedra, Papel e Tesoura
Na semana seguinte, o trabalho dos alunos do IFSP continuou com o
desenvolvimento da versão do jogo na qual o jogador joga contra o computador.
Esse momento da Oficina foi intencionalmente planejado para que os alunos
explorassem o conceito de sincronização via mensagens, disponibilizado pelo
Scratch. Após uma breve explicação dos professores sobre o conceito, os alunos
iniciaram o trabalho. Como as atividades (jogo manual e automático) iriam ser
avaliadas de forma independente, os alunos foram orientados a salvar o arquivo
finalizado do jogo manual e trabalhar em cima de uma cópia desse arquivo para
produzir o jogo automático.
Essa alteração de um jogo pré-existente causou uma dúvida em Isabel (P20).
Na versão para dois jogadores, ela havia feito com que o sprite do primeiro jogador
incorporasse o código para verificação da vitória (vide Figura 45). Como toda a
discussão inicial com os alunos foi feita na suposição do segundo jogador ser
controlado pelo computador, surgiu o questionamento:
[Isabel]
Eu vou ter que mexer aqui [sprite do Jogador 1] ou aqui
[sprite do Jogador 2]?
[Professor]
Bem, no seu caso, quando o jogador 1 aperta a tecla, ele faz
todas as verificações. Só que agora, o fluxo é diferente: o jogador “manual”
aperta a tecla, dispara uma mensagem para o jogador automático, que
sorteia e joga, e aí dá para fazer a verificação.
[Isabel]
Eu já pensei em colocar alguns desses comandos pro outro
lado, tipo “quando eu ouvir...” e aí começa... Mas acho que vai dar tudo
errado...
[Professor]
Não, é isso mesmo, quando o jogador automático receber a
mensagem, ele executa um sorteio. De acordo com o que acontecer no
sorteio, ele muda o traje, e depois verifica quem ganhou.
[Isabel]
Ah, entendi!
A alteração necessária no jogo de Isabel envolveria a migração de uma
funcionalidade – a verificação de vitória – para um outro sprite, gerando um
resultado final equivalente, mas adequado à sincronização de eventos necessária
para o jogo automático.
157
A sincronização de eventos também poderia afetar a visualização do
resultado final do jogo; isso foi relatado por Caio (P21), que achou que a “mão
automática estava entrando na tela muito depois da mão do jogador, parece que
eles não estão jogando ao mesmo tempo”; isso era resultado da ordem de
construção dos comandos, onde a animação da “mão do jogador” era executada
antes do envio da mensagem para o sprite do jogador automático. Apesar de essa
sequência ser coerente do ponto de vista intuitivo, ela gerava um atraso na resposta
do sprite do jogador automático. Após a alteração, Caio ficou satisfeito com o
resultado.
No Chile, devido a um conflito de calendário, foi possível trabalhar no jogo
apenas durante uma semana, e dessa forma a maioria dos alunos construiu apenas
a versão do jogo para dois jogadores humanos. Inicialmente, muitos dos presentes
demonstraram não saber como começar, no que lhes foi recomendado responder
primeiro à questão por escrito, referente à enumeração das possibilidades de jogo.
Essa estratégia do professor permitiu revelar a dificuldade dos alunos em raciocinar
em função das possibilidades do jogo: de 11 respostas entregues, 6 (54%)
apresentaram omissão de alguma possibilidade de jogo, embora estivesse presente
uma tentativa de sistematização do resultado; 3 respostas incorretas não
apresentaram nenhuma sistematização dos resultados, e apenas 2 respostas
apresentaram todas as possibilidades, enumeradas de forma sistemática. Na Figura
é apresentado um exemplo de uma sistematização incorreta das possibilidades,
elaborada por Bruno (P38). Todos os alunos do Chile responderam às questões
utilizando o processador de texto.
Figura 48 – Erro na enumeração sistemática das possibilidades do jogo Pedra,
Papel e Tesoura feita por Bruno (P38)
Foi possível observar que o ajuste dos aspectos visuais do jogo concentrou a
atenção dos alunos na primeira metade do encontro; a possibilidade de exibir a
mensagem de vitória ou derrota no fundo foi alvo do interesse de um aluno nesse
158
período, que expressou ao professor sua preocupação em não saber como poderia
construir o jogo daquela forma.
Apesar do pouco tempo disponível e da maior ocorrência de programas
incompletos, foi possível constatar que os alunos que conseguiram finalizar a
atividade demonstraram maior desenvoltura com o uso de mensagens mais
rapidamente do que os alunos do IFSP. Destaca-se aí o episódio da conversa de
dois alunos que procuraram se ajudar, discutindo a questão da sincronização entre
as jogadas de ambos os jogadores (semelhante àquela que havia sido apontada por
Lucas (P4) na turma A do IFSP): um dos alunos se queixava que o seu jogo
verificava a situação do jogo a todo e qualquer momento (o aluno havia uitlizado a
estratégia da “espera ocupada”, mencionada anteriormente), enquanto que seu
colega apontava que o jogo poderia ser “mais realista, escondendo as jogadas até
que ambos os jogadores escolham”48. O professor sugeriu aí o uso de mensagens
como um caminho para solucionar o problema.
6.2.5 Atividade 5: Simulação de Guerra
A quinta atividade envolveu a construção do jogo Simulação de Guerra; essa
atividade aconteceu no IFSP nos dias 01 e 02/04/2013, nas aulas das turmas A e B.
Na turma A, foi necessário continuar a atividade no dia 08/04, pois parte do encontro
do dia 01 já havia sido utilizado para finalizar o jogo Pedra, Papel e Tesoura. Na UV,
esta foi a última atividade realizada antes da paralisação estudantil que afetou todas
as universidades do país. Por isso, para esta atividade, houve apenas o encontro
com a turma 1 na sexta-feira, 10/05/2013. Houve a participação de apenas cinco
alunos e, devido aos contratempos gerados pela paralisação, o professor
responsável não pôde gerar nenhum registro sobre essa atividade. Sua análise será
feita com base nos jogos construídos pelos alunos, e na sequência desta subseção
serão descritas as observações feitas no IFSP.
Nesta atividade, a movimentação dos sprites assume uma função primordial,
pois se trata da construção do protótipo de um jogo de ação, ao contrário das duas
atividades anteriores (Jogo da Advinhação e Pedra, Papel e Tesoura), nas quais
48
Fala original: “[...] haga el juego aun mas realista, podrias esconder las jugadas hasta que
ambos jugadores elijan”.
159
foram construídos jogos de raciocínio lógico. Dessa forma, era esperado que os
alunos voltassem a mobilizar o conceito de sincronização entre sprites, utilizado na
atividade anterior. Por outro lado, passou a ser necessário o controle da posição e
orientação dos sprites do tanque, do tanque inimigo e da bala.
O conceito de orientação de um sprite é gerenciado pelo Scratch por um
atributo “direção”, que é um valor numérico inteiro entre -180 e 180 graus, sendo a
direção de 0 graus apontando para cima com valores crescentes no sentido horário.
A rotação do tanque controlado pelo jogador (e, consequentemente, da bala que ele
dispara) foram alvo de várias dúvidas dos alunos, principalmente relacionadas ao
significado dos comandos do Scratch. Foi o caso de Rafael (P29), que relatou:
[Rafael]
[Professor]
[Rafael]
Eu não tô conseguindo fazer a bala apontar para o tanque
Você precisa usar o comando “aponte para”...
Mas eu usei...
Aí aparece uma confusão de significado entre dois comandos muito similares
fornecidos pelo Scratch: “aponte para” é um comando que recebe como argumento
o nome de outro sprite, e modifica a orientação do sprite de modo que ela fique
apontando na direção do sprite passado como argumento. Já o comando “aponte na
direção” recebe como argumento um valor numérico inteiro, como descrito no
parágrafo anterior, e modifica a direção do sprite para aquele valor numérico. Rafael
havia utilizado, de forma incorreta, o primeiro comando ao invés do segundo. A
dificuldade do aluno foi a necessidade de utilizar como argumento do comando
“aponte na direção” o resultado da função “direção de”, que informa o valor numérico
da orientação do tanque (Figura 49). Dessa forma, a orientação da bala passa a ficar
coerente com a orientação do tanque.
Figura 49 – Uso do comando “aponte para” para mudar a orientação da bala no
jogo Simulação de Guerra
160
Uma vez que os sprites da bala e do tanque inimigo estivessem na orientação
correta, o próximo problema seria fazer com que eles se deslocassem pela tela – a
bala, quando disparada pelo jogador, e o tanque inimigo, automaticamente em
direção ao tanque do jogador – e que fosse identificada a colisão do tanque inimigo
com a bala, o que resultaria na explosão do tanque, que poderia ser indicada no
jogo pela modificação do traje do tanque inimigo, simulando o efeito de uma
explosão.
Porém, a estratégia utilizada inicialmente pela maioria dos alunos, apesar de
simples e rápida, não permitia identificar a colisão. Essa estratégia envolvia o
comando “deslize em <T> segundos para <X, Y>”. Esse comando permite fazer com
que um sprite realize uma trajetória linear em direção a um ponto específico do
palco, definido pelas suas coordenadas cartesianas, tendo como duração o intervalo
de tempo especificado no argumento T. No entanto, esse comando executa a
trajetória de forma atômica, ou seja, ele retém a execução do bloco de código onde
está inserido até que a trajetória linear seja finalizada, e não pode ser interrompido.
Esse é um impeditivo para seu uso na implementação da bala e do tanque inimigo,
já que a trajetória de cada um desses sprites deve ser interrompida no caso de
colisão. Além disso, como o tanque que dispara a bala pode ser rotacionado, a
posição final da bala não pode ser prevista49.
Dessa forma, após uma série de dúvidas sobre essa funcionalidade, os professores
das turmas indicaram que o caminho mais viável para implementar o deslocamento
da bala e do tanque inimigo seria a utilização de uma estrutura de repetição, cujo
passo envolveria o deslocamento do sprite alguns “passos” para frente
(considerando que a sua orientação já estivesse correta), e cuja condição de parada
envolveria a colisão com um outro sprite ou com os limites da tela, no caso da bala
não acertar o alvo. Um exemplo dessa estrutura para implementar o deslocamento
da bala é apresentado na Figura 50.
49
Ao menos, não de forma trivial – seria necessário um cálculo trigonométrico para descobrir
a posição final da bala, o que não seria prático e estaria fora do alcance dos alunos naquele
momento.
161
Figura 50 – Estrutura de repetição com teste de colisão com outro sprite no jogo
Simulação de Guerra
O terceiro problema enfrentado pelos alunos refere-se a modificar o estado do
sprite do tanque e da bala uma vez que cada um deles finalize o seu deslocamento
na tela. Em outras palavras, quando a bala é disparada e explode, ela deve mudar
seu traje (simulando uma explosão), desaparecer do palco, e daí alterar seu
posicionamento e direção para que, no próximo disparo, ela apareça saindo do
tanque novamente. A necessidade de modificar todos esses atributos do sprite pela
primeira vez também foi alvo de várias dúvidas, exemplificadas aqui nas palavras de
Benício (P6):
[Benício]
Ainda não está indo, a bala, olha só [mostrando o
programa]...
[O professor analisa brevemente o código já implementado]
[Professor]
Ele tá executando o movimento da bala, você viu?
[Benício]
Pois é, mas ela não tá aparecendo.
[Professor]
Ah... Ela estava oculta [clicando duas vezes no comando
“apareça”]. Viu só? Você executou o comando “desapareça” em algum
momento, e não executou o “apareça”!
[Benício]
Eu não ia encontrar nunca!...
O gerenciamento de vários atributos de uma só vez exigiu uma reflexão e
atenção adicionais dos alunos. Alguns desanimaram durante o caminho, como
expresso na fala de Jéssica (P16): “Ah, professor, desisto! É muito difícil...” – mesmo
assim, ao final do encontro a aluna já havia entendido o funcionamento e estava
ajudando outros colegas. Outros, como Bianca (P5), tentaram uma estratégia
diferente para compreender o funcionamento dos sprites: “Posso jogar um pouco
para entender?” – a aluna pediu permissão para jogar o jogo já concluído no
computador do professor e visualizado por todos os alunos na projeção na parede.
Outros alunos se sentiram à vontade para pedir o mesmo posteriormente.
O interesse em modificar a apresentação visual do jogo também esteve
presente na atividade. Guilherme (P19), ao saber que o efeito animado da explosão
da bala poderia ser obtido simplesmente por uma troca sequencial dos trajes,
162
comandada por uma estrutura de repetição com número definido de iterações,
afirmou: “Nossa que legal... Eu pensei que fosse uma coisa de outro mundo...”. A
fala de Caio (P21) revela a motivação em acrescentar mais uma funcionalidade ao
jogo: “Dá para fazer o jogo ter uma quantidade de vidas que vai diminuindo antes de
dar Game Over?”. Vários alunos também expressaram o interesse de incluir uma
tela de “Game Over” no jogo, que exigiria novamente o uso do mecanismo de
mensagens. Mais detalhes sobre a análise das funcionalidades adicionadas pelos
alunos aos jogos podem ser obtidos na subseção 0.
6.2.6 Atividade 6: Arkanoid
O jogo Arkanoid foi desenvolvido pelos alunos do IFSP na semana dos dias
15/04/2013 e 17/04/2013, e a atividade também prosseguiu no encontro que ocorreu
na semana seguinte. As atividades acadêmicas na UV ficaram interrompidas até o
mês de agosto, devido à greve estudantil; por essa razão, não houve tempo hábil
para desenvolver esta atividade no Chile.
Nesta atividade, os alunos iriam essencialmente utilizar os mesmos conceitos
empregados na construção do jogo Simulação de Guerra: alteração de orientação,
posicionamento e traje de sprites e a utilização de estruturas de repetição para
gerenciar a movimentação de sprites. Além desses conceitos, a definição do
comportamento dos blocos a serem atingidos pela bola envolvia intencionalmente a
construção de condições com operadores booleanos e o uso de variáveis, como
uma forma de também reforçar a utilização desses conceitos, conforme as diretrizes
de projeto da Oficina (seção 0).
Dessa forma, era esperado que os alunos não apresentassem muitas
dificuldades na realização desta atividade. No entanto, dois problemas foram
identificados: o primeiro deles relaciona-se à identificação do ângulo de reflexão da
bola; o segundo, à colisão entre a bola e os blocos. Ao considerar as limitações de
tempo impostas para a realização da Oficina, foi definido que os alunos receberiam
o código inicial para o deslocamento da bola, apresentado na Figura 51. Em
particular, esperava-se que os alunos inicialmente compreendessem a operação
aritmética realizada na estrutura condicional “se” e, dessa forma, conseguissem
163
deduzir a expressão análoga para produzir a reflexão da bola quando ela colidisse
com os blocos a serem construídos.
Figura 51 – Código inicial para movimentação da bola no jogo Arkanoid
No entanto, a grande maioria dos alunos apresentou dificuldades e pouco
interesse em deduzir os cálculos necessários para a reflexão da bola. Um exemplo
das dificuldades pode ser constatado na conversa de Breno (P7) com o professor,
quando tentava responder a uma das perguntas da aula. A pergunta solicitava que o
aluno informasse o que deveria acontecer com a direção da bola assim que ela
tocasse a plataforma, e qual a relação entre a nova direção da bola e sua direção
original. Analisando o código inicial, Breno escreveu que “se a direção da bola for
maior que 90, a bola é rebatida para -180º; se for menor que 90, rebata 180º (sic)”.
Ao ser questionado se a nova direção da bola não teria relação com a direção
original, Breno constata, executando o protótipo do jogo:
[Breno]
Olha só, a direção da bola tá 110... E agora 70 [ao colidir com
o limite lateral da tela]... 110... E agora 70 de novo...
Após identificar esse padrão, Breno conseguiu, com a ajuda do professor,
entender que o ângulo da nova direção resultava da operação “180 menos o ângulo
original”. No entanto, após alguma experimentação e alterando o ângulo inicial de
lançamento da bola para 45 graus, o aluno constatou outro fato:
[Breno]
Eu entendi que ela rebate os 45 graus, e os 135... Ela rebate
135 quando ela vem pra cá [em direção à barra], e 45 pra lá [se afastando
164
da barra], e vice-versa; só que eu mudei lá pra testar, ela continua
funcionando do mesmo jeito.
[Professor]
Como assim, do mesmo jeito?
[Breno]
Eu coloquei 180 ou -180 lá [na expressão de cálculo] e
funciona...
Em sua experimentação, Breno identificou uma característica peculiar do
ambiente do Scratch. Como dito anteriormente, a direção de um sprite pode
teoricamente assumir valores inteiros de -179 a 180. No entanto, verificou-se que os
comandos que aceitam o valor de um ângulo como parâmetro (como, por exemplo,
“aponte para a direção”), aceitam qualquer valor inteiro. Neste caso, relatado por
Breno, quando a bola tem a direção 135º, o valor correto do ângulo de reflexão com
a barra é dado pela expressão 180 – 135 = 45 graus. No entanto, se o cálculo for
feito com a expressão -180 – 135 = -315 graus, o ambiente do Scratch
automaticamente calcula o resto da divisão de -315 por 360, que resulta nos
mesmos 45 graus, e utiliza esse valor para a direção do sprite. Essa conversão
automática provavelmente resulta de características internas da linguagem Squeak,
na qual o Scratch foi construído, visando evitar erros em tempo de execução por
passagem de valores inválidos no argumento do comando “aponte para a direção”.
Essa característica inesperada da linguagem dificultou uma abordagem mais
conceitual para o problema do cálculo do ângulo de reflexão da bola, já que mesmo
valores “inválidos” seriam aceitos pelo programa. O termo “inválidos” está entre
aspas pois, evidentemente, os valores são conceitualmente válidos considerando
mais de uma volta no círculo trigonométrico; no entanto, esse conteúdo matemático
estava além dos conhecimentos dos alunos da turma, em sua maioria cursantes do
segundo ano do ensino médio. Devido a essa flexibilidade da linguagem, foi possível
verificar que a maioria dos alunos simplesmente copiou o condicional “se” para
implementar a colisão da bola com os blocos, obtendo o resultado esperado com
sucesso mesmo sem compreender o conceito subjacente.
O segundo problema enfrentado pelos alunos foi de ordem técnica. Como a
bola se movimentava por meio de uma estrutura de repetição, onde a cada iteração
é executado um movimento de algumas unidades (no exemplo da Figura 51, cinco
passos). Eventualmente, os alunos verificaram que mesmo após sendo detectada
uma colisão entre a bola e um bloco, com a consequente mudança de direção da
bola, isso não seria suficiente para a colisão deixar de existir, o que provocaria uma
165
nova (e indevida) mudança de direção da bola. A solução utilizada pelos alunos para
contornar esse problema foi fazer com que a bola imediatamente se desloque alguns
passos para “escapar” da colisão (Figura 52), antes de reiniciar a repetição que
controla seu deslocamento.
Figura 52 – Contorno do problema de colisão entre a bola e o bloco no jogo
Arkanoid
Poucos alunos solicitaram ajuda para resolver o problema de verificar quando
a bola não pode mais ser atingida pela barra, controlada pelo jogador, situação essa
na qual o jogador perde uma vida e o jogo é reiniciado. Esses alunos foram
orientados a verificar o valor da posição y do sprite da bola; no entanto, a maioria
dos alunos resolveu o problema reutilizando o conceito de colisão entre sprites,
criando um sprite artificial sob a barra. Maiores detalhes sobre essa funcionalidade
são descritas na subseção 0.
6.2.7Atividade 7: Pacman
A construção do Pacman foi a atividade que ocupou a maior quantidade de
encontros da Oficina no IFSP. Os encontros com as turmas A e B, do dia 29/04/2013
a 28/05/2013, foram dedicados à construção do jogo, sendo cinco encontros em
cada turma. Foi necessária uma semana a mais do que havia sido inicialmente
planejado no projeto da Oficina. No Chile, as atividades acadêmicas na UV foram
retomadas no dia 19/08/2013. Foi possível realizar os encontros da Oficina
dedicados à construção do Pacman por três semanas, e a entrega do projeto foi
marcada para o dia 10/09/2013.
166
Na primeira semana de trabalho no projeto, os alunos foram orientados a usar
a imagem pré-construída da grade de quadrados de lado igual a 16 pixels e definir a
movimentação do sprite do Pacman apenas sobre as linhas da grade, obtendo
assim o efeito de movimentação em um labirinto que seria necessário
posteriormente50. O suporte dos professores se mostrou muito necessário nesse
momento. Uma vez que os alunos foram orientados a descobrir qual seria a regra de
formação da grade, houve muita dificuldade em identificar a distância entre as linhas
da grade devido à necessidade de movimentar o cursor do mouse com muita
precisão para identificar as coordenadas relativas a cada linha na interface do
Scratch (vide Figura 36) e, consequentemente, a distância entre elas. Mesmo após
identificar que a distância entre duas linhas era de 16 pixels, foi necessário
identificar que as coordenadas y das linhas horizontais e as coordenadas x das
linhas verticais tinham valores múltiplos de 16. Nesse momento, já era planejada a
introdução dos alunos ao conceito de resto da divisão, para que fosse possível
identificar quando o Pacman estivesse cruzando uma linha horizontal ou vertical e,
dessa forma, pudesse mudar sua direção. Na Figura 53 é apresentado um trecho de
código para identificar essa situação.
Figura 53 – Código para identificar se o Pacman está posicionado sobre uma linha
horizontal e vertical ao mesmo tempo
Na segunda semana de trabalho do projeto, ainda havia vários alunos com
dúvidas relativas a esse posicionamento. Mesmo após a compreensão da lógica do
teste por múltiplos de 16, uma falha identificada por vários alunos é exemplificada na
fala de Adriana (P2): “Quando eu viro [o Pacman] para cima, ele sobe direitinho, mas
quando eu viro para a direita, ele sai da linha...” – essa constatação indica que a
aluna construiu sua condição lógica de forma semelhante àquela exibida na Figura
53, mas não atentou para a necessidade de testar ambas as coordenadas, x e y.
50
Vide a descrição da atividade na subseção 0 para maiores detalhes.
167
Ainda na segunda semana de trabalho, a grade que direcionava a
movimentação do Pacman foi substituída pela imagem do labirinto51, cuja construção
seguia as mesmas medidas da grade. Nesse momento, surge a necessidade de se
detectar a colisão do Pacman com as paredes azuis do labirinto e, para tanto, foi
sugerido aos alunos que utilizassem um segundo sprite, cujas cores permitiriam
indicar a presença de uma parede na “vizinhança” do sprite do Pacman52. A partir da
utilização desse segundo sprite, foi possível armazenar em quatro variáveis a
presença ou ausência de uma parede acima, abaixo, à direita ou à esquerda do
Pacman. A construção dessa funcionalidade ocupou a segunda e terceira semanas
de trabalho.
Foi definido que o personagem deveria se movimentar como no jogo original,
ou seja, se houvesse espaço livre à frente do Pacman, ele deveria automaticamente
seguir em frente, a menos que o jogador tentasse efetuar uma mudança de direção.
Tal mudança de direção só poderia ser efetuada se: (a) o Pacman estivesse em uma
intersecção das linhas de guia, tal como já havia sido feito com a grade; (b) na nova
direção desejada não existisse uma parede, evento identificável pelas variáveis que
são atualizadas pelo sprite indicador mencionado no parágrafo anterior. Logo, o
objetivo desta segunda semana de trabalho seria incluir a condição (b) no código, o
que exigiu dos alunos a enumeração de todas as possibilidades que impedissem a
movimentação do Pacman, em função da direção atual do seu sprite. Um exemplo
do código construído por Lucas (P4) para resolver a condição (b) é apresentado na
Figura 54. Note que a mudança de direção do sprite somente se efetiva se ambas as
condições, (a) e (b), são atendidas, e que condições análogas são definidas na
sequência para as direções direita e esquerda.
51
52
Vide Figura 19.
Vide Figura 20.
168
Figura 54 – Enumeração definida por Lucas (P4) das possíveis situações que
permitem a mudança de direção do Pacman
Lucas discutia a construção do jogo com mais dois colegas, mas foi após uma
conversa com o professor na segunda semana de trabalho que ficou clara a
necessidade de usar as variáveis do teste de colisão para efetivamente controlar as
movimentações possíveis do Pacman. No entanto, na semana seguinte o grupo de
Lucas e vários de seus colegas53 ainda precisaram de ajuda para resolver um
problema semelhante: fazer com que o Pacman parasse quando, em sua
movimentação automática, encontrasse uma parede à sua frente:
[Lucas]
Então, ele [Pacman] parte pra direita, né, então eu uso um “se
‘tocando na direita’ igual a falso” pra deixar ele seguir. Aí ele para no final do
corredor, normal. Mas aí eu viro ele pra cima, e ele atravessa a parede...
[Professor]
Isso acontece porque não adianta você testar só o valor [da
variável] “tocando na direita”. Depende da direção pra onde o Pacman vai,
não é?
Somente então Lucas percebeu que tinha se deparado com um problema
similar ao anterior: a colisão deveria ser verificada em função da direção atual do
Pacman e, novamente, todas as possibilidades deveriam ser enumeradas. O código
produzido pelo aluno para resolver essa situação é apresentado na Figura 55.
Apesar de alguma redundância no uso do comando “mova 2 passos”, Lucas
conseguiu definir que o Pacman só poderia se mover quando uma das quatro
condições fosse atendida com sucesso.
O raciocínio inverso foi seguido por Guilherme (P19), que definiu condições
análogas para situações em que o Pacman não deveria se movimentar; no entanto,
o aluno usou estruturas condicionais como “se direção = 90 e tocandonadireita =
verdadeiro então pare comando”. A semântica de “pare comando” interrompe o
bloco de código no qual está o comando está inserido, produzindo o problema do
qual Guilherme se queixou: o Pacman parava na primeira colisão com uma parede.
53
professor.
Na Turma A do IFSP, pelo menos outros seis alunos fizeram perguntas semelhantes ao
169
Figura 55 – Enumeração das possíveis situações para que o Pacman se movimente
quando não há um obstáculo a sua frente
O professor da turma B relatou a ideia de um aluno, cujo nome não foi
possível identificar, que pensou em uma curiosa solução para o problema de definir
os limites de movimentação do Pacman. Ele questionou o professor se seria
possível definir um grande sprite, abrangendo os quatro limites do labirinto, e testar
a colisão do Pacman com esse sprite54. Devido aos problemas técnicos que
potencialmente ocorreriam, relacionados à superposição de dois sprites, o aluno foi
desencorajado de seguir essa ideia.
Na quarta e quinta semanas, o trabalho dos alunos se concentrou na
construção dos dois fantasmas inimigos. O primeiro deles, que deveria andar por
uma região pré-determinada do labirinto, foi desenvolvido sem muitas dificuldades
pela maioria dos alunos; os principais problemas estiveram concentrados na
implementação do fantasma que deveria perseguir o Pacman. A partir da
especificação da tarefa, alguns alunos já haviam discutido algumas estratégias para
iniciar a sua resolução. A exibição para os alunos de uma versão funcional do jogo
no projetor no encontro da turma A foi o ponto de partida para intensificar essa
discussão:
[Caio]
Professor, o seu fantasma tem dois trajes, ou é impressão
minha?
[Professor]
Ele usa quatro trajes, quando a direção dele muda, dá para
perceber porque o “olhinho” muda de direção. É fácil de fazer.
[Lucas]
Mas qual que está perseguindo?
[Professor]
É o vermelho, é que nessa versão eu fiz um teste e ele para
de perseguir o Pacman depois de um intervalo de tempo. E depois, ele volta
a perseguir. É a lógica do jogo original.
[Lucas]
Mas como é que eles perseguem?
54
A reutilização de outras soluções como essa, baseadas na colisão entre sprites, será
apresentada na seção 0.
170
[Professor]
É uma questão de distância... O fantasma tem que tentar
sempre reduzir a distância em relação ao Pacman. Essa é a ideia. Se ele
pode escolher duas direções, você vai para aquela que deixa a distância
menor.
[Diana]
Então é mais fácil fazer primeiro aquele que fica só em uma
área, né?...
[Professor]
É verdade, é mais fácil começar por esse.
Mesmo havendo sido discutidos os princípios básicos que definem o algoritmo
do fantasma perseguidor, os alunos apresentaram muitas dificuldades e dúvidas, a
ponto da entrega do projeto ser adiada por mais uma semana. No quinto encontro
de trabalho no projeto, cientes das dificuldades dos alunos, os professores
propuseram estratégias que levassem em consideração conceitos que os alunos já
tivessem trabalhado em atividades anteriores. Isso aconteceu de forma autônoma
pelos dois professores, pois não houve tempo hábil para eles se comunicarem
previamente. Assim, duas estratégias diferentes foram propostas.
Na Turma A, o professor propôs que fossem criados quatro sprites, similares
ao sprite usado para identificar a colisão do Pacman com as paredes do labirinto,
mas que se posicionassem ao redor do sprite do fantasma. Esses sprites ficariam
continuamente armazenando em quatro variáveis a distância para o Pacman
(usando uma função disponibilizada pelo Scratch, denominada “distância para
<sprite>”) de forma que, quando o sprite do fantasma atingisse um ponto onde é
possível uma mudança de direção, sua orientação poderia ser alterada para a
direção que mais aproximasse o fantasma do Pacman. Na Figura 56 essa estratégia
é ilustrada. O sprite inferior armazenará a menor distância para o Pacman, dentre as
possíveis mudanças de posição para o fantasma, e dessa forma ele seguirá para
baixo.
Figura 56 – Estratégia para o fantasma patrulhador proposta aos alunos do IFSP –
Turma A
171
Na Turma B, o professor propôs uma simplificação do cálculo da distância
entre o fantasma perseguidor e o Pacman, verificando apenas a diferença de valor
entre as coordenadas x ou entre as coordenadas y dos dois sprites, optando assim
por seguir na primeira direção livre que reduzisse a distância horizontal ou vertical
entre os sprites. Na Figura 57, essa estratégia é ilustrada. Nessa estratégia, a ordem
de verificação das direções é arbitrária; assim, se o algoritmo testa as direções na
ordem: cima, direita, baixo, esquerda, na configuração abaixo o fantasma
perseguidor seguiria para a direita, e depois para baixo.
Figura 57 – Estratégia para o fantasma patrulhador proposta aos alunos do IFSP –
Turma B
Esta parece ter sido a funcionalidade que trouxe mais dificuldades aos alunos,
ao se considerar a quantidade de dúvidas que foram trazidas aos professores,
inclusive fora do horário dos encontros da Oficina. A utilização do projeto final como
um dos principais elementos de avaliação da disciplina certamente contribuiu para
esse engajamento. A entrega dos projetos foi feita nos dia 03 e 04/06/2013, quando
também foram feitas as entrevistas baseadas em artefatos.
Na UV, a quantidade de dúvidas levantadas pelos alunos durante os
encontros foi significativamente menor. O atraso na finalização do semestre letivo
levou vários alunos a trabalharem de forma autônoma na construção do projeto, cuja
nota seria utilizada pelos professores como bônus na disciplina de Fundamentos de
Programação. A preocupação dos alunos pode ser exemplificada por uma
comunicação eletrônica de Flavio (P46), enviada ao professor responsável pela
disciplina de Fundamentos de Programação e que supervisionou a aplicação da
Oficina:
172
Buenos días profesor, cuando realizamos las ayudantias y trabajamos con
las celdas, haciendo que el pacman avanzara según las coordenadas... yo
probé el método de amarillo tocando blanco, y el problema era el margen de
error al momento de tocar un borde, ya que avanzaba un poco más de lo
debido y se quedaba parado. Bueno ahora con la inserción de el mapa
original de pacman, si funciona insertandole un punto adelante de pacman,
con la condición que este tocando negro. No tuve problema con la creación
de los fantasmas, solo eso me complica. Y no puedo dedicar mucho más
tiempo a la tarea debido a los próximos certámenes de álgebra, calculo y
Fundamentos. Espero su comprensión y que sea posible la utilización de mi
método. Saludos cordiales.
O problema relatado por Flavio estava relacionado a uma dificuldade no uso
do sprite indicador de colisões; devido à geometria do labirinto e do sprite, quando a
verificação de colisão não ocorresse exatamente na intersecção das linhas
horizontais e verticais, o sprite do Pacman poderia se movimentar mais alguns
passos à frente, exatamente como descrito pelo aluno. O pouco tempo para resolver
o problema fez com que Flavio encontrasse uma solução alternativa e solicitasse
assim a permissão do professor para utilizá-la, já que a avaliação do projeto seria
considerada na disciplina de Fundamentos de Programação.
A dificuldade em construir o fantasma perseguidor foi maior, em especial pela
maior limitação de tempo para o desenvolvimento do projeto. Também aproveitando
a experiência que os alunos já haviam adquirido com o funcionamento da
movimentação do Pacman, o professor responsável propôs uma alternativa baseada
nessa funcionalidade. Na proposta feita aos alunos do Chile, o fantasma deveria
mudar de direção de forma aleatória quando seu sprite chegasse a uma posição da
tela onde fosse possível a mudança de direção. Para detectar essas posições, foi
sugerido que os alunos utilizassem a estratégia do sprite indicador de colisões já
utilizada para a movimentação do Pacman. Como a movimentação do fantasma não
depende do controle do jogador, o sorteio de uma nova posição foi feita sempre que
não fosse mais possível seguir em frente; trata-se de um problema similar à
interromper a movimentação do Pacman quando ele não pode mais seguir em
frente, discutido anteriormente (vide Figura 55). Da mesma forma que no IFSP, os
alunos chilenos foram estimulados a incluir funcionalidades adicionais no jogo e a
cuidar da qualidade da apresentação final do jogo, já que foi informado aos alunos
que tais atributos seriam considerados na avaliação do projeto.
173
6.3 Jogos desenvolvidos55
Conforme discutido na seção 0, a análise dos jogos desenvolvidos pelos
alunos parte da premissa que pelo menos parte das competências e habilidades
desenvolvidas pelos alunos estarão expressas nos artefatos produzidos por eles
(BRENNAN; RESNICK, 2012). Assim, nesta seção, serão apresentados os
resultados da análise dos jogos em termos dos conceitos de programação utilizados
ao longo do tempo pelos alunos (subseção 0) e em termos da jogabilidade
incorporada pelos alunos em funcionalidades adicionais (subseção 0). Por fim, será
apresentada na subseção 0 a identificação de traços de reutilização de
funcionalidades pelos alunos.
Ao iniciar essa análise, cabe ressaltar que os resultados foram parcialmente
influenciados pela modalidade de oferecimento da Oficina. Verificou-se que a
presença dos alunos às atividades no IFSP foi mais regular, já que a Oficina foi
incorporada a uma disciplina regular do curso. Na UV, provavelmente por se tratar
de uma atividade extracurricular, a Oficina teve uma participação mais irregular por
parte dos alunos. Soma-se a essa questão uma greve estudantil no Chile que
paralisou as aulas entre os meses de junho e agosto de 2013. Quando as atividades
foram retomadas, foi necessário cancelar a atividade de construção do jogo
Breakout para que houvesse tempo hábil para a construção do projeto final do
Pacman. Além da importância desse artefato para a pesquisa, já havia sido
acordado com os alunos que o projeto final seria avaliado e que a nota atribuída
seria utilizada como um bônus na disciplina de Fundamentos de Programação.
A quantidade de instâncias de cada tipo de jogo desenvolvidas pelos alunos
da Oficina, pelos grupos do Brasil e do Chile, são apresentadas na Tabela 13. Devese ressaltar que as oscilações na quantidade de jogos desenvolvidos deve-se à
55
As análises apresentadas nesta seção foram extraídas das seguintes publicações:
•
BARCELOS, T. S. et al. Informal HCI: Fixing Playability Issues As A Strategy To Improve The
Skills Of Novice Programmers. Revista IEEE América Latina, v. 12, n. 1, p. 29–35, 2014.
•
BARCELOS, T. S.; MUÑOZ, R.; SILVEIRA, I. F. Improving novice programmers’ skills through
playability and pattern discovery: a descriptive study of a Game Building Workshop. In:
SAEED, S.; BAJWA, I. S.; MAHMOOD, Z. (Org.). Human Factors in Software Development
and Design. Hershey: IGI Global, 2014 (no prelo).
174
Tabela 13 – Quantidade de instâncias de cada jogo desenvolvido na Oficina
Jogos
Brasil - IFSP
Chile - UV
Encontro do gato com o rato
32
24
Pescaria
28
11
Jogo de Advinhação
29
26
Pedra, papel e tesoura
29
15
Simulação de Guerra
22
5
Arkanoid
29
***
Pacman
21
22
*** O jogo Arkanoid não foi desenvolvido pelos alunos no Chile
ausência de alunos, bem como à preferência por desenvolver as atividades
individualmente ou em dupla.
6.3.1 Conceitos de programação
Esta primeira análise tem como objetivo identificar a seleção e uso de
estruturas de programação pelos alunos ao longo das atividades da Oficina. Em
particular, pretende-se compreender como os alunos utilizam as estruturas de
programação para resolver tarefas não-triviais, ou seja, que possibilitam mais de
uma estratégia de solução. Para tanto, optou-se por fazer um recorte, selecionando
a partir da rubrica educacional da Oficina (Apêndice B) as tarefas nas quais era
previsto o uso de estruturas de repetição. A compreensão e uso de tais estruturas
apresenta-se como uma das principais dificuldades para programadores iniciantes.
Ginat (2004) discute a dificuldade de alunos iniciantes em identificar os limites
numéricos de variáveis de controle da repetição; Setti (2009) apresenta um
experimento em que estudantes de Lógica de Programação, ao se depararem com
um problema envolvendo o cálculo de regularidades numéricas, encontram
dificuldades em passar do registro algébrico do problema para uma representação
algorítmica baseada no uso de laços de repetição.
Na Figura 58 é apresentado um diagrama ilustrando a sequência de tarefas
que envolveram a utilização de estruturas de repetição. Vale ressaltar que a
retomada do mesmo conceito em várias atividades na sequência relaciona-se a uma
das diretrizes para elaboração das atividades da Oficina, apresentadas na seção 0.
175
Figura 58 – Diagrama ilustrando as tarefas da Oficina que envolvem o uso de estruturas de
repetição
O primeiro uso de estruturas de repetição acontece durante a construção do
jogo de Pescaria. Nesta atividade, os alunos receberam uma versão inicial do
programa, na qual o código de um sprite, representando um peixe, modifica a
posição do sprite no palco utilizando coordenadas; a seguir, a execução entra em
estado de espera por dois segundos, e o procedimento se repete em um laço de
repetição (“sempre”) sem condição de parada (vide Figura 12). A proposta do jogo
envolve a criação de dois peixes com comportamentos diferentes, e uma das tarefas
da atividade solicita que os alunos definam um número máximo de vezes que cada
peixe apareça na tela. Dessa forma, espera-se que os alunos explorem o conceito
de condição de parada, por meio de uma estrutura de repetição “repita X”, com um
número definido de iterações (Figura 59).
Figura 59 – Uso de laço com número definido de iterações no jogo de Pescaria
A construção do Jogo de Advinhação é feita integralmente pelos alunos desde
o início: esta é a primeira atividade em que não é fornecido um programa inicial a ser
modificado. Aqui, novamente, o uso de uma estrutura de repetição está vinculado à
176
condição para finalização do jogo: o jogador deve ter uma quantidade limitada de
oportunidades para adivinhar o número sorteado pelo computador, definida pela
quantidade de iterações do laço em que o programa solicita a entrada de um número
via teclado e compara esse número com aquele previamente sorteado. A análise
das soluções apresentadas pelos alunos permite identificar alguma variabilidade. As
estruturas de repetição utilizadas são apresentadas na Tabela 14.
Tabela 14 – Estruturas de repetição utilizadas pelos alunos no Jogo de Advinhação
Estrutura utilizada
% jogos (qtde jogos)
Brasil - IFSP
Chile - UV
Repetição com condição booleana de parada (“repita até”)
32% (9)
31% (8)
Repetição com quantidade definida de iterações (“repita X”)
4% (1)
19% (5)
Repetição sem condição de parada, interrupção via comando
“pare”
25% (7)
8% (2)
Não utilizou estrutura de repetição
39% (11)
42% (11)
Sendo esta a primeira atividade na qual o uso da repetição é feita de modo
autônomo pelos alunos, é possível identificar um elevado percentual de alunos que
não conseguiram incorporar esse conceito (39% no Brasil e 42% no Chile56). Apesar
da utilização da repetição com quantidade definida de iterações (“repita X”) na
atividade anterior, em mais da metade das instâncias do Jogo de Advinhação com
uso de repetição, foi possível identificar o uso da estrutura “repita até”. Ao exigir a
definição de uma condição de parada, o uso dessa estrutura levou os alunos a
explorarem a sintaxe de expressões booleanas no Scratch. Conforme já
apresentado na descrição da observação das atividades de aula (subseção 0), a
realização da atividade em duas etapas levou os alunos a, inicialmente, testar uma
condição de parada do laço vinculada unicamente ao acerto do número sorteado
(em um código como “repita até resposta = número_sorteado”) e mantendo a
mesma estrutura na posterior modificação do programa, qual seja, a inclusão de
uma quantidade limite de oportunidades para que o jogador possa adivinhar o
56
No oferecimento desta atividade na UV, o domínio do conceito de repetição pode ter sido
limitado pela dificuldade adicional provocada pelo fato que muitos alunos compareceram à Oficina
nesta atividade pela primeira vez, conforme mencionado na subseção 0.
177
número. Nesse processo, em alguns jogos (4 do Brasil e 1 do Chile), foi inclusive
possível identificar que alguns alunos experimentaram com sucesso o uso do
operador booleano OU, construindo uma condição de parada composta para o laço
(Figura 60).
Figura 60 – Utilização do operador booleano OU no laço de repetição do Jogo de
Advinhação
No jogo Pedra, Papel e Tesoura, a utilização de uma estrutura de repetição foi
ocasionada pela implementação de uma funcionalidade adicional por alguns alunos:
uma mensagem no fundo da tela, indicando qual dos jogadores ganhou a disputa.
Essa funcionalidade foi implementada em 8 dos 29 jogos desenvolvidos no IFSP
(27,5% do total de jogos), todos oriundos da turma B57. Adicionalmente, um aluno
implementou a mesma funcionalidade, mas com o uso de mensagens. Na UV, essa
funcionalidade apareceu em 6 dos 15 jogos desenvolvidos (40% do total de jogos).
Para a criação dessa funcionalidade, foi necessária uma estrutura de repetição sem
condição de parada (“sempre”), que continuamente verificava o estado dos dois
sprites que representavam a mão dos jogadores e atualizava uma mensagem no
fundo de tela. A exploração desse conceito e de outras funcionalidades incluídas
pelos alunos nos jogos será discutida em detalhes na seção 0.
Nos jogos Simulação de Guerra e Arkanoid, os alunos se depararam com
uma questão muito comum em jogos digitais com representação gráfica em duas
dimensões: a necessidade de programar uma trajetória linear para um sprite,
verificando durante a trajetória a colisão com outros sprites ou com os limites da tela.
Esse é o caso da implementação da bala e do tanque inimigo no jogo Simulação de
Guerra, e da implementação da bola do Arkanoid. Para tanto, a única possibilidade
de solução é o uso de uma estrutura de repetição com condição de parada
envolvendo um teste de colisão com outros sprites (como exemplificado na Figura
50), utilizada por todos os alunos que resolveram o problema com sucesso após
57
Esse fato pode ter relação com uma diferença na orientação dada pelos dois professores
responsáveis pela Oficina no IFSP, que foi descrita na subseção 0.
178
alguma experimentação. Mais detalhes sobre essa experimentação são informados
na descrição da observação da atividade apresentada na subseção 0.
Para a construção do jogo Pacman, uma das tarefas envolvia a definição de
um fantasma inimigo que deveria se movimentar seguindo um caminho fixo no
labirinto. Nesse caso, não foi possível identificar uma estratégia de resolução
predominante entre os alunos. Na Tabela 15 é apresentado um resumo das
estratégias utilizadas nos jogos desenvolvidos pelo grupo brasileiro.
Três das estratégias foram igualmente encontradas, cada uma sendo utilizada
em seis instâncias dos jogos. A primeira delas é o uso de uma estrutura de repetição
onde o passo envolve movimentar o sprite do fantasma alguns passos para frente
(de forma similar ao exemplificado na Figura 50) e a condição de parada envolve as
coordenadas cartesianas do ponto onde o fantasma deve parar para daí mudar de
direção e continuar sua trajetória. A segunda estratégia é muito similar à primeira,
mas a condição de parada envolve a verificação da colisão com um pequeno sprite
indicador da posição em que o fantasma deve parar. Já a terceira estratégia envolve
o deslocamento atômico do sprite utilizando o comando deslize. Na Figura 61 é
apresentado um diagrama esquematizando as três estratégias, junto com um
pequeno exemplo de código de cada uma delas.
179
Tabela 15 – Estratégias utilizadas para implementar o fantasma patrulhador (alunos
do Brasil)
% jogos
Estrutura utilizada
Brasil - IFSP
Repetição com condição de parada (coordenadas cartesianas
do fantasma)
28,6% (6)
Repetição com condição de parada (colisão com sprite)
28,6% (6)
Comando “deslize”
28,6% (6)
1
Outra
4,8% (1)
Tarefa não cumprida
9,4% (2)
OU
OU
Figura 61 – Exemplo de três estratégias para implementar a movimentação do
fantasma patrulhador no jogo Pacman
Como mencionamos anteriormente na seção 0, no grupo do Chile houve um
tempo limitado para finalizar o projeto do Pacman, e dessa forma muitos alunos
optaram por uma implementação alternativa do fantasma patrulhador: dentro de um
laço sem condição de parada, o sprite se move alguns passos para frente. Quando o
sprite atinge um ponto de intersecção (detectado pela mesma estratégia usada para
movimentação do Pacman – vide seção 0), o código sorteia uma direção dentre as
direções livres. O fantasma passa a apontar para aquela direção e continua seu
deslocamento. Em 13 dos 22 jogos entregues foi implementado pelo menos um
180
fantasma; a estratégia mencionada acima foi implementada em 9 desses 13 jogos
(ou 40,9% do total de jogos). Nos demais 4 jogos (18,1% do total de jogos), o
fantasma patrulhador foi implementado com o comando “deslize”, utilizando-se a
mesma estratégia já descrita anteriormente.
6.3.2 Funcionalidades adicionais e jogabilidade
Conforme apresentado na descrição da observação etnográfica (seção 0), os
alunos frequentemente questionaram as limitações de alguns mecanismos de
interação dos jogos propostos e procuraram melhorar esses mecanismos por conta
própria, implementando funcionalidades adicionais que não estavam previstas na
proposta inicial das atividades. De forma coerente com uma proposta construcionista
e baseada na resolução de problemas, os alunos sempre foram encorajados pelos
professores a experimentar novos recursos do Scratch para implementar
funcionalidades adicionais. A análise das funcionalidades adicionais dos jogos que é
apresentada a seguir foi motivada por essa constatação. Para tanto, foram
analisados apenas os quatro últimos jogos (Pedra, Papel e Tesoura, Simulação de
Guerra, Breakout e Pacman) pelo fato da maior complexidade da sua mecânica abrir
maiores possibilidades de personalização e expansão.
Foi possível constatar que, ao longo do tempo, os alunos procuraram
incorporar mais funcionalidades adicionais nos jogos desenvolvidos. Na Figura 62 é
apresentada a proporção entre jogos com funcionalidades mínimas (ou seja, que
cumpriram apenas a proposta da atividade) e jogos com funcionalidades extras.
181
Brasil - IFSP
Funcionalidades extras
Funcionalidades mínimas
Pedra-Papel-Tesoura
Simulação de Guerra
Breakout
Pacman
0%
20%
40%
60%
80%
100%
Chile - UV
Funcionalidades extras
Funcionalidades mínimas
Pedra-Papel-Tesoura
Simulação de Guerra
Pacman
0%
20%
40%
60%
80%
100%
Figura 62 – Proporção de jogos desenvolvidos com funcionalidades mínimas e
funcionalidades adicionais
Enquanto que no Brasil houve um acréscimo, a cada atividade, no número de
jogos com funcionalidades adicionais, no Chile essa tendência foi interrompida na
atividade que envolveu a construção do jogo Simulação de Guerra. Essa diminuição
pode ser explicada pela baixa frequência a essa atividade, que resultou em apenas
cinco jogos desenvolvidos. A atividade ocorreu em maio, em um período conturbado
em que estava prestes a se iniciar a paralisação estudantil. No entanto, no projeto
final do Pacman, é possível identificar uma proporção semelhante de jogos com
funcionalidades extras nos dois grupos, mesmo considerando que os alunos
chilenos não desenvolveram uma das atividades anteriores.
A seguir, serão apresentadas as funcionalidades adicionais mais presentes
em cada jogo desenvolvido pelos alunos do Brasil e do Chile. Para cada
funcionalidade, são apresentadas as heurísticas de jogabilidade (BARCELOS et al.,
182
2011) associadas na avaliação heurística e o percentual de jogos que incorporou
aquela funcionalidade. Todos os percentuais são calculados em relação ao total de
jogos daquele tipo que apresentaram funcionalidades adicionais. Ainda, será feita
uma associação com os critérios de qualidade, associados às heurísticas, que foram
mais frequentemente mencionadas pelos alunos no questionário de levantamento de
perfil (seção 0) como sendo relevantes para a sua experiência como jogadores.
Primeiramente, na Tabela 16 são apresentados os dados para o jogo Pedra, Papel e
Tesoura.
Tabela 16 – Funcionalidades adicionais no jogo Pedra, Papel e Tesoura
Chile - UV
Brasil IFSP
Funcionalidade adicional
Mensagem de vitória, empate ou derrota
Controle de pontuação
Instruções de como jogar
Mensagem de vitória, empate ou derrota
Instruções de como jogar
Personagem indicando a opção feita por
cada jogador
Heurísticas associadas
% jogos
H3; H6
81,8%
H3; H6; H17
9,1%
H5
9,1%
H3; H6
84,6%
H5
30,8%
H3; H6
7,7%
A funcionalidade adicional implementada com maior frequência no jogo
Pedra, Papel e Tesoura estava relacionada a uma mensagem, apresentada no
fundo da tela ou por meio de um personagem adicional, indicando qual dos
jogadores venceu a partida ou se houve empate. Tal funcionalidade está associada
a uma fácil visualização do estado do jogo (heurística H3) e à clareza das
representações visuais do jogo (heurística H6). Exemplos dessa funcionalidade são
apresentados na Figura 63.
183
Figura 63 – Funcionalidade adicional: mensagem indicando o resultado do jogo
Pedra, Papel e Tesoura
Dentre as demais funcionalidades, destaca-se a inclusão de um controle de
pontuação para as sucessivas partidas do jogo, associado às heurísticas de
visualização do estado do jogo (H3 e H6), bem como à identificação clara da
conquista de uma vitória do jogador (heurística H17), por meio do acréscimo em sua
pontuação. No grupo chileno, alguns grupos ainda adicionaram uma tela ou
mensagem inicial com instruções de como jogar (heurística H5), instruções essas
comumente relacionadas às teclas que deveriam ser acionadas pelo jogador para
efetuar uma jogada. Critérios de qualidade relacionados à visualização dos itens do
jogo foram frequentemente citados pelos alunos no questionário: o critério vinculado
à heurística H6 – “O visual do jogo é fácil de entender” foi o segundo mais citado
pelos alunos do Brasil, enquanto que o critério vinculado à heurística H8 – “O layout
e os menus são fáceis de entender” foi também o segundo mais citado pelos alunos
do Chile.
Na Tabela 17 são apresentados os dados para o jogo Simulação de Guerra.
Os dados do grupo chileno são apresentados para efeito comparativo, apesar de se
referirem a um universo de apenas cinco jogos.
Tabela 17 – Funcionalidades adicionais no jogo Simulação de Guerra
Chile UV
Brasil IFSP
Funcionalidade adicional
Heurísticas associadas
% jogos
H1
76,9%
H3; H6
46,2%
Efeitos sonoros
H10
7,7%
Efeito visual de explosão
H10
100,0%
Permitir disparo contínuo da bala
H1
50,0%
Permitir disparo contínuo da bala
Tela de Game Over
184
A funcionalidade adicional que mais vezes foi implementada foi permitir que o
jogador pudesse imediatamente atirar novamente enquanto a bala ainda estivesse
indo para o lado oposto da tela. Essa funcionalidade vem a superar uma limitação do
ambiente do Scratch: na implementação padrão do disparo da bala, vinculada ao
evento do pressionamento de uma tecla, uma parcela dos alunos constatou a
impossibilidade de atirar novamente enquanto o código referente à animação do
deslocamento da bala não encerrasse sua execução, o que praticamente elimina a
chance do jogador acertar o tanque inimigo se errar o disparo do primeiro tiro. Essa
é uma limitação técnica do ambiente: uma vez que um bloco de comando vinculado
a um evento (como “quando tecla espaço pressionada”) esteja sendo executado,
não é possível interromper a sua execução. Porém, há uma exceção a esse
comportamento: se o bloco de comando é disparado pelo recebimento de uma
mensagem, sua execução pode ser imediatamente reiniciada quando uma nova
mensagem do mesmo tipo é recebida. Apesar de não terem sido registradas
referências dos alunos a essa limitação durante a observação das aulas (subseção
0), foi possível observar nos jogos de alguns deles uma solução baseada em envio
de mensagens, como exemplificado no código de Benício (P6) na Figura 64.
Figura 64 – Solução para o disparo da bala no jogo Simulação de Guerra utilizando
o envio de mensagens
A necessidade do uso de mensagens para construir outras funcionalidades do
jogo, como a identificação da colisão entre os sprites da bala e do tanque, pode ter
influenciado alunos como Benício a experimentar essa mesma construção para
resolver o problema do disparo da bala. Além dessa funcionalidade adicional,
também verificou-se a inclusão de efeitos sonoros e visuais (heurística H10) para
chamar à atenção do jogador para a ocorrência de eventos no jogo (colisões e
185
explosões). Os dois critérios de qualidade mencionados aqui – facilidade de
controlar o jogo e qualidade dos gráficos e som – estavam dentre os mais relevantes
para os alunos no questionário. O critério associado à heurística H1 – “Os controles
do jogo são claros, confortáveis e com resposta imediata” (grifo nosso) foi o sexto
mais citado pelos alunos do Brasil e o quinto mais citado pelos alunos do Chile. Já o
critério relacionado à heurística H10 – “Qualidade dos gráficos e da trilha sonora” foi
o sétimo mais citado pelos alunos de ambos os países. A presença de uma tela de
game over foi associada à visualização do estado do jogo (heurísticas H3 e H6), que
já foram discutidas no item anterior.
Na Tabela 18 são apresentados os dados para o jogo Arkanoid, que foi
desenvolvido apenas pelos alunos brasileiros.
Brasil –
IFSP
Tabela 18 – Funcionalidades adicionais no jogo Arkanoid
Funcionalidade adicional
Esmaecimento da barra quando a bola é
perdida
Jogo apresenta vários blocos a serem
destruídos
Cenário diferenciado
Heurísticas associadas
% jogos
H6, H10
64,7%
H14
35,3%
H10
29,4%
No jogo Arkanoid a funcionalidade adicionada pelo maior número de alunos
foi uma animação mostrando o esmaecimento da barra quando a bola não pudesse
mais ser alcançada pelo jogador (Figura 65).
Figura 65 – Funcionalidade adicional: animação de esmaecimento da barra no jogo
Arkanoid
186
Ainda, como a atividade previa que era obrigatória a criação de apenas três
blocos, com diferentes comportamentos, alguns alunos utilizaram um mecanismo de
cópia de sprites disponibilizado pelo Scratch, replicando os blocos e seus
respectivos comportamentos, criando assim um desafio maior (heurística H14) e
mais próxima de um jogo “real” (Figura 66).
Figura 66 – Funcionalidade adicional: vários blocos no jogo Arkanoid
A relevância da visualização do estado do jogo (heurística H6), presente no
esmaecimento da barra, e da qualidade gráfica (heurística H10) já estavam inclusas
nos critérios de qualidade indicados pelos alunos no questionário. A presença de
vários blocos a serem destruídos foi associada na avaliação à heurística H14; o
critério vinculado a ela no questionário (“O jogo ter vários desafios, que me permitam
usar estratégias diferentes”) foi o quarto mais citado pelos alunos do Brasil. Apesar
dos alunos do Chile não terem desenvolvido o jogo Arkanoid, esse critério também
apareceu como relevante para esses alunos, sendo o sexto critério mais citado no
questionário.
Na Tabela 19 são apresentados os dados para o projeto final da Oficina, o
jogo Pacman.
187
Tabela 19 – Funcionalidades adicionais no jogo Pacman
Chile – UV
Brasil – IFSP
Funcionalidade adicional
Som de fundo e efeitos sonoros
Heurísticas associadas
% jogos
H10
57,1%
H3, H6
57,1%
H3; H6; H10
50%
Tela de apresentação
H10
28,6%
Som de fundo e efeitos sonoros
H10
94,1%
H3; H6
47,1%
H10
35,3%
H13; H14
29,4%
Controle e visualização da quantidade de
vidas
Indicação de fim do jogo
Controle e visualização da quantidade de
vidas
Tela de apresentação
Frutas para obter pontuação adicional
A funcionalidade adicional mais frequentemente implementada neste jogo foi
a adição de efeitos sonoros vinculados ao início do jogo, ao momento em que o
Pacman “come” um ponto amarelo, ou ao momento da colisão do Pacman com um
dos fantasmas (heurística H10). Outra funcionalidade adicional identificada
frequentemente foi o controle e exibição da quantidade de vidas do personagem
(associadas às heurísticas H3 e H6) e o consequente reinício do nível quando o
Pacman toca em um dos fantasmas. Um exemplo dessa funcionalidade é exibido na
Figura 67.
Figura 67 – Funcionalidade adicional: exibição da quantidade de vidas no jogo
Pacman
Vários alunos implementaram telas de introdução ao jogo, simulando a
interação humano-computador encontrada no jogo original. Também foi identificada
a criação de telas indicando o final do jogo – usualmente, quando o Pacman perde
188
todas as vidas ou, quando esse controle não foi implementado, quando ocorre a
colisão com um fantasma. Exemplos dessas telas são apresentados na Figura 68.
Figura 68 – Funcionalidade adicional: exemplo de tela inicial e de indicação de fim
de jogo no Pacman
Uma funcionalidade encontrada com maios frequência apenas nos jogos do
grupo chileno (e que também imita uma funcionalidade do jogo original) é a inclusão
de uma fruta, que aparece após um intervalo de tempo determinado. Quando o
Pacman “come” a fruta, uma pontuação adicional é somada ao total de pontos do
jogo, criando assim um objetivo secundário ao jogador (heurística H13) que pode
envolver a modificação da sua estratégia de jogo (heurística H14). Um exemplo
dessa funcionalidade é apresentado na Figura 69.
Figura 69 – Funcionalidade adicional: frutas para obter pontuação extra no Pacman
Pode se observar que quase todas as heurísticas presentes na avaliação
heurística das funcionalidades adicionas do Pacman referem-se a critérios indicados
com relevância pelos alunos no questionário. Trata-se da qualidade dos gráficos e
189
som (heurística H10, presente nos sons e efeitos sonoros e telas de apresentação e
de fim de jogo), visualização do estado do jogo (heurísticas H3 e H6, presente no
controle e visualização da quantidade de vidas e também na indicação de fim de
jogo). As frutas para obter pontuação adicional, presentes com maior frequência nos
jogos dos alunos chilenos, foi associada às heurísticas H13 e H14. A heurística H13
refere-se à presença de objetivos secundários no jogo, já que o jogador não precisa
perseguir as frutas para atingir o objetivo final, que é comer todos os pontos do
labirinto. Essa heurística não foi citada pelos alunos com muita frequência no
questionário; no entanto, se associarmos a funcionalidade à heurística H14,
vinculada à presença de diferentes desafios no jogo, podemos afirmar que essa
funcionalidade também se relaciona parcialmente a um critério de qualidade
relevante para os alunos.
6.3.3 Reconhecimento de padrões e reutilização de estratégias de construção
Reconhecer e reutilizar padrões refere-se a uma competência relativamente
útil para desenvolvedores de software profissionais. Na área de desenvolvimento de
software, um padrão refere-se à descrição de um problema que se repete em
diversas situações, bem como de uma solução padronizada que pode ser aplicada
para resolver o problema (GAMMA et al., 1994). Segundo Muller, Haberman e
Averbuch (2004), vem se demonstrando que os chamados padrões de software são
uma ferramenta útil para transmitir conhecimento sobre práticas-modelo utilizadas
por especialistas.
Na análise dos jogos desenvolvidos durante a Oficina, foram encontrados
indícios da (re)utilização do que se poderia considerar como um padrão: o uso de
colisões entre sprites para identificar o posicionamento de um dos sprites. Essa
utilização apareceu nas duas últimas atividades, os jogos Arkanoid e Pacman.
No jogo Arkanoid, surge a necessidade de identificar a posição da bola pois,
caso a bola não possa mais ser alcançada pela plataforma controlada pelo jogador;
o jogo deve ser reiniciado e o jogador deve perder uma vida. As estratégias
utilizadas pelos alunos para implementar essa funcionalidade são apresentadas na
Tabela 20. A maioria dos alunos optou por criar um novo sprite “artificial” que cobre
toda a largura do palco, e a colisão da bola com esse sprite é utilizada para
190
identificar que ela não pode mais ser alcançada pela plataforma (Figura 70). Apesar
da verificação da coordenada y da bola ser uma estratégia de implementação mais
simples, ela foi utilizada por uma parcela menor dos alunos.
Tabela 20 – Estratégias utilizadas para verificar posição da bola no jogo Arkanoid
Estratégia utilizada
% jogos
Brasil - IFSP
Colisão com sprite “artificial”
58,6% (17)
Verificação da coordenada y da bola
17,2% (5)
Tarefa não cumprida
24,2% (7)
Figura 70 – Exemplo de sprite utilizado para detectar a posição da bola no jogo
Arkanoid
Vale relembrar que apenas os alunos do Brasil desenvolveram o jogo
Arkanoid; contudo, esse padrão foi também encontrado nas implementações do
Pacman feitas tanto por alunos do Brasil quanto por alunos do Chile. Neste jogo, a
colisão entre sprites foi utilizada para identificar quando o personagem principal
atingia o final dos túneis laterais existentes no meio do labirinto. Uma tarefa
solicitava que os alunos implementassem a clássica funcionalidade que permite que
o Pacman apareça no lado oposto do labirinto quando atinge o final de um dos
túneis (Figura 71). Novamente, muitos alunos optaram por criar um sprite adicional e
detectar a colisão do Pacman com esse sprite ao invés de verificar as coordenadas
x e y do sprite do Pacman. As estatísticas para essa tarefa são apresentadas na
Tabela 21.
191
Tabela 21 – Estratégias utilizadas para verificar se personagem do jogo Pacman
entrou no túnel
Estratégia utilizada
% jogos (qtde jogos)
Brasil - IFSP
Chile - UV
Colisão com sprite “artificial”
66,7% (14)
77,3% (17)
Verificação de coordenadas x e y
14,3% (3)
13,6% (3)
Verificação de intervalo da coordenada x
9,5% (2)
0 (0,0%)
Tarefa não cumprida
9,5% (2)
4,5% (1)
Figura 71 – Exemplo de sprite utilizado para identificar a posição do Pacman
Ao elencar as tarefas anteriores que exigiam a identificação de colisões entre
sprites, é possível constatar que essa estratégia foi extensivamente utilizada na
atividade imediatamente anterior, o jogo Simulação de Guerra – inclusive, cabe
ressaltar que as turmas de ambos os países desenvolveram esse jogo. Na Figura 72
é apresentado um diagrama esquematizando a sequência de tarefas da Oficina que
exigiam o uso do conceito de colisão entre sprites, onde é possível constatar que
três tarefas no jogo Simulação de Guerra envolviam tal conceito, além da única
tarefa da atividade inicial, o Encontro do gato com o rato. As tarefas do Arkanoid e
Pacman, apesar de não exigirem o uso da colisão, foram solucionadas dessa forma
por uma parcela considerável dos alunos.
192
Figura 72 – Diagrama ilustrando as tarefas da Oficina que envolveram o uso de
colisão entre sprites
As implicações desse achado na aquisição de competências do Pensamento
Computacional, bem como na mobilização do conceito de identificação de pontos no
plano, serão discutidas nas subseções 0 e 0.
6.4 Entrevistas baseadas em artefatos
As entrevistas com os alunos do IFSP foram realizadas nos dias 03 e
04/06/2013, na ocasião da entrega do projeto final, a implementação do jogo
Pacman. No Chile, as perguntas foram respondidas pelos alunos por meio de um
questionário em uma página web58, mediante solicitação do professor, na semana
do dia 23/09/2013, cerca de duas semanas após a entrega do projeto final.
Foram realizadas 21 entrevistas no Brasil, 11 na Turma A e 10 na Turma B.
Seguindo a abordagem da entrevista baseada em artefatos (BRENNAN; RESNICK,
2012), a apresentação do projeto foi o elemento direcionador das entrevistas
realizadas, e cada dupla de alunos que trabalhou conjuntamente participou de uma
mesma entrevista. No Chile, apesar de não ter sido possível utilizar essa
abordagem, cada dupla de alunos respondeu conjuntamente às questões durante
uma aula de laboratório. No total, foram obtidas 16 respostas às questões. A análise
das respostas informadas pelos alunos foi feita utilizando-se a técnica de análise de
58
Google Docs, atualmente denominado Google Drive (http://drive.google.com)
193
conteúdo, segundo as diretrizes descritas por Moraes (1999). As unidades de
análise foram definidas a partir da segmentação das frases escritas pelos alunos e
identificação de palavras-chave em cada segmento. A interpretação e o
agrupamento das unidades de análise produziram as categorias de análise que
serão apresentadas nas tabelas desta seção.
A análise das respostas à questão “Você usou alguma matemática para
implementar os fantasmas?” resultou nas categorias de análise apresentadas na
Tabela 22. Para facilitar a discussão posterior, as ocorrências das unidades de
análise foram segmentadas pela turma do respondente no IFSP.
Tabela 22 – Categorias de análise para a questão “Você usou alguma matemática para
implementar os fantasmas?”
Categoria de análise
Brasil - IFSP
Turma A
Turma B
Chile - UV
Divisão inteira
5
1
4
Coordenadas x e y
3
7
2
Outros conceitos
4
1
1
Conceito matemático utilizado não claro
2
1
4
Não utilizei matemática
1
4
1
É necessário ressaltar que quatro grupos de alunos chilenos não
responderam a essa questão, informando que não conseguiram implementar os
fantasmas em seu jogo. A maioria dos alunos que consegue identificar o uso de
conceitos matemáticos na construção dos fantasmas cita um ou, no máximo dois
tópicos.
Considerando essa tendência, é possível notar que os alunos da Turma A do
IFSP tende a mencionar com maior frequência o conceito de divisão inteira. Ocorrem
menções como a de Caio (P21), que afirma sobre o fantasma: “É, pra fazer ele virar
aqui, tem que ser múltiplo de 16”. Jéssica (P16) reconhece: “no caso do [fantasma]
vermelho, usei a divisão, uma operação matemática”. Já os alunos da Turma B
mencionam com maior frequência o uso das coordenadas dos sprites como o
conceito utilizado. Muitos dos alunos dessa turma afirmam, como Rafael (P29), que
utilizaram “só a comparação de x e y em relação ao Pacman”, fazendo menção à
estratégia sugerida pelo professor da turma para resolver o problema (vide subseção
194
0). Da mesma forma, a ênfase dada à movimentação do fantasma na grade, pelo
professor da Turma A, também parece ter influenciado a resposta aos alunos
daquela turma. Esse fenômeno será discutido em maiores detalhes na subseção 0.
Todas as menções feitas à divisão inteira pelos alunos chilenos utilizam o
termo “mod”, nome dado ao operador que calcula o resto da divisão inteira em
muitas linguagens de programação. Como exemplo, citamos a fala de Jorge (P59),
que menciona: “Se utilizó el mod 16=0 para el movimiento de los fantasmas como
también el del pacman”. Essa é muito provavelmente uma influência das atividades
regulares da disciplina de Fundamentos de Programação, que é simultaneamente
acompanhada pelos alunos.
A categoria “Outros conceitos” inclui as menções de poucos alunos que
identificaram de forma mais ampla a utilização de conceitos matemáticos na
construção do jogo, como é possível ver na fala de Denise (P9) e Isabel (P20):
[Isabel]
Sim, primeiro a divisão por 16, os múltiplos de 16, para pegar
a encruzilhada... A gente usou maior e menor, pra achar a menor
distância...
[Denise]
A condição pro Pacman se mover... Os pontos, pro pacman
morrer, quando toca diminui em um, você come um negócio e aumenta um
ponto...
[Isabel]
Esse aqui, que a gente fez com o “deslize” [fantasma
patrulhador]... A gente usou matemática também, as posições x e y, as
coordenadas... Acho que foi isso.
As alunas reconhecem em suas falas o uso do conceito de desigualdade e,
de forma rudimentar, mencionam a ideia de variáveis para controle de vidas e
pontuação do jogo. Houve também menções, embora poucas (uma na Turma A e
uma na Turma B), à utilização do conceito de velocidade para construir um dos
fantasmas. Pedro (P31) afirmou em sua resposta: “Eu usei [conceitos matemáticos]
na rota do fantasma de região fixa para calcular o tempo necessário para deslizar de
um ponto ao outro”. Apenas uma menção foi feita ao conceito do ângulo de
orientação do sprite do fantasma, embora ele seja extensivamente utilizado no
algoritmo para direcionar o personagem.
A próxima questão foi: “O que você achou mais difícil de implementar no
jogo?”. As respostas a esta questão refletem a dificuldade em implementar os
fantasmas inimigos, já descrita na observação etnográfica (subseção 0): 17
195
respostas dos alunos brasileiros (70,8% do total) mencionaram que o fantasma que
persegue o Pacman foi a funcionalidade mais difícil; 3 respostas (12,5%)
mencionaram a movimentação do Pacman e a colisão com as paredes do labirinto
como a funcionalidade mais difícil; 4 respostas (16,7%) mencionaram outros fatores.
No Chile, a implementação dos fantasmas, sem menção ao tipo, foi citada em 9
respostas (56,2% do total); a movimentação do Pacman e a colisão com as paredes
do labirinto foi mencionado em 6 respostas (37,5%); 1 resposta (6,3%) não
mencionou nenhuma dificuldade.
A última questão perguntava: “O que você incluiria em uma segunda versão
do jogo para torná-lo mais interessante, se tivesse mais tempo?”. Em sua análise,
utilizou-se novamente a análise de conteúdo; adicionalmente, continuando a análise
relacionada aos aspectos de jogabilidade apresentada na seção 0, a cada categoria
de análise foram associadas uma ou mais heurísticas de jogabilidade59 (BARCELOS
et al., 2011) que foram também utilizadas no levantamento do perfil dos alunos
(seção 0). O resultado da análise e da associação das heurísticas é apresentado na
Tabela 23.
Tabela 23 – Intenção dos alunos de acrescentar funcionalidades no jogo Pacman e
heurísticas associadas
Categorias de análise
Brasil – IFSP
Chile – UV
Heurísticas associadas
Mais níveis de dificuldade
8
6
H14; H16
Atribuir poderes ao Pacman
7
5
H14; H16; H17
Atribuir poderes aos inimigos
7
0
H14; H16
Acrescentar recompensas
5
5
H17
Criar os fantasmas
0
5
H14
4
H10
2
H14
Modificar estética do jogo
Acrescentar controle de vidas
0
O acréscimo de mais níveis de dificuldade do jogo é a categoria que
corresponde ao maior número de menções dos alunos de ambos os países. As
ideias descritas pelos alunos incluem o aumento da dificuldade em níveis
subsequentes, aumentando a velocidade (ou quantidade) dos fantasmas ou
59
Vide Tabela 12 para a enumeração das heurísticas.
196
mudando a geometria do labirinto. Portanto, essa categoria de análise foi associada
às heurísticas H14 – O jogo deve possuir vários desafios e permitir diferentes
estratégias e H16 – O desafio do jogo pode ser ajustado de acordo com a habilidade
do jogador.
A categoria de análise Atribuir poderes ao Pacman agrupa sugestões
principalmente relacionadas a uma funcionalidade do jogo real: as “pílulas de poder”,
os pontos brancos que podem ser comidos pelo Pacman e que lhe dão o poder
temporário de comer os fantasmas e somar pontos extras. Houve inclusive duas
menções de grupos que comentaram sobre seus planos para efetivamente adicionar
essa funcionalidade. Lucas (P4) afirmou como isso aconteceu:
[Lucas]
Eu consegui fazer, quando tocava nos pontos ele [o
fantasma] ficava brilhando. Só que aí quando eu mexi um monte de coisa
deu errado, e aí eu apaguei e tive que fazer de novo [...] Mas era assim,
quando comia a pílula, ele ficava brilhando, aí quando tocava naquela cor,
ele trocava de traje... Mas aí ele não voltava mais pra tela.
Essa categoria foi também associada às heurísticas H14 e H16, pois o
acréscimo de poderes ao Pacman se constituiria como uma estratégia para atingir
os objetivos do jogo para um jogador que tivesse a habilidade de obter esse poder.
Também foi associado à heurística H17 - O jogador deve ser recompensado pelas
suas conquistas de forma clara e imediata, pelo aspecto relacionado à bonificação
que o poder adicional do Pacman traz.
Na categoria de análise Atribuir poderes aos inimigos foram agrupadas as
menções ao aumento de habilidades dos fantasmas inimigos. Essas menções foram
feitas apenas pelos alunos do Brasil; apesar de estarem fortemente relacionadas à
categoria Mais níveis de dificuldade, tais menções não foram feitas pelos alunos de
forma associada aos níveis do jogo. As ideias citadas incluem ter mais fantasmas no
jogo (já que a tarefa solicitava a criação de apenas dois fantasmas), que os
fantasmas fossem mais rápidos e que houvesse um “fantasma-chefe”. Essa
categoria também foi associada às heurísticas H14 e H16.
Outra categoria em que as menções dos alunos têm relação com o projeto do
jogo original foi Acrescentar recompensas. Aqui foi citada, principalmente, a ideia de
acrescentar as “frutinhas” que aparecem esporadicamente no jogo original e que
197
oferecem uma pontuação adicional quando comida pelo Pacman. Essa categoria foi
associada à heurística H17.
Provavelmente devido ao menor tempo disponível para os alunos do Chile,
algumas intenções de melhorias no jogo foram citadas somente por esses alunos. É
o caso das categorias Criar os fantasmas, agrupando as menções de alunos que,
muito provavelmente, não conseguiram implementar os fantasmas ou não ficaram
satisfeitos com sua implementação, e Acrescentar controle de vidas. Vale mencionar
que o acréscimo de um controle de vidas foi uma das funcionalidades adicionais
presente com alguma frequência em jogos dos alunos do Brasil e do Chile60.
6.5 Pré e pós-teste de conhecimentos matemáticos
O pré-teste foi aplicado aos alunos brasileiros do IFSP na primeira semana de
aulas, em fevereiro de 2013, e em março de 2013 aos alunos chilenos da UV.
Naquela ocasião, 29 alunos fizeram o teste no Brasil e 71 alunos fizeram o teste no
Chile, o que corresponde a todos os alunos matriculados na disciplina de
Fundamentos de Programação daquela universidade. O pós-teste foi aplicado aos
alunos no último encontro da Oficina, que aconteceu em junho de 2013 no Brasil e
apenas em outubro de 2013 no Chile, devido à paralisação dos alunos. Nessa
ocasião, 33 alunos no Brasil e 25 alunos no Chile fizeram o teste. Nesta segunda
ocasião, o teste foi aplicado na UV apenas aos alunos que estavam frequentando a
Oficina, lembrando que ela foi oferecida naquela universidade como uma atividade
extraclasse.
60
Vide Tabela 19 na subseção 0.
198
Como o objetivo do quase experimento que utiliza o teste como instrumento
de coleta é identificar possíveis variações nos conhecimentos matemáticos ou no
processo de resolução de problemas, esta análise levará em consideração apenas
os alunos que fizeram ambos os testes, o que corresponde a uma amostra de 24
alunos no IFSP e 25 alunos na UV. Na Figura 73 são apresentados os percentuais
de respostas corretas a cada questão no pré e no pós-teste; as estatísticas
completas de respostas dos alunos podem ser encontradas no Apêndice E.
Brasil - IFSP
100%
90%
80%
70%
60%
50%
Pré-teste
40%
Pós-teste
30%
20%
10%
0%
Q1 - Expressões
algébricas e
identificação de
padrões
Q2 - Ângulo
replementar
Q3 Porcentagem
Q4 Coordenadas
cartesianas
Q5 - Identificação Q6 - Distância
de pontos no
entre pontos no
plano
plano
Q7 - Divisão
inteira
Q8 - Raciocínio
combinatório
Chile - UV
100%
90%
80%
70%
60%
50%
Pré-teste
40%
Pós-teste
30%
20%
10%
0%
Q1 - Expressões
algébricas e
identificação de
padrões
Q2 - Ângulo
replementar
Q3 Porcentagem
Q4 Coordenadas
cartesianas
Q5 - Identificação Q6 - Distância
de pontos no
entre pontos no
plano
plano
Q7 - Divisão
inteira
Q8 - Raciocínio
combinatório
Figura 73 – Porcentagens de respostas corretas às questões do pré e pós-teste
É possível identificar que os tópicos matemáticos que, aparentemente, os
alunos tem maior dificuldade em mobilizar nas questões são a distância entre pontos
no plano (questão 6), a divisão inteira (questão 7) e o raciocínio combinatório
(questão 8). Dentre as questões que envolvem estes tópicos, a questão 8, que
199
envolve o raciocínio combinatório, parece ser aquela em que se nota pouca ou
nenhuma diferença entre os resultados antes e após a Oficina. Nos alunos chilenos,
há uma sensível melhora nos acertos na questão 7, que envolve a divisão inteira;
em ambos os grupos, há alguma melhora nos acertos na questão 6, que envolve a
distância entre pontos no plano.
Nas demais questões, envolvendo tópicos em que os alunos já haviam obtido
mais de 80% de respostas corretas no pré-teste, destaca-se uma melhora na
questão 1, relativa à construção de uma expressão algébrica representando um
padrão, e na questão 4, envolvendo a identificação da posição final de um ponto
após uma sequência de mudanças de posição nos eixos x e y, descritas em uma
linguagem similar à utilizada no Scratch. Surpreendentemente, encontrou-se uma
significativa variabilidade negativa nas respostas à questão 2 dadas pelos alunos
chilenos, referente à identificação do ângulo replementar; é possível verificar que a
diminuição no índice de acertos deve-se a uma maior proporção de alunos que não
respondeu à questão no pós-teste. Após um contato feito com o professor local,
acredita-se que isso pode estar relacionado ao tempo limitado para responder ao
pós-teste, devido à finalização do semestre.
Considerando a quantidade de respostas corretas obtidas por um aluno no
pré-teste como uma variável aleatória , e a mesma quantidade de respostas
obtidas pelo aluno no pós-teste como , utilizou-se um teste t de Student para
diferenças entre variáveis dependentes com as variáveis e testando-se
a hipótese nula − = 0, ou seja, que o valor esperado da variável
Xdepois – Xantes é 0; em outras palavras, que não há diferença entre a quantidade de
acertos no pré e no pós-teste.
No nível de significância de 5%, considerando os dados dos alunos do Brasil,
a hipótese nula é rejeitada (t = -2,38689, p < 0,03). A média amostral é igual a
5,17 questões, enquanto que a média amostral é igual a 5,92. Considerando
os dados dos alunos do Chile, a hipótese nula também é rejeitada (t = -2,29528, p <
0,04). Para essa amostra, a média amostral é igual a 6,16 e a média amostral
é igual a 6,64. Assim, globalmente constata-se uma pequena melhora no
desempenho dos alunos, que parece ser mais acentuada em alguns tópicos, porém
200
insignificante em outros. Uma discussão desse fenômeno frente aos achados dos
demais instrumentos de pesquisa será feita a seguir.
6.6 Discussão
6.6.1 Mobilização de conteúdos matemáticos
Analisar a mobilização de conteúdos da Matemática pelos alunos da Oficina
relaciona-se à compreensão de como os conhecimentos prévios dos alunos podem
influenciar o desenvolvimento de competências e habilidades do Pensamento
Computacional, objetivo descrito na questão de pesquisa Q1. Ainda, pretende-se
compreender como e se os alunos, de alguma forma, modificam as suas
competências e habilidades relacionadas à Matemática, objetivo descrito na questão
de pesquisa Q4. Nesta subseção, iniciamos nossa análise pelos conteúdos
matemáticos; uma discussão das competências comuns entre o Pensamento
Computacional e a Matemática será descrita na próxima seção.
Em relação aos conteúdos matemáticos, nesta pesquisa é analisado um
subconjunto de conteúdos que foram mapeados no momento do projeto da Oficina
de Produção de Jogos Digitais. Evidentemente, esta pesquisa não tem o objetivo de
analisar exaustivamente as relações entre conteúdos matemáticos e conteúdos do
Pensamento Computacional, senão compreender como que, em um contexto real de
aprendizagem, o desenvolvimento de competências e habilidades relacionadas à
programação de computadores é influenciado pelo nível de conhecimentos prévios
dos alunos sobre alguns tópicos matemáticos.
Talvez a dificuldade mais visível dos alunos relacionada a um tópico
matemático relacionou-se ao raciocínio combinatório, avaliado por meio da questão
8 do teste. A carência no ensino de tópicos de Matemática Discreta no ensino
básico, como a combinatória, e seu impacto na contextualização de tópicos da
Ciência da Computação para esse público já havia sido apontada por Henderson,
Letvin e Litvin (2007). A comparação dos resultados do pré-teste e do pós-teste
mostra que não houve diferença notável entre os resultados antes e após a
participação da Oficina. Em paralelo, na observação etnográfica foi possível
identificar momentos nos quais a identificação e enumeração de todas as possíveis
201
configurações de jogo que deveriam ser tratadas pelo código foram fonte de muitas
dificuldades para os alunos. Isso aconteceu em dois momentos: na identificação de
todas as possíveis jogadas do jogo Pedra, Papel e Tesoura para exibir a mensagem
de vitória ou empate (subseção 0) e na identificação das direções de movimentação
do Pacman e as situações de colisão que poderiam impedir o seu deslocamento
(subseção 0). Em ambos os casos, os alunos parecem se deparar com situaçõesproblema que exigem o raciocínio sobre algo semelhante a uma “probabilidade
condicional” – ou seja, identificar quais são os possíveis eventos subsequentes que
pode ocorrer, dada a ocorrência de um evento inicial.
Na construção do jogo Pedra, Papel e Tesoura, os alunos da turma A do IFSP
lidaram de forma mais direta com a existência de eventos condicionais devido à
estratégia de construção que adotaram, pela orientação do professor da turma:
separar o código de identificação do resultado final do jogo no tratamento dos
eventos de pressionamento de cada uma das teclas vinculadas ao sprite de um dos
jogadores. Já os alunos da turma B, que optaram por enumerar de uma só vez todas
as possibilidades de resultados finais do jogo no código vinculado ao fundo da tela,
aparentemente foram menos afetados por essa dificuldade.
A questão a ser respondida em papel pelos alunos: “quais são as possíveis
configurações finais do jogo?” apresentava em um formato “tradicional”, o problema
matemático com o qual os alunos iriam se deparar na construção do jogo. Aí
também foi identificada uma diferença de postura entre os professores, que parece
ter influenciado os resultados. Os dois professores brasileiros permitiram que os
alunos cumprissem as tarefas da aula em qualquer ordem, e muitos preferiram
iniciar pela construção do jogo e só depois responder a questão. Isso resultou em
um percentual considerável de respostas corretas (cerca de 75% dos alunos) e que
denotam o uso de um procedimento sistemático para enumerar as possibilidades.
No Chile, o professor responsável pela Oficina na UV explicitamente orientou que os
alunos respondessem à questão antes de iniciar o trabalho no computador, e o que
se viu foi uma maior quantidade de respostas incorretas (cerca de 54% dos alunos),
ainda que muitos tenham tentado sistematizar a obtenção das possibilidades. É
necessário considerar que os dois grupos de alunos (IFSP e UV) apresentaram
resultados similares no pré-teste, no que se refere à questão sobre raciocínio
combinatório; assim, podemos dizer que os alunos brasileiros, ao terem contato com
202
a experimentação trazida pela construção do jogo, em um ambiente colaborativo,
lidaram com o problema matemático de uma forma mais rica, o que pode ter
influenciado as suas posteriores respostas à questão em papel.
No entanto, esse possível enriquecimento da experiência dos alunos com o
problema não pareceu ser, ainda, transferível para outras situações. Isso pode ser
constatado no pós-teste, no qual não houve melhora perceptível nos resultados dos
alunos referentes ao raciocínio combinatório. Antes disso, o problema dos “eventos
condicionais” pôde ser identificado novamente na construção do jogo Pacman.
Nessa atividade, o controle da mudança de direção do personagem principal
dependia do valor de uma dentre quatro variáveis indicadoras da colisão do Pacman
com as paredes, em função da direção desejada. A dificuldade de identificar essa
dependência foi expressa por vários alunos61 do IFSP (seção 0) e por. Na UV, os
resultados da entrevista final (seção 0) também mostram que a segunda
funcionalidade mencionada como sendo fonte das maiores dificuldades para os
alunos foi a movimentação do Pacman e a colisão com as paredes do labirinto. Nas
respostas dos alunos foi possível identificar diretamente a menção a “los sensores”,
ou seja, as variáveis indicadoras de colisão, que assim foram denominadas em
espanhol no material didático de orientação aos professores.
Nesse caso, apesar do episódio com os alunos do IFSP indicar que as tarefas
propostas para a construção dos jogos mobilizaram o raciocínio combinatório dos
alunos, as oportunidades proporcionadas – apenas duas, ao longo de toda a Oficina
– parecem não ter sido suficientes para que os alunos se tornassem mais aptos a
lidar com o problema combinatório apresentado novamente no pós-teste.
A identificação do deslocamento e posicionamento de pontos no plano
cartesiano eram habilidades exploradas, respectivamente, pelas questões 4 e 5 do
teste. A questão 6 explorava o cálculo da distância entre pontos no plano. Houve
uma melhora no desempenho dos alunos de ambos os países nessas questões;
essa melhora pode ser considerada previsível, já que o posicionamento e
deslocamento de sprites exigiu, em vários momentos, o reconhecimento da sua
posição no plano e o controle do seu deslocamento. Essas habilidades foram
mobilizadas, direta ou indiretamente, nas seguintes tarefas:
61
Vide o relato de Lucas (P4), descrito naquela seção.
203
•
Posicionamento dos peixes no jogo de Pescaria (subseção 0);
•
Animação das “mãos” que representam os jogadores no jogo Pedra, Papel e
Tesoura (subseção 0);
•
Posicionamento do tanque inimigo em uma posição aleatória ao longo dos
eixos x e y (subseção 0);
•
Controle da perda da bola no jogo Arkanoid (seção 0);
•
Controle da movimentação do personagem principal e dos fantasmas no jogo
Pacman (subseção 0).
No entanto, apesar de tais tarefas demandarem a identificação da posição e
deslocamento dos sprites no plano, em alguns momentos foi possível identificar que
os alunos preferiram utilizar recursos do próprio ambiente do Scratch para evitar o
uso do conceito matemático. Como vimos na subseção 0, nas duas últimas tarefas
enumeradas acima (controle da bola no Arkanoid e controle da movimentação do
Pacman e dos fantasmas), a estratégia preferida pela maioria dos alunos foi a
identificação do posicionamento dos sprites por meio da colisão com outros sprites,
posicionados na posição que se desejava identificar. No caso do Arkanoid, a posição
para perda da bola; no caso do Pacman, a posição do túnel que permitia o
“teletransporte” do Pacman para a extremidade do túnel oposto.
Essas estratégias por vezes exigiam um controle mais complexo do código
dos jogos em questão. Então, por que muitos alunos teriam optado por essa solução
mais trabalhosa? Uma possível explicação é que o posicionamento de um sprite na
posição desejada é uma operação predominantemente visual, que não demanda
uma abstração de nível mais alto sobre as coordenadas cartesianas do sprite. Essa
operação corresponde ao nível visual, o primeiro e menos sofisticado dos três níveis
de raciocínio geométrico na taxonomia de Van Hiele (JONES, 2002). Esse fenômeno
foi identificado nos alunos do IFSP e da UV. No primeiro caso, por estarem, em sua
maioria, cursando o segundo ano do Ensino Médio, seria esperado que ainda não
tivessem contato com tais conceitos no ensino regular; no entanto, isso não se
justifica no caso dos alunos da UV, recém-egressos do ensino médio chileno. Essa
constatação se alinha com a discussão feita por Confrey et al. (2010), que apontam
que a forma com a qual o conceito matemático é apresentado (ou tornado oculto)
em uma ferramenta de software pode afetar a apropriação do conceito pelos alunos,
204
em função da forma de interação com a ferramenta que é proposta pela sua
interface. A melhora dos resultados do pós-teste e, em contraposição, a utilização de
recursos do Scratch para evitar o uso de coordenadas cartesianas, indica que
mesmo havendo um maior domínio do conceito matemático, os alunos preferem
usar um recurso mais “concreto” e visual – a colisão entre sprites – quando a
circunstância e os recursos do ambiente de programação assim o permitem.
Em uma das últimas tarefas da Oficina, a construção do fantasma que deveria
perseguir o Pacman, essa limitação da abstração geométrica dos alunos para o
cálculo de distâncias no plano ficou clara. No caso da turma A do IFSP (sob
responsabilidade do autor desta tese), a partir da identificação preliminar do uso dos
sprites como um recurso “encapsulado” pelos alunos, foi proposta a alternativa de
implementação ilustrada anteriormente na Figura 56, utilizando quatro sprites e o
cálculo de distância por meio da função “distância para” do Scratch. Tal estratégia foi
compreendida e aceita mais facilmente pelos alunos, dadas as limitações de tempo
para a finalização da Oficina, apesar de não mobilizar explicitamente o conceito
matemático desejado. No entanto, cabe lembrar que, em seu contexto de aplicação
(e nos objetivos desta pesquisa) a proposta da Oficina não era introduzir novos
conceitos matemáticos, e sim identificar como eles seriam (ou não) utilizados pelos
alunos. De toda forma, o problema proposto pela construção do jogo criou uma
oportunidade para que, em uma circunstância diferente de tempo e objetivos da
Oficina, fossem criadas oportunidades pelo professor de direcionar os alunos em
sua Zona de Desenvolvimento Proximal para construírem seu próprio conceito da
distância entre pontos no plano, bem como para efetuassem os procedimentos
operacionais para seu cálculo. Exemplificando, uma forma do professor evitar os
“atalhos” proporcionados pelo Scratch seria propor: “E se agora formos calcular a
distância do fantasma para o Pacman sem usar a função ‘distância para’?”.
Curiosamente, mesmo que a distância entre pontos no plano não tenha sido
mobilizada da forma esperada, houve uma sensível melhora nos índices de acerto
da questão 6 do pós-teste (de 42,9% para 66,7% no Brasil e de 36% para 60% no
Chile), o que parece ser evidência de que os alunos passaram a identificar as
particularidades e o posicionamento dos pontos e de que foram capazes de, ao
menos, estimar uma resposta correta.
205
Outro tópico matemático cuja mobilização foi limitada pelo andamento das
atividades e pelos recursos da ferramenta foi o conceito de ângulo replementar,
avaliada na questão 2 do teste e que deveria ser utilizado no jogo Arkanoid para o
cálculo da reflexão da bola na plataforma e nos blocos (subseção 0). Essa atividade
foi desenvolvida apenas no IFSP, então infelizmente não foi possível contar com o
parâmetro de comparação dos alunos da UV, egressos do ensino médio e que
provavelmente já haviam exercitado esse conceito com o auxílio do círculo
trigonométrico (deve-se notar que 100% dos alunos chilenos acertaram a questão no
pré-teste). No caso do IFSP, a falta de experiência dos alunos com a trigonometria,
aliada à uma característica do Scratch descrita na subseção 0, que permite
quaisquer valores inteiros como ângulos válidos, levou à uma implementação
meramente “mecânica” da funcionalidade de reflexão da bola pelos alunos. De toda
forma, neste caso foi criada outra oportunidade para construir o conceito matemático
que poderia ser aproveitada em outras circunstâncias.
Discutimos agora um dos primeiros conteúdos matemáticos que foi
diretamente mobilizado pelos alunos: o cálculo de porcentagens, no jogo de
Pescaria. No registro da observação etnográfica (subseção 0) foi possível constatar
que o cálculo do percentual de peixes de cada tipo que foi clicado pelo jogador foi
alvo de várias dúvidas, tanto no Brasil quanto no Chile. Os índices de acerto da
questão 3 do pré-teste, relacionada ao cálculo de uma porcentagem, foram
relativamente altos; porém, deve-se levar em consideração que a questão
mobilizava a aplicação do conceito de porcentagem com valores numéricos. O
raciocínio para o cálculo da porcentagem no jogo envolvia uma abstração adicional,
já que o total de cliques em um peixe estava armazenado em uma variável. O total
de aparições de cada peixe era uma quantidade a ser definida pela quantidade de
repetições do código, a cargo do aluno. Essa quantidade deveria ser considerada
como o denominador da proporção a ser calculada62. Porém, em muitos casos os
alunos pretendiam utilizar de forma incorreta uma variável já definida no código, o
total de pontos, no cálculo da proporção. A discrepância entre a quantidade de
acertos (relativamente alta) no pré-teste e no pós-teste e as ações dos alunos para
mobilizar esse conceito na construção do jogo pode revelar uma dificuldade em
62
Para um exemplo desse cálculo, vide Figura 38.
206
generalizar um registro algébrico de um cálculo aritmético que por sua vez,
aparentemente, era dominado por muitos alunos.
No entanto, essa dificuldade dos alunos foi apresentada em uma atividade
que ocorreu apenas na segunda semana da Oficina, e contrasta com os resultados
obtidos na primeira questão do teste, que procura avaliar a identificação pelos
alunos do padrão de uma sequência numérica e a posterior dedução da expressão
algébrica que define o número de elementos a cada passo da sequência. Essa
questão apresentou uma razoável melhora no número de acertos (de 66,7% para
83,3% no Brasil, de 88% para 93% no Chile). Essa melhora denota que, ao final da
Oficina,
mais
alunos
conseguiram
mobilizar
competências
relacionadas
à
identificação de um padrão – temos aí uma das competências comuns ao
Pensamento Computacional e à Matemática, propostas na seção 0. Na subseção 0
o desenvolvimento de tais competências será discutido em maiores detalhes.
6.6.2 Pensamento Computacional e a construção de jogos
A Oficina de Produção de Jogos Digitais foi inicialmente desenvolvida em um
contexto bem específico, descrito nas subseções 0 e 0: ensinar os princípios da
programação estruturada de computadores a ingressantes em cursos técnicos e
superiores em Computação. Tais princípios de programação estão presentes em um
dos objetivos da categoria Computer Practice and Programming do currículo de
referência da CSTA (CSTA, 2011). Considerando essa informação e, ainda, que a
utilização de um ambiente como o Scratch, com um “chão baixo”63 do ponto de vista
conceitual, permite a exploração de conceitos computacionais relacionados à
programação de computadores sem que os alunos tenham que lidar com muitos
detalhes técnicos e de sintaxe, é possível afirmar que a Oficina é viável como um
ambiente de desenvolvimento de algumas competências e habilidades do
Pensamento Computacional.
O oferecimento inicial da Oficina a jovens ingressantes no ensino técnico no
Brasil e no ensino superior no Chile permitiu identificar algumas características
desse público bastante alinhadas à proposta de construção de jogos digitais. Os
participantes seriam, supostamente, pertencentes à geração de “nativos digitais”
63
Vide seção 0.
207
(PRENSKY, 2001); isso foi parcialmente confirmado com a identificação do perfil dos
alunos (seção 0) enquanto jogadores. Eles não apenas fazem uso de jogos digitais
com uma frequência semanal que vai de moderada (5 a 15 horas por semana) a alta
(mais de 15 horas por semana) como também jogam há bastante tempo, apesar de
sua pouca idade: pelo menos 65% deles jogam há mais de três anos. Esse
percentual é ainda mais alto entre os alunos chilenos, mais velhos.
Na observação etnográfica (seção 0), foi possível observar em vários
momentos que as situações-problema enfrentadas pelos alunos são, antes de tudo,
descritas na linguagem do jogo. Para maior clareza, agrupamos e selecionamos aqui
algumas falas dos alunos:
“E como a gente faz para acabar o jogo?” – Caio (P21), na verdade se
referindo à condição de parada do laço de repetição do jogo de Pescaria (seção 0);
“Mas aí o valor fica aparecendo, eu vou saber a resposta, né?” – Lucas (P4),
se referindo à exibição do valor da variável do valor sorteado no jogo de Adivinhação
(seção 0), impedindo que o jogador tenha que adivinhar o número;
“[...] aqui vai ter um problema de jogabilidade [...]” – Lucas novamente, se
referindo à falta de sincronismo entre as jogadas no jogo Pedra, Papel e Tesoura
(seção 0);
“Eu ia acrescentar um fantasma ‘chefão’... Ou mudar o level, que nem no
Mario, deixar mais rápido ia ser legal” – Diana (P10), na entrevista, se referenciando
às funcionalidades que gostaria de adicionar no Pacman;
“No pudimos implementar esta parte del juego pues se ‘bugueaba’ (sic)” –
Lucio (P61), na entrevista, referindo-se à dificuldade de implementar os fantasmas
no jogo Pacman.
Essa familiaridade dos alunos com o problema a ser resolvido e com a
linguagem referente a ele parece contribuir com o desenvolvimento da fluência em
jogo proposta por Peppler e Kafai (2009). Contribui para esse achado o fato que
todas as tarefas da Oficina envolviam, direta ou indiretamente, a construção de
mecânicas de um jogo real (diretriz (4), seção 0), em todas as atividades (diretriz (1),
seção 0). A motivação dos alunos, procurando soluções ou alternativas mesmo em
208
atividades consideradas difíceis por eles, é uma evidência da adequação dessa
estratégia ao público participante da Oficina.
A estruturação das atividades organizava os conceitos de programação em
uma sequência progressiva de atividades (diretriz (3), seção 0), na qual um mesmo
conceito seria explorado sucessivas vezes pelo aluno. Na perspectiva da
Aprendizagem Baseada em Problemas, essa utilização de um conceito estava
sempre implícita em alguma das funcionalidades que os alunos deveriam construir.
Ainda, ao iniciar a construção do seu jogo (ou o uso do jogo inicialmente
disponibilizado), o aluno interage com esse protótipo inicial, analisa possíveis
soluções para os próximos passos e, eventualmente, altera seus planos em função
de alguma constatação que surge ao interagir com o protótipo. Essa sequência de
ações, induzida muitas vezes pela estruturação da atividade, engaja os alunos em
um processo de reflexão-em-ação (SCHÖN; BENNETT, 1996), inerente ao processo
de design de artefatos interativos (WINOGRAD, 1996).
Em alguns casos, as decisões tomadas pelos alunos ao longo das sucessivas
tarefas da Oficina levaram a uma mobilização espontânea de um conceito; é o caso
do uso de estruturas de repetição para implementar a movimentação do fantasma
que patrulhava uma região fixa no Pacman (vide análise da seção 0 – Conceitos de
programação). Em outras situações, o apoio do professor se mostrou fundamental
para que os alunos pudessem entrar na Zona de Desenvolvimento Proximal; é o
caso da construção do jogo Simulação de Guerra, algumas semanas antes, quando
os alunos tentaram usar um comando atômico (“deslize”), sem sucesso,
impossibilitando a verificação da colisão entre sprites, ao invés de uma estrutura de
repetição (vide descrição da atividade na subseção 0).
Há um aspecto relevante em exemplificar a importância da estruturação das
atividades com a mobilização, pelos alunos, do conceito de repetição. Afinal, trata-se
de uma das maiores dificuldades para o aluno principiante em programação (SETTI,
2009; GINAT, 2004). Porém, também foram registradas evidências da retomada do
uso do conceito de variável, após decorridas algumas atividades; o suporte do
professor para a identificação do conceito pelos alunos também se mostrou
necessário nesse caso. Esse achado é consonante com o estudo de Maloney et al.
(2008), que identificam que o uso de variáveis não é determinante para produzir
209
aplicações interativas com relativa sofisticação no Scratch64. Uma evidência notável
pôde ser encontrada durante a construção do jogo Simulação de Guerra (subseção
0), quando ocorreu o episódio em que Caio (P21) deseja adicionar um controle da
quantidade de vidas ao jogo, mas não associa essa funcionalidade ao uso de
variáveis65. Outra necessidade apareceu durante a construção do jogo Arkanoid
(subseção 0), quando alunos questionavam como fazer com que o jogo iniciasse
com três vidas, e como controlar a quantidade de colisões com um dos blocos antes
que ele se desintegrasse.
Por outro lado, foi possível constatar que os alunos foram capazes de lidar
com conceitos computacionais que usualmente são tidos como avançados. É o caso
do trabalho de programação com paralelismo e sincronização, e a dedução de um
algoritmo de divisão e conquista. O conceito de paralelismo é necessário pela
própria estrutura do Scratch, onde cada bloco de comandos funciona como uma
linha de execução (thread) separada dentro de um mesmo processo. A comunicação
eficaz entre o código de dois ou mais sprites pode ser feita unicamente por meio do
envio de mensagens. Dessa forma, nos jogos em que era necessário o controle de
vários sprites (Pedra, Papel e Tesoura, Simulação de Guerra, Arkanoid e Pacman) o
uso de mensagens surgiu naturalmente, e por isso o conceito foi introduzido aos
alunos desde a atividade de construção do jogo Pedra, Papel e Tesoura (subseção
0). Desde antes do momento em que o conceito seria introduzido, alunos já
apontavam para limitações dos jogos que necessitavam de sincronização entre
threads para serem resolvidos. É o caso da sincronização entre as jogadas dos dois
jogadores, apontada por Lucas (P4) e Fabrício (P14) nos primeiros momentos da
construção do jogo Pedra, Papel e Tesoura. No encontro da Oficina no Chile
dedicado ao desenvolvimento dessa mesma atividade temos o questionamento dos
alunos sobre a mensagem de vitória ficar aparecendo o tempo todo na tela e a
posterior orientação do professor para o uso de mensagens.
No Brasil, também ocorreu o episódio da discussão dos alunos vinculada à
questão que perguntava qual seria uma “boa” estratégia para acertar o número no
64
Vide subseção 0.
Aqui identifica-se uma interessante coincidência com um episódio descrito por Resnick et
al. (2009) no qual um adolescente do centro comunitário agradece efusivamente a um dos
pesquisadores que apresentou a ele como o uso de variáveis permitiria o controle de pontuação do
jogo que ele estava desenvolvendo.
65
210
Jogo de Advinhação (subseção 0), no sentido de minimizar o número de passos
necessários. Houve casos de alunos como Jéssica (P16), que conseguiram chegar
muito próximo de um algoritmo ótimo baseado em divisão e conquista, e episódios
de alunos como Breno (P7) que, mesmo com dificuldades iniciais, também
chegaram ao mesmo algoritmo com o suporte do professor. Uma diferença pôde ser
observada nesse ponto, em relação aos alunos chilenos: em uma das entrevistas de
acompanhamento, o professor responsável esclareceu que não foi dada muita
ênfase (ou tempo) para que os alunos respondessem a essa questão; o resultado foi
que apenas três alunos indicaram em suas respostas um algoritmo de divisão e
conquista. Além da evidente questão do tempo disponível, esse episódio reforça a
importância do suporte do professor para o desenvolvimento de competências e
habilidades do Pensamento Computacional.
O registro etnográfico das atividades de aula não é isento; no caso desta
pesquisa, os professores das turmas assumem o papel de etnógrafos e, como em
toda pesquisa dessa modalidade, a influência do pesquisador sobre o meio, e deste
sobre o pesquisador é inevitável e deve ser reconhecida (LATORRE; DEL RINCÓN;
ARNAL, 1996). Dessa forma, é necessário reconhecer que a grande maioria dos
momentos registrados refere-se a pedidos de ajuda da parte dos alunos para
resolver algum problema nos jogos que desenvolviam. Nesse sentido, pode-se dizer
que a etnografia como um todo se constitui como uma evidência da necessidade
trazer os alunos para a Zona de Desenvolvimento Proximal em uma série de
situações. Inclusive, em alguns momentos, as diferenças na condução da Oficina
entre os professores resultaram em estratégias diferentes para resolução dos
problemas. É o caso da diferença entre as turmas do Brasil na orientação dada aos
alunos para construir a mensagem de vitória no jogo Pedra, Papel e Tesoura
(subseção 0) e para construir o fantasma perseguidor (subseção 0). Também é o
caso da ordem de realização das atividades – primeiro o exercício em papel, depois
a construção do jogo – sugerida pelo professor da turma do Chile na atividade do
Jogo de Adivinhação (subseção 0), que evidenciou as deficiências no raciocínio
combinatório dos alunos.
Uma influência do construcionismo na Oficina está no caráter público e
compartilhado dos artefatos construídos pelos alunos (HAREL; PAPERT, 1991). Os
processos cognitivos relativos à construção do conhecimento são, igualmente,
211
públicos e compartilhados entre os colegas de uma turma. A influência do aspecto
social da atividade pôde ser identificada desde as primeiras atividades, nas quais a
modificação do aspecto visual do jogo ainda era o único recurso autônomo
dominado pelos alunos, e assim a personalização dos sprites e fundos de tela era
frequente (ver descrição da atividade do Brasil na subseção 0 e do Chile nas
subseções 0 e 0, quando grupos de alunos participam da Oficina pela primeira vez).
Em alguns momentos, o aspecto social da atividade também parece ter contribuído
para que os alunos resolvessem alguns problemas ajudando uns aos outros, sem a
intervenção do professor. É o caso da correção do atraso para um novo disparo da
bala no jogo Simulação de Guerra, descrito na subseção 0, para a qual não se
encontraram registros na observação etnográfica. Em outras situações se observou
a atuação de alunos mais avançados que se dispunham a orientar seus próprios
colegas, em especial nas atividades no Chile, como foi possível constatar no
episódio com Jorge (P59), que ajudou seus colegas no desenvolvimento do Jogo de
Advinhação (subseção 0) e na discussão entre dois alunos sobre as estratégias para
implementar a mensagem de vitória no jogo Pedra, Papel e Tesoura (subseção 0).
6.6.3 Design de interação e funcionalidades adicionais nos jogos
Um aspecto complementar à motivação trazida pela atividade de construção
de jogos digitais está na iniciativa, tomada por vários alunos, de criar funcionalidades
nos jogos que não estavam previstas inicialmente no planejamento das atividades. A
motivação dos alunos para implementar tais funcionalidades parece estar
estreitamente relacionada a aspectos de jogabilidade. Ainda, muitos alunos
implementaram melhorias semelhantes nos seus jogos, o que provavelmente está
relacionado à natureza social da atividade de design, conforme discutido por
Winograd (1996, 1997).
Ao analisar conjuntamente o levantamento do perfil dos alunos enquanto
jogadores (seção 0) e a avaliação heurística das funcionalidades adicionais
implementadas pelos alunos (subseção 0), é possível constatar que a maioria das
funcionalidades adicionais estava relacionada a aspectos de qualidade que os
alunos também consideram como mais relevantes para a sua própria experiência
como jogadores. As funcionalidades adicionais envolveram a exibição de
212
características visuais (H6), em sua maioria relacionadas com o estado de jogo e
pontuação (H3), mas também foi possível identificar características relacionadas
com o tempo de resposta dos controles do jogo (H1), presença de efeitos gráficos e
som (H10) e a possibilidade do jogador enfrentar diferentes desafios (H14).
Ainda considerando as funcionalidades adicionais, na entrevista final, cujos
resultados foram descritos na seção 0, os alunos expressaram o que gostariam de
adicionar no jogo Pacman construído por eles caso tivessem mais tempo.
Evidentemente, nesse caso não é possível avaliar se os alunos estariam aptos a
efetivamente construir as funcionalidades que desejavam, mas sim como realizaram
uma reflexão-em-ação (SCHÖN; BENNETT, 1996) sobre as ações de design que
tomaram ao longo do projeto. Ao compararmos a relevância que os estudantes
atribuem às heurísticas enquanto jogadores com as heurísticas associadas às
funcionalidades que eles gostariam de implementar no Pacman, é possível verificar
que não foram necessariamente reafirmados os aspectos de qualidade que foram
considerados mais relevantes em um primeiro momento. Lembramos que as
funcionalidades mais frequentemente mencionados pelos alunos de ambos os
países foram: mais níveis de dificuldade (heurísticas H14 e H16); atribuir poderes ao
Pacman (heurísticas H14, H16, H17); e acrescentar recompensas (heurística H17).
As heurísticas H16 - O desafio do jogo pode ser ajustado de acordo com a
habilidade do jogador e H17 - O jogador deve ser recompensado pelas suas
conquistas de forma clara e imediata, associadas à intenção dos alunos de
acrescentar novos níveis de dificuldade e às recompensas (“frutinhas” e bônus),
tiveram pouco grau de importância atribuído a elas nas respostas ao questionário.
Tais heurísticas ocuparam, respectivamente, a 16ª e 17ª posições na ordenação
decrescente das dezenove heurísticas nas respostas dos alunos do Brasil. Nas
respostas dos alunos do Chile, elas ocuparam respectivamente a 19ª e 17ª
posições. Por outro lado, interpretando de forma conjunta as funcionalidades
mencionadas com maior frequência na entrevista e as heurísticas, foi possível
constatar que os critérios associados às heurísticas H16 e H17 estão muito
presentes nas intenções dos alunos. Ainda, duas dessas funcionalidades estão
também associadas à heurística H14, frequentemente citada pelos alunos no
questionário de levantamento de perfil.
213
Essa constatação parece indicar que nem sempre os alunos expressam a
mesma opinião quando no papel de jogador e quando no papel de desenvolvedor,
apesar de ser evidente que o primeiro papel influencia o segundo, de acordo com a
discussão apresentada nas duas últimas subseções do texto. Ao estarem envolvidos
com a construção da mecânica de um jogo em particular – e as limitações que
surgem nessa construção – novas questões de jogabilidade emergem, e essas
questões podem não estar claras na concepção pré-estabelecida dos alunos
enquanto jogadores. Esse é mais um indício de que os alunos, ao participarem de
atividades de construção de jogos digitais, se engajaram em um processo de
reflexão-em-ação ao identificar novos aspectos e, possivelmente, tomar novas
ações. Inclusive, é interessante observar que tanto a heurística H14 quanto as
heurísticas H16 e H17 são, segundo Schell (2008), aspectos vinculados ao projeto
de fases (level design), cuja relevância aparece para os alunos ao longo de sua
participação na oficina.
Deve ser feita a ressalva que, da mesma forma que os alunos parecem incluir
aspectos de qualidade que são tidos como relevantes por eles, muitas
funcionalidades que incluíram ou desejaram incluir são aquelas já experimentadas
por eles em experiências anteriores. Isso é particularmente presente nos jogos
construídos na Oficina que existem comercialmente, como é o caso do Arkanoid e
do Pacman. Podemos citar aqui a criação de vários blocos no jogo Arkanoid
(subseção 0, Figura 66), a tentativa de Lucas (P4) de implementar as “pílulas de
poder” para que o Pacman comesse os fantasmas (na transcrição da entrevista
apresentada na seção 0), ou a implementação das “frutas” para obter pontuação
extra em alguns jogos entregues pelos alunos chilenos (descrita na subseção 0,
Tabela 19). Por um lado, em um sentido estrito, isso indicaria que os alunos não
estariam se engajando em um “autêntico” processo de design de interação,
conforme descrito por Winograd (1996, 1997), pois eles não estariam criando novas
funcionalidades interativas. No entanto, sabemos que o objetivo principal da Oficina
é o desenvolvimento de competências e habilidades relacionadas ao Pensamento
Computacional e não a formação de designers de jogos. Nesse aspecto, a imitação
de jogos existentes se constitui como uma prática válida (e conveniente) para os
objetivos da Oficina. Lembramos que as diretrizes para a criação da Oficina incluem
conduzir os alunos à elaboração de um jogo completo (diretriz (2), seção 0) e a
214
utilização de referências de jogos reais (diretriz (4), seção 0). Dessa forma, construir
funcionalidades de jogos dos quais os alunos se lembram e que já experimentaram66
se mostrou como um estímulo adicional para o desenvolvimento de novas
competências e habilidades.
Efetivamente, vimos que os alunos que implementaram funcionalidades
adicionais tiveram que explorar conceitos que eram novos para eles nos momentos
correspondentes da Oficina. Foi o caso do uso de laços de espera ocupada para
implementar a mensagem no fundo da tela no jogo Pedra, Papel e Tesoura
(subseção 0) e o emprego não-usual de mensagens para permitir um controle mais
ágil dos tiros no jogo Simulação de Guerra (subseção 0) e a criação da tela de
Game Over no mesmo jogo (subseção 0). Em outros momentos, os alunos
revisitaram e deram outra utilização a conceitos já conhecidos, como no episódio
Guilherme (P19), orientado a usar uma estrutura de repetição para exibir a animação
do tanque explodindo no jogo Simulação de Guerra (subseção 0), ou o uso de
variáveis e mensagens para controle da quantidade de vidas e reinício do nível no
jogo Pacman (subseção 0). A aprendizagem e utilização de conceitos pelos alunos
para implementar funcionalidades adicionais nos jogos não eram esperados
inicialmente na pesquisa; no entanto, sua identificação reforça a utilidade do domínio
da construção de jogos digitais no desenvolvimento do Pensamento Computacional.
6.6.4 Desenvolvimento das competências comuns
Conforme mencionado na subseção anterior, analisar a mobilização de
conteúdos matemáticos em um contexto autêntico de aprendizagem pelos alunos
durante o desenvolvimento do Pensamento Computacional permite ampliar a
compreensão da relação entre as duas áreas – a Matemática e a Computação. No
entanto, como também foi mencionado, não é possível que essa análise seja
exaustiva; dessa forma, nesta subseção será utilizado o arcabouço conceitual
proposto na seção 0 desta tese, relacionado às competências comuns entre o
66
Algumas referências são inclusive curiosas, como a fala de Diana (P10), transcrita na
seção anterior, que indica que a aluna gostaria de implementar no Pacman a mudança de níveis,
“que nem no Mario”. Não foi possível obter mais detalhes, mas seria surpreendente se a referência
fosse ao jogo Super Mario Bros original, apesar da franquia de jogos dos irmãos Mario ser produzida
há cerca de 30 anos.
215
Pensamento Computacional e a Matemática. Conforme o mapeamento das
diretrizes curriculares realizado, tais competências são:
•
Alternar entre diferentes representações semióticas;
•
Identificar regularidades e padrões;
•
Construir modelos descritivos e representativos.
Dessa forma, pretende-se observar o fenômeno em uma perspectiva mais
ampla, considerando a possível transferência de competências e habilidades entre
as áreas.
A primeira competência, Alternar entre diferentes representações semióticas,
refere-se à capacidade do aluno compreender um problema em uma dada
representação semiótica; inicialmente, tanto no caso da Matemática quando do
Pensamento Computacional, trata-se da representação textual do problema a ser
resolvido. Paralelamente, a competência também refere-se à capacidade de
representar o problema em outra representação semiótica, com o formalismo
adequado para o seu tratamento. No caso da Matemática, a representação refere-se
a tabelas, gráficos, expressões matemáticas ou algébricas; no caso do Pensamento
Computacional, trata-se do algoritmo que, no caso do paradigma estruturado, é
construído com base em estruturas básicas (comandos, variáveis, estruturas de
seleção e repetição).
Vários episódios registrados durante a observação etnográfica evidenciam
que converter um problema para um registro relacionado à Matemática exigiu o
suporte ativo do professor. Na maioria dessas situações, a construção do registro
algorítmico da solução foi influenciada de alguma forma pela bem (ou mal) sucedida
conversão para o registro matemático. Os episódios que evidenciaram de forma
mais notável esse fato foram a construção da expressão algébrica para o cálculo da
porcentagem de peixes clicados no jogo de Pescaria (subseção 0) e a definição por
escrito da estratégia algorítmica mais eficiente para acertar o número no Jogo de
Advinhação (subseção 0). Em outras situações, o suporte do professor não foi
possível, apesar de se terem criado oportunidades para a representação do
problema em um registro matemático. Foram os casos da identificação da posição
da bola do jogo Arkanoid e do Pacman, a construção de um modelo adequado para
216
a reflexão da bola no jogo Arkanoid e do cálculo de distâncias no plano para o
funcionamento dos fantasmas no jogo Pacman. Em ambos os tipos de situação,
concretas ou potenciais, é possível constatar a necessidade de se atuar na Zona de
Desenvolvimento Proximal dos alunos com o objetivo de desenvolver essa
competência.
A segunda competência, Identificar regularidades e padrões, refere-se a
capacidade de identificar um padrão, bem como de prever ou deduzir sua ocorrência
ou as regras de formação do padrão. A análise dos jogos desenvolvidos pelos
alunos durante a Oficina identificou alguns traços da reutilização de funcionalidades
(subseção 0), o que parece indicar que os alunos identificaram alguns padrões de
problemas nos jogos da Oficina, em especial relacionados à identificação do
posicionamento espacial de sprites. Nas últimas atividades da Oficina, as menções à
ideia de reutilização de funcionalidades ficaram mais presentes na fala dos alunos,
como reproduzimos abaixo:
“Eu não queria fazer meu jogo só com dois fantasmas, eu queria colocar os
quatro... Mas eu queria usar o mesmo código que eu já fiz para os outros dois...
Pode?” – José (P22), se referindo ao seu desejo de deixar seu jogo Pacman mais
completo, mas reconhecendo a possibilidade de reaproveitar o trabalho já feito.
“Eu fiz que nem aquele jogo do tanque que a gente já tinha feito” – Lucas
(P4), reconhecendo que a mesma estratégia já utilizada para implementar o tanque
no jogo Simulação de Guerra (o uso de estruturas de repetição para movimentar o
sprite) poderia ser utilizado com sucesso para criar o fantasma que patrulha uma
região fixa no Pacman.
Por um lado, as estratégias de implementação reutilizadas e descritas na
subseção 0 poderiam significar uma “fuga” de um tratamento matemático para os
problemas. Mas, por outro lado, a competência de reconhecer e descrever um
padrão, que apareceu em vários episódios da Oficina, bem como nos artefatos
desenvolvidos pelos alunos, também se revelou nos resultados da questão 1 do
teste matemático. A questão estava diretamente relacionada à identificação de um
padrão e à construção da expressão algébrica de sua formação. Dessa forma, esse
é um primeiro indicativo de que uma competência que foi desenvolvida e mobilizada
217
em várias ocasiões no contexto do Pensamento Computacional parece afetar a
mobilização da mesma competência no contexto da Matemática. Certamente, um
aprofundamento dessa pesquisa será necessária no futuro para elucidar melhor as
relações dessa competência com as atividades nas duas áreas.
A
terceira
e
última
competência,
Construir
modelos
descritivos
e
representativos, refere-se à capacidade do aluno construir modelos que descrevem
e representam uma solução para um dado problema, utilizando a representação
semiótica mais conveniente considerando o contexto do problema. Para a Educação
Matemática, um modelo assume uma definição ampla; trazemos novamente aqui a
definição de Bassanezi (2002), para quem um modelo é uma definição clara e sem
ambiguidades de um determinado problema, permitindo inclusive o cálculo de
soluções numéricas quando necessário. Um algoritmo representado em uma
linguagem de programação pode ser considerado como um modelo nessa definição,
com a ressalva da necessária alteração do registro de representação.
Dessa forma, é possível afirmar que muitos episódios durante a Oficina se
configuraram como situações de modelagem. Porém, em apenas alguns poucos
casos o conceito matemático se faz mais presente. É o caso da definição da
movimentação do tanque inimigo no jogo Simulação de Guerra (subseção 0),
quando os alunos tiveram que definir o posicionamento de possíveis intervalos de
pontos para a entrada do tanque. Na maioria das situações o modelo a ser
construído é uma estrutura “mista”, um algoritmo que combina alguns aspectos
matemáticos com estruturas de programação que compõem e estruturam o modelo.
Voltando ao referencial teórico da Educação Matemática, na classificação
proposta por Alrø e Skovsmose (2004), as atividades da Oficina se constituiriam
como uma “semi-realidade”, ou seja, o problema a ser resolvido (a construção do
jogo digital) se refere a uma realidade construída com finalidade didática. Assim, do
ponto de vista matemático, os modelos construídos pelos alunos não se
enquadrariam em uma perspectiva de compreensão e crítica da realidade
(BARBOSA, 2001); de todo modo, não se pode descartar a utilidade da construção
desses modelos como uma ferramenta para que os alunos compreendam (e até
mesmo elaborem sua reflexão crítica) sobre a pervasividade dos dispositivos
218
computacionais na realidade que os cerca. Porém, essa discussão encontra-se além
do escopo desta tese e poderá ser aprofundada em trabalhos futuros.
219
Capítulo 7
CONSIDERAÇÕES FINAIS
O termo Pensamento Computacional agrega várias competências e
habilidades relacionadas à Computação cuja aplicação pode ser útil em várias
áreas. Dessa forma, espera-se que tais competências e habilidades poderiam ser
desenvolvidas na educação básica. Entretanto, a contextualização do Pensamento
Computacional nas disciplinas tradicionais pode ser fundamental para demonstrar a
sua relevância e a sua aplicabilidade no currículo escolar.
Na pesquisa vinculada a esta tese foi proposta a exploração das possíveis
relações entre o Pensamento Computacional e a Matemática na educação básica.
Inicialmente, uma análise das diretrizes curriculares para o ensino de Matemática no
ensino médio no Brasil e no Chile permitiu a identificação de três áreas de
competências comuns para o desenvolvimento de atividades que envolvam o
Pensamento Computacional e a Matemática. A seguir, uma revisão sistemática da
literatura foi realizada e uma de suas conclusões relacionou-se à carência de
estudos que analisem a transferência de competências entre a Computação e outros
domínios a partir de análises que explorem a complexidade do processo de ensinoaprendizagem de forma mais aprofundada, baseadas na triangulação de métodos,
tais como entrevistas, observação, dados quantitativos e análise de artefatos.
A partir desses primeiros resultados, incorporou-se à pesquisa um estudo em
campo relacionado ao desenvolvimento e oferecimento de uma oficina de
construção de jogos utilizando o ambiente de programação Scratch. A oficina foi
construída
com
Aprendizagem
base
Baseada
em
em
diretrizes
inspiradas
Problemas
e
seu
no
construcionismo
objetivo
principal
e
na
foi
o
desenvolvimento de competências do Pensamento Computacional relacionadas à
programação de computadores. Ainda, pretendeu-se resgatar na proposta das
atividades a relevância e familiaridade do jogo digital para as novas gerações, sendo
propostas em vários momentos a criação de mecânicas de jogo presentes em jogos
reais. Consonante com uma proposta de triangulação de métodos, foram propostos
como métodos de pesquisa: a etnografia (apoiada pela identificação do perfil dos
alunos, observação participante dos encontros da Oficina pelos professores, e uma
220
entrevista final); um quase experimento baseado em um pré e pós-teste de
conhecimentos matemáticos; e a análise documental dos jogos e atividades escritas
produzidos pelos alunos.
O mapeamento das diretrizes curriculares, a revisão sistemática e a análise
dos resultados obtidos com a pesquisa de campo permitiram ampliar a compreensão
do fenômeno das relações entre o Pensamento Computacional e a Matemática. Os
principais achados da pesquisa são resumidos a seguir, organizados de acordo com
as questões de pesquisa propostas na introdução (seção 0).
Em relação à questão de pesquisa Q1: “Como conhecimentos prévios em
Matemática podem ser mobilizados durante o desenvolvimento do Pensamento
Computacional?”, a pesquisa de campo desenvolvida com base no oferecimento da
Oficina de Produção de Jogos Digitais permitiu identificar que as dificuldades em
aspectos básicos do raciocínio combinatório dos alunos, relacionados ao princípio
fundamental da contagem, estiveram relacionadas a dificuldades em identificar e
enumerar todos os possíveis eventos a serem tratados pelo código dos jogos
desenvolvidos. Essa é uma habilidade fundamental ao desenvolvimento de muitos
tipos de algoritmos, além daqueles relacionados aos jogos digitais. Por outro lado,
sendo o raciocínio combinatório um tópico integrante da Matemática Discreta, esse
achado vem confirmar a carência do ensino dessa área da Matemática na educação
básica, bem como sua influência em uma importante habilidade para a construção de
algoritmos.
O domínio específico da construção de jogos gerou alguns subsídios para
responder à questão de pesquisa Q4: “Como as competências e habilidades
matemáticas dos alunos se modificam ao longo da participação em uma oficina
de construção de jogos digitais?”. A construção de jogos exigiu dos alunos a
mobilização de conteúdos da geometria plana e geometria analítica, como distâncias,
ângulos e posicionamento de pontos no plano cartesiano. Algumas características do
ambiente de programação Scratch limitaram a exploração pelos alunos de alguns
conceitos, como a identificação do ângulo replementar e do posicionamento de
pontos no plano cartesiano; os alunos optaram por construir funcionalidades
relacionadas a esses conceitos utilizando recursos alternativos do ambiente, como a
colisão entre sprites, que não exigiam a mobilização do conceito matemático. Apesar
221
dessa limitação, o contato com os conceitos ao longo da Oficina parece haver
contribuído para que os alunos melhorassem sua percepção sobre os conceitos de
identificação da posição e deslocamento de pontos no plano e distância entre pontos
no plano, conforme indicam os resultados do pós-teste matemático. Não é possível
“isolar” completamente os resultados do processo de ensino-aprendizagem e afirmar
que esses resultados se devem unicamente à participação dos alunos na Oficina. Os
alunos continuaram envolvidos com o ensino regular: o Ensino Médio, no caso dos
alunos do Brasil, e as disciplinas matemáticas introdutórias de graduação, no caso
dos alunos do Chile. No entanto, a distância temporal relativamente curta entre o pré
e o pós-teste (4 meses no Brasil e 7 meses no Chile, considerando 2 meses de
paralisação das aulas naquele país) e a variedade de tópicos da geometria
abrangidos aponta um indício consistente do efeito da participação da Oficina nos
resultados.
Em uma análise considerando as competências em um nível maior de
abstração, os resultados do pós-teste matemático indicam uma melhora nas
competências dos alunos relacionadas à identificação de padrões. Apesar da Oficina
não mobilizar tais competências em um contexto puramente matemático, foi possível
constatar a utilização de estratégias para reutilizar funcionalidades em diferentes
jogos a partir da identificação de padrões nos problemas a serem resolvidos, no
conceito dado a essa palavra dentro da área de desenvolvimento de software.
A influência da atividade de construção de jogos se mostrou bastante presente
no desenvolvimento do Pensamento Computacional, o que forneceu subsídios para
responder às questões de pesquisa Q2: “Que competências e habilidades do
Pensamento Computacional são desenvolvidas pelos alunos durante uma
oficina de construção de jogos digitais?” e Q4: “Como a construção de jogos
digitais influencia a motivação dos alunos para mobilizar e/ou desenvolver
competências e habilidades?”. Foi possível identificar que os alunos participantes
da Oficina tinham relativa experiência e em geral apreciavam o uso de jogos digitais.
Essa experiência dos alunos foi identificada no levantamento inicial do perfil, mas
também se manifestou na “linguagem do jogo”, utilizada em vários momentos para
descrever os problemas a serem resolvidos durante a construção dos jogos. Os
alunos ainda manifestaram uma visão crítica sobre a qualidade da interação humanocomputador nos jogos que eram construídos por eles, que levou uma parcela dos
222
alunos a melhorar as funcionalidades dos jogos construídos por iniciativa própria. Por
um lado, essa iniciativa se relacionou com os critérios de qualidade que já eram
valorizados pelos alunos enquanto jogadores, e indica a utilização da “reflexão
durante a prática”, inerente ao processo criativo de design de interação. Por outro
lado, as experiências prévias dos alunos como jogos se revelaram na intenção de
copiar funcionalidades iguais ou similares aos dos jogos reais, que de toda forma se
aplicou com um fator de motivação para o desenvolvimento do Pensamento
Computacional.
A construção de jogos digitais permitiu o desenvolvimento de competências e
habilidades relacionadas à construção de algoritmos utilizando o paradigma
estruturado, que formam um subconjunto do Pensamento Computacional. As tarefas
propostas para a construção dos jogos, estruturadas em uma sequência de
dificuldade crescente, permitiram que os alunos explorassem não apenas as
estruturas básicas de construção de algoritmos (comandos, variáveis, estruturas de
seleção e repetição), mas também tópicos que usualmente são considerados
“avançados”, como paralelismo, sincronização entre processos, encapsulamento de
atributos e estado de objetos.
A estruturação das atividades da Oficina possibilitava a introdução de novos
tópicos a serem explorados na medida em que tópicos já trabalhados eram
novamente solicitados. Essa estratégia contribuiu para o engajamento dos alunos, a
partir da manutenção de um nível de desafio constante. É possível inclusive afirmar
que essa estratégia contribuiu em manter o estado de fluxo, conforme Basawapatna
et al. (2013); por outro lado, os resultados indicam a importância do suporte docente
durante as atividades, como demonstram vários episódios em que o professor foi
responsável em manter os alunos na Zona de Desenvolvimento Proximal. Várias
oportunidades foram utilizadas pelos professores para desenvolver o Pensamento
Computacional e a Matemática; porém, várias outras oportunidades foram
identificadas, o que demostra o potencial e o campo de aplicação da construção de
jogos digitais como uma atividade didática significativa para o desenvolvimento de
competências e habilidades nas novas gerações.
As oportunidades identificadas durante o oferecimento da Oficina de
Produção de Jogos Digitais indicam um potencial para a exploração, em trabalhos
223
futuros, dessa estratégia didática nos campos da Educação Matemática e do ensino
de Computação. Em vários momentos, a exploração ou introdução de um novo
tópico matemático foram limitadas pelo tempo e contexto de aplicação da Oficina;
dessa forma, espera-se que novas pesquisas que efetivamente integrem as
atividades da Oficina ao ensino de Matemática possibilitem identificar um
aprofundamento das relações entre o Pensamento Computacional e a Matemática,
ou mesmo a identificação de novas relações. De forma complementar, as diretrizes
propostas nesta tese para a criação das atividades da Oficina podem ser aplicadas à
criação de novas atividades didáticas nas quais sejam explorados outros tópicos da
Computação e da Matemática.
Ainda, novas pesquisas serão necessárias para validar o arcabouço
conceitual proposto nesta tese por meio das três competências comuns ao
Pensamento Computacional e à Matemática. Uma revisão do mapeamento será
necessária na medida em que novas diretrizes curriculares para o Pensamento
Computacional surgirem e forem refinadas. Os resultados desta pesquisa
apresentaram indícios razoavelmente claros do desenvolvimento pelos alunos da
identificação de padrões, que é uma das competências comuns. Os resultados ainda
indicam momentos em que ocorre a conversão entre registros de representação
semiótica, incluindo aspectos computacionais, mas uma análise mais aprofundada
desse fenômeno se mostra necessária. Em relação a terceira e última competência
– a construção de modelos descritivos e representativos – foi possível constatar que
o referencial teórico da Modelagem Matemática apresenta um efetivo potencial de
dialogar com as atividades didáticas realizadas. No entanto, uma sistematização das
atividades com base nesse referencial e nas diretrizes para a criação de atividades
se mostra necessária para a validação desse potencial.
225
REFERÊNCIAS
ADAMS, J. C.; WEBSTER, A. R. What do students learn about programming from
game, music video, and storytelling projects? SIGCSE ’12, 2012, New York.
Proceedings of the 43rd ACM technical symposium on Computer Science
Education. New York: ACM, 2012. p. 643-648. Disponível em:
<http://doi.acm.org/10.1145/2157136.2157319>. Acesso em: 3 fev. 2012.
AHAMED, S. I. et al. Computational thinking for the sciences: a three day workshop
for high school science teachers. In: SIGCSE ’10, 2010, New York, NY, USA.
Proceedings of the 41st ACM technical symposium on Computer science
education. New York, NY, USA: ACM, 2010. p. 42-46. Disponível em:
<http://doi.acm.org/10.1145/1734263.1734277>. Acesso em: 3 fev. 2012.
ALRØ, H.; SKOVSMOSE, O. Dialogue and learning in mathematics education:
intention, reflection, critique. Netherlands: Kluwer Academic Publishers, 2004.
ANDRÉ, M. Questões sobre os fins e sobre os métodos de pesquisa em educação.
Revista Eletrônica de Educação, v. 1, n. 1, p. 119-131, 2007.
ASSIS, L. S. Uma aproximação prática no ambiente de trabalho: resolução de
problemas em matemática e manutenção de sistemas computacionais. 2011. Tese
(Doutorado em Educação Matemática)–Pontifícia Universidade Católica de São
Paulo, São Paulo, 2011.
ASSOCIAÇÃO BRASILEIRA DE EMPRESAS DE TECNOLOGIA DE INFORMAÇÃO
E COMUNICAÇÃO. Tecnologia sofre com evasão universitária. Disponível em:
<http://www.brasscom.org.br/brasscom/content/view/full/5155>. Acesso em: 3 fev.
2012.
BARBOSA, J. C. Modelagem na educação matemática: contribuições para o debate
teórico. In: REUNIÃO ANUAL DA ANPED, 24., 2001, Caxambu. Anais... Caxambu:
ANPED, 2001.
BARCELOS, T. et al. Análise comparativa de heurísticas para avaliação de jogos
digitais. In: LATIN AMERICAN CONFERENCE ON HUMAN-COMPUTER
INTERACTION, 5., 2011, Pernambuco, Brazil. Proc. IHC+CLIHC 2011.
Pernambuco, Brazil: SBC, 2011. p. 187-196.
______. et al. Design and evaluation of a robotics workshop to support learning of
programming fundamentals. In: CONFERENCIA LATINOAMERICANA EN
INFORMÁTICA - CLEI 2013, 39., 2013, Vezenuela. Anais… Vezenuela: Centro
Latinoamericano de Estudios en Informática, 2013.
BARR, V.; STEPHENSON, C. Bringing computational thinking to K-12: what is
Involved and what is the role of the computer science education community? ACM
Inroads, v. 2, n. 1, p. 48-54, fev. 2011.
226
BASAWAPATNA, A. et al. Recognizing computational thinking patterns. In: SIGCSE
2011, 2011, New York. Proceedings of the 42nd ACM technical symposium on
Computer science education. New York: ACM, 2011. p. 245-250.
BASAWAPATNA, A. R. et al. The zones of proximal flow: guiding students through a
space of computational thinking skills and challenges. ICER ’13, 2013, New York.
Proceedings of the Ninth Annual International ACM Conference on
International Computing Education Research. New York: ACM, 2013. p. 67-74.
Disponível em: <http://doi.acm.org/10.1145/2493394.2493404>. Acesso em: 3 fev.
2012.
BASSANEZI, R. Ensino-aprendizagem com modelagem matemática. São Paulo:
Contexto, 2002.
BATTAIOLA, A. L. et al. Desenvolvimento de jogos em computadores e celulares.
Revista de Informática Teórica e Aplicada, v. 8, n. 2, out. 2001.
BAYLISS, J. D.; STROUT, S. Games as a “flavor” of CS1. SIGCSE Bull, v. 38, n. 1,
p. 500-504, mar. 2006.
BEAUBOUEF, T. Why computer science students need math. SIGCSE Bulletin, v.
34, n. 4, p. 57-59, dez. 2002.
BELL, T. et al. Computer Science Unplugged: an enrichment and extension
programme for primary-aged children. Disponível em: <http://www.csunplugged.org>.
Acesso em: 1 ago. 2013.
BENETT, S.; MATON, K.; KERVIN, L. The “digital natives” debate: a critical review of
the evidence. British Journal of Educational Technology, v. 39, n. 5, p. 775-786,
2008.
BENITTI, F. B. V. Exploring the educational potential of robotics in schools: a
systematic review. Computers & Education, v. 58, n. 3, p. 978-988, 2012.
BRASIL. Ministério da Educação. Parâmetros Curriculares Nacionais: matemática:
1o e 2o ciclos. Brasília: Secretaria de Ensino Fundamental, 1997.
______. Ministério da Educação. Parâmetros Curriculares Nacionais: ensino
médio. Parte III: ciências da natureza, matemáticas e suas tecnologias. Brasília:
MEC/SEB, 1999.
______. Ministério da Educação. PCN+ Ensino Médio: orientações curriculares
complementares aos parâmetros curriculares nacionais. Brasília: MEC/SEB, 2002.
BRENNAN, K.; RESNICK, M. New frameworks for studying and assessing the
development of computational thinking. In: AERA 2012, 2012, Vancouver.
Proceedings of the 2012 annual meeting of the American Educational Research
Association. Vancouver: American Educational Research Association, 2012.
BRERETON, P. et al. Lessons from applying the systematic literature review process
within the software engineering domain. Journal of Systems and Software, v. 80, n.
4, p. 571-583, 2007. Disponível em: <ce:title>Software Performance</ce:title>
227
<xocs:full-name>5th International Workshop on Software and
Performance</xocs:full-name>. Acesso em: 1 ago. 2013.
BRUCE, K. B. et al. Why math? Communications of the ACM, v. 46, n. 9, p. 41-44,
2003.
BUCKINGHAM, D. Beyond technology: children’s learning in the age of digital
culture. Cambridge, MA: Policy Press, 2007.
CAMPBELL, P. F.; MCCABE, G. P. Predicting the success of freshmen in a
computer science major. Communications of the ACM, v. 27, n. 11, p. 1108-1113,
nov. 1984.
CARNEGIE MELLON UNIVERSITY. Alice - an educational software that teaches
students computer programming in a 3D environment. Disponível em:
<http://www.alice.org>. Acesso em: 15 ago. 2013.
CENTRO DE ESTUDOS SOBRE AS TECNOLOGIAS DA INFORMAÇÃO E DA
COMUNICAÇÃO. TIC Kids Online 2012. Disponível em:
<http://www.cetic.br/usuarios/kidsonline/2012>. Acesso em: 29 out. 2013.
CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DE SÃO PAULO. UNIDADE
DE ENSINO DESCENTRALIZADA DE GUARULHOS. Projeto pedagógico do
curso técnico em manutenção e suporte em informática. Disponível em:
<http://portal.ifspguarulhos.edu.br/tecnico-em-manutencao-e-suporte-eminformatica>. Acesso em: 21 ago. 2013.
CHILE. Ministerio d Educación. Objetivos fundamentales y contenidos mínimos
obligatórios de la educación media. Disponível em:
<http://www.aep.mineduc.cl/images/pdf/2010/CurriculumMedia.pdf>. Acesso em: 27
maio 2012.
COMISSÃO EUROPEIA. DIREÇÃO GERAL DE EDUCAÇÃO E CULTURA.
Competencias clave para un aprendizaje ao lo largo de la vida: un marco de
referencia europeo. [S.l: s.n.]. Disponível em:
<http://www.educastur.princast.es/info/calidad/indicadores/doc/comision_europea.pdf
>. Acesso em: 6 fev. 2014.
CONFREY, J. et al. Designing software for mathematical engagement through
modelling. In: HOYLES, C.; LAGRANGE, J. B. (Org.). Mathematics education and
technology-rethinking the terrain: the 17th ICMI Study. New York: Springer, 2010.
p. 19-46.
CONNOLLY, T. M. et al. A systematic literature review of empirical evidence on
computer games and serious games. Computers & Education, v. 59, n. 2, p. 661686, 2012.
CORMEN, T. H.; LEISERSON, C. E.; RIVEST, R. L. Introduction to algortihms.
Cambridge: MIT Press, 1989.
228
CORSETI, B. A análise documental no contexto da metodologia qualitativa: uma
abordagem a partir da experiência de pesquisa no programa de pós-graduação em
educação da Unisinos. UNIRevista, v. 1, n. 1, p. 32-46, 2006.
CRENSHAW, T. L. et al. A case study of retention practices at the University of
Illinois at Urbana-Champaign. In: SIGCSE ’08, 2008, New York. Proceedings of the
39th SIGCSE technical symposium on Computer science education. New York:
ACM, 2008. p. 412-416.
CRESWELL, J. W. Qualitative inquiry and research design: choosing among five
traditions. California: Sage Publications, 1998.
______. Research design: qualitative, quantitative and mixed methods approaches.
California: Sage Publications, 2013.
______; MILLER, D. L. Determining validity in qualitative inquiry. Theory Into
Practice, v. 39, n. 3, p. 124-130, 2000.
DE SOUZA, C. S. et al. Semiotic traces of computational thinking acquisition. In: ISEUD ’11, 2011, Heidelberg. Proceedings of the Third international conference on
End-user development. Heidelberg: Springer-Verlag, 2011. p. 155-170.
DELORS, J. Educação: um tesouro a descobrir. São Paulo: Cortez, 1998.
DENNER, J.; WERNER, L.; ORTIZ, E. Computer games created by middle school
girls: can they be used to measure understanding of computer science concepts?
Computers & Education, v. 58, n. 1, p. 240-249, jan. 2012.
DENNING, P. J. Is computer science science? Communications of the ACM, v. 48,
n. 4, p. 27-31, abr. 2005.
DINIZ, L. do N.; BORBA, M. C. Leitura e interpretação de dados prontos em um
ambiente de modelagem e tecnologias digitais: o mosaico em movimento. BOLEMA
- Boletim de Educação Matemática, v. 26, n. 43, 2012.
ERICKSON, F. Métodos cualitativos de investigación sobre la enseñanza. In:
WITTROCK, M. C. La investigación de la enseñanza. Barcelona: Paidós/MEC,
1989. p. 195-301.
FELLEISEN, M.; KRISHNAMURTHI, S. Viewpoint: why computer science doesn’t
matter. Commun. ACM, v. 52, n. 7, p. 37-40, jul. 2009.
FORBELLONE, A. L. V.; EBERSPÄCHER, H. F. Lógica de programação: a
construção de algoritmos e estruturas de dados. 3. ed. São Paulo: Makron Books,
2005.
FRANKLIN, D. et al. Assessment of computer science learning in a scratch-based
outreach program. SIGCSE ’13, 2013, New York, NY, USA. Proceeding of the 44th
ACM technical symposium on Computer science education. New York, NY,
USA: ACM, 2013. p. 371–376. Disponível em:
<http://doi.acm.org/10.1145/2445196.2445304>. Acesso em: 6 fev. 2014.
229
FROST, D. et al. A model curriculum for K-12 computer science: level I
objectives and outlines. Disponível em:
<http://csta.acm.org/Curriculum/sub/CurrFiles/L1-Objectives-and-Outlines.pdf>.
Acesso em: 6 fev. 2014.
GAMMA, E. et al. Design patterns: elements of reusable object-oriented software.
Massachusetts: Addison-Wesley, 1994.
GINAT, D. On Novice Loop Boundaries and range conceptions. Computer Science
Education, v. 14, n. 3, p. 165-181, set. 2004.
GOETZ, J. P.; LECOMPTE, M. D. Ethnography and qualitative design in
educational research. Orlando: Academic Press, 1984.
GOLDBERG, M. A complete history of breakout. Disponível em:
<http://classicgaming.gamespy.com/View.php?view=Articles.Detail&id=395>. Acesso
em: 10 out. 2013.
GÜNTHER, H. Pesquisa qualitativa versus pesquisa quantitativa: esta é a questão?
Psicologia: teoria e pesquisa, v. 22, n. 2, p. 201-210, 2006.
HAREL, I. Children sesigners: interdisciplinary constructions for learning and
knowing mathematics in a computer-rich school. New Jersey: Ablex Publishing,
1991.
HAREL, I.; PAPERT, S. Constructionism. Westport: Ablex Publishing, 1991.
HENDERSON, P. B. Math counts: mathematical reasoning in computing education.
ACM Inroads, v. 1, n. 3, p. 22-23, set. 2011.
______; LETVIN, M.; LITVIN, G. Pre-college math concepts vs skills: preparation for
computing studies. ACM Inroads, v. 39, n. 4, p. 26-28, 2007.
HERNANDEZ, C. C. et al. Teaching programming principles through a game engine.
CLEI Electronic Journal, p. 1-8, 2010.
HIX, D.; HARTSON, H. Developing user interfaces: ensuring usability through
product and process. New York: John Wiley & Sons, Inc., 1993.
HU, C. Computational thinking: what it might mean and what we might do about it. In:
ITICSE ’11, 2011, New York, NY, USA. Proceedings of the 16th annual joint
conference on Innovation and technology in computer science education. New
York, NY, USA: ACM, 2011. p. 223-227. Disponível em:
<http://doi.acm.org/10.1145/1999747.1999811>. Acesso em: 22 jun. 2013.
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SÃO
PAULO. Plano de desenvolvimento institucional 2009-2013. Disponível em:
<http://www.ifsp.edu.br/index.php/arquivos/category/34pdi.html?download=86%3Apd
i>. Acesso em: 22 jun. 2013.
230
INSTITUTO NACIONAL DE ESTUDOS E PESQUISAS EDUCACIONAIS ANÍSIO
TEIXEIRA. Censo da educação básica: 2012 – resumo técnico. Brasília:
INEP/MEC, 2012.
______. Prova Brasil - ensino fundamental - matrizes de referência, tópicos e
descritores. Brasília: MEC/SEB, 2008. Disponível em:
<http://download.inep.gov.br/educacao_basica/prova_brasil_saeb/menu_do_profess
or/cadernos/prova%20brasil_matriz.pdf>. Acesso em: 5 fev. 2013.
______. Prova do ENEM 2005: amarela. [S.l: s.n.]. Disponível em:
<http://download.inep.gov.br/educacao_basica/enem/provas/2005/2005_amarela.pdf
>. Acesso em: 20 jan. 2013.
______. Sistema de avaliação da educação básica: exemplos de questões. [S.l:
s.n.]. Disponível em:
<http://download.inep.gov.br/educacao_basica/prova_brasil_saeb/downloads/9ano_
SITE_MT.pdf>. Acesso em: 5 fev. 2013.
______. Sistema de avaliação da educação básica: prova modelo 9o ano. [S.l:
s.n.]. Disponível em:
<http://download.inep.gov.br/educacao_basica/prova_brasil_saeb/downloads/simula
do/2011/prova_modelo_9ano.pdf>. Acesso em: 5 fev. 2013.
ISBELL, C. L. et al. (Re)defining computing curricula by (re)defining computing.
SIGCSE Bulletin, v. 41, n. 4, p. 195-207, jan. 2010.
JONES, K. Issues in the Teaching and learning of geometry. In: HAGGARTY, L.
(Org.). Aspects of teaching secondary mathematics: perspectives on practice.
London: Routledge, 2002. p. 121-139.
JUUL, J. A casual revolution: reinventing videogames and their players.
Cambridge: MIT Press, 2010.
KAFAI, Y. Playing and making games for learning: instructionist and constructionist
perspectives for game studies. Games and Culture, v. 1, n. 1, p. 36-40, 2006.
KITCHENHAM, B. Procedures for performing systematic reviews. Technical
Report, no TR/SE-0401. UK: Keele University, 2004.
KRONE, J.; SITARAMAN, M.; HALLSTROM, J. O. Mathematics throughout the CS
curriculum. Jornal of Computing Sciences in Colleges, v. 27, n. 1, p. 65-73, out.
2011.
LATORRE, A.; DEL RINCÓN, D.; ARNAL, J. Bases metodológicas de la
investigación educativa. Barcelona: GR92, 1996.
LEE, I. et al. Computational thinking for youth in practice. ACM Inroads, v. 2, n. 1, p.
32-37, fev. 2011.
LEUTENEGGER, S. T. A CS1 to CS2 bridge class using 2D game programming. J.
Comput. Sci. Coll, v. 21, n. 5, p. 76-83, maio 2006.
231
LEWIS, C. M.; SHAH, N. Building Upon and enriching grade four mathematics
standards with programming curriculum. In: SIGCSE ’12, 2012, New York.
Proceedings of the 43th SIGCSE technical symposium on Computer science
education. New York: ACM, 2012.
LIKERT, R. A technique for the measurement of attitudes. Archives of Psychology,
v. 140, p. 1-55, 1932.
LÜDKE, M.; ANDRÉ, M. E. D. A. Pesquisa em educação: abordagens qualitativas.
São Paulo: Editora Pedagógica e Universitária, 1986.
MACHADO, N. J. Educação: competência e qualidade: ensaios transversais. São
Paulo: Escrituras, 2009.
MALAN, D. J.; LEITNER, H. H. Scratch for budding computer scientists. SIGCSE
Bull., v. 39, n. 1, p. 223-227, mar. 2007.
MALONEY, J. H. et al. Programming by choice: urban youth learning programming
with scratch. SIGCSE ’08, 2008, New York, NY, USA. Proceedings of the 39th
SIGCSE technical symposium on Computer science education. New York, NY,
USA: ACM, 2008. p. 367–371. Disponível em:
<http://doi.acm.org/10.1145/1352135.1352260>. Acesso em: 22 jun. 2013.
MARINHO, F. C. V.; GIANNELLA, T. R.; STRUCHINER, M. Estudantes do ensino
básico como desenvolvedores de jogos digitais: contextos autênticos de
aprendizagem para educação em ciências e matemática. In: ENCONTRO
NACIONAL DE PESQUISA EM EDUCAÇÃO EM CIÊNCIAS, 8., 2011, Campinas.
Atas... Campinas: [s.n.], 2011.
MERRIL, D. A Pebble-in-the-Pond Model for instructional design. Performance
Improvement, v. 41, n. 7, p. 41-46, 2002.
MICROSOFT RESEARCH. Kodu game lab community. Disponível em:
<http://www.kodugamelab.com/>. Acesso em: 16 jan. 2014.
MIT MEDIA LAB, LIFELONG KINDERGARTEN GROUP. Scratch. Disponível em:
<http://scratch.mit.edu>. Acesso em: 27 abr. 2012.
MOR, Y.; NOSS, R. Programming as mathematical narrative. International Journal
of Continuing Engineering Education and Life-long Learning, v. 18, n. 2, p. 214233, 2008.
MORAES, R. Análise de conteúdo. Revista Educação, v. 22, n. 37, p. 7-32, 1999.
MORAN, T. The command language grammars: a representation for the user
interface of interactive computer systems. International Journal of Man-Machine
Studies, v. 15, p. 3-50, 1981.
MOTA, M. P.; FARIA, L. S.; DE SOUZA, C. S. Documentation comes to life in
computational thinking acquisition with AgentSheets. IHC ’12, 2012, Porto Alegre,
Brazil. Proceedings of the 11th Brazilian Symposium on Human Factors in
Computing Systems. Porto Alegre, Brazil: Brazilian Computer Society, 2012. p.
232
151–160. Disponível em: <http://dl.acm.org/citation.cfm?id=2393536.2393558>.
Acesso em: 22 jun. 2013.
MULLER, O.; HABERMAN, B.; AVERBUCH, H. (An almost) pedagogical pattern for
pattern-based problem-solving instruction. ACM SIGCSE Bulletin, v. 36, n. 3, p. 102,
1 set. 2004. Acesso em: 18 set. 2013.
MURATET, M. et al. Towards a serious game to help students learn computer
programming. International Journal of Computer Games Technology, v. 2009, p.
3:1-3:12, jan. 2009.
NAKAMURA, J.; CSIKSZENTMIHALYI, M. Flow theory and research. In: SNYDER,
C. R.; LOPEZ, S. J. Oxford handbook of positive psychology. 2. ed. Oxford:
Oxford University Press, 2009. p. 195-206.
NIELSEN, J.; MOLICH, R. Heuristic evaluation of user interfaces. 1990, New York,
NY, USA. CHI ’90: Proceedings of the SIGCHI conference on Human factors in
computing systems. New York, NY, USA: ACM, 1990. p. 249-256.
NORMAN, D. A. Cognitive engineering. In: ______; DRAPER, S. W. (Org.). Usercentered system design. Hillsdale, NJ: Lawrence Erlbaum Associates, 1986. p. 3161.
NOSS, R.; HOYLES, C.; POZZI, S. Working knowledge: mathematics in use. In:
BESSOT, A.; RIDGWAY, J. Education for mathematics in the workplace.
Hingham, USA: Kluwer Academic Publishers, 2000. .
PAPERT, S. Mindstorms: children, computers and powerful ideas. New York: Basic
Books, 1980.
PEPPLER, K.; KAFAI, Y. Gaming Fluencies: Pathways into Participatory Culture in a
Community Design Studio. International Journal of Learning and Media, v. 1, n. 4,
p. 45-58, nov. 2009.
PERRENOUD, P. et al. As competências para ensinar no século XXI: a formação
dos professores e o desafio da avaliação. Porto Alegre: Artmed, 2007.
PERRENOUD, P. Avaliação: da excelência à regulação das aprendizagens entre
duas lógicas. Porto Alegre: Artmed, 1999.
PINELLE, D.; WONG, N.; STACH, T. Using genres to customize usability evaluations
of video games. 2008, Toronto, Ontario, Canada. Proceedings of the 2008
Conference on Future Play: Research, Play, Share. Toronto, Ontario, Canada:
ACM, 2008. p. 129-136.
PIORO, B. T. Introductory computer programming: gender, major, discrete
mathematics, and calculus. J. Comput. Sci. Coll, v. 21, n. 5, p. 123-129, maio 2006.
PITTMAN, J. The pac-man dossier. Disponível em:
<http://home.comcast.net/~jpittman2/pacman/pacmandossier.html>. Acesso em: 15
dez. 2012.
233
POLYA, G. A arte de resolver problemas. Rio de Janeiro: Interciência, 1995.
PRENSKY, M. Digital natives, digital immigrants. On the horizon, v. 9, n. 5, out.
2001.
QIN, H. Teaching computational thinking through bioinformatics to biology students.
SIGCSE Bulletin, v. 41, n. 1, p. 188-191, mar. 2009.
RALSTON, A. Do we need ANY mathematics in computer science curricula?
SIGCSE Bull, v. 37, n. 2, p. 6-9, jun. 2005.
______; SHAW, M. Curriculum ’78 - Is Computer science really that unmathematical?
Communications of the ACM, v. 23, n. 2, p. 67-70, 1980.
RAMALINGAM, V.; WIEDENBECK, S. Development and validation of scores on a
computer programming self-efficacy scale and group analyses of novice programmer
self-efficacy. Journal of Educational Computing Research, v. 19, n. 4, p. 367-381,
1998.
RED DE ASISTENCIA TÉCNICA DE ENLACES, MINISTERIO DE EDUCACIÓN DE
CHILE. Informática educativa en el currículum de enseñanza media –
matemática. Disponível em:
<http://www.eduteka.org/pdfdir/ChileCurriculoMatematicasTics.pdf>. Acesso em: 17
maio 2012.
RESNICK, M. et al. Scratch: programming for all. Communications of the ACM, v.
52, n. 11, p. 60-67, nov. 2009.
RIZVI, M. et al. A CS0 course using Scratch. J. Comput. Sci. Coll, v. 26, n. 3, p. 19*27, jan. 2011.
RUIZ, P. A. Nuevas tecnologías y estudiantes chilenos de secundaria: aportes a la
discusión sobre la existencia de nuevos aprendices. Estudios Pedagógicos
(Valdivia), v. 39, n. 2, 2013.
RUSSELL, S. J.; NORVIG, P. Artificial intelligence: a modern approach. Upper
Saddle River, NJ: Prentice Hall, 2003.
SALEN, K. Gaming literacies: a game design study in action. Journal of
Educational Multimedia and Hypermedia, v. 16, n. 3, p. 301-322, 2007.
______; ZIMMERMAN, E. Rules of play: game design fundamentals.
Massachusetts: The MIT Press, 2003.
SANDÍN ESTEBAN, M. P. Pesquisa qualitativa em educação: fundamentos e
tradições. Porto Alegre: AMGH, 2010.
SÁ-SILVA, J. R.; ALMEIDA, C. D.; GUINDANI, J. F. Pesquisa documental: pistas
teóricas e metodológicas. Revista Brasileira de História & Ciências Sociais, v. 1,
n. 1, p. 1-15, 2009.
234
SCAICO, P. D. et al. Sem matemática não existe computação. In: SIMPÓSIO
BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO - SBIE, 22., 2011, Aracajú/
WORKSHOP DE INFORMÁTICA NA ESCOLA - WIE, 17., 2011, Aracajú. Anais…
Aracaju: SBC, 2011. p. 1424-1427.
SCHELL, J. The art of game design: a book of lenses. Burlington, MA: Elsevier,
2008.
SCHÖN, D.; BENNETT, J. Reflective conversations with materials. In: WINOGRAD,
T. et al. (Org.). Bringing design to software. New York: ACM Press, 1996. .
SELLERS, M. Designing the experience of interactive play. In: VORDERER, P.;
BRYANT, J. (Org.). Playing video games: motives, responses, consequences.
Mahwah: Lawrence Erlbaum Associates, 2006.
SELWYN, N. The digital native-myth and reality. Aslib Proceedings, v. 61, n. 4, p.
364-379, 2009.
SETTI, M. de O. G. O processo de discretização do raciocínio matemático na
tradução para o raciocínio computacional: um estudo de caso no
ensino/aprendizagem de algoritmos. 2009. Tese (Doutorado em Educação)–
Universidade Federal do Paraná, Curitiba, 2009.
SETTLE, A. Computational thinking in a game design course. In: SIGITE ’11, 2011,
New York, NY, USA. Proceedings of the 2011 conference on Information
technology education. New York, NY, USA: ACM, 2011. p. 61-66. Disponível em:
<http://doi.acm.org/10.1145/2047594.2047612>. Acesso em: 15 dez. 2012.
SHADISH, WI. R.; COOK, T. D.; CAMPBELL, D. T. Experimental and quasiexperimental design for generalized causal inference. Boston: Houghton Mifflin,
2002.
SOLOWAY, E. Learning to program = learning to construct mechanisms and
explanations. Communications of the ACM, v. 29, n. 9, p. 850-858, 1986.
SOUZA, P. R. de A.; DIAS, L. R. Kodu game labs: estimulando o raciocínio lógico
através de jogos. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO SBIE, 23., 2012, Rio de Janeiro. Anais.... Rio de Janeiro: SBC, 2012. Disponível em:
<http://br-ie.org/pub/index.php/sbie/article/view/1733>. Acesso em: 9 ago. 2013.
STOLEE, K. T.; FRISTOE, T. Expressing computer science concepts through Kodu
game lab. SIGCSE ’11, 2011, New York. Proceedings of the 42nd ACM technical
symposium on Computer science education. New York: ACM, 2011. p. 99-104.
Disponível em: <http://doi.acm.org/10.1145/1953163.1953197>. Acesso em: 15 dez.
2012.
TANENBAUM, A. S.; WOODHULL, A. S. Sistemas operacionais: projeto e
implementação. 3. ed. Porto Alegre: Bookman, 2008.
TAPSCOTT, D. A hora da geração digital. Rio de Janeiro: Agir, 2010.
235
TAYLOR, M.; HARLOW, A.; FORRET, M. Using a computer programming
environment and an interactive whiteboard to investigate some mathematical
thinking. Procedia - Social and Behavioral Sciences, International Conference on
Mathematics Education Research 2010 (ICMER 2010), v. 8, n. 0, p. 561-570, 2010.
THE CSTA STANDARDS TASK FORCE. CSTA K-12 computer science
standards. New York: ACM Computer Science Teachers Association, 2011.
Disponível em: <http://csta.acm.org/Curriculum/sub/CurrFiles/CSTA_K-12_CSS.pdf>.
Acesso em: 3 fev. 2012.
TROCHIM, W. M. K.; DONELLY, J. P. Research methods knowledge base. . [S.l:
s.n.]. Disponível em: <http://www.socialresearchmethods.net/kb>. Acesso em: 30
out. 2013.
TURING, A. On computable numbers, with an application to the
Entscheidungsproblem. Proceedings of the London Mathematical Society, v. 42,
n. 2, p. 230-265, 1936.
UNIVERSIDAD DE VALPARAÍSO. ESCUELA DE INGENIERÍA CIVIL EN
INFORMÁTICA. Carreras - ingeniería civil en informática. Disponível em:
<http://www.decomuv.cl/index.php?option=com_content&view=article&id=64&Itemid=73>. Acesso em:
13 nov. 2013.
______. ESCUELA DE INGENIERÍA CIVIL INFORMÁTICA. Inducción alumnos.
Disponível em: <http://www.decom-uv.cl/documentos/induccionICI2012.html>.
Acesso em: 15 maio 2013.
UNIVERSITY OF KENT. Greenfoot. Disponível em: <http://www.greenfoot.org>.
Acesso em: 15 ago. 2013.
VALENTE, S. M. P. Competências e habilidades: pilares do paradigma avaliativo
vigente. In: ALVARENGA, G. M.; SOUZA, N. A. (Org.). Revista Avaliação, Londrina,
p. 153-176, 2003.
VAZQUEZ, C. M. R.; MALAGUTTI, P. L. A. Atividades experimentais de análise
combinatória no ensino médio em uma escola estadual. In: ENCONTRO DA REDE
DE PROFESSORES, PESQUISADORES E LICENCIANDOS DE FÍSICA E
MATEMÁTICA, 2., 2010, São Carlos. Anais... São Carlos: UFSCar, 2010.
VILLARREAL, M. E. Tecnologías y educación matemática: necesidad de nuevos
abordajes para la enseñanza. Virtualidad, Educación y Ciencia, n. 5, p. 73-94,
2012.
VYGOTSKY, L. S. Zone of proximal development. In: COLE, M. et al. (Org.). Mind in
society: the development of higher psychological processes. Oxford: Harvard
University Press, 1978. p. 52-91.
WATT, D. A. Programming language concepts and paradigms. Englewood Cliffs:
Prentice Hall, 1990.
236
WHOLIN, C. et al. Experimentation in software engineering: an introduction. USA:
Kluwer Academic Publishers, 2000.
WILSON, B. C.; SHROCK, S. Contributing to success in an introductory computer
science course: a study of twelve factors. In: SIGCSE ’01, 2001, New York.
Proceedings of the thirty-second SIGCSE technical symposium on Computer
Science Education. New York: ACM, 2001. p. 184-188.
WING, J. M. Computational thinking. Communications of the ACM, v. 49, n. 3, p.
33-35, mar. 2006.
WINOGRAD, T. From computing machinery to interaction design. In: DENNING, P.;
METCALFE, R. (Org.). Beyond calculation: the nest fifty years of computing.
Amsterdam: Springer-Verlag, 1997. p. 149-162.
______. Introduction-what is design? In: ______. et al. (Org.). Bringing design to
software. New York: ACM Press, 1996. .
WOHLIN, C. et al. Systematic literature reviews. Experimentation in software
engineering. [S.l.]: Springer Berlin Heidelberg, 2012. p. 45-54. Disponível em:
<http://dx.doi.org/10.1007/978-3-642-29044-2_4>. Acesso em: 16 jan. 2014.
YOYO GAMES, LTD. GameMaker: studio. Disponível em:
<https://www.yoyogames.com/studio>. Acesso em: 16 jan. 2014.
237
Apêndice A DADOS DA REVISÃO SISTEMÁTICA DA LITERATURA
Procedimentos para obtenção dos artigos
ACM
Na base da ACM, a busca foi restrita a artigos publicados pela ACM e organizações
afiliadas. Para tanto, foi realizado o seguinte procedimento:
•
Acessar o endereço http://portal.acm.org
•
Executar uma busca com qualquer palavra-chave (esse procedimento é
necessário para que seja possível o acesso à reconfiguração da busca com
uma string utilizando expressões booleanas; isso se deve a uma limitação da
interface do portal)
•
Na página que é apresentada com os resultados da busca, clicar em Limit
your search to publications from ACM and affiliated organizations
•
Clicar em Advanced search
•
Na caixa de texto, inserir a string de busca "computational thinking"
and ("math" or "mathematics")
•
Clicar em Search
ERIC
•
Acessar o endereço http://eric.ed.gov
•
Na caixa de texto, inserir a string de busca "computational thinking"
and ("math" or "mathematics")
•
Clicar na opção Peer-reviewed only
•
Clicar em Search
IEEE
•
Acessar o endereço http://ieeexplore.ieee.org
•
Clicar em More search options Command search
•
Selecionar a opção Full text and metadata
238
•
Na caixa de texto, inserir a string de busca "computational thinking"
AND ("math" OR "mathematics") (a base IEEExplore exige o uso dos
operadores booleanos em maiúsculas)
•
Clicar em Search
ScienceDirect
•
Acessar o endereço http://www.sciencedirect.com
•
Na caixa de texto, inserir a string de busca "computational thinking"
and ("math" or "mathematics")
•
Clicar em Search
SpringerLink
•
Acessar o endereço http://link.springer.com
•
Na caixa de texto, inserir a string de busca "computational thinking"
and ("math" or "mathematics")
•
Clicar em Search
Códigos e referências dos estudos classificados como Experiência Didática
ACM
SV001-ACM
S002-ACM
S004-ACM
SV002-ACM
S007-ACM
S010-ACM
SV003-ACM
PAGE, R.; GAMBOA, R. A more formal approach to “computer science: principles”.
SIGCSE ’13. Anais... New York: ACM, 2013. p. 257–262. Disponível em:
<http://doi.acm.org/10.1145/2445196.2445274>.
JENKINS, J. T.; JERKINS, J. A.; STENGER, C. L. A plan for immediate immersion of
computational thinking into the high school math classroom through a partnership with
the Alabama math, science, and technology initiative. ACM-SE ’12. Anais... New
York:
ACM,
2012.
p.
148–152.
Disponível
em:
<http://doi.acm.org/10.1145/2184512.2184547>.
COOK, C. T. et al. A systematic approach to teaching abstraction and mathematical
modeling. ITiCSE ’12. Anais... New York: ACM, 2012. p. 357–362. Disponível em:
<http://doi.acm.org/10.1145/2325296.2325378>.
CARTER, E.; BLANK, G.; WALZ, J. Bringing the breadth of computer science to
middle schools. SIGCSE ’12. Anais... New York: ACM, 2012. p. 203–208. Disponível
em: <http://doi.acm.org/10.1145/2157136.2157198>.
LEWIS, C. M.; SHAH, N. Building upon and enriching grade four mathematics
standards with programming curriculum. SIGCSE ’12. Anais... New York: ACM, 2012.
p. 57–62. Disponível em: <http://doi.acm.org/10.1145/2157136.2157156>.
AHAMED, S. I. et al. Computational thinking for the sciences: a three day workshop
for high school science teachers. SIGCSE ’10. Anais... New York: ACM, 2010. p. 42–
46. Disponível em: <http://doi.acm.org/10.1145/1734263.1734277>.
TAUB, R.; ARMONI, M.; BEN-ARI, M. CS Unplugged and Middle-School Students’
Views, Attitudes, and Intentions Regarding CS. Trans. Comput. Educ., v. 12, n. 2, p.
8:1–8:29, abr. 2012.
239
S013-ACM
S018-ACM
S019-ACM
S020-ACM
S021-ACM
S023-ACM
S025-ACM
S029-ACM
S030-ACM
ATER-KRANOV, A. et al. Developing a community definition and teaching modules
for computational thinking: accomplishments and challenges. SIGITE ’10. Anais...
New
York:
ACM,
2010.
p.
143–148.
Disponível
em:
<http://doi.acm.org/10.1145/1867651.1867689>.
WELLER, M. P.; DO, E. Y.-L.; GROSS, M. D. Escape machine: teaching
computational thinking with a tangible state machine game. IDC ’08, 2008, New York.
Anais...
New
York:
ACM,
2008.
p.
282–289.
Disponível
em:
<http://doi.acm.org/10.1145/1463689.1463767>.
JERKINS, J. A. et al. Establishing the impact of a computer science/mathematics antisymbiotic stereotype in CS students. J. Comput. Sci. Coll., v. 28, n. 5, p. 47–53, maio
2013.
BOYCE, A. K. et al. Experimental evaluation of BeadLoom game: how adding game
elements to an educational tool improves motivation and learning. ITiCSE ’11. Anais...
New
York:
ACM,
2011.
p.
243–247.
Disponível
em:
<http://doi.acm.org/10.1145/1999747.1999816>.
LAWSON, B.; SZAJDA, D.; BARNETT, L. Introducing computer science in an
integrated science course. SIGCSE ’13. Anais... New York: ACM, 2013. p. 341–346.
Disponível em: <http://doi.acm.org/10.1145/2445196.2445298>.
SENGUPTA, P.; FARRIS, A. V. Learning kinematics in elementary grades using
agent-based computational modeling: a visual programming-based approach. IDC
’12.
Anais...
New
York:
ACM,
2012.
p.
78–87.
Disponível
em:
<http://doi.acm.org/10.1145/2307096.2307106>.
HSI, S.; EISENBERG, M. Math on a sphere: using public displays to support
children’s creativity and computational thinking on 3D surfaces. IDC ’12. Anais... New
York:
ACM,
2012.
p.
248–251.
Disponível
em:
<http://doi.acm.org/10.1145/2307096.2307137>.
FLATLAND, R. Y.; MATTHEWS, J. R. Using modes of inquiry and engaging problems
to link computer science and mathematics. SIGCSE Bull., v. 41, n. 1, p. 387–391,
mar. 2009.
BRYANT, R. et al. Using the context of algorithmic art to change attitudes in
introductory programming. J. Comput. Sci. Coll., v. 27, n. 1, p. 112–119, out. 2011.
IEEE
S001-IEEE
S002-IEEE
S003-IEEE
SV002-IEEE
S007-IEEE
S012-IEEE
SV010-IEEE
S014-IEEE
FREUDENTHAL, E. et al. A computational introduction to STEM studies. Education
Engineering (EDUCON), 2010 IEEE, 14 abr. 2010, [S.l.]: IEEE, 14 abr. 2010. p. 663–
672.
HOJI, E. S.; VIANNA, W. B.; FELIX, T. D. A. A computer-aided math teaching
approach for students in a technical institute: The experience with the Octave in the
electro-mechanical technical course. 15th International Conference on Interactive
Collaborative Learning (ICL), 2012, 26 set. 2012, [S.l.]: IEEE, 26 set. 2012. p. 1–5.
RIZVI, M. et al. A new CS0 course for at-risk majors. 2011 24th IEEE-CS Conference
on Software Engineering Education and Training (CSEE T), 2011, [S.l.]: IEEE, 2011.
p. 314–323.
PHALKE, A.; LYSECKY, S. Adapting the eBlock Platform for Middle School STEM
Projects: Initial Platform Usability Testing. IEEE Transactions on Learning
Technologies, v. 3, n. 2, p. 152–164, 2010.
TURBAK, F. et al. Blocks languages for creating tangible artifacts. 2012 IEEE
Symposium on Visual Languages and Human-Centric Computing (VL/HCC), 2012,
[S.l.]: IEEE, 2012. p. 137–144.
FALKNER, N.; SOORIAMURTHI, R.; MICHALEWICZ, Z. Puzzle-Based Learning for
Engineering and Computer Science. Computer, v. PP, n. 99, p. 1–1, 2010.
MAXWELL, A. et al. Robot RAL-ly international-Promoting STEM in elementary
school across international boundaries using remote access technology. 2013 10th
International Conference on Remote Engineering and Virtual Instrumentation (REV),
2013, [S.l.]: IEEE, 2013. p. 1–5.
YEH, K.-C.; XIE, Y.; KE, F. Teaching computational thinking to non-computing majors
using spreadsheet functions. 2011 Frontiers in Education Conference (FIE), 2011,
[S.l.]: IEEE, 2011. p. F3J–1–F3J–5.
240
SV013-IEEE
YEVSEYEVA, K.; TOWHIDNEJAD, M. Work in progress: Teaching computational
thinking in middle and high school. 2012 Frontiers in Education Conference (FIE),
2012, [S.l.]: IEEE, 2012. p. 1–2.
ScienceDirect
SV002-SD
SV003-SD
S001-SD
S002-SD
S003-SD
IOANNIDOU, A.; REPENNING, A.; WEBB, D. C. AgentCubes: Incremental 3D enduser development. Journal of Visual Languages & Computing - Special Issue on Best
Papers from VL/HCC2008, v. 20, n. 4, p. 236–251, ago. 2009.
MANSON, J. R.; OLSEN, R. J. Diagnostics and rubrics for assessing learning across
the computational science curriculum. Journal of Computational Science, v. 1, n. 1, p.
55–61, maio 2010.
LARKINS, D. B.; HARVEY, W. Introductory computational science using MATLAB
and image processing. ICCS 2010, v. 1, n. 1, p. 913–919, maio 2010.
TAYLOR, M.; HARLOW, A.; FORRET, M. Using a Computer Programming
Environment and an Interactive Whiteboard to Investigate Some Mathematical
Thinking. Procedia - Social and Behavioral Sciences - International Conference on
Mathematics Education Research 2010 (ICMER 2010), v. 8, n. 0, p. 561–570, 2010.
CHIU, J. L. et al. WISEngineering: Supporting precollege engineering design and
mathematical understanding. Computers & Education, v. 67, n. 0, p. 142–155, set.
2013.
SpringerLink
S001-SL
S007-SL
S008-SL
S009-SL
JACOBS, P. Building Excitement, Experience and Expertise in Computational
Science among Middle and High School Students. In: ALLEN, G. et al. (Org.).
Computational Science – ICCS 2009. Lecture Notes in Computer Science. [S.l.]:
Springer Berlin Heidelberg, 2009. v. 5545. p. 15–24. Disponível em:
<http://dx.doi.org/10.1007/978-3-642-01973-9_3>.
SENGUPTA, P. et al. Integrating computational thinking with K-12 science
education using agent-based computation: A theoretical framework. Education and
Information Technologies, v. 18, n. 2, p. 351–380, 1 jun. 2013.
RHINE, D.; MARTIN, F. Integrating Mathematical Analysis of Sensors and Motion in
a Mobile Robotics Course. In: MITTERMEIR, R.; SYSŁO, M. (Org.). Informatics
Education - Supporting Computational Thinking. Lecture Notes in Computer
Science. [S.l.]: Springer Berlin Heidelberg, 2008. v. 5090. p. 41–52. Disponível em:
<http://dx.doi.org/10.1007/978-3-540-69924-8_4>.
TORT, F.; BLONDEL, F.-M.; BRUILLARD, É. Spreadsheet Knowledge and Skills of
French Secondary School Students. In: MITTERMEIR, R.; SYSŁO, M. (Org.).
Informatics Education - Supporting Computational Thinking. Lecture Notes in
Computer Science. [S.l.]: Springer Berlin Heidelberg, 2008. v. 5090. p. 305–316.
Disponível em: <http://dx.doi.org/10.1007/978-3-540-69924-8_28>.
Discussão conceitual – Categoria Ponto de vista
S001-ACM
S003-ACM
S005-ACM
S006-ACM
S009-ACM
ISBELL, C. L. et al. (Re)defining computing curricula by (re)defining computing.
SIGCSE Bulletin, v. 41, n. 4, p. 195–207, jan. 2010.
HEMMENDINGER, D. A plea for modesty. ACM Inroads, v. 1, n. 2, p. 4–7, jun.
2010.
EASTON, T. A. Beyond the algorithmization of the sciences. Commun. ACM, v. 49,
n. 5, p. 31–33, maio 2006.
BARR, V.; STEPHENSON, C. Bringing computational thinking to K-12: what is
Involved and what is the role of the computer science education community? ACM
Inroads, v. 2, n. 1, p. 48–54, fev. 2011.
WING, J. M. Computational thinking. Communications of the ACM, v. 49, n. 3, p.
33–35, mar. 2006.
241
S011-ACM
S014-ACM
S022-ACM
S028-ACM
S010-IEEE
SV006-SL
HU, C. Computational thinking: what it might mean and what we might do about it.
In: ITICSE ’11, 2011, New York, NY, USA. Anais... New York, NY, USA: ACM,
2011. p. 223–227. Disponível em: <http://doi.acm.org/10.1145/1999747.1999811>.
FLETCHER, G. H. L.; LU, J. J. Education: Human computing skills: rethinking the K12 experience. Commun. ACM, v. 52, n. 2, p. 23–25, fev. 2009.
KRAMER, J. Is abstraction the key to computing? Commun. ACM, v. 50, n. 4, p. 36–
42, abr. 2007.
LU, J. J.; FLETCHER, G. H. L. Thinking about computational thinking. SIGCSE
Bull., v. 41, n. 1, p. 260–264, mar. 2009.
ZHENRONG, D. et al. Exploration of ability development of engineering and
computational thinking skills in software engineering majors. In: 4th International
Conference on Computer Science Education - ICCSE ’09, 2009, [S.l: s.n.], 2009. p.
1665–1668.
HROMKOVIČ, J.; STEFFEN, B. Why Teaching Informatics in Schools Is as
Important as Teaching Mathematics and Natural Sciences. In: KALAŠ, I.;
MITTERMEIR, R. (Org.). Informatics in Schools. Contributing to 21st Century
Education. Lecture Notes in Computer Science. [S.l.]: Springer Berlin Heidelberg,
2011. v. 7013. p. 21–30. Disponível em: <http://dx.doi.org/10.1007/978-3-64224722-4_3>.
Discussão conceitual – categoria Mapeamento curricular
S031-ACM
S002-ERIC
S009-IEEE
S013-IEEE
SV002-SL
POKORNY, K. L. What will they know? Standards in the high school computer
science curriculum. J. Comput. Sci. Coll., v. 28, n. 5, p. 218–225, maio 2013.
BELL, P. et al. Exploring the Science Framework. Science and Children, v. 50, n. 3,
p. 11–16, 2012.
LIU, J.; WANG, L. Computational Thinking in Discrete Mathematics. In: 2010
SECOND INTERNATIONAL WORKSHOP ON EDUCATION TECHNOLOGY AND
COMPUTER SCIENCE (ETCS), 2010, [S.l: s.n.], 2010. p. 413–416.
BARCELOS, T. S.; SILVEIRA, I. F. Teaching Computational Thinking in initial
series: An analysis of the confluence among mathematics and Computer Sciences
in elementary education and its implications for higher education. XXXVIII
Conferencia Latinoamericana En Informatica (CLEI), 2012, [S.l: s.n.], 2012. p. 1–8.
MICHEUZ, P. Harmonization of Informatics Education – Science Fiction or
Prospective Reality? In: MITTERMEIR, R.; SYSŁO, M. (Org.). Informatics Education
- Supporting Computational Thinking. Lecture Notes in Computer Science. [S.l.]:
Springer Berlin Heidelberg, 2008. v. 5090. p. 317–326. Disponível em:
<http://dx.doi.org/10.1007/978-3-540-69924-8_29>.
Discussão conceitual – categoria Revisão da literatura
S024-ACM
S001-ERIC
SV001-IEEE
S011-IEEE
S006-SL
ARMONI, M. Looking at Secondary Teacher Preparation Through the Lens of
Computer Science. Trans. Comput. Educ., v. 11, n. 4, p. 23:1–23:38, nov. 2011.
GROVER, S.; PEA, R. Computational Thinking in K–12: A Review of the State of
the Field. Educational Researcher, v. 42, n. 1, p. 38–43, 1 jan. 2013.
LIU, J. et al. A survey on computer science K-12 outreach: Teacher training
programs. 2011, [S.l: s.n.], 2011. p. T4F–1–T4F–6.
MCMASTER, K.; RAGUE, B.; ANDERSON, N. Integrating Mathematical Thinking,
Abstract Thinking, and Computational Thinking. 2010, [S.l: s.n.], 2010. p. S3G–1–
S3G–6.
XU, Z.-W.; TU, D.-D. Three New Concepts of Future Computer Science. Journal of
Computer Science and Technology, v. 26, n. 4, p. 616–624, 1 jul. 2011.
243
Mapeamento entre competências, habilidades e conteúdos desenvolvidos e o nível de ensino das atividades
High order / "generic" skills
Algebra / Calculus
Functions (laws of physics and
chemical phenomena)
Modelling
Math modelling (pre and post
conditions)
Abstraction
S002-ACM
Generalization
S002-ACM Variables
Justification
S002-ACM Simple algebraic equations
S002-SD
Modulo arithmetic
Usage of Math language
SV010-IEEE Algebra
S009-SL
Ratio
S002-SD
Pattern identification
S020-ACM Basic algebra
S002-IEEE
Proportion
S002-SD
Iteration
S020-ACM Complex numbers
S002-IEEE
Measurements of time and
distance
S003-SD
Abstraction
S004-ACM
S007-SL
Binary, decimal and hexadecimal
numbering systems
S007-SL
Pattern recognition
S030-ACM Mathematical functions
S008-SL
Number/Operations
S009-SL
Iteration
S030-ACM Inequalities
Logical reasoning
S012-IEEE Slope variations
S001-IEEE
Abstract reasoning
S012-IEEE Exponencial decay
S001-IEEE
Special cases
Graphical and algebraic analysis
of sensor performance
S010-ACM
Arithmetics
S007-ACM State machine modelling
S004-ACM Integer division
SV002-ACM
S018-ACM Mathematical computations
S007-ACM
SV002-IEEE
Algebraic equations
SV001-ACM
Functions of several variables
S021-ACM
Elementary / middle school
Gradient descent
S021-ACM
High school
S021-ACM
Undergraduate school
Relationship between Math and CS SV003-ACM Partial derivatives
Relationship between Math skills
and CT
SV013-ACM Gradient
S001-SD
Relationship between Math skills
and CS
S019-ACM Functions
S014-IEEE
Teachers
SV003-SD
244
Mapeamento entre competências, habilidades e conteúdos desenvolvidos e nível de ensino (cont.)
Planar Geometry
Statistics
Linear Algebra
Geometrical relationships
S007-ACM Probability
S010-ACM Coordinate systems
Planar geometry
S025-ACM Probability
SV013-IEEE Cartesian coordinates
Spherical geometry
S025-ACM Decision trees
SV013-IEEE Cartesian coordinates
Physics
SV003-SD Constant acceleration
S023-ACM
Interpretation and generation of
speed-time graphs
S023-ACM
S020-ACM Distance, speed and acceleration
S023-ACM
S003-SD
Surface area
S002-SD
Probability/Statistics
2D geometrical figures
S003-SD
Probability
S029-ACM Matrices
S002-IEEE Speed
S001-SL
Angles
S003-SD
Principle of counting
S029-ACM Vectors
S002-IEEE Acceleration
S001-SL
S014-IEEE Linear systems
S002-IEEE Resonance
Scale
SV010-IEEE Statistics
Angles
SV010-IEEE
S009-SL
Normalization
Analytical geometry
S007-SL
S007-SL
Speed-time graphs
Forces
S001-SL
S001-IEEE
S002-IEEE
S009-SL
Cartesian coordinates
S001-IEEE Torques
S002-IEEE
Planar geometry
S003-IEEE
Cartesian coordinates
S003-IEEE Newtonian mechanics
SV002-SD
Planar geometry
S007-IEEE
Vectors and Matrices
Geometry/Measurement
S001-SD
Elementary / middle school
High school
Undergraduate school
Teachers
245
Apêndice B RUBRICA EDUCACIONAL DA OFICINA
Na tabela a seguir são apresentados os objetivos de aprendizagem definidos para cada uma das atividades da Oficina de
Produção de Jogos Digitais. Cada jogo desenvolvido na Oficina é composto por uma sequência progressiva de atividades que são
solicitadas aos alunos. Para cada atividade, são identificadas as competências e habilidades esperadas quando a atividade é
completada com sucesso por um aluno. As competências e habilidades são agrupadas por assunto: ambiente do Scratch; aquelas
Lógica de Programação e Matemática. As células sombreadas indicam uma competência ou habilidade que é desenvolvida ou
mobilizada pela primeira vez.
Jogo
Encontro do gato com
o rato
Tarefa solicitada
Controlar o rato com duas teclas
Compreender o conceito de evento (disparado por
teclado)
Lógica de Programação
Matemática
Compreender o conceito de comando
Utilizar o comando MOVA X PASSOS
Fazer o rato dizer "Olá gato" ao colidir com o gato
Criar um segundo tipo de peixe que vale dois
pontos ao ser clicado
Pescaria
Ambiente do Scratch
Diminuir o tempo que o segundo tipo de peixe
aparece na tela a partir do momento que o jogador
faz 20 pontos
Compreender o conceito de colisão entre sprites
Compreender e utilizar a sintaxe do condicional
simples
Criar um novo sprite
Compreender e utilizar a sintaxe de repetição sem
condição de parada (SEMPRE - "loop infinito")
Compreender o conceito de evento (disparado por
clique)
Utilizar uma variável acumuladora
Compreender e utilizar o comando ESPERE
Utilizar a sintaxe do condicional simples com
operador relacional <
Compreender e utilizar a sintaxe de repetição com
número definido de repetições ("REPITA X")
Decidir qual o número máximo de peixes de cada
tipo que serão exibidos pelo jogo
Mostrar quantos peixes de cada tipo foram
acertados como uma porcentagem do total de
peixes exibidos
Compreender e utilizar o conceito de
intervalo na reta real
Utilizar o comando DIGA
Construir uma expressão algébrica,
em função das variáveis criadas, para
o cálculo da porcentagem
246
Jogo
Tarefa solicitada
Escolher um personagem e um cenário para o jogo
Ambiente do Scratch
Dizer se o número informado é menor ou maior
que o número sorteado. Se o número informado
for igual ao número sorteado, o programa termina.
Jogo de Advinhação
Utilizar atribuição de variáveis
Utilizar o comando PERGUNTE X E ESPERE e a variável
pré-definida RESPOSTA
Utilizar o comando DIGA
Utilizar a sintaxe do condicional simples com os
operadores <, = e >
Utilizar o comando PARE
Caso contrário, o personagem deve perguntar
novamente
Contagem das tentativas feitas pelo jogador para
acertar o número. Quando se esgotarem as
tentativas, o jogo deve avisar que o jogador
perdeu.
Utilizar a sintaxe de repetição sem condição de
parada ("loop infinito")
Utilizar o comando DIGA
Utilizar a sintaxe de repetição com número definido
de repetições ("REPITA X") ou variável contadora.
Utilizar o comando PARE
Identificar qual é o número máximo de tentativas
necessárias para acertar o número na sua melhor
estratégia de jogo
Empregar adequadamente um
algoritmo de divisão-e-conquista
(tempo proporcional a log2(N))
Escrever todas as possíveis combinações finais de
jogo no papel antes de construir o código.
Utilizar adequadamente o princípio
fundamental da contagem (Análise
combinatória) para enumerar os
possíveis resultados em uma dada
situação
Criar um novo sprite e editar os trajes
Pedra, Papel e Tesoura
Matemática
Criar um novo sprite e mudar o traje do fundo
Utilizar o operador NÚMERO ALEATÓRIO ENTRE A E B
Perguntar ao jogador seu “palpite” para o número
sorteado
Lógica de Programação
Implementar o segundo jogador. Ele deve escolher
pedra, papel ou tesoura usando outras teclas
convenientes.
Utilizar o conceito de evento (disparado pelo teclado)
Compreender e utilizar o comando MUDE PARA O
TRAJE X
Utilizar a sintaxe do condicional simples com o
operador =
Indicar qual dos jogadores que ganhou
Utilizar a troca de traje do fundo de tela (opcional)
Utilizar um laço SEMPRE de espera ocupada
(opcional)
247
Jogo
Pedra, Papel e Tesoura
(cont.)
Tarefa solicitada
Ambiente do Scratch
Fazer o sprite da mão “entrar na tela” pela direita
ou pela esquerda quando o jogador indica sua
jogada
Compreender e utilizar o comando DESLIZE EM X
SEGUNDOS PARA X, Y
Segunda versão: montar uma estratégia para que o
computador escolha uma jogada aleatoriamente
assim que o primeiro jogador faça sua jogada
Compreender e utilizar o conceito de envio de
mensagens e de evento disparado por mensagem
Tanque azul pode girar para a esquerda e para a
direita, mas não pode se movimentar
Lógica de Programação
Matemática
Utilizar o conceito de evento (disparado pelo teclado)
Compreender e utilizar o comando VIRE X GRAUS
Criar um novo sprite e importar trajes
Disparar uma bala, que é lançada em linha reta na
direção em que o tanque está apontado
Utilizar um laço com condição booleana de parada
(REPITA ATÉ)
Utilizar o conceito de evento (disparado pelo teclado)
Utilizar o sensor de colisão com sprite
Tanque verde surge vindo do terreno inimigo e
vem na direção do nosso jogador
Simulação de Guerra
Se a bala atingir o tanque verde inimigo, ele
explode
Utilizar o comando APONTE PARA
Utilizar um laço com condição booleana de parada
(REPITA ATÉ)
Utilizar o comando PRÓXIMO TRAJE
Utilizar a sintaxe de repetição com número definido
de repetições ("REPITA X")
Utilizar o sensor de colisão com sprite
Compreender e utilizar o sensor TOCANDO EM BORDA
Modificar condição booleana de parada do laço
incorporando operador booleano OU
Utilizar o comando PRÓXIMO TRAJE
Utilizar a sintaxe de repetição com número definido
de repetições ("REPITA X")
Se a bala atingir o limite do terreno, ela que
explode.
Utilizar o comando PRÓXIMO TRAJE
O jogador perde se o tanque verde o atingir. Nesse
caso, o tanque azul explode e uma mensagem de
“Fim de jogo” deve ser apresentada.
Tanque inimigo entra no terreno em direção ao
jogador vindo cada vez de um lugar diferente.
Descreva seu algoritmo em termos das
coordenadas (x, y) do tanque.
Utilizar a troca de traje do fundo de tela
Utilizar o conceito de envio de mensagens e de evento
disparado por mensagem
Utilizar o operador NÚMERO ALEATÓRIO ENTRE A E B
Utilizar o comando VÁ PARA X, Y
Reconhecer pontos no plano
cartesiano; identificar a variação de
posições nos eixos x e y
248
Uma vez que o tanque verde exploda, ele volta a
aparecer em uma outra posição para atacar o
jogador
Jogo
Tarefa solicitada
Fazer com que a bola se movimente junto com a
plataforma antes de ser lançada pressionando-se a
barra de espaços
Utilizar um laço de repetição sem condição de
parada ("loop infinito")
Ambiente do Scratch
Lógica de Programação
Matemática
Utilizar o conceito de envio de mensagens e de evento
disparado por mensagem
Utilizar o comando VÁ PARA X, Y
Se a bola ultrapassar o limite no qual pode ser
alcançada pela plataforma, o jogador perde uma
vida e a bola volta a ser posicionada sobre a
plataforma para ser lançada novamente.
Arkanoid
O bloco amarelo desaparece quando for atingido
uma vez pela bola. Isso aumenta a pontuação em
50 pontos.
O bloco verde desaparece quando for atingido três
vezes pela bola. Isso aumenta a pontuação do jogo
em 150 pontos e diminui a velocidade da bola
(deixando o jogo mais fácil).
O bloco vermelho desaparece quando for atingido
uma vez pela bola. Ele libera uma cápsula que
desce na tela. Se a cápsula for tocada pela
plataforma, o jogador ganha uma vida adicional.
Utilizar a sintaxe do condicional simples com o
operador <
Identificar a variação de posição no
eixo y
Utilizar a mudança de valor de uma variável
Utilizar o conceito de envio de mensagens e de evento
disparado por mensagem
Utilizar a mudança de valor de uma variável
Identificar relações entre ângulos no
círculo trigonométrico. Identificar e
calcular o ângulo suplementar
Utilizar o sensor de colisão com sprite
Utilizar o conceito de envio de mensagens e de evento
disparado por mensagem
Utilizar a mudança de valor de uma variável
Utilizar o sensor de colisão com sprite
Utilizar o conceito de envio de mensagens e de evento
disparado por mensagem
Utilizar a mudança de valor de uma variável
Utilizar o sensor de colisão com sprite
Utilizar um laço com condição booleana de parada
(REPITA ATÉ)
Identificar relações entre ângulos no
círculo trigonométrico. Identificar e
calcular o ângulo suplementar
O pacman poderá se mover em quatro direções
Utilizar o conceito de evento (disparado pelo teclado)
(para cima, para baixo, para a direita e para a
esquerda), sendo controlado pelas setas direcionais Utilizar o comando MOVA X PASSOS
do teclado
Pacman
Uma mudança de direção só pode ser permitida
quando o centro do pacman estiver sobre a
intersecção de duas linhas
O Pacman automaticamente se movimenta para
frente, a menos que colida com uma parede
Utilizar a sintaxe do condicional simples com o
operador =
Utilizar o operador booleano E
Utilizar um laço de repetição sem condição de
parada ("loop infinito")
Utilizar a sintaxe do condicional simples
Calcular o resto da divisão inteira;
identificação de coordenadas
cartesianas de ponto no plano
249
Jogo
Tarefa solicitada
Ambiente do Scratch
Quando o jogador pressiona uma seta do teclado, o
PacMan vira para a direção indicada, a menos que
Utilizar o conceito de evento (disparado pelo teclado)
exista uma parede naquela direção.
Utilizar o sensor de colisão com cor
Cada vez que o PacMan colide com um “ponto de
energia” (círculo amarelo), ele deve somar mais um Utilizar os comandos ABAIXAR A CANETA e LEVANTAR
ponto
A CANETA
Pacman (cont.)
Quando o PacMan chega ao final do túnel direito,
no centro do labirinto, ele deve sumir e aparecer
na entrada do túnel da esquerda, e vice-versa
Lógica de Programação
Utilizar a sintaxe do condicional simples
Utilizar a mudança de valor de uma variável
Utilizar o comando VÁ PARA X, Y
Utilizar a sintaxe do condicional simples
Utilizar o comando MOVA X PASSOS
Utilizar um laço com condição booleana de parada
(REPITA ATÉ)
Fantasma que patrulha uma região
Matemática
Identificar a variação de posição no
eixo x, identificar coordenadas
cartesianas no plano
Utilizar o comando VIRE X GRAUS
Utilizar o comando MOVA X PASSOS
Utilizar um laço com condição booleana de parada
(REPITA ATÉ)
Utilizar o comando VIRE X GRAUS
Utilizar a sintaxe do condicional simples
Fantasma que persegue o Pacman
Calcular a distância entre pontos no
plano cartesiano
251
Apêndice C MATERIAL DIDÁTICO DA OFICINA
Nas páginas seguintes é apresentado o material didático preparado para
orientação dos professores responsáveis pela Oficina de Produção de Jogos
Digitais. Apesar da Oficina seguir uma proposta construcionista, tal material foi
produzido para facilitar a orientação dos professores envolvidos, considerando as
suas limitações de tempo e distância geográfica.
O material é dividido em sete tópicos temáticos. A abordagem de cada tópico
pode ser feita em uma ou mais aulas. As tarefas que devem ser desenvolvidas pelos
alunos, tanto no ambiente do Scratch quanto utilizando lápis e papel, estão descritas
sequencialmente em cada tópico temático. O material é ainda complementado com
algumas informações e curiosidades sobre os jogos que se baseiam na mecânica de
jogos comerciais clássicos.
Para a aplicação da Oficina na Universidad de Valparaíso, o conteúdo do
material didático foi integralmente traduzido ao espanhol.
252
01
Algoritmos e o Scratch
Objetivos
Introduzir o conceito de algoritmo e programação de computadores; Introduzir o ambiente do
Scratch através da exploração dos conceitos de sprite, palco e colisão.
Competências abordadas
Alternar entre representações semióticas
Conteúdo abordado
Conceitos sobre algoritmos
Estrutura de decisão
O computador executa as tarefas através da execução de programas;
Um programa de computador consiste em uma sequência de instruções (ou comandos)
escritas em linguagem de máquina, ou seja, uma linguagem codificada que é compreendida
pela sua Unidade de Processamento Central (CPU).
Para facilitar o trabalho de escrever programas, foram desenvolvidas as linguagens de
programação de alto nível, onde as instruções são escritas utilizando palavras mais próximas
da linguagem natural do ser humano. As instruções são, então, convertidas para linguagem de
máquina, em um processo denominado compilação.
Para simplificar e viabilizar o processo de compilação, as linguagens de programação de alto
nível permitem a utilização de apenas um conjunto limitado de instruções. As palavras que
representam as instruções são normalmente escritas em inglês.
A sequência de instruções que compõem um programa é chamada de algoritmo. Assim, a
Lógica de Programação é uma disciplina que estuda técnicas e estratégias para a construção
de algoritmos.
A ferramenta que utilizaremos para estudar a construção de algoritmos se chama Scratch. O
Scratch é uma ferramenta que permite a construção de jogos, animações interativas e
desenhos a partir da definição do algoritmo que executa cada uma das instruções que definem
os programas que vão ser gerados.
Esta é a interface do Scratch:
253
Paleta de
comandos
Palco
Sprites
Para começar, vamos explorar o projeto Scratch gravado no arquivo gatorato.sb
Veja o que acontece ao pressionar as setas para direita e para a esquerda. O gato e o rato são
representados por sprites, indicados no canto inferior direito.
Questões para exploração
Quantos comandos são executados quando a tecla Seta para direita é pressionada?
Quantos comandos são executados quando a tecla Seta para esquerda é pressionada?
Explique com suas palavras o que o computador deve fazer quando a seta para direita é pressionada.
Por que os comandos que você está vendo têm relação com o gato? Que dica visual o Scratch
fornece para indicar isso?
Agora é a sua vez!
Faça com que o rato também possa se movimentar. O rato deve ser controlado por duas teclas
diferentes das utilizadas para o gato. Faça com que o rato diga “Olá, gato!” ao encontrar com ele.
254
02
Armazenando a pontuação do jogo em variáveis
Objetivos
Introduzir o conceito de variáveis através do conceito de pontuação em um jogo
Competências abordadas
Alternar entre representações semióticas
Identificar regularidades e padrões
Construir modelos descritivos e representativos
Conteúdo abordado
Variáveis
Estrutura de decisão
Nesta aula vamos trabalhar com um jogo de apontar-e-clicar chamado O sonho do gato. Você
pode ajudar o gato Scratch a pegar peixes “caindo do céu” (o que imaginamos que seja o
sonho de qualquer gato). A cada clique do mouse correto em um peixe, o jogo soma mais um
ponto.
Note que os comandos relacionados ao armazenamento e modificação dos pontos estão na cor
laranja. Os pontos são armazenados em uma variável, que é uma área de armazenamento de
valores que podem ser modificados à medida que se torna necessário no programa.
Questões para exploração
Verifique o comando “Vá para”. Explique com suas palavras: como ele define a posição do peixe na
tela?
O peixe pode aparecer em qualquer posição da tela? Por quê?
O que faz com que o peixe mude de posição sem parar?
255
Agora é a sua vez!
Crie um segundo tipo de peixe que vale dois pontos ao ser clicado. Ambos os tipos de peixe vão
aparecer ao mesmo tempo, e o jogador deve escolher em qual clicar.
Torne o jogo mais difícil: diminua o tempo que o segundo tipo de peixe aparece na tela a partir do
momento que o jogador faz 20 pontos.
O jogo deve ter um final para que os jogadores possam competir e comparar os resultados obtidos.
Assim, você terá que decidir qual o número máximo de peixes de cada tipo que serão exibidos pelo
jogo. Ao final, o jogo deve mostrar quantos peixes de cada tipo foram acertados como uma
porcentagem do total de peixes exibidos.
256
03
Testando condições e o estado do jogo
Objetivos
Exercitar a identificação de condições lógicas para teste em estruturas de decisão
Competências abordadas
Alternar entre representações semióticas
Identificar regularidades e padrões
Construir modelos descritivos e representativos
Conteúdo abordado
Variáveis
Estrutura de decisão
Como você viu na aula passada, o Scratch dispõe de um comando para sortear um número
aleatório em um intervalo de valores definido pelo programador. Isso permite implementar
um jogo de adivinhação simples contra o computador.
Escolha um personagem e um cenário para o jogo. Ele deve perguntar ao jogador seu
“palpite” para o número sorteado e dizer se o número informado é menor ou maior que o
número sorteado. Se o número informado for igual ao número sorteado, o programa termina.
Caso contrário, o personagem deve perguntar novamente.
Questões para exploração
Uma forma simples (mas não muito esperta) de chegar ao número correto seria ir tentando os
números de 1 a 100, um por um. Você consegue imaginar uma estratégia para tentar ganhar o jogo
mais rapidamente? Qual é o número máximo de tentativas necessárias para acertar o número na sua
estratégia?
257
Agora é a sua vez!
Faça com que o seu jogo faça a contagem das tentativas feitas pelo jogador para acertar o número
(por exemplo, imagine que o jogador tem 10 tentativas inicialmente, e a cada tentativa incorreta a
contagem é reduzida em 1). Quando se esgotarem as tentativas, o jogo deve avisar que o jogador
perdeu.
Agora você vai construir uma versão digital do conhecido jogo Pedra, Papel e Tesoura. A
origem deste jogo é controversa: alguns historiadores indicam sua origem no Japão do século
XIX, mas há relatos de jogos de mão semelhantes desde a dinastia Ming chinesa (1368 –
1644).
No modelo fornecido, você tem um exemplo de inicialização de um código a partir do evento
do pressionamento de uma tecla.
Agora é a sua vez!
1. Implemente o segundo jogador. Ele deve escolher pedra, papel ou tesoura usando outras
teclas convenientes. Considere que ambos os jogadores vão jogar usando o mesmo teclado!
2. Uma vez que ambos os jogadores façam suas jogadas, é preciso que o programa indique qual
dos jogadores que ganhou. Para construir sua estratégia de programação, responda: quais
são as possíveis configurações finais do jogo? Escreva todas as possibilidades no papel antes
de montar seu código.
3. Um efeito interessante é fazer o sprite da mão “entrar na tela” pela direita ou pela esquerda
quando o jogador indica sua jogada. Escolha os comandos adequados do Scratch para
implementar esse efeito e explique por escrito como você fez o sprite aparecer.
4. O segundo jogador pode ser o próprio computador! Monte uma estratégia para que o
computador escolha uma jogada aleatoriamente assim que o primeiro jogador faça sua
jogada. (dica: uma forma de fazer um sprite se comunicar com outro sprite é através do
anúncio de mensagens)
258
04
Condições para colisões e ações repetitivas
Objetivos
Exercitar a identificação de condições lógicas para teste em estruturas de decisão e em estruturas de
repetição
Competências abordadas
Alternar entre representações semióticas
Construir modelos descritivos e representativos
Conteúdo abordado
Estrutura de decisão
Estrutura de repetição
Operador lógico OU
Hoje vamos construir a mecânica básica de funcionamento de um jogo de ação do tipo
shooter (tiro). Hoje a variação mais popular desse tipo de jogo são os chamados FPS - firstperson shooters (tiro em primeira pessoa) mas os primeiros jogos desse tipo apresentavam o
jogador a partir de uma perspectiva externa.
Vamos fazer uma simulação de guerra. O nosso jogador é representado por um tanque azul,
que ficará posicionado no canto inferior esquerdo da tela. O tanque pode girar para a
esquerda e para a direita, mas não pode se movimentar.
O inimigo é representado por um tanque verde,
vem na direção do nosso jogador.
que surge vindo do terreno inimigo e
Para se defender, o nosso jogador pode disparar uma bala, que é lançada em linha reta na
direção em que o tanque está apontado.
Se a bala atingir o tanque verde inimigo, ele explode. Se a bala atingir o limite do terreno, ela
que explode.
O jogador perde se o tanque verde o atingir. Nesse caso, o tanque azul explode e uma
mensagem de “Fim de jogo” deve ser apresentada.
Questões para exploração
Escreva com suas palavras qual deve ser o algoritmo básico de movimentação da bala. Qual é a
condição que define quando a bala deve parar de se movimentar?
Agora escreva com suas palavras o algoritmo de movimentação do tanque verde. O que faz o tanque
259
verde parar de se movimentar?
Como implementar as situações acima no Scratch?
O tanque verde não pode surgir na tela sempre vindo na mesma direção do jogador, pois isso
deixaria o jogo muito fácil. Faça um algoritmo para que o tanque entre no terreno em direção ao
jogador vindo cada vez de um lugar diferente. Descreva seu algoritmo em termos das coordenadas
(x, y) do tanque.
Agora é a sua vez!
Uma vez que você implementar a mecânica básica descrita, temos algumas sugestões para você
melhorar seu jogo:
1. Faça com que, uma vez que o tanque verde exploda, ele volte a aparecer em uma outra
posição para atacar o jogador (como se fosse outro inimigo chegando, mas
reaproveitando o mesmo sprite ☺)
2. Defina um sistema de pontuação, considerando todas as situações em que o jogador
pode ganhar (ou perder) pontos. Escreva quais são as situações que você definiu.
260
05
Treinando condições para colisões e ações
repetitivas
Objetivos
Exercitar a identificação de condições lógicas para teste em estruturas de decisão e em estruturas de
repetição
Competências abordadas
Alternar entre representações semióticas
Construir modelos descritivos e representativos
Conteúdo abordado
Variáveis globais e locais
Estrutura de decisão
Estrutura de repetição
Arkanoid é um jogo lançado inicialmente em 1986 pela empresa japonesa Taito para
máquinas de fliperama. O objetivo é lançar uma bola que atinge e quebra tijolos, e que é
rebatida por uma plataforma horizontal (que, no enredo do Arkanoid, representa uma nave
espacial).
Vamos começar por uma versão do Arkanoid onde apenas a bola está implementada.
Questões para exploração
O que acontece quando a bola chega a uma das extremidades do palco? Qual é o comando Scratch
que define esse comportamento?
Se quisermos alterar a velocidade da bola, qual comando Scratch deve ser modificado?
Para que a bola toque a plataforma, quais são os possíveis valores para a sua direção, em graus? Faça
um desenho exemplificando possíveis direções da bola para que essa situação aconteça.
O que deve acontecer com a direção da bola assim que ela tocar a plataforma? Qual a relação entre a
nova direção da bola e sua direção original?
261
Agora é a sua vez!
Faça com que a bola se movimente junto com a plataforma antes de ser lançada pressionando-se a
barra de espaços
O jogo se inicia com três vidas. Se a bola ultrapassar o limite no qual pode ser alcançada pela
plataforma, o jogador perde uma vida e a bola volta a ser posicionada sobre a plataforma para ser
lançada novamente.
Implemente três tipos de blocos, com comportamentos diferentes:
5. O bloco amarelo
desaparece quando for atingido uma vez pela bola. Isso aumenta a
pontuação em 50 pontos.
6. O bloco verde
desaparece quando for atingido três vezes pela bola. Isso aumenta a
pontuação do jogo em 150 pontos e diminui a velocidade da bola (deixando o jogo mais
fácil).
7. O bloco vermelho
desaparece quando for atingido uma vez pela bola. Ele libera uma
cápsula
que desce na tela. Se a cápsula for tocada pela plataforma, o jogador ganha
uma vida adicional.
8. A bola deve ser rebatida quando atingir um bloco.
Sugestão: Depois de implementar os três blocos, você pode copiar seus sprites para ter vários blocos
na tela de jogo, deixando o jogo mais interessante.
262
06
Movimentação em labirinto – o jogo PacMan
Objetivos
Exercitar a identificação de condições lógicas baseadas em resto da divisão para a movimentação de
sprite em um grid; exercitar o uso de operadores lógicos em condições compostas por mais de uma
sentença lógica
Competências abordadas
Identificar regularidades e padrões
Construir modelos descritivos e representativos
Conteúdo abordado
Estrutura de decisão
Estrutura de repetição
Operadores lógicos E e NÃO
O jogo Pacman foi um dos jogos mais bem sucedidos da história. Lançado
inicialmente para máquinas arcade (fliperamas) em 1980, teve diversas
continuações. Ele foi desenvolvido pela empresa japonesa Namco durante
um ano e cinco meses por uma equipe de nove engenheiros liderados por
um jovem funcionário chamado Toru Iwatani (figura ao lado). A ideia de
construir um jogo que tivesse apelo junto ao público feminino usando um
tema não-violento – a comida – tomou forma quando Iwatani teve um
insight ao ver uma pizza faltando um pedaço.
Na mecânica do jogo o pacman percorre um labirinto para “comer” pontos brancos que
representam comida. Para permitir o posicionamento correto do personagem e sua
movimentação no labirinto, vamos começar com uma versão simplificada, onde o labirinto é
substituído por uma “grade” formada por linhas horizontais e verticais.
O centro do pacman deve estar sempre posicionado sobre uma linha horizontal ou vertical.
263
O pacman poderá se mover em quatro direções (para cima, para baixo, para a direita e para a
esquerda), sendo controlado pelas setas direcionais do teclado. Para garantir que ele sempre
esteja posicionado sobre uma linha, uma mudança de direção só pode ser permitida quando o
centro do pacman estiver sobre a intersecção de duas linhas, como na figura abaixo:
Seta para esquerda
pressionada
Questões para exploração
A grade é regular? Em outras palavras, há alguma regra de formação para o traçado de suas linhas?
A partir da resposta anterior, identifique qual condição expressa que o pacman está no meio de uma
intersecção e pode se mover. Escreva essa condição em linguagem natural. Como ela pode ser
“traduzida” em termos dos comandos do Scratch?
Considerando que o pacman não pode sair da grade (ou seja, do labirinto), qual a condição para
garantir que ele pode continuar em frente? Escreva essa condição em linguagem natural. Como ela
pode ser “traduzida” em termos dos comandos do Scratch?
Agora é a sua vez!
Defina uma posição inicial para o pacman e implemente os comandos necessários para sua
movimentação na grade, de acordo com as regras definidas acima.
264
07
Finalizando o jogo Pacman
Objetivos
Exercitar uso de operadores lógicos em condições compostas por mais de uma sentença lógica para
movimentação do personagem do jogo.
Competências abordadas
Identificar regularidades e padrões
Construir modelos descritivos e representativos
Conteúdo abordado
Operador lógico E
Variáveis booleanas
Na aula de hoje vamos finalizar a construção do jogo Pacman.
Para começar, vamos trocar o grid do palco pela labirinto “clássico” do Pacman. O desenho
dos corredores segue a geometria do grid original, assim nosso personagem irá se movimentar
adequadamente.
Na aula anterior, para garantir que o Pacman não se movimentasse fora dos limites do grid,
era suficiente verificar os valores das suas coordenadas x e y, já que qualquer caminho dentro
do grid era válido. Agora, com os limites impostos pelo labirinto, temos que utilizar um
“truque” para superar uma limitação do ambiente do Scratch, que é a verificação de uma
colisão além dos limites do sprite.
Crie um novo sprite com o traje disponibilizado no arquivo colisao.gif. O traje é composto
apenas por 4 pontos de cores diferentes. Se for possível manter esse novo Sprite sempre
acompanhando a posição do Pacman, será possível identificar quando o Pacman irá colidir
com uma parede do labirinto alguns passos antes do evento realmente ocorrer. Veja o
exemplo abaixo:
265
Quando o Pacman chega no limite do labirinto, a cor amarela e a cor azul do sprite de colisão
estão tocando na borda externa azul-escura do labirinto. Essa condição permite que o Pacman
pare de se movimentar, obrigando o jogador a fazer uma mudança de direção.
Implemente o seguinte código no sprite de colisão:
Vamos entender o seu funcionamento. Os quatro losangos azuis são quatro sensores de
colisão de cores, que verificam exatamente se algum dos quatro pontos do sprite de colisão
está tocando a cor azul-escura da borda do labirinto. Como eles são precedidos pelo comando
Vá para, o sprite de colisão estará sempre alinhado com o centro do sprite do Pacman.
Os sensores podem valer verdadeiro ou falso, e seus valores são atribuídos a cada uma das
quatro variáveis: tocando na direita, tocando na esquerda, tocando em cima ou tocando
embaixo. E, como os comandos estão dentro de um laço Sempre, o valor das variáveis estará
sempre atualizado.
Como padrão, as variáveis no Scratch são globais, ou seja, seu valor pode ser acessado no
código de qualquer sprite ou no código do palco.
Com os valores dessas quatro variáveis sempre atualizados, podemos ajustar a movimentação
do Pacman para as restrições de espaço do labirinto.
Questões para exploração
Qual deve ser o valor das variáveis: tocando na direita, tocando na esquerda, tocando em cima e
tocando embaixo em cada uma das situações abaixo?
Em cada uma das situações acima, quais dos seguintes movimentos do jogador são permitidos?
1. Virar para cima
2. Virar para baixo
3. Virar para a direita
4. Virar para a esquerda
Quando o jogador pressiona cada uma das setas do teclado (por exemplo, seta para cima), qual a
266
condição necessária para que o Pacman possa se mover naquela direção? Escreva a condição para
cada uma das quatro direções em linguagem natural. Como escrever essas condições usando os
comandos do Scratch?
Agora é a sua vez!
Faça com que o Pacman se movimente pelo labirinto respeitando as limitações das paredes. Ele deve
automaticamente se movimentar para frente, a menos que colida com uma parede. Quando o
jogador pressiona uma seta do teclado, o Pacman vira para a direção indicada, a menos que exista
uma parede naquela direção.
[Sugestão] Para que o sprite de colisão continue fazendo sua tarefa mas não apareça no labirinto,
você pode usar o comando
Crie um controle de pontuação para o jogo: cada vez que o Pacman colide com um “ponto de
energia” (círculo amarelo), ele deve somar mais um ponto.
Quando o Pacman chega ao final do túnel direito, no centro do labirinto, ele deve sumir e aparecer
na entrada do túnel da esquerda, e vice-versa. Essa é uma estratégia para o Pacman fugir dos
inimigos.
267
Apêndice D QUESTIONÁRIO DE LEVANTAMENTO DE PERFIL
Neste Apêndice é apresentado o questionário de levantamento de perfil dos
alunos aplicado nos primeiros encontros da Oficina de Produção de Jogos Digitais.
Os princípios da sua elaboração são descritos na seção 0 e os resultados da sua
aplicação são descritos na seção 0.
1. Escolha uma opção correspondente ao seu gênero:
(
) Masculino
(
) Feminino
2. Qual é a sua idade?
3. Qual o seu nível de escolaridade?
(
) Ensino fundamental completo
(
) Ensino médio incompleto
(
) Ensino médio completo
(
) Ensino superior incompleto
(
) Ensino superior completo
(
) Pós-Graduação incompleta
(
) Pós-Graduação completa
4. Qual o seu país de residência?
(
) Brasil
(
) Chile
5. Você joga jogos digitais?
(
) Sim
(
) Não
6. Quanto tempo, em média, você utiliza jogando por semana (horas)?
(
) menos de una hora semanal
(
) de 1 hora até 3 horas semanais
(
) acima de 3 horas até 5 horas semanais
(
) acima de 5 horas até 8 horas semanais
(
) acima de 8 horas até 12 horas semanais
268
(
) acima de 12 horas até 15 horas semanais
(
) mais de 15 horas semanais
7. Em que dia da semana você costuma jogar mais?
(
) Segunda
(
) Terça
(
) Quarta
(
) Sexta
(
) Sábado
(
) Domingo
(
) Quinta
8. Há quanto tempo você joga jogos digitais (considerando videogame,
computador, dispositivos móveis e outros)?
(
) menos de 1 ano
(
) de 1 até 3 anos
(
) de 3 até 6 anos
(
) de 6 até 9 anos
(
) acima de 9 anos
9. Que dispositivo você utiliza para jogar? (É possível selecionar mais de uma
opção)
(
) PC (desktop ou notebook)
(
) Console (PS3, Xbox, Wii)
(
) Arcade (máquinas de fliperama)
(
) Videogame portátil
(
) Celular, tablet e outros dispositivos móveis
10. Na escala abaixo, assinale a opção que corresponda à sua preferência em
relação a cada categoria de jogos abaixo.
Não gosto
Ação e aventura (ex.: Sonic, SuperMario)
Estratégia e tática (ex.: Starcraft, Warcraft,
League of Legends)
RPG: ex:(Ragnarok, World of Warcraft,
Minecraft, GTA)
Tiro em primeira pessoa (ex.: Counter Strike)
Corrida (ex.: Gran Turismo, Need for Speed)
Esportes (ex.: FIFA, Table Tennis)
Não gosto
muito
Neutro
Gosto um
pouco
Gosto
muito
269
Luta (ex.: Teken, Mortal Kombat)
Cartas (ex.: FreeCell, Pôquer)
Casuais (ex.: Angry Birds, Cut the Rope)
Simulação (Guitar Hero, Kinect, Nintendo
Wii)
11. Avalie os aspectos de qualidade para jogos apresentados abaixo e indique
o quanto cada um deles é importante para que você goste de um jogo. 1
indica que o aspecto não é importante de forma alguma para que você
goste do jogo, e 5 indica que o aspecto é fundamental para que você goste
do jogo.
1
2
3
4
5
Os controles do jogo são claros, confortáveis e com resposta
imediata
É possível customizar o áudio e vídeo do jogo
É fácil saber o status e pontuação do jogo
É possível desenvolver habilidade que vão ser úteis no jogo
futuramente
O jogo tem um tutorial para familiarizar o jogador
O visual do jogo é fácil de entender
É possível salvar o jogo para continuar depois
O layout e os menus são fáceis de entender
História rica e envolvente
Qualidade dos gráficos e trilha sonora
Atores e cenário realistas
Saber o objetivo principal do jogo logo no início
O jogo ter outros objetivos menores, além do objetivo principal
O jogo ter vários desafios que me permitam usar estratégias
diferentes
O ritmo do jogo acompanha minha capacidade de jogar (cansaço,
concentração)
O desafio do jogo é ajustado às minhas habilidades
Recompensa imediata e clara pelas minhas conquistas
Surpresas e desafios inesperados
O jogo oferecer dicas na medida certa
12. Considere, para cada um dos possíveis problemas abaixo, o quanto ele
faria você não gostar ou até desistir de um jogo. 1 indica que o problema
não faria você desistir, e 5 que o problema faria você desistir com certeza.
1
Os controles do jogo são claros, confortáveis e com resposta
imediata
É possível customizar o áudio e vídeo do jogo
É fácil saber o status e pontuação do jogo
É possível desenvolver habilidade que vão ser úteis no jogo
futuramente
O jogo tem um tutorial para familiarizar o jogador
2
3
4
5
270
O visual do jogo é fácil de entender
É possível salvar o jogo para continuar depois
O layout e os menus são fáceis de entender
História rica e envolvente
Qualidade dos gráficos e trilha sonora
Atores e cenário realistas
Saber o objetivo principal do jogo logo no início
O jogo ter outros objetivos menores, além do objetivo principal
O jogo ter vários desafios que me permitam usar estratégias
diferentes
O ritmo do jogo acompanha minha capacidade de jogar (cansaço,
concentração)
O desafio do jogo é ajustado às minhas habilidades
Recompensa imediata e clara pelas minhas conquistas
Surpresas e desafios inesperados
O jogo oferecer dicas na medida certa
271
Apêndice E LISTA DOS PARTICIPANTES DA OFICINA
Brasil – IFSP
ID
P1
P2
P3
P4
P5
P6
P7
P8
P9
P10
P11
P12
P13
P14
P15
P16
P17
P18
P19
P20
P21
P22
P23
P24
P25
P26
P27
P28
P29
P30
P31
P32
Gênero
M
F
M
M
F
M
M
F
F
F
M
M
M
M
M
F
M
F
M
F
M
M
M
F
F
M
M
F
M
M
M
M
Escolaridade
Cursando 2º ano do EM
Cursando 2º ano do EM
EM concluído há 10 anos
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 2º ano do EM
EM concluído há 4 anos
Cursando 3º ano do EM
Cursando 2º ano do EM
Cursando 3º ano do EM
Cursando 2º ano do EM
EM concluído há 15 anos
Cursando 2º ano do EM
EM concluído há 10 anos
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 3º ano do EM
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 2º ano do EM
Cursando 3º ano do EM
Cursando 2º ano do EM
Cursando 3º ano do EM
Cursando 3º ano do EM
Cursando 2º ano do EM
EM concluído há 1 ano
Cursando 2º ano do EM
Cursando 2º ano do EM
EM concluído há 1 ano
Nome fictício
Adriana
Lucas
Bianca
Benício
Breno
Camila
Denise
Diana
Fabrício
Guilherme
Jéssica
Guilherme
Isabel
Caio
José
Rafael
Paulo
Pedro
272
Chile – UV
ID
Gênero
P33
P34
P35
P36
P37
P38
P39
P40
P41
P42
P43
P44
P45
P46
P47
P48
P49
P50
P51
P52
P53
P54
P55
P56
P57
P58
P59
P60
P61
P62
P63
P64
P65
P66
P67
P68
P69
P70
P71
P72
P73
M
M
M
M
M
M
F
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
F
M
F
F
M
Escolaridade (tempo desde a
conclusão do E.M.)
2 anos
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
menos de 1 ano
1 ano
1 ano
2 anos
2 anos
1 ano
1 ano
4 anos
2 anos
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
1 ano
3 anos
8 anos
1 ano
1 ano
1 ano
3 anos
1 ano
2 anos
1 não
2 anos
1 ano
1 ano
Nome fictício
Andrés
Bruno
Flavio
Jorge
273
P74
P75
P76
P77
P78
P79
P80
P81
P82
P83
P84
P85
P86
M
F
F
M
M
M
M
M
M
M
F
M
M
1 ano
1 ano
1 ano
1 ano
2 anos
2 anos
1 ano
2 anos
1 ano
2 anos
2 anos
1 ano
1 ano
275
Apêndice F
ESTATÍSTICAS
DO
TESTE
DE
CONHECIMENTOS
MATEMÁTICOS
Neste Apêndice são descritas as estatísticas completas do teste de
conhecimentos matemáticos aplicado no início e no término da participação dos
alunos na Oficina de Produção de Jogos Digitais. A descrição das perguntas do
teste é apresentada na seção 0. Nas tabelas com as porcentagens de respostas
corretas a cada item, o valor representado em negrito se refere à alternativa certa
para a questão.
Pré-teste com alunos do Brasil – IFSP
Questão 1
Questão 2
Questão 3
Questão 4
Questão 5
Questão 6
Questão 7
Questão 8
A
0,0%
25,0%
75,0%
70,8%
0,0%
0,0%
8,3%
54,2%
B
25,0%
0,0%
16,7%
8,3%
0,0%
4,8%
25,0%
20,8%
C
0,0%
66,7%
4,2%
8,3%
0,0%
47,6%
16,7%
8,3%
D
66,7%
4,2%
0,0%
12,5%
100,0%
42,9%
0,0%
12,5%
45,8%
E
Não
respondeu
8,3%
4,2%
4,2%
0,0%
0,0%
4,8%
4,2%
4,2%
Pós-teste com alunos do Brasil – IFSP
Questão 1
Questão 2
Questão 3
Questão 4
Questão 5
Questão 6
Questão 7
Questão 8
A
4,2%
25,0%
79,2%
83,3%
0,0%
0,0%
0,0%
58,3%
B
8,3%
4,2%
12,5%
0,0%
0,0%
4,2%
4,2%
4,2%
C
4,2%
66,7%
4,2%
4,2%
0,0%
29,2%
29,2%
8,3%
D
83,3%
4,2%
4,2%
12,5%
100,0%
66,7%
12,5%
25,0%
54,2%
E
Não
respondeu
0,0%
0,0%
0,0%
0,0%
0,0%
0,0%
0,0%
4,2%
276
Pré-teste com alunos do Chile – UV
Questão 1
Questão 2
Questão 3
Questão 4
Questão 5
Questão 6
Questão 7
Questão 8
A
0,0%
0,0%
100,0%
84,0%
0,0%
4,0%
0,0%
52,0%
B
8,0%
0,0%
0,0%
0,0%
0,0%
0,0%
4,0%
4,0%
C
0,0%
100,0%
0,0%
4,0%
0,0%
52,0%
28,0%
4,0%
D
88,0%
0,0%
0,0%
8,0%
100,0%
36,0%
0,0%
16,0%
56,0%
E
Não
respondeu
4,0%
0,0%
0,0%
4,0%
0,0%
4,0%
12,0%
24,0%
Pós-teste com alunos do Chile – UV
Questão 1
Questão 2
Questão 3
Questão 4
Questão 5
Questão 6
Questão 7
Questão 8
A
0,0%
4,0%
96,0%
96,0%
0,0%
0,0%
4,0%
52,0%
B
0,0%
4,0%
0,0%
12,0%
0,0%
4,0%
0,0%
0,0%
C
0,0%
80,0%
0,0%
4,0%
0,0%
36,0%
12,0%
4,0%
D
96,0%
0,0%
4,0%
0,0%
100,0%
60,0%
0,0%
24,0%
84,0%
E
Não
respondeu
4,0%
12,0%
0,0%
0,0%
0,0%
0,0%
0,0%
8,0%