Uso do Second Life no Suporte à Aprendizagem Contextualizada de Programação

Tese de Doutoramento apresentada por

Maria Micaela Gonçalves Pinto Dinis Esteves

Sob orientação do Professor Doutor Benjamim Fonseca e do Professor Doutor Leonel Morgado

Universidade de Trás-os-Montes e Alto Douro Escola de Ciências e Tecnologia Departamento de Engenharias 2010

Tese apresentada por Maria Micaela Gonçalves Pinto Dinis Esteves à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Doutor em Informática, sob orientação do Professor Doutor José Benjamim Ribeiro da Fonseca, Professor Auxiliar do Departamento de Engenharias, da Escola de Ciências e Tecnologia da Universidade de Trás-os-Montes e Alto Douro e co-orientado pelo Professor Doutor Leonel Caseiro Morgado, Professor Auxiliar do Departamento de Engenharias, da Escola de Ciências e Tecnologia da Universidade de Trás-os-Montes e Alto Douro.

i

Agradecimentos
A presente tese resultou do trabalho, esforço e dedicação da sua autora e do conjunto de pessoas que de alguma forma a incentivaram, apoiaram e colaboraram para que esta se concretizasse. Por isso pretendo expressar nesta nota o meu agradecimento a todos aqueles que directa ou indirectamente me ajudaram. Aos Professores Doutores Benjamim Fonseca e Leonel Morgado, orientadores desta tese, a quem expresso a minha gratidão e agradecimento, pelo precioso apoio na orientação e no incansável trabalho de acompanhamento prestado ao longo de todo este processo, sem os quais seria impossível concluí-lo com êxito. Aos professores Doutores Bulas Cruz e Paulo Martins pelo apoio constante na realização deste trabalho. Ao Professor Doutor António Pereira pelo carinho e incentivo manifestado ao longo desta jornada. Aos alunos que se voluntariaram para participar neste projecto, sem a sua disponibilidade este estudo não existiria. À Ivone Lopes e ao Luís Mendes pelo apoio e incentivo dado especialmente nas revisões do Inglês dos artigos e pelas sugestões interessantes que forneceram. Ao Instituto Politécnico de Leiria e à Escola Superior de Tecnologia e Gestão (ESTG) por todas as facilidades concedidas. Aos colegas do Departamento de Engenharia Informática da ESTG pela compreensão e apoio que sempre me ofereceram, em especial aos colegas do grupo dos mundos virtuais, nomeadamente ao Ricardo Antunes, pelo suporte e incentivo nesta longa caminhada. A toda a minha família em especial ao Manuel, Simão e Tiago não apenas pela compreensão, apoio e incentivo, mas essencialmente por todo o tempo de convívio que lhes roubei para concretizar esta tese. Finalmente, os meus agradecimentos a todos aqueles que das mais variadas formas ofereceram contributos para que o desenvolvimento deste trabalho fosse possível. A todos agradeço sinceramente. ii

iii

Resumo
Nesta tese apresenta-se o trabalho desenvolvido cujo objectivo consistiu na análise do modo como o ensino e a aprendizagem introdutória da programação, a alunos nos primeiros anos de cursos de informática do ensino superior, pode ser desenvolvido dentro de um mundo virtual tridimensional online. Neste contexto, efectuou-se a revisão da literatura, discutindo-se as questões das teorias de aprendizagem e respectivas metodologias, nas quais se destaca a aprendizagem baseada em problemas, bem como, a problemática da aprendizagem da programação e dos mundos virtuais tridimensionais online, com o intuito de fundamentar a opção pelo mundo virtual adoptado. O estudo realizado no contexto desta tese foi regido pela metodologia investigaçãoacção, tendo a autora desempenhado os papéis de investigadora e de professora. No trabalho de campo, que decorreu desde Março de 2007 até Julho de 2008, abrangendo o 2º semestre do ano lectivo 2006/2007 e o 1º e 2º semestres do ano lectivo 2007/2008, foi utilizado o mundo virtual Second Life®. Os resultados demonstram que é possível usar este mundo para o ensino e aprendizagem da programação nos primeiros anos de cursos de informática do ensino superior. Os principais resultados atingidos foram a identificação de problemas que dificultam a intervenção do professor neste mundo virtual e a detecção de soluções eficazes para permitir a utilização deste mundo como plataforma viável para o ensino e aprendizagem da programação de computadores. É ainda apresentada uma proposta de um modelo que consolida os resultados integrandoos num conjunto de factores relevantes para o ensino e aprendizagem de programação de computadores nestes mundos, no contexto dos primeiros anos dos cursos de informática do ensino superior.

Palavras-chave: aprendizagem da programação; ambientes virtuais colaborativos; investigação-acção; mundos virtuais; Second Life; aprendizagem baseada em problemas.

iv

v

Abstract
This thesis’ presents an analysis of how teaching and learning an introductory computer programming at the university level could be developed within three-dimensional virtual worlds. In this context, a revision of literature was made, the learning theories and methods were presented and discussed, in which the problem-base learning was highlighted; the difficulties reported in learning and teaching to programming; as well as the review of the three-dimensional virtual worlds in order to substantiate the option made. This research adopted an action research methodology to the analysis of how teaching and learning of computer programming at the university level could be developed within the Second Life virtual world. Four cycles were employed in this study, from March 2007 to July 2008. Pre-exploratory research took place during the second semester of the academic year 2006/2007, the first and second cycles of action research during the first semester of 2007/2008, and the third and fourth cycles in the second semester of that same academic year. Results support the notion that it is possible to use this environment for a better effectiveness in the learning of programming. The main results were the identification of problems hampering the teacher’s intervention in this virtual world and the detection of solutions for those problems that were found effective to the success in using this environment for teaching-learning computer programming. It was also proposed a framework for teaching-learning computer programming in these worlds, by highlighting the factors that emerged as relevant in the analysis made.

Keywords: learning programming; collaborative virtual environments; action research; virtual worlds; Second Life; project-based learning.

vi

vii

Índice
1. Introdução ............................................................................................................................ 2 1.1. 1.1. 1.2. 1.3. 2. 2.1. 2.1.1. Fundamentos da escolha do tema ........................................................................... 4 Abordagem ao problema .......................................................................................... 5 Objectivos e contributos fundamentais.................................................................. 7 Estrutura da tese ........................................................................................................ 8 Teorias de aprendizagem ........................................................................................ 12 Behaviorismo ..................................................................................................... 12

Aprendizagem – fundamentos teóricos.......................................................................... 10

2.1.1.1. Ivan Pavlov ................................................................................................ 12 2.1.1.2. John Broadus Watson .............................................................................. 13 2.1.1.3. Burrhus Frederic Skinner ........................................................................ 14 2.1.2. Construtivismo/Cognitivismo ........................................................................ 14 2.1.2.1. Jean Piaget.................................................................................................. 15 2.1.2.2. Lev Vygotski .............................................................................................. 17 2.1.2.3. Jerome Bruner ........................................................................................... 18 2.1.3. Teoria da aprendizagem situada ...................................................................... 20 2.2. 2.2.1. Metodologias de aprendizagem ............................................................................. 21 Aprendizagem baseada em problemas ........................................................... 22

3.

2.2.1.1. A implementação da PBL........................................................................ 23 2.2.1.2. O papel do professor e dos alunos na PBL .......................................... 25 Ensino da Programação .................................................................................................... 26 3.1. 3.2. 3.3. 3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5. 3.3.6. 3.3.7. 3.3.8. 3.3.9. 3.3.10. 3.3.11. Programar, o que è? ................................................................................................. 28 Dificuldades na aprendizagem da programação .................................................. 29 Soluções propostas na literatura para o ensino da programação ...................... 39 Programação modular ...................................................................................... 40 Abordagem gramatical ..................................................................................... 41 Abordagem em espiral...................................................................................... 41 Protocolo “pensar em voz alta”...................................................................... 42 Programação de jogos ...................................................................................... 42 Programar do concreto para o abstracto ....................................................... 43 Padrões de programação .................................................................................. 43 Programação aos pares ..................................................................................... 44 Programação por exemplos ............................................................................. 46 Abordagem “bricolage” ................................................................................... 46 Sistemas de suporte ao ensino da programação ........................................... 47 viii

3.4. 3.4.1.

Ferramentas de suporte ao ensino da programação ........................................... 47 Ferramentas de animação ................................................................................ 48

3.4.1.1. Ferramentas de animação de algoritmos............................................... 48 3.4.1.2. Ferramentas de animação de programas............................................... 51 3.4.1.3. Discussão ................................................................................................... 53 3.4.2. Mundos programáveis...................................................................................... 56 3.4.2.1. Discussão ................................................................................................... 57 3.4.3. Ambientes de desenvolvimento controlado ................................................. 58 3.4.3.1. BlueJ ........................................................................................................... 58 3.4.3.2. Alice............................................................................................................ 59 3.4.3.3. Discussão ................................................................................................... 61 3.5. A programação e os mundos virtuais ................................................................... 63 4. Mundos Virtuais ................................................................................................................ 68 4.1. 4.1.1 4.1.2 4.1.3 4.2. 4.3. 4.3.1 4.3.2 4.3.4 4.3.5 4.3.6 4.4. 5. 5.1. 5.2. 5.3. 5.4. 5.5. 5.5.1 5.5.2 6. 6.1. 6.2. Caracterização dos mundos virtuais ..................................................................... 70 Representação física ......................................................................................... 71 Interactividade ................................................................................................... 73 Persistência ........................................................................................................ 77 Os antecessores dos mundos virtuais ................................................................... 78 Categorização dos mundos virtuais ...................................................................... 82 Mundos virtuais de competição...................................................................... 84 Mundos virtuais sociais .................................................................................... 85 Mundos virtuais de formação ......................................................................... 92 Plataformas de desenvolvimento ................................................................... 92 Mundos virtuais profissionais ......................................................................... 95 Mundo virtual adoptado ......................................................................................... 96 Introdução ao Second Life................................................................................... 100 Avatares no SL ....................................................................................................... 102 Comunicação.......................................................................................................... 105 Construção de objectos 3D ................................................................................. 109 Programar no Second Life ................................................................................... 117 Como se desenvolve um programa no SL .................................................. 117 A linguagem de programação LSL ............................................................... 119 Opções metodológicas.......................................................................................... 126 O que é a investigação-acção? ............................................................................. 128 ix

Second Life......................................................................................................................... 98

Metodologia de investigação.......................................................................................... 124

6.2.1 7. 7.1. 7.2. 7.3. 7.3.1. 7.3.2. 7.3.3. 7.3.4. 7.4. 7.5. 7.5.1. 7.5.2.

Estrutura metodológica da investigação-acção ........................................... 129 Sumário ................................................................................................................... 136 Participantes............................................................................................................ 138 Recolha da informação ......................................................................................... 140 Relatórios diários............................................................................................. 140 Registos electrónicos ...................................................................................... 141 Questionários................................................................................................... 141 Entrevistas........................................................................................................ 142 Análise da informação ........................................................................................... 143 Preparação da intervenção preliminar ................................................................ 144 Caracterização dos alunos .............................................................................. 145 Projectos propostos ........................................................................................ 146

Aplicação do método de investigação .......................................................................... 134

7.5.2.1. Projecto de Lab. I ................................................................................... 147 7.5.2.2. Projecto de Lab. III ................................................................................ 148 7.5.3. Procedimento .................................................................................................. 148 7.5.4. 7.5.5. 7.6. 7.6.1. 7.6.2. 7.6.3. 7.6.4. 7.7. 7.7.1. 7.7.2. 7.8. 7.8.1. 7.8.2. 7.9. 7.10. Metodologia a usar nas aulas ......................................................................... 150 Plano da aula .................................................................................................... 152 Resultados e reflexões da fase preliminar........................................................... 152 Início da programação – Lab. I..................................................................... 154 Aulas de Lab. III ............................................................................................. 157 Professora......................................................................................................... 158 Questionários................................................................................................... 160 Plano do 1.º ciclo de investigação-acção ............................................................ 162 Caracterização dos alunos .............................................................................. 162 Planeamento das aulas .................................................................................... 163 Resultados e reflexão do 1.º ciclo ........................................................................ 167 Programação alunos de Lab. II ..................................................................... 168 Alunos de Proj. I ............................................................................................. 171 Plano do 2.º ciclo de investigação-acção ............................................................ 173 Resultados e reflexões do 2.º ciclo ...................................................................... 173 Professora......................................................................................................... 176 Questionários................................................................................................... 178

7.10.1. 7.10.2. 7.11. 7.12.

Plano do 3.º ciclo de investigação-acção ............................................................ 180 Resultados e reflexões do 3.º e 4.º ciclos de investigação-acção ..................... 183 x

7.12.1. 7.13. 8. 8.1. 8.1.1. 8.1.2. 8.1.3.

Questionários .................................................................................................. 188

Conclusão do projecto de investigação .............................................................. 189 Análise e discussão dos resultados ...................................................................... 192 Comunicação ................................................................................................... 192 Projecto ............................................................................................................ 195 Processo de aprendizagem ............................................................................ 198 Dificuldades dos alunos......................................................................... 198 Motivação dos alunos em participar neste projecto .......................... 204 Avaliação feita pelos alunos ao SL ....................................................... 205

Análise dos resultados .................................................................................................... 190

8.1.3.1. 8.1.3.2. 8.1.3.3. 8.1.4. 9.

O processo de ensino no SL ......................................................................... 208

Proposta de um modelo para o ensino da programação de computadores em 9.1. 9.2. 9.2.1. 9.2.2. 9.2.3. 9.2.4. Proposta de um modelo ....................................................................................... 214 Linhas orientadoras para o ensino da programação utilizando o SL ............. 214 Suporte técnico e emotivo............................................................................. 215 Contexto lúdico para a programação ........................................................... 219 A importância dos exemplos ........................................................................ 223 Comunidade que enfatiza a aprendizagem.................................................. 224 Conclusões.............................................................................................................. 232 Considerações finais e propostas de trabalho futuro ....................................... 234 Referências Bibliográficas ......................................................................................... 236 Anexos I ...................................................................................................................... 274 Anexos II..................................................................................................................... 278 Anexos III ................................................................................................................... 292 Anexos IV ................................................................................................................... 316 Anexos V ..................................................................................................................... 320

mundos virtuais ........................................................................................................................ 212

10. 10.1. 10.2. 11. 12. 13. 14. 15. 16.

Conclusões .................................................................................................................. 230

xi

Índice de Figuras
Figura 2.1: Diferença entre o Behaviorismo e o Construtivismo. ...................................... 15 Figura 3.1: Ambiente de programação Eclipse IDE............................................................. 38 Figura 3.2: Exemplo de um padrão para a estrutura de repetição while. ........................... 44 Figura 3.3: Exemplo da animação de um algoritmo no sistema Algorithma 98, representado na figura da esquerda e no sistema ANIMAL na figura da direita. ............ 49 Figura 3.4: Exemplo do sistema MatrixPro. .......................................................................... 50 Figura 3.5: Ambiente de trabalho do SICAS. ........................................................................ 51 Figura 3.6: Ambiente do animador de programas da Webworks. ...................................... 52 Figura 3.7: Ambiente de trabalho do Jeliot 3. ........................................................................ 53 Figura 3.8: Um exemplo do mundo de o Karel the robot. .................................................. 57 Figura 3.9 : Ambiente de trabalho do BlueJ. .......................................................................... 59 Figura 3.10: O ambiente de trabalho do Alice. ...................................................................... 60 Figura 3.11: Uma imagem de um mundo virtual criado com o Alice 3. ............................ 61 Figura 4.1: Avatares do Habitat. .............................................................................................. 71 Figura 4.2: À esquerda: avatar da investigadora no SL, “Micaela Korobase”. À direita: um avatar do mundo virtual NeoPets. .................................................................................... 72 Figura 4.3: À esquerda: edição do aspecto visual do avatar da autora no mundo virtual The Palace. À direita: edição da aparência de um avatar no mundo virtual MTV’s Virtual Worlds – The Virtual Hills. ...................................................................................................... 73 Figura 4.4: Mapa de algumas áreas do Second Life, referenciando, nos pontos verdes, o número de pessoas que se encontram em cada zona. .......................................................... 74 Figura 4.5: Exemplo de interacção com outro avatar do mundo Thinking Worlds. ....... 75 Figura 4.6: Exemplo de uma converção textual pública com vários avatares em simultâneo no mundo virtual MTV......................................................................................... 75 Figura 4.7: Exemplo de uma conversa privada no Entropia Universe. ................................. 76 Figura 4.8: Seminário Ambientes Virtuais 3D em Educação na ilha da Universidade de Aveiro no SL............................................................................................................................... 77 Figura 4.9: O interface do Jogo MUD textual. ...................................................................... 79 Figura 4.10: O interface do Meridian 59................................................................................. 81 Figura 4.11: À esquerda: aspecto gráfico do Ultima Online original. À direita: aspecto actual. ........................................................................................................................................... 82 Figura 4.12: Exemplos de mundos virtuais de competição: Lineage II na imagem da esquerda, World of Warcraft na imagem à direita................................................................. 84 xii

Figura 4.13: Exemplo de uma conversa textual pública; ..................................................... 86 Figura 4.14:Um avatar a experimentar roupa. ....................................................................... 87 Figura 4.15: Exemplo de uma conversa textual entre dois amigos no Frenzoo. ............. 88 Figura 4.16: O browser do Active Worlds Educational Universe. ..................................... 89 Figura 4.17: Na imagem da direita uma réplica da Praça do Comércio de Lisboa no SL; Na imagem da esquerda uma réplica do Museu Nacional dos Coches no SL. ................ 90 Figura 4.18: Jogo America’s Army. ......................................................................................... 92 Figura 4.19: Mundo virtual criado no OpenCroquet para apoio ao ensino da programação orientada a objectos........................................................................................... 94 Figura 5.1: Aspecto geral do viewer do Second Life. ........................................................... 100 Figura 5.2: Ilha no SL, durante a noite na qual se pode observar um belo céu estrelado. .................................................................................................................................................... 102 Figura 5.3: Na imagem da esquerda, apresenta o terreno alugado pela autora, para dar início às suas actividades. Na imagem da direita, a ilha da Universidade de Aveiro. ..... 103 Figura 5.4: O avatar da autora a editar a sua aparência no SL. ......................................... 104 Figura 5.5: O inventário de um avatar no SL. ..................................................................... 104 Figura 5.6: Exemplo de uma conversa pública entre vários avatares............................... 105 Figura 5.7: Exemplo de uma conversa privada entre dois avatares. ................................ 106 Figura 5.8: Exemplo de um cartão do SL. ........................................................................... 107 Figura 5.9:Exemplos de telas de informação no SL. .......................................................... 108 Figura 5.10: Objectos usados para transmitir pequenas mensagens no SL..................... 108 Figura 5.11: Editor de objectos no SL, no qual se observa o nome do dono e do criador da cúpula azul. .......................................................................................................................... 110 Figura 5.12: A janela do editor que permite construir e alterar as propriedades dos objectos. .................................................................................................................................... 111 Figura 5.13 : O menu redondo, designado de pie menu, na imagem da direita; na imagem da esquerda, a janela inicial do editor de construção, com as várias prims que se podem seleccionar................................................................................................................................. 112 Figura 5.14: A edição de uma prim no qual se pode observar os eixos direccionais a vermelho, verde e azul. ........................................................................................................... 113 Figura 5.15: Objectos que auxiliam na rotação, na imagem da esquerda, e no aumento do objecto, na imagem da direita........................................................................................... 113

xiii

Figura 5.16: Manipulação do zoom no SL. Na imagem da esquerda, a visualização do objecto sem o zoom activo. Na imagem da direita, zoom in, no qual se observa em pormenor o olho da boneca. .................................................................................................. 114 Figura 5.17: Editor de objectos, no qual se pode observar as permissões que se podem atribuir ao objecto criado. ....................................................................................................... 116 Figura 5.18: A construção colaborativa de um piano no Second Life. ............................ 116 Figura 5.19: Desenvolvimento de programas no SL. ......................................................... 118 Figura 5.20: Editor de programas no SL. ............................................................................. 118 Figura 5.21: Lista de funções pré-definidas do LSL. .......................................................... 121 Figura 5.22: A execução do código anterior no SL. ............................................................ 124 Figura 6.1: Metodologia de investigação-acção. .................................................................. 131 Figura 7.1: Esquema da metodologia investigação-acção efectuada neste estudo. ........ 137 Figura 7.2: Diagrama temporal desta investigação .............................................................. 138 Figura 7.3: Exemplo de objectos que se podem criar no Second Life: o sistema solar (imagem à esquerda) e um carro (imagem à direita). .......................................................... 147 Figura 7.4: Imagem do terreno no SL onde os alunos desenvolveram as suas actividades. .................................................................................................................................................... 149 Figura 7.5: Imagem do interior da sala.................................................................................. 149 Figura 7.6: Objectos criados pelos alunos no decorrer desta actividade. Na imagem, à esquerda, o conjunto de robôs, à direita um cão. ................................................................ 154 Figura 7.7: Objectos criados pelos alunos no decorrer desta actividade. O comboio, os apeadeiros, respectivas cidades e fábricas............................................................................. 154 Figura 7.8: Aspecto do monitor da professora durante uma aula, na qual a professora está a analisar o código de um aluno. .................................................................................... 156 Figura 7.9: Lista das mensagens trocadas numa aula: as setas vermelhas indicam as mensagens dos objectos; as verdes da professora e as amarelas dos alunos. .................. 159 Figura 7.10: Espaço de aula no SL com zonas demarcadas para cada grupo de alunos, a vermelho a zona de exposição. .............................................................................................. 166 Figura 7.11: Objecto de dúvidas para ser usado fora das aulas. ........................................ 167 Figura 7.12: Lista das funções existentes no LSL................................................................ 171 Figura 7.13: Ilustra o ecrã da professora durante as aulas.................................................. 177 Figura 7.14: Imagem de um dos trabalhos desenvolvidos. ................................................ 183 Figura 7.15: Reunião geral sobre o projecto. ....................................................................... 184

xiv

Figura 7.16: Objectos com mensagens para os alunos relembrarem o que tinham de fazer. .......................................................................................................................................... 187 Figura 8.1: Exemplos das mensagens de erro geradas pelo compilador de LSL. Na imagem da esquerda falta no código uma chaveta { na linha 11 e na da direita falta um ponto-e-vírgula ; na linha 12. ................................................................................................. 199 Figura 8.2: Exemplo da pirâmide, sobre estruturas de decisão e canal de comunicação, para os alunos testarem e alterarem. ..................................................................................... 203 Figura 8.3: Código em LSL, que cada uma das pirâmides executa................................... 204 Figura 9.1: Espaço utilizado nas aulas de programação durante os 1.º e 2.º ciclos de investigação-acção. .................................................................................................................. 218 Figura 9.2: Espaço utilizado nas aulas de programação durante os 3.º e 4.º ciclos de investigação-acção. .................................................................................................................. 219 Figura 9.3: Um dos alunos de Lab. III a exibir os seus objectos. ..................................... 225

xv

Índice de Tabelas
Tabela 4.1: Características dos mundos virtuais sociais........................................................ 91 Tabela 4.2: Características dos mundos virtuais de formação. ............................................ 95 Tabela 5.1: Tabela com os tipos de dados existentes na linguagem de programação LSL. .................................................................................................................................................... 122 Tabela 7.1: Número de alunos que participaram em cada fase desta investigação e respectivas disciplinas. ............................................................................................................. 139 Tabela 7.2: Linguagens de programação já estudadas ou em estudo pelos alunos......... 146 Tabela 7.3: Resumos das constatações da actividade preliminar. ..................................... 162 Tabela 7.4: Linguagens de programação já estudadas ou em estudo pelos alunos......... 163 Tabela 7.5: Resumo das constatações do 1.º ciclo de IA. .................................................. 172 Tabela 7.6: Resumo das observações do 2.º ciclo de IA. ................................................... 178 Tabela 7.7: Resumo das observações do 3.º e 4.º ciclos de IA. ......................................... 188 Tabela 9.1: Modelo para o ensino / aprendizagem da programação de computadores dentro do Second Life. ............................................................................................................ 228

xvi

xvii

Acrónimos
ACM ANIMAL AWEU BALSA BASIC CAT CET COBOL ENIAC ESTG Fortran IA IDE IDSV JHAVÉ Lab I Lab II Lab III LSL MMOG MMORPG MUD MV3D OLIVE PBL PILOT SDK SL SMS TANGO Association for Computer Machinery A New Interactive Modeller for Animations in Lectures Active Worlds Educational Universe Brown ALgorithm Simulator and Animator Beginners All-purpose Symbolic Instruction Code Collaborative Active Textbook Curso Técnico Pós-secundário COmmon Business Oriented Language Electrical Numerical Integrator and Calculator Escola Superior de Tecnologia e Gestão IBM mathematical FOrmula TRANslation system Investigação-Acção Integrated Development Environment Interactive Data Structure Visualization Java-Hosted Algorithm Visualization Environment Laboratório de informática I Laboratório de informática II Laboratório de informática III Linden Scripting Language Massively Multiplayer Online Games Massively Multiplayer Online Role Player Game Multi User Dungeon Mundo Virtual tridimensional On-Line Interactive Virtual Environment Problem-Based Learning Platform-Independent Learning Online Tool Sofware Development Kits Second Life Short Message Service Transition-based ANimation GeneratiOn

xviii

UO UTAD UUI

Ultima Online Universidade de Trás-os-Montes e Alto Douro Universally Unique Identifier

xix

1. Introdução
No presente capítulo introduz-se o tema desta tese, definindo o problema em questão, especificando-se os objectivos a alcançar e os contributos resultantes deste trabalho. Apresenta-se, ainda, a estrutura da tese.

Capítulo I: Introdução

3

Capítulo I: Introdução

1.1. Fundamentos da escolha do tema
Desde o início da sua carreira profissional que a autora tem estado ligada ao ensino da programação, tendo-se iniciado nessa actividade no ensino secundário e actualmente no ensino superior. Ao longo destes anos tem vindo a observar os problemas / dificuldades que os alunos e professores enfrentam no seu dia-a-dia, razão pela qual se dedicou à sua investigação. Com o surgimento do primeiro computador por volta de 1945, tem-se vindo a assistir a uma crescente proliferação deste em todos os sectores da actividade humana. Devido à rápida evolução tecnológica do último século e primeira década do actual, como, por exemplo, o aumento da capacidade de cálculo, a transmissão instantânea dos dados e a incrível precisão das operações, constata-se que o computador é um instrumento imprescindível. Tornou-se de tal maneira uma máquina de uso corrente que é praticamente impossível não se tomar consciência da sua presença. Mas, afinal, o que é um computador? É uma máquina que processa dados e executa sobre eles, com uma cadência muito rápida, sequências de operações elementares, a partir de informação inserida através de dispositivos de entrada, geralmente o teclado, quando essa informação provém directamente de seres humanos (Rocha, 2008). Mais concretamente, é uma máquina programável, em que as tarefas a desempenhar lhe são fornecidas através de um programa, consistindo numa sequência de operações elementares, que pode ser alterada ou substituída por outra sempre que se deseje. Por ser este aspecto de máquina programável a característica-base do que constitui um computador, a programação é considerada uma técnica elementar em qualquer curso da área científica das Ciências Informáticas. Contudo, a programação está igualmente presente na generalidade dos cursos de engenharia e de outras ciências, fazendo, por isso, parte dos currículos destes cursos uma ou mais disciplinas de Ciências e Tecnologia da Programação (Rocha, 2006). No caso de cursos que exijam conceitos sólidos de programação e de desenvolvimento de software é normal que o seu estudo seja feito através de várias disciplinas. As primeiras disciplinas de programação aparecem normalmente logo no início da generalidade dos cursos superiores de informática e áreas afins. Contudo, os alunos que iniciam o estudo de uma linguagem de programação sentem muitas dificuldades na sua 4

Capítulo I: Introdução aprendizagem. A consulta das actas das principais conferências mundiais na área de Computer Science Education como, por exemplo, as patrocinadas pela Association for Computer Machinery (ACM), revelam que estas dificuldades são comuns a muitos países e instituições de ensino (Gray, Goldberg e Byrnes,1993; Jenkins, 2002; Hawi, 2010). Este facto tem motivado a investigação por parte da comunidade científica, que procura identificar factores que contribuem para estas dificuldades, tendo como objectivo procurar e encontrar formas de as minorar ou ultrapassar (Lahtinen et al., 2005; Rodger et al., 2010), como se descreve mais aprofundadamente no capítulo 3.

1.1.Abordagem ao problema
A educação e a formação ao longo da vida constituem formas de aprender e de viver que enriquecem o ser humano e dinamizam o desenvolvimento da sociedade. A preocupação com a promoção de uma cultura que valorize a educação e a formação desafia educadores e investigadores a procurarem estratégias que possam colaborar no desenvolvimento efectivo de cada pessoa ao longo da vida (Miranda, Morais e Dias, 2007). Neste sentido e com a crescente evolução das tecnologias de informação e comunicação e das diversas potencialidades que lhes estão associadas, o conceito de ambiente de aprendizagem adquiriu novas dimensões, deixando de estar associado a um intervalo temporal ou a um espaço físico bem definidos, para assumir novas variáveis assentes não só nas características tecnológicas, mas também na flexibilidade temporal e espacial, podendo cada pessoa desfrutar de ferramentas cognitivas de aprendizagem, geralmente, a qualquer hora e em qualquer lugar. Durante a última década, várias tecnologias foram desenvolvidas e adaptadas para ambientes de aprendizagem, entre elas os mundos virtuais a três dimensões (3D). Por “mundo virtual 3D”, considera-se, no âmbito desta tese, sistemas informáticos que disponibilizam uma realidade virtual acessível em rede a vários utilizadores, geralmente a partir de aplicações instaladas em computadores pessoais. Estas aplicações disponibilizam vários elementos fundamentais de interacção, nomeadamente, a ilusão de um espaço 3D onde os utilizadores estão inseridos; avatars, que são representações virtuais dos utilizadores; e várias formas para os utilizadores comunicarem entre si (Leonel, 2009). Neste âmbito, entre os mundos virtuais 3D mais populares, encontramse o Everquest (2006), o World of Warcraft (2006), o Habbo Hotel (2006), o There (2006) e o Second Life (2006), descritos no capítulo 4. 5

Capítulo I: Introdução Uma das vantagens de utilizar um mundo virtual 3D para o ensino da programação é a possibilidade que os aprendizes têm de ver um objecto ou colocá-lo sob múltiplas perspectivas, que podem gerar uma melhor compreensão dos conceitos (Bricken e Byrne, 1994). O trabalho de Dede (1995) vem reforçar esta ideia de que um mundo virtual 3D oferece muitos benefícios, tais como a oportunidade de experimentar sem a repercussão do mundo real, a oportunidade de aprender fazendo e a possibilidade de personalizar o ambiente. Esta contextualização do conhecimento permite ao aprendiz ter uma experiência não simbólica e na primeira pessoa de alguns conceitos. Embora os mundos virtuais sejam relativamente recentes, já estão a ser usados como um meio pedagógico, permitindo criar um ambiente 3D rico para contextualizar a aprendizagem; sistemas de comunicação para apoiar a discussão e a colaboração; tirar partido da integração Web que fornece em tempo real recursos e ferramentas para pesquisar informação, como se refere no capítulo 3. Na literatura encontram-se alguns defensores de que os mundos virtuais, vistos como ambientes virtuais de aprendizagem, são o meio no qual se estabelece uma maior ligação interactiva entre o utilizador e o computador (Schroeder, 1996; Prensky, 2001; Slator, Hill, Del Val, 2004; Danilicheva, 2010). Esta ligação prende-se com a sua capacidade de motivar, de envolver os utilizadores, de ajudar a memorizar e a relembrar, e podem também encorajar o desenvolvimento de várias habilidades sociais e cognitivas. Por outro lado, vários autores (Carmen et al., 2010; Valdivia, Nussbaum e Ochoa, 2009) referem os benefícios da aprendizagem colaborativa, uma vez que alunos têm que explicar, justificar e argumentar as suas ideias aos outros. O uso dos mundos virtuais fomenta a colaboração e a aprendizagem construtivista por permitir uma comunicação em tempo-real juntamente com um ambiente visual e recursos de apoio à colaboração (Dickey, 2005; Attasiriluk et al., 2009). Face ao exposto, pretende-se analisar as características do uso dos mundos virtuais tridimensionais para minimizar as dificuldades sentidas pelos alunos no seu processo de aprendizagem da programação de computadores. Mais concretamente, pretende-se utilizar um mundo virtual 3D de aprendizagem colaborativa para proporcionar um ambiente visual contextualmente rico, imergindo os alunos num mundo onde estes podem individual ou em grupo interagir e manipular a informação disponibilizada.

6

Capítulo I: Introdução

1.2. Objectivos e contributos fundamentais
O objectivo primordial deste trabalho foi explorar as possibilidades e dificuldades da utilização dos mundos virtuais 3D online como plataforma para o ensino e aprendizagem introdutória da programação de computadores a alunos do ensino superior. Pretendeu-se analisar as características destes mundos quando utilizados em processos de ensino e aprendizagem de programação, estudando e analisando os próprios processos, como se desenvolvem, que tipos de apoios tecnológicos e metodológicos requerem, que limitações e vantagens apresentam, tendo sempre em vista possibilitar uma aprendizagem efectiva. De forma simples, verificar quais as dificuldades e as facilidades de dar aulas e acompanhar os alunos no desenvolvimento dos seus trabalhos nestes mundos. Pretendeu-se também, com o trabalho apresentado nesta tese, definir um modelo para o ensino e aprendizagem da programação de computadores nestes mundos virtuais 3D. De forma a cumprir as finalidades propostas, foi necessário estabelecer um conjunto de objectivos parcelares que se apresentam de seguida: Identificar e caracterizar os aspectos fundamentais da realidade complexa do ensino e aprendizagem da programação de computadores e dos ambientes de programação utilizados no seu suporte; Efectuar um estudo sobre o estado da arte dos mundos virtuais, onde deve ser dada uma atenção especial às características que estes possuem que permitam a sua utilização como plataforma para o ensino e aprendizagem da programação. O levantamento do estado das características dos mundos virtuais revestiu-se da maior importância no sentido de seleccionar um deles para ser usado neste estudo; Efectuar um estudo rigoroso de como os processos de ensino e aprendizagem da programação se desenrolam dentro do mundo virtual escolhido; Identificar e caracterizar os factores considerados relevantes no ensino e aprendizagem da programação de computadores nos mundos virtuais 3D, de modo a disponibilizar um modelo de apoio à sua utilização como plataforma.

7

Capítulo I: Introdução O presente trabalho oferece um modelo de suporte às actividades de ensino e aprendizagem da programação, contribuindo, deste modo, para melhorar a aprendizagem da programação no ensino superior, procurando também ajudar os professores a tirar partido dos mundos virtuais 3D para contextualizar o ensino da programação, com a ambição de poder eventualmente minorar, desta forma, o insucesso que actualmente se verifica. A melhor compreensão do processo de ensino e aprendizagem da programação nestes mundos virtuais é um caminho para a sua utilização nas aulas de introdução à programação. Ao analisar se as dificuldades de utilização destes mundos virtuais para o ensino e aprendizagem da programação podem ser superadas e como, constituiu-se uma base que permite efectuar estudos tanto qualitativos como quantitativos para determinar o impacte da sua utilização na motivação dos alunos para a aprendizagem, bem como de outros temas ligados ao ensino e aprendizagem deste assunto.

1.3. Estrutura da tese
Esta tese possui sete capítulos, que estão organizados da seguinte forma: Neste primeiro capítulo, de introdução, foi definido o problema, sendo especificados os objectivos que se pretendiam alcançar, bem como os contributos resultantes deste trabalho, e apresenta-se, ainda, a estrutura da dissertação. No segundo capítulo focam-se os pressupostos teóricos que sustentam esta investigação, onde são referidas as ideias dos diversos autores que contribuíram para o desenvolvimento destas teorias. Mencionam-se algumas das metodologias educativas inspiradas nestas teorias das quais se destaca a aprendizagem baseada em problemas. No terceiro capítulo, referente ao ensino da programação, efectua-se uma resenha das linguagens de programação que estão a ser utilizadas no ensino, assim como os respectivos ambientes de programação, sendo também apresentadas as principais dificuldades referidas na literatura. O quarto capítulo apresenta uma caracterização genérica dos mundos virtuais. Nele se faz um levantamento e classificação dos principais mundos virtuais existentes, dando especial atenção aos mundos que apresentam características que possibilitam a sua utilização no ensino e aprendizagem da programação.

8

Capítulo I: Introdução No quinto capítulo efectua-se uma descrição detalhada do mundo virtual Second Life, expondo as suas características principais. Apresenta-se também o modo como se constroem objectos 3D neste mundo virtual, evidenciando-se a implementação de programas neste mundo, de forma a gerar diferentes comportamentos para os objectos criados. No sexto capítulo é explicada a abordagem de investigação seguida, efectuando-se igualmente uma explanação da estrutura metodológica da investigação-acção. No sétimo capítulo, sobre a aplicação do método de investigação, descreve-se a praxis educativa efectivada, regida pela metodologia investigação-acção, para obter respostas ao problema proposto. No oitavo capítulo, dedicado à reflexão e discussão dos resultados obtidos. No nono capítulo apresenta-se o modelo proposto para a utilização do mundo virtual Second Life como plataforma para o ensino introdutório da programação. No último capítulo, de conclusão, recorda-se o problema e faz-se uma análise global do trabalho realizado, tendo em conta os objectivos estabelecidos. Termina-se com diversas reflexões sobre a continuidade desejada para este estudo.

9

2. Aprendizagem – fundamentos teóricos
Neste capítulo faz-se uma breve introdução às diferentes teorias da aprendizagem, referindo-se as ideias dos diversos autores que contribuíram para o seu desenvolvimento. Prossegue-se mencionando algumas das metodologias educativas inspiradas pelas teorias da aprendizagem entre as quais se destaca a aprendizagem baseada em problemas. Finalmente, efectua-se uma descrição detalhada sobre a aprendizagem baseada em problemas, que foi utilizada neste estudo, na qual se expõe as suas principais características, quais os pressupostos sobre como se processa a aprendizagem e qual o papel do professor e dos alunos.

Capítulo II: Aprendizagem – Fundamentos Teóricos

11

Capítulo II: Aprendizagem – Fundamentos Teóricos

2.1. Teorias de aprendizagem
Tudo o que ao longo da nossa vida provoca uma mudança que transforme a nossa relação com o mundo pode e deve ser considerado aprendizagem. O progresso da humanidade, o desenvolvimento científico, as grandes realizações conseguidas nas mais diversas áreas culturais, só foram possíveis pelo facto de o ser humano possuir capacidades para aprender, para reter e para transmitir às gerações vindouras as formas pelas quais, ao longo da história, foi sendo configurada a adaptação ao mundo que o rodeia (Abrunhosa, Leitão, 2002). De um modo espontâneo, consciente ou inconscientemente, com pouco ou muito esforço, estamos constantemente a aprender. Ao longo dos tempos o homem tem vindo a procurar compreender e aperfeiçoar os métodos de estímulo e/ou apoio à aprendizagem – em particular, o ensino. Esta procura contínua permitiu o desenvolvimento de muitas teorias que tentam explicar como o ser humano aprende. Sendo difícil pormenorizar o conjunto dos fundamentos teóricos, que ultrapassam o propósito deste trabalho, expõem-se, contudo, algumas teorias basilares referindo-se em cada uma delas as principais figuras onde se enquadra este estudo.

2.1.1.

Behaviorismo

O behaviorismo teve o seu apogeu entre meados dos anos 1950 e 1960 como teoria para explicar a natureza da aprendizagem, embora ainda hoje exerça a sua influência. Esta teoria teve origem no trabalho de vários autores, entre eles I. Pavlov (1849-1936), J. B. Watson (1878-1958) e B. F. Skinner (1904-1990), que identificaram o condicionamento como um processo de aprendizagem universal.

2.1.1.1. Ivan Pavlov Pavlov foi um fisiologista russo que em 1904, ao estudar o papel da saliva na digestão, verificou que os cães salivavam ao cheiro ou à vista da comida. Esta observação ocasional motivou Pavlov (1927) para o estudo sistemático do condicionamento, o que o levou a efectuar inúmeras experiências onde concluiu que:

12

Capítulo II: Aprendizagem – Fundamentos Teóricos Um estímulo (um pedaço de carne) provoca uma reacção (começa a salivar) – «reflexo simples»; A associação de estímulos desencadeia-se a mesma reacção – acrescentou o som de uma campainha sempre que apresentava o pedaço de carne ao cão e este começava a salivar; O novo estímulo provoca uma resposta adequada ao primeiro estímulo «reflexo condicionado» – o cão apenas ouve o som da campainha e começa a salivar. Em dado momento da experiência o cão é capaz de responder ao estímulo condicionado como se do estímulo não condicionado se tratasse. A este processo chama-se de condicionamento e consiste em associar um estímulo condicionado a um estímulo natural, de tal modo que o indivíduo reage ao estímulo condicionado do mesmo modo que reage ao estímulo natural. Por conseguinte, Pavlov define o comportamento como o conjunto de respostas objectivamente observáveis que o organismo executa face a estímulos também objectivamente observáveis (Abrunhosa, Leitão, 2002).

2.1.1.2. John Broadus Watson Watson foi um psicólogo americano, influenciado pelos estudos de Pavlov, fundador da corrente científica da psicologia conhecida por behaviorismo. Segundo Watson (1913) a psicologia tem de ser objectiva. Assim propõe que a psicologia estude apenas o que é observável, ou seja, o comportamento (behaviour), e se abstenha de qualquer tentativa de identificar actividades mentais. A ligação Estímulo-Resposta, para Watson (1928), processa-se de modo mecânico, o que lhe permite fazer uma interpretação causal do comportamento e, consequentemente, elaborar leis explicativas do mesmo. Tais leis pretendiam: Perante um determinado estímulo, prever a reacção subsequente. Perante uma dada resposta, determinar o estímulo que a desencadeou. Para Watson (1928), os diferentes comportamentos são adquiridos segundo processos de condicionamento, designados de «condicionamento clássico». A aprendizagem resulta da resposta a um estímulo e esta não é mais do que a aquisição de um novo comportamento.

13

Capítulo II: Aprendizagem – Fundamentos Teóricos 2.1.1.3. Burrhus Frederic Skinner Skinner, psicólogo americano nascido em 1904, ficou conhecido pelas suas experiências com animais, nomeadamente ratos, para as quais criou uma caixa especial, designada por caixa de Skinner. Esta caixa possuía um dispositivo que permitia o fornecimento automático de alimento (reforço) ao animal em observação. Para além disso, continha também um mecanismo que registava as respostas do animal, dispensando o pesquisador de uma permanente observação. No final dispunha de um registo cumulativo das respostas do animal em observação. Skinner colocou um rato faminto dentro da sua caixa e constatou que ao fim de algum tempo o roedor descobre que para obter alimento tem de premir uma alavanca. Como o animal só pode comer após ter accionado a alavanca, o alimento vai reforçar essa resposta, ou seja, o animal aprende a pressionar a alavanca em função do reforço que é o alimento. Isto significa que se estabeleceu no rato a associação entre a resposta operante (premir a alavanca) e o reforço (alimento). A este processo denomina-se de «condicionamento operante». Skinner (1983) considera que a aprendizagem ocorre quando uma resposta a um estímulo é reforçada (reforço). Embora o behaviorismo seja objectivo, ao fazer depender as respostas exclusivamente de situações objectivamente observáveis, tem sido criticado por esta restritividade. No cerne das críticas está a preocupação de que conduza a uma interpretação simplista e demasiado redutora da conduta humana (Pereira, 2007).

2.1.2. Construtivismo/Cognitivismo
A teoria construtivista ou cognitivista opõe-se à behaviorista, pois considera a aprendizagem não como um modelo em que alguém dá e alguém recebe, mas como um modelo em que o sujeito é o elemento activo primordial do processo de aprendizagem, gerador do seu próprio conhecimento (Figura 2.1). Este conhecimento obtém-se através da construção/interacção pelo sujeito de informações novas nas suas estruturas de saber, associando-as a representações existentes ou criando novas representações.

14

Capítulo II: Aprendizagem – Fundamentos Teóricos

Behaviorismo

Construtivismo/Cognitivismo

Carácter passivo do sujeito

Carácter activo do sujeito

Figura 2.1: Diferença entre o Behaviorismo e o Construtivismo.

Vários autores contribuíram para o desenvolvimento desta teoria, destacando-se tradicionalmente figuras como J. Piaget (1896-1980), L. Vygotski (1896-1934) e J. Bruner (1915-).

2.1.2.1. Jean Piaget Piaget foi o grande introdutor do construtivismo/cognitivismo no panorama das ciências modernas (Pereira, 2007). Formado em biologia, interessou-se por investigar o desenvolvimento do conhecimento nos seres humanos. Segundo Piaget (1977), todos os comportamentos humanos resultam da interacção organismo-meio. “O conhecimento não é uma cópia do objecto nem uma tomada de consciência das formas a priori que sejam predeterminadas no sujeito, é uma construção perpétua através de intercâmbios entre o organismo e o meio, do ponto de vista biológico, e entre o pensamento e o objecto, do ponto de vista cognitivo.” (Piaget, 1977). Dito de outro modo, o conhecimento resulta da acção conjunta de factores individuais de ordem inata e de factores adquiridos no contacto com a experiência. Opondo-se aos behavioristas, Piaget afirma que o sujeito é um participante activo no seu próprio desenvolvimento. O construtivismo de Piaget explica a aprendizagem por um processo semelhante ao da alimentação dos seres vivos: assimilação/acomodação/procura do equilíbrio. O desenvolvimento cognitivo seria caracterizado por várias fases (estágios) alcançadas pelas estruturas dos esquemas à disposição do indivíduo. Segundo Piaget (1977), cada etapa ou estágio do desenvolvimento é caracterizada pela presença de esquemas mentais que, quando coordenados entre si, constituem uma estrutura. Desta forma, o desenvolvimento cognitivo faz-se por etapas sucessivas em que as estruturas mentais se

15

Capítulo II: Aprendizagem – Fundamentos Teóricos constroem progressivamente. Cada novo estágio representa uma forma de equilíbrio cada vez maior, que permite uma adaptação mais adequada às circunstâncias. Em todos os estágios, a permuta entre o sujeito e o mundo opera-se por dois mecanismos constantes, que são a assimilação e a acomodação. Assim, perante uma nova situação, desconhecida, o aprendiz tenta primeiro identificá-la, incorporando-a nos esquemas já constituídos. Este apoia-se nas referências conhecidas. A esta regulação Piaget denomina de assimilação, que pode ser suficiente, mas pode, noutras circunstâncias, revelar-se insuficiente e necessitar da modificação dos esquemas referenciais, ou até mesmo da criação de novos esquemas. É a acomodação. O processo complementar, dialéctico, que combina assimilação e acomodação, conduz ao equilíbrio. O processo de equilíbrio permite a evolução, ela guia a coordenação das acções. Para Piaget a procura do equilíbrio é auto-regulação dinâmica, regulação que tende a aperfeiçoar-se em função dos factos exteriores que intervêm. É um processo que tende para o equilíbrio mas nunca está efectivamente estabilizada. “ (...) A cada instante, a acção é desequilibrada pelas transformações que aparecem no mundo, exterior ou interior, e cada nova conduta vai funcionar não só para estabelecer o equilíbrio, mas também para tender a um equilíbrio mais estável que o do estágio anterior a esta perturbação. (...) Pode dizer-se que toda a necessidade tende: 1º a incorporar as coisas e pessoas à actividade própria do sujeito, isto é, “assimilar” o mundo exterior às estruturas já construídas, e 2º, a reajustar estas últimas em função das transformações ocorridas, ou seja, “acomodá-las” aos objectos externos. Assim, toda a vida mental e orgânica tende a assimilar progressivamente o meio ambiente. (...) Ora, assimilando assim os objectos, a acção e o pensamento são compelidos a acomodarem-se a estes, isto é, a reajustarem-se por ocasião de cada variação exterior. Pode chamar-se “adaptação ao equilíbrio destas assimilações e acomodações. O desenvolvimento mental aparecerá, então como uma adaptação sempre mais precisa à realidade. “. (Piaget, 1973). Para Piaget (1976) a aprendizagem implica provocar o desequilíbrio na mente do aluno para que este procure o reequilíbrio, se reestruture cognitivamente e aprenda. “A equilibração cognitiva é, pois, “majorante”, o que significa que os desequilíbrios não conduzem a um regresso à forma anterior de equilíbrio, mas a uma forma melhor” (idid.).

16

Capítulo II: Aprendizagem – Fundamentos Teóricos Contudo, na aprendizagem é necessário ter em consideração o desenvolvimento cognitivo do aprendiz a cada momento, não se devendo propor-lhe tarefas que estejam completamente além das suas capacidades (Pereira, 2007).

2.1.2.2. Lev Vygotski Lev Vygotsky nasceu na Bielorrússia, em 1896. Trabalhou no Instituto de Psicologia de Moscovo, entre 1923 e 1934, onde teve oportunidade de desenvolver as suas teorias sobre o desenvolvimento cognitivo e a relação entre o pensamento e a linguagem. Como marxista, acreditava que só podia compreender o ser humano no contexto do seu ambiente sócio-histórico. Vygotsky (1979) enfatizou a ligação entre as pessoas e o contexto cultural em que vivem e são educadas. De acordo com este autor, as pessoas usam instrumentos que vão buscar à cultura onde estão imersas e entre esses instrumentos tem lugar de destaque a linguagem, a qual é usada como mediação entre o sujeito e o ambiente social. O conhecimento é inicialmente construído num nível social e posteriormente num nível individual. “(...) o verdadeiro curso do desenvolvimento do pensamento não vai do individual para o socializado, mas do social para o individual.” (Vygotsky, 1979) Da obra de Vygotski, destaca-se a ideia que marca de forma determinante os processos pedagógicos ligados à educabilidade. Trata-se do conceito de zona de desenvolvimento próximo (ZDP). É aprendendo a resolver uma situação com um tutor que domina o esquema que o aprendiz progride e constrói, por sua vez, o esquema considerado (Perraudeau, 2000). Vygotsky (1979) considera dois níveis distintos de desenvolvimento em que o aprendiz pode desenvolver diferentes capacidades. Por um lado, o chamado nível ou zona de desenvolvimento actual e, por outro, o nível ou zona de desenvolvimento proximal. A zona de desenvolvimento proximal estabelece a distância entre o que o aluno domina sozinho e o que ele domina com a colaboração de um adulto, ou com os colegas mais capazes. “Para determinar o actual nível de desenvolvimento, utilizam-se problemas que a criança deve resolver sozinha e que são indicativos em relação às funções já formadas e chegadas à maturidade. (...) Esta disparidade entre a idade mental, ou o nível de desenvolvimento actual, que é determinado com o auxílio dos problemas resolvidos de forma autónoma, e o nível atingido

17

Capítulo II: Aprendizagem – Fundamentos Teóricos pela criança, quando resolve problemas, já não sozinha mas em colaboração, determina precisamente a zona de desenvolvimento próximo. (...) a pesquisa mostra que a zona de desenvolvimento próximo tem um significado mais directo para a dinâmica do desenvolvimento intelectual e no êxito da aprendizagem do que no nível actual do seu desenvolvimento.” (Vygotsky, 1979). Segundo Vygotski (1981), construir o saber consiste em determinar um processo que evite dois perigos. O primeiro é o de propor uma situação já dominada: o propósito é, neste caso, vazio de sentido para o aprendiz. O segundo consiste no seu contrário: uma situação de tal modo afastada dos esquemas adquiridos que a ajuda de um tutor, fora da zona, se revelaria inoperante. Com efeito, parece que o aluno tira melhor proveito quando o nível cognitivo do mediador é ligeiramente superior ao seu. Uma distância cognitiva demasiado grande implica, por parte do aluno auxiliado, a aceitação de um saber sem questionamento autêntico (Perraudeau, 2000).

2.1.2.3. Jerome Bruner Jerome S. Bruner, psicólogo americano de formação, nasceu em 1915, sendo designado de “o pai da Psicologia Cognitiva”, devido ao seu papel relevante no campo da cognição. O pensamento de Bruner foi influenciado pela obra de Vygotsky, principalmente no que se refere ao contexto social da aprendizagem (Pereira, 2007). Bruner (1966) considera a aprendizagem um processo activo em que os sujeitos da aprendizagem constroem as ideias ou os novos conceitos baseados nos seus saberes préadquiridos ou actuais. Segundo este autor existe uma coordenação entre aquilo que o sujeito pensa quando constrói a sua aprendizagem e o percurso do pensamento para chegar ao objecto em estudo. Compreender um objecto é desenvolver um processo dedutivo de categorização: no final de um raciocínio, o objecto é entendido como pertencendo a uma categoria. A categorização, que se pode chamar de conceptualização, constrói-se pela e através da linguagem (Perraudeau, 2000). Dito por outras palavras, o sujeito da aprendizagem selecciona a informação e transforma-a, constrói hipóteses e toma as decisões necessárias a essa construção, recorrendo-se da sua estrutura cognitiva para o fazer. A estrutura cognitiva fornece o significado e a organização à realidade com que o sujeito se confronta e permite ao sujeito da aprendizagem ir além da informação recebida. Uma vez que o processo está ligado ao produto, o indivíduo aborda um novo

18

Capítulo II: Aprendizagem – Fundamentos Teóricos conteúdo a partir do que já sabe e a partir da forma como integrou esse conhecimento anterior. Assim, não é, antes de mais, o conteúdo exposto que informa o aluno, mas aquilo que ele sabe é que lhe permite atribuir um significado ao conteúdo exposto (Barth, 1995). Bruner parte do conceito de que aprendizagem é a modificação do comportamento resultante da experiência – aspecto particularmente evocativo da perspectiva behaviorista. Contudo, de acordo com Perraudeau (2000), a concepção de Bruner decorre da concepção de Piaget, por considerar que o conceito não se pode formar sem ser através da construção, e distancia-se dele, pelo facto de, para Bruner, a construção se efectuar graças à linguagem, em interacção entre os indivíduos. “ (...) a aprendizagem é amplamente facilitada pela linguagem, a qual constitui não só um meio de comunicação, mas também um instrumento que o indivíduo em situação de aprendizagem pode utilizar de forma a ordenar o meio ambiente.” (Bruner, 1966, p.6). Deste modo, Bruner atribui à linguagem um papel ordenador do meio ambiente, o qual se afigura imprescindível num processo sistemático de aprendizagem pela progressiva representação do mundo exterior que permite. Bruner (1960) defende que: “ (…) qualquer assunto pode ser eficazmente ensinado de uma forma intelectualmente perceptível a qualquer criança em qualquer estado de desenvolvimento.” Esta alegação constitui uma inovação, principalmente em relação às teorias de Piaget. Por conseguinte, a aprendizagem deve sempre iniciar-se no ponto em que o aprendiz se encontra sendo possível ensinar tudo ao aluno desde que se utilizem procedimentos adaptados ao seu estágio de desenvolvimento e às suas necessidades. Esta noção está subjacente à ideia de o currículo dever ser organizado em espiral, de modo a que as construções que o sujeito realiza se façam continuamente sobre a aprendizagem já realizada, construindo novas aprendizagens (Riding, 1980). Bruner (1990) enfatiza a aprendizagem através da descoberta, na qual salienta o processo activo do aluno. Deste modo, refere que para que se verifique, por parte do aluno, aprendizagem deve haver uma situação de desafio que o leve a resolver problemas. Com esta ideia, Bruner faz uma crítica às metodologias expositivas, considerando, ao invés, que a aprendizagem das Ciências se faz melhor através do envolvimento dos alunos no processo de descoberta e no uso das metodologias científicas próprias de cada ciência:

19

Capítulo II: Aprendizagem – Fundamentos Teóricos “Julgamos que, logo de início, o aluno deve poder resolver problemas, conjecturar, discutir da mesma maneira como se faz no campo científico da disciplina” (Bruner, 1966). Contudo, Bruner refere na sua obra Toward a theory of instruction (1966) que para a exploração de alternativas, por parte do aprendiz, é essencial “a presença de um nível óptimo de incerteza”. Torna-se necessário, para garantir este último, agir de forma a evitar que as tarefas a executar, no âmbito da exploração de alternativas, sejam de acentuada rotina ou de demasiada incerteza. No primeiro caso, haverá “pouca exploração” por parte dos sujeitos em situação de aprendizagem; no segundo, poderá surgir “confusão e ansiedade”, o que implicará uma “redução da exploração”.

2.1.3. Teoria da aprendizagem situada
Lave e Wenger (1991) influenciados pelas ideias de Vygotsky, principalmente pelo conceito de zona de desenvolvimento proximal, desenvolveram os princípios da aprendizagem situada. A aprendizagem situada consiste na conjugação do saber e do fazer, e implica que as actividades individuais e colectivas sejam parte de um todo mutuamente construído, num processo dinâmico, activo, interactivo, dialéctico e transaccional, que contribui para desenvolver conhecimentos sólidos e úteis (Wenger, 1998). Situar a aprendizagem significa, segundo Wenger (1998), criar condições para que os aprendizes experimentem a complexidade e a ambiguidade da aprendizagem em situações autênticas, criando assim o seu conhecimento através dos materiais, da experiência, tais como as relações com os outros, as actividades, o ambiente e a organização social dos participantes. Dito de outra forma, o conhecimento é uma relação activa entre o aprendiz e o ambiente, e a aprendizagem ocorre quando o aprendiz se envolve activamente com o contexto de instrução, que deve ser complexo e realista. Esta teoria está na origem do conceito de scaffolding, o qual teve origem na ZDP de Vygostky, que em português nos remete para a noção de andaime. De facto, a função dum andaime é apenas segurar uma estrutura em fase de crescimento. Uma vez a estrutura construída e alicerçada, o andaime é retirado e voltará a ser colocado numa nova posição com vista ao progresso da construção (Bettencourt-da-Cruz, 2006). Esta noção de andaime tem como característica central o processo designado de participação periférica legítima, que é um processo de entrada numa comunidade de prática do conhecimento, envolvendo a participação nas práticas socioculturais, em que a unidade 20

Capítulo II: Aprendizagem – Fundamentos Teóricos básica de análise é a actividade contextualizada das pessoas (Pereira, 2007). Uma comunidade de prática é constituída por participantes de diferentes níveis: central, activo e periférico. Um novo elemento que se junta à comunidade desloca-se da periferia para o centro desta, tornando-se mais activo e envolvido na cultura subjacente. Consequentemente, pode chegar a assumir o papel de um perito. Neste contexto, a aprendizagem é concebida como um fenómeno sociocultural onde o conhecimento é negociado e aplicado em situações do dia-a-dia, contrariando a perspectiva da aprendizagem como acção de um indivíduo que obtém informação geral a partir dum corpo de conhecimentos abstractos e descontextualizados (Bettencourt-daCruz, 2006). Assim, o aprendiz deve ser exposto à situação o mais realisticamente possível sem exclusão das complexidades do contexto. Um princípio fundamental que resulta desta teoria, segundo Pereira (2007), é o de organizar a instrução à volta de problemas do mundo real para induzir uma organização do conhecimento coerente com o seu posterior uso e a intercepção do conhecimento prévio e preferências com os dos seus colegas de aprendizagem. Neste quadro, a aprendizagem ocorre através da reflexão na experiência, das interacções entre o aprendiz, os outros e o meio.

2.2. Metodologias de aprendizagem
Os focos da educação nos dias de hoje são mais ambragentes que no século passado: não basta os alunos aprenderem os conteúdos é necessário que consigam reflectir com eles e sobre eles. É obvio que os conteúdos são importantes, mas aprender a aprender, ou seja, conseguir que o indivíduo ganhe consciência de como se processa a sua própria aprendizagem e de como pode optimizá-la, é fundamental no mundo actual. Isto porque, mais do que nunca, alguns conteúdos podem perder actualidade, enquanto que as estratégias e os processos de aprendizagem se mantêm e se podem modificar e desenvolver (Fonseca e Pereira, 2007). Este facto torna-se particularmente marcante quando se considera o ensino da programação a futuros informáticos, uma vez que a tecnologia informática está em constante e rápida evolução: os conteúdos que se ensina hoje, amanhã – possivelmente, mesmo antes de se concluir o processo formal de ensino – estão desactualizados. Como argumenta Fonseca, sujeitar os aprendizes a puras formas de assimilação de conhecimentos sem dominarem e compreenderem os

21

Capítulo II: Aprendizagem – Fundamentos Teóricos conceitos, e vice-versa, pode condenar as futuras gerações a um vazio cognitivo e a resistências à mudança, que podem comprometer seriamente a resolução dos desafios futuros que se lhes avizinham, onde a capacidade de aprendizagem se transformará em vantagem competitiva e em eficácia organizacional. Das referências teóricas anteriormente estabelecidas, surgiram algumas práticas para novas formas de aprendizagem como, por exemplo, aprendizagem situada, aprendizagem baseada em problemas, aprendizagem por descoberta, entre outras. As características da metodologia da aprendizagem baseada em problemas, descritas na secção seguinte, foram os factores que motivaram a autora em adoptá-la neste estudo, em detrimento de outras.

2.2.1. Aprendizagem baseada em problemas
A aprendizagem baseada em problemas, conhecida pela sigla PBL (Problem-Based Learning), tem vindo a ser aplicada há mais de 20 anos em diferentes domínios da educação e em diferentes países. A primeira aplicação da PBL verificou-se no ensino médico durante os anos 60 do século passado, tendo-se estendido a vários outros temas do ensino superior e também secundário (Barrows, 2001). A sua aplicação no ensino superior tem vindo a ser relatada com sucesso em diferentes áreas como, por exemplo, no ensino da medicina (Barrows e Tamblyn, 1980; Hogan e Eva, 2005), da arquitectura (Kingsland, 1996), da gestão (Stinson e Milter, 1996), da engenharia (Woods, 2001; Lahtinen, 2005), entre outros domínios (Raine e Symons, 2005; Bateman et al., 2007; Yang et al., 2009). A PBL é uma forma colaborativa de ensino-aprendizagem, na qual se pretende propiciar uma construção activa, coerente, de modelos mentais do conhecimento, ao invés do simples processamento dos assuntos. É também uma forma de ensino-aprendizagem contextualizada, uma vez que os princípios, as ideias e os mecanismos não são estudados em abstracto, mas antes no contexto de uma situação concreta que pode ser reconhecida pelos aprendizes como relevante e interessante. No caso ideal, a situação assemelhar-se-á à situação profissional futura na qual o conhecimento adquirido irá ser aplicado (Schmidt e Moust, 2001). Esta metodologia centra-se na resolução de problemas complexos da vida real como um estímulo para a aprendizagem, integração e organização da informação aprendida, de forma a garantir a sua aplicação em problemas futuros (Tsai e Shen, 2009). 22

Capítulo II: Aprendizagem – Fundamentos Teóricos Segundo Barrows (2001), o objectivo da PBL consiste em formar aprendizes que: adquiram uma base de conhecimentos integrada; obtenham uma base de conhecimentos estruturada relativa de problemas reais da área de actuação do profissional em questão; ganhem uma base de conhecimentos associada a processos de resolução de problemas; se envolvam, com iniciativa e entusiasmo, nos problemas que vão encontrando ao longo da sua vida profissional; empreguem as capacidades de aprendizagem auto-dirigida, de forma a continuarem o seu processo de aprendizagem ao longo da vida; examinem e avaliem a adequação dos seus conhecimentos de forma contínua; colaborem de forma eficaz como membros de um grupo. A PBL, para além de promover a construção do conhecimento, fomenta a auto-reflexão, a cooperação e a responsabilidade, sendo estas partes integrantes do processo de aprendizagem (Gijselaers, 1996; Norman & Schmidt, 1992; Savery e Duffy, 1995). Resumindo, uma das características que tornam a PBL num modelo educacional em expansão, no que se refere à sua utilização no ensino, é o facto de se poder atingir objectivos educacionais mais amplos, ou seja, permite não só a construção de conhecimentos, por parte dos alunos, mas também o desenvolvimento de capacidades e atitudes que lhes serão úteis na sua vida profissional futura, independentemente do percurso que escolham.

2.2.1.1. A implementação da PBL Em algumas instituições de ensino, a PBL foi implementada como uma estratégia de educação em todos os anos curriculares de um curso como, sendo este formado por um conjunto de problemas que constitui a espinha dorsal do currículo. Para além desta estratégia, existem outras aplicações desta metodologia como estratégia educacional em unidades curriculares isoladas dentro de um currículo convencional (Barrows, 2001; Hogan e Eva, 2005). Este modelo de aprendizagem tem dois aspectos centrais: a natureza do problema utilizado, que é o impulsionador da aprendizagem; e a aprendizagem centrada no aluno 23

Capítulo II: Aprendizagem – Fundamentos Teóricos (Duch et al., 2001). O problema é o ponto de partida no processo de aprendizagem dos alunos. Assim, a qualidade do problema adoptado é um ponto central nesta metodologia. Segundo o estudo realizado por Schmidt e Moust (2001) sobre a qualidade do problema na PBL, quanto melhor for o conteúdo do problema adoptado, melhor será o empenho dos alunos na sua resolução e maior será o interesse que estes demonstram no assunto em estudo. Estes autores referem ainda que os problemas de fraca qualidade apresentam um risco para a aprendizagem dos alunos, uma vez que estes se sentem frustrados e desinteressados pelo que estão a aprender. Deste modo, o conteúdo do problema deve ter um significado pessoal para os discentes e assim tornarse motivador. Para além deste aspecto, o problema deve ser adaptado ao nível de conhecimento dos alunos e não deve ser demasiado complexo. Este deve ser transparente, sem ambiguidades, mas sem se dar a solução (ibid.). Assim, a aprendizagem deve ser conduzida por um problema com solução aberta, ou seja, que não tenha uma única solução correcta. O problema deve preceder à teoria, actuando como o foco da aprendizagem, promovendo desta forma a integração dos conceitos e capacidades necessárias para a sua solução (Barrows, 2001). Os aprendizes são confrontados com um problema e tentam resolvê-lo; em grupos organizam as suas ideias, utilizando a informação e os conhecimentos que possuem. É através da discussão em grupo que os alunos vão avaliar e definir os diferentes aspectos do problema, formular hipóteses e levantar questões de aprendizagem acerca dos aspectos que não compreendem. Deste modo, os aprendizes analisam e avaliam os conhecimentos que têm a priori e adquirem uma percepção mais profunda do problema. As questões de aprendizagem levantadas são tópicos que necessitam de ser estudados, pelo que são distribuídos pelos vários elementos do grupo que se incumbem de ir procurar respostas. Após terem analisado o problema, tanto quanto possível, e identificado o que necessitam de aprender, os alunos envolvem-se num estudo autodirigido, com pesquisa das informações necessárias para responder às questões levantadas e resolver o problema. Desta forma, o ensino é personalizado para as necessidades e estilos de aprendizagem do aluno. Os alunos reúnem-se novamente, exploram as questões de aprendizagem anteriores, integrando os seus novos conhecimentos ao contexto do problema, na tentativa de o compreenderem melhor e proporem uma solução. Este processo repete-se enquanto uma solução não for encontrada. No final, os alunos avaliam o processo de aprendizagem, o seu desempenho e o dos colegas, de forma a desenvolverem hábitos de auto-avaliação e avaliação

24

Capítulo II: Aprendizagem – Fundamentos Teóricos construtiva dos seus pares, imprescindíveis para uma aprendizagem autónoma e eficaz (Barrows, 2001).

2.2.1.2. O papel do professor e dos alunos na PBL Este modelo de aprendizagem implica uma mudança de atitude tanto por parte dos alunos como do professor, quando adoptado após experiência de uns e/ou outros com métodos mais tradicionais de ensino-aprendizagem. Os alunos passam a ter um papel mais activo na sua aprendizagem, assumindo uma responsabilidade acrescida, trabalhando em grupo para identificar, analisar e resolver o problema. Debatem o problema em conjunto, expondo e analisando os seus pontos-chave, tendo como resultado a activação do conhecimento prévio dos alunos. Por outro lado, facilita a compreensão e a integração dos novos conhecimentos, aumentando, deste modo, a sua motivação, no sentido de se realizarem como aprendizes para toda a vida (Barrows, 2001; Duch et al., 2001). Os professores, por seu turno, transformam-se em recursos, tutores e guias, acompanhando os alunos nos seus esforços de resolução de problemas. Assim, o contributo do professor consiste em desafiar os alunos a clarificarem as suas ideias, incentivando-os a pensar, a delinearem questões, a procurarem incoerências e a considerarem alternativas, entre outros (Schmidt e Moust, 2001). Deste modo, o professor ajuda os alunos a organizar os seus conhecimentos, a resolver os seus equívocos e a descobrir o que não está bem compreendido. Em suma, as teorias de aprendizagem podem ser implementadas na prática de ensino de várias formas, nesta tese optou-se por empregar uma que tem um historial de êxito em várias áreas tecnológicas e científicas, a PBL.

25

3. Ensino da Programação
Procura-se neste capítulo apresentar a situação actual do ensino introdutório da programação a alunos dos primeiros anos dos cursos superiores da área científica da Ciências Informáticas. Começa-se por expor as dificuldades relatadas na literatura científica sobre a aprendizagem da programação. Prossegue-se com a explanação das principais abordagens pedagógicas propostas para o ensino da programação. Faz-se uma breve referência às ferramentas existentes para o ensino e aprendizagem da programação. Por último, face ao exposto apresenta-se a abordagem da investigadora para estudar o problema em questão.

Capítulo III: Ensino da Programação

27

Capítulo III: Ensino da Programação

3.1. Programar, o que é?
Numa visão genérica do termo, programar significa planear. No nosso quotidiano, todos programamos algo. Por exemplo: programamos o nosso dia de trabalho, programamos o relógio despertador para uma determinada hora, programamos as nossas férias, etc. E todos somos capazes de o fazer com relativa facilidade. “Programming is a widespread activity that is done both by nonspecialists (e.g., consumers who change the settings of their alarm clock or cellular phone) and specialists (computer programmers).” (Roy e Haridi, 2003). Quando se fala em programar um computador, as coisas tornam-se mais complicadas. Um computador, como foi referido no capítulo de introdução desta tese, é uma máquina que processa dados e executa, com uma cadência muito rápida, sequências de operações elementares, a partir de informação inserida através de dispositivos de entrada, tipicamente o teclado (Rocha, 2008). Mais concretamente, é uma máquina programável, em que as tarefas a desempenhar são-lhe fornecidas através de um programa, que é uma sequência de operações elementares, podendo ser alterada ou substituída por outra sempre que se deseje. Desta forma, a escrita de um programa tem, normalmente, por objectivo resolver um ou mais problemas. Deve-se começar por compreender e analisar o problema em questão, com o propósito de se esboçar uma solução eficaz para o mesmo. A concepção de uma solução requer escrever um conjunto finito, preciso e ordenado de passos que executados por uma determinada ordem resolvem um problema - o algoritmo. Em seguida, é preciso codificar a solução encontrada numa linguagem de programação, verificar se esta cumpre as regras sintácticas da linguagem de programação em causa e testar se faz o pretendido, isto é, se resolve o problema em questão. Numa perspectiva mais elevada de mestria, programar é uma arte (no sentido de “ofício”), porque existem muitas maneiras diferentes de codificar instruções, permitindo a criatividade. É também uma ciência (no sentido de “saber estruturado”), porque é constituída por um conjunto de regras orientadoras, porque é necessário o uso de lógica e porque existem alguns métodos rigorosos de programação que asseguram a eficiência, economia e utilidade dos programas gerados (Gomes, 2008).

28

Capítulo III: Ensino da Programação

3.2. Dificuldades na aprendizagem da programação
As disciplinas de programação surgem na generalidade nos primeiros anos dos cursos superiores da área científica das Ciências Informáticas, sendo consideradas uma técnica base destes cursos, como salientam Tucker et al. (2003) “While programming is a central activity to computer science, it is only a tool that provides a window into a much richer academic and professional field. That is, programming is to the study of computer science as literacy is to the study of literature.” O ensino inicial da programação centra-se no desenvolvimento de algoritmos, na aprendizagem dos conceitos básicos da programação, na qual se utiliza, na sua maioria, uma linguagem de programação procedimental ou orientada a objectos (McCracken et al., 2001; Goldman et al., 2010). As competências-base que os alunos devem adquirir nos primeiros anos de aprendizagem da programação (Goldman et al., 2010) são as seguintes: Resumir o problema a partir da sua descrição – os alunos devem ser capazes, a partir da especificação do enunciado do problema, de extrair os aspectos relevantes deste. Gerar o algoritmo – Os alunos devem conseguir desenvolver uma solução para o problema em causa. Esta solução pode ser efectuada por módulos, isto é, a partir do problema inicial, os alunos devem ser capazes de decompô-lo em subproblemas e gerar soluções para cada um deles. Construindo assim uma solução global para o problema em causa. Codificar a solução – A partir da solução encontrada, os alunos devem ser capazes de transcrevê-la para uma linguagem de programação, testá-la e corrigir os erros de sintaxe e lógicos que possa conter. Devem também ser capazes de ler e compreender o código de programas existentes. Desde o seu início que a programação de um computador tem sido considerada uma tarefa não trivial, como refere Maurice Wilkes1 (1985) nas suas memórias:

1 Maurice Vincent Wilkes nasceu em 1913 em Inglaterra, tendo sido pioneiro na ciências de computação, ajudou a construir o computador EDSAC em 1949, inventou a microprogramação em 1950, foi co-autor na escrita do primeiro livro sobre programação de computadores, escreveu o primeiro artigo sobre memórias cache em 1964 e foi pioneiro na arquitectura cliente-servidor em 1980. Recebeu o prémio Turing em 1967 e o prémio Kyoto em 1992. Em 1985 publicou o livro Memoirs of a Computer Pioneer (Wilkes, 2009).

29

Capítulo III: Ensino da Programação “By June 1949 people had begun to realize that it was not so easy to get a program right as had at one time appeared. I well remember when this realization first came on me with full force. The EDSAC (Electronic Delayed Storage Automatic Computer) was on the top floor of the building and the tape-punching and editing equipment one floor below on a gallery that ran round the room in which the differential analyser was installed. I was trying to get working my first non-trivial program, which was one for the numerical integration of Airy's differential equation. It was on one of my journeys between the EDASC room and the punching equipment that “hesitating at the angles of stairs" the realization came over me with full force in that a good part of the remainder of my life was going to be spent in finding errors in my own programs.". Apesar dos avanços tecnológicos, a aprendizagem da programação continua a ser considerada uma tarefa árdua, principalmente para os alunos que pela primeira vez têm contacto com ela, uma vez que o processo de familiarização com a programação não é simples, sendo vários os conceitos que têm de ser compreendidos e praticados. Os alunos têm de ter uma boa capacidade para resolver problemas, conhecer a sintaxe e a semântica da linguagem de programação e serem capazes de compreender o código existente (Winslow, 1996, Garner, 2008, Stiller, 2009). Como advoga Dijkstra (1989), aprender a programar é um processo lento e gradual que requer um estudo baseado na prática, e que é bastante diferente da maioria das disciplinas mais teóricas, que requerem muita leitura e alguma memorização. Daí, ser necessário haver uma consciencialização por parte dos alunos, quando iniciam o estudo da programação, que programar se aprende fazendo e não vendo como se faz. A programação exige um treino intensivo na resolução de problemas, envolvendo competências de diversas áreas para obter um pequeno retorno (Perkins et al. 1988; Dijkstra, 1989). Como salienta Ben-Ari (2001), os conceitos de programação não podem ser directamente transferidos do professor para os alunos, eles devem ser activamente adquiridos por estes. Apesar deste quadro de complexidade que envolve a aprendizagem da programação, existem alunos que aprendem a programar facilmente, sem necessitarem de fazer um esforço excessivo. Contudo, grande parte dos alunos não o consegue sem um acompanhamento intensivo por parte do professor (Robins et al., 2003). Outros alunos simplesmente acabam por desistir do curso por não alcançarem aprovação às disciplinas que envolvem a programação (Kelleher e Pausch, 2005; Garner, 2009). Por outro lado, uma percepção negativa sobre a natureza e os atractivos do trabalho na área da computação, principalmente o receio de terem de trabalhar isolados sem contacto

30

Capítulo III: Ensino da Programação humano e de ser um campo da ciência que atrai poucas mulheres, são factores que têm contribuído para o declínio do interesse mostrado pelos alunos por esta área do saber (Cassel et al., 2007; Stiller, 2009). Várias têm sido as razões apontadas na literatura científica para as causas destas dificuldades. Linn e Clancy (1992) referem que os alunos sentem dificuldades em compreender o enunciado do problema e consequentemente em desenhar uma solução para o mesmo. No estudo realizado por McCracken et al. (2001), no qual participaram alunos de diferentes instituições de ensino e de diferentes países, os investigadores concluíram que independentemente da linguagem de programação e do paradigma (procedimental simples ou orientado a objectos) adoptado, os alunos sentem as mesmas dificuldades. Neste estudo, McCracken et al. identificaram que a parte mais difícil da programação, para a generalidade dos alunos, consiste em conseguirem compreender o enunciado do problema a resolver e consequentemente desenvolverem uma solução. Verificaram também que a maioria dos alunos não adquiriu as competências-base desejadas, a média da pontuação obtida foi de 22.89 nos 110 pontos dos critérios gerais. Este estudo foi repetido por Lister et al. (2004), que chegaram às mesmas conclusões: identificou-se que os alunos apresentam frequentemente falhas de aptidão para resolver problemas. Esta dificuldade, segundo Gomes et al. (2006) advém da falta de conhecimentos de base de Matemática. Do estudo que realizaram com alunos de Engenharia Informática do ensino superior, concluíram que a maioria destes alunos não domina os conceitos básicos de Matemática, que posteriormente se reflecte na sua capacidade de resolver problemas (ibid.). De acordo com Dann, Cooper e Pausch, (2000), e também segundo Miliszewska e Tan (2007), esta lacuna deve-se principalmente ao facto de os alunos não terem formação em cálculo no ensino secundário (présuperior). Este ponto de vista é igualmente defendido por Fonseca (2007) que vai mais longe ao afirmar: “As instituições de ensino partem da assunção falsa de que os aprendizes dispõem de funções cognitivas para aprender e para reaprender, mas tal não é verdade. Por esse facto, essas instituições têm sido um local de sucesso para alguns, mas de insucesso para muitos.” (p. 355). O próprio adianta ainda: “Muitos alunos não têm o seu potencial de aprendizagem actualizado, na medida em que carecem de pré-requisitos cognitivos básicos para obterem mais rendimento na

31

Capítulo III: Ensino da Programação aprendizagem, considerando que raramente são colocados em situações de reflexão e de pensamento crítico, porque são frequentemente integrados em programas inadequados e ineficientes.” (p. 355). Esta situação resulta no facto dos alunos não evidenciarem as qualidades perceptivas necessárias para extrair dados da informação apresentada e conseguirem desenvolver estratégias para resolver os problemas (ibid.). Uma outra vertente apontada para a causa desta dificuldade refere-se à inadequada pedagogia utilizada no ensino da programação (Spohrer e Soloway 1986; Linn e Clancy 1992; Guzdial 2004a). Linn e Clancy (1992) sugerem, das observações efectuadas, que os alunos têm o seu conhecimento de programação organizado em torno da sintaxe da linguagem de programação utilizada. Consequentemente, os alunos sentem dificuldades em desenvolver algoritmos. Uma boa organização do conhecimento ajuda os alunos a relembrar e a reutilizar a informação que aprenderam, na medida em que lhes auxilia no reconhecimento de semelhanças entre diferentes problemas, assim como entre diferentes partes da informação, melhorando a sua compreensão (Anderson, 2004). Husic, Linn e Sloane (1989) e Robins et al. (2003) referem que os professores, muitas vezes, dão demasiada ênfase à sintaxe da linguagem, pelo que os alunos organizam o seu conhecimento, deste modo, em consequência da forma como a informação lhes é apresentada (Linn, Sloane e Clancy, 1987; Guzdial, 2004a). A generalidade dos livros de introdução à programação também pode contribuir para reforçar a ênfase na sintaxe da linguagem e em exemplos individuais de aprendizagem em vez de encorajar os alunos a reconhecer e a reutilizar padrões mais complexos (Guzdial, 2004a). Por exemplo, os livros de introdução à linguagem C, geralmente, restringem-se a introduzir a sintaxe da linguagem ao longo dos vários capítulos. Apesar de alguns alunos não apresentarem dificuldades na resolução de problemas, muitos não são capazes de codificar a solução encontrada na respectiva linguagem de programação (Sohrer e Soloway, 1989; Winslow, 1996; Lahtinen et al., 2005). Os alunos reclamam que não gostam de programar, uma vez, que não compreendem conceitos básicos tais como a noção de variáveis, endereços de memória e outros (Jenkins, 2002; Milne e Rowe, 2002; Miliszewska e Tan, 2007). Uma das causas possíveis refere que estes conceitos são abstractos, sem uma representação equivalente na vida real (Lahtinen et al., 2005; Miliszewska e Tan, 2007). Devido à natureza abstracta da programação, muitos alunos sentem dificuldades em compreender a estrutura do programa e principalmente o seu funcionamento (Cypher et al., 1993; Esteves e Mendes, 2004; 32

Capítulo III: Ensino da Programação Lemieux, e Salois, 2006; Urquiza-Fuentes e Velázquez-Iturbide, 2009). Um aspecto importante na aprendizagem da programação consiste em os alunos conseguirem estabelecer uma ligação entre o que escrevem, quando estão a digitar o código, e o que o programa realmente faz. Doutro modo, dificilmente os alunos conseguem compreender o que se passa quando um programa não funciona correctamente. Uma das causas apontadas refere-se ao facto dos alunos terem noções incorrectas dos conceitos-base de programação (Kolikant e Mussai, 2008; Kaczmarczyk et al., 2010) e consequentemente noções incorrectas acerca de um programa completo. A compreensão de um programa é muitas vezes vista como um processo de condução de hipóteses cujo objectivo consiste em construir uma representação mental do programa. Esta representação mental compõe-se em distintas partes: descrever o código do programa, o significado deste na perspectiva do domínio de aplicação e a ligação entre estes dois aspectos (Vainio e Sajaniemi, 2007). Durante a compreensão de um programa, o programador gera hipóteses relacionadas com as três partes da representação mental e tenta validar ou invalidar as hipóteses colocadas. Por exemplo, gerar hipóteses “deixa ver o que este conjunto de instruções faz, de forma a poder saber qual o seu objectivo; isto parece que efectua a pesquisa de um número no vector” e validá-las “deixa ver se realmente é assim ”. Este processo é necessário para a compreensão de novos programas e verificação de erros no código. Os alunos inexperientes têm dificuldade em fazer esta representção mental tanto de partes de um programa como de um programa completo. Os primeiros estudos, como o trabalho de Mayer (1981), sobre os modelos mentais da acção de escrever instruções num programa, seguido do estudo de Bayman e Mayer (1983) no qual examinaram os equívocos dos alunos relacionados com a escrita de instruções individuais na programação em Basic, concluíram que muitos alunos tinham compreensões incorrectas ou equívocos, mesmo em relação às instruções mais simples. Bonar e Soloway (1985), por seu turno, focaram-se em grupos de instruções de forma a analisar a compreensão dos alunos sobre a programação. Deste estudo, Bonar e Soloway concluíram que muitos dos erros resultam dos alunos não terem um conhecimento correcto da linguagem de programação e usarem erradamente os conhecimentos que têm de como resolver o problema passo-a-passo na linguagem natural. Estudos efectuados mais recentemente, por Gotschi, Sanders, e Galpin, (2003), por Ma et al., (2007) e por Kaczmarczyk et al., (2010) vêm corroborar este facto: os alunos têm modelos mentais errados dos conceitos de base da programação, como, por exemplo, inicializar variáveis, usar estruturas de controlo e empregar ponteiros, o que lhes

33

Capítulo III: Ensino da Programação dificulta a tarefa de conseguir escrever programas correctamente. Não obstante, para além de alguns alunos terem dificuldades em compreender os conceitos abstractos, muitos há que embora os compreendam não sabem como aplicá-los correctamente de forma a criar estruturas mais complexas (Perkins et al., 1988; Jenkins, 2002; Gomes et al., 2008). Soloway (1986) realça que a dificuldade real dos alunos, no seu processo de aprendizagem da programação, consiste em “putting the pieces together”, ou seja, em perceber que elementos devem usar e como coordená-los de forma a criar um programa correcto. Uma das vertentes defendidas na literatura para estas dificuldades, especialmente referente à codificação, diz respeito à linguagem de programação adoptada no ensino (Hadjerrouit, 1998; Close, Kopec e Aman, 2000, Jekins, 2002, Gomes et al., 2008, Hanhs e Brandt, 2009). Como Lister et al. (2004) verificaram no seu estudo, a maioria das instituições de ensino utiliza a linguagem de programação Java. Tymann (2005), do estudo que efectuou, acrescenta as linguagens de programação C e C++, como linguagens de introdução da programação mais utilizadas no ensino. Dos estudos realizados por Dingle & Zander, (2000) e por Raadt et al. (2002 e 2004) conclui-se que os factores que mais influenciam a escolha da linguagem de programação a adoptar no ensino na área da ciência da computação são: as necessidades do mercado; as exigências das empresas; a opinião dos alunos de que a linguagem leccionada seja a que vão usar na vida profissional. Conquanto, deve-se estar atento ao facto de que a popularidade de uma linguagem não significa obrigatoriamente que esta seja uma boa opção para o ensino, como salientou McGracken em 1973 no caso da linguagem FORTRAN: “Nobody would claim that FORTRAN is ideal for anything, from teachability, to understandability of finished programs, to extensibility. Yet it is being used by a whopping 70% of the students covered by the survey, and the consensus among the university people who responded to the survey is that nothing is going to change much anytime soon”(p. 88). De facto, o FORTRAN continuava a ser largamente utilizado na educação até ter surgido o Pascal. Böszörményi (1998) faz um comentário semelhante em relação à

34

Capítulo III: Ensino da Programação linguagem Java. Contudo, esta tem sido utilizada desde o seu aparecimento em 1995 até aos dias de hoje. Talvez isto se deva ao facto de, como Böszörményi refere: “(…) the approach we think today to be the best (if there is one) was not the first and probably will not be the last. The university should not try to teach ultimate wisdom: it should rather teach students to think about different possibilities” (p. 142). Nos anos 70, Gries (1974) e Schneider (1978) referiam que a introdução à programação deveria ter por objectivo a resolução de problemas e o desenvolvimento de algoritmos, pelo que a linguagem de programação utilizada: “(…) should be based on two critical and apparently opposing criteria: richness and simplicity – rich in those constructs needed for introducing fundamental concepts in computer programming but simple enough to be presented and grasped in a one semester course.” Schneider (p. 110) Estas alegações ainda hoje se mantêm válidas. Um aluno inexperiente começa por aprender a sintaxe da linguagem, progredindo de forma a ser capaz de combinar essa sintaxe para resolver problemas específicos e finalmente adquirir aptidões gerais de resolução de problemas que podem ser transferidos para outros domínios não relacionados com a programação (Bereiter e Ng, 1991). A ideia de ter uma sintaxe simples está claramente relacionada com este pensamento; de colocar o foco da aprendizagem na resolução de problemas. Jenkins (2002) salienta que as linguagens de programação utilizadas na aprendizagem têm uma sintaxe adequada para os profissionais, mas não para os alunos inexperientes. Tal como acontece, por exemplo, com as linguagens C++, Java e C detentoras de um vocabulário extenso e complexo que pouco tem a ver com a aprendizagem de algoritmos e a escrita de programas estruturados. Uma linguagem de programação com um pequeno número de comandos e funções permite solucionar facilmente problemas simples, mas a solução de problemas mais complexos pode tornar-se difícil. Como é o caso, por exemplo, da linguagem Scheme: esta tem a vantagem de ter um único tipo de dados – listas – e uma operação – avaliação da lista. Embora esta abstracção seja muito simples de explicar e não seja de difícil compreensão para os alunos inexperientes, resulta, no entanto, num código que é difícil de ler, uma vez que tem um grande número de parêntesis aninhado, assim como a ausência de outros tipos de pontuação. Por outro lado, uma linguagem com um número alargado de comandos e funções facilita a elaboração de problemas complexos, mas

35

Capítulo III: Ensino da Programação torna difícil a assimilação da sintaxe. Os aprendizes têm dificuldades em reter duas ou mais perspectivas de conceitos em simultâneo (Hofstadter, 1979). Deste modo, o facto de os alunos terem de lidar com a semântica e sintaxe da linguagem, estruturas de dados estáticas e dinâmicas, entre outros aspectos, dificulta a aprendizagem, como acontece com as linguagens de programação profissionais, C, C++ e Java, possuidoras de uma sintaxe complexa e uma extensa semântica, que se tornam difíceis de ensinar e complicadas para os aprendizes assimilarem (Mclver e Conway, 1996). No estudo desenvolvido por Jadud (2005), com alunos inexperientes, verificou-se que os alunos passam grande parte do tempo imersos nos erros de sintaxe quando aprendem a programar em Java. Este facto torna-se ainda mais evidente para os alunos com mais dificuldades. Fenwick et al. (2009), no estudo que efectuaram, confirmaram os resultados obtidos por Jadud (2005), tendo-se verificado que os alunos compilam o programa poucas vezes e normalmente só o fazem no fim de terem escrito uma grande quantidade de código. Em consequência desta forma de programar, quando os alunos compilam o seu programa obtêm geralmente um elevado número de erros que dificilmente conseguem corrigir. Face a este elevado número de erros, os alunos sentem-se frustrados e desiludidos, como concluíram Rodrigo et al. (2009) no estudo efectuado sobre o comportamento dos alunos inexperientes. Os erros de sintaxe mais frequentes observados nestes estudos foram: falta de pontos-e-vírgulas; variáveis que não são declaradas; falta de chavetas, quer nas estruturas de controlo quer nos métodos; classes e métodos desconhecidos. Por outro lado, Kopec et al. (2007) realizaram um estudo para observar que tipos de erros cometem os alunos de nível intermédio, que já possuem alguns conhecimentos de programação. Nesse estudo, os alunos aprenderam a programar com a linguagem C. Kopec et al. verificaram que os alunos intermédios não cometem muitos erros de sintaxe, sendo capazes de corrigir os que surgem no seu código. Contudo, os erros mais frequentes observados nestes alunos incidiam na codificação de funções, nomeadamente a utilização de funções com parâmetros de entrada incorrectos. Outros, no entanto, utilizavam estruturas de repetição erradas: em vez de usarem um for, que seria o mais correcto, para o problema em causa, usavam um ciclo while. Isto demonstrava falta de conhecimento de como usar as estruturas de repetição correctamente. Kopec et al.

36

Capítulo III: Ensino da Programação concluíram que os professores devem ter muito cuidado na apresentação e descrição do enunciado do problema, uma vez que os alunos facilmente se confundem com a linguagem usada na descrição do enunciado. Os alunos também apresentam dificuldades para saber que estrutura melhor se adapta a uma determinada situação. Outro aspecto importante na aprendizagem da programação é a atitude dos alunos face aos erros, que, segundo Perkins et al. (1989), é bastante diferenciada. Existem alunos incapazes de prosseguir quando confrontados com um erro no seu programa ou com a falta de uma direcção clara do que fazer a seguir, alunos estes que Perkins et al. designam por “estáticos”. Os alunos estáticos perdem toda a esperança de conseguir resolver o problema por si só e de continuarem a progredir. Outros há que, face aos erros, procuram soluções, experimentam e modificam o seu código, designados de Movers. E dentro deste grupo, os Movers, existem alunos que analisam as mensagens de erro que o sistema lhes fornece, tentam compreender a sua origem e conseguem corrigi-los e consequentemente progridem na aprendizagem. Por outro lado, existem alunos dentro deste grupo de Movers que fazem alterações aleatoriamente sem pensar no que estão a fazer, deste modo não conseguindo progredir na aprendizagem. O descontentamento gerado pelo uso das linguagens C, C++ ou Java na introdução à programação (Feldman, 1992; Roberts, 1993; Hadjerrouit, 1998; Reges, 2006) motivou a mudança, por parte de algumas universidades, para linguagens de programação usadas no passado, como o Pascal, ou a ponderar a possibilidade de adoptar linguagens como Python (Becker, 2002). Este descontentamento foi também factor impulsionador para o desenvolvimento de novas linguagens de programação mais simples, com o intuito de ajudar os alunos inexperientes a aprender a programar e a facilitar a migração posterior para linguagens com características mais complexas (Guzdial, 2004b; Hundhausen et al., 2010). Outra abordagem foi o desenvolvimento de ambientes que não alteram a linguagem de programação usada, mas “escondem” partes da linguagem (Guzdial, 2004b). Na secção seguinte expõem-se algumas destas linguagens e alguns destes ambientes. Outros autores, como por exemplo Dann et al. (2000), Reis e Cartwright (2004), Hundhausen, Farley e Brown (2009), referem que uma das causas que contribui para este panorama de dificuldades, principalmente no que se refere à codificação, é a utilização de ambientes de programação inadequados para alunos inexperientes. Os ambientes de desenvolvimento integrados, comummente designados de Integrated Development Environment (IDE), são ferramentas que permitem ao programador escrever, 37

Capítulo III: Ensino da Programação editar, executar e testar programas. Os IDE são geralmente desenvolvidos tendo em vista os programadores profissionais, pelo que estes possuem um interface complexo e uma multiplicidade de instrumentos (Figura 3.1) que tornam a sua utilização complicada para os alunos inexperientes (Kelleher e Pausch, 2005). Contudo, muitos deles são usados no ensino da programação, como por exemplo o Eclipse, JBuilder, Delphi ou Dev C++ (Trætteberg e Aalberg, 2006; Röbling et al., 2008). Estes factores motivaram alguns autores a desenvolver ferramentas de programação com o propósito de ajudar os programadores inexperientes na aprendizagem (Brown, 1984; Stasko, 1989; Concepcion et al., 1999; Röbling e Freigleben, 2001; Virtanen et al., 2005; Dann e Cooper, 2009). Na secção seguinte expõe-se algumas destas ferramentas.

Figura 3.1: Ambiente de programação Eclipse IDE

Aliado a estes factores, existe outro: verifica-se que os alunos que frequentam as disciplinas de programação apresentam níveis de experiência muito diferentes, pois alguns já tiveram contacto com uma ou várias linguagens de programação no ensino não superior e outros estão pela primeira vez a ter esse contacto (Milne e Rowe, 2002; Kelleher, e Pausch, 2005; Gomes et al., 2008). Na leccionação de aulas de programação,

38

Capítulo III: Ensino da Programação a investigadora também constatou a mesma situação, uma vez que é permitido que alunos de áreas muito diferenciadas frequentem o ensino, e como tal com conhecimentos de base muito diversificados. Assim, é possível encontrar alunos que vêm da área tecnológica já com alguns conhecimentos de programação e outros que apenas possuem conhecimentos informáticos na óptica do utilizador. Um aspecto fundamental no processo de aprendizagem é a assimilação de novos conceitos nas estruturas cognitivas existentes (Vygotsky, 1979; Bruner, 1990). Por conseguinte, esta discrepância nos conhecimentos de base dos alunos torna o processo mais complexo para os pedagogos do ensino tradicional, devido às aulas serem frequentadas por alunos de diferentes níveis de saber e capacidades. Nesta secção reviu-se os factores principais que têm vindo a ser apontados na literatura científica como causas que condicionam a aprendizagem da programação e a torna num processo difícil e exigente para a maioria dos alunos. A resposta a cada uma destas dificuldades resultou num conjunto de soluções que se traduziram, na sua maioria, no desenvolvimento de ambientes de programação que tentam minimizar estas dificuldades. O que não é de estranhar uma vez que não existe uma resposta correcta que abranja estas dificuldades na sua totalidade. Na secção seguinte, sumariza-se as diferentes soluções propostas para o ensino da programação de forma ajudar a colmatar estas dificuldades.

3.3. Soluções propostas na literatura para o ensino da programação
Na literatura científica encontram-se muitos artigos que relatam experiências ou abordagem utilizadas no desenvolvimento de ferramentas cuja intenção é melhorar a eficácia do ensino e da aprendizagem introdutória da programação de computadores. Contudo, encontram-se poucos artigos relacionados com pedagogias para o ensino da programação. Algumas das metodologias, consistem num conjunto de linhas orientadoras que alertam os professores para determinadas questões de forma a melhoraram a aprendizagem dos alunos. Por exemplo Hanks e Brandt (2009) do estudo que desenvolveram, sugerem que os professores devem: Tentar que os alunos pensem no problema antes de começarem a codificá-lo. Devem encorajar os alunos a perguntarem-se “Por que ordem devo fazer isto?”

39

Capítulo III: Ensino da Programação Ensinar os alunos a compilar e a testar os seus programas frequentemente. Se o professor programar em frente aos alunos deve seguir este exemplo para que os alunos se habituem a fazê-lo também. Assim, os alunos vão verificando e corrigindo os erros de sintaxe à medida que surgem, sendo mais fácil para os alunos aperceberem-se das falhas que cometem. Ensinar os alunos a usar o debugger, uma vez que muitos não o sabem utilizar. Fazer o debugging a um programa é uma forma de os alunos compreenderem o que o debug faz e de corrigirem os erros de execução. Esta aproximação também á corroborada por outros autores como Murphy et al. (2008). Salientar as partes da linguagem de programação em que os alunos se confundem mais. Incentivar os alunos a usarem técnicas de teste. A realização de testes é uma forma disciplinada de desenvolvimento, que implica a escrita de blocos autónomos de teste antes da implementação da correspondente unidade funcional. Esta metodologia de testes tem vindo a ser usada na indústria no desenvolvimento de software (Larman e Basili, 2003). Recentemente foi aplicada no ensino introdutório da programação com algum sucesso (Wellington et al., 2007; Desai et al. , 2009), como forma de facilitar a aprendizagem da programação, na medida em que obriga os alunos a testarem cada uma das subsoluções do problema e a verificarem se está correcta, ajudando-os assim na construção de uma solução geral para o problema. No entanto, os alunos apresentam alguma resistência à utilização desta metodologia, como referem Melnik e Maurer (2005): no estudo que efectuaram, os alunos que ainda não compreendem o que um programa faz têm dificuldades em desenhar testes. Esta dificuldade levou ao desenvolvimento de algumas ferramentas para simplificar a escrita de testes, como o ComTest (Lappalainen et al., 2010) mas ainda faltam estudos que comprovem a sua eficácia.

3.3.1. Programação modular
A programação modular é uma metodologia que vem sendo utilizada no ensino da programação desde os anos 70 (Lemos, 1979; Dutta, 1985; Kiczales e Mezini, 2005). Esta metodologia consiste em segmentar o problema em unidades ou módulos que correspondem a uma tarefa que pode ser codificada, compilada e testada como um

40

Capítulo III: Ensino da Programação subprograma independente. Como consequência da utilização desta metodologia, os sub-programas são menos complexos, resultando em programas melhor estruturados. Por outro lado os sub-programas são mais fáceis de testar e de corrigir os possíveis erros. Esta abordagem segue a abordagem top-down para resolver problemas, que consiste em dividir o problema inicial em sub-problemas cada vez mais pequenos, de modo que o problema original se torne mais compreensível e de mais fácil interpretação.

3.3.2. Abordagem gramatical
A abordagem gramatical envolve a exposição passo-a-passo da estrutura gramatical da linguagem de programação adoptada. Este método consiste em ensinar aos alunos a linguagem de programação, salientando as regras da linguagem e focando a maioria das opções desta. Com esta abordagem, relativamente à anterior, os alunos podem começar a codificar os programas mais cedo. Contudo, os alunos pouco ficam a conhecer da natureza da programação, uma vez que grande parte do tempo é passado com o ensino das regras gramaticais. Esta metodologia tem vindo a ser criticada como metodologia de ensino devido às dificuldades que os alunos sentem com a sua utilização, como foi referido na secção anterior.

3.3.3. Abordagem em espiral
A ideia-base da abordagem em espiral consiste em ensinar a linguagem de programação usando uma aproximação estrutural em vez de gramatical. Assim, tópicos como a sintaxe da linguagem, a estrutura física do computador e as instruções específicas da linguagem não são abordados nas primeiras semanas de aulas. Os alunos focam-se na escrita de simples programas no inicio do seu estudo, progredindo sucessivamente para níveis de dificuldade maior, centrando-se em programas que ilustram os vários conceitos de programação. Lemos (1979) refere que com esta abordagem torna-se mais fácil para o professor distinguir quais as dificuldades que os alunos sentem na resolução de problemas e na sua codificação.

41

Capítulo III: Ensino da Programação

3.3.4. Protocolo “pensar em voz alta”
Arshad (2009) sugere outra abordagem para o ensino introdutório da programação, baseada no protocolo de pensar em voz alta. Este protocolo foi desenvolvido por Ericcson e Simon (1984), com o objectivo de compreender o processo de pensamento que um sujeito utiliza ao usar um produto ou dispositivo. Neste protocolo é dada uma tarefa a realizar a uma pessoa que a executa e simultaneamente explica verbalmente o método que emprega para a concretizar. Esta abordagem tem vindo a ser utilizada no ensino da física com algum sucesso (Walsh et al., 2007). Arshad (2009) usou este protocolo no ensino introdutório da programação, durante o qual semanalmente os alunos observavam um perito em programação a resolver um problema. Enquanto o perito resolvia o problema ia explicando verbalmente o processo mental que estava a fazer. Os alunos, por seu turno, podiam ir colocando perguntas de forma a perceberem o que se estava a passar. Posteriormente, nas aulas laboratoriais era dado aos alunos um conjunto de exercícios semelhantes, para estes praticarem o que tinham visto o perito fazer. Arshad também sugere que se utilize uma ferramenta de discussão, onde os alunos possam colocar as suas questões e trocar impressões uns com os outros. No estudo realizado utilizando esta metodologia, Arshad concluiu ser uma abordagem eficaz mas que não deve ser usada isoladamente, antes em conjunto com outras como, por exemplo, uma ferramenta de discussão e aulas práticas de laboratório.

3.3.5. Programação de jogos
Esta abordagem tem por objectivo ir ao encontro dos interesses da maioria dos alunos, que frequentemente são os jogos, e consequentemente motivá-los para a aprendizagem da programação. Na programação de um jogo é dado ao aluno o motor ou o interface deste, sendo-lhe pedido que implemente as suas funcionalidades. Outra vertente consiste em pedir ao aluno que crie um jogo completo, processo no qual o aluno tem de criar as personagens e o enredo do jogo. Esta abordagem tem a vantagem de deixar os alunos expressarem a sua criatividade, servindo de suporte à compreensão e motivação destes pela aprendizagem da programação. Wu (2009) sugere a utilização da linguagem JavaScript para o desenvolvimento de jogos, uma vez que esta linguagem tem a particularidade de permitir aos alunos criarem os seus jogos e disponibilizá-los na Web. Outro aspecto do uso de JavaScript é a vantagem de os alunos aprenderem os

42

Capítulo III: Ensino da Programação conceitos-base de programação utilizando uma linguagem menos complexa que o C ou Java.

3.3.6. Programar do concreto para o abstracto
Esta metodologia baseia-se no princípio de que os jovens aprendem mais facilmente se os dados a estudar forem tangíveis e directamente acessíveis aos seus sentidos visuais, auditivos, tácteis e cinestésicos (Dann e Cooper, 2009). Com a experiência, desenvolvem a capacidade de compreender dados abstractos, manipular símbolos, efectuar raciocínios lógicos e, consequentemente, a generalizar. No entanto, a maioria das pessoas necessita, ao longo da vida, de exemplos concretos para compreender ideias novas (ibid.). Segundo estes autores, no ensino da programação deve-se começar do concreto para a abstracção, como acontece no ambiente de programação Alice. Neste ambiente, os alunos pegam em objectos concretos e familiares, como árvores, casas, carros e outros, e a partir deles criam pequenos filmes de animação ou jogos. Assim, o aprendiz envolvese no desenvolvimento de algo que o motiva, sendo impulsionando na procura e no estudo de soluções, de forma a conseguir colocar em acção o que vai na sua imaginação. Esta abordagem é semelhante à anterior, de programação de jogos. No entanto no ambiente Alice a programação é muito simplificada, como se descreve na secção seguinte.

3.3.7. Padrões de programação
Esta abordagem consiste na utilização de padrões para ajudar os alunos a aprender a programar. Um padrão de programação (Figura 3.2), geralmente, introduz um problema, explica a ideia e os conceitos subjacentes e finalmente apresenta a solução geral, abstracta no contexto de uma determinada linguagem de programação (de Barros et al., 2005). Os padrões de programação podem ajudar os alunos inexperientes de duas formas na aprendizagem de conceitos, estratégias gerais de programação e na resolução de problemas (num nível de abstracção elevado); em assimilar a sintaxe e aprender a usar um linguagens de programação, uma vez que a sua documentação inclui um exemplo de aplicação do padrão.

43

Capítulo III: Ensino da Programação

Figura 3.2: Exemplo de um padrão para a estrutura de repetição while.

A utilização de padrões no ensino da programação torna-se mais eficiente se for utilizada com o apoio de uma ferramenta. Assim, quando um aluno mostra dificuldades em resolver um problema ou uma parte deste, selecciona o padrão relacionado com o problema em causa. Um exemplo desta ferramenta de aprendizagem é ProPAT (de Barros et al., 2005), no qual os alunos poder resolver problemas com a ajuda de padrões, sendo também possível adicionar padrões ao ambiente. Para além das vantagens já mencionadas, os autores desta ferramenta referem ainda que esta abordagem ajuda os alunos a aprender a transferir o conhecimento adquirido para situações análogas.

3.3.8. Programação aos pares
A programação aos pares tem vindo a ser proposta como uma metodologia de ensino. A programação aos pares (“pair programming”) é uma técnica de programação em que dois programadores trabalham em conjunto num único computador, no mesmo projecto. A pessoa que está a escrever no computador é chamada de “condutor” e o outro colega de “navegador”. Ambos têm as suas responsabilidades: o condutor está encarregue de produzir o código, enquanto que o navegador deve procurar erros, pensar na estrutura geral do código, encontrar informação quando necessário, e estar sempre

44

Capítulo III: Ensino da Programação disponível para discutir com o condutor as opções a tomar em cada momento. Enquanto par, os parceiros trocam de papéis regularmente, muitas vezes com base em situações em que um elemento tem uma boa ideia para implementar uma solução. Esta técnica tem sido utilizada em diversos projectos de grande dimensão por se considerar que tem várias vantagens como, por exemplo, aumentar a produtividade e a satisfação, enquanto melhora a qualidade do software desenvolvido (Beck, 1999; Hulkko e Abrahamsson, 2005). De um ponto de vista educativo, a programação aos pares pode ser vista como uma forma de aprendizagem colaborativa. Esta metodologia de aprendizagem tem vindo a ser reportada como uma técnica que ajuda os alunos a aprender a programar, resultando numa melhoria do sucesso escolar (McDowell et al., 2006). Diversos autores referem que o trabalho colaborativo em geral, e a programação em pares em particular, são técnicas pedagógicas eficazes para a aprendizagem da programação (Bravo et al., 2004; McDowell et al., 2006; Hedin et al., 2008). Contudo, no estudo desenvolvido por Hans (2007), este concluiu que os tipos de problemas encontrados nos alunos que aprendem a programar aos pares são idênticos aos encontrados nos alunos que aprendem sozinhos. No estudo por si realizado, Hans verificou também, contudo, que os alunos que trabalham aos pares são capazes de resolver mais problemas por si, principalmente erros de sintaxe, o que pode aumentar a confiança e auto-estima do aluno. Na adopção desta metodologia têm surgido estudos sugerindo que a personalidade dos parceiros é um dos factores críticos na sua implementação (Kichuk e Wiesner, 1997; Karn e Cowling, 2006). Uma vez que a programação aos pares é uma prática que envolve duas pessoas que trabalham juntas para alcançar um objectivo comum, o êxito desta prática é largamente determinado pelo grau de eficiência da forma pela qual os pares trabalham em equipa, independentemente das suas capacidades e conhecimentos. Neste contexto da eficácia da equipa, a personalidade tem vindo a ser referida como um factor crítico de sucesso. Contudo, no estudo desenvolvido por Salleh et al. (2009), estes concluíram que diferentes tipos de personalidade não afectam significativamente o desempenho dos alunos na programação aos pares, tendo-se verificado que esta metodologia aumenta a autoconfiança e a satisfação dos alunos na aprendizagem.

45

Capítulo III: Ensino da Programação

3.3.9. Programação por exemplos
A programação por exemplos é uma abordagem semelhante à programação por padrões, uma vez que ambas salientam a utilização de soluções de problemas criados anteriormente. No entanto, na programação por exemplos são utilizados exemplos concretos de programas implementados para resolver um determinado problema. Assim, os alunos observam e estudam exemplos concretos relacionados com o problema que estão a resolver. Desta forma quando os alunos sentem dificuldades em resolver um determinado problema, é-lhes dada uma solução idêntica, que eles analisam e alteram para resolverem o problema em questão. No estudo realizado por Lahtinen et al. (2005), tanto os alunos como os professores consideraram esta abordagem como sendo eficiente no estudo da programação.

3.3.10. Abordagem “bricolage”
Stiller (2009) propôs uma abordagem para o ensino da programação que designou por bricolage approch, inspirada na metodologia de aprendizagem baseada em exemplos (Stiller, e LeBlanc, 2006) e na aprendizagem construtivista. Esta abordagem consiste em duas fases que são (a primeira) a formulação de hipóteses e teste e (a segunda) a resolução de problemas. Na primeira fase é dado aos alunos um programa para testarem e com ele se familiarizarem em termos da execução que apresenta. Os alunos, por seu turno, ao testarem o programa vão desenvolvendo hipóteses de forma a explicar o respectivo funcionamento. Nesta fase é também pedido aos alunos que façam pequenas alterações no programa dado e observem o resultado dessas alterações. Assim, os alunos vão compreendendo como o programa funciona e simultaneamente assimilam os conceitos que estão a ser ensinados. Na segunda parte desta metodologia, que tem início após os alunos compreenderem o programa dado, é-lhes pedido que usem este programa como ponto de partida para o desenvolvimento de outro com novas funcionalidades. Esta metodologia tem vindo a ser utilizada por este autor com algum êxito no ensino introdutório da programação. Contudo, o mesmo autor refere ainda que a abordagem tem uma desvantagem, que é o facto de os alunos não desenvolverem nenhum programa de raiz, podendo levá-los a pensar que não são capazes de o fazer.

46

Capítulo III: Ensino da Programação

3.3.11. Sistemas de suporte ao ensino da programação
Na literatura científica encontram-se algumas ferramentas que foram desenvolvidas com o propósito de ajudar os alunos a colmatar as suas dificuldades, que se destacam na secção seguinte. Estas ferramentas são usadas conjuntamente com algumas das abordagens descritas, nomeadamente a programação aos pares, os padrões de programação, entre outras. Em suma, após a análise deste conjunto de abordagens conclui-se que a quase totalidade destas podem auxiliar o aluno como algo complementar, mas como referem Martins et al. (2010) é importante que os alunos percebam que programar é acima de tudo um exercício mental que pode ser desenvolvido através de actividades adequadas e com esforço. Assim, qualquer estratégia pedagógica dirigida à aprendizagem de programação deve alertar os alunos que resolver problemas de programação é uma actividade que eles são totalmente capazes de realizar. É importante estabelecer um contexto e criar uma dinâmica nas aulas que motivem os alunos a trabalhar e os impulsione a envolverem-se e a comprometerem-se na sua aprendizagem. Assim, a autora encara a utilização dos mundos virtuais como um modo a criar um contexto de aprendizagem no qual os alunos possam dar largas à sua imaginação, construir objectos como, por exemplo, robôs e divertirem-se a programar o seu comportamento. Desta forma, pretende impulsionar os alunos a envolverem-se activamente no seu processo de aprendizagem. Como Barret (2005) refere: aprender exige tanto a diversão de brincar com as ideias assim como o esforço de as redefinir e reformulá-las, ambas as partes são complementares e necessárias na aprendizagem. A esta diversão Papert (1996) designou de “hard fun”, que é desafiadora e interessante e por isso implica esforço.

3.4. Ferramentas de suporte ao ensino da programação
Uma análise da literatura das ferramentas propostas por vários autores permite aferir a existência de diversos tipos, tanto no seu âmbito de aplicação, como no que respeita ao tipo de estratégia que utilizam, e ao tipo de actividades que suportam. Assim, existem algumas ferramentas bastante restritivas, quer no tipo de actividade pedagógica permitida, quer em relação ao âmbito de aplicação, limitando-se a apoiar a aprendizagem de tópicos específicos, como, por exemplo, árvores binárias ou algoritmos de 47

Capítulo III: Ensino da Programação ordenamento, nos quais os alunos são meros espectadores. Outras ferramentas, normalmente mais genéricas, permitem ao aluno introduzir e simular os seus próprios algoritmos ou programas, possibilitando-lhes assim uma participação muito mais activa no seu próprio processo de aprendizagem. Os tipos de ferramentas mais comuns são: ferramentas de animação – de algoritmos e de programas; os mundos programáveis; os ambientes de desenvolvimento controlado.

3.4.1. Ferramentas de animação
3.4.1.1. Ferramentas de animação de algoritmos As ferramentas de animação de algoritmos, também designadas por ferramentas de visualização, na sua generalidade, são representações gráficas das sucessivas operações computacionais que um determinado algoritmo desencadeia. Estas ferramentas foram, na sua maioria, desenvolvidas com o propósito de ajudar os alunos a compreenderem como funcionam os algoritmos, ou ajudar a perceber como se processam as operações nos tipos de dados abstractos, como por exemplo nas listas. Assim como auxiliar os professores, durante as aulas, a ilustrar como se processam as operações num determinado algoritmo (Brown e Najork, 1996). As primeiras ferramentas de animação surgiram por volta dos anos 80 com o Brown ALgorithm Simulator and Animator (BALSA). O BALSA é um sistema interactivo de animação de algoritmos que permite visualizar diferentes pontos de vista de um algoritmo e da estrutura de dados a ele associada (Brown, 1984a). Este sistema permite aos alunos invocar o código existente e sobre o qual o BALSA gera uma animação. Os alunos ao observarem estas animações compreendem melhor o funcionamento dos algoritmos (Brow, 1984b). Nesta linha de desenvolvimento surgiu o Transition-based ANimation GeneratiOn (TANGO) em 1989, reconhecido pelo facto de ter introduzido uma nova técnica de animação chamada Path Transition. Esta técnica baseia-se na noção de que uma animação é criada através de um conjunto de alterações feitas sobre uma imagem (Stasko, 1989).

48

Capítulo III: Ensino da Programação Desde então, muitos outros sistemas de visualização foram desenvolvidos. Os mais comuns retratam o comportamento de um algoritmo ou de uma família de algoritmos como, por exemplo, os algoritmos de ordenação e pesquisa, algoritmos que manipulam estruturas de dados dinâmicas, como as listas, as árvores ou os grafos. Por exemplo, no endereço http://www.cs.ubc.ca/spider/harrison/Java/sorting-demo.html podem-se executar várias applets relacionadas com os algoritmos de ordenação. Estas animações, na generalidade, permitem ao aluno um baixo nível de interactividade, limitando-se a demonstrar o funcionamento do algoritmo.

Figura 3.3: Exemplo da animação de um algoritmo no sistema Algorithma 98, representado na figura da esquerda e no sistema ANIMAL na figura da direita.

Noutras aplicações um pouco mais evoluídas, o utilizador pode intervir no funcionamento do algoritmo, através da inserção de valores, e até escolher outros algoritmos dentro do mesmo estilo de animação. Como acontece, por exemplo, nos sistemas CAT (Brown e Najork, 1996), IDSV (Jarc e Feldman, 1998), PILOT (Bridgeman et al., 2000), VIP (Virtanen et al. 2005) e JHAVÉ (Naps e Rößling, 2007). Dentro deste tipo de ferramentas existem alguns sistemas que permitem ao utilizador criar as suas animações, limitadas a um tipo de estrutura de dados. É o caso do MatrixPro (Karavirta et al., 2004), que permite aos professores criarem animações para um algoritmo, desde que a sua estrutura de dados seja um vector, uma lista ligada, uma árvore ou um grafo. Para os alunos, a ferramenta oferece a possibilidade de visualizar a animação e um conjunto de exercícios onde os alunos simulam o funcionamento do algoritmo. Os alunos, ao visualizar uma animação no MatrixPro podem avançar, 49

Capítulo III: Ensino da Programação retroceder ou ir para um passo específico da animação, indicar a velocidade desta, e inserir pontos de paragem (Figura 3.4).

Figura 3.4: Exemplo do sistema MatrixPro.

Dentro deste tipo de ferramentas, destaque-se o sistema SICAS (Gomes e Mendes, 2000), por permitir animar os algoritmos construídos pelos alunos (Figura 3.5). O SICAS tem a finalidade de apoiar a aprendizagem de estratégias e mecanismos básicos de construção de algoritmos para resolver problemas de programação, dando especial ênfase à utilização de estruturas de controlo como selecção e repetição. É um sistema que possibilita, essencialmente, dois tipos de cenários: edição / resolução do problema e execução / simulação de soluções previamente construídas. No primeiro cenário, o aluno pode construir algoritmos através de fluxogramas recorrendo à simbologia gráfica que representa as principais estruturas necessárias à construção de um algoritmo. No segundo cenário (execução / simulação), o aluno pode simular / animar a execução das resoluções anteriormente elaboradas, analisando com detalhe e ao ritmo desejado as várias fases e entidades do problema em causa. Recentemente surgiu uma evolução deste sistema, o SICAL-COL (Rebelo, 2007), de modo a suportar actividades

50

Capítulo III: Ensino da Programação colaborativas à distância. Esta ferramenta resulta da integração do SICAS com a ferramenta colaborativa PlantEdit (Redondo, Bravo, Ortega, Verdejo, 2002).

Figura 3.5: Ambiente de trabalho do SICAS.

3.4.1.2. Ferramentas de animação de programas Ao contrário das ferramentas referidas no ponto anterior, existem outras que permitem gerar animações a partir do código-fonte. O número de aplicações existente deste tipo é consideravelmente menor do que as ferramentas de animação de algoritmos, uma vez que o esforço para desenvolver uma simples ferramenta de animação de programas é muito maior dado ser necessário fazer o parse (análise gramatical ou lógica da linguagem de programação). Estas animações, na generalidade, mostram as instruções em execução e respectivas consequências, por exemplo, no valor das variáveis. Dentro deste tipo de sistemas existem aqueles cujas animações são efectuadas sobre um conjunto de programas prédefinidos como é o caso do Webworks (Boroni et al., 1999), (Figura 3.6).

51

Capítulo III: Ensino da Programação

Figura 3.6: Ambiente do animador de programas da Webworks.

Alguns sistemas deste género são mais abrangentes por permitirem ao aluno inserir os seus próprios programas, possibilitando-lhes assim observar como o seu programa funciona e os erros que contém, como é o caso dos seguintes sistemas: LEONARDO (Demetrescu, e Finocchi, 2001), OOPAnim (Esteves e Mendes, 2003), Codewitz (Kujansuu e Kulmala, 2003), Alma (Pereira e Henriques, 2003), JeCo (Moreno, Myller, e Sutinen, 2004), ALVIS Live! (Hundhausen e Brown, 2007), WinHIPE (Pareja-Flores et al. 2007). A título de exemplo descreve-se de seguida o sistema Jeliot.

3.4.1.2.1. Jeliot O sistema Jeliot (Moreno et al., 2004) é um sistema de animação de programas que teve início há quase treze anos com o sistema Eliot (Sutinen et al., 1997), cujo objectivo consistia em ajudar no desenvolvimento de animações de algoritmos. Este sistema deu origem ao JEliot (Java-Eliot), que actualmente vai na terceira versão com o JEliot 3 (Moreno e Joy, 2007). O JEliot 3 permite fazer a animação de programas escritos em 52

Capítulo III: Ensino da Programação Java. A animação incide sobre o valor das variáveis e dos métodos invocados, realçando a linha de código que está a ser executada. Na área de animação, o valor das variáveis, dos objectos e das classes vão sendo actualizados. O Jeliot 3 permite aos alunos seguir a execução do programa passo a passo, parar e voltar atrás (Figura 3.7). Estes sistemas são normalmente designados por debbugers visuais (Kelleher e Pausch, 2005).

Figura 3.7: Ambiente de trabalho do Jeliot 3.

3.4.1.3. Discussão Como foi descrito nos pontos anteriores, existe uma grande variedade de ferramentas de animação de algoritmos e de programas cujo intuito é melhorar a aprendizagem e ajudar os alunos a superar as dificuldades que sentem. Contudo, os resultados dos estudos efectuados indicam que os benefícios obtidos na sua utilização no ensino e aprendizagem da programação são questionáveis (Hundhlausen et al., 2002; Naps et al., 2002; Tversky, Morrison e Betrancourt, 2002). No estudo efectuado por Hundhlausen et al. (2002), os investigadores concluíram que a forma como a ferramenta é utilizada na aprendizagem é mais importante na eficácia desta do que os elementos gráficos usados

53

Capítulo III: Ensino da Programação na animação. Estes resultados influenciaram o desenvolvimento de um conjunto de directivas, descritos por Röbling e Naps (2002), indicando o que estas ferramentas devem conter para serem eficazes no ensino e aprendizagem da programação, como por exemplo: permitir ao aluno inserir dados, possibilitando assim que este compreenda melhor o funcionamento do algoritmo; permitir controlar o desenrolar da animação, ou seja, a ferramenta deve permitir que o aluno volte atrás, ande para a frente, pare ou controle a velocidade da animação – assim o aluno tem uma percepção melhor do seu funcionamento; possibilitar ao aluno e ao professor irem directamente para um ponto especifico da animação – este é um aspecto importante, principalmente para o professor poder fazer chamadas de atenção para um aspecto particular do algoritmo. Estas recomendações foram seguidas no desenvolvimento de alguns sistemas de animação como, por exemplo, no SICAS. Estudos feitos com o ambiente SICAS concluem que os alunos que usaram este ambiente desenvolveram melhores algoritmos do que os restantes colegas que não o usaram (Rebelo, Marcelino e Mendes, 2005). Hundhausen et al.(2009), também corroboram este resultado; no estudo que realizaram com ambiente ALVIS: concluíram que este reduz a resistência inicial dos alunos em aprender a programar e encoraja-os na exploração do processo de programar sendo esta mais centrada na execução do código. Contudo, estes autores mencionam que são necessários mais estudos para verificar se este tipo de ambientes facilita realmente a migração para outros ambientes profissionais. Algumas destas ferramentas têm vindo a ser utilizadas em situações de aprendizagem colaborativa, de modo a melhorar a aprendizagem da programação, em particular a programação aos pares (Williams et al. 2000; Hundhausen, 2002; Nagappan et al. 2003; Simon et al. 2004; McDowell et al. 2006; Hundhausen e Brown, 2008). A aprendizagem colaborativa baseia-se na argumentação e no conhecimento partilhado, assim como na coordenação de trabalhos em grupo (Soller et al., 2005). Alguns autores defendem a junção dos benefícios da visualização e colaboração como forma de aumentar o nível de empenhamento dos alunos na aprendizagem (Hübscher-Younger e Narayanan, 2003; Nguyen, Huang e Hawryszkiewycz, 2004; Myller et al., 2007; Balakrishnan, Fussell e Kiesler, 2008; Papka, 2009).

54

Capítulo III: Ensino da Programação No estudo que Myller et al. (2007) fizeram sobre a utilização da visualização e aprendizagem colaborativa não foram observadas grandes diferenças nos resultados obtidos no grupo de alunos que usufruíram da visualização e colaboração em relação aos que beneficiaram apenas da visualização. Contudo, numa réplica feita deste estudo por Laakso et al. (2009) obtiveram-se diferenças significativas usando a visualização num contexto colaborativo. Resultados idênticos foram obtidos por Hübscher-Younger e Narayanan (2003): os alunos que beneficiaram da visualização juntamente com a colaboração obtiveram melhores resultados. Assim também Hundhausen e Brown (2008) salientam que a utilização da visualização colaborativa aumenta o nível de envolvimento dos alunos no processo de aprendizagem. Myller et al. (2009) indicam que, para a visualização e a colaboração serem uma ferramenta eficaz, esta deve permitir aos alunos interagirem e construírem a sua animação, uma vez que os alunos ao observarem passivamente a visualização diminuem o nível de colaboração. Estes autores sugerem ainda, que uma ferramenta deve suportar diferentes níveis de envolvimento dos alunos, como por exemplo, a possibilidade dos alunos alterarem os valores de entrada durante a execução da animação ou o uso da animação para discutir os resultados obtidos. Estas argumentações vêm ao encontro do que Röbling e Naps (2002) alegam, como foi referido anteriormente. Como salienta Kelleher (2006): “It can be easier and more fun to learn with a group of people “. Apesar da abundância de ferramentas de animação e de estas poderem ajudar os alunos na aprendizagem de alguns aspectos da programação, a sua adopção generalizada pela comunidade académica ainda não ocorreu (Röbling e Naps, 2002; Kaczmarczyk, et al., 2010). Uma das razões apontadas para esta resistência à sua utilização, deve-se ao facto de não existirem estudos que comprovem a sua real eficácia na aprendizagem (Hundhlausen et al., 2002; Hundhausen et al. 2009). Contudo, a animação visual de um programa pode ser útil pelo menos a três níveis: ajuda a compreender a semântica operacional da linguagem fonte; é um auxiliar à depuração de erros (debugger de alto nível); facilita o entendimento dos algoritmos (Esteves e Mendes, 2004). No entanto, as ferramentas de animação não devem ser usadas isoladamente, mas como parte integrante da experiência de aprendizagem. O valor real de uma animação não reside na sua simples visualização, mas na capacidade de permitir que o aluno intervenha, construa, explore, modifique, experimente e teste as suas teorias e soluções.

55

Capítulo III: Ensino da Programação

3.4.2. Mundos programáveis
Os mundos programáveis são uma técnica utilizada para facilitar a aprendizagem da programação inspirada na linguagem Logo (Papert, 1980). Estes ambientes, na sua generalidade, eliminam os detalhes que não são importantes para os conceitos que estão a ser ensinados. Pretendem imergir os alunos no mundo de um agente – uma tartaruga ou um robô – para que estes se sintam os actores principais que estão a conduzi-lo, facilitando deste modo a construção dos modelos mentais dos conceitos que estão a aprender (Buck e Stucki, 2001). Por exemplo no sistema “Karel the Robot”, mencionado mais adiante, os detalhes eliminados foram as variáveis, tendo esta noção abstracta sido substituída pelo estado que o robô Karel ocupa no mundo. Sendo este estado visível e manipulado pelo programa do Karel, isto torna o estado mais real para os alunos do que um conjunto de valores alfanuméricos armazenados na memória. Um exemplo largamente utilizado deste tipo de mundos é o “Karel the Robot”, já mencionado nos parágrafos anteriores (Pattis, 1981). Karel é um robô que habita num mundo simples de grelhas com ruas e avenidas perpendiculares, no qual este se movimenta (Figura 3.8). Assim, o Karel desloca-se pelo mundo, vira e detecta as paredes que se encontram a meio bloco de distância de si, e apita se estiver no mesmo bloco. Os alunos desenvolvem programas que movimentam o Karel pelo mundo e fazem-no executar pequenas tarefas. O simulador do Karel permite aos alunos observarem o progresso dos seus programas passo a passo. O Karel tem inspirado o desenvolvimento de outros mundos programáveis, como por exemplo: Josef the robot (Tomek, 1983), Martino, (Olimpo et al., 1985), PMS (Tomek et al., 1985), Robot Brothers (Olimpo, 1988), Marta (Calabrese, 1989), Pascal Genie (Miller e Chandhok, 1989), Turingal (Brusilovsky, 1991), JKarelRobot (Buck e Stucki, 2001), Jeroo (Sanders e Dorn, 2003). Estes mundos, na sua maioria, incluem um simulador que permite aos alunos observarem a execução dos seus programas. Através do uso destes mundos, os alunos rapidamente se familiarizam com várias estruturas de controlo, como, por exemplo, o if e as estruturas de repetição. Assim, pretende-se que quando os alunos passarem para linguagens de programação de uso geral e mais complexas tenham uma preparação que lhes facilite essa mudança, ao contrário do que acontece com a generalidade dos alunos quando iniciam o estudo da programação (Kelleher e Pausch, 2005).

56

Capítulo III: Ensino da Programação

Figura 3.8: Um exemplo do mundo de o Karel the robot.

3.4.2.1. Discussão Os resultados da utilização do Karel mostram que neste ambiente os alunos são introduzidos aos conceitos fundamentais da programação orientada a objectos de uma forma natural (Pattis, 1995; Becker, 2001; Bergin, 2006). Na generalidade dos cursos os alunos usam o Karel somente durante as primeiras 4 a 5 semanas nas quais são introduzidos os conceitos-base como os objectos, a herança e outros. Depois desta introdução, o Karel é posto de lado e os alunos passam a usar outros ambientes (Buck e Stucki, 2001; Becker, 2001;Bergin, 2006). Becker (2001) adaptou o Karel++ para a linguagem Java, tendo utilizado este ambiente durante as primeiras 5 semanas de forma a introduzir os conceitos básicos. Becker concluiu que a utilização do Karel++ permitiu aos alunos compreenderem estes conceitos iniciais, o que lhes facilitou a tarefa de progredirem na sua aprendizagem. Um dos aspectos mais apreciados pelos alunos durante a utilização do Karel++ foi o facto de este ambiente lhe permitir verificar visualmente se o programa estava correcto ou não, através do comportamento do robô no ecrã (ibid.). Estudos feitos com o ambiente ObjectKarel, que é uma extensão do Karel++ ao qual foram adicionadas outras funcionalidades como, por exemplo, poder executar o programa passo a passo, também corroboraram estes resultados (Xinogalos, Satratzemi e Dagdilelis, 2006). Segundo Buck e Stucki (2001) o Karel apresenta algumas limitações, tais como, por exemplo, a nível da compreensão o Karel não ajuda o aluno a prever qual o comportamento do robô ao executar uma determinada instrução. Por outro lado, alguns 57

Capítulo III: Ensino da Programação alunos sentem dificuldades em fazer a ligação entre o comportamento do Karel e o código que este está a executar. Outro aspecto é o facto de este ambiente ser utilizado pelos alunos por pouco tempo devido à limitação de conceitos que se pode ensinar (ibid.). No JKarel, alguns destas limitações foram ultrapassadas com a utilização da linguagem Java e por permitir aos alunos construírem um programa usando fluxogramas (Buck e Stucki, 2001). Resultados obtidos com a utilização deste ambiente mostram que os alunos têm uma melhor percepção da execução do programa (ibid.).

3.4.3. Ambientes de desenvolvimento controlado
As ferramentas de desenvolvimento controlado oferecem geralmente um conjunto limitado de características das ferramentas profissionais. Em alguns casos, o ambiente é modificado de forma a esconder as características mais avançadas, como acontece por exemplo com o GILD (Storey et al., 2003) e Net-Beans BlueJ Edition (Sun Microsystems, 2009). Outras ferramentas foram criadas especificamente para ajudar a aprendizagem dos conceitos de programação, como por exemplo, Dr Java (Allen, Cartwright e Stoler, 2002), JPie (Goldman, 2004), CodeLab (Craft, 2004), jGRASP (Jain et al., 2006), SimplifIDE (Vogts, Calitz e Greyling, 2008) e o BlueJ, do qual se faz uma breve descrição.

3.4.3.1. BlueJ O BlueJ (Köling, Quig, Patterson e Rosenberg, 2003) permite o desenvolvimento de programas na linguagem Java e representa graficamente as classes, os objectos de cada classe e as relações entre elas, caso existam (Figura 3.9). Para além disso, o BlueJ também permite que os alunos testem o código dos objectos individualmente fora do contexto da execução do programa completo. Assim, o BlueJ ajuda os alunos no desenho dos programas. Os alunos podem ver o código de cada classe representado graficamente, através de um simples clicar do botão do rato sobre a imagem da classe.

58

Capítulo III: Ensino da Programação

Figura 3.9 : Ambiente de trabalho do BlueJ.

Alguns sistemas deste tipo são projectados tendo em mente que uma das formas de ajudar os aprendizes inexperientes a programar consiste em contornar os problemas de sintaxe que os alunos sentem quando iniciam a sua aprendizagem (Kelleher e Pausch, 2005). Estes sistemas usam gráficos ou objectos físicos que representam elementos dos programas, como comandos, estruturas de controlo ou variáveis. Estes objectos podem ser combinados de diferentes modos para gerarem os programas. Exemplos destes ambientes incluem o Pet Park Blocks (Cheng, 1998), o Pict (Glinert and Tanimoto, 1984) ou o Drape (Overmars, 2000). De seguida descreve-se o sistema Alice, a título de exemplo.

3.4.3.2. Alice O Alice (Pierce et al., 1998) é um exemplo de uma ferramenta deste género desenvolvida pela Carnegie Mellon University. No Alice, os alunos aprendem a programar através da manipulação de objectos concretos, que lhes são familiares do mundo real como, por exemplo, casas e árvores, entre outros. Com estes objectos, é possível criar mundos virtuais tridimensionais para contar uma história, produzir filmes ou jogos, que são os mais usuais. Neste ambiente os alunos aprendem a criar animações mas também a programar. É uma ferramenta de ensino gratuita, projectada para ser usada no ensino da

59

Capítulo III: Ensino da Programação programação orientada a objectos a alunos inexperientes. O Alice permite que os alunos aprendam os conceitos fundamentais da programação num contexto de criação de filmes animados ou videojogos simples. Neste ambiente, os erros de sintaxe foram eliminados, uma vez que no interface do Alice, os alunos arrastam da interface peças (“azulejos” ou “mosaicos”) que largam no editor da animação para criarem um programa (Figura 3.10). As instruções correspondem a instruções normais de uma linguagem de programação procedimental. Neste sistema, os alunos podem observar imediatamente o resultado da sua programação na animação gerada no ambiente (Figura 3.11). Esta visualização imediata facilita o entendimento por parte dos alunos da relação entre as instruções do programa e o comportamento dos objectos. O Alice permite aos alunos ganharem experiência com todos os conceitos habituais ensinados na introdução à programação procedimental, sem cometerem erros de sintaxe. Uma nova versão do Alice (Dann e Cooper, 2009) encontra-se em fase de testes e pretende permitir aos alunos programar animações num nível mais abstracto usando a linguagem Java. Um dos aspectos negativos apontado ao Alice diz respeito à sua interface, por ser bastante complexa e pesada (DePasquale III, 2003).

Figura 3.10: O ambiente de trabalho do Alice.

60

Capítulo III: Ensino da Programação

Figura 3.11: Uma imagem de um mundo virtual criado com o Alice 3.

3.4.3.3. Discussão A questão que se coloca com a utilização dos ambientes de programação controlados refere-se à sua eficácia relativamente aos IDE profissionais. Vários autores afirmam que os IDE profissionais não são ambientes propícios à aprendizagem da programação, chegando mesmo a mencionar que estes podem ser prejudiciais para os alunos inexperientes, como foi referido anteriormente. Contudo, a maioria destas conclusões não foi formalmente comprovada, uma vez que não existem estudos empíricos que confirmem estas alegações. Para obter resposta a esta questão, Vogts et al. (2008) efectuaram um estudo empírico de forma a analisar qual a influência de se utilizar um IDE profissional ou uma ferramenta de desenvolvimento controlado no ensino da programação a alunos inexperientes (alunos que anteriormente não tiveram nenhum contacto com a programação). Neste estudo foi utilizado um grupo de controlo que utilizou o IDE Borland Delphi tendo o outro grupo usado a ferramenta SimplifIDE. Os alunos foram classificados em categorias de “alto risco” (aqueles cujo desempenho final foi inferior a 65%) e de “baixo risco” (os que obtiveram um valor superior ou igual a 65%). Vogts et al. concluíram que uma ferramenta de desenvolvimento controlado é benéfica para o desempenho dos alunos inexperientes principalmente para os de baixo risco. Os alunos de alto risco beneficiaram da utilização da ferramenta em termos de

61

Capítulo III: Ensino da Programação comportamento a programar, ou seja, menos erros de compilação e menos vezes recorreram à ajuda do sistema. Contudo, os resultados indicam que uma melhoria no comportamento a programar não implica um aumento significativo no resultado académico final. Este resultado realça o facto de que nem todos os alunos beneficiam da ferramenta de igual modo, pelo que os professores precisam de estar atentos aos alunos de alto risco que necessitam de mais assistência de forma a melhorar o seu desempenho. Resultado semelhante foi obtido por BenneDsen e Schulte (2010), que realizaram um estudo no qual analisaram o efeito que tinha no ensino introdutório da programação em Java a utilização do BlueJ Visual Debugger. Neste estudo concluíram que os alunos não beneficiaram grandemente deste ambiente em relação ao grupo de controlo que não o utilizou. Em relação ao ambiente Alice, que usa outra abordagem, estudos efectuados com alunos com idades inferiores a 12 anos apresentaram resultados positivos na sua utilização (Kellehar et al., 2007; Cooper, Dann e Harrison, 2010; Rodger et al., 2010). Por exemplo, no estudo realizado por Kellehar et al. (2007) obtiveram resultados positivos e os investigadores concluíram que a utilização deste ambiente motiva os alunos para a aprendizagem da programação. Outros autores, como Johngard e McDonald (2008), notaram que alguns alunos passam uma boa parte do tempo centrados na criação das animações em vez de se focarem nos fundamentos da programação. Um estudo efectuado na Universidade Tufts (Powers et al., 2007) usou o Alice no primeiro semestre com alunos do ensino superior, seguido de uma linguagem de alto nível (C++). No semestre seguinte, intercalaram a utilização do Alice com C++, em que cada conceito foi introduzido no Alice e transferido para o C++. Powers et al. observaram dificuldades nos alunos em transitarem para uma linguagem de alto nível, C++. Estas dificuldades centraram-se principalmente a nível da sintaxe: os alunos sentiram-se frustrados quando os seus programas não executavam devido aos erros de compilação existentes, facto que é impossível acontecer quando se programa no Alice. Um estudo realizado recentemente por Garlick e Cankaya (2010) sobre a utilização do Alice com alunos do ensino superior, no qual participaram 150 alunos ao longo de dois semestres, obtiveram resultados negativos, principalmente no que se refere à assimilação de conhecimentosbase de programação, como a noção de declarar e atribuir valores às variáveis ou compreender as estruturas de controlo. A parte que os alunos mais gostaram foi o desenvolvimento de animações. Neste estudo, a maioria dos alunos considerou que o Alice não é um bom ambiente para se aprender a programar. Estes resultados

62

Capítulo III: Ensino da Programação motivaram os autores do Alice a considerar alterar o Alice de forma a permitir os alunos do ensino superior desenvolvessem programas em Java neste ambiente (Dann e Cooper, 2009). No entanto, a nova versão do Alice encontra-se actualmente numa versão beta e em testes, pelo que ainda não são conhecidos resultados destas alterações. Em suma, a utilização de ambientes de programação controlados pode ajudar alguns alunos no seu processo de aprendizagem. Contudo, existem aprendizes que necessitam de outro tipo de assistência que estes ambientes não conseguem dar.

3.5. A programação e os mundos virtuais
Todas as dificuldades relatadas nas secções anteriores, juntamente com o facto de os alunos considerarem a sua primeira experiência com a programação de computadores nada agradável (Kelleher, 2006), faz com que estes se sintam desmotivados e sem interesse em aprender a programar. É necessário introduzir uma mudança inovadora para alterar o estado actual de desinteresse que a generalidade dos alunos demonstra ter pela programação e consequentemente pelos cursos de ciências de computação. Como advoga Violino (2009), “The loss of attraction to [computing] comes from our being unable to communicate the magic and beauty of the field.” Conforme já foi mencionado, os jovens aprendem mais facilmente se os dados a estudar forem tangíveis e directamente acessíveis aos seus sentidos visuais, auditivos, tácteis e cinestésicos (Dann e Cooper, 2009). Com a experiência, eles desenvolvem a capacidade de compreender dados abstractos, manipular símbolos, efectuar raciocínios lógicos e consequentemente a generalizar. No entanto, a maioria das pessoas necessita, ao longo da vida, de exemplos concretos para compreender as novas ideias (ibid.). Segundo os autores referidos, no ensino da programação deve-se começar do concreto para a abstracção, como acontece com o Alice. Papert (1980) refere que: “A programming language is like a natural, human language in that it favours certain metaphors, images, and ways of thinking.” Criar uma representação concreta (modelo externo) de algo abstracto (modelo mental) ajuda na compreensão e facilita a resolução de problemas. Por exemplo, Noyes e Garland (2003) no estudo que fizeram sobre o jogo lógico “Torres de Hanói”, verificaram que o uso de um exemplo externo ajudou os aprendizes em certos aspectos 63

Capítulo III: Ensino da Programação da resolução do problema. Williams e Noyes (2007) mencionam também que uma representação baseada no computador desempenha um papel vital no desenvolvimento das capacidades necessárias para resolver problemas, principalmente na fase inicial da aprendizagem, uma vez que as representações visuais, espaciais e físicas são mais fáceis de reter e manipular. Os alunos, ao obterem uma visualização imediata dos resultados de uma acção, verificam mais facilmente se a sua ideia está certa ou errada. Se estiver errada terão de a corrigir, repensar a solução e, consequentemente, este repensar e reanalisar da situação vai estimular o seu pensamento crítico (Shneiderman, 1983; Kiili, 2005; Chan e Black, 2006). No entanto, alguns estudos concluem que a simples visualização não é suficiente para se obter sucesso na aprendizagem (Naps et al., 2002; Hundhausen & Brown, 2008, Urquiza-Fuentes e Velázquez-Iturbide, 2009), uma vez que os alunos podem olhar para uma visualização dinâmica sem realmente compreender o seu sentido. A visualização torna-se mais eficiente se envolver activamente o aprendiz, ao contrário da simples observação passiva (Pierson e Rodger, 1998; Naps et al. 2002; Hundhausen e Brown, 2005, Schweitzer e Brown, 2009). Por exemplo, na visualização de um algoritmo, os alunos beneficiam muito mais do ambiente se poderem construir e representar as suas próprias visualizações, não só porque este tipo de exercícios aumenta a sua motivação e interesse, mas também por que são um estímulo para gerar discussões significativas sobre o assunto (Hundhausen e Brown, 2007, Urquiza-Fuentes e Velázquez-Iturbide, 2009). Face ao exposto, e seguindo a linha orientadora que levou ao desenvolvimento do Alice, passar do concreto para o abstracto (Dann, Cooper, 2009), influenciou a investigadora a utilizar os mundos virtuais 3D, como plataforma para o ensino e aprendizagem da programação. Nestes mundos, os alunos aprendem a programar num contexto visual 3D, colaborando uns com os outros e inseridos numa comunidade internacional, como acontece por exemplo no mundo virtual Second Life., onde os alunos constroem objectos 3D e desenvolvem programas dentro do mundo para gerar o comportamento funcional desses objectos. Uma das vantagens de utilizar um mundo virtual 3D para o ensino da programação é a possibilidade que os aprendizes têm de ver um objecto ou colocá-lo sob múltiplas perspectivas, os quais podem gerar uma melhor compreensão dos conceitos (Bricken e Byrne, 1994; Dickey, 2005; Champion, e Sekiguchi, 2005). Embora o conceito de mundos virtuais multi-utilizador não ser novo, a crescente popularidade de aplicações de mundos virtuais tem crescido exponencialmente nos 64

Capítulo III: Ensino da Programação últimos 5 anos, como é constatável com os cerca de 180 mundos virtuais actualmente disponíveis ou em desenvolvimento (de Freitas, 2008). Contudo, o aparecimento dos mundos virtuais como ferramenta de ensino e aprendizagem é relativamente recente. Nos últimos anos têm surgido alguns estudos, assim como uma variedade de iniciativas educacionais na introdução dos mundos virtuais como complemento das actividades das aulas tradicionais, e também como meio usado na educação à distância (Barab, et al., 2000; Corbit e DeVarco, 2000; Bailey e Moar, 2002; Barab, Hay, Barnett e Squire, 2001; Dickey, 2003, 2004, 2005, Jong, van der Meijden e von Berg, 2005; Lim, Nonis e Hedberg, 2006; Peterson 2006; Robbins, 2007; de Freitas, 2008; Warburton, 2009). As conclusões gerais destes estudos indicam que os alunos se sentem motivados com a interacção gráfica que estes mundos apresentam, uma vez que são visualmente atractivos, animados e interactivos. Jong et al. (2005) referem que: “3D virtual world can support an effective, active, and more playful learning process” (p. 33). Vários autores (Dede, 1995; Antonacci e Modaress, 2005; Hew e Cheung, 2010) argumentam que os mundos virtuais têm a vantagem de permitir aos alunos experimentar sem as repercussões do mundo real e oferecem oportunidades de aprender fazendo. Esta asserção é compartilhada por Dickey (2005), ao alegar que os mundos virtuais permitem aos alunos aprender através da interacção com objectos virtuais que, dependendo do conteúdo, podem conduzir a uma melhor compreensão dos conceitos. Esta compreensão resulta dos aprendizes interagirem com os objectos 3D do mundo, permitindo-lhes, para além de aprender fazendo, observar os resultados das suas acções, testar as suas hipóteses e reflectir sobre a sua própria compreensão (Winn, 2002; Chee, 2007). A vantagem mais aclamada dos mundos virtuais é o envolvimento, estimulando os alunos a vivenciarem exaustivamente uma dada experiência, podendo ajudar a colmatar o fosso entre a aprendizagem experimental e a representação da informação (Winn, 2002; Sourin et al., 2006). Segundo Austin e Boulder (2007): “Virtual worlds offer an opportunity for people to interact in a way that conveys a sense of presence lacking in other media. These spaces can be huge, in terms of the number of people that use them, and they are growing in popularity because they combine many of the elements that make Web 2.0 really exciting: social networking; the ability to share rich media seamlessly; the ability to connect with friends; a feeling of presence; and a connection to the community.” (p.18).

65

Capítulo III: Ensino da Programação Barab et al. (2000) usaram os mundos virtuais como suporte para facilitar a compreensão dos conceitos de astronomia pelos alunos, baseado numa aprendizagem construtivista. Barab et al. (2000) e Barab, Hay, Barnett e Squire (2001) concluíram que os mundos virtuais podem ser utilizados de forma eficaz como uma ferramenta para facilitar a compreensão dos fenómenos astronómicos. Bailey e Moar (2002) constataram, também, que o uso dos mundos virtuais fomenta a colaboração e a comunicação entre os alunos. Dickey (2003) corrobora estes resultados ao mencionar que a utilização dos mundos virtuais 3D, tal como o Active Worlds, suporta uma aprendizagem construtivista por permitir uma comunicação em tempo-real, juntamente com um ambiente visual e recursos de apoio à colaboração. O mesmo autor refere ainda que o uso dos mundos virtuais 3D ajuda os alunos a desenvolver as suas competências num ambiente colaborativo tridimensional (Dickey, 2004). Antonacci e Modaress (2005) acrescentam que os mundos virtuais ajudam os aprendizes a desenvolver as capacidades de interpretação, análise, avaliação e resolução de problemas. No estudo realizado por Sourin et al. (2006), observou-se que os alunos quando trabalhavam no seu projecto dentro do mundo virtual, que consistia em desenvolver objectos usando ferramentas gráficas, estes gradualmente e sem fazerem um esforço extra eram imersos em muitos conceitos de computação gráfica. O mesmo autor refere, ainda, que este facto fez com que os alunos aprendessem melhor os conceitos de computação gráfica e obtivessem, em média, uma melhoria nos resultados do exame em 14%. Contudo, alguns estudos apresentam resultados contraditórios, referindo que o uso dos mundos virtuais não melhora a aprendizagem dos alunos, uma vez que estes se distraem facilmente durante as actividades online (Dalgarno, 2002; Lim et al., 2006, Omale et al., 2009). Por exemplo, Lime et al. (2006) constataram que os alunos estavam tão preocupados com a exploração do espaço 3D que não se conseguiam concentrar no desenvolvimento das suas actividades. Apesar de durante a escrita desta tese terem surgido alguns estudos relacionados com a utilização dos mundos virtuais na educação, (de Freitas e Neumann, 2009; Warburton e Perez-Garcia, 2009; Veletsianos, 2009; de Freitas et al., 2010; Hew e Cheung, 2010) vários autores continuam a salientar a falta de estudos com linhas orientadoras de como os usar no ensino (de Freitas e Veletsianos, 2010; Hew e Cheung, 2010). Como refere Warburton (2009): “Despite the high level of activity in the area (the Second Life Educators list has a membership figure of over 5000), clear guidelines for practice remain difficult to find.” 66

Capítulo III: Ensino da Programação Face aos problemas relatados que envolvem o ensino e aprendizagem da programação, às diferentes soluções propostas e atendendo ao facto de os alunos continuarem a sentir dificuldades na aprendizagem da programação, a autora sugere a utilização dos mundos virtuais de modo a criar um contexto de aprendizagem no qual os alunos possam aprender partindo do concreto para o abstracto. Pretende-se com a utilização destes mundos criar um ambiente onde os alunos possam “brincar” com as ideias, dar largas à sua imaginação através da construção de objectos, conjuntamente com a programação do seu comportamento. Ambiciona-se com a utilização dos mundos virtuais 3D, imergir os alunos no mundo de modo a que desta forma sejam os actores principais na programação e sejam capazes de sentir e raciocinar qual o passo seguinte a dar para solucionar o problema, de forma semelhante à filosofia usada no Karel. Deste modo, como foi relatado no capítulo de introdução, considerou-se necessário começar por estudar as possibilidades e dificuldades da utilização dos MV3D online como plataforma para o ensino e aprendizagem introdutória da programação de computadores a alunos do ensino superior.

67

4. Mundos Virtuais

Os aspectos abordados no presente capítulo dizem respeito ao processo de caracterização dos mundos virtuais. Dada a panóplia de mundos virtuais existentes actualmente considera-se pertinente efectuar uma sistematização destes com o intuito de seleccionar o que se enquadra nos objectivos deste estudo. Deste modo, começa-se por definir o que são os mundos virtuais enunciando as suas características elementares. Referindo, ainda os seus antecessores, para uma melhor compreensão dos actuais numa breve perspectiva histórica. Apresenta-se também uma categorização dos mundos virtuais analisados, culminando com a justificação da opção tomada.

Capítulo IV: Mundos Virtuais

69

Capítulo IV: Mundos Virtuais

4.1. Caracterização dos mundos virtuais
Os mundos virtuais existem, de algum modo, desde o início dos anos 80 do século passado. Apesar disto, o significado desta expressão não é consensual. Isto reflecte a dificuldade em descrever uma área que está intrinsecamente ligada ao desenvolvimento tecnológico, mas caracterizada também por aspectos sociológicos. Obviamente, as diferenças de entendimento sobre o que é um “mundo virtual” reflectem visões alternativas, ora complementares, ora referentes a conceitos distintos. Considerando a investigadora, contudo, ser esta a expressão mais comum para identificar as plataformas com que trabalhou, optou-se aqui por reunir apenas as definições e características propostas por autores que se enquadram também no significado dado no âmbito do presente trabalho. Segundo Warburton (2009), a definição de mundo virtual mais simples e consensual foi dada por Schroeder (1996) que argumenta que os mundos virtuais devem ser definidos como: “A computer-generated display that allows or compels the user (or users) to have a sense of being present in an environment other than the one they are actually in, and to interact with that environment” (Schroeder, 1996). Outros autores, como Castronova (2001), Smart, Cascio e Paffendof (2007) e de Freitas (2008), consideram que a melhor forma de definir os mundos virtuais é através do conjunto mínimo de características recorrentes que estes contêm, nomeadamente: Representação física – um corpo virtual designado de avatar, que é uma representação personalizada do ser humano; Interactividade – permite uma interacção entre utilizadores e destes com objectos no mundo virtual; Persistência – o mundo virtual continua a existir mesmo quando o utilizador não está conectado e consequentemente não está a participar nele. De seguida retrata-se cada um destas características em pormenor.

70

Capítulo IV: Mundos Virtuais

4.1.1 Representação física
No mundo virtual, cada indivíduo é representado graficamente através de um corpo virtual tridimensional ou bidimensional, consoante a dimensão do mundo, cuja funcionalidade consiste em permitir ao utilizador interagir com esse mundo. A esta representação gráfica dá-se o nome de avatar. Originalmente, o termo “avatar” surge na mitologia hindu e significa a incarnação de um ser divino, tendo sido utilizado na informática pela primeira vez por volta de 1985, por Chip Morningstar (Damer, 2001), para descrever a representação visual dos utilizadores no mundo virtual Habitat (Figura 4.1) – isto embora desde os primórdios do género existisse o conceito de alter-ego ou representação do jogador no espaço virtual dos jogos de computador, mas sem recurso à designação “avatar”. Desde então, este termo tem-se vindo a popularizar não só no seio dos mundos virtuais, mas também na indústria cinematográfica como é constatado através do recente filme Avatar, escrito e realizado por James Cameron (2009).

Figura 4.1: Avatares do Habitat. Imagem retirada de Morningstar e Farmer, 1991.

Nos mundos virtuais existe uma panóplia de formas de avatares que vão desde figuras humanas a animais fictícios (Figura 4.2). A maioria destes mundos possibilita ao utilizador a atribuição de um nome para o seu avatar, que o representa dentro do mundo virtual (sendo portanto uma entidade única nesse mundo), de forma a facilitar a sua identificação.

71

Capítulo IV: Mundos Virtuais

Figura 4.2: À esquerda: avatar da investigadora no SL, “Micaela Korobase”. À direita: um avatar do mundo virtual NeoPets.

A generalidade dos mundos virtuais permite ao utilizador seleccionar, configurar e personalizar o seu avatar, relativamente ao sexo, à forma do rosto, à cor da pele ou outros elementos. Este aspecto transmite ao utilizador uma sensação de solidez e realismo na aparência. A nível educativo, possibilita ao professor e alunos uma identificação visual do outro e o reconhecimento de alguém através da sua representação física fomentando a comunicação (Veletsianos, 2010). O nível de configuração dos avatares permitido depende do mundo: existem mundos como o The Palace com um conjunto de avatares predefinidos, os quais pouco permitem alterar; e outros em que quase tudo é configurável como no The Virtual Hills ou no Second Life (Figura 4.3).

72

Capítulo IV: Mundos Virtuais

Figura 4.3: À esquerda: edição do aspecto visual do avatar da autora no mundo virtual The Palace. À direita: edição da aparência de um avatar no mundo virtual MTV’s Virtual Worlds – The Virtual Hills.

No entanto, os avatares que actualmente existem restringem-se ao mundo virtual em que são criados. Esta limitação implica que o utilizador tenha de criar e configurar um novo avatar sempre que entre pela primeira vez num mundo virtual (Morgado, 2009). Contudo, devido à crescente importância dos mundos virtuais (Gartner, 2007), prevê-se que no final de 2011 80% dos utilizadores activos da Internet tenham um avatar num mundo virtual — perspectiva provavelmente demasiado optimista, mas reveladora do impacte do género nas expectativas do sector informático. Colin Parris, da I.B.M., e a Linden Lab, empresa criadora do mundo virtual Second Life, anunciaram pretender desenvolver um avatar universal que permita ao utilizador movê-lo entre os vários mundos virtuais existentes mantendo o mesmo nome, aparência e inclusive o saldo de dinheiro digital (Lohr, 2007).

4.1.2 Interactividade
Os mundos virtuais na sua generalidade são acedidos remotamente através da Internet, permitindo a partilha do espaço entre vários utilizadores em simultâneo, independentemente da sua localização geográfica. Estes mundos são designados de multi-utilizador, como por exemplo, o Second Life. A grande maioria dos mundos virtuais simula no total ou em parte as leis naturais da Terra, como a gravidade, o dia e a noite, a topologia e o movimento, como forma de

73

Capítulo IV: Mundos Virtuais apresentar alguma familiaridade aos utilizadores e gerar uma mais forte sensação de presença do utilizador no mundo (Castronova, 2001). Para além deste aspecto, os mundos virtuais contêm um conjunto de elementos que geram a sensação de presença e de co-presença, ou seja, a sensação da presença de outrem, fomentando desta forma a interacção entre os seus pares (Warburton, 2009), que são: Físicos – os utilizadores têm uma representação física no mundo (avatar), através da qual podem observar os outros utilizadores (ou seja, os avatares dos outros utilizadores), fazer gestos, rir, colocarem-se em determinadas poses, dançar, abraçarem-se, aplaudir, etc. Para além disso, também permite a possibilidade de localizar geograficamente no mundo outros avatares, por exemplo a partir de um mapa (Figura 4.4).

Figura 4.4: Mapa de algumas áreas do Second Life, referenciando, nos pontos verdes, o número de pessoas que se encontram em cada zona.

Estado – fornece informações mínimas sobre a presença dos avatares no mundo, por exemplo indicando quando os avatares amigos entram ou saem do mundo (ou seja, quando é que os respectivos utilizadores estão online ou offline). Comunicação – na generalidade dos mundos virtuais, a comunicação é efectuada através da comunicação escrita, sendo contudo também comum a comunicação vocal. Em alguns mundos é permitida uma conversação “aberta” (ou seja, pública) através de vários canais, noutros a comunicação é mais restrita

74

Capítulo IV: Mundos Virtuais limitando-se à utilização de um conjunto de frases pré-existentes, como é o caso do mundo virtual Thinking Worlds (Figura 4.5). Contudo, a comunicação encontrada na generalidade dos mundos virtuais é realizada através de conversas textuais (chats) públicas ou privadas. As mais comuns são as conversas textuais públicas, isto é, mensagens que os utilizadores podem escrever e partilhar uns com os outros e que são visíveis por toda a comunidade de utilizadores que se encontra num determinado raio de acção, como acontece por exemplo, no MTV’s Virtual World (Figura 4.6).

Figura 4.5: Exemplo de interacção com outro avatar do mundo Thinking Worlds.

Figura 4.6: Exemplo de uma converção textual pública com vários avatares em simultâneo no mundo virtual MTV.

É possível, também, estabelecer comunicações textuais com outros utilizadores de uma forma privada - mensagens instantâneas (IM) - o que evita a constante interrupção feita por outros utilizadores ou mensagens informativas durante a conversação (Figura 4.7). Estas mensagens geralmente não têm limites de distância virtual, ou seja, são enviadas directamente para o avatar em questão, independentemente da distância virtual a que se encontre.

75

Capítulo IV: Mundos Virtuais

Figura 4.7: Exemplo de uma conversa privada no Entropia Universe.

As características dos mundos virtuais que suportam a interactividade são a base das actividades educativas por permitirem a interacção e a colaboração entre os educandos. Desta forma é possível ter um grupo de alunos a discutir um tema (Figura 4.6) ou a desenvolver uma actividade, independentemente do local físico em que cada aprendiz se encontra (Figura 4.8) como, por exemplo, ocorreu no seminário Ambientes Virtuais 3D em Educação integrado no Mestrado Multimédia em Educação da Universidade de Aveiro, que decorreu no Second Life, a 17 de Novembro de 2008 pelas 21h, durante o qual cada aluno e professor acederam ao SL das respectivas casas.

76

Capítulo IV: Mundos Virtuais

Figura 4.8: Seminário Ambientes Virtuais 3D em Educação na ilha da Universidade de Aveiro no SL.

4.1.3 Persistência
Uma das características importantes dos mundos virtuais é a sua persistência (Rosedale e Ondrejka, 2003), isto é, o mundo continua a funcionar mesmo quando o utilizador se encontra desconectado e já não participa nele. O utilizador pode ligar-se a qualquer momento, mantendo-se no local em que se encontrava anteriormente. Um outro aspecto a salientar é a persistência do aspecto físico do avatar e dos seus pertences, tais como roupa, sapatos, malas e os objectos que criou ou comprou – aspecto que permite ao utilizador identificar-se visualmente com o seu avatar. A persistência do mundo abre um leque de oportunidades do ponto de vista educativo, nomeadamente no que se refere à possibilidade de permitir o prolongamento das actividades educativas no tempo (Salmon, 2009). Desta forma, deixa de existir as limitações que muitas vezes os alunos colocam ao trabalho em grupo, relatando não o apreciarem por não conseguirem se encontrar fora das aulas devido a morarem longe uns dos outros (Miranda, Morais e Dias, 2007). Os professores, por outro lado, têm a possibilidade de acompanhar e observar a evolução do trabalho, sem ser só no momento em que este está a ser realizado. A persistência do mundo permite também a existência de uma comunidade de utilizadores online em cada 24h do dia, como acontece

77

Capítulo IV: Mundos Virtuais por exemplo no Second Life, sendo esta comunidade constituída na sua maioria por construtores activos que compram e vendem produtos. A nível educativo, a existência de uma comunidade que reconhece o trabalho desenvolvido pelos alunos é um factor de motivação que impulsiona os alunos a quererem aprender mais (Lave e Wenger, 1991; Esteves et al., 2008).

4.2. Os antecessores dos mundos virtuais
Os actuais mundos virtuais partilham características comuns que reflectem as suas raízes nos jogos de aventuras e fantasias, como os de “masmorras multi-utilizador” (Multi User Dungeon ou MUD). Estes jogos surgiram durante as décadas de 70 e 80 do século passado, inicialmente baseados em descrições textuais do mundo que envolviam a exploração de espaços e salas com vários obstáculos e opositores (Bartle, 1990). Estes jogos tiveram origem nos jogos role-playing de papel e lápis, muito populares nos anos 70 a 90. O primeiro jogo de role-playing comercialmente disponível foi o Dungeon & Dragons (D&D), criado por Gary Gygax e publicado em 1974 pela TSR, Inc. O sucesso alcançado com este jogo conduziu ao proliferamento de outros jogos similares como o Tunnels & Trolls (focado no jogo a solo), o Traveller ou o RuneQuest. Mais tarde, surgiram estes jogos em computador, permitindo que vários jogadores interagissem em simultâneo uns com os outros da forma que desejassem (Figura 4.9). Um dos primeiros jogos de computador deste género, bastante popular, foi desenvolvido por Richard Bartle e Roy Trubshaw em 1978. Este jogo, designado por MUD (ou seja, o nome deste jogo deu origem ao nome de todo o género), consistia num jogo textual que podia ser jogado em simultâneo por vários jogadores (Bartle, 1990). Posteriormente, estes jogos seguiram outras abordagens, empregando mais regras e características dos D&D, tais como estratégias, a possibilidade de formarem grupos de jogadores para atingirem os objectivos de jogo e basearem-se em fantasias contendo personagens fictícias. Este é um aspecto importante seguido em muitos dos jogos online multi-utilizador (Massively Multiplayer Online Games – MMOG), enquanto outros como o TinyMUD criado em 1989 por Jim Aspnes, focaram-se nas interacções sociais entre jogadores, retirando-lhes toda a componente de fantasia e objectivos de jogo (Cox e Campbell, 1994). Por outro lado, o TinyMUD permitia aos seus utilizadores criarem elementos no mundo, o que o tornou bastante popular, principalmente por ser distribuído gratuitamente (ibid.).

78

Capítulo IV: Mundos Virtuais

Figura 4.9: O interface do Jogo MUD textual.

Estes MUD apresentavam todas as características dos mundos virtuais actuais, embora fossem baseados em texto. Estes sistemas constituíram as bases para o desenvolvimento das comunidades actuais online, que presentemente são baseadas em espaços animados 3D proporcionando um cenário para o dia-a-dia do que ali acontece. As principais semelhanças residem na dimensão e nas comunidades que se formaram nestes mundos baseados em texto, em torno das quais se desenvolveram amizades (de Freitas, 2008). Baseado nesta geração de MUD textuais, emergiu em 1985 o primeiro mundo virtual no sentido utilizado nesta tese, o Habitat da LucasFilm, utilizando gráficos e avatares (Figura 4.1). O Habitat era acedido através da utilização de um modem e de um computador pessoal bastante comum em vários países, o Commodore 64. Este primeiro mundo virtual manteve uma comunidade online durante seis anos, tendo um ambiente social semelhante aos mundos baseados em texto. O Habitat era: “(…) built on top of an ordinary commercial on-line service…Habitat presents its users with a real-time animated view into an online simulated world in which users can communicate, play games, go on adventures, fall in love, get married, get divorced, start businesses, found religions, wage wars, protest against them, and experiment with selfgovernment.” (Morningstar & Farmer, 1991)

79

Capítulo IV: Mundos Virtuais Em 1996 surgiu o mundo virtual Meridian 59, tendo sido considerado o primeiro mundo do tipo Massively Multiplayer Online Role Player Game ou MMORPG (GameSpy, 2003), ou seja, com um número muito elevado — milhares — de jogadores em simultâneo (Achterbosch, Pierce e Simmons, 2008). Na sequência desta forte adesão, o termo massively multiplayer foi introduzido na comunidade dos mundos virtuais, bem como a denominação “mundo persistente” (GameSpy, 2003), uma vez que o mundo continuava a existir quando o utilizador estava desconectado deste. O Meridian 59 empregava muitas das características dos MUD. No entanto, revelou-se inovador pelos seus gráficos, pois permitia aos utilizadores observar no ecrã uma representação gráfica de tudo o que acontecia, como, por exemplo, ver outro jogador a acenar (Figura 4.10). O sistema de comunicação, embora irrealista, uma vez que permitia aos jogadores de qualquer parte do mundo conversar entre eles, facilitava o estabelecimento de uma comunidade. A interface continha elementos que ainda hoje são bastante populares como os mini-mapas (semelhantes a um sistema de radar) e uma caixa de diálogo que permitia, além de conversar, exibir informação detalhada sobre as acções que tinham sido realizadas. Os gráficos do Meridian 59 rapidamente se tornaram obsoletos, mas este mundo virtual conseguiu abrir caminho para o desenvolvimento de outros mundos que actualmente são conhecidos como MMORPG.

80

Capítulo IV: Mundos Virtuais

Figura 4.10: O interface do Meridian 59.

Outro exemplo deste tipo de mundos virtuais bastante popular foi o Ultima Online (UO), lançado em 1997. O UO, que ainda se encontra activo nos dias de hoje, foi considerado o primeiro sucesso comercial deste género de mundos, tendo rapidamente alcançado 100.000 assinantes (Koster, 2002). Recentemente, sofreu uma remodelação no aspecto gráfico, de forma a poder competir com outros MMORPG do género que proliferaram nos últimos anos (Figura 4.11).

81

Capítulo IV: Mundos Virtuais

Figura 4.11: À esquerda: aspecto gráfico do Ultima Online original. À direita: aspecto actual.

Com o desenvolvimento tecnológico verificado nas últimas décadas, principalmente no acesso mais generalizado a equipamento informático com elevadas capacidades gráficas, a banda larga, a serviços Web mais rápidos e a computadores pessoais cada vez mais potentes, foram factores impulsionadores do crescimento acelerado destes mundos virtuais existindo actualmente mais de 180 mundos disponíveis ou em desenvolvimento (de Freitas e Veletsianos, 2010).

4.3. Categorização dos mundos virtuais
Como se explicou na secção anterior, os mundos virtuais existem há mais de 20 anos e dentro deste vasto panorama podem-se encontrar mundos com código-fonte aberto, mundos com acesso livre e mundos privados disponíveis apenas por pagamento de uma licença de utilização. Podem identificar-se também várias plataformas de desenvolvimento e de distribuição segundo o público-alvo a que se destinam. Vários autores têm vindo a propor diferentes formas de classificar os mundos virtuais (Porter, 2004; Messinger, Stroulia e Lyons, 2008; de Freitas, 2008; Warburton, 2009), baseadas na forma como estes podem ser utilizados, nomeadamente: mundos virtuais de competição; mundos virtuais sociais; mundos virtuais de formação;

82

Capítulo IV: Mundos Virtuais plataformas de desenvolvimento mundos virtuais profissionais. Como foi referido no capitulo anterior, pretende-se usar os mundos virtuais no ensino da programação de forma a que os alunos possam aprender a programar partindo do concreto para o abstracto. A partir da construção de objectos os alunos desenvolvem programas que simulam o comportamento atribuído a esses objectos. Pretende-se também fomentar a aprendizagem colaborativa entre os alunos. Deste modo o mundo virtual deve permitir: a conexão em simultâneo de vários utilizadores, com idade superior a 18 anos, com o intuito de trabalharem e colaborarem entre si durante e depois das aulas. O mundo deve ser multi-utilizador e persistente, de forma que os alunos possam trabalhar no mundo quando quiserem e deixarem os seus trabalhos expostos para que os colegas de grupo possam ver o que já foi feito. Assim como possibilitar que o professor acompanhe o que está a ser feito fora das aulas; a comunicação em tempo real entre alunos e o professor enquanto estão online no mundo virtual – o mundo deve permitir comunicação síncrona; a construção de objectos com relativa facilidade, sem requerer muito tempo de aprendizagem. Por outro lado, não deve ser demasiado restritivo no tipo de objectos que se possam criar, uma vez que se pretende que os alunos se envolvam e se motivem com o que estão a fazer. O mundo deve permitir a animação visual dos objectos criados, através da aplicação de programas que simulem determinados comportamentos, como por exemplo, um robô que segue o seu dono pelo mundo. Face ao exposto, na análise dos mundos virtuais procurou-se responder às seguintes questões: Qual o objectivo do mundo? Onde e como pode ser usado? E por quem? – que se traduziram nos seguintes cinco parâmetros: Objectivo: qual o conteúdo, específico ou aberto, focado no mundo; Local: a interacção é restrita a um espaço ou é geograficamente dispersa;

83

Capítulo IV: Mundos Virtuais Plataforma: permite uma comunicação síncrona, assíncrona ou as duas. O mundo é persistente. Qual o tipo de ligação que consente, através do computador ligado à Internet ou é necessário alguma plataforma de jogo específica. O acesso é gratuito ou é necessário o pagamento de uma licença de utilização; População: qual o número de pessoas que permite ter conectado em simultâneo e a sua idade; Programação: possibilita criar objectos dentro do mundo ou fora através de outras aplicações, os objectos podem ser animados visualmente dentro do mundo. Como, ou seja, que tipo de programação suporta para gerar essas animações.

4.3.1 Mundos virtuais de competição
Os MMORPG são mundos virtuais orientados para a competição, com objectivos e regras bem definidas, baseados em narrativas, sendo geralmente utilizados para o lazer. Apesar de estes mundos serem orientados para a competição, também fazem parte dos mundos virtuais sociais, na medida em que existe uma colaboração e socialização entre os participantes para atingir o objectivo final do jogo (Smart et al., 2007). A título de exemplo refere-se: Everquest, Guild Wars, Lineage, Lineage II, World of Warcraft, Meting2, Entropia Universe. (Figura 4.12).

Figura 4.12: Exemplos de mundos virtuais de competição: Lineage II na imagem da esquerda, World of Warcraft na imagem à direita.

84

Capítulo IV: Mundos Virtuais Como pode ser constatado, de uma forma geral, nestes mundos virtuais, os utilizadores têm objectivos de jogo a cumprir, sendo o local de actuação disperso pelo mundo. Contudo, a realização de determinadas tarefas limitam o local de actuação. Relativamente à plataforma, alguns mundos virtuais como, por exemplo, World of Warcraft tem duas opções de utilização: através da Internet online ou localmente no PC sem se recorrer à ligação à rede. Na sua maioria, os mundos desta categoria permitem uma comunicação síncrona, possibilitando a interacção, em simultâneo, de milhares de utilizadores online, como é o caso do World of Warcraft com mais de 8,5 milhões de subscrições (Blizzard Entertainment, 2010).

4.3.2 Mundos virtuais sociais
Ao contrário dos mundos referidos no item anterior, os mundos virtuais sociais caracterizam-se por não terem um objectivo pré-definido, assim como não terem uma narrativa. Um dos aspectos interessantes deste género de mundos virtuais é o facto de não serem centrados numa tarefa mas serem mais uma ferramenta de socialização. Assemelham-se aos espaços de conversas textuais como por exemplo o MySpace or Cyworld (Messinger, Stroulia e Lyons, 2008), em que juntam as características destes com a possibilidade de partilhar recursos, criar objectos 3D e trocar conteúdos multimédia. Nos mundos sociais, o entretenimento pode variar desde concertos ou apenas conversas com os amigos. de Freitas (2008) salienta que as interacções sociais que se estabelecem nestes mundos virtuais são profundamente pessoais e podem inclusive serem íntimas. Alguns destes mundos tornaram-se bastante populares, como é o caso do Second Life (ibid.). Contudo, existem outros que foram encerrados, como aconteceu com o Lively, extinto em 9 de Janeiro de 2009 e mais recentemente com o There.com, que foi oficialmente encerrado em Março de 2010, devido a problemas financeiros (Wilson, 2010). Apesar de o There.com ter sido encerrado, era um mundo virtual aberto, orientado para a socialização, no qual os participantes podiam conversar, jogar, fazer compras ou participar em eventos (por exemplo, festas). Tendo sido criado em 1998 por Will Harvey e Jeffrey Ventrella, a partir de 2001 foram lançadas várias versões beta e em Outubro de 2003 (Wilson, 2010) a versão final. A utilização do There.com estava direccionada a jovens acima dos 13 anos. A comunicação era feita através de uma conversa textual, que podia ser pública, sendo visível por todas as pessoas que estavam 85

Capítulo IV: Mundos Virtuais num determinado raio de acção (Figura 4.13) ou privada, só entre duas pessoas. Os participantes, também, podiam alterar a aparência do seu avatar, experimentar e comprar roupa (Figura 4.14). Contudo, o desenvolvimento de objectos e a sua programação eram efectuados fora do mundo, recorrendo a aplicações específicas, como o StyleMaker e o Painter Toolkit, que requeriam algum tempo de aprendizagem e adaptação (Wilson, 2010).

Figura 4.13: Exemplo de uma conversa textual pública;

86

Capítulo IV: Mundos Virtuais

Figura 4.14:Um avatar a experimentar roupa.

Outros exemplos deste tipo de mundos são também o Kaneva, que tem um elevado número de utilizadores, o Frenzoo e o IMVU, que foram criados recentemente. O Frenzoo começou a ser desenvolvido em 2008 e actualmente está disponível online numa versão beta (Fenzoo Limited, 2010). Este mundo está integrado numa página Web, na qual o utilizador tem um espaço pessoal, podendo colocar e partilhar imagens com os amigos. Por outro lado, tem também a possibilidade de conversar textualmente com os outros avatares em tempo real (Figura 4.15 e Figura 4.14).

87

Capítulo IV: Mundos Virtuais

Figura 4.15: Exemplo de uma conversa textual entre dois amigos no Frenzoo.

Dentro desta categoria pode-se distinguir aqueles que permitem, para além da socialização, a criação de elementos dentro do mundo, como acontece, por exemplo, com o Activeworlds, o DotSoul, e o Second Life. O Activeworlds estreou-se em 1995 sendo um dos mundos virtuais mais antigos que ainda hoje se mantém em funcionamento. O Activeworlds Universe é uma aplicação cliente/servidor que consiste em vários mundos individuais onde os utilizadores podem interagir com outros do universo. Actualmente existem diversas versões do Activeworlds, como por exemplo, o Activeworlds Europe e o Activeworlds Educational Universe (AWEU), fundado em 1999. Este último é um universo separado, dedicado exclusivamente à educação. Neste mundo os utilizadores são representados por avatares, que têm uma identificação única no mundo (Figura 4.16). A comunicação é feita através da conversação textual entre avatares. Os utilizadores têm a possibilidade de construir objectos a partir de réplicas de outros objectos existentes no mundo, como árvores, casas, bancos, entre outros. Este mundo permite também que os utilizadores desenvolvam animações para os objectos criados, tais como abrir uma porta quando um avatar lhe bate. Para tal, o Activeworlds disponibiliza bibliotecas de programação ou “Sofware Development Kits” (SDK) para os utilizadores criarem aplicações que interajam com o mundo.

88

Capítulo IV: Mundos Virtuais

Figura 4.16: O browser do Active Worlds Educational Universe.

Dentro desta categoria, o Second Life (SL) é o mundo virtual mais conhecido, graças à grande exposição mediática desde 2007, tendo sido lançado em 2003 (Rymaszewski et al., 2007). Este é um mundo virtual 3D que usa a Internet como meio de comunicação, no qual a maior parte do seu conteúdo é criado pelos seus utilizadores, comummente designados de residentes. O SL tem a particularidade de permitir aos utilizadores construírem objectos, dentro do mundo, que vão desde simples cadeiras a réplicas de edifícios e locais históricos, como é o caso da versão virtual da Praça do Comércio de Lisboa ou de uma versão virtual do Museu Nacional dos Coches (Figura 4.17). A ferramenta de modelação 3D que o SL disponibiliza é simples e fácil de utilizar sendo uma das que apresenta mais funcionalidades em relação aos outros mundos virtuais actuais (Salmon, 2009). Para além deste aspecto, que o torna bastante popular, tem uma linguagem de programação interna (Linden Scripting Language – LSL) que possibilita a atribuição de comportamentos aos objectos criados. Os programas são desenvolvidos, compilados e executados dentro do mundo. No capítulo seguinte encontra-se uma descrição mais detalhada da ferramenta de modelação 3D, assim como da linguagem LSL. De acordo com Robin Harper (2007), as três directivas principais do SL são a vida em comunidade, a criação colaborativa e também a economia.

89

Capítulo IV: Mundos Virtuais O SL é utilizado como plataforma para educação por diversas instituições, como universidades, empresas e entidades governamentais. Muitas destas instituições têm no SL representações oficiais. Por exemplo, a nível nacional, a primeira organização a utilizá-lo para fins educativos foi a ARCI, desde 2004 (Expresso, 2007). A nível do ensino superior, a primeira instituição a utilizar o Second Life para fins educativos foi a Universidade de Trás-os-Montes e Alto Douro, em Dezembro de 2006, tendo criado um espaço no SL em Fevereiro de 2007 (Bettencourt, 2007). Também pouco depois a Universidade de Aveiro inaugurou um espaço no Second Life, a 25 de Maio de 2007 (JPN, 2007).

Figura 4.17: Na imagem da direita uma réplica da Praça do Comércio de Lisboa no SL; Na imagem da esquerda uma réplica do Museu Nacional dos Coches no SL.

Para além da utilização do SL na educação, muitas organizações têm no SL um balcão de informação, como é o caso do Ministério da Justiça, que tem um centro de mediação e arbitragem (e-Justice Centre). Este centro disponibiliza serviços de mediação e arbitragem aos avatares residentes no SL, podendo ser utilizado para dirimir conflitos derivados de relações de consumo ou de quaisquer contratos celebrados entre as partes. Os utilizadores do centro podem optar pela aplicação da lei portuguesa ou pela aplicação de critérios de equidade na resolução dos litígios submetidos ao centro. Este centro foi desenvolvido pelo Ministério da Justiça em estreita colaboração com o Departamento de Comunicação e Arte da Universidade de Aveiro. O funcionamento do centro de mediação e arbitragem está a ser assegurado pela Faculdade de Direito da Universidade Nova de Lisboa, através de um protocolo celebrado com o Ministério da Justiça (E-Arbitration-T, 2008). Muitas das organizações com presença no SL geralmente só proporcionam interacção directa dos utilizadores com os funcionários desta em horários específicos. Devido a esta limitação, a Universidade de Trás-os-Montes e Alto

90

Capítulo IV: Mundos Virtuais Douro, em parceria com a Portugal Telecom Inovação, desenvolveu um sistema que permite às organizações manter uma constante interacção entre utilizadores no SL, através da simulação da presença de funcionários usando avatares automatizados que comunicam com as pessoas na vida real por meio de mensagens instantâneas e por tecnologias de serviço de mensagens curtas (Valério et al., 2009). No capítulo seguinte encontra-se uma descrição detalhada deste mundo virtual. Na tabela seguinte apresenta-se um resumo com as características dos mundos virtuais sociais estudados.

Objectivo There Aberto

Local Disperso

Plataforma Síncrona Internet

População Multi-utilizador

Programar Sim

Kaneva

Social

Disperso

Síncrona Internet

Multi-utilizador

Sim

Lively

Social

Disperso

Síncrona Internet

Multi-utilizador

Não

The Sims Online Frenzoo

Social Objectivo Social

Disperso

Síncrona Internet

Multi-utilizador

Não

Disperso

Síncrona Internet

Multi-utilizador

Não

IMVU

Social

Disperso

Síncrona Internet

Multi-utilizador

Não

Activeworlds

Educação

Disperso

Síncorna Assíncrona Internet

Multi-utilizador

Sim

Second Life

Aberto

Disperso

Síncorna Assíncrona Internet

Multi-utilizador

Sim

Tabela 4.1: Características dos mundos virtuais sociais.

91

Capítulo IV: Mundos Virtuais

4.3.4 Mundos virtuais de formação
Os mundos virtuais de formação são aqueles cujo objectivo consiste em apoiar as necessidades de formação específicas, tais como na área da saúde, nas empresas e nos militares (de Freitas, 2008). Por exemplo, o America’s Army (Figura 4.18) desenvolvido pelo Moves Institute, é um jogo online multi-utilizador, persistente, cujo objectivo é recrutar soldados para o exército Americano, mas tem vindo a ser utilizado para treinar futuros oficiais na academia militar em West Point (Reuters, 2003). O America’s Army pretende simular o ambiente de guerrilha, de forma a preparar os soldados para estas situações num ambiente seguro.

Figura 4.18: Jogo America’s Army.

4.3.5 Plataformas de desenvolvimento
Dentro desta categoria incluem-se os mundos virtuais considerados como plataformas de desenvolvimento por permitirem criar novos mundos virtuais. Exemplos destas plataformas são o OpenCroquet, que é uma plataforma de código aberto, e o OLIVE (On-Line Interactive Virtual Environment) da Forterra System, que é uma plataforma de desenvolvimento privada, sendo acessível através do pagamento de uma licença de utilização.

92

Capítulo IV: Mundos Virtuais O OLIVE, desenvolvido pelo Fronterra System de Nova Iorque e San Mateo da Califórnia, é um exemplo interessante deste tipo de mundos virtuais, que tem vindo a ser usado principalmente para formação profissional nas áreas da saúde, forças armadas e comunicação social nos Estados Unidos (Forterra Systems, 2004). A MTV Networks usou o OLIVE para criar um mundo online baseado nos seus programas televisivos, por exemplo. Um outro exemplo de utilização do OLIVE é o caso do U.S. National Institute of Health, que criou um mundo para treinar os seus alunos nos casos de ocorrência de desastres. Uma das razões apontadas por David Kushner (2008) para crescimento na utilização dos mundos virtuais na formação profissional é: “...complexe environments are becoming more critical, and the cost of staging real-world simulation training exercises is escalating.” (p38) O principal factor desta plataforma ter vindo a ser utilizada apenas em contextos profissionais deve-se ao elevado custo de licenciamento e ao facto de ser um mundo privado, não estando disponível para o público em geral. Desta forma, este mundos criados no OLIVE proporcionam um mundo mais seguro e controlável para o treino. Ao contrário do OLIVE, o OpenCroquet é uma plataforma de desenvolvimento de open source. Por conseguinte, pode ser utilizada livremente por qualquer utilizador sem custos adicionais, o que permite criar aplicações baseadas em mundos virtuais, online multiutilizador. O OpenCroquet assenta na linguagem de programação orientada a objectos Smalltalk. Este sistema possui uma arquitectura de rede que permite a comunicação, colaboração, partilha de recursos e computação sincronizada entre vários utilizadores (OpenCroquet, 2008). Pode ser utilizado para construir sistemas de visualização de dados, aprendizagem virtual, ambientes partilhados para resolução de problemas, 3D wikis, jogos online, ambientes privados para vários utilizadores, entre outros. Na Figura 4.19 pode-se ver um exemplo de uma aplicação criada para ensinar os conceitos da programação orientada a objectos no OpenCroquet (Carvalho, Cozinheiro, 2007).

93

Capítulo IV: Mundos Virtuais

Figura 4.19: Mundo virtual criado no OpenCroquet para apoio ao ensino da programação orientada a objectos.

Para além destes existem os motores de jogos, também conhecidos como game engines, que permitem desenvolver jogos 3D, mundos virtuais 3D, entre outras aplicações interactivas 3D. Estes motores, tipicamente, contêm um motor gráfico para efectuar o rendering dos objectos 2D ou 3D, um motor físico que permite detectar colisões e simular a gravidade, o suporte a animações, sons, entre outros elementos. Exemplos dentro deste tipo de sistemas são Panda3D (2008), Delta3D (2008), CPAL3D (2002), Unity3D (. 2005). O OpenSimulator (2009) é um servidor de mundos virtuais que pode ser utilizado para criar mundos virtuais 3D semelhantes ao Second Life. Contudo, não foi considerado como alternativa no âmbito desta tese por só apresentar estabilidade tecnológica numa fase posterior ao trabalho de campo realizado. Na Tabela 4.2 apresenta-se um resumo das características destas plataformas de desenvolvimento.

94

Capítulo IV: Mundos Virtuais

Objectivo Olive Aberto plataforma de desenvolvimento OpenCroquet Aberto Plataforma de desenvolvimento Unity3D Plataforma de desenvolvimento

Local Disperso

Plataforma Licença de utilização

População Multi-utilizador

Programar Sim

Disperso

Gratuito

Multi-utilizador

Sim

Disperso

Gratuito

Multi-utilizador

Sim

Tabela 4.2: Características dos mundos virtuais de formação.

4.3.6 Mundos virtuais profissionais
Os mundos virtuais profissionais, também designados de trabalho, são mundos que estão a ser utilizados no contexto empresarial, como plataforma de colaboração e negociação entre trabalhadores. Algumas empresas têm os seus escritórios espalhados pelo mundo, noutras os empregados trabalham fora do escritório de forma independente, pelo que existe a necessidade de permitir que as pessoas colaborem e aprendam em conjunto sem terem a necessidade de se deslocarem. Desta forma, os mundos virtuais estão a ser usados como plataformas de colaboração e aprendizagem formal e informal por várias empresas, como é o caso da IBM. A IBM está a usar o mundo virtual Second Life extensivamente para as suas comunicações de negócios. Contudo, devido à necessidade que os seus empregados têm de comunicar e colaborar num ambiente seguro, a IBM desenvolveu um mundo virtual privado, o IBM Innovate Quick Internal Metaverse Project (IBM, 2007). Um outro exemplo da tendência das grandes corporações empresariais para construírem os seus próprios mundos virtuais é o projecto Wonderland, desenvolvido pela Sun Microsystems, no qual usou a plataforma Project Darkstar (Yankelovich, 2005). Este projecto tem por objectivo a

95

Capítulo IV: Mundos Virtuais utilização de um mundo virtual 3D para que os utilizadores possam comunicar, colaborar, partilhar aplicações e documentos. Segundo de Freitas (2008) a principal diferença entre os mundos sociais e os profissionais é o custo. Nos mundos sociais como o SL, as barreiras para se aceder ao mundo são baixas. Os encargos associados à construção de objectos, edifícios e o custo anual do terreno podem ser convidativos para as empresas se instalarem neste mundo virtual (Freitas, 2008). Por outro lado, nos mundos privados de trabalho torna-se mais difícil o acesso, devido ao elevado custo da licença de utilização, o que pode ser um impedimento para muitos utilizadores. Contudo, os benefícios do custo advêm quando o número de formandos é elevada e o grupo se encontra distribuído pelo globo, pelo que a despesa inicial pode-se justificar comparando com a despesa que envolveria uma formação presencial tradicional.

4.4. Mundo virtual adoptado
A escolha de um mundo virtual a ser adoptado nesta tese não teve em conta apenas a linguagem de programação que o mundo virtual suporta, mas também, o contexto que este permite criar para a aprendizagem da programação. De todos os mundos virtuais analisados, o Second Life parece ser aquele cujas características melhor se adequam aos objectivos desta tese. Conforme foi anteriormente reportado, o SL contém uma ferramenta de modelação 3D fácil de usar, que permite o desenvolvimento de diferentes objectos desde os mais simples aos mais complexos. Permite também a animação visual dos objectos criados dentro do mundo, um pouco como o que acontece no Alice. Este aspecto permite a um aluno criar um objecto, implementar o comportamento que pretende que este simule, executar e observar imediatamente no mundo o resultado do que foi codificado. No entanto, no SL a linguagem de programação utilizada é semelhante à linguagem C a nível da sintaxe, o que facilita a rápida migração dos alunos para outras linguagens de programação, o que não sucede actualmente no Alice como foi referido no capítulo anterior. Outro aspecto importante refere-se ao tipo de suporte pedagógico que o mundo detém principalmente para aprendizagens construtivistas. Neste aspecto o SL tem algumas características interessantes que viabilizam a sua utilização construtivista, nomeadamente

96

Capítulo IV: Mundos Virtuais por permitir a construção colaborativa de objectos, assim como a partilha do código entre os elementos de um grupo. Em resumo, o SL foi o mundo virtual adoptado, no entanto neste estudo poderia também ter sido usado outro tipo de mundo virtual como, por exemplo, o Active World ou There.com, sendo no entanto estes mundos mais limitados no que se refere à construção de objectos e ao tipo de colaboração que estes suportam.

97

5. Second Life

No presente capítulo, apresenta-se o mundo virtual Second Life (SL), adoptado nesta investigação. Faz-se uma descrição geral deste mundo virtual, explanando-se a forma como os utilizadores interagem com o mundo através de avatares, assim como as diferentes formas de comunicação existentes. Apresenta-se também o modo como se constroem objectos 3D no SL, evidenciando-se como se implementam programas neste mundo virtual, de forma a gerar diferentes comportamentos para os objectos criados. Neste sentido, descreve-se a linguagem de programação associada ao SL, expondo-se as suas principais características.

Capítulo V: Second Life

99

Capítulo V: Second Life

5.1. Introdução ao Second Life
O Second Life é um mundo virtual idealizado por Philip Rosedale, tendo inicialmente sido designado de Linden world (Rymaszewski et al., 2007). Em Novembro de 2002, uma versão beta começou a ser testada, abrindo ao público seis meses depois. A 23 de Junho de 2003, o SL entrou oficialmente em funcionamento, como um novo conceito de espaço tridimensional online, partilhado e colaborativo, cujos conteúdos são gerados pelos utilizadores, comummente denominados de residentes. O SL é um sistema computacional cliente /servidor. O servidor, Second Life Grid, está activo 24h por dia, todos os dias da semana, excepto nos momentos em que se encontra em manutenção. O software-cliente, designado viewer, pode ser obtido gratuitamente através do site oficial (www.secondlife.com). Permite aos utilizadores interagir uns com os outros e com o mundo através de avatares (Figura 5.1).
Indicação da região onde se encontra o avatar, pelo nome e respectivas coordenadas Menu superior Indicação da hora local no SL

Menu inferior

Comunicação escrita - Conversas públicas

Comunicação por voz

Figura 5.1: Aspecto geral do viewer do Second Life.

100

Capítulo V: Second Life

Este mundo é composto por várias regiões que estão interligadas, sendo frequentemente designadas de sims, um diminutivo de “simulador”, uma vez que inicialmente um servidor ou simulador suportava uma região (actualmente, um servidor físico pode suportar um número variado de regiões). Cada região tem uma área de 65.536 m2 virtuais, sendo identificada por um nome. Uma posição no mundo virtual SL é dada pelo nome da região e pelas coordenadas x, y, z dentro desta, que indicam a posição este-oeste, norte-sul e altitude, respectivamente. O SL teve durante vários anos duas áreas separadas: uma denominada de Teen Grid que estava reservada a adolescentes com idades compreendidas entre 13 e 17 anos, e outra – a Main Grid – reservada a adultos. Não era permitido que adultos entrassem na área dos adolescentes (excepto professores devidamente verificados pela Linden Lab, e mesmo assim com grandes restrições de movimentação) e vice versa. Em 2010, a Linden Lab fundiu a duas grelhas numa só, com alguma complexidade na gestão da participação de menores de 16 anos, mas permitindo que turmas do 12.º ano do ensino secundário ou do 1.º ano dos cursos superiores pudessem estar juntas, já que estes anos escolares apresentam alguns meses em que agregam alunos de 17 e 18 anos nas mesmas turmas. O SL é um mundo virtual social, que imita o mundo real, não só no aspecto físico, no qual existe a terra com efeito gravítico, a água, o céu e o passar do tempo com a noção de dia e noite (Figura 5.2), mas também no aspecto económico. O SL tem a sua própria moeda – o Linden Dollar (L$), que apesar de não ter valor real directo, pode ser trocado por moedas efectivas, como dólares americanos ou euros. A moeda virtual tem um valor flutuante em função da oferta e da procura diárias. Por exemplo, no momento de escrita desta tese 1 US dólar equivalia a 275 L$.

101

Capítulo V: Second Life

Figura 5.2: Ilha no SL, durante a noite na qual se pode observar um belo céu estrelado.

5.2. Avatares no SL
Neste mundo virtual, os utilizadores são representados por avatares através dos quais podem interagir uns com os outros e com o mundo em tempo real. As possibilidades de interacção que o SL apresenta aos seus utilizadores são inúmeras. Neste mundo, os utilizadores podem explorar, conhecer outros residentes, socializar, participar de actividades individuais ou em grupo, criar e comercializar objectos, tais como roupa, sapatos, mobília para as casas virtuais, entre outros elementos. É possível também alugar espaços virtuais como pequenos terrenos ou ilhas (espaços maiores exclusivos), nos quais o seu dono pode criar e decorar conforme as suas necessidades e gosto (Figura 5.3). Estes espaços podem ser alugados directamente à Linden Lab, empresa gestora do SL, ou a outros residentes o que se tornou numa forma de rendimento para alguns utilizadores. Normalmente, as ilhas são usadas por instituições, como universidades, para criarem a sua representação oficial no mundo virtual.

102

Capítulo V: Second Life

Figura 5.3: Na imagem da esquerda, apresenta o terreno alugado pela autora, para dar início às suas actividades. Na imagem da direita, a ilha da Universidade de Aveiro.

Cada avatar tem um nome que é único no mundo, formado pela conjunção do nome próprio definido pelo utilizador com um dos apelidos que o SL disponibiliza. Por exemplo, o apelido do avatar da autora é Korobase que juntamente com o seu nome de baptismo formam um nome único no SL, Micaela Korobase. Quanto à forma do avatar, os utilizadores podem escolher um entre as várias figuras humanóides que o SL disponibiliza. Contudo, os utilizadores têm ainda a possibilidade de personalizar todos os elementos físicos do seu avatar, através do editor do SL (Figura 5.4). No entanto, a maioria dos utilizadores preferem um avatar com forma humana, mas também é possível ter a forma de um animal ou personagem fictícia como, por exemplo, um urso. Através da utilização de scripts é possível atribuir comportamentos ao avatar como, por exemplo, dançar, acenar com a mão, cruzar os braços.

103

Capítulo V: Second Life

Figura 5.4: O avatar da autora a editar a sua aparência no SL.

Cada avatar tem associado um inventário no qual pode guardar uma panóplia de itens, como objectos, cartões, localização de regiões, programas, entre outros elementos (Figura 5.5). O inventário está organizado por pastas, que o utilizador pode dispor e alterar da forma que desejar. Este inventário persiste enquanto o avatar existir, isto é, sempre que este se conecta ao mundo o seu conteúdo fica disponível.

Figura 5.5: O inventário de um avatar no SL.

104

Capítulo V: Second Life

Os utilizadores também têm a possibilidade de formar um grupo e convidar outros avatares para fazerem parte dele. Desta forma, podem criar uma comunidade e conceder privilégios aos elementos dessa comunidade, tais como só permitirem aos seus elementos aceder a um terreno, manipular objectos ou trocarem mensagens entre si.

5.3. Comunicação
Os avatares podem comunicar uns com os outros através de conversas textuais públicas ou privadas, designadas de mensagens instantâneas (conhecidas por IM de Instant Messaging). As conversas públicas, estabelecidas entre vários avatares, são visíveis por todos os que se encontram dentro de um determinado raio de acção (Figura 5.6).

Figura 5.6: Exemplo de uma conversa pública entre vários avatares.

Por outro lado, as IM são usadas para conversas privadas entre dois avatares ou entre os membros de um grupo. Ao contrário das conversas públicas estas não têm uma distância limite. Assim, pode-se estabelecer uma conversa privada entre dois avatares independentemente da distância a que estes se encontram. Uma outra particularidade

105

Capítulo V: Second Life das conversas privadas, bastante útil quando se está a trabalhar com um grupo de alunos, resulta do facto de estas emitirem um sinal sonoro e visual ao avatar receptor da mensagem. Sempre que a janela das IM esteja aberta, o separador com o nome do avatar emissor das mensagens começa a piscar e ouve-se um sinal sonoro (Figura 5.7). As IM podem também ser enviadas para o email do avatar receptor, se este não estiver conectado ao mundo quando a mensagem é enviada. Contudo, estas mensagens são também guardadas e mostradas ao avatar receptor quando este novamente se conectar ao mundo. Janela das IM em que cada separador corresponde a uma conversa privada

Figura 5.7: Exemplo de uma conversa privada entre dois avatares.

Outra forma de comunicação existente no SL é através do uso de cartões digitais (notecards). Nestes cartões é possível escrever mensagens directamente e fazer ligações para outras regiões do SL. Os residentes do SL usam frequentemente estes cartões para transmitirem informações sobre o seu espaço. Normalmente, são distribuídos automaticamente por um objecto quando se toca nele ou oferecidos directamente de um avatar para outro, bastando arrastar o cartão com o rato para cima do avatar a quem se pretende oferecê-lo. Contudo, como estes cartões são atribuídos individualmente a cada avatar, não é possível ter o seu conteúdo visível a todos como se tratasse de uma tela.

106

Capítulo V: Second Life

Figura 5.8: Exemplo de um cartão do SL.

Uma das restrições do SL, em relação à comunicação escrita, refere-se ao facto de este não permitir que se escreva directamente num quadro ou numa tela. Assim, sempre que se pretende expor informação a um nível mais abrangente, por exemplo através de uma tela, torna-se necessário criar, fora do SL, imagens com a informação textual ou visual pretendida e importar para dentro do mundo como se tratasse de uma textura (Figura 5.9), textura esta que se pode ser aplicada num placar construído para esse fim. No entanto, alguns utilizadores, na tentativa de colmatar esta limitação, desenvolveram XYText e quadros com grandes limitações ao nível de detalhe que é possível apresentar. Contudo, na mais recente versão do SL, lançada em 2010 é possível utilizar como textura uma página Web com applets e Flash, o que veio alterar significativamente esta limitação.

107

Capítulo V: Second Life

Figura 5.9:Exemplos de telas de informação no SL.

Outra forma de transmitir pequenas mensagens, muito utilizada também, é através da elaboração de um pequeno programa no qual se escreve a mensagem na cor pretendida e se insere num objecto qualquer (Figura 5.10).

Figura 5.10: Objectos usados para transmitir pequenas mensagens no SL.

108

Capítulo V: Second Life A partir de versão 1.18.1.2 em Agosto de 2007 deu-se início à comunicação por voz, tanto pública como privada.

5.4. Construção de objectos 3D
Ao contrário dos outros mundos virtuais, quase tudo o que se encontra dentro do SL é construído pelos seus utilizadores. Esta é uma das características bastante populares do SL, pelo facto de este permitir aos seus utilizadores a criação, edição e destruição de objectos 3D dentro do mundo. Contudo, não é possível construir objectos em quaisquer terrenos do SL, uma vez que são propriedades privadas, estando a construção limitada aos seus donos. Mas existem diversos espaços designados Sandboxes, nos quais qualquer avatar que a eles tenha acesso (geralmente, o acesso é totalmente aberto) pode construir os objectos que desejar. No SL é possível construir objectos com comportamentos próprios, como pregões que se movem ao sabor do vento ou aquários transparentes nos quais se observam diferentes tipos de peixes a nadar. Para se conseguir garantir os direitos de autor de cada objecto construído estes estão identificados por um Universally Unique Identifier (UUI), uma string de 16 bytes que os identifica de modo único em todo o SL. Para se saber quem foi o autor que criou um objecto basta editar esse mesmo objecto aparecendo na janela do editor o nome do seu criador. Assim, pode-se entrar em contacto com autor do referido objecto e pedir informações. O SL faz a distinção entre quem criou o objecto e quem é o seu actual dono, uma vez que este pode já ter sido transmitido a outra pessoa.

109

Capítulo V: Second Life

Figura 5.11: Editor de objectos no SL, no qual se observa o nome do dono e do criador da cúpula azul.

A aplicação cliente possui um editor que permite, de um modo acessível, a construção de objectos tridimensionais (Figura 5.12). Todos os objectos no SL são construídos a partir de um objecto 3D designado de prim, diminutivo de primitive, ou seja, um objectobase. Uma prim é um dos seguintes objectos geométricos 3D: um cilindro, um prisma (quadrangular e triangular), uma esfera, um cone, um tubo ou um anel. A partir destas prim pode-se construir qualquer objecto 3D mais complexo. Um objecto pode conter entre 1 a 255 prims ligadas entre si. Actualmente está disponível em versão Beta a possibilidade de produzir externamente volumetrias com meshes de triângulos, aspecto não disponível aquando da realização do trabalho de campo de suporte a esta tese.

110

Capítulo V: Second Life

Figura 5.12: A janela do editor que permite construir e alterar as propriedades dos objectos.

Para se dar início à construção de um objecto começa-se por pressionar o botão direito do rato no chão do SL. Esta acção faz surgir o menu redondo, designado de pie menu, no qual se deve seleccionar a opção Criar (na versão 2.0 do software-cliente, o menu deixou de ser redondo e passou a ser uma lista tradicional, mas os demais aspectos referidos mantêm-se; optou-se por efectuar a descrição com base no software-cliente disponível aquando da realização do trabalho de campo). Esta opção “Criar”, por sua vez, abre o editor que permite criar ou editar objectos. A seguir escolhe-se a prim que se pretende usar para construir o objecto desejado (Figura 5.13). Esta prim é colocada no chão do SL e a partir daqui pode-se usar o editor para moldar o seu formato.

111

Capítulo V: Second Life

Figura 5.13 : O menu redondo, designado de pie menu, na imagem da direita; na imagem da esquerda, a janela inicial do editor de construção, com as várias prims que se podem seleccionar.

O modo mais básico e flexível para moldar e manipular objectos/prims é através do uso dos seus objectos auxiliares. Estes objectos auxiliares encontram-se associados a cada objecto quando são editados sob a forma de pequenos triângulos ou cones azuis, verdes e vermelhos que representam os eixos direccionais: X: eixo Este/Oeste representado pela cor vermelha; Y: eixo Norte/Sul, representado pela cor verde; Z: Cima/Baixo, representado pela cor azul.

112

Capítulo V: Second Life

Figura 5.14: A edição de uma prim no qual se pode observar os eixos direccionais a vermelho, verde e azul.

No caso de se pretender rodar um objecto ou alterar o seu tamanho, estes objectos auxiliares mantêm as mesmas cores que representam os eixos sobre os quais essas alterações são efectuadas, sendo apresentados sobre a forma de círculos ou pequenos cubos à volta do objecto (Figura 5.15).

Figura 5.15: Objectos que auxiliam na rotação, na imagem da esquerda, e no aumento do objecto, na imagem da direita.

113

Capítulo V: Second Life A construção de objectos mais complexos é feita através da ligação de vários objectos entre si. Esta ligação tem por objectivo formar um objecto único, que permite ao utilizador mover e manipular a combinação de objectos como se tratasse de um só. Para ligar várias prims é necessário seleccionar, individualmente, todas as prims que se pretende conectar enquanto se mantém o botão Shift do teclado premido. Por fim, prime-se em simultâneo o botão Ctrl e a tecla L ou através do menu superior do SL selecciona-se no item ferramentas (tools) a opção ligar prims. Outra funcionalidade muito apreciada pelos construtores no SL é o facto de este permitir a duplicação de objectos de uma forma rápida. Deste modo, facilita a construção de objectos complexos, para tal basta seleccionar o objecto que se pretende duplicar, em seguida premir em simultâneo a tecla Shift e deslocar uma das setas dos eixos direccionais do objecto em causa. Na construção de objectos mais elaborados convém saber manipular a câmara, de forma a focalizar determinados aspectos do objecto (Figura 5.16). Para um principiante, o controlo da câmara pode-se tornar difícil pois é necessário premir em simultâneo a tecla Alt do teclado, o botão esquerdo do rato e deslocar este para a frente e para trás conforme se pretenda aumentar ou diminuir o zoom. Uma outra forma de aceder ao controlo da câmara é através da sua janela de controlo, que se encontra no menu superior item View/camera control. Contudo, esta opção precisa de alguma prática, principalmente quando se pretende visualizar um objecto em pormenor. O editor de objectos disponibiliza ainda uma grelha, tornando-se visível quando se selecciona a opção Use Grid, permitindo o alinhamento de objectos de uma forma mais precisa.

Figura 5.16: Manipulação do zoom no SL. Na imagem da esquerda, a visualização do objecto sem o zoom activo. Na imagem da direita, zoom in, no qual se observa em pormenor o olho da boneca.

114

Capítulo V: Second Life

Para se criar objectos com uma aparência mais realista, o SL permite decorá-los com cores ou texturas. Estes elementos de decoração podem ser adicionados ao objecto na sua totalidade ou colocados faseadamente em cada um dos lados do objecto, bastando seleccionar no editor a opção Select Texture, seguidamente ir ao objecto, com o rato escolher a face que se pretende colorir e indicar a cor respectiva no editor. O SL disponibiliza também um conjunto de texturas que podem ser utilizadas, mas se o utilizador preferir pode importar para dentro do SL as suas texturas preferidas, num dos seguintes formatos: Targa (.TAG), Windows Bitmap (.BMP) e JPEG. Contudo, é necessário pagar 10 L$ por cada textura que se pretenda importar; esta limitação tem por objectivo, segundo Rymaszewski (2007), evitar “encher” os servidores do SL. Uma das características únicas do SL é o facto de este permitir a construção colaborativa de objectos. Vários utilizadores podem trabalhar em equipa na construção de objectos, assim como podem observar em tempo real a sua construção (Figura 5.18). O SL contém um sistema de permissões que possibilita a um utilizador conceder a outros o direito de editarem os seus objectos (Figura 5.17). Este sistema de permissões permite: a partilha do objecto com um grupo, previamente definido; que qualquer pessoa o possa mover; que qualquer pessoa o possa copiar; colocar o objecto visível quando se faz uma pesquisa; colocar o objecto à venda, no qual é possível definir o seu preço, bem como o que o próximo dono pode fazer com este, isto é, modificar, copiar ou dar a outro.

115

Capítulo V: Second Life

Figura 5.17: Editor de objectos, no qual se pode observar as permissões que se podem atribuir ao objecto criado.

A característica mais apreciada é a partilha com os elementos de um grupo, tornando possível a construção compartilhada e simultânea de objectos, evitando também que outros utilizadores danifiquem os objectos que não são seus.

Figura 5.18: A construção colaborativa de um piano no Second Life.

116

Capítulo V: Second Life Os objectos criados no SL podem ser, de algumas formas, semelhantes aos objectos existentes na vida real, isto é, podem ser objectos físicos que sofrem o efeito da gravidade, ou tenham outros comportamentos dinâmicos. Por exemplo, para se entrar dentro de um museu ou de uma casa tem de ser feito pela porta, não sendo normalmente possível atravessar paredes – embora o construtor da parede possa cancelar esta limitação, pois as características físicas são meras opções de cada objecto.

5.5. Programar no Second Life
O SL tem uma linguagem de scripting associada, que permite definir comportamentos para os objectos criados dentro deste mundo virtual, tais como conduzir veículos motorizados ou ter animais de estimação que seguem o seu dono. Esta linguagem chama-se Linden Scripting Language (LSL) e é baseada em resposta a eventos, tendo uma sintaxe semelhante às das linguagens C e Java. Como aspecto particular, é baseada no conceito de máquina de estados: cada script possui associada a si uma máquina de estados. Um objecto pode ter vários scripts associados, em que cada um deles tem a sua zona de memória, isto é, não existe partilha do mesmo espaço.

5.5.1 Como se desenvolve um programa no SL
Após a construção de um objecto, na janela do editor selecciona-se o separador content e prime-se o botão New Script (Figura 5.19). Desta forma, abre-se a janela do editor de programas, o qual já contém o programa “Hello Avatar” por defeito (Figura 5.20). Este editor está dividido em quatro partes. Na parte superior apresenta um menu com três itens (File, Edit, Help), a seguir a área de edição na qual é possível escrever um programa em LSL, a área de mensagens onde surgem especificados os erros de compilação existentes no programa, caso estes existam, ou a informação de que o programa não contém erros e que está a ser guardado. Por último, o menu inferior, no qual se insere o botão Save que permite guardar as alterações efectuadas e em simultâneo compilar o programa. O popup menu insert permite inserir no código do programa funções da LSL.

117

Capítulo V: Second Life

Figura 5.19: Desenvolvimento de programas no SL.

Área de edição do programa

Área de mensagens

Figura 5.20: Editor de programas no SL.

Após se ter compilado o programa e verificado que este não contém erros, fecha-se a janela do editor e o programa começa a ser executado. Por exemplo, no programa

118

Capítulo V: Second Life “Hello Avatar” este ao ser executado envia a mensagem “Hello, avatar!” para o canal público. A linguagem LSL é executada no servidor num software denominado de simulador, que simula o mundo virtual SL. No entanto, o compilador de LSL encontra-se no viewer do SL, onde todos os programas são compilados e posteriormente enviados ao servidor onde são executados (Rymaszewski et al., 2007). O compilador do LSL emite mensagens de erros sempre que detecta que o programa não respeita as regras de sintaxe da linguagem. Estas mensagens indicam a linha e a coluna na qual ou perto da qual o erro de sintaxe ocorreu. Por exemplo, a mensagem:
“(7, 19): ERROR: Syntax error”

indica que existe um erro de sintaxe na linha 7 coluna 19 ou perto desta localização. Após a correcção do erro, o programa tem de ser compilado novamente para poder ser executado, como acontece nas outras linguagens de programação. As mensagens de erro emitidas pelo compilador, por seu turno, nem sempre são muito claras, o que dificulta a sua correção principalmente a um aprendiz.

5.5.2 A linguagem de programação LSL
A linguagem LSL, enquanto linguagem de scripting, tem uma máquina de estados implícita, com um ou mais estados, e é orientada a eventos, como já referido previamente. Um programa escrito em LSL tem de ter pelo menos o estado default, sem o qual o programa não existe. Dentro deste estado, delimitado pelas chavetas chavetas, escreve-se o código que se pretende executar. Por defeito, ao iniciar um programa o estado default contém os event handlers state_entry e touch_start.

default { state_entry() { llSay( 0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay( 0, "Touched."); } }

119

Capítulo V: Second Life O código que se encontra no evento state_entry é executado quando se prime no botão Save do editor. Deste modo, o programa começa a ser executado ao entrar no estado default. O segundo event handler touch_start, por seu lado, é desencadeado sempre que o utilizador toca no objecto. No programa “Hello Avatar” inicial, ambos os events handlers state_entry e touch_start contêm a função llSay. llSay é uma função pré-definida da linguagem LSL, que permite a escrita de mensagens de texto num determinado canal de comunicação, semelhante à função printf da linguagem C. O canal zero é o canal público, sendo o seu texto visível por todos os avatares que se encontram dentro de um determinado raio de acção. Assim, por exemplo, llSay (0, “Hello, Avatar!”); escreve a mensagem “Hello, Avatar!” no canal público. O LSL contém uma biblioteca de funções pré-definidas que executam funcionalidades comuns ou fornecem funcionalidades extras que seriam difíceis de escrever directamente na linguagem (Figura 5.21). Actualmente existem mais de 300 funções na biblioteca do LSL (Rymaszewski, 2007). Curiosamente todas as funções pré-definidas da linguagem começam por dois ll, tornando-se assim mais fácil reconhecer as funções da linguagem no código. Um aspecto importante refere-se ao facto de algumas destas funções terem associado um valor de atraso, o que implica que demorem algum tempo a serem executadas. Segundo Rymaszewski (2007), este valor existe para proteger o SL contra certos tipos de abusos (tentativas de sobrecarregar os servidores com código cíclico).

120

Capítulo V: Second Life

Figura 5.21: Lista de funções pré-definidas do LSL.

O utilizador também pode criar as suas funções, possuindo estas a mesma sintaxe das funções na linguagem C. Contudo, estas são definidas antes do estado default, como por exemplo, a função que calcula o factorial de um número:

integer factorial (integer num){ if(num<3) return num; else { llSay(0,"novo calculo"); return num*factorial (num -1); } } default { state_entry() { integer n=7; llSay(0, "Calculo do factorial de "+ (string)n); llSay(0, (string) factorial(n)); } }

121

Capítulo V: Second Life Os tipos de dados básicos que o LSL suporta são semelhantes aos existentes na linguagem C. No entanto, na linguagem LSL, o tipo de dados int é denominado de integer como se pode observar na Tabela 5.1:

Tipos de Dados integer

Descrição Valores numéricos positivos e negativos; semelhantes ao int da linguagem C.

float key vector list

Valores reais. Identificador unívoco que é usado para objectos e avatares. 3 valores reais usados em conjunto como um único item. Permite arquivar valores de diferentes tipos de dados; semelhante às listas na linguagem Java.

string rotation

Conjunto de caracteres; semelhante às strings na linguagem Java. Permite representar a orientação de um objecto 3D.

Tabela 5.1: Tabela com os tipos de dados existentes na linguagem de programação LSL.

As variáveis dos diferentes tipos de dados podem ser declaradas locais ou globais sendo estas últimas visíveis em todo o programa. A declaração das variáveis é muito semelhante à forma usada nas linguagens C e Java, embora apenas permita que se declare uma variável por linha. Por exemplo, no seguinte código definiu-se várias variáveis locais e globais. Neste código, várias funções pré-definidas da linguagem foram utilizadas. O seu objectivo é colocar o objecto que contenha este programa em diferentes posições e simultaneamente emitir bolas vermelhas para o ar. Após um período de 19 segundos de deslocações arbitrárias, o objecto regressa à sua posição inicial (Figura 5.22).

122

Capítulo V: Second Life
integer counter; integer second; vector startPosition; default{ state_entry() { llSay(0,"Toca-me, para eu me deslocar"); counter=0; startPosition=llGetPos();//obtém as coordenadas da posição inicial //do objecto } touch_start(integer num) { counter++; llSetTimerEvent(1);//acciona o evento timer de 1 em 1 segundo } timer() { second++; float x_d = llFrand (10.0); float y_d = llFrand (10.0); float z_d = llFrand (10.0); vector increment = <x_d,y_d,z_d>; vector newP = startPosition + increment; llSetPos(newP); //coloca o objecto numa nova posição llParticleSystem( [ PSYS_PART_FLAGS, PSYS_PART_WIND_MASK | PSYS_PART_EMISSIVE_MASK, PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_EXPLODE, PSYS_PART_START_COLOR, <1,0,0> ] ); //cria bolas vermelhas if(second>19) //ao fim de 19 segundos coloca o objecto na posição { // inicial while(llVecDist(llGetPos(),startPosition)>0.001) llSetPos(startPosition); llParticleSystem([]); llResetScript(); } } }

123

Capítulo V: Second Life

Figura 5.22: A execução do código anterior no SL.

Relativamente às estruturas de controlo, estas são idênticas às da linguagem C, quer em termos das estruturas de decisão (if, switch), quer das de repetição (for, while, do...while). No SL, a colaboração entre os avatares não se limita à construção de objectos, como já foi mencionado, mas inclui também a cooperação no desenvolvimento de programas. Assim, é possível partilhar um script que se encontra dentro de um objecto com os amigos. Deste modo, é necessário partilhar o objecto primeiro e a seguir, com a janela do editor do programa fechada, colocar o cursor do rato em cima do script, premir o seu botão direito e seleccionar a opção Proprerties e nesta activar a opção Share with group. Com esta linguagem é possível criar programas simples, como o programa “Hello Avatar”, mas também programas bastante complexos que englobam vários estados, sensores que possibilitam detectar vários objectos, entre outros. Contudo, é uma linguagem simples com muitas funções pré-definidas que permite criar uma panóplia de animações. Esta característica da linguagem LSL foi um dos factores tidos em consideração quando se ponderou a utilização do SL para o ensino e aprendizagem da programação, uma vez que vem ao encontro do que Jenkins (2002) argumenta que uma linguagem de introdução à programação deve ser, como foi referido no capítulo III.

124

6. Metodologia de investigação
Para abordar o problema proposto de uma forma sistemática, começa-se por expor e justificar o método científico adoptado no desenvolvimento desta investigação – a investigação-acção – e prossegue-se com a explanação da estrutura desse método.

Capítulo VI: Metodologia de Investigação

125

Capítulo VI: Metodologia de Investigação

6.1. Opções metodológicas
A procura de soluções para um problema de investigação deve envolver o emprego de metodologias que, a partir de elementos teóricos e problemas de investigação, permitam estabelecer directrizes e formular procedimentos para a determinação de soluções optimizadas (Ackoff, 1998). Na selecção do método de investigação a seguir deve-se ter em conta que na procura de soluções inovadoras para os problemas educativos em geral, e em particular, no que se refere ao uso de tecnologias de informação, é essencial a intervenção de profissionais no terreno (Coutinho e Chaves, 2002). Este procedimento permite clarificar o problema na sua fase inicial e possibilita a avaliação e teste de soluções in loco. Toda a investigação está ligada à acção e dela depende em última análise, ninguém poderá investigar um objecto sem agir ou interagir com ele, ou seja, o investigador tem de se envolver na situação que tem para investigar. No entanto, isto não implica que o investigador não faça uma interpretação objectiva daquilo que observa para dar aos factos a sua interpretação pessoal. Assim, a investigação para ser autêntica tem de produzir conhecimentos, conceitos novos, novas atitudes (Santos e Travassos, 2009). Para o conseguir, o investigador terá de sujeitar-se às exigências do método científico, conforme entendido pela comunidade científica. Os investigadores que investigam novos domínios são muitas vezes confrontados com o desafio de reconhecer e descrever estes fenómenos (Rijo, 2008). Poder-se-ia ter optado por partir de um conjunto inicial de proposições com as quais se procuraria corroborar e aprofundar os elementos a analisar, menosprezando outros. No entanto, seria necessário existir um modelo ou teoria para estabelecer estas hipóteses iniciais (Figueiredo, 2003). Com base nas características da realidade que se pretendia conhecer, adoptou-se como método científico a investigação-acção (IA). A opção por esta metodologia baseou-se em dois aspectos fundamentais: O primeiro aspecto relaciona-se com facto de ser um trabalho exploratório numa área onde existe pouca investigação (o ensino da programação de computadores em mundos virtuais). No decorrer do trabalho, o investigador pode ser simultaneamente o actor investigante e objecto de investigação. 126

Capítulo VI: Metodologia de Investigação Num estudo exploratório, a metodologia investigação-acção, devido às suas características, propicia um melhor método de investigação do que as restantes alternativas (Dick, 2000; Farquhar, 2000; Santos e Travassos, 2009).O segundo aspecto a considerar consistiu no grau de flexibilidade permitido pela investigação-acção, quando envolve tecnologias de informação relacionadas com problemas sobre os quais pouco se sabe (Neville, 1992; Bawden e Zuber- Skerritt, 2000), o que implica ir para o terreno observar, alterar e reflectir, possibilitando uma melhoria de métodos e processos em estudo. A IA é um método de investigação que visa dar, ao mesmo tempo, contributos práticos e científicos. Este método insere-se nos métodos qualitativos que são usados mais frequentemente nas ciências sociais e humanas para o estudo de fenómenos de grande complexidade, que num grande número de casos não podem ser estudados por métodos quantitativos. Actualmente, estes métodos estão a ser utilizados em Engenharia Informática e isto deve-se ao facto de as aplicações informáticas terem hoje de ser desenvolvidas tendo em consideração factores sociais e humanos (Figueiredo, 2003; Santos e Travassos, 2009). Existem grandes vantagens na utilização desta metodologia de investigação, segundo Almeida (2001): “Ela implica o abandono do praticismo não reflexivo, favorece, quer a colaboração interprofissional, quer a prática pluridisciplinar — quando não interdisciplinar ou mesmo transdisciplinar —, e promove, inegavelmente, a melhoria das intervenções em que é utilizada.”. Uma convicção fundamental deste método consiste em concluir que os processos complexos podem ser melhor estudados introduzindo mudanças nesses processos e, então, observar os efeitos produzidos por essas mudanças. (Baskerville, 1999; Schein, 2006). A IA é um método essencialmente prático e aplicado, regendo-se pela necessidade de resolver problemas reais, que pode ser utilizado por qualquer profissional. Contudo, como o foco desta tese se centra no ensino da programação, passa-se a relatar apenas as características da investigação-acção em educação. Neste método não se distingue o momento da produção de conhecimento (que é levado a cabo pelo investigador) do da aplicação desse conhecimento pelo professor (que normalmente é também o investigador). Estes dois momentos estão interligados 127

Capítulo VI: Metodologia de Investigação na investigação-acção. Assim, porque inclui nela os próprios sujeitos dessa transformação, é provavelmente a investigação mais operante em matéria de alterações profundas e duradouras de atitude. Essas transformações nascem de dentro, são vividas, sentidas pelos próprios investigadores-actores. É a interconexão entre teoria e reflexão do professor na acção que permite originar sólidas mudanças nas práticas (Avison et al., 1999). Este processo de investigação na aula tem um alto poder de incisão na prática e nas mudanças, levando o professor a apropriar-se do currículo, tornando-se mais evidente a disfuncionalidade dos processos que tudo previam de antemão (ibid.). Neste estudo são valorizadas as situações pedagógicas concretas, na medida em que a professora participante vai adequando as suas práticas de acordo com o desempenho dos seus alunos, reflectindo passo a passo sobre os aspectos positivos e negativos das suas tomadas de decisão que, inevitavelmente, acompanham o processo de ensino e aprendizagem. Nesta linha de acção, assumiu-se o papel de professora- investigadora, no sentido de a investigadora analisar reflexivamente como os processos de ensino e aprendizagem decorrem no mundo virtual, qual a sua complexidade e como professora aplicar nas aulas o resultado dessa investigação reflectida.

6.2. O que é a investigação-acção?
A investigação-acção, como método de investigação, estabeleceu-se essencialmente no âmbito das ciências sociais e médicas. Atribui-se a Kurt Lewin (1946) o trabalho pioneiro de investigação-acção que lhe deu corpo no âmbito da psicologia e na linha de uma certa preocupação com os problemas sociais da sociedade americana. Segundo este autor, a investigação-acção baseia-se numa “acção de nível realista sempre seguida por uma reflexão autocrítica objectiva e uma avaliação de resultados”, não se pode ter “acção sem investigação nem investigação sem acção”. Nesta linha de orientação, convém referir o que se entende por (Dick, 2000): Acção - o sentido de alterar, mudar uma situação; Investigação - a obtenção de conhecimentos sobre um determinado problema ou comunidade.

128

Capítulo VI: Metodologia de Investigação Na investigação-acção, o professor trata de resolver os problemas que a prática apresenta (complexidade, incerteza...), seleccionando actividades, procurando comprovar os seus efeitos e depois alternando-as para corrigir as imperfeições descobertas. Permite “transformar a realidade e produzir os conhecimentos que dizem respeito às transformações realizadas” (Hugon e Seibel, 1988). O processo da investigação-acção alterna ciclicamente entre a acção e a reflexão crítica que, de um modo contínuo, apura os seus métodos na recolha de informação e na interpretação que se vai desenvolvendo à luz da compreensão da situação em causa. É, portanto, um processo iterável que converge progressivamente para uma melhor compreensão do problema e do que acontece.

6.2.1 Estrutura metodológica da investigação-acção
Na literatura encontra-se referência a várias propostas de organização estrutural de investigação-acção. Nesta secção procede-se apenas à explanação da estrutura metodológica seguida no decurso desta investigação. Diversos autores definem o processo investigação-acção como um ciclo (ou espiral) implícito ou explícito (Dick, 2000; Zuber-Skerritt, 2000; Cairncross e McEwan 2009). Estes ciclos não significam a existência de repetição, mas sim de desenvolvimento, no sentido em que os ciclos que se seguem são enriquecidos pelos precedentes. Segundo Zubert-Skerritt (2000), um ciclo compreende quatro grandes fases: 1 - Planeamento estratégico; 2 - Acção, isto é implementação do plano; 3 - Observação; 4 - Reflexão crítica e autocrítica sobre os resultados dos pontos anteriores e tomadas de decisões para o ciclo seguinte da investigação-acção. De acordo com Lessard-Hébert e Goyette (1990), na fase inicial, a definição do problema pode englobar uma operação de pré-intervenção que compreende uma pré-observação, a escolha do problema, a planificação do projecto e a delineação de um calendário de operações. A fase seguinte inclui a operação de intervenção no terreno, o ensaiar do projecto, a observação e registo. Por último, a reflexão que 129

Capítulo VI: Metodologia de Investigação engloba as operações de avaliação, que abrangem a avaliação dos resultados da intervenção, a apresentação desses resultados, as limitações do projecto, as conclusões e as hipóteses que potenciem novas actuações. Quando a reflexão mostra que o problema está resolvido ou se atingiu um nível de conhecimento significativo sobre o problema, o projecto está concluído e o relatório final é preparado (Passfield, 2000; Cairncross e McEwan 2009), ou seja, é um processo cíclico (Figura 6.1) que continua até que o problema inicial esteja satisfatoriamente resolvido e o processo de investigação-acção seja dado por terminado (Carson et al., 2001). A reflexão pode ser feita em simultâneo com a acção ou posteriormente. Quando o investigador descreve a sua acção e todas as descrições são fruto de uma reflexão que é feita em simultâneo com a acção ou a partir de uma retrospectiva da mesma, designa-se por reflexão-na-acção. Segundo Schön (Schön seg. Smith, 2001), a simultaneidade da reflexão com a acção é um conhecimento tácito que está na acção do investigador. Quando alguém reflecte-na-acção converte-se num investigador no seu contexto prático, não está a depender de uma teoria estabelecida, mas sim está a construir a sua, pois não separa o pensamento da acção, experimenta, dando ao pensamento o valor de um tipo de acção que se constrói na sua própria pesquisa. A reflexão-na-acção é, no fundo, um processo por meio do qual se aplicam os dados conhecidos para resolver um problema; o que implica, pois, experimentar com a situação.

130

Capítulo VI: Metodologia de Investigação

Definição do problema

Planeamento

Planeamento

Reflexão Acção Observação

Reflexão Acção Observação

Figura 6.1: Metodologia de investigação-acção. Adaptado de Edwards e Bruce (2000); Zuber-Skerritt (2000).

A retrospectiva feita pelo investigador que descreve as suas acções depois da sua realização, reconstruindo mentalmente a acção ou através de filmes, para tentar analisá-la com mais pormenor, tentando descobrir aspectos que lhe irão permitir melhorá-la, chama-se de reflexão-sobre-acção. Alguns autores não distinguem grandes diferenças entre esta e a anterior (Alarcão, 1991). “Exercemos naturalmente este tipo de reflexão quando a acção assume uma forma inesperada ou quando, por qualquer motivo, a percepcionamos a uma luz diferente da habitual, tal como acontece quando, ao passarmos por aquela rua onde todos os dias passamos, reparamos um dia numa janela bonita que nunca tinha atraído a nossa atenção.” (Alarcão, 1991, p.9) No decorrer desta investigação aplicaram-se estes dois tipos de reflexões, na medida em que ao introduzir-se novas alterações visualizou-se e reflectiu-se em simultâneo a ocorrência, ou não, de melhorias. Assim como, posteriormente, ao relembrar o sucedido para descrever as observações feitas, se reflectiu sobre a acção efectuada, de modo a obter-se progressivamente um conhecimento aprofundado da exequibilidade deste meio de ensino. 131

Capítulo VI: Metodologia de Investigação Durante as várias fases do processo de IA, as diferentes etapas devem ser constantemente monitorizadas por uma variedade de mecanismos, devendo-se ser rigoroso e sistemático nessa recolha (Dick, 2000; Cairncross e McEwan, 2009). Daí ser necessário o uso de técnicas, tais como: elaboração de um diário com os relatórios das impressões subjectivas, descrições dos encontros mantidos e das ilações aprendidas; realização de gravações áudio, vídeo ou fotografias dos encontros; recolha de documentos relativos a uma determinada situação; elaboração de inquéritos sob a forma de entrevistas ou questionários. (Lessard-Hébert e Goyette, 1990; Cairncross e McEwan, 2009).

Em suma, sendo a preocupação primordial da investigadora compreender como o mundo virtual SL pode ser utilizado como plataforma para o ensino e aprendizagem inicial da programação a alunos do ensino superior, optou pela metodologia IA. Esta escolha deveu-se principalmente ao facto de a IA permitir ao investigador ir para o terreno observar, reflectir e alterar, possibilitando uma melhoria de métodos e processos em estudo.

132

Capítulo VI: Metodologia de Investigação

133

7. Aplicação do método de investigação
No presente capítulo descreve-se a praxis educativa realizada, regida pela metodologia IA, para obter respostas ao problema proposto. Começa-se por expor a recolha e análise de dados efectuada e termina-se com os resultados obtidos.

Capítulo VII: Aplicação do Método de Investigação

135

Capítulo VII: Aplicação do Método de Investigação

7.1. Sumário
O propósito de compreender os processos de ensino e aprendizagem da programação de computadores utilizando o mundo virtual Second Life determinou a opção de conduzir uma investigação qualitativa. Neste sentido, efectuaram-se quatro ciclos da metodologia IA (Figura 7.1), que decorreram desde Março de 2007 até Julho de 2008, tendo abrangido o 2.º semestre do ano lectivo 2006/2007 e o 1.º e 2.º semestres do ano lectivo 2007/2008. Começou-se por efectuar um estudo exploratório no qual se procurou indagar e compreender como o SL poderia ser usado como plataforma para o ensino e aprendizagem da programação. A condição exploratória deste estudo tinha como intenção encontrar linhas de orientação para a planificação do primeiro ciclo. Tratouse, assim, de um processo que permitiu à investigadora inteirar-se do problema. A actividade preliminar decorreu ao longo do segundo semestre do ano lectivo 2006/2007, o primeiro e segundo ciclos de IA durante o primeiro semestre de 2007/2008 e o terceiro e quarto ciclos no segundo semestre do mesmo ano lectivo. A Figura 7.2 apresenta um diagrama de todo o processo de investigação.

136

Capítulo VII: Aplicação do Método de Investigação

Definição do problema

Planeamento

Planeamento

Reflexão Acção Observação

Reflexão Acção Observação

1.º ciclo

2.º ciclo

Planeamento

Planeamento

Reflexão Acção Observação

Reflexão Acção Observação

3.º ciclo

4.º ciclo

Figura 7.1: Esquema da metodologia investigação-acção efectuada neste estudo.

137

Capítulo VII: Aplicação do Método de Investigação

2006/2007 Março Julho Outubro

2007/2008 5 Novembro 19 Novembro Janeiro

2007/2008 Março Junho

Actividade Preliminar

Reflexão/Plano 1.º Ciclo Reflexão/Plano

2.º Ciclo Reflexão/Plano 3.º Ciclo 4.º Ciclo

Figura 7.2: Diagrama temporal desta investigação

Procurou-se que este estudo decorresse num contexto real das aulas de programação de computadores a alunos de informática do ensino superior, nas quais a investigadora fosse também a professora. Assim, durante este estudo substituiu-se a linguagem de programação e o ambiente de desenvolvimento tradicionalmente utilizados pelo mundo virtual SL, sendo usada a linguagem interna de scripting do SL, o Linden Scripting Language (LSL). As aulas decorreram online, tendo sido usada duas vertentes: uma síncrona, durante as aulas, onde todos os participantes estavam simultaneamente online integrados numa aprendizagem colaborativa, e outra assíncrona, sempre que os alunos desenvolviam as suas actividades fora do período das aulas.

7.2. Participantes
Neste estudo participaram, voluntariamente, alunos da Licenciatura em Informática da Universidade de Trás-os-Montes e Alto Douro (UTAD) e do curso técnico póssecundário (CET) da Escola Superior de Tecnologia e Gestão (ESTG) do Instituto Politécnico de Leiria. A Tabela 7.1 expõe o número de alunos que participaram em cada um dos ciclos de IA. Estes alunos tomaram parte neste processo de investigação, enquanto desenvolviam um trabalho alternativo nas seguintes disciplinas: Laboratório de informática I (Lab. I), do primeiro ano curricular da UTAD; Laboratório de Informática II (Lab. II) e III (Lab. III) do segundo ano curricular da UTAD; e Projecto I (Proj. I) da ESTG.

138

Capítulo VII: Aplicação do Método de Investigação As disciplinas onde o estudo se desenrolou são aulas práticas laboratoriais, nas quais os alunos desenvolveram um projecto, isto é, um trabalho prático nas linguagens de programação C, C++ ou C#. Estas disciplinas têm por objectivo que os alunos pratiquem e aprofundem os seus conhecimentos de programação. Neste sentido, o professor responsável pela disciplina propõe aos alunos vários projectos, havendo posteriormente uma selecção daqueles que pretendem desenvolver. São disciplinas práticas, com presença obrigatória e uma carga horária de 2 horas semanais em sala de aula e 2 horas semanais de trabalho autónomo.

Gru pos A B

Ciclo de IA

Discipli nas Lab. I Lab. III

Ano curricular 1. º 2. º Póssecundário 2. º 1.º 1.º

Número de Alunos 5 4

Institui ção UTAD UTAD

Actividade preliminar

C

1.º e 2.º ciclo

Proj. I

6

ESTG

D E F 3.º ciclo 4.º ciclo

Lab. II Lab. I Lab. I

10 5 4

UTAD UTAD UTAD

Tabela 7.1: Número de alunos que participaram em cada fase desta investigação e respectivas disciplinas.

Os alunos são avaliados pelo código produzido, pelas funcionalidades do sistema implementadas e pela especificação / modelação efectuadas. Basicamente, as actividades dos alunos que participaram neste estudo consistiram em: desenvolver o algoritmo do projecto proposto; implementar o código do programa de acordo com o algoritmo efectuado. Nas disciplinas de Proj. I, Lab. II e Lab. I do 3.º e 4.º ciclos de investigação, efectuou-se uma avaliação faseada, ou seja, ao longo do semestre existiram períodos

139

Capítulo VII: Aplicação do Método de Investigação de entrega de parte do trabalho, sendo a avaliação final a soma dessas avaliações faseadas.

7.3. Recolha da informação
Nesta investigação, para reduzir a probabilidade de má interpretação, fez-se uma conjunção de técnicas de recolha de dados, o que permitiu efectuar o cruzamento da informação obtida, conduzindo a uma maior profundidade e compreensão dos resultados que se obtiveram. Como refere Barbier (1990) quanto mais diversificadas forem as técnicas utilizadas, mais “finos” e mais fiáveis serão os resultados. Neste sentido foram utilizadas as seguintes fontes de dados: relatórios diários; registos electrónicos: o imagens e vídeos das aulas virtuais; o todas as mensagens trocadas entre a professora e os alunos; questionários; entrevistas informais. No anexo I encontra-se o código atribuído a cada elemento da fonte de dados, que serão utilizados na apresentação e discussão dos resultados. De seguida expõem-se os objectivos que cada uma destas fontes de dados teve na recolha de informação no âmbito desta investigação.

7.3.1. Relatórios diários
Neste estudo, a própria investigadora foi o instrumento principal de observação e actuação. A observação participante permitiu tentar descobrir o sentido, a dinâmica e os processos envolvidos nos acontecimentos, transcendendo o aspecto descritivo da abordagem (Lessard-Hébert et al., 1990). Este tipo de observação serviu de base às reflexões sobre as aulas realizadas. Sendo a preocupação da investigadora compreender como o SL pode ser utilizado como plataforma para o ensino e aprendizagem da programação e tendo em

140

Capítulo VII: Aplicação do Método de Investigação consideração a inexistência de estudos indicativos de como este pode ser utilizado neste âmbito, como foi referido no terceiro capítulo, começou-se por explorar o mundo virtual sem pré-determinações do que poderia acontecer. Contudo, à medida que o estudo foi evoluindo as observações das aulas incidiram, na sua generalidade, sobre os seguintes pontos: a forma como os alunos e a professora interagiram entre si e com o mundo; a forma como se processaram as tarefas; o uso da interface do SL; os desafios, constrangimentos e as potencialidades para o ensino e aprendizagem dentro do SL.

Através destas observações, foram criados relatórios diários correspondentes a cada sessão, elaborados pela investigadora após o término destas, referindo os aspectos importantes que ocorreram, as impressões subjectivas e as ilações aprendidas.

7.3.2. Registos electrónicos
O recurso aos registos electrónicos teve por objectivo ajudar a investigadora a relembrar as questões importantes que ocorreram durante as aulas. Assim, efectuaram-se vários momentos de captura de imagens e gravação de vídeos do que se passava no ecrã. Para além destes registos também se guardaram todas as mensagens escritas trocadas entre a professora e os alunos, com o intuito de a investigadora poder aferir algumas questões importantes que ocorreram. Estas mensagens desempenharam um papel importante na fase de reflexão, pois ajudaram a investigadora a relembrar o contexto das incertezas e opiniões dos alunos.

7.3.3. Questionários
Foram desenvolvidos e aplicados três questionários ao longo de cada um dos semestres em que o estudo decorreu. Estes questionários foram apresentados aos alunos que participaram no início, no meio e no fim do semestre. No anexo IV encontram-se exemplares destes. Do ponto de vista de formato, os questionários

141

Capítulo VII: Aplicação do Método de Investigação foram constituídos por questões de resposta aberta. De seguida, apresentam-se os objectivos atribuídos aos questionários visando um esclarecimento adicional, por parte dos alunos, sobre a aprendizagem no SL: O primeiro questionário teve como finalidade compreender as razões pelas quais os alunos se sentiram motivados a participar nesta experiência, quais as linguagens de programação que tinham estudado anteriormente e resultados obtidos, e verificar, também, se já conheciam o SL; O segundo questionário teve como propósito o levantamento das dificuldades até então sentidas pelos alunos e formas de superação, assim como o método de ensino adoptado; O último questionário, realizado no fim do semestre lectivo, teve como objectivo fazer uma avaliação do impacto que teve nos alunos a aprendizagem da programação neste ambiente, assim como avaliar se o enunciado do projecto proposto estava claro, se o consideraram interessante o suficiente a ponto de os motivar na procura de soluções para o implementarem, e, por último, avaliar o método de ensino usado. No final do questionário, os inquiridos foram convidados a efectuar um comentário geral sobre a actividade desenvolvida. Estes questionários tiveram uma dupla função. Por um lado, resultaram em indicadores importantes sobre a forma como os alunos encaram a aprendizagem no SL. Por outro, contribuíram para um melhor conhecimento destes aspectos, por parte da investigadora, e forneceram dados para a reflexão sobre o processo de ensino e aprendizagem.

7.3.4. Entrevistas
Com o recurso às entrevistas pretendeu-se obter uma visão mais generalista do problema investigado. As entrevistas com os alunos decorreram sob a forma de conversas informais com periodicidade mensal, incidindo particularmente sobre as aulas no SL, sobre o enunciado do projecto, sobre as dificuldades que os alunos estavam a sentir e sobre sugestões para melhorar o processo de aprendizagem. Durante as entrevistas, a investigadora tomou notas das opiniões dos alunos. Estas

142

Capítulo VII: Aplicação do Método de Investigação permitiram estabelecer ideias sobre a forma como os participantes interpretavam as dificuldades e potencialidades das tarefas (Bogdam e Biklen, 1994). Os questionários e as entrevistas, em termos metodológicos, tiveram como objectivo a produção de discursos pelos actores, tornando-os fontes directas de informação. Como Almeida (2001) advoga, os alunos são simultaneamente aprendizes, observadores e intérpretes do seu próprio processo de aprendizagem, pelo que os seus comentários e observações são fonte fundamental de informação para se compreender e melhorar o processo. Toda esta informação proporcionou dados à investigadora para que esta fosse obtendo um maior conhecimento sobre o processo de ensino e aprendizagem no SL, de modo a poder melhorá-lo, assim como analisar o empenho e a motivação que os alunos demonstravam ter ao longo do processo.

7.4. Análise da informação
Durante esta investigação houve também preocupação em validar os dados que iam sendo obtidos, analisando a sua relevância e grau de profundidade, para que fosse possível conferir-lhes credibilidade (Chizzotti, 1991). Numa investigação qualitativa, em que as hipóteses e as questões do estudo emergem à medida que este se vai desenvolvendo, a validação da informação recolhida é realizada através de triangulação metodológica entre dados, investigador e teoria (Bogdan e Biklen, 1994). A triangulação é, assim, um processo que utiliza múltiplas percepções para clarificar o sentido e para identificar diferentes formas de abordagem do fenómeno em estudo (Stake, 1995). Neste estudo os dados analisados provieram das seguintes fontes: Relatórios diários de cada sessão; Questionários e entrevistas. Os registos electrónicos serviram principalmente para auxiliar a investigadora a confirmar e a relembrar o contexto das incertezas e opiniões dos alunos. Toda a informação recolhida no decorrer desta investigação foi submetida a uma análise de conteúdo. A análise de conteúdo efectuada nesta investigação baseou-se no

143

Capítulo VII: Aplicação do Método de Investigação trabalho de Bettencourt-da-Cruz (2006), tendo sido realizadas, na generalidade, as seguintes etapas: 1. Identificação de tópicos ou problemas significantes; 2. Agrupamento das declarações semelhantes em categorias, por comparação e contraste; 3. Procura de inter-relações entre as categorias encontradas. A primeira etapa da análise de conteúdo consistiu em dividir ou quebrar em unidades os dados em bruto (Descombe, 1998, Bettencourt-da-Cruz, 2006). A finalidade desta primeira etapa na análise de conteúdo é identificar as categorias que vão passar a ser o objecto de análise nas fases seguintes do processo de IA. Neste sentido, começouse por ler os relatórios diários com o intuito de identificar problemas ou questões importantes. Na segunda etapa, procedeu-se à procura de declarações semelhantes nos questionários e nas entrevistas. Nesta etapa, relativamente ao significado que a investigadora atribuiu às reacções dos alunos no decorrer das actividades, efectuou-se um cruzamento de dados entre a percepção entendida pela investigadora e as opiniões emitidas pelos próprios alunos nas entrevistas e questionários. Por fim, na terceira etapa, procurou-se compreender se existiam inter-relações entre as categorias encontradas e propôs-se uma solução que melhorasse ou resolvesse os problemas em questão. Este processo repetiu-se nos ciclos subsequentes até se ter encontrado uma solução plausível para a generalidade dos problemas; e ter-se alcançado um nível de conhecimento sobre o problema inicial desta investigação, que permitiu dar por concluído este estudo (Zuber-Skerritt, 2000). De seguida, faz-se uma explanação de todo o processo de investigação desenvolvido.

7.5. Preparação da intervenção preliminar
A primeira questão levantada, relativamente ao planeamento desta actividade preliminar, referiu-se ao tipo de projecto que seria mais adequado para os alunos desenvolverem no SL. Uma vez que o projecto é o ponto de partida para a aprendizagem nestas disciplinas, parte-se do princípio de que este deve despertar o interesse dos alunos e motivá-los a procurar compreender os conceitos que vão

144

Capítulo VII: Aplicação do Método de Investigação sendo introduzidos (Duch, 2001). Para além deste aspecto, como Schmidt e Moust (2001) advogam, o projecto deve ser adaptado ao nível de conhecimento dos alunos e não ser demasiado complexo, nem demasiado simples. Por conseguinte, na generalidade, procurou-se conhecer o nível de conhecimentos que os alunos que frequentavam estas disciplinas possuíam para melhor se poder especificar o projecto a apresentar.

7.5.1. Caracterização dos alunos
Alunos de Lab. I – a disciplina de Lab. I funciona em paralelo com a disciplina de Metodologias de Programação I, a primeira do currículo integralmente dedicada à programação, embora no semestre anterior, aspectos introdutórios da programação tivessem sido abordados em cerca de 30% da matéria lectiva de duas disciplinas, sumariadas na Tabela 7.2. Para estes alunos, o projecto em LSL constituiu o primeiro exercício de elaboração de um projecto de programação próprio, ou seja, esta foi a primeira vez que os alunos se depararam com um enunciado de um trabalho com alguma complexidade que tiveram de desenvolver. Atendendo aos antecedentes de aprendizagem de programação destes alunos, juntamente com as respostas dadas ao primeiro inquérito efectuado, pôde-se considerar que estes alunos estavam numa fase muito inicial do estudo da programação. Alunos de Lab. III – para além do contacto com a programação de projectos no ano curricular anterior (em C), aprenderam no 1.º semestre do ano 2006/2007 conceitos de programação orientada a objectos em C++ e nesse mesmo semestre desenvolveram um segundo projecto prático em C++, competências sintetizadas na Tabela 7.2. Deste conjunto de disciplinas que frequentaram e considerando as respostas ao primeiro inquérito, considera-se que estes alunos se encontravam numa fase que, embora inicial, visava já a sua autonomização no uso e estudo da programação.

145

Capítulo VII: Aplicação do Método de Investigação

Ano Disciplinas curricular

Linguagens de programação anteriormente estudadas

Linguagens de programação em estudo

Lab. I Lab. III

1.º 2.º

---C, C++

C C#

Tabela 7.2: Linguagens de programação já estudadas ou em estudo pelos alunos.

7.5.2. Projectos propostos
O projecto que os alunos implementam na generalidade das disciplinas de introdução à programação consiste no desenvolvimento de um sistema de gestão, por exemplo, a gestão de clientes num hotel ou a gestão de produtos num armazém. Projectos deste tipo são desenvolvidos com o auxílio de um compilador de C para linha de comandos, a partir do qual os alunos aprendem a programar através da manipulação textual de informação, em que focam técnicas como a manipulação de estruturas de dados e strings. O SL é um mundo virtual onde é possível criar objectos visuais com formas muito diversificadas e programar o seu comportamento através da linguagem LSL, recorrendo a scripts com execução concorrente, como se descreveu no capítulo V. Por exemplo, pode-se programar um sistema solar ou um carro que se desloque seguindo o dono (Figura 7.3). Pelo facto do SL ser um mundo com uma forte componente visual e seguindo as recomendações de vários autores (Kumar, 2005; Hundhausen e Brown, 2008; Urquiza-Fuentes e Velázquez-Iturbide, 2009) sobre os benefícios da visualização mencionados no capítulo III, a investigadora considerou importante que os alunos desenvolvessem um projecto adaptado a este ambiente. Assim, os projectos propostos tiraram partido desta possibilidade, consistindo no desenvolvimento de vários objectos visuais (um cão, um robô e um comboio e as suas respectivas estações) e na programação do comportamento que esses objectos deveriam manifestar. No anexo III encontram-se os enunciados de todos os projectos desenvolvidos no âmbito desta investigação.

146

Capítulo VII: Aplicação do Método de Investigação

Figura 7.3: Exemplo de objectos que se podem criar no Second Life: o sistema solar (imagem à esquerda) e um carro (imagem à direita).

7.5.2.1. Projecto de Lab. I Tendo em atenção o nível de aprendizagem da programação em que estes alunos se encontravam, nível inicial, o enunciado do projecto teve por objectivo que os alunos aprendessem a: Manipular estruturas de dados; Trocar informação entre objectos; Manipular estruturas de controlo; Estruturar o código; Desenvolver e aplicar funções implementadas por eles, bem como utilizar as funções pré-definidas da linguagem. Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente ampliar a complexidade das técnicas a dominar, nomeadamente, o lançamento de respostas a eventos. Neste sentido, procurou-se que o enunciado do projecto abrangesse estas técnicas de programação para que os alunos as colocassem em prática. Assim, o enunciado constou na criação e programação de um cão virtual que recebia ordens do dono e as executava, devendo também segui-lo.

147

Capítulo VII: Aplicação do Método de Investigação

7.5.2.2. Projecto de Lab. III Os objectivos de aprendizagem do enunciado do projecto de Lab. III centraram-se, para além da revisão das técnicas de programação aprendidas anteriormente, nos seguintes aspectos: Na manipulação de estruturas de dados, tais como lists2 e strings; Na manipulação de informação, nomeadamente a explorar as técnicas de canais de comunicação e o envio de mensagens através de e-mails; No lançamento e resposta a eventos; Na execução concorrente de código num mesmo objecto; Na gestão da máquina de estados; No uso de temporizadores e de sensores virtuais. Aos alunos de Lab. III foram propostos dois projectos idênticos, quer na sua complexidade quer a nível de dificuldade. Num caso, consistiu na criação de quatro robôs; noutro, de um comboio e respectivas estações. Em ambos os casos, pretendeu-se que os alunos desenvolvessem autonomamente um projecto mais complexo que o de Lab. I.

7.5.3. Procedimento
Os projectos foram apresentados a todos os alunos na primeira aula, após a qual alguns se voluntariaram para participar nesta investigação, havendo um total de 9 alunos: 5 de Lab. I e 4 de Lab. III. No SL alugou-se um terreno no qual se construiu uma casa, com uma única divisão onde os alunos puderam desenvolver os seus projectos ( Figura 7.4 e Figura 7.5). As aulas dentro do SL decorreram online, isto é, a professora-investigadora estava em Leiria e os alunos em Vila-Real, a 260 km de distância. Uma vez por mês, encontravam-se em Vila Real para conversarem sobre o projecto.

List: No LSL as list podem ser implementadas como listas internamente, mas para os alunos são semelhantes a vectores com dimensionamento variável e automático.

2

148

Capítulo VII: Aplicação do Método de Investigação Os alunos envolvidos nesta actividade juntaram-se à professora-investigadora online, no SL, enquanto frequentavam as aulas de Lab. I e Lab. III em Vila Real, ou seja, estavam situados fisicamente nos laboratórios de informática da UTAD, ao lado dos restantes colegas (que desenvolviam um projecto alternativo na linguagem C) e do professor da UTAD responsável pela disciplina. Contudo, o professor da UTAD não estava a apoiar estes grupos de alunos, a sua actuação limitava-se a resolver questões de conectividade de rede. Embora o espaço utilizado no SL, pelos alunos de Lab. I e Lab. III, fosse o mesmo, estas aulas decorreram em dias diferentes. No SL, cada aluno tinha um avatar, através do qual ia desenvolvendo o seu trabalho. Na Figura 7.5, podem-se observar os avatares de vários alunos a trabalhar.

Figura 7.4: Imagem do terreno no SL onde os alunos desenvolveram as suas actividades.

Figura 7.5: Imagem do interior da sala.

149

Capítulo VII: Aplicação do Método de Investigação

Os alunos utilizaram os computadores que se encontravam no laboratório de informática da UTAD. Estes estavam equipados com processadores Pentium IV e 1 GB de RAM, e sistema operativo Windows XP, estando ligados à Internet com largura de banda limitada.

7.5.4. Metodologia a usar nas aulas
A segunda questão levantada referiu-se à metodologia de ensino que a professora devia adoptar e ao tipo de apoio a dar aos alunos durante as aulas. Com esta questão, pretendeu-se decidir qual o tipo de intervenção que a professora-investigadora devia usar nos ciclos seguintes e qual a metodologia que melhor se adaptava a este tipo de ambientes. Como existiam alunos que estavam numa fase inicial da aprendizagem da programação (Lab. I), seguiu-se uma sugestão encontrada na literatura: a aprendizagem por exemplos (Halbert, 1984; Myers, 1990; Cypher, 1991; Lieberman, 2001; Lahtinen et al., 2005; Miliszewska e Tan, 2007). Na aprendizagem por exemplos, os conceitos a aprender devem ser ilustrados por pequenos programas, que os alunos executam e alteram, de forma a compreenderem melhor o que está a ser ensinado (Lieberman, 2001). Assim, a professora devia preparar uma panóplia de exemplos sobre os vários conceitos a serem ensinados. Por outro lado, a investigadora pretendeu empregar uma pedagogia diferenciada, ou seja, adaptar o ensino ao nível de conhecimento e ritmo de trabalho de cada aluno. Como refere Tomlison (2000): “In differentiated classrooms, teachers provide specific ways for each individual to learn as deeply as possible and as quickly as possible, without assuming one student’s road map for learning is identical to anyone else’s.”3 Como os alunos apresentam ritmos diferentes de aprendizagem é importante que tenham no início um acompanhamento personalizado (ibid.). Neste sentido, a professora deve adaptar os exemplos práticos ao nível de conhecimento de cada aluno.

“Numa sala de aula diferenciada, os professores providenciam formas específicas para cada indivíduo aprender o mais profundamente e tão depressa quanto possível, sem assumir que o trajecto de aprendizagem de um aluno seja idêntico a qualquer outro.”

3

150

Capítulo VII: Aplicação do Método de Investigação Para os alunos que se encontravam numa fase mais avançada (Lab. III) optou-se por uma aprendizagem construtivista em que a professora desempenhou as funções de tutora, como agente facilitadora do processo de aprendizagem (Bruer, 1993), estimulando os alunos a colaborarem entre si de forma efectiva para que consigam atingir os objectivos definidos no projecto. Esta ajuda envolve explicações, demonstrações e a colocação de questões, de modo a que os alunos possam reflectir na solução apresentada. Os alunos de Lab. I realizaram o projecto individualmente. Embora esta organização fosse uma opção do professor responsável pela disciplina na UTAD, este opção foi também estendida aos alunos que realizaram o projecto no SL, de modo a haver uniformização nesta disciplina. Já os alunos de Lab. III formaram grupos de dois alunos para colaborarem entre si. Outra variável considerada neste processo refere-se ao canal de comunicação a ser usado pela professora durante as aulas. Nesta investigação, toda a comunicação baseou-se na troca de mensagens escritas. A comunicação por voz, dentro do SL, não foi utilizada, por duas razões fundamentais: A primeira, deveu-se ao facto de as aulas serem online e os alunos estarem na sala de aula com outros colegas, que não faziam parte desta investigação. Não era possível colocar os alunos participantes na investigação a comunicar por voz com a professora, uma vez que seria uma acção perturbadora para os restantes colegas; A segunda razão, prendeu-se com a panóplia de recursos tecnológicos envolvidos. Para além de auriculares e microfones era necessário também dispor de uma grande largura de banda para permitir que os alunos conversassem em simultâneo. Este segundo factor tem sido frequentemente referido na literatura como impedimento para a utilização de voz (Zimmermann e Liang, 2008; Bessière, Ellis e Kellogg, 2009; Edirisingha et al., 2009). Assim, inicialmente optou-se por usar unicamente o canal público (consultar no capítulo V, subcapítulo 5.3 uma explicação detalhada sobre comunicação no SL), não só por ser o meio de comunicação mais utilizado no SL, mas também por ter a vantagem de todos os alunos visualizar o que se estava a passar na aula.

151

Capítulo VII: Aplicação do Método de Investigação

7.5.5. Plano da aula
No que se refere ao plano da aula (Reynolds, 1992, seg. Bettencourt-da-Cruz, 2006, p. 99): “…esta deverá retratar cada uma das aulas em si, no que respeita às actividades que a professora pretende levar a cabo em sala de aula e ao que espera que o aluno faça. (...) Este plano deverá ser perspectivado como flexível e passível de reajustes ou, até mesmo, de abandono face à realidade dos acontecimentos em sala de aula.” Neste sentido, elaborou-se o plano das aulas desta primeira actividade preliminar. O plano detalhado encontra-se no anexo II. A primeira fase consistia na construção dos objectos que eram necessários para a realização do projecto. Pretende-se, para tal, despender um máximo de 2 aulas, para ambos os grupos Lab. I e Lab. III. Esta primeira fase serve, também, para que os alunos se adaptem e familiarizem com o SL. As restantes aulas são dedicadas à programação. No fim de cada aula, a professora fornecerá orientações sobre o que os alunos devem estudar e fazer em casa para a aula seguinte.

7.6. Resultados e reflexões da fase preliminar
A professora começou, tanto nas aulas de Lab. I como nas de Lab. III, por explicar e demonstrar como funcionam o SL em geral e o editor de código em particular, incluindo as técnicas de construção de objectos. Nas três primeiras aulas, os alunos dedicaram-se à construção dos objectos que faziam parte do projecto (um cão, um robô e um comboio) e a familiarizarem-se com o editor. Durante esta etapa de adaptação, as dificuldades sentidas pelos alunos de ambos os grupos foram semelhantes, nomeadamente: Como ligar objectos entre si – um erro comum, que sucedeu ao tentarem ligar vários objectos que tinham construído, foi que ao seleccionarem os objectos em questão, por descuido seleccionavam também outros dos quais não eram os donos, como, por exemplo, o chão da casa. Desta forma a ligação tornava-se impossível. Em outras ocasiões, não seleccionaram todos os objectos que pretendiam ligar entre si;

152

Capítulo VII: Aplicação do Método de Investigação Como criar cópias de objectos – sucedeu frequentemente que, ao tentarem replicar um objecto, por exemplo, a pata do cão, seleccionarem outros dos quais não eram os donos, nomeadamente, o chão; isto impediu-os de criar réplicas. Por vezes, não tiveram os objectos que faziam parte da pata ou do braço do robô todos ligados entre si, assim só parte do objecto era replicado. Outro aspecto, a salientar durante esta actividade, consistiu no facto de os alunos repetirem com alguma frequência o mesmo erro, nas várias aulas. Do ponto de vista da investigadora, a frequente incidência destes erros deveu-se a dois factores: primeiro, o editor tem uma panóplia de comandos (ver capítulo V) o que dificulta a sua utilização, principalmente para quem é iniciante; segundo, os alunos não compreenderam o que a professora lhes explicou. Devido ao facto de a explicação ser dada por escrito e alguns comandos consistirem na conjunção de teclas como, por exemplo, fazer o zoom (descrito no capítulo V, pag. 113), o que dificulta o processo de execução, os alunos frequentemente não compreendiam que as tinham de premir em simultâneo. Este segundo factor foi corroborado pelos alunos nos encontros mensais, os quais mencionaram: - “A nossa principal dificuldade consistiu em fazer o zoom aos objectos, de forma a podermos seleccionar apenas os nossos e não percebíamos como fazê-lo”. (Ent., aluno 2 de Lab III, dia 26/4/2007) -“Embora a professora explicasse como se devia fazer o zoom nós não compreendíamos que tínhamos de utilizar as várias teclas em conjunto”. (Ent., aluno 4 de Lab. I, dia 27/4/2007) Esta etapa da construção levou mais tempo do que a investigadora planeara, que inicialmente era de duas aulas. Por um lado, as dificuldades sentidas atrasaram a construção dos objectos, por outro, os alunos entusiasmaram-se com a construção e em vez de criarem objectos simples empenharam-se em criar objectos mais elaborados e complexos (Figura 7.7 e Figura 7.7).

153

Capítulo VII: Aplicação do Método de Investigação

Figura 7.6: Objectos criados pelos alunos no decorrer desta actividade. Na imagem, à esquerda, o conjunto de robôs, à direita um cão.

Figura 7.7: Objectos criados pelos alunos no decorrer desta actividade. O comboio, os apeadeiros, respectivas cidades e fábricas.

7.6.1. Início da programação – Lab. I
Na quarta aula, deu-se início à aprendizagem da programação. Durante este processo, verificou-se uma boa adaptabilidade, por parte dos alunos, à linguagem de programação LSL, quer à sua sintaxe, quer à sua semântica. Contudo, sentiram algumas dificuldades na compreensão das técnicas de programação mais avançadas, como o lançamento e resposta a eventos, o que obrigou a professora ter de explicar cada parte do código dos exemplos fornecidos e para alguns alunos foi necessário alterar-se esses exemplos por outros mais simples. Os alunos pegaram nestes exemplos, experimentaram e adaptaram-nos de forma a completarem o seu projecto.

154

Capítulo VII: Aplicação do Método de Investigação Observou-se que os alunos conseguiram compreender o que estes pequenos programas faziam e qual o objectivo de cada um. Quer através da experiência pessoal da investigadora como docente de programação, quer através da literatura da área (Chen e Weld, 2008), sabe-se que este aspecto é difícil de alcançar quando os alunos estão a aprender a programar, principalmente, em ambientes tradicionais como, por exemplo, compiladores de C para linha de comandos, onde os alunos, geralmente, sentem grande dificuldade em perceber o objectivo da programação. Um aspecto particularmente importante no ensino da programação é a reacção dos alunos aos erros de compilação e execução (Gomes e Mendes, 2007; Esteves, 2004), inevitáveis para quem está a aprender. Neste grupo de alunos, observou-se diferentes tipos de comportamentos face às dificuldades, quer em relação aos erros de compilação e execução, quer em relação às questões do projecto. Observou-se que alguns alunos foram incapazes de avançar quando surgia alguma dificuldade, ficavam passivamente à espera que a professora os fosse ajudar, enquanto outros faziam várias tentativas para resolver a situação ao acaso sem pensarem nem/ou analisarem de onde vinha o problema, mas, mesmo assim, sempre conseguiam resolver algumas das questões. Face às necessidades destes alunos, que não conseguiam avançar sem uma ajuda complementar, foi necessário um acompanhamento mais intenso, por parte da professora, a qual explicava e exemplificava o que estava errado, e por outro lado incentivava-os a começarem a tentar resolver as questões por si próprios. Consequentemente, ao dedicar-se a um aluno, a professora muitas vezes perdia a noção do que os outros estavam a fazer, das dificuldades que estavam a sentir, se necessitavam de alguma explicação, etc. Por conseguinte, nem sempre foi possível à professora aperceber-se de imediato das necessidades individuais de todos os alunos e fazer o respectivo acompanhamento. Deste modo, o objectivo inicial de se empregar uma pedagogia diferenciada foi parcialmente alcançado, em parte devido ao canal de comunicação escolhido, uma vez que quando os alunos tinham alguma dificuldade em relação ao código a utilizar, partilhavam-no com a professora para que esta o pudesse analisar e dar indicações do que estava errado. Assim, a professora perdia a noção do que se estava a passar no canal público, quando alguém lhe queria perguntar alguma coisa, visto que este não emitia nenhum sinal sonoro ou visual para além do simples texto. A Figura 7.8 ilustra o aspecto do ecrã da professora durante o esclarecimento de uma dúvida. Esta situação também foi corroborada pelos alunos nos encontros mensais:

155

Capítulo VII: Aplicação do Método de Investigação “Algumas vezes perguntávamos se a professora nos podia ajudar e não obtínhamos resposta.”. (Ent., aluno 3 de Lab. I, dia 12/7/2007) Uma das soluções pensadas para ultrapassar este problema consistiu em criar algum processo de chamada de atenção, sem ser por chat, de tal forma que a professora se apercebesse visualmente de que um aluno ou grupo também precisava de ajuda. Este mecanismo visual de chamada de atenção não chegou a ser implementado neste ciclo, nem nos seguintes, uma vez que a investigadora, face ao problema exposto, decidiu utilizar o canal público exclusivamente para dar explicações gerais a todos os alunos e o canal privado para tirar dúvidas ou dar explicações individuais a um aluno de cada vez.

Figura 7.8: Aspecto do monitor da professora durante uma aula, na qual a professora está a analisar o código de um aluno.

Outro contratempo constatado verificou-se quando os alunos tinham dúvidas no código que estavam a desenvolver, sendo necessário partilhá-lo com a professora para que esta o pudesse analisar, com o intuito de os ajudar. Frequentemente sucedia que os alunos não atribuíam ao objecto e respectivo script as permissões correctas, de modo a que essa partilha fosse possível (ver no capítulo V, partilha de scripts). Esta situação também era comum acontecer aos alunos de Lab. III. Nos encontros mensais os alunos referiram que esta situação se devia: 156

Capítulo VII: Aplicação do Método de Investigação -“Muitas vezes esquecíamo[-no]s que se tinha de dar permissões para a professora poder ver o código.”. (Ent., aluno 2 de Lab. I, dia 31/05 /2007) -“ Acontecia frequentemente não nos lembrarmos como é que se davam as permissões e por isso a professora não conseguia ver o código, porque as permissões estavam erradas.”. (Ent., aluno 4 de Lab III, dia 31/05/2007) Os alunos de Lab. I não conseguiram concluir o projecto na totalidade durante as aulas como estava previsto no plano inicial. Contudo, embora estes alunos tivessem uma semana adicional após as aulas terem terminado não foram capazes de o acabar sozinhos. Este resultado deveu-se, na opinião da investigadora, por um lado, devido aos alunos não terem hábitos de programação autónoma e, por outro, ao facto de durante as aulas ter-se consumido algum tempo para que estes assimilassem os conceitos de programação e respectivas técnicas, o que os impediu de chegarem à última aula com o projecto totalmente concluído. Os alunos nos questionários e nas conversas tidas com a professora, explicaram esta situação da seguinte forma: -“Nós tínhamos outras disciplinas para fazer e deixámos o projecto para o fim, só que depois não tivemos tempo de o acabar”.(Ent., aluno 1 de Lab I, dia 12/07/2007) -“Pensávamos que o projecto era fácil de fazer e por isso dedicamo-nos (sic) a outras disciplinas e deixámos esta para o fim e por isso não conseguimos acabar”. (QuestF.)

7.6.2. Aulas de Lab. III
Estes alunos facilmente se adaptaram ao SL e à linguagem de programação LSL. O objectivo inicial da professora em centrar-se na orientação, fazendo com que os alunos por sua auto-iniciativa investigassem e apresentassem soluções, foi totalmente atingido. Contudo, esta metodologia levou a que os alunos efectuassem muitos erros de execução. Frequentemente, aplicavam erradamente as funções predefinidas da linguagem. Observou-se que escolhiam as funções por tentativa e erro, sem pensarem no que realmente queriam fazer. Nestas situações, a professora questionava-os sobre qual a funcionalidade que pretendiam implementar, obrigandoos, assim, a reflectir no que tinham feito e no que realmente era pretendido, conduzindo, desta forma, os alunos a desenvolverem o pretendido. Não se observou que os alunos ficassem desmotivados por isto acontecer, antes pelo contrário

157

Capítulo VII: Aplicação do Método de Investigação corrigiram o programa e continuaram à procura de uma solução. Apesar de os alunos terem referido que o projecto era difícil e extenso, estes concluíram-no na totalidade, como se pode constatar no seguinte comentário feito nas aulas: -“O projecto é complicado e tem muitas funcionalidades, mas nos (sic) estamos a gostar de o desenvolver.”(Reg., aluno 3 de Lab III, dia 8/05/2007) No decorrer das aulas, observou-se, por parte dos alunos, um grande empenho no desenvolvimento do projecto. Estes ficaram de tal modo fascinados pelo SL que criaram vários objectos e programas por mero divertimento, acabando um deles por receber uma proposta de compra, por um dos avatares residentes no SL (não se tratou de uma tentativa de fraude académica, mas sim de legítimo interesse individual no produto criado).

7.6.3. Professora
Do ponto de vista da investigadora, a maior dificuldade na utilização do SL para o ensino da programação consistiu: Na gestão da comunicação entre a professora e os alunos – devido ao facto de se ter escolhido o canal público, verificou-se um certo grau de dificuldade na comunicação entre a professora e os alunos. A constante troca de mensagens entre os alunos e entre estes e a professora, juntamente com os objectos a enviarem mensagens para o seu dono (Figura 7.9), dificultou o acompanhamento das actividades, quer por parte dos alunos, quer pela professora. Daí, ter-se optado por solicitar que nas mensagens se incluísse sempre o nome do aluno para o qual a mensagem se dirigia. Desta forma, cada mensagem tinha sempre a identificação do autor, colocada pelo SL, mas também do receptor da mensagem, evitando-se assim ambiguidade sobre o destinatário. Devido a esta limitação, nos ciclos seguintes abandonou-se esta forma de comunicar;

158

Capítulo VII: Aplicação do Método de Investigação

Figura 7.9: Lista das mensagens trocadas numa aula: as setas vermelhas indicam as mensagens dos objectos; as verdes da professora e as amarelas dos alunos.

Na disposição espacial dos grupos de alunos no mundo virtual – os alunos encontravam-se dispersos pela sala, outros vinham para fora trabalhar, atendendo ao facto do limite visível de comunicação através do canal público ser de 20m (virtuais). Consequentemente, a professora tinha de se deslocar pelo espaço para se inteirar do que estavam a fazer e das possíveis dúvidas existentes. Este facto poderia ter sido evitado caso fosse utilizado outro canal na comunicação, como seja o uso de mensagens privadas através das quais se pode estabelecer uma comunicação independentemente da distância a que se está; No apoio aos alunos fora das aulas semanais – os alunos fora do tempo de aula continuavam a desenvolver os seus projectos, a procurar soluções para os diversos problemas. Todas as vezes que tinham aulas, expunham à professora as dificuldades sentidas e os progressos alcançados. Em alguns casos, preferiam enviar pelo SL uma mensagem à professora expondo as suas dificuldades e pedindo orientações. Para um acompanhamento mais eficiente, por parte da professora, seria útil existir um mecanismo de informação como, por exemplo, e-mail ou outro sistema exterior ao SL, que desse indicação do

159

Capítulo VII: Aplicação do Método de Investigação que os alunos realizaram ao longo da semana, as dificuldades sentidas e as tentativas efectuadas para as ultrapassar.

7.6.4. Questionários
Relativamente aos questionários realizados nesta actividade, ao primeiro e segundo responderam a totalidade dos alunos (15) que participaram, no último responderam 3 de Lab. I e 5 de Lab. III. Da análise feita a estes questionários e das reuniões tidas com os alunos, foram mencionados os seguintes aspectos: Método de ensino usado – os alunos consideraram que em algumas aulas tornou-se difícil de perceber o que a professora explanava porque alguns colegas estavam a conversar ou os objectos a enviar mensagens. Referiram, também, que o facto de estarem a trabalhar perto uns dos outros e alguns em grupo, associado aos problemas em acompanhar o discurso da professora, contribuiu para entrarem em conversas paralelas e a dispersarem-se dos assuntos em discussão. Uma vez mais se confirma que o canal escolhido não foi o mais apropriado. Os alunos de Lab. I consideraram que os exemplos práticos que puderam testar e alterar foram importantes para compreenderem os conceitos e os ajudaram no desenvolvimento do projecto; Projecto proposto – os alunos foram unânimes em referir que o enunciado era explícito, que compreenderam o que tinham de implementar, embora não soubessem de que forma. Os alunos de Lab. I consideraram o projecto acessível, no entanto confessaram que não o conseguiram terminar por não terem dedicado mais tempo fora do período das aulas. Por outro lado, os seus colegas de Lab. III consideraram o enunciado do projecto interessante e um pouco difícil, mas gostaram muito de o concretizar. Este facto levou a investigadora a considerar que o enunciado do projecto atribuído aos alunos de Lab. I talvez fosse demasiado simplista, pelo que estes alunos não se aplicaram como deviam para o concluir. Este raciocínio vem na linha do que Schmidt e Moust (2001) referem ao mencionarem que um problema não deve ser nem demasiado simples nem demasiado complexo; quando um projecto é demasiado fácil, muitas vezes, os alunos não se aplicam como deveriam;

160

Capítulo VII: Aplicação do Método de Investigação Aprendizagem no SL – os alunos mencionaram que nunca tinham usado o SL. Um aspecto positivo, realçado por todos, referiu-se ao facto de no SL poderem observar visualmente a execução dos seus programas: -“Assim conseguíamos perceber para que servem as estruturas de repetição e decisão.” (Ent., aluno 5 de Lab. I, dia 12/07/2007) -“No SL bastava observar o comportamento do nosso cão para saber se o programa estava correcto, assim é muito mais fácil.” (Reg., aluno 3 de Lab. I, dia 4/06/2007) Referiram ainda que gostaram da experiência, que foi proveitosa para quem estava a aprender a programar. Um dos pontos negativos que referiram consistiu no facto de a linguagem de programação ser o LSL e não uma das linguagens que estudam ao longo do curso; Comentário geral sobre a actividade – os alunos não fizeram grandes comentários, mas genericamente gostaram da experiência, como se evidencia nos seguintes comentários: “Gostei de participar nesta experiência”(Ent., aluno 1 de Lab. I, dia 12/07/2007); “gostei de programar no SL”;(QuestF.) “fiquei viciado no SL” (Reg., aluno 4 de Lab III, dia 12/06/2007) Na Tabela 7.3 apresenta um resumo do que se constatou ao longo da actividade preliminar.

161

Capítulo VII: Aplicação do Método de Investigação

Participantes

Constatações Dificuldades na utilização do editor de objectos do SL;

Lab. I

Dificuldades em compreender os erros de compilação; Dificuldades em compreender como funcionam os eventos; Dificuldades na utilização do editor de objectos do SL;

Lab. III Dificuldades em compreender as funções predefinidas da linguagem; Dificuldade em gerir a comunicação entre os alunos e a professora; Os alunos estavam muitos dispersos pelo espaço da aula no SL o que Professora dificultou o acompanhamento por parte da professora; Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas semanais.

Tabela 7.3: Resumos das constatações da actividade preliminar.

7.7. Plano do 1.º ciclo de investigação-acção
Após a fase preliminar, na qual se identificaram os vários problemas supra mencionados, deu-se início à planificação do primeiro ciclo estruturado da IA. Neste primeiro ciclo, a preocupação principal da investigadora consistiu em perceber a razão primordial das dificuldades sentidas pelos alunos, sobretudo no que diz respeito à programação e testar uma nova forma de comunicação para melhorar a dinâmica das aulas.

7.7.1. Caracterização dos alunos
Neste ciclo participaram os alunos das disciplinas de Lab. II da UTAD e Proj. I da ESTG. São disciplinas práticas, com presença obrigatória e uma carga horária de 2 horas semanais em sala de aula e 2 horas semanais de trabalho autónomo, estando previstas 15 aulas. Na primeira aula apresentou-se aos alunos o enunciado do 162

Capítulo VII: Aplicação do Método de Investigação projecto proposto, findo a qual se voluntariaram para participar nesta experiência 6 alunos da ESTG e 10 da UTAD. Os alunos de Lab. II, no ano anterior, tiveram uma disciplina semestral de introdução à linguagem C, na qual desenvolveram um projecto nesta linguagem de programação, na linha de comandos. No corrente ano lectivo, em simultâneo com a disciplina de Lab. II estavam a aprender programação orientada a objectos em C++ (Tabela 7.4). Na generalidade, estes alunos possuíam um pouco mais de conhecimentos de programação do que os de Proj. I. Os alunos de Proj. I, no ano anterior, tiveram uma disciplina semestral de introdução ao C, na qual abordaram somente os conceitos básicos, tendo sido, no entanto, este o primeiro projecto que desenvolveram. Estes alunos, a nível de conhecimentos de programação, encontravam-se no mesmo patamar dos de Lab. I.

Disciplinas

Ano curricular

Linguagens de programação anteriormente estudadas

Linguagens de programação em estudo C++ ----

Lab. II Proj. I

1.º Pós-Secundário

C C

Tabela 7.4: Linguagens de programação já estudadas ou em estudo pelos alunos.

7.7.2. Planeamento das aulas
Face aos resultados analisados na actividade preliminar, a investigadora considerou importante para melhorar o processo de ensino e aprendizagem fazer as seguintes alterações nas variáveis de processamento: Projecto proposto – aos alunos de Proj. I propôs-se dois enunciados de trabalho com características idênticas. Pretendeu-se que estes alunos aprendessem a programar através de interacções físicas, pelo que o enunciado foi semelhante ao desenvolvido pelos alunos de Lab. I (projecto visual), embora com um grau de dificuldade um pouco superior. Com este trabalho pretendeu-se que os alunos estudassem e praticassem os seguintes conceitos: o Variáveis;

163

Capítulo VII: Aplicação do Método de Investigação o Manipulação de estruturas de dados, tais como lists e strings; o Troca de informação entre objectos; o Manipulação de estruturas de controlo; o Estruturação do código; o Desenvolvimento e aplicação de funções, implementadas pelos alunos assim como as pré-definidas da linguagem. Em relação aos alunos de Lab. II, acordou-se com o professor responsável pela disciplina da UTAD que o enunciado do trabalho efectuado no âmbito desta investigação teria de ter características idênticas aos dos trabalhos propostos fora dela aos demais alunos da disciplina. Assim, este trabalho consistiu na gestão de um armazém de farmácias onde os alunos aprenderam a programar, focando técnicas não visuais como a manipulação de dados textuais e numéricos. Os objectivos de aprendizagem deste projecto centrarem-se, para além da revisão das técnicas de programação aprendidas anteriormente, nos seguintes aspectos: o Na manipulação de estruturas de dados, tais como lists e strings; o Na manipulação de informação, nomeadamente a exploração de técnicas de canais de comunicação e o envio de mensagens através de e-mails; o Na gestão de máquina de estados. Os enunciados dos projectos foram disponibilizados no SIDE da UTAD e no Moodle da ESTG, ao qual todos os alunos que participaram tinham acesso. No anexo III encontram-se os enunciados dos projectos propostos. Procedimento durante as aulas – os alunos trabalharam aos pares, colaborando entre si na resolução do problema. Ambos os grupos de alunos permaneceram na sala de aula acompanhados pelo respectivo professor da disciplina e restantes colegas, e encontravam-se no SL com a professorainvestigadora. Uma vez por mês, os alunos de Lab. II reuniam-se com a investigadora na UTAD para conversarem sobre o trabalho. Por outro lado, os alunos de Proj. I como estavam mais próximo da investigadora teriam,

164

Capítulo VII: Aplicação do Método de Investigação também, reuniões agendadas uma vez por mês e outras sempre que se considerassem necessárias. Relativamente ao plano da aula, este foi semelhante aos dos alunos de Lab. I do semestre anterior, que pode ser consultado no anexo II. Contudo, salienta-se o aspecto de na terceira aula os alunos terem de entregar o algoritmo do projecto. Pretendeu-se, assim, obrigar os alunos a pensar e a planear o projecto antes de iniciarem a sua execução. Para além disto, o projecto teve quatro momentos de avaliação, ao longo do semestre. Na última aula, todas as funcionalidades deviam estar implementadas. Durante as aulas, a professora empregou uma pedagogia diferenciada, disponibilizando exemplos práticos dos conceitos que foram sendo introduzidos. Contudo, estes exemplos foram alterados e adaptados às dificuldades versus facilidades e ritmos de trabalho de cada aluno; Comunicação – as aulas, em ambas as disciplinas, decorreram de forma semelhante às da fase anterior, isto é, foram aulas online. Face às dificuldades sentidas, na iteração anterior, referente à utilização exclusiva do canal público durante as aulas, no próximo ciclo de IA passou-se a utilizar o canal público exclusivamente para fazer chamadas de atenção, para expor ou demonstrar algo para todos os alunos. O canal privado passou a ser o principal meio de comunicação entre a professora e os alunos. Todos os objectos deveriam enviar as suas mensagens directamente para o seu dono, através de um canal próprio em vez de ser o público; Espaço da aula – para cada grupo de alunos, foram criadas zonas demarcadas por um círculo onde estes deviam trabalhar (Figura 7.10). Esta demarcação resultou do facto de na iteração anterior os alunos terem-se dispersado pelo terreno, obrigando assim a professora a deslocar-se constantemente de forma a inteirar-se do que estes faziam. No espaço da aula criou-se também uma zona de exposição, onde se colocaram os vários exemplos usados nas aulas para demonstração. Nesta zona, os alunos puderam colocar os trabalhos que desenvolveram ao longo do semestre.

165

Capítulo VII: Aplicação do Método de Investigação

Figura 7.10: Espaço de aula no SL com zonas demarcadas para cada grupo de alunos, a vermelho a zona de exposição.

Apoio aos alunos fora das aulas – considerando a dificuldade da professora, na iteração anterior, em acompanhar o trabalho autónomo dos alunos fora das aulas, desenvolveu-se um objecto com o cognome de “objecto de dúvidas”. O propósito deste objecto consistiu no recebimento de cartões, no qual os alunos podiam expor as suas dúvidas, com o código para a professora analisar, ou simplesmente sugestões que queriam fazer. Este objecto enviava um e-mail à professora notificando-a da chegada de um cartão etiquetado como sendo de dúvidas ou sugestões (ver Figura 7.11). Esperava-se que, assim, a professora pudesse ajudar os alunos a ultrapassar as suas dificuldades fora das aulas e acompanhá-los melhor nas actividades que estavam a desenvolver.

166

Capítulo VII: Aplicação do Método de Investigação

Figura 7.11: Objecto de dúvidas para ser usado fora das aulas.

7.8. Resultados e reflexão do 1.º ciclo
Por volta da sétima semana, a investigadora efectuou uma interrupção no ciclo de IA e reflectiu sobre o que se tinha observado até ao momento nesta iteração, de forma a repensar sobre o que estava correcto e errado, inserindo alterações para melhorar o processo de ensino e aprendizagem. A primeira e segunda aulas foram de adaptação ao SL, consistindo estas na criação e configuração do avatar, e na construção de objectos para a ambientação dos alunos ao editor de SL. As dificuldades relatadas na fase preliminar, em relação à utilização do editor, mantiveram-se, ou seja, ambos os grupos de alunos sentiram as mesmas dificuldades em relação à forma de replicar e ligar objectos entre si. Nas reuniões mensais, os alunos confirmaram que tiveram dificuldades em compreender como usar os comandos, como se constata pelos seus comentários: -“Não conseguímos compreender como criar uma cópia, nem como fazer o zoom.”. (Ent., aluno 2 de Proj. I, dia 22/10/2007) -“Foi difícil de perceber como ligar os objectos entre si.” (Ent., aluno S de Lab II, dia 25/10/2007) Por outro lado, os alunos de Proj. I pediram à professora para terem uma reunião na qual lhes explicasse como funcionava o editor, como se podia fazer uma réplica de

167

Capítulo VII: Aplicação do Método de Investigação um objecto e como se fazia o zoom. Notoriamente as dificuldades em usar o editor desapareceram. Esta situação levou a investigadora a considerar importante que a primeira aula no SL seja presencial e não remota para se poder explicar e demonstrar a correcta utilização do editor. Em termos de comunicação, a abordagem adoptada neste ciclo evitou os problemas mencionados anteriormente, uma vez que, através do canal privado, a professora teve sempre presente as solicitações que estava a receber dos alunos. Contudo, nem sempre conseguiu dar uma resposta imediata às solicitações recebidas, nomeadamente, quando se encontrava a esclarecer alguma dúvida a um aluno, para não interromper a explicação em curso, a professora só respondia quando terminava. Esta situação induziu os alunos a pensarem que a professora se tinha ausentado e muitas vezes perguntavam através do canal público: “ A professora está aí?” (Reg., aluno S de Lab II, dia 17/12/2007) Para além deste aspecto, no geral, os alunos apreciaram a utilização deste meio de comunicação, uma vez que, sentiram que tinham uma professora exclusivamente para eles, como se constata pelos seus comentários: -“(…)parecia que estávamos a ter explicações e não numa aula.”(QuestInt.) -“Gostei, pois podia colocar as minhas dúvidas sem me preocupar com o que os meus colegas iam pensar.” (Ent., aluno M de Lab. II, 22/11/2007) Relativamente à distribuição espacial dos alunos, o facto de se terem demarcado zonas de trabalho no espaço dedicado às aulas para cada grupo, evitou as constantes deslocações da professora para fora da sala, e por outro lado ajudou-a a ter uma noção geral da turma durante as aulas.

7.8.1. Programação alunos de Lab. II
A questão da programação foi introduzida usando-se a mesma metodologia dos alunos de Lab. I da fase preliminar. Fez-se uma revisão dos conceitos básicos e utilizaram-se exemplos que os alunos alteraram e testaram. Inicialmente, estes alunos mostraram que compreendiam estes conceitos. Na terceira semana, os alunos entregaram o algoritmo do trabalho em texto e não manifestaram terem tido grandes dificuldades em perceber o que tinham de implementar. À medida que se avançou no

168

Capítulo VII: Aplicação do Método de Investigação desenvolvimento do trabalho, observou-se que os alunos não foram capazes de aplicar os conceitos aprendidos a novas situações. Apesar de estes alunos já terem conhecimentos de programação em linguagem C, apresentavam muitas dificuldades e falhas na compreensão dos conceitos básicos, principalmente em como os aplicar correctamente. A título de exemplo: nas estruturas de repetição, não sabiam quando nem como usá-las; nas funções, não sabiam como chamar uma função definida por eles. Ao contrário do que seria de esperar, estes alunos não reconheciam as suas dificuldades, como se pode constatar pelos seus comentários: -“Eu sei a linguagem C, e não tenho dificuldades em C, eu tive uma boa nota o ano passado.” (Reg., aluno A, dia 29/10/2007) -“A linguagem C eu sei, aqui é que não percebo nada disto.” (Reg., aluno B de Lab. II, dia 5/11/2007) Contudo, não mostraram nas aulas que realmente sabiam aplicar esses conhecimentos. Alguns dos exemplos práticos, que a professora disponibilizou para eles analisarem, foram na generalidade percebidos, mas no entanto os alunos não foram capazes de observar que era precisamente esse mesmo código que tinham que aplicar no seu trabalho. Este aspecto vem ao encontro do que Winslow (1996) refere: “that novice programmers neglect strategies, are limited to the general knowledge of the subject and that knowledge is fragile.” Um conhecimento frágil é descrito, pelo mesmo autor, como sendo algo que os alunos sabem, mas não conseguem aplicá-lo quando é necessário. Os erros de compilação ocorreram com alguma frequência. Os alunos de Lab. II apresentaram muitas falhas em termos de sintaxe, por exemplo, nas estruturas de decisão e repetição, o que surpreendeu a investigadora, uma vez que estes já tinham desenvolvido um projecto em C e não era de esperar este tipo de erros. A abordagem adoptada pela professora consistiu em aconselhar os alunos a analisarem a linha do código na qual o erro se encontrava e a pensarem no que faltava ou no que estava errado. Contudo, após a reincidência dos mesmos erros, pôde-se concluir que esta abordagem não foi a mais adequada. Assim, no ciclo de IA seguinte a professora passou a escrever comentários no código dos alunos, para que estes tivessem sempre presente uma justificação escrita da causa do erro.

169

Capítulo VII: Aplicação do Método de Investigação Quanto aos erros de execução observou-se, em algumas situações, que os alunos não eram capazes de concluir se o programa estava a funcionar correctamente ou não. Como se tratava de um projecto não visual, que se resumia à manipulação textual da informação, os alunos pediam com frequência o auxílio da professora para esta conferir o correcto funcionamento do programa, como se pode constatar pelas seguintes afirmações recolhidas nas aulas: -“Confirme, se faz favor, se é isto que o programa tem de fazer.” (Reg., aluno A, dia 5/11/2007) -“Eu não percebo nada disto, não sei se o programa está certo ou errado.” (Reg., aluno B, dia 29/10/2007) A falta de uma componente visual no projecto foi motivo de um maior descontentamento e até frustração por não terem sido capazes de solucionar as situações. Um dos grupos estava constantemente a solicitar ajuda, parava à mínima dificuldade, quer em relação aos erros de compilação, quer de execução e até de interpretação do enunciado do problema. Por mais que a professora tentasse que este grupo progredisse sozinho, tal não foi alcançado. Uma das razões apontadas pelos alunos nas respostas ao questionário foi: -“(...) que o enunciado do trabalho prático era complicado para ser feito no SL e que preferiam estar a implementar outro tipo de programa mais interessante.” (QuestF.) Outra fonte de dificuldades, em relação aos erros de execução, residiu na escolha da função correcta para simular uma determinada funcionalidade. Esta mesma dificuldade também se observou nos alunos de Proj. I. O manual da linguagem LSL, para cada função, descreve o que esta faz, o tipo de dados que recebe e devolve. Embora existam muitas funções (Figura 7.12), algumas destas são correntemente usadas, pelo que a investigadora estava com alguma dificuldade em compreender a razão deste erro sistemático. Tendo-se observado no decorrer das aulas e principalmente das conversas tidas com os alunos que o problema residia, fundamentalmente, na dificuldade em compreenderem a língua inglesa, pelo que a investigadora decidiu traduzir para português algumas das funções usualmente empregues no projecto que os alunos estavam a desenvolver.

170

Capítulo VII: Aplicação do Método de Investigação

Figura 7.12: Lista das funções existentes no LSL.

7.8.2. Alunos de Proj. I
Os alunos de Proj. I embora sentissem dificuldades em relação aos erros de compilação, execução e de interpretação do problema, já referidos anteriormente, tentavam dar-lhe solução, efectuando pesquisas e adaptando os programas-exemplo que encontravam. Estes alunos demonstraram ser mais autónomos, apesar de estarem no início da sua aprendizagem, mostraram maior entusiasmo com o SL, demonstrado através do desenvolvimento de outros objectos e programas, para além dos que lhes era solicitado no enunciado do projecto. Face a estes dois cenários opostos relativos à reacção dos alunos, expostos a enunciados diferentes, a investigadora, para despertar o interesse dos alunos de Lab. II mais desmotivados, considerou pertinente introduzir uma componente visual no

171

Capítulo VII: Aplicação do Método de Investigação enunciado do projecto dos alunos. Aos alunos de Proj. I, mais motivados, introduziu-se, no projecto, uma componente de manipulação textual da informação. Com este ajuste aos enunciados dos projectos pretendeu-se avaliar se haveria mudanças significativas nestes dois grupos ao nível da motivação na aprendizagem, tendo representado o início de uma nova iteração de IA. A Tabela 7.5 apresenta um resumo das observações deste ciclo de IA.

Participantes

Constatações Dificuldades na utilização do editor de objectos do SL; Dificuldades em compreender os erros de compilação e de execução;

Lab. II

Dificuldades em compreender o objectivo do projecto e consequente desmotivação dos alunos; Dificuldades em compreender o que as funções predefinidas da linguagem; Dificuldades na utilização do editor de objectos do SL;

Proj..I Dificuldades em compreender o que as funções predefinidas da linguagem; Constante repetição dos mesmos erros, quer de compilação quer de execução; Professora Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas semanais.

Tabela 7.5: Resumo das constatações do 1.º ciclo de IA.

No que concerne ao apoio aos alunos fora das sessões semanais, ainda não se encontrou uma solução. O objecto criado com o intuito de os alunos inserirem um cartão com as dúvidas que tinham para esclarecer raramente foi utilizado. Os alunos preferiram agendar com a professora uma hora fora das aulas, ou aproveitaram a sua presença online. Este aspecto levou a que a professora ficasse frequentemente longas horas, extra aulas, no SL a trabalhar com os alunos.

172

Capítulo VII: Aplicação do Método de Investigação

7.9. Plano do 2.º ciclo de investigação-acção
Face ao exposto, efectuaram-se as seguintes alterações nas variáveis: Projecto – considerando as dificuldades e reacções dos alunos ao facto de não terem um projecto sem execução visual, no projecto dos alunos Lab. II, incluiu-se uma componente visual, a qual consistiu na criação de um balcão com dois objectos, um receptor dos pedidos e outro que os executava. Sempre que um pedido fosse executado com êxito, o objecto que os executava devia, por exemplo, lançar uma bola para o ar, de modo a que os alunos tivessem um feedback visual da execução do seu programa. No projecto dos alunos de Proj. I, pretendeu-se analisar qual o efeito que surtiu nos alunos inserir-se uma componente não visual. Assim, incluiu-se mais uma funcionalidade “gestão de vendas”, para que os alunos passassem a focar-se em técnicas não visuais como a manipulação de estruturas de dados e strings; Apoio ao aluno durante as aulas – Face às dificuldades em os alunos se recordarem das causas dos erros cometidos, que foram anteriormente explicados pela professora, esta passou a escrever comentários no código destes, expondo as causas dos erros. De modo a que os alunos compreendessem o funcionamento das funções predefinidas da linguagem LSL, a professora traduziu para português as funções da linguagem mais usadas, que foram disponibilizadas no SIDE da UTAD e no Moodle da ESTG. As restantes variáveis mantiveram-se inalteradas.

7.10. Resultados e reflexões do 2.º ciclo
A estratégia adoptada neste ciclo, em relação ao projecto, não produziu os frutos desejados, nomeadamente, em relação aos alunos de Lab. II. As alterações introduzidas não foram suficientes para alterar o estado de espírito destes alunos, muito antes pelo contrário, o descontentamento foi-se agravando. Apesar de o melhor aluno do ano anterior, a pedido da professora, comparecer várias vezes nas aulas e fora delas para conversar com os colegas, tentar motivá-los e ajudá-los,

173

Capítulo VII: Aplicação do Método de Investigação também não conseguiu que estes alunos passassem a gostar do que estavam a fazer nem alterassem a sua posição. Contudo, a maioria conseguiu chegar ao fim das aulas com parte do projecto desenvolvido, embora houvesse um grupo que acabou por desistir e outro que não obteve aprovação à disciplina. Os restantes alunos conseguiram chegar ao fim com êxito, devendo-se principalmente ao tipo de acompanhamento que tiveram, à relação que se estabeleceu entre eles e a professora e à ajuda do colega, particularmente por constatarem que este estava a ser bemsucedido como programador no SL. Este aluno, depois de ter participado na fase preliminar, desenvolveu vários trabalhos no SL por brincadeira, acabando por vender alguns como produtos a verdadeiros utilizadores finais e inclusivamente a receber pedidos para criar outros. Por outro lado, é importante salientar que o entusiasmo e a motivação que os alunos de Proj. I vinham a demonstrar se mantiveram. Estes alunos alcançaram com sucesso os objectivos propostos no projecto, embora referissem que as alterações efectuadas tornaram o projecto um pouco mais difícil, como se constata pelos seus comentários, referidos no encontro final e no questionário: -“Gostei de aprender a programar no SL, e não percebo porque razão não se usa este ambiente nas outras aulas de programação.” (Ent., aluno B de Proj. I, dia 14/01/2008) -“Não conhecia o SL...mas fiquei entusiasmado com as potencialidades, vou continuar a desenvolver objectos.” (QuestF.) -“O projecto ficou mais complicado mas consegui implementá-lo na totalidade...” (Ent., aluno M de Proj. I, dia 14/01/2008) A solução adoptada para minimizar a reincidência dos erros de compilação e de execução, que consistiu na escrita de comentários no código dos alunos, explicando o porquê dos erros, ajudou-os a resolver por si próprios o problema e a relembrar o que não deviam fazer. Os alunos apreciaram o facto de a explicação ser efectuada por escrito no código, pois permitiu-lhes ler e reler o que tinha sido escrito, reflectir e esclarecer as dúvidas e assim consolidar conhecimentos. Dos comentários dos alunos, no último encontro mensal, salientamos: - “(...) na sala de aula ao ouvirmos a explicação sobre o erro fica-nos algo na cabeça do que foi dito, mas voltamos a cometer o mesmo na aula seguinte ou na mesma aula porque já não nos conseguimos lembrar do porquê; agora quando está escrito no local 174

Capítulo VII: Aplicação do Método de Investigação do erro, lemos e quando ocorre, voltamos a ler e assim conseguimos nos lembrar e resolver o problema quando acontece.” (Ent., aluno R de Proj. I, dia 14/01/2008) - “(...) a professora a explicar pelo chat na altura percebe-se mas quando voltamos a cometer o mesmo erro já não nos lembramos o porquê e também não procuramos o que foi dito no chat porque já lá está muita coisa escrita e é difícil de localizar; assim escrito no código é mais rápido de iremos ver.” (Ent., aluno C de Lab II, dia 11/01/2008) Deste modo, os erros de compilação diminuíram. Em relação aos erros de execução, a tradução para português das principais funções ajudou os alunos a compreenderem o seu funcionamento e como deviam ser utilizadas. Contudo, observou-se ao longo das aulas que os alunos apesar de terem feito no início o algoritmo do trabalho não o compreenderam na totalidade. Daí, que a cada passo que dessem na sua implementação ficavam sem saber o que fazer a seguir e como fazê-lo. Estes resultados induziram a investigadora na procura de outra solução para o ensino da programação neste ambiente, que despertasse nos alunos o interesse pela aprendizagem e, por outro lado, os impulsionasse na procura autónoma de soluções para o problema que estavam a solucionar. Naturalmente, surgiu a ideia de se utilizar a metodologia problem-based learning (PBL), uma vez que esta pode ser aplicada a pequenos grupos de tutoria. Para além deste aspecto, os estudos efectuados por De Grave (1998) e corroborados por Schmidt e Moust (2001) sugerem que a análise do problema ao ser efectuada por um grupo pequeno tem um efeito largamente positivo nos alunos, porque estes conseguem relembrar as soluções aplicadas, em oposição ao que sucede na análise individual dos problemas. Por outro lado, esta metodologia incentiva a discussão dos problemas pelo grupo. De Grave (1998) e Schmidt e Moust (2001) consideram que o trabalhar sobre o conhecimento que os alunos têm a priori e o facto de aprenderem uns com os outros, mesmo antes de novas informações serem adquiridas, é um poderoso meio para facilitar a compreensão da informação relevante sobre o problema em questão. Estes e outros aspectos, referidos no capítulo 3, levaram a investigadora a utilizar esta metodologia no ciclo seguinte. A problemática da comunicação ficou parcialmente resolvida com a metodologia usada. Com a utilização do canal privado para os alunos exporem as suas dúvidas

175

Capítulo VII: Aplicação do Método de Investigação individualmente à professora, conseguiu-se criar uma dinâmica de trabalho eficaz durante as aulas. A professora notava mais rapidamente os alunos que solicitavam ajuda, colocavam as suas dúvidas e dificuldades sem se sentirem embaraçados pela presença dos colegas, e sem perturbarem a aula, como se constata pelos seus comentários referidos nos questionários e nos encontros mensais: -“(...) assim, sentia-me à vontade para perguntar quantas vezes fossem necessárias, nas aulas os meus colegas acham que eu não percebo nada por estar constantemente a fazer perguntas.” (Ent., aluno M de Lab. II, 22/11/2007) -“Deste modo é mais é mais interessante... pois os colegas não criticam as nossas dúvidas.” (QuestInt.) Apesar de os alunos estarem a trabalhar em grupos de dois alunos, cada um deles tem um avatar que o representa no mundo virtual e com o qual trabalha em colaboração com o colega no desenvolvimento do projecto. Assim, a professora conseguiu aperceber-se das dificuldades de cada aluno e prestar o devido apoio. Desta forma, o objectivo de se empregar nas aulas uma pedagogia diferenciada foi alcançado.

7.10.1. Professora
Devido à natureza desta comunicação repartida, em que a professora teve de dividir o seu tempo e atenção por vários grupos e comentar por escrito o código desenvolvido, principalmente quando este tinha erros, o trabalho da professora tornou-se mais intenso e cansativo (a Figura 7.13 mostra o ecrã da professora durante uma aula). Por outro lado, tornou-se necessário minimizar o tempo entre perguntas / contactos de alunos e o feedback da professora, como referem estudos sobre a educação à distância, os quais mostram que um rápido feedback é importante quer na compreensão quer na motivação dos alunos para concluírem com sucesso o trabalho (Rekkedal, 1983, Kollock, 1998, Preece, 2000). Tal minimização permite manter a fluidez da comunicação, que se pode perder caso a professora tenha de escrever sempre todas as respostas, mesmo as mais comuns. Os alunos, nos questionários e nas conversas tidas mensalmente, aludiram que algumas vezes ficavam sem saber se a professora se encontrava ou não online, porque não recebiam nenhuma resposta. Assim, a professora fez-se munir de um conjunto de frases pré-

176

Capítulo VII: Aplicação do Método de Investigação preparadas relativas a situações frequentes, como por exemplo: “Já falo contigo, estou a tirar uma dúvida ao teu colega”, “vê o que falta nessa função”, “ a variável não foi declarada” ou “ falta iniciar a variável”.

Janela com o código de um aluno que a professora estava a analisar.

Janela com a comunicação, pelo canal privado, entre a professora e cada um dos alunos, identificados pelo nome do avatar.

Figura 7.13: Ilustra o ecrã da professora durante as aulas.

Em relação ao apoio prestado aos alunos fora das aulas, no decorrer deste ciclo, os alunos mantiveram a mesma forma de estar do ciclo anterior. Preferiram marcar uma hora com a professora ou sempre que a encontravam online aproveitavam para esclarecer dúvidas. Na Tabela 7.6 apresenta-se um resumo das observações deste ciclo de IA.

177

Capítulo VII: Aplicação do Método de Investigação

Participantes

Constatações Agrado por se comentar por escrito os erros cometidos, evitou a sua repetição; Dificuldades em perceber se a execução do projecto estava correcta;

Lab. II Dificuldades em saber o que faltava implementarem do projecto; Desagrado pelo projecto que tiveram de desenvolver e consequente desmotivação dos alunos. Agrado por se comentar por escrito os erros cometidos, evitou a sua Proj. I repetição; Agrado por aprenderem neste ambiente e pelo projecto que desenvolveram. Dificuldade em dar resposta em tempo útil a todas as solicitações dos alunos; Professora Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas semanais.

Tabela 7.6: Resumo das observações do 2.º ciclo de IA.

7.10.2. Questionários
No que respeita aos questionários realizados neste semestre, ao primeiro e ao segundo responderam a totalidade dos alunos (16) que participaram. No último questionário responderam 6 da ESTG e 6 de Lab. II. Da análise feita aos questionários e das reuniões tidas com os alunos, salientam-se os seguintes aspectos: Método de ensino usado – ambos os grupos de alunos consideraram que os exemplos dados para testarem e alterarem os ajudaram a compreender melhor alguns conceitos, como a troca de mensagens entre objectos. As funções e alguns exemplos práticos da linguagem LSL em português foram uma boa ajuda na compreensão das mesmas. Os alunos da ESTG referiram que eles próprios depois de pesquisaram na Internet exemplos de programas

178

Capítulo VII: Aplicação do Método de Investigação em LSL que testaram e adaptaram ao problema proposto, tornou-lhes mais fácil a compreensão e assimilação dos conceitos abordados. Os alunos também foram unânimes ao afirmar que durante as aulas tiveram toda a ajuda que necessitavam da parte da professora. Dois alunos de Lab. II inclusive salientaram que foi essa mesma ajuda e empenho que os fez chegar ao fim do projecto, uma vez que tinham vontade de desistir a par dos seus colegas. Projecto proposto – os alunos de Lab. II foram unânimes ao dizer que o enunciado era extenso, tinha muitas componentes interligadas e que não percebiam como é que as iam implementar. Referiram também que o enunciado era explícito, tendo sido capazes de conceber o algoritmo. No entanto, a codificação tornou-se mais complexa, pois os alunos não entenderam o que o programa estava a fazer, nem perceberam como interligar a informação. Mencionaram, ainda, que não compreendiam a razão de lhes ter sido atribuído um projecto em que grande parte do trabalho consistia na manipulação de dados, ao contrário dos seus colegas, que fizeram um projecto completamente diferente. Os alunos salientaram que este tipo de projecto não se adequava a este ambiente virtual e que na opinião deles foi uma perda de tempo, manifestando ter sido preferível realizá-lo no compilador normal como os seus colegas de turma. Nas respostas dadas notou-se a frustração destes alunos, pelo facto de se terem voluntariado na expectativa que também fossem criar objectos interessantes e terem sucesso como o seu colega. Tal não aconteceu, em parte por terem ficado bloqueados pelo enunciado do trabalho proposto, que não lhes despertou interesse. Como refere Schmidt e Moust (2001), o enunciado do problema deve estimular a discussão, este influencia o tempo e o interesse que o aluno mostra pelo assunto que está a estudar. Os mesmos autores salientam, ainda, que um “mau” enunciado prejudica a aprendizagem dos alunos. Os alunos de Proj. I consideraram que o enunciado do projecto era claro, embora as alterações efectuadas o tornassem um pouco mais difícil. Contudo, manifestaram o agrado pelo seu desenvolvimento e mencionaram ter sido interessante aprender a programar no SL. O enunciado e o SL motivaramnos na procura de soluções para implementarem o projecto na sua totalidade.

179

Capítulo VII: Aplicação do Método de Investigação Aprendizagem no SL – para a maioria dos alunos este foi o primeiro contacto que tiveram com o SL (apenas um dos alunos de Lab. II já tinha frequentado as aulas de Lab. I no SL). Os alunos de Lab. II referiram que não apreciaram a experiência e que não viram vantagem alguma em aprender neste ambiente; mesmo o aluno que já tinha frequentado aulas no SL referiu que não tinha gostado desta experiência devido ao enunciado do trabalho. Outros alunos exprimiram o seu desagrado em terem de aprender outra linguagem de programação além das que já estudavam noutras disciplinas. Não obstante o LSL tivesse semelhanças com a linguagem C, não ia ser usado, nem ao longo do curso nem quando fossem trabalhar. Opinião oposta expressaram os alunos do Proj. I, ao referir que gostaram muito do SL, apesar de não o conhecerem e ter sido a primeira vez que tinham ouvido falar e usado. Prospectaram grandes potencialidades na sua utilização futura, principalmente no desenvolvimento de aplicações para o ensino da música4, entre outras coisas. Em relação à aprendizagem da programação, consideraram a utilização do SL trazer mais vantagens relativamente aos ambientes que tinham sido usados anteriormente noutras disciplinas do curso, não entendendo a razão de não ter sido adoptado desde o início em detrimento doutro muito mais complexo (DevC++). Comentário geral sobre a actividade – os alunos não fizeram grandes comentários, salientando-se apenas um aluno de Lab. II que referiu não ter gostado e que estava arrependido de ter participado.

7.11. Plano do 3.º ciclo de investigação-acção
Este ciclo teve início no segundo semestre do ano lectivo 2007/2008. Voluntariaramse para participar nesta actividade 9 alunos da disciplina de Lab I da UTAD (ver na pag. 144 deste capítulo a caracterização geral destes alunos). Do que se observou e reflectiu no ciclo anterior, foram efectuadas as seguintes alterações:

Um dos alunos de Proj. I é professor de música e dá aulas privadas, no seu dia-a-dia sente que as pessoas gostariam de aprender musica mas não têm tempo para se deslocarem, de forma que gostaria de explorar a utilização do Second Life para dar aulas online, perspectivando um grande número de aderentes.

4

180

Capítulo VII: Aplicação do Método de Investigação Projecto – considerando o comportamento dos alunos face ao tipo de enunciado que desenvolveram no ciclo de IA anterior, nomeadamente o facto de os alunos com um projecto com uma componente fortemente visual apresentarem uma atitude positiva. Neste ciclo pretendeu-se propor um projecto (ver enunciado no anexo III) que fosse “rico” o suficiente, de forma a despertar nos alunos o interesse e motivação necessários para o quererem concluir e aprender. Assim, o enunciado proposto consistiu no desenvolvimento de uma pista para circulação de automóveis, com cruzamentos e semáforos. A pista deveria ser constituída por blocos independentes para que em qualquer momento fosse possível alterar o seu formato. Os automóveis deviam circular somente dentro da pista, devendo ser abastecidos com combustível, pois à medida que fossem circulando o combustível diminuía. Era da responsabilidade do condutor (neste caso o dono do veiculo) garantir que o veículo não parasse na pista por falta de combustível. Se tal sucedesse o dono teria de pagar uma coima por desleixo. Este projecto teve por objectivo que os alunos aprendessem a: o Manipular as estruturas de dados; o Trocar informação entre objectos; o Manipular estruturas de controlo; o Estruturar o código; o Desenvolver e aplicar funções, implementadas pelos alunos assim como as pré-definidas da linguagem. Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente ampliar a complexidade das técnicas a dominar por estes, nomeadamente, o lançamento de respostas a eventos. Comunicação – manteve-se a mesma metodologia usada nos dois últimos ciclos. Contudo, devido ao facto de a professora não conseguir dar uma resposta em tempo útil a todos os alunos, considerou-se necessário adicionar pequenas frases previamente escritas para as situações mais frequentes, de modo que a professora pudesse copiar e usar sempre que fossem necessárias, pretendendo-se desta forma diminuir o tempo de resposta e servir de auxílio no seu trabalho durante as aulas.

181

Capítulo VII: Aplicação do Método de Investigação Procedimento durante as aulas – prosseguiu-se com a mesma abordagem do ciclo anterior, escrevendo-se comentários no código dos alunos, sempre que se considerasse necessário, bem como a disponibilização em português das funções mais utilizadas. Devido às dificuldades sentidas pelos alunos em compreender como funciona o editor do SL, considerou-se ser mais adequado que esta explicação fosse dada presencialmente. Deste modo, a primeira aula na qual se explica o editor do SL foi presencial, na UTAD. Nas aulas seguintes utilizou-se a metodologia problem-based learning, aplicada a pequenos grupos de tutoria. Assim, os alunos formaram grupos de dois, para discutirem entre eles o projecto, de forma a apresentarem à professora, na 3ª semana, um relatório no qual expunham quais os problemas que estes continham e como pensavam resolvê-los. Na aula seguinte, a professora discutiu em conjunto com os alunos os pontos fortes e fracos de todas as soluções apresentadas. Doravante, os alunos colaboram entre si no desenvolvimento do projecto. O papel do professor deve ser o de incentivar os alunos a esclarecer as suas ideias, a procurar soluções para os problemas, a reflectir nas soluções apresentadas, a procurar incoerências e a encontrar soluções alternativas. O plano das aulas encontra-se no anexo II. Também se disponibilizaram objectos com exemplos de programas para os alunos exercitarem e adaptarem. A investigadora considerou pertinente, para esta investigação, a comparação dos resultados obtidos com os recolhidos por outro professor, que seguisse a mesma metodologia. Desta forma, pôde eliminar dos dados a variável “investigadora X” e colher dados independentes dela. Para tal, neste ciclo outro professor de programação da ESTG ficou responsável por leccionar as aulas de uma turma. Estas aulas decorreram em dias diferentes, embora tivesse sido utilizado o mesmo espaço no SL. Este estudo paralelo constituiu o 4.º ciclo da IA.

182

Capítulo VII: Aplicação do Método de Investigação

7.12. Resultados e reflexões do 3.º e 4.º ciclos de investigação-acção
A presença da professora-investigadora na primeira aula, em que se explicou e demonstrou como o editor do SL é utilizado, evitou ao longo do desenvolvimento do projecto as dúvidas e incertezas relatadas anteriormente na actividade preliminar e no 1.º ciclo de IA. Uma vez que o trabalho que os alunos tiveram que desenvolver exigia a criação de vários objectos, como um carro, blocos da pista, semáforos (ver exemplo de alguns objectos desenvolvidos na Figura 7.14), era importante que os alunos aprendessem a trabalhar com o editor, de maneira que construíssem os seus objectos rapidamente e de forma mais autónoma. Assim, tornou-se mais fácil aprender demonstrando como se faz, do que estar a descrever textualmente o mesmo processo, como, por exemplo, ligar objectos entre si ou criar réplicas de objectos.

Figura 7.14: Imagem de um dos trabalhos desenvolvidos.

Após os alunos terem entregue o algoritmo do trabalho, reuniram-se juntamente com a professora para conversarem sobre as soluções apresentadas para cada um dos 183

Capítulo VII: Aplicação do Método de Investigação problemas identificados (Figura 7.15). Durante esta reunião, para cada um dos problemas que os alunos identificaram, a professora expôs as soluções apresentadas que foram examinadas e discutidas pelo grupo. A professora pediu aos alunos que esclarecessem as suas ideias, encorajando-os a pensarem sobre o assunto, a procurarem incoerências e a encontrarem alternativas. Para algumas questões levantadas, por exemplo, “como é que os carros seguem a pista?”, o grupo não foi capaz de encontrar uma resposta satisfatória para o problema. Contudo, esta discussão ajudouos a perceber que o que tinham proposto não era válido, uma vez que se a pista fosse alterada o carro deveria ser capaz de segui-la. Assim, os alunos foram compreendendo a razão pela qual as soluções que apresentaram não estavam correctas, tendo sido um factor que os impulsionou a descobrirem novas soluções, o que vai ao encontro do que Schmidt e Moust (2001) defendem: “This perceived cleft induces an intrinsic motivation to learn.” À medida que as várias soluções iam sendo debatidas foi importante para o grupo ter presente o que tinha sido dito sobre o problema em discussão, de forma a evitar repetições ou a visualizar a possibilidade de combinar algumas das soluções apresentadas. A professora escreveu numa folha de texto, fora do SL, todas as soluções apresentadas e sempre que considerou oportuno, copiava essa informação para o chat para que os alunos relessem o que se discutiu.

Figura 7.15: Reunião geral sobre o projecto.

184

Capítulo VII: Aplicação do Método de Investigação Do ponto de vista da professora, esta troca de ideias ajudou os alunos a tomar consciência do trabalho que tinham de desenvolver e também dos conceitos a absorver. Os alunos corroboraram desta opinião como se constata dos seguintes comentários: -“(...) esta discussão ajudou-me a compreender o que eu tinha de errado no meu algoritmo e alguns aspectos que não tinha considerado...” (Ent., aluno A de Lab I, dia 23/05/2008) -“(...) foi bastante importante estarmos a discutir o projecto em conjunto pois pudemos esclarecer as nossas dúvidas.” (Reg., aluno W de Lab I, dia 30/05/2008) -“(...) foi a primeira vez que participei numa discussão assim, ajudou-me a compreender o que tinha de fazer e estudar...noutras disciplinas devia-se fazer o mesmo.” (Enc., Aluno B de Lab I, dia 23/05/2008) No decorrer das aulas observou-se isso mesmo, os alunos tinham a noção do que tinham que fazer, discutiam entre si qual seria a melhor solução e apresentavam à professora algumas soluções já implementadas, para esta testar e verificar a sua exequibilidade. A metodologia PBL ajudou os alunos a compreender os objectivos do projecto desde o início e a estruturar as suas ideias, evitando assim incoerências e equívocos ao longo do seu desenvolvimento. Estes resultados também são corroborados por O’Kelly e Gibson (2006). Os conceitos de programação foram sendo introduzidos à medida que os alunos necessitavam deles para fazer o trabalho. Com esta metodologia conseguiu-se criar uma dinâmica de trabalho, de colaboração e empenho entre os alunos na resolução dos problemas, o que não se tinha observado nos anteriores colegas (1.º e 2.º ciclos de IA). Este facto também foi confirmado pelos professores de outras disciplinas, ao constatarem “que os alunos passam o tempo a falar do trabalho que estão a desenvolver no SL”. No decorrer das aulas, observou-se uma diminuição dos pedidos de ajuda em relação aos erros de compilação à medida que estes iam ocorrendo, devido ao facto de a professora comentar no código, o porquê do erro, o que induziu os alunos a conseguirem corrigi-los, como se constata pelos seus comentários: -“Quando tinha um erro eu ia ver o que a professora me tinha escrito e assim consegui corrigir alguns (...).” (Reg., aluno W de Lab. I, dia 20/06/2008)

185

Capítulo VII: Aplicação do Método de Investigação -“(...) sempre que me surgia um erro de compilação, eu ia ver o que a professora me tinha escrito e conseguia corrigi-lo, assim foi mas fácil.” (Ent., aluno S de Lab. I, dia
27/06/2008)

Por outro lado, os erros de execução tornaram-se mais frequentes, não por não saberem usar as funções do SL, como se verificou nos ciclos anteriores, mas por implementarem soluções que não tinham em consideração todas as vertentes do problema. Um dos casos mais frequentes foi esquecerem-se de que a pista podia ter cruzamentos, pelo que o carro em vez de seguir em frente virava. Quando isto acontecia, os alunos tentavam de antemão resolver o problema sozinhos, só recorrendo à ajuda da professora após várias tentativas mal-sucedidas. Este comportamento vem ao encontro do que Williams e Noyes (2007) referem em relação ao papel da visualização no ensino: “Computer-based representation has the potential to play a vital role in the development of problem solving abilities.” Um outro factor a realçar, apesar de os alunos no espaço da sala estarem muito distanciados uns dos outros, devido à natureza do projecto que estavam a desenvolver, foi que a professora não teve de se deslocar constantemente para saber quais eram as suas dúvidas, nem para as esclarecer, o que ajudou a manter a dinâmica da aula. Tudo isto tornou-se possível devido ao processo de comunicação adoptado. A utilização do canal privado para tirar dúvidas, juntamente com o facto de a professora ter um conjunto de frases previamente preparadas das situações mais frequentes, evitou que os alunos estivessem sem resposta às suas questões ou quando não era possível, devido a complexidade da pergunta, era-lhes indicado que tinham que aguardar um pouco. Para a professora, esta metodologia usada durante as aulas aliviou a fadiga registada no ciclo antecedente, embora a preparação da aula levasse mais tempo, pois para além da preparação normal de cada aula, tinha de prever quais as dificuldades que iriam surgir em cada etapa do trabalho, para assim escrever pequenas frases para serem usadas. No que concerne ao acompanhamento dos alunos fora das aulas semanais, este grupo, tal como o antecessor, preferia enviar mensagens à professora através do SL ou marcar uma hora para tirar dúvidas. A professora sempre que queria deixar no espaço da aula algumas mensagens aos alunos, por exemplo, a relembrar o que

186

Capítulo VII: Aplicação do Método de Investigação deviam estudar para a aula seguinte, criou um objecto na forma de cogumelo com a mensagem escrita por cima (Figura 7.16).

Deixem a sala limpa Devem recolher os vossos objectos no fim da aula

Trabalho de casa Para a próxima aula devem completar, ler e guardar os dados dos fornecedores

Figura 7.16: Objectos com mensagens para os alunos relembrarem o que tinham de fazer.

As observações feitas directamente pela professora-investigadora durante o 3.º ciclo de IA foram coincidentes com as do professor que leccionou no SL (4.º ciclo de IA), sob a orientação da investigadora. Este professor fez o seguinte comentário em relação à metodologia adoptada: “Com esta metodologia os alunos têm consciência do que têm de desenvolver no projecto. A discussão em grupo foi importante para eles poderem esclarecer as suas dúvidas e interiorizarem o que estava errado e o porquê. Considero que é uma metodologia apropriada para os alunos aprenderem a programar.” Na Tabela 7.7 apresenta um resumo das observações destes dois ciclos de IA.

187

Capítulo VII: Aplicação do Método de Investigação

Participantes

Constatações Explicação presencial do editor de objectos do SL evitou constantes erros na sua utilização; Agrado por se comentar por escrito os erros cometidos, evitou a sua repetição;

Lab. I

Agrado pela metodologia utilizada, nomeadamente a discussão em grupo do projecto; Agrado pelo enunciado do projecto. Empenho dos alunos na resolução do projecto. Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas semanais.

Professora

Tabela 7.7: Resumo das observações do 3.º e 4.º ciclos de IA.

7.12.1. Questionários
Relativamente aos questionários efectuados nesta actividade, responderam a totalidade dos alunos que participaram aos três inquéritos. Nas respostas aos inquéritos efectuados e nas reuniões mensais os alunos mencionaram: Método de ensino usado – a discussão em grupo sobre o trabalho foi muito importante porque ajudou a ver o que estava errado no algoritmo, a compreender melhor o enunciado e a ter uma visão global do mesmo. Evitou que tivessem implementado o trabalho de forma errada, tal como acontece muitas vezes em outros trabalhos, em que só se apercebem do erro depois do trabalho ter sido entregue. Projecto proposto – os alunos consideraram o projecto aliciante, gostaram de o implementar, embora fosse difícil porque tinha muitas componentes a interagir entre si. A generalidade dos alunos considerou que a parte mais

188

Capítulo VII: Aplicação do Método de Investigação difícil do projecto consistiu em colocar os carros a circular na pista e a implementar o sistema de coimas para os donos. Aprendizagem no SL – na generalidade, os alunos manifestaram o seu contentamento em aprender num ambiente aliciante, tal como o SL. Outros consideraram que, por exemplo, para aprender programação avançada, o SL não é apropriado. Comentário geral sobre actividade – só quatro alunos fizeram um comentário, referindo que gostaram da actividade e da forma como decorreu.

7.13. Conclusão do projecto de investigação
Com a maioria dos problemas resolvidos em relação ao processo de ensino e aprendizagem da programação no SL, a investigadora deu por terminado este processo. Ficou por resolver a questão do acompanhamento dos alunos fora das aulas semanais. Uma possível solução para este problema seria a integração do SL com um sistema de gestão da aprendizagem, como proposto por Antunes et al. (2008), na medida em que este acompanha e grava o trabalho autónomo do alunos para posteriormente o professor poder observar. Assim, o professor tem a possibilidade de perceber o que o aluno fez, de forma a poder ajudá-lo melhor. Finda a apresentação do processo de investigação seguido, no próximo capítulo fazse a reflexão e discussão dos resultados obtidos e expõe-se uma proposta de modelo para o ensino e aprendizagem da programação num ambiente virtual com características semelhantes ao Second Life.

189

8. Análise dos resultados
No presente capítulo faz-se uma análise dos resultados da investigação-acção, relacionando-os com a literatura científica existente.

Capítulo VIII: Análise dos Resultados

191

Capítulo VIII: Análise dos Resultados

8.1. Análise e discussão dos resultados
Como já foi referido anteriormente, o objectivo desta tese foi analisar como os mundos virtuais, com características semelhantes ao SL, poderiam ser utilizados como plataforma para o ensino e aprendizagem da programação. No capítulo VII descreveu-se a actividade preliminar e a subsequente IA que permitiu uma melhor compreensão do problema, e a obtenção do conhecimento que possibilitou gerar uma proposta de um modelo para o ensino / aprendizagem da programação nos mundos virtuais. Os resultados deste estudo relevam que o SL apresenta características que suportam uma aprendizagem construtivista da programação, mas tem restrições que podem deteriorar o seu uso pragmático. O foco desta investigação centra-se em descortinar como usar o mundo virtual no ensino da programação e não na sua eficácia relativamente aos resultados obtidos pelos alunos. Por conseguinte, os resultados desta investigação não pretendem ser uma receita de como os mundos virtuais devem ser usados, mas sim servir de guia e ponto de partida a futuras investigações. Ao longo deste estudo foram identificados os seguintes itens considerados fundamentais na autenticação do SL como plataforma para o ensino / aprendizagem da programação: métodos de comunicação; projecto; processo de aprendizagem; processo de ensino. De seguida, faz-se uma análise de cada um destes elementos, relacionando-os com a literatura científica existente.

8.1.1.

Comunicação

Na educação online, os elementos fundamentais para o êxito dos alunos são as interacções: aluno-aluno, professor-aluno(s) e a colaboração na aprendizagem resultante dessas interacções (Palloff e Pratt, 2005). Assim, pode-se considerar que os 192

Capítulo VIII: Análise dos Resultados termos colaboração e interacção são palavras-chave sobre as quais se deve reflectir quando se pretende promover a construção de conhecimento apoiada por ambientes de aprendizagem online (Dias, 2004; Miranda, Morais e Dias, 2007). A palavra comunicação deriva do latim communicare, tal como “comungar”, significando “dividir/partilhar alguma coisa com alguém”. Desde os primórdios que a comunicação é um instrumento de integração, instrução, troca mútua e desenvolvimento entre pessoas. Por isso, uma boa comunicação é essencial para qualquer profissional. No contexto educacional, a comunicação apresenta-se como elemento chave no planeamento, execução e avaliação de todo o processo ensino / aprendizagem, isto é, a gestão da comunicação é parte integrante da gestão de projectos educacionais, principalmente na modalidade à distância (Reis, 2008). A primeira abordagem usada nesta investigação, referente à comunicação, que se limitou a utilizar o canal público durante as aulas, rapidamente foi abandonada. Conforme foi descrito no capítulo anterior, na secção7.6, constatou-se por parte de todos os intervenientes (professora e alunos), a existência de muito ruído, nomeadamente os alunos a trocar ideias entre si e os objectos a enviar mensagens para o seu proprietário. Por estes motivos, nem sempre se conseguiu estabelecer uma boa comunicação entre os vários participantes. Era difícil aos alunos seguir a linha de raciocínio da professora e, por outro lado, frequentemente, a professora não se apercebia dos seus pedidos de ajuda. Após a constatação de que assim seria difícil utilizar o SL, optou-se por realizar a análise fazendo-se a seguinte atribuição de funções dos canais público e privado: o canal público passou a ser utilizado apenas para a professora se dirigir a todos os alunos em geral. Por exemplo, para fazer uma chamada de atenção ou explicar algum conceito; o canal privado passou a ser usado exclusivamente para tirar dúvidas aos alunos individualmente. Nos objectos, usou-se um canal privado específico direccionado exclusivamente ao seu proprietário. Deste modo, eliminou-se a perturbação sentida nas aulas e obteve-se um melhor relacionamento professora-aluno. O SL, pelo facto de ser um meio informal, directo e rápido, cria condições para os alunos não se sentirem embaraçados pela presença dos colegas e, mais

193

Capítulo VIII: Análise dos Resultados extrovertidamente poderem colocar questões e interagir, isto é, concordarem, discordarem, exporem e tirarem dúvidas sempre que necessitarem. Como a troca de opiniões é intensa, esta forma de comunicação com os ajustes efectuados, principalmente no que se refere ao facto de a professora ter um conjunto de frases pré–escritas, veio a ser um factor precioso na utilização do SL. À professora é dada a vantagem de melhor gestão da aula através da colocação em discussão pública apenas das questões mais pertinentes. Aos alunos possibilitou um meio “seguro” de colocarem as suas dúvidas. Por exemplo, os alunos que reflectem maior timidez numa sala de aula tradicional manifestaram sentirem-se mais desinibidos neste ambiente, factor que leva a diferentes atitudes e modos de participação, tal como Miranda et al. (2007) também constaram no estudo que efectuaram, e se observa nos seguintes comentários recolhidos nas conversas mensais: - “Neste ambiente como conversava directamente com a professora sem que os colegas lessem o que escrevia senti-me muito mais à vontade que na sala de aula, pois nesta, mesmo que tenha dúvidas, evito falar. Gostei muito...” (Ent., aluno S de LabI do 3.º Ciclo de IA) - “Aqui, neste ambiente, senti-me completamente à vontade para falar e expor as minhas dúvidas. Na sala de aula é diferente porque os meus colegas podem rir-se de mim.” (Ent., aluno 2 de Lab. I, dia 31/05 /2007) A maioria das opiniões recolhidas permitiu à investigadora concluir que é importante estabelecer uma comunicação privada entre o professor e os alunos, principalmente quando se refere ao esclarecimento de dúvidas, uma vez que os alunos podem desenvolver um sentimento de confiança e segurança dentro do mundo virtual. Na ausência desta confiança, os alunos sentem-se desconfortáveis e constrangidos em colocar as suas dúvidas e comentários (Anderson, 2004). Por outro lado, o facto de a comunicação se efectuar em tempo real permite tornar a realização das actividades de aprendizagem num processo activo e dinâmico. Um aspecto importante que mantém este dinamismo está relacionado com a rapidez do feedback que os alunos recebem da professora. A literatura científica relacionada com o ensino à distância refere que um rápido feedback é importante para os alunos não se sentirem sozinhos, sendo também um factor relevante para a sua motivação e compreensão dos assuntos que estão a estudar (Rekkedal, 1983; Bender, 2003; Haythornthwaite, 2006). Neste estudo, esta questão também se colocou, uma vez que

194

Capítulo VIII: Análise dos Resultados nem sempre a professora conseguia dar uma resposta suficientemente rápida a todas as solicitações que recebia. Consequentemente, os alunos dispersavam-se e começavam a conversar, como se pode observar pelos seguintes comentários referidos nas conversas mensais: - “Como a professora não dizia nada, eu começava a conversar com o meu colega.” (Ent., aluno 2 de Lab. I, dia 31/05 /2007) - “(...) às vezes, acontecia que a professora demorava algum tempo a dar uma resposta e como não sabia se a rede tinha ido abaixo, perguntava através do canal público se a professora ainda ali estava.” (Ent., aluno 2 de Lab. II, dia 3/07 /2007) Como advoga Sobral (2008): “Se um aluno colocar uma questão, houver uma discussão ou alguma alteração ao funcionamento “normal”, o professor tem que ter uma resposta rápida. O professor tem que estar presente e os alunos necessitam do sinal de acompanhamento caso contrário a comunidade perderá a referência e sentir-se-á perdida”.(p. 23) A solução encontrada pela investigadora consistiu em construir uma série de frases já pré-definidas e preparadas, para poder copiar e colar no chat. Assim, sempre que alguém lhe colocava uma questão e não podia responder imediatamente, recorria a uma dessas frases, como por exemplo, “ tem de esperar um minuto, estou a falar com o seu colega” ou para as situações de erro mais frequentes: “falta iniciar a variável”. De um modo geral, o sentimento que os alunos expressaram em relação à comunicação foi de agrado, como se verifica nas seguintes expressões retiradas dos questionários e das conversas mensais: “gostei muito”, “...senti-me completamente à vontade ...”.

8.1.2. Projecto
A natureza do problema proposto aos alunos desempenha um papel importante na sua aprendizagem. Na literatura, este conceito tem sido referido como um dos principais factores para estimular e motivar os alunos na aprendizagem, e um impulsionador da auto-aprendizagem orientada (self-directed learning) (Barrows, 1985; Guzdial et al., 1996; Robbert, 2000; Schmidt e Moust, 2001; Duch, 2001; O’Kelly e Gibson, 2006; Boyer, Langevin e Gaspar, 2008).

195

Capítulo VIII: Análise dos Resultados Neste estudo, o projecto foi o ponto de partida para o processo de aprendizagem da programação. No decorrer do estudo foram utilizados dois tipos de projectos com características bastante diferenciadas: Visual – os alunos aprendem a programar através de interacções “físicas”. Estes projectos envolvem a construção de vários objectos tridimensionais, como um robot ou um carro, e a implementação de vários programas que simula o comportamento que esses objectos deveriam ter. Não visual – os alunos aprendem a programar, apenas no processamento de informação textual. Nestes projectos, a comunicação com os objectos é feita textualmente, os objectos recebem ordens textuais dos avatares e respondem do mesmo modo ou guardam a informação em listas de strings. No decorrer desta investigação, foram observados e registados diferentes tipos de comportamento nos alunos, em relação ao enunciado do projecto. No projecto visual, alguns alunos não se empenharam, como era de esperar, por concluir com êxito o enunciado proposto, como foi o caso dos alunos de Lab. I da actividade preliminar. Apesar de considerarem o projecto acessível e interessante não se empenharam o suficiente, como se pode notar nos seguintes comentários referidos nos questionários: -“(...) achei o projecto bastante engraçado e fácil. Gostei de ver o comportamento do meu cão, que nem sempre obedecia ao seu dono, mas não dediquei muito tempo a fazê-lo, pois tinha outras disciplinas para fazer.” (Ent., aluno 2 de Lab. I, dia 31/05 /2007) -“(...) gostei do projecto, mas não dediquei muito tempo para o desenvolver , porque tinha outras disciplinas para fazer. Como achei o projecto fácil pensei que no fim o fazia rapidamente, mas depois não tive tempo para o acabar.” Ent., aluno 1 de Lab I, dia 12/07/2007) Por outro lado, um outro grupo de alunos de Lab. I (3.º e 4.º ciclos) e da ESTG, com um projecto visual mais complexo que exigia, também, a manipulação de dados não visuais, apresentaram um comportamento oposto em relação aos seus outros colegas de Lab. I. Gostaram do projecto e empenharam-se na sua concretização. O mesmo tipo de comportamento foi constatado relativamente aos alunos de Lab. III com um projecto visual, no entanto com um grau de dificuldade superior. Este tipo de

196

Capítulo VIII: Análise dos Resultados comportamento observado vem ao encontro do que Allan e Tomlinson (2002) referem: “É necessário que as tarefas tenham o grau adequado de dificuldade para serem e permanecerem motivadoras: as tarefas que são demasiado fáceis tornam-se aborrecidas e consequentemente os alunos não se empenham na sua resolução; as tarefas que são demasiado difíceis provocam frustração.” Os alunos que aprenderam a programar, usando apenas um projecto não visual, evidenciaram um comportamento de frustração e desinteresse pelo que estavam a aprender. Os alunos não aprenderam adequadamente e “sufocaram” por não compreenderem a razão de terem que desenvolver um projecto com estas características neste ambiente, como é visível nos seus comentários mencionados nas conversas mensais e durante as aulas: - “(...) Não gosto deste projecto, não percebo o que tenho de fazer e como? Isto é complicado e difícil. Não entendo porque tenho de fazer este projecto, os nossos colegas não fizeram nada disto (...)”.(Ent., aluno S de Lab II, dia 25/10/2007) -“(...) Isto não tem nada de engraçado… é só texto, se soubesse que ia ser assim não tinha feito este trabalho.” (Ent., aluno J de Lab. II, 22/11/2007) Uma das justificações encontradas para este tipo de comportamento foi dada por Howard (1994) e Jensen (1998) que, nos estudos que efectuaram sobre a actividade cerebral, explicam que a aprendizagem ocorre quando o aluno não se sente aborrecido, frustrado, ansioso e quando não é sobrestimado, nem subestimado. Por outro lado, segundo Pereira (2007), o conhecimento é uma relação activa entre o aprendiz e o ambiente, e a aprendizagem ocorre quando o estudante se envolve activamente com o contexto instrucional, que deve ser complexo e realista. Este autor refere ainda que o aprendiz deve ser exposto à situação o mais realisticamente possível, sem exclusão das complexidades do contexto. Estes alunos beneficiaram do ambiente do SL apenas para reforçar o contexto da aprendizagem e não como uma fonte visual de feedback (Prensky 2001; Roubidoux et al., 2002) na execução dos programas, como sucedeu com os seus colegas. Não é habitual para um aluno assumir que o seu script está correcto apenas porque este aparentemente mostra dados textuais certos. Com um projecto visual, os alunos têm um feedback óbvio quanto à exactidão do seu projecto, basta olhar para o comportamento do seu objecto; por exemplo, o carro deve seguir a pista, se não o 197

Capítulo VIII: Análise dos Resultados fizer está errado. O comportamento errado do carro ou do robô era motivo de uma maior preocupação por parte dos alunos, impulsionando-os a procurarem uma solução para o problema. A professora para motivar os alunos introduziu, a meio do desenvolvimento do projecto, uma componente visual. Contudo, esta medida não foi suficiente para alterar o comportamento dos alunos. Como Duch (2001) refere, problemas eficazes devem despertar nos alunos o interesse e a motivação para investigarem e procurarem compreender os conceitos que estão a ser introduzidos. Um outro ponto a realçar deste estudo é que, quando foi apresentado aos alunos um projecto com um misto das duas componentes visuais e não visuais, ou seja, um enunciado com uma grande componente visual juntamente com manipulação de dados não visuais, a reacção destes foi idêntica aos alunos com projecto visual, como foi o caso dos alunos de Lab. I (3.º e 4.º ciclos) e da ESTG. Estes resultados vêm ao encontro do que se refere na literatura sobre os benefícios da visualização, como é o caso de certos aspectos da resolução de problemas nos alunos inexperientes, uma vez que os ajuda a terem um melhor entendimento do problema, bem como o nível de envolvimento e motivação que eles desenvolvem ao construírem e representarem as suas próprias visualizações (Naps, 2005; van Dam, 2005; Kiili, 2005; Schweitzer e Brown, 2009; Myller et al., 2009). Aprender exige tanto brincar com as ideias como a dureza de redefinir e reformular ideias sendo ambas as partes complementares e necessárias para a aprendizagem (Barret, 2005). A diversão “transpirada” é o que Papert (1996) designou de “hard fun”; in that it is both challenging and interesting, and this implies “hard”.

8.1.3. Processo de aprendizagem
8.1.3.1. Dificuldades dos alunos Na aprendizagem, em geral, o erro é necessário para o aperfeiçoamento do processo evolutivo do pensamento (Pereira, 2007). Em particular, na aprendizagem da programação um aspecto importante é a reacção dos alunos aos erros de compilação e execução (Esteves e Mendes, 2004, Lahtinen et al., 2005), que são inevitáveis no processo de aprendizagem.

198

Capítulo VIII: Análise dos Resultados O comportamento registado nos alunos face aos erros não difere muito do que Jenkins (2002) verificou no estudo que efectuou. Neste estudo, alguns alunos não eram capazes de avançar sem a ajuda da professora, outros que tentavam resolver o problema por tentativa e erro sem reflectirem primeiro no que estavam a fazer, e outros, embora em menor número, pensavam e investigavam o porquê do erro. Como acontece na generalidade dos compiladores, as mensagem de erro que estes geram não são esclarecedoras sobre o porquê do erro e onde ele ocorreu. O compilador do LSL não foge à regra, como se pode observar nos exemplos ilustrados na Figura 8.1. À falta de uma chaveta ou de um ponto-e-vírgula, a mensagem gerada apenas indica que existe um erro de sintaxe na linha de código seguinte onde este falta. Para os alunos inexperientes torna-se difícil de compreender o que sucedeu.

Figura 8.1: Exemplos das mensagens de erro geradas pelo compilador de LSL. Na imagem da esquerda falta no código uma chaveta { na linha 11 e na da direita falta um ponto-e-vírgula ; na linha 12.

A metodologia adoptada pela professora, no que se refere aos erros de compilação, foi a de escrever comentários no código desenvolvido pelos alunos e explicar a razão pela qual o erro acorreu. Estes comentários foram de extrema importância, principalmente para os alunos inexperientes, na medida em que tinham sempre presente uma explicação da razão de ser do erro, e isto ajudou-os a relembrarem-se

199

Capítulo VIII: Análise dos Resultados do porquê e de como podiam evitá-lo e corrigi-lo. Miranda (2005), no estudo que efectuou sobre a educação online, também corrobora este aspecto de existir uma explicação escrita que pode ser consultada sempre que necessário, ajudando os alunos a reflectirem e a relembrarem-se dos problemas. Relativamente aos erros de execução, a primeira dificuldade observada relacionou-se com a utilização das funções do LSL. Após várias iterações, verificou-se que a principal dificuldade dos alunos residia na incompreensão da língua inglesa, pelo que foi necessário traduzir para português as funções mais utilizadas. Outra dificuldade que resultou em vários erros de execução, refere-se à compreensão do enunciado do problema e consequentemente ao desenvolvimento do respectivo algoritmo. A maioria dos alunos, apesar de ter feito o algoritmo antes de implementar o projecto, não compreendeu o enunciado. Esta dificuldade complicou a estruturação do seu pensamento. O facto de não perceberem o que tinham que fazer, levou-os a perguntar constantemente “o que é para fazer a seguir?”, “o que me falta implementar?”. A adopção da metodologia PBL veio minorar este problema. Com esta metodologia os alunos desenvolveram o algoritmo e após a sua entrega à professora debateram todos em grupo as soluções apresentadas. Este esforço colaborativo, onde os alunos se entre ajudam na clarificação das suas questões, é o ponto central desta metodologia (O'Kelly e Gibson, 2006). Como referem Schmidt e Moust (2001), o conhecimento de um participante vai activar o conhecimento inacessível de outro. Assim, o conhecimento colectivo torna-se acessível, os aprendizes começam por trabalhar sobre o que sabem e a estabelecer pontes entre o seu conhecimento e o problema em questão, porque alunos diferentes tendem a saber coisas diferentes ou a pensar de outra maneira. Uma construção teórica torna-se um efeito colaborativo que pode trazer novas luzes que não estão presentes nos participantes individualmente antes de se começar a análise do problema em grupo (ibid.). Os alunos que participaram neste estudo vieram a comprovar estes mesmos aspectos, como se pode observar pelos comentários que fizeram nos encontros mensais e no questionário: - “(...) esta discussão em grupo foi muito útil, pois permitiu-me ver o que não tínha feito no meu algoritmo e, por outro lado, verifiquei que tínha algumas coisas erradas.” (Reg., aluno W de Lab I, dia 20/06/2008)

200

Capítulo VIII: Análise dos Resultados - “Gostaria que em outras disciplinas se fizesse o mesmo, pois assim sabía o que estava errado antes de o implementar e também nos ajudou a compreender melhor o enunciado que parecia ser mais fácil do que realmente é.” (Ent., aluno S de Lab I,
dia 27/06/2008)

Diversos autores argumentam que o diálogo e a discussão promovem a colaboração e consequentemente apoiam a negociação social da aprendizagem (Vygotsky, 1978; Lave e Wenger, 1991; Jonassen, 1999; Bourne, Harris e Mayadas, 2005). O acrescentar de novas ideias para a discussão sem excluir ideias anteriores, salientando que as conversações encorajam a diversidade, cria um ambiente fértil no qual novos níveis de compreensão podem ser desenvolvidos, conduz a uma mudança conjunta dos intervenientes e à criação de um conjunto rico de informação que sustenta o ambiente no qual as experiências são emergentes (Bourne, Harris e Mayadas, 2005). Por outro lado, as discussões online constituem uma oportunidade para os professores orientarem experiências de aprendizagem, de acordo com o paradigma de aprendizagem social e colaborativa, nas quais os alunos podem partilhar perspectivas e as suas próprias experiências, construindo conhecimento através dos significados partilhados (Tan, Wang, e Xiao, 2010). Neste sentido, Larkin-Hein (2001) salienta que as discussões funcionam como um veículo adicional de ensino e de aprendizagem, que facilita aos alunos a aquisição de capacidades de pensamento de nível mais elevado e os torna mais competentes para transferirem e utilizarem a informação em novas situações. Com esta abordagem, os alunos conseguiram compreender melhor o projecto proposto. As dúvidas que os seus colegas tiveram, “o que ainda me falta fazer?”, não se registaram ao longo do decorrer da experiência. Para esta metodologia ser eficaz é necessário também que o enunciado do problema, como foi referido na secção anterior, desperte nos alunos o interesse e a motivação pela aprendizagem dos conceitos que estão a ser introduzidos. Como referem O’Kelly e Gibson (2006), a utilização da metodologia PBL favorece uma compreensão profunda dos conceitos em vez de uma aprendizagem superficial, porque são os alunos que estão activamente a desenvolver. Um outro aspecto positivo salientado pela generalidade dos alunos que participaram nos vários ciclos deste estudo, quer os de nível mais avançado, quer os elementares, refere-se aos pequenos exemplos que a professora empregou durante as aulas para

201

Capítulo VIII: Análise dos Resultados explicar os conceitos, como se pode constatar pelos seguintes comentários dos alunos referidos nos encontros mensais e nos questionários: -“(...)assim com estes exemplos é mais fácil perceber para que servem as estruturas de repetição e como funcionam.” (Ent., aluno R de Proj. I, dia 28/11/2007) -“(...)com os exemplos percebemos melhor e podemos alterá-los e adaptá-los ao nosso projecto.” (Ent., aluno 1 de Lab I, dia 12/07/2007); -“(...)os exemplos são uma grande ajuda, já andámos na net à procura de mais, assim é mais fácil de ver como isto funciona.” (Ent., aluno S de Lab II, dia 5/06/2007) Uma das dificuldades relatadas na literatura é que os alunos muitas vezes compreendem a sintaxe e a semântica da linguagem ou de partes da linguagem, como por exemplo as estruturas de decisão, mas não sabem como aplicá-la nem para que serve (Perkins et al., 1988; Jenkins, 2002; Gomes et al., 2008). Deste modo, conseguiuse que os alunos compreendessem como e quando se usam determinados conceitos. Um dos exemplos mais apreciados foi o das estruturas de decisão, conforme as ordens dadas à pirâmide, esta ora subia, descia ou rodava. Por outro lado, ajudou-os a perceber também como funcionam os canais de comunicação (ilustrada na Figura 8.2 e o respectivo código na Figura 8.3).

202

Capítulo VIII: Análise dos Resultados

Figura 8.2: Exemplo da pirâmide, sobre estruturas de decisão e canal de comunicação, para os alunos testarem e alterarem.

203

Capítulo VIII: Análise dos Resultados
default{ state_entry(){ //escuta o que se passa no canal zero //quando ouve o dono do objecto executa o listen llListen(0,"",llGetOwner(),""); }//fim do state_entry //-------Executa as ordens enviadas pelo dono do objecto-------//-------que podem ser: subir; descer;rodar;stop;--------------//-------o stop- faz com que o objecto pare de rodar-----------listen(integer channel, string name, key id, string msg){ if(msg == "subir") llSetPos(llGetPos() + <0,0,2>); else if(msg == "descer") llSetPos(llGetPos() + <0,0,-2>); else if(msg == "rodar") llTargetOmega( < 0, 1, 1 >, .2 * PI, 1.0 ); else if(msg =="stop") llTargetOmega(<0,0,0>, 0,0); }//fim do listen }//fim do script

Figura 8.3: Código em LSL, que cada uma das pirâmides executa.

8.1.3.2. Motivação dos alunos em participar neste projecto Uma das questões colocadas no inquérito efectuado no início das actividades, referiase ao motivo que levou os alunos a quererem participar nesta experiência. Os que participaram na actividade preliminar, maioritariamente mencionaram que foi por “curiosidade em experimentar o SL”, outros referiram que queriam “aprender a programar no SL”, pois já conheciam o ambiente. Curiosamente, alguns dos alunos que já tinham aprendido a programar anteriormente mencionaram que: -“Para experimentar uma nova forma de aprender a programar porque já tive C e não gostei, como estou em informática pode ser que passe a gostar.” (Reg., aluno W de Lab I, dia 20/06/2008) -“Para ver se consigo aprender a programar, tentei fazer a disciplina de Metodologias de programação I e não consegui. Os meus colegas dizem que aqui é mais interessante e fácil.” (Ent., aluno S de Lab. II, dia 25/10/2007)

204

Capítulo VIII: Análise dos Resultados -“Pode ser que desta forma consiga fazer está disciplina(Lab. I) porque estou no 3º ano e quero acabar o curso.” (Reg., aluno B de Lab. II, dia 29/10/2007) -“Eu não gosto de programar, mas gosto de jogar e como o SL é um mundo virtual e eu gosto deste tipo de ambientes, vim experimentar. Os meus colegas dizem que gostaram.” (Ent., aluno S de Lab II, dia 25/10/2007) Estes comentários revelam alguma insatisfação pela forma como os alunos aprendem a programar, tal como Lethbridge (2007) refere: “The number of students in computing disciplines have decreased in U.S. since 2000, and points out some reasons for that such as: young people are so immersed in computers that they do not see the excitement to them any more and the stereotype of the ‘nerd’ coding all night with no social contact, leave the students avoid these areas.” No SL observou-se o oposto, os alunos não estão sem contacto social quando programam e gostam de o fazer, na generalidade. Duas situações tiveram um impacto positivo nos alunos: um dos alunos recebeu uma proposta de outro avatar no SL para comprar um dos seus objectos, que tinha programado; outro aluno recebeu uma proposta de trabalho profissional para desenvolver programas numa empresa que presta serviços no SL.

8.1.3.3. Avaliação feita pelos alunos ao SL Para além dos aspectos mencionados anteriormente sobre a opinião dos alunos em aprenderem no SL e as diferentes metodologias adoptadas ao longo desta investigação, salienta-se nesta secção outros pontos tidos como importantes por parte dos alunos. Das várias opiniões manifestadas pelos alunos, constatou-se que uma das características que foi muito apreciada no SL refere-se ao facto de neste ambiente poderem colaborar com o colega de grupo no desenvolvimento do trabalho, sem terem de partilhar o mesmo espaço físico. Uma vez que o SL permite partilhar o código, os alunos mesmo estando fisicamente distantes, conseguem trabalhar em conjunto, como eles próprios referiram nos encontros mensais: -“Aqui já não tenho o problema de ter que estar junto do meu colega para desenvolver o projecto, principalmente ao fim-de-semana. Como eu sou de Pombal e costumo ir a casa aos fins-de-semana, encontro-me com o meu colega no SL, usamos phones e estamos a conversar e a desenvolver o projecto os dois, partilhamos o código e assim

205

Capítulo VIII: Análise dos Resultados observamos o que um e outro está a fazer.” (Ent., aluno W de Lab I, dia
27/06/2008)

-“(...) um dos problemas que eu tinha em fazer trabalho de grupo era ter tempo para estar com o meu colega, como trabalho em part-time era difícil. Assim, à noite encontramo-nos no SL, cada um em sua casa, e trabalhamos no projecto durante a noite.” (Ent., aluno D de Proj. I, dia 28/11/2007) Para além deste aspecto, do SL permitir uma colaboração síncrona, também, foi destacado como positivo o facto de poderem deixar ficar no SL o seu trabalho e enviar para o colega uma mensagem, via canal privado, sobre o que este devia fazer: -“(…) algumas vezes o meu colega não podia estar no SL a trabalhar comigo e eu deixava-lhe recados sobre o que ele tinha de fazer.” (Ent., aluno A de Lab I, dia
27/06/2008)

O feedback instantâneo e um ambiente livre de risco é um convite à exploração, experimentação e estimulação da curiosidade e da aprendizagem por descoberta (Gee, 2003; Mitchell e Savill-Smith, 2004, Wagner, 2008; Salmon, 2009). A importância do feedback visual instantâneo como forma de debug foi um dos aspectos considerados mais relevantes pelos alunos. Para uma grande parte, o facto de poderem olhar para o objecto desenvolvido e observarem o seu comportamento, como por exemplo, se o cão segue o seu dono, sempre que este lhe dava essa ordem e parava quando recebia a mensagem “stop”, foi um dos aspectos mais apreciados neste mundo virtual. Por outro lado, consideraram importante poderem programar objectos virtuais realistas como o carro, o comboio e o cão, sem terem medo de estragar componentes como aconteceria se estivessem a mexer num robot real, como se certifica nas seguintes opiniões referidas nos encontros mensais: -“Gostei muito, principalmente de poder olhar para o meu boneco e ver como este se comportava. Nos outros ambientes de programação é mais difícil de detectar os erros de execução... aqui basta olhar.” (Ent., aluno C de Proj. I, dia 28/11/2007) -“(...) considero este ambiente muito útil para quem está a aprender a programar, aqui percebe-se para que serve a programação e como funciona. Os erros de execução são muito simples de detectar basta olhar por exemplo no meu caso, o carro nunca parava porque não ficava sem gasolina e foi muito fácil de verificar que o programa não estava correcto.” (Ent., aluno 5 de Lab. I, dia 12/07/2007)

206

Capítulo VIII: Análise dos Resultados -“(...) aqui não existe o medo de se poder estragar um objecto, como acontece algumas vezes no laboratório de redes...sinto-me livre de testar e experimentar à vontade.”
(Ent., aluno S de Lab I, dia 27/06/2008)

Estes aspectos corroboram as conclusões feitas por Dede (1995) sobre os benefícios dos mundos virtuais: “…offer many benefits such as provisions for experimentation without real world repercussions, opportunities to ‘‘learn by doing”…’, Salientaram, também, a oportunidade que este ambiente lhes proporcionou de conhecerem e trocarem ideias com pessoas de outros países, com as quais puderam falar do trabalho que andavam a desenvolver e, inclusive, alguns lhes pediam ajuda para resolver problemas nos scripts que estavam a implementar, como se constata nos seus comentários das reuniões mensais: -“Conheci um holandês que me pediu ajuda para resolver um erro que tinha no seu script, mas eu não o consegui ajudar.” (Ent., aluno 3 de Lab. I, dia 12/7/2007) -“(...) estive a falar com um americano sobre o meu trabalho e disse-lhe que tinha aulas de programação no SL. Ele achou o máximo e disse-me que andava no SL só por brincadeira, mas que gostava de saber criar coisas.” (Ent., aluno M de Proj. I, dia 28/11/2007) -“Fiquei a conhecer muita gente, alguns alugam terrenos só para se poderem encontrar com os amigos, pois moram longe uns dos outros. Assim, vão brincando e construindo coisas e pediram-me se eu os (sic) podia ensinar LSL.” (Ent., aluno 5 de Lab. I, dia 12/07/2007) Estas considerações feitas pelos alunos vêm ao encontro do que Paulo Dias (2004) refere: “A colaboração online é uma das formas de responder, em conjunto, a objectivos de aprendizagem, de cultivar a interacção e de proporcionar a construção e a utilização do conhecimento.” Um dos pontos negativos relatados pelos alunos na sua generalidade, referiu-se ao facto de a linguagem de programação do SL ser LSL. Os alunos preferiam que a linguagem fosse uma das que estudam ao longo do curso ou usada na indústria, em vez de estarem a esforçar-se por aprender outra linguagem, que embora semelhante à linguagem C não voltaria a ser usada por eles no futuro. Como Jenkins (2002)

207

Capítulo VIII: Análise dos Resultados advoga, este argumento não é relevante, porque o objectivo de uma linguagem de introdução à programação como esta, é compreender os conceitos (variáveis, funções, listas, etc.) e não o estudo da linguagem em si. Contudo, este aspecto negativo mencionado pelos alunos não é relevante para o comprimento dos objectivos desta investigação, mas é relevante porque os alunos se sentem afectados. Salientam-se, ainda, exemplos de opiniões relativas à aprendizagem da programação no SL, que traduzem o sentimento geral dos alunos que participaram na investigação: -“Gostei, porque podia ver como o meu cão se comportava e isto ajudou muito”; (Ent., aluno 4 de Lab I, dia 6/5/2008) -“ diverti-me imenso”; (Ent., aluno 1 de Lab III, dia 26/4/2007) -“ fiquei viciado no SL, passo muitas horas a desenvolver objectos só por brincadeira”; (Ent., aluno 2 de Lab III, dia 26/4/2007) - “Gostei muito, pois posso encontrar-me com os meus colegas que estavam no 2º ano e já aprenderam LSL, assim podemos trocar ideias.” (Ent., aluno 10 de Lab I, dia 6/5/2008)

8.1.4. O processo de ensino no SL
Ao longo desta investigação foi claro e notório que as funções do professor são multifacetadas, pois tem de realizar várias funções quando ensina no mundo virtual. As suas funções começam antes de iniciar as aulas, em que o professor actua como um design instrucional, planeia e prepara as aulas. As funções do professor incluem actividades pouco habituais como preparar a sala ou o espaço virtual, isto é, definir áreas na sala para cada grupo de alunos, de forma a poder ajudá-lo a identificar o que cada grupo de alunos está a fazer no projecto. Para além disto, também tem de preparar os materiais para as aulas e alguns deles visuais, ou seja, exemplos práticos de objectos com pequenos programas que sejam visualmente atractivos e interessantes, para que os alunos inexperientes possam observar, experimentar e adaptar. Por outro lado, é indispensável que esses exemplos sejam simples, de modo a que o professor durante uma aula facilmente os adapte às dificuldades dos alunos. Estes materiais têm duas particularidades, por um lado ajudar os alunos a compreender melhor os conceitos que estão a ser introduzidos e,

208

Capítulo VIII: Análise dos Resultados por outro, despertar neles o interesse pela aprendizagem, através da observação do que pode ser feito e da motivação em fazê-lo. Como advoga Miranda et al. (2007), muitas das actividades de ensino e aprendizagem dependem da proposta do professor. O professor precisa de estar presente e envolvido para assegurar que os alunos se empenham colaborativamente na resolução das tarefas de uma forma significativa. O trabalho do professor, no SL, é mais intenso e stressante do que nas aulas tradicionais: este necessita de preparar antecipadamente, por escrito, tudo o que quer ensinar e dizer, bem como prever quais serão as potenciais dificuldades dos alunos e as possíveis questões que possam surgir, de forma a poder escrever pequenas respostas a essas dificuldades e/ou questões e consequentemente dar aos alunos um rápido feedback. No decorrer das actividades foi patente que a presença e intervenção do professor dentro e fora das aulas é imprescindível para assegurar que os alunos se empenhem no desenvolvimento do seu projecto. Numa análise mais aprofundada ao papel do professor nota-se que este tem de estar muito atento às necessidades dos alunos, de forma a poder prestar a ajuda necessária, facilitar o discurso e fornecer instruções directas quando necessário. Este aspecto foi considerado fundamental no desempenho dos alunos, como foi mencionado pelos próprios. O professor, que deu aulas aos alunos de Lab. I no 4º ciclo de IA, também corrobora esta opinião de que ensinar no mundo virtual é muito mais trabalhoso e exige mais do professor do que as aulas tradicionais. Por outro lado permite também um contacto mais directo e personalizado com os alunos, tornando-se, assim mais fácil de identificar quais as dúvidas e as dificuldades de cada um. Neste estudo, conclui-se que a presença “física” do professor na primeira aula sobre o SL é importante para que os alunos compreendam o interface. Isto facilita a movimentação dos alunos no SL e a utilização do editor do programa. Obviamente, isto deve-se à falta de familiarização dos alunos com o interface do SL e eventualmente pode não ser relevante em estudantes que já tenham alguma experiência com o mundo. Considerou-se também importante, como meio de suporte aos alunos, existir um espaço online onde fosse possível colocar os materiais de estudo, como por exemplo o enunciado do trabalho, apontamentos sobre o SL e a linguagem LSL, assim como os resultados da discussão em grupo, utilizando-se para este fim o SIDE. Outro ponto considerado importante para que o professor pudesse dar um apoio mais focalizado 209

Capítulo VIII: Análise dos Resultados aos alunos, seria a existência de um mecanismo que o informasse por e-mail ou outro sistema fora do SL, das dúvidas e dificuldades que os alunos tiveram ao longo da semana, fora do período das aulas. Resumindo, ao longo desta investigação implementou-se e aperfeiçoou-se a intervenção do professor tendo em mente o seu papel como construtivista. De acordo com Brooks e Brooks (1993), os professores construtivistas são aqueles que: incentivam a autonomia e iniciativa dos estudantes; deixam que as respostas dos alunos conduzam as lições, a ponto de alterarem as estratégias de ensino; encorajam a pesquisa dos estudantes fazendo perguntas pensadas e abertas e entusiasmam-nos a fazer perguntas uns aos outros; encorajam a elaboração das respostas iniciais dos estudantes; envolvem os estudantes em experiências que podem originar contradições às suas hipóteses iniciais e encorajam a discussão de forma a ultrapassar tais contradições; dão tempo para reflectir, construindo relações e mesmo criando metáforas.

210

Capítulo VIII: Análise dos Resultados

211

9. Proposta de um modelo para o ensino da programação de computadores em mundos virtuais
No presente capítulo expõe-se um conjunto de linhas orientadoras para a utilização do SL como plataforma para o ensino introdutório da programação a alunos do ensino superior, resultante da análise dos resultados desta investigação. Este conjunto de linhas orientadoras tem por objectivo servir de guia e ponto de partida para investigações futuras.

Capítulo IX: Proposta de um Modelo

213

Capítulo IX: Proposta de um Modelo

9.1. Proposta de um modelo
A introdução de uma nova tecnologia na educação implica, na generalidade, adaptação e alteração na pedagogia utilizada. Contudo, existem mudanças tecnológicas cujo impacto é menor como, por exemplo, a mudança de um quadro branco face ao giz, outras com impacto maior como o computador ou os quadros electrónicos (smart boards). O uso destas tecnologias com maior impacto implica uma mudança pedagógica para garantir o êxito da sua introdução (Collis, 1998; Collis e Wende, 2002, Pereira et al., 2003, Salmon, 2009). Deste modo, deve-se contrariar a tendência para fazer com as novas tecnologias aquilo que já antes se fazia sem elas (Aparici, 1999; Figueiredo, 2001), ou seja, continuar a usar-se velhos métodos através dos novos meios. Assim, torna-se necessário desenvolver métodos e abordagens adequados e que tirem partido das novas potencialidades disponíveis. Neste contexto, propõe-se um conjunto de linhas orientadoras para o ensino e aprendizagem da programação resultante desta investigação.

9.2. Linhas orientadoras para o ensino da programação utilizando o SL
Face ao observado ao logo da actividade preliminar e subsequentes ciclos de IA constatou-se que o mundo virtual SL proporcionou aos alunos que participaram nestas actividades: um suporte técnico e emotivo; um contexto lúdico para a programação; exemplos elucidativos; uma experiência comunitária que enfatiza a aprendizagem. Cada um destes factores contribuiu individualmente para motivar os alunos a aprender a programar.

214

Capítulo IX: Proposta de um Modelo

9.2.1. Suporte técnico e emotivo
Os alunos que frequentam as aulas de introdução à programação são muito heterogéneos no que respeita aos seus conhecimentos de programação. Existem alunos que estão a ter contacto com a programação pela primeira vez e outros que já aprenderam a programar (Kelleher e Pausch, 2005; Gomes et al., 2008). Esta situação é um desafio para o professor. Se o professor ensinar ao nível dos alunos com mais conhecimentos, os outros sentem-se confusos, acabando provavelmente por desistir da disciplina. Se o professor ensina ao nível dos mais fracos, os que possuem mais conhecimentos sentem-se esmorecidos e ficam extremamente frustrados com a falta de progressos e de desafios. Finalmente, se o professor ensina no nível intermédio, as necessidades de ambos os alunos que estão no patamar acima e abaixo não são contempladas. Por outro lado, observa-se, com frequência, que os estudantes revelam níveis de autonomia bastante diferentes entre si, pelo que será necessário intervir de forma diferenciada, diagnosticando o ponto da situação para cada um dos casos, tentando conhecer o melhor possível os seus conhecimentos prévios, as suas atitudes e interesses (Pereira, 2007). Ao longo desta investigação observou-se que os alunos tinham ritmos e necessidades de apoio muito diferentes entre si. Alguns alunos não eram capazes de avançar sem o apoio constante da professora, como sucedeu com o aluno J de Lab II. Outros alunos sentiam-se mais desinibidos para esclarecer as suas dúvidas directamente com o professor, sem estarem os colegas a observar, como referiu o aluno S de Lab I que participou no 3.º ciclo de IA. Pedir e prestar ajuda são actos sociais que auxiliam a fomentar uma relação, como se observou ao longo desta experiência. Ajudar não é somente dar informação, mas é também motivar e incentivar o aluno para a aprendizagem. A relação que se estabelece entre o professor e o aluno é uma componente essencial do processo de aprendizagem online (Bruckman, 1997). Foi reconfortante notar o à-vontade dos alunos a conversar com a professora, levando-os a considerarem-na como uma colega de turma. Numa aula tradicional, os alunos têm uma relação diferente com o professor. Nalguns casos, os alunos podem sentir-se relutantes em pedir ajuda, por timidez. Noutros casos, o professor pode estar sobrecarregado por ter muitos alunos e não ter tempo suficiente para ajudar 215

Capítulo IX: Proposta de um Modelo cada um individualmente e principalmente aperceber-se das suas dificuldades. No SL somos todos iguais, não existe a formalidade de uma sala de aula, os alunos tratam o professor por “tu” e vêem-no como um colega de trabalho mais experiente com quem trocam ideias, conversam e pedem ajuda. Aqui podem interagir uns com os outros de uma forma mais livre de preconceitos do que no espaço real. Este foi um dos aspectos realçados pelos alunos na sua avaliação sobre a comunicação. Por conseguinte, a primeira recomendação destas orientações é que o professor utilize o canal privado para esclarecer as dúvidas individuais de cada aluno e o canal público para chamadas de atenção ou esclarecimentos gerais. Este tipo de comunicação permitiu à professora, por outro lado, ter um contacto directo e individual com cada aluno, permitindo-lhe, desta forma, aperceber-se das dificuldades de cada um e a possibilidade de lhe dar o suporte adequado. Observou-se na fase preliminar e no 1.º ciclo de IA uma repetição constante dos mesmos erros de compilação e execução. No entanto, foi notória a diminuição dos pedidos de ajuda a partir do momento em que a professora passou a escrever comentários no código dos alunos sobre as causas do erro. Os alunos também salientaram este aspecto referindo que deste modo poderiam ler quais as causas do problema sempre que este surgia, sendo capazes de o resolver. Assim, recomenda-se que o professor escreva comentários no código dos alunos sobre a causa do erro ou da dificuldade em questão, tornando deste modo a ajuda do professor ainda mais eficaz. Esta ajuda personalizada que a professora concedeu aos alunos levantou-lhe algumas dificuldades, nomeadamente em conseguir dar uma resposta atempada a todas as solicitações que recebia em simultâneo. Face a esta situação observada ao longo do 1.º e 2.º ciclos recomenda-se que o professor tenha um conjunto de frases predefinidas e escritas sobre as situações mais frequentes, de modo a dar um rápido feedback aos alunos em qualquer situação. Observou-se, principalmente no 3.º e 4.º ciclos, a importância do professor em encorajar os alunos, autonomamente, a explorar soluções para os problemas, a envolverem-se activamente na auto reflexão e na reflexão em grupo, a colaborarem com os colegas. Constatou-se no 3.º e 4.º ciclos, que a discussão em grupo do problema proposto gerou uma melhor compreensão deste por parte dos alunos. Esta discussão serviu também para que os alunos se apercebessem da fragilidade das soluções que apresentavam. Deste modo, recomenda-se a utilização da metodologia PBL para pequenos grupos de tutoria. Esta recomendação vem ao encontro do que 216

Capítulo IX: Proposta de um Modelo Dahlgren (2005) argumenta que a interacção entre pares é importante para a aprendizagem, como uma das características referidas nas abordagens pedagógicas centradas nos alunos na educação do ensino superior. O mesmo autor refere, ainda, o uso de pequenos grupos de tutoria como forma base de trabalho, salientando a importância da interacção e comunicação para o processo de aprendizagem. Os alunos geralmente esperam apenas uma solução correcta para o problema vinda do professor. Contudo, muitas vezes não existe apenas um única solução correcta, mas sim várias igualmente válidas. Constatou-se nas reuniões em grupo dos 3.º e 4.º ciclos que o facto de o professor dar alguma das soluções em forma de pergunta levou os alunos a reflectirem na solução. Por vezes, os alunos podem sentir-se irritados e confusos, como ocorreu com o aluno J de Lab. II. Neste caso, recomendase que o professor dê algumas pistas para que eles consigam progredir e resolver o problema por si. Sollmann (1994) refere que, os alunos quanto mais vezes se encontram em situações incertas melhor conseguem lidar com a situação, ou seja, levam mais tempo até se sentirem novamente inseguros. Isto é semelhante a um treino físico, quanto mais superarem os seus limites, maior será a sua capacidade de resistência. É importante ter um espaço no mundo virtual onde os alunos aprendam (Cheal, 2007; Salmon, 2009). Este para além de ser dinâmico deve permitir aos alunos ter uma zona individual onde deixar os seus objectos, quer os do projecto que estão a desenvolver, quer outros que tenham feito. Este espaço não deve ser uma reprodução da estrutura de uma sala de aula comum com cadeiras e mesas; é importante que os alunos se sintam à vontade, que possam saltar, voar e brincar nesse espaço antes de iniciarem as actividades para se focarem mais no seu trabalho (Cheal, 2007; Salmon, 2009). Ao longo desta investigação, utilizou-se para as aulas de programação um espaço no mundo virtual, no qual os alunos tinham zonas demarcadas para trabalhar e zonas de exemplos onde podiam deixar amostras do trabalho já concretizado. Estas zonas de trabalho não eram rígidas, os alunos podiam deslocar-se pelo espaço, trocar ideias uns com os outros (Figura 9.1 e Figura 9.2). O acesso a este espaço restringia-se apenas a alunos e colaboradores que a professora convidou para participarem nas aulas. Desta forma, durante as aulas nunca se verificou nenhuma presença de estranhos à turma, nem se sentiu nenhuma dificuldade pelo facto de os alunos estarem a observar objectos que não pertenciam ao espaço da aula. Estes são alguns dos factores negativos mencionados em vários

217

Capítulo IX: Proposta de um Modelo estudos feitos sobre o uso do SL no processo de ensino (Di Blas, Poggi e Reeves, 2006; Cai et al., 2008, Warburton, 2009). Assim, recomenda-se que se tenha um espaço no mundo virtual no qual decorrerão as aulas e restrinja-se o acesso a alunos e convidados. Nesse espaço aconselha-se identificar zonas de trabalho para cada grupo de alunos, assim como uma zona para se colocar os vários exemplos práticos.

Figura 9.1: Espaço utilizado nas aulas de programação durante os 1.º e 2.º ciclos de investigaçãoacção.

218

Capítulo IX: Proposta de um Modelo

Figura 9.2: Espaço utilizado nas aulas de programação durante os 3.º e 4.º ciclos de investigaçãoacção.

9.2.2. Contexto lúdico para a programação
Na literatura é referido que problemas eficazes despertam nos alunos o interesse e a motivação para procurarem compreender melhor os conceitos que estão a ser ensinados (Schmidt e Moust, 2001; O’Kell e Gibson, 2006). A reacção inicial dos alunos a um assunto ou tópico é crítico para que adquiram interesse pelo assunto em questão (ibid.). Consequentemente, é importante que os alunos inexperientes sejam introduzidos a programar no mundo virtual de uma forma adequada. Observou-se ao longo das actividades que os alunos que desenvolveram um projecto com uma forte componente visual mostravam-se empenhados no seu desenvolvimento, como ocorreu com os alunos de Lab III, Lab I e Proj. I. Contudo, também se constatou que quando o projecto foi considerado simples, como foi no caso dos alunos de Lab. I na fase preliminar, estes não se empenharam o suficiente para o terminarem atempadamente. Pelo que se recomenda que o projecto proposto deva ser adaptado ao nível de conhecimento dos alunos. Esta recomendação vem em concordância com o que é referido na literatura, de que se o projecto apresentado estiver no nível de domínio do aluno ou abaixo, então não haverá crescimento. Se for apresentado num nível superior dessa zona, os alunos ficarão confusos e frustrados (Byrnes, 1996). Segundo Poikela (2004), a natureza do conhecimento é contextual, como um

219

Capítulo IX: Proposta de um Modelo recurso e um catalisador da aprendizagem; não é apenas conceptual, simbólico ou facto formal, mas é incorporado como potencial em objectos, artefactos, actividade humana ou na estrutura de uma organização. O uso de um projecto visual permite aos alunos manipularem representações dinâmicas do mundo real e estas possibilitam objectivar os seus pensamentos de modo a que possam reflectir sobre eles. Contudo, estes objectos, designados de mindtools por Papert (1991), não funcionam sozinhos. Para aprender com estes objectos, os alunos necessitam de ser preparados em relação ao que aprender, precisam de oportunidades para articular o que descobrem e necessitam de feedback sobre as suas descobertas. Para se conseguir isto, deve-se usar estes objectos como um recurso em pequenos grupos colaborativos de aprendizagem, nos quais o professor deve estar presente e dar feedback sempre que considerar necessário (Laurillard, 2002). A aprendizagem vem da experiência e muita da experiência útil provém dos erros. Contudo, um aluno que não tenha confiança em si vai temer o fracasso e esse medo dificulta ou mesmo impede a aprendizagem. Os alunos confiantes usam as falhas e a frustração como mecanismos de incentivo. Eles sabem que uma “resposta errada” oferece a oportunidade para descobrir um mal entendido e chegar a uma melhor compreensão sobre o assunto. Esse conhecimento reparador levará a um melhor desempenho ao longo do tempo. No entanto, muitos alunos não começam a aprendizagem com confiança. O ensino tradicional normalmente desencoraja ou penaliza as falhas através de sistemas de avaliação e do reconhecimento do desempenho académico (Harrison, 2000). Os empregados podem temer que os seus empregadores vejam o seu fracasso como um sinal de incapacidade e temem perder o seu trabalho. Como resultado, a confiança em falhar é rara e difícil de desenvolver. Assim, é importante remover o medo do fracasso como uma barreira para a aprendizagem, tornando o fracasso ou erros como parte integrante do processo de aprendizagem. Ao longo desta investigação foi-se procurando formas de minimizar os erros e consequentemente encontrar soluções para que os alunos aprendam e tirem partido deles. Como se verificou, a comunicação utilizada entre a professora e os alunos veio remover certas barreiras que, geralmente, impedem os alunos de expor as suas dúvidas e fracassos ao professor. Um outro fenómeno observado foi que os alunos não ficavam perturbados quando os seus objectos não se comportavam da maneira 220

Capítulo IX: Proposta de um Modelo que esperavam, muito antes pelo contrário, na generalidade os que desenvolveram um projecto visual iam à procura de uma solução para o problema. Como se conclui dos comentários que os alunos fizeram no último encontro mensal: -“diverti-me imenso, principalmente porque o meu cão passava a vida a dizer que tinha fome, mesmo quando tinha acabado de comer”; (Ent., aluno D, de Proj. I, dia 14/1/2008) -“(...) gostei de criar o carro e a pista... este projecto foi interessante..” (Ent., aluno B de Lab. I, dia 27/4/2007) De acordo com Eckstein (2001), deve-se construir actividades que exijam que os alunos reflictam sobre o que está certo e incorrecto como forma de compreender melhor o tema em estudo. O mesmo autor refere ainda que se deve garantir que todos os alunos que encontrem resultados incorrectos não serão estigmatizados por não chegarem à resposta certa. No ensino da programação ocorre frequentemente os alunos dizerem que sabem programar, mas quando vão aplicar os conceitos verifica-se o oposto. Nesta investigação também foi notória esta lacuna, principalmente nos alunos de Lab II, que frequentemente diziam que sabiam programar mas não o conseguiam demonstrar. Muitas vezes, os alunos são expostos a problemas simples e têm uma solução simples. Quando se deparam com problemas complexos, os alunos apresentam soluções que não resolvem o problema. Mais grave, a ausência de experiência impede-os de reconhecer falhas no seu pensamento; esta foi uma das lacunas identificadas em alguns alunos que participaram neste estudo. Por este motivo, recomenda-se que o problema proposto deve ser complexo o suficiente de forma a levar os alunos a reflectir na sua solução. Assim, o problema deve à primeira vista sugerir uma solução simples baseada directamente nos conceitos gerais que o aluno sabe. No entanto, após uma análise cuidadosa de um número de questões, os alunos são levados a repensar na sua solução e a concluir que o problema exige uma solução mais complexa. O contraste entre a reacção inicial do aprendiz (o projecto é acessível) e o resultado de algum estudo ou discussão (este problema é mais complexo do que inicialmente se pensou) é crucial para o sucesso ( Anthony, 1996; McAndrew, Goodyear e Dalziel, 2006). Isto induz que o aprendiz reconheça que o assunto é mais subtil do que tinha inicialmente pensado. Por outro lado, serve de ligação entre a aprendizagem dos

221

Capítulo IX: Proposta de um Modelo conceitos básicos e os tópicos mais avançados. Esta forma faz com que os alunos suspeitem da compreensão que têm dos conceitos básicos, de modo a que continuem a questioná-los e a melhorar a sua compreensão. Como referem McAndrew et al. (2006), os alunos, ocasionalmente, precisam de ser confrontados com uma realidade distinta da que estão a fazer, de modo a aperceberem-se das subtilezas. Uma vez que na indústria novas ideias são muitas vezes vistas como ferramentas ou técnicas de programação, é necessário que os alunos sejam treinados para desenvolvê-las. Ademais, este estudo mostrou que a atitude dos alunos perante a aprendizagem dentro deste ambiente foi, em geral, de empenho na realização do projecto, tendo-se observado uma saudável competição pela criação de objectos mais atraentes. Os alunos de Lab. I e de Proj. I construíram um cão, os do Lab. III vários robots e um comboio e as respectivas estações. Outros alunos de Lab. I (3.º e 4.º ciclos) criaram carros, semáforos, uma bomba de gasolina e uma pista, tendo todos eles programado os seus respectivos comportamentos. Os alunos trabalharam fora do período das aulas, durante longas horas, colaborando uns com os outros e com a professora. Constatou-se que os alunos aprendiam e divertiam-se com o que estavam a fazer. Os alunos aprendem melhor num contexto onde a prática não é entediante e estão a resolver problemas com significado, e isto motiva-os a trabalhar mais (Bergin et al., 2001; Gee, 2003; Oliver, 2009). No SL é relativamente fácil criar objectos engraçados e realistas, sendo possível através da linguagem LSL programar o seu comportamento fazendo com que interajam uns com os outros e com os avatares, o que torna os objectos ainda mais realistas. Como refere Gee (2003): “Thinking, problem solving, and knowledge are “stored” in material objects and the environment. This frees learners to engage their minds with other things while combining the results of their own thinking with the knowledge stored in material objects and the environment to achieve yet more powerful effects.” (p. 210). Um aspecto surpreendente foi observar que os alunos, por sua própria iniciativa, criaram outros programas apenas por diversão e tinham orgulho em exibi-los. Observou-se também que se empenhavam por descobrir novas funcionalidades, que poderiam aplicar não só no seu projecto, mas também aos programas que andavam a desenvolver por divertimento. Da experiência da investigadora como professora de programação, também observou este tipo de comportamento em alguns dos alunos

222

Capítulo IX: Proposta de um Modelo usando ambientes tradicionais. Contudo, este tipo de atitude não é generalizado, ou seja, em ambientes tradicionais apenas alguns alunos programam “por diversão”. Como Twining (2009) refere: “virtual worlds seem to provide the ideal vehicle for providing people with such ‘lived experiences’, of radically different models of education. They allow users to do things which would be difficult or impossible to do in the physical world.”(p. 512 ). Em resumo, é importante que os alunos estudem em locais onde se identifiquem e se sintam confortáveis para deixar a sua imaginação voar. De acordo com Isaacson (2007): “A society’s competitive advantage will come not from how well its schools teach the multiplication and periodic tables, but from how well they stimulate imagination and creativity.”(p. 7). Em suma, recomenda-se que o projecto proposto deve ser complexo o suficiente de forma a obrigar a cooperação de todos os elementos do grupo para a sua resolução. Deve ter, também, uma forte componente visual e ser adaptado ao nível de conhecimento dos alunos.

9.2.3. A importância dos exemplos
Na programação existem muitos conceitos abstractos que os alunos precisam de compreender para poderem progredir na aprendizagem. Como refere Gruber (2008), um conceito abstracto é difícil de compreender e perceber qual a sua utilidade se não existir um exemplo concreto. Os exemplos concretos de utilização desses conceitos são especialmente úteis para estudantes que têm pouca experiência, consequentemente, os alunos aprendem o conceito abstracto e observam uma aplicação concreta. Isto permite-lhes distinguir o próprio conceito da sua aplicação. Os alunos, muitas vezes, consideram difícil converter o que assimilam nas aulas em competências que podem usar fora da sala (Bruckman, 1997). Eles lembram-se menos do que ouviram, do que testaram e experimentaram (ibid.). Constatou-se no decorrer dos vários ciclos, principalmente na fase preliminar e no 3.º e 4.º ciclos, no qual participaram os alunos com menos experiência de programação, que a utilização de exemplos concretos os ajudou a compreender os conceitos. Por outro lado, os exemplos serviram também como mecanismos de 223

Capítulo IX: Proposta de um Modelo incentivo e motivação para os alunos explorarem o que podem fazer no mundo virtual. Face ao observado, recomenda-se a utilização de pequenos exemplos para os alunos testarem e alterarem de forma a melhor compreenderem os conceitos. Os exemplos aplicados devem contudo ser lúdicos e mostrar as potencialidades do ambiente. Não obstante, é necessário ter em atenção que estes não devem ser demasiados complexos, pois se assim for perde-se o objectivo inicial. Este estudo enfatizou a importância que tem para os alunos o exemplo do sucesso alcançado pelos colegas. O facto de dois alunos terem conseguido obter sucesso na comunidade SL e principalmente um deles ter recebido uma proposta de emprego foi motivo de interesse para que outros quisessem seguir o seu exemplo. Como foi o caso de um dos alunos de Lab. II, que apesar da frustração do projecto que teve de desenvolver e de não ter gostado de o implementar, sempre quis aprender a programar no SL, pois como ele próprio referiu: “eu quero aprender a programar para me candidatar e ganhar um estágio remunerado no SL”, e conseguiu apesar de todas as dificuldades que teve.

9.2.4. Comunidade que enfatiza a aprendizagem
O mundo virtual SL está cheio de objectos interessantes criados pelos seus residentes, que servem de modelos para os novos utilizadores. Cada objecto, no mundo virtual, funciona como um possível modelo de aprendizagem e inspiração. É interessante que cada modelo esteja associado ao seu autor, com o qual se pode proporcionar um encontro online. Os exemplos para aprender estão situados num contexto social. A comunidade de residentes presente no mundo virtual foi um dos elementos importantes na motivação dos alunos em aprender a programar. Os alunos queriam mostrar à comunidade o que eram capazes de fazer. Os seus objectos foram tema de conversa com os residentes e serviram de base para outras conversas. Desta forma, criar um objecto interessante confere aos alunos um status dentro da comunidade de designers de objectos. Para além da satisfação pessoal de terem conseguido dominar a técnica de criar e programar objectos serviu, também, como um catalisador para a interacção social. Segundo Bruckman (1997), a motivação das pessoas em tentarem programar alguma coisa nos mundos virtuais é principalmente social. O primeiro passo para aprender a programar é talvez o mais difícil. A barreira inicial é principalmente emocional (ibid.). No mundo virtual, os alunos começaram a

224

Capítulo IX: Proposta de um Modelo construir objectos, a quererem aprender a programar, e a serem capazes de criar funcionalidades como os outros fizeram. O conjunto de exemplos disponíveis no mundo virtual para aprender não são estáticos, eles crescem e evoluem à medida que a comunidade vai aumentando. Um único autor com um conjunto de exemplos nunca poderia reflectir os interesses e necessidades da comunidade, o mesmo sucede com um autor que use criações de todos os intervenientes, descontextualizadas do ambiente de trabalho, como exemplos para aprender (Bruckman, 1997; Salmon, 2009; Warburton 2009). Um bom exemplo de um projecto simples e fortemente ligado ao seu criador foi o do cão. Este pequeno objecto acompanhava o seu dono nos passeios pelo mundo e algumas vezes ia ter com outros avatares a mando do dono (uma alteração introduzida por alguns alunos), o que era motivo para iniciar conversa. Um outro aluno passeava frequentemente pelo mundo acompanhado pelas suas criações, como se pode ver na Figura 9.3. A comunidade forneceu a motivação inicial para os alunos quererem aprender a programar neste ambiente, como alguns deles referiram nos questionários que já conheciam o SL e queriam aprender a programar.

Figura 9.3: Um dos alunos de Lab. III a exibir os seus objectos.

225

Capítulo IX: Proposta de um Modelo No mundo virtual, os alunos nunca estão sozinhos mesmo quando estão fora do tempo da aula. Quando tinham um problema no seu programa, existia sempre alguém a quem eles podiam recorrer, e por vezes ocorria o inverso, eram os outros que vinham ter com eles e lhes solicitavam ajuda. Ajudar os outros é uma actividade central na cultura do mundo virtual (Bruckman, 1997; Wagner, 2008; Twining, 2009) e é a base sobre a qual um relacionamento se estabelece. Pelo facto da comunidade ser um impulso na aprendizagem da programação, como se observou ao longo destas actividades, recomenda-se que os alunos fora das aulas devem desenvolver os seus projectos em qualquer local livre no mundo virtual. A Tabela 9.1 apresenta um resumo das recomendações resultantes deste estudo para o ensino inicial da programação, utilizando o mundo virtual SL como plataforma ou outro com características semelhantes.

226

Capítulo IX: Proposta de um Modelo

Elementos

Procedimento recomendado Projecto – deve ser complexo o suficiente de forma a obrigar a cooperação de todos os elementos do grupo para a sua resolução. Deve ter, também, uma forte componente visual e ser adaptado ao nível de conhecimento dos alunos. Pequenos exemplos – fornecer aos alunos objectos atractivos com programas simples sobre os novos conceitos a aprender, que os alunos devem experimentar e alterar. Estes exemplos devem ser adaptados ao nível de conhecimento de cada aluno. Problem-based learning para pequenos grupos de tutoria, juntamente com uma pedagogia diferenciada; Comunicação: Canal público – restringir a sua utilização, apenas para explicações ou chamadas de atenção gerais por parte do professor; Canal privado – este canal deve ser usado pelo professor e alunos para tirar dúvidas e dar explicações individualizadas por parte do professor a cada um dos alunos. Professor: escrever comentários, sempre que possível, no código dos alunos sobre a causa do erro ou da dificuldade em questão; deve estar presente fisicamente na primeira aula para explicar o interface do SL; deve ter um conjunto de frases já predefinidas e escritas sobre as situações mais frequentes, de modo a dar um feedback rápido aos alunos em qualquer situação; cabe-lhe o papel de mediador do processo de aprendizagem, orientando e guiando os alunos,

Materiais de aprendizagem

Metodologia

227

Capítulo IX: Proposta de um Modelo Elementos Procedimento recomendado dando-lhes apoio directo na fase inicial da aprendizagem, e seguidamente ajudar os alunos a transitar gradualmente para uma autoaprendizagem. Ter um espaço no mundo virtual no qual decorrerão as aulas. Restringir o acesso a esse espaço a alunos e convidados. Fora das aulas – para intensificar o contacto com a comunidade, os alunos devem desenvolver os seus projectos em qualquer local livre no mundo virtual. Espaço da aula Espaço da aula: Identificar zonas de trabalho para cada grupo de alunos. Definir uma zona para colocar os vários exemplos práticos usados nas aulas. Neste espaço os alunos podem deixar objectos que considerem interessantes para os colegas.
Tabela 9.1: Modelo para o ensino / aprendizagem da programação de computadores dentro do Second Life.

228

Capítulo IX: Proposta de um Modelo

229

10. Conclusões
Concluído o processo de investigação, tendo-se analisado e apresentado os resultados, resta tirar conclusões acerca da forma como os objectivos definidos inicialmente foram ou não atingidos. Por fim, apresentam-se as considerações finais e o trabalho futuro.

Capítulo X: Conclusões

231

Capítulo X: Conclusões

10.1.

Conclusões

Aprender a programar um computador é uma tarefa difícil e exigente, principalmente para os alunos inexperientes. Por outro lado, a programação parece não ser um assunto atractivo para a generalidade dos alunos dos cursos de informática do ensino superior, em várias partes do mundo, como na América, Austrália, Nova Zelândia e Europa (Mierlus, 2007; Lister et al., 2010). Os alunos gostam de usar o computador, passam horas a jogar jogos complexos sozinhos ou online com outros colegas, mas estas aplicações de lazer normalmente requerem algum tempo de adaptação, pois é necessário ler as instruções, compreender os objectivos, etc. Os alunos também gostam de conversar no Messenger, e expor as suas experiências em blogs, mas quando se fala em aprender a programar um computador a motivação e o interesse esmorecem. Uma das questões primordiais que se coloca hoje em dia aos professores é como ajudar os alunos a compreender os fundamentos e a ganhar motivação para a programação. A resposta não é simples, depende do que se considera importante ensinar, como, por exemplo, seguir uma abordagem orientada a objectos ou procedimental, focar mais nos algoritmos e na resolução de problemas, dar mais ênfase na linguagem da programação utilizada ou ao desenvolvimento de competências como as de comunicação e colaboração, que também são desejáveis que os alunos de engenharia adquiram (Jenkins, 2002; Ma et al., 2007; Shivers, 2008; Czejdo, e Bhattacharya, 2009). A proposta da investigadora consiste em contextualizar o ensino introdutório da programação através da utilização dos mundos virtuais tridimensionais online multiutilizador como plataforma para o ensino e aprendizagem, dando ênfase à resolução de problemas reais, num ambiente com características semelhantes àquelas em que os alunos estão habituados a usar nos jogos. Desta forma, com base na revisão da literatura pretendeu-se com esta dissertação explorar as possibilidades, atitudes, práticas, dificuldades e limitações do ensino e aprendizagem inicial da programação a alunos do ensino superior no mundo virtual Second Life. O estudo realizado desenvolveu-se a partir de um projecto de investigação-acção que a investigadora levou a cabo com os alunos do ensino

232

Capítulo X: Conclusões superior em disciplinas de programação. Este estudo compreendeu uma actividade preliminar e 4 ciclos subsequentes de investigação-acção, tendo resultado no desenvolvimento de um modelo para o ensino e aprendizagem da programação de computadores dentro do mundo virtual Second Life. Em resumo, para concretizar os objectivos traçados cumpriram-se as seguintes etapas: foi feito um levantamento das dificuldades relatadas na literatura científica sobre a aprendizagem da programação, assim como a explanação das principais abordagens pedagógicas propostas. Foram também descritas as ferramentas que têm vindo a ser utilizadas para o ensino e aprendizagem da programação; foram analisados os mundos virtuais existentes com o intuito de seleccionar um para ser utilizado nesta investigação. Desta análise resultou na adopção do mundo virtual Second Life; foi concebido o projecto de investigação, no qual se optou por utilizar uma metodologia de investigação qualitativa, mais concretamente, a metodologia investigação-acção; foi levado a cabo o trabalho de campo regido pela metodologia investigaçãoacção; fez-se a análise e discussão dos resultados; fez-se a conclusão do projecto de investigação. Os objectivos definidos no capítulo da introdução foram, na generalidade, atingidos com sucesso. Os resultados obtidos são fruto de uma associação equilibrada da teoria com a prática resultante de uma observação reflectida. O modelo proposto enfatiza a importância de se utilizar um enunciado do projecto com uma forte componente visual e adaptado ao nível do conhecimento dos alunos. É igualmente importante o empenho do professor no acompanhamento do trabalho dos alunos, nomeadamente na escrita de comentários no código dos alunos sobre a causa do erro ou da dificuldade em questão. Desta forma, os alunos têm sempre presente o porquê do erro e podem reler quantas vezes considerarem necessário, o que os ajuda a conseguir resolver erros semelhantes. Por outro lado, o professor deve fornecer aos alunos pequenos exemplos de programas sobre os conceitos a aprender, para que

233

Capítulo X: Conclusões estes os experimentarem e alterarem. Contudo, o modelo realça a importância destes exemplos serem adaptados ao nível de conhecimento de cada aluno. O modelo propõe que se deve utilizar um canal de comunicação privado entre o professor e aluno, para o esclarecimento de dúvidas e dar explicações individualizadas. Assim, estabelece-se uma relação de partilha e ajuda, que se torna difícil de estabelecer publicamente para muitos alunos. É igualmente importante o reconhecimento público do trabalho dos alunos, como fonte de motivação para que estes se envolvam e comprometam na sua aprendizagem. Em suma, verificou-se que o mundo virtual SL ou outro com características idênticas pode ser utilizado como plataforma para o ensino e aprendizagem introdutórios da programação. Contudo, na sua utilização deve-se ter em conta principalmente os seguintes factores: é necessário um grande empenho por parte do professor em todo o processo de gestão, acompanhamento, suporte do ensino e aprendizagem; é necessário ter muito cuidado com o tipo de projecto que se propõe. Estes são os dois pilares fundamentais que a investigadora considera indispensáveis para se poder utilizar os mundos virtuais no ensino e aprendizagem da programação. Apesar dos mundos virtuais terem características que os tornam bastante atractivos para serem usados na educação, falta averiguar se o esforço compensa, isto é, se realmente os alunos neste ambiente aprendem melhor, sendo esta uma das propostas de trabalho futuro.

10.2. Considerações finais e propostas de trabalho futuro
Este estudo pretende ser um ponto de partida para outras investigações, quer qualitativas quer quantitativas, sobre os benefícios da utilização dos mundos virtuais no ensino e aprendizagem da programação. Pelo que, este trabalho não termina nesta dissertação, acredita-se que o modelo proposto servirá de guia a futuras investigações e que estas venham trazer-lhe melhorias. Uma das lacunas referidas nesta investigação diz respeito ao acompanhamento por parte do professor do trabalho dos alunos fora das aulas. Uma das soluções possíveis seria a integração das actividades no mundo virtual com um serviço de mensagens

234

Capítulo X: Conclusões semelhante ao SMS dos telemóveis. Esta integração poderá ser ainda mais eficaz se permitir que o professor siga os progressos e esforços dos alunos, de forma a poder ajudá-los de um modo mais directo, mesmo quando este não se encontra dentro do mundo. Para tal, seria necessário desenvolver um mecanismo automático que registasse o trabalho dos alunos dentro do mundo quando o professor não está presente, respondendo automaticamente a algumas questões, e proporcionar o contacto com este através de vários meios, como por exemplo usar um sistema semelhante ao proposto por Valério et al. (2009). Um outro objectivo a alcançar futuramente prende-se com a confirmação de que através da utilização dos mundos virtuais como plataforma no ensino e aprendizagem da programação os alunos aprendem melhor do que nos ambientes tradicionais, o que implicaria fazer um estudo comparativo entre estes distintos ambientes, a nível nacional e internacional, de modo a se poder obter resultados mais conclusivos. Especificamente, seria interessante averiguar não só o domínio das técnicas de programação, mas também se os conhecimentos adquiridos pelos alunos são autênticos e não superficiais, isto é, se eles são capazes de usar esses conhecimentos em outras situações. Outro aspecto a explorar seria a utilização do mundo virtual como plataforma para o ensino e aprendizagem da programação em disciplinas não introdutórias da programação, com o propósito de se analisar o seu desempenho, bem como a sua utilização em disciplinas como a engenharia do software. Os resultados desta investigação serviriam também para introduzir melhorias ao presente modelo. A investigadora pretende desenvolver esta investigação e, em simultâneo, explorar outras variáveis, tais como o impacto deste ambiente na motivação dos alunos, e se diminui o índice de reprovação nas disciplinas de introdução à programação. Um outro aspecto a desenvolver seria explorar e adequar o modelo ao ambiente de sala de aula sem ser remotamente, embora se considere que a principal adaptação seja de anular a utilização do canal público que seria substituído por explicações directas para todos os alunos que se encontram nesse ambiente. Contudo, a mudança radical de contexto não presencial para presencial poderá permitir descortinar outras dinâmicas, por agora não antecipadas.

235

11. Referências Bibliográficas
Abrunhosa, M. A. e Leitão, M. (2002). Psicologia. Volume1. Areal Editores. Ackoff, R. L. (1998), Acoff’s Best: His Classic Writtings on Management. John Wiley & Sons, Inc. Alarcão, I. (1991). Reflexão crítica sobre o pensamento de D. Schön e os programas de formação de professores. Cadernos Cidíne 1: Supervisão e formação de professores, Aveiro: Universidade de Aveiro, pp. 5-22. Allan, S. e Tomlinson C.(2002). Liderar projectos de diferenciação pedagógica. Porto: Edições Asa. Allen, E., Cartwright, R. e Stoler, B. (2002). DrJava: a lightweight pedagogic environment for Java. In Proceedings of the 33rd SIGCSE technical symposium on Computer science education (SIGCSE '02). ACM, New York, NY, USA, 137-141. Almeida, J. C. (2001). Em defesa da investigação-acção. Sociologia, nov. 2001, no.37, p.175-176. ISSN 0873-6529 Disponível em on-line em http://www.scielo.oces.mctes.pt/scielo.php?pid=S087365292001000300010&script=sci_arttext&tlng=pt. Consulta em 14-01-06 Anderson, T. (2004). Teaching in an online learning context. In T. Anderson & F. Elloumi (Eds), Theory and practice of online learning (pp. 1–14). Athabasca: Athabasca University. Antonacci, DM., Modaress, N., (2005). Second Life: the educational possibilities of a massively multiplayer virtual world (MMVW). In: Proceedings of the EDUCAUSE western regional conference, April 26, 2005, San Francisco. Antunes, R.; Morgado, L.; Martins, P.; e Fonseca, B. (2008). Managing 3D Virtual Classrooms, Learning Technology, 10 (1), pp. 3-5. Aparici, R. (1999). Mitos de la educación a distancia y nuevas tecnologias. In Rodríguez, E. M. & Quintillán (Eds.) – La educación a distancia en tiempos de cambios: nuevas generaciones, viejos conflitos, (pp. 177-192). Madrid: Ediciones de la Torre. Arshad, N. (2009). Teaching programming and problem solving to CS2 students using think-alouds. In Proceedings of the 40th ACM Technical Symposium on Computer Science Education. (Chattanooga, TN, USA, March 04 - 07, 2009). SIGCSE '09. ACM, New York, NY, 372-376. Attasiriluk, S., Nakasone, A., Hantanong, W., Prada, R., Kanongchaiyos, P. and Prendinger, H. (2009). Co-presence, collaboration, and control in environmental studies: A Second Life-based approach. Virtual Real. 13, 3 (August 2009), 195-204.

236

Austin, T., Boulder, C. (2007). The Horizon Report, 2007 Edition. New Media Consortium and EDUCAUSE Learning Initiative. [Online]; disponível em http://www.nmc.org/pdf/2007_Horizon_Report.pdf (acedido em 12 de Setembro de 2008) Avison, D. E., Lau, F., Myers, M. D. e Nielsen, P. A. (1999). Action research. Commun. ACM 42, 1 (Jan. 1999), 94-97. Bailey, F., e Moar, M. (2002). The Vertex Project: Exploring the creative use of shared 3D virtual worlds in the primary (K-12) classroom. Paper presented at SIGGRAPH 2002, San Antonio. In ACM SIGGRAPH 2002 Conference Abstracts and Applications (pp. 52 – 54). New York: ACM SIGGRAPH. Balakrishnan, A. D., Fussell, S. R. e Kiesler, S. (2008). Do visualizations improve synchronous remote collaboration?. In Proceeding of the Twenty-Sixth Annual SIGCHI Conference on Human Factors in Computing Systems (Florence, Italy, April 05 - 10, 2008). CHI '08. ACM, New York, NY, 1227-1236. Barab, S. A., Hay, K. E., Barnett, M. G., e Squire, K. (2001). Constructing virtual worlds: Tracing the historical development of learner practices/understandings. Cognition and Instruction, 19(1), 47 – 94. Barab, S. A., Hay, K. E., Squire, K., Barnett, M., Schmidt, R., Karrigan, K., et al. (2000). Virtual solar system project: Learning through a technology-rich, inquiry-based, participatory learning environment. Journal of Science Education and Technology, 9, 7 – 25 Barbier, J. (1990). L’ evaluation en formation (2ª ed.). Paris: Press Universitaires de France. Barrett, T. (2005). Who said learning couldn’t be enjoyable, playful and fun? – The voice of PBL students. In Esa Poikela & Sari Poikela (Eds.), PBL in Context – Bridging Work and Education (pp. 159–175). Finland,Tampere University Press. Barrows, H. (2001). Problem-based Learning (PBL). Disponível <http://www.pbli.org/pbl>. Consultado em: 16 junho de 2007 em:

Barrows, H.S. (1985). How to design a problem-based curriculum for the preclinical years. New York: Springer. Barrows, H: S. e Tambly, R. M. (1980). Problem-Based Learning, an approach to medical education. New York: Springer. Barth, B. M. (1995). The role of contexts and interactions in the chld’s construction of knowledge. European Early childhood Education Research Journal, V. 3,1. pag 7384. Bartle, R. (1990). Early Mud history. http://www.mud.co.uk/richard/mudhist.htm. Consultado a 30 de Abril de 2008. Baskerville, R. (1999). Investigating Information Systems with Action Research. Communications of The Association for Information Systems, (19) Article 2.

237

Bateman, M.; Storer, T.; Purdie, S. e Lock, R. (2007). Encouraging experimentation in programming using a problem based learning approach. Proposal to SELF 2007, October 2007. Bawden, R. e Zuber-Skerritt, O. (2000). The concept of process management. In Action Learning, Action Research and Process Management: Theory, Practice, Praxis, Action Research Unit. Faculty of Education, Griffith University, Brisbane. Bayman, P. e Mayer, R. E. (1983). A diagnosis of beginning programmers' misconceptions of BASIC programming statements. Commun. ACM 26, 9 (Sep. 1983), 677-679. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Becker, B. W. (2001). Teaching CS1 with karel the robot in Java. In Proceedings of the Thirty-Second SIGCSE Technical Symposium on Computer Science Education (Charlotte, North Carolina, United States). SIGCSE '01. ACM, New York, NY, 50-54. Becker, K. (2002). Back to Pascal: Retro but not backwards. Journal of Computing in Small Colleges, 18(2):17–27. Ben-Ari, M., (2001). Constructivism in computer science education. Journal of Computer in Mathematics and Science Teaching 20 (1), 45-73. Bender, T. (2003). Discussion-based online teaching of enhance student learning: Theory, practice and assessment. Virginia: Stylus Publishing. Bennedsen, J. e Schulte, C. (2010). BlueJ visual debugger for learning the execution of object-oriented programs? ACM Trans. Comput. Educ. 10, 2, Article 8 (June 2010), 1-22. Bereiter, C. e Ng., E. (1991). Three Levels of Goal Orientation in Learning. In Journal of the Learning Sciences, nº 3, (vol. 1), 243-271 Bergin, J. (2006). Karel universe drag & drop editor. In Proceedings of the 11th Annual SIGCSE Conference on innovation and Technology in Computer Science Education (Bologna, Italy, June 26 - 28, 2006). ITICSE '06. ACM, New York, NY, 307307. Bergin, J., Eckstein, J., Manns, M. L., Wallingford, E. (2001). Patterns for Gaining Different Perspectives, Proceedings of PLoP 2001 Bessière, K., Ellis, J. B. e Kellogg, W. A. (2009). Acquiring a professional "second life": problems and prospects for the use of virtual worlds in business. In Proceedings of the 27th international Conference Extended Abstracts on Human Factors in Computing Systems (Boston, MA, USA, April 04 - 09, 2009). CHI EA '09. ACM, New York, NY, 2883-2898. Bettencourt, T (2007). Education in virtual/real http://cleobekkers.wordpress.com/2007/12/15/a-1ª-universidadeportuguesa-em-sl-foi-a-utad-i consultado a 9 de Setembro de 2010. worlds.

238

Bettencourt-da-Cruz, T. M. (2006). A Internet na Construção de Conhecimento Didáctico. Tese de Doutoramento, Universidade de Aveiro. Blizzard Entertainment. (2010). World of Warcraft®: The Burning Crusade™ continues record breaking sales pace. http://www.blizzard.com/press/070307.shtml. Consultado a 8 de Janeiro de 2010. Bogdan, R. e Biklen, S. (1994). Investigação Qualitativa em Educação. Porto:Porto Editora. Bonar, J. e Soloway, E. (1985). Preprogramming knowledge: a major source of misconceptions in novice programmers. Hum.-Comput. Interact. 1, 2 (Jun. 1985), 133-161. Boroni, C. M., Goosey, F. W., Grinder, M. T., Lambert, J. L. e Ross, R. J. (1999). Tying it all together: creating self-contained, animated, interactive, Web-based resources for computer science education. In the Proceedings of the Thirtieth SIGCSE Technical Symposium on Computer Science Education (New Orleans, Louisiana, United States, March 24 - 28, 1999). SIGCSE '99. ACM, New York, NY, 7-11. Böszörményi, L. (1998). Why Java is not my favourite first-course language. SoftwareConcepts & Tools, 19(3):141–145. Bourne, J., Harris, D., Mayadas, F. (2005). Online Engineering Education: Learning Anywhere, Anytime. Journal of Engineering Education 94(1), 131-146. Boyer, N. R., Langevin, S. e Gaspar, A. (2008). Self direction & constructivism in programming education. In Proceedings of the 9th ACM SIGITE Conference on information Technology Education (Cincinnati, OH, USA, October 16 - 18, 2008). SIGITE '08. ACM, New York, NY, 89-94. Bravo, C., Mendes, A.J., Marcelino, M.J. e Redondo, M. (2004), Integrating collaboration with animation and simulation in computer-supported Programming learning. In Proceedings of the 33rd International Symposium IGIP / IEEE / ASEE, pp. 409 - 414, Fribourg, Suiça, Setembro. Bricken, M., Byrne, C. M. (1994), Summer students in virtual reality: A pilot study on educational applications of virtual reality technology, in A. Wexelblat (Ed.), Virtual reality: Applications and explorations (pp. 199–218). Boston: Academic Press. Bridgeman, S., Goodrich, M.., Kobourov, G. e Tamassia, R. (2000). PILOT: An Interactive Tool for Learning and Grading, Proceedings on the 31st SIGCSE Technical Symposium on Computer Science Education, Austin, TX , USA. Brooks, Jacqueline G., e Brooks, Martin G. (1993). In Search of Understanding: The Case for Constructivist Classrooms. Alexandria, VA: Association for Supervision and Curriculum Development.

239

Brown, M. e Sedgewick, R. (1984a). Progress Report: Brown University Instructional Computing Laboratory. In Proceedings of the fifteenth SIGCSE Technical Symposium on Computer Science Education, vol.6, No. 1, pp. 91-101,. Brown, M., Najork, M. (1996). Collaborative Active Textbooks: A Web-Based Algorithm Animation System for an Electronic Classroom, In Proceedings of the IEEE Symposium on Visual Languages (VL’96) to be held September 3–6, 1996 in Boulder, Colorado Brown, M., Sedgewick, R. (1984b). A System for Algorithm Animator, ACM Computer Graphics, Vol. 18, pp. 177-186, Minneapolis, Julho. Bruckman, A. S. (1997). MOOSE Crossing: Construction, Community, and Learning in a Networked Virtual World for Kids. Massachusetts Institute of Technology. Bruer, J.T. (1993). Schools for Thought: A science of learning in the classroom. Cambridge MA: MIT Press. Bruner, J. S. (1960). The Process of Education. Cambridge. Harvard University Press Bruner, J. S. (1966). Toward a Theory of Instruction. Cambridge. Harvard University Press. Bruner, J. S. (1990). Acts of Meaning. Cambridge. Harvard University Press. Brusilovsky, P. (1991). Turingal—the language for teaching the principles of programming. In the 3rd European Logo Conference, Parma, Italy. 423–432. Brusilovsky, P., Calabrese, E., Hvorecky, J., Kouchirenko, A., e Miller, P. (1997). Mini-languages: A way to learn programming principles. Educat. Inform. Technol., 2, 1, 65–83. Buck, D. e Stucki, D. J. (2001). JKarelRobot: a case study in supporting levels of cognitive development in the computer science curriculum. In Proceedings of the Thirty-Second SIGCSE Technical Symposium on Computer Science Education (Charlotte, North Carolina, United States). SIGCSE '01. ACM, New York, NY, 16-20. Byrne, P. e Lyons, G. (2001). The effect of student attributes on success in programming. SIGCSE Bull. 33, 3 (Sep. 2001), 49-52. Byrnes, J. (1996). Cognitive development and learning in instructional contexts. Boston : Allyn and Bacon. Cai, H., Sun, B., Farh, P. e Ye, M. (2008). Virtual Learning Services over 3D Internet: Patterns and Case Studies. In Proceedings of the 2008 IEEE international Conference on Services Computing - Volume 2 (July 07 - 11, 2008). IEEE Computer Society, Washington, DC, 213-219

240

Cairncross, S.; McEwan, T. (2009). Researching engineering education: Some philosophical considerations. In Proceedings of the 39th ASEE/IEEE Frontiers in Education Conference, Santo Antonio, Texas, USA, 18- 21 October 2009, 1-6 Calabrese, E. (1989). Marta – The “intelligent turtle”. In Proceedings of the Second European Logo Conference. G. Schuyten and M. Valcke (Eds.) pp 111-127, Belgium. Cameron, J. (2009). Avatar, disponível em http://www.avatarmovie.com/index.html consultado a 15 de Dezembro de 2009. Carmen L. Z. Gress, Meghann Fior, Allyson F. Hadwin e Philip H. Winne. (2010). Measurement and assessment in computer-supported collaborative learning. Comput. Hum. Behav. 26, 5 (September 2010), 806-814. Carson, D. Gilmore, A., Gronhaug, K. e Perry (2001). Qualitative Marketing Research, Sage, London. Carvalho, R., Cozinheiro, L. (2007) AV3D – Ambiente virtual 3D de apoio à programação orientada a objectos. Escola Superior de Tecnologia e Gestão do IPL. Cassel, L.; McGettrick, A., Guzdial, M. e Roberts, E. (2007). The current crisis in computing: what are the real issues?. In Proceedings of the 38th SIGCSE Technical Symposium on Computer Science Education (Covington, Kentucky, USA, March 07 - 11, 2007). SIGCSE '07. ACM, New York, NY, 329-330. Castronova, E. (2001). Virtual Worlds: A First-Hand Account of Market and Society on the Cyberian Frontier. In The Gruter Institute Working Papers on Law, Economics, and Evolutionary Biology, 2(1), 1-66. Champion, E. e Sekiguchi, S. (2005). Suggestions for New Features to Support Collaborative Learning in Virtual Worlds. In Proceedings of the Third international Conference on Creating, Connecting and Collaborating Through Computing (January 28 29, 2005). C5. IEEE Computer Society, Washington, DC, 127-134. Chan, M. S. e Black, J. B. (2006). Direct-manipulation animation: incorporating the haptic channel in the learning process to support middle school students in science learning and mental model acquisition. In Proceedings of the 7th international Conference on Learning Sciences (Bloomington, Indiana, June 27 - July 01, 2006). International Conference on Learning Sciences. International Society of the Learning Sciences, 64-70. Chee, Y. S. (2007). Embodiment, embeddedness, and experience: game-based learning and the construction of identity. Research and Practice in Technology Enhanced Learning, 2, 1, 3–30. Chen, J. e Weld, D. S. (2008). Recovering from errors during programming by demonstration. In Proceedings of the 13th international Conference on intelligent User interfaces (Gran Canaria, Spain, January 13 - 16, 2008). IUI '08. ACM, New York, NY, 159-168.

241

Cheng, A. (1998). A graphical programming interface for a children’s constructionist learning environment. Electrical Engineering and Computer Science Department. MIT, Cambridge, MA. Chizzotti, A. (1991). Pesquisa em ciências humanas e sociais. São Paulo: Cortez. Clancy, M. J. e Linn, M. C. (1992). Case studies in the classroom. SIGCSE Bull. 24, 1 (March 1992), 220-224. Close, R., Kopec, D. e Aman, J. (2000). CS1: perspectives on programming languages and the breadth-first approach. In Proceedings of the 5th annual CCSC Northeastern Conference on Computing in Small Colleges, pages 228–234. Consortium for Computing Sciences in Colleges. Cohen, L. e Manion, L. (1994). Research Methods in Education Fourth Edition, London, Routledge. Collis, B. (1998). New didactics for university instruction: why and how?. Computers & Education, 31, pp.373-393 Collis, B.; Wende, M. (2002). Models of Technology and Change in Higher Education. Center for Higher Education and Policies/Faculty of Educational Science and Technology of University of Twente Concepcion, A. I., Cummins, L. E., Moran, E. J., e Do, M. M. (1999). Algorithma 98: an algorithm animation project. SIGCSE Bull. 31, 1 (Mar. 1999), 301-305. Cooper, S., Dann, W. e Harrison, J. (2010). A k-12 college partnership. In Proceedings of the 41st ACM Technical Symposium on Computer Science Education (Milwaukee, Wisconsin, USA, March 10 - 13, 2010). SIGCSE '10. ACM, New York, NY, 320-324. Cooper, S., Dann, W. e Pausch, R. (2000). Alice: a 3-D tool for introductory programming concepts. In Proceedings of the Fifth Annual CCSC Northeastern Conference on the Journal of Computing in Small Colleges (Ramapo College of New Jersey, Mahwah, New Jersey, United States). J. G. Meinke, Ed. Consortium for Computing Sciences in Colleges. Consortium for Computing Sciences in Colleges, 107-116. Corbit, M. e DeVarco, B. (2000). SciCentr and BioLearn: Two 3-D implementations of CVE science museums. In E. Churchill and M. Reddy (Eds.), Proceedings of the Third International Conference on Collaborative Virtual Environments (pp. 65 – 71). New York: ACM. Coutinho, Clara P. e Chaves, José H. (2002) O estudo de caso na investigação em Tecnologia Educativa em Portugal. Revista Portuguesa de Educação, Volume 15, número 1, 221-244. Cox, A. e Campbell, M. (1994). Multi-user dungeons. Interactive Fantasy 2, 15-20

242

CPAL3D (2002). CPAL3D engine http://www.cpal3d.net. Consultado a 5 de Abril de 2009. Craft, T. (2004). Codelab-C: on Line Product. Jones and Bartlett Publishers, Inc Crosby, M. e Stelovsky, J. (1995). From multimedia instruction to multimedia evaluation. Journal Educ. Multimedia and Hypermedia 4, 147–162. Cypher, A. (1991). EAGER: Programming Repetitive Tasks by Example, In CHI, Proceedings SIGCHI’91. April. New Orleans, LA: pp.33-39.. Cypher, A., Halbert, D. C., Kurlander, D, Lieberman, H, Maulsby, D.,. Myers, B. A and Turransky, A. Eds. (1993) Watch what I Do: Programming by Demonstration. MIT Press. Czejdo, B. D. e Bhattacharya, S. (2009). Programming robots with state diagrams. J. Comput. Small Coll. 24, 5 (May. 2009), 19-26. Dahlgren, L.-O. (2005). Learning conceptions and outcomes. In F. Marton, D. Hounsell & N. Entwistle (Eds.), The experience of learning: Implications for teaching and studying in higher education (3rd (Internet) ed., pp. 23–38). Edinburgh: Edinburgh: University of Edinburgh, Centre for Teaching, Learning and Assessment. Dalgarno, B. (2002). The potential of 3D virtual learning environments: a constructivist analysis. Electronic Journal of Instructional Science and Technology, 5, 2, 1–19. Consultado a 15 de Abril de 2007 em http://www.usq.edu.au/electpub/e-jist/docs/Vol5_No2/Dalgarno%20%20Final.pdf Damer, Bruce (2001), Global Cyberspace and Personal Memespace, disponível em http://www.kurzweilai.net/meme/frame.html?main=/articles/art0096.html consultada a 2 de Março de 2007. Danilicheva, P., Klimenko, S., Baturin, Y. e Serebrov, A. (2010). Education in Virtual Worlds: Virtual Storytelling. In CyberWorlds, 2009. CW '09. IEEE International conferencve on Bradford Outubro 6-10-2010. pp. 333-338. Dann, W. e Cooper, S. (2009). Education Alice 3: concrete to abstract. Commun. ACM 52, 8 (Aug. 2009), 27-29. Dann, W., Cooper, S., Pausch, R. (2000). Making the connection: programming with animated small worlds. In Proceedings of the 5th annual conference on Innovation and Technology in Computer Science Education. Helsinki, Finland, July, 2000, 41- 44. de Barros, L. N., dos Santos Mota, A. P., Delgado, K. V. e Matsumoto, P. M. (2005). A tool for programming learning with pedagogical patterns. In Proceedings of the 2005 OOPSLA Workshop on Eclipse Technology Exchange (San Diego, California, October 16 - 17, 2005). eclipse '05. ACM, New York, NY, 125-129.

243

de Freitas, S. (2008). Serious virtual worlds: a scoping study. Bristol: Joint Information Systems Committee. Consultado em 14 de Outubro de 2009, em http://www.jisc.ac.uk/publications/publications/seriousvirtualworldsreport.a spx de Freitas, S. e Neumann, T. (2009). The use of ‘exploratory learning’ for supporting immersive learning in virtual environments. Computers and Education, 52, 2, 343–352. de Freitas, S. e Veletsianos, G. (2010). Editorial: Crossing boundaries: Learning and teaching in virtual worlds. British Journal of Educational Technology, 41, 1, 3–9. de Freitas, S., Rebolledo-Mendez, G., Liarokapis, F., Magoulas, G. e Poulovassilis, A. (2010). Learning as immersive experiences: Using the four-dimensional framework for designing and evaluating immersive learning experiences in a virtual world. British Journal of Educational Technology. 41(1). 69-85 De Grave, W. S. (1998). Problem-based learning as knowledge construction. Doctoral dissertation, Maastricht University, Maastricht, The Netherlands. de Raadt, M., Watson, R., Toleman M., (2002). Language Trends in Introductory Programming. In Proceedings of Informing Science and IT Education Conference, pages 329–337. InformingScience.org, June de Raadt, M., Watson, R., Toleman M., (2004). Introductory programming: what’s happening today and will there be any students to teach tomorrow? In Proceedings of the 6th Conference on Australasian Computing Education, pages 277– 282. Australian Computer Society, Inc. Dede, C. (1995). The evolution of constructivist learning environments: Immersion in distributed virtual worlds. Educational Technology, 35(5), 46–52. Delta 3D (2008). Delta 3D open source gaming simulation engine http://www.delta3d.org/index.php. Consultado a 5 de Abril de 2009.

Demetrescu, C. e Finocchi, I. (2001). Smooth animation of algorithms in a declarative framework. Journal of Visual Languages and Computing, 12(3). Denning, P. J., (1989). A debate on teaching computing science. Communications of the ACM, 32:1397–1414. Denscombe, M. (1998). The good research guide for small-scale social research projects, Open University Press. DePasquale III, P. J., (2003). Implications on the Learning of Programming Through the Implementation of Subsets in Program Development Environments. PHD Thesis, Blacksburg, Virginia. Desai, C., Janzen, D. S. e Clements, J. (2009). Implications of integrating test-driven development into CS1/CS2 curricula. In SIGCSE ’09: Proceedings of the 40th ACM technical symposium on Computer science education, pages 148–152, New York, NY, USA, 2009. ACM.

244

Di Blas, N., Poggi, C. e Reeves, T. C. (2006). Collaborative learning in a 3D virtual environment: design factors and evaluation results. In Proceedings of the 7th international Conference on Learning Sciences (Bloomington, Indiana, June 27 - July 01, 2006). International Conference on Learning Sciences. International Society of the Learning Sciences, 127-133. Dias, P. (2004). Desenvolvimenyto de objectos de aprendizagem para plataformas colaborativas. In X. Barrientos, V. Zuñiga, J. Ortiz, L. Isaías, S. Guerra, R. Garza, M. Cantú e S. Hinojosa (Org.), Actas do VII Congeso Iberoamericano de Informática Eductiva. Monterrey: Universidade de Monterrey, (pp. 3-12). Dick, B. (2000) A beginner's guide to action research [On line]. Disponível em http://www.scu.edu.au/schools/gcm/ar/arp/guide.html . Consultado a 5 de Março de 2008. Dickey, M. D. (2003). Teaching in 3D: Pedagogical affordances and constraints of 3D virtual worlds for synchronous distance learning. Distance Education, 24(1), 105 – 121. Dickey, M. D. (2004). An architectural perspective for the design of educational virtual environments. Journal of Visual Literacy, 24(1), 49 – 66. Dickey, M. D. (2005). Three-dimensional virtualworlds and distance learning: two case studies of ActiveWorlds as amedium for distance education. British Journal of Educational Technology, 36, 3, 439–451. Diehl, S. (2007). Software visualization: Visualizing the Structure, Behaviour, and Evolution of Software. Springer New York. Dijkstra, E. W. (1989). On the Cruelty of Really Teaching Computing Science. In Communications of ACM, Issue 12, (vol.32), 1398-1404. Dingle, A., Zander, C. (2000). Assessing the ripple effect of CS1 language choice. In Proceedings of the 2nd Annual CCSC Computing in Small Colleges Northwestern Conference, pages 85–93. Consortium for Computing Sciences in Colleges, Duch, B. (2001). Writing Problems for Deeper Understanding. In B. Duch, S. E. Groh, & D. E. Allen (Eds.) The power of problem-based learning: A practical “how to” for teaching undergraduate courses in any discipline (pp. 47-53). Sterling, Virginia, 2001, Stylus Publishing Duck, B., Gron, S. e Allen, D. (ed), (2001). The power of Problem-Based Learning. A practical “How to” for teaching undergraduate courses in any discipline. Stylus Publishing, LLC. Dutta, K. (1985). Modular programming in C: an approach and an example. SIGPLAN Not. 20, 3 (Mar. 1985), 9-15. E-Arbitration-T (2008). e-Justice Centre, ODR in Second Life. http://www.e-arbitrationt.com/2008/02/28/e-justice-centre-odr-insecond-life/ Consultado a 7 de Setembro de 2009.

245

Eckstein, J. (2001). Learning to Teach and Learning to Learn. Proceedings of EuroPLoP 2000, UKV Konstanz. Edirisingha, P., Nie, M., Pluciennik, M. and Young, R. (2009). Socialisation for learning at a distance in a 3-D multi-user virtual environment. British Journal of Educational Technology. 40(3), 458-479 Edwards, S., Bruce C. (2000). Reflective internet searching, an action research model, in Ortrun Zuber-Skerrit (Ed). Action Learning, Action Research and Process Management, Theory, Practice, Praxis. Action Research Unit, Griffith University, 5th World Congress of Action Learning, Action Research and Process Management, University of Ballarat, Victoria, September, pp. 141-152 Ericsson, K. A. e Simon, H. A. (1984). Protocol analysis: Verbal reports as data. Cambridge: MIT Press. Esteves, M. and Mendes, A. (2003). OOP-Anim, a system to support learning of basic object oriented programming concepts. In Proceedings of the 4th international Conference Conference on Computer Systems and Technologies: E-Learning (Rousse, Bulgaria, June 19 - 20, 2003). B. Rachev and A. Smrikarov, Eds. CompSysTech '03. ACM, New York, NY, 573-579. Esteves, M. and Mendes, A. (2004). A Simulation Tool to Help Learning of Object Oriented Programming Basics. In Proceedings of the 34th ASEE/IEEE Frontiers in Education Conference, Savannah, Georgia, USA, October 2004, 20-23 Esteves, M., e Mendes, A., (2004). A Simulation Tool to Help Learning of Object Oriented Programming Basics. In Proceedings of the 34th ASEE/IEEE Frontiers in Education Conference. Savannah, Georgia, USA, October 2004, 20-23. Esteves, Micaela; Fonseca, Benjamim; Morgado, Leonel; Martins, Paulo (2008). Contextualization of Programming Learning: A Virtual Environment Study. In Proceedings of the 38th ASEE/IEEE Frontiers in Education Conference, October 22 – 25, 2008, Saratoga Springs, NY, pp. 17-22, ISBN 978-1-4244-1970-8. Washington, DC, USA: IEEE. Everquest (2006), Everquest Web site, consultado http://eqplayers.station.sony.com/index.vm , a 30 Outubro, 2006. em

Expresso, (2007). Mundo virtual dá “asas” a deficientes. Disponível em http://aeiou.expresso.pt/mundo-virtual-da-asas-a-deficientes=f95680 consultado a 20 de Setembro de 2010 Farquhar, M. (2000). Reflexions of a founding member of ALARPM: an interview with Ortun Zuber-Skerritt. In Action Learning, Action Research and Process Management: Theory, Practice, Praxis, Action Research Unit. Faculty of Education, Griffith University, Brisbane. Feldman, M. B., (1992). Ada experience in the undergraduate curriculum. Communications of the ACM, 35(11):53–67.

246

Fenwick, J. B., Norris, C., Barry, F. E., Rountree, J., Spicer, C. J., and Cheek, S. D. (2009). Another look at the behaviors of novice programmers. In Proceedings of the 40th ACM Technical Symposium on Computer Science Education (Chattanooga, TN, USA, March 04 - 07, 2009). SIGCSE '09. ACM, New York, NY, 296300. Figueiredo, A. D. (2001). Novos Media e Nova Aprendizagem. In Textos da Conferência Internacional Novo Conhecimento, Nova Aprendizagem. (pp.71-82). Lisboa: Fundação Calouste Gulbenkian. Figueiredo, A. D. and Afonso, A. P. (2006). Managing Learning in Virtual Settings: the Role of Context. Information Science Publishing Tavel, P. 2007 Modeling and Simulation Design. AK Peters Ltd. Figueiredo, António Dias de (2003). Métodos de Investigação Científica, Acetatos, Notas das aulas disponíveis em: https://www.dei.uc.pt/weboncampus/class/getmaterial.do?idclass=66&idyea r=1, Departamento de Engenharia Informática, Faculdade de Ciências e Tecnologia da Universidade de Coimbra, Portugal. Consultado a 9 de Maio de 2006 Fonseca, V. (2007). Aprender a aprender a educabilidade cognitiva. Âncora Editora. Lisboa. Forterra Systems Inc. (2004). http://www.forterrainc.com/index.php/about-us. Consultado a 15 de Março de 2009. Frei, P., Su, V., and Ishii, H. (2000). Curlybot: Designing a new class of computational toys. In the Conference on Human Factors in Computing Systems, Los Angeles, CA. 129–136. Frenzoo Limited. (2010). http://www.frenzoo.com/beta/information.php?chapter=about_us. Consultado a 15 de Março de 2010 GameSpy. (2003). Massively multiplayer online games: The past, the present, and the future. http://archive.gamespy.com/amdmmog/. Consultado a 15 de Abril de 2008. Garlick, R. and Cankaya, E. C. (2010). Using Alice in CS1: a quantitative experiment. In Proceedings of the Fifteenth Annual Conference on innovation and Technology in Computer Science Education (Bilkent, Ankara, Turkey, June 26 - 30, 2010). ITiCSE '10. ACM, New York, NY, 165-168. Garner, S. (2002). The Learning of Plans in Programming: A Program Completion Approach. In Proceedings of the international Conference on Computers in Education (December 03 - 06, 2002). ICCE. IEEE Computer Society, Washington, DC, 1053. Garner, S. (2008). The Teaching and Learning of Programming: the Use of a Technology Supported Part-Complete Solution Method. VDM Verlag.

247

Garner, S. (2009). Learning to Program from Scratch. In Proceedings of the 2009 Ninth IEEE international Conference on Advanced Learning Technologies - Volume 00 (July 15 - 17, 2009). ICALT. IEEE Computer Society, Washington, DC, 451-452. Gartner, Inc. (2007).Gartner Says 80 Percent of Active Internet Users Will Have A "Second Life" in the Virtual World by the End of 2011, April 24, 2007. Disponível em http://gartner.com/it/page.jsp?id=503861 Acedido em 29 de Março de 2009. Gee, J. P. (2003),What video games have to teach us about learning and literacy, New York: Palgrave Macmillan. Gerdt, P., Kommers, P., Looi, C. K. and Sutinen, E. (2001). Woven stories as a cognitive tool. In Cognitive Technology, LNAI 2117, pages 233–247. Gijselaers, W. H. (1996). Connecting problem-based practices with educational theory. In L. Wilerson & W, H. Gijselaers (Eds.) New Directions for Teaching and Learning, Vol 68, (pp. 13 – 21). San Francisco: Jossey Bass. Glinert, E. and Tanimoto, S. (1984). Pict: An interactive graphical programming environment. Computer 17, 11, 7–25. Goldman, K. J. (2004). A concepts-first introduction to computer science. In Proceedings of the 35th SIGCSE Technical Symposium on Computer Science Education, pages 432–436. ACM. Goldman, K., Gross, P., Heeren, C., Herman, G., Kaczmarczyk, L., Loui, M., and Zilles, C. (2010). Setting the Scope of Concept Inventories for Introductory Computing Subjects. Trans. Comput. Educ. 10, 2 (Jun. 2010), 1-29. Gomes, A. and Carmo, L. and Bigotte, E. and Mendes, A. (2006). Mathematics and programming problem solving. 3rd ELearning Conference – Computer Science Education. Coimbra, September. Gomes, A. e Mendes, A. J. (1999). A animação na aprendizagem de conceitos básicos de programação. Revista de Enseñanza y Tecnología, No. 13, pp. 22-32. Gomes, A. J. e Mendes, A. J.(2000). Suporte à aprendizagem da programação com o ambiente SICAS, in RIBIE. Gomes, A., Areias, C. M., Henriques, J., Mendes, A. (2008). Aprendizagem de programação de computadores: dificuldades e ferramentas de suporte. Revista Portuguesa de Pedagogia, Vol. 42, # 2, pp. 161-179, Julho. Gomes, A., Henriques, J., Mendes, A. J. (2008). Uma proposta para ajudar alunos com dificuldades na aprendizagem inicial de programação de computadores. Educação, Formação & Tecnologias, vol. 1 (1), Maio.

Gomes, A., Mendes, A. J. (2007). An environment to improve programming education. In B. Rachev, A. Smrikarov, and D. Dimov (Eds.), Proceedings of the

248

2007 International Conference on Computer Systems and Technologies, Bulgaria, June 14–15, 2007, ACM: New York Gotschi, T.; Sanders, I. and Galpin, V. (2003). Mental models of recursion. In Proceedings of the 34th SIGCSE Technical Symposium on Computer Science Education (Reno, Navada, USA, February 19 - 23, 2003). SIGCSE '03. ACM, New York, NY, 346-350. Gray, W. D.; Goldberg, N.C.; Byrnes, S. A. (1993), Novices and programming: Merely a difficult subject (why?) or a means to mastering metacognitive skills? Review of the book Studying the Novice Programmer, Journal of Educational Research on Computers, pp 131-140. Gries, D. (1974). What should we teach in an introductory programming course?. In Proceedings of the Fourth SIGCSE Technical Symposium on Computer Science Education SIGCSE '74. ACM, New York, NY, 81-89. Gruber, P. (2008). Bringing Abstract Concepts Alive. How to Base Learning Success on the Principles of Playing, Curiosity and In-Classroom Differentiation. In Proceedings of the 3rd international Conference on informatics in Secondary Schools - Evolution and Perspectives: informatics Education - Supporting Computational Thinking (Torun, Poland, July 01 - 04, 2008). R. T. Mittermeir and M. M. Sysło, Eds. Lecture Notes In Computer Science, vol. 5090. Springer-Verlag, Berlin, Heidelberg, 134-141. Guzdial, M. (2004a). Introduction to Computing and Programming in Python: A Multimedia Approach. Prentice Hall, Upper Saddle River, NJ. Guzdial, M. (2004b). Programming environments for novices. In Computer Science Education Research, S. Fincher and M. Petre, Eds. Taylor and Francis, London, 128–154. Guzdial, M., Kolodner, J., Hmelo, C., Narayanan, H., Carlson, D., Rappin, N., Hübscher, R., Turns, J., and Newstetter, W. (1996). Computer support for learning through complex problem solving. Commun. ACM 39, 4 (Apr. 1996), 43-45. Habbo Hotel (2006), Habbo Hotel Web site, http://www.habbohotel.co.uk/, a 30 Outubro, 2006 consultado em

Hadjerrouit, S. (1998). Java as first programming language: a critical evaluation. SIGCSE Bulletin, 30(2):43–47. Halbert, D. C. (1984). Programming by Example. Computer Science Division. Dept. of EE&CS, University of California, Berkeley, CA. PHD thesis. Hanks, B. and Brandt, M. (2009). Successful and unsuccessful problem solving approaches of novice programmers. In Proceedings of the 40th ACM Technical Symposium on Computer Science Education (Chattanooga, TN, USA, March 04 07, 2009). SIGCSE '09. ACM, New York, NY, 24-28.

249

Harper, R. (2007). Universidade de Aveiro Inaugura ilha no Second Life. No Jornalismo Porto net (JPN). http://jpn.icicom.up.pt/2007/05/25/universidade_de_aveiro_inaugura_ilha_ no_second_life.html. Consultado a 25 de Maio de 2007. Harrison, Foote. (2000). Rohnert (eds.), Pattern Languages of Program Design 4, Addison Wesley Hartmann,W., Nievergelt, J., and Riechert, R. (2001). Kara: Finite state machines, and the case for programming as part of general education. In IEEE Symposia on Human Centric Computing Languages and Environments, Stresa, Italy. 135–141. Hawi, N. (2010). Causal attributions of success and failure made by undergraduate students in an introductory-level computer programming course. Comput. Educ. 54, 4 (May 2010), 1127-1136. Haythornthwaite, C. (2006). Facilitating collaboration in online learning. JALN Journal of Asynchronous Learning Networks, Vol. 10,1 consultado em : http://www.sloanconsortium.org/publications/jaln/v10n1/v10n1_2 haythornthwaite.asp a 23 Junho de 2009. Hedin, G., Bendix, L. and Magnusson, B. (2008). Teaching Software Development Using Extreme Programming. In Reflections on the Teaching of Programming, 2008, pp.166-189. Hew, K. F. e Cheung, W. S. (2010). Use of three-dimensional (3-D) immersive virtual worlds in K-12 and higher education settings: A review of the research. British Journal of Educational Technology. 41(1). 33-55. Higgins, C. A., Gray, G., Symeonidis, P. and Tsintsifas, A. (2005). Automated assessment and experiences of teaching programming. ACM Journal on Educational Resources in Computing, 5(3):5. Hoare, C. A. R., (1969). An axiomatic basis for computer programming. Communications of the ACM, 12(10):576–580. Hofstadter, D. (1979). Gödel, Escher, Bach: an Eternal Golden Braid, Part II, Chapter 10: "Similar Levels", Basic Books. Hogan, M. and Eva, K. W. (2005). Students’ perceptions of Problem-based learning in an undergraduate medical programme. Poikela, E.; Poikela, S. (eds.). PBL in Context - Brindging work and education. p. 135 - 145. Hogger, C. J. (1990). Essentials of Logic Programming, Graduate Texts in Computer Science 1. Oxford University Press. Holt, R., Wortman, D., Barnard, D., and Cordy, J. R. (1977). SP/k: A system for teaching computer programming. Commun. ACM. 20, 5, 301–309. Howard, P. (1994). The owner's manual for the brain. Austin, TX: Leornian. Hübscher-Younger, T. and Narayanan, N. H. (2003). Constructive and collaborative learning of algorithms. SIGCSE Bull. 35, 1, 6–10.

250

Hugon, M. A., Seibel, C. (1988). Recherches impliquees. Recherches actions - lecas de l’éducation. Bruxelles : De Boeck. Hulkko, H.; Abrahamsson, P. (2005), A Multiple case study on the impact of Pair Programming on Product Quality. In ICSE’05. St. Louis, Missouri, USA, Maio pp. 15–21. Hundhausen, C. and Brown, J. (2005). What you see is what you code: A “radicallydynamic” algorithm visualization development model for novice learners. In Proceedings of the IEEE Sym-posium on Visual Languages and Human-Centric Computing (VL/HCC’05). 163–170. Hundhausen, C. D. (2002). Integrating algorithm visualization technology into an undergraduate algorithms course: Ethnographic studies of a social constructivist approach. Comput. Ed. 39, 3, 237–260. Hundhausen, C. D. e Brown, J. L. (2008). Designing, visualizing, and discussing algorithms within a CS 1 studio experience: An empirical study. Comput. Educ. 50(1), 301– 326. Hundhausen, C. D., Farley, S. F. e Brown, J. L. (2009). Can direct manipulation lower the barriers to computer programming and promote transfer of training?: An experimental study. ACM Trans. Comput.-Hum. Interact. 16, 3 (Sep. 2009), 1-40. Hundhausen, C. e Brown, J. (2007). An experimental study of the impact of visual semantic feedback on novice programming. Journal of Visual Language and Computing 18, 537–559. Hundhausen, C. e Brown, J. (2008). Designing, visualizing, and discussing algorithms within a CS 1 studio experience: an empirical study. Comput. & Educ. 50, 1, 301–326. Hundhausen, C. e Douglas, S. A. (2000). SALSA and ALVIS: A language and system for constructing and presenting low fidelity algorithm visualizations. In Proceedings of the IEEE International Symposium on Visual Languages, pages 67– 68. Hundhausen, C., Brown, J. (2007). What you see is what you code: A “live” algorithm development and visualization environment for novice learners. Journal of Visual Language and Computing, Vol. 18, 22-47. Hundhausen, C., Douglas, S. A, S., e Stasko, J. (2002). A meta-study of algorithm visualization effectiveness. Journal Vis. Lang. Comput. 13, 3, 259–290. Husic, F. T., Linn, M. C. e Sloane, K. D. (1989). Adapting Instruction to the Cognitive Demands of Learning To Program. Journal of Educational Psychology, Vol. 81, No. 4, pp. 570-583. Hwang, W. –Y., Wang, C. –Y, Hwang, G.-J, Huang Y.-M, Huang S., (2008). A webbased programming learning environment to support cognitive development. Interacting with Computers 20,6, 524-534.

251

IBM

(2007). http://domino.research.ibm.com/comm/research_projects.nsf/pages/virtual worlds.IBMVirtualWorldGuidelines.html. Consultado a 20 de Março de 2009.

Isaacson, W. (2007). Einstein: His Life and Universe. Simon &Schuster Paperbacks, Rockefeller Center. New York. Jacobs, K. (2007). Microsoft Office Excel 2007: The L Line, The Express Line to Learning (The L Line: The Express Line To Learning). Wiley; illustrated edition edition. Jacobson, M. J. (2006). Empirical research into learning in 3D virtual and game environments: selected review of the literature. Singapore: Learning Sciences Laboratory, National Institute of Education, Nanyang Technological University. Jadud, M. C (2005). A first look at novice compilation behaviour. Computer Science Education, 15, 1, 25-40. Jain, J., James, I., Cross, H., Hendrix, T. D. and Barowski, L. A. (2006). Experimental evaluation of animated-verifying object viewers for Java. In Proceedings of the 2006 ACM Symposium on Software Visualization, pages 27–36. ACM. Jarc, D. e Feldman, M. (1998). An Empirical Study of Webbased Algorithm Animation Courseware in a Ada Data Structure Course, In Proceedings of the Annual ACM SIGAda International Conference on Ada, Washington, D.C. – USA. Jenkins, T. (2002). On the difficulty of learning to program. In Proceedings of 3rd Annual LTSN_ICS Conference (Loughborough University, United Kingdom, August 27-29. The Higher Education Academy, p.53-58. Jenkins, T.(2002) On the difficulty of learning to program, in “Proceedings of the 3rd annual conference of the LTSN centre for information and computer science” (Loughborough, United Kingdom, August 27-29, 2002). Jensen, E. (1998). Teaching with the brain in mind. Alexandria, VA: ASCD. Johnsgard, K., and McDonald, J. (2008). Using ALICE in Overview Courses to Improve Success Rates in Programming I. In 21st Conference on Software Engineering Education and Training, CSEET 2008. Johnston, M. W., Hanna, J. R., Millar, R. (2004). Advances in Dataflow Programming Languages. ACM Computing Surveys, Vol. 36, No. 1, March, pp 1-34. Jonassen, D. (1999). Designing constructivist learning environments. In C. M. Reigeluth (Ed.), Instructional-design theories and models: A new paradigm of instructional theory. Vol. II. Hillsdale, NJ: Lawrence Erlbaum Associates. Jong, F. P. C. M., van der Meijden, H. e von Berg, J. (2005). 3D learning in the workplace and at school: playing, learning, or both? Educational Technology, 45, 5, 30–34.

252

JPN. (2007). UA é a primeira universidade em Portugal a marcar presença no Second Life com compra de ilha. Disponível em http://jpn.icicom.up.pt/2007/04/03/aveiro_juntase_as_70_universidades_d e_todo_o_mundo_no_second_life.html . Consultado a 9 de Setembro de 2010. Kaczmarczyk, L., Petrick, E., East, J. P., and Herman, G. L. (2010). Identifying student misconceptions of programming. In Proceedings of the 41st Annual ACM Technical Symposium on Computer Science Education (SIGCSE’10). Karavirta, V., Korhonen, A., Malmi, L. and Stlanacke, K. (2004). MatrixPro - A tool for on-the-fly demonstration of data structures and algorithms. In Proceedings of the 3rd Program Visualization Workshop, pages 26–33, The University of Warwick, UK, July. Karn, J. S. and Cowling, T. (2006). A Follow up Study of the Effect of Personality on the Performance of Software Engineering Teams. ACM ISESE’06. Kay, Alan (1993). The Early History of Smalltalk. In The second ACM SIGPLAN conference on History of programming languages. pp. 69-95, ACM Press, New York, NY, USA. Kehoe, C., Stasko, J., end Taylor, A. (2001). Rethinking the evaluation of algorithm animations as learning aids: An observational study. Int. Journal Hum.-Comput. Studies 54, 2, 265–284. Kelleher, C. (2006). Motivating Programming: using storytelling to make computer programming attractive to middle school girls. PhD Thesis, School of Computer Science, Carnegie Mellon University, Pittsburgh, Kelleher, C. e Pausch R. (2005). Lowering the Barriers to Programming: A Taxonomy of Programming Environments and Languages for Novice Programmers. ACM Computing Surveys, Vol. 37, No. 2, June 2005, pp. 83–137. Kelleher, C. Pausch, R. e Kiesler, S. (2007). Storytelling Alice Motivates Middle School Girls to Learn Computer Programming. In CHI ’07: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 1455-1464, New York, NY, 2007. Kerman, M. C. (2001). Programming and Problem Solving with Delphi. ISBN-10: 0321204417. Pearson Education; International edition Kichuk, S. L. and Wiesner, W. H. (1997). The Big Five Personality Factors and Team Performance: Implications for Selecting Successful Product Design Teams. J. of Engin. and Technol. Management. 14, pp.195-221. Kiczales, G. and Mezini, M. (2005). Aspect-oriented programming and modular reasoning. In Proceedings of the 27th international Conference on Software Engineering (St. Louis, MO, USA, May 15 - 21, 2005). ICSE '05. ACM, New York, NY, 49-58.

253

Kiili, K., (2005). Digital game-based learning: Towards an experiential gaming model. Internet and Higher Education, Vol. 8, 13-24. Kimura, T., Choi, J., and Mack, J. (1990). Show and tell: A visual programming language. In Glinert, E. P., Ed. Visual Programming Environments: Paradigms and Systems. IEEE Computer Science, 397–404. Kingsland, A. J. (1996).Time expenditure, workload, and student satisfaction in Problem-based Learning. Wilkerson, L.; Gijselaers, W.H. (Ed.). Bringing Problem-based Learning to higher education. San Francisco: Jossey-Bass Publishers. p.73-81. Knowlton, K. C.(1966). L6: Bell telephone laboratories low-level linked list language. 16 mm black and white sound film, 16 minutes, 1966 Kolb, D. A., (1984). Experimental Learning: Experience as the Source of Learning and development. Prentice Hall, England Kolikant, Y. B-D. and Mussai, M. (2008). “So my program doesn't run!” Definition, origins, and practical expressions of students' (mis)conceptions of correctness. Computer Science Education, 18, 2 (Jun. 2008), 135-151. Köling, M., Quig, B., Patterson, A. and Rosenberg, J. (2003). The BlueJ system and its pedagogy. Computer Science Education, 13. Kolling, M. and Rosenberg, J. (1996). Blue—A language for teaching objectoriented programming. In Proceedings of the 27th SIGCSE Technical Symposium on Computer Science Education. Philadelphia. pp. 190–194. Kollock, P. (1998) Design Principles for Online Communities. Annual Review of Sociology. PC Update 15(5): 58-60. June 1998. Kopec, D., Yarmish, G., and Cheung, P. (2007). A description and study of intermediate student programmer errors. SIGCSE Bull. 39, 2 (Jun. 2007), 146156. Koster, R. (2002). Online world timeline. http://www.raphkoster.com/gaming/mudtimeline.shtml. Consultado a 15 de Março de 2009 Kujansuu, E. and Kulmala, M. (2003). Codewitz: producing interactive elearning material for beginners in programming. In Proceedings of the 8th Annual Conference on innovation and Technology in Computer Science Education (Thessaloniki, Greece, June 30 - July 02, 2003). D. Finkel, Ed. ITiCSE '03. ACM, New York, NY, 266-266. Kumar, A. (2005). Results from the evaluation of the effectiveness of an online tutor on expression evaluation. In Proceedings of the 36th SIGCSE Technical Symposium on Computer Science Education (SIGCSE’05). 216–220. Kurhner, D. (2008). Make your very own virtual world with OLIVE. IEEE Spectrum, 45(1). 37-39.

254

Kurtz, T. (1981). In Wexelblat, R., Ed. BASIC- History of Programming Languages. Academic Press, New York, 515–537. Laakso, M., Myller, N. and Korhonen, A. (2009). Comparing Learning Performance of Students Using Algorithm Visualizations Collaboratively on Different Engagement Levels. Journal Ed. Technol. Soc. 12, 2, 267-282 Lahtinen, E., Mutka, K. A., and Jarvinen, H. M (2005). A Study of the difficulties of novice programmers, in “Proceedings of the 10th annual SIGSCE conference on Innovation and technology in computer science education (ITICSE 2005)” (Monte da Caparica, Portugal, June 27-29, 2005). ACM Press, New York, NY, pp. 14-18. Lahtinen, E., Mutka, K. A., and Jarvinen, H. M. (2005). A Study of the difficulties of novice programmers. In Proceedings of the 10th annual SIGSCE conference on Innovation and technology in computer science education (ITICSE 2005). Monte da Caparica, Portugal, June 27-29, 2005, ACM Press, New York, NY, pp. 14-18. Lahtinen, T. (2005). Implementation of Problem-based Learning in Engineering Education- PBL curriculm in mechatronics. Poikela, E.; Poikela, S. (eds.). PBL in Context - Brindging work and education. p. 79- 95. Laird, J. (2001), Using a computer game to develop advanced AI, Computer, 34(7):70-75, July 2001. Lappalainen, V., Itkonen, J., Isomöttönen, V., and Kollanus, S. (2010). ComTest: a tool to impart TDD and unit testing to introductory level programming. In Proceedings of the Fifteenth Annual Conference on innovation and Technology in Computer Science Education (Bilkent, Ankara, Turkey, June 26 - 30, 2010). ITiCSE '10. ACM, New York, NY, 63-67. Larkin-Hein, T. (2001). On-line discussions: a key to enhancing student motivation and understanding?. In Proceedings of the Frontiers in Education Conference, 2001. 31st Annual - Volume 02 (FIE '01), Vol. 2. IEEE Computer Society, Washington, DC, USA, F2G-6-F2G-12vol.2. Larman, C. and Basili, V. R. (2003). Iterative and incremental development: A brief history. Computer, 36(6):47–56, 2003. Laurillard, D. (2002). Rethinking teaching for the knowledge society, EDUCAUSE, Consultado em: http://www.educause.edu/ir/library/pdf/ERM0201.pdf, a 24/11/2008. Lave, J., and Wenger, E. (1991). Situated learning: Legitimate peripheral participation. Cambridge, MA: Cambridge University Press. Lawrence, A., Badre, A., and Stasko, J. (1994). Empirically evaluating the use of animations to teach algorithms. In Proceedings of the IEEE Symposium on Visual Languages (VL’94). 48–54.

255

Lemieux, F. and Salois, M. (2006). Visualization Techniques for Program ComprehensionA Literature Review. In Proceeding of the 2006 Conference on New Trends in Software Methodologies, Tools and Techniques: Proceedings of the Fifth Somet_06 H. Fujita and M. Mejri, Eds. Frontiers in Artificial Intelligence and Applications, vol. 147. IOS Press, Amsterdam, The Netherlands, 22-47 Lemos, R. S. (1979). Teaching programming languages: A survey of approaches. In Proceedings of the Tenth SIGCSE Technical Symposium on Computer Science Education SIGCSE '79. ACM, New York, NY, 174-181. Lessard-Hebert, M., Goyette, G., and Boutin, G. (1990). Recherche qualitative: fondements et pratiques. Montréal: Agence d’ARC. Lester, C. K. (2007). Jubilation: Programming with Euphoria 4.0 a ebook disponível em http://www.usingeuphoria.com/books/jubilation/?entirebook Consultado a 4/4/2008. Lethbridge, C.; Diaz-Herrera, J.; LeBlanc, Jr.; Thompson, B. (2007). Improving software practice through education: Challenges and future trends. Future of Software Engineering, (FOSE apos;07),May 2007 Page(s):12 – 28. Lewin, K. (1946). Action research and minority problems. Journal of Social Issues, Vol. 2 No. 4, pp. 34-6. Lieberman, H., ed.(2001). Your wish is My Commend. Morgan Kaufmann: San Francisco. Lim, C. P., Nonis, D. e Hedberg, J. (2006). Gaming in a 3D multiuser virtual environment: engaging students in science lessons. British Journal of Educational Technology, 37, 2, 211–231. Linn, M. C.; Sloane, K. D. e Clancy, M. J. (1987). Ideal and actual outcomes from precollege Pascal instruction. Journal of Research in Science Teaching. 25, 5, 467490 Lister, R., Adams, Elizabeth S., Fitzgerald, S., Fone, W., Hamer, J., Lindholm, M., McCartney, R., Moström, Jan Erik, Sanders, K., Seppälä, O., Simon, B., Thomas, L. (2004). A multi-national study of reading and tracing skills in novice programmers. ACM SIGCSE Bulletin, v.36 n.4. Lister, R., Clear, T.; Simon, Bouvier, Dennis J.; Carter, P.; Eckerdal, A.; Jacková, J.; Lopez, M.; McCartney, R.; Robbins, P.; Seppälä, O. e Thompson, E. (2010). Naturally occurring data as research instrument: analyzing examination responses to study the novice programmer. SIGCSE Bull. 41, 4 (January 2010), 156-173. Lister, R., Leaney, J., (2003). First year programming: let all the flowers bloom. In Proceedings of the 5th Australasian Computer Education Conference.

256

Lohr, S. (2007) Free the Avatars, The New York Times. Disponível em http://bits.blogs.nytimes.com/2007/10/10/free-the-avatars/ acedido a 29 de Março de 2009. Lukas, G. (1972). Uses of the LOGO Programming Language in Undergraduate Instruction. In Proceedings of the ACM Annual Conference (New York, New York, 1972), Association for Computing Machinery, pp. 1130-1136. Ma, L., Ferguson, J., Roper, M., and Wood, M. (2007). Investigating the viability of mental models held by novice programmers. In Proceedings of the Thirty-Eighth SIGCSE Technical Symposium on Computer Science Education (Covington, Kentucky, United States, March 07 - 11, 2007). SIGCSE '07. Malmi, L., Karavirta, V., Korhonen, A., Nikander, J., Seppälä, O. and Silvasti, P. (2004) Visual algorithm simulation exercise system with automatic assessment: TRAKLA2. Informatics in Education, 3(2):267 – 288. Manninen, T. (2004). Rich Interaction Model for Game and Virtual Environment Design, Academic Dissertation, Department of Information Processing Science, University of Oulu, Oulu, Finland. Martins, S. W., Mendes, A. J., and Figueiredo, A. D. (2010). Diversifying activities to improve student performance in programming courses. In Proceedings of the 11th international Conference on Computer Systems and Technologies and Workshop For PhD Students in Computing on international Conference on Computer Systems and Technologies (Sofia, Bulgaria, June 17 - 18, 2010). B. Rachev and A. Smrikarov, Eds. CompSysTech '10. ACM, New York, NY, 540-545. MathWorks (1994). Accelerating the pace of engineering and science (1994 – 2009) – site oficial disponível em :http://www.mathworks.com consultada em Março 2009 Maurice Vincent Wilkes. (2009). In Encyclopædia Britannica. Consultado a 22 de Outubro de 2009, em Encyclopædia Britannica Online: http://www.britannica.com/EBchecked/topic/725595/Maurice-VincentWilkes Mayer, R. E. (1981). The Psychology of How Novices Learn Computer Programming. ACM Comput. Surv. 13, 1 (Mar. 1981), 121-141. McAndrew, P., Goodyear, P., and Dalziel, J. (2006). Patterns, designs and activities: unifying descriptions of learning structures. Int. J. Learn. Technol. 2, 2/3 (Aug. 2006), 216-242. McCracken, D. (1973) Is there a FORTRAN in your future? Datamation (May 1973), vol. 19, pp.236-237.

257

Mccracken, M., Almstrum, V., Diaz, D., Guzdial, M., Hagan, D., Kolikant, Y. B.-D., Laxer, C., Thomas, L., Utting, I., and Wilusz, T. (2001). A multi-national, multi-institutional study of assessment of programming skills of first-year CS students. In Proceedings of Working Group Reports on Innovation and Technology in Computer Science Education (ITiCSE-WGR’01). 125–180. Mcdowell, C., Werner, L., Bullock, H. E., and Fernald, J. (2006). Pair programming improves student retention, confidence, and program quality. Comm. ACM 49, 8, 90–95. Mclver, L.; Conway, D. (1996). Seven Deadly Sins of Introductory Programming Language Design. In Proceedings of the 1996 International conference on Software Engineering Education and Practice. Pag. 309-316. Melnik, G. and Maurer, F. (2005). A cross-program investigation of students’ perceptions of agile methods. In ICSE ’05: Proceedings of the 27th international conference on Software engineering. pages 481–488, New York, NY, USA, 2005. ACM. Mendes, António J. (2002). Software Educativo para Apoio à Aprendizagem de Programação. 2002. Disponível em: http://www.c5.cl/ieinvestiga/actas/tise01/pags/ charlas/charla_mendes.htm. (consultado a 13/9/2006). Messinger, P., Stroulia, E. e Lyons, K. (2008). A Typology of VirtualWorlds: Historical Overview and Future Directions. Journal of VirtualWorlds Research, 1(1). Consultado em 11 de Dezembro de 2008, em http://journals.tdl.org/jvwr/article/view/291 Mierlus, I. (2007). Learning Programming Languages Using Visualizations. Fourth International Conference on eLearning for Knowledge-based Society, November Bangkok, Thailand, 25-32. Miliszewska, I. e Tan, G. (2007). Befriending computer programming: A proposed approach to teaching introductory programming. Journal of Issues in Informing Science & Information Technology. 4, 277–289. Miller, P. e Chandhok, R. (1989). The design and implementation of Pascal Genie. In Proceedings of the ACM Computer Science Conference. Louisville, KY. Milne, I. and Rowe, G. (2002). Difficulties in Learning and Teaching Programming—Views of Students and Tutors. Education and Information Technologies 7, 1 (Mar. 2002), 55-66. Miranda, C., Morais, C. E, Dias, P. (2007). Colaboração em ambientes online na resolução de tarefas de aprendizagem. In P. Dias, C. Freitas, B. Silva, A. Osório, e A. Ramos (Orgs.) Actas de V Conferência Internacional de Tecnologias de Informação e Comunicação na Educação, pp. 576-585. Braga: Centro de Competências da Universidade do Minho. Miranda, L. (2005). Educação online: Interação e estilos de aprendizagem de alunos do ensino superior numa plataforma Web. Braga: Universidade do Minho.

258

Mitchell, Alice and Savill-Smith, Carol. (2004). The use of computer and video games for learning - a review of the literature. Published by the Learning and skills Development Agency. Consultado no endereço: https://www.lsnlearning.org.uk/search/Resource-32183.aspx em 23/10/2007 Mitchell, John C. (2002). Concepts in Programming Languages. Cambridge University Press. Cambridge, UK. Moreno, A. and Joy, M. S. (2007). Jeliot 3 in a Demanding Educational Setting. Electron. Notes Theor. Comput. Sci. 178 (Jul. 2007), 51-59. Moreno, A., Myller, N., and Sutinen, E. (2004). JeCo, a Collaborative Learning Tool for Programming. In Proceedings of the 2004 IEEE Symposium on Visual Languages - Human Centric Computing (September 26 - 29, 2004). VLHCC. IEEE Computer Society, Washington, DC, 261-263. Moreno, A., Myller, N., Ben-Ari, M., and Sutinen, E. (2004). Program animation in jeliot 3. In Proceedings of the 9th Annual SIGCSE Conference on innovation and Technology in Computer Science Education (Leeds, United Kingdom, June 28 - 30, 2004). ITiCSE '04. ACM, New York, NY, 265-265. Moreno, A., Myller, N., Sutinen, E. and Ben-Ari, M.(2004). Visualizing programs with Jeliot 3. In Proceedings of the Working Conference on Advanced Visual Interfaces, pages 373–376. ACM. Morgado, L. (2009). Interconnecting virtual worlds. Journal of Virtual Worlds Research, 1(3). Consultado a 10 de Abril de 2009, em http://journals.tdl.org/jvwr/article/view/469/430 Morningstar, C. e Farmer, F. R. (1991). The Lessons of Lucasfilm's Habitat, Published in Cyberspace: First Steps, Michael Benedikt (ed.), MIT Press. Motil, J. and Epstein, D. (2000). JJ: a Language Designed for Beginners (Less Is More). Consultado em http://www.ecs.csun.edu/jmotil/TeachingWithJJ.pdf a 2 de Março de 2007. Murphy, L.; Lewandowski, G.; McCauley, R.; Simon, B.; Thomas, L. and Zander, C. (2008). Debugging: the good, the bad, and the quirky – a qualitative analysis of novices' strategies. In SIGCSE '08: Proceedings of the 39th SIGCSE technical symposium on Computer science education, pages 163-167. Myers, B. A.(1990). Taxonomies of Visual Programming and Program Visualization. Journal of Visual Languages and Computing, Mar. 1(1). Pp. 97-123. Myers, B. A., Ko, A. J., and Burnett, M. M. (2006). Invited research overview: enduser programming. In CHI '06 Extended Abstracts on Human Factors in Computing Systems (Montréal, Québec, Canada, April 22 - 27, 2006). CHI '06. ACM, New York, NY, 75-80.

259

Myller, N., Bednarik, R., Sutinen, E., and Ben-Ari, M. (2009). Extending the Engagement Taxonomy: Software Visualization and Collaborative Learning. Trans. Comput. Educ. 9, 1 (Mar. 2009), 1-27. Myller, N., Laakso, M., and Korhonen, A. (2007). Analyzing engagement taxonomy in collaborative algorithm visualization. In Proceedings of the 12th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education (ITiCSE’07), J. Hughes, D. R. Peiris, and P. T. Tymann Eds. ACM Press, 251–255. Nagappan, N., Williams, L., Ferzli, M., Wiebe, E., Yang, K., Miller, C., and Balik, S. (2003). Improving the CS1 experience with pair programming. In Proceedings of the 34th SIGCSE Technical Symposium on Computer Science Education (SIGCSE’03). ACM Press, 359–362. Naps, T. L. (2005). JHAVÉ – Supporting Algorithm Visualization. IEEE Computer Graphics and Applications, 25(5):49–55. Naps, T. L. and Rößling, G. (2007). JHAVÉ - More Visualizers (and Visualizations) Needed. In Rößling, G. Ed. Proceedings of the Fourth Program Visualization Workshop. Electronic Notes in Theoretical Computer Science, 178, 4 (2007), 33-41. Naps, T. L., Rößling, G., Almstrum, V., Dann, W., Fleischer, R., Hundhausen, C., Korhonen, A., Malmi, L., McNally, M., Rodger, S., and Velázquez-Iturbide, J. Á. (2002). Exploring the role of visualization and engagement in computer science education. In Working Group Reports From ITiCSE on innovation and Technology in Computer Science Education (Aarhus, Denmark, June 24 - 28, 2002). ITiCSE-WGR '02. ACM, New York, NY, 131-152. Neville, B. (1992). Research as consultant: consultant as researcher – a phenomenological experiential model of action research. A Quarterly Experience, Vol. 28, pp. 33-9. Nguyen, Q. V., Huang, M. L., and Hawryszkiewycz, I. (2004). A New Visualization Approach for Supporting Knowledge Management and Collaboration in ELearning. In Proceedings of the information Visualisation, Eighth international Conference (July 14 - 16, 2004). IV. IEEE Computer Society, Washington, DC, 693-700. Norman, G. R., e Schmidt, H. G. (1992). The psychological basis of problem-based learning: A review of the evidence. Academic Medicine, 67(9), 557-565. Noyes, J. M., e Garland, K. J. (2003). Solving the Tower of Hanoi: Does mode of presentation matter? Computers in Human Behavior. 19, 579–592 O'Brien, S. K. e Nameroff, S. (1993). Turbo Pascal 7: The Complete Reference. McgrawHill Osborne Media.

260

O'Kelly, J. and Gibson, J. P. (2006). RoboCode & problem-based learning: a nonprescriptive approach to teaching programming. In Proceedings of the 11th Annual SIGCSE Conference on innovation and Technology in Computer Science Education (Bologna, Italy, June 26 - 28, 2006). ITICSE '06. ACM, New York, NY, 217-221. Olimpo, G. (1988). The Robot Brothers: An environment for learning parallel programming oriented to computer education. Computers & Education, Vol.12, No 1, pp. 113-118. Olimpo, G., Persico, D., Sarti, L. e Tavella, M. (1985). An experiment in introducing the basic concepts of informatics. In Proceedings of the Fourth World Conference on Computers in Education. pp. 31-38, K. Dunkan and D. Harris(Eds.). Amsterdam. Oliver, M. y Carr, D. (2009). Learning in virtual worlds: Using communities of practice to explain how people learn from play. British Journal of Educational Technology. 40(3), 444 – 457. Omale, N., Hung, Wei-Chen, Luetkehans, L. and Cooke-Plagwitz, J. (2009). Learning in 3-D multiuser virtual environments: Exploring the use of unique 3-D attributes for online problem-based learning. British Journal of Educational Technology, 40,3, 480-495. OpenCroquet, (2008). Open Croquet project. http://c2.com/cgi/wiki?OpenCroquet. Consultado a 2 de Abril de 2009. OpenSimulator (2009). http://opensimulator.org/wiki/Main_Page. Consultado a 6 de Setembro de 2010. Overmars, M. (2000). Drape: Drawing programming environment. Disponível no seguinte endereço: http://www.cs.uu.nl/people/markov/kids. Palloff, R. E Pratt, K. (2005). Collaborating online: Learning together in community. San Francisco: Jossey-Bass. Palumbo, D., (1990). Programming language/problem-solving research: a review of relevant issues. Review of Educational Research, 60(1):65–89. Panda 3D (2008). Panda 3D game engine http://www.panda3d.org. Consultado a 5 de Abril de 2009. Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas, 1st ed. Basic Books, Inc., New York, New York, 1980 Papert, S. (1996). The connected family: Bridging the digital generation gap. Atlanta, Georgia, Longstreet Press. Papert, Seymour M. (1980). Mindstorms: Children, Computers, and Powerful Ideas. New York: Basic Books.

261

Papka, M. E. (2009). Visualization and Collaboration Technologies to Support HighPerformance Computing Research. Doctoral Thesis. UMI Order Number: AAI3350887., University of Chicago. Pareja-Flores, C., Urquiza-Fuentes, J., and Velázquez-Iturbide, J. (2007). WinHIPE: An IDE for functional programming based on rewriting and visualization. SIGPLAN Notes 42, 3, 14–23. Passfield, R. (2000) Anticipatory action learning: Perceiving the future through the eyes of our children. International Journal of Action Learning, 1(3), 81-84. Pattis R. E., Roberts, J. and Stehlik, M. (1981). Karel the Robot: A Gentle Introduction to the Art of Programming. John Wiley & Sons, Inc., New York, NY, USA, 1981 Pattis, R.E. (1995). Karel the Robot: A Gentle Introduction to the Art of Programming, 2nd ed., Wiley. Pavlov, I. P. (1927). Conditioned Reflexes: An Investigation of the Physiological Activity of the Cerebral Cortex. Translated and Edited by G. V. Anrep. London: Oxford University Press. Pears, A., Seidman, S., Malmi, L., Mannila, L., Adams, E., Bennedsen, J., Devlin, M., and Paterson, J. (2007). A survey of literature on the teaching of introductory programming. In Working Group Reports on ITiCSE on innovation and Technology in Computer Science Education (Dundee, Scotland, December 01 - 01, 2007). J. Carter and J. Amillo, Eds. ITiCSE-WGR '07. ACM, New York, NY, 204-223. Pereira, A.; Mendes, A. Q.; Mota, J. C.; Morgado, L. e Aires, L.L. (2003). Contributos para uma pedagogia do ensino online pós-graduado: proposta de um modelo. Discursos, Série Perspectivas em Educação, nº1, pp. 39-53. Pereira, D. C. (2007). Nova Educação na nova ciência para a nova sociedade, Fundamentos de uma pedagogia cientifica contemporânea. Vol I. Editora da Universidade do Porto, Série do Saber,4. Pereira, M. J. and Henriques, P. R. (2003). Visualization/animation of programs in Alma: obtaining different results. In Proceedings of the 2003 IEEE Symposium on Human Centric Computing Languages and Environments (October 28 - 31, 2003). HCC. IEEE Computer Society, Washington, DC, 260-262 Perkins, D. N., Schwartz, S. and Simmons, R.; (1988). Instructional Strategies for the Problems of Novice Programmers. In R. E. Mayer (ed.), Teaching and Learning Computer Programming, p.153-178. Hillsdale, NJ: Lawrence Erlbaum Associates. Perraudeau, M. (2000). Os métodos cognitivos em educação. Aprender de outra forma na escola. Instituto Piaget. Lisboa. Peterson, M. (2006). Learner interaction management in an avatar and chat-based virtual world. Computer Assisted Language Learning, 19, 1, 79–103. Piaget, J. (1973). Seis estudos de psicologia. Lisboa, Dom Quixote.

262

Piaget, J. (1976). A Equilibração das estruturas cognitivas. Rio de Janeiro: Zahar Editores. Piaget,J., (1977). O desenvolvimento do pensamento. Dom Quixote, Lisboa. Piajet, J. (1973). Seis estudos de psicologia. Dom Quixote, Lisboa. Pierce, J. S., Christiansen, K., Cosgrove, D., Conway, M., Moskowitz, D., Stearns, B., Sturgill, C., and Pausch, R. (1998). Alice: easy to learn interactive 3D graphics. In CHI 98 Conference Summary on Human Factors in Computing Systems (Los Angeles, California, United States, April 18 - 23, 1998). CHI '98. ACM, New York, NY, 26-27. Pierson, W. C. and Rodger, S. H. (1998). Web-based animation of data structures using JAWAA. In Proceedings of the Twenty-Ninth SIGCSE Technical Symposium on Computer Science Education (Atlanta, Georgia, United States, February 26 March 01, 1998). D. Joyce and J. Impagliazzo, Eds. SIGCSE '98. ACM, New York, NY, 267-271. Pillay, N. (2003). Developing intelligent programming tutors for novice programmers. SIGCSE Bull. 35, 2 (Jun. 2003), 78-82. Pita, Sara T. O. (2008). As interacções no Second Life: a comunicação entre avatares. Prisma.com 6, ISSN 1646-3153, 19-31. Poikela, E. (2004). Developing criteria for knowing and learning atwork: towards context-based assessment. Journal of Workplace Learning, 16, 5, 267–274. Porter, C. E. (2004). A typology of virtual communities: a multi-disciplinary foundation for future research. Journal of Computer-Mediated Communication, 10, 1, Article 3. Powers, K., Ecott, S., and Hirshfield, L. (2007). Through the Looking Glass: Teaching CS0 with Alice. 38th SIGCSE Technical Symposium on Computer Science Education, pp. 213-217, 2007. Preece, J. (2000) Online Communities - Designing Usability, supporting sociability. Chichester: John Wiley & Sons, 439 p, 2000. Prensky M (2001), Digital game-based learning, New York: McGraw-Hill. Price, B. A., Baecker, Ronald M. and Small, Ian S. (1993). A principled taxonomy of software visualization. Journal of Visual Languages and Computing, 4(3):211– 266. Quilici, A. E. E Miller, L. H. (1989). The Turbo C(r) Survival Guide. John Wiley & Sons; 1 edition. Raine, D. and Symons, S. (2005). Experiences of PBL in physics in UK higher education. Poikela, E.; Poikela, S. (eds.). PBL in Context - Brindging work and education. p. 67-79.

263

Ralston, A. (1971). Fortran and the first course in computer science. SIGCSE Bulletin, 3(4):24–29. Ramadhan, H. A. (2000). Programming by discovery. Journal of Computer Assisted Learning, 16, 83-93. Rebelo, B. (2007). SICAS-COL - Um Sistema Colaborativo para Aprendizagem Inicial da Programação. Tese de Mestrado, Universidade de Coimbra – Departamento de Engenharia Informática, Janeiro. Rebelo, B. and Mendes, A. and Marcelino, M. and Redondo, M.(2005). Sistema Colaborativo de Suporte à Aprendizagem em Grupo da Programação – SICAS-COL. VII Simpósio Internacional de Informática Educativa. Leiria, Novembro 2005. Rebelo, B., Marcelino, M. J., Mendes, A. J. (2005). Evaluation and utilization of SICAS – a system to support algorithm learning, In Proceedings of CATE05 – Computers and Advanced Technology in Education, Oranjestad, Aruba, August, 2005. Redondo, M., Bravo, C., Ortega, M., Verdejo, M., (2002). PlanEdit: An adaptive tool for design learning by problem solving. In P. De Bra, P. Brusilovsky y R. Conejo (Eds.), Adaptive Hypermedia and Adaptive Web Based-Systems, 2nd International Conference of Adaptive Hypermedia and Adaptive Web- Based Systems, pp. 560-563. Reges, S. (2006). Back to basics in CS1 and CS2. In Proceedings of the 37th SIGCSE Technical Symposium on Computer Science Education, pages 293–297. ACM Press, Reis, C. and Cartwright, R. (2004). Taming a Professional IDE for the Classroom. In SIGCSE’04, (Norfolk, Virginia, USA, 2004), ACM, 156-160. Reis, F. L. (2008). Formas de comunicação no ensino e-learning. Pensamento Plural: Revista Científica do UNIFAE, São João do Boa Vista, V.2, n. 2 pp 5-15. Rekkedal T. (1983). The written assignments in correspondence education. Effects of reducing turnaround time. Distance Education, 4, 231-250 Reuters. (2003). Video game hones US soldiers’ fighting skills, The Straits Times, May 17 2003 Reynolds, A. (1992). What is competent beginning teaching? A review of the literature. Review of Educational Research, 62 (1), 1-35. Riding, R. J. (1980). Aprendizagem escolar – Mecanismos e processos. Lisboa. Ed. Livros Horizonte. Rijo, R. (2008). Framework para a Gestão de Projectos de Sistemas de Informação de Contact Centers. Tese de doutoramento. Robbert, M. A. (2000). Enhancing the value of a project in the database course. SIGCSE Bull. 32, 1 (Mar. 2000), 36-40.

264

Robbins, S. (2007). A futurist’s view of Second Life education: a developing taxonomy of digital spaces. In D. Livingstone & J. Kemp (Eds), Proceedings of the Second Life EducationWorkshop 2007 (pp. 27–33). Chicago, IL. Consultado a 5 de Maio de 2008, em www.simteach.com/slccedu07proceedings.pdf Roberts, E. S. (1993). Using C in CS1: evaluating the Stanford experience. In Proceedings of the 24th SIGCSE Technical Symposium on Computer Science Education, pages 117–121. ACM Press. Robins, A., Rountree, J., and Rountree, N., (2003). Learning and teaching programming: a review and discussion. Computer Science Education, 13(2):137– 172. RöBling, G. e Freisleben, B. (2001). AnimalScript: An Extensible Scripting Language for Algorithm Animation, In Proceedings of the 32nd SIGCSE Technical Symposium on Computer Science Education. Charlotte, NC USA. RöBling, G., Joy, M., Moreno, A., Radenski, A., Malmi, L., Kerren, A., Naps, T., Ross, R.J., Clancy, M., Korhonen, A., Oechsle, R. e Iturbide, J. A. (2008). Enhancing learning management systems to better support computer science education. SIGCSE Bull. 40, 4 (November 2008), 142-166. Rocha, A. A. (2006). Introdução à Programação usando C. Lidel- edições técnicas, lda. Rocha, A. A. (2008). Estruturas de dados e algoritmos em C. Lidel- edições técnicas, lda. Rodger, S. H., Bashford, M., Dyck, L., Hayes, J., Liang, L., Nelson, D., and Qin, H. (2010). Enhancing K-12 education with alice programming adventures. In Proceedings of the Fifteenth Annual Conference on innovation and Technology in Computer Science Education (Bilkent, Ankara, Turkey, June 26 - 30, 2010). ITiCSE '10. ACM, New York, NY, 234-238. Rodrigo, M. M. T., Baker, R. S. J., Sugay, J. O. and Tabanao E. (2009). Monitoring novice programmer effect and behaviours to identify learning bottlenecks. In Philippine Computing Society Congress: Research-in-Progress, March 2009. Rosedale, Philip; Ondrejka, Cory R. (2003). Enabling Player-Created Online Worlds with Grid Computing and Streaming. Gamasutra. Consultado em 27 de Maio de 2009 em http://www.gamasutra.com/resource_guide/20030916/rosedale_01.shtml Rößling, G. and Naps, T. L. (2002). A Testbed for Pedagogical Requirements in Algorithm Visualizations. Proceedings of the 7th Conference on Innovation and Technology in Computer Science Education (ITiCSE 2002). (Århus, Denmark).ACM Press, New York, NY, USA, 2002, 96-100. Roubidoux, M. A., Chapman, C. M., Piontek, M. E. (2002). Development and evaluation of an interactive web-based breast imaging game for medical students. Academic Radiology, 9 (10), 1169-1178. Roy, P. V. e Haridi, S. (2003). Concepts, Techniques, and Models of Computer Programming. The MIT Press, Cambridge, Massachusetts, London, England.

265

Rymaszewski, M., Au, W. J., Wallace, M. Winters, C., Ondrejka, C., Cunningham, B. (2007). Second Life the official guide. Jonhn Wiley & Sons, Inc., Hoboken, New Jersey. Salleh, N., Mendes, E., Grundy, J., and Burch, G. S. (2010). An empirical study of the effects of conscientiousness in pair programming using the five-factor personality model. In Proceedings of the 32nd ACM/IEEE international Conference on Software Engineering - Volume 1 (Cape Town, South Africa, May 01 - 08, 2010). ICSE '10. ACM, New York, NY, 577-586. Salmon, G. (2009). The future of Second Life and learning. British Journal of Educational Technology. 40(3), 526-538. Salmon, G. e Hawkridge, D. (2009). Editorial: out of this world. British Journal of Educational Technology, 40, 3, 401–413. Sanders, D. and Dorn, B. (2003). Jeroo: a tool for introducing object-oriented programming. In Proceedings of the 34th SIGCSE Technical Symposium on Computer Science Education (Reno, Navada, USA, February 19 - 23, 2003). SIGCSE '03. ACM, New York, NY, 201-204. Santos, P. S. and Travassos, G. H. (2009). Action research use in software engineering: An initial survey. In Proceedings of the 2009 3rd international Symposium on Empirical Software Engineering and Measurement (October 15 - 16, 2009). Empirical Software Engineering and Measurement. IEEE Computer Society, Washington, DC, 414-417. Savery, J. R. and Duffy, T. M. (1995). Problem based learning: An instructional model and its constructivist framework. Educational Technology, 35(5), 31-38. Schein, Edgar H. (2006). Kurt Lewin’s Change Theory in the Field and in the Classroom: Notes Twoard a Model of Managed Learning, Web page at http://www.a2zpsychology.com/ARTICLES/kurt_lewin's_change_theory.ht m, consultada a 24 de Outubro de 2007 Schmidt, Henk G. and Moust, Jos H. C. (2001). Factors Affecting Small-Group Tutorial Learning: A Review of Research. In B. Duch, S. E. Groh, & D. E. Allen (Eds.) The power of problem-based learning: A practical “how to” for teaching undergraduate courses in any discipline (pp. 17-51). Sterling, Virginia, 2001, Stylus Publishing. Schneider, G. M. (1978). The introductory programming course in computer science: ten principles. In Papers of the SIGCSE/CSA Technical Symposium on Computer Science Education (Detroit, Michigan, February 23 - 24, 1978). ACM, New York, NY, 107-114. Schnotz, W., Rasch, T. (2005). Enabling, facilitating, and inhibiting effects of animations in multimedia learning: why reduction of cognitive load can have negative results on learning. Educational Technology Research and Development 53 (3), 47–58

266

Schroeder, R. (1996). Possible worlds: The social dynamic of virtual reality technology. Boulder, CO. & Oxford: Westview Press Schulte, C. and Bennedsen, J. (2006). What do teachers teach in introductory programming?. In Proceedings of the Second international Workshop on Computing Education Research (Canterbury, United Kingdom, September 09 - 10, 2006). ICER '06. ACM, New York, NY, 17-28. Schweitzer, D. and Brown, W. (2009). Using visualization to teach security. J. Comput. Small Coll. 24, 5 (May. 2009), 143-150 Second Life (2006), Second Life Web site, consultado em http://www.secondlife.com a 30 Outubro, 2006. Sells, C., Flanders, J. and Griffiths, I. (2003). Mastering Visual Studio.NET. O'Reilly Media; 1st edition Senge, P. Mmmabe, N. Lucas, T. Kleiner, A. Dutton, J. and Smith, B. (2000). Schools that learn: A Fifth Discipline Fieldbook for educators, Parents, and Everyone Who Cares About Education. New York. Sheard, J., Simon, S., Hamilton, M., and Lönnberg, J. (2009). Analysis of research into the teaching and learning of programming. In Proceedings of the Fifth international Workshop on Computing Education Research Workshop (Berkeley, CA, USA, August 10 - 11, 2009). ICER '09. ACM, New York, NY, 93-104. Shivers, O. (2008). Why teach programming languages. SIGPLAN Not. 43, 11 (Nov. 2008), 130-132. Shneiderman, B. (1983). Direct manipulation: a step beyond programming languages. IEEE Computer, Vol. 16, , 57-69. Simon, B., Anderson, R., Hoyer, C., and Su, J. (2004). Preliminary experiences with a tablet PC based system to support active learning in computer science courses. In Proceedings of the 9th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education (ITiCSE’04). ACM, 213–217. Skinner, B. F. (1983) A Matter of Consequences: Part 3 of an Autobiography. Slator, B. M., Hill, C. and Del Val, D. (2004) Teaching computer science with virtual worlds. IEEE Transactions on Education 47(2), pp. 269-275. Sloane, K. D. and Linn, M. C. (1988). Instructional Conditions in Pascal Programming Classes. In R. E. Mayer (ed.), Teaching and Learning Computer Programming, p.207-235. Hillsdale, NJ: Lawrence Erlbaum Associates. Smart, J., Cascio, J. e Paffendorf, J. (2007) Metaverse Roadmap 2007: Pathways to the 3D Web. A Cross-industry Public Foresight Project. Consultado a 27 de Janeiro de 2008 em: www.metaverseroadmap.org Smith, M. K. (2001) Donald Schön: learning, reflection and change, the encyclopedia of informal education, www.infed.org/thinkers/et-schon.htm

267

Papert, Seymour; Harel, Idit (1991). Situating Constructionism, in “Constructionism”, Ablex Publishing Corporation, Norwood, NJ, USA. Referenced from the online version, retrieved from http://www.papert.org/articles/SituatingConstructionism.html. Consultado a 8 de Abril de 2008.

Sobral, S.C. (2008). B-Learning em disciplinas introdutórias de programação. Escola de Engenharia, Braga: Universidade do Minho. Soller, A., Martínez, A., Jermann, P., and Muehlenbrock, M. (2005). From Mirroring to Guiding: A Review of State of the Art Technology for Supporting Collaborative Learning. Int. J. Artif. Intell. Ed. 15, 4 (Dec. 2005), 261-290 Sollman and Heinze. (1994).Vision Management. Success as a pre-thought result. Orell Füssli. Soloway, E.M. Learning to Program = Learning to Construct Mechanisms and Explanations. Communications of the ACM, 29 (1986), 850-858 Sourin, A., Sourina, O. Prasolova-Førland, E. (2006). Cyber-learning in cyberworlds. Journal of Cases on Information Technology, 8, 4, 55–70. Spohrer J. C. and Soloway E. (1989): Novice mistakes: Are the folk wisdoms correct? In Soloway and Spohrer (1989), 401-416. Squire, K.D., Jenkins, H. (2002). The Art of Contested Spaces. In Ed. Game On!, London: Barbican. Stake, R. (1995). The art of case study research. Thousand Oaks: Sage. Stasko, J. (1997). Using student-built algorithm animations as learning aids. In Proceedings of the 28th SIGCSE Technical Symposium on Computer Science Education (SIGCSE’97). 25–29. Stasko, J. T. (1989). Tango: a Framework and System for Algorithm Animation. Technical Report. UMI Order Number: CS-89-30., Brown University. Stasko, J. T. (1990). TANGO: A framework and system for algorithm animation. IEEE Computer, 23(9):27–39, 1990. Stephenson, C., West, T., (1998). Language Choice and Key Concepts in Introductory Computer Science Courses. Journal of Research on Computing in Education, 31(1):89–95. Stiller, E. ( 2009). Teaching programming using bricolage. J. Comput. Small Coll. 24, 6 (June 2009), 35-42. Stiller, E. e LeBlanc, C. (2006). Teaching software development by example. J. Comput. Small Coll. 21, 6 (June 2006), 228-237.

268

Stinson, J. E.; Milter, R. G. (1996). Problem-based Learning in business education: curriculum design and implementation. Wilkerson, L.; Gijselaers, W.H. (Ed.). Bringing Problem-based Learning to higher education. San Francisco: Jossey-Bass Publishers. p.33-42. Storey, M.-A., Damian, D., Michaud, J., Myers, D., Mindel, M., German, D., Sanseverino, M. and Hargreaves, E. (2003). Improving the usability of Eclipse for novice programmers. In Proceedings of the 2003 OOPSLA Workshop on Eclipse Technology Exchange, pages 35–39. ACM. Sun Microsystems, (2009). NetBeans. Disponível em http://edu.netbeans.org/bluej, consultado a 7 de Novembro de 2009. Sutinen, E., Tarhio, J., Lahtinen, S., Tuovinen, A., Rautama, E. e Meisalo, V. (1997). Eliot – an Algorithm Animation Environment. University of Helsinki, Department of Computer Science, Series of Publications A, No A-1997-4. Tan, L., Wang, M. e Xiao, J. (2010). Best practices in teaching online or hybrid courses: a synthesis of principles. In Proceedings of the Third international conference on Hybrid learning (ICHL'10), Philip Tsang, Simon K. S. Cheung, Victor S. K. Lee, and Ronghuai Huang (Eds.). Springer-Verlag, Berlin, Heidelberg, 117126. There (2006), There Web site, consultado em http://www.there.com/ a 30 Outubro, 2006. Thompson, S., (1999). Haskell: The Craft of Functional Programming. Addison-Wesley. Tomek, I, Muldner, T. e Khan, S. (1985). PMS – A program to make learning Pascal easier. Computers & Education, Vol. 9, Nº 4, pp. 205-211. Tomek, I. (1983). The First Book of Josef: An Introduction to Computer Programming. Prentice Hall, Englewood Cliffs, NJ. Tomlinson, C. A. (2000). The differentiated classroom: responding to the needs of all learners. Darcie Simpson (Eds.) ASCD – association for Supervision and Curriculum Development, 1703 N. Beauregard St. Alexandria, VA 22311-1714 USA. Trætteberg, H. and Aalberg, T. (2006). JExercise: a specificationbased and testdriven exercise support plugin for Eclipse. Proceedings of the 2006 OOPSLA workshop on Eclipse technology eXchange. (Portland, Oregon, USA). ACM Press, New York, NY, USA, 2006, 70-74. Tsai, Chia-Wen e Shen, Pei-Di. (2009). Applying web-enabled self-regulated learning and problem-based learning with initiation to involve low-achieving students in learning. Comput. Hum. Behav. 25, 6 (November 2009), 1189-1194. Tucker, A.; Deek, F.; Jones, J.; McCowan, D. Stephenson, C. Verno, A. (2003). A Model Curriculum for K–12 Computer Science: Final Report of the ACM K– 12 Task Force Curriculum Committee. In Computer Science Teachers Association ACM, New York, October 2003.

269

Tversky, B., Morrison, J. B., Betrancourt, M., (2002). Animation: can it facilitate? International Journal of Human-Computer Studies. 57, 247-262. Twining, P. (2009). Exploring the educational potential of virtual worlds—Some reflections from the SPP. British Journal of Educational Technology. 40 (3), 496514. Tymann, P. (2005). Life after CS. Consultado a Junho de 2009 em http://www.cs.rit.edu/ptt/apac06/Life_After_CS.pdf Unity 3D (2005). Unity Technologies http://unity3d.com/unity. Consultado a 5 de Abril de 2009. Urquiza-Fuentes, J. and Velázquez-Iturbide, J. (2009). A Survey of Successful Evaluations of Program Visualization and Algorithm Animation Systems. Trans. Comput. Educ. 9, 2 (Jun. 2009), 1-21. Vainio, V. and Sajaniemi, J. (2007). Factors in novice programmers' poor tracing skills. In Proceedings of the 12th Annual SIGCSE Conference on innovation and Technology in Computer Science Education (Dundee, Scotland, June 25 - 27, 2007). ITiCSE '07. ACM, New York, NY, 236-240. Valdivia, R.; Nussbaum, M.; Ochoa, S. F. (2009). Modeling a Collaborative Answer Negotiation Activity Using IMS-Based Learning Design. In Education, IEEE Transations, 52, 3, pag. 375- 384. Valério, S.; Pereira, J.; Morgado, L.; Mestre, P.; Serôdio, C.; Carvalho, F. (2009). Second Life Information Desk System using Instant Messaging and Short Messaging Service Technologies. In Rebolledo-Mendez, G.; Liarokapis, F.; Freitas, S. (Eds.) IEEE First International Conference - Games and Virtual Worlds for Serious Applications, Coventry, UK, 23-24 March 2009, pp. 125-132. Los Alamitos, CA, USA: IEEE Computer Society. Valles, Miguel S. (1997). Técnicas Cualitativas de Investigación Social. Reflexión metodológica y práctica profesional. Madrid: Editorial Síntesis. van Dam, A. (2005). Visualization Research Problems in Next-Generation Educational Software. IEEE Computer Graphics and Applications, Vol. 25(5), September/October, pp. 88- 92. Veletsianos, G. (2009). The impact and implications of virtual character expressiveness on learning and agent-learner interactions. Journal of Computer Assisted Learning, 25, 4, 345–357. Veletsianos, G. (2010). Emerging Technologies in Distance Education. AU Press, Athabasca University. Violino, B. (2009). Time to reboot. Commun. ACM 52, 4 (Apr. 2009), 19.

270

Virtanen, A., Lahtinen, E., and Järvinen, H.-M. (2005). VIP, a visual interpreter for learning introductory programming with C++. In Proceedings of the 5th Koli Calling Conference on Computer Science Education (KOLI’05). 125–130. Vogts, D., Calitz, A. e Greyling, J. (2008). Comparison of the effects of professional and pedagogical program development environments on novice programmers. In Proceedings of the 2008 annual research conference of the South African Institute of Computer Scientists and Information Technologists on IT research in developing countries: riding the wave of technology (SAICSIT '08). ACM, New York, NY, USA, 286-095. Vygotsky, L. S. (1978). Mind in society: The development of higher psychological processes. Boston, MA: Harvard University Press. Vygotsky, L. S. (1979). Pensamento e Linguagem. Lisboa, Edições Antídoto. Vygotsky, L. S. (1981). The genesis of higher mental functions. Em J. V. Wertsch (Red.), The concept of activity in soviet psychology .(pp. 144-188). Armonk, NY: M. E. Sharpe. Wagner (2008). Learning Experience with Virtual Worlds. Journal of Information Systems Education. 19(3). 263-266 Walsh, L. N., Howard, R. G., and Bowe, B (2007). Phenomenographic study of students’ problem solving approaches in physics. Phys. Rev. ST Phys. Educ. Res. 3, 2. Warburton, S. (2009). Second Life in higher education: Assessing the potential for and the barriers to deploying virtual worlds in learning and teaching. British Journal of Educational Technology. 40 (3), 414-426. Warburton, S., Perez-Garcia, M. (2009). 3D design and collaboration in massively multi-user virtual environments. In D. Russel (Ed.), Cases on collaboration in virtual learning environments: processes and interactions. Hershey, PA: IGI Global. Forthcoming April 2009 Watson, J. B. (1913). Psichology as the Behaviorist sees it. Psichological Review, 20, pp. 158-177. Watson, J. B. (1928). Psychological Care of Infant and Child. New York: W. W. Norton Company, Inc. Wellington, C. A.; Briggs, T. H. and Girard, C. D. (2007). Experiences using automated tests and test driven development in computer science I. In AGILE '07: Proceedings of the AGILE 2007 Conference. pages 106-112. Weng, K. S. (1975). Stream oriented computation in recursive data-flow schemas. Tech. Rep. 68. Laboratory for Computer Science, MIT, Cambridge, MA. Wenger, E. (1998). Communities of Practice, Learning, Meaning, and Identity. USA: Cambridge University Press

271

Wilkes, M. (1985). Memoirs of a Computer Pioneer. The MIT Press. Williams, D. J. and Noyes, J. M. (2007). Effect of experience and mode of presentation on problem solving. Computers in Human Behavior 23(1), 258-274. Williams, L., Kessler, R. R., Cunningham, W., AND Jeffries, R. (2000). Strengthening the case for pair programming. IEEE Softw. 17, 4, 19–25. Wilson, M. (2010). CEO, There.com. http://www.there.com/info/announcement. Consultado a 12 de Março de 2010. Winn, W. (2002). Current trends in educational technology research: The study of learning environments. Educational Psychology Review, 14(3), 331 – 351 Winslow, L. E. (1996). Programming pedagogy – A psychological overview. SIGCSE Bulletin 28, 17–22. Wirth, N. (1993). Recollections about the development of Pascal. In the Second ACM SIGPLAN Conference on History of Programming Languages (Cambridge, Massachusetts, United States, April 20 - 23, 1993). HOPL-II. ACM, New York, NY, 333-342. Woods, D. (2001). They just don’t pull their weight. Schwartz, P.; Mennin, S.; Webb, G. (Ed.). Problem-based Learning: case studies, experience and practice. Londres: Kogan Page. p.163-170. World of Warcraft (2006), World of Warcraft Web site, consultado em http://www.worldofwarcraft.com/index.xml, a 30 Outubro, 2006. Wu, P. (2009). Teaching basic game programming using JavaScript. J. Comput. Small Coll. 24, 4 (Apr. 2009), 211-220. Xinogalos, S.; Satratzemi, M. and Dagdilelis, V. (2006). An introduction to objectoriented programming with a didactic microworld: objectKarel. Computers and Education, 47(2):148–171. Yang, Hsieh-Hua, Kuo, Lung-Hsing Yang, Hung-Jen, Yu, Jui-Chen e Chen, Li-Min. (2009). On-line PBL system flows and user's motivation. WTOC 8, 4 (April 2009), 394-404. Yankelovich, N. (2005). Project Wonderland: Sun's Virtual Workplace. http://research.sun.com/marcom/projectbriefs/index.php. Consultado a 25 de Março de 2009. Zimmermann, R. and Liang, K. (2008). Spatialized audio streaming for networked virtual environments. In Proceeding of the 16th ACM international Conference on Multimedia (Vancouver, British Columbia, Canada, October 26 - 31, 2008). MM '08. ACM, New York, NY, 299-308.

272

Zuber-Skerritt, O. (2000). A generic model for action learning and research programs. In Action Learning, Action Research and Process Management: Theory, Practice, Praxis, Action Research Unit. Faculty of Education, Griffith University, Brisbane.

273

12. Anexos I
Lista de códigos atribuída a cada fonte de dados utilizada.

274

275

Fonte de dados

Denominação Mensagens escritas trocadas entre professora e os alunos durante as aulas Questionário inicial

Código

Registos electrónicos

Reg. QuestI. QuestInt. QuestF. Ent.

Questionários

Questionário intermédio Questionário final

Entrevistas informais Alunos de: Proj. I (1º e 2º ciclo) Lab. II (1º e 2º ciclo) Lab. I (3º e 4º ciclo) Alunos de: Lab. I Lab. III

Conversas informais com prioridade mensal Os alunos, de cada unidade curricular, são designados pela 1º letra do nome do seu avatar.

Aluno S

Os alunos de cada unidade curricular são designados por números.

Aluno 1

Tabela I : Códigos atribuídos a cada uma das fontes de dados utilizadas.

276

277

13. Anexos II

Planos das aulas no mundo virtual Second Life

278

279

Plano das aulas de Laboratório de Informática I

Actividade Preliminar

Realizadas entre Março e Junho de 2007, na qual participaram 5 alunos da licenciatura em Informática da UTAD. O enunciado do projecto teve por objectivo que os alunos aprendam a: manipulação de estruturas de dados; troca de informação entre objectos; manipular estruturas de controlo; estruturar o código; desenvolver e aplicar funções, implementadas pelos alunos assim como as prédefinidas da linguagem. Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente ampliar a complexidade das técnicas a dominar por estes, nomeadamente, o lançamento de respostas a eventos. A tabela seguinte apresenta o plano das aulas previstas para os alunos de Lab. I

280

Semana 1

2

3

4

5

6

7

Plano Apresentação do mundo virtual Second Life (SL). Criar e personalizar um avatar. Adaptação ao SL. Criar e modelar objectos. Fazer a ligação de objectos. Introdução à linguagem LSL. Sintaxe, operadores e variáveis. Exemplos de output utilizando o canal de público. Estruturas de controlo. Estados: estados pré-existentes, criar novos estados, transições entre estados. Funções: exemplos de funções préexistentes, criação de novas funções. Eventos: exemplos de event handlers pré-existentes. Continuação da aula anterior. Colocar o robot a seguir o seu dono Comunicação entre objectos: envio e recepção de mensagens. Comunicação entre o canal de chat e os objectos: reacção de objectos a comandos. Pôr o robot a executar as tarefas que recebe do seu dono. Fazer o parse das mensagens recebidas. Identificar os token que impliquem uma tarefa para o robot executar. Continuação da aula Rotação de objectos.

Projecto: cão BOBI

Primeiro esboço do cão.

Associar um script ao cão; comunicação pelo canal público.

Colocar o cão em vários estados distintos. Reacção do cão a eventos, como, por exemplo, acções do rato, actualizar o estado interno e modificar propriedades que permitem realizar um determinado comportamento, como alterar cor ou alterar a sua posição.

Execução das ordens recebidas.

8

anterior Efectuar a rotação do cão para a direita e para a esquerda.

9

Criar um canal de comunicação entre o Temporizadores: criação de eventos cão e o seu dono. Por o cão a enviar a com temporizadores. mensagem "estou com fome" ao dono como resposta ao evento tempo Completar as funcionalidades do cão no que diz respeito ao temporizador. - No fim de 3h sem comer salta; - Passado 4h sem comer muda de cor; - Por fim desliga-se.

10

Controlo do tempo.

281

Semana 11

Plano Envio de mensagens para um endereço de email. Leitura de informação em notecards. Conclusão do projecto.

Projecto: cão BOBI

Envio de emails ao dono 12

282

Plano das aulas de Laboratório de Informática III Actividade Preliminar

Realizadas entre Março e Junho de 2007, na qual participaram 4 alunos da licenciatura em Informática da UTAD. Os objectivos de aprendizagem do enunciado do projecto de Lab. III incluíam, para além da revisão das técnicas de programação aprendidas anteriormente, centrarem-se nos seguintes aspectos: na manipulação de estruturas de dados, tais como listas e strings; na manipulação de informação, nomeadamente a explorar as técnicas de canais de comunicação e o envio de mensagens através de e-mails; no lançamento e resposta a eventos; na execução concorrente de código num mesmo objecto; na gestão de máquina de estados; no uso de temporizadores e de sensores virtuais.

Semana 1

2

3

Plano Projecto: Robot Alf Apresentação do mundo virtual Second Life (SL). Criar e personalizar um avatar. Adaptação ao SL. Criar e modelar objectos. Primeiro esboço do Robot. Criação de objectos para o Fazer a ligação de objectos. aspecto visual, ligar objectos para as várias partes do robot. Associar um script ao robot que escreva através do canal 0 (chat). Colocar o robot em vários estados distintos. Reacção do robot a eventos, como por exemplo acções do rato, Introdução ao LSL, revisões actualizar o estado interno e modificar propriedades dos conceitos base da que permitem realizar um determinado programação comportamento, como por exemplo alterar uma cor ou alterar a posição do robot

283

Plano

Projecto Colocar o robot à escuta de comandos do dono (owner) e a reagir a comandos direccionados do dono para o robot nomeadamente mover o robot para a frente e para trás. Comunicação entre objectos: envio e recepção de mensagens. Comunicação entre o canal de chat e os objectos: reacção de objectos a comandos. Pôr o robot a executar as tarefas que recebe do seu dono. Fazer o parse das mensagens recebidas. Identificar os token que impliquem uma tarefa para o robot executar. Criar um canal de comunicação entre o robô e o seu dono. Por o robô a enviar a mensagem "estou com fome" ao dono como resposta ao evento tempo Completar as funcionalidades do robot no que diz respeito ao temporizador. - No fim de 3h sem comer salta; - Passado 4h sem comer muda de cor; - Por fim desliga-se.

4

Troca de mensagens entre objectos; Lançamento e resposta a eventos

5

Introdução aos estados; Criar e mudar de estados; temporizadores

6

7

Temporizadores, continuação; Sensores: detecção de avatares e objectos num Introdução aos sensores determinado raio de acção Colocar o robot a detectar obstáculos e a desviar-se Sensores, detectar e desviar de destes. obstáculos Listas, inserir, retirar informação de uma lista Execução concorrente de código num mesmo objecto Enviar informação através de email Guardar nessa lista a identificação dos vários objectos que o sensor foi detectando. Guardar as mensagens trocadas entre o robot e o seu dono. Criar 4 robot. Designar um deles como sendo o chefe do grupo, os restantes passan a executar as ordens dadas por este. O chefe do grupo só recebe ordens do seu dono e transmite aos restantes. Dispor os robot de modo a formarem um triangulo Colocar os robots a seguirem o movimento do chefe do grupo Programar o robot para executar uma sequência de tarefas: o robot chefe executa as instruções previamente construídas num notecard e dá ordens aos outros elementos Tornar o robot num humanóide não só de aspecto mas também no movimento de braços e pernas.

8

9

10

11

Continuação

12

Conclusão do projecto

284

Plano das aulas de Projecto I

Primeiro e segundo ciclos Realizadas entre Outubro de 2007 e Janeiro de 2008, no qual participaram os alunos da ESTG. Pretendeu-se que estes alunos aprendessem a programar através de interacções físicas, pelo que o enunciado foi semelhante ao desenvolvido pelos alunos de Lab. I (projecto visual), embora com um grau de dificuldade um pouco superior. Com este trabalho pretendeu-se que os alunos estudassem e praticassem os seguintes conceitos: Variáveis; Manipulação de estruturas de dados, tais como lists e strings; Troca de informação entre objectos; Manipulação de estruturas de controlo; Estruturação do código; Desenvolvimento e aplicação de funções, implementadas pelos alunos assim como as pré-definidas da linguagem.

Semana 1

Plano Apresentação do mundo virtual Second Life (SL). Apresentação dos vários enunciados do projecto; Criar e personalizar um avatar. Criar e modelar objectos. Fazer a ligação de objectos.

2

3

Criar e modelar os objectos do projecto;

285

Semana

Plano Introdução à linguagem Linden Sripting Language (LSL). Revisões dos conceitos base Sintaxe, operadores e variáveis. Exemplos de output utilizando o canal de chat. Estruturas de controlo. Estados: estados pré-existentes, criar novos estados, transições entre estados. Funções: exemplos de funções pré-existentes, criação de novas funções. Continuação da aula anterior. Colocar o robot a seguir o seu dono; Eventos: exemplos de event handlers pré-existentes. Entrega do algoritmo. Comunicação entre objectos: envio e recepção de mensagens. Comunicação entre o canal de chat e os objectos: reacção de objectos a comandos. Entrega da primeira fase do trabalho (envio de mensagem ao cão pelo dono) Pôr o cão ou Boneco de neve a executar as tarefas que recebe do seu dono (temporizador). Fazer o parse das mensagens recebidas. Identificar os token que impliquem uma tarefa para o robot executar. Continuação da aula anterior Rotação de objectos. Entrega da segunda fase do projecto (funcionalidades comer 3 em 3h) Continuação do projecto. Introdução aos sensores. Continuação do desenvolvimento do projecto. Entrega da 3 fase (funcionalidades bolas ar ao fim 4 h sem comer, desligar-se); Envio de mensagens para o dono por email; Implementação da segunda parte do projecto; Listas: guardar a quantidade de vendas efectuadas; Conclusão do projecto

4

5

6

7

8

9

10

11

12 13

286

Plano das aulas de Laboratório Informático II

Primeiro e segundo ciclos Realizadas entre Outubro de 2007 e Janeiro de 2008, no qual participaram os alunos da UTAD. Os objectivos de aprendizagem deste projecto centrarem-se, para além da revisão das técnicas de programação aprendidas anteriormente, nos seguintes aspectos: Na manipulação de estruturas de dados, tais como lists e strings; Na manipulação de informação, nomeadamente a exploração de técnicas de canais de comunicação e o envio de mensagens através de e-mails; Na gestão de máquina de estados.

Semana 1

Plano Apresentação do mundo virtual Second Life (SL). Criar e personalizar um avatar. Criar e modelar objectos. Fazer a ligação de objectos. Introdução à linguagem Linden Sripting Language (LSL). Revisões dos conceitos base Sintaxe, operadores e variáveis. Exemplos de output utilizando o canal de chat. Estruturas de controlo Entrega do algoritmo. Comunicação entre objectos: envio e recepção de mensagens. Comunicação entre o canal de chat e os objectos: reacção de objectos a comandos. Eventos, criar funções no LSL

2

3

4

5

Estados: estados pré-existentes, criar novos estados, transições entre estados. Entrega da primeira fase do projecto.

287

Semana 6

Plano Continuação da aula anterior. Leitura de informação em cartões; Ficheiros

7

. Continuação. Ficheiros

8

Continuação Projecto. Entrega da segunda fase do projecto

9 10

Continuação da aula anterior Continuação do projecto. Entrega da terceira fase de avaliação Conclusão do Projecto

11

288

Plano das aulas de Laboratório Informático I

Terceiro e quarto ciclos Realizadas entre Março e Junho de 2008, no qual participaram os alunos da UTAD. Este projecto teve por objectivo que os alunos aprendessem a: Manipular as estruturas de dados; Trocar informação entre objectos; Manipular estruturas de controlo; Estruturar o código; Desenvolver e aplicar funções, implementadas pelos alunos assim como as pré-definidas da linguagem. Para além de os alunos se focarem nestas técnicas base, pretendeu-se igualmente ampliar a complexidade das técnicas a dominar por estes, nomeadamente, o lançamento de respostas a eventos.

Semana 1 Apresentação do projecto

Plano

2

Apresentação do mundo virtual Second Life (SL) na UTAD. Criar e personalizar um avatar. Criar e modelar objectos. Fazer a ligação de objectos. Introdução à linguagem Linden Sripting Language (LSL). Revisões dos conceitos base Sintaxe, operadores e variáveis. Funções; Entrega do algoritmo

3

4

5

Discussão em grupo das soluções apresentadas

289

Semana 6

Plano Continuação do desenvolvimento do projecto

7

. Continuação. Sensores

8

Continuação Projecto. Entrega da primeira fase do projecto

9 10

Continuação da aula anterior Continuação do projecto.

11

Conclusão do Projecto

290

291

14. Anexos III

Enunciado dos projectos desenvolvidos pelos alunos no mundo virtual Second Life.

292

293

Licenciatura em Informática

Licenciatura em Tecnologias de Informação e Comunicação

Laboratório de Informática I Trabalho Prático
Data de entrega:22 de Junho de 2007 NOTA: O trabalho deve ser entregue através do SIDE.

Cão “Bobi”

Resumo No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para criação de uma loja virtual, nas coordenadas: http://slurl.com/secondlife/Cocaine%20Island/126/199/22. Neste mundo virtual pretende-se construir um robô com a forma de um cão: “Bobi”, que se desloca pelo mundo seguindo o respectivo dono. O “Bobi” deve ser colocado na loja virtual em exposição. Quando algum avatar quiser adquirir o “Bobi”, este deve registar a chave do seu novo dono, passando a obedecer exclusivamente às ordens enviadas por este.

Descrição da aplicação Os alunos devem criar um objecto com a forma de um cão e atribuir-lhe um nome, por exemplo “Bobi”. Este, cão, deve ser desenvolvido no Second Life, utilizando os objectos disponíveis no mesmo (prims). O desenvolvimento do cão deve decorrer, no terreno referido anteriormente ou em locais públicos (sandboxes), como a Sandbox Morris, por exemplo: http://slurl.com/secondlife/sandbox%20Morris\224\137\21 Quando estive pronto, o cão deve ser colocado em exposição na loja virtual acima referida. Quando alguém o adquirir, o “Bobi” deve captar a chave do futuro dono e a partir desse momento só obedece às ordens deste.

294

Funcionalidades a implementar O “Bobi” precisa de ser alimentado de 3 em 3 horas. A alimentação consiste em bolinhas de ração que o dono do Bobi lhe fornece sempre que toca nele. Assim, o nome do comando “Touch” deve ser alterado para “Comida”. O “Bobi” é responsável por controlar os intervalos de tempo em que é alimentado. Desta forma, sempre que passarem 3 horas sem ser alimentado, o Bobi deve avisar o dono de que está com fome, por exemplo enviando-lhe uma mensagem. Se as suas preces não forem atendidas, começa a saltar. Ao fim de 4 horas sem ser alimentado, o “Bobi” pára e envia bolas de saliva para o ar. Por fim, se continuar sem ser alimentado, o “Bobi” desliga-se (ou seja: fica inactivo). O “Bobi” unicamente obedece às instruções do seu dono. Sempre que outra pessoa lhe tocar ele ladra, ou seja envia a seguinte mensagem para o canal público: “Bau, Bau”. De cada vez que o “Bobi” recebe uma instrução do seu dono, este deve executá-la. As instruções são mensagens que o “Bobi” recebe e as executa como, por exemplo: dono – stop . Acção do “Bobi” - deixa de seguir o dono e pára. dono – frente 5 Acção do “Bobi” - desloca-se 5 passos para a frente dono – direita 90 Acção do “Bobi” - roda sobre si mesmo 90º para a direita.

O “Bobi” deve guardar as tarefas executadas ao fim de um dia de trabalho: nessa altura envia por e-mail ao dono os locais que visitaram e as tarefas que andou a realizar. Podem ser adicionadas ao “Bobi” outras funcionalidades que considerar interessantes.

295

Licenciatura em Informática

Licenciatura em Tecnologias de Informação e Comunicação

Laboratório de Informática III

Trabalho Prático
Data de entrega: dia 18 de Junho de 2007 Nota: A defesa dos trabalhos pode ser efectuada em qualquer das chamadas do 2º semestre.

Exploração de rede ferroviária virtual
Resumo No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para as disciplinas Laboratório de Informática III e Laboratório de Tecnologias de Informação e Comunicação, em: http://slurl.com/secondlife/Cocaine%20Island/126/199/22. Neste mundo virtual pretende-se simular o funcionamento de uma linha férrea que faça a ligação entre duas cidades. Entre estas cidades existem várias indústrias (ex.: madeira, papel, exploração petrolífera). Nesta linha circulam dois comboios, que vão recebendo mensagens das estações que existem nas cidades e nas indústrias. Cada comboio deve processar essas informações e saber onde tem de parar para receber/descarregar mercadorias. A linha pode ter pontos de cruzamento entre comboios, com semáforos que lhes controlam o movimento.

Descrição dos componentes a desenvolver Este trabalho é constituído por: dois comboios de mercadorias; três indústrias (ex.: madeira, papel, exploração petrolífera); duas cidades; cinco estações de comboios; e duas linhas ferroviárias. Depois de montado, deve ocupar, no máximo, 100 m2 . dentro do ambiente virtual Second Life, utilizando os objectos disponíveis no mesmo (prims). Cada cidade é constituída por um conjunto de edifícios, cujo número de andares por edifício deve variar entre 2 a 10. Cada cidade deve ocupar no máximo 20 m2. Cada comboio deve ter uma locomotiva, que puxa quatro carruagens de mercadorias, para transportar os produtos (cada carruagem só pode transportar um tipo de produto).

296

As estações de comboios são pequenos edifícios, constituídos por um só andar, que devem ser colocados ao longo da linha férrea, indicando o ponto no qual o comboio deve parar. Cada indústria deve ocupar, no máximo, 10 m2 , sendo constituída por um ou dois edifícios a condizer visualmente com a respectiva actividade. A linha ferroviária deve ser colocada de modo a ligar as duas cidades e as indústrias. A linha deve ter pontos de cruzamento nos quais serão colocados semáforos para controlar o tráfego. Todo o desenvolvimento do trabalho deve decorrer em locais públicos (“sandboxes”), como a Sandbox Morris, por exemplo: http://slurl.com/secondlife/sandbox%20Morris\224\137\21 Quando o trabalho estiver pronto, deve ser colocado em exposição no terreno acima referido, em local próprio para o efeito (contactar um dos docentes para o efeito).

Funcionalidades a implementar • Cada comboio deve ter as seguintes funcionalidades: o Receber os pedidos de cada cidade sobre as necessidades de papel, madeira e petróleo que estas têm. Estes pedidos podem ser recebidos directamente ou estarem descritos num notecard. o Identificar os produtos que lhe foram pedidos e entregá-los por ordem das cidades pelas quais vai passar. o Saber onde parar e a quantidade de produtos que pode transportar. o Quando o comboio está cheio deve avisar as indústrias que não pode parar. o Enviar para o dono do comboio, no fim do dia, um relatório com os produtos transportados e entregues. o Sempre que um comboio não tenha mercadorias para transportar não deve circular. • Cada cidade deve ter uma estação ferroviária na qual o comboio descarrega os produtos de que esta necessita. Deve ter um notecard com a descrição e a quantidade de produtos de que necessita.

297

A linha ferroviária deve ter semáforos nos cruzamentos, de modo a evitar congestionamentos ao longo da linha. Deve ter um terminal no qual os comboios devem ficar sempre que não têm mercadorias para transaccionar.

298

Licenciatura em Informática

Licenciatura em Tecnologias de Informação e Comunicação

Laboratório de Informática III

Trabalho Prático
Data de entrega: dia 18 de Junho de 2007 Nota: A defesa dos trabalhos pode ser efectuada em qualquer das chamadas do 2º semestre.

Robô “Alf”
Resumo No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para as disciplinas Laboratório de Informática III e Laboratório de Tecnologias de Informação e Comunicação, em: http://slurl.com/secondlife/Cocaine%20Island/126/199/22 Neste mundo virtual pretende-se construir quatro robôs: “Alf”,”Alf1”, ”Alf2” e ”Alf3” que se desloquem livremente e sigam o respectivo dono. Estes robôs devem comportar-se como um só: há um chefe do grupo (Alf) que recebe ordens do dono (avatar) e as transmite aos restantes. Pretende-se que este grupo de robôs seja colocado na loja virtual. Quando algum avatar comprar o robô-chefe Alf, este deve registar a chave do novo dono, e só responder a ordens enviadas por ele.

Descrição dos robôs a desenvolver Os alunos devem criar 4 robôs humanóides, identificá-los e definir qual deles vai ser o chefe do grupo. Cada robô deve ter uma altura máxima de 2m, tendo todos a mesma estrutura física mas cores e/ou texturas diferentes. Estes robôs devem ser desenvolvidos no Second Life, utilizando os objectos disponíveis no mesmo (prims). Todo o desenvolvimento do trabalho deve decorrer em locais públicos (“sandboxes”), como a Sandbox Morris, por exemplo: http://slurl.com/secondlife/sandbox%20Morris\224\137\21

299

Quando estiverem prontos, os robôs devem ser colocados em exposição na loja virtual acima referida. Quando alguém os adquirir, o robô Alf deve captar a chave do futuro dono e a partir desse momento só receber ordens deste.

Funcionalidades a implementar O Alf é o único que tem permissões para contactar o dono, sendo responsável por transmitir aos restantes elementos as ordens recebidas. O dono por sua vez também só necessita de interagir com o Alf. Cada robô precisa de ser alimentado de 3 em 3 horas. A alimentação consiste em energia que é passada do dono para o Alf quando este é tocado pelo seu dono. Assim, devem os alunos alterar o nome do comando “Touch” do robô-chefe Alf para “Energizar”. Cada vez que o Alf for alimentado, deve enviar uma mensagem aos restantes num canal privado, a dizer “energia”: desta forma todos são alimentados. O robô Alf2 é responsável por controlar os intervalos de tempo em que são alimentados. Desta forma, sempre que passarem 3 horas sem serem alimentados, o Alf2 deve avisar o Alf. O Alf por sua vez vai avisar o dono de que está com fome; se não for atendido, dá ordens aos restantes robôs para começarem a saltar coordenadamente formando uma onda. Ao fim de 4 horas sem serem alimentados, o Alf2 envia nova mensagem ao Alf, a dizer “a energia está a esgotar-se”. O Alf dá ordens para mudarem de cor e o Alf3 indica qual a cor que cada um deve ter. Por fim, se continuarem sem ser alimentados, o Alf dá ordens para se desligarem (ou seja: ficarem inactivos). O Alf, que vai à frente dos outros robôs, sempre que no seu caminho aparecer um obstáculo deve desviar-se dele; os outros robôs devem fazer o mesmo. A programação dos robôs, para que executem uma sequência de tarefas, pode ser feita directamente. Por exemplo: dono – stop . Alf deixa de seguir o dono e pára. dono – frente 5 Alf desloca-se 5 passos para a frente dono – direita 90 Alf roda sobre si mesmo 90º para a direita.

300

dono – quadrado Alf e os restantes robot dispõem-se em formação, na forma de um quadrado. Outra alternativa consistiria em escrever as instruções num notecard, que é lido pelo Alf, o qual dá depois ordens aos restantes elementos. O Alf1 tem a função de guardar as tarefas executadas pelo grupo ao fim de um dia de trabalho: nessa altura envia por e-mail ao dono os locais que visitaram e as tarefas que andaram a fazer. Podem ser adicionadas ao Alf outras funcionalidades que considerar interessantes.

301

Licenciatura em Informática

Licenciatura em Tecnologias de Informação e Comunicação

Trabalho Prático

Data de entrega: dia 9 de Janeiro de 2008 NOTA: O trabalho deve ser entregue através do SIDE. Deve ser composto por: relatório de modelação e especificação; código fonte; executável e ficheiros de apoio.

- Aplicativo de Gestão de Armazém para uma Farmácia –

Introdução
No mundo virtual Second Life pretende-se construir uma farmácia virtual, FARMAUTAD. A farmácia tem em exposição vários produtos como medicamentos, produtos de beleza, entre outros. Com este projecto pretende-se simular o funcionamento de uma farmácia real, mais especificamente, receber informações acerca dos produtos disponibilizados (além de medicamentos também pode vender outros tipos de produtos), tratar a informação relativa aos fornecedores dos produtos, encomendar produtos, assim como tratar a informação relativa aos movimentos efectuados (entradas e saídas de armazém), de acordo com a descrição informal a seguir apresentada.

Descrição informal:
Para cada produto comercializado na farmácia são registados os seguintes dados: código de identificação, nome, tipo (medicamento, produto de beleza, etc.), a sua referência (para o fornecedor), fornecedor, quantidade existente em armazém, quantidade de alarme (quantidade abaixo da qual não está garantida a sua disponibilidade), quantidade de encomenda (quantidade que deve ser encomendada ao fornecedor).

302

Cada produto é vendido por um fornecedor. Para cada fornecedor é armazenado o seu código de identificação, o nome, um endereço, um número de telefone, e o nº de contribuinte. Os fornecedores, mensalmente, enviam para a farmácia um catálogo que além de conter dados actualizados sobre os produtos disponibilizados, incluem informação sobre novos produtos, a qual é enviada à direcção para apreciação. A “caixaGestão” da farmácia é responsável por elaborar as notas de encomenda a enviar aos fornecedores. As notas de encomenda são elaboradas tendo em conta a informação relativa aos produtos existentes em armazém com uma quantidade inferior à quantidade de alarme, e a relação dos novos produtos a adquirir enviada pela Direcção. Na nota de encomenda é indicado o código de identificação, o nome do fornecedor, o seu endereço, e uma lista de produtos a encomendar. Para cada produto é indicado a sua referência, o nome e a quantidade pretendida. Ao elaborar a nota de encomenda “caixaGestão” tem sempre em conta a quantidade de encomenda registada para o produto. Os produtos enviados pelos fornecedores são acompanhados por uma factura e por uma guia de remessa onde constam os seguintes dados: nome do fornecedor, nome da farmácia, endereço da farmácia, nº de contribuinte, e para cada produto é indicado o seu nome e a quantidade enviada. A guia de remessa é processada de forma a se proceder no sistema à actualização da quantidade em armazém para cada um dos produtos que constam da mesma, ou à inserção do produto no sistema quando se trata de um novo produto. A factura é enviada à Contabilidade para se proceder ao seu pagamento. Quando é realizada uma venda, é verificado se existe quantidade suficiente em armazém e caso exista é processada a venda sendo actualizada a respectiva quantidade existente em armazém. Quando a quantidade existente em armazém de um produto é inferior à quantidade de alarme definido para o mesmo, o sistema envia um alerta. Diariamente é enviada à Direcção uma lista contendo informação relativa a todos os movimentos efectuados. Semanalmente é enviada uma lista dos produtos cuja quantidade existente em armazém está a duas unidades da quantidade de alarme definida para o mesmo. Mensalmente é enviada uma lista com os dez produtos mais vendidos e os dez menos vendidos.

303

Objectivos
O programa deve permitir ao utilizador efectuar as seguintes actividades: 1. Efectuar a gestão de fornecedores (criação, alteração, eliminação). 2. Receber catálogos (ficheiros de texto) com dados de produtos novos e actualização de produtos actuais. 3. Fazer encomendas (produzir ficheiros de texto com os dados das encomendas). 4. Receber encomendas (ficheiros de texto com dados dos produtos entregues no armazém). 5. Processar vendas efectuadas no balcão (dar baixa no inventário e lançar alertas). 6. Produzir relatórios.

Orientação para o desenho da aplicação.
Na farmácia existe um terminal “caixaGestão” (ver Figura 1)que efectua a gestão dos fornecedores. Cada produto exposto ao ser comprado (adquirido por um avatar) deve transmitir à “caixaGestão” que foi vendido de modo a que este actualize o stock existente. Cada produto é representado por um objecto, por exemplo uma caixa de aspirinas é um objecto.

Figura 1: exemplo de uma “caixaGestão” da cidade de Roma no Second Life

304

A “caixaGestão” deve ter três scripts, um que trata de toda a informação relativa aos produtos, um que ocupa-se de todos os dados dos fornecedores e outro que emite relatórios. Estes scripts funcionam em simultâneo e trocam mensagens entre si.

O script de gestão dos produtos deve ter: • uma lista com os dados de todos os produtos (key, nome, quantidade, quantidade mínima para repor stock, etc); • dois estados: um no qual se processa toda a informação referente a recepção de encomendas; outro para processar informação da venda dos produtos; • a recepção de encomendas deve ser feito através de um notcard que o fornecedor entrega.

O script de gestão dos fornecedores deve ter: • • uma lista com os dados dos fornecedores (nome, endereço, etc); três estados: um no qual se processa a gestão de fornecedores; outro para receber catálogos; e outro para fazer as encomendas. • O pedido das encomendas deve ser feito por e-mail.

O script que emite automaticamente os relatórios diários, semanais e mensais. • Para além das listas e estados sugeridos, implemente outros que achar convenientes, que permitam um melhor desenho e uma melhor funcionalidade da aplicação. • Todos os dados são enviados do Second Life por e-mail e posteriormente transformados em ficheiros de texto. • Os dados dos fornecedores da farmácia devem ser guardados num ficheiro “fornecedores.txt”, obedecendo ao seguinte formato:

305

Exemplo: fornecedores.txt código de identificação; nome; endereço; número de telefone; nº de contribuinte

Os dados dos produtos da farmácia devem ser guardados num ficheiro “produtos.txt”, obedecendo ao seguinte formato:

Exemplo: produtos.txt código de identificação; nome; tipo; referência; código do fornecedor; quantidade existente; quantidade de alarme; quantidade de encomenda

Os dados dos movimentos da farmácia devem ser guardados num ficheiro “movimentos.txt”, utilizando os identificadores “v:” para objectos da classe “venda” e “c:” para objectos da classe “compra”, obedecendo ao seguinte formato:

Exemplo: movimentos.txt v: código produto; nome do produto; quantidade; data do movimento c: código produto; nome do produto; quantidade; data do movimento; código do fornecedor; nome do fornecedor

Serão colocados três ficheiros, para teste, na área de downloads da disciplina no SIDE.

306

Instituto Politécnico de Leiria Escola Superior de Tecnologia e Gestão Departamento de Engenharia Informática
T

Trabalho Prático
Data de Entrega: 18 de Janeiro de 2008

Boneco de Neve
Resumo
No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno em: http://slurl.com/secondlife/Cocaine%20Island/126/199/22 Neste mundo virtual pretende-se construir um boneco de neve (BN) formado por duas bolas, uma mais pequena que representa a cabeça e outra maior, o corpo do boneco. As duas bolas devem ser colocadas uma em cima da outra de modo a formar um boneco de neve. A cabeça e o corpo do boneco embora sobrepostos devem ter funcionalidades diferentes, assim a cabeça do boneco funciona como receptor de mensagens, que depois de as analisar dá ordens ao corpo para as executar. As mensagens são enviadas pelo dono do boneco.

Descrição do boneco neve a desenvolver
Os alunos devem criar um boneco de neve formado por duas bolas sobrepostas. O boneco deve ter uma altura máxima de 2m. Este boneco deve ser desenvolvidos no Second Life, utilizando os objectos disponíveis no mesmo (prims). O desenvolvimento do cão deve decorrer, no terreno referido anteriormente ou em locais públicos (sandboxes), como a Sandbox Morris, por exemplo: http://slurl.com/secondlife/sandbox%20Morris\224\137\21

307

Funcionalidades a implementar
O BN só recebe ordens do seu dono, sempre que outra pessoa lhe toca na cabeça, ele escreve a seguinte mensagem: “Eu não sou teu!!” e passado alguns segundos apaga-a. A cabeça do BN recebe as ordens do seu dono, sendo responsável por as analisar e transmitir à barriga o que esta deve fazer. A cabeça do BN controla a tempo durante o qual o seu dono está sem interagir com ele. Se passarem 3 horas sem brincadeira a cabeça do BN escreve a mensagem “Brinca comigo”por cima da sua cabeça, envia um e-mail ao seu dono a dizer “Eu gostaria muito que brincasses comigo” e simultaneamente altera a cor da barriga para cinza escuro. Assim que o dono começar a brincar com o BN a mensagem deve ser apagada e este voltar repor a cor original da barriga. Sempre que o dono tocar na barriga do boneco esta começa a lançar bolas para o ar, ao ser tocado novamente as bolas cessam. Assim, devem os alunos alterar o nome do comando “Touch” da barriga do BN para “Bolas de sabão”. O dono do BN pode interagir com o boneco enviando-lhe as seguintes mensagens através do chat: dono –Salta 3 vezes A barriga do BN separa-se da cabeça e dá três saltos; dono –Circulo A barriga do BN desloca-se de modo a desenhar um circulo; dono –Cumprimenta O BN escreve a seguinte mensagem por cima dele: “Olá, como vai?”; dono –Segue-me O BN ( cabeça e barriga) segue o dono; dono – stop . BN deixa de seguir o dono e pára

Podem ser adicionadas ao BN outras funcionalidades que considerar interessantes

308

2ª Fase do trabalho prático
Agora que o BN está pronto para ser vendido, pretende-se que implementem uma loja virtual no Second Life. O objectivo é construírem um balcão virtual que faça a gestão das vendas. Assim o balcão deve registar os seguintes elementos: • o número de BN existentes na loja; • o nome do BN; • a quantidade de BN vendidos; • o preço de cada BN;

O balcão sempre que vende um BN deve actualizar os seus registos. Quando a quantidade existente de BN na loja for inferior ou igual a cinco unidades, deve enviar um email ao fabricante a pedir mais.

309

Instituto Politécnico de Leiria Escola Superior de Tecnologia e Gestão Departamento de Engenharia Informática
T

Trabalho Prático
Data de Entrega: 18 de Janeiro de 2008

Cão “Bobi” Resumo
No mundo virtual Second Life (www.secondlife.com), foi reservado um terreno para criação de uma loja virtual, nas coordenadas: http://slurl.com/secondlife/Cocaine%20Island/126/199/22. Neste mundo virtual pretende-se construir um robô com a forma de um cão: “Bobi”, que se desloca pelo mundo seguindo o respectivo dono. O “Bobi” deve ser colocado na loja virtual em exposição. Quando algum avatar quiser adquirir o “Bobi”, este deve registar a chave do seu novo dono, passando a obedecer exclusivamente às ordens enviadas por este.

Descrição da aplicação
Os alunos devem criar um objecto com a forma de um cão e atribuir-lhe um nome, por exemplo “Bobi”. Este, cão, deve ser desenvolvido no Second Life, utilizando os objectos disponíveis no mesmo (prims). O desenvolvimento do cão deve decorrer, no terreno referido anteriormente ou em locais públicos (sandboxes), como a Sandbox Morris, por exemplo: http://slurl.com/secondlife/sandbox%20Morris\224\137\21 Quando estive pronto, o cão deve ser colocado em exposição na loja virtual acima referida. Quando alguém o adquirir, o “Bobi” deve captar a chave do futuro dono e a partir desse momento só obedece às ordens deste.

310

Funcionalidades a implementar
O “Bobi” precisa de ser alimentado de 3 em 3 horas. A alimentação consiste em bolinhas de ração que o dono do Bobi lhe fornece sempre que toca nele. Assim, o nome do comando “Touch” deve ser alterado para “Comida”. O “Bobi” é responsável por controlar os intervalos de tempo em que é alimentado. Desta forma, sempre que passarem 3 horas sem ser alimentado, o Bobi deve avisar o dono de que está com fome, por exemplo enviando-lhe uma mensagem. Se as suas presses não forem atendidas, começa a saltar. Ao fim de 4 horas sem ser alimentado, o “Bobi” pára e envia bolas de saliva para o ar. Por fim, se continuar sem ser alimentado, o “Bobi” desliga-se (ou seja: fica inactivo). O “Bobi” unicamente obedece às instruções do seu dono. Sempre que outra pessoa lhe tocar ele ladra, ou seja envia a seguinte mensagem para o canal público: “Bau, Bau”. De cada vez que o “Bobi” recebe uma instrução do seu dono, este deve executá-la. As instruções são mensagens que o “Bobi” recebe e as executa como, por exemplo: dono – stop . Acção do “Bobi” - deixa de seguir o dono e pára. dono – frente 5 Acção do “Bobi” - desloca-se 5 passos para a frente dono – direita 90 Acção do “Bobi” - roda sobre si mesmo 90º para a direita.

O “Bobi”, sempre que no seu caminho aparecer um obstáculo deve desviar-se dele. Outra alternativa consiste em escrever as instruções num notecard, que é lido pelo Bobi e as executa. O “Bobi” deve guardar as tarefas executadas ao fim de um dia de trabalho: nessa altura envia por e-mail ao dono os locais que visitaram e as tarefas que andou a realizar. Podem ser adicionadas ao “Bobi” outras funcionalidades que considerar interessantes.

2ª Fase do trabalho prático

311

Agora que o cão está pronto para ser vendido, pretende-se que implementem uma loja virtual no Second Life. O objectivo é construírem um balcão virtual que faça a gestão das vendas. Assim o balcão deve registar os seguintes elementos: • o número de cães existentes na loja; • o nome do cão; • a quantidade de cães vendidos; • o preço de cada cão;

O balcão sempre que vende um cão deve actualizar os seus registos. Quando a quantidade existente de cães na loja for inferior ou igual a cinco, deve enviar um email ao fabricante a pedir mais.

312

Licenciatura em Informática

Licenciatura em Tecnologias de Informação e Comunicação

Laboratório de Informática I

Trabalho Prático
Data de entrega: 23 de Junho de 2008

– Simulador de carros –
Introdução
No mundo virtual Second Life pretende-se construir um simulador para carros de alta velocidade. Este simulador deve incluir uma pista, na qual os carros se deslocam, com semáforos e zonas de abastecimento de combustível.

Descrição informal
O simulador é constituído por uma pista e os respectivos carros. A pista é formada por blocos independentes que são dispostos de modo a formar uma linha fechada. É da responsabilidade do utilizador criar esta linha com os blocos fornecidos. A pista contém um controlador que indica quantos os carros estão em circulação, o nome de cada carro e do respectivo dono, e ainda a quantidade de combustível que cada carro tem. O controlador é responsável por cobrar as coimas aos participantes que deixam os carros ficar sem combustível no meio da pista. Sempre que o controlador observa que um carro está parado sem combustível identifica o seu dono e envia-lhe um email com o valor da coima a pagar. Os blocos que formam a pista são de cinco tipos: cruzamentos; simples; curvas 45º; semáforos; combustível. Cada bloco indica, sempre que solicitado, o seu tipo, se está livre, isto é se não tem nenhum carro por cima e as suas coordenadas. O semáforo troca de cor (verde, amarelo, vermelho), de x em x segundos. Os carros movem-se a gasolina e por cada bloco gastam x litros de combustível, especificado no fabrico do carro. Quando a quantidade de combustível for inferior a 0,5 litros deve aparecer por cima do carro a seguinte mensagem: ”Preciso de gasolina” e a cor do carro pisca. Se o carro ficar sem combustível pára e o seu dono recebe uma coima de 313

10LD. Cada carro move-se consoante as ordens recebidas do seu dono. As ordens dadas têm o seguinte formato, nome do carro seguida da ordem. Por exemplo: “vermelho andar”. O dono pode enviar ao seu carro as seguintes ordens: • • • • Andar; virar esquerda/direita; abastecer; parar.

Os carros guardam numa lista as ordens recebidas e à medida que as executam retira da lista essas ordens (fila ordens).

Objectivos
Criar um simulador de carros de alta velocidade que deve ter os seguintes itens: 1. Pista formada por blocos de cinco tipos (cruzamentos; simples; curvas 45º; semáforos; combustível); 2. Controlador da pista que fornece informação sobre os carros que se encontram em circulação e cobra as coimas; 3. Carros que recebem ordens do seu dono e as executam.

314

315

15. Anexos IV
Questionários

316

Questionário Inicial Instituição de Ensino: _____________Nome da disciplina: ___________________

1. Indique o que o motivou a participar nesta experiência?

2. Já estudou anteriormente alguma linguagem de programação? Sim Não

2.1.Se sim, indique qual o resultado obtido.

3. Já conhecia o mundo virtual Second Life? Sim Não

3.1. Se sim, indique o que costuma fazer no Second Life.

317

Questionário Intermédio Instituição de Ensino: _____________Nome da disciplina: ___________________

1. Esta experiência está a ser enriquecedora para si? Sim Não

1.1. Se respondeu Sim, mencione o aspecto que mais lhe agradou até ao momento.

1.2. Se respondeu Não, mencione o aspecto que mais lhe desagradou até ao momento.

318

Questionário Final Instituição de Ensino: _____________Nome da disciplina: ___________________

1. Sentiu dificuldades na execução deste projecto? Sim 1.1.Se sim, identifique-as. Não

2. Expresse a sua opinião sobre o método de ensino usado durante as aulas.

3. Expresse a sua opinião sobre o enunciado do projecto.

4. Se pretender pode deixar aqui um comentário geral.

FIM Muito obrigada pela sua colaboração

319

16. Anexos V
Relatórios diários das aulas no mundo virtual Second Life, assim como os relatórios dos encontros mensais.

320

321

Relatório das aulas de Laboratório de Informática I Actividade Preliminar

Realizadas entre Março e Junho de 2007, na qual participaram 5 alunos da licenciatura em Informática da UTAD.

322

Aula:1 Dia: 12/03/2007

Observações da aula: Os alunos entraram no SL, fizeram o seu registo e escolheram o
avatar, tendo, posteriormente, juntado ao meu avatar no espaço da aula. Ao observarem o meu avatar quiseram saber como podiam personalizar o deles. Desta forma passei a explicar-lhes como usar o editor para poderem alterar a forma do corpo, a cor da pele, entre outros aspectos. Como não podia deixar de ser, todos quiseram saber onde arranjar roupa para vestir o seu. Após esta introdução que serviu também de adaptação ao ambiente, expus os diferentes modos que podem interagir com o ambiente, isto é, tocar nos objectos, voar, dançar e correr. Por último, dedicamo-nos a criar um banco. Assim, passei a explicar como funciona o editor de objectos do SL. Nesta fase de construção, os alunos sentiram algumas dificuldades, nomeadamente: criar cópias de objectos, utilizar o zoom e fazer a ligação entre objectos. Por exemplo, o aluno 2 preferiu fazer 4 pernas do banco do que criar réplicas de uma. Este facto levantou-lhe algumas dificuldades em conseguir obter as 4 pernas do mesmo tamanho e forma. Expliquei-lhe como usar a régua para criar objectos do mesmo tamanho. Os alunos 3 e 4 tiveram alguma dificuldade em efectuar a ligação dos objectos, disseramme que “…não dava que aparece uma mensagem de erro.”. Esta mensagem diz que não podem ligar os objectos porque não são os seus donos. Por conseguinte, expliquei-lhes qual a razão deste erro. Ao fim de alguma insistência lá conseguiram fazer a ligação. Por outro lado, alguns alunos foram mais rápidos a fazer o que eu tinha sugerido, pelo que estes tiveram de esperar que os colegas acabassem e por isso começaram a falar uns com os outros e a voar, o que perturbou um pouco os alunos mais atrasados. Três alunos não conseguiram acabar, tendo ficado para trabalho de casa.

323

Aula: 2 Dia: 19/03/2007

Observações da aula: Nesta aula, o avatar de alguns alunos já tinha um aspecto diferente.
Comecei por expor qual o objectivo da aula, criar o cão para o projecto, e perguntei se tinham alguma dúvida em relação ao que fizemos na aula passada, disseram-me que não. Começamos a construção do cão. Os alunos estavam com algumas dificuldades em iniciar a construção, tendo referido: “ que não tinham jeito para desenho”. Assim, mostrei-lhes um exemplo e expliquei-lhes quais as primes que usei para o fazer. Desta forma, todos eles começaram a criar um cão. No decorrer da aula fui-lhes relembrando o que tínhamos feito na aula anterior com o banco, ou seja criar cópias de objectos. É importante que um cão tenha as patas todas do mesmo tamanho, assim como as orelhas. Como já não se lembravam de como se cria uma réplica, tive de lhes explicar novamente. Expliquei-lhes as vantagens de criarem cópias dos objectos, como para além de terem a certeza que são todas iguais, torna-se mais rápida a sua construção. Nesta fase dei especial atenção ao aluno 2 que na aula anterior não conseguiu criar as réplicas das pernas do banco. Os alunos sentiram algumas dificuldades em criá-las, estavam sempre a dizer: “isto dá erro”, “não me deixa fazer uma cópia”. A causa do problema residia no facto que eles seleccionavam também o chão da sala, e como não eram os donos de todos os objectos, o SL não lhes permitia criar as réplicas. Expliquei-lhes como usar o zoom para terem a certeza de que estavam a seleccionar só os seus objectos. Os alunos 3 e 2 sentiram alguma dificuldade em compreender como fazer o zoom e diziam: “isto aqui não funciona...”, “ não consigo ver nada…”. Ao fim de alguma insistência lá conseguiram fazer os passos que eu estava a dizer. A razão pela qual eles não estavam a conseguir era que não clicavam nas teclas em simultâneo. Os alunos 1 e 5 decidiram que o seu cão devia ter pernas e patas, pelo que lhes disse que era melhor ligarem a perna à pata do cão e depois criarem réplicas do objecto já ligado. Estes alunos não estavam a conseguir criar réplicas completas da pata do cão, só criavam réplicas da perna. O problema estava na ligação de objectos. Pedi-lhes que tentassem mover a pata do cão para cima, logo observaram que só se deslocou a perna, uma vez que estes objectos não estavam ligados entre si.

324

Notou-se alguma dificuldade por parte dos alunos em compreender a sequência dos comandos que tinham de executar, para ligar os objecto e criar réplicas. Tive de repetir a mesma informação várias vezes no decorrer da aula. Observei que os alunos se esqueciam de como fazer as coisas frequentemente. O objectivo inicial da aula, criarem um cão, não foi atingido; nenhum aluno conseguiu chegar ao fim com o cão completo. Nesta aula, o cão apenas ficou com o corpo completo tendo ficado por fazer o focinho. Assim, pedi-lhes que terminassem em casa e que na próxima aula iríamos começar a programar.

Aula: 3 Dia:26/03/2007

Observações da aula: O aluno 1 faltou a esta aula. Ao ver os cães verifiquei que não
tinham feito o que lhes pedi na aula passada. Pediram-se se podiam acabar a construção nesta aula, tendo justificado que tinham um outro trabalho para fazer, pelo que não tiveram tempo de se dedicar a este. Assim, consenti que na primeira parte da aula terminassem a construção. Nesta aula os alunos dedicaram-se a criar o focinho do cão, isto é colocarem os olhos, boca, nariz. Para criarem e colocarem os olhos e o nariz do cão é necessário que se utilize o zoom. Desta forma disse-lhes como deviam usar o zoom para conseguirem melhor desenvolver os olhos do cão. Isto implica que se use o zoom, que se faça a ligação e cópia de objectos. As dificuldades da aula anterior mantiveram-se. Os alunos já não se lembravam como efectuar a réplica, sucederam os mesmos erros por estarem a seleccionar objectos que não lhes pertenciam. Contudo desta vez já sabiam a razão de ser do erro mas diziam que “eu só seleccionei os meus objectos...” , mas ao repetirem o processo verificavam que afinal isso não era verdade. Em relação a fazerem o zoom verificou-se alguma dificuldade apesar de na aula anterior os alunos 3 e 5 já terem utilizado o zoom não foram capazes de voltar a usá-lo. A aula ao contrário do que tinha previsto foi dedicada à construção não conseguiu começar com a programação. Apesar das dificuldades, nota-se que os alunos estão a gostar do que estão a fazer, cada um dele está a empenhado para que o seu cão seja o mais bonito, razão pela qual não se conseguiu entrar na programação. Pedi-lhes que em casa dessem uma vista de olhos ao manual da linguagem LSL que está online.

325

Aula:4

Dia: 2/04/2007

Observações da aula: Nesta aula faltaram os alunos 2 e 5, os colegas disseram que como
têm um trabalho para entregar estes alunos faltaram. Perguntei se tinham lido alguma coisa sobre a linguagem LSL, responderam-me que não tiveram tempo devido ao trabalho que têm para entregar. Assim, tive de alterar o que tinha planeado para esta aula. Comecei por lhes explicar como funciona a programação no SL e a onde os programas são colocados, pelo que pedi-lhes que criassem uma prime no mundo e lhe adicionassem um script. A seguir expliquei-lhes como funciona a linguagem LSL e as suas características. Continuei e pedi-lhes que alterassem o script para que o objecto diga o nome deles quando tocado. Pode observar, pelos seus comentários, que estavam entusiasmados por o objecto dizer o nome deles. O aluno 1 disse: “…olha o meu já sabe o meu nome…”; o aluno 3 “… isto é engraçado…vou trocar-lhe o nome..”. Para melhor compreenderem o significado das funções que estavam a utilizar pedi-lhes que fossem à página do lsl wiki e lessem o que estas funções fazem. Deste modo ficam a saber onde procurar ajuda sobre as potencialidades da linguagem e a perceberem como esta são descritas. Passado algum tempo pedi que me dissessem o que esta faz, verifiquei que só um deles, o aluno 4, tinha percebido, os restantes disseram-me se não havia em português pois tinham dificuldades no Inglês. Então tive de lhes explicar o que lá estava escrito. Depois dei-lhes um pequeno exemplo para eles testarem. Este programa inicial mostrava como um objecto podia enviar informação para o mundo pelo canal público, exemplificando como se definem variáveis. No fim de o terem testado expliquei-lhes como este funciona e pedi-lhes que o alterassem a mensagem e todos eles foram capazes de o fazer. No fim desta etapa introdutória fiz uma revisão das estruturas de controlo, nomeadamente a estrutura de decisão if. Mostrei-lhe um exemplo de aplicação, o qual eles testaram, pedilhes que inserissem mais um outro if para o caso da mensagem recebida ser um “parar”. O aluno 4 disse-me que o dele estava a dar um erro pedi para partilhar o código comigo. Ficaram surpreendidos por verem que podem ver o código uns dos outros de uma forma 326

tão rápida. Aluno 4 disse: ”..olha que fixe…assim podemos trocar código….”. Aproveitei para lhes explicar como se faz para partilhar o código, houve alguma dificuldade principalmente os alunos 1e 4 porque não estavam a conseguir fazer o que eu lhes dizia. Depois de ver o código disse-lhe para ver o que faltava na linha 8 de pois do if. O aluno conseguiu emendar o erro. Após esta introdução passamos a falar do projecto e rever quais as funcionalidades que este tinha de ter e o que tinha de estudar da linguagem para a próxima aula. Chamei-lhes a atenção para a importância de eles estudarem um pouco sobre a linguagem antes da aula, para que consigam progredir mais na compreensão da linguagem. Os alunos voltaram a referir que tinham disciplinas em atraso e que por isso não tinham muito tempo para se dedicarem ao projecto.

Aula:5

Dia:16/04/2007

Observações da aula: Esta aula começou um pouco atrasada devido alguma dificuldade
de os alunos entrarem no SL, problemas na rede da UTAD. A esta aula estiveram todos os alunos presentes, perguntei se tinham estudado ou lido alguma coisa disseram-me que não por falta de tempo. Devido ao facto de os alunos 2 e 5 não terem estado na aula anterior estive mais tempo dedicada a estes alunos a explicar as funcionalidades da linguagem, os restantes alunos preferiram estar a recapitular o que tinham feito do que a fazerem coisas novas. Assim, pouco se avançou nesta aula. Estivemos a ver o que é uma função e quais as funções preexistentes da linguagem e como se podem criar funções. Passamos em revista as funções preexistentes na linguagem que os alunos vão precisar de utilizar no seu projecto, embora não lhes tenha dito. Estiveram a testar cada uma delas. Esta fase da aula correu relativamente bem, alguns alunos cometeram pequenos erros. Para corrigir estes erros pedi que partilhassem o código e verifiquei que mais uma vez já não se lembravam de como o fazer. Os alunos 2,5 3 o 1 tiveram alguma dificuldade me conseguir partilhar o código por não seguirem os passos que eu lhes disse correctamente. Por fim lá se consegui que o fizessem e pude ver os erros que estavam a cometer, o aluno 3 tinha as funções a serem chamadas no sítio errado, isto é fora do programa principal; o aluno 2 faltava-lhe um ; no fim da chamada da função. Por fim, pedi-lhes que criassem uma função que recebesse uma mensagem e caso esta fosse “escrever” escrevia a mensagem no canal público caso

327

fosse “cor” mudava a cor do objecto para verde. O aluno 5 teve dificuldades em chamar a função, começou por se queixar que não funciona, depois de observar o código expliqueilhe que não era assim que se chama uma função. Os restantes alunos conseguiram fazer mas com alguns erros o mais frequente foi a falta de ; no fim das instruções. Novamente lhes pedi para estudarem um pouco da linguagem e começarem a fazer o projecto.

Aula: 6

Dia:23/04/2007

Observações da aula: Comecei a aula por fazer uma revisão do que já se tinha estudado
em relação à linguagem LSL. De seguida expliquei-lhes o que eram os eventos e como este funcionavam. Os alunos 2,3 e 4 disseram que não estavam a perceber nada então dei-lhes um exemplo para testarem e tive de lhes explicar o que cada linha de código fazia e como funciona. Deste modo, os alunos ficaram a perceber como funcionam os eventos. A seguir informei os alunos que nesta aula era para eles começarem a fazer o projecto, assim deviam colocar o cão e seguir o seu dono. Os alunos 4 e 2 ficaram sem saber por onde começar e pediram-me para eu os ajudar. Disse-lhes que era para irem ver os exemplos que tínhamos visto nas aulas anteriores e tentarem fazer. Observei que estavam muitas mensagens a ir para o canal público o que dificultava a comunicação entre mim e os alunos. Assim, pedi aos alunos que passassem a mandar as mensagens dos objectos directamente para o seu dono. Tive de fazer várias chamadas de atenção geral para lhes explicar que antes de usar uma variável deviam declara-la. Para eu poder observar os erros que o programa dos alunos tinha era necessários que os alunos me dessem permissão. Observou-se que os alunos não conseguiram partilhar o código pois não davam as permissões correctas, foi necessário eu explicar individualmente a cada um o que tinham de fazer para finalmente conseguir observar o código. Reparei que os alunos estavam com algumas dificuldades em conseguir fazer o pretendido. Os alunos 3 e 5 estavam a tentar fazer o pretendido mas sem sucesso. O aluno 3 referiu “.. o cão não é nada obediente …só faz o que lhe apetece….”. Pedi para partilhar o código e novamente tive de lhe dizer como o devia fazer. Ao observar o código deste aluno 3 verifiquei que apenas estava a alterar a função que tinha feito na última aula. Fui confirmar o que os outros estavam a programar e conclui que só o aluno 1 estava no bom caminho. Face a estas dificuldades decidi que seria melhor dar-lhes um pequeno exemplo para eles testarem e a partir deste alterar para o pretendido. Com este exemplo os

328

alunos conseguiram fazer o cão andar, com excepção dos alunos 2 e 4. Estes alunos estavam constantemente a pedir auxilio, à mínima dificuldade, como por exemplo a falta de um ; não sabiam o que fazer. O aluno 2 referiu que já estava a algum tempo a pedir para eu ver o código dele mas eu não respondia. Esta dificuldade na comunicação deve-se principalmente pelo facto de eu estar a ver o código de outros colegas e não estar atenta às mensagens que estão a passar no canal público. Apesar de eu pedir para que os objectos não enviem mensagens para o canal público alguns ainda continuam a fazê-lo. Os erros de sintaxe mais comuns observados na aula de hoje são que alguns alunos continuam a esquecer-se de declarar as variáveis antes de as usar, assim como colocarem ; no fim das instruções. Esta aula foi a primeira em que eles já tinham que desenvolver o projecto autonomamente mas observei que a maioria dos alunos não é capaz de o fazer por falta de estudo, pelo que necessitam de um acompanhamento mais intenso da minha parte.

Aula 7

Dia:30/04/2007

Observações da aula: O aluno 1 faltou a esta aula. Informei os alunos que o objectivo
desta aula era colocarem o cão a receber ordens do dono e a executá-las, principalmente o andar e o parar. Assim disse-lhes para criarem um cubo e colocarem este a responder “sim” para o dono sempre que este diz “olá”. A seguir iriam trabalhar no cão deles de forma a completarem uma parte do projecto. Como aconteceu na alua passada a maioria dos alunos não sabia por onde começar, pelo que tive de lhes dar um pequeno exemplo e explicar como este funciona. Pedi-lhes então que o adaptassem de forma a fazer o que tinha pedido no inicio da aula. Na generalidade todos foram capazes de o fazer, com excepção do aluno 2 que tem mais dificuldades. O aluno 4 queixou-se que “.. eu já chamei a professora várias vezes…” como a quantidade de mensagens a circular no canal público continua a ser um pouco exagerada o que dificulta a comunicação entre mim e os alunos. Esta situação devese ao facto de os alunos necessitam de enviar mensagens para o cão, é necessário repensar o modo como se comunica. Observou-se novamente que os alunos se esquecem de como se partilha o código, tenho de pensar numa forma de ter esta informação sempre presente durante as aulas para eles lerem. A adaptação do código feito ao projecto foi um pouco mais difícil para a maioria dos alunos, tive de lhes dizer que era melhor criarem uma função andar e outra para analisar as mensagens recebidas de forma que quando a mensagem fosse

329

“andar” só tinham de chamar a respectiva função. A aula terminou e eu pedi-lhes que tentassem em casa terminar esta parte do projecto. Estes alunos conseguem acompanhar e fazer o que lhes é pedido, se partirem de um exemplo semelhante ao que têm de fazer. Estão um pouco atrasados no desenvolvimento do projecto mas como eles não trabalham em casa não sei se vão conseguir implementar todas as funcionalidades requeridas.

Aula 8

Dia: 7/05/2007

Observações da aula: Faltou o aluno 5. Perguntei se tinham acabado o que ficou da aula
passada, isto é colocar o cão a seguir o dono quando este lhe envia a mensagem “anda”. Disseram-me que não, assim nesta aula foram terminar essa parte, expressei-lhes a minha preocupação em eles conseguirem implementar todas as funcionalidades pedidas no projecto até ao final das aulas. Os alunos 2 e 4 pediram-se se eu podia estar com eles no SL na próxima semana, fora das aulas para adiantar o projecto, disse-lhes que sim, os restantes alunos também disseram que iam aparecer. Os alunos 1 e 3 foram trabalhar fora da sala, para verem o cão a andar. O que dificultou a minha tarefa pois tive de me deslocar algumas vezes cá fora para os ajudar e observar o cão. O aluno 2 queixou-se que estava a precisar de ajuda e eu não lhe dizia nada. Alguns dos erros mais frequentes nesta fase foi a falta de ; e chamarem as funções no sítio errado, isto é fora do programa. Nota-se que os alunos não compreendem o que as mensagens de erro dizem, como foi o caso do aluno2 em que lhe faltava um ; e não foi capaz de perceber.. Nesta aula apenas conseguiram completar o que ficou da aula passada. Contudo o aluno 2 e 4 não foram capazes de o fazer parar quando o dono lhe envia a mensagem “Parar”. Nesta aula senti alguma dificuldade em conseguir acompanhar as actividades de todos os alunos, devido ao facto de eles estarem muito dispersos pelo terreno. Marquei uma aula suplementar para a próxima semana das 18h às 20h, para ver se eles avançam um pouco mais no projecto

330

Aula 9 Dia: 14/05/2007

Observações da aula: Faltaram os alunos 2 e 5. Nesta aula os alunos deviam colocar o
cão a rodar para a direita e esquerda conforme a mensagem do dono. Esta fase foi mais fácil para a generalidade dos alunos, uma vez que tínhamos antes visto um exemplo parecido. Contudo, o aluno 4 precisou que eu o ajudasse a começar pois já não se lembrava desse exemplo. O aluno 3 estava com dificuldades em fazer o parse das mensagens enviadas para saber se a rotação era para a direita ou esquerda. Estive grande parte da aula a ajudar este aluno. Foi preciso partilhar o código para eu poder ver o que o aluno 3 tinha feito, mais uma vez não se lembrava de como dar permissões. Verifiquei que a maior dificuldade deste aluno era em compreender o que as funções predefinidas da linguagem fazem. O aluno 1 veio ter com o meu avatar e colocou-se à minha frente para me chamar a atenção que estava a precisar de ajuda, disse-me que já tinha pedido mas que eu não respondi. Como os alunos estão muito dispersos pelo terreno eu não consigo visualizar todas as mensagens que estão a passar no canal público, dai a dificuldade em me aperceber das chamadas de ajuda. Verifiquei que o aluno 1 também estava com dificuldades no mesmo ponto que o aluno 3, sendo a principal razão a não compreensão do que está escrito no lsl wiki. Assim, depois de lhe explicar como usar as funções para separar uma string em vários toIken, fui confirmar com os restantes alunos quais as suas dificuldades e verifiquei que eram as mesmas. Apesar da aula de hoje terminar a hora do costume mantive-me online a pedido do aluno 4, disse que ia sair da sala e já voltava a entrar. Passado algum tempo o aluno voltou a estar online e estive com ele mais 3 horas a ajudá-lo no desenvolvimento do projecto. Este aluno tem algumas dificuldades a programar, principalmente em conseguir saber o que fazer a seguir e por onde começar. Nota-se também dificuldades na compreensão das mensagens de erro, que geralmente são por falta de ; ou por colocarem-no no sítio errado como por exemplo no fim do if. Para o ajudar tento lhe dar pequenos exemplos para ele ver, testar e adaptar ao projecto. Verifiquei com agrado que este tipo de abordagem o tem ajudado a perceber como funciona a linguagem e a progredir aos poucos. No entanto, o aspecto negativo desta metodologia refere-se ao facto de se despender algum tempo para que os alunos compreendam os conceitos resultando num atraso no desenvolvimento do trabalho. Outra dificuldade, deve-se à falta de estudo.

331

Aula 10 Dia: 28/05/2007

Observações da aula: A esta aula compareceram todos os alunos. Como os alunos 2 e 5
não vieram à aula passada perguntei-lhes se tinham feito alguma coisa no projecto disseram que não. Assim estive a ajudar estes alunos a fazer o que os outros tinham feito, colocar o cão a rodar segundo as ordens do dono. Os restantes alunos estiveram a colocar o cão a dizer que tem fome ao fim de 3h sem comer, esta tarefa implica usarem a técnica dos eventos e temporizadores. Relembrei-lhes o que já tínhamos estudado sobre os eventos e disse-lhes para implementarem até ao fim da aula esta parte do trabalho. Os alunos 2 e 5 tiveram dificuldades em saber por onde começar tive de lhes explicar como deviam proceder e quais as funções a utilizar. Ao contrário dos seus colegas na aula anterior estes alunos foram capazes de implementarem esta parte do trabalho sem grandes dificuldades. Continuo a verificar alguma incompreensão das mensagens de erro, principalmente quando falta um ; ou {. Regra geral os alunos esquecem-se de colocar ; no fim das instruções e chamam as funções fora do programa. O aluno 4,1 e 3 estavam com problemas na utilização dos eventos, tive de lhes dar um pequeno exemplo, pois já não sabiam onde tinham guardado o outro que estudaram anteriormente. Foi necessário explicar-lhes passo a passo o que o código fazia. Verifiquei com agrado que o aluno 4 conseguiu implementar o que era pedido, o mesmo não sucedeu com o aluno 1. Ao verificar o código do aluno 1 pude observar que tinha alguns erros de sintaxe, nomeadamente falta de ; chamada incorrecta de funções. Na próxima aula vou começar por lhes lembrar que devem colocar ; no fim de cada instrução e de que as estruturas de decisão não têm ; no fim, pode ser que deste modo os erros de sintaxe diminuam.

Aula 11 Dia: 4/06/2007

Observações da aula: Nesta aula estiveram presentes todos os alunos. Estiveram a
terminar de implementar as funcionalidades que dizem respeito ao temporizador, ou seja, colocar o cão a saltar ao fim de 3h sem comer, mudar de cor ao fim de 4h e desligar-se ao fim de 5h sem comer. Na aula passada fizeram apenas a primeira parte ou seja o temporizador a contar 3h, ficou a faltar o salto. Assim disse-lhes que era melhor colocarem a funcionar o temporizador para 4 e 5 h e recomeçar a contar se o dono der de comer ao

332

cão. A maior dificuldade sentida pela maioria dos alunos foi em saber como inicializar o temporizador sempre que o cão é alimentado. Ao analisar o código individual dos alunos verifiquei que o alunos 2 e3 estavam a inicializar a variável que controla o tempo a zero no sitio errado, o aluno 5 não tinha inicializado a variável. Mais uma vez fiquei surpreendida com o aluno 4 que apresentava mais dificuldades agora consegue fazer o que é pedido sozinho, embora continue com dificuldades em perceber as mensagens de erro de compilação. Nesta aula os alunos 5 e 2 voltaram a queixar-se que estavam a pedir ajuda a algum tempo mas eu não lhes respondia. O aluno 3 salientou que “no SL bastava observar o comportamento do nosso cão para saber se o programa esta correcto, assim é muito mais fácil..” Em resumo é necessário repensar a forma de comunicação, uma vez que eu ao dedicar-me a um alunos que está longe dos outros perco a noção do que os outros estão a fazer e das necessidades que têm.

Aula 12 Dia: 11/06/2007 Observações da aula: Faltaram os alunos 1 e 3. Esta é a última aula e na próxima semana os alunos têm de entregar o trabalho. Avisei-os que ainda têm uma semana para conseguirem acabar o projecto e que eu estaria disponível para os ajudar. Contudo, convinha que na aula de hoje terminassem o temporizador. O aluno 2 teve algumas dificuldades em colocar o cão a saltar, cada vez que passava as 3h, neste caso reduzidas a segundos, o cão deslocava-se pelo mundo descontrolado. Foi difícil de apanhar o cão. Esta situação também aconteceu com o aluno 4. Contudo os alunos reagiram bem diziam que “ o meu cão esta doido de fome..” ou “.. ficou maluco coitado”. Esta situação deveu-se ao facto de os alunos pegarem num exemplo que encontraram no lsl wiki e aplicarem directamente no seu trabalho, sem lerem o que este fazia. Chegamos ao fim da aula e só o aluno 4 conseguiu por o cão a saltar como deve ser, tendo ficado as restantes funcionalidades por implementar.

333

Primeiro encontro mensal

Dia: 27/4/2007 Nesta reunião estiveram presentes todos os alunos de Lab. I. Aproveitei para saber quais as dificuldades que estavam a ter , se estavam a gostar de aprender a programar no SL e quais as razões de na criação dos objectos cometerem constantemente os mesmos erros. Foram unânimes em responder que estavam a gostar da experiência. O aluno 5 referiu: - “…isto é muito melhor aprender no SL é mais engraçado porque vemos logo o que o cão faz” Em relação aos erros constantes na construção dos objectos, o aluno 4 disse que: -“embora a professora explicasse como se devia fazer o zoom nós não compreendíamos que tínhamos de utilizar as várias teclas em conjunto”. Os outros concordaram que a maior dificuldade era em perceber como usar os comandos e que muitas vezes se esqueciam de qual era a sequência. O aluno 1 mencionou que acontecia frequentemente não prestar atenção ao que a professora estava a explicar porque estava a trabalhar no seu cão. Em relação à programação: Os alunos referiram que a linguagem LSL é parecida com o C e que não é difícil, o que a torna mais complicada é o facto de não existir um manual em português. Em relação ao enunciado do projecto os alunos foram unânimes ao referirem que gostam do enunciado o problema maior é que têm alguma disciplinas em atraso o que lhes deixa pouco tempo para se dedicar ao estudo, como é o caso do aluno 1,5 e 2.

Segundo encontro mensal Dia: 31/05/2007 Nesta reunião estiveram presentes todos os alunos. Aproveitei para esclarecer algumas dúvidas sobre o projecto. Perguntei o que consideram que está menos bem nas aulas e como podemos alterar. O aluno 4 referiu que –“…muitas vezes pede ajuda mas a professora não responde….fico sem saber se a professora está online ou não” 334

Os outros também concordaram que a maior dificuldade é em conseguir comunicar comigo principalmente quando eu estou junto de outros colegas. Eu sugeri a utilização de um objecto que quando alguém tivesse dúvidas tocava nele e este mudava de cor ou emitia bolas para o ar. Os alunos acharam uma boa ideia, vamos ver se funciona. No entanto como faltam poucas aulas para acabar fica para o próximo ano.

Terceiro encontro mensal Dia: 12/07/2007 Esta reunião serviu para se fazer um balanço geral da actividade, como foi em tempo de exames os alunos 1 e 5 não puderam comparecer. No geral disseram que gostaram de aprender a programar no SL e que gostariam de repetir a experiência. O aluno 2 referiu que: -“(...) gostei do projecto, mas não dediquei muito tempo para o desenvolver , porque tinha outras disciplinas para fazer. Como achei o projecto fácil pensei que no fim o fazia rapidamente, mas depois não tive tempo para o acabar.” O aluno 3: -“(...) achei o projecto bastante engraçado e fácil. Gostei de ver o comportamento do meu cão, que nem sempre obedecia ao seu dono, mas não dediquei muito tempo a fazê-lo, pois tinha outras disciplinas para fazer.” O aluno 3 referiu ainda que tinham problemas em conseguir comunicar comigo: “Algumas vezes perguntávamos se a professora nos podia ajudar e não obtínhamos resposta.”.

335

Relatório das aulas de Lab III

Actividade Preliminar

Realizadas entre Março e Junho de 2007

336

Aula 1:

Dia: 13/03/2007

Registo de observações: Os alunos entraram no SL, fizeram o seu registo e escolheram o
avatar. De seguida, juntaram-se à professora no espaço da aula. Ao observarem o meu avatar quiseram saber como podiam personalizar o seu avatar, assim estive a explicar como usar o editor para poderem alterar a forma do corpo, a cor da pele, entre outros aspectos. Como não podia deixar de ser, todos quiseram saber onde arranjar roupa para vestir o seu avatar. Após esta apresentação que serviu também de introdução ao SL os alunos formaram grupos de dois, para desenvolverem o projecto ao longo do semestre. Assim formaram-se os seguintes grupos: aluno 1 e 4 e aluno 2 e 3. Os alunos1 e 4 optaram por fazer o trabalho do robô os restantes alunos escolheram o do comboio. Contudo, disselhes que nesta aula não iam trabalhar em grupo, uma vez que todos eles precisam de saber como criarem objecto. O aluno4 e 2 disseram-me que já tinham entrado no SL e estiveram atentar criar um carro mas que não saiu lá muito bem. Os restantes elementos era a primeira vez que tinham contacto com o SL. A estes alunos que já tinham andado a experimentar sugeri-lhes que começassem por criar os objectos do seu trabalho mas eles preferiram assistir à minha explicação de como o SL funciona. Deste modo, estive a explicar como podiam interagir com o ambiente, ou seja como se pode voar, abrir portas ir para outras zonas. A seguir, dedicamo-nos a criar objectos, para começar sugerir que criassem algo simples, como por exemplo uma cadeira ou um banco. Comecei por explicar como funciona o editor, as suas características e funcionalidades e disse-lhes para começarem a criar. Informei-os que podiam fazer cópias dos objectos como, por exemplo, criarem uma perna da cadeira e depois faziam 3 réplicas desta, tendo lhes explicado como isto se faz. Alguns alunos sentiram dificuldades em criarem cópias, como foi o caso do aluno 3 que não estava a perceber e foi necessário que o seu colega aluno 9 fosse ao seu computador explicar-lhe como isto se faz. O aluno 1 não percebeu que tinha de seleccionar e com o rato arrastar uma das setas direccionais para criar a cópia e preferiu fazer 4 objectos. Este facto levantou-lhe algumas dificuldades em conseguir obter 4 pernas do mesmo tamanho e forma. O aluno 4 perguntou-me como podia criar objectos do mesmo tamanho, pois queria fazer um cão. Assim chamei a atenção de todos e expliquei-lhes como

337

usar a régua para criar objectos do mesmo tamanho. Na fase seguinte, ligar objectos entre si de forma a obterem um só. Demonstrei aos alunos qual a vantagem de terem um só objecto e expliquei-lhes como podiam fazer a ligação. O aluno 2, 3 e 4 tiveram alguma dificuldade em efectuarem a ligação dos objectos disseram-me que “… que aparece uma mensagem de erro..”, esta mensagem diz que não podem ligar os objectos porque não são o seus donos, expliquei-lhes qual a razão deste erro, ao fim de alguma insistência lá conseguiram. Alguns alunos não conseguiram acabar as suas construções, tendo ficado para trabalho de casa.

Aula 2

Dia: 20/03/2007

Registo de observações: Verifiquei que todos os alunos tinham terminado a construções
dos objectos da aula passada. Assim, disse-lhes que na aula de hoje iam trabalhar em grupo na construção dos objectos que fazem parte do trabalho prático. Uns vão ter de criarem robôs, outros, o comboio e as respectivas estações. Os alunos não tiveram dificuldades em saber por onde começar a sua construção. Disse-lhes para trabalharem em grupo na construção, que o SL permite a construção colaborativa de objectos. Assim, fui a cada grupo explicar como isto pode ser feito. Os alunos sentiram algumas dificuldades em perceber como fazer esta partilha. A meio da aula já se via o esboço de um comboio e de um robô. Os alunos foram comentando as construções uns dos outros, o aluno 3 referiu que “…o teu comboio para que tem um focinho de cão…”, outro sugeriu ao colega “… tens de colocar uma chaminé …assim fica um comboio a vapor…”. Quando tiveram necessidade de criarem uma réplica das pernas do robô, os alunos já não se lembravam de como isto se fazia. Assim tive de lhes voltar a explicar mas contudo cometeram o mesmo erro, isto é seleccionaram também o chão o que não lhes permitia fazer a cópia. Os alunos 2 e 3 disseram que queriam colocar no centro do comboio uma grelha mas não estavam a conseguir, porque esta fica afasta da parte central deste. Fiz uma chamada de atenção geral e expliquei-lhes como podia usar o zoom para verem melhor os objectos mais pequenos. Os alunos sentiram alguma dificuldade em compreender como fazer o zoom e diziam o aluno 4 disse “..isto não funciona...”. Ao fim de alguma insistência lá conseguiram fazer os passos que eu estava a dizer. Os alunos 1 e 4 perguntaram-me como é que se ligava os objectos entre si porque já não se lembravam. Novamente estive a explicar-lhes como o

338

podiam fazer. Este alunos tiveram algumas dificuldades em compreender o que eu estava a dizer pois os colegas estavam constantemente a trocar mensagens entre si o que perturbou um pouco a aula. Por outro lado, também não foram capazes de o fazer correctamente os alunos disseram que dava erro. Notou-se alguma dificuldade por parte dos alunos em compreenderem a sequência dos comandos que tinhas de executar, para ligar os objecto e criar réplicas. Tive de repetir a mesma coisa várias vezes no decorrer da aula. Observei que os alunos se esqueciam de como fazer as coisas frequentemente. Nesta aula ficou parte dos objectos por construir, pedi-lhes que os acabassem em casa.

Aula 3

Dia: 27/03/2007

Registo de observações: Nesta aula pretendia dar inicio à programação em LSL.
Contudo, os alunos pediram-me para continuara com as construções pois só tinham ainda feito um objecto, robô e o comboio, faltava criar as estações e os restantes robôs. Assim, esta aula foi dedicada à construção. Ao longo desta aula observou-se algumas dificuldades na partilha de objectos entre eles, em criarem réplicas. Alguns alunos já não se lembravam como fazer, outros diziam que dava erro. As dificuldades da aula passada na utilização do editor mantiveram-se nesta aula. Assim como a troca de mensagens entre eles, o que dificultou um pouco a percepção do meu discurso. No final da aula os alunos ainda não tinham todos os objectos criados, pelo que lhes disse que na próxima aula íamos começar a programar e que deviam terminar as construções fora da aula.

Aula 4

Dia: 3/04/2007

Registo de observações: Nesta aula comecei por lhes explicar como funciona a linguagem
LSL e as suas características. Foi com agrado que verifiquei que alguns alunos já tinham andado a experimentar alguns scripts. Informei-os que nesta aula de introdução ao LSL não iam trabalhar em grupo e disse-lhes que era melhor desenvolverem todas as funcionalidades do projecto em objectos simples e que depois de estar pronto ai sim deviam passa-los para os objectos do projecto. Assim, pedi-lhes que abrissem o LSL wiki

339

onde se encontra todas as funcionalidades da linguagem, de modo a que fossem lendo o que cada função faz e como deve ser utilizada. A seguir estivemos a analisar o script que o SL tem por defeito. Estiveram a fazer alterações a esse script, nomeadamente a enviar mensagens para o canal público e para o canal direccionado ao dono do objecto. Nesta aula fez-se uma revisão dos conceitos básicos, tipos de dados, declaração de variáveis, estruturas de controlo e desenvolvimento de funções. Pedi-lhes que criassem uma função altere a cor do objecto consoante o número de pessoas que tocam nele, por exemplo se for 1 passa a vermelho, duas a laranja e 3 a amarelo, devendo também o objecto escrever por cima dele o número de pessoas que lhe tocaram. Na generalidade os alunos conseguiram fazer o pretendido. A maior dificuldade observada consistiu em saber como colocar por escrever por cima do objecto o número de pessoas que lhe tinham tocado. Pedi-lhes que fossem procurar no wiki a função que fazia o pretendido. De forma a poder ver o código dos alunos expliquei-lhes como podiam partilhar o código, ou seja tinham de dar permissões de partilha ao objecto e ao script. Sentiram algumas dificuldades em fazer a partilha do objecto pois já não se lembravam como era. Os alunos 4 foi o primeiro na ver qual a função que devia usar. A maioria dos alunos tiveram dificuldades em saber como usar esta função. Contudo, o aluno 1 e 2 foram à procura de um exemplo na net que estiveram a testar e adaptaram para este exemplo. No fim da aula disse-lhes para irem ver o projecto e começarem a pensar em como o desenvolver e para estudar o envio de mensagens entre objecto. Em resumo, esta primeira aula de introdução ao LSL correu bem, nota-se que estes alunos têm umas noções base de programação e alguma autonomia para procurarem soluções para os seus problemas.

Aula5

Dia: 17/04/2007

Registo de observações: No inicio da aula os alunos 3 e 2 pediram-me se eu podia dar
uma vista de olhos no código deles pois estavam atentar enviar uma mensagem para outro objecto, só que o receptor não o estava a receber. Novamente algumas dificuldades em conseguir partilhar o código. Após observar o código verifiquei que o objecto emissor estava a emitir por um canal e o receptor à escuta noutro, logo nunca podia ouvir a mensagem. Pedi-lhes que me explicassem como funciona a função que estavam a utilizar.

340

Verifiquei que simplesmente tinham copiado o código e não perceberam o que este fazia. Perguntei ao outro grupo se tinham estudado e visto a comunicação entre objecto disseram que sim e que não tinham problemas. Assim, pedi-lhes que explicassem aos colegas o significado de cada parâmetro de entrada da função em causa, tendo estes rapidamente verificado qual a causa do erro. O aluno 2 referiu “..pois então eles deviam estar a usar o mesmo canal de comunicação”. Após terem esta tarefa concluída, estivemos a discutir como implementar algumas das funcionalidades do projecto, que são comuns aos dois grupos, nomeadamente distinguir numa mensagem recebida qual a tarefa a executar. Assim, foram sugerindo várias ideias, tendo concluído que precisavam de separar a mensagem recebida em vários tokens de forma a determinar a tarefa a executar. Pedi-lhes que fossem ver se o LSL já tinha algumas funções predefinidas que os pudessem ajudar. Deste modo foram testando algumas mas não conseguiram descobrir as funções correctas, pelo que tive de lhes pedir que fossem estudar algumas funções da linguagem. Passado algum tempo, o aluno 1 e 4 pediram-se se eu podia dar uma vista de olhos ao seu código pois não estava a funcionar. Novamente a partilha do código não estava correcta faltava o script. Observei que tinham alguns parâmetros de entrada errados nas funções, pedi-lhes que me explicassem o que cada um fazia e vi que não sabiam. Estavam a testar as funções por tentativa erro sem perceberem realmente como esta funciona. Assim., tive de lhes explicar o que cada parâmetro significava e pedi-lhes que o corrigissem. Estes alunos disseram-me que não tinham percebido pois estava a passar no canal público muitas mensagens. Pedi que usassem o canal o dono e tive de lhes explicar novamente. Os colegas também estavam com algumas dificuldades, mas por razões diferentes estavam a usar as funções pela ordem errada. Resumindo estes alunos programam por tentativa erro, muitas vezes sem pensarem no que estão a fazer. A seguir sugeri que a melhor forma de implementarem as diversas funcionalidades era criarem um estado para cada uma delas, em vez de um conjunto de if encadeados. Assim, estive a explicar-lhes como se cria e muda de estado no SL, tendo pedido que tentassem criar vários estados que necessitavam para o projecto. Os alunos 1 e 4 não sabiam como colocar o nome por cima de cada um dos robôs, sugeri que visse a função llSetText. Pesquisaram e concluíram que esta era a função que precisavam, ao utilizá-la surgiu que um robot tinha por cima da cabeça o nome “Alf” e o outro aparecia duas vezes escrito “Alf1”. Os alunos não sabiam o porquê desta situação. Novamente, analisei o script e não havia razão para aparecer dois nomes escritos, sugeri ao aluno que verificasse se o robot não tinha dois objectos com o mesmo scritp. Não conseguiram descobrir qual o objecto que tinha outro script nem como este lá foi parar. Ao

341

analisar o robô verifiquei que no olho direito tinha um script que escrevia o nome do robot. Problema resolvido. No fim da aula disse-lhes que na próxima aula deviam trazer algumas dessas funcionalidades a funcionar. O papel do professor nesta aula consistiu em analisar os erros que foram surgindo e propor possíveis soluções para o aluno pensarem e resolverem o erro.

Aula 6

Dia: 24/04/2007

Registo de observações: O aluno 2 faltou a esta aula. Nesta aula comecei por verificar
junto de cada grupo o que eles tinham feito depois da aula passada. Os alunos 1 e 4 já tinham implementado algumas das funcionalidades do robô e estavam com dúvidas em como colocar o robô a marcar as horas. Este alunos sabiam que precisavam de implementar um temporizador mas não tinham encontrado nenhuma função que lhes indique as horas em segundos. Assim indiquei-lhes algumas funções para eles irem estudar e verem qual desta se adapta melhor ao caso deles. O aluno 3 que estava a implementar o projecto do comboio disse-me que não tinham feito grande coisa. Este aluno estava a tentar colocar o comboio a andar para a frente e para trás mas sem sucesso, disse-me: “..este comboio é muito teimoso, não quer andar…”. Tentei ver o código mas não consegui, assim pedi-lhe que me desse permissões. O aluno perguntou-me como é que fazia isso pois já não se lembrava. Quando observei o código verifiquei que estava a usar as funções erradas, pelo que lhe pedi para me explicar o que pretendia fazer com aquelas funções e pedi-lhe que fosse ler no lsl wiki o que elas faziam. O aluno 3 disse: “ pois não é bem isto que eu quero..”, então propus-lhe que fosse ver exemplos do género que ele estava a tentar implementar. Passado algum tempo este aluno disse-me que já tinha descoberto como era mas estava a dar erro. Fui ver o código e notei que tinha um parâmetro de entrada errado, pelo que lhe pedi para ir ver melhor quais os parâmetros de entrada da função em causa. Deste modo o aluno conseguiu corrigir o erro. Os alunos 1 e 4 andavam de volta do temporizador, reparei que estavam numa grande troca de ideias, sem chegarem a um acordo de como marcar o passar do tempo. Assim pedi-lhes para ver o código, verifiquei que estavam a usar a função correcta mas no sítio

342

errado. Desta forma, perguntei-lhes qual era a ideia de cada um deles, sobre como isto devia ser. Pela explicação que me deram, verifiquei que o aluno 4 estava a pensar correctamente. Assim, sugeri que cada um deles criasse um objecto e implementassem o que estavam a sugerir para ver quem tinha razão. Passado algum tempo o aluno 4 disse : “Vês tinha razão o meu funciona…” enquanto o aluno 1 o programa dele tinha um erro de compilação. Pedi ao aluno que partilha-se o código e expliquei-lhe o que estava errado no código dele. No fim da aula informei-os que se precisassem de ajuda quando estão a trabalhar ao longo da semana me podiam enviar uma mensagem. Em resumo, na aula de hoje os alunos avançaram pouco em relação ao trabalho mas fiquei com a impressão que ficaram a compreender um pouco melhor como a linguagem funciona. Estes alunos programam por tentativa erro e quando não funciona vão alterando à sorte sem pensar, principalmente o aluno 3.

Aula 7

Dia: 08/05/2007

Registo de observações: No início da aula fui verificar o que cada um dos grupos tinha
andado a fazer. Foi com agrado que confirmei que ambos os grupos tinham estado a trabalhar no projecto. O aluno 4 esteve a mostrar-me os objectos que tinham andado a programar e disse-me que alguns residentes perguntaram-lhe se ele não os queria vender, houve um que gostou muito do seu robô. Os alunos2 e3 andavam a tentar colocar o comboio a andar e a parar quando este recebesse uma ordem de paragens mas estavam com algumas dificuldades em conseguir pará-lo. O aluno 2 comentou: “..este comboio não é nada obediente…não pára nas estações.”. Passei grande parte da aula a ajudar este grupo a conseguir colocar o comboio a parar, que é uma funcionalidade base do projecto. Ao fim de várias tentativas sem sucesso feitas pelos alunos, pediram-me para ver o código. Desta forma, pude observar o que estava de errado, estes alunos tinham uma grande confusão no código. Pedi para me explicarem o que aquele código fazia, tendo confirmado que estavam a fazer alterações por tentativa erro, sem pensarem nem compreenderem o que realmente estavam a fazer. Assim aconselhei-os a criarem um objecto simples, criarem um novo script que ponha o objecto a andar e a parar ao fim de 2 metros e a inverter a marcha. No fim de isto estar pronto é que devem ir colocar a função que analisa as mensagens. 343

Os alunos 1 e 4 passaram aula a implementarem a troca de mensagens entre os robôs e a colocar estes a executarem a ordem recebida. Durante esta aula estes alunos não solicitaram a minha ajuda, pelo que perto do fim fui ver o que já tinham feito. Estavam satisfeitos por já conseguirem que os robôs obedecessem ao chefe e executassem alguns dos seus pedidos. No fim da aula disse-lhes que estavam a ir muito bem no desenvolvimento do projecto.

Aula 8

Dia: 15/05/2007

Registo de observações: Os alunos 2 e 3 encontraram-me no SL, no dia 11, e pediram se
eu os podia ajudar. Estive com eles 3h a ajudá-los a colocar o comboio a andar e a parar na estação correcta. A maior dificuldade observada foi em conseguirem analisar as mensagens recebidas de forma a saberem em que estação devia o comboio parar. Nesta aula os alunos 2 e 3 disseram-me que iam sair mais cedo pois tinham um outro trabalho para terminar e estavam a faltar à aula de Lab III na UTAD. Tinham vindo à aula apenas para me mostrarem o que já tinham conseguido avançar desde a última vez que estiveram comigo. As alunos 1 e 4 estiveram a continuara a desenvolver o seu projecto. Estive a rever com este grupo o que lhes faltava fazer. Assim, estivemos a trocar ideias de como implementar algumas funcionalidades principalmente como os robôs podiam se desviar dos objectos. Este grupo ficou de estudar como funcionam os sensores.

Aula 9

Dia: 22/05/2007

Registo de observações: Os alunos 1 e 4 pediram a minha ajuda pois estavam com
dificuldades em colocar os robôs a rodar. Pedi aos alunos que me explicassem como estavam a fazer, disseram-se que estavam a usar a função llSetPos. Expliquei-lhes que havia uma função específica no LSL que rodava os objectos e pedi-lhe que fossem investigar qual seria. Estes alunos foram sugerindo e testando várias soluções sem sucesso até que eu lhes disse para irem ver o que a função llSetRot faz. Concluíram que era esta a função que precisavam mas não estavam a conseguir que funcionasse. Assim, sugeri que fossem à

344

procura de um exemplo. Ao fim de algum tempo voltaram a chamar-me, disseram que estavam a testar mas que não funcionava como eles queriam. Estive a observar o sript e verifiquei que lhes faltava a função llEuler2Rot, pelo que sugeri que fossem ver o que esta função fazia. Por fim, conseguiram colocar os robôs a rodar. Sugeri que criassem uma função para rodar os objectos, sendo esta usada sempre que fosse necessário. Nesta aula, os alunos 2 e 3 não solicitaram a minha ajuda. Contudo, fui verificar o que andavam a fazer e disseram-me que estavam a tentar controlar as encomendas que o comboio recebe de cada estação.

Aula 10

Dia: 29/05/2007

Registo de observações: O aluno 3 faltou à aula. O seu colega, o aluno 2 esteve a
continuar o trabalho sozinho. Disse-me que estavam com alguma dificuldades em controlar as encomendas recebidas. Assim, estive grande parte da aula a ajudar este grupo. Notei que tinham uma grande confusão no código, pelo que lhe disse para criar algumas funções, inserir comentários de forma a que o código se torne mais legível. A maior dificuldade sentida por este aluno consistiu em saber que funções poderia utilizar para separar a mensagem recebida em strings isoladas. Desta forma fui-lhe sugerindo que fosse estudar o que algumas funções predefinidas da linguagem fazem. O aluno conseguiu ver quais a s funções que devia utilizar e foi procurar exemplos de aplicação. Os alunos 1 e 4 também pediram ajuda pois estavam com dificuldades em colocar o temporizador a funcionar e também não sabiam como é que podiam desligar os robôs. Estive a analisar o código destes alunos e verifiquei que embora estivessem a usar a função correcta llSetTimerEvent faltava-lhes o evento timer() que é chamado quando o tempo marcado na função anterior chega ao fim. Assim, estive a explicar como funcionam os eventos em especial o timer. Desta forma os alunos conseguiram colocar o timer a funcionar. No fim da aula, o aluno 3 confirmou-me que já tinha conseguido resolver o problema das mensagens. Os alunos 1 e 4 pediram-me se podia ficar mais um bocado para os ajudar com os sensores. Estive mais 3 horas no SL a ajudar estes alunos a trabalhar com os sensores. A

345

principal dificuldade deles foi em compreender como estes funcionam, nomeadamente conseguirem colocar o sensor a detectar obstáculos que se encontrem à frente do robô.

Aula 11

Dia: 5/06/2007

Registo de observações: Nesta aula os alunos de ambos os grupos disseram-me que
apenas lhes faltava implementar a parte de guardar todas as actividades efectuadas para depois enviarem ao dono por email. O aluno 4 referiu que tinha andado a ver os vectores mas não estava a funcionar. Perguntei-lhes porque não pensaram nas listas, nas quais podiam guardar vários tipos de dados. Assim foram ver como funcionam as listas em LSL. Cada grupo esteve a implementar listas no seu projecto. Os alunos 2 e 3 estavam com alguma dificuldade em conseguirem saber o que estava dentro da lista, estive a ver o código deles e verifiquei que estavam a usar a função errada, pelo que lhes pedi pra irem ver o que aquela função fazia. O aluno 2 disse “ pois não é bem isto que nós queremos”, então sugeri que fossem ler o que fazia as funções llGetListLength e llList2String. Desta forma este alunos conseguiram listar todo o conteúdo da lista e verificar o que esta continha. Os alunos 1 e 4 não estavam a conseguir enviar para o email deles o conteúdo da lista. Verifiquei que tinham um erro nos parâmetros da função llEmail, pedi-lhes que verificassem os parâmetros, tendo conseguido emendar o erro. Ambos os grupos terminaram a aula com esta funcionalidade implementada, lembrei-lhes que a próxima aula era a última antes da entrega do trabalho, tendo me dito que lhes faltava pouco para terminarem o projecto.

Aula 12

Dia: 12/06/2007

Registo de observações: Esta é a última aula do semestre e os alunos têm de entregar o
trabalho na próxima semana dia 18, segunda-feira. Os alunos 1 e4 têm o trabalho completo, pelo que estiveram apenas a embelezar mais os seus robôs. O aluno 4 disse-me que já tinha vendido alguns dos seus objectos e que tinha inclusive recebido encomendas.

346

Disse-me também que várias pessoas queriam comprar os seus robôs mas que não os queria vender pois eram os seus animais de estimação. Este aluno estava a pensar em ganhar algum dinheiro em produzir scripts e objectos para outros avatares. Este aluno referiu:”fiquei viciado no SL” Os alunos 1 e 3 já tinham todo o trabalho completo a nível da programação faltava apenas criar as estações, uma vez que não tinham tido tempo para o fazer. Assim aproveitaram a aula para o fazer. Nesta aula limitei-me a observar as suas construções.

Primeiro encontro mensal

Dia: 26/4/2007 Nesta reunião estiveram presentes todos os alunos. Estivemos a trocar ideias sobre o projecto, tendo os alunos referido que o consideravam um pouco grande e complexo. Perguntei-lhes se estavam a gostar da experiência, disseram que sim. O aluno 2 comentou: “ diverti-me imenso a construir o meu comboio que mais parecia um cão “ O aluno 4 referiu. “ fiquei viciado no SL, passo muitas horas a desenvolver objectos só por brincadeira.”

Segundo encontro mensal

Dia: 31/05/2007 Este encontro, no qual estiveram presentes todos os alunos, serviu principalmente para conversar sobre o projecto e como as aulas estão a decorrer. Referiram alguma dificuldade em conseguirem comunicar comigo. O aluno 1 referiu: “ algumas vezes chamava-mos a professora mas não nos respondia”. Outro problema com as permissões o aluno 3 comentou: “Acontecia frequentemente que não nos lembrávamos como é que se davam as permissões e por isso a professora não conseguia ver o código porque as permissões estavam erradas.”

347

Terceiro encontro mensal

Dia: 12/07/2007 Este encontro serviu para se fazer uma avaliação global das aulas no SL. Os alunos na sua totalidade reafirmaram a sua satisfação em terem participado. O aluno 4 referiu que “fiquei viciado no SL. Já tenho vários clientes, ando a desenvolver objectos e scripts.”, continuou “ ainda não fui capaz de vender os meus robôs apesar de ter recebido boas ofertas”. Quando lhes perguntei se consideravam o SL um bom ambiente de programação, disseram que sim. O aluno 1 acrescentou: “ …no SL é fácil verificar se o programa está correcto ou não basta olhar para o objecto e ver como este se comporta” Todos os alunos confirmaram que se tiverem hipótese gostariam de repetir a experiência.

348

Relatório das aulas de Projecto I Primeiro e segundo ciclos de Investigação-acção

Realizadas entre Outubro de 2007 e Janeiro de 2008

349

Aula 1:

Dia:10/10/2007

Registo das observações: Nesta aula apresentei aos alunos de Proj. I o mundo virtual
Second Life. Nenhum dos alunos presente na aula tinha ouvido falar do SL, mostrei-lhes alguns dos trabalhos desenvolvidos pelos alunos da UTAD. Apresentei o enunciado dos dois trabalhos práticos e o modo como iríamos trabalhar caso pretendessem escolher estes projectos. Nesta turma voluntariaram-se 6 alunos, que formaram os seguintes grupos: aluno R e aluno M; aluno B e aluno D; aluno C e aluno J. Os dois primeiros escolheram implementar o projecto do cão o terceiro grupo ficou com o projecto do boneco de neve. Estes alunos entraram no SL, escolheram e personalizaram o seu avatar. Apresentei-lhes o espaço da aula no qual vamos trabalhar.

Aula 2

Dia: 17/10/2007

Objectivo da aula: No fim desta aula os alunos devem ser capazes de criar um objecto,
alterarem-lhe as suas propriedades como a cor, forma, entre outras.

Registo das observações: Primeira aula realizada online. Os alunos entraram no sistema a
horas. Comecei por lhes mostrar as alterações que fiz ao espaço nomeadamente a zona de trabalho de cada grupo, a zona de exposição onde já se encontra expostos alguns trabalhos dos alunos da UTAD. Expliquei-lhes o modo de comunicação existente, canal público e privado. Referi que iríamos usar o canal público só para explicar ou demonstrar algo para todos os alunos e o canal privado para tirar dúvidas individuais, sendo este o principal meio de comunicação entre mim e cada um deles. Mostrei-lhes o objecto de dúvidas e como podiam colocar lá um cartão. Cada aluno, escreveu num cartão o seu nome, o número de aluno, o nome do colega de grupo e o nome do seu avatar. Expus-lhes o objectivo da aula: “ No fim desta aula vocês devem ser capazes de criar um objecto, alterarem-lhe as suas propriedades como a cor, forma, entre outras”. Assim, comecei por lhes explicar como funciona o editor do SL, pedi que colocassem no mundo um objecto base e colocassem

350

cada face a uma cor diferente. Nesta aula de introdução os alunos não trabalharam em grupo. Recebi solicitações de todos eles a dizer que não estavam a conseguir seleccionar só uma face do objecto, pelo que fiz uma chamada de atenção geral pelo canal público a explicar como isto se fazia. O aluno R continuou com dificuldades, assim como o J, ao fim de algumas tentativas falhadas lá conseguiram fazer o pretendido. O passo seguinte consistiu na criação de um banco, sendo este um objecto simples de criar, o qual envolve a junção de objectos e o desenvolvimento de réplicas. A base do banco todos conseguiram criar, uns fizeram-na redonda, outros quadrada. No que respeita às pernas, os alunos tiveram dificuldade em saber como criar uma cópia do objecto. Recebi várias solicitações em simultâneo dos alunos a queixarem-se que dava erro. Assim fiz uma chamada de atenção geral para lhes explicar como deviam fazer, mesmo assim o aluno M não conseguiu. Deste modo, estive a explicar novamente como isto se faz a este aluno. O aluno J e C estavam com o mesmo problema, pelo que estive individualmente a explicar todos os passos que deviam fazer. Por fim, conseguiram criar as réplicas, no entanto observei que o aluno D preferiu criar 4 pernas em vez de criar réplicas. Contudo, este aluno estava com alguma dificuldade em colocar todas as pernas com o mesmo tamanho, assim expliquei-lhe como podia usar a régua. Perguntei-lhe porque razão não criou uma cópia diz que “Eu tentei mas dava erro e como não queria ficar parado fui criando, assim é mais rápido”. O aluno R disse: “Isto fica assim! o meu banco quando o desloco perde as pernas…hehehe.”. Fiz uma chamada de atenção geral e pedi que movessem o banco, como verificaram que este “perdia as pernas” expliquei-lhes como podiam juntar de forma a criarem um objecto único. O aluno C disse-me que não tinha percebido, pelo que tive de lhe explicar outra vez. O mesmo sucedeu com outros alunos. A maior dificuldade residiu em conseguirem seleccionar apenas os elementos que pertencem ao banco, o que os impede de os juntar.

Notas: nota-se que as dificuldades em compreenderem o funcionamento do editor se
mantêm. A explicação individual, passo a passo resolve a situação mas não é muito viável pois implica ter outros alunos à espera.

351

Aula 3

Dia: 24/10/2007

Objectivo da aula: Criar os objectos do projecto, ou seja o cão e o boneco de neve. Registo das observações: Disse-lhes que nesta aula deviam começar a criar o cão e o
boneco de neve, os objectos que fazem parte do projecto. Referi que nesta aula já deviam trabalhar em grupo. Contudo, eles preferiram trabalhar individualmente disseram que assim viam qual o “animal” que saia melhor. No decorrer da aula fui-lhes relembrado o que tínhamos feito na aula passada com o banco, ou seja criar cópias de objectos, é importante que um cão tenha as patas todas do mesmo tamanho, assim como as orelhas. Como já não se lembravam de como se cria uma réplica de um objecto tive de lhes explicar outra vez. O aluno B começou a criar o cão a partir de um cubo, perguntei-lhe que parte do corpo estava a criar, disse “ a cabeça do cão”, achei estranho e perguntei-lhe se a forma da cabeça não era redonda ou oval, assim o aluno mudou de prim. Os alunos sentiram algumas dificuldades em criarem réplicas das patas, estavam sempre a dizer “isto dá erro”, “não me deixa fazer uma cópia”. A causa do problema residia no facto que eles seleccionavam também o chão da sala, e como não eram os donos de todos os objectos o SL não lhes permitia criar réplicas. Os alunos B e D pediram-me se na segunda parte da aula eu podia ir ter com eles para lhes explicar como funciona o editor. Assim, fiz uma chamada de atenção geral e disse que na segunda parte da aula eu ia à sala. Na segunda parte da aula os alunos disseram-me que assim é mais fácil de perceber, uma vez que o editor tem muitas funcionalidades e muitas vezes eu estou a dizer uma coisa e eles a fazerem outra, só ao fim de algumas tentativas é que compreendem o que eu estava a dizer. Assim estive junto de cada aluno a explicar as diferentes funcionalidades do editor. Expliquei-lhes, também, como se partilha objectos e scripts. Observei que construíram mais rapidamente os objectos.

Notas: O editor do SL deve ser explicado presencialmente. Desta forma os alunos
compreendem o que estamos a dizer e como se faz.

352

Aula 4

Dia: 31/10/2007

Objectivos: Introdução à programação no LSL, revisão de alguns conceitos básicos. Registo das observações: Foi com agrado que observei os alunos a exibirem os seus
objectos, cão e o boneco de neve. No início da aula o aluno R, M e C estiveram a mostrar os objectos que tinham andado a criar, para além do cão. Comecei por relembrar os alunos que no dia 14 deviam-me entregar o algoritmo do trabalho. Expus os objectivos desta aula, tendo iniciado por explicar como funciona a linguagem LSL e as suas características. Esta explicação foi sendo acompanhada por um exemplo que lhes dei para cada um deles experimentar. Os alunos receberam o script e inseriram-no num objecto para o poderem testar. Sugeri que alterassem a mensagem que este continha para que surgisse por cima do objecto o nome de cada aluno. O aluno J não foi capaz de fazer esta alteração, assim tive de lhe dar a função com o texto e pedi-lhe que substituísse a que se encontrava no script por aquela. A seguir, pedi que abrissem a página do lsl wiki e fossem procurar o significado da função llSetText. O aluno B disse-me que não estava a perceber o que esta função fazia concretamente, pelo que tive de lhe explicar o que lá estava escrito. Perguntei-lhe se tinha dificuldades no Inglês respondeu-me: “sim, só tive francês”. Confirmei com os restantes alunos se tinham percebido o que esta função faz e conclui que 3 deles tinham dificuldades em ler Inglês. O exemplo seguinte, que os alunos estiveram a testar, teve por objectivo introduzir os tipos de dados básicos do LSL, declaração e iniciação de variáveis e as estruturas de decisão. Pedi que fizessem algumas alterações ao código, nomeadamente alterassem o valor das variáveis, declarassem outras e alterassem a estrutura de decisão para o caso de a condição ser falsa. O aluno J solicitou a minha ajuda dizendo que o programa dele estava a dar um erro de compilação. Pedi-lhe que partilhasse o código mas este já não se lembrava. Assim fiz uma chamada de atenção geral e relembre-lhes como se partilhava o código. Ao analisar o código do aluno J observei que tinha ; no fim do if logo dava-lhe um erro no else. Expliquei-lhe a causa do erro e este corrigiu. Em simultâneo fui recebendo várias solicitações de ajuda, pois estavam com alguns erros de compilação. No geral os erros

353

consistiam em faltas de ; ou a existência dele no sítio errado. A seguir, pedi que alterassem o if para um swicth. Só o aluno B não foi capaz de o fazer, estive a ver o código e observei que lhe faltava o case. Por último estivemos a rever os ciclos, novamente lhes dei um exemplo e pedi que testassem e fizessem alterações. Nem todos os alunos conseguiram fazê-las pois a aula chegou ao fim. No fim da aula pedi-lhes que fossem pensando no projecto, lendo alguma coisa da linguagem.

Notas: Notei alguma demora, da minha parte, em conseguir responder a todas as
solicitações que ocorreram em simultâneo. Assim como a repetição de algum erros de sintaxe.

Aula5

Dia: 7/11/2007

Objectivos: Estudo de funções, declarar, chamar e definir funções. Comunicação entre
objectos.

Registo das observações: Nesta aula comecei por rever algumas das funções predefinidas
da linguagem LSL que já tínhamos utilizado. Estive a explicar como se podem criar funções no LSL e dei-lhes um exemplo para testarem. Pedi que criassem uma função que escrevesse por cima do objecto o nome de cada um dos elementos do grupo. Os alunos C e J estavam com algumas dificuldades, pedi que me partilhassem o código. Fiquei surpreendida por estes alunos se lembrarem de como isto se faz. Observei o código e reparei que estavam a chamar a função no sítio errado, isto é fora do programa. O aluno B, também solicitou a minha ajuda ao ver o código observei que lhe faltava um ; no fim da chamada da função. Na generalidade os erros de compilação são devido à falta de ; ou { mal colocadas como foi o caso do aluno R. Na segunda parte da aula, depois do intervalo, estivemos a ver como se processa a comunicação entre o dono e um objecto, assim como entre objectos. Assim, comecei por explicar o conceito de comunicação e como este se processa no SL e dei um exemplo para os alunos testarem. A seguir fomos colocar um objecto a comunicar com outro. Neste caso surgiram algumas dificuldades, ao observar o código dos alunos reparei que no geral o

354

problema consistia no facto de o objecto emissor e receptor não estarem a comunicar pelo mesmo canal. O aluno D disse-me que estava a testar um exemplo que tinha retirado da net mas que dava um erro de compilação, ao observar o código reparei que lhe faltava uma }. O aluno M perguntou-me se ainda estava online, disse que sim, tive de lhe pedir desculpa pela demora em responder mas estava a ver o trabalho de outro colega. Após terem completado esta parte do exemplo, foram fazer alterações de forma a conseguirem implementar algumas das funcionalidades pedidas no projecto. Os alunos foram capazes de implementar esta troca de mensagens entre o dono e o cão ou boneco de neve com relativa facilidade. O aluno R perguntou se era possível separa em strings as mensagens enviadas, por exemplo rodar 90 ele precisava de separar a mensagem em duas. Assim, fiz uma chamada de atenção geral e expliquei-lhes como isto se fazia, tendo lhes pedido que fossem ver no LSL wiki. O aluno B que não percebe muito bem Inglês estive a explicar o que estas funções faziam. Reparei que os alunos tinham ido à internet procurar exemplos e que estavam a testá-los. No fim da aula relembrei que tinham de entregar o algoritmo antes do inicio da próxima aula.

Notas: Observei que os alunos conseguem lidar com o editor, as constantes falhas em
saber como partilhar o código, observadas no ciclo anterior, não se constatam aqui. Alguma repetição de erros, por parte dos mesmos alunos.

Aula 6

Dia: 14/11/2007

Objectivos: Comunicação entre objectos, continuação. Eventos. Registo das observações: Verifiquei que todos os alunos me tinham enviado por email o
algoritmo do trabalho. Foi com agrado que observei que alguns alunos já estavam a implementar algumas das funcionalidades pedidas. Os alunos R e M tinham ido à internet e estavam a testar os exemplos, pediram a minha ajuda pois queriam colocar o cão a seguir o dono mas estavam com algumas dificuldades. Observei o código deles e pedi para me explicarem o que este fazia, reparei que não sabiam muito bem. O aluno R referiu que tinham ido buscar à net mas não estava a funcionar assim estive-lhes a explicar o que

355

algumas das funções faziam ao aluno R e depois ao M. Expliquei-lhes o que tinham que alterar no código deles. Os restantes alunos também andavam a tentar colocar o cão a seguir o dono. A maioria dos alunos estavam a fazer alterações no código por tentativa erro, sem perceberem o que estavam a fazer. Os alunos B e D testaram vários exemplos e tentaram criar um deles através da junção dos exemplos testados. Pediram a minha ajuda pois estavam com algumas dificuldades com os erros de compilação. Observei que tinham uma grande quantidade de erros. Assim, disse-lhes que a melhor forma era pegarem num exemplo, e fazerem pequenas alterações mas irem compilando e corrigindo os erros que surgissem. Perguntei ao aluno B com quem tinha estado a falar se o seu colega tinha acompanhado a nossa conversa disse-me que sim. Posteriormente fui confirmar com o aluno D, este disseme que sim e já estava a implementar o que tinha sugerido. Fiz uma chamada de atenção geral, e estive-lhes a explicar como funcionam os eventos, pois alguns alunos estavam a utilizá-los mas não sabiam o que eram. Os alunos C e J estavam mais atrasados pois não tinham ainda conseguido separar as mensagens recebidas em várias string isoladas. Assim estive a ajudar este grupo mas foi necessário dar-lhes um exemplo para eles verem. O aluno B chamou a minha atenção para o cão dele, “ professora olhe repare no meu cão…este já anda a trás de mim mas não pára quando eu digo parar.”, “ este cão não é nada obediente..hehehe”. Fui observar o código do cão e reparei que este não tinha o código necessário para poder seguir o dono. O que o aluno tinha feito foi associar o cão ao avatar. Assim, chamei-lhe a atenção que não era isto que se pretendia, ele replicou “isso sei eu…estava a brincar”. Os alunos C e já tinham algumas funcionalidades do boneco de neve a funcionar, pediramme que tocasse no boneco e este escreveu por cima da cabeça a mensagem “ não és o meu dono”. Agora queriam fazer a parte do marcar o passar do tempo mas não sabiam como. Assim disse-lhes que fossem ver as funções llSetTimerEvente timer, que são eventos. O aluno M queixou-se que estava a pedir ajuda algum tempo mas eu não lhe respondia, tive de lhe pedir desculpa mas estava a ajudar outros colegas. Disse-me que o código dele e do colega estava com erros de compilação ao observar verifiquei que lhe faltavam alguns ; e {. Chamei-lhes a atenção de que no fim de uma instrução leva sempre ; e pedi para irem verificar o código deles. Assim, conseguiram emendar alguns erros mas não todos, pelo que tive de os ajudar a corrigir alguns.

356

No fim da aula fiz uma chamada de atenção geral, para lhes relembrar que na próxima aula têm de entregar a primeira fase do trabalho para avaliação, objectos receberem ordens do dono. Para que os alunos não se esqueçam coloquei na sala um objecto com texto escrito por cima a relembrara a data de entrega da primeira fase.

Notas: Esta aula correu bem, os alunos estão a progredir no desenvolvimento do projecto.
Noto alguma dificuldade da minha parte em conseguir dar resposta às várias solicitações que ocorrem em simultâneo. É necessário ter uma forma de dizer algo aos alunos rapidamente. Continua haver repetição dos mesmos erros e os alunos não conseguem resolver sozinhos.

Aula 7

Dia: 21/11/2007

Objectivos: Eventos, (início do 2 ciclo). Registo das observações: Relembre-lhes da existência do objecto de dúvidas, uma vez
que até ao momento nenhum aluno o utilizou. Fui confirmar se tinham a primeira fase do trabalho pronta para entregar todos os grupos me disseram que sim. Desta forma sugeri que me enviassem que me enviassem por email o script. Nesta aula estive a rever o que tínhamos dado sobre eventos. O aluno B disse-me que não estava a perceber, dei-lhe um exemplo para ele testar e coloquei comentários a explicar algumas das funções utilizadas. Este aluno comentou que assim com a explicação no código é mais fácil de compreender o que este faz. Desta forma achei melhor dar este código também aos restantes alunos. O passo seguinte consistiu na alteração do código dado de forma a implementarem o temporizador. Os alunos R e M solicitaram a minha ajuda pois o programa deles estava com erros. Observei o código destes alunos, tendo verificado que os erros se deviam à falta de ; e }, assim escrevi no código deles um comentário sobre as causas do erro. Os alunos foram ver e conseguiram corrigi-los. O aluno R comentou: “pois esquecemo-nos sempre do ;”. Os alunos B e D estavam com alguma dificuldade em mudar o nome do comando “tocar” para comida, tive de lhes estar a dizer como isto se faz. O mesmo problema teve o aluno R e M. 357

Os alunos B e D pediram a minha ajuda pois não estavam a conseguir colocar o tempo a zero quando o dono tocava no cão. Ao observar o código reparei que não tinham declarado a variável. Assim, em vez de lhes dizer a causa do erro escrevi no código um comentário para eles lerem. O aluno B disse: “pois, assim não podia funcionar…” O aluno C já tinha solicitado a minha ajuda mas ainda não tive oportunidade para lhe responder, quando falei com ele, disse-me “ estou aqui com um erro já algum tempo…”. Reparei que o erro é por falta de uma }, escrevi um comentário no código a referir que todas as funções terminam por }. No fim da aula confirmei a recepção de todos os trabalhos.

Notas: Estes alunos mostram-se empenhados na implementação do seu projecto. A escrita
de um comentário explicativo teve uma boa aceitação mas implica alguma demora em responder.

Aula 8

Dia: 28/11/2007 Objectivos: eventos, temporizador.

Registo das observações: Informei os alunos que ia acrescentar algumas funcionalidades
ao projecto, nomeadamente o desenvolvimento de uma loja virtual na qual fosse possível vender o cão e o boneco de neve aos residentes do SL. O aluno B comentou: “assim fica mais completo e engraçado…ainda vamos ganhar dinheiro com isto”. O aluno M não gostou muito da ideia por ser uma sobrecarga de trabalho. Na generalidade os alunos aceitaram bem esta alteração. Informei os alunos que se encontrava no Moodle da disciplina um pdf sobre a linguagem LSL em português com a explicação de algumas das funções mais utilizadas. Relembrei-lhes que na próxima aula tinham de entregar a 2ª fase do projecto. Verifiquei que todos os grupos tinham esta fase completa. Os alunos R e M pediram a minha ajuda, pois já tinham o temporizador a funcionar, no entanto o cão não enviava bolas para o ar ao fim de 4h sem comer. As restantes funcionalidades já estavam a funcionar correctamente. Assim, ao observar o código reparei que não estavam a usar a função llParticleSystem, perguntei como estavam a pensar

358

implementar esta parte do programa. O aluno R disse-me que o cão devia atirar bolas, tipo de futebol para o ar, que tinha no seu inventário. Expliquei-lhes que o que se pretendia era que o cão deitasse para o ar bolas de sabão e mostrei-lhes um exemplo, tendo referido que fossem ver como funciona a função llParticleSystem. Os alunos B e D chamaram a minha atenção para eu ver o cão deles, este já tinha a funcionalidades do comer todas a funcionar. Contudo estes alunos queriam que as bolas fossem transparentes e o cão estava a deitar bolas vermelhas. Assim, expliquei-lhes que isso depende das constantes que estavam a usar na função llParticleSystem. Os alunos R e M disseram-me: “professora o nosso já funciona…olhe veja”. Ambos os grupos ficaram com a funcionalidades do comer a funcionar. Perguntei se o cão já se desligava caso o dono continua-se sem lhe dar de comer, só os alunos B e D tinham esta funcionalidade a funcionar. Assim pedi-lhes que explicassem aos colegas como podiam implementá-la. No fim da aula os alunos B e D pediram-me se os podia ajudar a colocar o cão a seguir o dono. Estes alunos já conseguiam identificar as ordens do dono faltava-lhes colocarem o cão a obedecer às ordens. Assim, estive com este grupo mais 2 h depois da aula a ajudá-los. A maior dificuldade deste grupo de alunos consiste em saber que funções utilizar. Na maior parte das vezes eles vão à procura de exemplos que depois não conseguem adaptar, nem compreender como funcionam. A minha ajuda resumiu-se a comentar alguns dos exemplos que eles estiveram a testar para que eles compreendessem o que as funções fazem.

Notas: No decorrer desta aula notou-se um decréscimo de solicitações por causa dos erros
de compilação mais comuns.

Aula 9

Dia:5/12/2007 Objectivos: movimento autónomo de objectos

Registo das observações: Os alunos B e D não compareceram. Nesta aula os alunos
tinham de entregar a segunda fase do projecto. Antes do inicio da aula recebi de todos os grupos os respectivos ficheiros.

359

Nesta aula os alunos não solicitaram muito a minha ajuda. Passaram grande parte da aula a estudarem exemplos de como colocar o cão e o Boneco de neve a andar, embora já tivessem tentado anteriormente mas sem sucesso. Perguntei aos alunos se já tinham ido ler o documento sobre o LSL em português, disseram-me que sim, e que agora percebem melhor como certas funções funcionam. Os alunos C e J conseguiram colocar o Boneco de Neve a deslocar-se, contudo ficou a faltar-lhes o parar. Os seus colegas passaram a aula a testar exemplos mas não conseguiram implementar a funcionalidade pedida. Estive a observar o código deles e verifiquei que lhes faltava obterem a posição do dono, para poderem colocar o cão a segui-lo. Estive a explicar-lhes o que tinham de fazer, ficou para trabalho de casa. Os alunos R e M que estão mais adiantados pediram-me que lhes explicasse como funcionam os sensores pois andaram a ver alguns exemplos e não perceberam. Depois da aula terminar mantive-me no SL com este grupo de alunos durante a qual estive a explicarlhes o funcionamento dos sensores deixe-lhes um exemplo para eles testarem. Contudo, tive de escrever comentários nas partes mais importantes porque não estavam a compreender como estes funcionam.

Notas: Estes alunos gostam de procurar soluções testarem e alterarem-nas, penas que
algumas vezes o façam por tentativa erro e não pensem no que realmente estas funções fazem. Tenho de insistir mais com eles para tentarem compreender o que o código faz.

Aula 10

Dia: 12/12/2007 Objectivos: Sensores

Registo das observações: Chamei a atenção dos alunos que na próxima aula deviam
entregar a 3 fase do projecto. No inicio da aula os alunos C e J informaram-me que o boneco deles já segue o dono. Contudo, tem um defeito anda colado ao dono. Estive a analisar o código deles e reparei que tinham um erro na função llvecDist, faltava-lhes definir um valor máximo e outro

360

mínimo que este deve estar afastado do dono. Enquanto revia o código deste grupo recebi várias solicitações dos outros alunos, que não consegui dar resposta em tempo útil. Ao verificar que outros alunos tinham o mesmo problema, uma vez que os objectos caminhavam quase colados ao dono, fiz uma chamada de atenção geral para explicar o que deviam fazer. Os alunos R e M disseram que já tinham visto um exemplo assim mas não perceberam o que este fazia. Assim pedi para ver esse exemplo e estive a comentar no código algumas das funcionalidades deste. Os alunos disseram-me que agora já perceberam e que o cão deles já funciona. Na segunda parte da aula estive a explicar aos alunos o funcionamento dos sensores, deilhes para experimentarem o exemplo que tinha dado aos colegas com alguns comentários inseridos. Estes alunos não apresentaram grandes dificuldades em compreender o seu funcionamento.

Notas: com a escrita de comentários no código os alunos compreendem melhor o que este
faz. Contudo, atrasa a resposta a dar aos colegas.

Aula 11

Dia: 19/12/2008 Objectivos: listas

Registo das observações: Verifiquei que todos os alunos me tinham entregue o programa
com as funcionalidades da 3 fase da avaliação. Nesta aula começamos a implementar a se segunda etapa do projecto. Foi com agrado que verifiquei que os alunos já tinham começado o seu desenvolvimento, unsjá tinham o balcão criado. Os alunos C e J perguntaram-me como podiam guardar a informação das vendas efectuadas, disse-lhes que seria em listas. Assim fiz uma chamada de atenção geral e estive a explicar o funcionamento das listas, tendo lhes dado um exemplo com comentários para eles testarem e alterarem. O aluno R referiu: “ assim com comentários é melhor..”

361

Estivemos a conversar pelo canal público sobre como a implementar a loja virtual. Todos os alunos perceberam como podiam implementá-lo, através da troca de mensagens entre o balcão e cada um dos objectos vendidos. Os alunos estiveram na segunda parte da aula a desenvolverem a troca de mensagens entre o cão e o balcão. Observou-se alguns erros de compilação no manuseamento das listas. O aluno D estava com dificuldades em conseguir obter o tamanho da lista de forma a poder mostrar todos os elementos que esta continha. Ao observar o código reparei que tinha a função llList2String a ser chamada sem o contador do ciclo for. O erro não estava onde o aluno referiu mas sim no ciclo. Escrevi um comentário no código, desta forma o aluno corrigiu o erro. Ficou para trabalho de férias acabarem de fazer as funcionalidades do balcão.

Notas: Observei que estes alunos conseguiram compreender o que tinham de fazer com
relativa facilidade.

Aula 12

Dia: 9/01/2008 Objectivos: comunicação para o email

Registo das observações: Durante as férias foi frequente encontrar alunos online que
solicitaram a minha ajuda na realização do trabalho. Grande parte do trabalho estava completo. Os alunos R e M estavam mais atrasados no desenvolvimento do projecto. Assim passei grande parte da aula dedicada a ajudar estes alunos. Este grupo estava com algumas dificuldades em enviar a informação para o email do dono. Disse-lhes para irem procurar uma função que lhes permitia enviar a informação para o email. Passado algum tempo disseram que não estavam a encontrar, assim tive de lhes dizer qual era. Os restantes colegas estavam a completar algumas funcionalidades, sem grandes dificuldades. O aluno M referiu:” afinal isto foi mais fácil do que parecia ao princípio.” Os alunos R e M estavam com dificuldades em contabilizar a quantidade de cães vendidos. Assim, tive de lhes sugerir que uma solução seria que cada cão ao ser comprado enviava uma mensagem ao balcão da sua venda e este aumentava o contador.

362

Perguntei aos alunos se tinham todas as funcionalidades implementadas disseram-me que sim. Os alunos C e J pediram-me para eu verificar. No fim da aula, voltei a conferir com os alunos R e M o que lhes faltava, tendo verificado que já tinham todas as funcionalidades implementadas.

Aula 13

Dia: 16/01/2008

Registo das observações: Esta é a última aula do semestre, os alunos têm de entregar o
trabalho no próximo dia 18. Os alunos C e J pediram-me se eu não me importava que eles saíssem para poderem terminar de fazer o relatório uma vez que já tinham todas as funcionalidades implementadas. Os restantes colegas andaram a embelezar alguns dos objectos como o balcão. Nesta aula limitei-me a observar os alunos a trabalharem pois pouco ou nada fizeram em relação ao código.

Primeiro encontro mensal Data: 22/10/2007 Neste encontro estiveram presentes todos os alunos. Estivemos a conversar sobre o projecto e a forma como têm decorrido as aulas. O aluno R referiu algumas dificuldades, nomeadamente: “não conseguimos compreender como criar uma cópia, nem como fazer o zoom” Os restantes colegas foram unânimes ao afirmar que sentem algumas dificuldades em compreender como se usa o editor, talvez fosse melhor explicar presencialmente e não online.

363

Segundo encontro mensal Data: 28 / 11/2007 Nesta reunião faltou o aluno R. Estivemos a trocar impressões sobre o projecto, aproveitei para esclarecer algumas dúvidas. Alguns alunos mencionaram o seu agrado por esta forma de ensino. O aluno M referiu: -“(...) estive a falar com um americano sobre o meu trabalho e disse-lhe que tinha aulas de programação no SL. Ele achou o máximo e disse-me que andava no SL só por brincadeira, mas que gostava de saber criar coisas.” O aluno C disse: -“Gostei muito, principalmente de poder olhar para o meu cão e ver como este se comportava. Nos outros ambientes de programação é mais difícil de detectar os erros de execução... aqui basta olhar.” O aluno D: -“(...) um dos problemas que eu tinha em fazer trabalho de grupo era ter tempo para estar com o meu colega, como trabalho em part-time era difícil. Assim, à noite encontramo-nos no SL, cada um em sua casa, e trabalhamos no projecto durante a noite.”

Terceiro encontro mensal Data: 14/01/2008 Neste encontro compareceram todos os alunos, tendo servido para fazer um balanço geral das aulas. Os alunos gostaram de aprender a programar no SL como se depreende dos seus comentários. Aluno B: -“gostei de aprender a programar no SL, e não percebo porque razão não se usa este ambiente nas outras aulas de programação”. Alunos D: -“diverti-me imenso, principalmente porque o meu cão passava a vida a dizer que tinha fome, mesmo quando tinha acabado de comer” Aluno M: -“O projecto ficou mais complicado mas consegui implementá-lo na totalidade...”

364

Aluno R: - “(...) na sala de aula ao ouvirmos a explicação sobre o erro fica-nos algo na cabeça do que foi dito, mas voltamos a cometer o mesmo na aula seguinte ou na mesma aula porque já não nos conseguimos lembrar do porquê; agora quando está escrito no local do erro, lemos e quando ocorre, voltamos a ler e assim conseguimos nos lembrar e resolver o problema quando acontece”.

365

Relatório das aulas de Laboratório Informático II Primeiro e segundo ciclos de Investigação-acção

Realizadas entre Outubro de 2007 e Janeiro de 2008

366

Aula 1:

Dia: 8/10/2007 (segunda-feira)

Objectivos: Apresentação do projecto Registo das observações: apresentação do mundo virtual SL e do projecto aos alunos de
Lab. II, pelo professor da UTAD. Nesta turma voluntariaram-se 10 alunos que formaram grupos de dois alunos da seguinte forma: aluno F e T; aluno M e J; aluno C e S; aluno A e B; aluno R e V;

Aula 2

Dia: 22/10/2007 Objectivos: Introdução ao SL, apresentação do editor, construção de objectos

Registo das observações: Os alunos entraram online, estive a mostra-lhes o espaço da
sala, as zonas de trabalho de cada grupo, a zona de exposições onde já se encontrava alguns dos trabalhos dos seus colegas. Expliquei-lhes o modo de comunicação existente, canal público e privado. Referi que iríamos usar o canal público só para explicar ou demonstrar algo para todos os alunos e o canal privado para tirar dúvidas individuais, sendo este o principal meio de comunicação entre mim e cada um deles. Mostrei-lhes o objecto de dúvidas e como podiam colocar lá um cartão. Cada aluno, escreveu num cartão o seu nome, o número de aluno, o nome do colega de grupo e o nome do seu avatar. Expus-lhes o objectivo da aula e pedi para não trabalharem em grupo hoje. Assim, passei a explicar como funciona o editor do SL e como se constroem objectos. Pedi-lhes que construíssem um banco e que lhe dessem uma textura de madeira de carvalho, embora o trabalho deles pouco tem de construção. Mostrei-lhes o meu banco e pedi para criarem um parecido com o meu. Observou-se algumas dificuldades em conseguirem colocar texturas no banco, e como sucedeu com os seus colegas anteriores não foram capazes de criarem réplicas das patas nem juntar os vários objectos num só.

367

No fim da aula só 4 alunos não tinham completado o banco, tendo este ficado para trabalho de casa. Relembrei que embora estivessem a fazer o projecto no SL tinham de cumprir as mesmas regras de avaliação dos restantes colegas, por isso na próxima aula tinham de me enviar por email o algoritmo do trabalho. Seguindo as regras impostas pelo professor da disciplina na UTAD.

Notas: Dificuldades em compreenderem o funcionamento do editor.

Aula 3

Dia: 29/10/2007 Objectivos: Introdução à linguagem LSL, revisão dos conceitos básicos de programação.

Registo das observações: Confirmei com os alunos se estes tinham submetido no SIDE
o algoritmo do trabalho. Após a aula fui retirar o algoritmo de cada grupo do SIDE. Expus os objectivos desta aula, tendo iniciado por explicar como funciona a linguagem LSL e as suas características. Esta explicação foi sendo acompanhada por um exemplo que lhes dei para cada um deles experimentar. Os alunos receberam o script e inseriram-no num objecto para o poderem testar. Sugeri que alterassem a mensagem que este continha para que surgisse por cima do objecto o nome de cada aluno. Alguns alunos sentiram dificuldades em conseguirem alterar a mensagem, como foi o caso do aluno R e C. Tive de lhes explicar novamente como fazer esta alteração. A seguir, fiz uma revisão geral dos conceitos base de programação, como a noção de variável, tipos de dados base em C e o seu correspondente em LSL, as estruturas de controlo e dei-lhes um exemplo para testarem. O aluno A referiu: -“Eu sei a linguagem C, e não tenho dificuldades em C, eu tive uma boa nota o ano passado.” Assim, fiz uma chama de atenção geral e perguntei se alguém não compreendeu ou teve dificuldades em se lembrar dos conceitos básicos. Dissera-me que não, pelo que sugeri que passasse-mos então a analisar o projecto e a implementá-lo. A primeira fase que os alunos tinham de entregar consistia na troca de informação entre a caixa de gestão de vendas e os produtos.

368

Estivemos a conversar sobre o projecto e a forma de este ser implementado no SL, sugeri que criassem uma caixa e escrevessem por cima “caixa de gestão” e outra “Aspirinas”. A seguir deviam ir implementar um pequeno script para a caixa de aspirinas que envia-se uma mensagem à caixa de gestão. Estive a explicar para todos os alunos como se processa a comunicação entre objectos no SL e dei-lhes um pequeno exemplo para verem, testarem e adaptarem para o projecto. Na generalidade os alunos compreenderam o funcionamento deste exemplo, a seguir disse-lhes agora alterem-no para o vosso trabalho. O aluno B solicitou ajuda pois não percebeu o que tinha de fazer. Assim, pedi que lesse o enunciado do trabalho principalmente a parte que fala da caixa de gestão. A mesma dificuldade foi sentida por outros alunos. Desta forma fiz uma chamada de atenção geral e pedi que fossem ler o enunciado do trabalho principalmente o que diz respeito à caixa de gestão. Após confirmar que tinham lido perdi que me dissessem o que a caixa de aspirinas devia enviar à caixa de gestão. Por surpresa minha nem todos foram capazes de me responder, pelo que tive de lhes explicar o que se pretendia e o que tinham de fazer. Desta forma os alunos deram início à implementação do projecto. O aluno J pediu que visse o código dele porque tinha um erro, pedi que partilha-se comigo o código, mas este já não se lembrava como isto se faz. Assim tive de lhe explicar como fazer. Ao observar o código reparei que tinha vários erros de sintaxe, andou a retirar ; e } em alguma partes do código que lhe tinha dado. Expliquei-lhe o que estava errado e pedi que alterasse. O aluno B, pediu que o ajudasse pois não estava a conseguir fazer as alterações, este aluno referiu: -“eu não percebo nada disto, não sei se o programa está certo ou errado”( Estive a explicar-lhe, novamente, o que era pretendido no projecto e o que este devia fazer. Pedi que partilha-se o código comigo para eu poder ver o que estava a fazer. Este aluno também já não se lembrava de como isto se fazia. O aluno J, voltou a pedir ajuda pois não estava a conseguir emendar os erros, fui ver e este continuava na mesma. Assim tive de lhe dizer explicitamente o que faltava no código. Entretanto, recebi várias solicitações de outros alunos que ia tentando dar resposta enquanto observava o código do aluno J. Estive a ajudar o aluno B e J a fazer pretendido, os restantes alunos foram solicitando ajuda devido aos erros de compilação nomeadamente à falte de ;

369

No fim verifiquei que só o aluno J não foi capaz de fazer o que eu tinha pedido, tendo isto ficado para trabalho de casa. Pedi aos alunos que estudassem um pouco da linguagem LSL e que fossem praticando com pequenos exemplos.

Notas: Observei algumas lacunas de programação nestes alunos, principalmente não conseguirem corrigir erros básicos. Notei dificuldade em conseguir dar resposta a todas as solicitações.

Aula 4

Dia: 5/11/2007 Objectivos: continuação do projecto, Eventos, funções e listas;

Registo das Observações: Comecei por relembrar aos alunos que tinham de entregar a
primeira fase do projecto na próxima aula. Perguntei se tinham estudado alguma coisa de LSL, disseram-me que não. O aluno J pediu que o ajudasse pois não estava a perceber nada disto. Assim estive a ajudar este aluno a conseguir colocar dois objectos a comunicarem entre si. Fiz uma chamada de atenção geral para lhes explicar como funcionam os eventos em LSL, dei-lhes um pequeno exemplo para eles testarem. O aluno F disse-me que o meu exemplo não estava a funcionar, pedi que partilhasse o código para eu poder ver. Observei que este aluno não esteve atento ao que tinha dito, pelo que tive de lhe explicar o que tinha de fazer. Mesmo assim este aluno não estava a conseguir perceber o que este código fazia, pelo que tive de lhe dar outro mais simples. O aluno F referiu: “ agora percebi…” A seguir estivemos a estudar como se podem criar funções no LSL, tendo lhes dado um exemplo para eles testarem. O aluno A pediu-me para analisar que o programa dele estava correcto. Estive a confirmar com todos os grupos o que tinham de entregar na próxima aula no SIDE. Na segunda parte da aula os alunos continuaram a desenvolver o projecto, a fase seguinte consiste na caixa de gestão actualizar o stock de medicamentos. Sugeri que guardassem

370

numa lista o stock de cada medicamento existente no armazém. Assim pedi-lhes que fossem ler no LS wiki sobre listas. O aluno B pediu para eu lhe explicar como funcionam as listas pois não estava a perceber nada. Assim expliquei-lhe e dei-lhe um exemplo para ele observar. Como disse-me que não percebia o que este fazia, tive de lhe dar um mais simples e explicar-lhe cada parte do código. Este aluno comentou: -“A linguagem C eu sei, aqui é que não percebo nada disto.” Recebi várias solicitações para lhes explicar como funcionam as listas pelo que achei melhor fazer uma chamada de atenção geral e explicar a todos como estas funcionam tendo lhes dado um exemplo, para testarem. Contudo, a alguns alunos tive de lhes dar outro mais simples e explicar como fiz com o aluno B. No fim da aula relembrei-lhes que tinham de submeter no SIDE a 1º fase do projecto. Notas: Muitas dificuldades na compreensão da linguagem, estes alunos têm pouca autonomia, não são capazes de avançarem sozinhos estão sempre à espera que eu os ajude. Nota-se uma repetição dos erros de compilação como a falta de ; e {.

Aula5

Dia: 12/11/2007 Objectivos: continuação do projecto, mudança de estados.

Registo das observações: Todos os alunos confirmaram que tinham entregue a primeira
fase do projecto. Perguntei se tinham avançado mais alguma coisa ou estudado as listas, disseram-me que não. Assim pedi-lhes que fossem estudar alguma das funções usadas nas listas. Alguns alunos referiram que tinham dificuldades no Inglês se não havia em português. Informei que no fim da aula deviam ter a actualização do stock feito. O aluno R pediu para eu o ajudar porque o programa dele estava com erros, ao observar verifiquei que estava a chamar as funções que tinha implementado com os parâmetros errados. Assim, pedi-lhe que me explica-se ou o colega, o aluno v, o que a função fazia e qual o objectivo dos parâmetros que tinham definido. Estes alunos disseram-me que a função recebia um número inteiro e uma string, mas não foram capazes de me dizer o que representa esses valores em relação ao projecto deles, ou seja o inteiro a quantidade vendida e a string o

371

nome do produto. Foi difícil para estes alunos compreenderem qual o objectivo da funçõe s, que eles criaram, e como a usar. O aluno J, está constantemente a solicitar ajuda, embora eu tente que ele e o colega o aluno M procurem resolver os problemas por eles, mas sem sucesso. O aluno J refere constantemente que percebe de C, mas no entanto não é capaz de resolver um simples erro como a falta de uma { num if. O aluno C e S pediram para eu ver se o programa deles fazia o que era pedido, pois este não tinha erros de compilação, mas não eram capazes de ver se estava correcta a sua execução. Este tipo de pedido começa a ser muito solicitado pelos alunos. Nesta aula pouco se avançou no projecto, os alunos não foram capazes de concluir o que eu tinha pedido. O aluno J pediu-me para ficar mais um pouco no SL, depois da aula, porque estava com muitas dúvidas nas listas. Assim, estive com este alunos mais os alunos M, F e T que entretanto apareceram online a trabalhar no projecto. As maiores dificuldades destes alunos foram em perceberem o que as funções predefinidas da linguagem fazem, corrigir os erros de compilação, nomeadamente faltas de ; e {. Não sabem usar funções desenvolvidas por eles, estes alunos são capazes de as criar as funções mas não sabem como usá-las e quando. Notas: Nota-se alguma frustração nos alunos e falta de empenho no seu desenvolvimento, estão sempre à espera da minha ajuda. Não são capazes de ver sequer se o programa está correcto ou não.

Aula 6

Dia: 19/11/2007 Objectivos: Ler informação de cartões, semelhante a ler dados em ficheiros.

Registo das observações: Perguntei os restantes colegas, os que não tinham estado
comigo depois da aula, se tinham estudado as listas ou avançado no projecto. Disseram-me que não. Expressei-lhes a minha preocupação em eles conseguirem entregar todas as funcionalidades para a segunda fase.

372

Expus o objectivo da aula de hoje, ler informação de cartões, e expliquei-lhes as semelhanças com o ler dados em ficheiros, que tinham aprendido em C. Pedi-lhes para irem ver as funções llGetNotecardLine, LLGetInventoryNumber, entre outras. O aluno R disse-me que não percebia nada do que estas funções faziam, se eu o podia ajudar, pois não sabia Inglês. Perguntei se o colega percebia, o aluno V, disse-me que não. Assim, pedi ao aluno V que observa-se o que eu ia explicar ao colega, deste modo estive a explicar-lhe o que cada uma delas fazia e dei-lhe um exemplo para ele testar. Perguntei-lhe se compreendeu o exemplo. Disseram-me que não, pelo que tive de lhes dar outro mais simples, e expliquei-lhes todos os passos do código. A mesma dificuldade sentiu os aluno A e B, a quem procedi de igual forma. O aluno J está constantemente a pedir ajuda, pediu-me para verificar se o programa dele estava a funcionar pois não tem erros de compilação. Perguntei-lhe se ele e o colega não conseguem ver se o programa funciona ou não, este respondeu:” isto é só texto a correr, eu não consigo ver se está certo ou não..” Voltei a insistir mas isto é semelhante aos programas que fazem em C. O aluno J responde “pois mas aqui eu não percebo nada, e não sou só eu os meus colegas também (...) só que eu como eles não vêm o que digo não me importo de dizer e peço ajuda” O aluno R estava a pedir ajuda a algum tempo, pelo que tive de lhe pedir desculpa de só agora conseguir falar com ele mas estava a falar com outro colega. O código deste aluno estava com erros de compilação ao analisá-lo observei que faltavam ; chavetas nos if, e por conseguinte tinham muitos erros de compilação. Assim comecei a escrever comentários no código antes de cada erro e pedi para eles verem o que tinha escrito. O aluno, conseguiu corrigir os vários erros sozinho.

Notas: nota-se que estes alunos têm muitas dificuldades na programação e este enunciado não os ajuda a conseguirem superá-las nem os motiva a trabalhar. Sinto alguma dificuldade em conseguir responder atempadamente às várias solicitações que recebo em simultâneo.

373

Aula 7

Dia: 26/11/2007 Objectivos: continuação Ler informação de cartões (início do 2º ciclo) Registo das observações: Comecei por relembrar que na próxima semana tinham de entregar a 2º fase do projecto. Os alunos A, B R e U disseram que não sabiam que era já na próxima semana, pelo que tive de lhes relembrar que o método de avaliação era igual para todos os alunos de Lab. II. Informei os alunos que tinha traduzido para português algumas das funções predefinidas da linguagem LSL mais utilizadas. Nesta aula compareceu o aluno 4 de Lab. III, a meu pedido, para ver se ajuda os colegas a sentirem-se um pouco mais motivados. Este aluno esteve a mostrar-lhes alguns dos objectivos que tinha feito e esteve a tirar dúvidas aos colegas. O aluno J referiu: “pois se este projecto também fosse assim, agora isto é só texto e mais nada…” Expus aos alunos as alterações que tinha feito no projecto nomeadamente que tinham de criar um boneco que recebia os pedidos e que devia mandar bolas de sabão para o ar sempre que um pedido era satisfeito. Mostrei-lhes a minha boneca e a funcionalidade que eles tinham de implementar. Os erros de compilação que foram surgindo, nomeadamente do aluno J, passei a escrever comentários no código para este ver e corrigir. O aluno referiu que assim é melhor. Nesta aula estive a ajudar os alunos a concluírem a leitura da informação dos cartões. No fim da aula verifiquei que os alunos A,B R e U não tinham todas as funcionalidades pedidas implementadas. Ofereci-me para os ajudar ao longo da semana.

Notas: A presença do colega ainda acentuou mais a frustração pelo trabalho que estes alunos estão a fazer.

374

Aula 8

Dia: 3/12/2007 Objectivos: Continuação do projecto.

Registo das observações: Os alunos A e B não compareceram. Perguntei se todos tinham
submetido no SIDE a segunda fase, disseram-me que sim. Embora os alunos R e U referiram que não fizeram todas as funcionalidades pedidas. Nesta aula os alunos estiveram a construir a boneca. Já não se lembravam de como se faz a réplica de objectos, nem como se usa o zoom. Assim fiz uma chamada de atenção geral para voltar a explicar como isto se faz. Os alunos J e M voltaram a pedir se eu podia ficar com eles no SL depois da aula para os ajudar no projecto. Assim estive com estes alunos no SL online a ajudá-los, notei que a escrita de comentários no código fez com que os pedidos de ajuda em relação aos erros de compilação diminuíram. O aluno J pediu-me para o ajudar no LSL pois queria concorrer a um estágio renumerado no SL. Notas: Notou-se que os alunos estavam mais descontraídos e satisfeitos por estarem a construir alguma coisa.

Aula 9

Dia: 10/12/2007 Objectivos: Continuação do projecto

Registo das observações: Os alunos A e B não compareceram. Perguntei aos colegas se
sabiam alguma coisa deste grupo, referiram-me que eles tinham desistido da disciplina. O aluno M referiu que também tinha vontade de fazer o mesmo, pois não percebia nada disto e já estava arrependido de se ter voluntariado para estas aulas. O aluno C pediu que eu visse o código deles pois não percebia a razão pela qual este não estava a funcionar. Ao analisar o código reparei que tinham as funções definidas mas não as estavam a chamar no programa. Este tipo de erros em alunos que já tiveram programação na qual tiveram aprovação e com boas notas é um pouco estranho. Escrevi

375

um comentário no código do aluno a explicar porque razão o programa não podia funcionar. Este percebeu e tentou corrigir a situação mais o colega o aluno S, mas tive de o ajudar a chamar as funções pois não conseguiram colocar os parâmetros de entrada correcto. Os alunos J e M estavam constantemente a pedir auxílio, não por erros de compilação mas por não saberem o que fazer a seguir. O mesmo sucedia com os alunos R e V que não sabiam o que tinham de fazer a seguir. Perguntei-lhes como é que tinham feito o algoritmo, disseram-me que o algoritmo foi fácil de fazer ali é que não percebem nada. Assim fiz uma chamada de atenção geral e estive a explicar o que tinham de entregar na 3 fase do projecto. Os alunos F e T disseram-me que já tinham essa parte implementada. O aluno 4 voltou a comparecer na aula e esteve a ajudar os colegas mais atrasados no desenvolvimento do projecto. Este aluno referiu que tem tentado motivar os colegas mas eles não estão a gostar do que estão a fazer.

No fim da aula referi que na próxima tinham de entregar a 3 fase do projecto. Notas: Observa-se que estes alunos estão cada vez mais desmotivados, a desistência dos colegas levou-os a pensarem a fazerem o mesmo. Nota-se muita falta de bases a programação que já deviam ter. A escrita de comentário no código ajudou a minimizar o pedido de auxílio nos erros de compilação mais frequentes. Não compreendo como é que estes alunos foram capazes de fazer o algoritmo e agora não sabem o que fazer no projecto.

Aula 10

Dia: 17/12/2007 Objectivos: continuação do projecto Registo das observações: Confirmei no SIDE que todos os alunos tinham entregue a 3 fase do projecto com excepção do grupo que tinha desistido. Contudo os alunos R, V M e J não implementaram todas as funcionalidades. Assim disse a estes alunos que deviam implementar as funcionalidades em falta e entregar na 4 fase. Referi também que falta apenas mais uma aula antes de entregarem o projecto.

376

O aluno J pediu-me se o podia ajudar nas férias para conseguir acabar o projecto pois estavam com muitas dificuldades. Nesta aula estive a ajudar os alunos R e U que estavam mais atrasados no desenvolvimento do projecto. Estes alunos apesar de não estarem constantemente a pedir auxílio não são capazes de procurarem soluções para o que estão a fazer. Tive de lhe dar alguns exemplos para eles testarem e compreenderem como se lê informação de um cartão. Contudo, os alunos não foram capazes de ver que era esse o código que tinham de aplicar no projecto deles. O aluno S perguntou para o canal público: “a professora está aí?” Tive de lhe pedir desculpa por não o ter atendido mas estava a ajudar um colega dele. Em relação à boneca os alunos nesta aula não estiveram a trabalhar nela, preferiram avançam na implementação do projecto. Notas: a componente visual introduzida no projecto não surtiu o efeito desejado. Os alunos continuam frustrados e desmotivados.

Aula 11

Dia: 7/01/2008 Objectivos: conclusão do projecto Observações: durante as férias ajudei os alunos J, M C e S no desenvolvimento do projecto no SL. Os alunos R e V não pediram ajuda nem compareceram nas horas que eu marquei com os colegas, apesar de lhes enviar um email a dizer que ia estar online. Os alunos não implementaram a funcionalidade da boneca enviar bolas de sabão para o ar quando concluía um pedido. A razão apontada por eles é que não tiveram tempo e também não acharam muita graça a essa funcionalidade. Nesta aula estiveram a completar o resto das funcionalidades que lhes faltava. Os alunos R e V mais atrasados no desenvolvimento deste não compareceram à aula.

377

Primeiro encontro mensal. Data: 25/10/2007 Primeiro encontro com os alunos no qual estiveram todos presentes. Aproveitei esta reunião para compreender as dificuldades em usar o editor, bem como para saber as razões que levaram os alunos a participar neste projecto. O aluno S referiu:“foi difícil de perceber como ligar os objectos entre si.” -“Eu não gosto de programar, mas gosto de jogar e como o SL é um mundo virtual e eu gosto deste tipo de ambientes, vim experimentar. Os meus colegas dizem que gostaram.”

Os restantes alunos confirmaram que também sentiram dificuldades em perceber o que eu dizia, no que diz respeito ao editor. Em relação ao projecto referiram que pensavam que iam fazer um projecto diferente como foi o caso dos seus colegas nos outros anos e que não compreendem o porquê de ser diferente com eles.

Segundo encontro mensal Data: 22/11/2007 Esta reunião serviu para esclarecer algumas dúvidas sobre o projecto. Em relação à comunicação utilizada nas aulas os alunos foram unânimes ao dizerem que gostaram pois podiam por as suas dúvidas sem que os colegas vissem. Como disse o aluno M: “Gostei, pois podia colocar as minhas dúvidas sem me preocupar com o que os meus colegas iam pensar.” Em relação ao projecto o aluno J mencionou: -“(...) Isto não tem nada de engraçado… é só texto, se soubesse que ia ser assim não tinha feito este trabalho.” Os colegas também são da mesma opinião.

378

Terceiro encontro mensal Data: 11/01/2008 Este encontro serviu para fazer um análise geral das aulas. Os alunos mostraram o seu desagrado por terem de aprender outra linguagem de programação que não lhes ia servir de nada no seu futuro profissional. Em relação aos comentários escritos no código o aluno C disse: - “(...) a professora a explicar pelo chat na altura percebe-se mas quando voltamos a cometer o mesmo erro já não nos lembramos o porquê e também não procuramos o que foi dito no chat porque já lá está muita coisa escrita e é difícil de localizar; assim escrito no código é mais rápido de iremos ver”. Os colegas também são da mesma opinião. Relativamente ao facto dos colegas terem desistido, os alunos voltaram a confirmar que também tiveram vontade de fazer o mesmo, o que os motivou a continuar foi o apoio que tiveram por parte da professora.

379

Relatório das aulas de Laboratório Informático I Terceiro e quarto ciclos de Investigação-acção

Realizadas entre Março e Junho de 2008

380

Aula 1:

Dia: 14/03/2008 Objectivos: Apresentação do projecto

Registo das observações: apresentação do mundo virtual SL e do projecto aos alunos
de Lab. I, pelo professor da UTAD. Nesta turma voluntariaram-se 9 alunos que formaram grupos de dois alunos da seguinte forma: aluno A e M; aluno R e C; aluno F e B; aluno D e I; aluno W. O aluno W fez o projecto sozinho, por opção dele uma vez que já conhecia o SL. Os alunos A,M,R,C e W fazem parte da turma da investigadora, os restante alunos (F, B, D e o I) ficaram na turma do professor Ricardo da ESTG cujas aulas são à terça-feira.

Aula 2

Dia: 28/03/2008 Objectivos: Introdução ao SL, apresentação do editor, construção de objectos Registo das observações: Esta aula decorreu na UTAD na qual estiveram presentes os 9 alunos que se voluntariaram, a meu pedido de forma a poder explicar o editor do SL. Os alunos estiveram a trabalhar individualmente, cada um no seu PC. Apesar do aluno W já conhecer o SL também esteve presente. Apresentei a sala de trabalho na qual cada grupo tem uma zona definida, mostrei-lhes a zona de exposições e apresentei-lhes o professor Ricardo que estava online de Leiria. Nesta aula os alunos estiveram a criar um banco, outros preferiram criar um carro. Deste modo tive a possibilidade de explicar e demonstrar como se faz o zoom, liga objectos, criam réplicas. Esta aula serviu também para apresentar o projecto e a metodologia de avaliação que consiste em 3 fases a primeira entrega do algoritmo na segunda parte do código implementado e na 3 o projecto completo. Na próxima semana os alunos vão estar nas respectivas turmas.

381

Aula 3

Dia: 4/04/2008 Objectivos: Construção dos objectos do projecto, Introdução ao LSL.

Registo de observações: Nesta aula os alunos estiveram a concluir a construção do
carro outros a iniciar a sua construção como foi o caso dos alunos R e C. Relembrei aos alunos que deviam entregar na próxima semana o algoritmo do projecto. No decorrer da aula os alunos apenas solicitaram a minha opinião em relação ao carro, como foi o caso do aluno A, que me perguntou se este estava grande demais. Expliquelhe que podia criar do tamanho que deseja-se e depois podia reduzir o seu tamanho no fim de o ter todo ligado. Na segunda parte da aula estive a explicar-lhes as características da linguagem LSL, informei-os que tinham um ficheiro no qual descrevia as características da linguagem e as funções mais utilizadas da linguagem. Referi que durante esta semana deviam ler esse ficheiro para podermos começar a programar o projecto. Assim estivemos a ver os tipos de dados, como se declaram, as estruturas de controlo. Dei alguns exemplos para os alunos testarem, mas não lhes pedi alterações. Estes exemplos tinham comentários no código sobre o que cada função faz. O aluno M referiu: “ assim com comentários percebe-se melhor o que este código faz” Nesta aula os alunos não criaram todos os objectos do projecto, apenas terminaram o carro, as restantes partes vão ser desenvolvidas ao longo do semestre.

O professor Ricardo comunicou-me que na aula dele os alunos não levantaram grandes dúvidas em relação à utilização do editor. Notas: Observou-se uma melhoria em relação à compreensão de como funciona o editor do SL.

382

Aula 4

Dia: 11/04/2008 Objectivos: Funções predefinidas da linguagem

Registo das observações: todos os alunos entregaram o algoritmo do projecto. Referi
que na próxima aula íamos conversar sobre as várias soluções apresentadas. Nesta aula começaram a desenvolver o projecto, colocar o carro a andar. Perguntei se tinham lido o ficheiro sobre LSL, o aluno R e C disseram-me que não. Assim disse-lhes para irem ler e só no fim é que poderia começar a trabalhar no projecto. Fiz uma chamada de atenção geral no qual informei os alunos para a importância de estudarem antes da aula as funcionalidades da linguagem, caso contrário iriam passar a aula a estudar o que deviam ter feito em casa. Os alunos A,M e W começaram a colocar o carro a andar. Assim estive-lhes a perguntar o que algumas funções predefinidas da linguagem fazem. O aluno M já não se lembrava, pelo que sugeri que tivessem aberto o ficheiro ou LSLwiki para verem. Estive-lhes a explicar o que são os eventos e como estes funcionam, tendo lhes dado um exemplo para eles testarem. O aluno W como já tinha conhecimentos de LSL, avançou um pouco mais rápido tendo pedido a minha ajuda para alguns erros de compilação. Ao observar o código dele verifiquei que lhe faltava alguns ; e tinha parâmetros errados em algumas funções. Assim, escrevi um comentário antes de cada erro. Recorri às frases que tinha preparado tendo-me ajudado a responder mais rapidamente. Tive o cuidado de verificar se o aluno tinha conseguido corrigir todos os erros ele disse-me que sim, os comentários ajudaramno a corrigi-los.

Na segunda parte da aula os alunos R e C disseram-me que já tinham lido o ficheiro, pelo que estiveram a desenvolver o projecto. Comecei por lhes perguntar como estavam a pensar colocar o carro a andar. O aluno R disse-me que através da utilização da função llSetPos, para mudar a posição. Estive a explicar-lhes o funcionamento dos eventos e dei-lhes um exemplo para testarem. O aluno C disse-me que não estava a perceber como os eventos funcionam, pelo que tive de lhe explicar novamente e alterar o exemplo para ficar mais simples. 383

Os alunos A e M o carro deles alterava a posição mas um passo de cada vez, sempre que era tocado por alguém. Estive a conversar com o aluno A e pedi ao aluno M que acompanha-se a nossa conversa, uma vez que ele está sentado ao lado do colega, Perguntei o que eles queriam fazer, disseram-me colocar o carro a andar uns metros seguidos, só para testar. Como já sabem alterar uma posição se querem repetir essa função várias vezes seguidas teriam de usar um ciclo. Assim estiveram a rever como os ciclos funcionam. Estes alunos primeiro usaram um ciclo while que não fazia sentido neste exemplo. Estive a explicar-lhes em que situações cada um dos ciclos se aplica. Estes alunos conseguiram colocar o carro a andar continuamente 10 passos. Os alunos R e C só conseguiram colocar o carro a deslocar-se um passo. Relembrei que na próxima aula íamos discutir o algoritmo do trabalho.

O professor Ricardo referiu-me que a aula dele correu bem os alunos D e I não tinham estudado nada de LSL, pelo que o estiveram a fazer durante a aula. Referiu também que desta forma ao obrigarmos os alunos na aula a fazer o que deviam ter estudado antes, eles vão ter mais cuidado e estudar antes. Em relação ao suporte dado aos alunos considera que as pequenas frases o auxiliaram a dar uma resposta rápida aos alunos.

Notas: Com a utilização das frases pré-escritas consigo ser mais rápida a escrever comentários e dar um feedback aos alunos.

Aula5

Dia: 18/04/2008 Objectivos: análise do algoritmo

Registo das observações: Nesta aula estiveram presentes os 9 alunos. O professor
Ricardo não esteve presente porque nesta hora tinham aulas. No espaço da aula no SL criei 10 cadeiras dispostas em círculo nas quais nos sentamos. Comecei por ler o enunciado do projecto e para cada funcionalidade perguntei qual a solução apresentada por cada um dos grupos. A que suscitou mais dúvidas foi a pista poder alterada. Os

384

alunos não perceberam que se eu altera-se a forma da pista o carro teria de ser capaz de a seguir. O algoritmo que todos eles apresentaram o carro seguia uma trajectória predefinida. Assim perguntei-lhes o que acontecia se eu alterar a forma da pista? Eles responderam quase em simultâneo “ o carro continuava a circular”. Tive de lhes chamar a atenção que nesse caso o carro andava mas não por cima da pista. O aluno D, disse que não estava a perceber o que eu queria dizer. Assim, disse-lhes supondo que a pista era quadrada, o carro segue um percurso quadrado, certo. Se eu parar o carro e alterar a forma da pista para oval o que acontece se eu colocar o carro nessa pista. O aluno D respondeu: “continua a andar na forma quadrada….” O que eu confirmei; “ exactamente mas não é esse o objectivo do enunciado, se eu alterar a forma da pista o carro tem de seguir o percurso da nova pista…” O aluno W comentou: “ estou a perceber… então o meu algoritmo está errado”. Os colegas também concluíram o mesmo que parte do algoritmo deles tinha erros. O mesmo sucedeu com os semáforos e com as coimas, as soluções apresentadas não tinham em consideração todas as vertentes do problema. Ao longo da discussão foram sugerindo várias soluções para os mesmos problemas, o aluno A referiu se não existia só uma solução, por exemplo, para a funcionalidade da gasolina. Assim, chamei-lhes a atenção que existe diversas formas de fazer a mesma coisa, não é obrigatório fazerem todos da mesma forma é claro que umas soluções são mais eficientes que outras. No fim desta discussão em grupo, os alunos manifestaram o seu agrado por poderem discutir as várias soluções e verem o que estava errado em cada uma delas. O aluno w comentou:”Isto devia ser feito noutras disciplinas, porque muitas vezes só sabemos o que está errado no fim de termos o projecto todo desenvolvido” Os alunos ficaram de pensar e apresentar novas soluções para os problemas detectados no seu algoritmo.

Notas: Nesta reunião de grupo, senti a falta de um quadro no qual poderia estar sempre presente as várias soluções apresentadas para cada um dos problemas.

385

Aula 6

Dia: 9/05/2008 Objectivos: continuação do projecto, sensores

Registo das observações: No inicio da aula o aluno A disse-me que já tinha pensado
numa solução para a pista : “ o carro devia ter um sensor que via onde estava o próximo bloco..”. Dei os parabéns ao aluno pela solução apresentada. Perguntei-lhe se tinha estudado como se implementam os sensores disse-me que tinha visto apenas o que estava no meu documento sobre LSL. Assim estive a explicar-lhe como estes funcionam e dei-lhe um exemplo para ele testar e tentar adaptar ao projecto. Perguntei aos colegas se já tinham pensado numa solução, disseram-me que ainda não, que para já o carro ia funcionar assim, caminho pré-definido, estavam a ver como ele ia dar as curvas, os carro por enquanto não curvavam. Assim, estive a ver como estes alunos estavam a implementar as curvas. Notei que os alunos R e C já tinham estudado as funções do LSL e estavam a usar a função correcta llSetRot, mas não estava a funcionar correctamente. O aluno R pediu para eu os ajudar “pois o carro estava um pouco teimoso em vez de curvar para a direita ia para a esquerda”. O aluno w nesta aula pediu pouca ajuda diz que estava a ver se coloca o carro a andar correctamente num percurso pré definido. Tentei que estes alunos se preocupassem em colocar o carro a andar correctamente mas eles preferiram fazer primeiro assim. No fim da aula escrevi num objecto que os alunos deviam estudar os sensores, para a próxima aula. O professor Ricardo referiu que na turma dele os alunos estiveram a aprender como funciona os sensores. Nesta aula alguns alunos cometeram vários erros de compilação que ele comentou no código. Referiu que os alunos D e I estão muito entusiasmados com a construção da pista e teme que se atrasem no desenvolvimento do programa, já chamou a atenção deles para se dedicarem mais ao projecto. Notas: Observa-se que os alunos estão mais conscientes do que têm de fazer no projecto.

386

Aula 7

Dia: 16/05/2008 Objectivos: sensores, continuação

Registo das observações: Comecei por relembrar que na próxima aula deviam
entregar a primeira parte do projecto. Escrevi num objecto a data de entrega da primeira fase. Os alunos R e C estiveram a mostrar-me o carro deles, este já consegue seguir um percurso pré-definido com curvas. Agora iam tentar alterar para que o carro detecte os blocos da pista. Referiram que estiveram a conversar com os colegas e que estes lhe disseram que estavam a usar sensores. Assim, pediram-me que lhes explique como funcionam os sensores pois tinham estado a estudar, mas não compreenderam muito bem. Assim estive-lhes a explicar como estes funcionam tendo lhes dado um exemplo com o código comentado para eles testarem. O aluno A também pediu o ajuda, enviei-lhe uma mensagem “já falo contigo, estou a esclarecer dúvidas ao teu colega”. Assim, que terminei estive a ver o código deste aluno pois o carro só detecta as placas que estão à frente as curvas não. O aluno W, pediu que o ajudasse com os sensores, assim dei-lhe também o exemplo para ele testar. A maior dificuldade sentida pelos alunos consiste em alterarem o raio de acção do sensor de forma que este detecte os blocos. A maioria dos alunos está a fazer esta alteração por tentativa erro. No fim da aula só os alunos R e C não tinham conseguido colocar o sensor a funcionar correctamente. Na aula do professor Ricardo também observou as mesmas dificuldades. Notas: Observa-se uma diminuição dos erros de compilação, surgem mais erros de execução. Nota-se que os alunos estão empenhados no desenvolvimento do projecto.

387

Aula 8

Dia: 23/05/2008 Objectivos: continuação do projecto, cruzamentos na pista, temporizadores…

Registo das observações: Conferi no SIDE que todos os alunos desta turma tinham
entregue a primeira fase do projecto (colocar o carro a andar, independentemente da posição da pista). Como os alunos já todos tinham o carro a circular, fiz uma chamada de atenção geral e perguntei-lhes o que sucedia se a pista tiver cruzamento, responderam-me que o mais certo era o carro seguir em frente. Sugeri que deviam implementar os semáforos. Assim estiveram a dedicar-se à sua construção. Coloquei na zona de exposição um semáforo a funcional para eles verem como podiam construir um. Contudo este exemplo não tinha o código acessível. Na segunda parte da aula os alunos dedicaram-se a programar o funcionamento do semáforo. Assim estivemos a trocar ideias em conjunto sobre como este devia ser desenvolvido. O aluno W sugeriu que este devia funcionar com um ciclo for e que ao fim de 5 voltas dia trocar de cor. Perguntei se os outros concordavam, disseram que era uma boa ideia então sugeri que o implementassem para verem se funcionava. Os alunos R e C foram os primeiros a concluir o desenvolvimento desta funcionalidade e chamaram os colegas e disseram isto é demasiado rápido, tem de haver outra forma. Eu perguntei-lhes como funcionam os semáforos que se encontram nas estradas. O aluno A referiu troca de sinal ao fim de alguns minutos. Perguntei-lhes porque não fazem o mesmo. Assim, foram procurar funções que controlem o tempo. Tendo ficado para trabalho de casa estudar o funcionamento dos temporizadores.

Na outra turma o professor Ricardo referiu que os alunos estiveram a desenvolver o sistema da gasolina. Os alunos sugerirem várias soluções e cada grupo estava a implementar uma diferente.

388

Notas: Os alunos ao testarem as suas ideias, ajuda-os a verificar os erros que estas contêm. As frases pré-definidas ajudam a minimizar o tempo de escrita dos comentários.

Aula 9

Dia: 30/05/2008 Objectivos: temporizadores… Registo das observações: O aluno R faltou a esta aula. Os alunos continuaram com o desenvolvimento dos semáforos. O aluno C pediu para lhe explicar como funciona o evento Timer. O mesmo pedido fez o aluno M. Assim fiz uma chamada de atenção geral e estive a explicar-lhes como estes funcionam, tendo lhes dado um exemplo para eles testarem. Os alunos estiveram a testar o funcionamento dos semáforos, houve algumas dificuldades em controlar a passagem do verde a amarelo. O aluno W, esqueceu-se que o semáforo está menos tempo no amarelo do que no vermelho, ou seja o semáforo deste aluno tinha igual tempo de vermelho, amarelo e verde. Foi o colega C que chamou atenção para o mal funcionamento deste. Na segunda parte da aula estivemos a conversar em grupo, como os carros deviam saber que tinham de para no vermelho. Relembrei-lhes algumas das sugestões que tinham proposto anteriormente. Assim ficaram de implementar uma das soluções apresentadas para a próxima aula. O aluno W referiu que -“(...) foi bastante importante estarmos a discutir o projecto em conjunto pois podemos esclarecer as nossas dúvidas.” Os alunos A e M pediram para ficar mais um pouco no SL para os ajudar no projecto. O aluno F e B também compareceram. Assim estive mais de 3 h com estes alunos depois da aula terminar a ajudá-los no desenvolvimento do trabalho.

O professor Ricardo comentou que os alunos D e I estavam um pouco atrasados no desenvolvimento do projecto.

389

Notas: A discussão em grupo ajuda ao alunos a verem os seus erros e a pensarem em novas soluções.

Aula 10

Dia: 13/06/2008 Objectivos: Continuação do projecto.

Registo de observações: Relembrei aos alunos que só tínhamos mais uma aula antes
da entrega do trabalho. Nesta aula, estiveram a desenvolver o sistema de gasolina. O aluno W disse-me que já tinha o seu projecto a funcionar, mas queria que o dono visse o nível de gasolina que o carro tinha. Assim, sugeri que adicionasse um cilindro que ia diminuindo à medida que a gasolina ia sendo gasta. O aluno esteve a tentar desenvolver esta funcionalidade. Contudo, disse-me que não estava a conseguir e ia fazer de outra forma, ou seja, escrever por cima do carro, em percentagem, a quantidade de gasolina que este ainda tinha. Os restantes colegas centraram-se apenas no desenvolvimento do código e não na parte visual, tendo esta ficado para trabalho de casa.

Os alunos da outra turma já tinham esta funcionalidade implementada. O professor Ricardo comunicou-me que a aula tinha decorrido bem. Contudo, os alunos D e I estavam mais atrasados. Nota: Os alunos já não pedem ajuda devido aos erros de compilação.

Aula 11

Dia: 20/06/2008 Objectivos: Conclusão do projecto.

Registo das observações: Última aula do semestre. Nesta aula, os alunos estiveram a
acabar o desenvolvimento do projecto. Os alunos A e M estão um pouco atrasados, pois

390

ainda lhes falta implementar a parte visual da gasolina e o sistema de coimas. Os restantes colegas estiveram a desenvolver o sistema de coimas. O aluno W estava mais adiantado no desenvolvimento do projecto. Estive a conversar com ele sobre a aprendizagem no SL. Este aluno referiu que gostou do facto de eu ter comentado por escrito a razão dos erros: “quando tinha um erro eu ia ver o que a professora me tinha escrito e assim consegui corrigir alguns (...)” Esta aula decorreu normalmente sem grandes pedidos de ajuda, uma vez que cada grupo estava concentrado em terminar o projecto. O professor Ricardo referiu que os alunos D e I não completaram todas as funcionalidades durante as aulas, mas esperava que ainda o conseguissem fazer.

Primeiro encontro mensal Datas:17/04/2008 Nesta reunião estiveram presentes os 9 alunos. Estivemos a conversar e a trocar opiniões sobre o projecto. Em relação às aulas, os alunos referiram que estavam a gostar de aprender a programar no SL.

Segundo encontro mensal Datas: 23/05/2008 Nesta reunião estivemos a conversar sobre o projecto, e sobre algumas das soluções apresentadas na discussão em grupo. O aluno A disse: -“(...) esta discussão ajudou-me a compreender o que eu tinha de errado no meu algoritmo e alguns aspectos que não tinha considerado...” O aluno B referiu: -“(...) foi a primeira vez que participei numa discussão assim, ajudou-me a compreender o que tinha de fazer e estudar...noutras disciplina devia-se fazer o mesmo”

391

Terceiro encontro mensal Datas: 27/06/2008 Este encontro serviu para fazermos uma avaliação geral de como decorreram as aulas. Os alunos foram unânimes em referir que gostaram desta metodologia e que devia ser usada noutras disciplinas. O aluno S comentou: -“(...) sempre que me surgia um erro de compilação, eu ia ver o que a professora me tinha escrito e conseguia corrigi-lo, assim foi mas fácil”.

392

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times