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%