uso do second life no suporte à aprendizagem contextualizada de programação

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.

ii

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.

iv

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ção-

acçã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 integrando-

os 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.

vi

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.

viii

Índice 1. Introdução ............................................................................................................................ 2

1.1. Fundamentos da escolha do tema ........................................................................... 4

1.1. Abordagem ao problema .......................................................................................... 5

1.2. Objectivos e contributos fundamentais .................................................................. 7

1.3. Estrutura da tese ........................................................................................................ 8

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

2.1. Teorias de aprendizagem ........................................................................................ 12

2.1.1. Behaviorismo ..................................................................................................... 12

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. Metodologias de aprendizagem ............................................................................. 21

2.2.1. Aprendizagem baseada em problemas ........................................................... 22

2.2.1.1. A implementação da PBL ........................................................................ 23 2.2.1.2. O papel do professor e dos alunos na PBL .......................................... 25

3. Ensino da Programação .................................................................................................... 26

3.1. Programar, o que è? ................................................................................................. 28

3.2. Dificuldades na aprendizagem da programação .................................................. 29

3.3. Soluções propostas na literatura para o ensino da programação ...................... 39

3.3.1. Programação modular ...................................................................................... 40

3.3.2. Abordagem gramatical ..................................................................................... 41

3.3.3. Abordagem em espiral...................................................................................... 41

3.3.4. Protocolo “pensar em voz alta” ...................................................................... 42

3.3.5. Programação de jogos ...................................................................................... 42

3.3.6. Programar do concreto para o abstracto ....................................................... 43

3.3.7. Padrões de programação .................................................................................. 43

3.3.8. Programação aos pares ..................................................................................... 44

3.3.9. Programação por exemplos ............................................................................. 46

3.3.10. Abordagem “bricolage” ................................................................................... 46

3.3.11. Sistemas de suporte ao ensino da programação ........................................... 47

ix

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

3.4.1. 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. Caracterização dos mundos virtuais ..................................................................... 70

4.1.1 Representação física ......................................................................................... 71

4.1.2 Interactividade ................................................................................................... 73

4.1.3 Persistência ........................................................................................................ 77

4.2. Os antecessores dos mundos virtuais ................................................................... 78

4.3. Categorização dos mundos virtuais ...................................................................... 82

4.3.1 Mundos virtuais de competição ...................................................................... 84

4.3.2 Mundos virtuais sociais .................................................................................... 85

4.3.4 Mundos virtuais de formação ......................................................................... 92

4.3.5 Plataformas de desenvolvimento ................................................................... 92

4.3.6 Mundos virtuais profissionais ......................................................................... 95

4.4. Mundo virtual adoptado ......................................................................................... 96

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

5.1. Introdução ao Second Life ................................................................................... 100

5.2. Avatares no SL ....................................................................................................... 102

5.3. Comunicação .......................................................................................................... 105

5.4. Construção de objectos 3D ................................................................................. 109

5.5. Programar no Second Life ................................................................................... 117

5.5.1 Como se desenvolve um programa no SL .................................................. 117

5.5.2 A linguagem de programação LSL ............................................................... 119

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

6.1. Opções metodológicas.......................................................................................... 126

6.2. O que é a investigação-acção? ............................................................................. 128

x

6.2.1 Estrutura metodológica da investigação-acção ........................................... 129

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

7.1. Sumário ................................................................................................................... 136

7.2. Participantes............................................................................................................ 138

7.3. Recolha da informação ......................................................................................... 140

7.3.1. Relatórios diários ............................................................................................. 140

7.3.2. Registos electrónicos ...................................................................................... 141

7.3.3. Questionários ................................................................................................... 141

7.3.4. Entrevistas ........................................................................................................ 142

7.4. Análise da informação ........................................................................................... 143

7.5. Preparação da intervenção preliminar ................................................................ 144

7.5.1. Caracterização dos alunos .............................................................................. 145

7.5.2. Projectos propostos ........................................................................................ 146

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. Metodologia a usar nas aulas ......................................................................... 150

7.5.5. Plano da aula .................................................................................................... 152

7.6. Resultados e reflexões da fase preliminar ........................................................... 152

7.6.1. Início da programação – Lab. I ..................................................................... 154

7.6.2. Aulas de Lab. III ............................................................................................. 157

7.6.3. Professora......................................................................................................... 158

7.6.4. Questionários ................................................................................................... 160

7.7. Plano do 1.º ciclo de investigação-acção ............................................................ 162

7.7.1. Caracterização dos alunos .............................................................................. 162

7.7.2. Planeamento das aulas .................................................................................... 163

7.8. Resultados e reflexão do 1.º ciclo ........................................................................ 167

7.8.1. Programação alunos de Lab. II ..................................................................... 168

7.8.2. Alunos de Proj. I ............................................................................................. 171


7.10. Resultados e reflexões do 2.º ciclo ...................................................................... 173

7.10.1. Professora......................................................................................................... 176

7.10.2. Questionários ................................................................................................... 178


7.12. Resultados e reflexões do 3.º e 4.º ciclos de investigação-acção ..................... 183

xi

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

7.13. Conclusão do projecto de investigação .............................................................. 189

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

8.1. Análise e discussão dos resultados ...................................................................... 192

8.1.1. Comunicação ................................................................................................... 192

8.1.2. Projecto ............................................................................................................ 195

8.1.3. Processo de aprendizagem ............................................................................ 198

8.1.3.1. Dificuldades dos alunos......................................................................... 198

8.1.3.2. Motivação dos alunos em participar neste projecto .......................... 204

8.1.3.3. Avaliação feita pelos alunos ao SL ....................................................... 205

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

9. Proposta de um modelo para o ensino da programação de computadores em

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

9.1. Proposta de um modelo ....................................................................................... 214

9.2. Linhas orientadoras para o ensino da programação utilizando o SL ............. 214

9.2.1. Suporte técnico e emotivo ............................................................................. 215

9.2.2. Contexto lúdico para a programação ........................................................... 219

9.2.3. A importância dos exemplos ........................................................................ 223

9.2.4. Comunidade que enfatiza a aprendizagem.................................................. 224

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

10.1. Conclusões.............................................................................................................. 232

10.2. Considerações finais e propostas de trabalho futuro ....................................... 234

11. Referências Bibliográficas ......................................................................................... 236

12. Anexos I ...................................................................................................................... 274

13. Anexos II ..................................................................................................................... 278

14. Anexos III ................................................................................................................... 292

15. Anexos IV ................................................................................................................... 316

16. Anexos V ..................................................................................................................... 320

xii

Í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

xiii

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

xiv

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

xv

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

xvi

Í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

xviii

Acrónimos

ACM Association for Computer Machinery

ANIMAL A New Interactive Modeller for Animations in Lectures

AWEU Active Worlds Educational Universe

BALSA Brown ALgorithm Simulator and Animator

BASIC Beginners All-purpose Symbolic Instruction Code

CAT Collaborative Active Textbook

CET Curso Técnico Pós-secundário

COBOL COmmon Business Oriented Language

ENIAC Electrical Numerical Integrator and Calculator

ESTG Escola Superior de Tecnologia e Gestão

Fortran IBM mathematical FOrmula TRANslation system

IA Investigação-Acção

IDE Integrated Development Environment

IDSV Interactive Data Structure Visualization

JHAVÉ Java-Hosted Algorithm Visualization Environment

Lab I Laboratório de informática I

Lab II Laboratório de informática II

Lab III Laboratório de informática III

LSL Linden Scripting Language

MMOG Massively Multiplayer Online Games

MMORPG Massively Multiplayer Online Role Player Game

MUD Multi User Dungeon

MV3D Mundo Virtual tridimensional

OLIVE On-Line Interactive Virtual Environment

PBL Problem-Based Learning

PILOT Platform-Independent Learning Online Tool

SDK Sofware Development Kits

SL Second Life

SMS Short Message Service

TANGO Transition-based ANimation GeneratiOn

xix

UO Ultima Online

UTAD Universidade de Trás-os-Montes e Alto Douro

UUI Universally Unique Identifier

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


4

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


5

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, encontram-

se 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.


6

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.


7

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.


8

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.


9

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.

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


12

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:


13

� 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.


14

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.


15

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

Behaviorismo Construtivismo/Cognitivismo

Carácter passivo do sujeito

Carácter activo do sujeito

≠


16

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.).


17

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


18

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


19

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:


20

“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


21

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-da-

Cruz, 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


22

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).


23

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


24

(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 tornar-

se 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 auto-

dirigido, 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


25

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.

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


28

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).


29

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 sub-

problemas 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).


30

“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


31

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


32

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;


33

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


34

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 à


35

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


36

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.


37

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,


38

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,


39

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?”


40

� 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 sub-

soluçõ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


41

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.


42

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


43

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 envolve-

se 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.


44

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


45

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.


46

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.


47

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


48

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).


49

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,


50

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


51

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).


52

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


53

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


54

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).


55

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.


56

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).


57

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


58

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.


59

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


60

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.


61

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


62

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 conhecimentos-

base 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


63

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


64

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


65

ú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).


66

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.”


67

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.

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


70

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.


71

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.


72

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).


73

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


74

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


75

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.


76

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.


77

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


78

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.).


79

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 self-

government.”

(Morningstar & Farmer, 1991)


80

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.


81

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).


82

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;


83

� 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;


84

� 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.


85

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


86

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;


87

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).


88

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.


89

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.


90

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


91

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 Local Plataforma População Programar

There Aberto Disperso Síncrona

Internet

Multi-utilizador Sim

Kaneva Social Disperso Síncrona

Internet


Lively Social Disperso Síncrona

Internet

Multi-utilizador Não

The Sims

Online

Social

Objectivo

Disperso Síncrona

Internet


Frenzoo Social Disperso Síncrona

Internet


IMVU Social Disperso Síncrona

Internet


Activeworlds Educação Disperso Síncorna

Assíncrona

Internet


Second Life Aberto Disperso Síncorna

Assíncrona

Internet


Tabela 4.1: Características dos mundos virtuais sociais.


92

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.


93

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 multi-

utilizador. 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).


94

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.


95

Objectivo Local Plataforma População Programar

Olive Aberto

plataforma de

desenvolvimento

Disperso Licença de

utilização


OpenCroquet Aberto

Plataforma de

desenvolvimento

Disperso Gratuito Multi-utilizador Sim

Unity3D Plataforma de

desenvolvimento

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


96

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


97

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.

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


100

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).

Figura 5.1: Aspecto geral do viewer do Second Life.

Menu superior

Indicação da região onde se encontra o avatar, pelo nome e

respectivas coordenadas

Indicação da hora local no SL

Menu inferior Comunicação por

voz Comunicação

escrita - Conversas públicas


101

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$.


102

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.


103

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.


104

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.


105

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


106

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.

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.

Janela das IM em que cada separador corresponde a uma conversa privada


107

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.


108

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.


109

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.


110

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 objecto-

base. 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.


111

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.


112

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.


113

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.


114

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.


115

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.


116

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.


117

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.


118

Figura 5.19: Desenvolvimento de programas no SL.

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

Área de edição do programa

Área de mensagens


119

“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."); } }


120

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).


121

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)); } }


122

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 Descrição

integer Valores numéricos positivos e negativos; semelhantes ao int da

linguagem C.

float Valores reais.

key Identificador unívoco que é usado para objectos e avatares.

vector 3 valores reais usados em conjunto como um único item.

list Permite arquivar valores de diferentes tipos de dados; semelhante às

listas na linguagem Java.

string Conjunto de caracteres; semelhante às strings na linguagem Java.

rotation 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).


123

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(); } } }


124

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.

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


126

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.


127

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


128

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.


129

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


130

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.


131

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.

Acção Observação

Planeamento

Reflexão

Definição do problema


Reflexão

Planeamento


132

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.


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


136

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. Tratou-

se, 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.


137

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

Planeamento


Reflexão

3.º ciclo 4.º ciclo

Planeamento


Reflexão

Planeamento


Reflexão

Planeamento


Reflexão

1.º ciclo 2.º ciclo

Definição do problema


138

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ós-

secundá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.

Março Março Julho Outubro 5 Novembro 19 Novembro Janeiro Junho

Actividade Preliminar

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

2006/2007 2007/2008 2007/2008


139

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

Ciclo de

IA

Discipli

nas

Ano

curricular

Número de

Alunos

Institui

ção

A Actividade

preliminar

Lab. I 1. º 5 UTAD

B Lab. III 2. º 4 UTAD

C 1.º e 2.º

ciclo

Proj. I Pós-

secundário 6 ESTG

D Lab. II 2. º 10 UTAD

E 3.º ciclo Lab. I 1.º 5 UTAD

F 4.º ciclo Lab. I 1.º 4 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


140

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


141

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


142

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


143

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


144

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çou-

se 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


145

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.


146

Disciplinas

Ano

curricular

Linguagens de programação

anteriormente estudadas

Linguagens de

programação

em estudo

Lab. I 1.º ---- C

Lab. III 2.º 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.


147

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.


148

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.

2 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.


149

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.


150

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.

3 “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.”


151

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.


152

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;


153

� 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).


154

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.


155

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:


156

“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:


157

-“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, obrigando-

os, 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


158

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;


159

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


160

que os alunos realizaram ao longo da semana, as dificuldades sentidas e as

tentativas efectuadas para as ultrapassar.


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;


161

� 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.


162

Participantes Constatações

Lab. I

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

Dificuldades em compreender os erros de compilação;

Dificuldades em compreender como funcionam os eventos;

Lab. III


Dificuldades em compreender as funções predefinidas da linguagem;

Professora

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

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


163

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

Lab. II 1.º C C++

Proj. I Pós-Secundário 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;


164

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 professora-

investigadora. 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,


165

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.


166

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.


167

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


168

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


169

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.


170

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.


171

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


172

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.


Lab. II


Dificuldades em compreender os erros de compilação e de execução;

Dificuldades em compreender o objectivo do projecto e consequente

desmotivação dos alunos;

Dificuldades em compreender o que as funções predefinidas da linguagem;

Proj..I


Dificuldades em compreender o que as funções predefinidas da linguagem;

Professora

Constante repetição dos mesmos erros, quer de compilação quer de

execução;


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.


173


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,


174

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 bem-

sucedido 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


175

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


176

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é-


177

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”.

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.

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

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


178


Lab. II

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;

Dificuldades em saber o que faltava implementarem do projecto;

Desagrado pelo projecto que tiveram de desenvolver e consequente

desmotivação dos alunos.

Proj. I


repetição;

Agrado por aprenderem neste ambiente e pelo projecto que desenvolveram.

Professora

Dificuldade em dar resposta em tempo útil a todas as solicitações dos

alunos;


semanais.

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


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


179

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 motivaram-

nos na procura de soluções para implementarem o projecto na sua totalidade.


180

� 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.


Este ciclo teve início no segundo semestre do ano lectivo 2007/2008. Voluntariaram-

se 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:

4 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.


181

� 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.


182

� 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.


183

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


184

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 ajudou-

os 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.


185

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)


186

-“(...) 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


187

deviam estudar para a aula seguinte, criou um objecto na forma de cogumelo com a

mensagem escrita por cima (Figura 7.16).

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.

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


188


Lab. I

Explicação presencial do editor de objectos do SL evitou constantes erros

na sua utilização;


repetição;

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.

Professora Dificuldade em acompanhar o desenvolvimento do trabalho fora das aulas

semanais.

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


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


189

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 faz-

se 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.

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


192

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


193

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


194

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


195

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).


196

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


197

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


198

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.


199

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


200

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)


201

- “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


202

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, conseguiu-

se 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).


203

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

testarem e alterarem.


204

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, referia-

se 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)

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


205

-“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


206

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)


207

-“(...) 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)


208

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,


209

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


210

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.


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


214

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.


215

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


216

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


217

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, recomenda-

se 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


218

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ção-

acção.


219

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

acçã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


220

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


221

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


222

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


223

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


224

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


225

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.


226

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.


227

Elementos Procedimento recomendado

Materiais de aprendizagem

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.

Metodologia

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,


228

Elementos Procedimento recomendado

dando-lhes apoio directo na fase inicial da

aprendizagem, e seguidamente ajudar os alunos a

transitar gradualmente para uma auto-

aprendizagem.

Espaço da aula

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:

� 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.


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


232

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 multi-

utilizador 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


233

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ção-

acçã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


234

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


235

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.

236

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=S0873-65292001000300010&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.

237

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 em: <http://www.pbli.org/pbl>. Consultado em: 16 junho de 2007

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 73-84.

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.

238

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, 307-307.

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 worlds. http://cleobekkers.wordpress.com/2007/12/15/a-1ª-universidade-portuguesa-em-sl-foi-a-utad-i consultado a 9 de Setembro de 2010.

239

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. Software-Concepts & 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.

240

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

241

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.

242

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

243

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.

244

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.aspx

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.

245

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-arbitration-t.com/2008/02/28/e-justice-centre-odr-insecond-life/ Consultado a 7 de Setembro de 2009.

246

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 em http://eqplayers.station.sony.com/index.vm , a 30 Outubro, 2006.

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.

247

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, 296-300.

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&idyear=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.

248

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

249

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, consultado em http://www.habbohotel.co.uk/, a 30 Outubro, 2006

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.

250

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.

251

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 “radically-dynamic” 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 web-based programming learning environment to support cognitive development. Interacting with Computers 20,6, 524-534.

252

IBM (2007). http://domino.research.ibm.com/comm/research_projects.nsf/pages/virtualworlds.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.

253

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_de_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.

254

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 object-oriented 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), 146-156.

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.

255

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.

256

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, 467-490

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.

257

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-Vincent-Wilkes

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.

258

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.

259

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: end-user 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.

260

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 E-Learning. 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. Mcgraw-Hill Osborne Media.

261

O'Kelly, J. and Gibson, J. P. (2006). RoboCode & problem-based learning: a non-prescriptive 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.

262

Papka, M. E. (2009). Visualization and Collaboration Technologies to Support High-Performance 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.

263

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.

264

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.

265

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.

266

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.htm, 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

267

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

268

Papert, Seymour; Harel, Idit (1991). Situating Constructionism, in “Constructionism”, Ablex Publishing Corporation, Norwood, NJ, USA. Referenced from the on-line 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.

269

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, 117-126.

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 test-driven 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.

270

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), 496-514.

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.

271

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

272

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 object-oriented 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.

273

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.

274

12. Anexos I

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

276

Fonte de dados Denominação Código

Registos electrónicos Mensagens escritas trocadas entre professora e os alunos durante as aulas

Reg.

Questionários

Questionário inicial QuestI.

Questionário intermédio QuestInt.

Questionário final QuestF.

Entrevistas informais Conversas informais com prioridade mensal Ent.

Alunos de:

Proj. I (1º e 2º ciclo)

Lab. II (1º e 2º ciclo)

Lab. I (3º e 4º ciclo)

Os alunos, de cada unidade curricular, são designados pela 1º letra do nome do seu avatar. Aluno S

Alunos de:

Lab. I

Lab. III

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.

278

13. Anexos II

Planos das aulas no mundo virtual Second Life

280

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


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

281

Semana Plano Projecto: cão BOBI

1

Apresentação do mundo virtual Second Life (SL). Criar e personalizar um avatar. Adaptação ao SL.

2 Criar e modelar objectos. Fazer a ligação de objectos. Primeiro esboço do cão.

3

Introdução à linguagem LSL. Sintaxe, operadores e variáveis. Exemplos de output utilizando o canal de público. Estruturas de controlo.

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

4

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.

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.

5 Continuação da aula anterior. Colocar o robot a seguir o seu dono

6

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.

Execução das ordens recebidas.

7

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.

8 Continuação da aula anterior Rotação de objectos.

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

9 Temporizadores: criação de eventos com temporizadores.

Criar um canal de comunicação entre o cão e o seu dono. Por o cão a enviar a mensagem "estou com fome" ao dono como resposta ao evento tempo

10 Controlo do 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.

282

Semana Plano Projecto: cão BOBI

11 Envio de mensagens para um endereço de email. Leitura de informação em notecards.

Envio de emails ao dono

12 Conclusão do projecto.

283

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




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 Plano Projecto: Robot Alf

1

Apresentação do mundo virtual Second Life (SL). Criar e personalizar um avatar. Adaptação ao SL.

2 Criar e modelar objectos. Fazer a ligação de objectos.

Primeiro esboço do Robot. Criação de objectos para o aspecto visual, ligar objectos para as várias partes do robot.

3 Introdução ao LSL, revisões dos conceitos base da programação

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, actualizar o estado interno e modificar propriedades que permitem realizar um determinado comportamento, como por exemplo alterar uma cor ou alterar a posição do robot

284

Plano Projecto

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

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.

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

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.

6 Temporizadores, continuação; Introdução aos sensores Sensores: detecção de avatares e objectos num

determinado raio de acção Colocar o robot a detectar obstáculos e a desviar-se destes. 7

Sensores, detectar e desviar de obstáculos

8 Listas, inserir, retirar informação de uma lista

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.

9 Execução concorrente de código num mesmo objecto

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.

10 Enviar informação através de email

Dispor os robot de modo a formarem um triangulo Colocar os robots a seguirem o movimento do chefe do grupo

11 Continuação

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

12 Conclusão do projecto Tornar o robot num humanóide não só de aspecto mas também no movimento de braços e pernas.

285

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 Plano

1 Apresentação do mundo virtual Second Life (SL). Apresentação dos vários enunciados do projecto; Criar e personalizar um avatar.


3 Criar e modelar os objectos do projecto;

286

Semana Plano

4

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.

5 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.

6

Continuação da aula anterior. Colocar o robot a seguir o seu dono; Eventos: exemplos de event handlers pré-existentes. Entrega do algoritmo.

7

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)

8

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.

9 Continuação da aula anterior Rotação de objectos. Entrega da segunda fase do projecto (funcionalidades comer 3 em 3h)

10 Continuação do projecto. Introdução aos sensores.

11

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;

12 Implementação da segunda parte do projecto; Listas: guardar a quantidade de vendas efectuadas;

13 Conclusão do projecto

287

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 Plano

1 Apresentação do mundo virtual Second Life (SL). Criar e personalizar um avatar.


3

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.

4 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

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

288

Semana Plano

6 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 Continuação da aula anterior

10 Continuação do projecto. Entrega da terceira fase de avaliação

11 Conclusão do Projecto

289

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 Plano

1 Apresentação do projecto

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.

3 Introdução à linguagem Linden Sripting Language (LSL). Revisões dos conceitos base Sintaxe, operadores e variáveis.

4 Funções; Entrega do algoritmo

5 Discussão em grupo das soluções apresentadas

290

Semana Plano

6 Continuação do desenvolvimento do projecto

7 . Continuação. Sensores

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

9 Continuação da aula anterior

10 Continuação do projecto.

11 Conclusão do Projecto

292

14. Anexos III

Enunciado dos projectos desenvolvidos pelos alunos no mundo

virtual Second Life.

294

Licenciatura em Informática Licenciatura em Tecnologias de Informação e Comunicação

Laboratório de Informática I

Trabalho Prático

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.

Data de entrega:22 de Junho de 2007 NOTA: O trabalho deve ser entregue através do SIDE.

295

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.

296


Laboratório de Informática III

Trabalho Prático

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:


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).

Data de entrega: dia 18 de Junho de 2007

Nota: A defesa dos trabalhos pode ser efectuada em qualquer das chamadas do 2º semestre.

297

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:


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).


• 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.

298

• 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.

299


Laboratório de Informática III

Trabalho Prático

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:


Data de entrega: dia 18 de Junho de 2007

Nota: A defesa dos trabalhos pode ser efectuada em qualquer das chamadas do 2º semestre.

300

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.


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.

301

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.

302


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).

303

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.

304

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

305

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:

306

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.

307

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:


308


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

309

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.

310

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:


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:


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.

311


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

312

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.

313


Laboratório de Informática I

Trabalho Prático

– 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

Data de entrega: 23 de Junho de 2008

314

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.

316

15. Anexos IV

Questionários

317

Questionário Inicial

1. Indique o que o motivou a participar nesta experiência? 2. Já estudou anteriormente alguma linguagem de programação? 2.1.Se sim, indique qual o resultado obtido. 3. Já conhecia o mundo virtual Second Life?

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

Instituição de Ensino: _____________Nome da disciplina: ___________________

Sim Não

Sim Não

318

Questionário Intermédio

1. Esta experiência está a ser enriquecedora para si?

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.


Sim Não

319

Questionário Final

1. Sentiu dificuldades na execução deste projecto? 1.1.Se sim, identifique-as. 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


Sim Não

320

16. Anexos V

Relatórios diários das aulas no mundo virtual Second Life, assim como os relatórios dos

encontros mensais.

322

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




323

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, disseram-

me 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.

324

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.

325

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.

326

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, pedi-

lhes 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

327

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

328

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 expliquei-

lhe 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

329

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 deve-

se 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

330

“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

331

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.

332

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

333

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.

334

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”

335

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.”.

336

Relatório das aulas de Lab III


Realizadas entre Março e Junho de 2007

337

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, disse-

lhes 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

338

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

339

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

340

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.

341

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

342

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

343

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.

344

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 à

345

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

346

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.

347

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.


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.”


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.”

348


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.

349

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

350

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

351

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.

352

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.

353

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

354

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

355

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

356

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 disse-

me 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, pediram-

me 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.

357

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.

358

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

359

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.

360

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 explicar-

lhes 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

361

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, dei-

lhes 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..”

362

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.

363

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.


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.

364


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.”


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...”

365

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”.

366

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

367

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ó.

368

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.

369

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 ;

370

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

371

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

372

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.

373

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.

374

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.

375

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

376

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.

377

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.

378

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.


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.

379


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.

380

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

381

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.

382

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. Explique-

lhe 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.

383

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 ajudaram-

no 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.

384

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

385

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.

386

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.

387

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.

388

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.

389

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.

390

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

391

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.


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.


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”

392


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”.

uso do second life no suporte à aprendizagem contextualizada de programação

Documents